Diskussion:Harvard-Architektur

message: === 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)
thread_title:  fachliche Ungenauigkeiten/Fehler 

message: 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)
thread_title:  punkt 1 

message: 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)
thread_title:  anmerkung zu obigen 3 punkten 

message: 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)
thread_title: Lemma mit Bindestrich

message: 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)
thread_title:  Werbung 

message: 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:

--Eorhim 15:28, 2. Mai 2010 (CEST)
thread_title:  Belege 

message: Man vergleiche mit  im Abschnit "1.4 Die Harvard Architektur". --Eorhim 18:55, 7. Mai 2010 (CEST)
replies: text: URV scheint mir geklärt: --Eorhim 10:20, 8. Mai 2010 (CEST)
thread_title:  Mögliche Urheberrechtsverletzung 

message: 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)
thread_title:  ARM CPU? 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Kernidee der Harvard-Architektur 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Bezug zu Mikrocontrollern (z.B. 8051)