Insbesondere Marketing-Leute haben in der letzten Zeit stark den Begriff "RISC" in den Vordergrund geschoben, wenn es um neue Prozessor-Architekturen ging. Der Eindruck drängte sich auf, daß nur noch RISC-Systeme das einzig Wahre seien - und man alles andere getrost vergessen könne.

Berkeley-Professor David A. Patterson, mitunter auch als "Vater der RISCs" bezeichnet, stellte Architekturüberlegungen an, die weit über das engere Mode-Thema hinausreichen. Eine oft zu hörende Behauptung im Zusammenhang mit dem Thema RISC besagt, es seien vor allem die heutigen, schnellen Halbleiter-Hauptspeicher, die diesen neuen Typus Maschine ermöglichten.

Denn, so die Argumentation, sie erlauben Befehle in rascher Folge vom Speicher in die Zentraleinheit zu bringen und deshalb jetzt auch "einfache" Befehle zu benutzen, die pro Instruktion sozusagen nicht mehr so sehr viel "leisten" müssen, wie früher jene weit komplexeren Instruktionen typischer "CISC"-Rechner mit ihrem "Complex Instruction Set". Jene CISC-Befehle nämlich arbeiteten relativ zeitaufwendig.

Diese Argumente weist Patterson zwar nicht zurück, doch das sei längst nicht die gesamte Story. Für Patterson tritt unter dem Stichwort Speicher primär ein ganz anderer Aspekt nach vorn. Im Zeichen des rasanten Hardware-Preisverfalls kann man heute weitaus größere Speicher vorsehen, wenn man einen neuen Rechner konzipiert, als noch vor 20 oder 30 Jahren. Diese großen Speicher bieten nun eine ganze Reihe - auf den ersten Blick keineswegs ins Auge springender - Möglichkeiten.

Mit ihrer Hilfe nämlich könne man jetzt "endlich Compiler bauen", die die typischen, wenigen und Stück für Stück nicht sonderlich '"mächtigen" Befehle eines RISC weitaus effizienter nutzen, als frühere Compiler dies je vermocht hätten. Diese Compiler selbst können viel umfangreicher sein als frühere, weil für sie genug Speicherplatz zur Verfügung stehe. Dies habe zur Folge, daß sie beispielsweise sehr komplizierte, aufwendige Fallunterscheidungen treffen können und daß heutige, "wirklich moderne Compiler mit den einfachen, kurzen Befehlen und Befehlsformaten eines typischen RISC optimal zurechtkommen".

Heute ist es daher so, spinnt Patterson den Faden weiter, daß vieles, was früher erst während des Laufs eines Programms gemacht werden konnte, jetzt schon beim Compilieren erledigt werden kann: Allein schon dadurch aber "werden die Programme beziehungsweise die Maschinen natürlich schneller". Patterson wußte ein Beispiel anzuführen, an dem der Unterschied zwischen der heutigen Compilerbauer-Denkweise und jener von vor rund zehn Jahren schlagend sichtbar wird: "Wer heute einen neuen Compiler entwickelt, der erwartet, "daß der Rechner mindestens 32 Register hat - oder mehr." Doch selbst 1977 noch "wollten die Entwickler damaliger Compiler gar nicht so viele Register einplanen müssen"; sie "wußten sie gar nicht recht zu nutzen....."

Heute also, so Patterson, können wir Compiler sehen, die die - allerhöchstens - 32 Register eines modernen RISC-Prozessors wirklich voll und effizient nützen, eher aber nur 16; und erst spätere Compiler dürften eines Tages sogar 64 oder mehr Register "sinnvoll" - und auf dieses "sinnvoll" legt Patterson großen Wert - nutzen können. Für die Gegenwart ist er der Meinung, daß Prozessoren mit mehr als 16 oder gar 32 Registern noch gar nicht effizient genutzt würden. Auch wenn manche Hersteller sogar Maschinen anpriesen, die weit über tausend Register aufweisen sollen.

Folgt man Patterson, so geht die Leistung eines Prozessors beim heutigen Stand der Compiler-Technik "eher wieder nach unten", wenn wesentlich mehr als 16 Register bereitstehen. Erst spätere Compilerausführungen dürften jenen kritischen Punkt, ab dem die Leistungskurve bei steigender Register-Zahl wieder nach unten geht, eines Tages "in Richtung zu mehr Registern verschieben."

