Embed Size (px)
Citation preview
1
1
Instruction Level Parallelism (ILP) Dinamico (prima parte)
• Introduzione all’ILP • Dipendenze e alee sui dati e sui nomi • Scheduling dinamico della CPU • Branch prediction • Speculazione hardware • Multiple issue • Limiti teorici dell’ILP dinamico
2
Instruction Level Parallelism (ILP): Introduzione
• Abbiamo visto che il pipeling sovrappone parzialmente l’esecuzione delle istruzioni, cercando così di sfruttare il potenziale parallelismo insito nelle istruzioni stesse.
• Questa forma di parallelismo prende il nome di “Parallelismo a livello di istruzione” o, in inglese, “Instruction Level Parallelism” (solitamente abbreviato nell’acronimo ILP).
• Nei prossimi lucidi introduciamo alcuni concetti e termini fondamentali dell’ILP, per poi vedere in dettaglio come questi concetti vengano implementati praticamente nei processori moderni.
• I concetti che introduciamo sono: multiple issue, ILP statico e dinamico, scheduling statico e dinamico della pipeline, branch prediction dinamico, speculazione hardware.
3
Instruction Level Parallelism (ILP) • L’effettivo grado di parallelismo insito nelle istruzioni di un
programma che si riesce a sfruttare dipende però dai problemi del pipelining introdotti nel capitolo precedente:
• strutturali: un numero limitato di unità funzionali disponibili • sui dati: una istruzione deve usare il risultato di un’altra, e le due
istruzioni non possono quindi procedere in parallelo • sul controllo: fino a che non si sa se un salto verrà eseguito o no,
non si sa qual è la prossima istruzione da eseguire • Nella letteratura, questi problemi vengono chiamati “alee” (in
inglese “hazard”) e sono i responsabili degli stall della pipeline. • Se questi problemi non fossero presenti, avremmo sostanzialmente
due modi per aumentare l’efficienza della pipeline, ossia aumentare il potere computazionale del processore: 1) aumentare la frequenza del clock della CPU e 2) mandare più istruzioni in esecuzione in parallelo
2
4
Instruction Level Parallelism (ILP) 1. aumentare la frequenza del clock della CPU
• Il che significa un ciclo di clock più corto, che però deve essere dimensionato per permettere all’informazione l’attraversamento della porzione di datapath contenuto in una fase della pipeline.
• Allora, perché la pipeline continui a funzionare, occorre riprogettare l’architettura suddividendo il lavoro in un numero maggiore di fasi, in ciascuna delle quali svolgere la minor quantità di lavoro permessa dal nuovo ciclo di clock più corto.
• Ma se aumenta il numero di fasi della pipeline (la cosiddetta profondità della pipeline) allora a regime ci saranno più istruzioni in esecuzione in parallelo, e quindi aumenta lo sfruttamento del parallelismo insito nelle istruzioni del programma in esecuzione.
5
Instruction Level Parallelism (ILP) • In altre parole, il numero di fasi della pipeline e la frequenza del
clock della CPU (e ovviamente anche la lunghezza del ciclo di clock) sono strettamente legati fra loro e determinano le effettive prestazioni della CPU (insieme a molti altri fattori che vedremo più avanti)
• Questa relazione fu pesantemente sfruttata nel caso notabile del Pentium IV, in cui si riuscirono a raggiungere frequenze che sfioravano i 4 GHz con pipeline di quasi 30 stadi.
• Da notare che maggiore è la profondità della pipeline e maggiore è il tempo necessario ad eseguire la singola istruzione, ma aumenta il numero di istruzioni eseguite in parallelo.
6
Instruction Level Parallelism (ILP) • Evidentemente, non si può sperare di poter sfruttare questa tecnica
indefinitamente.
– sia per problemi architetturali: maggiore complessità della pipeline, e quindi della sua control Unit;
– sia per problemi tecnologici: spessore delle piste che connettono i transistor della CPU, interferenze tra le piste, consumi e conseguenti problemi di dissipazione del calore.
• Nelle intenzioni dei progettisti Intel, il Pentium 4 sarebbe dovuto arrivare ad una frequenza di circa 10 GHz, ovviamente mai raggiunti in condizioni normali di lavoro.
3
7
Instruction Level Parallelism (ILP)
2. mandare più istruzioni in esecuzione in parallelo,
• Questa tecnica è comunemente nota come “multiple issue” ed è sfruttata in tutti i processori moderni.
• Notate che mandare in esecuzione due o più istruzioni in parallelo significa che “si sa” che queste istruzioni sono indipendenti, cioè nessuna ha bisogno del risultato di nessun altra istruzione del pacchetto avviato in parallelo (come questo “si sa” venga implementato lo vedremo in dettaglio più avanti)
• Il multiple issue richiede innanzi tutto un datapath più ampio, in grado cioè di trasportare le varie informazioni di tutte le istruzioni lanciate in parallelo da uno stadio della pipeline al successivo.
• E richiede anche più unità funzionali più sofisticate, in particolare:
8
Instruction Level Parallelism (ILP) a. Deve essere disponibile un numero sufficiente di unità funzionali
per l’esecuzione di più istruzioni in parallelo. Ad esempio, più ALU, più unità di moltiplicazione intera / Floating Point, e così via.
b. deve essere possibile prelevare dalla Instruction Memory più istruzioni, e dalla Data Memory più operandi, per ciclo di clock (come vedremo, le memorie cache che contengono le istruzioni e i dati hanno una ampiezza di banda adeguata a questo scopo)
c. Deve essere possibile indirizzare in parallelo più registri della CPU, e deve essere possibile leggere e/o scrivere i registri usati da diverse istruzioni in esecuzione nello stesso ciclo di clock
9
Instruction Level Parallelism (ILP) • In una architettura pipelined senza multiple issue, in assenza di
dipendenze, ad ogni ciclo di clock viene portata a termine l’esecuzione di una istruzione: Clock Per Instruction (CPI) = 1
• In una architettura pipelined multiple issue invece, è virtualmente possibile portare a termine l’esecuzione di più di una istruzione per ciclo di clock e quindi CPI < 1
• Le architetture multiple issue vengono di solito dette superscalari, anche se, più correttamente, questo termine va riservato alle architetture a multiple issue “dinamico” (chiariremo fra poco…)
• Purtroppo, la presenza delle alee fa si che nel caso reale anche i processori che implementano il multiple issue abbiano spesso un CPI medio > 1.
4
10
Instruction Level Parallelism (ILP)
• Lo schema di base di una architettura superscalare. Nella realtà, gli stage della pipeline sono di solito più di 5, ma l’esecuzione delle istruzioni può comunque essere concettualmente suddivisa in 5 fasi fondamentali (H-P5, fig. C.33)
11
Instruction Level Parallelism (ILP) • I moderni processori di fascia alta combinano normalmente il
pipelining e il multiple issue, e sono in grado di avviare all’esecuzione un numero che va da 3 a 8 istruzioni per ciclo di clock.
• Un processore a 3 GHz in grado di lanciare in esecuzione fino a 4 istruzioni per ciclo di clock avrebbe una velocità di esecuzione di picco di 12 miliardi di istruzioni al secondo, e un CPI di 0,25.
• Ovviamente, nella realtà i possibili stall della pipeline diminuiscono drasticamente queste prestazioni, e anche mantenere un CPI = 1 è spesso difficile…
12
Instruction Level Parallelism (ILP) • Per implementare il multiple issue è necessario determinare quali e
quante istruzioni possono essere avviate all’esecuzione in un dato ciclo di clock.
• La ricerca va fatta tra le istruzioni in attesa di essere eseguite, e ovviamente ci sono dei limiti pratici a quante istruzioni possono essere analizzate per trovare quelle indipendenti fra loro.
• Una volta individuate, si dice che le istruzioni vengono impacchettate in un issue packet, e avviate nello stesso issue slot (ossia nello stesso ciclo di clock)
• I processori multiple issue si possono dividere in due grandi categorie, a seconda di come (e soprattutto quando) vengono risolti questi due problemi.
5
13
Instruction Level Parallelism (ILP) • Nei processori a multiple issue statico la scelta delle istruzioni da
mandare in esecuzione in parallelo viene fatta dal compilatore, cioè a livello software.
• Quando il processore preleva dalla Instruction Memory un pacchetto di istruzioni preparato dal compilatore, sa già che potrà eseguire quelle istruzioni in parallelo senza rischi di alee presenti tra queste istruzioni.
• Il numero di istruzioni nel pacchetto è stabilito a priori, nella fase di progettazione del processore, e si parla di architettura a issue statico.
• Quando tutto (o quasi, come vedremo nel caso dell’Itanium 2) il lavoro di ricerca del parallelismo tra le istruzioni è fatto dal compilatore siamo in presenza di Instruction Level Parallelism Statico
• Vedremo l’ILP statico e le relative tecniche usate nel prossimo capitolo
14
Instruction Level Parallelism (ILP) • Nei processori a multiple issue dinamico (che vedremo in questo
capitolo) è il processore che risolve a run time le alee e decide quali istruzioni mandare in esecuzione in parallelo.
• Ovviamente c’è un limite al numero di istruzioni che la logica del processore è in grado di esaminare per trovare pacchetti di istruzioni indipendenti, limite che dipende dall’architettura specifica e dal fatto che la ricerca avviene a run time e quindi il processore ha poco tempo per individuare pacchetti di istruzioni indipendenti.
• Il numero di istruzioni individuate può cambiare ad ogni ciclo di clock (fino al massimo consentito dall’architettura) e si parla di issue dinamico e di instruction Level Parallelism Dinamico
• Nella realtà, ILP statico e dinamico non sono completamente distinti, e i processori di una categoria di solito adottano almeno qualche tecnica di base dell’altra categoria.
15
Instruction Level Parallelism (ILP) • In definitiva, possiamo dunque dire che:
• Aumentare la frequenza del clock permette di eseguire più velocemente le istruzioni, e in una architettura pipelined permette di sovrapporre l’esecuzione di più istruzioni.
• Il multiple issue permette di mandare in esecuzione più istruzioni indipendenti in parallelo, aumentando ulteriormente la produttività della pipeline.
• Tuttavia, la produttività della pipeline è ostacolata dalla presenza delle alee, e le tecniche che introduciamo ora: scheduling dinamico della pipeline, branch prediction e speculazione hardware hanno lo scopo di minimizzare l’effetto negativo delle alee.
• Nota: per semplificare un po’ l’esposizione dei prossimi concetti, torniamo per ora a pensare ad una sola istruzione avviata per ciclo di clock, più avanti reintrodurremo il multiple issue.
6
16
Scheduling dinamico della pipeline • Consideriamo questo pezzo di programma, e supponiamo che il
valore indirizzato da 100(R2) non si trovi nella memoria cache:
LD R4, 100(R2) DADD R10, R4, R8 DSUB R12, R8, R1
• L’esecuzione della DADD dipende dalla LD, ma in una pipeline come l’abbiamo introdotta nel capitolo precedente le istruzioni procedono una dopo l’altra nella pipeline: fino a che la DADD non può essere inviata alla fase EX, blocca anche l’esecuzione della DSUB, che pure potrebbe essere eseguita perché non ha dipendenze con le istruzioni precedenti.
17
Scheduling dinamico della pipeline • Per mitigare problemi come questi, quasi tutti i processori “general
purpose” (sia del passato, come i vari Pentium, PowerPC, SPARC, MIPS, sia i più moderni multi-core), i quali implementano l’ILP dinamico, adottano qualche forma di scheduling dinamico della pipeline: l’ordine in cui le istruzioni vengono mandate in esecuzione (ossia vengono inviate alla fase EX della pipeline) può essere diverso dall’ordine con cui sono state prodotte dal compilatore.
• Naturalmente l’ordine di esecuzione va mantenuto tra istruzioni che dipendono l’una dall’altra.
• Se invece le istruzioni non possono superarsi l’un l’altra nella pipeline allora si parla di scheduling statico della pipeline, il che permette di avere un datapath e una control unit più semplici.
18
Scheduling dinamico della pipeline • Un processore con pipeline schedulata dinamicamente è dunque in
grado di riconoscere che la DSUB non dipende da istruzioni precedenti, e la può mandare in esecuzione sull’unità intera mentre la DADD è ancora in attesa del valore in R4.
• Il fatto che le istruzioni possano superarsi l’un l’altra all’intero della pipeline implica non solo la loro esecuzione out-of-order, ma anche il loro completamento out-of-order. In altre parole, le istruzioni possono eseguire la fase MEM e la fase WB in un ordine diverso dal quello in cui compaiono nel programma.
• Lo scheduling dinamico della pipeline permette di mitigare le dipendenze sui dati, poiché istruzioni fra loro dipendenti non ostacolano più il procedere di quelle indipendenti lungo la pipeline
7
19
Scheduling dinamico della pipeline • Notate che in un sistema che implementa l’ILP statico, sarebbe il
compilatore ad accorgersi di una situazione di potenziale stallo come quella dell’esempio precedente, e potrebbe generare un codice oggetto in cui la DSUB è stata postata prima della LD.
• Come vedremo nel prossimo capitolo, nell’ILP statico il compilatore è responsabile di questi e di altri ben più sofisticati riarrangiamenti del codice al fine di renderne più efficiente l’esecuzione.
• Ovviamente, il tutto deve avvenire mantenendo invariato il comportamento globale del programma (il che del resto è vero anche per i processori che implementano l’ILP dinamico e una qualche forma di esecuzione e completamento out of order delle istruzioni)
20
Branch prediction dinamico • Nell’ILP dinamico è inoltre comune qualche forma di branch
prediction dinamica: per ogni istruzione di branch eseguita, l’hardware della CPU tiene traccia del risultato delle precedenti esecuzioni di quella stessa istruzione (ossia, se il salto è stato eseguito o no).
• Quando lo stesso branch viene di nuovo eseguito, si usa la storia passata di quel branch per predire se il salto verrà eseguito o no, e quindi decidere quale sarà la prossima istruzione da eseguire.
• Ovviamente, questa tecnica funziona solo per quei branch che hanno una storia, ossia che vengono eseguiti più di una volta.
• La branch prediction dinamica è una tecnica così utile ed efficace per migliorare le prestazioni dei processori che spesso viene anche usata nei processori che adottano l’ILP statico.
21
Speculazione hardware • Una naturale estensione del branch prediction è, infine, la
speculazione hardware. Considerate questa situazione:
FMUL F4, F0, F2 // may need 10 clock cycles BLE F4, #0.66666, next // branch if less or equal FADD F1, F1, #0.5 DADD R1, R1, #2 FADD F2, F2, #0.25 DADD R2, R2, #1
next:
8
22
Speculazione hardware • Le istruzioni controllate dal branch possono essere eseguite
(eventualmente) solo quando si conosce il risultato della BLE, che a sua volta dipende dal risultato della FMUL.
• Il processore può allora speculare sul risultato del salto sulla base di qualche forma di branch prediction, e se la predizione dice che il salto non verrà eseguito, lanciare l’esecuzione del blocco di istruzioni evidenziato nel riquadro.
• La predizione può ovviamente essere sbagliata, e il processore deve quindi essere in grado di annullare l’effetto delle istruzioni eseguite, e che non dovevano esserlo.
• La speculazione richiede hardware molto sofisticato, e non è adottata da tutti i processori che implementano l’ILP dinamico.
23
Dipendenze e Alee • Ora cerchiamo formalizzare il concetto di dipendenza tra le
istruzioni, che limita la possibilità di sfruttare il parallelismo insito nelle istruzioni di un programma.
• Anche se ne parliamo qui, questi concetti ci serviranno anche quando parleremo dell’ILP statico, dove è principalmente il compilatore che si occupa di capire quali istruzioni possono essere eseguite in qualsiasi ordine, perché indipendenti fra loro, e quali no.
• nell’ILP dinamico invece è il processore, prima di avviare le istruzioni alla fase EX, che deve cercare di scoprire le possibili dipendenze e gestirle.
24
Dipendenze e Alee • determinare come una istruzione dipende dalle altre è fondamentale
per stabilire quanto parallelismo esiste in un programma e come può essere sfruttato.
• Se due istruzioni sono indipendenti fra loro possono essere eseguite simultaneamente e/o in qualsiasi ordine nella pipeline, se ci sono sufficienti risorse (ossia: sufficienti unità funzionali)
• Se due istruzioni sono dipendenti devono essere eseguite in ordine, e possono al massimo solo parzialmente essere eseguite in modo sovrapposto (ossia possono al più trovarsi contemporaneamente all’interno della pipeline ma in fasi “sufficientemente” distanti fra loro).
• Quindi per sfruttare il parallelismo contenuto nelle istruzioni di un programma è fondamentale determinare le dipendenze fra istruzioni.
9
25
Dipendenze • Analiziamo le dipendenze che si possono verificare all’interno di un
gruppo di istruzioni consecutive che non contengono branch.
• In alternativa, possiamo assumere che, in caso di branch, la CPU sappia sempre se il salto verrà eseguito o no usando qualche forma di predizione. (in altre parole, per ora non ci preoccupiamo dei problemi di controllo).
• Distinguiamo due tipi di dipendenze:
1. dipendenze sui dati
2. dipendenze sui nomi
26
Dipendenze sui Dati
• Una istruzione j si dice (true) data dependent da una istruzione i se vale una delle seguenti condizioni:
1. j usa un risultato prodotto da i
2. j è data dependent da k, e k è data dependent da i
• La condizione 2 specifica semplicemente che ci può essere una catena di dipendenze, arbitrariamente lunga.
27
Dipendenze sui Dati
LOOP: LD F0, 0 (R1) FADD F4, F0, F2 SD F4, 0 (R1) DADD R4, R4, #-8 BNE R4, R5, LOOP
• La seconda istruzione è data dependent dalla prima, così pure la terza rispetto alla seconda e la quinta rispetto alla quarta.
• Le frecce ci indicano l’ordine in cui è necessario eseguire le istruzioni, con conseguenti possibili stall nella pipeline.
10
28
Dipendenze sui Nomi • Una dipendenza sui nomi (name dependence) si verifica quando
due istruzioni usano lo stesso registro o locazione di memoria ma non c’è flusso di dati tra le istruzioni che usano lo stesso nome (cioè le istruzioni non sono data dependent)
• Data l’istruzione i che precede l’istruzione j abbiamo:
1. una antidipendenza tra i e j se i legge in un registro (o locazione di memoria) che j deve scrivere. L’istruzione i deve aver tempo di leggere il registro prima che venga sovrascritto da j, altrimenti legge un valore sbagliato.
2. una dipendenza in output se i e j scrivono nello stesso registro (o locazione di memoria). L’ordine di scrittura deve essere mantenuto affinché il valore finale scritto corrisponda a quello dell’istruzione j.
29
Dipendenze sui Nomi • Ecco esempi di antidipendenza e di dipendenza in output:
DIV F0, F2, F4 ADD F6, F0, F8 SUB F8, F10, F14 MUL F6, F10, F12
• Antidipendenza tra ADD (che aspetta DIV) e deve leggere F8, e SUB che deve scrivere in F8. Che Succede se SUB modifica F8 prima che ADD l’abbia usato per la somma?
• Dipendenza in output tra ADD e MUL: che succede se ADD (sempre per colpa di DIV) termina dopo MUL?
30
Eliminare le Dipendenze sui Nomi • la dipendenza sui nomi non è una vera dipendenza sui dati perché
non ci sono valori trasmessi tra le istruzioni. (ecco perché parliamo invece di true data dependence).
• Le istruzioni coinvolte in una dipendenza sui nomi possono essere eseguite simultaneamente se il nome del registro (o l’indirizzo della locazione di memoria) usato nelle istruzioni viene cambiato in modo da evitare conflitti. (evidentemente, è più facile usando i registri: ecco un vantaggio delle istruzioni RISC).
• La rinominazione può essere fatta staticamente dal compilatore (lo vedremo nel prossimo capitolo) o dinamicamente dall’hardware (lo vedremo tra poco).
11
31
Eliminare le Dipendenze sui Nomi • Ecco come, nel nostro esempio, antidipendenza e dipendenza in
output possono essere risolte con opportune rinominazioni:
DIV F0, F2, F4 ADD F6, F0, F8 SUB F9, F10, F14 MUL F11, F10, F12
• Naturalmente, perché la rinominazione sia possibile occorre che F11 ed F9 siano disponibili. Occorre anche tener traccia di queste modifiche per le istruzioni che seguono quelle modificate.
• Una soluzione alternativa (ma concettualmente identica) è di usare qualche registro aggiuntivo ma “nascosto” (nel senso di non visibile a livello ISA) disponibile nella CPU.
32
Dipendenze e Alee • I diversi tipi di problemi dovuti alle dipendenze sui dati e sui nomi
possono essere formalizzati come segue. Consideriamo due istruzioni i e j con i che occorre prima di j. Possono sorgere tre tipi di alee sui dati:
1. RAW (Read After Write): j cerca di leggere un registro (ma anche una locazione di memoria) prima che i lo abbia scritto. j legge erroneamente il vecchio valore.
– è dovuta ad una true data dependence, ed è anche la più comune. L’ordine delle istruzioni va preservato in modo che j riceva il valore corretto da i.
– Esempio: LD R2, #100(R3) seguito da ADD R5,R4,R2. La presenza della pipeline (la ADD viene avviata prima che sia terminata la LD) produce un RAW hazard.
33
Dipendenze e Alee • In sostanza, in caso di RAW l’istruzione j non può proseguire
l’esecuzione perché i dati di cui ha bisogno non sono ancora disponibili.
• Il processore deve accorgersi della dipendenza di j da una istruzione precedente e sospenderne l’esecuzione fino a che il dato mancante sia disponibile.
• Il forwarding può risolvere alcune alee di tipo RAW:
DADD R1, R2, R3
DSUB R4, R1, R5
AND R6, R1, R7
• ma altre rimangono…
12
34
Dipendenze e Alee • …in particolare quando sono coinvolte operazioni “lunghe”:
LD R1, 0(R2)
DSUB R4, R1, R5
AND R6, R1, R7
• Occorre dunque fermare la DSUB (e quindi la AND) per un ciclo di clock, in attesa che sia disponibile il dato della LD (ammesso che il dato sia in cache, perché altrimenti…)
• Questo si può ottenere semplicemente ripetendo le fase ID della DSUB (che viene ridecodificata e i registri riletti) e la fase IF della AND (che viene riprelevata dalla IM)
Il dato indirizzato dalla LD sarà presente nel registro MEM/WB solo alla fine del ciclo di clock 4, ma la DSUB ne ha bisogno all’inizio di quel ciclo.
35
Dipendenze e Alee 2. WAW (Write After Write): j cerca di scrivere un registro prima
che sia scritto da i. La doppia scrittura termina nell’ordine sbagliato, lasciando nel registro il valore scritto da i anziché quello scritto da j.
– E’ dovuta ad una dipendenza in output, e si verifica perché nella pipeline una istruzione può procedere anche se una precedente è in stall.
– Esempio: in una pipeline con una unità floating point a più stage, ecco un semplice esempio di WAW hazard:
FMUL F4, F5, F6 SD F4, #0 (R8) LD F4, #0 (R7) //che succede se la FMUL termina dopo la LD? FADD F4, F4, F10
– Come si può risolvere questa situazione?
36
Dipendenze e Alee 3. WAR (Write After Read): j cerca di scrivere un registro prima
che sia letto da i. i legge erroneamente il nuovo valore.
– E’ dovuta ad una antidipendenza, e si verifica raramente, dato che, nella maggior parte delle pipeline, la lettura degli operandi avviene di solito “molto” prima (nello stage ID) della scrittura (nello stage WB).
– WAR hazard si possono verificare nel caso in cui ci siano istruzioni che scrivono risultati in qualche stage iniziale della pipeline, e istruzioni che leggono operandi negli stage finali. WAR hazard si verificano anche in caso di riordinamento delle istruzioni (provate a trovare un esempio di WAR hazard).
• E gli hazard di tipo RAR?
13
37
Limitare le alee su dati e nomi con lo Scheduling Dinamico della pipeline
• Lo scheduling dinamico della pipeline consiste in un insieme di tecniche implementate dal processore a run-time per ridurre la frequenza e la durata degli stall della pipeline dovuti alle dipendenze sui dati e sui nomi:
1. Modificando eventualmente l’ordine in cui vengono eseguite le istruzioni in modo da minimizzare gli effetti delle alee di tipo RAW
2. Rinominando i registri in modo da ridurre l’influenza delle alee di tipo WAW e WAR
38
scheduling dinamico della pipeline: l’approccio di Tomasulo
• La tecnica di base per lo scheduling dinamico della Pipeline fu sviluppata già nel 1967 per l’IBM360/91 da Robert Tomasulo, ricercatore del’IBM
– Per minimizzare l’effetto delle alee di tipo RAW tiene traccia di quando gli operandi delle istruzioni da eseguire sono disponibili, indipendentemente dall’ordine di esecuzione delle istruzioni stesse.
– Per minimizzare le alee di tipo WAW e WAR, un insieme di registri interni alla CPU (invisibili al livello ISA) viene usato per implementare la rinominazione dei registri.
• Varianti della tecnica originale sono utilizzate in tutte le CPU che implementano l’ILP dinamico.
39
scheduling dinamico della pipeline: • La chiave fondamentale dello schema di Tomasulo sono le
stazioni di prenotazione (reservation stations) associate alle unità funzionali, in cui le istruzioni, dopo essere state prelevate dalla IM e decodificate, attendono di poter essere eseguite (Patterson-Hennessy, fig. 4.72 modificata).
Register file
14
40
Scheduling dinamico delle pipeline La struttura base dell’unità F.P della macchina MIPS che implementa l’ILP dinamico secondo lo schema di Tomasulo. Per ora ignorate la “instruction Queue” e fate conto che quella sia la Instruction Memory (H-P5, Fig. 3.6)
From the Instruction memory
41
Scheduling dinamico della pipeline • Le stazioni di prenotazione associate ad una unità funzionale
possono contenere ciascuna una istruzione in attesa di essere eseguita su quella unità e, per ogni operando di ogni istruzione:
– (se già disponibile) il valore dell’operando stesso oppure
– (se l’operando non è ancora stato calcolato) l’identificativo della stazione di prenotazione che contiene l’istruzione che dovrà produrre l’operando mancante.
• Un Common Data Bus (CDB) connette tutte le unità funzionali, i registri e le reservation stations, e permette di trasferire in parallelo il risultato prodotto da una unità funzionale a tutte le stazioni di prenotazione che lo stanno aspettando e al register file.
42
Scheduling dinamico della pipeline • Nello schema di Tomasulo, l’esecuzione di una istruzione è
suddivisa in tre “macropassi” fondamentali (ciascuno dei quali può corrispondere a più stage della pipeline):
• ISSUE. Prelievo, decodifica e inserimento dell’istruzione nella stazione di prenotazione associata all’unità funzionale che dovrà eseguire quell’istruzione (se non ci sono stazioni disponibili, stall della pipeline).
• Se gli operandi dell’istruzione sono disponibili nel register file, o in qualche altra stazione di prenotazione, vengono prelevati e mandati nella stazione di prenotazione in cui è stata messa l’istruzione.
• Per ogni operando che manca, in un campo della stazione di prenotazione viene scritto l’identificativo della stazione di prenotazione in cui è presente l’istruzione che dovrà produrre quell’operando.
15
43
Scheduling dinamico della pipeline • Notate che per sapere che gli operandi di una istruzione:
– possono trovarsi in un’altra stazione di prenotazione, oppure
– devono ancora essere prodotti da una istruzione che attualmente si trova in qualche altra stazione di prenotazione
• La logica di controllo della CPU, nella fase di ISSUE ha dovuto tenere conto delle istruzioni prelevate in precedenza e già instradate verso qualche stazione di prenotazione, da cui l’istruzione corrente potrebbe dipendere.
44
Scheduling dinamico della pipeline • EXECUTE: (fase EX dello schema di base) l’istruzione si trova in
una stazione di prenotazione. Fintanto che uno o più operandi non sono ancora disponibili, si monitorizza il CDB in attesa della comparsa di quegli operandi.
• Quando un operando viene prodotto come risultato dell’esecuzione di un’altra istruzione, tramite il CDB esso viene inviato al register file e alle stazioni di prenotazione che lo stanno aspettando.
• Quando tutti gli operandi sono disponibili l’istruzione può essere inoltrata per l’esecuzione alla corrispondente unità funzionale.
• Se più istruzioni sono contemporaneamente pronte ad una determinata unità funzionale vengono eseguite una dopo l’altra (eventualmente in pipeline).
45
Scheduling dinamico della pipeline • Nel caso di istruzioni LOAD e STORE, viene prima calcolato
l’indirizzo di memoria effettivo, non appena il valore del registro base è disponibile, e l’indirizzo è memorizzato in stazioni di prenotazione chiamate load/store buffer
• le istruzioni di LOAD presenti nel buffer possono poi completare l’esecuzione non appena l’unità di accesso alla memoria dati è disponibile.
• Invece, le istruzioni di STORE nel buffer possono dover ancora attendere il risultato da caricare nella cella di RAM specificata.
• Per evitare possibili alee sulle celle in RAM, l’ordine di esecuzione di LOAD e STORE sottostà ad alcuni vincoli aggiuntivi, che vedremo più avanti con un esempio (secondo voi, perché è laborioso controllare la presenza di queste alee?)
16
46
Scheduling dinamico della pipeline • WRITE RESULT: (fasi MEM e WB dello schema di base)
quando termina la fase EX di una istruzione, il risultato viene scritto sul CDB, e da qui nel register file, nelle stazioni di prenotazione e negli store/load buffer che stanno attendendo quel risultato.
• Le istruzioni di STORE scrivono in memoria dati in questa fase, quando sia l’indirizzo che il dato da mandare in memoria sono disponibili.
• Analogamente, le LOAD prelevano il dato dalla RAM e lo scrivono nel registro di destinazione.
47
Scheduling dinamico della pipeline • Le stazioni di prenotazione e i load/store buffer sono composti da
più campi, implementati da registri interni (invisibili al livello ISA) che permettono di memorizzare le informazioni necessarie a gestire l’intero meccanismo.
• Se l’istruzione I si trova in una stazione di prenotazione A e sta aspettando un operando che deve essere prodotto da una istruzione J che si trova in una stazione B, allora la control unit scrive in un opportuno campo di A il numero della stazione B che contiene l’istruzione J che dovrà produrre il risultato atteso da I.
• Quando B produce un risultato da scrivere (ad esempio) in R5, attraverso il CDB il valore viene instradato verso R5 e anche verso la stazione di prenotazione A in cui I sta aspettando quel risultato.
48
Scheduling dinamico della pipeline • Se a questo punto un’altra istruzione vuole sovrascrivere R5 lo può
fare senza danneggiare I, perché il valore che deve usare I è già stato salvato nella sua stazione di prenotazione.
• In altre parole, i registri interni di cui sono fatte le stazioni di prenotazione svolgono il compito di registri temporanei, e vengono usati per implementare la rinominazione dei registri.
• Inoltre, una istruzione può essere eseguita non appena i suoi operandi sono disponibili, eventualmente prima di una istruzione che la precedeva nella Instruction Memory: la pipeline è schedulata dinamicamente.
• Naturalmente, se due istruzioni indipendenti devono usare la stessa unità funzionale non potranno essere eseguite in parallelo (se la U.F. è essa stessa pipelined, possono però procedere in pipeline)
17
49
Scheduling dinamico della pipeline • Vediamo alcuni esempi di funzionamento dello schema di
Tomasulo. Ogni stazione di prenotazione è composta dai seguenti campi:
– Op: l’operazione da eseguire su determinati operandi.
– Qj, Qk: le stazioni che produrranno il risultato atteso da Op. Uno zero indica che l’operando è già presente in Vj o Vk.
– Vj, Vk: Il valore degli operandi.
– A: presente solo nei load/store buffer, contiene prima il valore immediato per la LOAD o STORE, e dopo che è stato calcolato, l’indirizzo effettivo in RAM.
– Busy: indica che la stazione è attualmente in uso.
50
Scheduling dinamico della pipeline • Ad ogni registro del file dei registri è associato un campo:
– Qi: il numero della stazione di prenotazione che contiene l’istruzione il cui risultato dovrà andare in quel registro.
– Se Qi vale 0, non c’e alcuna istruzione che sta calcolando un valore che deve andare il quel registro.
51
Scheduling dinamico: esempio 1 LD F6, 34 (R2) LD F2, 45 (R3) MUL F0, F2, F4 SUB F8, F2, F6 DIV F10, F0, F6 ADD F6, F8, F2
Instruction Issue Execute Write Res. LD F6, 34 (R2) √ √ √ LD F2, 45 (R3) √ √ MUL F0, F2, F4 √ SUB F8, F2, F6 √ DIV F10, F0, F6 √ ADD F6, F8, F2 √
notate (e.g.) il WAR hazard sulla ADD: scrive F6, che al passo precedente viene usato dalla DIV. Se ADD completa prima che DIV legga F6, viene usato il valore sbagliato. (H-P5, Fig. 3.7)
18
52
Scheduling dinamico : esempio 1 Reservation stations / Register Status (H-P5, Fig. 3.7)
nome busy Op Vj Vk Qj Qk A
Load1 no
Load2 yes Load 45+Regs[R3]
Add1 yes SUB Mem[34+Regs[R2]] Load2
Add2 yes ADD Add1 Load2
Add3 no
Mult1 yes MUL Regs[F4] Load2
Mult2 yes DIV Mem[34+Regs[R2]] Mult1
Field F0 F2 F4 F6 F8 F10 F12 ... F31
Qi Mult1 Load2 Add2 Add1 Mult2
53
Scheduling dinamico : esempio 1 • Notate:
– Regs[N] indica il valore del registro numero N
– Mem[A] indica il contenuto della cella di memoria dati di indirizzo A
– La seconda Load ha completato il calcolo dell’indirizzo effettivo ed è in attesa di usare l’unità di memoria dati.
– la SUB ha già disponibile un operando (Vk) e attende il secondo dalla seconda Load (Qj)
– la ADD attende i suoi operandi dalla SUB (Qj) e dalla seconda load (Qk): appena questi sono disponibili, la ADD può eseguire.
– il WAR viene risolto con la rinominazione dei registri: la DIV non preleva più il secondo operando da F6, ma da Vk. La terminazione di ADD prima di DIV non crea problemi.
54
Scheduling dinamico della pipeline • Lo schema di Tomasulo ha due caratteristiche essenziali (che lo
rendono tra l’altro superiore a schemi più semplici, come lo scoreboarding, una tecnica di scheduling dinamico molto semplice, che trovate descritta sul Tanenbaum):
1. L’accesso agli operandi avviene in maniera distribuita.
– Quando più istruzioni stanno aspettando un operando A per passare alla fase EX, non appena A è disponibile tutte le istruzioni possono essere avviate, perché A viene distribuito a tutte mediante il CDB (purché usino unità funzionali differenti, o queste siano pipelined).
– Se si prelevasse A da un registro del register file, ogni unità funzionale dovrebbe accedere sequenzialmente al registro che contiene A.
19
55
Scheduling dinamico della pipeline 2. Gli hazard WAW e WAR vengono eliminati.
– Questo si ottiene mediante la rinominazione dei registri attraverso i registri interni delle stazioni di prenotazone, e inoltrando simultaneamente gli operandi appena computati a tutte le stazioni che li attendono.
– Considerate il WAR dell’esempio 1. Se la prima LOAD non fosse ancora completata, Qk di DIV conterrebbe Load1, e la DIV sarebbe ancora indipendente dalla ADD.
– La ADD può eseguire senza attendere che la DIV abbia letto i suoi operandi (in particolare il secondo)
56
Scheduling dinamico: esempio 1a
• Consideriamo, nello stesso codice del precedente esempio, la situazione quando l’istruzione MUL è pronta per scrivere il proprio risultato (H-P5, Fig. 3.8):
Instruction Issue Execute Write Res. LD F6, 34 (R2) √ √ √ LD F2, 45, (R3) √ √ √ MUL F0, F2, F4 √ √ SUB F8, F2, F6 √ √ √ DIV F10, F0, F6 √ ADD F6, F8, F2 √ √ √
57
Scheduling dinamico: esempio 1a Reservation stations / Register Status (H-P5, Fig. 3.8)
nome busy
Op Vj Vk Qj Qk A
Load1 no
Load2 no
Add1 no
Add2 no
Add3 no
Mult1 yes MUL Mem[45+Regs[R3]] Regs[F4]
Mult2 yes DIV Mem[34+Regs[R2]] Mult1
Field F0 F2 F4 F6 F8 F10 F12 ... F30
Qi Mult1 Mult2
20
58
Scheduling dinamico della pipeline • L’effettiva efficacia dello schema di Tomasulo nel gestire le alee sui
dati e sui nomi si vede soprattutto nella gestione dei loop.
• Nel codice di questo esempio, supponiamo che quando incontra il branch la CU assuma che il salto verrà eseguito (potrebbe usare una predizione statica: i salti all’indietro vengono eseguiti, oppure usare una delle tecniche di branch prediction dinamico che vedremo più avanti).
Loop: LD F0, 0 (R1) (H-P5, Fig. 3.9) MUL F4, F0, F2 // moltiplica gli elementi di un SD F4, 0 (R1) // vettore per uno scalare in F2 ADD R1, R1, -8 BNE R1, R2, Loop; //branches if R1 <> R2
59
Scheduling dinamico della pipeline
• Se la CPU è in grado di prelevare una nuova istruzione dalla Instruction Memory ad ogni ciclo di clock, l’uso delle stazioni di prenotazione permette di fatto di avere istruzioni appartenenti a più iterazioni diverse (ovviamente consecutive) contemporaneamente in esecuzione, e le stazioni stesse fungono da registri addizionali.
• Nel codice dell’esempio, supponiamo che tutte le istruzioni di due iterazioni successive del loop abbiano già passato la fase ISSUE, ma nessuna sia stata completata.
• Ignoriamo per semplicità l’operazione di ADD, che serve per gestire il loop, e assumiamo che il salto venga eseguito.
60
Scheduling dinamico: esempio 2 Loop: LD F0, 0 (R1) (H-P5, Fig. 3.10)
MUL F4, F0, F2 // moltiplica gli elementi di un SD F4, 0 (R1) // vettore per uno scalare in F2 ADD R1, R1, -8 BNE R1, R2, Loop; // branch if R1 <> R2
Instruction Iteration Issue Execute Write Res. LD F0, 0 (R1) 1 √ √ MUL F4, F0, F2 1 √ SD F4, 0 (R1) 1 √ LD F0, 0 (R1) 2 √ √ MUL F4, F0, F2 2 √ SD F4, 0 (R1) 2 √
21
61
Scheduling dinamico: esempio 2 • A regime sono in esecuzione le istruzioni appartenenti a due
iterazioni successive del loop, e questo meccanismo è noto come srotolamento dinamico (dynamic unrolling) del loop, che può fornire notevoli guadagni in termini di tempi di esecuzione.
• Un punto delicato è rappresentato dalle LOAD e STORE appartenenti a cicli diversi. Queste possono essere eseguite in ordine qualsiasi se accedono a indirizzi diversi, ma se usano lo stesso indirizzo si verifica:
– un WAR, se la STORE viene dopo la LOAD ma le due istruzioni vengono eseguite in ordine inverso
– un RAW, se la LOAD viene dopo la STORE ma le due istruzioni vengono eseguite in ordine inverso.
– (notate: due STORE scambiate producono un WAW)
62
Scheduling dinamico: esempio 2 • Per determinare se una LOAD può essere eseguita, la control unit
deve controllare se una STORE non ancora completata e che precede la LOAD indirizza la stessa locazione in RAM (hazard di tipo RAW)
• Analogamente una STORE deve attendere fino a che non ci sono altre STORE o LOAD precedenti e non ancora completate che indirizzano la stessa locazione in RAM (hazard di tipo WAW e WAR)
• Per individuare tali hazard, la CPU deve aver calcolato l’indirizzo in RAM associato ad ogni LOAD e STORE precedente a quella in corso.
• Notate che l’ordine relativo deve essere mantenuto solo per le STORE rispetto alle operazioni di LOAD e STORE, mentre le varie LOAD possono essere riordinate liberamente (perché?)
63
Scheduling dinamico: esempio 2
• LOAD: quando il calcolo dell’indirizzo usato da una LOAD è stato completato, la CU esamina il campo A di tutti gli STORE buffer attivi per individuare eventuali conflitti di indirizzi.
• Se l’indirizzo di una LOAD è uguale all’indirizzo di una qualche entry attiva in uno STORE buffer, la LOAD non viene inviata al LOAD buffer fino a che il conflitto non scompare (ossia, la STORE relativa non è terminata).
• STORE: come la LOAD, ma la CU controlla sia gli STORE che i LOAD buffer attivi, perché le STORE che usano un dato indirizzo non possono essere riordinate rispetto ad altre STORE o LOAD attualmente attive (ossia non ancora completate).
22
64
Scheduling dinamico: esempio 2 Loop: LD F0, 0 (R1) (H-P5, Fig. 3.10)
MUL F4, F0, F2 // moltiplica gli elementi di un SD F4, 0 (R1) // vettore per uno scalare in F2 ADD R1, R1, -8 BNE R1, R2, Loop; // branch if R1 <> R2
Instruction Iteration Issue Execute Write Res. LD F0, 0 (R1) 1 √ √ MUL F4, F0, F2 1 √ SD F4, 0 (R1) 1 √ LD F0, 0 (R1) 2 √ √ MUL F4, F0, F2 2 √ SD F4, 0 (R1) 2 √
65
nome busy Op Vj Vk Qj Qk A
Load1 yes Load Regs[R1]
Load2 yes Load Regs[R1]-8
Add1 no
Add2 no
Add3 no
Mult1 yes MUL Regs[F2] Load1
Mult2 yes MUL Regs[F2] Load2
Store1 yes Store Regs[R1] Mult1
Store2 yes Store Regs[R1]-8 Mult2
Field F0 F2 F4 F6 F8 F10 F12 ... F30
Qi Load2 Mult2
H-P5, Fig. 3.10:
66
Scheduling dinamico: esempio 2 – Provate a descrivere lo stato delle stazioni di prenotazione e ad
analizzare come avviene il completamento (la fase write result) delle load e delle store quando lo stato di esecuzione delle istruzioni è il seguente:
Instruction Iteration Issue Execute Write Res. LD F0, 0 (R1) 1 √ √ √ MUL F4, F0, F2 1 √ √ SD F4, 0 (R1) 1 √ √ LD F0, 0 (R1) 2 √ √ √ MUL F4, F0, F2 2 √ √ SD F4, 0 (R1) 2 √ √
23
67
Scheduling dinamico: osservazioni • Come abbiamo già osservato, tutti i processori moderni che
implementano L’ILP dinamico usano una qualche variante dello schema di Tomasulo.
• Implementare l’ILP dinamico richiede però un hardware complesso e costoso (ogni stazione deve essere realizzata mediante buffer associativi, in modo da limitare al massimo i ritardi introdotti dall’implementazione dello schema stesso), e una logica di controllo molto sofisticata.
• Anche il funzionamento del CDB richiede una hardware molto complesso.
• Una pipeline schedulata dinamicamente può fornire prestazioni molto elevate (vicine ad una istruzione completata per ciclo di clock – ricordate che per ora non consideriamo il multiple issue), purché i salti vengano predetti in modo accurato.
68
Branch Prediction (BP) • Abbiamo già visto qual è il problema associato al controllo.
Considerate le istruzioni:
ADD R1, R4, R5 BNE R1, R2, branchtag; SUB R5, R6, R7
branchtag: ADD R5, R6,R7
• In teoria, fino a che non è noto l’esito del confronto tra R1 ed R2 la CPU non sa quale sarà l’istruzione successiva da prelevare ed eseguire (SUB o ADD), e dovrebbe fermare temporaneamente la pipeline
69
Branch Prediction (BP) • Nelle architetture di tipo RISC, analizzando varie tipologie di
programmi si è visto che, statisticamente, ogni 4-:-7 istruzioni viene eseguito un branch.
• Nel caso di una pipeline a 5 stadi con implementazione “aggressiva” dei branch, eseguiti in soli 2 cicli di clock, la pipeline va fermata per un ciclo di clock in attesa del risultato del confronto, sprecando in questo modo all’incirca 1/5 dei cicli di clock a disposizione.
• In molti casi reali le pipeline sono più profonde, il risultato del confronto è noto solo dopo più cicli di clock, e lo spreco è maggiore.
24
70
Branch Prediction (BP) • Un modo semplice ma efficace per mitigare il problema consiste nel
prelevare comunque l’istruzione “fisicamente” successiva al branch (la SUB nel nostro esempio) e incominciare ad eseguirla nella pipeline.
• Si tratta sostanzialmente di una forma molto semplice di predizione statica: si ipotizza che il salto non verrà eseguito.
• Se la predizione è giusta non si sprecano cicli di clock.
• In caso di errore, la pipeline va svuotata (flushed), mediante opportuni segnali della CU, di tutte le istruzioni nella pipeline successive al branch (potrebbero esserne state prelevate più di una), che non dovevano essere eseguite.
71
Branch Prediction (BP) • In caso di errore di predizione lo spreco di cicli di clock è tanto
maggiore quanto più è profonda la pipeline, e quanto più il risultato del confronto nel branch viene prodotto ben in profondità nella pipeline.
• Purtroppo qualsiasi assunzione di tipo statico sul comportamento dei branch non è sufficiente a garantire un grado di errore abbastanza basso.
• I moderni processori adottano quindi tutti qualche forma di branch prediction dinamico, in cui l’esito di un branch viene ipotizzato sulla base della storia di quel branch: le esecuzioni precedenti della stessa istruzione.
72
Branch Prediction (BP) • Il branch prediction (d’ora in poi intendiamo sempre quello
dinamico) funziona perché molte istruzioni di branch nei programmi vengono eseguite più volte, e il più delle volte si comportano allo stesso modo delle volte precedenti.
• È ovviamente il caso dei branch che controllano i cicli: se si usa un ciclo in un programma è perché si suppone che il gruppo di istruzioni al suo interno dovrà essere ri-eseguito più volte, e quindi probabilmente il branch avrà più volte lo stesso comportamento.
• E’ chiaro che non è possibile alcuna branch prediction nel caso di branch eseguiti una sola volta…
25
73
Branch-Prediction Buffer • La forma più semplice di branch prediction consiste nell’usare un
branch prediction buffer: una memoria con 2n entry indirizzate dagli ultimi n bit meno significativi dell’indirizzo di una istruzione di branch.
• Ogni entry del buffer memorizza un bit di predizione che indica se la volta precedente in cui è stata eseguito quel branch il salto è stato preso o no.
• In sostanza, il buffer si comporta come una cache di informazioni sulle istruzioni di branch.
74
Branch-Prediction Buffer • Alla prima esecuzione del branch il bit di predizione della entry
corrispondente al salto viene appropriatamente settato.
• Se in seguito lo stesso branch viene nuovamente eseguito, e (ad esempio) il suo bit di predizione dice che il salto non va fatto, la CPU continua con l’esecuzione delle istruzioni fisicamente successive al branch.
• Intanto, l’istruzione di branch completa l’esecuzione, e se la predizione si rivela sbagliata (il salto fa fatto) la pipeline viene svuotata e si ricomincia dall’istruzione a cui salta il branch. Il bit di predizione viene complementato.
75
Branch-Prediction Buffer • Domanda (1): cosa succede se il bit di predizione dice che il salto va
fatto?
• Domanda (2): e cosa succede se questa predizione è sbagliata?
• Domanda (3): siamo proprio sicuri che le informazioni in una certa entry del buffer siano proprio quelle relative a quell specifico branch che si sta eseguendo?
26
76
Branch-Prediction Buffer • Il problema di questa forma di predizione è che può produrre più
errori di quanto ci si aspetti intuitivamente.
• Consideriamo un loop iterato 10 volte, dopo di che il programma esce dal loop, per rientrarvi in una fase successiva. Qual è l’accuratezza della predizione?
• Alla fine della decima iterazione vi sarà sicuramente un errore di predizione inevitabile: il bit di predizione dice di eseguire ancora il ciclo, ma il ciclo è terminato. Il bit viene complementato.
• Quando il programma rientra nel loop, la prima predizione è di nuovo sbagliata...
77
Branch-Prediction Buffer • Per evitare questo problema si usa di solito uno schema di
predizione a due bit (local 2-bits predictor): una predizione deve essere sbagliata due volte consecutive prima di venire modificata. Il tutto viene implementato con un automa a 4 stati finiti (P-H5 fig. C.18) :
78
Branch-Prediction Buffer • Lo schema a due bit, sebbene più complesso, funziona molto bene
se, per ciascun branch eseguito più volte, il rapporto fra salti effettuati e no è molto squilibrato.
• In tali casi lo schema a 2 bit si dimostra sensibilmente più efficiente di quello ad 1 bit.
• Visto che 2 bit predicono meglio di 1, sembra naturale pensare di migliorare ulteriormente la capacità predittiva usando, ad esempio, uno schema a 3 bit.
• Stranamente però, la capacità predittiva non aumenta in maniera sensibile usando più di 2 bit di predizione.
27
79
Branch-Prediction Buffer • Inoltre, l’efficacia dello schema dipende dal numero di entry nella
memoria associativa che contiene i bit di predizione per le istruzioni di branch.
• Tipicamente, vengono usate cache da 4096 entry, un valore considerato sufficiente per la maggior parte delle situazioni. Anche 4096 entry però non garantiscono di stare usando i bit di predizione del branch giusto. Perché? In questo caso, che percentuale di corretta predizione possiamo aspettarci?
• Simulazioni varie hanno comunque mostrato che buffer più capienti non forniscono prestazioni sensibilmente migliori
80
Branch-Prediction Buffer • accuratezza di predizione per BPB a 2 bit e 4096 entry (P-H5, Fig.
C.19):
81
Branch-Prediction Buffer
miglioramento dell’accuratezza usando un BPB a 2 bit con un numero infinito di entry rispetto a un BPB a 2 bit con 4096 entry: come vedete, non ci sono quasi differenze (P-H5, Fig. C.19).
28
82
Branch-Prediction Buffer • Per un dato schema di predizione, vi sono dei limiti al grado di
accuratezza che si riesce a raggiungere (ad esempio, lo schema visto non migliora sensibilmente usando più di due bit e più di 4096 entry). Inoltre la capacità predittiva varia in base all’applicazione in esecuzione.
• I processori moderni usano varianti sofisticate delle tecniche di BP viste, in grado di aumentare ulteriormente l’accuratezza della predizione.
• Schema a predittori correlati: combina i predittori a due bit di due salti consecutivi, combinando così la storia locale di un salto con il comportamento dei salti “circostanti”.
• Schema a torneo: in cui ciascun salto ha due predittori diversi, a uno e due bit, e viene ogni volta usato quello che si è comportato meglio la volta precedente.
83
Branch-Prediction Buffer media di errori di predizione per diversi benchmark e 3 diverse tecniche di predizione (H-P5, Fig. 3.4):
84
Branch Target Buffer • Fin’ora abbiamo ignorato un aspetto importante della Branch
Prediction: se il predittore dice che il salto fa effettuato, la CPU non può immediatamente iniziare la fase di fetch dell’istruzione puntata dal salto, perché il suo indirizzo non è ancora noto e va calcolato (PC + offset specificato nell’istruzione di branch).
• Per ovviare a tale problema molte CPU usano un branch target buffer, (detto anche branch prediction cache), che, per ogni branch, memorizza anche l’indirizzo a cui trasferire il controllo se il salto viene predetto come “eseguito”.
• La prima volta che un branch viene eseguito il valore “PC + offset” viene calcolato e messo nel buffer.
• Le volte successive il calcolo non è più necessario. In caso di salto predetto il PC viene aggiornato col valore memorizzato nel buffer.
29
85
Branch Target Buffer Ogni entry del buffer contiene una istruzione di branch del programma in esecuzione (H-P5, Fig. 3.21):
86
Speculazione Hardware • Nel branch prediction la CPU inizia l’esecuzione di alcune
istruzioni prima di sapere se dovranno effettivamente essere eseguite.
• Se si scopre che la predizione del salto è sbagliata, le istruzioni che si trovano prima del salto e sono state inserite erroneamente nella pipeline vengono annullate e si riparte dall’istruzione giusta.
• Consideriamo però la situazione del prossimo lucido, in cui una true data depedence rispetto ad un branch può richiedere uno stall della pipeline molto più lungo di quello dovuto al solo tempo necessario a eseguire l’istruzione di branch.
87
Speculazione Hardware 1. LD F4, 100(R4) // value not in cache… 2. BLE F4, #0.66666, jump // branch if less or equal 3. FADD F1, F1, #0.5 4. DADD R1, R1, #2 5. jump: FADD F1, F1, #0.25 6. DADD R1, R1, #1
• Se il dato caricato dalla LOAD non si trova in cache, ci possono volere decine di cicli di clock per recuperarlo dalla RAM.
• Potremmo allora decidere di usare la Branch prediction sulla BLE, e iniziare e completare l’esecuzione delle ADD controllate dal branch, se questo richiede un numero di cicli di clock molto inferiore al tempo necessario a recuperare il dato atteso dalla BLE.
• Ma che succede se la predizione è sbagliata?
30
88
Speculazione Hardware • La speculazione hardware è la tecnica utilizzata nell’ILP dinamico
per gestire e sfruttare vantaggiosamente situazioni come questa.
• Le istruzioni controllate dal branch vengono eseguite, come se la predizione sul branch fosse corretta (si dice di solito che sono eseguite speculando sul salto, e si parla di istruzioni speculative)
• Ma deve sempre essere possibile annullare le istruzioni speculative nel caso in cui la predizione si riveli errata.
• Domanda: nell’esempio visto, cosa possiamo dire delle istruzioni non controllate da BLE (le istruzioni 5 e 6)?
89
Speculazione Hardware • Il problema è che le istruzioni 3 e 4, controllate dal branch, passano
dei valori alle istruzioni 5 e 6, che andrebbero comunque eseguite.
• Se la LOAD richiede molto tempo, la CPU è in grado di eseguire le istruzioni 5 e 6 prima di riuscire a sapere se doveva eseguire anche la 3 e la 4.
• Ma se la 3 e la 4 non andavano eseguite, i valori calcolati dalla 5 e dalla 6 sono sbagliati, e le due istruzioni vanno rieseguite.
• In altre parole, anche la 5 e la 6 vanno trattate come istruzioni speculative, fino a che non si conosce l’effettivo esito della BLE.
90
Speculazione Hardware • La speculazione hardware prevede, nello schema di Tomasulo, una
unità di commit: un banco di registri interni alla CPU noto come Reorder Buffer (ROB) in cui vengono parcheggiate le istruzioni in attesa di sapere se dovevano effettivamente essere eseguite (H-P5, fig. 4.72 modificata).
Register file
Data memory
31
91
Speculazione Hardware • Nel ROB le istruzioni eseguite vengono memorizzate insieme al
risultato che hanno calcolato, e le entry del ROB fungono quindi da ulteriore supporto alla rinominazione dei registri.
• Quando la CPU “sa” (vedremo tra poco come) che una istruzione nel ROB doveva effettivamente essere eseguita, ne esegue il commit: la toglie dal ROB e permette che il registro di destinazione (o la cella di RAM per le store) dell’istruzione venga aggiornato
• Se invece la CPU si rende conto che l’istruzione non doveva essere eseguita (o eseguita, ma con altri argomenti), semplicemente la rimuove dal ROB, in questo modo annullandone ogni effetto. (in realtà quasi, ogni effetto, perché?)
92
Speculazione Hardware • Sebbene l’esecuzione delle istruzioni possa avvenire out-of-order, il
commit deve avvenire nell’ordine in cui le istruzioni sono entrate in CPU, e per questo il ROB è chiamato così ed è gestito come una coda circolare: ogni istruzione eseguita viene inserita al fondo della coda, e fa scalare di una posizione verso la cima le istruzioni già presenti nel ROB.
• Questo vincolo diminuisce la quantità di lavoro necessario per il controllo delle dipendenze, e rende più facile la gestione delle eccezioni, di per se molto complesso nella speculazione.
• Infatti, pensate, che succede se una istruzione speculativa genera una eccezione, e poi si scopre che quella istruzione non doveva essere neanche eseguita?
93
Speculazione Hardware • Ogni entry del ROB è composta di 4 campi (ed è quindi
implementata con quattro registri nascosti al livello ISA):
1. il tipo di istruzione: branch, che non produce un risultato; store, che scrive in RAM; ALU o load, che scrivono in un registro.
2. il campo destinazione: ossia il numero del registro o l’indirizzo della locazione di memoria modificati dall’istruzione, se questa riuscirà a passare la fase di commit.
3. il campo valore: che memorizza temporaneamente il risultato dell’esecuzione dell’istruzione fino al commit.
4. il campo ready: che indica che l’istruzione ha terminato l’esecuzione (ossia la fase EX) e il contenuto del campo valore è valido.
32
94
Speculazione Hardware • Con la speculazione l’esecuzione di una istruzione I viene divisa in
quattro “macropassi” fondamentali. I primi tre sono gli stessi visti nello schema di Tomasulo:
1. ISSUE: • Dopo le fasi IF e ID, l’istruzione I viene avviata ad una stazione
di prenotazione. I viene anche inserita in fondo al ROB, facendo scalare verso la cima tutte le istruzioni già presenti nel ROB.
• Se disponibili, gli operandi di I vengono inviati alla stazione relativa, prelevandoli da uno dei registri, da un’altra stazione di prenotazione, o da una entry del ROB (perché possono essere nel ROB?)
• il numero della entry del ROB che contiene I viene scritto nella stazione di prenotazione di I (così alla fine della fase EX di I, il risultato di I potrà essere inviato a quella entry del ROB)
95
Speculazione Hardware
2. EXECUTE:
• quando gli operandi sono tutti disponibili l’istruzione I viene inoltrata all’Unità Funzionale corrispondente.
3. WRITE RESULT:
• quando il risultato di I è pronto, viene scritto sul CDB, e da qui viene inoltrato ad ogni stazione di prenotazione che lo stava aspettando (ma, notate, non nel register file o in RAM).
• Il risultato di I viene anche inoltrato verso il ROB e scritto nel campo valore della entry che contiene una copia dell’istruzione I. (il numero della entry da usare è quello scritto nella stazione di prenotazione di I durante la fase ISSUE)
96
Speculazione Hardware 4. COMMIT: (ricordate che il commit delle istruzioni viene fatto in-
order, e che il ROB è gestito come una coda circolare, in cui le istruzioni sono inserite nello stesso ordine in cui sono state prelevate dalla IM)
• quando una istruzione nel ROB raggiunge la testa della coda circolare (perché altre istruzioni sono state inserite nella coda), il commit può avvenire.
• Se l’istruzione non è un branch, il contenuto del campo valore è trasferito nel registro o nella locazione di RAM opportuni. L’istruzione viene rimossa dal ROB.
• se l’istruzione è un branch con predizione sbagliata (si suppone a questo punto che l’esecuzione del branch sia stata completata), tutto il ROB viene svuotato, e la computazione è riavviata dall’istruzione corretta.
33
97
Speculazione Hardware
• notate che se il branch è stato predetto correttamente, in sostanza non accade nulla: l’istruzione di branch viene semplicemente rimossa dalla testa del ROB.
• Nell’effettiva implementazione della speculazione, nel momento in cui la CU scopre che la predizione relativa ad un branch nel ROB è sbagliata, quel branch viene rimosso dal ROB anche se non si trova in testa alla coda. Vengono rimosse anche le istruzioni che lo seguono (eseguite erroneamente), mentre vengono mantenute quelle prima del branch stesso.
98
Speculazione Hardware La struttura di base di una architettura RISC che implementa lo schema di Tomasulo e la speculazione. Notate il ROB e l’assenza dei buffer per le store (perché?).
Per ora fate conto che la “instruction Queue” sia in realtà la Instruction Memory (H-P5, Fig. 3.11):
99
Speculazione Hardware: esempio • Consideriamo una CPU con unità funzionali FP che eseguono una
ADD in 2 cicli di clock, una MUL in 10 cicli di clock e una DIV in 40 cicli di clock. Viene eseguito il seguente codice:
LD F6, 34 (R2) LD F2, 45 (R3) MUL F0, F2, F4 SUB F8, F6, F2 DIV F10, F0, F6 ADD F6, F8, F2
• ecco lo stato delle reservation stations, del ROB e dei registri FP quando la MUL è pronta per il commit (H-P5, Fig. 3.12):
34
100
nome busy Op Vj Vk Qj Dest A Load1 no Load2 no Add1 no Add2 no Add3 no Mult1 no MUL Mem[45+Regs[R3]] Regs[F4] #3 Mult2 yes DIV Mem[34+Regs[R2]] #3 #5
Field F0 F1 F2 ... F5 F6 F7 F8 F10 reorder # 3 ... 6 4 5 busy yes no no ... no yes ... yes yes
entry busy instruction state destination value 1 no LD F6,34(R2) commit F6 Mem[34+Regs[R2]] 2 no LD F2,45(R3) commit F2 Mem[45+Regs[R3]] 3 yes MUL F0,F2,F4 write result F0 #2 x Regs[F4] 4 yes SUB F8,F6,F2 write result F8 #1 - #2 5 yes DIV F10,F0,F6 execute F10 6 yes ADD F6,F8,F2 write result F6 #4 + #2
101
Speculazioni errate
• Le istruzioni eseguite erroneamente sono mediamente di più nei programmi interi (i primi 5 programmi). H-P5, Fig. 3.25
102
Multiple Issue • Se alle tecniche di ILP dinamico viste fin’ora aggiungiamo il
multiple issue: la capacità di lanciare in esecuzione più istruzioni in parallelo, abbiamo la descrizione completa del funzionamento della maggior parte dei processori moderni (single core)
• N.B.: fino ad ora e in tutto ciò che segue, fino al capitolo sui sistemi multi-processore, ragioniamo sulle proprietà di processori in grado di eseguire le istruzioni di un solo processo alla volta, e useremo quindi in modo equivalente i termini: processore, CPU, processore single core, core.
• come abbiamo osservato all’inizio del capitolo, il multiple issue richiede un datapath più ampio, in grado cioè di trasportare le varie informazioni di tutte le istruzioni lanciate in parallelo da uno stadio della pipeline al successivo.
35
103
Multiple Issue • E richiede anche più unità funzionali più sofisticate, in particolare:
a. Deve essere disponibile un numero sufficiente di unità funzionali per l’esecuzione di più istruzioni in parallelo. Ad esempio, più ALU, più unità di moltiplicazione intera / Floating Point, e così via.
b. deve essere possibile prelevare dalla Instruction Memory più istruzioni, e dalla Data Memory più operandi, per ciclo di clock (come vedremo, le memorie cache che contengono le istruzioni e i dati hanno una ampiezza di banda adeguata a questo scopo)
c. Deve essere possibile indirizzare in parallelo più registri della CPU, e deve essere possibile leggere e/o scrivere i registri usati da diverse istruzioni in esecuzione nello stesso ciclo di clock
104
Multiple Issue • Se un processore ha queste caratteristiche, è allora in grado di
avviare all’esecuzione più di una istruzione per ciclo di clock, ed è allora un processore con architettura superscalare. (H-P5, Fig. C.33)
• Notate che possiamo pensare ad un processore superscalare come se avesse più pipeline che operano in parallelo, ognuna delle quali trasporta un’istruzione in esecuzione, come nel primo Pentium.
• Notate anche che, in senso stretto, una architettura superscalare non implementa necessariamente nè lo scheduling dinamico della pipeline nè la speculazione.
105
Multiple Issue • Tuttavia, l’assenza di scheduling dinamico della pipeline limita
fortemente il numero di istruzioni che possono essere effettivamente eseguite in parallelo:
– una istruzione indipendente C che nella pipeline viene immediatamente dopo una coppia di istruzioni fra loro dipendenti A e B subisce comunque lo stall della pipeline causato da A e B.
• Come conseguenza, cercare di aumentare il numero di istruzioni avviate in parallelo in un processore con pipeline schedulata staticamente è poco produttivo (in realtà dovremmo dire: in un processore che implementa l’ILP dinamico)
36
106
Multiple Issue • Per questa ragione, i processori con scheduling statico della pipeline
hanno di solito un multiple issue limitato al più a due istruzioni per ciclo di clock, tanto non riuscirebbero a sfruttare un multiple issue più elevato.
• Anche così, devono ricorrere alle tecniche basate sull’ILP statico (in particolare, all’aiuto del compilatore) per poter aumentare al massimo il valor medio del CPI.
• Una ampiezza di banda superiore a due istruzioni per ciclo di clock (di solito fino ad un massimo di 4 o 5 istruzioni avviate in parallelo) richiede invece una CPU con scheduling dinamico della pipeline o un processore VLIW (prossimo capitolo)
107
Multiple Issue
• Vediamo a grandi linee come funziona un processore superscalare.
• Preleva dalla IM (ossia dalla cache di istruzioni di primo livello) da 0 a N istruzioni per ciclo di clock, dove N è il numero massimo di istruzioni che la IM riesce a fornire in parallelo.
• Le istruzioni vengono messe in una Instruction Queue (IQ) per poter essere analizzate dalla logica della CU che deve risolvere eventuali alee e dipendenze.
• Potete notare questa Instruction Queue nelle figure H-P5 3.6 e 3.11. A seconda del tipo di processore, l’IQ ha una dimensione di qualche decina di entry (il valore preciso dipende dal tipo di processore, e nuovi processori tendono ad avere IQ più grandi)
108
Multiple Issue • La logica di controllo della CPU controlla la presenza di eventuali
alee strutturali e sui dati tra le istruzioni nella IQ e avvia all’esecuzione (cioè instrada verso le stazioni di prenotazione) (alcune del)le istruzioni indipendenti, liberando così spazio nella Instruction Queue.
• Al successivo ciclo di clock vengono prelevate dalla IM un altro gruppo di istruzioni (possibilmente il numero massimo possibile).
• Presumibilmente il numero di istruzioni che la CPU riesce ad avviare all’esecuzione è inferiore al numero di istruzioni che riesce a prelevare dalla IM.
• A regime quindi, la IQ tende riempirsi di istruzioni, e se ad un certo ciclo di clock M istruzioni vengono avviate all’esecuzione, al massimo M ≤ N altre istruzioni possono essere prelevate dalla IM al successivo ciclo di clock
37
109
Multiple Issue • Come caso limite, se la IQ è piena, e a causa delle alee nessuna
istruzione è stata inviata alla fase EXECUTE al ciclo precedente, nessuna istruzione può essere prelevata dalla IM al ciclo successivo.
• Anche se nella IQ c’è spazio, perché il processore potrebbe prelevare un numero di istruzioni inferiore alle entry disponibili nella IQ?
• Notate che, a regime, la CPU deve controllare la presenza di dipendenze e alee tra qualche decina di istruzioni, il che può richiedere migliaia di confronti incrociati (che devono essere fatti in uno o due cicli di clock!)
• Notate anche che se è implementata la speculazione la CPU deve anche essere in grado di eseguire il commit di più istruzioni nel ROB per ciclo di clock, che altrimenti diviene il collo di bottiglia del sistema.
110
Multiple Issue: esempio Loop: LD F0, 0 (R1)
FADD F4, F0, F2 SD F4, 0 (R1) ADD R1, R1, -8 BNE R1, R2, Loop; //branches if R1 <> R2
• Usiamo lo schema di Tomasulo per schedulare dinamicamente una versione superscalare della macchina MIPS con una ALU e una unità F.P., in grado di avviare due istruzioni per ciclo di clock, e senza speculazione. Assumiamo che il branch BNE sia predetto correttamente con un branch target buffer.
• Nel diagramma del lucido successivo, lo scheduling dinamico dei primi tre cicli del codice. ( I = Issue, X = Execute, M=Memory access, W=Write results to CDB)
111
Multiple Issue: esempio • Alcune assunzioni aggiuntive:
• La fase X (execute) della FADD richiede 3 cicli di clock.
• Branch prediction perfetto, ma le istruzioni che seguono il branch non possono passare alla fase X fino a che la condizione del branch non è stata valutata (infatti non è implementata la speculazione).
• Un valore calcolato viene scritto sul CDB alla fine del ciclo di clock in cui il valore è stato prodotto, ed è quindi disponibile nelle varie stazioni di prenotazione che lo attendono solo alla fine del ciclo successivo
• La ALU viene usata sia per le operazioni intere che per il calcolo degli indirizzi di load e store.
38
112
Multiple Issue: esempio clck LD FADD ST ADD BNE LD FADD ST ADD BNE LD FADD ST ADD BNE
1 I I
2 X I I
3 M X I
4 W X I I
5 X W I I
6 X X I
7 X X I I
8 W M X I I
9 M W X I
10 X W
11 X X
12 X X
13 W M X
14 M W X
15 X W
16 X X
17 X
18 W
19 M
113
Multiple Issue: esempio • Vengono eseguite 15 istruzioni (tre cicli) in 19 colpi di clock, per un
CPI di 19/15 = 1,27
• Potremmo fare meglio di così?
• Notate che la ALU è usata per le operazioni intere e per il calcolo degli indirizzi, per cui diviene un collo di bottiglia.
– Usando due ALU separate Le istruzioni verrebbero completate in 12 anziché 19 cicli di clock.
• Inoltre, l’unità FP è sotto utilizzata (una sola operazione FP per ciclo), e 2 delle 5 istruzioni sono puro overhead in ogni loop (ADD e BNE)
– Potremmo allora applicare il loop unrolling statico per aumentare il numero di operazioni FP e diminuire l’overhead di ogni ciclo (ma questo lo vedremo nel prossimo capitolo)
114
Perché l’ILP dinamico funziona? • I processori che implementano l’ILP dinamico cercano di
minimizzare le alee strutturali, sui dati e sul controllo a run time, e devono svolgere un lavoro molto complesso in pochi cicli di clock.
• Perché non cerchiamo di spostare tutto il lavoro necessario a sfruttare il parallelismo insito nelle istruzioni al livello del compilatore, che ha molto più tempo per analizzare e risolvere (se possibile), le varie alee presenti in un programma?
• Vi sono sostanzialmente 3 ragioni:
1. I miss cache non sono prevedibili staticamente, e l’ILP dinamico può parzialmente nasconderli eseguendo altre istruzioni, mentre una istruzione attende dalla RAM il dato mancante in cache.
39
115
Perché l’ILP dinamico funziona? 2. I salti non sono prevedibili con accuratezza in modo statico e il
BP dinamico e la speculazione aumentano la probabilità di riuscire a sbrigare del lavoro utile in anticipo rispetto al momento in cui si conosce l’esito dell’esecuzione delle istruzioni di branch.
3. L’ILP statico funziona bene solo su una specifica architettura, come vedremo approfonditamente nel prossimo capitolo. Con l’ILP dinamico i programmi possono essere distribuiti e girare su architetture diverse (purché con ISA compatibili) per numero di unità funzionali, numero di registri rinominabili, numero di stage della pipeline, tipo di predizione dei salti (diversi tipi di pentium, core duo, AMD, ad esempio)
• L’ILP dinamico funziona, ma quanto funziona?
116
I limiti teorici dell’ILP dinamico
• Abbiamo visto molte tecniche complesse per sfruttare a run-time il parallelismo presente nelle istruzioni di un programma.
• Ma, a prescindere dalle limitazioni pratiche (ossia dalle risorse hardware effettivamente disponibili) quanto parallelismo potremmo sfruttare?
• Le uniche limitazioni teoriche sono quelle sulle vere dipendenze tra i dati:
LD F0, 0 (R1)
ADD F4, F0, F2
• tutte le altre limitazioni possono essere superate con sufficiente hardware e sufficiente conoscenza disponibili
117
I limiti teorici dell’ILP dinamico • Facciamo le seguenti assunzioni su una CPU virtuale:
– register renaming: la CPU ha un numero infinito di registri rinominabili. Quindi, tutti gli hazard WAW e WAR sono eliminati e un numero arbitrario di istruzioni può essere eseguito simultaneamente
– Branch prediction: perfetto
– Memory-address alias analysis: tutti gli indirizzi di RAM sono noti, per cui si possono sempre evitare le dipendenze sui nomi in RAM. Ad esempio, sappiamo sempre se #57 (R5) = #10 (R1)
– Multiple issue: illimitato
– Cache memory: non si verificano miss.
40
118
I limiti teorici dell’ILP dinamico
• notiamo come i programmi FP tendano ad avere più parallelismo sfruttabile a livello di ciclo di clock
• Ecco i risultati per alcuni benchmark. (H-P5, Fig. 3.26)
119
I limiti teorici dell’ILP dinamico • Ora limitiamo il multiple issue, il che significa anche limitare il
numero massimo di istruzioni consecutive che possono essere contemporaneamente prese in considerazione per cercare dipendenze tra i dati (assumendo il branch prediction perfetto)
• Il lavoro da fare (e che va fatto velocemente, in un ciclo di clock o due) come sappiamo, può essere enorme. Alcune stime:
• 2000 istruzioni: 4 milioni di confronti
• 50 istruzioni: 2500 confronti
• Quest’ultimo è il numero medio di confronti in grado di compiere una moderna CPU (in uno o due cicli di clock!)
120
I limiti teorici dell’ILP dinamico Ecco come si degrada la possibilità di sfruttare l’ILP in questo caso (H-P3, Fig 3.37).
E notare che, nel caso reale, il multiple issue difficilmente supera le 5 o 6 istruzioni per ciclo di clock…
41
121
I limiti teorici dell’ILP dinamico Alla precedente limitazione reale, ora aggiungiamo quella sul branch prediction, usando diversi tipi di predizione (H-P3, Fig. 3.39)
122
I limiti teorici dell’ILP dinamico • Come vedete, considerando alcune limitazioni reali, lo sfruttamento
dell’ILP degrada velocemente.
• Se aggiungiamo le altre limitazioni prima ignorate, come un numero finito di registri rinominabili, l’impossibilità di analizzare in modo perfetto i riferimenti alla RAM, la presenza di cache miss, e così via, l’effettivo sfruttamento dell’ILP risulta ancora più limitato.
123
Un po’ di (fanta)scienza • E’ chiaro che lo sfruttamento dell’ILP può essere aumentato
aumentando il numero di risorse disponibili (cache, registri, logica usata per analizzare le dipendenze). Ma a parte questo?
• Alcune ricerche cercano di analizzare la possibilità di eseguire qualche forma di value prediction (VP).
• il VP consiste nel cercare di predirre il valore dei risultati prodotti dalle istruzioni, e l’indirizzo effettivo specificato nelle istruzioni di LOAD e STORE
42
124
Un po’ di (fanta)scienza • Se si riesce a predirre in anticipo il risultato dell’esecuzione di una
istruzione, questo può essere passato ad altre istruzioni che lo useranno come operando.
• E’ evidente che questa è una forma di speculazione su istruzioni non di salto, e permette(rebbe) di eseguire istruzioni fra loro dipendenti.
• Ovviamente ciò è possibile solo se la predizione ha buone possibilità di essere corretta, il che può verificarsi per alcuni tipi di situazioni.
• A cosa porterebbe una capacità di predizione perfetta?
125
Un po’ di (fanta)scienza • Un’altra forma di predizione può essere condotta sugli indirizzi
usati nelle LOAD e STORE, e permetterebbe di riordinare l’esecuzione di tali istruzioni senza incorrere su hazard di tipo WAW o WAR.
• Alcuni studi indagano poi sulla possibilità di speculare su branch multipli, nidificati e no, fino ad 8 branch consecutivi...
