3.1 Einführung (1) Nahezu jeder Prozessor in einem Desktop-Rechner (der auf oder unter dem Tisch steht) und in einem Server- Rechner (auf dem man sich von der Ferne einloggt und dort rechnet) nutzt heute Caches (s. Kap. 2.3.3) Pipelining Superskalare Befehlsabarbeitung Out-of-order execution (Abarbeitung der Befehle entgegen der vom Compiler erzeugten Reihenfolge) Diese Prinzipien werden wir im Kapitel 3 behandelt 3.6.-17.6.2013, Folie 1
3.1 Einführung (2) Ferner: Evolution der Prozessor-Architektur Stationen dieser Evolution von CISC bis Multi-Core Complex Instruction Set Computing (CISC) Reduced Instruction Set Computing (RISC) Superskalare Architekturen Very long instruction Word (VLIW) Explicitly Parallel Instruction Computing (EPIC) Multithreading (Simultanes Multithreading (SMT) Hyperthreading (HT)) Multikern-Architekturen 3.6.-17.6.2013, Folie 2
3.2 CISC-Architekturen (1) Am Anfang war CISC (Complex Instruction Set Computer): Technik der Mikroprogrammierung ist CISC So benannt in den 1980er Jahren nachdem RISC aufkam Vorteile CISC: Erforderliche Speicherkapazität geringer es erfolgt Expansion eines CISC-Befehls im Prozessor Abbildung Makrobefehl -> Folge von Mikrobefehlen (Mikroprogramm) (s. Bsp. Folie 7, Kap. 2) A B A Könnte z.b so kodiert sein SUB A B 010 000 001 010 000 001 Kostet weniger Speicher als 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 3.6.-17.6.2013, Folie 3
3.2 CISC-Architekturen (2) Weiterer Vorteil: in den 60er Jahren vorhandene sog. semantische Lücke überbrückbar Durch Mikroprogramm einen Hochsprachen-Befehl implementieren Gilt für Chip-Hersteller und deren Compiler-Bauer Details zu semantischer Lücke, s. Vorlesung SP Beispiel: Switch-Befehl als Mikroprogramm Befehl in Hochsprache switch ( i ) { case 0 : a = 1 ; break ; case 1 : a = 2 ; break ; } ; Lücke durch Mikroprogramm überbrücken (fiktive Syntax) 0: i -> ACCU 1: if ACCU=0 JMP TO 6 2: DECR ACCU 4: if ACCU=0 JMP TO 8 5: RETURN 6: SET a=1 7: RETURN 8: SET a=2 9: RETURN nackte Menge der 10-Befehlsmuster der Maschine 0 0 1.. 0 1 0 0.. 1 1 0.. 1 0 1 0 Entsprechende Mikrobefehle 3.6.-17.6.2013, Folie 4
3.2 CISC-Architekturen (3) Lange Zeit der Zufriedenheit mit diesem Ansatz Konzept der Mikroprogrammierung zuerst in Großrechner eingeführt dort auf in der Kapazität limitierte Ferritkernspeicher ausgerichtet CISC Mikroprozessor-Architekturen waren dem Stand der Großrechnertechnik bis Anfang der 80er Jahre angepasst Gründe: wohl einfacher adaptierbar technologische Gründe für diese Orientierung gab es nicht, denn Mikroprozessoren waren von Anfang an mit Halbleiter-Arbeitsspeichern ausgestattet 3.6.-17.6.2013, Folie 5
3.2 CISC-Architekturen (4) Mit der Zeit: immer neue Prozessoren Erweiterung der Befehlssätze Zwang zur Abwärtskompatibilität Folge der Entwicklung immer größere und undurchschaubarere Befehlssätze Komplizierte Adressierungsarten (z.b. VAX11/780 verwendete 22 verschiedene Adressierungsarten) Befehle mit sehr unterschiedlichen Längen Compiler-Bauer verwendeten nur noch kleine Teilmenge des Befehlssatzes 3.6.-17.6.2013, Folie 6
3.2 CISC-Architekturen (5) Beispiel: Eigenschaften Befehlssätze CISC-Prozessoren 3.6.-17.6.2013, Folie 7
3.2 RISC-Architekturen (1) Die Zeit war reif für Neues: RISC-Prozessoren (Reduced Instruction Set Computer) Prozessoren der vierten Generation Vierte Generation: Hochintegration (VLSI - > 10 6 Transistoren) RISC-Architekturen gekennzeichnet durch Elementare und kleine, einheitliche Maschinenbefehlssätze einheitliche (dadurch aber auch redundante) Befehlsformate, die schnell dekodierbar sind Operanden- und Befehlsholphase während eines Grundtaktes ausführbar Adressrechnungen werden durch explizite Befehle ausgeführt Vorteil: keine komplizierten Adressierungsarten in Befehlen und damit verbundene Adressierungsberechnungen Load-Store-Architektur Alle Operanden liegen in Registern vor Keine Befehle, in denen ein Operand direkt auf Speicheradresse verweist Wenn nicht, dann Operanden laden bzw. speichern durch explizite Lade- /Speicherbefehle 3.6.-17.6.2013, Folie 8
3.2 RISC-Architekturen (2) große universelle Registersätze festverdrahtete Leitwerke kein Mikroprogramm; kein Mikroprogrammspeicher Schafft Platz auf dem Chip für Caches und Register Jeder RISC-Befehl wird direkt in binäres Befehlsmuster dekodiert konsequentes Ausnutzen von Fließbandverarbeitung (Pipelining) nach Möglichkeit alle Befehle bis auf Laden/Speichern innerhalb eines Taktes abzuwickeln (im Durchsatz) war später jedoch nicht mehr konsequent durchzuhalten (z.b. numerische Gleitkomma-Operationen) ab Pentium Pro wird in Intel-Prozessoren komplexer Maschinenbefehl intern in eine Folge einfacher nach dem RISC-Prinzip abzuarbeitender Befehle zerlegt Erforderlich: Zusammenspiel von optimierenden Compiler und RISC- Prozessor-Architektur, um Fließbandverarbeitung auch effizient auszunutzen 3.6.-17.6.2013, Folie 9
3.3.1 RISC-Architekturen Pipelining (1) Fließbandprinzip (Pipelining) Übertragung des z.b. in der Automobilindustrie angewandten Prinzips der überlappten Bearbeitung von Arbeitsteilschritten auf den Befehlszyklus eines Prozessors Phasen des Befehlszyklus streng synchron arbeitenden unabhängigen Teilwerken zuweisen jeder einzelne Befehl durchläuft sequentiell alle Teilwerke Gegenteil: Nicht zeitlich überlapptes Abarbeiten der Befehle (s. Bild) 3.6.-17.6.2013, Folie 10
3.3.1 RISC-Architekturen Pipelining (2) Elementare Phasen des Befehlszyklus : Befehl holen inkl. Befehlszähler inkrementieren : Befehl dekodieren OH: Operanden holen : Befehl ausführen ES: Ergebnisse zurückschreiben (in Register bzw. in Speicher bei Store- Operationen) inkl. Befehlszähler im Falle eines Sprungs überschreiben 5 Phasen 5 Teilwerke 1. Befehl OH ES 2. Befehl DE OH ES 3. Befehl Beispielhaft; kein ehernes Gesetz! kann in der Realität viel fein-granularer sein, z.b. Intel P4-Architekturen über 30 Stufen [in Hennessy/Patterson /OH zusammengefasst, extra Phase für Zugriff auf Arbeitsspeicher] Zeit 3.6.-17.6.2013, Folie 11
3.3.1 RISC-Architekturen Pipelining (3) überlapptes Arbeiten 1. Befehl OH ES 2. Befehl DE OH ES 3. Befehl Zeit OH ES 1. Befehl OP ES 2. Befehl OH ES 3. Befehl OH ES 4. Befehl Dauer eines Befehls mindestens genauso lang wie zuvor (Latenzzeit) evtl. länger, denn Fließband muss sich nach der langsamsten Komponente richten Durchschnitt (Durchsatz) steigt an im Idealfall auf das n-fache bei n Teilschritten 3.6.-17.6.2013, Folie 12
3.3.1 RISC-Architekturen Pipelining (4) Viele Eierköpfe gleichzeitig unterwegs 3.6.-17.6.2013, Folie 13
3.3.1 RISC-Architekturen Pipelining (5) Leistungssteigerung bei vier Befehlen? anstatt 20 Zeiteinheiten nur (bitte selbst überlegen wie viele) Zeiteinheiten Welche Leistungssteigerung ist (theoretisch) möglich? Allgemein gilt: jede Pipeline-Stufe verursacht gewissen Zusatz-Aufwand für Datenbewegung Zwischenspeicherung im Datenfluss zwischen einzelnen Stufen kritisch bei vielen Unterbrechungen im synchronen sequentiellen Ablauf Vorsicht: Steuerlogik zur Behandlung von Register- und Speicher- Abhängigkeiten steigt mit Zahl der Stufen Evtl. höherer Gatteraufwand für Steuerung der Stufen als für die Stufen selbst 3.6.-17.6.2013, Folie 14
3.3.1 RISC-Architekturen Pipelining (6) Pipeline dominiert von langsamster Stufe Zykluszeit t einer Pipeline (bestimmt zugleich Takt = 1 /t ) t max t i d t m d 1 i i k t m = maximale Stufen-Verzögerung k = Anzahl Stufen d = Zeitverzögerung bedingt durch Zwischenspeicherung Gesamtzeit T k zur Bearbeitung von n Instruktionen T k ( n 1) t k 3.6.-17.6.2013, Folie 15
3.3.1 RISC-Architekturen Pipelining (7) erreichbarer Speed-Up S k Verhältnis von Ausführungszeit T 1 ohne Pipeline zur Ausführungszeit T k in einer Pipeline mit k Stufen S k / nkt nk T1 Tk k ( n 1) t k ( n 1) lim n S k k nk ( n 1) k 3.6.-17.6.2013, Folie 16
3.3.1 RISC-Architekturen Pipelining (8) Kurvenverlauf des Speed-Up S k in Abhängigkeit der Anzahl Instruktionen n für verschieden große Anzahl an Stufen k Speed-Up 12 Stufen 9 Stufen 6 Stufen #Instruktionen (10^x) 3.6.-17.6.2013, Folie 17
3.3.1 RISC-Architekturen Pipelining (9) Je mehr Stufen um so später läuft Kurve in Sättigung Wunderbar: dann möglichst viele Pipelinestufen k realisieren? Damit ist auch höherer Chiptakt möglich Je mehr Stufen desto kürzere Laufwege von einer Stufe zur nächsten Kürzere Laufwege -> schnellerer Takt (Erklärung s. Skizze Tafel) Preis für potentiellen Gewinn zusätzlicher Pipeline-Stufen zu zahlen (s. nächste Folie) 3.6.-17.6.2013, Folie 18
3.3.1 RISC-Architekturen Pipelining (10) Anstieg HW-Kosten Zwischen Pipelinestufen müssen Daten gefangen werden wg. Entkopplung der einzelnen Stufen, d.h. zwischen einzelnen Stufen liegen Register Je mehr Stufen je mehr Register Pipeline-Einschwingphase erhöht sich je mehr Stufen gegeben Damit Anstieg der Latenzzeit pro Befehl Nicht so schlimm könnte durch höheren Durchsatz kompensiert werden Energieverbrauch nimmt zu Kein Beitrag zu GreenIT Wahrscheinlichkeit leerer Pipeline-Zyklen steigt bei Datenabhängigkeiten bei Verzweigungen 3.6.-17.6.2013, Folie 19
3.3.1 RISC-Architekturen Pipelining (11) Problem: Datenabhängigkeiten (sog. Datenhazards) Ein Befehl benötigt Ergebnis eines vorherigen Befehls, dessen Ergebnis noch nicht in die Register zurückgeschrieben wurde Beispiel: t 1 2 3 Befehle MUL R1, R2 R3 ADD R3, R1 R5 sind nacheinander in Pipeline OH 4 OH 5 ES 6 7 ES MUL R1,R2 R3 Details Vorlesung Rechnerarchitektur (2 + 2/4 SWS, 5/7.5 ECTS) 8 ADD R3, R1 R5 R1 R2 noch nicht in R3 zurückgeschrieben! Erfolgt erst zum Zeitpunkt 5 (ES-Phase MUL-Befehl) 3.6.-17.6.2013, Folie 20
3.3.1 RISC-Architekturen Pipelining (12) Probleme: Verzweigungen Sprünge (sog. Steuerungshazards) Nächster Befehl in Pipeline ist nicht der Richtige t 1 2 3 4 5 6 7 8 40: if (R1 == R2) jmp 72 OH ES 44: (R1 and R12) R5 OH ES 48: (R1 or R12) R5 OH ES 52: (R14 add R2) R2... OH ES 72: (R12 add R2) R2 Erst nach Zeitschritt 4 steht fest, wie Vergleich (R1==R2) ausgeht. Der nächste Befehl in der Pipeline steht an Adresse 44, evtl. falscher Befehl. Lösung: statische und dynamische Sprungvorhersagen (sog. Spekulative Befehlsausführung) Details: Vorlesung zur Lösung Steuerungs-/Sprunghazard Rechnerarchitektur 3.6.-17.6.2013, Folie 21
3.3.1 RISC-Architekturen Pipelining (13) Nochmaliges Beispiel Sprungbefehl (detailliertere strukturelle Sicht der Vorgänge in den Stufen) Zeitpunkt 0: 1.Stufe 2.Stufe 3.Stufe 4.Stufe OH 40: if (R1 == R2) jmp 72 44: (R1 and R12) R5 48: (R1 or R12) R5 52: (R14 add R2) R2.. Registerinhalte 72: (R12 add R2) R2 R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: 8 3.6.-17.6.2013, Folie 22
3.3.1 RISC-Architekturen Pipelining (14) Zeitpunkt 1: 1.Stufe 2.Stufe 3.Stufe 4.Stufe OH 44: (R1 and R12) R5 48: (R1 or R12) R5 40: if (R1 == R2) jmp 72 52: (R14 add R2) R2.. 72: (R12 add R2) R2 Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: 8 3.6.-17.6.2013, Folie 23
3.3.1 RISC-Architekturen Pipelining (15) Zeitpunkt 2: == -Vergleich ist auszuführen 1.Stufe 2.Stufe 3.Stufe 4.Stufe OH 48: (R1 or R12) R5 52: (R14 add R2) R2.. 72: (R12 add R2) R2 44: (R1 and R12) R5 40: if (R1 == R2) jmp 72 Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: 8 3.6.-17.6.2013, Folie 24
3.3.1 RISC-Architekturen Pipelining (16) Zeitpunkt 3: Operanden werden aus R1 und R2 geholt 1.Stufe 2.Stufe 3.Stufe 4.Stufe OH 52: (R14 add R2) R2.. 72: (R12 add R2) R2 48: (R1 or R12) R5 44: (R1 and R12) R5 40: if (0 == 0) 72 Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: 8 3.6.-17.6.2013, Folie 25
3.3.1 RISC-Architekturen Pipelining (17) Zeitpunkt 4: Ergebnis Vergleich wird berechnet 1.Stufe 2.Stufe 3.Stufe 4.Stufe OH.. 72: (R12 add R2) R2 52: (R14 add R2) R2 48: (0 or 15) R5 44: (0 and 15) R5 Ergebnis des Vergleichs 0==0 ist true Nächster Befehl in der Pipeline sollte somit 72 sein Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: 8 Der nächste Befehl in Stufe 3 ist aber Befehl 44 3.6.-17.6.2013, Folie 26
3.3.2 RISC-Architekturen Superskalare Architekturen (1) Weitere Entwicklung: Superskalare Recheneinheiten Gruppierung von mehreren Befehlen, die nach dem Fließbandprinzip abgearbeitet werden Vorsicht: Befehle müssen nicht synchron abgearbeitet werden! OH ES OH ES OH ES OH ES OH ES OH ES OH ES OH ES OH ES 1. Befehl 2. Befehl 3. Befehl 4. Befehl 5. Befehl 6. Befehl 7. Befehl 8. Befehl 9. Befehl Zeit 3.6.-17.6.2013, Folie 27
3.3.2 RISC-Architekturen Superskalare Architekturen (2) erfordert mehrere Rechenwerke heute Stand der Technik 3.6.-17.6.2013, Folie 28
3.3.2 RISC-Architekturen Superskalare Architekturen (3) Technik eigentlich alt: übernommen von Supercomputern (CDC6600) gleichzeitige Anwendung von Operationen auf einzelne Komponenten eines Vektors (Vektorrechner) nicht alle Operationen sind Vektoroperationen skalare Werte müssen auch berechnet werden dennoch Prozessor mit mehreren Rechenwerken besser als skalarer, eben superskalar Anwendung auf Befehle benötigt Befehlsgruppierer Umordnung sequentiell einlaufender Befehle zur Laufzeit, um sie parallel auszuführen (dynamische Parallelisierung) allgemeines Prinzip superskalarer Rechner!! keine direkte Parallelität (vom Compiler erzeugt) Herausziehen von Parallelität aus sequentiellem Befehlsstrom in der Hardware 3.6.-17.6.2013, Folie 29