IBM801 - IBM 801

Der 801 war ein experimentelles Design einer zentralen Verarbeitungseinheit (CPU), das in den 1970er Jahren von IBM entwickelt wurde . Es gilt als das erste moderne RISC- Design, das sich für alle Berechnungen auf Prozessorregister verlässt und die vielen unterschiedlichen Adressierungsmodi eliminiert, die in CISC- Designs zu finden sind. Ursprünglich als Prozessor für eine Telefonvermittlung entwickelt , wurde er später als Basis für einen Minicomputer und eine Reihe von Produkten für ihre Mainframe- Linie verwendet. Das ursprüngliche Design war ein 24-Bit- Prozessor; das wurde bald durch 32-Bit- Implementierungen der gleichen Konzepte ersetzt und der ursprüngliche 24-Bit-801 wurde nur in den frühen 1980er Jahren verwendet.

Der 801 war auf dem Computermarkt äußerst einflussreich. Bewaffnet mit riesigen Mengen an Leistungsdaten konnte IBM zeigen, dass das einfache Design selbst die leistungsstärksten klassischen CPU-Designs locker übertrifft und gleichzeitig Maschinencode produziert , der nur unwesentlich größer ist als die stark optimierten CISC-Befehle. Die Anwendung derselben Techniken sogar auf existierende Prozessoren wie dem System/370 verdoppelte im Allgemeinen auch die Leistung dieser Systeme. Dies demonstrierte den Wert des RISC-Konzepts, und alle zukünftigen Systeme von IBM basierten auf den Prinzipien, die während des 801-Projekts entwickelt wurden.

Für seine Arbeit an den 801, John Cocke wurde ausgezeichnet mit Turing Award 1987 National Medal of Technology im Jahr 1991 und die National Medal of Science 1994.

Geschichte

1974 begann IBM, die Möglichkeit zu prüfen, eine Telefonvermittlung zu bauen, um eine Million Anrufe pro Stunde oder etwa 300 Anrufe pro Sekunde abzuwickeln. Sie berechneten, dass jeder Aufruf 20.000 Befehle erfordern würde, und wenn man den Timing-Overhead und andere Überlegungen hinzufügte, benötigte eine solche Maschine eine Leistung von etwa 12 MIPS. Dies würde eine erhebliche Leistungssteigerung erfordern; ihre aktuelle Spitzenmaschine, das IBM System/370 Modell 168 von Ende 1972, bot etwa 3 MIPS.

Die an diesem Projekt arbeitende Gruppe am Thomas J. Watson Research Center , zu der auch John Cocke gehört , hat dafür einen Prozessor entwickelt. Um die erforderliche Leistung zu erreichen, überlegten sie, welche Art von Operationen eine solche Maschine erforderte, und entfernten alle, die nicht angemessen waren. Dies führte beispielsweise zum Entfernen einer Gleitkommaeinheit , die in dieser Anwendung nicht benötigt würde. Noch wichtiger ist, dass sie auch viele der Befehle entfernten, die mit Daten im Hauptspeicher arbeiteten, und nur die Befehle beließen, die in den internen Prozessorregistern arbeiteten , da diese viel schneller zu verwenden waren und der einfache Code in einer Telefonvermittlung geschrieben werden konnte nur diese Typen Anweisungen. Das Ergebnis dieser Arbeit war ein Konzeptentwurf für einen vereinfachten Prozessor mit der erforderlichen Leistung.

Das Telefonvermittlungsprojekt wurde 1975 eingestellt, aber das Team hatte erhebliche Fortschritte bei dem Konzept gemacht und im Oktober beschloss IBM, es als Allzweckdesign fortzusetzen. Da es kein offensichtliches Projekt gab, mit dem es verbunden werden konnte, beschloss das Team, es nach dem Gebäude, in dem sie arbeiteten, "801" zu nennen. Für die allgemeine Rolle begann das Team, reale Programme in Betracht zu ziehen, die auf einem typischen Minicomputer ausgeführt werden sollten . IBM hatte enorme Mengen an statistischen Daten über die Leistung von realen Workloads auf ihren Maschinen gesammelt und diese Daten zeigten, dass über die Hälfte der Zeit in einem typischen Programm mit der Ausführung von nur fünf Anweisungen verbracht wurde: Wert aus dem Speicher laden, Wert in den Speicher speichern, Verzweigung , Festkommazahlen vergleichen und Festkommazahlen hinzufügen. Dies deutete darauf hin, dass das gleiche vereinfachte Prozessordesign für einen Allzweck-Minicomputer genauso gut funktionieren würde wie für einen Spezialschalter.

