hallo meine frage hier soll jetzt nicht sein, welche von den beiden architekturen besser/schlechter ist! ich möchte nur konktret wissen, was mit der von neumann architektur besser(oder überhaupt erst) zu realisieren ist als mit der harvard architektur bzw umghekehrt, und wo die vor und nachteile liegen(zb programmierung)! und das alles natürlich im bezug auf mikrocontroller =) hoffe ihr könnt mir helfen mfg Stefan
:
Gesperrt durch Moderator
Bei der Programmierung gibt es überhaupt keinen Unterschied. Die beiden Architekturen unterscheiden sich darin, daß bei der von Neumann Architektur Befehle und Operanden im gleichen Speicher stehen und zum Lesen dieser 2 Lese-Zyklen der CPU notwendig sind. Bei der harvard-Architektur hat die COU 2 getrennte Busse über die 2 getrennte Speicher gleichzeitig adressiert werden. Damit kann dann die CPU den Befehl und den dazugehörigen Operanden gleichzeitig lesen. Unser guter PC zuhause hat - wenn es zumindest ein Pentium-Prozessor ist beides vereint: Wenn die CPU auf den hauptspeicher zugreift, arbeitet die CPU mit der herkömmlichen von Neumann-Architektur, und wenn die CPU mit ihrem internen primären Cache arbeitet, arbeitet sie mit einer Harvard-Architekur. Der Vorteil der von Neumann Atrchitektur ist, daß man nur halb so viele Leitungen und CPU-Anschlüsse braucht wie bei der Harvard-Architektur, NAchteil die CPU muß zum Lesen eines Befehks, der einen Operanden hat, 2 Mal auf den Speicher zugreifen. Vorteil der Harvard-Architektur ist, daß der Befehl und der Operand geichzeitig gelesen werden kann. Gerhard
also erstmal danke für die schnelle antwort! vllt habe ich nicht klar ausgedrückt worauf ich hinaus will, entschuldigung dafür ^^ ich weis prinzipiell wo der unterschied zwischen von neumann und harvard leigt, nämlich in den punkten die du oben so ausführlich beschrieben hast =) aber diese punkte sind für mich als endanwender nicht relevant! mir geht es darum wo für mich die vor- und nachteile als benutzer liegen! wenn bei der programmierung kein unterschied ist, und mir die anzahl der leitungen etc. egal sein können, ist es dann für mich bei der wahl des uC überhaupt wichtig ob ich eine harvard oder von neumann architektur wähle bzw bemerke ich den unterschied überhaupt ?! soweit ich weis sind PICs immer Harvard architekturen und da ich diese schon benutzt habe kenn ich mich auch damit aus. aber wie funktioniert die aufteilung des speichers bei einem uC mit von neumann architektur? wenn daten und befehle im gleichen speicher stehen, ist dann der gesamte speicher ein Flash? wenn ja, würde das den uC doch erheblich verlangsamen?! oder ist dann der gesammt speicher ein RAM? wo wird dann das programm abgespeichert? in einem seperaten programmspeicher, aus dem dann das programm in den RAM geladen wird? oder wird das programm im seperaten speicher gelassen und direkt von dort aus benutzt? wobei dann wieder kein direkter unterschied zur harvard architektur vorhanden wäre? also mal sorry dass so viele fragen kommen =) was ich so weit mitbekommen habe würde sich die harvard architektur für systeme die mehrere programme ausführen sollen(zb. programmierbare taschenrechner) nicht eigenen, da nur befehle aus dem programmspeicher ausgelesen werden können, also keine externen programme geladen werden können.richtig ? =) dies wäre ein großer vorteil der von neumann architektur! aber worin liegt dann der vorteil von harvard, wenn nicht in der einfacheren programmierbarkeit? danke schon mal
Hallo, bei der von Neumann Architektur gibt es natürlich auuch RAM und ROM bereiche, in diesen Bereichen kann halt alles liegen was man braucht. Sowohl Programm als auch Daten. Befehle und Operanden werden dann Sequentiell aus dem Speicher gelesen. Das ist natürlich etwas langsamer, macht aber meistens nichts. Intern ist es dem anwender ja egal aber bei externem Speicher hat eigentlich keiner mehr lust auf Harvard Architektur. Die Busse müssen halt doppelt vorhanden sein und das kostet doppelt soviele Pins. Manche MC´s regeln den Zugriff auf Daten oder Programm dann über einen Separaten Pin aber dann ist es mit dem Parallelen Zugriff auch wieder vorbei. Der Vorteil bei von Neumann ist einfach das man den vorhandenen Speicher für alles nutzen kann. Es kann nicht passieren das noch jede Menge Datenspeicher vorhanden ist aber der Progarmmspeicher aus alle nähten platzt. Es kann auch sehr von Vorteil sein wenn es um das Thema Bootloader geht, hier sind die Daten ja wenig später auf einmal Programm. Sowas geht mit einer echten Harvard Architektur nicht. Eckhard
Hi Als Anwender merkst du wohl praktisch keinen Unterschied. Ich kann, wenn ich in einem Auto sitze, auch nicht sagen, ob es mit Benzin oder Diesel läuft. Mein kleiner Käfer, der MSP430F149 von Texas Instrumens, ist ein sehr moderner uC nach der von Neumann-Architektur. Vor allem der Umstand, dass er ortogonal aufgebaut ist, hat mir den Einstieg sehr erleichtert. Ortogonal heisst, dass alle Peripheriegeräte, das Ram, Boot-, Informations- und Hauptspeicher sowie die Interrupt-Vektortabelle in einen einzigen Speicherbereich abgebildet werden. Das macht die Programmierung genial einfach und ist einfach genial: Interrupt-Konfiguration (SFR): 0000h - 000Fh 8Bit-Peripherie: 0010h - 00FFh 16Bit-Peripherie: 0100h - 01FFh RAM: 0200h - 09FFh (2KB) Boot-Memory: 0C00h - 0FFFh (1KB) Info-Memory: 1000h - 10FFh (256B) Main-Memory: 1100h - FFFFh Der ganze Speicher ist ein Flash-Speicher. Programmiert wird dieser von unten nach oben, wenn ich mich nicht täusche. Bei meinem Datenlogger habe ich mit dem Debugger die End-Adresse des Programms ausfindig gemacht und diese als End-Adresse für den Datenspeicher genommen, der von oben nach unten beschrieben wird. Funktioniert prima, nur wenn man die Adressen nicht richtig wählt kann man auch das Programm selbst überschreiben. Dann geht natürlich gar nichts mehr. Den Vorteil der Von Neumann-Architektur hast du erfasst - zumindest für Mikrocontroller. Bei ausgewachsenen Rechnern wird dies aber des öffteren zu einem ernsthaften Sicherheitsrisiko - Stichwort Bufferoverflow. Der Vorteil der Harvard-Architektur liegt vor allem in der höheren Geschwindigkeit. Bei uCs ist diese wohl aber eher von kleinerer Bedeutung, bzw. man kriegt auch Von Neumann-uCs mit derselben Leistung (vermute ich jetzt mal). Tom
Das mit dem Buffer Overflow ist mir noch nicht so ganz klar, vielleicht kann da mal jemand näheres zu sagen warum das ein Nachteil der Neumann-Architektur ist? Wenn man vor dem Beschreiben der Buffer prüfen würde, ob das Datenpaket auch reinpasst, dann wäre das Problem ja gelöst. Damit könnte man theoretisch derartige Würmer stoppen. Ich verstehe einfach nicht warum dennoch soviele Würmer derartige Sicherheitslücken ausnutzen können; das müsste doch einfach zu stoppen sein! Im Prinzip liegt doch hier das Problem bei der schlechten/schlampigen Programmierung (die eben mögliche Fehler nicht abfängt), und nicht bei der Architektur!
Bei der Wahl des uC kann Dir die Architektur egal sein. Dich interssiert nur wieviele MIPS der uC macht. Wie der das hinkriegt ist sein Problem. Gerhard
Bufferoverflows an sich werden durch die Harvard-Architektur auch gar nicht vermieden, es ist nur nicht möglich, auf diesem Wege ausführbaren Code zu injizieren. Die vom Programm verwendeten Daten können auch auf einer Harvard-Maschine durch einen Bufferoverflow zerstört werden - was durchaus unappetitliche Folgen haben kann.
"Bei der Wahl des uC kann Dir die Architektur egal sein. Dich interssiert nur wieviele MIPS der uC macht. Wie der das hinkriegt ist sein Problem." Blödsinn. Ein Mips auf einem 8051 bedeutet wesentlich mehr Performance als ein Mips auf einem AVR. Die Mips-Betrachtung krankt an der fehlenden Betrachtung des Befehlssatzes. Insbesondere wenn man Risc und Cisc hat, ist Cisc natürlich bei gleichen Mips-Zahlen wesentlich überlegen, eben aufgrund des komplexen Befehlssatzes, wo einzelne Befehle in Risc durch viele nachgebildet werden muessen. Dazu kommt dann noch die bei Risc typische Load- and Store-Architektur, welche insbesondere im embedded-Bereich bei Mikrocontrollern nochmals Performance kostet.
"Blödsinn. Ein Mips auf einem 8051 bedeutet wesentlich mehr Performance als ein Mips auf einem AVR." So simpel ist das nicht. i51 ist akku-orientiert. In Assembler mag das so stimmen. Aber C arbeitet gezwungenermassen (ANSI Vorschrift) in vielen Fällen mit 16bit Operation, auch wenn im Quelltext nur Bytes vorkommen. Und da sieht's bei einem 8-Bit Akku recht mau aus. Ausserdem ist manches, was in C häufig ist, beim i51 auch etwas umständlich realisiert. Freilich: nicht jeder i51 Compiler hält sich an ANSI. CC5X beispielsweise nicht. So kann man es natürlich auch machen.
"So simpel ist das nicht. i51 ist akku-orientiert. In Assembler mag das so stimmen. Aber C arbeitet gezwungenermassen (ANSI Vorschrift) in vielen Fällen mit 16bit Operation, auch wenn im Quelltext nur Bytes vorkommen. Und da sieht's bei einem 8-Bit Akku recht mau aus." Doch, das ist so simpel. Zum einen haben gute C-Compiler Optimizer, die unnütze Null-Vergleiche von den oberen 16-Bit-Hälften wegoptimieren, zum anderen kann man bei schlechteren Compilern durch Typecasts so etwas von vorneherein verhindern. "Ausserdem ist manches, was in C häufig ist, beim i51 auch etwas umständlich realisiert." Ich wage mal zu behaupten, dass im Durchschnitt die Keil-C-8051-Compilate bei gleich-Mips-starken CPUs schneller mehr Performance haben als die AVR-Varianten.
Dann zeig mir mal, was bei
unsigned char a, b;
if (a > b+1)
...
in ANSI-C rauskommt. Bzw. wie der Code aussehen muss, damit das
rauskommt, was Du dir davon erhoffst.
Kannst auch das Beispiel vom Keil selbst nehmen.
http://www.keil.com/support/man/docs/c51/c51_intpromote.htm. Der Code
in Zeile 9 bringt's bei AVR/GCC auf 7 Befehle, bei Keil i51 auf 17.
Die "optimierte" Variante von Keil scheitert bei c2 >= 252.
"Zum einen haben gute C-Compiler Optimizer, die unnütze Null-Vergleiche von den oberen 16-Bit-Hälften wegoptimieren" Aber den komplett überflüssigen Code im o.A. Beispiel in Zeile 6, den lässt Keil drin. GCC nicht.
Hi "Blödsinn. Ein Mips auf einem 8051 bedeutet wesentlich mehr Performance als ein Mips auf einem AVR." Blödsinn. SCNR :-) Es kommt, wie immer, drauf an. Bei irgendwelchen Operationen auf Ports mag das stimmen da der AVR da z.T. den Port-Wert erst in ein Register Laden muß um darauf eine Operation auszuführen zu können. Der AVR hat dann aber bei Berechnungen einen Vorteil. Insbesondere wenn die Zahlen länger als 8 Bit werden oder sogar Fixpunktarithmetik verlangt ist. Es kommt auf die Anwendung an. Und oftmals wartet so ein µC eh auf Eingaben von außen und läuft ewig durch den Mainloop ohne das was passiert. Ich erschlage typische Regelanwendungen üblicherweise mit einem 4MHz AVR. Weniger ginge meistens auch aber die 4MHz haben sich halt so eingebürgert. BTW: Ich hatte schonmal geschrieben: MIPS == Meaningles Information about Processor Speed Matthias
also: WOW, danke für die vielen kompetenten antworten die schonmal viele meiner fragen beantwortet haben =)
@Matthias: War das nicht "Marketing Inspired Processor Speed" ? ;) Ähnlich wie bei diesem sinnlosen GHz zahlen die man so bei den PCs sieht. Wenn man CPUs vergleichen möchte muß man sich mit den interna beschäftigen und wenn ich mich an mein nebenfach richtig erinnere war das ein semester grundlagen... (Hennessey & Patternson) Und die antwort ist dann, niemals einen P4... Aber das ist (noch) und hoffentlich NIE ein µC. @Jim: Wenn ein 8051 und ein AVR jeweils 1 MIPS (gelesen als millionen instructionen pro secunde) machen, dann ist die performance des einen nich unbedingt 'besser' als vom anderen, port zugriffe oder nicht. (mal abgesehen von dem fakt daß die meisten 8051 12x höher getakted sind als der zum vergleich betrachte AVR). Ich bin kein experte für (und auch kein freund) des 8051, aber die meisten befehle benötigen auch noch mehrere maschinen zyklen. Kann man diese befehle nicht auch mit mehreren RISC befehlen mit gleicher laufzeitzeit nachbilden? Nicht immer seh ich ein (BCD-arithmetic) aber dies ist in anbetracht der zeitkritischen bereiche (i.a.) auch nicht notwendig. Die load/store architectur ist gerade bei von Neuman architecturen interessant, denn die verhindert gerade (in der theorie) übermäßiges laden und speichern von daten von/zum hauptspeicher. I.a. ist das gesamte hickhack um Havard/von Neumann bei µCs eh egal, da man sich mit "festen" programmen beschäftigt. Sollte man aber sowas wie laden von programmen benötigen (von CF/SD/ATA...) dann haben von Neumann µC gewonnen, da bei allen (?) Havard µC der programm-speicher flash ist... Dann nehm ich eher (da GCC verfügbar) ein ARM derivat, als mich mit 8051 (akku,ram-banking,... unbekannter C-compiler) rumzuschlagen. Olaf
Hallo Also noch mal zurück zum eigentlichen Thema: Dass bei der Programmierung kein Unterschied besteht stimmt ja wohl nicht wirklich. Wenn ich getrennte Adressbereiche für Code und Daten habe, dann muss ich verschiedene Befehle verwenden um ein Byte aus dem Speicher zu laden. So kann z.B. ein printf mit einem String aus dem RAM funktionieren, mit einem String aus dem Flash aber nicht (vorausgesetzt der Compiler berücksichtigt das nicht, aber effektiv braucht man dann 2 printf-Funktionen, eine fürs RAM und eine fürs Flash). Der grosse Unterschied für den Anwender (den ich hier mal mit Programmierer gleichsetze) besteht in der Zahl der verwendenten Adressräume. Hat man mehrere Busse, so sind das meistens auch mehrere Adressräume und Adressen können doppelt vergeben sein. Also z.B.: Harvard Code-Raum: 0x0-0x1fff Flash Daten-Raum: 0x0-0xff RAM Dagegen bei v. Neumann: 0x0- 0x1fff Flash 0x2000-0x20ff RAM Daher kommt dir oben angesprochene Notwendigkeit für verschiedene Befehle bei Harvard (je nachdem woher gelesen werden soll). Zur Performance: Bei denn schnellen, "grossen" uCs mit x-Stufigen Pipelines macht das wohl keinen grossen Unterschied wie die Architektur ist, bei 1MHz Controllern ist es sehr wohl ein Kriterium ob ein Befehl in einem oder zwei Zyklen ausgeführt werden kann. gruss Tom
Der zugriff auf unterschiedlichen addressräumen ist schon wichtig zu wissen, man muß sich halt nur darüber im klaren sein die entsprechenden funktionen zu benutzen. Und daher ist das insgesammt egal, nicht aber egal wie. Tschuldige fürs missverständnis. Gerade bei mehrstufigen pipeline µCs IST ein unabhängiger programm und daten speicher wichtig, da die unterschiedlichen pipeline stages ja gleichzeitig speicher bereiche lesen können. Daher auch die unabhängigen Instruktionen und Daten caches, um eine Havard architecture nahe zu kommen. Olaf
"Wenn ein 8051 und ein AVR jeweils 1 MIPS (gelesen als millionen instructionen pro secunde) machen, dann ist die performance des einen nich unbedingt 'besser' als vom anderen, port zugriffe oder nicht. (mal abgesehen von dem fakt daß die meisten 8051 12x höher getakted sind als der zum vergleich betrachte AVR)." Doch, das ist es schon. Alleine das Portbitmodifizieren braucht beim AVR drei Befehle gegenüber einem beim 8051. Im Übrigen sind eben nicht die meisten 8051er 12x höher getaktet. Schau Dir mal die Verkaufszahlen an. Ist aber auch egal, hier ging es um den Mipsvergleich. "Ich bin kein experte für (und auch kein freund) des 8051, aber die meisten befehle benötigen auch noch mehrere maschinen zyklen. Kann man diese befehle nicht auch mit mehreren RISC befehlen mit gleicher laufzeitzeit nachbilden?" Beim AVR brauchen die meisten Befehle auch mehrere Zyklen. Moderne 8051er haben auch eine Pipeline, die so etwas teilweise ausgleicht. "I.a. ist das gesamte hickhack um Havard/von Neumann bei µCs eh egal, da man sich mit "festen" programmen beschäftigt." Häh? "Sollte man aber sowas wie laden von programmen benötigen (von CF/SD/ATA...) dann haben von Neumann µC gewonnen, da bei allen (?) Havard µC der programm-speicher flash ist... Dann nehm ich eher (da GCC verfügbar) ein ARM derivat, als mich mit 8051 (akku,ram-banking,... unbekannter C-compiler) rumzuschlagen." Nochmals häh?
> Beim AVR brauchen die meisten Befehle auch mehrere Zyklen.
?
Dann habe ich da aber etwas komplett falsch verstanden...
Genaugenommen sind es zwischen 1 und 4 Zyklen, aber schau ins Datenblatt.
@Jürgen: 1. 1 maschienen zyklus sind 12 takt zyklen bei den meisten 8051. Es gibt auch 8051 die 1 maschienen zyklus mit einem takt zyklus gleich haben. Eingesehen. 2. die pipeline gleicht die execution zeit nicht aus, sie wird duch multi zyklen befehle angehalten (pipeline stall). Und die AVR-befehle die mehrere zyklen nutzen sind "selten" da man die speicher zugriffe ja minimiert durch die "große" anzahl register. Beim 8051 muß man sich vorwiegend mit dem Akku rumschlagen, wenn man die werte bewegen um den akku zu sicher... Und wo liegen die ports? werden die 'direct' mit ORL <addr>,#imm manipuliert. Gerade mal bei atmel nachgesehn und das benötigt 3 maschienen zyklen. Und einzelne bits in einem port zu änderen ist bei AVR AUCH ein takt. sbi/cbi Also ich sehe keinen vorteil der alten architektur. 3. Man programiert den µC und das program ändered sich während des laufes nicht. Also egal ob von Neumann oder Havard. 4. Nun wie arbeites du an deinem computer? Programme werden während des laufenden betriebes von externen medien in den RAM geladen und ausgeführt. Nicht sehr verbreitet bei µCs. Olaf
Hallo Jürgen, Deine Aussage bezgl. der benötigten Taktzyklen für Instzruktionen bei der AVR-Architektur ist haltlos : Ein einfacher Blick in das Instruction Set Summary zeigt, dass tatsächlich ide Mehrheit der Befehle single cycle instructions sind. Was natürlich nicht viel heißen muss, da die Auftretenshäufigkeit eines speziellen Befehls abhängig vom Porgramm (und auch vom verwendeten Compiler ist). Ein Bitschubbserles-Programm benötigt natürlich ganz andere Instruktionen, als eine Benutzer-Menü-Führung. Außerdem hat die Anzahl der benötigten Prozessor- oder auch Taktzyklen nicht viel zu tun mit dem topic, oder was meinst Du ? MfG, Daniel.
Beitrag #6031072 wurde von einem Moderator gelöscht.
Beitrag #6031076 wurde von einem Moderator gelöscht.
Beitrag #6031078 wurde von einem Moderator gelöscht.
Beitrag #6031082 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten