ISSCC 2018 Prozessor-Legende und RISC-V-Erfinder stellt Google-TPU vor

Dier vier Keynote-Sprecher auf der ISSCC 2018. Yukihiro Kato (DENSO 2.v.l.), Barbara de Salvo (CEA-Leti 3.v.l.), Vincent Roche (CEO Analog Devices, 3.v.r.) und Prof. David Patterson (Google, 2.v.r.).
Dier vier Keynote-Sprecher auf der ISSCC 2018. Yukihiro Kato (DENSO 2.v.l.), Barbara de Salvo (CEA-Leti 3.v.l.), Vincent Roche (CEO Analog Devices, 3.v.r.) und Prof. David Patterson (Google, 2.v.r.).

Auf der weltweit führenden Chip-Konferenz ISSCC in San Francisco stellte Prof. David A. Patterson Googles "Wunder-Chip", eine sogenannte TPU, vor und erklärte, warum der RISC-Architektur "RISC-V" aus seiner Sicht die Zukunft gehört.

Bevor die Besucher der diesjährigen IEEE-Chip-Konferenz ISSCC2018 den vier Keynotes lauschen konnten, wurden wie üblich zunächst einmal wieder Zahlen präsentiert, die insbesondere die Rolle der Mikroelektronik in Deutschland wie schon lange in ein nicht zufriedenstellendes Bild rücken.

Während die Anzahl der zahlenden Teilnehmer gegenüber 2017 leicht von 3.019 auf 3.050 anstieg, kommen nur 12,1 % aus Europa, dafür 64,1 % aus Nordamerika und 23,8 % aus Asien. Von den eingereichten 610 Vorträgen fanden 207 den Weg ins Programm, was einer auch seit Jahren mehr oder weniger konstanten Rate von 33 % entspricht. Leider gibt es nur 35 Vorträge aus Europa und davon die meisten von den Forschungseinrichtungen IMEC bzw. CEA-Leti sowie Universitäten aus deren Umfeld. 88 Vorträge kommen aus Nordamerika und 79 aus Asien.

Im europäischen Programm-Kommitee, einer Untergruppe des Gesamt-Kommitees, finden sich insgesamt 36 Personen, davon drei aus Deutschland.

Eine Zeitreise durch das Computer-Zeitalter

Von den vier Keynotes stach zweifelsfrei die von Prof. David A. Patterson, ursprünglich Informatiker an der US-Eliteuniversität in Berkeley und jetzt auf der Gehaltsliste von Google, heraus.

An Hand einer Zeitreise durch das Computerzeitalter begründete Patterson, warum CISC-CPUs aber auch GPUs nicht mehr die Antwort auf den immer größeren Bedarf nach Rechenleistung sind und warum die von ihm erfundene RISC-V-Architektur ein neues Zeitalter des Computing begründen kann.

In den frühen 60er-Jahren gab es von IBM vier Mainframe-Architekturen, die allesamt inkompatibel zueinander waren. Mit einer damals neuen Art der Ablaufsteuerung mittels MIkro-Programmierung wurde das Ziel eines gemeinsamen Befehlssatzes (ISA) realisiert, indem jedes Modell einen eigenen ISA-Interpreter bekam, der in modellabhängigen Mikro-Instruktionen geschrieben war. Das billigste Modell nutzte 4.000 Mikro-Instruktionen mit jeweils 50 bit Breite, das teuerste 2800 mit jeweils 87 bit Breite.

Am 7. April 1964 kündigte IBM mit dem System/360 eine neue Familie an, deren Preis heute umgerechnet von 1.054.000 bis 43.570.000 Dollar gereicht hat.

Die 70er-Jahre waren die Zeit der CISC-Architekturen. RAM, ROM und Logik wurden aus denselben Transistoren gefertigt, die wachsenden ISAs erhielten leistungsfähigere Instruktionen, was zu einer höheren Fehleranfälligkeit führte. Daher wurde die Software vom ROM ins RAM verlagert, um Reparaturen einfacher durchführen zu können. Ein Highlight dieser Epoche war zweifellos DECs VAX-11/780, der am 25.10.1977 vorgestellt wurde. Der Rechner hatte 5120 Mikro-Instruktionen mit jeweils 96 bit Breite.

Intel mischt den Markt auf – mit dem “falschen” ISA

Intels Gründer Gordon Moore wollte im Jhr 1975, ein Jahr nach Fertigstellung des 8-bit-Prozessors 8080, ein ISA entwickeln, welches die “Lebensdauer der Firma” überdauert. Ohne Allzweckregister, dafür mit jeder beliebigen Länge einer Instruktion, einem 32-bit-Adressraum und einem in Ada entwickelten OS wurde das iAPX-432 im Jahr 1981 vorgestellt.

Leider passte das riesige Mikroprogramm nicht auf einen Chip, iAPX-432 war teuer, langsam und verspätet. In einer Art “Notfall-Projekt” entwickelte Intel den 16-bit-Prozessor 8086, der auf Assembler-Ebene kompatibel zum 8080 war, den Adressraum auf 20 bit erweiterte und dessen ISA in unfassbaren 3 Wochen mit einem Aufwand von nur 10 Personenwochen entwickelt wurde. Nach nur 52 Wochen war der Chip fertig, 1978 kam er ohne viel Hoffnung seitens Intel auf den Markt.