Diese Schlussfolgerung widersprach dem zeitgenössischen Prozessordesign, das auf dem Konzept der Verwendung von Mikrocode beruhte . IBM gehörte zu den ersten, die diese Technik als Teil ihrer System/360- Serie weit verbreitet einsetzten. Die 360er und 370er gab es in verschiedenen Leistungsstufen, die alle denselben Maschinensprachencode ausführten. Auf den High-End-Maschinen wurden viele dieser Anweisungen direkt in Hardware implementiert, wie eine Gleitkommaeinheit, während Low-End-Maschinen diese Anweisungen stattdessen mit einer Folge anderer Anweisungen simulieren konnten. Dadurch konnte eine einzige binäre Anwendungsschnittstelle über die gesamte Linie ausgeführt werden, und die Kunden konnten sich sicher sein, dass sie ohne weitere Änderungen auf eine schnellere Maschine umsteigen konnten, wenn jemals mehr Leistung erforderlich war.

Microcode ermöglichte es einem einfachen Prozessor, viele Anweisungen anzubieten, die von den Designern verwendet wurden, um eine Vielzahl von Adressierungsmodi zu implementieren . Zum Beispiel kann eine Anweisung wie ADDein Dutzend Versionen haben, eine, die zwei Zahlen in internen Registern hinzufügt, eine, die ein Register zu einem Wert im Speicher hinzufügt, eine, die zwei Werte aus dem Speicher hinzufügt usw. Dies ermöglichte es dem Programmierer, das genaue auszuwählen Variation, die sie für eine bestimmte Aufgabe brauchten. Der Prozessor würde diese Anweisung lesen und Mikrocode verwenden, um sie in eine Reihe interner Anweisungen aufzuteilen. Zum Beispiel könnte das Hinzufügen von zwei Zahlen im Speicher implementiert werden, indem man diese beiden Zahlen in Register lädt, sie addiert und sie dann wieder abspeichert.

Das Team bemerkte einen Nebeneffekt dieses Konzepts; Angesichts der Fülle möglicher Versionen einer gegebenen Anweisung würden Compiler- Autoren fast immer eine einzelne Version auswählen. Dies war fast immer diejenige, die auf den Low-End-Rechnern in Hardware implementiert wurde. Dadurch wurde sichergestellt, dass der vom Compiler generierte Maschinencode auf dem gesamten Lineup so schnell wie möglich ausgeführt wurde. Während die Verwendung anderer Befehlsversionen auf einem Computer, der andere Versionen des Befehls in Hardware implementiert hat, noch schneller ausgeführt werden kann, machte die Komplexität, zu wissen, welche von einer sich ständig ändernden Liste von Maschinen auszuwählen ist, dies äußerst unattraktiv, und die Compiler-Autoren ignorierten dies weitgehend Möglichkeiten.

Als Ergebnis wurde die Mehrheit der im Befehlssatz verfügbaren Befehle nie in kompilierten Programmen verwendet. Und hier realisierte das Team die entscheidende Umsetzung des 801-Projekts:

Das Auferlegen von Mikrocode zwischen einem Computer und seinen Benutzern verursacht einen teuren Overhead bei der Ausführung der am häufigsten ausgeführten Befehle.

Der Mikrocode benötigt eine Zeit ungleich Null, um den Befehl zu untersuchen, bevor er ausgeführt wird. Derselbe zugrunde liegende Prozessor mit entferntem Mikrocode würde diesen Overhead beseitigen und diese Befehle schneller ausführen. Da Mikrocode im Wesentlichen kleine Subroutinen ausführte, die einer bestimmten Hardwareimplementierung gewidmet waren, führte er letztendlich dieselbe grundlegende Aufgabe wie der Compiler aus, indem er Befehle auf höherer Ebene als eine Folge maschinenspezifischer Befehle implementierte. Das einfache Entfernen des Mikrocodes und die Implementierung im Compiler könnte zu einer schnelleren Maschine führen.

