Diskussion:Harvard-Architektur

fachliche Ungenauigkeiten/Fehler

punkt 1

Der Befehls- und Datenspeicher sind in der Harvard-Architektur nicht nur physisch voneinander getrennt, das sind auch zwei RAM-Riegel in einem x86-Rechner. Vor allem werden sie ueber getrennte Busse angesprochen. So kann gleichzeitig auf den Befehls- und Datenspeicher zugegriffen werden. Das synchrone Einlesen eines Befehls mit seinen Daten ist dennoch nicht moeglich, man kann ja vorher nicht wissen, auf welchen Daten der Befehl arbeiten wird. Dass die meisten Befehle in einem Zyklus abgearbeitet werden koennen, liegt daran, dass alle Rechenoperationen in Registern stattfinden! --AndreasDittrich 20:26, 19. Jan. 2007 (CET)

punkt 2

Oft wird als Kriterium für die Einteilung in Harvard- und Von-Neumann-Architektur nicht nur die Anzahl der Busse verwendet, sondern auch die Anzahl der Adressräume. Siehe Hauptprozessor: "Dagegen sind bei der Harvard-Architektur Daten und Programm in strikt voneinander getrennten Speicher- und Adressräumen abgelegt."

punkt 3

Der Abschnitt "Ein weiterer Vorteil der Trennung ist, dass die Datenwortbreite (die kleinste adressierbare Einheit) und Befehlswortbreite unabhängig festgelegt werden kann. Damit kann auch, wenn erforderlich, die Effizienz des Programmspeicherbedarfs verbessert werden, da sie nicht direkt von den Datenbusbreiten abhängig ist, sondern ausschließlich vom Befehlssatz. Dies kann z.B. in eingebetteten Systemen oder kleinen Microcontroller-Systemen von Interesse sein." ist falsch. Die Datenwortbreite ist z.B. im schon sehr betagten Motorola MCORE prozessor 32 Bit, während die Instruktionsbreite 16 Bit ist. So wird eine hohe Codedichte erreicht. Trotzdem hat der MCORE eine von-Neumann-Architektur.

Re: Besser wäre "Die (Instruktions- und Daten-)Busbreite kann verschieden gewählt werden". Der MCore wird ja sicherlich nur eine Busbreite haben.

anmerkung zu obigen 3 punkten

ich hatte viel im internet nach harvard arch gesucht und war mir nie ganz sicher wie das mit den zwei speichern (instruction/data) gemeint war. die mischform von heutigen computern hat mich immer verwirrt und ich habe die mischform für die harvard arch gehalten.

mir gefallen gerade die 3 obigen punkte gut und sie sollten unbedingt in den artikel mit übernommen werden. da sollte ganz klar stehen:

• wir haben hier ein ram riegel mit "data"
• wir haben ein ram riegel mit "instructions"

d.h. wenn ich das richtig verstehe aber auch: - wir haben zwei festplatten für store/restore oder halt zwei flash speicher weil:

• die zwei speicher müssen ja getrennt liegen und wir müssen ja die befehle "code" von wo laden, also aus einem flash-speicher z.b. (oder auch ein ROM)
• aber schon berechnete daten müssen wir ja auch wo zwischenspeichern z.b. flash speicher (hier geht ROM gerade nicht)

falls aber garkein session save/restore nötig ist, so kann man den "data" flash speicher einfach weglassen und alles im RAM machen was nötig ist. so wird das wohl bei den embedded sachen laufen.

falls das was ich geschrieben habe richtig ist, dann kann derjenige der das hier versteht ev. gleich im artikel noch anpassungen vornehmen. es wäre auch eine andere grafik schön welche dann die ram/flash speicher mit einbezieht.

und hier fehlen noch quellenangaben. mein wissen hab ich fast nur aus der wikipedia und webseiten im netz. ev. finden wir dazu was im tanenbaum. (nicht signierter Beitrag von 134.2.186.2 (Diskussion | Beiträge) 20:37, 18. Okt. 2009 (CEST))

Lemma mit Bindestrich

Hallo, ich habe diesem Artikel wieder seinen Bindestrich zurückgegeben aus folgenden Gründen:#

• Grundsätzlich werden englisch-deutsche Mischworte nach neuer dt. Rechtschreibung mit Bindestrich geschrieben, außer in einigen Ausnahmefällen, die hier nicht zur Geltung kommen.
• Die Schreibweise mit Bindestrich ist in der Fachliteratur üblicher, darunter die einschlägigen Bücher von Tanenbaum und Schiffmann.
• Google liefert wesentlich mehr Treffer für die Bindestrich-Schreibweise.

Da dieses Lemma bereits einmal in umgekehrter Richtung angepasst wurde, bitte ich, die nun korrektere Schreibweise zu bewahren. Für eine Anpassung der Schreibweise in anderen Artikeln sorge ich. Grüße --Mkleine 01:43, 2. Apr 2005 (CEST)

Re: Die Trefferanzahl von Suchmaschinen ist bestenfalls ein Indiz, aber überhaupt nicht relevant für die Rechtschreibung, so wie auch nicht für die Richtigkeit von Aussagen.

Werbung

Hi.

Ist dieser Teil... "Als besonders bekannte Vertreter sollten hier auch die Produkte der Firma Microchip Technology Inc. zu erwähnt werden, die ebenso auf dieser Architektur aufbauen (PICmicro)." ...nicht eigentlich unterschwellige Werbung? Das hat doch nichts in einer Enzyklopädie zu suchen oder? Ich schlage vor, dass dieser Absatz gelöscht wird. --GambitNC 22:36, 4. Mai 2006 (CEST)

Nunja in einem Artikel über Betriebssysteme, kommst du auch nicht ohne eine Erwähnung von Microsoft aus. Das ist keine Werbung sondern einfach ein Beispiel für die Anwendung. Und sowas gehört sehrwohl in einen solchen Artikel.

Da die meisten One-chip Microcontroller diese Architektur verwenden - wegen der notwendigen Trennung zwischen (meist) fest programmiertem Programmspeicher (ROM, evtl. EPROM, Flash) und Datenspeicher (RAM) - habe ich diesen Abschnitt verallgemeinert und andere "besonders bekannte" Beispiele genannt. Damit dürfte der Werbungsverdacht abgemildert sein. -- Wosch21149 11:07, 3. Jan. 2011 (CET)

Belege

Der Artikel hat leider noch keine Belege. Bei der Suche für Informationen für SHARC bin ich auf folgendes gestoßen: Steven W. Smith, The Scientist and Engineer's Guide to Digital Signal Processing. Netterweise online lesbar.

