Home

Computer

Hardware

Site Map

Der Intel i8800 oder iAPX 432

In meiner losen Reihe von „Fehlschlägen“ von Intel, also Prozessoren, die von Intel entwickelt wurden, aber die Erwartungen nicht erfüllten kommt mit diesem Artikel der krönende Abschluss. Bisher erschienen schon:

• Der Intel 8085 (1976) – ein Nachfolger des Intel 8080, dem zum Verhängnis wurde, das zeitgleich der noch bessere Z80 erschien.

• Der iAPX 432 (1981) – eine objektorientierte 32 Bit Architektur, die jedoch in realen Benchmark quälend langsam war. (Den Artikel lesen sie gerade).

• Der I860 (1989), ein von Intel als „Cray on a Chip“ beworbener RISC Prozessor mit auf dem Papier beeindruckender Performance. Leider erreichte er diese Geschwindigkeit in realen Programmen nicht und noch bedeutender: Er war auf Maschinensprachenebene inkompatibel zu jedem eingeführten Prozessor.

• Und nun eben im Jahre 2001 der Itanium mit einer VLIW Architektur, der nicht die Erwartungen Intels erfüllte.

Einleitung

Intel war in den Siebzigern der Mikroprozessor-Pioneer. Zwar erfanden sie den Mikroprozessor nicht, hatten aber mit dem vor den eigentlichen Erfindern Texas Instruments das erste Produkt auf dem Markt. Nach zwei Zwischenschritten - dem verbesserten 4 Bit Prozessor Intel 4004 und dem ersten, rudimentären 8 Bit Prozessor 8008 folgte 1974 der erste vollwertige 8 Bit Prozessor Intel 8080. Er steckte in vielen der ersten PCs, vor allem ,weil der erste PC überhaupt, der Altair 8800 ihn verwendete. Motorolas nur kurz danach erschienener MC 6800 konnte diesen Erfolg nicht in dem Maße vorweisen.

Doch schon wenige Jahre hatte sich die Situation gewandelt. Mit dem MOS 6502 kam ein vereinfachter Nachbau des Motorolas 6800 auf den Markt, aufgrund des einfacheren Aufbaus war er aber viel preiswerter und zwang Intel auch die Preise für die eigenen Prozessoren, die deutlich komplexer waren, zu senken. Der 6502 steckte in den Atari Heimcomputern, vor allem aber in dem Apple II und natürlich in Commodores eigenen Rechnern.

Noch bedrohlicher für Intel war der Z80 der Firma Zilog. Gegründet mit Venturekapital von Exxon von dem ehemaligen Intel-Mitarbeiter Frederico Faggin, der an der Entwicklung des 8080 maßgeblich beteiligt war, war er viel erfolgreicher als sein Vorbild. Faggin kannte als Entwickler des 8080 seine Mängel und beseitigte diese. Der 8080 benötigte einen externen Taktgeber, der war im Z80 integriert. Die damals aufkommenden dynamischen RAM benötigten eine Auffrischung, der Z80 hatte die nötige Logik integriert. Daneben wurde der Befehlssatz deutlich erweitert. Der Z80 erschien 1976 und wenige Jahre später hatte der 8080 keine Marktbedeutung mehr. Als sich der ct’ Redakteur Andreas Stiller, der seit der ersten Ausgabe der ct’ (12/1983) bei der Zeitschrift war, in einem Interview die Zeit Revue passieren lies, konnte er sich an keinen Rechner erinnern, der den Weg in die Redaktion fand und der einen 8080 Prozessor hatte.

Mit dem 8080 begann die PC-Geschichte. Es kamen immer mehr, immer leistungsfähigere Geräte auf den Markt, es war aber auch klar, das die Entwicklung weitergehen musste. Die Grenzen des Adressraums von 64 KByte waren schon 1982 erreicht. Damals erschien der C64 im unteren Marktsegment mit 64 KByte RAM und 20 KByte ROM – da ein 8 Bit Rechner nur 64 KByte adressieren kann waren für den Anwender aber nur 38 KByte des RAMs nutzbar. Anwender wünschten schnellere Geräte mit besserer Grafik und mehr Speicher. So begannen viele Firmen Ende der Siebziger Jahre mit der Entwicklung von 16 Bit Prozessoren: Zilog mit dem Z8000, National Semiconductor mit dem NS160016, Motorola mit dem MC 68000. Am frühesten war Texas Instruments mit dem TMS 9900 fertig, der schon 1976 erschien, aber vergleichsweise langsam war und einen Adressraum von nur 64 KByte hatte, also keinen wesentlichen Vorteil gegenüber den etablierten 8-Bittern besaß.

Das Management bei Intel fällte im Jahre 1975 eine verhängnisvolle Entscheidung, die im Nachhinein sich als Fehlentscheidung entpuppen sollte. Da man bei den 8 Bit Prozessoren sah, wie schnell einen die Konkurrenz überholen konnte, beschloss man die 16 Bit Generation komplett zu überspringen und gleich einen 32 Bit Prozessor zu konstruieren. Dies sollte der 8800 werden. Ein 32 Bit Prozessor ist aber erheblich komplexer als ein 8 Bit Prozessor. Entsprechend lange dauerte die Konstruktion und die vielen Transistoren waren bei Entwicklungsbeginn auch nicht mit der vorhandenen Technologie auf einem Chip unterzubringen. Beides bedeutete, dass der Prozessor nicht vor den frühen achtziger Jahren verfügbar sein würde.

Gemäß der Intel Tradition würde der neue Prozessor „8800“ heißen. Das entsprach dem „Intel-Shift“ bei dem die letzte Ziffer der Typennummer immer weiter nach vorne rückte (8008 – 8080 – 8800).

Um die Kunden aber nicht zu verlieren, entschloss man sich 1978 dann doch für einen 16 Bit Prozessor. In den vergangenen drei Jahren hatte Intel mitbekommen das andere Firmen 16 Bit Prozessoren entwickelten und bald auf dem Markt präsent sein würden.

