Forum: Mikrocontroller und Digitale Elektronik Harvard vs Neumann 8051


von guest123 (Gast)


Lesenswert?

Hallo,

bei harvard gibt es einen externen Programmspeicher und Datenspeicher. 
Das PSEN wird von CPU aktiviert, wenn es von dem Speicher lesen will und 
natürlich mus CS(Chip select) aktiviert sein.

Aber schreiben kann man auf den Programmspeicher nicht bei harvard? WR 
und RD sind mit Datenspeicher verbunden.

Bei von Neumann sieht das anders aus, hier gibt es z.b. nur ein RAM, wo 
Programm und Datenspeicher drinnen sind.

Falls man lesen will muss RD und PSEN aktiviert sein(über UND zu RAM 
führen). Bei schreiben nur WR.

Aber aufjedenfall weiß man hier nicht ob man nun Programm liest oder 
Daten liest. Schreiben kann man doch beides oder?

Habe ich das richtig verstanden?

mfg

von Deutschlehrer (Gast)


Lesenswert?

Naja.

So halb ist's recht, so halb ist's schlecht.

von Georg G. (df2au)


Lesenswert?

/RD und /WR sind für den Datenspeicher zuständig. Für den 
Programmspeicher ist /PSEN das Lesesignal.

von Deutschlehrer (Gast)


Lesenswert?

>bei harvard gibt es einen externen Programmspeicher und Datenspeicher.

Ob "extern" oder "intern" ist für Charakterisierung von Harvard nicht 
entscheidend.
Charakteristisch ist vielmehr das es sich um "getrennte" Speicher 
handelt.
Getrennt in dem Sinne, dass die entsprechenden Register und 
Befehlsbestandteile entweder den Programmspeicher oder den Datenspeicher 
adressieren können.

>Aber schreiben kann man auf den Programmspeicher nicht bei harvard?
Der "reinen Lehre" folgend, nicht. Aber in der Praxis (siehe AVR) gibt 
es dennoch Möglichkeiten.

>hier gibt es z.b. nur ein RAM, wo Programm und Datenspeicher drinnen sind.
Naja. Das ist so etwa, als wenn Du von einem Auto sagst das ein VW oder 
ein Peugot drinnen wäre.

Ein RAM ist schon ein Datenspeicher. Da kann nicht noch ein 
Datenspeicher drinnen sein. Genausowenig ein Programmspeicher.
Was Du wahrscheinlich schreiben wolltest, ist: Es gibt nur einen RAM in 
dem Daten und Programme gemeinsam (genauer in einem Adressraum) 
gespeichert werden.

>Aber aufjedenfall weiß man hier nicht ob man nun Programm liest oder >Daten 
liest.
Nun, wer ist hier "man"? Wenn Du Dir mal die Befehlsätze anschaust, dann 
gibt es Befehle die Daten (hier im allgemeinsten Sinne) schreiben und 
lesen. Nehmen wir solche wie Store und Load. Bei einem von 
Neumann-Prozessor können diese auf Programme wie auf Daten angewendet 
werden.
Bei Befehlen wie Jump oder Call ist aufgrund der Tatsache, das deren 
Opcode vom Befehlszähler adressiert wurde klar das es sich um Programm 
handelt. Bei von Neumann gibt es Grenzfälle, wo ein zuvor mit store 
gespeichertes Datum ein gültiger Opcode ist. Sogenannter 
Selbstmodifizierender Code.
Wer aber "weiß" das? Der Programmier!

von Alfred E. N. (Gast)


Lesenswert?

Was sind die Vorteile?

Bei Harvard kann doppelt soviel Speicher adressiert werden, als der 
lineare Adressraum zu lässt. Beim 8051 sind 64k Code und 64k RAM.

Bei Harvard können die beiden Speicher an getrennten Bussen liegen. Dann 
kann gleichzeitig zugegriffen werden. Ein DMA Transfer kann parallel zum 
Codefetch erfolgen.

von Deutschlehrer (Gast)


Lesenswert?

>Bei Harvard kann doppelt soviel Speicher adressiert werden, als der
>lineare Adressraum zu lässt. Beim 8051 sind 64k Code und 64k RAM.

Mit Verlaub: Das ist kein der Harvard-Architektur innewohnende, ihre 
Eigenart wesentlich bestimmende Eigenschaft. Die Größe der Speicher 
hängt von der Breite der Register ab. Deren Breite wird von der 
Spezifikation bestimmt, kann also so oder so sein. Aber sie wird nicht 
von der Art der Architektur bestimmt. Schon garnicht war das die Absicht 
bei der Idee.

