{"id":575,"date":"2009-01-15T12:33:59","date_gmt":"2009-01-15T11:33:59","guid":{"rendered":"http:\/\/bernd-leitenberger.de\/blog\/?p=575"},"modified":"2009-01-15T12:33:59","modified_gmt":"2009-01-15T11:33:59","slug":"die-rueckkehr-der-harvard-architektur","status":"publish","type":"post","link":"https:\/\/www.bernd-leitenberger.de\/blog\/2009\/01\/15\/die-rueckkehr-der-harvard-architektur\/","title":{"rendered":"Die Rückkehr der Harvard Architektur"},"content":{"rendered":"\n

Nach längerer Pause mal wieder ein Computerthema, auf das ich ganz zufällig gestoßen bin. Wer einmal theoretische Informatik als Fach hatte, weiß, das es zwei grundlegende Architekturen für Computer gibt (wahrscheinlich noch mehr, aber zwei haben sich eben durchgesetzt). Das eine ist die "von Neumann" Architektur, die ihr PC hat. Es ist die am weitesten verbreitetste und bis vor kurzem dachte ich, dass sie eigentlich die einzige überlebende ist. Die Architektur ist ganz einfach: Es gibt einen Speicher, der Befehle und Daten aufnimmt und einen Adressbus und einen Datenbus der beides verbindet. Der Vorteil liegt auf der Hand: Man hat nur ein Bussystem und kann den Speicher frei aufteilen, wo Daten und wo Code gespeichert werden sollen. Es ändert auch nichts an der Von Neumann Architektur, wenn Speicher dafür fest reserviert werden, z.B. es Codesegmente und Datensegemente gibt oder es einen beschreibbaren und einen nicht beschreibbaren Speicher gibt. <\/p>\n

<\/p>\n

Die zweite Architektur ist dagegen auf den ersten Blick unterlegen: Die "Harvard Architektur" hat einen separaten Datenspeicher und einen Programmspeicher. Beide mit einem eigenen Datenbus und einem eigenen Adressbus. Auf den ersten Blick ist das deutlich umständlicher: Ich habe zwei Bussysteme, zwei Speichersysteme und kann nicht einmal unbelegten Datenspeicher für Programme nutzen. (Und umgekehrt)<\/p>\n

So sahen es auch die meisten Computerbauer und daher konnte sich die von Neumann Architektur durchsetzen. Mittlerweile muss man aber schon einige Tricks anwenden, um die CPU weiter zu beschleunigen. So werden heute Programminstruktionen in kleinere Einheiten übersetzt. Das wird um so problematischer, je variabler der Datenanteil ist (8,16,32,64 Bit lange Zahlen). Caches werden segmentiert in Daten und Code Teile, weil die Codeteile sich normalerweise nicht ändern. Streaming Instruktionen versuchen die Geschwindigkeit zu erhöhen, indem eine Instruktion mehrere Datenwörter parallel bearbeitet, indem mehrere Recheneinheiten gleichzeitig unterschiedliche Teile eines sehr großen (128-256 Bit langen) Datenworts bearbeiten. Damit dies geht, braucht man dann schon dicke Datenbusse.<\/p>\n

Eigentlich kommt diese Idee des SIMD (Single Instruction Multiple Data) von den Signalverarbeitungsprozessoren und bei diesen setzt sich nun langsam wieder die Harvard Architektur durch. Warum? Nun die modernen Signalverarbeitungsprozessoren, wie z.B. die C6Xx Serie von Texas Instruments, haben oft die Aufgabe sehr viele Daten nach immer der gleichen Weise zu verarbeiten. Denken sie an das Umwandeln von Blue Ray Daten in Fernsehsignale: Die nach dem H264 kodierten Signale müssen dekomprimiert werden, bei HD-TV Auflösung sind das 1920 x 1080 Punkte 25-60 mal pro Sekunde: Es gibt laufend neue Daten, während das Programm dafür recht kompakt und klein ist. Diese CPU’s verarbeiten mit einer Instruktion typischerweise mehrere Datenwörter parallel nach dem selben Algorithmus (ideal bei Videosignalen, die natürlich alle gleich kodiert sind) und erreichen so bei unter 1 GHz Takt enorme Geschwindigkeiten. Nur gibt es dann auch Probleme:<\/p>\n