Eine Sorge war, dass Programme, die für eine solche Maschine geschrieben wurden, mehr Speicher beanspruchen würden; Einige Aufgaben, die mit einer einzigen Anweisung auf dem 370 ausgeführt werden könnten, müssten auf dem 801 als mehrere Anweisungen ausgedrückt werden , und dann ein Store-to-Memory. Dies könnte das System insgesamt möglicherweise verlangsamen, wenn es mehr Zeit mit dem Lesen von Anweisungen aus dem Speicher verbringen müsste, als es früher für deren Decodierung erforderlich war. Als sie weiter am Design arbeiteten und ihre Compiler verbesserten, stellten sie fest, dass die Gesamtprogrammlänge weiter abnahm und schließlich ungefähr die gleiche Länge wie die für den 370er hatte.

Die ursprünglich vorgeschlagene Architektur war eine Maschine mit sechzehn 24-Bit- Registern und ohne virtuellen Speicher . Es verwendete ein Zwei-Operanden-Format in der Anweisung, so dass Anweisungen im Allgemeinen die Form hatten A = A + B, im Gegensatz zum Drei-Operanden-Format, A = B + C. Die resultierende CPU war im Sommer 1980 betriebsbereit und wurde unter Verwendung der diskreten Komponententechnologie MECL-10K von Motorola auf großen, drahtumwickelten kundenspezifischen Boards implementiert. Die CPU wurde mit 66 ns Zyklen (ca. 15,15 MHz) getaktet und konnte mit der hohen Geschwindigkeit von ca. 15 MIPS rechnen  .

Die 801-Architektur wurde in einer Vielzahl von IBM-Geräten verwendet, einschließlich Kanalcontrollern für ihre S/370-Mainframes (wie dem IBM 3090 ), verschiedenen Netzwerkgeräten und schließlich dem IBM 9370- Mainframe-Kern selbst. Die ursprüngliche Version der 801-Architektur war die Grundlage für die Architektur des IBM ROMP- Mikroprozessors, der im IBM RT-PC- Arbeitsplatzcomputer und mehreren experimentellen Computern von IBM Research verwendet wurde .

Spätere Änderungen

Ursprünglich für ein System mit eingeschränkter Funktion konzipiert, fehlten dem 801-Design eine Reihe von Funktionen, die auf größeren Maschinen zu sehen waren. Bemerkenswert unter diesen war der Mangel an Hardwareunterstützung für virtuellen Speicher , der für die Controller-Rolle nicht benötigt wurde und auf frühen 801-Systemen, die ihn benötigten, in Software implementiert wurde. Für eine breitere Nutzung war die Hardwareunterstützung ein Muss. Darüber hinaus bewegte sich die Computerwelt in den 1980er Jahren insgesamt in Richtung 32-Bit- Systeme, und es bestand der Wunsch, dasselbe mit dem 801 zu tun.

Der Wechsel zu einem 32-Bit-Format hatte einen weiteren wesentlichen Vorteil. In der Praxis stellte sich heraus, dass das Zwei-Operanden-Format in typischem mathematischen Code schwierig zu verwenden war. Idealerweise verbleiben beide Eingangsoperanden in Registern, wo sie in nachfolgenden Operationen wiederverwendet werden können, aber da die Ausgabe der Operation einen von ihnen überschreibt, musste oft einer der Werte aus dem Speicher neu geladen werden . Durch den Übergang zu einem 32-Bit-Format ermöglichten die zusätzlichen Bits in den Befehlswörtern die Angabe eines zusätzlichen Registers, so dass die Ausgabe solcher Operationen an ein separates Register geleitet werden konnte. Das größere Befehlswort erlaubte auch, die Anzahl der Register von sechzehn auf zweiunddreißig zu erhöhen, eine Änderung, die bei der Untersuchung des 801-Codes eindeutig nahegelegt worden war. Trotz der Erweiterung der Befehlsworte von 24 auf 32 Bit wuchsen die Programme aufgrund der vermiedenen Lasten und Einsparungen durch diese beiden Änderungen nicht um die entsprechenden 33 %.

