Pipeline - Architettura elaboratori

CONTROL HAZARDS

Essi sono relativamente semplici da gestire ed occorrono un numero di volte minore rispetto ai data

hazards.

Come abbiamo detto prima ci sono vari metodi per risolvere questo problema.

Uno dei quali è Assumere che la branch non venga presa e che quindi non si salti.

Usiamo questo metodo poichè mettere in stallo la pipeline fino a quando la branch non sia presa è

troppo lento. Il meccanismo con il quale assumiamo che la branch venga o non venga presa è

chiamato PREDICTION.

Dobbiamo allora dividerci in due casi:

⚫ Se la branch non sarà presa allora si continua l’esecuzione e si passa alla riga

successiva non dovendo eseguire salti. Se questa occasione succederà anche

metà delle volte e i costi per scartare sono piccoli, l’ottimizzazione dimezza il

costo.

⚫ Se la branch sarà presa le istruzioni che sono nella fase di fetch e decode devono

essere scartate e l’esecuzione continua all’indirizzo della branch.

Altra soluzione potrebbe essere Ridurre il delay delle branch. Esso è un metodo per accrescere la

performance nel momento che andiamo a ridurre i costi della branch taken.

Invece di prendere l’indirizzo a cui saltare dalla Memoria (stadio MEM), spostiamo l’operazione in

5

uno stadio precedente così abbiamo da scartare meno istruzioni.

Moving Up Branch Decision. Calcoliamo l’indirizzo di salto e valutiamo la decisione.

Spostare la decisione del salto più indietro nella pipeline richiede di anticipare due azioni: il calcolo

dell’indirizzo di destinazione del salto e la valutazione del confronto sulla base della quale il salto viene

effettuato o meno. Questo processo consta di due parti: una Parte Facile ed una Parte Difficile.

PARTE FACILE.

Abbiamo già il PC (Program Counter) ed il campo immediato in IF/ID. Dobbiamo solo muovere il

branch adder dallo stage EX allo stage ID.

PARTE DIFFICILE.

La DECISIONE.

Fatta la branch equal dovremmo comparare i due registri letti durante l’ID stage per vedere se sono

uguali.

Dobbiamo aggiungere Forwarding e Hazard Detection hardware, dato che la decisione dipende dai

dati contenuti all’interno della pipeline. Dobbiamo assicurarci che la branch funzioni correttamente

anche con questa ottimizzazione.

Abbiamo però 2 Fattori di complicazione.

1. Durante ID. Dobbiamo decodificare l’istruzione; decidere se bypassare l’equality unit;

completare l’eqaulity comparision cosicchè avessimo un branch taken potendo poi settare il PC.

L’Introduzione dell’equality unit necessita di una nuova unità logica per il forwarding.

2. Possibile Data Hazard. Avendo necessità del valore nella branch comparision in ID stage, ma

questo valore potrebbe essere prodotto tardi nel tempo. 6

Altra possibile soluzione ai Control Hazards è la DYNAMIC BRANCH PREDICTION.

Assumere che la branch non sia presa è una semplice forma si Branch Prediction. In una pipeline più

aggressiva, uno schema statico della prediction non funzionerà al meglio. Con più componenti

hardware è possibile riuscire a predire il comportamento della branch durante l’esecuzione.

APPROCCIO 1.

Cercare l’indirizzo dell’istruzione e verificare che l’ultima volta il salto sia stato effettivamente

eseguito.

In caso affermativo le prossime istruzioni cominciano ad essere prese dallo stesso punto.

Come implementare l’approccio....

Abbiamo bisogno di un Branch Prediction Buffer. Essa è una piccola memoria che contiene un bit che

dice se la branch è stata recentemente presa o meno.

Abbiamo allora due casi sulla predizione:

1. Azzeccata. Eseguiamo il salto

2. Non Azzeccata. Le istruzioni predette sono cancellate. Il bit invertito e riposto in

memoria e la giusta sequenza è presa ed eseguita.

Lo schema ad un bit ha un difetto però.

⚫ Anche se una branch è quasi sempre presa, possiamo predire incorrettamente

due volte, invece di una, quando non è presa.

Come soluzione a ciò utilizziamo uno schema a due bit -> Una predizione deve essere sbagliata due

7