Zur gleichen Zeit wollte IBM einen Wettbewerber gegen den Apple I bauen und zwar mit Motorolas CPU 68000. Nachdem es bei dessen Entwicklung Verzögerungen gab, setzte IBM den 8086 ein. IBM plante den Verkauf von 250.000 PCs, tatsächlich wurden es 100 Millionen Stück.

Gordon Moore hatte Recht behalten, ein Intel-ISA dominierte die Zukunft. Allerdings nicht das gescheiterte und 1986 abgekündigte iAPX-432, sondern der 8086 und dessen 1985 vorgestellter 32-bit-Nachfolger 80386.

RISC-Computer – einfach und schnell

Ingenieure bei DEC hatten festgestellt, dass 20 % aller VAX-Instruktionen für 60 % des Mikrocodes stehen, aber nur für 0,2 % der Ausführungszeit. In einem Experiment entwickelte IBM einen Compiler für das System/370, der nur Register-zu-Register-Operationen und Lade-/Speicherbefehle umsetzte. Die Programme liefen damit erheblich schneller als auf denen, die das komplette ISA nutzten. Die Idee war nun, ein ISA zu entwickeln, das so einfach war, dass es keinen Mikro-Code-Interpreter brauchte. Ein weiterer Vorteil bestand darin, dass man einfacher Pipeline-Architekturen bauen konnte, was zu höheren Taktfrequenzen führte.

Skeptiker zweifelten an RISC, da es mehr Instruktionen braucht als CISC. Die Formel für den Zeitbedarf eines Programms lässt sich wie folgt errechnen:

Instruktionen/Programm x Taktzyklen/Instruktion x Zeit/Taktzyklus

DEC fand heraus, dass bei der VAX RISC gegenüber CISC bei gleicher Taktfrequenz einen Geschwindigkeitsvorteil von 3 brachte. Zwar wurden bei RISC doppelt soviele Befehle ausgeführt, die aber nur ein Sechtel der Taktzyklen pro Instruktion benötigt. Die Geburtsstunde für ARM, MIPS, Power und SPARC war gekommen.

Fazit: CISC vs. RISC aus heutiger Sicht

Über interne RISC-ähnliche Instruktionen, genannt Mikro-Ops, konnte Intel an den Fortschritten der RISC-Architekturen partizipieren. Schrumpfende Fertigungsgrößen der Chips und damit einhergehende Kosten- und Energieeinsparungen ließen die x86-Architektur den PC- und Server-Markt dominieren. Für den Embedded-Markt, wo jährlich Milliarden Chips verkauft werden, waren sie freilich immer noch zu teuer. Chips mit RISC-Architekturen wachsen jährlich um 24 %, seit 2007, als das erste iPhone vorgestellt wurde, haben sich die Zahlen versiebenfacht.

Die x86-Lieferungen hatten im Jahr 2011 mit 365 Mio. Stück ihren Höhepunkt. Seitdem gehen die Stückzahlen im Schnitt um 8 % pro Jahr zurück. Intel und AMD haben 2016 zusammen weniger x86-Chips verkauft als 2007.

Und was ist mit der Cloud? Prof. Patterson schätzt die Installationen bei Google, Microsoft und Amazon zusammen auf 10 Mio. Server. Die CPUs sind teuer, aber ihr Volumen vernachlässigbar. 10 Mio. RISC-Chips werden alle 4 Stunden ausgeliefert.

Das VLIW-Desaster: Intel wieder am Abgrund

Wer anderen eine Grube gräbt, fällt selbst hinein, sagt ein altes Sprichwort. Nachdem die 32-bit-x86-Architektur MItte der 90er Jahre drohte, die zunehmenden Anforderungen der Software nicht mehr bedienen zu können, hätte Intel einfach auf 64 bit erweitern können. Stattdessen wollte man ISA-Partner AMD loswerden und setzte auf ein neues ISA, das auf VLIW (Very-Long-Instruction-Word) setzte. Diese Befehle sind länger als 100 bit und bündeln mehrere Operationen wie z.B. zwei Integer-Berechnungen, zwei Speicherzugriffe und zwei Gleitkommaberechnungen. Der erste Prozessor sollte 1997 geliefert werden, stattdessen wurde 1999 erstmal der Name “Itanium” angekündigt. Geliefert wurde er erst 2001 mit katastrophalen Performance-Problemen, die sich aus drei Punkten ergaben: Die explodierende Codegröße führte zu mehr Cache-Misses, das Scheduling von VLIW-Code bei unvorhersagbaren Sprüngen und variierende Speicher-Latenzen durch unvorhersagbare Cache-Misses.

AMD blieb derweil nichts anderes übrig, als mit AMD64 ein 64-bit-x86-ISA durch Verbreiterung der Register zu entwickeln und ironischerweise musste Intel auf Grund der Itanium-Probleme den gleichen Weg gehen.

VLIW ist bei Allzweck-CPUs gescheitert, allerdings nicht bei DSPs. Diese haben normalerweise vergleichsweise kleine Programme, sehr vorhersehbare Sprünge und Programm-gesteuerte Speicherzugriffe statt Caches, so dass die Latenzzeiten konstant sind.