Andere wünschenswerte Ergänzungen sind Anweisungen zum Arbeiten mit Zeichenfolgendaten, die im "gepackten" Format mit mehreren ASCII- Zeichen in einem einzigen Speicherwort codiert wurden , und Ergänzungen zum Arbeiten mit binärcodierten Dezimalzahlen , einschließlich eines Addierers, der Vier-Bit-Dezimalzahlen übertragen kann .

Wenn die neue Version des 801 als Simulator auf dem 370 laufen gelassen wurde, wurde das Team überrascht , dass Code im Simulator auf die 801 und führen zu erstellenden finden würde schneller als die gleichen oft laufen Quellcode direkt zu 370 kompilierte Maschinencode unter Verwendung der 370 PL/1- Compiler. Als sie ihre experimentelle Sprache "PL.8" zurück auf den 370 portierten und Anwendungen damit kompilierten, liefen sie auch schneller als der vorhandene PL/1-Code, bis zu dreimal so schnell. Dies lag daran, dass der Compiler RISC-ähnliche Entscheidungen darüber traf, wie der Code in interne Register zu kompilieren ist, wodurch so viele Speicherzugriffe wie möglich optimiert wurden. Diese waren beim 370 genauso teuer wie beim 801, aber diese Kosten wurden normalerweise durch die Einfachheit einer einzigen Zeile CISC-Code verdeckt. Der PL.8-Compiler war viel aggressiver beim Vermeiden von Lasten und Speichern, was zu einer höheren Leistung sogar auf einem CISC-Prozessor führte.

Amerika-Projekt

In den frühen 1980er Jahren wurden die Erfahrungen aus dem 801 in das neue "America"-Design zurückgeführt. Dies war ein Drei-Chip-Prozessorsatz mit einem Befehlsprozessor, der Befehle abruft und decodiert, einem Festkommaprozessor, der die Aufgaben mit dem Befehlsprozessor teilt, und einem Gleitkommaprozessor für die Systeme, die dies benötigen. Das vom 801-Team entworfene endgültige Design wurde an das IBM-Büro in Austin geschickt, das es zum IBM RS/6000- System entwickelte. Die mit 25 MHz betriebene RS/6000 war eine der schnellsten Maschinen ihrer Zeit. Es übertraf andere RISC-Maschinen in gängigen Tests um das Zwei- bis Dreifache und übertraf ältere CISC-Systeme trivial.

Nach dem RS/6000 richtete das Unternehmen seine Aufmerksamkeit auf eine Version der 801-Konzepte, die in verschiedenen Maßstäben effizient hergestellt werden konnte. Das Ergebnis war die IBM POWER-Befehlssatzarchitektur und der PowerPC- Ableger. Für seine Arbeit an den 801, John Cocke wurde ausgezeichnet mit Turing Award 1987 National Medal of Technology im Jahr 1991 und die National Medal of Science 1994.

Michael J. Flynn betrachtet das IBM 801-Design als das erste Computersystem mit reduziertem Befehlssatz (RISC).

Verweise

Zitate

Literaturverzeichnis

Weiterlesen

  • "Die Änderung der Computerarchitektur ist eine Möglichkeit, den Durchsatz zu erhöhen, schlagen IBM-Forscher vor". Electronics V. 49, N. 25 (23. Dezember 1976), S. 30–31.
  • V. McLellan: „IBM Mini ein radikaler Aufbruch“. Datamation V. 25, N. 11 (Oktober 1979), S. 53–55.
  • Dewar, Robert BK; Smosna, Matthäus (1990). Mikroprozessoren: Die Sicht eines Programmierers . McGraw-Hill. S. 258–264.
  • Tabak, Daniel (1987). RISC-Architektur . Research Studies Presse. S. 69–72.

Externe Links