Damit der 16 Bit Prozessor möglichst schnell verfügbar war, schließlich begann man mit der Entwicklung später als die anderen Firmen, wurde der neue Prozessor kein fundamental neues Design, sondern das Design des 8080 wurde auf 16 Bit aufgebohrt – er erhielt 16 Bit Befehle, hatte aber Register mit derselben Funktion wie beim 8080 und als Subset auch die alten Befehle. Selbst der Adressraum von 64 KByte pro Register war unverändert. Da dies zu knapp war, konnte man diesen Adressraum mit vier Segmentregistern innerhalb eines 1 Mbyte großen globalen Adressraums verschieben. Den Bestandskunden wurde dies als Feature verkauft. Denn so konnte ein Programm aus einem Assemblerprogramm (Quellcode) für den 8080 ein Binärprogramm für den 8086 erzeugen. Dieses Crossassembling führte denn auch schnell zu ersten Anwendungen und Betriebssystemen für den 8086, die so entstanden, dann aber auch nur einen Teil der Fähigkeiten ausnutzten, z.b. war der Adressraum so auf 64 Kbyte beschränkt. Die erste Version von MS-DOS aber auch CP/M-86 nutzten nur 64 KByte für Programme, das damals eingeführt .com Format der Anwendungen gibt es bis heute.

Intel sah den 8086 als Lückenbüßer und hat sich, als er im Mai 1978 erschien, wohl kaum vorstellen können, das im Jahre 2021, also über 40 Jahre später die Architektur immer noch die Basis der meisten PC ist. Dass es dazu kam, lag daran, dass IBM den Prozessor bzw., dessen kleinen Bruder 8088 für den IBM PC selektierte. Hier spielte genau diese Abwärtskompabilität eine große Rolle, denn IBM war im Zeitdruck, hatte vorher aber schon einen Rechner auf Basis des 8085, ein verbesserter 8080 entwickelt und konnte so viel von diesem Rechner übernehmen.

Das Design des Intel 8800

Das Projekt startete schon 1975, also drei Jahre vor dem 8086. Intel machte einen kompletten Schnitt mit der bisherigen Entwicklung. Diese war bisher von den Kundenwünschen getrieben. Der 4004 sollte einen Tischrechner antreiben und war so auf die Verarbeitung von Dezimalzahlen ausgelegt. Der 8008 war für ein Terminal vorgesehen und sollte so Buchstaben verarbeiten. Mit dem 8080 hatte man Design des 8080 erweitert und universeller gemacht, aber es war keine eigenständige Neuentwicklung.

Chef Architekt war Justin Rattner und Projektmanager war Bill Lattin. Beide hatten bisher nichts mit Mikroprozessoren zu tun. Rattner fällte die verhängnisvolle Entscheidung das Geschwindigkeit nicht das Hauptkriterium des Prozessors sein sollte. Normal wäre das die nächste Generation 5 bis 10-mal schneller als die vorhergehende war. Dies sollte deswegen keine Rolle spielen, weil der Prozessor für eine Multiprozessor Umgebung ausgelegt war. Schaffte ein Prozessor nicht die erwartete Performance, so sollte das System eben mehrere dieser Prozessoren beinhalten.

Ein 32-Bit-Prozessor spielt in der Liga der Superminicomputer und Mainframes. Die bekannte IBM 360 Serie und ihre Nachfolger die 370 Serie waren 32 Bit Großrechner. Während der Entwicklung des 8800 erschienen die ersten Superminis wie die VAX von DEC oder Eclipse von Data General die in der Leistungsfähigkeit zwischen den Minicomputern (mit typischerweise einem 16 Bit Prozessor) und einem Großrechner lagen. Intel beschloss, dass der neue Prozessor Features haben sollte wie ihn Prozessoren für Großrechner haben sollten. So spielte auch keine Rolle, das man dies alles gar nicht auf einem Chip unterbringen konnte, denn auch der Prozessor eines Großrechners bestand aus vielen Chips, teilweise über mehrere Platinen verteilt. In Intels Manuals wird er auch „Micro Mainframe“ genannt.

Die erste Version des Intel 8800 erschien 1981. Mittlerweile war der 8086 erschienen, der Coprozessor 8087 war angekündigt, die Nachfolger 80186 und 80286 waren in der Arbeit und die 16 Bit Microcontroller der Familie 8096 wurde entwickelt. Da passte die ursprüngliche Bezeichnung „Intel 8800“ nicht mehr. Denn alle diese Prozessoren waren 16 Bit Architekturen. Intel entschloss sich zu einer Namensänderung und nannte den Prozessor nun „iAPX 432“. Die Abkürzung iAPX stand für intel Advanced Processor architecture, wobei das X vom griechischen Buchstaben Chi kam; wenn man „APX“ an sich als griechische Schrift deutet (Alpha, Rho, Chi), dann steht es selbst für architecture. Eine Zeitlang benutzte Intel das Kürzel iAPX als Prefix für andere Prozessoren wie den iAPX 286 oder iAPX 386, stellte das aber nach dem 386-er ein. Intel referierte die Abkürzung auch als Intel Advanced Processor System.

Grundlegende Eigenschaften

Ein völlig neues Feature war, dass der Prozessor Objekte unterstützen sollte. Die objektorientierte Programmierung war damals völlig neu. Die erste Programmiersprache, die sie einführte, war das im Xerox Parc entwickelte Smalltalk. Es gibt einige Merkmale von Objekten. Ein grundlegendes ist, das Code und Daten nicht getrennt sind, wie dies bei Prozessoren sonst der Fall ist. Der 8086 hatte sogar eigene Segmente für Code und Daten. Vielmehr haben Objekte Methoden mit denen sie die Daten bearbeiten und nur über sie kommt man an die Daten an. Das ist ein weiterer Sicherheitsfaktor gegen Programmierfehler. Objekte leiten sich von einem Muster einer Klasse ab, vergleichbar einem Bauplan und Objekte können sich vererben, sprich aus einer Klasse kann durch Vererbung eine abgeleitete Klasse mit neuen Eigenschaften aber auch den alten entstehen.

Objekte sind in der Implementierung dynamische Datenstrukturen, sie werden über einen Konstruktor erzeugt und einen Destruktor gelöscht. Sie haben Zeiger auf die Methoden, die sie einsetzen können, das heißt, Objekte arbeiten sehr viel mit Zeigern, weniger mit statischen Variablen deren Adressen sich nie ändert.

Im Falle des Intel 8800 nahm Intel die Sprache ADA als Basis. Ada, so benannt nach Ada Lovelace war eine von 1977 bis 1983 entwickelte Programmiersprache. Beim US-Militär häuften sich zu dieser Zeit die Probleme mit der Softwareentwicklung. Computersysteme wurden immer wichtiger, nicht nur in Einsatzzentralen, sondern auch als Bestandteil von Waffen. Die Softwarepflege wurde bei vielen eingesetzten Programmiersprachen zunehmend aufwendiger. Ada war eine Sprache, die nicht nur die Möglichkeiten der wichtigsten Programmiersprachen, die schon eingesetzt wurden hatte, sondern vor allem sicher sein sollte. Sie hatte Prüfungen zur Laufzeit integriert und sie verfolgte den Ansatz das der Compiler nicht nur die Syntax des Quelltextes überprüfen konnte, sondern auch, ob das compilierte Programm bei der Ausführung fehlerfrei war.