>Bei Harvard können die beiden Speicher an getrennten Bussen liegen. Dann
>kann gleichzeitig zugegriffen werden. Ein DMA Transfer kann parallel zum
>Codefetch erfolgen.

Ebenso ist dies kein Wesensmerkmal der Harvard-Architektur. Nehme einmal 
an, ein Neumann-Prozessor führt auch zwei Datenbusse auf ein 
Dual-Port-RAM. Dann wäre das dort auch möglich.

von Georg G. (df2au)


Lesenswert?

Alfred E. N. schrieb:
> Ein DMA Transfer kann parallel zum
> Codefetch erfolgen.

Das gab es schon beim Urahnen der CPUs, dem Z80. Im M1 Zyklus wurde der 
DMA Zugriff versteckt.

Harvard oder Neumann ist eher Glaubenssache, beide haben Vorteile und 
Nachteile. Ein Vorteil der getrennten Bereiche wurden von Intel und 
Kleinstweich mit dem "no Execution" Bit vor kurzem ja auch erkannt. Und 
für den 8051 gab es von Anfang an Vorschläge, wie man die Nachteile der 
getrennten Bereiche mit ein wenig Hardware umgehen konnte.

von Alfred E. N. (Gast)


Lesenswert?

Harvard kann doppelt soviel Speicher ansprechen, wie der Adressbus zu 
lässt. Code und Daten liegen auf gleichen Adressen in unterschiedlichen 
Speichern.
Korrigierte lieber die Linksschreibung. :-P

Bei Dualportet Speichern darf schreibend nicht gleichzeitig zugegriffen 
werden.

von Deutschlehrer (Gast)


Lesenswert?

>Harvard kann doppelt soviel Speicher ansprechen, wie der Adressbus zu
>lässt. Code und Daten liegen auf gleichen Adressen in unterschiedlichen
>Speichern.

Nimm an, ein Harvard-Prozessor hat einen 16Bit Adressbus für den 
Programmspeicher und einen 20Bit Adressbus für den Datenspeicher. Es 
gilt dann also nicht, was Du geschrieben hast. Ist es trotzdem ein 
Harvard-Prozessor?

Wenn Nein: Warum nicht? Das entscheidende ist die Trennung der Speicher. 
Nicht die Trennung der Busse oder der Vergleich der beiden Grö0en.


>Bei Dualportet Speichern darf schreibend nicht gleichzeitig zugegriffen
>werden.

Das darf man durchaus. Kommt auf den Speicher an.

Aber es geht hier um was anderes. Das war nur ein Beispiel.

>Bei Harvard können die beiden Speicher an getrennten Bussen liegen. Dann
>kann gleichzeitig zugegriffen werden. Ein DMA Transfer kann parallel zum
>Codefetch erfolgen.

Es ist richtig, das man bei Neumann nicht von verschiedenen Speichern 
sprechen kann, deswegen also auch keine getrennten Busse haben kann. 
Also kann man nur bei Harvard überhaupt erwägen getrennte Busse 
vorzusehen. Mein Fehler.

von Deutschlehrer (Gast)


Lesenswert?

>Korrigierte lieber die Linksschreibung. :-P

Und bitte verkneife Dir solche Angriffe. Ich setze Dich ja auch nicht 
herab, weil Du die Harvard-Architektur noch nicht voll verstanden hast.

von Bastler (Gast)


Lesenswert?

Getrennter Speicher für Daten und Code kann auch bedeuten, daß man 8-Bit 
Einheiten im Datenbereich adressieren kann (wie allgemein üblich), aber 
Befehle auch mal 17 Bit haben dürfen, wenn man eben soviel braucht, um 
die CPU zu steuern.

von Wilhelm F. (Gast)


Lesenswert?

guest123 schrieb:

> Aber schreiben kann man auf den Programmspeicher nicht bei harvard? WR
> und RD sind mit Datenspeicher verbunden.

Da die Überschrift sich um 8051 dreht:

Beim 8051 sagt man, er hat eine Harvard-Architektur. Eben, weil alle 
Speicher separate Adreßräume haben. Es gibt (bzw. gab) aber 
Entwicklungsboards mit 8051 und dessen Derivaten, wo die Signale PSEN, 
RD und WR logisch miteinander verknüpft sind. Dort kann man 
Testprogramme vom PC ins RAM laden, und ausführen. Im ROM befindet sich 
dann nur ein Bootloader. Das ist zwar heute etwas veraltet, weil moderne 
µC ja Flash haben. Ein Vorteil bleibt aber: Mit dem RAM flasht man 
nichts kaputt, kann es beliebig oft neu mit Code bespielen. Das ist aber 
auch mehr theoretisch: Zum kaputt flashen müßte man wochenlang 
ununterbrochen nur Programme bespielen, um die 10.000 oder 100.000 
Flash-Zyklen zu erreichen. Nachteil: Der Code im RAM verschwindet nach 
Stromabschaltung. Auch kann man nicht die vollen 64k Codebereich nutzen, 
vielleicht die Hälfte, wenn ein RAM ein 32k-Typ ist, aber das spielt 
meistens keine Rolle. Unter Umständen kann sich ein Programm auf diese 
Weise während der Laufzeit sogar selbst den Codespeicher ändern, z.B. 
ein Konstanten-Array mit Parametern, der ja dann im RAM ist, und wenn 
man das wirklich wünscht.

Ich selbst habe auch noch solche Boards, z.B. Compuboard mit 8032 oder 
80C535 von Elektor, und arbeite sogar gelegentlich noch damit. So lange 
die für meine benötigte Performance reichen, denn ich baue nicht nur 
Raketen für den Space, ist das voll OK. ;-)

von Reinhard Kern (Gast)


Lesenswert?

Deutschlehrer schrieb:
> Es gibt nur einen RAM in
> dem Daten und Programme gemeinsam (genauer in einem Adressraum)
> gespeichert werden.

Wenn man schon jemanden korrigieren will, dann sollte es auch stimmen 
(ganz besonders als Lehrer): ein v.Neumann-Prozessor kann keineswegs 
bloss RAM adressieren, das ist sogar völlig unüblich bzw. technisch 
garnicht möglich. In fast allen Fällen besteht ein Teil des Speichers 
aus ROM, ein Teil aus RAM. Ohne ROM startet das System nicht.

Gruss Reinhard

von Svenska (Gast)


Lesenswert?

> In fast allen Fällen besteht ein Teil des Speichers
> aus ROM, ein Teil aus RAM. Ohne ROM startet das System nicht.
Du musst nur den RAM vor dem Start des System mit gültigen Daten 
befüttern, dann geht das.

Macht man bei manchen Militärgeräten (Drohnen, Raketen), damit der 
Gegner nicht an das Programm kommt.

von Reinhard Kern (Gast)


Lesenswert?

Svenska schrieb:
> Du musst nur den RAM vor dem Start des System mit gültigen Daten
> befüttern, dann geht das.

Dazu braucht man einen Bootloader (wo steht der wohl) oder ein externes 
System, z.B. einen ICE - von sich aus kann das kein System, egal ob 
Havard oder v. Neumann. Auch Schalterregister wie bei der alten PDP8 zur 
manuellen Eingabe des Startcodes kam man wohl kaum als RAM bezeichnen 
(für eine Flugabwehrraktete auch eher unpraktisch).

Oder man ist Lehrer und braucht sich mit der blöden Realität nicht 
befassen, stattdessen hat man ja seine berufsbedingte Autorität.

Gruss Reinhard

von (prx) A. K. (prx)


Lesenswert?

Georg G. schrieb:
> Das gab es schon beim Urahnen der CPUs, dem Z80. Im M1 Zyklus wurde der
> DMA Zugriff versteckt.

Eher der Refresh von DRAM.

von Thomas E. (thomase)


Lesenswert?

Reinhard Kern schrieb:
> Oder man ist Lehrer und braucht sich mit der blöden Realität nicht
> befassen, stattdessen hat man ja seine berufsbedingte Autorität.
>
Der Hugo ist doch kein Lehrer, sondern nur ein Möchtegern, der keine 
Ahnung hat. Leider schliesst sich das allerdings auch nicht aus.

Aber wer sowas schreibt:

>>Aber schreiben kann man auf den Programmspeicher nicht bei harvard?
>Der "reinen Lehre" folgend, nicht. Aber in der Praxis (siehe AVR) gibt
>es dennoch Möglichkeiten.

hat einfach keine Ahnung. Denn das hat mit Harvard oder von Neumann 
überhaupt nichts zu tun. Auch wenn es immer wieder kolportiert wird.

mfg.

von Alfred E. N. (Gast)


Lesenswert?

Deutschlehrer schrieb:
> Prozessor hat einen 16Bit Adressbus für den
> Programmspeicher und einen 20Bit Adressbus für den Datenspeicher
Ein v. Neumann hätte jetzt einen 36Bit Adressbus. ;-)

Als D-Lehrer solltes du der deutschen Sprache mächtig sein. Ich schrieb 
*"Vorteil"*, nicht muss!

Aber es geht hier um *Harvard vs Neumann 8051*. Da wird der Bus 
gemultiplext. Und es gilt ein 16Bit Adressbus (64k) kann 128k erreichen.

