Daß RISC-Mikroprozessoren wegen ihrer hohen Leistung ideal als Prozessoren für Hochleistungs-Workstations geeignet sind, ist heute allgemein bekannt. Multiprozessor-Systeme mit RISC-Mikroprozessoren sind in den Leistungsbereich der klassischen Superrechner mit ihrer hochkomplexen Technologie und Architektur eingebrochen.
Beim Vergleich von RISC- mit Standard-CISC-Mikroprozessoren geht man von leistungssteigernden Faktoren zwischen zwei und fünf aus. Entsprechende Workstations der Firmen SUN, DEC, PCS etc. haben sich schon lange auf dem Markt durchgesetzt, neue Vertreter, beispielsweise das IBM System/6000, werden derzeit eingeführt Nunmehr erschließen die RISC-Mikroprozessoren jedoch auch zwei weitere, bisher durch andere Prozessortypen dominierte Märkte.
Spätestens seit der Ankündigung des iPSC/860 - der Version des Hypercube-Multiprozessors auf Basis des RISC-Mikroprozessors 860 von Intel mit nomineller Maximalleistung von 7,6 Gflops - reichen RISC-basierte Systeme in die Domäne von Supercomputern. Auch die Firma Alliant hat mit dem Sunrise-Multiprozessor mit maximal 28 Prozessoren einen sehr leistungsfähigen speichergekoppelten Multiprozessor mit Unix-Betriebssystem vorgestellt. Wegen der spektakulären Leistungszahlen sind diese Vorstellungen von Höchstleistungsarchitekturen auf der Basis von Standard-RISC-Mikroprozessoren in der Öffentlichkeit beachtet worden.
Weit weniger spektakulär, für die Hersteller von RISC-Architekturen aber wesentlich lukrativer, da hier hohe Stückzahlen anfallen, ist der zunehmende Einsatz von RISC-Architekturen für Embedded Controller-Anwendungen. RISC-Mikroprozessoren als Steuerprozessoren für Laserdrucker, Grafikbildschirme, Anwendungen in der Telekommunikation, Robotersteuerung und Produktionsautomatisierung ersetzen zunehmend die früher verwendeten wesentlich aufwendigeren mikroprogrammierbaren Bitslice-Lösungen. Sie sind überall dort notwendig, wo die Leistungsfähigkeit von CISC-Mikroprozessorsystemen nicht ausreicht.
Architekturentwicklung: Der Weg von CISC zu RISC
Seitdem Mitte der 60er Jahre die Software als der wesentliche Kostenfaktor bei Rechneranwendungen erkannt wurde, ist die Aufwärtskompatibilität auf Binärcode-Ebene eine wesentliche Forderung an kommerziell erfolgreiche Rechnerarchitekturen. Das mit dem IBM-System /360 eingeführte Familienkonzept erlaubt innerhalb einer Rechnerfamilie die Übernahme existierender Objektprogramme von einem Rechnermodell auf das nächste ohne neue Programmierung beziehungsweise Kompilierung. Einmal getätigte Investitionen für Software bleiben dem Anwender damit auch beim leistungsbedingten Modellwechsel erhalten.
Voraussetzung für die Aufwärtskompatibilität im Familienkonzept war die logische Trennung des Entwurfs von Maschinen-Befehlssätzen, die innerhalb einer Rechnerfamilie konstant gehalten werden müssen, bestenfalls erweitert werden dürfen, von der Implementierung des Maschinen-Befehlssätzes und der Realisierung. Unter Implementierung versteht man dabei Details der Rechnerorganisation, wie Gestaltung der Speicherhierarchie (Register, Cache-Speicher, Hauptspeicher, Hintergrundspeicher), des Leitwerks (mikroprogrammiert oder festverdrahtet), der physikalischen Wortlänge der Datenpfade etc.
Die Realisierung ist der physikalische Aufbau der Elemente eines Rechners. Durch das Familienkonzept wurden beispielsweise innerhalb der IBM-Familie die Systeme /360 und /370 für den gleichen Maschinen-Befehlssatz durch unterschiedliche Implementierungen und Realisierungen Modelle bereitgestellt, die sich um Leistungsfaktoren von mehr als 1000 unterscheiden.
Oft wurde im Zusammenhang mit der Modellpolitik der Hersteller auf das Gesetz von Grosch verwiesen, das besagt innerhalb der Rechnerfamilien würde die angebotene Leistung der Modelle in etwa quadratisch mit den Kosten steigen. Das Auseinanderfallen von fester Maschinen-Befehlsschnittstelle aber variierenden Implementierungen und Realisierungen wurde technisch durch die Mikroprogrammierung als Implementierung des Leitwerks von Rechnern ermöglicht.
Die Mikroprogrammierung erlaubt die Generierung der benötigten Steuersignale für die Hardware eines Rechners auf strukturierte Weise. Für jedes Taktintervall definiert eine Mikroinstruktion eines Mikroprogramms alle benötigten Steuersignale für die gesamte Rechnerhardware. Mikroprogramme sind meist verzweigte Programmstrukturen, die in den Mikro-Programmspeichern der Prozessoren abgelegt sind.
Auch die Mikroprogrammierung als Implementierungstechnik der Leitwerke hatte ihre realisierungstechnische Voraussetzung: die Entwicklung der Halbleitertechnologie war zu diesem Zeitpunkt soweit fortgeschritten, daß Speicher-Chips mit wenigen Kbit Speicherkapazität als Grundbausteine für Mikro-Programmspeicher kostengünstig und platzsparend zur Verfügung gestellt werden konnten, die Hauptspeicher der Rechnersysteme mußten dagegen aus Kapazitäts- und Kosten-Gründen noch in Kernspeichertechnologie realisiert werden.
Die Zugriffszeit der Mikro-Programmspeicher lag daher aus technischen Gründen etwa um einen Faktor 10 unter derjenigen der Hauptspeicher, es ergab sich so ein ideales Leistungsverhältnis zwischen der Ausführungszeit einer Mikroinstruktion und einem Maschinenbefehl. Tatsächlich benötigen die Maschinenbefehle der klassischen Großrechner im Mittel zirka fünf bis zehn Mikroinstruktionen für ihre Ausführung. Wegen der Aufwärtskompatibilität und weil die Mikroprogrammierung eine sehr effiziente Implementierungsebene darstellte, wurden immer neue Befehle in die Maschinen-Befehlssätze integriert. Bald hatten die Prozessoren von Großrechnern als Standard einige hundert Grundbefehle.
Hauptspeicher aus Halbleiterbausteinen
Zwei Faktoren führten Mitte der 70er Jahre zu den Reduced Instruction Set Computers (RISC), die gleichzeitig an den Universitäten Berkeley und Stanford sowie im IBM Forschungslabor in Yorktown Heights entwickelt wurden: Zum eilen erlaubte die Weiterentwicklung der Halbleitertechnologie bald schon die Realisierung von Hauptspeichern mit Halbleiterbausteinen, wodurch der prinzipielle Geschwindigkeitsvorteil der Mikro-Programmspeicher verlorenging. Auch die immer breiter genutzte Implementierungstechnik des Cache-Speichers trug zum Verlust des Leistungsvorteils der Mikroprogrammierung bei.
Zum anderen wurden Rechenanlagen mehr und mehr
mit höheren Programmiersprachen programmiert, die Codegeneratoren der zugehörigen Compiler nutzten aber nur einen sehr geringen Ausschnitt
der riesigen Maschinen-Befehlssätze von RISC-Architekturen.
Es lag also nahe zu fordern, daß RISC-Architekturen nur die von Compilern häufig genutzten Maschinenbefehle umfassen
Die Eigenschaften der RISC-Architekturen
sollten, das diese dafür aber extrem effizient implementiert werden. Daraus leiten sich die bis heute typischen sechs Charakteristika für RISC-Architekturen ab:
1. Einzyklusmaschinenbefehle: Durch Verzicht auf Mikroprogrammierung und Nutzung des Maschinenbefehls-Pipelining als Implementierungsprinzip versuchen RISC-Architekturen einen Wert CPI = 1 (Clocks per Instruction) zu erreichen, superskalare oder VLIW-Architekturen zielen durch Integration mehrerer Rechenwerke in den Prozessorbaustein sogar darauf, einen CPI-Wert zu erreichen. Die Latenzzeit für die Ausführung jedes einzelnen Maschinenbefehls beträgt natürlich dennoch mehr als einen Takt.
2. Load-Store-Architektur: Alle ausführenden Befehle von RISC-Architekturen setzen die Operanden in Registern des Rechenwerks voraus. Lediglich der LOAD- und der STORE-Befehl greifen auf den Hauptspeicher zu. Umfangreiche Registerdateien reduzieren die Anzahl der notwendigen Zugriffe auf den Hauptspeicher, zusätzlich erleichtert die vereinfachte Operanden-Hol-Phase wegen des gleichartigen Zeitverhaltens das Pipelining der Maschinenbefehle und die festverdrahtete Implementierung des Leitwerks.
3. Festverdrahtetes Leitwerk: Die "maßgeschneiderte" Implementierungstechnik des Leitwerks verzichtet auf die Redundanz mikroprogrammierter Leitwerke, bei denen jeder Zugriff auf eine Mikroinstruktion einen zusätzlichen Zugriff auf den Mikro-Programmspeicher notwendig macht.
4. Wenige Maschinenbefehle und Adressierungsarten;
5. horizontales Maschinen-Befehlsformat: Maschinenbefehle haben generell 32 Bit Format und werden auf festen Wortgrenzen abgelegt. Die Dekodierung im Leitwerk wird dadurch vereinfacht und der Zugriff auf den Speicher erleichtert.
6. Verlagerung möglichst vieler Aufgaben in die Übersetzungszeit, optimierende Compiler: Da bei RISC-Architekturen davon ausgegangen wird, daß der Benutzer die Architektur nur vermittelt über den Compiler einer höheren Programmiersprache sieht, sind auf der Maschinen-Befehlsebene unangenehme Eigenschaften der Implementierung und Realisierung teilweise nicht verborgen. Optimierende Compiler können diese Eigenschaften (verzögerte Sprünge, verzögertes Laden und Speichern, Synchronisation des Zugriffs auf Register etc. ) verdecken.
Unterschiede in den Forschungsansätzen
Wenn auch die genannten sechs Charakteristika allen RISC-Architekturen gemeinsam sind, so existieren doch auch einige Unterschiede, die sich bereits in den Forschungsansätzen der Universitäten von Stanford und Berkeley ankündigten. Von Stanford wurden eher extrem einfache Hardwarelösungen favorisiert, dafür besonders ausgefeilte Compilertechnologien angeboten. Demgegenüber war man bei der Forschung in Berkeley davon ausgegangen, daß trotz des Ziels, die Architektur abzuspecken, eine gewiße Hardware-Unterstützung von Funktionen sinnvoll ist.
Flache Registerdatei vs Registerfensterkonzept
Die Unterschiede finden sich heute typischerweise in den folgenden Bereichen:
- Art und Organisation der Registerdateien,
- Organisation der Cache-Speicherstrukturen und
- Bearbeitung von Pipeline-Konflikten und Synchronisation bei 5 nebenläufigen Rechenwerken.
Bezüglich der Register favorisierte man in Stanford eine einfache, "flache" 32-Bit-Registerdatei. Wegen der in moderner Programmiertechnik häufig verwendeten Prozeduraufrufe und -rücksprünge verwendete man in Berkeley dagegen das Registerfenster-Konzept. Es sieht vor, daß beim Prozeduraufruf die zu einer Prozedur gehörigen lokalen Variablen sowie Ein und Ausgabeparameter nicht auf einen Systemkeller im Hauptspeicher abgelegt werden, sondern daß für eine bestimmte Anzahl von Prozeduraufrufen getrennte Registerbänke im Rechenwerk vorhanden sind, so daß beim Prozeduraufruf lediglich von einer Bank auf die nächste umgeschaltet werden muß.
Diese Registerbänke ("Fenster") können dabei überlappt sein, da die Ausgabeparameter der aufrufenden Prozedur in der Regel den Eingabeparametern der aufgerufenen Prozedur entsprechen. An Stelle von Registerfenstern fester Größe kann man in einer kellerartigen Verwaltung sogar Registerfenster variabler Größe überlappt verwalten. Dies setzt natürlich eine gewisse Adressierungsverwaltung in der Hardware voraus führt jedoch zu einer extrem effizienten Nutzung von Registern auf dem Prozessor. RISC-Architekturen nach dem Berkeley-Konzept (Sun Sparc, AMD 29000, i80960) liefern auf dem Rechenwerk einige hundert Register. Die Standford-Variante (Mips, Clipper, Motorola 88000, HP Precision Architecture, IBM) liefern dagegen teilweise hochoptimierende Compiler, die sogar Variablen über Prozedurgrenzen hinweg in einer Registerdatei abbilden.
Die Cache-Organisation im Stanford-Ansatz setzt ursprünglich einen gemeinsamen Cache-Speicher für Daten und Instruktionen voraus, der bei der hohen Taktfrequenz der RISC-Prozessoren natürlich extrem leistungsfähig sein muß. Berkeley-Architekturen dagegen arbeiten meist mit getrennten Cache-Speichern für Instruktionen und Daten (Harvard Architektur), bieten auf dem Prozessor-Chip meistens noch zusätzliche Spezial-Cache-Speicher, wie Befehlspuffer, Sprungziel-Caches für die Auflösung von Pipeline Konflikten bei Sprüngen etc.
Während die Stanford-Variante Mips (Micro Processor without interlocked Pipeline Stages) schon im Namen ankündigt, daß die Mikroprozessor-Hardware keine Vorkehrung für die Beseitigung von Pipeline-Konflikten auf Maschinen-Befehlsebene bereitstellt und einen Compiler voraussetzt, der bei solchen Konflikten explizite No-Operations zur Auflösung generiert, sehen fast alle anderen RISC-Architekturen Hardwaremaßnahmen vor, die eine eventuelle fehlerhafte Programmierung auch auf Maschinen-Befehlsebene unmöglich machen.
So ist beispielsweise die Erkennung von Datenabhängigkeiten in unmittelbar aufeinander folgenden Maschinenbefehlen durch das Score-Boarding implementiert. Jedes Register in der Registerdatei erhält ein zusätzliches Bit, das gesetzt wird, wenn das Register im Adreßfeld eines Maschinenbefehls auftaucht.
Das Register bleibt dann für weitere Zugriffe so lang gesperrt, bis das Ergebnis aus dem entsprechenden Befehl in das Register explizit geladen wird.
Mit dieser Technik wird auch das asynchrone Verhalten von Ladebefehlen aus dem Speicher unterstützt und die Synchronisation zwischen möglicherweise vorhandenen nebenläufig arbeitenden Mehrfach-Rechenwerken. Man kann heute die RISC-Architekturen in drei Generationen einteilen:
- RISC-Architekturen der ersten Generation waren die ersten Entwürfe an den Universitäten Stanford (Mips) und Berkeley (RISC I und RISC II, sowie die Nachfolgesysteme SPUR und SOAR) sowie bei IBM (801). Die Komplexität der Prozessor-Chips war gering, im Bereich von 20 000 bis 100 000 Transistorfunktionen.
- Die RISC-Prozessoren der zweiten Generation haben bereits deutlich leistungsfähigere Befehlssätze, die meist Gleitkomma-Operationen beinhalten, darüber hinaus werden bereits zusätzliche Funktionen wie Memory Management Units auf den Prozessor-Chip integriert Typische Vertreter dieser Klasse mit 300 000 bis einer Million Transistorfunktionen sind Clipper, 29000, Sparc, Mips R2000 und R3000, 88000, HP PA, Inmos Transputer.
- RISC-Architekturen der dritten Generation sind vor allem durch höheren Chip-internen Parallelismus charakterisiert Systeme wie IBM/6000, i860, i960CA unter anderem bieten auf einem Chip mehrere Rechenwerke, die nebeneinander mehrere Maschinenbefehle aus einem Befehlsstrom auszuführen gestatten. Man spricht von superskalaren Architekturen oder VLIW-Technik (Very Long Instruction Word), CPI-Werte von deutlich < 1 werden angestrebt.
Fast alle Hersteller von RISC-Technologien bieten ihre Produkte heute in CMOS-Technologie an. Die Taktfrequenzen im Bereich von 33 Megahertz gelten als Stand der Technik, Ausnahmen gehen bis 50 Megahertz. In Einzelfällen werden Multi-Chipversionen auch in aufwendigeren Technologien angeboten beziehungsweise angekündigt. ECL-Versionen liegen dabei im Bereich bis l00 Megahertz, bei Gallium-Arsenid sind sogar 200 Megahertz erreichbar.
Der Trend zum Parallelismus im Bereich der RISC-Architekturen wird sicher noch zunehmen. Da der Kern eines RISC-Prozessors nur größenordnungsmäßig 50 000 Transistorfunktionen benötigt, die Halbleiter-Technologie aber in der Lage ist, bei CMOS-Bausteinen bereits über eine Million Transistorfunktionen auf einen Baustein zu integrieren, liegt es nahe, zusätzliche Funktionen mit einzubauen.
Neben der VLIW-Technik mit mehreren Rechenwerken, die ein Leitwerk steuert, wird man in Zukunft sicher auch Multiprozessoren auf einem Chip finden. Darüber hinaus sollen aber auch zunehmend Speicherelemente (Cache-Speicher für Instruktionen und Daten) und Kommunikationspuffer für parallele Systeme (wie beim Transputer) untergebracht werden.
Mit der deutlich gesteigerten Leistung der Prozessoren muß aber auch gesteigerte Leistung bei Speichern und Bussen einhergehen.
Schon heute ergreift man aufwendige Maßnahmen zur Erhöhung der Transferleistung zwischen Speicher und Prozessor-Chip etwa durch Verbreiterung der Datenbusse auf doppelte Wortbreite, Unterstützung des Blocktransfers, Pipelining von Busaufträgen und Trennung in Datenpfade für Instruktionen und Daten.
Im Bereich der Speicher wird die benötigte Leistung nur durch Auftrennung in parallele Bänke, Nutzung spezieller Zugriffsarten (Static Column Mode), Erhöhung der Stufen der Speicherhierarchie durch mehrstufige Cache-Speicher auf und außerhalb des Chips, sowie durch Spezial-Cache-Speicher wie Sprungzielkeller und ebenfalls Trennung nach Instruktion und Daten möglich sein.
Für den Nutzer von RISC-Architekturen stellt sich mit dieser Verkomplizierung der Rechnerarchitektur in jedem Fall die Frage nach der Verfügbarkeit von geeigneten Entwurfswerkzeugen bei Hardware und Software.
Der Zwang zu Kompatibilität
RISC-Architekturen werden in Zukunft einen wachsenden Marktanteil der Mikroprozessor-Systeme erobern. Der Zwang zur Kompatibilität läßt jedoch auch die CISC-Architekturen nicht verschwinden Vielmehr werden diese versuchen, Beschleunigung zu übernehmen, etwa RISC-Kerne für CISC-Architekturen.
Auf der anderen Seite ist ebenfalls aus Kompatibilitätsgründen in den RISC-Architekturen ein Trend zur Familienbildung zu erwarten, so daß insgesamt in gewisser Weise RISC- und CISC-Eigenschaften zusammenwachsen.
*Professor Arndt Bode lehrt am Lehrstuhl für Rechnertechnik und Rechnerorganisation des Instituts für Informatik an der Technischen Universität München