Der Intel 8800 unterstützte so komplexe Datenstrukturen wie sie Records – Verbund von mehreren Variablen die zusammengehören und Arrays – indizierte Felder. Objekte werden zur Laufzeit erzeugt und vernichtet, dabei entstehend Lücken im Speicher, die objektorientierte Programmiersprachen regelmäßig beseitigen müssen. Dies nennt man „Garbage Collection“. Der Intel 8800 unterstütze das Betriebssystem bei der Garbage Collection.

Der grundlegende Ansatz hinter der Überlegung ADA auszuwählen war, das man den Mikroprozessor nicht in Assembler programmieren würde, sondern in einer Hochsprache und die Instruktionen sich so Befehlen der Hochsprache nähern sollten. Das war ein Ansatz, den es auch woanders gab, so hatte die VAX einen Befehlssatz der einige C-Befehle wie die Prä- und Post- Inkremente/Dekremente nach Array Operationen als Maschinencode beinhaltete, ebenso wie die doppelt indirekte Adressierung, die man bei verketteten Listen benötigte.

Für die relativ einfache Programmiersprache wurden sogar LISP-Machinen entworfen welche die Befehle von LISP nativ ausführen konnten.

Intern arbeitete der iAPX 432 mit zwei Phasen bei einem Maximaltakt von bis zu 8 MHz Takt. Eine Mikroinstruktion wurde intern in 125 ns ausgeführt. Es dauerte aber einige Jahre bis man den Maximaltakt erreicht hatte. Angekündigt wurde er mit 5 MHz, doch die ersten ausgelieferten Exemplare schafften nur 4 MHz. Eigentlich sollte der Prozessor 10 MHz erreichen. Dies wurde nie geschafft. Ende 1985 stellte Intel die Produktion ein. Inzwischen gab es mit dem 386-er schon einen 32 Bit Prozessor in der x86 Linie.

Aufbau

Die grundlegende Schwäche des iAPX 432 war es das das System am Schluss nicht auf einem Chip unterzubringen ar, sondern drei benötigte: Der eigentliche Prozessor (General Data Processor GDP) war in zwei IC untergebracht. Ein GFDP enhielt die Ausüfhrienheit, ein zweiter den Befehlsdekodierer. Die Kommunikation mit der Außenwelt (Speicher / andere IC) erfolgte durch den Interface Processor IP. Diese drei Chips bildeten zusammen die CPU. Bedingt dadurch das Signale außerhalb des Prozessors längere Wege nehmen und auch verstärkt werden müssen, da sie über breite Verbindungsbahnen zwischen den Pins gehen ist der maximale Takt den eine solche Architektur haben kann immer kleiner als wenn man alle Elemente auf einen Chip unterbringt.

Die drei Chips waren:

1. 43201: GDP 1: er holte Daten vom Speicher über den IP und dekodierte die Anweisungen. Den Microcode übermittelte an den

2. 4302: GDP 2: der die Befehle dann ausführte. Die Kommunikation mit dem Speicher erfolgte dann über den

3. 43203: IP den Interface Prozessor.

Später erschien noch die 43204 BIU (Bus Interface Unit), Sie war für Multiprozessorsystem gedacht und erlaubte 63 Speichermodule pro Bus und 8 Busse. So konnten sich mehrere Prozessoren einen Speicher teilen und die 43205 Memory Control Unit (MCU).

Jeder der drei Chips saß in einem 64 Pin Gehäuse, das entsprach den Pins eines 80286 (68), Intels 80386 als erster 32 Bit Prozessor der x86 Linie hatte dagegen ein 132 Pin Gehäuse. Die beiden GDP hatten zusammen 160.000 Transistoren.

Hier ein Vergleich der Integrationsdichten und Taktfrequenzen mit anderen Prozessoren dieser Zeit:

Bei den maximalen Taktfrequenzen ist allerdings zu berücksichtigen das alle anderen Prozessoren viel länger produziert wurden und während dieser Zeit die maximalen Taktfrequenzen anstiegen. Die maximalen Taktfrequenzen bei Einführung waren 5 MHz beim 432, je 8 MHz beim 8086, 80286 und Motorola 68000 und 16 MHz beim Motorola 68020 und Intel 80386.

Objektarchitektur

In der Implementierung des Intel 8800 war wirklich alles ein Objekt. Selbst die Anweisungen. Jedes Objekt enthielt ein Beschreibungsfeld, das je nach Objekttyp variierte, einen Code und Datenbereich und Zeiger auf abgeleitete bzw. weitere Objekte.

• Anweisungsobjekt enthält ausführbare Anweisungen

• Domänenobjekt ist ein Programmmodul und enthält Verweise auf Unterprogramme und Daten

• Kontextobjekt repräsentiert den Kontext eines Prozesses in der Ausführung (Rechte etc.)

• Typdefinitionsobjekt repräsentiert einen softwaredefinierten Objekttyp

• Typsteuerungsobjekt repräsentiert typspezifische Privilegien

• Objekttabelle identifiziert die Sammlung aktiver Objektdeskriptoren des Systems

• Speicherressourcenobjekt stellt einen freien Speicherpool dar

• physisches Speicherobjekt identifiziert freie Speicherblöcke im Speicher

• Speicheranspruchsobjekt begrenzt den Speicher, der von allen zugeordneten Speicherressourcenobjekten zugewiesen werden kann

• Arbeitsobjekt identifiziert einen laufenden Prozess

• Port-Objekt ist eine Port- und Nachrichtenwarteschlange für die Interprozesskommunikation

• Träger Carrier transportieren Nachrichten zu und von Ports

• Prozessor enthält Statusinformationen für einen Prozessor im System

• Prozessorkommunikationsobjekt wird für die Interprozessorkommunikation verwendet

Befehlsaufbau

