zusammenfassungen/Writerside/topics/RA/Multicore.md

# 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
![image_532.png](image_532.png)
- **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)**
  - ![image_533.png](image_533.png)
- **Reihenfolge mit Pipelining (3 Befehle)**
  - ![image_534.png](image_534.png)
  - ![image_535.png](image_535.png)

## Pipeline-Konflikte
### Strukturelle Konflikte (structural hazards)
- resultieren aus Ressourcenkonflikten
  - überlappende Instruktionen, die gleiche Ressource benutzen

#### Beispiel strukturelle Konflikte
- ![image_536.png](image_536.png)
- ![image_537.png](image_537.png)
- Alternative Darstellung:
  - ![image_538.png](image_538.png)

### 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
  - ![image_539.png](image_539.png)

## 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
![image_540.png](image_540.png)

### 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)**
  - ![image_541.png](image_541.png)
  - 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)**
    - ![image_542.png](image_542.png)
    - Erfolgt in IF-Phase
    - Verhalten ähnlich eines Caches
      - adressiert mit Sprungbefehlsadresse
    - BTB liefer vorhergesagte Adresse als Ergebnis
    - Keine Verzögerung
      - WENN KORREKT