Deutschlehrer schrieb:
> Und bitte verkneife Dir solche Angriffe.

So ein Großk... wie du muss damit leben. Pappnase bleibt eben Pappnase, 
was soll ich da machen!? ;-P

von (prx) A. K. (prx)


Lesenswert?

Deutschlehrer schrieb:
>>Bei Harvard können die beiden Speicher an getrennten Bussen liegen. Dann
>>kann gleichzeitig zugegriffen werden. Ein DMA Transfer kann parallel zum
>>Codefetch erfolgen.
>
> Es ist richtig, das man bei Neumann nicht von verschiedenen Speichern
> sprechen kann, deswegen also auch keine getrennten Busse haben kann.
> Also kann man nur bei Harvard überhaupt erwägen getrennte Busse
> vorzusehen. Mein Fehler.

Busse kann man haben so viel man will. Egal ob H oder vN. Zumindest 
dann, wenn man etwas Realismus einkehren lässt und sich von den 
Rechnerstrukturen trennt, die zu der Zeit gängig waren, als diese 
Begriffe geprägt wurden.

Denn man kann natürlich Busse auch über Aufteilung der physikalischen 
Adressen eines Adressraums trennen, und natürlich geschieht das ziemlich 
oft. Je nach Bauart ist damit paralleler Zugriff in jedem dieser Busse 
möglich.

Caches verkomplizieren die Sache zusätzlich. Sind getrennte L1-Caches, 
also getrennte Zugriffspfade für Code- und Datenzugriff, ein Zeichen von 
H-Arch, auch wenn der Adressraum gemeinsam bleibt? Ist dann der 
getrennte L1-Cache H und der gemeinsame L2-Cache vN? Ist ein 486 eine 
vN-Arch, der Pentium aber H? Oder sind beide vN, weil nur ein externer 
Bus? Dann aber war der Motorola 88000 H, obwohl sich der in dieser Frage 
nur dadurch vom Pentium unterschied, dass die I- und D-Caches noch 
extern waren und somit getrennte Anschlüsse hatten.

Das Argument von parallelen Zugriffen, ob DMA oder anders, hat 
jedenfalls zu Adressräumen keinen Bezug mehr, sobald man die Antike 
verlässt.

Begrenzt man die Begriffe H/vN strikt auf die Adressräume aus Sicht des 
Programmierers, um diesen Rattenschwanz an Absurditäten zu rasieren, 
dann bleiben keine strukturellen Performanceunterschiede übrig. Weil man 
in den realen Implementierungen reichlich Freiheiten hat.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Reinhard Kern schrieb:
> Dazu braucht man einen Bootloader (wo steht der wohl) oder ein externes
> System, z.B. einen ICE - von sich aus kann das kein System, egal ob
> Havard oder v. Neumann. Auch Schalterregister wie bei der alten PDP8 zur
> manuellen Eingabe des Startcodes kam man wohl kaum als RAM bezeichnen
> (für eine Flugabwehrraktete auch eher unpraktisch).

Wenn ein Prozessor seine ersten Befehle aus einer solchen Klaviatur 
bezieht, dann ist das kein adressierter Speicher und die Begriffe RAM 
und ROM verlieren schwer an Sinn.

Wenn ein System (RCA 1802) von einem Zweitsystem (PC per UART) urgeladen 
wird, dann ist summarum zwar irgendwo tief im PC vergraben ein ROM zu 
finden, aber das ist völlig ausserhalb der Sichtbarkeit des Prozessors, 
um den es grad geht (der 1802).

von Alfred E. N. (Gast)


Lesenswert?

A. K. schrieb:
> Ist ein 486 eine
> vN-Arch, der Pentium aber H? Oder

x86 klar v. Neumann: Code und Daten teilen sich einen linearen 
Adressbereich. Es gibt nur ein Interface.

Wie das intern geregelt wird, weiss nur Intel. ;-)

(... und ein D-Lehrer!)

von (prx) A. K. (prx)


Lesenswert?

Alfred E. N. schrieb:
> x86 klar v. Neumann: Code und Daten teilen sich einen linearen
> Adressbereich.

Yep, meine Rede. Nur muss man sich dazu vom Begriff "Bus" lösen. Leider 
sind in der Literatur die Begriffe H/vN nahezu unlösbar mit dem Begriff 
"Busse" verklebt.

> Es gibt nur ein Interface.

Was verstehst du unter einem "Interface"?

von Alfred E. N. (Gast)


Lesenswert?

A. K. schrieb:
> Was verstehst du unter einem "Interface"?

