Vieles, was heute als modernes Rechnersystem angepriesen werden kann, wurzelt seiner Konzeption nach im Denken der 50er und 60er Jahre. Doch was damals für die Probleme jener Zeit die optimale Lösung gewesen sein mag, hat heute vielfach keinen Bestand mehr.
In den frühen 60ern, erinnert sich Professor David A. Patterson von der University of California in Berkley, stand die weltweite Computer-Industrie vor dem Problem, daß jeder einzelne Typ Rechner eines Herstellers mit jeweils anderer Software betrieben werden mußte, daß für jeden Typ eine völlig neue Dokumentation zu schreiben war, daß für jeden Typ ganz eigene Schulungskurse zusammengestellt werden mußten und daß auch die Verkäufer-Truppen, denen man ja fachlich nie allzuviel zumuten durfte, jeweils nur einen Typ verstehen und anpreisen konnten. Das alles war ein ziemlich teueres Vergnügen.
Die Wende kam, als IBM - mit hohem wirtschaftlichem Risiko - seine 360er-Rechnerfamilie entwickelte, bei der die sechs Modelle unterschiedlicher Leistungsstufen - die Spanne reichte von 1 bis 50 - einem einheitlichen Grundkonzept, also einer einheitlichen "Architektur" folgten. Damit gelang es, den oben erwähnten Überhang an unnötigen Aufwand stark zu reduzieren und den Kunden überdies mit dem verlockenden Angebot eines "Wachstums-Pfades" zu kommen: Man bot fortan die Chance, mit steigenden Anforderungen schrittweise immer mehr Leistung zu ordern, dabei aber nur einen relativ geringen Umlern- und Umorganisations-Aufwand leisten zu müssen.
Der Erfolg dieses neuen Familien-Denkens in der EDV war so durchschlagend, daß andere Hersteller mit mehr oder weniger Geschick rasch nachzogen; so etwa RCA - wobei diese Radio Corporation of America sich inzwischen längst aus dem Rechner-Geschäft verabschiedet hat -, Honeywell, Hitachi, Amdahl etc. Rund sechs Jahre später folgten dann, wie Patterson ins Gedächtnis zurückruft, die Hersteller von Minicomputern den Großrechner-Leuten; also beispielsweise DEC, und ebenfalls sechs Jahre nach den Minis beschritten dann die ersten Mikrorechner-Architekten den gleichen Pfad: Intel etwa mit der Vier-Bit-Pionier-Maschine 4004 und den folgenden Systemen, oder auch Motorola etc.
Dies läßt sich in Zahlen noch ein wenig präziser aufzeigen. Die 360erSerie erschien 1964, die 16-Bit-PDP-11 von DEC 1970, die IBM-370er 1972 und die VAX 1978. Dabei waren die ersten beiden Rechner Maschinen mit Mikrocode im ROM, also in einem kompakten Nur-Lese-Speicher, und die beiden Folge-Typen dann bereits jeweils Maschinen mit großem virtuellem Speicher.
Bei den Minis brachte DEC seine berühmte PDP-8 im Jahr 1965 heraus und Intel zog mit dem 4004 1971 nach. DEC ging 1970 mit der PDP-11 auf die 16-Bit-Architektur mit Mikrocode im ROM über, Intel kam 1977 mit dem 8086. DEC schließlich präsentierte 1978 die VAX mit virtuellem Speicher und erlebte 1984 im Motorola-68020 ein entsprechendes Gegenstück in VLSI-Mikroprozessor-Technik.
Es lohnt sich, diesen kurzen Rückblick noch ein wenig gründlicher zu überdenken, denn er zeigt in aller Deutlichkeit, wie stark die frühen Ideen der 60er-Jahre auch heute, in den allermodernsten Mikroprozessoren etwa des 68030er-Typs von Motorola, oder auch der vergleichbaren Serien von Intel und NatSemi, nachwirken: Traditionen prägen eben doch weithin unser Denken und Tun.
Zu diesen Traditionen gehört vor allem, was IBM 1964 auf breiter Front in die Welt der EDV einführte und was der Schlüssel zum Bau einer ganzen Familie von Rechnern unterschiedlicher Leistungsklassen werden sollte: die in einem Festwertspeicher (ROM) abgelegten Mikroprogramme. Denn damit begann ein Denken, nach dem die einzelnen Befehle der Maschine durch Programme interpretiert und ausgeführt werden. Das war aus der damaligen Zeit der teuren Ferritkernspeicher und der vergleichsweise billigen Festwertspeicher heraus, mehr als sinnvoll: Bei dem 360-Rechnern war deren Mikrocode-Steuerspeicher rund zehnmal so groß wie ihr Ferritkernspeicher.
Nun ist aber die Welt der EDV eine Welt des raschen Wandels - und so kam es, daß schon im folgenden Jahrzehnt wesentliche Änderungen zu berücksichtigen waren. Die Hardware beispielsweise wurde viel zuverlässiger, schneller und billiger, und bei der Software begannen erste wache Köpfe, von der einsetzenden "Krise" zu parlieren: Die Programme wurden immer unzuverlässiger und die Kosten ihrer Neuentwicklung, Pflege und Reparatur immer höher. - Wie sollten die Rezepte von gestern da noch lange gelten können ... ?
Sie begannen denn auch, Mitte der 70er Jahre in der Tat an Gültigkeit zu verlieren - doch seltsamerweise suchte die Rechner-Industrie zunächst nach einem Ausweg in der falschen Richtung. Denn man ging nun verstärkt daran, immer mehr Software in die Hardware (oder die Firmware) zu verlegen und hoffte damit - mehr ratend als rechnend gleich zwei Fliegen mit einer Klappe zu schlagen: erstens dachte man, so würden die Maschinen "natürlich" schneller, und zweitens hoffte man, durch Einsatz der immer zuverlässiger werdenden Hardware die durch Fehlfunktionen gekennzeichnete - Software-Krise wenigstens partiell in den Griff bekommen zu können.
David Patterson schildert in seinen Vorträgen, welche Vorstellungen hinter der Hoffnung steckten, die Verlagerung von Software-Funktionalität in Hard- beziehungsweise Firmware (Mikrocode-ROMs) werde ein Mehr an Tempo bringen. Dabei geht er von der Überlegung aus, daß die Zeit, die zur Bearbeitung eines gegebenen Programms benötigt wird, von drei Parametern bestimmt wird. Nämlich von der Zahl I, die die Zahl der Maschinen-Befehle angibt, die für die Bearbeitung des Programmbefehls benötigt werden, der Zahl C, die die durchschnittliche Zahl von Maschinentakten oder auch Mikrobefehlen pro Maschinenbefehl repräsentiert, und dann schließlich noch von T, also von der Zeit, die pro Taktzyklus beziehungsweise pro Mikrobefehl verstreicht.
Trade-Offs zwischen Leistung und Tempo
Die Programmlaufzeit errechnet sich also zu Z = I x C x T; und für Maschinen mit Mikrocode ist C laut Patterson mit etwa 5 bis 15 anzusetzen; Maschinen mit sehr viel in Mikrocode verlagerter Software-Funktionalität nähern sich dabei eher dem oberen dieser beiden Werte.
Geht man nun davon aus, daß für frühe, mikrocodierte Rechner für I die Zahl 6 typisch sein mag, so scheint es auf den ersten Blick durchaus verlockend, mehr Funktionen in den Mikrocode zu verlagern und so - hoffentlich - die Zahl I drücken zu können. Doch gleichzeitig begann man bereits im letzten Jahrzehnt zu sehen, daß es auch wichtig ist, möglichst viele der Maschinen-Befehle als Ein-Takt oder Ein-Mikroinstruktions-Befehle vorzusehen.
Der Grund dafür wird klar, folgt man erneut der hier wiedergegebenen Modell-Rechnung Pattersons: denn hat man einen Rechner, der pro Maschinenbefehl im Schnitt sechs Mikrobefehle oder Taktzyklen benötigt, so errechnet sich dessen Programm-Laufzeit zu Z = I x 6 x T. Doch kann man nun 20 Prozent der Maschinenbefehle zu Ein-Takt-Befehlen umgestalten beziehungsweise in nur noch einem einzigen Takt ausführen, so sieht die Rechnung so aus: Z = (I x 6 x T) x 0,8 + (I x 1 x T) x 0,2. Dabei repräsentieren die Zahlen 0,8 und 0,2 die 80- beziehungsweise 20prozentigen Anteile der in sechs beziehungsweise in nur einem Taktzyklus abarbeitbaren Maschinenbefehle.
Diese Rechnungen zeigen nun auf den ersten Blick, daß die "alte" Maschine für ein Programm 6 x I x T an Zeit benötigt, die neue aber nur noch 5 x I x T; man hat also ein Sechstel an Geschwindigkeit gewonnen.
In den 70ern müssen die Entwickler sich ständig in einem inneren Streit befunden haben, ob sie die Zahl der Mikrobefehle immer weiter erhöhen sollen, oder ob sie, analog zur soeben dargestellten Berechnung, lieber doch auf möglichst viele Ein-Takt-Maschinen-Befehle aus sein sollten. Doch wie die Historie zeigt, gewann zunächst die Schule der aufgeblähten Mikroprogramme das Rennen.
So hatte, berichtet Patterson, die Serie 360 von IBM 168 Maschinenbefehle und 220 KB Mikrocode, die 370er-Serie aber schon 208 Maschinenbefehle und 400 KB. Was bedeutet, um die Zahl der Maschinenbefehle um 20 Prozent zu vergrößern, mußte der Mikrocode um 120 Prozent erweitert werden.
Billige Speicher verdrängen Mikrocode
Ähnliches kann man auch beim Konkurrenten DEC beobachten. Die PDP-11 hatte 52 Maschinen-Befehle - was man übrigens heute glatt schon als RISC bezeichnen würde! - und 16 KB Mikrocode, die VAX aber schon 303 (!) Befehle und 450 KB. Was besagt, um die Zahl der Maschinenbefehle versechsfachen zu können, mußte 25mal soviel an Mikrocode vorgesehen werden.
Dieses eifrige Auftürmen von immer mehr Mikrocode mag nun zwar aus der Sicht jener Zeit heraus durchaus sinnvoll erschienen sein - doch ironischerweise gab es in genau den gleichen Jahren bei der Hardware Entwicklungen, die sozusagen die geistigen Fundamente der ganzen Mikrocode-Turmbauerei zu unterspülen begannen. In jenen Jahren begannen erstens billige Halbleiter-Speicher den teuren Ferritkernspeicher zu ersetzen und zweitens wurde - Stichwort: "Cache" - die sogenannte Speicher-Hierarchie mit schnellen Speichern in direkter Nähe der Zentraleinheit und, nach außen zu, dann immer langsameren und dafür voluminöseren Speicher-Geräten entwickelt. Beide Neuerungen sollten gravierende Konsequenzen nach sich ziehen. .
Erstens nämlich war nun mit einem Mal jene "gute alte Zeit' vorbei, in der der Mikrocode-Speicher zehnmal so groß war wie der - inzwischen ja billig gewordene und jetzt automatisch, nämlich "virtuell" verwaltete - Hauptspeicher. Und zweitens wurde es plötzlich möglich, auf die im Hauptspeicher ruhenden Maschinenbefehle praktisch ebenso rasch zuzugreifen, wie zuvor nur auf die Mikrobefehle des Mikrocode-ROM. Und das wieder, so betont Patterson, bedeutet: "Funktionen, die in die Hardware (Firmware) verlagert wurden, waren plötzlich kaum mehr schneller als solche, die als Software im Kernspeicher präsent waren".
Weitere Entwicklungen jener Jahre liefen darauf hinaus, daß man sich nun weit weniger um ein effizientes Nutzen der - nun ja billig gewordenen - Speicher kümmern mußte, daß man nun begann, auch Compiler und Betriebssysteme einfach in höheren Sprachen zu schreiben - und die Anwenderprogramme sowieso. Damit wiederum bot sich - dank Hochsprache - die Möglichkeit, komplexe, raffiniertere und umfangreichere Compiler als je zuvor zu entwickeln; Compiler, von denen die Altvorderen nicht mal zu träumen gewagt hätten. Deren Existenz änderte eine weitere Randbedingung, auf die ein Entwickler eines Prozessors zu achten hat.
Diese neuartige Randbedingung, also die Möglichkeit der Erarbeitung sehr leistungsstarker Compiler dank großer Speicher und dank der Verwendung höherer Sprachen beim Schreiben des Compiler, führte - anfangs ziemlich unbemerkt - dazu, daß die nachwachsende, jüngere Generation von Compiler-Autoren aus den großen Befehlssätzen von Rechnern wie der VAX und so weiter einfach nur noch die simpelsten, leicht anwendbaren und leicht im Kopf zu merkenden Befehle auswählten; sie genügten ihnen, konnten sie doch auch allein mit ihnen alle Probleme lösen, die die Sachlage stellte.
Es kam also unter der Hand, und nur von wenigen aufmerksamen Beobachtern wahrgenommen, im Lauf der Zeit dazu, daß die meisten neueren Programme, die von den neuen Compilern in Maschinenbefehle übersetzt worden sind, die teilweise immense Komplexität der Rechner gar nicht mehr voll nutzten, erinnert Professor Patterson.
Außerdem gab es wieder eine in sich gegenläufige Entwicklung.
Denn während die Kosten der Hardware zum Abspeichern eines Mikroprogramms infolge sinkender Chip-Preise deutlich fielen, stellten die Erfinder der immer riesiger werdenden Mikroprogramme fest, daß sie da eigentlich auf Sand bauten. Denn ihre tollen Konstruktionen brauchten laut Patterson immer länger, bis sie endlich geschrieben, getestet, "entwurmt" und schließlich freigegeben waren - und solche Zeitverluste können, in Zeiten scharfer Konkurrenz und rascher Innovationsfolge, für ein Unternehmen tödlich werden. Die Hardware wurde in flottem Tempo immer moderner und, so Patterson, "neue Rechner (wegen der langen Mikrocode-Entwicklungszeiten) wurden in alter Technik ausgeliefert."
Diese Verzögerungen führt der Professor aus Berkeley übrigens besonders darauf zurück, daß man Hard- beziehungsweise Firmware wie etwa Mikrocode-ROMs "weitaus gründlicher entwickeln und testen" müsse, ehe die Auslieferung einer Maschine beginnen kann, als etwa Software-Funktionen. Denn jene "sind ja rasch geändert", stellt sich später mal ein Wurm heraus.
Ein schlagendes Beispiel dafür, wie problematisch die Verlagerung von Funktionalität in Hard- und Firmware sein kann, ist für Patterson der Intel-Prozessor "286". Dessen erste Exemplare wurden mit bestimmten, komplizierten Eigenschaften geliefert, auf denen Digital Research ein neues Betriebssystem aufbaute. Doch später wurden die erwähnten Eigenschaften der Hardware verändert und erweitert und in der Folge gab es Probleme, wenn das neue Betriebssystem auf dem Chip lief. Eine Entwicklung, die Lieferant wie Kunde dann ziemlich viel Kopfzerbrechen bereiten sollte.
Umgekehrt gibt es auch ein gutes Beispiel für den Nutzen, den die Verlagerung von Funktionen zurück in Software schenken kann. Dazu muß man nur die beiden Rechner VAX und MicroVAX-2 einander gegenüberstellen, und sich die wichtigsten Kennzahlen anschauen.
Die MicroVAX-2 hat laut Patterson 80 Prozent der 303 Maschinenbefehle der VAX, benötigt aber nur 13 Prozent der 480 KB Mikrocode der VAX und nur acht Prozent der 1,25 Millionen Transistoren des Ur-Modells. Dennoch aber leistet die MicroVAX-2 fast genausoviel wie die VAX; und zwar bietet sie, um exakt zu sein, 96 Prozent von deren Power.
In diesem Zusammenhang ist laut Patterson besonders interessant, daß allein durch das Eliminieren einer komplexen CALL-Instruktion beim DEC-Modula-Compiler ein Tempo-Gewinn von etwa 20 Prozent erzielt werden konnte.