Architettura dei Calcolatori
Hazards
Problema
Abbiamo delle istruzioni che provocano hazards.
Alee strutturali
⚠️ Risorsa condivisa tra più stadi (es. memoria).
Come si risolve?
- Duplicazione della risorsa. Lo facciamo per esempio per l’ALU, che dovrebbe essere condivisa tra la fase di EXECUTE e quella di FETCH. Non sempre va bene ovviamente.
- Serializzazione degli accessi.
- [ADVANCED] Caches ovunque e facciamo finta di aver duplicato la risorsa.
Alee di Dato
⚠️ Un istruzione legge qualcosa che è stato modificato da un’altra istruzione che è ancora in pipeline (es. Read After Write - RAW, jump a registro appena modificato)
Come si risolve?
-
Forwarding: colleghiamo all’EX le fasi più avanti in modo tale che l’u.c. possa scegliere se utilizzare i registri provenienti dalla fase di DECODE (stale) oppure quelli appena creati (forwarded).
Risolve quasi tutte le RAW senza stallare la pipeline.
-
Se l’istruzione che modifica (quella da cui la nostra istruzione attuale nell’EX dipende) è una LOAD è un problema. Perchè? Perchè c’è accesso in memoria. Che cazzo forwardi? nulla. Quindi bisogna aspettare la fine di MEM.
In questo caso si può ricorrere alla delayed load perchè se la nostra istruzione è nella fase di EX, la LOAD sarà in fase di WB, quindi possiamo prendere già il valore presente nel registro appena e forwardarlo alla fase di EX.
🔥 La delayed load è fattibile solamente se ho il forward.
Alee di Controllo
La BRANCH
e la JUMP
, oltre ad avere un problema di alea di dato se faccio jump/branch ad un registro appena modificato, hanno anche un alea di controllo.
In generale per entrambe possiamo ottimizzare l’archittetura per avere che il risultato della JUMP/BRANCH (nella EX) mi faccia caricare direttamente la prossima istruzione corretta.
Mentre per la JUMP, non posso fare nient’altro, per la branch posso provare a predirre se il jump sarà taken or not. Per fare questo ci sono vari modi.
La migliore (vista) è il BTB, perchè sbaglio molto meno di qualsiasi modo (sicuramente non ha senso l’always stall e con la predict not taken sbaglio molte più volte)