Das ist eine Schnittstelle an der Systemgrenze.

von (prx) A. K. (prx)


Lesenswert?

Reinhard Kern schrieb:
> manuellen Eingabe des Startcodes kam man wohl kaum als RAM bezeichnen
> (für eine Flugabwehrraktete auch eher unpraktisch).

Ein Rechnersystem kann vollständig aus RAM bestehen. Deine Rakete ist 
ein schönes Beispiel. Denn wenn sie mal losgeflogen ist, und damit jeden 
Kontakt zum Urladesystem verloren hat, dann dürfte wenig Bedarf 
bestehen, sie aus- und wieder einzuschalten.

Beim altertümlichen Ringkernspeicher klappt das sogar mit 
Aus/Einschalten. Und wenn dir das exotisch erscheint: Wenn das RAM in 
Handys einmal nichtvolatil sein wird (z.B. MRAM), dann kommt bestimmt 
irgend eine Birne und "vergisst", ein ROM einzubauen. Urladen vom 
Hersteller reicht ja.

von (prx) A. K. (prx)


Lesenswert?

Alfred E. N. schrieb:
> Das ist eine Schnittstelle an der Systemgrenze.

Hmm. Wo ist die Systemgrenze bei besagtem 8051? Der hat ein seiner 
Reinform, also ROM und RAM intern, zwar ein paar I/O-Ports, aber 0 
Speicherschnittstellen. ;-)

Wenn du die Grenze irgendwo in den 8051 hinein verlegt: Wo genau liegt 
diese dann?

Der Core des STR9 µC, ein ARM9 ohne Caches, hat eine Schnittstelle für 
I-Zugriffe und zwei für D-Zugriffe. An der I-Schnittstelle hängt direkt 
das Flash, an einer der D-Schnittstellen direkt das RAM. Da sollte es 
dir schwer fallen, diesen vN Kerl auf eine Schnittstelle zu reduzieren, 
egal wo du die Säge ansetzt.

: Bearbeitet durch User
von Alfred E. N. (Gast)


Lesenswert?

A. K. schrieb:
> Hmm. Wo ist die Systemgrenze bei besagtem 8051?

Er zwei Speicherinterfaces, 8Bit gemultiplexter BUS. Mit PSEN wird von 
einem auf das andere Interface umgeschaltet.

Das der Hersteller ROM und RAM mit auf dei gleiche Chipfläche packt 
ändert nix an den Interfaces zum 8051 Kern.

von (prx) A. K. (prx)


Lesenswert?

Alfred E. N. schrieb:
> Er zwei Speicherinterfaces, 8Bit gemultiplexter BUS. Mit PSEN wird von
> einem auf das andere Interface umgeschaltet.

Ich wollte dich ja nicht mit noch einem weiteren µC plagen, aber glaubst 
du alles Ernstes, dass sämtliche µCs über externe Busse verfügen, bloss 
weil der 8051 das hat? Auch diverse Derivate vom 8051 haben keine 
externen Busse. Mit externen Bussen kommst du da nicht weiter.

> Das der Hersteller ROM und RAM mit auf dei gleiche Chipfläche packt
> ändert nix an den Interfaces zum 8051 Kern.

Jetzt also doch wieder der Kern. Dann ist der erwähnte STR9 mit seinen 
inhärent getrennten I- und D-Interfaces Harvard. Obwohl er, wie alle 
ARM, nur einen Adressraum hat und dieses Detail der Implementierung für 
den Programmierer auch auf Assembler-Ebene meist irrelevant ist.

Meine These: Sobald man das Kriterium "Bus" für die Unterscheidung 
zwischen vN und H verwendet, auch wenn ersatzweise als "Interface" 
bezeichnet, kommt man in Teufels Küche. Weil dann auch Architekturen mit 
einem einzigen übergreifenden Adressraum je nach exakter Implementierung 
mal das Eine und mal das Andere sind; es auch davon abhängt, wie nahe 
oder fern man die Lupe ansetzt.

: Bearbeitet durch User
von Reinhard Kern (Gast)


Lesenswert?

A. K. schrieb:
> Meine These: Sobald man das Kriterium "Bus" für die Unterscheidung
> zwischen vN und H verwendet, auch wenn ersatzweise als "Interface"
> bezeichnet, kommt man in Teufels Küche.

Es gibt heute jede Menge Controller, die internes Flash und internes RAM 
haben und dazu einen externen Bus, z.B. für noch mehr RAM (oder auch 
gern noch mehr ROM). Die Interfaces sind durchaus unterschiedlich, z.B. 
was Zugriffszeiten angeht, aber alles liegt in dem einen Adressraum, den 
ein v.Neumann-Rechner eben hat.