Ein Befehl selbst bestand aus mehreren Feldern, die den Prozessor informierten, was verarbeitet werden sollte. Dies war ein Feld für den Opcode also den Befehl, ein Feld für die Klasse, in der die Anzahl der Operanden und deren Länge angegeben wird (z. B. ob eine 16 oder 32 Bit Zahl folgt) und ein Formatfeld das den Typ genauer charakterisiert (vorzeichenbehaftet oder nicht) und zuletzt die Operanden 0 bis 3. Erst als letztes kam der Opcode selbst. Die dahinter liegende Idee war, das der Befehlskodierer, wenn er den Opcode hatte, alle benötigten Informationen zur Verarbeitung hatte und sofort loslegen konnte. In der Praxis entwickelte sich dies aber nicht als Vorteil, sondern als Nachteil, denn Befehle waren so sehr variabel in der Länge und aufwendig zu dekodieren. Beides erzeugte Verzögerungen, da es so nicht möglich war den nächsten Befehl vorausschauend zu lesen, da man ja nicht wusste, wo der vorhergehende Befehl endet und das Dekodieren von nicht auf harten Bytegrenzen festgelegten Befehlen mit variabler Länge war auch komplexer. In der Praxis war die mittlere Befehlslänge nicht viel unterschiedlich von denen der Mc 68000 Architektur und lag bei verschiedenen Benchmarks zwischen 35 und 41 Bits pro Befehl.

Datentypen

Normal waren damals das ein Mikroprozessor ganze Zahlen verarbeitete. Oft unterschied er noch vorzeichenbehaftete Zahlen (auch negative Zahlen möglich) und vorzeichenlose (nur Null und positive Werte möglich). Der Intel 8800 kannte auch ganze Zahlen von 8, 16 und 32 Bit Breite. Er kannte aber auch zwei Gleitkommatypen:

• „Real“ war 64 Bit lang, davon 52 Bits für die Mantisse, 11 Bits für den Exponenten und 1 Bit für das Vorzeichen. Dieses Format ist nach IEEE 754 der Standard für einen 64 Bit Gleitkommawert, in der Programmiersprache „C“ meistens identisch mit „double“

• „Temporary Real“ war 80 Bits lang, davon 64 Bits für die Mantisse, 15 Bits für den Exponenten und 1 Bit für das Vorzeichen. Dieser Typ ist nicht nach IEEE 754 standardisiert und findet sich auch nur bei Intel Prozessoren (auch als Datentyp der x87-Coprozessoren). In „C“ entspricht er dem Datentyp „long double“.

Ein 32 Bit langer Gleitkommatyp, der damals sehr oft verwendet wurde, weil Berechnungen damit schneller gingen, fehlte. Gegen ihn sprach wohl, dass die Genauigkeit nur sieben bis acht Dezimalstellen beträgt, was bei Simulationen sehr leicht zu falschen Ergebnissen führen kann, wenn ein Ergebnis immer auf dem vorhergehenden Ergebnis beruht und sich Rechenfehler potenzieren.

Daneben unterschied der 432 bei den Ganzzahlentypen auch vorzeichenbehaftete von nicht vorzeichenbehaftete Typen. Das wurde bei anderen Prozessoren meistens durch die Programmierapache gelöst. Er hatte somit acht Datentypen, der 80386 als erster 32 Bit Mikroprozessor der x86 Linie, dagegen nur drei. Es gab für die Fließkommazahlen die Grundrechenarten (Addition, Subtraktion, Multiplikation, Division, Rest). Für 8 und 16 Bit Ganzzahlen gab es auch Bitoperationen.

Die höheren Datentypen Record und Array wurden nicht durch Rechenbefehle unterstützt, aber durch die Adressierungsarten. Jede Adressierungsart ging mit jedem Register und jedem Operantentyp. Das war zumindest in der Intel Linie neu. Sowohl beim 8080 wie auch 8086 gab es Spezialregister mit denen nur bestimmte Adressierungen möglich waren. Die Indirekte Speicheradressierung war beim 8080 nur mit dem HL Register möglich und die indizierte Adressierung bei 8086 nur mit dem BX Register.

Der Intel 432 unterstützte logische Adressierung. Das bedeutet, dass die Adresse eines Anwendungsprogramms nicht unbedingt die physikalische Adresse im Speicher ist. Innerhalb des Prozessors wird die logische Adresse in eine physikalische Adresse übersetzt durch eine Ersetzungstabelle. Dieses Feature ist wichtig für alle Betriebssysteme, bei denen mehr als ein Prozessor gleichzeitig läuft, denn so kann jeder Prozess seinen eigenen Adressraum haben. Die Übersetzung geschieht meist in Seiten fester Größe z.B. 1 KByte oder 4 KByte um die Komplexität zu reduzieren. Der Intel 432 unterstützte 2²⁴ Seiten, das war eine Menge. Jede Seite konnte maximal 2¹⁶ Bytes umfassen. Da dieser Adressraum größer als der verfügbare Speicher war unterstützte er auch virtuellen Speicher, bei diesem wird physikalischer speicher auf einen Massenspeicher (Festplatte) ausgelagert. Das erfolgt durch das Betriebssystem, aber der Prozessor kann das Betriebssystem von einer Speicheranforderung unterrichten. Auch das war ein Feature von Superminis und Großrechnern. Es wurde daher auch beim Intel 80386 eingeführt. Physikalisch waren 16 Mbytes direkt adressierbar. Das war auch der Adressraum eines 80286 oder MC 68000.

Anweisungen

Es gibt eine Reihe von Anweisungen, die versteht jeder Prozessor, auch ein einfacher 8 Bit Prozessor, dazu gehören die logischen Operationen, Addition und Subtraktion. Der iAPX 432 bot zudem Multiplikation, Division und Restbildung bei allen Datentypen außer Char (8 Bit). Für die beiden Realtypen war auch das Wurzelziehen möglich, aber keine transzendenten Operationen wie Sinus oder Logarithmus bilden. Jeder der Datentypen konnte zudem in einen anderen umgewandelt werden, wenngleich dies auch einen Fehler produzieren konnte, wenn der Wert z.B. in einen kleineren Typ konvertiert wurde und nicht in dessen Wertebereich passte.

Anweisungen bildeten ein Instruction Objekt, das hießt sie wurden zu einem Objekt zusammengefasst das aus einem Instruktionsblock und einem Datenblock bestand. Referenzen auf Daten bezogen sich auf dieses Datenobjekt das bis zu 8.192 Byte lang sein konnte, daher kam man mit 16 Bit breiten Adressen innerhalb des Objektes aus. Alle Instruktionsobjekte waren auf geraden 16 Bit Adressen angeordnet und wurden in Paketen von 32 Bit geholt.

Insgesamt gab es 225 Anweisungen. Die Zahl der Instruktionen lässt aber keinen Rückschluss auf die Leistungsfähigkeit einer Architektur zu, vielmehr ist sie ein Hinweis, ob der Chip sehr komplex ist (CISC Ansatz) oder vielmehr auf die schnellere Ausführung einfacher Instruktionen setzt. (RISC Ansatz) Der 8086 Prozessor ist ein typischer CISC Vertreter, er hatte 177 Basisinstruktionen, der MC 68000, obwohl schneller als ein 8086 dagegen nur 57. Er ist ein Vertreter des CISC Ansatzes. Der iAPX 432 ist noch mehr als der 8086/286 ein CISC Prozessor. Er hat einige sehr komplexe Instruktionen die für die Objektverwaltung und Prozesskommunikation benötigt werden und die bis zu 400 Mikrosekunden dauern.