Man müsse aber sehen, daß "die heutigen Compiler grob geschätzt rund fünfmal soviel leisten, wie jene des Jahres 1977". Die besseren, in größeren Speichern residierenden Compiler von heute haben nun, ganz im Gegensatz zur Rechner-Steinzeit mit ihren teuren Winz-Speichern, bei der Nutzung eben dieser Speicher außerdem noch viel mehr Möglichkeiten; sie können beispielsweise im Zusammenwirken mit besseren, effizienteren und sich auf größere Speicher abstützenden Algorithmen erreichen, daß mit Speicherraum weitaus großzügiger umgegangen wird als früher, und daß das Arbeitstempo einer Maschine dadurch deutlich steigt.

Zeigen diese Ausführungen Pattersons schon mehr als deutlich, daß im Bereich der Prozessor-Entwicklung heute ein ganz neues Denk-Spiel begonnen hat, so wird dies noch durch die Frage unterstrichen, was gedanklich zu tun sei, wenn man heute einen neuen Prozessor möglichst hoher Leistung zu möglichst geringen Fertigungskosten von Null an entwickeln will? Eine Maschine also, wie sie effizienter kaum denkbar ist?

Bei dieser Frage, meint Patterson gehe man sinnvollerweise von dem Grundgedanken aus, daß es letztlich doch die "Systemkosten pro Leistungseinheit" sind, die das entscheidende Bewertungskriterium darstellen. Wenn man hier ein Minimum erzielen wolle, so müsse man sich in jeder Phase fragen, ob dieses oder jenes zusätzliche Rechner-Element wirklich ein Plus (oder ein Minus) an Leistung bringe. Oder sei es, kostenseitig gesehen, für das erzielbare Leistungs-Plus nicht einfach "zu teuer"?

Hier findet sich laut Patterson ein wichtiger, bisher kaum in der Öffentlichkeit diskutierter Punkt: "Früher", so die Erinnerung des RISC-Gurus, "konnten die Entwickler von Rechnern in dieser Sache vielfach bloß raten". Denn es gab bei den damaligen Techniken und Hilfsmitteln zur Entwicklung neuer Logik-Schaltungen "ganz einfach nie genügend Zeit, dieser Frage in exakten Berechnungen nachzugehen" beziehungsweise "in schrittweiser und langwieriger Verfeinerung konkreter elektronischer Versuchs-Aufbauten" das "Verhalten unterschiedlicher Prozessor-Versionen in aller Ruhe zu erproben".

Heute indes, und dies ist nach den Punkten Speicher und Compiler vielleicht die dritte große und wichtige Neuerung gegenüber der schlechten alten Zeit, existieren die entsprechenden Test- und Simulationswerkzeuge zum genauen Durchkalkulieren neu zu entwickelnder Prozessoren, Jetzt "sprechen wir von der experimentellen Schule der Computerentwicklung", die der überkommenen und sehr oft "völlig in die Irre führenden" Raterei ein Ende setzte.

Analyse der Befehle führt zu Überraschungen

Die Tatsache, daß vor rund zehn Jahren, also bei der Entwicklung der VAX und anderer Rechner sozusagen ein bißchen "auf Verdacht" konstruiert werden mußte, erklärt Patterson damit, daß jenes DEC-Entwicklungsteam seinerzeit unter schwerem, konkurrenzbedingten Zeitdruck gestanden habe. Und außerdem gibt es in der Computerei nicht weniger als in anderen Branchen ausgesprochene Moden: "Damals", so Patterson, "war das Thema Mikroprogrammierung eben sehr populär." So dürfe es heute niemanden verwundern, daß die DEC-Entwickler seinerzeit der Versuchung erlagen, einen sehr aufwendigen und komplizierten - und, wie sie wohl vermutet haben dürften, entsprechend leistungsfähigen Befehlssatz - zu erfinden.

Man fängt heute also bei der Weiterentwicklung eines Prozessors beziehungsweise eines Computers zunächst einmal damit an, daß man die vorhandenen Systeme prüft und genau analysiert: "Welche von ihren Eigenschaften ist wirklich wichtig? Was kann oder sogar sollte man besser weglassen?" - Schon dabei kann es dann, wie ein Beispiel Pattersons zeigt, Überraschungen geben. Denn als man auf diese Weise den Befehlssatz der bekannten VAX-Maschinen durchleuchtete und im nächsten Schritt einige der mehr als 300 Instruktionen durch entsprechende Software-Routinen ersetzte, wurden die Rechner schneller.

Im Zuge der Entwicklung von Rechnern wie der VAX oder auch wie Intels einst vielbewunderte, kommerziell jedoch wegen Lahmheit als Flop endende Einheit "432" wucherte damals der Microcode. Vor nicht mal einem Jahrzehnt also sprach noch kein Mensch von RISC, und alle Welt folgte der herrschenden Philosophie: Bring möglichst viel Software-Funktionen direkt in die Hardware - und hoff dann auf stattliche Geschwindigkeitsgewinne.