Eigentlich ist es ja ganz einfach: bei Harvard können an der Adresse X 
sowohl ein Programmbefehl liegen als auch Daten, bei von Neumann gibt es 
das nicht, an X liegen entweder Befehle oder Daten, beides geht nicht.

Gruss Reinhard

von Alfred E. N. (Gast)


Lesenswert?

Der 8051 Kern steht für die Familie. Und der hat getrennte Adressräume. 
Code und Daten haben gleiche Adressen. Was ist daran jetzt so schwer?

Beim ARM ist das nicht so offensichtlich. Jeder Halbleiterhersteller 
bastelt seine eigenen Sachen mit auf den Chip. Auch das Bus-System!
Auf dem Bild kannst du sehr schön rechts und links vom Core die 
Anbindung von Daten und Code sehen. Also ganz klar Harvard!
http://www.arm.com/images/proc-A968E-s.gif

von Alfred E. N. (Gast)


Lesenswert?

Ach ja, Interface ist nicht Bus. Es ist die Schnittstelle an der 
Systemgrenze!!!

von (prx) A. K. (prx)


Lesenswert?

Alfred E. N. schrieb:
> Beim ARM ist das nicht so offensichtlich. [...] Also ganz klar Harvard!

Also sind für dich ARMs bis ARM7 vN, weil der Core da nur einen Bus für 
I- und D-Pfade hat. Neuere wie ARM9 hingegen sind H, weil I- und D- 
getrennt, obwohl sich Code und Daten einen linearen Adressbereich 
teilen?

Alfred E. N. schrieb:
> x86 klar v. Neumann: Code und Daten teilen sich einen linearen
> Adressbereich.

Während x86 durchgängig vN sind, auch wenn I- und D-Pfade im Core 
getrennt sind? Sorry, aber da kommt ich nicht ganz mit.

Oder gibt es für x86 eine völlig andere Definition von vN/H als für ARM?

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Alfred E. N. schrieb:
> Ach ja, Interface ist nicht Bus. Es ist die Schnittstelle an der
> Systemgrenze!!!

Definiere bitte deinen Begriff "Systemgrenze".

von (prx) A. K. (prx)


Lesenswert?

Reinhard Kern schrieb:
> Eigentlich ist es ja ganz einfach: bei Harvard können an der Adresse X
> sowohl ein Programmbefehl liegen als auch Daten, bei von Neumann gibt es
> das nicht, an X liegen entweder Befehle oder Daten, beides geht nicht.

Einverstanden. Das ist analog zur Definition über getrennte oder 
gemeinsame Adressräume für Code und Daten in der ISA. Das ist die m.E. 
einzige Definition, die bei Betrachtung realer Prozessoren einigermassen 
schlüssige Ergebnisse liefert.

von Georg G. (df2au)


Lesenswert?

A. K. schrieb:
> Eher der Refresh von DRAM.

Der war da auch eingebaut. Ansonsten als Beispiel: Micropro Performer, 
80kByte RAM (obere 16k doppelt), HD/FD Controller als Bitslice. Einen 
schnelleren Z80 gab es nicht.

von Soul E. (Gast)


Lesenswert?

guest123 schrieb:

> Bei von Neumann sieht das anders aus, hier gibt es z.b. nur ein RAM, wo
> Programm und Datenspeicher drinnen sind.
(...)
> Aber aufjedenfall weiß man hier nicht ob man nun Programm liest oder
> Daten liest. Schreiben kann man doch beides oder?

Der große Vorteil einer von Neumann-Architektur ist, dass Programme auch 
Daten sind. Man kann Programme laden, kopieren, speichern und wieder 
löschen. Macht jeder PC so.

Bei Systemen mit Harvard-Architektur ist das Programm üblicherweise fest 
und wird zur Laufzeit niemals geändert. Der Vorteil ist, dass bei 
SW-Fehlern nicht aus Versehen das Programm überschrieben oder gelöscht 
werden kann.

von Peter D. (peda)


Lesenswert?

Die Unterscheidung Harvard vs Neumann gibt es heute nicht mehr.
Du könntest sogar dem Z80 getrennten Daten- und Programmspeicher 
verpassen und mit dem M1 Signal umschalten.
Umgekehrt haben die ARM intern mehrere Busse und können gleichzeitig 
Code und Daten zugreifen.

von (prx) A. K. (prx)


Lesenswert?

Peter Dannegger schrieb:
> Du könntest sogar dem Z80 getrennten Daten- und Programmspeicher
> verpassen und mit dem M1 Signal umschalten.

