So besehen, scheint die Frage RISC oder CISC bei den Rechnertechnologien nicht nur von den Faktoren der augenblicklich machbaren Preis/Leistungsbalance der verschiedenen Systemkomponenten abzuhängen, sondern ist auch eine Stimmungsfrage. Der Trend zum Downsizing ist sicher mehr auf eine Ver-Stimmung zu begründen, nämlich mit der augenblicklichen Unzufriedenheit der Anwender mit den Praktiken der Hersteller der Mainframe-Systeme, und nicht mit der Technologie.
Die Entscheidung für RISC-Prozessoren ist ebenfalls ein gut Teil Stimmungsmache. Da in den damaligen Rechnerkursen an der Uni Berkeley mit dem zur Verfügung stehenden CAD-Equipment im Rahmen von Diplomarbeiten nur ein extrem einfacher Rechner konstruiert werden konnte, machte man aus der Not eine Tugend und fand ein paar gute Gründe, warum RISC eben besser sein sollte als CISC. Daraus entstand dann die SPARC-Prozessorlinie von SUN.
Der entscheidende Faktor in der Leistungsfähigkeit eines (Von-Neumann-) Rechners ist die Memory Bandwidth, oder die Durchsatzgeschwindigkeit von Instruktionen und Daten durch die CPU. Die Prozessortechnologie ist der Memory-Technologie schon seit jeher um Größenordnungen an Geschwindigkeit voraus, und der Abstand weitet sich. Die Geschichte der Microprozessoren ist ja bekannt: Zuerst war es eine technische Großtat, überhaupt eine (4-bit) CPU auf einem Siliziumchip zu integrieren. Die Integrations-Technologie entwickelte sich weiter, und man konnte immer mehr Transistoren und Leiterbahnen auf einem Chip unterbringen. Also verbreiterte man die Datenbreite, bis man bei 32 (und später 64) Bit angelangt war. Damit war es möglich, Prozessoren nach Muster der VAX auf einem Chip zu installieren. Das hatte auch den Vorteil, daß die gesamte Compilertechnologie schon vorhanden war und leicht zu portieren war. ROM-Speicher nimmt weniger Platz ein als RAM, und so liegt es auch technisch sehr nahe, daß man die ersten komplexeren Prozessoren wie MC 68000, oder Intel 386 zuerst mit Microprogrammen dieser Art baute. Wenn dann die Chip-Technologie noch ein bißchen weiter geht, wie es Anfang der 80er Jahre der Fall war, hat man freien Platz auf dem Chip übrig. Das war die Zeit der RISCs. RISC ist ein Konzept, in dem ein Teil der freien Chip-Fläche für Onboard-RAM (Ob als Registerfeld, oder als Cache-Speicher) freigemacht wird, um durch Pufferung den Abstand zwischen CPU-Geschwindigkeit und RAM-Geschwindigkeit zu verringern, und somit in der Lage zu sein, mit der höher getakteten CPU überhaupt etwas besseres tun zu können, als Wartezyklen für RAM-Zugriffe einzuschieben.
Ob sich RISC lohnt, hängt entscheidend davon ab, wie oft der Cache einen 'hit' hat, oder wie oft statistisch ein 'miss' vorkommt. Wenn die 'misses' überwiegen, fährt die CPU effektiv mit einem Fünftel der Taktgeschwindigkeit, da es so lange dauert, um Daten aus dem Off-Board RAM einzulesen. Und dann ist ein RISC eine sehr lahme Ente. Wie der Erfolg von Intel mit der immer weiter fortgeführten x86er Serie zeigt, ist die CISC-Technologie noch lange nicht tot, und letztlich ist ein CISC-Prozessor heute nichts anderes als ein RISC, dem man einige oft vorkommende Programmfolgen in sein on-board-ROM des Microcodespeichers per 'hardwiring' eingebaut hat. Man spricht hier von 'Tradeoffs' also Tauschverhältnissen, wo man unweigerlich gezwungen ist, einen Vorteil hier gegen einen Nachteil dort einzutauschen. Da Benchmarks einer Maschine bekanntlich die 100%-ige Aussagefähigkeit haben, daß diese und diese Maschine in der Lage ist, genau diesen Benchmark so und so schnell zu fahren, ist der frommen Lüge Tür und Tor geöffnet. Daß ein Benchmark anzeigen soll, daß die Maschine als 'General Purpose Processor' auch besser sein soll, wird ja nirgends behauptet.
Die grundlegende Technologie ist bei allen Rechnern gleich und hängt von den physikalischen Grenzen der Elektronenbewegung und der Kapazität der Leiterbahnen ab. Sowohl bei RISC als bei CISC. Nehmen wir die Microzyklusfrequenz von 100 MHz als Beispiel. Ein CISC braucht im Mittel 3-5 Microzyklen, um eine CISC-Instruktion zu verarbeiten. Da er auf das RAM also vielleicht mit 20 MHz (= 1 Zugriff alle 50 Nsec) zugreift, ist er nicht weit von den heutigen DRAM-Geschwindigkeiten entfernt, und muß keine besonders aufwendigen Cache-Strategien einsetzen. Off-Chip SRAM genügt vollkommen.
Ein RISC-Prozessor arbeitet eine Instruktion in einem Microzyklus ab und wäre bei Direktzugriff auf externes DRAM so ausgebremst, daß er effektiv auch nur mit 20 MHz arbeitet, aber auf einem wesentlich primitiveren Instruction set (und damit viel mehr Instruktionen braucht, um dasselbe zu tun wie ein CISC mit einer). Da er aber on board cache RAM hat, lädt er sich 14 K oder 32 K oder mehr ein, und wenn er Glück hat, kann er eine ganze Weile damit arbeiten. Wenn er Pech hat, gibt es einen Subroutine-Call nach dem anderen, oder große Schleifen, und dann ist der Cache unbrauchbar und muß zeitraubend gegen einen neuen Inhalt ausgetauscht werden. Da Optimizing Compiler die Tendenz haben, Subroutine-Expansion zu machen, kann zwar hier vielleicht ein Call gespart werden, aber dann wird dort eine Schleife zu groß, daß sie nicht mehr in den Cache paßt. Es ist auf jeden Fall ein RISKantes Geschäft, und es gibt keine klaren Antworten für alle Fälle. Der interessante Faktor ist aber, daß RISC Technologie die Möglichkeit von frei programmierbarem RAM on-chip, also zu Zugriffszeiten des CPU-Taktes bietet, was vorher noch nie möglich war. (Man erinnere sich: Die Register der CPU sind seit den uralten Tagen von EDVAC, ENIAC, UNIVAC und MANIAC nichts anderes als der erste, rudimentäre Ansatz eines onboard-Cache-Speichers).
Nach all diesen Ausführungen wird vielleicht deutlicher, daß die technologischen Fragen sich einzig und allein um bestimmte feine Punkte drehen, die alle auf jenen Gedankenblitz des Herrn von Neumann zurückzuführen sind, nämlich, daß es hier einen Prozessor zu geben habe, und da einen Arbeitsspeicher. Alles andere ist eine Nebelschlacht der Vertriebsstrategen. Seien Sie den Herren bitte nicht böse: Sie kämpfen um das Überleben ihrer Companies.
Und nun möchte ich Ihnen, meine lieben Leser, die Sie so lange mit diesem Artikel ausgeharrt haben, ein besonderes Bonbon präsentieren: Ein Fünfminuten-Kurs in Micro-Prozessordesign. Falls Sie also bei dem augenblicklichen Angebot an Universitäts-und Fernlehr-Instituts-Kursen nicht die Zeit oder die Ausdauer zum Belegen einer 5-Jährigen Integrated-Processor-Design Ausbildung gehabt hatte, nun ist Ihre Chance: Gehen Sie zu Ihrem Kind ins Kinderzimmer, nehmen Sie aus irgendeinem der dort herumliegenden Haufen von Spielzeug und Bettwäsche einen Luftballon, gehen Sie mit diesem Luftballon zum nächstgelegenen Wasserhahn, halten Sie die Öffnung des Ballons an den Wasserhahn, drehen Sie das Wasser auf, und lassen Sie soviel Wasser hineinlaufen daß der Ballon so etwas größer wird, wie in Ihre hohle Hand hineinpaßt. Dann verschließen Sie wieder den Wasserhahn, und machen einen Knoten in die Ballon-Öffnung. Und nun kommt der große Moment der Wahrheit: Nehmen Sie den Ballon zwischen beide Hände, und drücken und drehen Sie ihn kräftig, und versuchen Sie ihn auf den kleinsten Raum zusammenzudrücken. Die Erfahrung, die Sie dabei machen, wird Ihnen das wesentliche Wissen vermitteln, mit dem Sie sämtliche Probleme des Microprozessor-Designs mit links bewältigen können. Alle nebensächlichen Detailinformationen können Sie sich durch Lesen der Computerwoche aneignen.
Um kurz zu definieren, wovon hier die Rede ist: Object Code Compiliation ist das Software-Paradigma, unter dessen Anwendung die formale Beschreibung einer zu lösenden Aufgabe (das Computerprogramm) durch geeignete Werkzeuge (Compiler) in das Object-Code Format (oder den native Binary-Code) des Computers übersetzt wird, auf dem die Aufgabenlösung abgearbeitet werden soll. Metacode Programmierung bedeutet, daß ein (native Object-Code) Kontrollprogramm im Arbeitsspeicher des Computers (permanent) resident ist, das die formale Beschreibung einer zu lösenden Aufgabe (das Computerprogramm) interpretierend abarbeitet. Vergleichbar mit der Polarisierung RISC / CISC hat es in der Geschichte der Computerindustrie eine ebenso interessante Auseinandersetzung zwischen den Object-Code contra Meta-Code Verfechtern gegeben. Diese Auseinandersetzung war zwar interessant, aber sehr einseitig. Da bisher immer die reine Verarbeitungs-Geschwindigkeit eines Rechners, also die optimale Nutzung der Maschine im Vordergrund stand, gewannen die Objekt-Code Proponenten bisher immer. Einige Systeme sind dabei auf der Strecke geblieben, andere waren akademisch interessant und kommerziell unfruchtbar, und einige führen ein recht reges Leben in recht unbekannten Nischen: UCSD-Pascal mit der P-Code Maschine, Smalltalk mit der Bytecode-Maschine, Forth und einige Abkömmlinge wie Actor und Amber. Lisp kann auch dazugezählt werden, sowie APL und Mumps. Ebenfalls viele BASIC-Systeme, die incrementell zu einem Tokencode compilieren, und das PICK System. Seit ungefähr zehn Jahren hat sich die Balance insofern entscheidend verschoben, als daß nicht mehr die Maschine, sondern der Faktor Mensch der Grenzfaktor ist. Allerdings ist heute erst der größere Teil der EDV-Industrie mit den Schlagworten "Software-Krise" und "Downsizing" zu dieser Erkenntnis aufgewacht. Der Macintosh Computer war sozusagen das Fanal dieser Entwicklung. Mit der ersten Version dieser Maschine hatte man einen Rechner konstruiert, in dem 90% der Prozessor-Leistung auf das User-Interface konzentriert war. Die heutigen Modelle haben ja noch etwas Power übrig, aber bei dem ersten "Toaster" konnte man das schon unumwunden sagen. Es gab da noch nicht mal eine Programmier-Schnittstelle, dafür sollte man die Lisa nehmen. Das war vor 20 Jahren undenkbar, und ist heute dadurch möglich geworden, daß man so etwas für 10.000 bis 20.000 DM bekommt (seit Apple die jüngsten Preisstürze im PC-Bereich mitmachen mußte, auch für weniger). Ein weiterer Vertreter dieser Philosophie ist NeXt (von Steve Jobs, Vater des Macintosh, of course). Was dem Anwender recht ist, ist dem Programmierer billig. NeXt ist entscheidend auf dem Weg, denselben Quantensprung für den Programmierer zu liefern, wie der Mac für den "unbedarften" Benutzer.
Metacode-Systeme kann man auch als MISC-Rechner ansehen: Mighty Instruction Set Computers. (In Publikationen, wo man einen mehr akademisch klingenden Titel braucht, ersetze man "Mighty" durch "Metacoded"). Eine andere Bezeichnung ist "Very High Level Language Instruction Set Computer", aber VHLL-ISC klingt einfach nicht gut. Warum fanden sich in der Vergangenheit immer wieder so engagierte Verfechter dieses Paradigmas, das ja von der Prozessor-Ökonomie gesehen keine Chance hatte? Es ist sehr einfach, wenn man einige solcher Sprachen kennt, zu sehen, warum Programmierer, die einmal mit einem solchen System zu tun hatten, so ungern wieder davon lassen (siehe auch: Die Gänseküken von Konrad Lorenz). MISC-Rechner machen den Programmierern das Leben entscheidend leichter. Sie verlagern einen Großteil der Komplexität des Programmierer-Daseins dahin, wo sie hingehört, auf den Rechner. Erstaunlicherweise sind diese Ansätze so alt wie die Computerei selber, zum Beispiel APL oder LISP. Die guten Ideen sind sehr alt, aber heute ist endlich die Zeit gekommen, in der sie wieder ihre Auferstehung feiern dürfen. Der Grund ist -wieder mal -in der jetzigen Verschiebung der Technologie-Balance zu finden.
RISC Prozessoren hängen in ihrer Effizienz entscheidend davon ab, ob sie ihren On-Board Cache auswechseln müssen, oder nicht. Der effizienteste RISC ist einer, der den Cache nie auswechseln muß. Er kann mit Vmax gefahren werden. Wenn es gelingt, einen MISC-Code Interpreter zu konstruieren, der voll und ganz in den Instruction-Cache paßt, ist diese Maschine auch mit konservativer Schätzung dreimal schneller als ein RISC, der das RISK hat, auf Cache Faults zu laufen. Dies geht deswegen, weil die MISC-Instruktionen ja Daten sind, und nicht Programm. Der RISC bräuchte deshalb noch einen Datencache. Der größte, und entscheidendste Vorteil für die heutige Software-Technologie wäre aber, daß man endlich einmal darangehen könnte, gezielt Systeme zu entwerfen, die die maximale Effizienz und Sicherheit, und Unterstützung für den Prozess des Programmierens bieten. Die optimale Ausführungs-geschwindigkeit ist durch obigen Effekt zu erzielen. Mit heutiger RISC-Technologie ist das ohne jede Probleme möglich. On-Board Cache von 256 K sollte auch luxuriösen Ansprüchen an einen VHLL-Interpreter genügen.
Jener alte Herr läßt uns auch hier nicht los, denn was in den MISC-Maschinen passiert, sprengt ein wenig das ganze Konzept, das er uns hinterlassen hat. Dies ist ein anderer Grund, warum die EDV bisher nichts so rechtes mit dieser Klasse von Systemen anzufangen gewußt hat. Ist ein MISC-Programm nun Programm oder ist es Daten? Die Idee des Herrn Von Neumann fußt nämlich auf einer noch tieferen Überlegung: Es muß im Rechner etwas geben, das sich dynamisch verändern kann, das man den Arbeitsspeicher nennt, und das die sogenannten "Daten" aufnimmt, und etwas das statisch bleibt, also das Rechenwerk, oder die CPU. Damit man mit diesem statischen Teil aber etwas besseres machen kann als mit den guten alten Analogrechnern, muß man mit bestimmten "Daten" das Rechenwerk steuern können, daher also das Prinzip des gespeicherten "Programms". An der Diskrepanz zwischen der Geschwindigkeit des Datenspeichers und des Rechenwerks entzündeten sich alle Rechner-Optimierungsversuche der Computer-Geschichte. Nun kann man es sich auch einfach machen, und sagen, daß MISC-Instruktionen zweistufige Programme sind. Und wenn man das etwas umformt, dann hat man hier die Analogie zu einem RAM-Cache, nämlich den Programm-Cache. Nur ist die Übersetzung in einer anderen Dimension. RAM-Cache ist RAUM-Cache. Programm-Cache ist ZEIT-Cache. Daraus ergibt sich die folgende Lehre: Wenn der Hund nicht mit dem Schwanz wackelt, dann wackelt der Schwanz eben mit dem Hund. Die Vorarbeiten zur Implementation eines MISC Rechners sind in dem Projekt Leibniz der UniBwM gemacht worden, und die Ergebnisse zeigen, daß damit eine neue Größenordnung der Programmier-Produktivität erreicht werden kann.