Moderne Computer setzen heute auf schmale, einfache und sehr schnell abarbeitbare Befehlssätze, denn damit sind sie per saldo flotter als herkömmliche Maschinen. Doch so trivial diese Weisheit, die heute alle Spatzen von den Dächern pfeifen, auch klingt - blickt man tiefer, stecken hinter dem Konzept der Reduced Instruction Set Computer (RISC) doch erheblich tieferschürfendere, komplexere Überlegungen.
Für Professor David Patterson aus Berkeley, in der Fachwelt als einer der Ahnherren der neuen RISC-Rechner bekannt, kennzeichnen zwei Haupteigenschaften einen modernen Computer als RISC. Dies sind erstens seine einfachen Ein-Zyklus-Befehle, die ebenso schnell abgearbeitet werden wie die herkömmlichen, einzelnen Mikrobefehle eines Mikroprogramms, und zweitens die RISC-typische, weitgehende Verlagerung von Funktionen in die Software. Denn Software läßt sich leicht und immer wieder ändern, verbessern und ausbauen - doch das ist nicht alles: Software nämlich wird ja nur ein einziges Mal kompiliert, betont Patterson; dabei werden die Funktionen des Programms einmal maschinengerecht aufbereitet. Dies sei weit besser, als wenn bei jedem Lauf pro Befehl erneut umfangreiche Mikroprogramme in Gang gesetzt werden müßten. "RISCs", so der Professor aus den USA, "überlassen alles dem Compiler, weshalb für sie übrigens auch besonders gute und leistungsstarke Compiler (Übersetzer) benötigt werden."
RISC-Vorzüge ließen sich früher nicht nutzen
In einer kleinen Kalkulation läßt sich gegenüberstellen, wie reine RISC-Rechner sich im Gegensatz zu herkömmlichen, mikrocodierten Maschinen darstellen. Dabei werden wieder die Kürzel für die Zahl der pro Programm auszuführenden Maschinenbefehle (nicht Mikrobefehle!), C für die durchschnittliche Zahl der Taktzyklen pro Maschinenbefehl und T für die Dauer eines Taktzyklus benutzt. Die Laufzeit des Programms (Z) ergibt sich damit als Produkt Z = I x C x T.
Nun gilt für eine typische, mikrocodierte Maschine, daß C etwa mit dem Wert 7,5 anzusetzen ist, wobei die Grenzen hier zwischen 5 und 10 liegen; und Z ergibt sich, setzt man für den Wert 1, zu 7,5 x T.
Anders ein RISC, denn wegen seiner simpleren Befehle ist nun mit 1,2 anzusetzen; es werden hier eben pro Programm rund 20 Prozent mehr Maschinen-Befehle als beim herkömmlichen CISC (Complex Instruction Set Computer) benötigt. Doch dafür geht beim RISC der Wert C mit durchschnittlich nur noch 1,5 statt mit 7,5 in die Kalkulation ein. Daraus folgt, daß ein RISC für das gleiche Programm eine Zeit von nur noch 1,8 x T benötigt, also rund viermal weniger als der CISC. Außerdem sei es beim RISC noch möglich, so Patterson weiter, T im Vergleich zum herkömmlichen CISC zu verkürzen.
Die - zumindest nach dieser Kalkulation - nun sehr plausibel aussehenden Vorzüge des RISC-Konzepts hat man in früheren Jahren einfach nicht nutzen können, weil einmal die Hardware - auch preislich - eine ganz andere war, und weil zweitens die Compiler der 60er und 70er Jahre laut Patterson "unzuverlässig waren". Es war schwer, welche zu entwickeln, und noch schwerer, solche zu konzipieren, die in der Lage waren, statt eines Stapelspeichers oder statt Hauptspeicher-Lokationen direkt die schnellen Register einer Zentraleinheit ausnutzen.
"Semantische Lücke" sollte geschlossen werden
Außerdem galten leistungsfähige Maschinenbefehle in Fülle auch noch aus einem anderen Grund für wünschenswert, erinnert Patterson: Man hoffte damals, die seinerzeit wirklich landauf-landab beklagte "semantische Lücke" zwischen den höheren Programmiersprachen mit ihren komplizierten Datentypen und den früher arg primitiven, elementaren Maschinensprachen mit ihrer Hilfe zu schließen. Dabei ist anzumerken, daß die "eigentlichen" Mikrocode-Befehle, die ja "unterhalb" der Maschinensprache eines mikroprogrammierten Rechners "versteckt" sind, gleichfalls eher als arg simpel anzusprechen sind.
Ein weiterer Gedanke hinter der Begeisterung für komplexe und in großer Zahl eingesetzte Maschinenbefehle war schließlich noch der, daß man damit meinte, die "Qualität der Architektur" verbessern zu können. Man war eben stolz darauf, daß die dementsprechend gebauten Maschinen pro Funktion "bloß wenige (Befehls- und Daten-)Bit aus dem Speicher zu holen" brauchten und damit, wie man ganz einfach annahm, schneller als andere laufen müßten.
Entwurfsgrundsätze und Realität divergieren
Es ist fast schon grotesk, stellt man, im Rückblick, die im vergangener Jahrzehnt weithin akzeptierten Computer-Entwurfs-Grundsätze einmal den Realitäten jener Zeit gegenüber. Denn es galten damals ja Sätze wie etwa "Nütz' die stark sich verbilligenden Festwertspeicher für größere Mikroprogramme", "Bring' Softwarefunktionen in die Hardware und erreich' damit ein Plus an Tempo und an Zuverlässigkeit", "Bau' keine registerorientierten Maschinen" und "Erreich' Dank leistungsfähiger Maschinenbefehle kürzere Programme"; die nämlich würden, dachte man, dann schneller laufen.
Wie aber sah nun demgegenüber die Realität aus? - Nicht nur die Mikroprogramm-Festwertspeicher, auch die zuvor fast unbezahlbaren Hauptspeicher wurden unvorstellbar billig, die fest verdrahteten Mikroprogramme erwiesen sich als fehlerträchtig, es wurden schnelle Pufferspeicher zum Hauptspeicher hinzugefügt und außerdem an immer mehr Arten Compiler entwickelt, die nur noch einen kleinen Teil der gesamten, umfangreichen CICS-Maschinenbefehle nutzen.
Es war in dieser Situation eigentlich bloß noch eine Frage der Zeit, bis einem nachdenklichen Kopf die zündende Idee kam. Denn wenn schon jeder sogenannte Maschinenbefehl im Durchschnitt aus fünf primitiven Mikrobefehlen - und das waren ja sozusagen die "wirklichen" Maschinenbefehle - bestand; wenn viele einfache Operationen sowieso nur einen einzigen Mikrobefehl nutzten, und wenn drittens der Mikroprogramm-Speicher, damit er zur Fehlerbehebung leichter geändert werden konnte, in einen - billig gewordenen - Schreib-Lese-Speicher (sozusagen zurück-)verlegt worden ist: Warum sollte der Programmierer den simplen Maschinenbefehls-Satz dann nicht selber ganz nach Gusto nutzen können?
Zunächst blieb es nur bei der Idee
Es darf hier nicht verschwiegen werden, daß vor zehn Jahren ganz reale Gründe existierten, diesen soeben als Idee skizzierten Schritt nicht kurzerhand zu tun. Da existierte das Problem der seinerzeit unzureichenden Compiler-Technik, und es gab auch Schwierigkeiten mit dem neu erfundenen, virtuellen Speicher. Was sollte beispielsweise geschehen, wenn ein Befehl den benötigten Operanden nicht im Speicher vorfindet? Eine ganze Reihe von Fragen harrte der Beantwortung.
Die Lösung tauchte erst auf, als der zögernd begonnene Umdenk-Prozeß konsequent bis zum Ende durchgespielt worden war. Laut Patterson sah man nun mit einem Mal glasklar die RISC Rechner-Prinzipien der Zukunft vor sich: einfach und ohne verwirrende Umwege oder Fallen.
Es blieb beim neuen Konzept der hierbei entstehenden RISC-Prinzipien zwar bei der Idee, dem Programmierer künftig die Möglichkeit zu geben, die elementaren Befehle der Maschine, also die früheren Mikrobefehle, selber zu nutzen. Doch gleichzeitig wurde ein umfangreicher virtueller Adreßraum mit automatischer Verwaltung vorgesehen, übrigens laut Patterson "eines der wichtigsten Elemente moderner Computer". Und dann galt es eben auch noch, gute Compiler, die ein Quellprogramm bis herunter in die wenigen Elementar-Befehle der Maschine zerlegen können, zu entwickeln.
Kleiner Adreßraum legte Beschränkungen auf
Zur Frage des Adreßraums merkt Patterson an, gerade ein kleiner Adreßraum, der ja den Umfang der von der Maschine handhabbaren Datenstrukturen stark beschränkte, war "eines der schlimmsten Dinge in der Computerei der frühen Jahre". Und er kreidet beispielsweise dem neuen, manchmal übrigens als "RISC" apostrophierten "Transputer"-Chip der Firma Inmos an, leider keine virtuelle Speicherverwaltung mit entsprechend großem Adreßraum zu bieten. Inmos-Mitarbeiter Peter Eckelmann weist dies umgehend zurück: Die "Philosophie" der Transputer gehe in eine andere Richtung. Denn hier sollen die Tasks bewußt alle sehr klein gehalten und nach Möglichkeit von mehreren, miteinander kommunizierenden Transputern parallel bearbeitet werden. Eckelmann: "Wir meinen, daß heute 'Task-Management' das Gebot der Stunde sei, nicht nur das reine 'Memory-Management'." Denn heute sind ja, anders als früher, die Prozessoren etwas sehr Billiges. Zurück nun wieder zu Patterson und seinen RISC's, wobei das "Reduced", das sich in diesem Akronym verbirgt, sogar zweierlei Bedeutung aufweist. Denn einmal wurde die Zahl der sogenannten Maschinenbefehle reduziert und zum anderen auch noch die einzelne Instruktion vereinfacht, also quasi strukturell reduziert.
Laut Patterson sollte man beim Entwurf eines RISC alles vermeiden, was die Zykluszeit T (aus der oben erwähnten Gleichung Z = I x C x T) verlängern könnte; denn man müßte sonst mit viel Aufwand versuchen, das Produkt der beiden restlichen Faktoren I x C dann wieder um den gleichen Faktor zu verkleinern.
Es sei wichtig, sagt Patterson weiter, nur simple Funktionen vorzusehen. Denn die Rechner erzielen heute jedes Jahr einen Leistungsgewinn pro Mark, der etwa 20 bis 40 Prozent beträgt. Wenn nun die Entwicklung komplizierter Funktionen die Entwicklung des Rechners unerwartet - aber durchaus häufig vorkommend - verzögert, so kommt der Hersteller mit seiner Neuheit vielleicht erst zu einer Zeit auf den Markt, da einfacher denkende Konkurrenten schon längst vergleichbar preiswerte Systeme parat haben.
Ein weiterer wichtiger Merksatz für heute und morgen besagt laut Patterson, daß sogenannte Mikrobefehle aus Mikroprogrammspeichern heutzutage nicht mehr schneller ausgeführt werden, als gewöhnliche, einfache RISC-Maschinenbefehle. Denn die einen werden aus einem schnellen Mikroprogramm-Speicher geholt, die anderen eben aus einem schnellen Befehls-Pufferspeicher.
Einen großen Zuwachs an Geschwindigkeit erzielen moderne RISC-Maschinen, weil sie ihre Befehle intern, ähnlich aufwendigen Vektorrechnern, fließbandartig-überlappend ausführen. Man sieht also sogenannte "Pipelines" vor, in denen die Befehle schrittweise geholt, dekodiert, die Operanden geholt, der Befehl ausgeführt und das Resultat dann abgespeichert wird. Dabei können in einer Pipeline mehrere Befehle zugleich bearbeitet werden, und zwar jeder in einer etwas früheren Phase des eben geschilderten Zyklus, als der vor ihm.
Bei dieser Pipeline-Technik müssen wechselseitige Abhängigkeiten aufeinanderfolgender Befehle erkannt und besonders - und zeitraubend die Pipeline unterbrechend - behandelt werden. Doch dafür kann die Pipeline, wenn zum Beispiel stets drei Befehle gleichzeitig durch das Fließband geschickt werden, im Idealfall eine Beschleunigung der Arbeit um den Faktor drei bewirken Patterson: "Der Effekt des Pipelining bringt mehr als der Versuch, den Programmcode möglichst klein zu halten". Und er hebt weiter hervor, daß für diese Fließband-Technik schnelle Register in ausreichender Zahl wichtig seien, sowie außerdem möglichst einfache Verfahren zum Dekodieren der Befehle. Dabei betont Patterson, bei den einfachen Befehlsformaten eines RISC könne der Compiler wechselseitige Abhängigkeiten zwischen Befehlen relativ leicht im Voraus erkennen und somit oft bewirken, daß die betreffenden Befehle dann nicht etwa zur gleichen Zeit durch die Pipeline geschleust werden. Denn dann würden ja zeitraubende Zwischenaktionen unvermeindlich.
Risc-Register müssen effizient genutzt werden
Beim Übersetzen eines Hochsprachen-Programms - etwa in Pascal - auf das Niveau der RISC-Maschinensprache ist laut Patterson wichtig, daß der hier aktive Compiler die vom RISC gebotenen Register effizient zu nutzen versteht. Und er legt ein Beispiel vor, das im Falle einer Programmierung mit Lade-Speicher-Anweisungen 228 Befehlsbit und sechs Datenspeicherzugriffe umfaßt. Wird das gleiche Programm auf einer Maschine mit Speicher-zu-Speicher-Befehlen bearbeitet, so umfaßt es 168 Befehlsbit und es erfordert neun Datenspeicherzugriffe. Während ein nur mit Registern arbeitendes Programm - vorausgesetzt, die Operanden sind schon in den Registern - nur 60 Befehlsbit lang ist und keinerlei - zeitraubende - Datenspeicherzugriffe mehr erfordert.
Entwicklung läßt sich sehr schnell durchziehen
RISCs, die den hier skizzierten Grundsätzen gehorchen, sind erstaunlich schnell zu entwickeln. So brauchte Patterson für seinen "RISC I"-Chip aus dem Jahre 1982 nur 44 000 Transistoren und 15 beziehungsweise zwölf Mannmonate Entwurfs- beziehungsweise Layout-Zeit. Hingegen umfaßt der Motorola-Prozessor 68000 rund 68 000 Transistoren und für ihn wurden für Entwurf und Layout 100 beziehungsweise 70 Mannmonate Zeitaufwand ermittelt.
Der Bau eines RISC-Prototypen an der Universität Pattersons ist ein Indiz für die Richtigkeit seiner immer wiederholten Feststellung, es werde in der Fachwelt heute auf der Suche nach optimalen Prozessoren "viel mehr experimentiert als früher". Beispielsweise wurde im Laufe der Jahre auch entdeckt, daß "alle Programme sehr viel Lokalität" aufweisen.
Weniger Adressiermodi als bei herkömmlichen Rechnern
Diese Lokalität nun wiederum nutzt der kalifornische RISC-Pionier, um Operanden möglichst lange in den internen Registern des Prozessors zu halten und um möglichst nur noch schnell ablaufende Register-Operationen vorzusehen; Speicherzugriffe hingegen werden nur noch über besondere Lade- und Speicher-Befehle erlaubt. Dabei ergeben sich außerdem weniger, und mikrocodefreie, Adressiermodi als bei herkömmlichen Rechnern, was zwar bei reinen Register-Register-Operationen sowieso klar ist, was aber bei anderen Adressierungen zu flotten Ein-Zyklus-Operationen mit "relativer", auf den Programmzähler bezogener Adressierung führt.
Befehlsformate bei RISC haben einheitliche Länge
Beeindruckend ist im Vergleich zu herkömmlichen Maschinen auch, wie einfach die Befehlsformate eines RISC aussehen. Sie sind in einem Beispiel des Professors aus Kalifornien einheitlich nur 32 Bit lang, wohingegen VAX-Instruktionen zwischen 1 und 456 Bit umfassen können.
Das einfache überschaubare Befehlsformat eines RISC in Pattersons Manier erlaubt auch so interessante Tricks wie den "verzögerten Sprung", der dafür sorgt, daß die oben erwähnte Pipeline erst noch kurz weiterarbeiten kann, ehe ein Sprungbefehl ausgeführt wird. Auch hier kommen übrigens Optimierungen, die schon während des - einmaligen - Kompilierens erfolgen, bei jedem erneuten Programm-Durchlauf dann wieder neu zum Tragen.
Compiler übernehmen organisatorische Aufgaben
Gute, neue Compiler erkennen laut Patterson auch, wie man ein Programm sinnvoll organisiert, wenn man beispielsweise nur vier Register, aber sieben Operanden hat. Denn dann kann der Compiler eines modernen RISC feststellen, daß zum Beispiel in jenen Phasen des Programmlaufs, in denen bestimmte Operanden gerade nicht benötigt werden, zwischenzeitlich andere in die Register geholt werden können. Diese Technik wurde übrigens in den IBM-Labors am RISC-Urahn "801", sowie am "MIPS"-RISC der Stanford University entwickelt.
Patterson wiederum hat in Berkeley eine Register-"Fenster"-Technik
erarbeitet, bei der jedem Prozeduraufruf jeweils ein eigener Register-Satz zugewiesen wird; denn auch so könne man die Arbeit des Computers beschleunigen.
Weitere Techniken, einem RISC mal so richtig Beine zu machen, haben mit Verfahren des beschleunigten Ladens neuer Operanden aus dem Hauptspeicher zu tun. Denn auch das kann bei geschickter Organisation in nur noch einem Maschinenzyklus erledigt werden. Nötig sind dazu ebenfalls wieder besondere Fähigkeiten des Compilers, beziehungsweise spezielle, "direkte" Datenwege; sie werden zusätzlich angelegt und verbinden die Register unmittelbar mit dem Hauptspeicher.
Zur höheren RISCologie gehört weiterhin, daß man beim Konzipieren der weiter oben schon dargestellten Fließband- oder auch Pipeline-Technik auf gute zeitliche Ausgewogenheit achtet: daß also die überlappend durchzuführenden Befehlshol-, Register-lese-, arithmetisch-logischen Ausführungs- und schließlich die Register-Schreib-Operationen alle gleich viel Zeit benötigen. Dabei hat übrigens Patterson in seinen RISC-Modellen I und II, im Gegensatz zu den Entwicklungen von IBM und Stanford, eine Besonderheit vorgesehen: die Register-Schreib-Operation wird erst nach einer Pause von exakt einer Fließband-Arbeitsphase ausgeführt.
Programme laufen bis zu 50mal schneller
So kann die Hardware in Fällen, in denen der nachfolgende Befehl Daten benötigt, die im Befehl unmittelbar davor erarbeitet wurden, diese Operanden direkt übergeben; es werden also unnötige Verzögerungen vermieden. Wobei aber auch hier wieder Compiler wünschenswert sind, die eben diese Eigenschaft einer Maschine "kennen" und effizient zu nutzen wissen.
Wie wichtig die Compiler heute bei der Konzeption moderner DV-Systeme schon sind, sieht man auch an einem verblüffenden Beispiel Pattersons, das sich auf die IBM-Rechner der Serie /370 bezieht. Denn da gebe es, als Subset des üblichen Compilers, einen für die Sprache PL/1, der die 370er-Architektur bewußt als Register-Register-Maschine behandle.
Mit dem Erfolg, daß die Programme dann rund 50mal schneller laufen, als hätte man einen herkömmlichen, "optimierenden" Compiler eingesetzt.