Nur das erste Opcode-Byte wird mit M1 gekennzeichnet, evtl. auch 
Präfixe. Die übrigen Bytes eines Befehls (Adresse/Konstante/...) nicht.

> Umgekehrt haben die ARM intern mehrere Busse und können gleichzeitig
> Code und Daten zugreifen.

Teils. Bis ARM7 wars noch recht klassisch.

> Die Unterscheidung Harvard vs Neumann gibt es heute nicht mehr.

MaxQ2000 ist ziemlich Harvard-mässig und noch recht frisch.

: Bearbeitet durch User
von Alfred E. N. (Gast)


Lesenswert?

A. K. schrieb:
> ARM9 hingegen sind H, weil I- und D-
> getrennt, obwohl sich Code und Daten einen linearen Adressbereich
> teilen?

Du musst dir nur das Bild ansehen!!! Es gibt eine Systemgrenze vom 
Instruction Interface und eine weitere vom Data Interface. Wenn da 
einer was dran bastelt und die Speicher mapped hat das nichts mit der 
ARM Architektur zu tun.

Und um den 8051 wieder ins Spiel zu bringen:
Du kannst ja einmal versuchen Code in den Datenbereich zu kopieren und 
dort auszuführen. Wenn das nicht geht, muss der 8051 wohl Harvard 
Architektur sein. ;-)
!!!Aber jetzt bitte nicht wieder verallgemeinern, wenn Code im RAM 
läuft ... !!!

von Alfred E. N. (Gast)


Lesenswert?

A. K. schrieb:
> MaxQ2000 ist ziemlich Harvard-mässig
Ich kenn den zwar nicht, aber auch hier reicht ein Blick auf das Schema: 
Family User Guide AN4811 S.8. Die MMU hat zwei Interfaces, eins für 
Code, eins für Data. Also Harvard!

Und im Text steht es genauso:
'... MAXQ is based on a Harvard architecture with separate address 
spaces for program and data memory. ...'

von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

Alfred E. N. schrieb:
> Du musst dir nur das Bild ansehen!!! Es gibt eine Systemgrenze vom
> Instruction Interface und eine weitere vom Data Interface.

Das (http://www.arm.com/images/proc-A968E-s.gif) ist ein Beispiel und 
keine Definition. Darf ich daraus schliessen, dass die Grenze zwischen 
Core und Rest für dich die "Systemgrenze" darstellt?

Demzufolge muss die CPU im Anhang auch Harvard sein, denn es sind 
eindeutig getrennte Interfaces für Code und für Daten erkennbar. 
Richtig?

: Bearbeitet durch User
von Alfred E. N. (Gast)


Lesenswert?

A. K. schrieb:
> Demzufolge muss die CPU im Anhang auch Harvard sein, denn es sind
> eindeutig getrennte Interfaces für Code und für Daten erkennbar.

Das Bild ist unvollständig. Es wird nicht gezeigt, wie die Cache 
angebunden sind.

A. K. schrieb:
> dass die Grenze zwischen
> Core und Rest für dich die "Systemgrenze" darstellt

Wenn es um ARM9 Architektur geht: Ja!

Mal nebenbei, was willst du hier beweisen?

von (prx) A. K. (prx)


Lesenswert?

Alfred E. N. schrieb:
> Das Bild ist unvollständig. Es wird nicht gezeigt, wie die Cache
> angebunden sind.

Mit Absicht. Hier ist auch nicht gezeigt, wie der Rest aussieht: 
http://www.arm.com/images/proc-A968E-s.gif. Verbinde diese diversen 
Interfaces mit einem Bus und es ist vN, verbinde sie irgendwie getrennt 
und es ist H?

> Wenn es um ARM9 Architektur geht: Ja!

Aber nicht bei x86 Cores? Die sind per Vorgabe vN?

> Mal nebenbei, was willst du hier beweisen?

Beitrag "Re: Harvard vs Neumann 8051"
Beitrag "Re: Harvard vs Neumann 8051"

: Bearbeitet durch User
von Mox (Gast)


Lesenswert?

Alfred E. N. schrieb:
> Und um den 8051 wieder ins Spiel zu bringen:
> Du kannst ja einmal versuchen Code in den Datenbereich zu kopieren und
> dort auszuführen. Wenn das nicht geht, muss der 8051 wohl Harvard
> Architektur sein. ;-)

Bei diesem Beispiel geht das prächtig, siehe 10.2.1:
http://www.ti.com/lit/ds/symlink/cc1111f32.pdf

Der 8051 muss dann wohl von Neumann sein.  :-)

von Alfred E. N. (Gast)


Lesenswert?

