Die Rückkehr der Harvard Architektur

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.

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)

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.

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:

• Der Datenbus muss recht groß sein um die Daten zu transferieren
• Ein Datencache macht keinen Sinn, weil die Daten sich dauernd ändern
• Ein Codecache macht auch keinen Sinn, weil die der limitierende Faktor eigentlich der Speicherzugriff für die Daten ist. Stattdessen würde sehr schnelles RAM ausreichen.

Fasst man diese Überlegungen zusammen, so drängt sich fast automatisch die Harvard Architektur auf: Der Code sitzt in einem sehr kleinen RAM, aber dieses ist schnell: Dual Port RAM oder gar SRAM, anstatt langsamen statischen RAM. Viel mehr Speicher braucht man für die Daten. Diese erhalten ein einen eigenen Datenspeicher mit einem sehr dicken Datenbus. so können die Daten in mehrere Rechenwerke gleichzeitig transferiert werden und der langsame Zugriff auf DRAM wirkt sich nicht so sehr aus. Heutige DSP von Ti, die auch ihren Einzug in der Raumfahrt haben, setzen daher oft schnelles SRAM für den Code ein und einen viel größeren Speicher mit DARM für die Daten. Das Programm selbst kommt oft aus einem EEPROM und wird vor dem Start ins RAM kopiert. Auch die GPU’s von Grafikkarten haben ein getrenntes RAM für Code und Befehle (oft unterschiedlich schnell getakt), wobei hier die Datenmenge noch größer ist, so dass auch 256-512 Bit breite Datenbusse nötig sind um die vielen Recheneinheiten zu versorgen.

Es ist unwahrscheinlich, dass die PC’s von der von Neumamn Architektur abkommen werden (obwohl getrennte Caches für Daten und Code ja schon eine gewisse Abkehr sind9, doch für Signalverarbeitungsaufgaben scheint die Harvard Architektur echte Vorteile zu haben.