Von CW-Mitarbeiter Egon Schmidt Immer öfter ist die Vorstellung zu konstatieren, RISC und Unix - also einerseits ein neues Prinzip, Rechner zu bauen, und andererseits das neue und herstellerunabhängige Betriebssystem Unix - hätten zwingend miteinander zu tun. Doch ist dieser Eindruck auch wirklich gerechtfertigt?
Wohl kaum, wie die nähere Beleuchtung dieses gern diskutierten Themas zeigt; denn sobald man sich von der gängigen Kopplung der beiden Welten im Namen der - auf dem Markt nun ja allerdings wirklich sehr prominenten - "Unix-RISC-Workstation" einmal frei macht, verliert die scheinbar unlösbare Bindung sogleich viel von ihrer suggerierten Zwangsläufigkeit. Und was bleibt, ist im wesentlichen die Erkenntnis: RISC bedingt nicht zwingend Unix, und Unix fordert nicht zwingend RISC. Aber viele Unix-Systeme laufen heute doch besonders effizient auf RISC-Konfigurationen, die wiederum besonders stark auf Unix hin orientiert sind.
Zwei tragende Säulen moderner Arbeitsstationen
RISC - dies ist bekanntlich das Kürzel für eine jetzt rund zehn Jahre alte Gattung von Prozessoren, bei denen man auf überflüssige Befehle verzichtet, um die verbliebenen um so rascher bearbeiten zu können; bei denen man den Platz für den sonst üblichen Mikrocode- Speicher lieber für eine große Zahl schneller Register genutzt hat und bei denen schon die modernen, aufwendigen Compiler dafür sorgen, daß die Operationen des Prozessors im allgemeinen mit rasch greifbaren Registerinhalten ausgeführt werden, während nur selten zeitraubende Datenaustausch-Prozeduren mit dem Hauptspeicher fällig sind.
Außerdem ist diesen Prozessoren noch eine Fülle weiterer Feinheiten und Differenzierungen eigen, über die hier leider nicht weiter berichtet werden kann; doch läßt sich dies beispielsweise im CW-Focus vom Dezember 1989 nachlesen.
Unix wiederum ist ein weitgehend herstellerneutral sich entwickelndes Multitasking-Betriebssystem, das die Portierung von Programmen auf Rechner unterschiedlicher Fabrikate besonders leicht machen will. Es stammt aus der 32-Bit-Welt und ist dabei, sich in der EDV immer mehr an Platz zu erobern.
Nun zielt RISC in seiner Grundidee zwar nicht unbedingt auf Unix ab", wie etwa Marketingleiter Gert Haas vom Arbeitsstationen-Hersteller Sun betont, doch falle andererseits auf: "Fast alle erfolgreichen Unix-Rechner arbeiten heute auf RISC-Basis". Was für Haas durchaus schon ein Indiz dafür ist, daß diese Kopplung zweier Techniken ja wohl einen gewissen Sinn haben muß.
Diese Kopplung allerdings ist vielfach wohl auch damit zu erklären, daß die einzelnen Hersteller von RISC-Chips und ganzen RISC-Chipsätzen ihre Produkte oft ganz bewußt auf bestimmte Unix-Varianten hin optimiert - und somit für beste Effizienz im Bearbeiten der Anwenderprogramme gesorgt - haben. "Unsere Sparc-Prozessoren beispielsweise wurden stark auf Unix-System V abgestimmt", bemerkt Haas mit Blick auf deren zahlreiche Registersätze, auf die Architektur und die Verwaltung der Pufferspeicher sowie drittens auf die Art der Anbindung der Koprozessoren; während etwa die RISC-Chips in den Arbeitsstationen des RISC-Miterfinders IBM primär auf dessen hauseigenes Unix-Derivat AIX zielen.
Diese AIX-RISCs haben mit ihren bisher gezeigten Leistungen in der Fachwelt weithin Eindruck gemacht, wie etwa auch Dr. Uwe Kranich vom Chip-Hersteller AMD offen einräumt, denn was jener Hersteller in absehbarer Zeit bei RISC-Arbeitsstationen wohl an Leistung pro Mark zu bieten haben werde, sei "ganz dramatisch". - Auch Kranich sieht in Unix und RISC heute "das Gespann der Zukunft" und führt in diesem Zusammenhang weiterhin ins Feld, daß RISC-Prozessoren einfach flexibler an immer neue Gegebenheiten einer rasch sich wandelnden Welt anpaßbar seien: Weil nämlich dem Programm beziehungweise dem optimierenden Compiler hier viel von dem übertragen werde, was sonst komplizierte und fest verdrahtete Hardware beziehungsweise der auch recht starre Mikrocode ausführe.
So sei beispielsweise Unix "im Zuge großer Änderungen" von einem Swapping-System zu einem mit virtuellem Paging umgebaut worden - und die entsprechenden Speicherverwaltungs-Routinen konnten diesem Schwenk bei verschiedenen RISC-Prozessoren - Dank ihrer Implementierung in Software - viel flexibler angepaßt werden, als bei CISC-Prozessoren mit ihrem starren Konzept und ihrer besonderen Hardware-Speicherverwaltungseinheit (MMU). - Eine Erfahrung, die für viele System-Konstrukteure sicherlich ein weiterer Grund sein dürfte, dem fortlaufend weiter reifenden Unix ebenso leicht mitreifende, flexible Prozessor-Konzepte wie eben RISC an die Seite zu stellen.
Compiler-Teghnik läßt kaum mehr Wünsche offen
Ein wichtiger Schlüssel zum Erzielen hoher Leistung ist gerade bei RISCs mit ihrem großen semantischen Abstand zwischen den anspruchsvollen Befehlen einer modernen Hochsprache wie etwa C einerseits und den simplen Maschinenbefehlen typisiher RISCs andererseits der Compiler. Er muß viel an Optimierungsarbeit leisten, soll am Ende ein vernünftiges Tempo herauskommen, doch geschieht dies in der modernen RISC-Unix-Welt anscheinend auch schon: Kranich weiß, daß man das Produkt eines gut optimierenden Compilers bei typischen Durchschnitts-Programmen selbst bei manueller Nachbearbeitung heute nur noch "um etwa zehn bis 15 Prozent besser" machen kann.
Was gute Compiler bringen können, zeigt Kranich einmal am Beispiel des IBM-Prozessors auf, der "zwar gar nicht soviel Registersätze hat, aber Dank des Compilers und guter Abstimmung auf AIX dennoch eine Superleistung bringt"; sowie anhand der AMD-eigenen Compiler für die RISC-Chips der Serie 29000. Diese "halten Daten so lange wie möglich im schnellen Register-Stack", "wissen" sozusagen, daß "Zugriffe auf den Speicher bei diesem Prozessor gleichzeitig zur Ausführung anderer Befehle erfolgen" können und sich damit "als zeitsparende Parallel-Operationen einplanen lassen", und optimieren insbesondere "auf Laufzeitverkürzung hin"; denn speziell hier liege heute der Schlüssel zu hoher Gesamt-Systemleistung. Während beispielsweise Dinge wie Kontext-Umschaltungen etc., von deren Tempo insbesondere Verkäufer manchmal ebenso gern wie irrig schwärmen, bei RISCs per Saldo nicht sehr ins Gewicht fallen sollen.
Die Bedeutung guter, optimierender Compiler ist für Prof. Georg Färber von der TU München allerdings vor allem mit Blick auf "das Interface zur Programmiersprache" wie etwa C oder Fortran zu sehen, weniger indes mit Blick auf das (Unix-) Betriebssystem. Denn während der Compiler, so der Wissenschaftler, mit dem Betriebssystem ja "im Grunde gar nichts zu tun hat", sieht man hier mal von einer ganz speziellen Ausnahme ab, spielen beispielsweise die eingebauten Scheduler, die die optimale Nutzung des Maschinen-Befehlssatzes sicherstellen, für das schnelle Abarbeiten der Anwenderprogramme zweifellos ein wichtige Rolle. Doch dies wiederum, so rückt Färber so manch vermischte Vorstellung zurecht, hat eigentlich nichts mit RISC als solchem zu tun; denn auch gute CISC-Compiler haben natürlich längst auch gute Scheduler.
Im Bereich der RISC-Prozessoren meint Färber, die besten Compiler heute wohl rund um die bekannten Mips-Prozessoren orten zu können; zumal dort Techniken offeriert würden, die ein mehrstufiges Umschalten der Compiler erlauben. Wodurch sie je nach Bedarf teils besonders schnell, aber halt nicht mit allerletzter Optimierung arbeiteten, teils aber auch maximal optimierend, aber dann eben auch sehr zeitraubend.
Zwei Königskinder haben sich gefunden
Und die große Ausnahme, von der Färber vorhin sprach? - Das ist jener Bereich, in dem ein Compiler erstmals ein in C geschriebenes - neues - Unix auf einen - neuen - RISC-Prozessor portieren soll. Denn hier spiele die Güte oder besser Effizienz dieses Übersetzers naturgemäß eine ganz entscheidende Rolle.
Doch zurück zum Verhältnis RISC-Unix. Diese beiden Welten haben für Färber zunächst vor allem gemein, daß sie "heutzutage jede für sich die jeweils beste Leistung" bieten, während ansonsten keine zwingende Kopplung zwischen Unix und RISC behauptet werden könne; denn auch CISC-Unix-Systeme könnten durchaus sinnvolle Lösungen darstellen. Zumal mit Blick auf Unix weniger Fragen wie die des RISC-Befehlssatzes und dergleichen eine Rolle spielten, sondern vielmehr Aspekte wie die der effizienten Speicherverwaltung vorn stünden; denn beispielsweise letztere würden "die Unix-Leistung ja direkt tangieren".
Außerdem haben die beiden Welten RISC und Unix auf einer weit höheren Ebene dann aber doch wieder eng miteinander zu tun, wie Färber mit Blick auf deren jeweilige historische Entwicklung in Erinnerung zu rufen weiß.
Denn in einer scheinbar rundum abgeschlossenen und nicht gerade nach Neuem gierenden Welt wie der der MVS-, VMS-, BS-2000- und anderen Betriebssysteme strikt nach Hersteller-Eigenrezept sei für die brandneuen RISC-Prozessoren der ersten Generation das schon damals offene - und auf der Spielwiese der Akademiker weit verbreitete - Unix vor rund einem Jahrzent "als portables System doch eigentlich die einzige Chance gewesen", auf dem Markt Furore zu machen.
So daß sich mit RISC hier und Unix da sozusagen zwei etwas spät geborene Königskinder gefunden haben; die sahen: Nu(...)vereint in einer Quasi-Ehe kann man sich wechselseitig stützen und so versuchen, doch noch eine steile Erfolgsbahn einzuschlagen. Was gleich auch erklärt, warum die einzelnen RISC-Prozessoren - um hier nochmals an Haas zu erinnern - eben auch ganz gezielt auf bestimmte Unix-Varianten hin, entwickelt und optimiert worden sind.
Unix für Benchmarktests
Dazu weiß mit Blick auf die Geschichte der letzten zehn, fünfzehn Jahre auch Haas' Sun-Kollege Reinhard Herrmann ein paar Ergänzungen beizusteuern. Denn rückblickend auf die Frühzeit etwa der GUUG (German Unix Users Group) erinnert er sich noch gut an jene fröhlichen Tage, da man im Kreis der allerersten Unix-Adepten gern eben dieses Unix benutzte, um immer neue Prozessoren beziehungsweise Computer kritischen Benchmarks zu unterziehen. Was per Saldo dazu führte, daß eifrige Entwickler in aller Welt immer neue Prozessor- und Systemkonzepte entwarfen, die speziell auf die verschiedenen Unix-Varianten hin ausgelegt waren - und die dann mal aus diesem und mal aus jenem Versuchslauf der Freaks als Sieger hervorgingen. Was wiederum die Entwicklung der ganzen RISC-Unix-Gruppierungen wie auch der einzelnen, Unix-optimierten RISC-Prozessoren "stark befördert" zu haben scheint.
Wie gut diese Abstimmung RISC-Unix vielfach im Detail funktioniert, kann Hermann schön am Exempel seines Sparc-Prozessors vorführen, der ja - laut Haas - auf System V abgestimmt sein soll und der damit das Problem hat, daß bei Unix "relativ viele Traps, also Sprünge ins Betriebssystem, vorkommen". Denn hier kann der Sparc-Prozessor nun ja einfach um je ein Register-Fenster weiterschalten - und dabei überdies eine Vorkehrung nutzen, die die Ausgabe-Register des Fensters davor automatisch zu Eingabe-Registern des neuen Fensters macht. So das mit minimaler Verzögerung kontextnah weitergearbeitet werden kann.
Ähnlich effizient arbeitet so ein RISC nach Sun-Rezept aber auch bei Unterprogrammaufrufen, also den bekannten und in praktisch allen Hochsprachen vorfindbaren Calls, erläutert Herrmann. Denn auch hier wird bei Sun-Sparc einfach ein Fenster weitergeschaltet und quasi die Deklarierung der Ein- und der Ausgaberegister vertauscht. Mit ebenfalls wieder der Folge, daß - wie übrigens auch Färber oder Kranich bereitwillig bestätigen - Calls selbst in mehrstufigen Ketten für RISC-Prozessoren eine schnell bewältigbare Angelegenheit darstellen.
Wenn's pressiert, dann RISC als Mittel der Wahl
Daß Unix dennoch nicht unbedingt mit RISC verbandelt werden muß, um ein leistungsfähiges Gesamtsystem zu günstigen Kosten auf den Markt bringen zu können - dies betont naheliegenderweise natürlich auch Roland Roth von Motorola; einem klassischen CISC-Hersteller, der jetzt aber auch eine RISC-Linie - vom Typ 88000 - im Programm hat. Doch wenn Roth auch meint, ein moderner CISC wie etwa der hauseigene 68040 leiste ja wohl schon mehr als so manch bekannter RISC, so zeigt intensives Nachfragen dann doch alsbald, wohin die Reise wohl gehen dürfte: nämlich im oberen Leistunsbereich eindeutig zu RISC. Während in jenem Segment, in dem es primär auf niedrige Kosten pro MIPS ankommt, die eingefahrenen Motorola-CISCs noch weiterhin ihren Platz finden könnten.
So verheißt Roth beispielsweise bei den neuen 88000er-RISCs seines Hauses, deren heutige Leistung von - grob umrissen - 20 MIPS werde "in der zweiten Generation wohl schon auf 60 bis 100 und in der dritten dann auf 200 bis 300 MIPS steigen"; also überaus rasant; während die CISC-Linie "wohl kaum solche Sprünge versprechen könne. Und allein von daher scheine es ihm doch wohl ratsam, ein Unternehmen, das eine "neue Linie von Unix-Rechnern konzipieren möchte, sollte sich auf einen Prozessor konzentrieren, der langfristig ein großes Potential bietet".
Doch für RISC spricht laut Roth dabei nicht nur, daß diese Technik im Gegensatz zur - langfristig eher auf kostengünstige Systeme zielenden - CISC-Bauweise der ausgesprochene Hochleistungs-Weg zu sein scheint; denn für RISC spreche auch, daß die rasch größer werdende Welt der modernen, schnellen Unix-Parallelrechner beziehungsweise Parallel-Supercomputer technischwissenschaftlicher Orientierung hier einen idealen Chip vorfinden dürfte. Denn mit RISC sei es dank der knappen, einheitlichen Befehlsformate und anderer, ausgesprochen RISC-typischer Eigenheiten wesentlich leichter als mit CISC, Mehrprozessor-Strukturen hoher Leistung aufzubauen; und zwar Strukturen, bei denen Unix dann überdies verteilt im ganzen System gefahren wird. Bei denen also nicht etwa, wie noch bei herkömmlichen Lösungen, Unix einfach nur einem einzigen der Prozessoren übertragen wird - während die übrigen sich allein mit dem Anwendungsprogramm befassen. Voraussetzung dafür seien dann allerdings RISC-Prozessoren, die das Multiprocessing direkt per Hardware unterstützen, nicht allein nur per Software. Und eh' der Leser erst lang raten muß, was für Prozessoren wohl über solche Mechanismen verfügen mögen - hier gleich die Antwort: zufällig die 88000er aus Roths eigener Firma. +