1975 fand eine Forschergruppe bei IBM heraus, dass Compiler von den möglichen Befehlen, die eine CPU anbietet, nur eine Teilmenge nutzen. Insbesondere von der Adressierungsweise her komplexe Befehle, die viele Takte benötigen, verwenden Compiler kaum.
Nur wenige Autominuten voneinander entfernt machten sich 1980 die traditionell konkurrierenden Universitäten Berkeley und Stanford an neue Konzepte für CPUs. In Berkeley entstand das Projekt RISC (Reduced Instruction Set Computing), das später den SPARC-Prozessor hervorbrachte und namensgebend für die neue Klasse von CPUs war. In Stanford wurde das MIPS-Projekt geboren, das in der gleichnamigen CPU-Architektur aufging.
Beide Projekte stellten in etwa die gleichen Überlegungen an: Da sich C-Compiler immer mehr gegenüber direkter Assemblerprogrammierung durchsetzten, sollten Befehle auf ein Minimum beschränkt werden. Ziel war es, komplexe Befehle durch einfachere zu ersetzen, so dass jeder Befehl in nur einem Takt ausgeführt werden kann. Klassische CPUs nannte man fortan CISC-CPUs (Complex Instruction Set Computing).
Der Begriff RISC wird oft missverstanden. Der Bestandteil "Reduced" bedeutet nicht, dass eine RISC-CPU funktional im Befehlssatz reduziert wird. Nur Befehle, deren Datenadressierung komplex ist, etwa eine Operation mit zwei Speicherreferenzen als Operanden und einer weiteren Speicherreferenz als Ergebnis, gibt es in einer RISC-Architektur nicht. Ein solcher Befehl muss in einer RISC-CPU durch vier aufeinanderfolgende Befehle realisiert werden, da alle logischen und mathematischen Operationen nur mit Registern und niemals direkt mit Speicher ausgeführt werden. Der CISC-Pseudo-Befehl mem3 = mem1 XOR mem2 muss auf einer RISC-CPU durch die vier Befehle r1 = mem1; r2 = mem2; r3 = r1 XOR r2; mem3 = r3 ausgedrückt werden, wobei mem eine Speicherreferenz und r ein Register darstellt.
Hinzu kamen weitere Vereinfachungen. Jeder Befehl in einer RISC-CPU hat die gleiche Länge. In einer CISC-CPU sind häufig genutzte Befehl ein Byte lang. Seltener genutzte Befehle haben zwei oder mehr Bytes. Hinzu kommt die Länge des oder der Operatoren. Eine RISC-CPU benötigt deutlich weniger Transistoren zum Dekodieren von Befehlen, dafür braucht der Code mehr Speicher.
Die eingesparten Transistoren investierte man vor allem in mehr Register und Pipelining. RISC-CPUs besitzen typischerweise 32 oder 64 General Purpose Register (GPR), während CISC-CPUs meist nur acht aufweisen. Vor allem das Pipelining führte dazu, dass fast alle Befehle in einem Takt ausgeführt werden konnten.
Beide Universitäten brachten kommerziell erfolgreiche CPUs hervor. 1985 kam die MIPS-R2000-CPU auf den Markt. Der SPARC-Prozessor folgte 1987. Allerdings stellte sich später heraus, dass Seymour Cray bereits 1965 bei Control Data die CDC 6600 entwickelt hatte, die als erste RISC-CPU bezeichnet werden muss, lange bevor es den Begriff RISC überhaupt gab und lange bevor Seymour Cray mit seiner eigenen Firma den legendären Cray-1 im "Formfaktor Sofa" herausbrachte . So gesehen muss man die MIPS- und SPARC-Prozessoren als erste RISC-Prozessoren in VLSI-Technik bezeichnen.
Die R2000- und die SPARC-CPU konnten durch sehr gute Leistungen überzeugen, an die damalige CISC-Prozessoren nicht herankamen. In der x86-Architektur war damals der 80386 das Maß aller Dinge – der 80486 erschien erst 1989. Der 80386 kann weder mit einem On-Chip-Cache aufwarten, der fast Registergeschwindigkeit erreicht, noch mit Pipelining, das den Durchsatz erhöht, so dass es kein Wunder war, dass sie von den RISC-Prozessoren überholt wurden. Der R2000 konnte mit 96 KByte Cache aufwarten. Der SPARC besaß bis zu 128 KByte.
Wesentlich weiter entwickelt als der 80386 war damals die Motorola-CISC-CPU 68020. Sie hatte einen 256 Byte L1-Instruction-Cache und ein dreistufiges Pipelining. Das Pipelining war im Gegensatz zu den ersten RISC-CPUs recht limitiert und der Cache sehr klein. So wurde auch sie von den RISC-CPUs in der Performance geschlagen.
Die Leistungssteigerung war immens. Der große On-Chip-Cache konnte in erster Linie durch eingesparte Transistoren erreicht werden. Effektives Pipelining erzielte man durch feste Befehlslänge. Das ließ sich damals auf CISC-Prozessoren nicht realisieren. Man hätte erwarten müssen, dass sich der Markt in Richtung der RISC-Prozessoren entwickelt. Ende der 80er bis etwa 2003 konnten RISC-Prozessoren ihre CISC-Konkurrenten leistungsmäßig mühelos abhängen.
- Milliardengrab: Warum Intels Itanium gescheitert ist
- Kampf der CPU-Architekturen: CISC, RISC, VLIW und EPIC
- Berkeley und Stanford im Wettstreit um RISC-CPUs
- Erfolg von RISC wäre das Ende von Microsoft gewesen
- Das EPIC-Konzept des Itanium: beim Erscheinen schon veraltet
- Deterministisches EPIC-Design bremst Performance
- x86-Wettrüsten zwischen AMD und Intel: Renaissance der CISC-CPUs
- Fazit
Neueste Kommentare
1 Kommentar zu Milliardengrab: Warum Intels Itanium gescheitert ist
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
WindowsNT 3.1 und 16MB RAM
Wie Sie auf "Microsoft sah sich allerdings genötigt, das Chicago-Projekt ins Leben zu rufen, das in Windows 95 mündete, um damals übliche Rechner mit bis zu 4 MByte Hauptspeicher zu unterstützen" ist mir schleierhaft, denn "Windows NT 3.1 benötigt mindestens 16 MByte" ist schlichtweg falsch, auch der Nach-Nachfolger WindowsNT 3.51 lief noch prima mit 8MB RAM. Und selbst das gute alte WindowsNT 4 begnügt sich in der Workstation-Variante mit lediglich 12MB, nur die Server-Version brauchte tatsächlich 16MB RAM. WindowsNT 4 kam aber erst Ende 1996 und damit geraume Zeit nach Windows95 raus.
Der wahre Grund für Windows95 lag zum Einen in der damals noch hohen Verbreitung von DOS-Programmen (vor Allem Spiele), welche unter der DOS-Emulation von WindowsNT garnicht bzw. nur eingeschränkt funktionierten. Zudem erlaubte das die Aufspaltung des eigenen Portfolios in Consumer- (Windows95) und Business-Linie (WindowsNT).
Davidoff