Als Buch zitierbar: {{Literatur | Autor=Steven W. Smith | Titel=The Scientist and Engineer's Guide to Digital Signal Processing | Verlag= | Ort= | Datum= | ISBN=0-9660176-3-3 }} --Eorhim 15:28, 2. Mai 2010 (CEST)

Mögliche Urheberrechtsverletzung

Man vergleiche mit [1] im Abschnit "1.4 Die Harvard Architektur". --Eorhim 18:55, 7. Mai 2010 (CEST)

URV scheint mir geklärt: „Der Inhalt der Skripten darf für nichtkommerzielle Zwecke frei verwendet werden, sofern der Inhalt in unveränderter Form und vollständig verwendet wird.“[2]--Eorhim 10:20, 8. Mai 2010 (CEST)

Das Webarchiv findet von der Webseite nur eine Version aus 2001 [3]. Darin ist der Text nicht enthalten. In unseren Artikel wurde der Text am 2. April 2005 eingefügt. Daher vermute ich eine umgekehrte URV (vergleiche auch Ra'ikes Kommentar). --tsor 08:57, 12. Jun. 2011 (CEST)

ARM CPU?

Warum steht hier nichts von ARM drin? Man muss erst auf RISC klicken, um schließlich die wohl wichtigsten Prozessoren dieser Methode zu finden.. (nicht signierter Beitrag von 92.193.118.147 (Diskussion) 19:01, 22. Jun. 2010 (CEST))

Kernidee der Harvard-Architektur

Wenn ich es richtig verstanden habe, ist das primäre Ziel dieser Architektur also die Beschleunigung der CPU durch den parallelen Zugriff von Code und Daten, und die Trennung der Ikonizität von Code/Daten nur ein erwünschter Nebeneffekt? Ich frage mich gerade, weil diese Trennung, wenn auch nur virtuell, auch in der Segmentierung der x86-Architektur im 32-bit-Protected-Mode umgesetzt wurde... --Carminox 03:11, 25. Aug. 2010 (CEST)

In den Artikel wurde jetzt unter "Motivation" aufgenommen: "Um z.B. zu verhindern das bei Softwarefehlern Programmcode überschrieben werden kann, wurde für den Programmcode ein im Betrieb nur lesbarer Speicher (z.B. ROM, Lochkarten) verwendet, für die Daten schreib- und lesbarer Speicher (z.B. RAM, Ringkernspeicher)." Diese Behauptung halte ich für sehr mutig. Bei der Implementierung der ersten Mikroprozessoren und besonders Mikrocontroller war ausschlaggebend, zumindest einen erheblichen Teil des Programms in einem Festspeicher unterzubringen, da bot sich das "billige" ROM an. Die Trennung war also wohl tatsächlich eher ein Nebeneffekt. Ich denke, die "Zugriffsrechtetrennung" sollte eher unter "Geschichte" - wie einige andere Vorteile - erwähnt werden. --Wosch21149 17:19, 3. Aug. 2011 (CEST)

Hallo Wosch21149, nun mutig eigentlich nicht den die nicht-modifizerbarkeit des Codes ist eine der am häufigst gehörtesten Gründe für Harvard (aus meienr Sicht aber ebenfalls weder der wichtigste noch ein zwnagsläufiger). Ich gebe dir recht das dies nur ein Nebeneffekt der historischen Wahl von ROM-artigen Codespeichern und RAM-artigen Datenspeichern dich sich ergab. den eine Harvard-artiges system mit 2 getrennten RAM-artigen Speichern ist ebenfalls an Harvard-System. Nichtdestotrotz ist die möglichkeit damit auf eine einfache art speicherschutz erzielen zu können ein konzeptioneller Vorteil. Könntest du dir eine Darstellung vorstellen in der dies zwar genannt wird aber als Nebenprodukt? erste Idee: Die Trennung in Code und Datenspeicher erlaubt die differenzierte Verwendung unterschiedlciher Speichertypen, preiswerteren nur lesbaren Speicher für den Code (Beispiele...), und teuereren RAM für den lese- und schreibfähigen Datenspeicher. Als Nebenenffekt ist damit auch eine einfacher Speicherschutz realisierbar... (Teile des vorherigen Textes) gruesse Shaddim 17:48, 3. Aug. 2011 (CEST)

wenn ich's mir recht überlege sollten wir diesen artikel vielleicht anders strukturierne: Konzptionelle vorteile (geschichtsunabhängige vorteile: unabhängige busbreite, parallele zugriffe, einfach realisierbarer speicherschutz) und historie (in die die herkunft und motivation kommt: zugriff auf verschiedene speichertypen, kostendruck) Shaddim 17:57, 3. Aug. 2011 (CEST)

Harvard und Zeiger

Einen grundsätzlichen Nachteil der Harvard-Architektur sollte man auch erwähnen. Nämlich dass man bei Zeigern immer dessen Typ kennen muss (Code oder Daten). Kaum ein realistisches Programm kommt ohne Konstantenlese-Operationen aus, etwa Tabellen, Zwischen-Code oder feste Zeichenketten. Im Fall von gewünschter Code-Veränderung (bspw. Flash schreiben) hat man es mit erwünschten Schreiboperationen zum Konstanten-Speicher zu tun.

Zumindest C / C++ kennt primär nur einen Zeiger-Typ. Je nach "Target" muss man die richtige Funktion auswählen. Oder der Zeigertyp ist um mindestens ein Unterscheidungs-Bit aufgebläht, und alle Funktionen müss(t)en mit entspechenden Fallunterscheidungen gespickt werden. Ersteres macht Programme schwer pflegbar (bspw. avr-gcc), letzteres macht das Programm langsam und groß; der Vorteil von Harvard schwindet. Oder eine spezielle Initialisierung kopiert alle Konstanten in den Daten-Speicher. Der ist meistens knapp.

Die heutige Entwicklung scheint eindeutig in Richtung von-Neumann zu gehen, man hat ja genügend Adressbits. Flaschenhälse werden im Mikrocontrollerbereich durch Bus-Matrixschalter aufgelöst, im Desktop-Bereich durch entsprechende Caches. Nur bei kleinen Controllern mit 8 oder 16 bit bleibt Harvard übrig; hier sind ja die Adressbits eher knapp. Code vom RAM ausführen geht bei solchen Mikrocontrollern nicht; On-The-Fly-Compiler lassen sich eben nicht realisieren. Man denke dabei an die verschiedenen Rasteroperationskodes für Bitmap-Transfers, die sehr gern mit Code-auf-dem-Stack realisiert werden.

Während 8051-Systeme gerne "von-Neumannisiert" betrieben werden (Code == XRAM), war die Entwicklung des 8086 und insbesondere des 80286 Protected Mode eine "Harvardisierung" des von-Neumann-Prozessors, um letztlich mit einem Mangel an Adressbits (nur 16 "echte" Bits) auszukommen. (Dort war ja sogar der Stack getrennt adressier- und schützbar.) Nachträglich gesehen ein Irrweg, dem man nun durch die (für den Desktop-Bereich vielleicht etwas verfrühte) Einführung von 64 Adressbits nicht wiederholen will.

Bezug zu Mikrocontrollern (z.B. 8051)

Man sollte sich grundsätzlich festlegen, was die Harvard-Architektur ausmacht. Das ist im Prinzip hier geschehen. Aber dann nicht irgendwelche Beispiele heranziehen, die dem Prinzip der Architektur widersprechen. Der 8051 verwendet lediglich ein Bit (Anschluss PSEN), um eine (physikalische) Unterscheidung zwischen zwei Speicherbereichen vorzunehmen. Ansonsten werden dieselben Adress- und Datenleitungen für den Programm- und den Datenspeicher verwendet. Was hat das mit Harvard und dem gleichzeitigen Zugriff auf Daten und Befehle zu tun? Aus diesem Blickwinkel sollte man auch die anderen als Beispiel aufgeführten Mikrocontroller und Mikroprozessoren betrachten. Was nicht Harvard ist, sollte auch nicht in diese Schublade gepresst werden. --DrRobertPatzke (Diskussion) 08:47, 1. Jul. 2014 (CEST)

Ich stimme dir insofern zu, dass der Artikel schlecht aufgebaut ist. Er stellt als erste Eigenschaft eine besondere Schnelligkeit heraus, bevor das eigentliche Merkmal, nämlich der getrennte Adressraum für Befehle und Daten erwähnt wird. Ob dann die getrennten Adressräume dieselben Leitungen/Signale (Adressbus/Datenbuss) verwenden, ist unerheblich, das wäre wiederum nur interessant, wenn es auf Geschwindigkeit ankommt. Und die ganannten Mikrocontroller wie 8051 haben getrennte Adressbereiche für Daten und Programm, sind also in Havard-Architektur implementiert. Bei Von-Neumann hätten wir keine Unterscheidung, Daten und Befehle können im selben Adressbereich liegen (obwohl es natürlich auch ROMs und RAMs geben kann, d.h., der "Programmspeicher" im ROM kann nicht per Programm geändert werden). Nachtrag: Dass Daten- und Adressbereiche bei Havard getrennt sind, heißt nicht automatisch, dass gleichzeitig auf beide zugegriffen werden muss. Die Unterscheidung durch PSEN reicht aus, um eine Trennung von beiden Speicherbereichen zu bewirken. PSEN kannst du hier also als zusätzliche Adressleitung ansehen. --Wosch21149 (Diskussion) 12:21, 1. Jul. 2014 (CEST)

AVR hat laut data sheet definitiv eine Harvard-Architektur. (Attiny25/45/85 und Atmega16/L habe ich nachgesehen) [HL] (nicht signierter Beitrag von 93.132.116.48 (Diskussion) 20:21, 10. Jan. 2016 (CET))

Ich habe das auch nochmal recherchiert. Tatsächlich steht es in den Datenblättern vom AVR so drin: Zitat: In order to maximize performance and parallelism, the AVR uses a Harvard architecture – with separate memories and buses for program and data. Aber das war es dann auch. Details dazu findet man nicht. Ähnlich bei den modernen SAM-Prozessoren (ARM). Zitat: Harvard processor architecture enabling simultaneous instruction fetch with data load/store. Da es hierbei um innere Abläufe des Mikrocontrollers geht, würde ich das jetzt auch nicht anzweifeln. Auch, wenn das Datenblatt "lügt", wäre es nicht nachweisbar.

Aber wenn man einen Mikrocontroller mit externem Speicher erweitern will, dann würde ich bei einem Harvard-Prozessor zusammenzucken, weil ich mir vorstelle, wie zwei getrennte Adress- und Datenbusse zu bedienen wären. Wären die z.B. gemultiplext oder müsste ich tatsächlich doppelt so viele Pins bedienen? Aus diesem Blickwinkel bitte ich darum, wenigstens den 8051 und ähnliche Mikrocontroller nicht mehr als Beleg für eine Harvard-Architektur aufzuführen und die anderen Beispiele auch noch einmal zu prüfen. Insbesondere vor dem Hintergrund einer möglichen (externen) Speichererweiterung. --DrRobertPatzke (16:32, 19. Feb. 2016 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)