Servus beinand, in welchem speziellen Fall kann der Vorteil einer Harvard-Architektur gegenüber einer Von-Neumann-Architektur nicht genutzt werden?
Servus zurück, das müsste eigentlich in deinem Skript stehen. Ich meine auf Seite 32. Wann ist denn die Prüfung? Viel Zeit hast du ja nicht mehr!
Der größte Nachteil von Harvard ist die fehlende Möglichkeit selbstmodifizierenden Code zu realisieren, da Programm und Daten strikt getrennt sind.
andsche schrieb: > in welchem speziellen Fall kann der Vorteil einer Harvard-Architektur > gegenüber einer Von-Neumann-Architektur nicht genutzt werden? Wenn der uC kein RAM hat.
Neumann schrieb: > Der größte Nachteil von Harvard ist die fehlende Möglichkeit > selbstmodifizierenden Code zu realisieren, da Programm und Daten strikt > getrennt sind. Prinzipiell ist das doch nicht ausgeschlossen von der Architektur. Die Harvard Architektur basiert ja nur auf der Trennung von Code und Daten, aber nicht, dass der Code read-only sein muss. Wenn es Befehle gibt, den Code-Speicher zu modifizieren, kann ein Programm auch sich selbst modifizieren. Nur sind dafür dann eben andere Befehle notwendig. Oder übersehe ich da was?
:
Bearbeitet durch User
> Nur sind dafür dann eben andere Befehle notwendig.
Genau. Will man das ? Wahrscheinlich nicht. Auch wenn man in das
Codesegment schreiben kann, wird es schwierig wenn man nur seitenweise
schreiben kann und vorher die ganze Seite loeschen muss.
Neumann schrieb: > Der größte Nachteil von Harvard ist die fehlende Möglichkeit > selbstmodifizierenden Code zu realisieren, da Programm und Daten strikt > getrennt sind. Das heisst aber nicht, dass man in den Programmspeicher nicht schreiben kann, das ist ja offensichtlich bei Flash-Versionen, also im Prinzip kann der Prozessor durchaus sein Programm verändern. Ob das eine gute Idee ist, ist nochmal eine ganz andere Frage. Was man nicht so ohne weiteres kann, ist Code im RAM ausführen, z.B. weil die Wortlänge von Code und Daten unterschiedlich ist. Aber auch das liesse sich lösen wenn man nur will, man kann ja auch einen Teil des Programmspeichers als RAM ausführen, z.B. zum Debuggen. Georg
Ich würde noch einwerfen, dass die Harvard-Architektur keine großen Vorteile mehr hat, wenn man SIMD-Befehle einführen würde. Je nachdem wie viele Daten da aufeinmal verarbeitet werden wird der Daten-Bus mehr belastet. (Harvard-Architektur wird ja gerne mit RISC-Befehlssätzen verbunden)
andsche schrieb: > in welchem speziellen Fall kann der Vorteil einer Harvard-Architektur > gegenüber einer Von-Neumann-Architektur nicht genutzt werden? Wie, "der Vorteil"? Gibt doch mehrere. Wenn man bei Neumann den Code in einem ROM hat, fällt der Vorteil von Harvard weg, daß ein Datenfehler keinen Code modifizieren kann (buffer overflow), weil das im ROM auch bei Neumann nicht geht. Andererseits bleibt aber der Vorteil von Harvard, daß Daten- und Adreßbus getrennt sind, was von der Geschwindigkeit her besser ist. Weil sich Code-Fetch und Daten-RW nicht in die Quere kommt.
Nop schrieb: > Andererseits bleibt aber der Vorteil von Harvard, daß Daten- und > Adreßbus getrennt sind Wer sagt denn, dass sie das sind - siehe 8051-Architektur. Das ist garkeine Frage von Harvard oder nicht. Georg
Ja gut, was genau nun Harvard ist, das ist halt umstritten. Umgedreht haben Cortex-M zwar separate Busse für Daten und Befehle, können die aber trotzdem im selben Speicherbaustein haben.
Nop schrieb: > Ja gut, was genau nun Harvard ist, das ist halt umstritten. Umgedreht > haben Cortex-M zwar separate Busse für Daten und Befehle, können die > aber trotzdem im selben Speicherbaustein haben. Umstritten ist die Definition an sich nicht. Aber heutige Prozessoren können meist nicht 1:1 zugeordnet werden, da sie meist Hybrid-Formen der beiden Architekturen sind. Man denke nur mal an die vielen Caches die es mittlerweile gibt, MMUs und NUMA in Zeiten von Mehr-Kern-Prozessoren.
Hallo, ich fürchte das nützt dem TO bei seiner Prüfung alles nichts mehr, aber ehrlich gesagt ist mir das auch herzlich egal. Vielleicht ist er ja inzwischen auf dem Klo erfroren. Georg
Robin R. schrieb: > Nop schrieb: >> Ja gut, was genau nun Harvard ist, das ist halt umstritten. Umgedreht >> haben Cortex-M zwar separate Busse für Daten und Befehle, können die >> aber trotzdem im selben Speicherbaustein haben. > > Umstritten ist die Definition an sich nicht. Doch. Die Unterscheidung ergibt schon seit Jahrzehnten nur noch auf der Ebene der Adressräume einen Sinn. Dennoch rudern viele immer noch auf der hoffnungslosen Definition über irgendwelche physikalischen Busse herum. Anno Harvard Mark I gab es diese Unterscheidung nicht, später schon.
:
Bearbeitet durch User
A. K. schrieb: > Die Unterscheidung ergibt schon seit Jahrzehnten nur noch auf der > Ebene der Adressräume einen Sinn Die Unterscheidung ist überhaupt nur noch zum Quälen von Studenten mit sinnarmen Definitionen gut. Bei einem konkreten Prozessor steht im Manual, welche Adressräume er hat und welche Busse, da gibt es vielfältige Variationen, und alles andere ist irrelevant. Die beiden Johns, Harvard und von Neumann, sind schon lange tot und können sich nicht mehr wehren, aber vermutlich berührt es sie auch nicht mehr welche Achitektur nach ihnen benannt wird. Mir ist das beim Entwurf eines Prozessorsystems auch herzlich egal, meinetwegen kann der Prozessor auch nach John Lennon benannt sein. Georg
A. K. schrieb: > Dennoch rudern viele immer noch auf > der hoffnungslosen Definition über irgendwelche physikalischen Busse > herum. Das kann auch immer noch ein Argument sein, denn wenn man sich mal den Cortex-M4 ansieht, dann gehen sowohl das "große" SRAM als auch das ROM sowohl für Code als auch für Daten. Also von Neumann, obwohl unterschiedliche Busse für Daten und Instruktionen da sind, die aber zu beiden führen. Und dann haben wir noch das CCM-RAM, aus dem man keinen Code ausführen kann. Das liegt aber nicht am Adreßbereich, sondern daran, daß das nur über den Datenbus angebunden ist und nicht über den Befehlsbus. Typischer Harvard-Effekt.
Es ist eigentlich prinzipiell sinnvoll Unterscheidungen zu treffen. Nur durch Analyse und Differenzierung kann man doch erst neue Ideen synthetisieren. Sicher ist es für den täglichen Gebrauch total unwichtig, dass Luft aus ~78% Stickstoff, ~21% Sauerstoff, ~0.9% Argon und ~0,04% anderem Zeug besteht. Aber für viele wissenschaftliche Entdeckungen ist eine Unterscheidung doch durchaus wichtig. Wie oft kommt hier jemand ins Forum und wird zerlegt weil er sozusagen Strom nicht von Spannung unterscheiden kann. Oder weil er Arduino nicht von C++, AVR Controllern, einer IDE oder einer C++-Bibliothek unterscheiden kann. Ich denke, die Definitionen und damit die Differenzierung von Harvard Architektur und Neumann ermöglicht es doch erst über Vor- und Nachteile dieser nachzudenken. Überhaupt erst dadurch kann man ja auch erfassen, dass ein hybrides Modell eventuell viel praktikabler ist. Aber das ist natürlich sehr theoretisch und akademisch, ich schlage vor, in Zukunft nicht zwischen Wechsel- und Gleichstrom bzw. -Spannung zu unterscheiden. Werfen wir alles einen Topf und nennen es "Wirbelblitzdings", weil wenn man an 230VAC fasst, blitzt es und wirbelt einen umher. Oder ist die Unterscheidung auch zu akademisch? ;-)
Robin R. schrieb: > Wie oft kommt hier jemand ins Forum und wird zerlegt Wer ist hier von wem zerlegt worden? > weil er sozusagen Strom nicht von Spannung unterscheiden kann. Der Threadstarter hat sich nicht einmal die Mühe gemacht, zu seiner Hausaufgabe auch nur einen einzigen eigenen Gedanken beizutragen. Das ist eigentlich die Mindestanforderung bei geposteten Hausaufgaben. > Ich denke, die Definitionen und damit die > Differenzierung von Harvard Architektur und Neumann ermöglicht es doch > erst über Vor- und Nachteile dieser nachzudenken. In der Diskussion darüber ist kein Anfänger beteiligt, jedenfalls nicht soweit es dem Stil der Beiträge zu entnehmen ist. > Oder ist die Unterscheidung auch zu akademisch? ;-) Es ist also sinnlos, über den Sinn bestimmter geradezu per Definition akademischer Definitionen nachzudenken, weil die Diskussionen über diese Definitionen dann zu akademisch werden?
:
Bearbeitet durch User
A. K. schrieb: >> weil er sozusagen Strom nicht von Spannung unterscheiden kann. > > Der Threadstarter hat sich nicht einmal die Mühe gemacht, zu seiner > Hausaufgabe auch nur einen einzigen eigenen Gedanken beizutragen. Das > ist eigentlich die Mindestanforderung bei geposteten Hausaufgaben. > Ja, von dem rede ich auch gar nicht mehr. Der hat sich ja nichtmal weiter in die Diskussion eingebracht. Ich dachte das Thema ist mittlerweile in das Allgemeininteresse übergegangen. > >> Oder ist die Unterscheidung auch zu akademisch? ;-) > > Es ist also sinnlos, über den Sinn bestimmter geradezu per Definition > akademischer Definitionen nachzudenken, weil die Diskussionen über diese > Definitionen dann zu akademisch werden? Nein nein, ich denk schon, dass man darüber diskutieren sollte. War ja auch nicht ganz ernst gemeint, daher das ";-)". Vermutlich ist Harvard vs. Neumann in heutiger Zeit eher von historischem Interesse. Und eine Diskussion über die verschieden Pipelining- und Caching-Architekturen viel wichtiger.
Das sollte eigentlich sauber definiert sein. Bevor ich auf das Thema Harvard eingehe, mal etwas zur Relativierung von Bezeichnungen in der Technik. Jeder von uns kennt den Begriff Baudrate zur Kennzeichnung der Geschwindigkeit einer seriellen Datenübertragung. Der Begriff hat sich etabliert, auch an den Hochschulen wird er für den genannten Zweck verwendet. Wenn man allerdings mal näher darauf sieht, dann setzt sich dieser Begriff aus den Begriffen Baud, als eine physikalische Einheit und Rate, als Ableitung nach der Zeit (bzw. Ereignisse pro Zeitabschnitt) zusammen. Da nun aber Baud die Einheit für die Schrittgeschwindigkeit (z.B. von Fernschreibern) ist, würde es bei der Zuordnung einer seriellen Übertragung der Einheit Bit/s entsprechen, also der Übertragungsgeschwindigkeit. Die Baudrate wäre demnach die Ableitung von Bit/s nach der Zeit also die Bitbeschleunigung. Ich kann das in meinen Vorlesungen allerdings nur als Denkanstoß erwähnen. Den Begriff formal zu korrigieren wäre ein Kampf gegen Windmühlen. So, nun aber zu Harvard. Ja, es gibt die formale Unterscheidung zwischen Code- und Datenbus und theoretisch könnte man den 8051 in diese Schublade stecken. Allerdings sollte man einmal den Hintergrund dieser Definition betrachten. Die Trennung von Code- und Datenspeicher hat zwei wesentliche Gründe. 1. Man kann die Bitbreite der Busse voneinander unabhängig festlegen. Also z.B. eine 8-Bit-Befehlskodierung mit einer 64-Bit-Datenauflösung kombinieren. (Oder sogar umgekehrt, wenn man Zeiger in die Befehle kodiert). 2. Man kann die Fetch-Zyklen voneinander separieren und bei der Befehlsdekodierung bereits die Daten laden bzw. beides physikalisch entkoppeln. (Die ersten PCs hatten ihre Befehle und Daten direkt aus dem RAM geholt, keine Frage, das war gewiss nicht Harvard. Wer sich aber mal mit den Fetch-Zyklen moderner Prozessoren und ihren diversen Cache-Speichern befasst, wird schnell erkennen, dass wir hier eine innere Harvard-Architektur und eine äußere von-Neumann-Architektur haben). Der 8051 kann weder das Eine noch das Andere. Code- und Datenzugriffe erfolgen streng nacheinander und mit gleicher Bitbreite. Ich denke, es war einfach eine pfiffige Idee der Entwickler des 8051, über ein einzelnes Bit (PSEN) zwischen RAM und ROM zu unterscheiden und dieses von der Art des Fetch abhängig zu machen. Doppelter Speicherbereich und die im letzten Jahrhundert bei den MC übliche Aufteilung von Code und Daten in entsprechenden Bausteinen (ROM/EPROM und RAM) haben dem 8051 einen Vorteil verschafft. Das sei ihm gegönnt. Hier aber von einer Harvard-Architektur zu sprechen würde den Sinn einer solchen Architektur entstellen. Ich hoffe, dass sich diese Zuordnung von Harvard und 8051 nicht etabliert, denn für mich wäre das wieder eine ähnliche Begriffsvernebelung wie bei der Bitbeschleunigung.
Ein Jahr später wird den Gast dieses Thema sicher nicht mehr interessieren. Wahrscheinlich bekommt er gar nicht mit, wie viel Mühe Du Dir mit deinem ausführlichen Beitrag gemacht hast.
Ja, das stimmt. Ich habe auch inzwischen gesehen, dass das Thema hier an vielen anderen Stellen diskutiert wird und ich meinen Beitrag besser an anderer Stelle platziert hätte. Aber ich kann ihn bei Gelegenheit ja an anderer Stelle zitieren. Was mir heute morgen noch eingefallen ist: Der 8051 hat nur einen physikalischen Datenbus, über den sowohl Code als Daten übertragen werden. Allein das verbietet eine Zuordnung zu Harvard.
In der Schule lernten wir (ich zumindest) die schwarz-weiße Welt von Harvard versus von Neumann Architektur. Aber es gibt auch viele Graustufen dazwischen und sicher auch Chips die ganz anders funktionieren. Die Entwicklung ist eben nicht in der Mitte des letzten Jahrhunderts stehen geblieben.
Hallo, das der 8051 ist auch etwas in die jahre gekommen. Er wird dieses Jahr stolze 38 Jahre alt. Damals war jeder pin extem teuer. 24 zusätzliche Pins (16 Address und 8 Datenleitungen) zu spendieren währe unwirtschaftlich gewesen. Selbst beim Herausgeführten Bus wurde aus kostenbründen addressen und Daten gemultiplext. Der baustein hatte nur 40Pins! Allen für den Bus ging die hälfte der IOs drauf. Weiter gibt es keinerlei Piplines, ein Zyklus benötigt 12 Takte, ... Der interne buss ist nur 8Bit breit. Darüber wird alles angesprochen. Addressen Daten ProgrammCode, ... daher vermutlich auch die 12 takte je Zyklus. Damals wäre das auch viel zu aufwendig gewesen so breite busse und ggf auch noch getrennte zu designen. CAD Systeme waren damals noch nicht so leistungsfähig wie heute damals ano 1980. Für mich ist der 8051 logisch eine "Harvard" Architektur. Der Programmspeicher kann intern nicht von der Software selber überschrieben werden (einerseits von der Technologie des Speichers bedingt andererseits fehlen hier die notwendigen instruktionen). Weiter kann keine Code aus dem Internen RAM abgearbeitet werden. Harvard verbietet meines wissens nicht den gleichen buss zu verwenden. Logische und physikalische trennung ist gefodert für die klassifizierung und die ist meines erachtens gegeben. Was am externen buss gemacht wird, ... ist etwas anderes. Hier kann durch entsprechende beschaltung der geleiche Speicherbereich für Programmspeicher und für RAM addressierbar gemacht werden. Damit fällt Harvard. Mit dem nachteil das der maximal zur verfügung stehende Speicher durch die doppeltnutzung reduziert wird. Dadurch sind aber auch erst Monitorprogramme möglich mit der man sich jede menge zeit mit IC Programmierung und löschen sparen konnte. Das debugging wurde damit auch erst möglich, ... (HW Breakpoints gab es noch nicht, ... und Emulatoren waren extrem extrem teuer) gruss
Termite schrieb: > Für mich ist der 8051 logisch eine "Harvard" Architektur. Der > Programmspeicher kann intern nicht von der Software selber überschrieben > werden (einerseits von der Technologie des Speichers bedingt > andererseits fehlen hier die notwendigen instruktionen). Weiter kann > keine Code aus dem Internen RAM abgearbeitet werden. Das ist doch aber nicht die Kernaussage einer Harvard-Architektur, sondern eher eine Folge unterschiedlicher Datenbusse. Hier hat sich jemand mit dem Thema kompetent auseinandergesetzt: https://bernd-leitenberger.de/harvard-neumann.shtml Daraus die Kernaussage: Die Harvard-Architektur trennt dagegen Daten und Code. Es gibt zwei Datenbusse und sehr oft auch zwei Adressbusse. Die Vorteile: Während ein Befehl dekodiert wurde können die Daten eingeladen werden, während der nächste Befehl geholt wird können die Ergebnisse geschrieben werden. Was beim 8051 gemacht wurde, ist eine Trennung von Code- und Datenspeicher in unterschiedliche Adressräume. Das hat man seinerzeit auch mit dem 8086 über die Segmentregister (steuerbar) eingerichtet, also unterschiedliche Adressbereiche für Code und Daten. Ist jemand auf die Idee gekommen, dem 8086 deswegen eine Harvard-Architektur zuzuschreiben? Das Thema treibt mich deshalb um, weil ich selbst in der Ausbildung tätig bin und es mir wichtig ist, was man den Studenten mitteilt. Natürlich schließe ich Fehler bei mir nicht aus, aber ich bemühe mich, diese zu korrigieren.
> Weil es mir wichtig ist, was man den Studenten mitteilt.
Ich würde diese beiden Architekturen gar nicht mehr lehren, weil
praktisch alle aktuellen Produkte anders funktionieren.
Stattdessen würde ich über Adressräume und deren Mapping sprechen. Denn
das macht bei allen Architekturen (auch Harvard und von Neumann)
gleichermaßen Sinn.
Hallo Was sind die Kriterien für eine Harvard Architektur? Getrennter Daten und Code speicher sollte der der 8051 doch haben. Data ist RAM (128 Byte) code ist Maskenprogramierter ROM oder EPROM. Haben auch beide getrennte Addressräume. Der RAM hat ein eigenes RAM address register und geht direkt aufs RAM. Das Programm address register geht auf das Code Speicher. Das ganze ist über einen internen Bus an die ALU angebunden. über den alle Daten Teiladressen PIO / ... zugriffe laufen. Vermutlich macht das Ihrer Meinung nach den MCS-51 zu einer von Neuman Architektur. Wobei es einige eigenschaften vom MCS-51 gibt die der von Neuman Architektur wiedersprechen. Blockschaubild MSC51 https://de.wikipedia.org/wiki/Intel_MCS-51 So oder ähnlich ist es auch in den Intel Datenblättern Bei den ARM cores lässt sich sicher auch streiten, ... bis wo hin gehen wir hier? zählt nur der Core, dann ist des für mich eine Harvard Architektur. Sicher eindeutiger als der 8051. nur ich bezweifle das einen reinen ARM core wie den ARM7TDMI jemals einer zu gesicht bekommen hat. Nehmen wir alles, was ARM so liefert ist das für mich wieder von Neuman, ... zumindest füht sich das beim entwickeln so an. (ich can code aus dem RAM laufen lassen wenn ich das will. ich kann das auch verhindern wenn ich das will. Code aund RAM haben den Gleichen Addressraum) Bei den Cortex lässt sich das leider nicht mehr so gut unterscheiden, beim ARM 7 / 9 gab war das Eindeutiger da hatte der reine Core eine eigene bezeichnung ARM7TDMI / ARM9TDMI. Basierend darauf gab es dann z.B. den ARM740T der Basiert auf dem ARM7TDMI, reichert ihn aber um MPU und Caches an und vereint dadurch die beiden busse und Addressräume auf einem AMBA Bus. ps. bitte nicht duch die 80er serie verwirren lassen. es ist nirgendwo beschrieben welche ICs alle darunter fallen? z80 8080 8085 8086 8008 8048 8051 gruss
Das klassische Beispiel für Harvard sind die ersten DSPs eben wegen VLIW-Befehlsstruktur und typischerweise festem Code und variable Daten. Von Neumann steht dagegen für variable Programme via Compiler auf dem System und auch eher Downloadfähigkeit.
@Termite Was ist denn daran nicht zu verstehen, dass eine Harvard-Architektur den "gleichzeitigen" Fluss (Fetch, etc.) von Code und Data auf physikalisch getrennten Bussen ermöglicht?
Termite schrieb: > Was sind die Kriterien für eine Harvard Architektur? Getrennte Busse für Daten und Code, so dass während der Prozessor den nächsten Befehl einliest, gleichzeitig auf Daten zugegriffen werden kann und diese Zugriffe nicht nacheinander ausgeführt werden müssen. > Das ganze ist über einen internen Bus an die ALU angebunden. Genau: Über einen Bus. > Vermutlich macht das Ihrer Meinung nach den MCS-51 zu einer von Neuman > Architektur. Wobei es einige eigenschaften vom MCS-51 gibt die der von > Neuman Architektur wiedersprechen. Wie schon oben stand: Heute kann man nicht mehr jeden Prozessor eindeutig zuordnen. Es gibt erweiterte Formen und es gibt Mischformen. Selbst der AVR, den ich am ehesten als Harvard-Architektur sehe, ist eine erweiterte Form davon. Erweitert, weil man Daten auch aus dem Codespeicher lesen kann. > Bei den ARM cores lässt sich sicher auch streiten, ... bis wo hin gehen > wir hier? zählt nur der Core, dann ist des für mich eine Harvard > Architektur. Sicher eindeutiger als der 8051. nur ich bezweifle das > einen reinen ARM core wie den ARM7TDMI jemals einer zu gesicht bekommen > hat. Ich habe schon eine Firmware für einen ARM7TDMI geschrieben und wüsste nicht, warum das Harvard sein sollte. > Nehmen wir alles, was ARM so liefert ist das für mich wieder von Neuman, > ... zumindest füht sich das beim entwickeln so an. (ich can code aus dem > RAM laufen lassen wenn ich das will. Viele machen den Fehler, bei Harvard immer erst an eine Trennung RAM/Flash zu denken. Darum geht es aber nicht. Es ist eine Trennung zwischen Code- und Datenspeicher. Das ist ganz unabhängig davon, von welchem Typ diese Speicher sind. Abdul K. schrieb: > Das klassische Beispiel für Harvard sind die ersten DSPs eben wegen > VLIW-Befehlsstruktur und typischerweise festem Code und variable Daten. Soweit ich weiß, gab es da auch noch deutlich erweiterte Varianten mit zwei oder sogar drei getrennten Bussen für Datenspeicher, um z.B. sehr schnell große Mengen von Werten aus Speicher A mit Speicher B in irgendeiner Weise verknüpfen und das Ergebnis in Speicher C ablegen zu können, ohne dass sich die Zugriffe alle ins Gehege kommen.
Hallo, Mir ist schon klar das 2 Busse vorhanden sein müssen. Nur müssen die physikalisch vorhanden sein? oder reicht es wenn diese "virtuell" vorhanden sind. An vielen stellen wird nur von getrennten Addressräumen geredet. Wenn der bus physikalisch vorhanden sein muss nach definition, dann ist die unterscheidung historisch. Siehe MCS-51. Was heist hier z.B. gleichzeitig? in absoluter laufzeit gesehen? oder auf cycles ebene? Der MSC-51 braucht für ein INC adr genau einen Cycle. Der 8086 braucht alein dafür schon mindestens 3 cylcles bzw. 15 wenn auf den speicher zugegriffen werden muss. Der MCS-51 hat einen internen 8 Bit buss. an dem so zimlich alles dranhängt und alles Mögliche übertragen wird. Intel hat ihn dodumentiert. Hätte sie aber auch nicht machen müssen. Der bus ist on chip. wir können ihn nicht modifizieren und auch nicht beeinflussen wie, was übertragen wird. Der MCS-51 braucht nicht um sonst 12 Takte für einen Cycle. Innerhalb eines Cycles ist das "gleichzeitig". Wenn man das auf Takt ebene betrachtet ist das sequenziell. gruss.
Die 12 Takte beim 8051 kommen von der internen seriellen Bitverarbeitung, die nur außen als 8bit parallel erscheint. So das Gerücht.
Termite schrieb: > Hallo, > > Mir ist schon klar das 2 Busse vorhanden sein müssen. Nur müssen die > physikalisch vorhanden sein? oder reicht es wenn diese "virtuell" > vorhanden sind. An vielen stellen wird nur von getrennten Addressräumen > geredet. Für mich zumindest ist das physische Vorhandensein Voraussetzung. > Wenn der bus physikalisch vorhanden sein muss nach definition, dann ist > die unterscheidung historisch. Auch das habe ich ja schon geschrieben. > Was heist hier z.B. gleichzeitig? in absoluter laufzeit gesehen? oder > auf cycles ebene? Was ist denn so schwer dran zu verstehen? Gleichzeitig heißt, dass ich zwei seprate Kanäle habe (einen für den Code, einen für die Daten), so dass es möglich ist, dass über beide unabhängig von einander eine Übertragung stattfinden kann. Ich muss nicht die beiden Übertragungen miteinander mulitplexen, um sie über den selben Kanal zu schicken. > Der MSC-51 braucht für ein INC adr genau einen Cycle. > Der 8086 braucht alein dafür schon mindestens 3 cylcles bzw. 15 wenn auf > den speicher zugegriffen werden muss. Aktuellere x86-Prozessoren brauchen mehrere Hundert Taktzyklen, wenn auf den Speicher zugegriffen werden muss (also falls es noch nicht im Cache liegt). Das hat dann aber eher damit zu tun, dass der Speicher so langsam ist im Vergleich zum Prozessor. > Der MCS-51 hat einen internen 8 Bit buss. an dem so zimlich alles > dranhängt und alles Mögliche übertragen wird. Intel hat ihn > dodumentiert. Hätte sie aber auch nicht machen müssen. Der bus ist on > chip. wir können ihn nicht modifizieren und auch nicht beeinflussen wie, > was übertragen wird. Der MCS-51 braucht nicht um sonst 12 Takte für > einen Cycle. Da sieht man dann auch den Unterschied. Der AVR braucht für einen Cycle einen Takt. Zum Lesen eines Bytes aus dem RAM braucht er einen Cycle. Während er aus dem RAM den Wert liest, kann er bereits gleichzeitig den nächsten Befehl aus dem Codespeicher laden, so dass im nächsten Taktzyklus dieser gleich bearbeitet werden kann.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.