Intels Flops

Wer meine Website kennt, der weiß, dass ich genau einen Artikel mit diesem Titel dort schon habe. Aber weil viele eben nur den Blog besuchen gibt es den Inhalt eben doppelt, vielleicht auch etwas Neues. Denn ich habe gerade eine kleine Serie fertigstellt, in der ich die dort vorgestellten Prozessoren genauer betrachtet habe und da liegt eine erneute Auseinandersetzung mit dem Thema auf der Hand.

Um was geht es? Intel ist seit 1981 erfolgreich mit der x86-Linie, dazu morgen später mehr, hat in den vergangenen 45 Jahren aber einige Male auf das falsche Pferd gesetzt wobei – wie ich meine – in den meisten Fällen der Misserfolg vorhersehbar war.

Der Intel 8085

Fangen wir an mit dem 8085, keinem richtigen Flop, aber nicht der Erfolg den sich Intel erhoffte. Der 8085 erschien 1976 als Nachfolger des 8080. Der 8080 war zwar der erste Prozessor auf dem Markt, aber der kurz danach erschienene Motorola 6800 und der etwas später auf den Markt gekommene MOS 6502 machten einiges besser. Der 8080 war auf zwei Bausteine angewiesen. Den 8224 Clockgenerator, weil man einen externen Kristall nicht direkt anschließen konnten und den 8228 Busgenerator zum Ansprechen der RAM und zum Verstärken der geringen Ströme der Pins. Daneben brauchte der 8080 drei Versorgungsspannungen. Alle drei Dinge machten die Konkurrenten besser. Sie kamen mit einer Spannung aus und benötigten keine Zusatzbausteine. Intel sah das Problem und schuf eine verbesserte Version des 8080, eben den 8085. Die drei Mankos wurden abgestellt. Der 8085 hatte zudem vier weitere Pins für Interrupts, davon waren drei maskierbar und einer nicht. Daneben hatte er zwei serielle Leitungen. Er war ansonsten Befehlskompatibel zum 8080 und hatte nur zwei neue Befehle um die Interruptmaske zu setzen oder abzufragen und die serielle Leitung abzufragen / ein Bit auf die Leitung schreiben (es waren nur zwei Befehle, weil man ein Bit in der Interruptmaske nicht benötigte und das dann für die serielle Leitung verwendet wurde. Mehr gab es nicht an Änderungen, obwohl es noch freie Opcodes gab. Warum nutzte Intel die nicht für neue Befehle? Man hatte schon beschlossen den 8086, als Nachfolger zu entwickeln und der sollte alle Befehle des 8080 als Subset enthalten, damit man maschinell ein Assemblerprogramm des 8080 für den 80986 übersetzen konnte – ein kluger Schachzug denn so gab es bald nach der Veröffentlichung von PC-DOS viele Programme die durch Crossassemblieren aus CP/M Programmen entstanden.

Zum Verhängnis wurde dem 8085, das zwei Monate später der Z80 auf den Markt kam. Auch er softwarekompatibel zum 8080, aber mit erheblich mehr und teilweise sehr komplexen Befehlen, ebenfalls ohne die Mankos des 8080 und zusätzlich konnte er noch den Refresh für RAMs selbst erzeugen, das konnten weder 8080 noch 8085. Tja und das Bessere ist der Feind des Guten. Es erschienen nur wenige Rechner auf Basis des 8085. Meistens portable Rechner da es sehr bald eine stromsparende CMOS-Version gab. Er hatte trotzdem ein langes Leben, weil er in zwei langlebigen Produkten, dem Terminal VT-102 und einem Bandkontroller von DEC verbaut war und er steckte in erstaunlich vielen Raummissionen und flog sogar zum Mars. Das hat der Z80 nie geschafft.

Der iAPX 432

Der nächste Flop war von allen der größte. Angesichts der Konkurrenz die sich auftat und angekündigten 16 Bit Prozessoren beschloss Intel die 16 Bit Generation komplett zu überspringen und gleich einen 32 Bit Prozessor zu designen. Aber nicht nur einen einfachen 32 Bit Prozessor. Nein er sollte gleich auch Fließkommaoperationen durchführen (wenngleich nur per Microcode), er sollte objektorientiert sein und Prozesse unterstützen. Beworben wurde er in der Klasse von Mainframes. Es dauerte lange den Prozessor zu entwickeln, der schließlich unter der Bezeichnung iAPX 432 der 1981 herauskam. Was herauskam passte nicht auf einem Chip, der Prozessor benötigte davon gleich drei. Was er nicht war, war das er schnell war und das ist eigentlich die Kerneigenschaften eines Prozessors. Er wunde mit dem schon vorhandenen Motorola MC 68000 verglichen, auch mit Intels 8086 und als ein Jahr später der 80286 kam auch mit diesem. Immer zog er den kürzeren. Er war fünf bis zehnmal langsamer als die beiden schnelleren Konkurrenten und immer noch langsamer als der 8086.

Es gab dafür nicht einen, sondern viele Gründe. Einer war das Intel ADA als Programmiersprache wählte, der ADA-Compiler aber langsame Programme erzeugte. Ein zweiter Grund war das der Prozessor intern, als Stack-Maschine arbeitete, der Stack befand sich aber im Arbeitsspeicher und das machte viele Zugriffe nötig de zudem langsam waren. Das grundlegende Problem war, das Intel den Prozessor einsortiere bei den Minicomputern und Großrechnern, daher auch die Features für Prozesskommunikation. Der grundlegende Gedanke war wohl, dass der Prozessor selbst nicht so schnell ist, aber er unterstützte es das verschiedene Prozessoren auf den Bus zugriffen. Intel dachte sich wohl, die Kunden würden dann einfach ihr System aus zwei oder noch mehr Prozessoren aufbauen. Nur war Intels Kundenstamm eben nicht der, der Minicomputer oder Großrechner entwickelte. Der iAPX 432 erschien 1981, schon 1985 wurde seine Produktion beendet.

Der I860

Wurde schon der iAPX 432 als „Microframe“ (von „Mainframe = Großrechner) bezeichnet, so legte Intel beim i860 noch eine Schippe bei der Werbung drauf und bewarb ihn als „Cray on a Chip“. Der i860 war ein reinrassiger 64 Bit RISC Prozessor und das schon 1989. In ihm wurde viel richtig gemacht. Er hatte viele Register, eine integrierte Fließkommarecheneinheit, benötigte also keinen Coprozessor, hatte sogar den Vorgänger von MMX an Bord – eine Graphics Engine verarbeitete anstatt 64 Bit Zahlen acht 8 Bit oder vier 16 Bit oder zwei 32 Bit Zahlen, jeweils als Ganzzahlen. Damit sollte sie schnell in einem Bildschirmspeicher Muster setzen und füllen können. Die Bezeichnung „Cray on a Chip“ bekam Intel deswegen, weil die Fließkommaeinheiten mit den Registern gepipelint werden konnten. Das bedeutet pro Takt landete ein neuer Wert in den Registern und diese kopierten die Werte jeweils um ein Register weiter und übergaben das letzte Register an die FPU. Pro Takt kam sie in diesem Modus der spezielle Maschinenbefehle erforderte auf 1 FLOP, bei 33 bis 50 MHz die der Prozessor getaktet war, also maximal 50 Mflops – nicht ganz die Performance einer Cray 1, die damals auch schon veraltet war (die schaffte maximal 160 Mflops), aber doch zumindest die gleiche Größenordnung.

Der Prozessor war in jedem Falle erheblich schneller als der zeitgleich auf den Markt gekommene 486 Prozessor und hatte mit 1 Million Transistoren zwar für einen RISC Prozessor eine ziemliche Komplexität aber immer noch weniger als der 486 (1,2, Millionen).

Warum wurde er nicht zum Verkaufserfolg?

Ein Problem, das man aber abstellen konnte und bei der zweiten Generation auch abmilderte, waren zu kleine Caches. Im Pipeline Mode liefen sie regelmäßig leer. Compiler erzeugten auch nicht den Code der die volle Geschwindigkeit erreichte, aber immerhin 10 MFLOPs, das ist um ein vielfaches schneller als ein 486-er.

Das eigentliche Problem war, das er eine völlig neue Architektur war, mit einem völlig neues Befehlssatz. Er emulierte auch keinen anderen Befehlssatz. Seitens Intel gab es nur Crosscompiler die auf x86-Systemen liefen. So konnte man vielleicht noch vor zehn Jahren einen neuen Prozessor auf den Markt bringen 1989 ging das nicht mehr. Kein Hardwarehersteller schreibt auch das ganze Betriebssystem und alle Systemprogramme. Andy Grove, damals CEO von Intel umschrieb das Problem so:

„We now had two very powerful chips that we were introducing at just about the same time: the 486, largely based on CISC technology and compatible with all the PC software, and the i860, based on RISC technology, which was very fast but compatible with nothing. We didn’t know what to do. So we introduced both, figuring we’d let the marketplace decide. … our equivocation caused our customers to wonder what Intel really stood for, the 486 or i860?“

Der i860 wäre wohl ein Erfolg geworden, hätte Intel sich rechtzeitig um Allianzen mit Softwareherstellern gekümmert, so aber stellte Intel die Produktion nach wenigen Jahren Mitte der Neunzigern wieder ein.

Der Itanium

Der wohl bekannteste FLOP von Intel war der Itanium. HP fing mit der Entwicklung an um einen Nachfolger für die PA-RISC Serie zu lancieren. Intel fand das Konzept gut und beteiligte sich und fertigte später auch alle Chips, wobei aber HP Hauptabnehmer blieb.

Der Itanium war ein 64 Bit Prozessor mit auf dem Papier beeindruckenden Daten. Er hatte massenweise Register, die er dynamisch zuweisen konnte, viel mehr Ports und interne Funktionseinheiten als die damaligen x86 Prozessoren, er konnte Befehle bedingt ausführen, also abhängig, ob eine Bedingung erfüllt ist und so Sprünge vermeiden. Das herausragende war aber eine neue Architektur: VLIW die bei Intel EPIC hieß. In einem VLIW wurden drei Befehle in einem langen 128 Bit Wort untergebracht und einige Statusbits informierten über Art der Befehle und Abhängigkeit. Der grundlegende Gedanke war, das der Compiler so die Befehle so anordnet, dass der Prozessor voll ausgelastet ist. Das war nötig, denn der Itanium konnte selbst nicht Befehle umsortieren, im Fachjargon er war eine „In-order“ Architektur.

Das war ein Grund, warum er scheiterte. Denn die Compiler brachten es nicht fertig, den optimalen Code zu erzeugen. In einem Test der ct’ lieferte der Intel C-Compiler dreimal schnellere Programme als der von Microsoft und der von HP nochmals 40 Prozent mehr Performance. Immerhin hatte Intel hinzugelernt und Microsoft hinzugenommen. Es gab vom Start weg eine Version von Windows XP für den Itanium, HP passte ihr HP-UX an und später erschienen auch noch Windows Server 2003 und 2008 für den Itanium. Intel baute eigens eine – wenn auch wegen der komplett anderen Architektur quälend langsame Emulator von 32 Bit x86 Code ein – man hatte aus dem Fiasko mit dem i860 gelernt. HP baute in sein Betriebssystem nur eine Softwareemulation ein, die jedoch so gut war, das der PA-RISC Code deutlich schneller als der IA32 Code lief.

Die erste Version Codename „Merced“ war jedoch sehr langsam. Das wurde auch so erwartet, Intel wusste das. Nur kam sie fünf Jahre zu spät und fortan hinkte der Itanium laufend seinen Konkurrenten hinterher. Merced erschien z.B. 2001 mit 800 MHz Takt als die x86 Linie schon 1.200 und 1.400 MHz Takt erreichte (Pentium III/Athlon). Die internen Caches waren viel kleiner als bei der x86 Linie, und das obwohl durch das VLIW doppelt so viele Daten bei einem Zugriff angefordert wurden.

Die nächste Version „McKinley“ hatte dann den vorher externen Level 3 Cache auf dem Die integriert und die Caches vergrößert, nur lief auch sie mit gerade Mal 1 GHz. Die Transistorzahl stieg enorm von 25 auf (je nach Cachegröße) 225 – 325 Millionen und billig zu produzieren war der Itanium so nicht.

Es folgten noch etliche Nachfolger, HP bezahlte schließlich sogar Intel, damit sie den Chip weiter entwickelten. Doch lediglich zwischen 2006 und 2008 konnte der Montecito/Montvale Kern in etwa zu aktuellen Architekturen aufschließen, in dieser Zeit gab es auch den größten Marktanteil an verkauften Systemen.

In der Retrospektive frickelte Intel beim Itanium immer an Ecken herum anstatt den Kern des Problems anzugehen. Die Caches wurden mehrfach vergrößert, sodass die letzte Version sogar 3,1 Milliarden Transistoren hatte. Es gab zwei, dann vier oder acht Kerne. Aber man änderte nie, das der Prozessor intern nur ein In-Order Architektur hatte. Das ist aber änderbar, Intel hat in der x86 Linie beide Architekturen – In-Order für die billigen Atoms und Out-of-Order für alle besseren Prozessoren. Zudem gelang es nie den Takt stark zu erhöhen. Die letzte Version die 2017 erschien, schaffte gerade mal 2,53 GHz Maximaltakt.

2019 kündigte Intel an die Produktion einzustellen, HP, seit 2015 einziger Hersteller von Itanium-Servern hatte schon 2018 keine Systeme mehr mit dem Prozessor produziert und seit 2020 ist der Itanium Geschichte. Die Entwicklung soll Intel 10 Milliarden Dollar gekostet haben, was weit über den Umsatzerlösen der verkauften Prozessoren liegen dürfte, denn selbst im besten Jahr, 2008, wurden nicht mehr als 56.000 Itaniumsysteme verkauft, wenngleich da es Server waren, die meisten wahrscheinlich mit mehr als einer CPU.

Morgen dann von einigen, ja Flops kann man nicht sagen, aber von einigen Überraschungen in der x86 Linie.