Rechner herkömmlicher Architektur besitzen einen komplexen internen Instruktionssatz. Dieser verhindert, daß die technischen Möglichkeiten heutiger Halbleitertechnik voll zum Tragen kommen. Erst die Einführung eines reduzierten Befehlssatzes gibt die Leistungsfähigkeit der Hardware an den Benutzer weiter.
Die Entwicklung der Minicomputer hat in den letzten Jahren enorme Fortschritte gemacht. Heute sind Super-Minicomputer auf dem Markt, die selbst manche Großrechenanlage leistungsmäßig weit hinter sich lassen. Im Zusammenhang mit diesem Trend macht in jüngster Zeit der Begriff des "Reduced Instruction Set Computer (RISC)" von sich reden.
In der COMPUTERWOCHE vom 23. August 1985 wurden die Entwicklung sowie die globale Arbeitsweise dieser Rechnerarchitektur aufgezeigt. Am Beispiel der Ridge 32, die in der Bundesrepublik Deutschland von der Firma Honeywell Bull unter der Bezeichnung Bull SPS 9 angeboten wird, sollen die technischen Daten dargestellt werden, die der RISC-Architektur zugrunde liegen. Diesem Rechner für technisch-wissenschaftliche Anwendungen gilt insofern besondere Aufmerksamkeit, da es sich hierbei um die erste auf dem Markt angebotene Maschine handelt, in der das RlSC-Konzept verwirklicht ist.
Die Fortentwicklung der höheren Programmiersprachen (HLL) mit der dort implementierten Fülle an Möglichkeiten für den Anwender führte zu dem Bestreben, die Befehle von seiten der CPU aus hardwaremäßig möglichst gut zu unterstützen. Das Ziel bestand darin, nach dem Kompilieren des Quellcodes einen Maschinencode zu erhalten, der eine schnelle Programmausführung liefert. Als Lösungsweg kristallisierte sich bald der Aufbau relativ komplizierter Befehle innerhalb der CPU heraus. Es handelte sich dabei zum Teil um Eins-zu-eins-Abbildungen der Hochsprachenbefehle auf Maschinenebene. Der dazu notwendige Aufwand in der Schaltungslogik ließ die Zahl der Bauelemente innerhalb der CPU enorm anwachsen. Dennoch erbrachten die parallel laufenden Fortschritte auf dem Gebiet der Integrationstechnik kürzere Zykluszeiten innerhalb der CPU und somit höhere Rechengeschwindigkeiten.
Das Streben nach einer besseren Ausnutzung der vorhandenen technischen Möglichkeiten mündete in der Überlegung, sich innerhalb der CPU auf ein Minimum an Instruktionen und damit einen möglichst geringen Hardware-Aufwand zu beschränken. Der Gedanke der RISC-Architektur war geboren.
Es hat sich gezeigt, daß der Einsatz der RISC-Architektur die Bearbeitungsgeschwindigkeit in der Tat erheblich steigert. Während die beschriebene CPU eine Maximalleistung von 8 Mips ermöglicht, ergibt sich für CAD-Anwendungen zum Beispiel im Bereich der Netzwerkentflechtung ein Wert von rund vier Mips. Dieses Ergebnis liegt weit besser, als es bei vergleichbaren Maschinen mit CISC- (Complex Instruction Set Computer-)Architektur bisher möglich war.
Was sind nun die Besonderheiten von RISC? Innerhalb der CPU wird ein begrenzter Grundbefehlssatz, 83 Instruktionen umfassend, verwendet. Außer den Befehlen "load" und "store", die die einzigen Speicherzugriffe darstellen, sind alle übrigen als sehr schnelle Register-to-Register-Instruktionen ausgeführt. Dabei wird ein einheitliches Befehlsformat verwendet, in dem acht Bits für den Operationscode zur Verfügung stehen. Dieser dient der eindeutigen Charakterisierung der Instruktion. Über die dadurch spezifizierte Adresse erfolgt der Zugriff auf die in einem ROM abgelegte Maschinendarstellung des Befehls, die so in den Arbeitsbereich geladen wird. Außerdem wird durch den Operationscode der Instruktionstyp und die Art der Adressierung (direkt oder indirekt) gekennzeichnet. Die folgenden acht Bits enthalten die Nummern der Register (vier Bits pro Registerfile entsprechend Registernummer 0 bis 15), auf deren Inhalt der Befehl wirken soll.
Bei Befehlen mit Speicherzugriff erweitert sich das Format um die Angabe des Displacements auf die volle Wortlänge von 32 Bits.
Da mit der Dimensionierung des Operationscodes genügend Bits zur eindeutigen Beschreibung der Befehle vorhanden sind, macht der skizzierte Aufbau die Interpretation des Operationscodes und die entsprechende Steuerung der ROM-Zugriffe überflüssig. Damit reduziert sich insgesamt der Aufwand zum Aufbau der Befehle auf Maschinenebene erheblich. Gegenüber den derzeitigen 32-Bit-Konzepten auf Mikroprozessorbasis ergibt sich bei dem beschriebenen Rechner eine stark vereinfachte CPU mit einem Minimum an digitalen Bauelementen bei gleichzeitig gesteigerter Leistungsfähigkeit.
Die Bearbeitung eines Befehlssignales innerhalb eines Bauelements benötigt eine bauteilespezifische minimale Ausführungszeit, die aus physikalisch-technischen Gründen (Aufbau und Anordnung der Kristallstrukturen im Halbleiterelement) nicht unterschritten werden darf. Weiterhin kann ein Signal erst verarbeitet werden, wenn es am Eingang des Bauelements anliegt. Damit wird eine Minimalbearbeitungszeit (Maximaltaktfrequenz) pro Signal und Baugruppe definiert, die aus Sicherheitsgründen (zum Beispiel Berücksichtigung der Alterungsprozesse der Bauteile, Berücksichtigung der thermischen Stabilität der Schaltung) nicht unterschritten (überschritten) werden darf. Durch die Verkleinerung der Baugruppen wird die Signallaufzeit in den Baugruppen insgesamt geringer, so daß die CPU mit einer höheren Frequenz getaktet werden kann. Bei den SPS9-Rechnern ergibt sich damit eine Zykluszeit von 125 Nanosekunden.
Die den Umfang des Grundbefehlssatzes überschreitender Instruktionen werden als Sequenzen von Grundbefehlen realisiert:, die innerhalb der CPU wie Subroutinen behandelt werden. Dies ist für rund 10 Prozent der CISC-Befehle eines technisch-wissenschaftlichen Programms erforderlich. Durch das Arbeiten mit Routinen erhöht sich zwar die Zahl der von der CPU auszuführenden Befehle, aber durch die Optimierung vieler Grundbefehle auf eine Ausführungszeit von einem einzigen Zyklus ergibt sich ein Zeitgewinn.
Zeitgewinn durch Optimierung und Pipelining
Die nach außen wirksame Ausführungsgeschwindigkeit von einem Befehl pro Zyklus (bei 8 Mips) kommt durch die Anwendung des Pipelining-Prinzips zustande. In herkömmlichen Konzepten werden die Befehle sequentiell abgearbeitet, so daß erst eine neue Instruktion begonnen werden kann, nachdem die vorhergehende beendet worden ist. Das Pipelining läßt dagegen eine teilweise überlappende Verarbeitung zu. In jedem Zyklus wird ein neuer Befehl gestartet, während die vorhergehenden, noch nicht abgeschlossenen Instruktionen weiter bearbeitet werden. Auf Befehlsebene wird mit einem vierstufigen Pipelining operiert. Dies ist im allgemeinen für HLL-Programme optimal.
Integer-Addition und -Subtraktion sowie logische Operationen auf Registerebene benötigen nur eine Ausführungszeit von einem Zyklus. Alle übrigen Instruktionen machen mehr als einen Zyklus erforderlich, so daß in der entstehenden Pipeline zwangsläufig nicht alle 125 Nanosekunden ein neuer Befehl gestartet werden kann. Dies ist zum Beispiel bei Speicherzugriffen (bei SPS 9: "load" 500 Nanosekunden, "store" 375 Nanosekunden Ausführungszeit) und Ein-/Ausgabe-Operationen der Fall und führt zu der oben genannten Bearbeitungsgeschwindigkeit für technisch-wissenschaftliche Anwenderprogramme von etwa vier Mips.
Unnötige Zugriffe lassen sich vermeiden
Unnötige Speicherzugriffe, verursacht durch das Auslagern von Registerinhalten in den Arbeitsspeicherbereich, werden dadurch vermieden, daß zum einen eine genügend große Anzahl von Registern zur Verfügung steht, zum anderen von seiten des Betriebssystems her versucht wird, die noch benötigten Werte möglichst lange im Registerbereich zu halten. Der Rechner ist dafür mit insgesamt 32 Registern von 32 Bit Länge ausgerüstet, wovon 16 ausschließlich für Zugriffe vom Betriebssystem aus reserviert sind.
Das Benutzerprogramm hat Zugriff auf die restlichen 16 Register. Hier werden die aktuellen, für die Ausführung notwendigen Programmschritte und Indizes abgelegt. Das Arbeiten auf Registerebene bringt für die Befehlsausführung erhebliche Zeitvorteile mit sich, da die Register über einen schnellen Bus angeschlossen sind. Somit stellen Register das Speichermedium mit der kürzesten Zugriffszeit dar.
Neben der parallelen Ausführung der Befehle im Pipelining, möglichst ausschließlich auf Registerebene, ist die Vorbereitung der Instruktionen für die Geschwindigkeit der Maschine von entscheidender Bedeutung. Dazu enthält der Rechner einen entsprechend großen Instruction Cache, der speziell für die Beschleunigung der Ausführung von Loops konzipiert wurde. Die den Loop beinhaltenden Befehle werden in
den Cache hineingeladen und ausschließlich dort bearbeitet. Für Programme, bei denen es entscheidend auf die Laufzeit ankommt, bringt dies erhebliche Zeitgewinne.
Weiter wurde eine Instruction Prefetch Unit in Verbindung mit einer Branch Prediction Unit installiert. Die Instruction Prefetch Unit ist in der Lage, bis zu zwei Befehle im voraus aus der Instruktions-Sequenz zu laden, während der aktuelle Befehl ausgeführt wird. Damit stehen für den Prozessor ständig genügend Aufgaben auf Abruf bereit, so daß kein Leerlauf und somit auch kein Zeitverlust durch das Holen von Befehlen aus dem Speicherbereich entstehen. Es ist also sichergestellt, daß die Pipeline ständig optimal beschickt ist.
Die Branch Prediction Unit wird aktiv, sobald während des Ladevorgangs der Befehle aus dem Speicherbereich ein Sprungbefehl gefunden wird. Wichtig ist vorherzusagen, zu welcher Adresse in der Befehlssequenz verzweigt wird, um den nächsten Befehl direkt von dort holen zu können. Eine solche Vorgehensweise vermeidet die bei herkömmlichen Konzepten üblichen Zeitverluste bei Sprüngen. Bei unbedingten Sprüngen ermittelt die Branch Prediction Unit unmittelbar die Sprungadresse und teilt diese der Instruction Prefetch Unit mit. Im Falle eines bedingten Sprunges wird in heuristischer Form das Ergebnis der Bedingung ermittelt. So ist ebenfalls eine Sprungadresse bekannt, an der voraussichtlich weitergearbeitet wird. In rund 90 Prozent der Fälle ist die Vorhersage richtig, so daß auch hier keine zeitlichen Verzögerungen durch den Sprung entstehen. Andernfalls muß die Pipeline geräumt werden, da sie schon Befehle aus der Sequenz, beginnend mit der vorausgesagten, aber falschen Sprungadresse enthält. Gleichzeitig werden die Instruktionen von der richtigen Adresse geladen, und die Pipeline wird neu beschickt.
Die beschriebene RISC-Architektur mit der vorausschauenden Behandlung des Befehlsstromes verlagert die Aktivitäten in starkem Maße aus der Speicher- in die Registerebene. Dies zeigt folgende Gegenüberstellung sehr deutlich:
durchschnittliches Benutzerprogramm CISC RISC
Speicherzugriffe 30 %-50 % < 20 %
Register-to-Register-lnstruktionen ca 20 % > 50 %
Preis/Leistungs-Verhältnis der RlSC-Architektur
Vergleichende Benchmarks mit dem Megamini SPS 9 von Bull (baugleich mit der Ridge 32) haben gezeigt, daß die RISC-Architektur die Ausführungszeit von Programmen je nach Anwendungsfall um bis zu 90 Prozent reduziert. Dabei werden zum Vergleich teilweise Maschinen herangezogen, deren Preis den der SPS 9 bei weitem übersteigt, so das sich insgesamt durch den Einsatz des beschriebenen Konzeptes ein günstiges Preis/Leistungsverhältnis ergibt. Mit. der RISC-Architektur wird somit der technologische Fortschritt auf dem Gebiet der Halbleiterentwicklung und -herstellung voll an, den Benutzer des Rechners weitergegeben und nicht durch eine konventionelle Rechnerarchitektur zum Teil zunichte gemacht.
Dipl.-Ing. (TH) Wolfgang Zimmer ist Systemberater in der Abteilung "Scientific Processing Systems" in der Honeywell Bull AG, Köln.
Literatur
/1/ Basart, E.; Folger, D., Shellooe, B: . Pipelining And New OS Boost Mini To 8 MIPS
/2/ Carlyle, R. E.: RISC-Y Business?
/3/ Foderaro, J. K.; Van Dyke, K. S.; Patterson, D. A.: Running RlSCs
/4/ Foley, P.: Apple Benchmarks of the VLSI Technology Design Tools
/5/ Hopkins, W. C.: HLLDA defies RISC: Thoughts on RlSCs, CICSs and HLLDAs
/8/ Lunde, A.: Empirial Evaluation of Some Features of Instruction Set Processor Architectures
/7/ Markoff, J.: RlSC Chips
/8/ Ohr, s.: RISC Machines
/9/ Patterson, D. A.: Reduced Instruction Set Computers
/10/ Patterson, D. A.: The Case For The Reduced Instruction Set Computer
/11/ Patterson, D. A.: Reduced Instruction Set VLSI Computer
/12/ Patterson, D. A.: RISC Assessment: A High Level Language Experiment
/13/ Patterson, D. A.: RISC Watch
/14/ Tamir, Y.: Strategies For Managing the Register File in RISC
/15/ Zimmer, W.: Vergleichende Benchmarks