# Multicore ## Erweiterung Steuerwerk - Zur überlappenden Verarbeitung von Befehlen ### Phasenpipelining - Mehrere Befehle gleichzeitig im Prozessor in Arbeit - in unterschiedlichen Phasen - verwenden unterschiedliche Komponenten des Prozessors - **Je mehr Stufen, desto mehr Befehle gleichzeitig** - desto eher wird CPI = 1 erreicht - Voraussetzung - Anpassung Befehlssatz an Pipelinebedingungen - RISC, Load-Store, Register-Register - Probleme - Steuerungs-, Daten-, strukturelle Konflikte (=Hazards) - **Je mehr Stufen, desto schlimmer ist Leeren und Neustart der Pipeline nach falscher Sprungvorhersage** #### 14-18 Pipelinestufen optimal #### Verfahren zur Lösung der Konflikte - Hardware - Caches, Forwarding, Branch Prediction - Befehlssatzerweiterung - Software - Pipeline-gemäße Sortierung der Befehle durch den Compiler ## Beispiel anhand einer 5-Stufigen Pipeline  - **Befehlsholphase (IF)** - Lesen des Befehls - separater Speicher von Befehlen und Daten - Vermeidung von Konflikten mit Datenzugriffen - `STR R1, [R2]` bzw `ADD R4, R5, R6` - **Dekodier- / Register-Lese-Phase (ID)** - Lesen der Register - möglich wegen fester Plätze für Registernummern im Befehlswort - `R1, R2` bzw `R5, R6` lesen - **Ausführungs- / Adressberechnungsphase (EX)** - Berechnung arithmetischer Funktionen - `R5 + R6` - bzw. Adresse für Speicherzugriff - `[R2] + 0` - **Speicherzugriffsphase (Mem)** - Wird nur bei Lade- / Speicherbefehlen benötigt - _Abspeichern des Werts R1 an zuvor berechnete Adresse [R2]_ - **Abspeicherungsphase (WB)** - Speichern in Register - Bei Speicherbefehlen (ohne Autoinkrement) nicht benötigt - _Speichern des Ergebnisses der Addition in R4_ - **Reihenfolge ohne Pipelining (3 Befehle)** -  - **Reihenfolge mit Pipelining (3 Befehle)** -  -  ## Pipeline-Konflikte ### Strukturelle Konflikte (structural hazards) - resultieren aus Ressourcenkonflikten - überlappende Instruktionen, die gleiche Ressource benutzen #### Beispiel strukturelle Konflikte -  -  - Alternative Darstellung: -  ### Datenkonflikte (data hazards) - resultieren aus Instruktionen, die von Ergebnissen einer vorigen Instruktion abhängig sind - _bspw. Read-After-Write_ - Instruktion liest aus Register, nachdem eine andere reingeschrieben hat - **Lösung durch Forwarding** - Write-After-Read - Write after Write - 2 Instruktionen haben gleiches Ergebnisregister - WAR / WAW - Konflikte durch Doppelverwendung - können durch mehr Register gelöst werden ### Steuerungskonflikte (control hazards) - resultieren aus Sprüngen - Befehle, die PC verändern - führt zu entleeren der Pipeline und einem erneuten Befüllen -  ## Sprungvorhersage - Vorhersagen, ob Sprung ausgeführt wird - Falls nicht ausgeführt wird - Pipelinedurchlauf nicht unterbrechen - PC inkrementieren - nächste Instruktion machen - Falls richtig, kann Pipeline normal weiter laufen ### Korrektur Sprungvorhersage  ### Methoden Sprungvorhersage #### Statisch (vom Computer implementiert) - Default-Annahmen über Sprungverhalten zur Laufzeit - Default not taken - bspw. Verzweigung (Sprung vorwärts) - Default taken - bspw. Schleifen (Sprung rückwärts) - Delayed branches - ersetzen den freien Slot in der Pipeline mit sinnvollen, Sprungunabhängigen Befehlen ### Dynamisch - in Abhängigkeit vom tatsächlichen Verhalten des Sprungs - **Sprungvorhersagepuffer (Branch History Table - BHT)** -  - Sprungziel muss noch ausgerechnet werden - Kleiner Speicher - wird mit (Teil der) Adresse des Sprungbefehls indiziert - verwendet nur wenige untere Bits der Adresse - Enthält ein Bit - Sprung beim letzten Mal ausgeführt? - **Taken / not Taken** - Vorhersage - Sprung verhält sich wie beim letzten Mal - Nachfolgebefehle - ab vorhergesagter Adresse holen - Falls Vorhersage Falsch - Vorhersagebit invertieren - **Sprungzielvorhersage** - **Branch Target Buffer (BTB)** -  - Erfolgt in IF-Phase - Verhalten ähnlich eines Caches - adressiert mit Sprungbefehlsadresse - BTB liefer vorhergesagte Adresse als Ergebnis - Keine Verzögerung - WENN KORREKT