Die Anweisungen beinhalteten auch Anweisungen, die man zu der damaligen Zeit woanders nicht fand um Objekte zu unterstützen. Man konnte Botschaften an Objekte Senden und diese anhalten. Einen Speicherpool mit Allocate und Type verwalten, und Prozesse initiieren und stoppen (Schedule, Dispatch). Ebenso fortschrittlich meldete der Prozessor einen Fehler als ein Ereignis und das Betriebssystem konnte darauf reagieren, anstatt einfach abzustürzen oder mit falschen Werten weiter zu rechnen.

Für Mikroprozessoren neu war der Drei-Adress-Ansatz, der heute bei den Erweiterungen der x86 Architektur Standard ist und damals auch bei Großrechnern Standard war. Das heißt, es waren Anweisungen möglich wie:

C := A + B

oder

Record.Field := A[i] * D

Beim 8086 waren Felder als Teile eines Rekords nicht individuell ansprechbar und das Ergebnis einer Rechnung überschrieb jeweils einen Operanden (Zwei-Adress-Architektur).

Die Architektur war intern stackbasiert, das heißt die Kommunikation führte über einen Stack auf dem die Werte abgelegt wurden. Demgegenüber waren alle anderen Mikroprozessoren der damaligen Zeit registerbasiert, hielt die Werte und Adressen in Registern. Wie groß die internen Arbeitsregister waren und wie viele es gab ist unbekannt. Lediglich für das Zwischenspeichern von Daten gab es im Bereich des GDP, der die Daten empfing, einen Eintrag von 20 Werten zu je 43 Bit Breite. Für den Programmierer waren keine Register sichtbar, also mit einem Befehl adressierbar.

Als Adressierungsarten gab es:

• Basis direkt und indiziert direkt – direkter Zugriff auf einfache Datentypen.

• Basis indirekt und indiziert direkt – Zugriff auf Records.

• Basis direkt und indiziert indirekt – zugriff auf statische Arrays

• Basis indirekt und indiziert indirekt – zugriff auf dynamische Arrays

Direkt: Die Adresse ist Bestandteil der Anweisungen. z.B. „Hole den Wert von Adresse 1000“

Indirekt: Die Adresse in der Anweisung ist nicht die Adresse der gewünschten Daten, sondern diese referierte Speicherzelle enthält diese. z.B. „Hole den Wert von der Adresse, die Du in der Speicherstelle 1000 findest“. Diese Adressierung ist die Basis für Zeigeroperationen.

Indiziert: Zu der gebildeten Adresse (direkt oder indirekt) wird noch ein Offset addiert um z.B. einen Wert in einem Array anzusprechen, dessen Basisadresse in einem anderen Register steht.

Diese Adressierungsmodi waren für einen 32 Bit Prozessor schon relativ wenig. Die Motorola MC 68000 beherrschte z. B. die doppelt indirekte Adressierung, die man für verkettete Listen benötigte. Die VAX als ein Computer, in dessen Region Intel den 8800 sah, hatte neun Adressierungsarten.

Microcode

Der Prozessor verwandte Microcode. Bei Microcode gibt es im Prozessor ein ROM in dem einzelne Befehle in noch kleinere elementare Befehle aufgegliedert sind und der Befehlsdekodierer liefert Adressen in diesem ROM. Dann werden die Instruktionen dort abgeholt und ausgeführt. Es ist im Prinzip ein Interpreter im Prozessor. Microcode hat große Vorteile. Er spart viel Logik ein, ist flexibler, kann leicht geändert werden, schon damals sogar nach der Herstellung. IBM erreichte die große Skalierbarkeit der 360-er Familie auch durch Microcode, der bei den kleineren Modellen einfacher war als bei den größeren. Aber Geschwindigkeit gehört nicht zu den Vorteilen von Microcode. So waren auch die Spitzenmodelle des Systems 360 hardwarekodiert und das war der Standard damals bei den Mikroprozessoren.

Microcode machte die Rechnungen mit den Fließkommaoperationen überhaupt erst möglich. Für eine Hardware Lösung hätte man noch mehr Transistoren benötigt. Als für 8086 der numerische Coprozessor 8087 erschien, im Prinzip nur eine Arithmetrisch-Logische Einheit (ALU) für Fließkommaoperationen, benötigte diese 45.000 Transistoren, während der Hauptprozessor 8086 der außer der ALU noch Befehlsdekodierer, Ein/-Ausgabeeinheit, Steuereinheit beinhaltete, nur auf 29.000 Transistoren kam. Trotzdem war Microcode bei diesen komplexen Operationen immer noch erheblich schneller, als wenn eine Programmiersprache die Berechnungen durch ein Maschinensprachenprogramm ausführte, denn das Lesen und Dekodieren der Anweisungen fiel weg. Für normale einfache Anweisungen, die bei den meisten Programmen dominierten, bedeutete Microcode eine Verlangsamung.

In den Prozessoren hatte jede eigenständige Untereinheit ein eigenes Microcode ROM. Jede Microinstruktion hatte eine Breite von 16 Bit und auch die beiden GDP tauschen über mehre Busse 16 Bit Mikroinstruktionen aus. Die GDP hatten jeweils ein 4K und 2K großes Microcode ROM, der IP zwei je 2 K große Mikrocode ROMs. Zusammen also 16 K x 16 Bit = 32 KByte. Zum Vergleich, ein langsamer 32 Bit Mikroprozessor der IBM 360 Serie hatte einen 2 K x 48 Bit Microcode, also nur 12 KByte.

Schwächen

Neben dem hehren Anspruch einen Großrechner auf einem Chip abzubilden (den Intel einige Jahre mit der „Cray on a Chip, dem Prozessor Intel 860 wiederholen sollte) hatte das Design einige Mängel. Intel sparte Transistoren da ein, wo es ging, schließlich passte ja nicht alles auf einen Chip als man an die Entwicklung ging, aber es sollten kein Dutzend werden. Das beschränkte die Leistung.

