Im Bereich der Computerei tun sich immer wieder seltsame Dinge. Da kommen zunächst in esoterischen akademischen Zirkeln Ideen auf, die anfangs ein lebhaftes, fast enthusiastisches Echo finden. bald aber von den "Realos" unter den Informatikern als unpraktikables Hirngespinst abgetan und prompt vergessen werden - nur, um schließlich mit neuer. noch größerer Strahlkraft wieder aufzutauchen.
Wer nun vielleicht glaubt, die Rede sei von der "Künstlichen Intelligenz", der irrt. Gemeint sind vielmehr die sogenannten "RISC-Prozessoren", die in etwa das oben skizzierte Geschick durchlebt haben; zur Zeit befinden sie sich in jener Phase, in der landauf, landab täglich mehr von ihrem Einfluß auf die Konzeption künftiger, moderner Rechnerarchitekturen gesprochen wird. Was heißt aber RISC? - Dieses Kürzel steht für "Reduced Instruction Set Computer" und drückt eigentlich schon das Wichtigste aus: Es geht um Rechner, deren Satz elementarer Maschinenbefehle so stark verkleinert wurde, daß die Hardware bewußt die restlichen Befehle mit nun um so größerem Tempo bearbeiten kann, wobei die RISCs vorwiegend reine Register-Operationen ausführen und zeitraubende Hauptspeicher-Zugriffe eher vermeiden.
Wie manches in der modernes Computerei kann auch das RISC-Konzept auf Ideen aus der IBM-Denkfabrik "Thomas J. Watson Research Center" in Yorktown Heights nahe New York zurückgeführt werden. Dort entwickelten John Cocke und seine Kollegen schon in den frühen siebziger Jahren ihre in Fachkreisen berühmt gewordene "801": Eine stark abgemagerte Maschine mit schnellen ECL-Schaltungen und nur einigen wenigen, in jeweils nur einem Maschinenzyklus abarbeitbaren Befehlen, die überdies nicht microprogrammiert war, sondern mit festverdrahteter (kombinatorischer) Logik arbeitete. Sie brachte es auf viele Millionen Befehle pro Sekunde (Mips) - aber das waren eben recht simple Befehle.
Die Einfachheit des Befehlssatzes der 801 und anderer RISC-Entwicklungen ist nun keineswegs von Haus aus ein Nachteil, denn hier haben die RISC-Fans ganz einfach die praktischen Konsequenzen aus der sogenannten "80-20-Regel" gezogen. Diese Regel ist ein Produkt intensiver Studien und besagt, daß die komplexeren Instruktionen, die konventionelle Rechner bieten, eigentlich nur selten benutzt werden. Es gelte also die Faustregel, daß 80 Prozent der vorhandenen Maschinenbefehle nur in 20 Prozent der Rechenzeit ausgeführt werden - und umgekehrt.
Nachdem die Wissenschaftler ihren Rechnern also endlich auf die Schliche gekommen waren, lag es für Cocke und seinen Berkeley-Kollegen David Patterson natürlich nahe, daraus praktische Konsequenzen zu ziehen: Es müßte doch eigentlich reichen, überlegten die RlSC-Erfinder, die selten genutzten, komplexeren Befehle einfach alle in simple Basisbefehle wie Lade, Speichere, Vergleiche, Verzweige, Addiere etc. aufzuspalten; denn per Saldo, das zeigten die Berechnungen, müßte so eine RlSC-Maschine dann schneller laufen. Und das vor allem deshalb, weil man die einfachen Instruktionen jeweils in bloß einem einzigen Taktzyklus durchziehen kann. Außerdem erfordern Maschinen mit wenigen Befehlen auch weniger Hardware, und das bringt natürlich zusätzlichen Gewinn in Form geringerer Maschinenkosten.
Obwohl lange Zeit von der Industrie kaum beachtet, konnten die wenigen RlSC-Freaks in aller Welt doch nachweisen, daß ihr Konzept unter günstigen Umständen aufging - allerdings nur mit einer Einschränkung. Denn die frühen RlSC-Rechner arbeiteten zwar schnell - doch mußten sie sich mit komplexen Gleitkommaberechnungen herumschlagen, so war ihre Überlegenheit dahin. Hier ist es eben nicht damit getan, ein Byte aus dem Speicher zu holen, es mit einem zweiten aus irgendeinem Rechner zu vergleichen und dann zu
verzweigen oder auch nicht: Gleitkomma-Arithmetik ist schon ein bißchen anspruchsvoller . . .
Nun könnte man natürlich sagen, dann setzen wir RlSC-Rechner eben für Arithmetik-lastige Programme gar nicht erst ein und beschränken uns auf die eher anspruchslose übrige Software. Doch weil so etwas niemanden recht zufriedenstellen kann, ist man inzwischen auf den Ausweg verfallen, die Gleitkomma-Rechnerei einfach von der eigentlichen RlSC-Zentraleinheit weg auf einen schnellen, speziellen Gleitkomma-Prozessor zu verlagern. Und neuere RISC-Entwicklungen, so etwa ein Mehr-Chip-Rechner der amerikanischen Firma Ridge aus Santa Clara Kalifornien, sollen außerdem sogar in der Lage sein, Gleitkomma-Rechnungen direkt in der RISC-CPU hinreichend flott hinter sich zu bringen.
Damit wird das ganze RISC-Konzept nun natürlich noch um ein gutes Stück interessanter. Ein Konzept, das zum Beispiel auch den schnellen Rechnern der US-Firma Pyramid zugrunde liegt und das man knapp mit folgenden Stichworten umreißen kann:
- kleine Menge sehr einfacher Befehle;
- einfaches und einheitliches Befehlsformat, das nur Befehle einheitlicher Länge und Struktur kennt;
- festverdrahtete Logik statt besonderer Mikroprogramme;
- registerorientierte Konzepte, bei denen nur die besonderen Lade- und Speicherbefehle auf den Hauptspeicher zugreifen.
Das Ziel heißt Multiprozessor-Architektur
Die Pyramid-Rechner sind ein Beispiel dafür, was man von einem ausgeklügelten RISC-System heute theoretisch erwarten kann: Der neue, auf der NCC in Chicago vorgestellte RISC-Prozessorkomplex namens "98x" soll nämlich, so wurde versprochen, mit seiner registerintensiv arbeitenden Hardware den Weg zu (Unix-)Multiprozessor-Architekturen öffnen, die dann zu geringeren Kosten als etwa DECs neues Flaggschiff, die "8600", ein Höchstmaß an Leistung bieten sollen.
Nicht allein im Bereich kompletter Rechner taucht das Thema RISC von Woche zu Woche häufiger auf, auch im Sektor Mikroprozessoren erwärmt es die Gemüter. So stellte unlängst das britische Unternehmen Acorn aus Cambridge - es gehört bekanntlich mittlerweile zu Olivetti
- einen RlSC-Prozessorchip vor; eine 32-Bit-Maschine, die von vier Ingenieuren binnen 18 Monaten entwickelt wurde und die drei Mips leistet.
Dieser "ARM" getaufte Chip verfügt über eine überlappend, also im Fließband- oder auch Pipeline-Verfahren arbeitende Zentraleinheit sowie - und das ist eine Besonderheit - einen CPU-Speicher-Port von außerordentlich hoher Bandbreite. Die arithmetische und logische Einheit (ALU) kann auf den stattlichen Satz von 25 Registern zu je 32 Bit Wortbreite zugreifen. Der Chip beinhaltet einen festverdrahteten Satz von fünf Basisbefehlen, die alle noch um einen Bedingungscode erweitert werden. Jeder Befehl wird in nur einem einzigen Taktzyklus von 150 Nanosekunden Dauer abgearbeitet..
Durch die erwähnte Fließbandverarbeitung können laut Acorn bei aufeinanderfolgenden Register-Register-Befehlen in jedem einzelnen Zyklus alle Teile des Prozessors und auch des Speichers von genutzt werden; in jedem Zyklus kann also ein Befehl den Weg der Daten steuern, ein zweiter gerade für den nächsten Taktschritt decodiert und ein dritter soeben aus dem Speicher geholt werden.
Mit einem 26 Bit breiten Adreßbuch und einem 32-Bit-Datenbus soll der ARM eine Speicherübertragungs-Bandbreite von glatt 18 MB pro Sekunde erreichen. Der entsprechende Wert soll für eine VAX 750 nur 4 MB betragen. In der englischsprachigen Elektronikfachpresse wird Acorn-Manager Steve Furber zum ARM mit den Worten zitiert: "Wir erzielen eine bessere Leistung als ein Zilog- oder ein Motorola-Prozessor mit nur etwa einem Zehntel der Bauelemente und mit einem viel kleineren Chip." Das ist insofern ein wichtiger Aspekt, als ein einfacherer und kleinerer Chip im Entwurf und in der Fertigung ja billiger als ein gewöhnlicher sein sollte.
Wie sehr sich so ein RlSC-Chip von seinen herkömmlichen Brüdern abhebt, zeigen auch einige andere Zahlen: Während ein Motorola-Mikro vom Typ "68020" auf einem 80-mm² Chip 192 000 Transistoren unterbringt, kommt der ARM-Chip mit 25 000 Transistoren auf 50 Quadratmillimeter aus. Die kleineren Chip-Abmessungen führen zu einer höheren Ausbeute an intakten Chips pro Wafer und sorgen dafür, daß der neue Chip viermal billiger zu fertigen ist als ein herkömmlicher. Später, wenn eine zweite Generation dieses Chips noch weiter geschrumpft sein wird, rechnet man sogar mit einem Kostenabstand von rund eins zu zehn.
Benchmarks, also Testprogramme, ergeben für die neuen RISC-Maschinen sowohl von Acorn als auch von Ridge erstaunliche Geschwindigkeiten, mißt man ihre Performance etwa an einer VAX 780. Details wollen wir hier allerdings nicht ausbreiten, da Benchmarks problematisch sind.
Wie sorgsam Konstrukteure von RISC-Rechnern zwischen einerseits einfachen und schnellen und andererseits leistungsfähigen - und dann entweder mehr Zeit oder mehr Hardware erfordernden Befehlstypen - wählen müssen, zeigt sich, wenn man den Ein-Chip-Acorn-Prozessor mit dem Mehr-Chip-System von Ridge vergleicht. Während der erstere ja nur simple Ein-Takt-Befehle kennt, hat der Ridge-RISC 91 Befehle von 16,32 und 48 Bit Länge. Und rein theoretisch wäre es machbar, alle diese Befehle, würde man nur genug zusätzliche Hardware vorsehen, in ein bis allerhöchstens zwei Taktzyklen ausführen zu lassen.
Mehr Hardware vermindert Zykluszahl
"Mehr Hardware" ist aber der RISC-Grundidee genau entgegengesetzt, und deshalb braucht der Ridge-Rechner auch beispielsweise für eine Gleitkomma-Addition fünf Zyklen. Das aber sei unterm Strich immer noch günstiger, meint John V. Sell, der Konstrukteur dieser Maschine, als die rund 100 Chips an Zusatzaufwand vorzusehen, ohne die man eben nicht auf Befehle mit höchstens zwei Zyklen kommt. Sie würden die Gesamtzahl der Ridge-RISC-Chips übrigens auf rund 500 erhöhen.
Die Verteilung der RISC-Maschine auf so viele Chips hat laut Sell den Grund, daß man eben dadurch vermeiden konnte, die Gleitkomma-Arithmetik auf einen besonderen, numerischen Koprozessor-Chip auslagern zu müssen. Dadurch spart man im Betrieb einmal jene Zusatzzyklen ein, die immer wieder mit diesen Auslagerungen verbunden wären, und kann außerdem so auch die Gleitkommabefehle in die überlappende (Pipelining) Arbeitsweise mit einbeziehen, die Ridge-Konstruktion ebenso auszeichnet wie den ARM-Chip. Ferner spreche für die Implementierung mit vielen Chips, daß man so das Zeitverhalten der Hardware flexibler planen könne.
Sell meint, es habe mehr gebracht, alle Funktionen in die CPU zu packen, statt nur einfach zu versuchen, möglichst viel - und dann eben auch ohne die Gleitkomma-Arithmetik - auf einem Chip zu integrieren. Was aber nicht bedeuten soll, daß in einer späteren Entwicklung diese ganze CPU nicht vielleicht doch noch auf einem - hochkomplexen, aber im Kern immer noch die RISC-Idee repräsentierenden - Chip untergebracht werden könnte. Oder doch wenigstens in nur noch einer kleinen Zahl komplexer Gate-Arrays.
RISC-Rechner mit ihren einfachen Befehlen haben - und das wird von Kritikern immer wieder eingeworfen - nun allerdings den Nachteil, daß wegen der geringen Mächtigkeit der einzelnen Instruktion längere Programme abzuarbeiten sind. Doch hierzu meint Sell von der Firma Ridge, das sei doch zum Beispiel beim Abarbeiten einer Schleife gar kein Problem, denn hier könne ja oft der immer wieder gleiche Befehl iterativ angewandt werden; übrigens habe seine RISC-Maschine aus diesem Grunde auch einen besonderen Ergebnis-Bus, der Resultate direkt vom Ausgang der ALU zurück zu einem ihrer Eingänge und auch zurück zum Registersatz befördere. So werden Daten nicht erst langwierig abgespeichert.
Das Problem der optimierenden Compiler
Kann Sell diesen einen kritischen Einwand somit wenigstens teilweise ausräumen, so ist ein anderer Aspekt, den DV-Fachleute auf Befragen hervorheben, sicherlich wichtiger. Sie kritisieren nämlich, jede RISC-Maschine könne doch eigentlich nur so gut sein wie ihr Compiler - und gerade wegen der Simplizität des einzelnen RISC-Befehls brauche man hier nun bestens optimierende Compiler, die "absolut keine Optimierungsgelegenheit übersehen. Solche aber fehlten bislang, und: "Genau daran sind alle kommerziellen RISC-Maschinen bisher ja auch gescheitert!"
Zwar, so die bösen Kritiker weiter könne man "mit handgetunten Assembler-Programmen" schon mal die Leistungen erzielen, die die RISC-Idee verspreche, und solche mühsam optimierten Programme liegen wohl auch einigen der Benchmarks zugrunde, die gern publiziert werden. Aber heute schreibe doch kaum jemand mehr komplexen Assembler-Code, auch nicht im immer noch vergleichsweise komfortablen und mit mächtigen Befehlen ausgestattetes Assembler herkömmlicher Prozessoren. Wie da erst im viel mühsameren Schritt-für-Schritt-Assembler eines auf magere Elementarbefehle reduzierten RISC-Rechners?
Man kann angesichts solcher Einwände also nur einmal mehr hoffen, die Zukunft werde klären, wer endgültig recht behalten wird: Die sich immer lauter zu Wort meldenden RISC-Protagonisten - oder die notorischen Skeptiker, für die RISC-Maschinen allenfalls für bestimmte Anwendungsnischen interessant" sind: für Nischen, bei denen man zufrieden ist, einen Compiler für bloß eine Sprache - und auch da vielleicht nur für einen Subset dieser Sprache - parat zu haben.
Diese Nörgler verstehen es aber auch, Glykol in den Wein jener zu schütten, für die RISC-Elemente so etwas wie die idealen Bausteine fehlertoleranter Mehrrechnerkonzepte sind. Indes - wer weiß: Vielleicht haben die Freunde der RISC-Maschinen insgeheim schon längst Mittel und Wege gefunden, auch diese hier knapp skizzierten Probleme zu überwinden und überraschen uns alle schon bald mit Rechnern, die jedermann nur noch staunen machen . . .