Wollte man sich in früheren Jahren als Computerexperte ausweisen, so genügte es vielfach, gekonnt mit Kürzeln wie DFU, ADA oder MVS um sich zu werfen; der Erfolg war vorprogrammiert. Heute indes muß man schon Akronyme wie RISC oder CISCS auf der Platte haben. Doch was ist dran an der RlSCanten Diskussion?
Geht man der Frage nach, warum heute fast keine Woche mehr ohne Präsentation eines neuen RISC-Produktes vergehen kann, stößt man bald auf die drei bekannten Buchstaben - IBM. Denn auch die RISC-Woge, auf der vor allem die Marketingabteilungen bestens zu surfen gelernt haben, läßt sich bis in die Studierstuben des Armonker Rechnergiganten zurückverfolgen.
Was heute so leichthin mit RlSC, also als "Reduced Instrustion Set Computer", bezeichnet wird, und was angeblich ein Gegenstück zu herkömmlichen "CISCs", also zu Rechnern mit einem "complexen" Befehlssatz darstellen soll, geht auf Überlegungen des IBM-Wissenschaftlers John Cocke zurück. Statt immer kompliziertere Rechner mit immer "mächtigeren" Befehlssätzen zu entwickeln, setzte er auf E. F. Schumachers "Small is beautiful"-Thesen, um einen Rechner mit betont einfacher Architektur und schlichtem Befehlssatz zu entwikkeln.
"Versuchskaninchen" 801
Diese Idee erprobten Cocke und eine kleine Schar getreuer Adepten zunächst am IBM-Forschungsprojekt "801". Dabei bauten sie auf Vorarbeiten auf, die der Entwicklung eines schnellen Steuerbausteins für umfangreiche Telefon-Schaltzentralen gegolten hatten und aus denen l979 dann der Prototyp des 801 entstand.
Daß bei diesen Arbeiten in der Tat ein Rechner mit einem recht mager aussehenden Befehlssatz entstand, ist Cocke zufolge eher das Nebenprodukt einer Entwicklungstätigkeit, die in erster Linie nur auf eine einfache Architektur abzielte; denn es. zeigte sich bei den Studien des Teams, daß man oft ohne jede Leistungseinbuße auf komplizierte Befehle verzichten und deren Funktionen simpel durch Ketten einfacher Befehle vollführen kann.
Dieses Emulieren komplizierter Befehle durch einfache bedarf allerdings besonderer Voraussetzungen: Man benötigt sehr leistungsfähige Compiler, die vor allem über sehr gute Optimierungsfähigkeiten verfügen müssen.
Cockes Entwicklung, die 801, wäre unvollständig beschrieben, würde man hier nicht noch auf ein anderes ihrer typischen Merkmale hinweisen: auf die sehr schnellen und sehr großen Speicher, mit denen die Maschine - und das sollte ein charakteristisches Kennzeichen ihrer Architektur werden - ausgestattet wurde. Auf diese Weise bauten Cocke und seine Leute nunmehr einen Rechner der das Problem, Informationen zu speichern und wiederzufinden, allein schon von der ganzen Anlage seiner Speicher-Hierarchie her minimierte.
Diese Eigenschaften der Hardware erlaube dem Team nun die Verwendung von Befehlen eines einfachen, einheitlichen Formats, die alle in jeweils nur einem Zyklus ausgeführt werden und die der Rechner nach Art einer Pipeline, fließbandartig behandelt. Damit ließ sich wertvolle Zeit sparen.
Während Cocke selber eigentlich nie von einem RISC sprach, wurde dieses Kürzel Ende des letzten Jahrzehnts von David A. Patterson und seinen Freunden geprägt, als sie an der University of California eine entsprechende Maschine namens "RISCI" zusammenbauten. Ähnliche Ideen verfolgten seinerzeit auch Kollegen von der Stanford University in Palo Alto. Die schon damals bei allen Arbeiten entwickelten RlSC-Merkmale wie
- wenige, einheitlich strukturierte einfache Befehle mit einer Ausführungszeit von nur einem Zyklus
- zahlreiche Register in der Zentraleinheit;
- Speicherzugriffe nur noch über die Lade- und Speicherbefehle
- Verzicht auf Mikrocode;
- ausgefeilte optimierende Compiler
setzten sich durch. Sie finden sich mehr oder weniger deutlich, auch in allen heute auf dem Markt offerierten RISC-Systemen wieder.
Dabei waren eigentlich nur die beiden Forschungs-Maschinchen oder besser -Chips aus Berkeley und Palo Alto echte "RISCs", wie Kenner der Technik betonen; hingegen segeln viele der sogenannten RISCs der Industrie heute unter mehr oder weniger falscher Flagge: zu viele Befehle, zu wenig Register.
Nun ist es allerdings kein Nachteil, wenn kommerziell im Wettbewerb stehende Rechner aus Leistungsgründen über mehr Befehle verfügen, als die "reine Lehre" vom hehren RISC-Konzept es vielleicht gerne sähe; nur sehen "RISCs" mit 150 Instruktionen und mehr vertrauten "gewöhnlichen" Computern wie etwa DECs Microvax II-CICS schon wieder recht ähnlich. Dies bestätigt jene Fachleute, die von einer sogenannten RISC-Architektur nichts mehr hören wollen; sie meinen nämlich, wichtig sei letztlich doch nur, daß eine kosteneffiziente Maschine genau das tut, was sie soll.
So kommt es, daß sich bei näherem Hinschauen manche sogenannte RISC-Lösung einfach als Variation des klassischen Prinzips darstellt: HP etwa kennt bei seinen "Spectrum"-Rechnern auch Befehle, die mehrere Zyklen benötigen, und Ein- und Ausgabeoperationen werden teilweise per Microcode abgewickelt. Auf der anderen Seite wiederum verblüffte unlängst GEI bei der Vorstellung der aus den USA kommenden Celerity-Rechner die Fachleute, als die Zahl der Register jener Maschinen bekanntgegeben wurden: bis zu 32 000. Das ist fast schon RISC im Extrem.
Daten primär in schnellen Registern
Versucht man, sich von den gängigen Schlagwörtern freizumachen und mehr auf das Ziel zu schauen, das Entwickler moderner Rechner heute verfolgen müssen, wenn sie im Wettbewerb bestehen wollen, so kann man von ideologisch nicht gebundenen Experten die Meinung hören, ein Prozessor-Chip sollte heute vor allem die Möglichkeit haben, so schnell als nur irgend möglich zu laufen; Speicherzugriffe und Ein-Ausgabe-Operationen sollten ihn dabei so selten wie möglich bremsen.
Moderne Rechner tun also gut daran, Daten primär in schnellen Registern zu halten, die Verarbeitung gleichzeitig-überlappend mit Speicherzugriffen ablaufen zu lassen und Befehle möglichst in nur einem Zyklus auszuführen; denn so läuft der Prozessor fast stets mit maximalem Tempo und so gibt es keine großen Schwierigkeiten, das ganze System nochmals schneller zu machen, falls später neue Chips mit höherer Arbeitsgeschwindigkeit zur Verfügung stehen.
Ein wichtiger Gesichtspunkt neben dem reinen Tempo-Aspekt ist die Frage, wie man die Maschinenbefehle eines RISC oder auch Nicht-RISC am besten auslegt. Man kann viel an Tempo gewinnen, schafft man Instruktionen, die gut zu modernen, höheren Programmiersprachen passen und die dem Compiler seine Übersetzungsarbeit so stark erleichtern, daß er wirklich effizienten, die gegebene Rechnerarchitektur optimal nützenden Code erzeugen kann.
Betrachtet man die Argumente, die es beim Entwickeln moderner Rechner gegeneinander abzuwägen gilt, so findet man rasch noch ein weiteres, das die aktuelle Tendenz in Richtung RISC unterstreicht. Es gilt heute, die Entwicklung eines CPU-Chips möglichst schnell durchzuziehen, um dem Wettbewerb zuvorzukommen. Das aber bedingt einfache Entwürfe mit weniger Befehlen, die zudem auch rascher geändert werden können als komplizierte Chips, wenn man später beispielsweise Weiterentwicklungen implementieren will.
Für diese Beschränkung auf einfache, magere Befehlssätze spricht weiterhin, daß die Zykluszeit eines Rechners zu umso größeren Werten tendiert, je komplexer die Instruktionen sind und je mehr interne Fallunterscheidungen und Prüfungen etc. bei einem Programmlauf jeweils erforderlich werden. Das kann dazu führen, daß man selbst dann, wenn man die Vorteile der komplexen Instruktionen nicht voll nutzt, für sie einen Preis zu zahlen hat.
Zahlen aus der Praxis besagen, daß ein Programm für eine RISC knapp ein Drittel mehr Befehle umfaßt, als ein gleichartiges für einen CISC- doch dafür sollen pro Befehl bis zu fünfmal weniger Zyklen nötig sein als im Falle des CISC. Dabei ist anzumerken, daß die beiden hier genannten Werte nochmals stark variieren; sie schwanken je nach Art des Programms und hängen auch davon ab, ob beispielsweise ein Extra-Koprozessor für Arithmetik implementiert ist.
Ein Aspekt, der bei der beliebten RlSC-CISC-Debatte bisher kaum angesprochen worden ist, betrifft ein Konzept, das in HP-Kreisen als typische RISC-Ein-Ausgabearchitektur apostrophiert wird und das eigentlich etwas Revolutionäres zum Ziel hat. Denn, so zitiert die US-Elektroniker-Fachpresse einen HP-Mann, künftige Maschinen dieses Herstellers sollen so gebaut werden, daß die Peripheriegeräte direkt auf der Systembus der Zentraleinheit zugreifen - und nicht mehr auf zwischengeschaltete Kanalsteuerungseinheiten. Diese Neuerung soll um einiges gewichtiger sein als die oberflächliche Frage: Ist RISC nun besser als CISC?
RISC-Rechner belohnen ihre Konstrukteure für deren Disziplin beim Sich-Beschränken auf nur die nötigsten Befehle damit, daß die Zentraleinheit bei der heutigen VLSI-Technik auf einem extrem kleinen Chip Platz findet - beziehungsweise damit, daß man auf einem normal großen Chip gleich noch allerhand an Zusatzaufwand unterbringen kann: Pufferspeicher, Speicherverwaltungseinheiten, Gleitkommahardware und so weiter. Dadurch wiederum stoßt man in höhere Tempobereiche vor, denn das somit entstehende, komplexe Einchip-System ist vielfach deutlich schneller als vergleichbar verschaltete Mehrchip-Aufbauten mit ihren Signallaufzeit- und Anpassungsproblemen von IC zu IC.
Vor allem Unternehmen, die Chips nicht verkaufen, sondern nur für den internen Bedarf fertigen, dürften diesen Weg der komplexen Chips mit RISC-Prozessoren gern gehen; denn für sie ist der Preis des einzelnen Chips relativ unwichtig, gemessen am Preis, den das komplette von ihnen aufgebaute System bringen soll. Deshalb können sie die relativ geringere Ausbeute an guten Chips die sich - kostentreibend - stets ergibt, fertigt man pro Wafer-Scheibe wenige große statt viele kleine Chips, eher hinnehmen als eine reine Chip-Factory.
RISCs bearbeiten idealerweise pro Taktzyklus jeweils einen Befehl - und das bedeutet natürlich, die Befehle müssen ihnen sehr schnell zugeführt werden: die Bandbreite des Pfads zwischen Speicher und Prozessoren muß möglichst groß sein. Dies ist der Grund, warum man bei RISCs auf schnelle Speicher-Chips Wert legt und weshalb man außerdem teils schnelle Pufferspeicher und teils besondere, raffiniert arbeitende Speicherverwaltungseinheiten vorgesehen hat.
Zur Abrundung des Bildes Zahlen über die Pyramid-RISCs, die in Deutschland von Nixdorf verkauft werden: Während VAX-Rechner von DEC beispielsweise mehr als 300 Befehle kennen - und DEC mit sicherlich guten Gründen an dieser auf das Betriebssystem VMS zugeschnittenen Konzeption auch nichts Grundlegendes ändern will - begnügen die Pyramids sich mit 90 Befehlen.
Die Maschinen-Programme für die Pyramid-Rechner sollen um etwa zehn bis 20 Prozent länger werden als bei herkömmlichen ClSC-Rechnern, doch die Rechenzeit der RISCs soll dennoch zwei- bis dreimal kürzer sein. Die durchschnittliche Zahl der zum Ausführen eines Befehls nötigen Taktzyklen betrage beim CICS acht, beim Pyramid-"RISC" aber nur drei.
Die vielen Register eines "echten" RISC, die sozusagen der Gegenwert dafür sind, daß der RISC keine oder fast keine Chip-Fläche für Mikrocode-Speicher verschwendet, schlagen sich in puncto Tempo dadurch nieder, daß, so die Zahlen zu den Pyramids, Register-Register-Operationen rund zehnmal schneller sind als Register-zu-Hauptspeicher-Operationen.
In diesem Zusammenhang verdient der GEI-Celerity-Rechner Beachtung, der erstens über eine immense Zahl von Registern verfügt, zweitens mehrere schnelle Cache-Speicher besitzt und der wohl auch zur weiteren Vergrößerung der CPU-Speicher-Bandbreite, drittens noch eine Speicherverwaltungseinheit aufweist.
Logisch überlappende Registerfenster
Zum Thema Register ist im Falle der Pyramid-RISCs noch interessant, daß hier mit logisch überlappenden Registerfenstern gearbeitet wird. Das heißt, diese Maschinen übergeben Parameter in der Weise von einem Register zum anderen, daß neue logische Zuordnungen vorgenommen, nicht aber Informationen physisch bewegt werden. Es genügt ja, Zeiger, die das jeweils gemeinte Register spezifizieren, zu ändern - und schon gehen, so heißt es, Prozeduraufrufe in einem Zehntel der Zeit über die Bühne, die bei konventioneller Technik gemessen wird.
Beim Pyramid-RISC sollen nur etwa ein Viertel bis Fünftel aller Befehle eines typischen Programms Load- und Store-Instruktionen darstellen, also zeitraubende Daten-Speicherzugriffe erfordern. Hingegen sollen bei CISCs fünf bis sieben von zehn Befehlen den Speicher involvieren; und wenn ein Cache-Zugriff auch drei- bis viermal schneller ablaufen mag als ein Zugriff auf den Hauptspeicher - er ist immer noch zwei- bis viermal langsamer als eine reine Register-Register-Operation
Zuletzt noch eine Statistik, die das Bild weiter erhellen soll. Danach betreffen nur zwölf Prozent der Befehle einer typischen ClSC-Anwendung Call-/Return-Instruktionen, doch entfallen allein auf jene 45 Prozent die Hauptspeicherzugriffe. Gar nur drei Prozent der Befehle betreffen Schleifen, doch hängen damit 26 Prozent der Hauptspeicherzugriffe zusammen. Und auf der anderen Seite sind 38 beziehungsweise 43 Prozent der Befehle Zuweisungs- und Verzweigungsbefehle, doch auf sie entfallen nur 15 und 13 Prozent der Speicherzugriffe.