Die ALU war eine 16 Bit ALU, führte daher alle 32 Bit Operationen in mehreren Schritten durch. Diese dauerten so systembedingt immer länger als bei einer 32 Bit breiten ALU. Ebenso kommunizierten die drei Prozessoren, wahrscheinlich damit sie in ein 64 Pin Gehäuse passten nur mit 16 Bit. Auch der Microcode war nur 16 Bit breit, sodass man eher von einem intern 16 Bit arbeitenden Prozessor mit einem 32 Bit Datenbus sprechen sollte.

Die Fähigkeiten zur Adressierung die zum einen fortschrittlich durch die logische Adressierung und die Unterstützung von virtuellem Speicher war wurden aber dahingehend beschnitten, das nur so über den Speicher zugegriffen werden konnte und jedes Segment maximal 64 Kbyte groß war, ebenfalls eine Folge des internen 16 Bit Aufbaus. Das war vor allem ein Problem für große Datenstrukturen wie Arrays. Der 8086 hatte auch diesen Zugriff über Segmente auf den Speicher und in Anwendungsprogrammen mussten die Programmierer große Klimmzüge unternehmen wenn eine Datenstruktur mehr als ein Segment belegt, weil man dann diese nicht mehr linear abarbeiten konnte, sondern bei jeder Operation prüfen musste ob man nicht das Segment wechseln muss.

Es gab maximal 2²⁴ Instruction Objekte, die aber mehrere Instruktionen umfassten. Typisch war ein Instruction Objekt eine Prozedur oder ein Unterprogramm in einer höheren Programmiersprache. So fortschrittlich die Organisation in Objekten war, sie war der Zeit weit voraus. Ein rein objektorientiertes Betriebssystem gibt es bis heute nicht (damals gab es eines, das war das in Smalltalk programmierte Betriebssystem des Xerox Alto). Bis die Vorteile eines objektorientierten Systems das auch Objekte für typische Betriebssystemstrukturen wie Kontextobjekte eines Prozesses und Unterstützung für Rechte (in Form des Access Feldes eines Objektes) auch bei einem Mutli-Tasking Betriebssystem benötigt wurden, sollte es Jahre dauern. Das grundlegende Problem war, das Intel Mikroprozessoren verkaufte, man aber für das Nutzen der Fähigkeiten des iAPX432 einen kompletten Rechner mit einem entsprechenden Betriebssystem benötigte. Das erforderte einen hohen Entwicklungsaufwand, der sich vielleicht bei einem teuren Rechner der mehrere Benutzer bediente lohnte, aber das war dann ein Minicomputer und die Hersteller dieser Rechner fertigten ihre eigenen CPUs.

Für Kunden die um den Prozessor herum einen Rechner bauten, eben den typischen PC zählte vielmehr der Preis und die Leistungsfähigkeit.

Bei der klassischen Programmierung, wo im Prinzip jeder Befehl ein eigenes Objekt war, war von Nachteil, das die Instruktionen beim Intel 8800 eine variable Länge hatten. Dies ist dahingehend gemeint, dass Instruktionen nicht ein Vielfaches eines Bytes oder Wortes lang waren, sondern mitten in einem Byte anfangen und aufhören konnten. Instruktionen waren beim Intel 8800 zwischen 6 und 321 Bits lang. Dieses Feature sollte wohl es erlauben, die Instruktionen in einem Instruction Objekt eng zu packen, da man so keine Füllbits hatte, es verlangsamte die Ausführung aber beträchtlich.

Der Prozessor hatte keinen Cache. Das bedeutete, dass er die Statusinformtionen die er zu jedem Objekt benötigte, laufend aus dem Speicher holen musste anstatt sie intern zwischenzuspeichern. Gleiches galt für die Tabellen mit denen man physikalischen auf logischen Speicher mappte. Bei einer Architektur die viel auf den Speicher zugreift ist ein Cache üblich. Der Intel 80386 als erster 32 Bit Prozessor der x86 Linie hatte einen internen Support für einen externen Cache. Bei der Motorola MC 68020 fehlte dieser, ihr Nachfolger die MC 68030 hatte dann aber einen integrierten Cache. Auch die Stackarchitektur, bei der nur die obersten 16 Bits lokal im Prozessor waren, tat ihr übriges. Dabei griff der 8800 nicht gerade schnell auf den Speicher zu. Ein Speichertransfer benötigte für 32 Bits 15 Zyklen, davon alleine 6 Wartezyklen. Ein 80286 benötigte für die 16 Bit lange Instruktion MOV Reg,Word dagegen nur 2 Takte.

Die Wahl von Ada als primäre Sprache, war ebenso ein Fehler. Ada war noch ganz neu. Der erste Standard erschien erst 1983, das heißt zwei Jahre nach dem iAPX 432. Es war zu viel verlangt von einem Systementwickler das er nun anfing nicht nur Anwendungsprogramme, sondern auch die Systemsoftware in einer völlig neuen Programmiersprache zu schreiben. Hätte man auf „C“ als Programmiersprache gesetzt, so wäre dies sicher anders gewesen. Besonders ergab eine Untersuchung des ADA-Compilers das dieser sehr langsamen Code produzierte. Ada ist eine relativ komplexe Sprache, mit dem Anspruch alle anderen Hochsprachen zu ersetzen. Die vielen Sprachfeatures führten dazu, dass der Compiler für Ada sehr langsamen Code produzierte, zumal die Sprache jung war und es noch nicht viele Erfahrungen mit ihr gab, bzw. wie man einen schnellen Compiler schreibt.

Standard war es bei anderen Prozessoren dagegen das diese in Maschinensprache programmiert wurden in denen man die Vorzüge der Architektur voll ausnutzen konnte.

In der Summe war der Prozessor durch diese komplexe Innenarchitektur relativ langsam. Es gab Vergleiche mit den damals aktuellen 16 Bit Prozessoren 80286 und MC 68000. In diesen sah er nicht gut aus. Die folgende Tabelle gibt die Ausführungszeit von verschiedenen Benchmarks in Mikrosekunden auf beiden Intel Prozessoren der damaligen Zeit wieder.

Eine andere Untersuchung der Geschwindigkeit ergab folgendes:

Der Minicomputer VAX 11/780 ist die Rechnerklasse in der sich Intel mit der Bezeichnung „Micro-Mainframe“ einordnet. Angesichts der Preise für die Prozessoren würde ein fertiges System auch preislich eher bei den Minicomputern liegen.

Eine genaue Analyse des Codes sowie der verursachten Langsamkeit ergab, das der 432 im Schnitt 35 bis 45 Prozent seiner Performance verschwendete. Das variierte in verschiedenen Benchmarks sehr stark und konnte beim bekannten Dhrystone Benchmark über 90 Prozent erreichen, bei anderen nur 5 Prozent. Davon entfielen 25 bis 35 Prozent auf den ineffizienten ADA Compiler und 5 bis 10 Prozent auf mögliche Verbesserungen des Prozessors.