A. K. schrieb:
> Aber nicht bei x86 Cores?

x86 ist von Neumann, aber das hatten wir doch schon. Willst du jeden 
einzelnen Prozessor durchgehen?

Was ist eigentlich los mit dir? Fahr zum Drive In und gönn dir ne große 
Schokomilch. Dann hast du mehr Freude am Leben. >;->>>

Und dann fang hier wieder an:
http://www.mikrocontroller.net/articles/Prozessorarchitekturen
;-P

von Alfred E. N. (Gast)


Lesenswert?

Mox schrieb:
> Alfred E. N. schrieb:
>> Und um den 8051 wieder ins Spiel zu bringen:
>> Du kannst ja einmal versuchen Code in den Datenbereich zu kopieren und
>> dort auszuführen. Wenn das nicht geht, muss der 8051 wohl Harvard
>> Architektur sein. ;-)
>
> Bei diesem Beispiel geht das prächtig, siehe 10.2.1:
> http://www.ti.com/lit/ds/symlink/cc1111f32.pdf
>
> Der 8051 muss dann wohl von Neumann sein.  :-)

Da steht:
1
10.2
2
Memory
3
The 8051 CPU architecture has four different
4
memory spaces. The 8051 has separate
5
memory spaces for program memory and data
6
memory.
Also ist alles gut. :-)))

Und das hat nichts mehr mit 8051 zu tun:
1
Both the DATA and the SFR memory space is
2
mapped to the XDATA and CODE memory
3
space as shown in Figure 14, Figure 15
4
, and Figure 16 (the CODE and XDATA memory
5
spaces are mapped identically), and
6
CC1110 FX/ CC1111 FX has what can be called a
7
unified memory space.
Man kann auch externes RAM und ROM umschalten. Das hat aber nix mit der 
Architektur zu tun.

So, und jetzt spielt ohen mich weiter. ;-D

von (prx) A. K. (prx)


Lesenswert?

Alfred E. N. schrieb:
> x86 ist von Neumann, aber das hatten wir doch schon. Willst du jeden
> einzelnen Prozessor durchgehen?

Ich versuche rauszufinden, worin dein Kriterium für vN vs H besteht. 
Bisher vergeblich, denn ein x86 Core mit getrennten Interfaces ist bei 
dir vN, ein ARM Core mit getrennten Interfaces ist H.

Aber irgendwie passt das prima in den Thread, denn dieser auch von dir 
als H klassifizierte 8051 hatte zumindest in seiner ursprünglichlichen 
Implementierung tatsächlich ein gemeinsames Interface für Code und 
Daten: http://commons.wikimedia.org/wiki/File:Intel_8051_arch.svg 
(dieses Bild folgt Intels eigener Darstellung).

Also: Der P54 hat getrennte Interfaces und ist vN. Der Intel 8051 hat 
nur ein Interface für beides, ist aber H. Ich denke, bei dieser 
Klarstellung können wir es belassen. :-)

: Bearbeitet durch User
von Mox (Gast)


Lesenswert?

Alfred E. N. schrieb:
> Man kann auch externes RAM und ROM umschalten. Das hat aber nix mit der
> Architektur zu tun.

Ich lese mit z.B. movc Daten aus RAM (nicht XRAM, nicht CODE). Und ich 
muss gar nichts umschalten. Aber ich bin auch keine Experte.

von Reinhard Kern (Gast)


Lesenswert?

Mox schrieb:
> Ich lese mit z.B. movc Daten aus RAM (nicht XRAM, nicht CODE). Und ich
> muss gar nichts umschalten. Aber ich bin auch keine Experte.

Kann man so sagen. Was der Compiler übersetzt und linkt hat nämlich sehr 
wenig mit der tatsächlichen Architektur zu tun, jeder C-Compiler 
übersetzt Code in ein CODE-Segment und Daten in ein DATA-Segment, und 
dazu legt er ein Stack- und ein Heap-Segment an. Auch wenn die nachher 
wie beim PC alle im selben Adressraum im RAM liegen. Bei Harvard werden 
nur die Segmente anderswohin geladen (das Programm ins Program Memory, 
welche Überraschung). Man müsste deshalb nicht mal was am Sourcecode 
ändern.

Aber der Thread nervt allmählich, weil ohne jede Fachkenntnis immer neue 
Behauptungen aufgestellt werden, am Ende triumphieren unvermeidlich die 
Nichtwisser aus reiner zahlenmässiger Überlegenheit. Was H. und v.N. 
ist, ist eigentlich längst abschliessend geklärt.

Gruss Reinhard

Bitte 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
Noch kein Account? Hier anmelden.