Heute hat man gelernt, betont Patterson, mit alternativen Rechner-Entwürfen konkret zu experimentieren - und "auf dem Weg in dieses Heute haben wir Verblüffendes festgestellt". Denn "wir mußten sehen" daß von diesen (Mikroprogramm-) Hardware verlegten Software-Funktionen viele "weitaus zu selten genutzt" wurden, als daß "man sie überhaupt hätte rechtfertigen können". Und "als wir weiter experimentierten, verdichtete sich dieser Eindruck" sogar noch.

Er verdichtete sich so lange, bis schließlich für Leute wie Patterson ein Fundamentalsatz zur absoluten Gewißheit wurde: "Hardware ist der wirklich schlechteste Ort, irgendwelche Funktionen zu implementieren." Denn fortan ist es ja "extrem schwer und teuer, die Maschine wieder zu ändern". Ganz zu schweigen von den Kosten, die beim Beheben von (Entwurfs-)Fehlern entstehen, da man stets die ganze Hardware umkrempeln muß. Software ist hier, was Flexibilität und Fehlerkorrekturen angeht, "natürlich einfach perfekt".

Lösungen innerhalb der Hardware sind hingegen da am Platz, wo Funktionen mit dem höchst möglichen Tempo ausgeführt werden müssen. Doch dieser Einsatz von Hardware "lohnt sich eben, so wissen wir aus unseren Analysen, nur dort, wo eine Funktion sehr, sehr oft aufgerufen wird". Man denke heute also in diesen Dingen "genau entgegengesetzt zu dem, was noch vor zehn Jahren als allgemeine Weisheit galt".

Dieses Umdenken, so RISC-Vorreiter Patterson, erfolgte "natürlich nicht von heute auf morgen", aber doch "erstaunlich rasch". Denn heute, so seine Worte, "gibt es einen allgemeinen Konsens, daß RISC die richtige Denkweise ist". Doch "noch vor fünf Jahren" war RISC, ehe dann das allgemeine Umdenken einsetzte, "sehr umstritten. Es gab damals "über RISC und dessen Für und Wider noch eine ganze Reihe lebhafter Konferenzen".

Wenn in der Entwicklung neuer Prozessoren heute weitgehend Pattersons Rat befolgt wird ("Keep it simple"), so steckt dahinter übrigens noch eine andere, mit teurem Lehrgeld erkaufte Erkenntnis der Fachwelt. Es gibt, so weiß Patterson auszumalen, "eine richtige Architektur-Falle". In die tappe man unweigerlich, wenn man bei der Konzeption eines Rechners in der konventionellen Art vorgeht.

Rasche Lösungen führen in die Falle

Diese Falle, so erläutert Patterson, besteht darin, daß man im Zuge der Entwicklung des neuen Systems "immer wieder auf ein ganz neues Problem" stößt - und dafür dann "meist auch sehr rasch eine Lösung findet". Weil diese Lösung nun leicht zu finden war und oft auch recht elegant erscheint, ist man "stark in Versuchung, sie flugs in Microcode zu implementieren". Dabei übersieht man aber leider, daß das Problem, für das man diesen Zusatz-Aufwand treibt, später doch "nur bei jedem hundertsten oder gar tausendsten Programmbefehl vorkommt".

Genau dies "ist nun der Punkt, an dem die Falle zuschnappt". Denn man implementiert in "bewährter" CISC-Manier Befehl um Befehl und Trick um Trick und übersieht dabei dann völlig, daß man, weil die Befehle und Tricks ja fast nie genutzt werden, "per Saldo an Leistung fast gar nichts gewinnt". Während man umgekehrt aber einen oft sehr, sehr hohen Preis zahlen muß: denn die vielen Zusätze machen "den Bau der Hardware schwierig und teuer"; und "letztlich wird das komplexe" so entstehende Gebilde sogar eher wieder langsamer". - Also hätte man die vielen Zusätze lieber gleich weggelassen . . .

Und damals waren die üblichen Ferritkernspeicher übrigens auch ein derart unerhörter Luxus, daß es in jenen Jahren einfach auf der Hand lag, leistungsfähigen Microcode zu entwickeln und jenen dann in großen Mengen in billigen, schnellen Nur-Lese-Speichern (ROMs) abzulegen.

Dieser Microcode wurde maschinenintern dann eben flott abgearbeitet und so die relativ lange Zeitspanne gut genutzt, die damals bei den Ferritkernspeichern verstrich, bis der jeweils nächste Befehl endlich in der Zentraleinheit eintraf.