Im Schnitt war der iAPX 432 in der Praxis um den Faktor 4 langsamer als der 80286, der aber erheblich preiswerter war. Hätte man beide Prozessoren in ADA anstatt Maschinensprache programmiert wäre das Missverhältnis wahrscheinlich nicht so groß gewesen. Gegenüber dem noch schnelleren MC 68000 soll das Verhältnis zwischen 5 und 10 gelegen haben. Dabei war der Prozessor teuer. 1984 kostete bei Abnahme von mindestens 1.000 Stück die drei Chips die den iAPX 432 bildeten 1.267 Dollar, ein Intel 8086, der immer noch schneller war als der iAPX 432, lag dagegen zu diesem Zeitpunkt bei 30 Dollar. 1984 kam dann von Motorola die MC 68020, ein 32 Bit Mikroprozessor heraus, gefolgt im nächsten Jahr von der Intel 80386.

Erst recht war die Performance verglichen mit den Minicomputern schlecht, denn Intel kündigte den Chip ja als „Großrechner auf einem Chip“ an. 1983 erschien auch von DEC die erste Microvax, eine VAX 780 nur war die gesamte CPU auf einem Chip untergebracht. Dies war nun ein Minicomputer auf einem Chip, etwas was Intel nicht fertigbrachte. In Benchmarks war sie in etwa so schnell wie ein MC 68000 und 20 % schneller als ein 80286, mithin um ein vielfaches schneller als der iAPX 432.

Intel versuchte in der kurzen zeit die der Prozessor angeboten wurde ihn zu verbessern, um die Mängel zu beseitigen. Zum einen vereinfachte man in den Revisionen des Prozessors den komplexen Aufbau der Objekte und lies größere Objekte zu mit bis zu 128 KByte pro Objekt – offensichtlich erzeugten Compiler nicht wie von Intel gedacht pro Prozedur ein Objekt sondern füllten den verfügbaren Platz eines Objektes voll mit Code bevor sie ein neues Objekt anfingen.

Auf der anderen Seite machte Intel keinerlei Anstalten die drei Bestandteile eines Prozessors auf einen Prozessor zu integrieren. Die drei Chips hatten in etwa so viele Transistoren wie ein 80286 Prozessor, würden also auf ein Die passen. Stattdessen präsentierten sie neue Bausteine, die man nur für ein großes System brauchte. Die Bus Inferace Unit (BIU, 43204) erhält von einem der drei Bestandteile des Kernprozessor Speicheranforderungen und entscheidet welches Speichermodul angesprochen wird, es sorgt dafür das der Speicherbus optimal ausgelastet wird und leitet innerhalb des Systems Fehler weiter. Eine solche Einheit war bei Großrechnern üblich, die anders als ein PC mehrere Speichermodule hatten, oft konnte man den Rechner auch nachträglich um Speichermodule erweitern. Dann kann man die Geschwindigkeit eines Systems beschleunigen indem man die Zugriffe auf die Module verteilt. Es spricht viel aus den Reviews, das der Speichertransfer ein wunder Punkt des iAPX 432 war. Der billige dynamische RAM Speicher benötigt nach jedem Zugriff eine gewisse Zeit bis er den Ursprungszustand wiederhergestellt hat, beim Gegenstück dem 8086 griff dieser nur in der ersten Hälfte des Befehlszyklus auf den Speicher zu und dieser hatte so diese Erholzeit. Wenn der IP aber permanent Daten liest, so überfordert er den Speicher und muss waren – oder er kann die Zugriffe abwechselnd auf mehrere Module verteilen. Daher hatte der Intel 8800 bei einem 32 Bit Speicherzugriff auch 6 Wartetakte – das waren 30 % der Gesamtzeit von 15 Takten für den Speichertransfer.

Die Memory Controll Unit (MCU, 43205) führte im Mikrocomputerbereich Features ein, die es sonst bei Großrechnern nicht gab. Sie wurde zwischen Speichermodule und Speicherbus geschaltet. Sie führte die Fehlerkorrektur und Fehlererkennung ein. Zu je 32 Bits speicherte sie 7 weitere Bits ECC Information und ein Sparebit. Mittels ECC können Speicherfehler erkannt werden. Unabhängig vom Zugriff überprüfte sie dauernd die Speicherzellen und korrigierte 1 Bit Fehler und meldete 2 Bit Fehler, die sie nicht korrigieren konnte. Sie führte zudem den Refresh von RAM Bausteinen durch. Intel verweist als Vorteil, dass man so auch teilweise fehlerhafte RAM einsetzen kann. Der Autor hat da seine Zweifel. In der Liga in der Intel mitspielen wollte, also bei Mini- und Großrechnern war Speicher das preiswerteste am System und man würde fehlerhafte Module ersetzen. Immerhin war so ein fehlertolerantes System aufbaubar das bei einem Fehler nicht ausfiel.

Anders als GDP und IU konnte es mehrere BIU und MCU im System geben. Pro RAM Bank eine MCU, pro Teileprozessor eine BIU und wenn mehrere Busse verbunden wurden, weitere BIU.

Resümee

Intel war in der Funktionsweise des Prozessors seiner Zeit um Jahre voraus. Das grundlegende Problem war aber, dass dadurch die Geschwindigkeit enorm litt, so stark, das man auch bei gutem Willen keinen kommerziellen Einsatzzweck finden kann, zumal die Prozessoren sehr teuer waren.

In der Retrospektive scheiterte der iAPX 432 an mehreren Faktoren. Zum einen war die grundlegende Performance des Prozessors nicht sehr hoch, das kostete den Massenmarkt, wo in einem PC eben ein Prozessor steckte und dieser für die Leistung des Systems verantwortlich war.

Im Markt den Intel anvisierte – dem der Minicomputer und Großrechnern - wäre das Zusammenfassen mehrerer Prozessoren preislich durchaus eine Option gewesen und zumindest bei Großcomputern auch gang und gäbe. Doch auch hier war er zu langsam und seine Architektur zu fortschrittlich. An der Langsamkeit Schuld hatten auch die Compiler. Die meisten programmierten nicht in Ada, sondern C oder Pascal und deren Compiler verfolgten den Architekturansatz den sie von anderen Architekturen kannten. Sie benutzten so oft Befehle, die sie als Analoga zu Befehlen anderer Architekturen ansahen, diese waren aber oft die langsameren Instruktionen.

Der Chip hätte eigentlich nur eine Chance gehabt, wenn Intel selbst einen Computer auf dessen Basis entworfen und auf den Markt gebracht hätte, der die Vorteile des Systems voll ausgenutzt hätte und die Nachteile vermied. Das tat Intel aber nicht. Es gab, wie bei den früheren Prozessoren Musterboards, in denen ein Minimalsystem implementiert war. Sie dienten als Vorlage um ein komplexeres eigenes System aufzubauen. Intel schrieb dafür auch ein Betriebssystem IMAX.

Vergleicht man die folgenden Angaben von Intel über Ausführungszeiten, mit dem realen Ergebnis von Benchmarks, so fällt ein deutliches Missverhältnis auf:

Diese Werte sind nicht schlecht. Vor allem, wenn man die Werte für die Fließkommazahlen ansieht, die andere Prozessoren per Software berechnen mussten, was noch langsamer als der Microcode des iAPX 432 ist. Ich habe noch Werte eines alten Benchmarks von 1987 wo man in einer Schleife nichts weiter tut als 10.000 mal eine Addition, Subtraktion, Division und Multiplikation durchzuführen. Nimmt man obige Zahlen so benötigt der iAPX 432 dafür rund 1,15 Sekunden. Ohne Coprozessor in Software mit Turbo Pascal 3.02 kommt erst ein mit 40 MHz getakteter 386 auf ähnliche Zeiten. Ein 80286 mit 8 MHz liegt bei etwa 8 Sekunden, ein 8086 mit 8 MHz bei fast 16 Sekunden.

Eventuell sah Intel den Einsatzzweck des Chips tatsächlich in dem Anwendungsfeld von Großrechnern, wo Fließkommaoperationen eine große Rolle spielen. Leider war dies bei den damals verbreiteten Mikroprozessoren aber nicht der Fall. Bei den vergleichsweise langen internen Ausführungszeiten von 19 bis 48 Mikrosekunden, verglichen mit 0,5 Mikrosekunden für eine 32 Bit Addition/Subtraktion spielten dann der langsame Speichertransfer und andere Architekturunzulänglichkeiten nicht die Rolle, wie bei den Ganzzahlberechnungen.

Allerdings kam auch hier der Chip auf nur durchschnittlich 36 Kflops und war weit von der Leistung von Großrechnern im Bereich Mflops entfernt.

Etwa zeitgleich begannen viele Firmen eine entgegengesetzte Richtung zu verfolgen. Der iAPX war, wie die x86 Linie ein typischer CISC Vertreter - mit Instruktionen die viel konnten. Diese komplexen Instruktionen machten aber das Chipdesign aufwendig und teuer und vor allem für Start-Ups wurden die finanziellen Hürden so mit jeder Generation und immer mehr Transistoren pro Chip immer höher. Man begann neue Prozessoren in der RISC Architektur zu entwerfen – mit wenigen Befehlen, die aber schnell abgearbeitet wurden.

So entstand die MIPS Architektur, die SPARC von Sun, später der PowerPC von Motorola/IBM für den Motorola sogar ihre eigene Mc 68k Linie aufgab. Die erfolgreichste und heute in weitaus mehr Geräten vertretene Linie ist aber die ARM Architektur die sich in fast jedem Smartphone oder Tablett findet.

Links / Quellen

http://bitsavers.org/components/intel/iAPX_432/171821-001_Introduction_to_the_iAPX_432_Architecture_Aug81.pdf

http://www.bitsavers.org/components/intel/iAPX_432/171860-004_iAPX_432_General_Data_Processor_Architecture_Reference_Manual_Feb84.pdf

https://homes.cs.washington.edu/~levy/capabook/Chapter9.pdf

http://www.brouhaha.com/~eric/retrocomputing/intel/iAPX432/cs460/

https://wiki.edu.vn/wiki5/2020/11/27/intel-iAPX-432-wikipedia/

http://bitsavers.informatik.uni-stuttgart.de/components/intel/iAPX_432/210963-001_iAPX_43204_43205_Fault_Tolerant_Bus_Interface_and_Memory_Control_Units_Preliminary_Mar83.pdf

https://ieeexplore.ieee.org/document/5430762

https://cs.uwaterloo.ca/~Brecht/courses/702/Possible-Readings/oses/imax-multiprocessor-os-sosp-1981.pdf

https://homes.cs.washington.edu/~levy/capabook/Chapter9.pdf

http://www.bitsavers.org/components/intel/iAPX_432/171821-001_Introduction_to_the_iAPX_432_Architecture_Aug81.pdf

http://www.bitsavers.org/components/intel/iAPX_432/171867-001_Intel432_System_Summary_Managers_Perspective_Aug81.pdf

Artikel erstellt: 15.2.2022.

Zum Thema Computer ist auch von mir ein Buch erschienen. "Computergeschichte(n)" beinhaltet, das was der Titel aussagt: einzelne Episoden aus der Frühzeit des PC. Es sind Episoden aus den Lebensläufen von Ed Roberts, Bill Gates, Steve Jobs, Stephen Wozniak, Gary Kildall, Adam Osborne, Jack Tramiel und Chuck Peddle und wie sie den PC schufen.

Das Buch wird abgerundet durch eine kurze Erklärung der Computertechnik vor dem PC, sowie einer Zusammenfassung was danach geschah, als die Claims abgesteckt waren. Ich habe versucht ein Buch zu schreiben, dass sie dahingehend von anderen Büchern abhebt, dass es nicht nur Geschichte erzählt sondern auch erklärt warum bestimmte Produkte erfolgreich waren, also auf die Technik eingeht.

Die 2014 erschienene zweite Auflage wurde aktualisiert und leicht erweitert. Die umfangreichste Änderung ist ein 60 Seiten starkes Kapitel über Seymour Cray und die von ihm entworfenen Supercomputer. Bedingt durch Preissenkungen bei Neuauflagen ist es mit 19,90 Euro trotz gestiegenem Umfang um 5 Euro billiger als die erste Auflage. Es ist auch als e-Book für 10,99 Euro erschienen.

Mehr über das Buch auf dieser eigenen Seite.

Hier geht's zur Gesamtübersicht meiner Bücher mit direkten Links zum BOD-Buchshop. Die Bücher sind aber auch direkt im Buchhandel bestellbar (da ich über sehr spezielle Themen schreibe, wird man sie wohl kaum in der Auslage finden) und sie sind natürlich in den gängigen Online-Plattformen wie Amazon, Libri, Buecher.de erhältlich.

Sitemap

Kontakt

Impressum / Datenschutz

Neues

Hier werben / advertisment here

Buchshop

Bücher vom Autor