Dispensa Calcolatori..

Calcolatori Elettronici II
23/03/2004
Questa sopra è una curva che rappresenta le performance evolutive al passare degli anni.
Quella in basso è la curva che dà ragione della crescita delle prestazioni se questa fosse soltanto
dovuta all’innovazione tecnologica.
Si vede che inizialmente le curve sono molto vicine e poi da un certo punto succede qualcosa, nel
senso che il tasso di crescita della prestazione ha un brusco incremento, e come si vede poi si arriva
al punto per cui, negli anni 2000, si ha un incremento al di sopra di quello che ci si poteva aspettare
soltanto dall’innovazione tecnologica (fattore 10-15).
Oggi occorrono 1000$, o anche meno, per un personal computer che ha più performance, memoria
e disco di un computer che negli anni '80 era un supercomputer e che veniva venduto per
1.000.000$. Questo dà l'idea di quello che è successo negli ultimi 20 anni.
Che cosa ha prodotto questo?
Le cause sono sostanzialmente due:
1. I progressi dovuti all'innovazione tecnologica;
2. L'innovazione nei principi di progettazione dei computer.
Fino agli anni '70 queste due cause concorrevano pressoché allo stesso livello, cioè avevano la
stessa importanza per quanto riguardava la crescita delle performance dei computers: normalmente
si aveva un 25%-30% di tasso di crescita annuale delle prestazioni.
Da un certo punto in poi è successo qualcosa che ha rivoluzionato quel trend, ed in particolare
l’avvento dei microprocessori, che è stato dovuto all’innovazione tecnologica, alla tecnologia MOS,
quindi alla grande capacità di integrazione che si è resa disponibile, e alla possibilità di integrare
all’interno di un unico chip quella che normalmente viene chiamata CPU, che prima veniva
realizzata a logica discreta. Questo ha fatto sì che i progettisti cavalcassero questa tendenza
abbandonando via via la logica discreta nel realizzare i computer, e quindi facendo morire dei
settori che erano i settori prevalenti dei minicomputer e dei mainframes (grossi computer). Questo
ha fatto sì che l’incremento delle prestazioni dal 25%-30% l’anno passasse al 35%.
1

In realtà però questo salto essenzialmente era dovuto, più che all'innovazione nelle tecniche di
progettare un computer, quasi esclusivamente alla tecnologia. Ad un certo punto c'è stata una
svolta: fino a quel punto si lavorava tipicamente in assembler, e questo significa che non era facile
programmare, e poi quando veniva creato un nuovo microprocessore si cercava di renderlo
compatibile con quello precedente, almeno per quanto riguardava l'esecuzione del codice; un
esempio classico è quello della famiglia Intel (che è nata con l'8080, che era un microprocessore a 8
bit, poi è nato l'8085, l'8086, l'80186, …, l'80486, Pentium), dove un codice sviluppato negli anni
'80 ancora girerebbe su un Pentium. Questo era legato non al fatto che il progettista nel progettare il
prossimo microprocessore era “innamorato” dell'architettura precedente, ma ad un fatto pratico,
cioè al fatto di non sprecare tutte le risorse investite nel progettare il software che girava su quel
microprocessore. Questo era un vincolo fortissimo per il progettista. A metà degli anni '80 però via
via si è cominciato ad abbandonare il linguaggio assembler, perché i programmatori cominciavano
ad usare sempre più i compilatori. Abbandonare il linguaggio assembler significava incominciare ad
eliminare quel vincolo sulla compatibilità del codice: se ho un codice scritto in C e voglio passare
da un processore all'altro ricompilo e non devo rifare il software. Però questo è uno degli aspetti;
l'altro aspetto fondamentale è legato ai sistemi operativi: fino a quel tempo i sistemi operativi erano
essenzialmente i sistemi operativi proprietari, e questo significava che quando l'IBM, per esempio,
vendeva ad una banca un software che girava su quel sistema operativo, questa era bloccata a vita
su quella piattaforma perché il software fa riferimento al sistema operativo.
Poi è stato creato Unix: è stato concepito all'interno di un’università, quindi era un software libero,
non risentiva di logiche di mercato e si poneva quindi come un sistema operativo che non era legato
ad una particolare piattaforma hardware. Unix è stato già dall'inizio progettato, quasi tutto scritto in
C e non più in assembler, per essere indipendente dalla piattaforma. Questo ha fatto sì che il
progettista improvvisamente si trovasse di fronte ad una libertà inaspettata. A questo punto,
Patterson ed Hennessy non dovendo più sottostare a quei vincoli potevano progettare un processore
che aveva delle prestazioni molto più elevate delle architetture che in quel momento erano in
circolazione. Questa logica ha fatto sì che si incominciasse ad affermare la nuova filosofia di
processori, che è quella che si chiama RISC (reduced instruction set computer).
A parità di tecnologia perché una filosofia RISC dovrebbe avere prestazioni migliori?
Patterson ed Hennessy hanno fatto una considerazione: prima si programmava in assembler, e oltre
al problema della compatibilità del codice c'erano altri problemi, cioè un programmatore assembler
da un nuovo processore si aspetta un set di istruzioni molto ricco così ha una certa libertà nello
scegliere il proprio stile di programmazione. Una volta che non si programma più in assembler non
è più programmatore che utilizza il set di istruzioni del processore ma il compilatore, ovvero il
progettista del compilatore; allora ci si è chiesti il perché continuare a progettare un processore con
set di istruzioni ricchissimo (ricchissimo significa che da un punto di vista implementativo più
esteso e complesso è il set di istruzioni più complesso è l'hardware che poi realizza quel set di
istruzioni, e quindi occupa più area sul silicio) se poi nessuno più lo utilizza, o meglio non si sa
quanto è utilizzato. Qual è il modo più semplice e diretto di capire se conviene o no progettare un
set di istruzioni ricco visto che adesso ci sono i compilatori? Si cominciano a compilare tanti
programmi diversi tra loro e vado a vedere ogni per programma compilato quali sono le istruzioni
del processore che utilizza, e magari faccio una statistica. Facendo questo posso scoprire che, per
esempio, un’istruzione pazzesca che qualcuno aveva concepito in quel microprocessore dal
compilatore non veniva mai usata o quasi mai; ma allora se io la tolgo il compilatore entra in crisi
oppure si può sempre trovare una strategia per cui quella istruzione io la faccio la stessa però
usando altre istruzioni? La risposta naturalmente è sì. Siccome progettare un processore significa
innanzitutto definire il suo set di istruzioni, e siccome il progettista sa che più complesso è il set di
istruzioni più complesso è il processore, allora incomincia a vedere un determinato compilatore su
quel processore che ha un set complesso di istruzioni quante ne utilizza, e quindi si fanno delle
statistiche, delle misure sull'utilizzo del set di istruzioni. Facendo queste misure è emerso che
moltissime istruzioni erano praticamente quasi mai utilizzate. Allora a questo punto la cosa più
2

ovvia era ridurre il set di istruzioni all'essenziale; ma riducendo il set di istruzioni qual è il
vantaggio che si ottiene? Se il set di istruzioni è meno complesso significa che l'hardware è meno
complesso e quindi posso andare più veloce. Se io diminuisco il numero di transistor all'interno del
chip per eseguire le istruzioni, i rimanenti transistor li posso utilizzare per metterci dentro la
memoria oppure per realizzare il pipeline (un modo di eseguire più istruzioni contemporaneamente
all'interno dello stesso processore). Normalmente il processore è molto più veloce della memoria,
allora se all'interno del processore si sono liberati tanti transistor potrei utilizzare quell'aria di silicio
libera per mettere un po’ di memoria dentro, per esempio dei registri; questo mi fa andare più
veloce perché si risparmiano un sacco di accessi in memoria.
Un aspetto è la memoria cache. Tutte le volte che si va memoria il processore deve rallentare
moltissimo, allora la possibilità di inventarsi la gerarchia di memoria, cioè la memoria cache, è un
qualcosa che fa pagare molto meno il prezzo al processore sulla lentezza della memoria.
Facendo queste innovazioni si incomincia ad assistere ad un rate di crescita delle prestazioni di oltre
il 50% per anno, e questo è quello che dà la spiegazione dell'andamento di quelle curve.
Conseguenze:
• Un microprocessore di oggi supera le prestazioni di un supercomputer di 10 anni fa
• Dominanza di computer a microprocessore (PC+WS) sull'intero range dei computers
(minicomputer e mainframe sostituiti da multiprocessore).
Tutto questo è dovuto a questa innovazione nell'arte di progettare, innovazione che si basa sul
principio fondamentale che è quello di un approccio quantitativo alla progettazione. Approccio
quantitativo significa che prima di progettare qualcosa vado a fare delle misure vedo quello che già
ho come viene utilizzato, e se ci sono cose che vengono utilizzate raramente queste sono le
candidate ad essere buttate via, e questo significa inventarsi qualcosa di nuovo.
Questa è una possibile rappresentazione della catena alimentare: i pesci più grossi mangiano i pesci
più piccoli:
Questa catena alimentare nel caso dell'informatica è stata ribaltata:
Alcune conseguenze dell'approccio quantitativo sono:
• Le prestazioni delle workstation migliorano del 50% per anno
• Se si tiene conto del fattore costo un miglioramento costo-prestazioni del 70% per anno.
Quando parliamo di computer che cosa intendiamo esattamente?
Oggi ci sono tre segmenti di mercato che è abbastanza facile identificare:
• Desktop computing (PC + WS)
• Servers: file server, web server, ecc…
• Embedded computers: parte più in crescita del mercato.
3

Questi tre segmenti di mercato però hanno caratteristiche diverse da diversi punti di vista:
Nell'ultima riga sono riportate le caratteristiche tipiche di ognuno dei tre settori: nel caso del
desktop due parametri importanti sono il prezzo e le prestazioni (anche sulla grafica); per quanto
riguarda il server si vuole un throughput elevato, cioè che riesca per esempio a processare un certo
numero di milioni di richieste secondo, la disponibilità, che significa la capacità del sistema a
continuare a mantenersi funzionante anche in presenza di guasti, e poi la scalabilità, ovvero la
capacità del sistema ad essere espanso (un server normalmente prevede la possibilità di aumentare
la capacità di memorizzazione, la possibilità di aggiungere processori, ecc…); per quanto riguarda i
sistemi embedded questi sono caratterizzati sicuramente dal prezzo, il consumo di potenza,
prestazioni per quella specifica applicazione.
Dopo aver parlato di questa suddivisione e aver visto come i tre settori richiedono parametri di
performance diversi, il compito del progettista è quello di determinare quali sono gli attributi della
nuova macchina, e progettare per massimizzare la prestazioni rispettando i vincoli di costo e
potenza, naturalmente collocandosi nel settore orientato (desktop, server o embedded).
Un aspetto molto interessante è quello legato alla tendenza della tecnologia: perché un progettista di
computer deve preoccuparsi moltissimo della tendenza tecnologica? Se io progettista ho oggi una
certa tecnologia e il progetto del prossimo processore lo faccio con quello che ho a disposizione,
perché mi devo preoccupare della tecnologia che avrò fra due anni?
Ci sono dei dati che sono abbastanza consolidati che riguardano l'evoluzione della tecnologia:
(capacity = capacità d’integrazione)
C'è un parametro che assume un ruolo cruciale: time to market = 2 anni design + produzione. Il
time to market è il tempo che si impiega ad immettere un nuovo prodotto sul mercato. Se io ho un
time to market, per esempio per una workstation, di due anni e faccio il progetto con la tecnologia
di oggi faccio un errore clamoroso perché se fra due anni il trend tecnologico è quello visto sopra
allora la capacità, per esempio, sarà sicuramente maggiore di quella di oggi. Quindi bisogna
guardare a cosa ci sarà disponibile quando il prodotto andrà in produzione.
Altri aspetti legati alla tecnologia sono:
• Feature size: minima size di un transistor o wire nelle direzioni x e y
10µ (1971) → 0,08µ (2003)
Il numero di transistor incrementa quadraticamente con la diminuzione della feature size,
mentre la performance invece aumenta linearmente con la feature size.
• All'aumentare della capacità di integrazione e della frequenza di funzionamento di questi
dispositivi il ritardo di propagazione (wire delay) dei segnali incomincia ad essere rilevante:
4

molti cicli di clock sono spesi per il ritardo sulle linee, e nel caso del Pentium IV due stage di
pipeline su 20 sono consumati per la propagazione dei segnali attraverso il chip.
• Potenza (power): l'incremento del numero di transistor per chip e la frequenza di switching
comporta un incremento del consumo di potenza (qualche decina di W per un microprocessore
anni '80, 100 W per il Pentium IV a 2GHz).
Nel prossimo futuro la potenza sarà il limite principale.
5

25/03/2004
Abbiamo visto che una delle chiavi fondamentali che spiega l'elevato incremento delle performance
nei computers è un nuovo approccio alla progettazione: un approccio di tipo quantitativo, quindi un
approccio che sostanzialmente assume come paradigma quello di eseguire delle misure e sulla base
di queste misure selezionare quelli che sono gli aspetti più rilevanti, quindi quelli che sono più
suscettibili di essere migliorati garantendo un elevato livello di performance, e trascurando altri
aspetti che, per quanto possono offrire scelte che soddisfano l'utente, magari poi sono molto poco
utilizzati.
Per fare queste misure questo approccio quantitativo utilizza vari strumenti che si basano su un
insieme di programmi che si chiamano Benchmarks, sui Traces (queste informazioni vengono
derivate a fronte dell'esecuzione di un programma, e per esempio questi traces ci dicono
un'istruzione rispetto al totale quante volte viene eseguita), sugli instruction Mixes (mi dicono per
esempio 30% di ALU e così via).
Abbiamo visto, per esempio, nel caso dei sistemi embedded che uno dei requisiti fondamentali,
oltre alla performance per quella determinata applicazione, per esempio era il consumo di potenza,
ma si capisce bene è fondamentale anche l'area consumata sul silicio. Quindi sono stati messi a
punto strumenti per la stima della potenza, dell'aria, del delay (tempo speso per eseguire un
programma), ecc.
Naturalmente poi ci sono strumenti che provano valutare i vari parametri di interesse attraverso
teorie “tradizionali”, quale la teoria delle code, regole di tipo pratico, e leggi fondamentali.
Oggi incominciamo a vedere cosa significa valutare alcuni parametri prestazionali dei sistemi
partendo da alcune definizioni di base. Per noi misurare le prestazioni di un computer, per esempio
in termini di velocità, significa valutare il tempo di esecuzione, cioè all'utente finale quello che
interessa è quanto tempo viene speso da questo oggetto per eseguire una determinata applicazione,
quindi si parla di ExTime (execution time): dire che un computer X è n volte più veloce di un
computer Y significa dire che
(per un web server non ci interessa l’ExTime, ma il throughput). A seconda che si parla di ExTime,
oppure di throughput, oppure di qualsiasi altro parametro, devo stare attento a cosa mettere
numeratore per dire che una cosa è più performante di quella precedente; questa ambiguità si
elimina, quanto meno a livello di linguaggio, parlando di rapporto di prestazioni: se io dico che la
macchina X è più performante della macchina Y di n volte, significa che
Naturalmente in questo caso si ha che , se la mia performance è
espressa in termini di tempo di esecuzione; se invece come performance intento il throughput ecco
che la performance coincide con il throughput.
Se X è n% volte più veloce di Y significa che
dove
> 1
> 1
,
6

Esempio:
Se Y impiega 15 secondi per eseguire un task e X impiega 10 secondi, quanto % X è più veloce?
n=50%.
Legge di Amdahl
Questo è un principio che dovrebbe essere sempre seguito da un progettista, e in verità occorrerebbe
seguirlo sempre a prescindere che il progetto riguardi un computer piuttosto che un'automobile, ecc.
Make the common case fast! (rendi il caso più frequente veloce).
“Più frequente” come va inteso? Va inteso che quando io utilizzo il sistema c'è una sua parte che è
responsabile di molto del tempo di lavoro del sistema, allora intuitivamente un miglioramento
apportato a questa parte ci ripaga sufficientemente.
In miglioramento di prestazioni che può essere ottenuto migliorando una qualche attività, quindi
rendendola più veloce, è limitato dalla frazione di tempo in cui tale attività ha luogo.
SPEEDUP: misura di quanto più veloce un task gira sulla macchina enhanced. Quindi se io misuro
uno Speedup = 1.5 significa che ho migliorato le performance del 50%.
Vediamo come si ricava una qualche relazione che ci consenta quantitativamente di misurare qual è
lo Speedup che si ottiene quando si apporta un miglioramento ad un sistema.
Supponiamo di avere un programma che impiega il seguente tempo (la ExTime) per essere
eseguito; analizzando il sistema vedo che c'è una sua parte che si
può migliorare e in termini di tempo di esecuzione è
responsabile di quella frazione di tempo (parte colorata) rispetto al totale. Questa parte a cui applico
il miglioramento posso renderla più veloce, e questo significa che nel nuovo sistema quella parte si
contrarrà, e quindi il tempo di esecuzione totale si accorcerà:
Il rapporto tra il primo tempo di esecuzione e il secondo mi dà lo Speedupoverall (cioè Speedup
complessivo).
Le due grandezze che ci interessano sono: Speedupenhanced (Speedup Enhanced, cioè lo Speedup che
posso ottenere solo della parte a cui applico il miglioramento); il rapporto tra il tempo da migliorare
e l’ExTime totale si chiama FractionEnhanced (cioè la frazione di tempo a cui posso applicare il
miglioramento, si misura sul sistema originario).
Avendo definito queste due grandezze possiamo vedere come si misura lo Speedupoverall.
Quest'ultimo non è altro che:
(woE = without enhancement, wE = with
enhancement).
Il nuovo tempo di esecuzione è dato da:
Così lo Speedupoverall è:
Questa formula ci consente di fare un sacco di valutazioni per scoprire se un determinato
miglioramento ripaga oppure no in termini di guadagno complessivo che si può ottenere.
Nelle annunciato della legge di Amdahl abbiamo detto che il performance improvement è limitato
dalla frazione di tempo in cui l'attività ha luogo; questa frazione di tempo è proprio la
FractionEnhanced; ovvero il massimo Speedup ottenibile è limitato dalla FractionEnhanced. In che senso?
7

Immaginiamo, caso irrealizzabile, di trovare un’idea che fa sì che una certa parte del sistema possa
andare infinitamente più veloce di quanto va adesso; questo significa che lo Speedupenhanced sarebbe
infinito e quindi il rapporto FractionEnhanced/Speedupenhanced tenderebbe a 0; più elevata è la
FractionEnhanced maggiore è lo Speedupoverall.
Da questa analisi semplicissima si può concludere che quello che in effetti ha un impatto enorme
dal punto di vista di guadagno di prestazioni complessivo è la FractionEnhanced, ovvero la frazione di
tempo suscettibile di essere migliorata: maggiore è questa frazione di tempo maggiore è il guadagno
che si può ottenere, e questo ragionamento lo si fa indipendentemente da quanto veloce si vuole
rendere.
Esempio
Prendiamo un computer che ha un certo processore in cui la parte relativa all’esecuzione delle
istruzioni in floating point può essere migliorata facendola andare al doppio di velocità rispetto a
quella attuale, quindi abbiamo uno Speedupenhanced pari a 2; qual è il guadagno che possiamo
ottenere? Per rispondere a questa domanda dobbiamo stimare la FractionEnhanced. L’unità floating
point viene utilizzata dai programmi, quindi non devo parlare in astratto, ma prendo un programma,
suppongo che è il programma che mi interessa, e vedo quanto tempo viene speso (da questo
programma) durante l’esecuzione sull’unità floating point rispetto al totale. In questo caso
supponiamo che soltanto il 10% delle istruzioni eseguite sono di tipo floating point, ed è come dire
che soltanto il 10% del tempo rispetto al totale del tempo di esecuzione, di un determinato
programma, viene speso per la parte floating point. Questo 10% rappresenta la FractionEnhanced.
Applicando le formule abbiamo:
Quindi viene fuori che lo Speedup è pari al 5,3%.
Esempio
Dato un computer cerchiamo di rendere più veloce la CPU di 5 volte, ma questo ci costa 5 volte il
costo originale della CPU. Quanto ci guadagno?
Per vedere se questo investimento è economicamente vantaggioso devo vedere quanto ci guadagno
in termini di performance e quanto mi costa questo guadagno di performance.
I dati che abbiamo sono:
la CPU nel sistema originario è responsabile del 50% del tempo totale di esecuzione (di un
determinato programma); questo significa che l’altro 50% è dedicato all’I/O. Il costo della CPU è
di 1/3 del costo totale del sistema.
La prima cosa che facciamo è valutare lo Speedup:
Quindi ottengo un miglioramento di performance complessivo pari al 67%.
Quanto mi costa questo investimento? I 2/3 del sistema continueranno a costare quanto prima,
mentre l’altro 1/3 costerà 5 volte di più:
Quindi mi costerà 2,33 volte il costo originario.
Così ho che il costo cresce molto di più delle performance.
8

Esempio
Supponiamo di avere un computer su cui viene eseguito una determinata applicazione. Questa
applicazione ha delle operazioni in floating point alcune delle quali sono radici quadrate (FPSQR).
In totale l’unità floating point è responsabile del 50% del tempo di esecuzione, e la sola FPSQR è
responsabile del 10% del tempo di esecuzione totale. A questo punto c’è una gara tra due tipi di
progettazione diversi:
1) l’hardwareista dice che riesce a migliorare l’hardware del FPSQR in modo tale da farlo andare
10 volte più veloce;
2) il softwareista dice che può ottenere il doppio di velocità dell’intera unità floating point.
Nel primo caso ho una FractionEnhanced che è pari a 0,2 e uno Speedup di 10, e allora ne segue che:
Nel secondo caso ho una FractionEnhanced che è pari a 0,5 e uno Speedup di 2, e allora ne segue che:
Quindi migliorano di più le prestazioni se aumento la velocità di tutta l’unità floating point anche se
solo del doppio, rispetto al miglioramento della sola FPSQR anche se di 10 volte.
Abbiamo detto che uno dei dilemmi che fa diventare matti i progettisti di computer è quello della
lentezza della memoria. È un problema perché il computer nasce come una macchina per eseguire
programmi e la CPU non fa altro che andare a leggere l'istruzione della memoria ed eseguirla.
Quindi sicuramente per ogni istruzione bisogna fare quanto meno un accesso in memoria; questo
significa che tutti i miglioramenti di prestazioni che si riescono ad apportare al processore possono
essere vanificate dalla lentezza della memoria. Cosa si può fare per cercare di risolvere questo
problema, o quanto meno di farlo pesare poco?
Non potendo fare niente la tecnologia, qualcuno si è inventato una soluzione estremamente
intelligente. Questa soluzione fa riferimento ad un principio che è il cosiddetto principio di
località, e ad un altro principio che è molto legato all'elettronica. Per quanto riguarda l'elettronica
c'è un principio che dice che: “smaller is faster” (più piccolo è più veloce). Sappiamo che quando
parliamo di memorie RAM ci sono due tipologie: RAM statiche e RAM dinamiche. Le RAM
statiche sono caratterizzate da una velocità più elevata delle RAM dinamiche, però le prime hanno il
problema che consumano di più, perché sono più veloci, e la loro capacità di integrazione è molto
più bassa delle seconde.
Il principio di località è un principio che fa riferimento ad una considerazione base: quando eseguo
un programma vado in memoria legge un istruzione, la eseguo e vado all'istruzione successiva, ecc.;
queste istruzioni quando un programma viene caricato in memoria si succedono una dopo l'altra
nella memoria; quindi quando io eseguo l'istruzione i-esima è probabile che la prossima da eseguire
sta nella locazione di memoria immediatamente successiva. Questo è quello che ha fatto pensare a
qualcuno che allora c'è una località nell'esecuzione del programma, e questo è quello che viene
chiamato principio di località spaziale, ovvero quando io vado a referenziare un item
probabilmente referenzierò gli item che stanno là intorno.
C'è un altro aspetto di questo principio di località che, piuttosto che guardare alla località spaziale,
guarda alla località temporale, ovvero se io vada referenziare un item (istruzione) in questo tempo, è
probabile che nel prossimo futuro la referenzierò di nuovo (si pensi ai loop).
Questa considerazione che tipo di idea potrebbe fare venire al progettista per risolvere questo
problema del gap di prestazioni tra processore e memoria?
9

Se io vado ad interporre una memoria statica, quindi una piccola memoria, tra processore e RAM
dinamica, e in questa piccola memoria di volta in volta ci metto, sfruttando il principio di località, la
parte di codice che viene referenziata, essendo veloce diminuisco in termini di velocità il gap tra
processore e memoria. Quest’idea è furba soltanto se capita poco spesso che il processore andando
in questa piccola memoria (memoria cache) non trova quello che cerca. Per verificare se questa cosa
succede poco spesso oppure no si fanno delle misure su dei programmi di uso molto frequente. Ci
sono delle misure su programmi molto utilizzati e si va scoprire che l’80%-90% dei riferimenti
generati dal processore durante l'esecuzione di un programma cadono all'interno del 10%-20%
dell'intero codice. Se questo è vero quel 20% di codice lo piglio e lo metto nella memoria statica.
Da un punto di vista architetturale il nostro sistema si organizza nel seguente modo:
abbiamo il processore all'interno del quale c'è un certo insieme di registri (che si può vedere come
una piccola memoria incorporata all'interno del processore), poi quando il processore ma all'esterno
per leggere dalla memoria qualcosa, incontra come prima cosa la memoria cache, che sta prima
della main memory, e naturalmente dopo c’è la memoria di massa. Vista in questi termini è come se
avessimo creato una gerarchia di memoria. Più alto è il livello, più questo è prossimo al processore
più veloce è, e più costoso è.
Esempio
Cache cinque volte più veloce della main memory, e il 90% del tempo di CPU è speso in una
frazione di codice che può interamente essere posto in cache.
Lo Speedup che posso ottenere è:
Questo significa che il sistema complessivamente sarà più veloce di 3,6 volte, cioè delle 360%.
(secondo me del 260%)
La formula che sintetizza il principio di Amdahl e che fa riferimento allo Speedupenhanced e alla
FractionEnhanced ci serve a valutare il rapporto tra il vecchio ExTime e il nuovo ExTime. Laddove
questi ExTime io potessi valutarli attraverso altre grandezze che magari in alcuni casi sono più
facilmente misurabili è ovvio che ricorro ad un altro modo per valutarli.
Cycles per Instruction
A noi interessa vedere qual è il CPU time, cioè il tempo speso dalla CPU per eseguire un
programma. Naturalmente in questo CPU time non è presente la parte eventualmente legata
all’input/output.
Il CPU time lo possiamo esprimere attraverso il seguente prodotto:
10

Il tempo del processore durante il suo lavoro viene scandito da un clock con un periodo pari a Tck.
Se io voglio misurare quanto tempo ho speso per eseguire un programma, ovviamente se conosco
quant'è il periodo di clock, misuro quanti cicli di clock dall'inizio alla fine del programma sono
trascorsi.
CK cycles for a program a sua volta si può esprimere come Ic × CPI, dove Ic sta per Instruction
Count, e CPI è il clock per instruction.
Supponiamo di potere sapere quante istruzioni sono state eseguite, Ic, e conosco il numero di cicli di
clock eseguiti per ogni istruzione, allora il numero di cicli di clock richiesti per un’istruzione
moltiplicati per il numero di istruzioni mi dà il numero totale di cicli di clock del programma, che
moltiplicato per il tempo di clock mi dà il CPUtime:
Il CPI in realtà non è altro che un valore medio, ed è ottenuto come:
Qua si parla di CPI medio. In realtà molto spesso io posso calcolare il CPI attraverso una media
pesata che fa riferimento a categorie diverse di istruzioni: quando viene eseguito un programma ci
saranno istruzioni che implicano l’esecuzione di operazioni logico-aritmetiche (ALU), poi ci
saranno istruzioni di Branch (salto condizionato), poi ci saranno istruzioni di scambio di
informazioni tra la memoria e il processore (Load/Store), ecc…; ammettendo che ogni categoria sia
omogenea dal punto di vista del numero di cicli di clock richiesta per essere eseguita posso
calcolare il CPI attraverso una media pesata:
dove n rappresenta il numero di categorie distinte di istruzioni, ed Fi è la frequenza con cui la
categoria i-esima è presente all’interno del running; la frequenza non è altro che il numero di volte
in cui quella categoria di istruzioni è stata eseguita rispetto al numero di istruzioni totali eseguite:
Ovviamente il CPUtime in questo caso è pari a:
Il problema è stimare Fi, cioè durante un runnig quante volte è stata eseguita una determinata classe
di istruzioni; questo si chiama instruction mix.
È da notare che il CPIi dovrebbe essere misurato e non dedotto da quello che normalmente viene
chiamato CPU technical reference manual, perché questo assume che tutto vada alla velocità del
processore e non considera che alcuni cicli di clock possono essere spesi per degli accessi in
memoria che è più lenta.
Se è vero che il CPUtime è una misura delle prestazioni del nostro sistema ed è esprimibile dal
prodotto di Ic, CPI e Tck, noi possiamo pensare che se vogliamo apportare un miglioramento,
diminuire l’Ic del 30% è la stessa cosa, in termini di guadagno di performance, di fare più veloce il
clock del 30% oppure ridurre del 30% il CPI medio. Allora si potrebbe pensare di investire sulla
cosa che viene più facile migliorare. C’è un problema: questi tre fattori non sono tra di loro
indipendenti, ma cercare di migliorare uno dei tre porta al peggioramento di qualcuno degli altri due
o di entrambi. Quindi come sempre succede nella pratica bisogna trovare un compromesso tra
esigenze molto spesso tra di loro in conflitto.
11

Di seguito mostriamo una tabella che fa vedere da cosa dipendono l’Ic, il CPI e il Clock Rate:
L’Ic dipende dal compilatore perché ogni compilatore lo stesso programma lo può tradurre in
diversi modi; dipende dall’Instruction Set perché per esempio un’istruzione di Branch in alcuni
processori è un’unica istruzione, e ci sono processori in cui il loro set di istruzioni non prevede di
fare sia la verifica della condizione che il salto in un’unica istruzione, ma sono splittate su due
istruzioni diverse.
Il CPI indirettamente dipende dal compilatore perché a seconda di come compilo, e quindi dalla
sequenza di istruzioni che produco, questo può portare a richiedere più cicli di clock per eseguire
un’istruzione; dipende dall’Instruction Set perché se nel mio set di istruzioni includo un’istruzione
che fa un insieme di operazioni è ovvio che ha bisogno di più cicli di clock per essere eseguita;
dipende dall’Organizzazione che è l’organizzazione architetturale che io scelgo per implementare
tutte le attività che deve eseguire il processore.
Il Clock Rate dipende dall’Organizzazione perché più semplice è l’hardware più veloce si può
rendere; ed è ovvio che la Tecnologia incide sulla frequenza di clock.
Si vede che il miglioramento della tecnologia porta solo benefici.
Come si vede se io penso di abbassare il CPI agendo sull’organizzazione bisogna capire cosa
succede al clock rate; per esempio se io trovo una soluzione che mi porta le istruzioni dell’ALU da
1.5 cicli di clock ad 1 ciclo di clock, e però per implementare questa soluzione scopro che
l’hardware si è complicato e quindi la frequenza di clock con cui opero devo abbassarla,
automaticamente ho migliorato il CPI ed ho peggiorato il Clock Rate.
12

30/04/2004
Esempio
Facciamo riferimento ad una macchina base A in cui all’interno dell’instruction set tutte le volte che
dobbiamo implementare un if, cioè un salto condizionato, in realtà per come è fatto l’instruction set
questo richiede l’esecuzione di due istruzioni: COMPARE + BRANCH.
Immaginando di avere un programma che giri su questa macchina, attraverso delle misure sono
state dedotte le seguenti frequenze di esecuzione delle varie classi di istruzioni:
alla fine otteniamo un CPI
medio di 1,2. Significa che
per eseguire quel
programma mediamente
spendiamo 1,2 cicli di
clock per ogni istruzione.
A questo punto un progettista pensa di apportare una modifica: proviamo a modificare l’instruction
set di questo processore in modo tale che l’istruzione COMPARE venga incorporata all’interno
dell’istruzione di BRANCH, cioè in poche parole la fase di valutazione della condizione appartiene
all’istruzione di BRANCH. Per fare questo però l’organizzazione interna del processore,
l’organizzazione hardware, è tale che la frequenza di clock operativa deve modificarsi; in
particolare a seguito di questa modifica bisogna allungare, rispetto alla versione base, il periodo di
clock di 1,25, cioè del 25%. La domanda è: conviene questa modifica?
Supponendo di ignorare il problema legato al costo, cioè quanto costa fare questa modifica, ma ci
concentriamo soltanto sulla performance, noi dobbiamo andare a vedere se il tempo speso per
eseguire lo stesso programma sulla macchina A o sulla macchina B (quella modificata) varia, e
come varia.
Cercando di ricavarsi di nuovo quel tipo di tabella, però per la nuova macchina, adesso dobbiamo
vedere qual è la nuova frequenza di BRANCH, e la frequenza delle rimanenti istruzioni:
Sappiamo che il CPUtime della macchina base è: CPUtimeA = IcA × 1,2 × TckA.
Noi sappiamo che sulla macchina B l’IcB varia rispetto a quello della macchina A perché in
quest’ultima c’erano due istruzioni per ogni BRANCH; questo significa che adesso il numero di
istruzioni si contrae del 20%: IcB = IcA – 20%IcA = 0,8IcA.
La frequenza di BRANCH è data dal numero di occorrenze del BRANCH rispetto all’IcB
complessivo:
Così la tabella che si ottiene è:
quindi il nuovo CPI medio è 1,25.
13

A questo punto il CPUtimeB è:
CPUtimeB = IcB × CPIB × 1,25 × TckA = 0,8IcA × 1,25 × 1,25TckA = 1,25 × IcA × TckA.
Questo significa che il programma viene eseguito più velocemente nella macchina A.
Quando si parla di misure delle performance c'è un indice, che è stato utilizzato moltissimo un po'
di anni fa, tuttora viene ancora utilizzato, ma è caduto in disuso, che è il cosiddetto MIPS: milioni di
istruzioni per secondo. MIPS = instruction count / Time × 10 6 = Clock Rate / CPI × 10 6 .
Se io confronto due CPU è una ha un numero di MIPS maggiore dell'altra allora la prima è più
veloce della seconda. Questa cosa non è detto che sia una cosa vera: è facilmente dimostrabile che
una CPU con un numero di MIPS può portare ad un CPUtime maggiore piuttosto che minore. Se
due CPU hanno un set diverso di istruzioni, lo stesso programma compilato su una macchina
potrebbe presentare un MIPS, quando viene eseguito, maggiore perché per esempio sono istruzioni
semplici quindi maggiori come numero di istruzioni piuttosto che in un'altra macchina dove ci sono
istruzioni più complesse.
I MFLOP/s sono milioni di floating point operation per second.
MFLOP/s = FP Operation / Time × 10 6 . Anche in questo caso vale lo stesso ragionamento fatto
prima.
Esempio
Supponiamo di avere una macchia base di cui sono state ottenute, a fronte dell'esecuzione di un
programma, le seguenti statistiche:
Questa macchina base che tipo di set di istruzioni ha?
Ha un set di istruzioni che si chiamano register/register, oppure si può dire che è una macchina di
tipo Load/Store. Una macchina di tipo Load/Store è una macchina in cui qualsiasi operazione che
coinvolge l'unità logica-aritmetica (ALU) può essere eseguita soltanto se gli operandi stanno
entrambi all'interno del processore, cioè sono nei registri del processore. Questo significa che, per
esempio, quando scriviamo un programma in C e c’è la somma fra due variabili, queste variabili se
quando è stato compilato il programma stanno in memoria, prima di potere eseguire la somma
bisogna prevedere che il valore di queste variabili venga caricato con un’operazione di load
all’interno di registri del processore, e successivamente può essere eseguita la somma; il risultato
della somma presuppone che poi ci sia un’operazione di store, cioè venga scritto in memoria.
Questa è un’architettura load/store. In un’architettura di questo tipo non è possibile eseguire, per
esempio, la somma tra un operando che sta all’interno di un registro del processore e un operando
che sta all’interno della memoria.
Adesso rispetto ad una macchina di tipo load/store supponiamo di voler modificare l’architettura di
questa macchina modificando l’instruction set e aggiungendo una nuova classe di istruzioni di tipo
register/memory ovvero che mi consentono di fare operazioni ALU anche con operandi che stanno
uno in un registro e uno in memoria. Questo tipo di istruzioni richiedono due cicli di clock, a
differenza di una qualunque istruzione ALU che invece richiedeva un ciclo di clock.
14

Il problema è: a fronte dello stesso programma, compilato sulle due macchine, cosa ci guadagno
modificando il set di istruzioni introducendo questo tipo di istruzione? In particolare la domanda è:
quale frazione di load nella macchina base deve essere eliminata perché questa modifica incominci
a dare un guadagno?
Questo significa che, se adesso ho istruzioni di tipo register/memory, tutta una parte di operazioni
che facevo nella macchina base, operazioni che coinvolgevano l’ALU, che richiedevano delle load
verranno eliminate nella nuova macchina perché non è necessario fare delle load esplicite.
In pratica probabilmente riduco l’Ic, e riducendo l’Ic, siccome CPUtime = Ic × CPI × Tck, se non
peggiorano le altre due componenti può darsi che avrò un CPUtime più basso, quindi che la nuova
macchina con questo nuovo set di istruzioni sia più performante della vecchia macchina.
È ovvio che in qualche modo la performance di una macchina dipenderà da quante load
scompaiono; allora in questo caso il nostro obiettivo è valutare qual è la percentuale di load che
deve essere eliminata perché questo tipo di instruction set architecture possa incominciare a fornire
un guadagno rispetto alla macchina base. I dati relativi alla macchina base sono riportati sopra.
Se io metto anche l’istruzione RegMem e chiamiamo X il numero di istruzioni RegMem eseguite
abbiamo che X è il numero di load che si riducono rispetto alla macchina originaria, ma queste
istruzioni di tipo RegMem le utilizzo per fare operazioni di tipo ALU, quindi anche le istruzioni
ALU si riducono di X:
facendo questa
modifica purtroppo
il branch avrà
2 bisogno di tre cicli
di clock.
Calcolando il nuovo CPI otterrei 1.7-X; in realtà X è la frazione di istruzioni espressa però rispetto
al vecchio instruction count. Noi vogliamo calcolare il CPI della nuova macchina, quindi questo
CPI deve essere normalizzato rispetto al nuovo instruction count, ovvero il vecchio instruction
count moltiplicato per 1-X, questo perché ognuna delle nuove frequenze è divisa per 1-X:
F’ALU=N’ALU/I’C=(NALU–NRegMem )/IC(1–X)=NALU/IC(1–X)–NRegMem/IC(1–X)=FALU/(1–X)–X/(1–X).
Vado a trovare il valore di X per cui i due CPUtime sono uguali:
⇒ 1.00 × 1.5 = (1 – X) × (1.7 – X)/(1 – X) (ClockOld = ClockNew)
⇒ 1.5 =1.7 – X ⇒ X = 0.2
X deve essere almeno uguale a 0.2, cioè tutte le load che erano presenti dovrebbero essere
eliminate, affinché la modifica non produca una perdita di performance.
Noi abbiamo considerato il CPUtime immaginando che tutto vada alla velocità della CPU, e quindi
che la CPU non debba aspettare memoria, ecc.
In realtà le cose non stanno così: quando la CPU accede in memoria normalmente deve aspettare.
Abbiamo visto che per mitigare questo problema è stata inventata la memoria cache. Allora tutte le
volte che andando in memoria la CPU trova quello che sta cercando nella cache di fatto non deve
aspettare (immaginando che la cache vada alla stessa velocità del processore); naturalmente questo
non può succedere sempre perché la cache è piccola e quindi difficilmente riuscirà a contenere tutto
quello che serve; questo significa che delle volte ci sarà un miss (mancato successo); in tal caso si
/
15

deve aspettare che il dato che non sta in cache debba essere reperito nel livello di memoria
successivo, main memory, spostato nella cache e quindi il processore può leggere quel dato se si
trattava di un’operazione di lettura. Questo significa che il CPUtime, se lo devo calcolare
correttamente quando c’è una gerarchia di memoria, lo devo esprimere nel seguente modo:
Quindi il tempo di CPU per eseguire un determinato programma sarà pari al numero di cicli della
CPU se tutto andasse bene dilatato di un numero di cicli di stallo, nel senso che il processore deve
bloccare la propria attività aspettando che qualcosa arrivi dalla memoria. Questo come si vede fa sì
che il numero di cicli di clock totale per eseguire quel programma in presenza di una memoria reale
aumenti rispetto al numero di cicli di clock strettamente richiesti dal processore.
Proviamo a esprimere il MemoryStallCycles in qualche modo: questi cicli di clock di stallo si
verificano tutte le volte che andando in memoria si verifica un miss. Se moltiplico il numero di miss
per il miss penalty, ovvero per la penalità che pago per spostare il dato dalla main memory alla
cache espresso in numero di cicli di clock, ottengo il numero totale di cicli di clock di stallo. Se io
voglio mettere in evidenza l’instruction count, il numero di miss non è altro che una frazione di Ic,
ovvero il numero di miss per instruction. Posso definire una nuova grandezza: il cosiddetto miss
rate. Il miss rate non è altro che la frazione di miss che sperimento rispetto al numero totale di
accessi in memoria: se vado 100 volte in memoria (cache) e 15 volte su queste 100 volte c’è un
miss allora il miss rate è il 15%. Allora possiamo scrivere:
dove mem.ref.per.instr. è il numero di riferimenti medio per istruzione, cioè per ogni istruzione
quanti riferimenti in memoria si fanno.
Esempio
Supponiamo di avere una macchina A e supponiamo di avere un programma in cui ci sono il 40% di
istruzioni load/store, un CPI medio pari a 2, in cui però ci siano tutti cache hits (tutti gli accessi in
memoria hanno successo). Questa macchina la voglio confrontare con una macchina B che ha il 2%
di miss rate, cioè il 2% delle volte che vado in cache non trovo quello che voglio; tutte le volte che
succede questo il miss penalty è di 25 cicli di clock.
Nel caso della macchina A abbiamo:
Per quanto riguarda la macchina B abbiamo:
Il mem.ref.per.instr. sarà 1 perché tutte le istruzioni eseguite richiedono un accesso in memoria, e
poi ci sono il 40% delle istruzioni che sono di tipo load/store che richiedono due accessi: uno per
leggere l’istruzione e un altro per eseguire o la load o la store, quindi il numero di riferimenti medi è
1+0,4.
Così il CPUtime è:
Se facciamo il rapporto otteniamo:
Così abbiamo un degrado di performance del 35%.
,
16

Abbiamo parlato di approcci quantitativi alla progettazione basati su misure per vedere quanto una
certa alternativa piuttosto che un’altra è utilizzata, e abbiamo visto come valutare.
Siccome parliamo di computer, cos’è che ci consente di valutare le prestazioni?
Fare girare dei programmi e vedere quanto tempo impiega il computer per eseguirlo.
Se ci mettiamo nella prospettiva in cui normalmente si mettono i produttori di computer si capisce
che è auspicabile che il proprio prodotto è migliore di quello che produce qualcun altro. Solo che
dire “migliore” non è facile.
Incominciamo da un punto di vista logico a definire cosa ci consentirebbe di dire se un computer è
migliore oppure no. Il produttore per dire che un computer è meglio di un altro dovrebbe dimostrare
che per eseguire certi programmi il suo computer impiega meno tempo di un altro; però non si sa a
quali programmi fare riferimento, perché non si sa ogni utente quali programmi usa.
Il primo problema quindi è: quali programmi usare per valutare le prestazioni? E per quali tipologie
di utenti?
Qual è la condizione ideale impossibile da realizzare?
La condizione è quella di utilizzare un workload reale, quindi fatto da programmi reali, che non è
altro che l’insieme di applicazioni e di comandi di sistema operativo che vengono dati durante
l’utilizzo normale da parte di quell’utente. Questo perché gli utenti sono tanti e ognuno ha esigenze
abbastanza diverse.
La soluzione che è stata individuata già da un po’ di anni è quella di utilizzare le cosiddette
benchmark suites, cioè delle collezioni di programmi che in qualche modo siano rappresentativi
dei diversi scenari di utilizzo dei computer.
Che tipo di programmi costituiscono una benchmark suite? Ci sono varie tipologie di programmi.
• Toy benchmarks, sono dei software semplicissimi, 10-100 linee di programma, fatti per
stimolare certi parti del sistema: sieve, puzzle, quicksort.
• Synthetic benchmark, che non sono dei programmi reali, cioè che non risolvono nessun
problema reale: whetstone, dhrystone.
• Kernels, che sono dei pezzi di programmi reali, tipicamente per esempio pezzi di programmi di
un sistema operativo o kernel di qualche applicazione particolare: livermore loops.
• Programmi reali: gcc, spice, ecc.
Dopo aver litigato per tanti anni alla fine i costruttori sempre cercano di trovare un accordo, e in
genere lo scenario in cui si cerca di sintetizzare queste liti e questo accordo è quello degli organismi
di standardizzazione internazionali. A livello di standardizzazione è stato proposto il cosiddetto
SPEC (Standard Performance Evaluation Corporation), che è riconosciuto da tutti i costruttori e che
specifica quali sono i programmi che bisogna utilizzare per valutare le prestazioni di una macchina.
Considerando il tipo di differenziazione del mercato nel settore dei computer (desktop, server ed
embedded) SPEC ha cercato di differenziare le suites per valutare le prestazioni dei vari settori:
CPU intensive significa che stimolano prevalentemente la CPU, quindi valutano le prestazioni
prevalentemente del processore. I Graphic intensive che cercano di valutare le prestazioni dal punto
di vista della grafica. Gli SPEC FS (spec filesystem) sono basati sulla valutazione del numero di
transazioni per secondo che è in grado di eseguire un server.
17

Tipicamente un benchmark esce ogni 3 anni.
SPEC CPU2000
Naturalmente c’è un ampio settore di mercato, che è il settore di mercato più promettente, che è
quello dei PC, per cui sono nati anche i benchmark per PC:
• Business Winstone: è uno script che lancia Netscape e diversi prodotti di Office per cercare di
simulare un workload reale di un tipico pc user;
• CC Winstone: simula un ambiente di applicazioni per la creazione di contenuti multimediali
(Photoshop, Premiere, Navigator, ecc.);
• Winbench: insieme di kernel per il test di CPU, sistema video, dischi.
Per quanto riguarda i sistemi embedded è nato il consorzio EEMBC che ha creato la suite chiamata
EDN che include: automotive industrial, consumer, networking, office automation,
elecommunication.
Si fanno molti giochi con i benchmark:
• ottenere dei risultati migliori su una macchina rispetto ad un’altra facendo girare lo stesso
benchmark suite sui due sistemi senza dire come sono equipaggiati;
• ottenere performance migliori ottimizzando dei compilatori per determinati programmi;
18

• workload utilizzati in modo arbitrario: quando per esempio ho una suite di benchmark con i
programmi A, B, C, D, e il programma A è quello più veloce allora quando faccio girare questa
suite di benchmark, se non ho delle costrizioni particolari, potrei fare girare molte volte il
programma A e poche volte gli altri programmi; quindi prevale la performance del programma
A.
19

01/04/2004
Abbiamo detto che proprio perché è abbastanza complicato individuare un workload che sia
rappresentativo per ogni utente sono nati dei benchmark suites. Un benchmark suite abbiamo detto
che è costituito da un insieme di programmi molto diversi tra di loro, quindi si capisce che non è
facile stabilire qual è il giusto mixing di questi programmi per valutare le prestazioni.
Allora c’è il problema di cercare di stabilire quando si fa girare un benchmark che tipo di rapporto
di prestazioni devo andare ad ottenere.
Una delle cose che molto raramente avviene nel campo dei computer è quello di rispettare il
cosiddetto principio di riproducibilità: includere tutto ciò che consente ad altri di replicare gli
esperimenti fatti.
Nel caso degli SPEC benchmark un report richiede:
- una descrizione quasi completa della macchina (configurazione hardware e software);
- flag di compilazione: quando si usa un programma come gcc per compilare, per esempio, è
necessario settare dei flag in modo tale che tutti devono utilizzare quei flag per compilare;
- pubblicazione dei risultati sia delle performance di base (baseline) sia quelle ottimizzate.
Nella performance baseline viene imposto di utilizzare un particolare tipo di compilatore e un set
di flag da utilizzare nella compilazione per tutti i programmi nello stesso linguaggio.
Per quanto riguarda la performance di picco (peak performance) c’è una maggiore libertà in modo
da potere fare un tuning delle prestazioni attraverso, per esempio, compilatori proprietari o flag
specifici, cioè che non sono imposti.
Esempio di baseline performance
Per quanto riguarda l’affidabilità dei benchmark come predittori della performance reale riportiamo
un esempio:
c’è un programma che si chiama matrix300 (SPEC 89), un software che fa il prodotto tra matrici,
che spende il 99% del tempo di esecuzione su una linea di codice. ottimizzando il loop più interno
attraverso un compilatore per una IBM PowerStation 550 si ottiene un miglioramento di un fattore 9
20

nella performance. In questo modo però non sto testando la macchina ma sto semplicemente
testando la performance del compilatore.
Andiamo ora a capire come si possono misurare le prestazioni a fronte dell’esecuzione di alcuni
programmi.
Quando faccio girare un programma posso dire che la performance è il tempo di esecuzione del
programma; quando mi pongo il problema di trovare un indice globale di prestazione per la mia
macchina è ovvio che non mi conviene dire che la mia macchina per fare girare, per esempio, il gcc
piuttosto che un’altra applicazione impiega tot tempo; poi se quella applicazione non è
rappresentativa per l’utente questo di per sé non è un’informazione che è appetibile per il mercato.
Quindi bisognerebbe tirare fuori un indice di performance globale ricavato dal running di una suite
di benchmark, cioè di programmi abbastanza rappresentativi. Ma qual è quest’indice globale?
Vediamo quali si potrebbero utilizzare, e sulla base di questi eventuali indici globali cercare di
capire se è possibile rispondere ad una domanda: quest’indice globale di performance mi consente
di dire che una macchina è più veloce di un’altra?
Esempio
Abbiamo tre computer e supponiamo di avere una suite di benchmark fatta da due programmi: P1 e
P2. Facendo girare questi due programmi sui tre computer impiego i secondi indicati nella seguente
tabella:
A questo punto bisognerebbe cercare di capire qual è l’indice globale di performance utile ai fini di
dire quale delle tre macchine è più veloce.
Ovviamente per il programma P1 la macchina più veloce è A, e a sua volta B è più veloce di C; per
il programma P2 la macchina più veloce è C, e B è più veloce di A. Quindi non c’è una tendenza
che mi porta a dire che una macchina è più veloce delle altre.
Una misura più consistente è quella, per esempio, di considerare il total execution time. Se io vado a
considerare questo indice trovo i tempi indicati nella tabella sopra. Questo mi porterebbe a dire che
il computer C è 2,75 volte più veloce del computer B e 25 volte del computer A; e il computer B è
9,1 volte più veloce del computer A.
Quindi in questo caso il tempo di esecuzione totale è una misura consistente e ci consente di
affermare quello detto sopra; però questa cosa è vera solo se io faccio girare su queste tre macchine
i programmi P1 e P2 lo stesso numero di volte.
Il problema è che non è detto che io faccia girare lo stesso numero di volte P1 e P2.
Se il numero di running di ogni singolo programma costituente la benchmark allora il total
execution time oppure la media dei tempi di esecuzione sono abbastanza rappresentativi delle
performance.
Nel caso in cui il numero di running di P1 è diverso dal numero di running di P2 si può ricorrere a
due soluzioni:
1) media aritmetica pesata
2) media geometrica.
La media aritmetica pesata è uguale a: , dove Ti è il tempo di esecuzione del programma
i-esimo all’interno del benchmark.
21

Se io ho ni che è il numero di running di Pi nel workload e ∑i ni = n, il peso o la frequenza relativa
del programma i-esimo non è altro che wi = ni / n.
Vediamo alcuni esempi relativamente alle macchine A, B e C:
La pesatura w(1) fa si che pesa nello stesso modo i due programmi: così otteniamo quello che
avevamo ottenuto prima, cioè che il computer C è più veloce di B, e B è più veloce di A, e se si
fanno i rapporti si ottengono gli stessi valori di prima.
Nella pesatura w(2) fisso i pesi in modo tale che siano inversamente proporzionali ai tempi di
esecuzione dei programmi P1 e P2 sul computer B, cioè faccio girare più volte il programma che
richiede meno tempo. In questo modo ottengo che il computer B è più veloce di A e di C, e C è più
veloce di A.
Con la pesatura w(3) fisso i pesi in modo inversamente proporzionale al tempo di esecuzione di P1
e P2 sulla macchina A. In questo modo ottengo che il computer A è più veloce di B e C, e B è più
veloce di C.
Sempre parlando di indici di prestazione globale quando il numero di running dei vari programmi è
diverso piuttosto che la media aritmetica pesata un altro tipo di media che si potrebbe utilizzare è
quella geometrica. In particolare si considera normalmente la media geometrica dei tempi di
esecuzione normalizzati: ho una suite di benchmark e voglio misurare le prestazioni sulla macchina
A, allora devo fare girare il programma sulla macchina A e ottengo un tempo di esecuzione che
devo normalizzare rispetto al tempo di esecuzione dello stesso programma su una macchina
campione (per esempio come macchina campione viene utilizzata per la SPEC una SPARCstation).
In questo caso la media geometrica dei tempi normalizzati è:
Si potrebbe erroneamente pensare che si possa predire la performance di un programma sulla mia
macchina moltiplicando π per la performance del programma sulla macchina campione, essendo
noti sia il primo che la seconda.
Un’altra cosa da notare è che quando si utilizzano i tempi di esecuzione normalizzati e si utilizza la
media aritmetica di questi ultimi si può arrivare a dei paradossi. Per esempio: supponiamo di avere
al solito i computer A, B e C, e i due programmi P1 e P2; normalizzando i tempi di esecuzione
22

considerando le varie macchine come macchina campione si ottengono i valori riportati in tabella.
Se io considero la media aritmetica dei tempi normalizzati o rispetto ad A, B o C, questa fornisce
delle misure assolutamente inconsistenti, nel senso che nel primo caso viene fuori che A è il
computer più veloce, nel secondo caso è B il più veloce, è nel terzo caso e C il più veloce; quindi il
computer più veloce è quello rispetto a cui normalizzo. Quindi non bisogna mai considerare la
media aritmetica dei tempi di esecuzione normalizzati, ma considerare la media geometrica. Infatti
la media geometrica è consistente: indipendentemente dalla macchina campione otteniamo sempre
misure consistenti, in questo caso C è sempre il computer più veloce, e anche i rapporti sono sempre
uguali.
Quindi la media geometrica dei tempi di esecuzione normalizzati è consistente indipendentemente
dalla macchina di riferimento, e non dipende dal numero di running dei programmi individuali.
Uno dei problemi con la media geometrica è che non consente di predire il tempo di esecuzione. Un
altro problema è che quando si considerano tre o più macchine non esiste nessun workload che sia
compatibile con la performance predetta dalla media geometrica. Questo significa che in qualche
modo si vanifica la ragione per cui questa media è stata introdotta.
Un altro problema con la media geometrica è: se per esempio io voglio fare un’ottimizzazione,
ovvero voglio migliorare sulla mia macchina le prestazioni e ho due possibilità, per esempio passare
da 2s a 1s per un programma piuttosto che da 1000s a 500s per un altro programma, se io considero
la media geometrica il miglioramento che io vado a valutare è identico, cioè dire dato lo stesso peso
ai due abbattimenti dei tempi di esecuzione. Quindi se io mi metto nei panni di quello che vuole
truccare le carte e volessi ottenere quello stesso miglioramento di performance globale valutato
attraverso la media geometrica, supponendo che voglio dimezzare il tempo di esecuzione, fra tutti i
programmi vado a scegliere quello su cui è più facile farlo.
Cosa bisogna fare per cercare di dare delle informazioni consistenti e corrette? Bisogna misurare un
workload reale e pesare i programmi con nelle loro frequenze di esecuzione reali.
Quando si dà come misura delle prestazioni un indice globale, questo tende a nascondere delle
informazioni importanti, e in alcuni casi potrebbe non essere il migliore indicatore della
performance per un'applicazione d'utente. Per cui assieme all'indice globale sarebbe bene fornire
anche i risultati (tempo di esecuzione, frequenza con cui è stato fatto girare un programma del
benchmark, ecc…) dei singoli benchmark costituenti il workload.
Sistema di elaborazione
Un sistema di elaborazione per noi non è altro che costituito da tre entità:
statica
In particolare un sistema di elaborazione lo possiamo definire come una macchina in grado di
eseguire programmi espressi in un determinato linguaggio di programmazione.
23

La macchina è un'entità attiva, dinamica (che evolve nel tempo), mentre il programma è una entità
statica. Durante l'esecuzione di un programma questo rimane quello che è, mentre la macchina,
rappresentata da tastiera, monitor e dall'insieme di variabili (che dobbiamo considerare appartenenti
alla macchina) viene modificata (ad esempio il valore delle variabili viene modificato).
Nel nostro modello noi assumiamo normalmente che un'istruzione costituisce una azione atomica
per il nostro sistema, cioè significa che se noi facciamo riferimento allo stato della nostra macchina
(insieme di variabili, e in generale tutto ciò che ha all'interno della macchina memorizza
informazioni) l’istruzione ci fa passare da uno stato all'altro; quindi significa che eseguire un
programma equivale a fare compiere alla nostra macchina una traiettoria di stati all'interno dello
spazio dei possibili stati che la macchina può assumere.
Quello a cui siamo stati abituati a vedere come modello di un sistema di elaborazione è quello che
viene chiamato modello funzionale: il modello che descrive la macchina come un puro esecutore
del proprio linguaggio. Da questo punto di vista tutte le macchine Pascal, oppure C, ecc…, sono
funzionalmente identiche.
Il modello realizzativo di un sistema di elaborazione fa riferimento a come quest’ultimo è fatto,
cioè che tipo di componenti fisici ci sono, come sono collegati tra di loro, ecc.
Questo significa che due macchine che hanno lo stesso modello funzionale non è affatto detto che
abbiano lo stesso modello realizzativo:
Parlando del modello funzionale possiamo dire che la traiettoria di stato che viene percorsa dalla
nostra macchina è di tipo deterministica, cioè è predicibile sapere quali sono tutti gli stati che
attraverserà la nostra macchina se noi conosciamo tre elementi: programma in esecuzione, i dati che
forniamo al nostro programma e lo stato iniziale. Questa affermazione assume un’importanza
notevole perché non è detto che sia così.
Da un punto di vista schematico quello che abbiamo detto sul modello funzionale è rappresentabile
nel seguente modo:
Esempio
dove M = macchina, L = linguaggio, P = programma.
In generale in realtà un sistema di elaborazione è costituito da una gerarchia di macchine, non da
una singola macchina. Questa gerarchia di macchine è organizzata attraverso il seguente principio:
se io mi metto ad un certo livello di questa gerarchia di macchine posso salire di livello, e realizzo
una macchina che sta ad un livello superiore a partire dalla macchina del livello immediatamente
inferiore. Questa affermazione che sembra banale è quella che è stata uno dei motivi della
rivoluzione nel campo dell’informatica, o quantomeno che ha consentito di estendere l’uso dei
calcolatori ad una quantità di utenti maggiore.
24

Realizzo una macchina sopra un’altra macchina a partire o da un compilatore (traduttore) o da un
interprete. (Il compilatore traduce il nostro codice in un altro linguaggio, l’interprete legge il codice
lo interpreta e lo esegue). Il compilatore è più efficiente perché questo traduce il codice una sola
volta, mentre l’interprete ogni volta che si deve far girare il programma interpreta il codice.
In che senso realizzo una macchina sopra un’altra macchina?
Supponiamo di avere una macchina M1 caratterizzata da un proprio
linguaggio L1; su questa macchina posso realizzare una macchina M2,
che gerarchicamente è superiore ad essa, con un linguaggio L2
semplicemente costruendo un programma P12(L1) espresso nel
linguaggio L1, e questo programma non è altro che o un compilatore o
un interprete. Ovviamente il programma che può girare sulla macchina
M2 sarà scritto nel linguaggio L2: P(L2).
Il senso di realizzare una gerarchia di macchine è quello di fare sì che
la macchina sia più facilmente utilizzabile.
Naturalmente se salire di livello significa rendere più facile l’utilizzo
all’uomo, questo allo stesso tempo può penalizzare le prestazioni.
Adesso scendiamo di livello e arriviamo nell’ambito della gerarchia di macchine a quella che viene
chiamata macchina processo. La macchina processo è quella macchina che esegue i programmi
che tipicamente producono i compilatori. Il linguaggio della macchina processo è un linguaggio di
tipo binario. Una caratteristica della macchina processo è che si incomincia a perdere quella che
viene chiamata identità funzionale tra le varie macchine: noi abbiamo detto che tutte le macchine C,
per esempio, sono funzionalmente identiche, mentre la stessa cosa non vale più per le macchine
processo, cioè un programma espresso nel linguaggio di una macchina processo non può girare su
un’altra macchina processo; questo avviene perché la macchina processo è quel livello all’interno
della gerarchia al di sotto del quale non è più possibile nascondere i dettagli realizzativi della
macchina, cioè le differenze reali tra le varie macchine. Questo significa che ogni macchina
processo ha un proprio linguaggio binario, che dipende dal sistema di elaborazione. Sebbene questo
sia vero tutte le macchine processo sono caratterizzate da un insieme di elementi che le rendono
simili. Questi elementi sono:
• sono dotate di una memoria di processo, che sostanzialmente è uguale un po’ per tutte;
• richiedono che il programma, che poi verrà eseguito dalla stessa macchina processo, debba
risiedere nella memoria di processo;
• sono caratterizzate dal fatto che utilizzano per eseguire i programmi un registro che si chiama
Program Counter;
• sono dotate di un meccanismo di esecuzione delle istruzioni del programma che è analogo;
• stato del processo: contenuto di memoria + contenuto dei registri.
La memoria di processo su per giù è la seguente:
25

La memoria non è altro che un sistema che è in grado di memorizzare informazioni espresse in
formato binario. Se il suo scopo è quello di memorizzare informazioni significa che è un sistema
che per essere usato mi deve offrire dei servizi; questi servizi mi devono consentire di memorizzare
informazioni, ma se memorizzo informazioni lo faccio perché poi voglio andare a reperirle. Questo
sistema è organizzato come un insieme di locazioni (ognuna è una riga), e ciascuna locazione (o
cella di memoria, o parola di memoria) è in grado di memorizzare un certo insieme di bit. Una
caratteristica del sistema memoria è che tutte le locazioni di memoria costituenti il sistema hanno la
stessa dimensione in bit, nel nostro caso k bit (k=1, 8 ,16, 32, 64).
Per utilizzare i servizi che vengono offerti dal sistema memoria è necessario specificare alcune
cose. Quando voglio andare a memorizzare un informazione, poiché questo sistema ha N diverse
locazioni, devo specificare al sistema dove voglio che l’informazione venga memorizzata; questo lo
specifico attraverso un indirizzo, utilizzando la porta degli indirizzi che il sistema memoria mette a
disposizione. Inoltre se si vuole depositare una specifica informazione, questa la si dà al sistema
memoria attraverso la porta dei dati.
La capacità di memoria esprime la quantità di informazioni in bit che è memorizzabile in essa
(1Mbyte = 2 20 byte, ovvero 2 20 word di un byte).
Quando avviene la scrittura di una particolare locazione, questa fa sì che il contenuto precedente
scompaia, cioè si altera il contenuto informativo di quella locazione. La lettura, viceversa, mi
consente di accedere ad una locazione ottenere l’informazione che c'è all'interno di quella locazione
mantenendo nella stessa locazione la stessa informazione; quindi significa che la lettura non altera
l’informazione contenuta all'interno di una locazione di memoria.
In scrittura:
• sulla porta degli indirizzi devo fornire l'indirizzo, ovvero la posizione su cui memorizzare la
parola;
• sulla porta dei dati devo fornire l'informazione da scrivere.
A questo punto la memoria prende quello che c'è sulla porta dei dati è lo va a memorizzare
all'interno della locazione selezionata dall'indirizzo presente sulla porta degli indirizzi:
In lettura:
• sulla porta degli indirizzi devo specificare l'indirizzo della locazione da leggere;
• sulla porta dei dati si ottiene la parola memorizzata in quell'indirizzo.
L’indirizzo deve specificare in modo univoco ogni singola locazione di memoria. Ad esempio se
ho una memoria da 1 Kbyte (2 10 byte) occorrono 10 bit (log2 2 10 = 10) per specificare un indirizzo.
26

Come fa il sistema memoria sulla base di quei 10 bit a dire a quale locazione si fa riferimento? Non
fa altro che usare un decodificatore, che è un circuito combinatorio che riceve un ingresso, in questo
caso di 10 bit, e fornisce un’uscita, in questo caso 1024. Facciamo un esempio con un decodificare
binario a 3 bit:
bit più significativo
0
0
1
DEC
bit meno significativo
0
1
2
3
4
5
6
7
Della macchina processo la parte che esegue i programmi è l’unità centrale di processamento
(CPU). Essa non è altro che l’esecutore di cui si serve la macchina processo per eseguire i
programmi che stanno nella memoria di processo; nello svolgere questo ruolo di esecutore coordina
anche tutti i vari blocchi che costituiscono la nostra macchina.
Questa CPU è caratterizzata da un proprio set di istruzioni, ovvero dall’insieme di istruzioni che
essa è in grado di eseguire. Ognuna di queste istruzioni è codificata in binario, e ovviamente questa
codifica binaria deve essere riconoscibile da quella particolare CPU. Questo ci fa capire perché
macchine processo diverse hanno linguaggi binari diversi. Ovviamente un programma può essere
eseguito dalla CPU se è costituito da istruzioni appartenenti al set di istruzioni della CPU, e inoltre
se tutte le istruzioni che costituiscono il programma sono codificate in quel linguaggio binario e
memorizzate sequenzialmente nella memoria centrale. Quindi un programma eseguibile dalla
macchina processo lo possiamo immaginare fatto così:
Il modo stesso di andare a memorizzare il programma in memoria
implicitamente per l’esecutore contiene l’informazione di quale è
l’ordine di esecuzione delle istruzioni.
Formato delle istruzioni
Abbiamo detto che è codificata in binario; questo significa che ogni istruzione del set di istruzioni
di una determinata CPU è costituita da una stringa di 1 e 0 con una certa lunghezza. Tutte le
macchine processo, per quanto ognuna ha un linguaggio binario diverso e tecniche di codifica
diverse, si assomigliano su degli elementi comuni, ovvero tutte utilizzano una tecnica di codifica
che consente di individuare sempre due campi all’interno dell’istruzione codificata: un campo che si
chiama codice operativo e un campo che si chiama operandi
codice operativo operandi
27

La prima parte dell’istruzione (codice operativo) specifica all’esecutore di che tipo di istruzione si
tratta, cioè caratterizza l’istruzione; gli operandi specificano gli oggetti su cui quell’operazione deve
essere eseguita. Gli operandi o rappresentano i dati stessi o rappresentano il modo di riferimento ai
dati su cui fare l’operazione; per esempio se un dato sta in memoria e l’altro sta in un registro il
campo operandi dell’istruzione conterrà l’indirizzo del dato che sta in memoria e l’indirizzo del
registro, ovvero il nome del registro (qualcosa che individui il registro su cui sta il dato su cui fare
l’operazione). Il codice operativo per ogni istruzione dello stesso tipo (per esempio somma) non è
sempre lo stesso perché deve specificare sì il tipo di istruzione, ma specifica anche come
interpretare il campo operandi.
La CPU normalmente è costituita da due componenti: unità di controllo e unità logico-aritmentica
(ALU). L’unità di controllo non fa altro che essere la parte attiva della CPU e a tutti gli effetti è la
parte “intelligente” dell’esecutore: legge l’istruzione, la interpreta, la esegue, decide quale sarà la
prossima istruzione da eseguire, ecc.
L’unità logico-aritmentica è una sorta di “schiavetto” asservito all’unità di controllo, cioè
quest’ultima a fronte dell’istruzione che sta eseguendo decide cosa farle fare.
All’interno di questa CPU ci sono un insieme di registri, che servono per memorizzare le
informazioni; ci sono in particolare due registri che hanno un ruolo particolare: Program Counter e
Instruction Register. Questi registri sono presenti all’interno di qualsiasi CPU per quanto diverse
queste siano. Il PC contiene l’indirizzo della prossima istruzione da eseguire; l’IR è un registro che
viene utilizzato dall’unità di controllo ogni qualvolta quest’ultima si accinge ad eseguire una nuova
istruzione. L’unità di controllo legge l’istruzione dalla memoria e la deposita nell’IR.
L’unità centrale e l’ALU cooperano per eseguire istruzioni; normalmente cooperano e utilizzano la
memoria in un processo che possiamo distinguere in quattro fasi che porta al completamento di un
ciclo macchina. Un ciclo macchina racchiude un insieme di attività che sono caratteristiche durante
il processo di esecuzione dell’istruzione.
Questo ciclo macchina è fatto da quattro fasi:
1) la prima fase è quella in cui l’unità di controllo va a prelevare dalla memoria la prossima
istruzione da eseguire; questa istruzione letta dalla memoria viene all’interno dell’unità di
controllo depositata nel registro IR;
2) poi avviene la decodifica dell’istruzione;
3) la fase 3 è quella dell’esecuzione, dove per esempio se ci sono da fare dei conti vado ad usare la
parte di ALU coinvolta per l’esecuzione di quell’istruzione;
4) la fase 4 è quella di memorizzazione dei risultati, ovviamente laddove ci siano dei risultati da
memorizzare.
28

02/04/2004
Ritorniamo al meccanismo di esecuzione e diamo qualche dettaglio in più: supponiamo che la
seguente sia la nostra memoria di processo e all’interno di questa a partire da questa locazione sia
memorizzato un programma che deve essere
PC
}
} 1a
2 a
}
3 a
eseguito e supponiamo che ogni istruzione
codificata in linguaggio binario di quella
macchina processo in lunghezza coincida
con la dimensione di una locazione di
memoria. Vediamo di capire cosa avviene
durante l’esecuzione. Abbiamo detto che
l’unità di controllo utilizza il PC per
stabilire da quale locazione di memoria
andare a leggere la prossima istruzione.
Questo significa che durante il ciclo
macchina di esecuzione di un istruzione ci
deve essere un’attività specifica che va ad aggiornare il PC. Quando viene fatto questo? Quando c’è
la fase di lettura dell’istruzione e di caricamento all’interno dell’IR la CPU sa che la prossima
istruzione da eseguire starà all’indirizzo successivo perché si assume che la successione in memoria
delle istruzioni coincida con l’ordine di esecuzione del programma stesso; per cui se ho letto
quell’indirizzo la prossima istruzione la andrò a leggere al prossimo indirizzo. Quindi tra la fase di
lettura dell’istruzione e caricamento all’interno dell’IR e la fase di decodifica avviene sempre
l’aggiornamento del PC: incremento di 1 del PC. Questo è vero solo se io vado sempre in sequenza,
però noi sappiamo che non sempre avviene questo all’interno di un programma perché ogni tanto ci
può essere qualche diramazione (branch). Come può funzionare il fatto intanto il PC si incrementa
di 1 e poi magari non devo andare a leggere l’istruzione successiva, ma devo andare a un certo
numero di locazioni dopo? Tutto questo è compatibile perché tutto sommato non conviene fare delle
eccezioni, cioè se io ho già l’hardware implementato che ogni volta che leggo un’istruzione
incrementa il PC non devo preoccuparmi di non farlo quando si verifica che l’istruzione appena
letta per esempio è un branch, perché questo significa fare delle aggiunte che spesso complicano la
parte realizzativa. La CPU continua a comportarsi sempre nello stesso modo, cioè incrementa il PC;
però abbiamo detto che questo avviene tra la fase di lettura e quella di decodifica, poi c’è la fase di
esecuzione dell’istruzione, ma nel caso in cui l’istruzione è un’istruzione di branch la fase di
esecuzione è quella di testare una condizione, e se questa è vera allora devo eseguire il salto, ma
eseguire il salto vuol dire andare a caricare nel PC il valore dell’indirizzo target di salto.
Le cose funzionano così in tutte le macchine processo.
Non necessariamente dobbiamo fare l’assunzione che l’istruzione occupi un’unica locazione di
memoria; ci sono casi, ed è tipico delle architetture CISC, in cui l’istruzione non ha una lunghezza
fissa: ci può essere un’istruzione che per essere codificata richiede 32 bit e un’istruzione che
richiede 64 bit per esempio. Quindi immaginando che ognuna delle locazioni della memoria
disegnata sopra sia di 32 bit, si può avere che la prima istruzione richieda 3 locazioni di memoria
(96 bit), la seconda richieda 2 locazioni e la terza 1 locazione, ecc. In questo caso sembrerebbe che
ci sia una difficoltà aggiuntiva, ovvero il PC non si deve incrementare sempre della stessa quantità
per passare all’istruzione successiva in memoria. Questo come si gestisce? L’aggiornamento del PC
avviene sempre nella fase di decodifica dell’istruzione; questo perché quando ho letto l’istruzione,
l’ho depositata nell’IR e a partire da questo l’ho decodificata, e averla decodificata significa averla
identificata, cioè ho capito che istruzione è, e quindi so anche quanto è lunga questa istruzione. Se il
codice operativo è più lungo di una parola, nella prima parola deve essere contenuta l’informazione
di quanto è lunga l’istruzione e quante altre locazioni si devono leggere per avere a disposizione
l’intero codice operativo.
29

Abbiamo visto che il linguaggio della macchina processo è un linguaggio binario; si capisce che per
chi deve fare programmi nel linguaggio della macchina processo questa è una cosa scocciante.
Proprio per questa ragione e per superare questa difficoltà c’è uno strato che sta immediatamente
prima della macchina processo, e che quindi realizza una macchina sopra la macchina processo, che
si chiama macchina assembler.
La macchina assembler sostanzialmente mantiene quasi tutte le caratteristiche della macchina
processo, nel senso che macchine assembler di modelli realizzativi diversi sono diverse, però
rispetto alla macchina processo offre una maggiore facilità di programmazione. Questa facilità
deriva dal fatto che tutte le istruzioni previste nella macchina processo vengono codificate nella
macchina assembler in modo mnemonico: se nella macchina processo l’istruzione somma è 1100,
per esempio, nella macchina assembler dico che quest’istruzione si chiama “somma”, cioè associo
ai codici operativi un codice mnemonico, cioè ci ricorda l’operazione che fa l’istruzione e quindi
rende più facilmente usabile questa istruzione. L’istruzione somma non solo contiene il codice
operativo che ci dice che è un’istruzione di somma, ma contiene ovviamente degli operandi, che
nella macchina processo non sono altro che un insieme di bit che possono rappresentare un
indirizzo piuttosto che gli operandi veri e propri dell’istruzione, ecc. Nella macchina assembler per
eliminare questa scocciatura si dà la possibilità di identificare gli operandi con dei simboli. Questo
comporta che la realizzazione della macchina assembler sulla macchina processo avviene attraverso
uno strato di software che è ancora una volta un traduttore; quindi significa che quando faccio un
programma in assembler per generare il codice per la macchina processo devo passare attraverso un
processo di traduzione, in questo caso si dice attraverso una fase di assemblaggio.
Parliamo dello strato che sta ancora sotto la macchina processo, cioè la macchina hardware. Noi
abbiamo detto che una macchina viene realizzata sopra un’altra macchina per effetto di un software;
se diciamo che al di sotto della macchina processo c’è la macchina HW significa che la macchina
processo non era l’ultima nella gerarchia, ma allora qual è lo strato software che fa sì che io realizzi
la macchina processo sulla macchina HW? Lo strato software è il sistema operativo. Il sistema
operativo è un programma fatto da tanti pezzi ognuno responsabile di determinate attività. Il sistema
operativo più che realizzare la macchina processo sulla stessa macchina HW è in grado di realizzare
tante macchine processo, ognuna con la propria memoria e il proprio PC, sulla stessa macchina
HW.
Da un punto di vista logico l’architettura la possiamo immaginare in questo modo: ho un
programma 1 che viene eseguito dalla macchina processo 1, un programma 2 che viene eseguito
dalla macchina processo 2, …, un programma N che viene eseguito dalla macchina processo N.
Naturalmente questi programmi sono espressi in linguaggio binario.
Le N macchine processo attraverso questo strato di software, che è il sistema operativo, vengono
realizzate a partire dalla macchina hardware:
30

Naturalmente se stiamo parlando di quel modello architetturale, in cui c’è la gerarchia di macchine,
ogni macchina è caratterizzata da un proprio linguaggio, quindi se c’è la macchina HW ci deve
essere il linguaggio della macchina HW. Anche il linguaggio della macchina HW è un linguaggio
binario.
Se il sistema operativo realizza N macchine processo sulla stessa macchina HW significa che un
programma che viene eseguito da una macchina processo ha come visibilità il fatto che tutte le
risorse sono dedicate ad un altro programma. Il programma che viene eseguito da una determinata
macchina processo fa sì che questa evolva in funzione delle istruzioni del programma; ma se la
macchina processo funziona così come abbiamo detto significa anche che un’istruzione di quel
programma viene eseguita attraverso il meccanismo del PC; quindi se ci sono N processi significa
che ci saranno N PC, e non solo perché un programma spesso fa riferimento alle operazioni di I/O,
quindi da un punto di vista logico è come se ogni macchina processo fosse dotata del proprio PC, da
una propria memoria di processo dove sta caricato il programma in esecuzione e poi da unità
ingresso/uscita (come se avesse l’unità monitor, l’unità tastiera, ecc…):
Realizzando N macchine processo sulla stessa macchina HW si sfruttano al meglio le risorse
hardware, cioè le risorse disponibili nella macchina HW vengono sfruttate al meglio; questo
significa che normalmente si fa in modo che non stiano ferme o inutilizzate inutilmente.
Durante l’esecuzione di un programma se c’è ad un certo punto un operazione di input/output per
esempio, devo congelare quel programma e attivarne un altro; però poi non ho finito perché quel
programma che era stato congelato si potrebbe scongelare, ma se si scongela un programma si deve
congelare un altro programma. Una cosa del genere come può avvenire e dov’è la complessità nel
far avvenire questo?
Una macchina HW ha un solo esecutore reale, quindi stiamo cercando di inventare la possibilità di
condividere quest’esecutore fra più programmi, però deve valere una regola: se l’esecutore è
dedicato ad un programma, non può essere dedicato ad un altro programma.
Tutte le volte che certe istruzioni della macchina processo devono essere eseguite dalla macchina
HW, si ha che la loro esecuzione è “truccata”, cioè quella che per la macchina processo è
l’istruzione “leggi” in realtà la macchina HW la interpreta come un salto ad un certo indirizzo dove
31

c’è un pezzo di software del sistema operativo; quindi viene congelato il programma e il sistema
operativo può decidere di scongelarne un altro; ma congelare il programma vuol dire che poi perché
tutto funzioni prima o poi quando lo riscongelo questo non si deve essere accorto di essere stato
congelato, quindi il sistema operativo deve salvare tutto un insieme di informazioni che poi
consentono di svegliare di nuovo il programma e ridargli il suo contesto (PC, registri, variabili,
ecc…).
Il sistema operativo è in buona parte costituito da sequenze di istruzioni che sono i servizi di
sistema, che svolgono azioni richieste da un processo garantendo che l’esecuzione del servizio sia
per il processo equivalente all’esecuzione di una normale istruzione (anche quando il processo
viene momentaneamente sospeso).
A livello di macchina HW non esiste più il principio del determinismo. Esiste il meccanismo delle
interruzioni asincrone che ci danno il non determinismo.
Il meccanismo delle interruzioni porta la macchina ad eseguire un salto ad un indirizzo prefissato
ogni qual volta si verificano particolari eventi (battere un tasto). Si parla di interruzioni asincrone
quando non sono prevedibili, cioè sono relative ad eventi esterni.
Quindi esistono due meccanismi di interruzione di interruzione:
• sincrona: causata da un evento interno all’esecuzione del programma e che determina un salto a
un servizio di sistema;
• asincrona: causata da un evento esterno alla macchina; essa interrompe il flusso di istruzioni che
la macchina stava eseguendo e determina un salto a un indirizzo del sistema operativo.
La macchina HW è costituita da sottosistemi funzionali collegati dal sistema di comunicazione:
Ciascun sottosistema è realizzato con dei componenti elementari, le porte logiche, la cui
combinazione da luogo a circuiti più complessi, quali reti combinatorie e sequenziali. Non si può
comunque affermare che i livelli inferiori alla macchina HW sono certamente hw mentre i livelli
superiori sono certamente software.
32

06/04/2004
Noi non studieremo un intero sistema di elaborazione, ma l’attenzione sarà focalizzata soltanto su
un blocco principale che è il processore, la CPU. Quale CPU scegliere come caso di studio? Non si
fa riferimento ad un’architettura commerciale, ma si utilizza un’architettura finta: DLX. Questo
processore è simile a molte architetture commerciali.
Il processore DLX è pronunciato delux, e la sigla deriva da: (AMD 29K, DECstation 3100, HP 850,
IBM 801, Intel i860, MIPS M/120A, MIPS M/1000, Motorola 88K, RISC I, SGI 4D/60,
SPARCstation-1, Sun-4/110, Sun-4/260)/13 = 560 = DLX.
Il DLX è un’architettura RISC, quindi semplicissimo dal punto di vista hardware; una cosa che
caratterizza le architetture RISC è che sono macchine Load/Store, che significa che poiché il set di
istruzioni deve essere molto limitato le operazioni possono essere eseguite soltanto tra operandi
contenuti all’interno del processore (nei registri).
Il DLX ha due banchi di registri: un banco di registri lo chiameremo da ora in poi GPR (generalpurpose
registers) e l’altro lo chiameremo FPR (floating-point registers). Entrambi i banchi di
registri sono formati da 32 registri. I registri hanno tutti la stessa dimensione e questa dimensione è
di 32 bit; si dice quindi che questo processore ha un parallelismo di 32 bit, cioè le operazioni
vengono eseguite su numeri codificati con 32 bit. La memoria è indirizzabile a byte, il suo
ordinamento è di tipo Big Endian, e gli indirizzi sono a 32 bit, cioè abbiamo uno spazio di
indirizzamento di 32 bit.
Concentriamo la nostra attenzione sui registri GPR.
I registri GPR contengono gli operandi delle istruzioni, cioè le istruzioni del set di istruzioni di
questo processore operano su dati contenuti nei registri. Il DLX può eseguire sia calcoli con numeri
interi che calcoli con numeri reali. GPR è il banco dei registri che contiene gli operandi interi,
mentre FPR è quello che contiene gli operandi reali.
Come abbiamo detto il banco GPR contiene 32 registri di 32 bit, e ogni registro verrà identificato da
una lettera seguito da un indice: R0, R1, …, R31. Abbiamo istruzioni del DLX che consentono di
modificare il contenuto di qualsiasi registro ad esclusione del registro R0, che è un registro che può
essere soltanto letto e contiene il valore 0.
Vediamo a cosa può essere utile il registro R0:
supponiamo di voler inizializzare un registro con un valore; se io ho un’istruzione di somma si può
evitare di usare un’istruzione di “move”, cioè di spostamento di una costante in un registro? La
risposta è no. Supponiamo di voler inizializzare registro R1 con il valore 7: R1 ← 7. Se non
conoscessi l’assembly potrei pensare che ci sia un’istruzione del tipo: MOVE R1, 7, cioè
un’istruzione in cui specifico un registro di destinazione e una costante numerica. (Molti processori
hanno questa istruzione). Hennessy e Patterson hanno detto che questa istruzione non è
indispensabile perché può essere simulata con un’altra istruzione: ADDI Rd, Rs, immediate;
questa istruzione somma il contenuto del registro Rs con la costante immediate e il risultato lo
deposita nel registro Rd. Quindi se io voglio scrivere 7 nel registro R1 posso fare così: ADDI R1,
R0, 7. Un registro speciale è anche il registro R31: esistono delle istruzioni di jump and link, e il
registro R31 serve per ricordare l’indirizzo a cui ritornare dopo queste istruzioni.
I bit di ogni registro li indicheremo in questo modo: il bit più a sinistra sarà il bit 0 e quello più a
destra sarà il bit 31. I 32 bit li posso partizionare in 4 byte e anche questi sono ordinati nello stesso
modo dei bit:
Le istruzioni ALU sono le istruzioni che coinvolgono l’unità logico-aritmetica, ed operano
sull’intero registro, cioè sui 32 bit; non ci sono istruzioni ALU che operano su parti di registro.
Le istruzioni Load/Store sono le istruzioni di comunicazione con la memoria e possono operare sia
sull’intero registro (word), sia sul mezzo registro (half word) e sia su un byte:
33

Le istruzioni load/store su mezza parola o su un byte utilizzeranno sempre i byte meno significativi.
Passiamo ai registri FPR.
Il DLX contiene istruzioni per effettuare calcoli in virgola mobile sia in precisione singola (32 bit),
sia in precisione doppia (64 bit). Ma se abbiamo registri a 32 bit come facciamo a memorizzare
operandi a 64 bit? Le istruzioni che operano su operandi a 64 bit considerano i registri come
appaiati l’uno con l’altro: cioè un banco di 32 registri a 32 bit lo posso anche vedere come un banco
di 16 registri a 64 bit; dico che F0 ed F1 li considero uniti e formano un registro a 64 bit che
chiamerò F0
Esistono istruzioni che operano con operandi a 64 bit. Per esempio:
ADDD F0, F8, F12
F8 F9
(F0 è un registro come gli altri e non contiene lo 0 come R0). In questo caso F0 = F0 + F1, F8 = F8
+ F9, F12 = F12 + F13.
Oltre ai registri considerati abbiamo anche altri registri speciali che non possiamo manipolare
direttamente:
• PC (Program Counter), è un registro che contiene l’indirizzo della prossima istruzione da
eseguire; non abbiamo istruzioni che lo modificano esplicitamente, però esistono tante altre
istruzioni, tipicamente le istruzioni di salto, che lo modificano;
• IAR (Interrupt Address Registrer);
• FPSR (Floating-Point Status Register).
Come vengono ordinati i byte in memoria?
Il DLX ordina i byte in memoria in un modo che si chiama Big Endian. Tipicamente i dati possono
essere ordinati in due modi: una modalità si chiama Big Endian e un’altra modalità si chiama Little
Endian. Supponiamo di voler scrivere all’indirizzo 0 della memoria il numero in esadecimale
0×AABBCCDD, e consideriamo che quest’ultima sia divisa in byte:
34

Nel DLX la memoria è indirizzata al byte, cioè la più piccola quantità che posso indirizzare è il
byte. Il byte lo posso scrivere a qualsiasi indirizzo della memoria. Invece ho limitazioni per la
scrittura delle half-word e per la scrittura delle word. Una half-word non la posso scrivere a partire
da un indirizzo qualsiasi della memoria, ma le posso scrivere soltanto a partire da indirizzi pari. Per
esempio consideriamo la seguente istruzione: store half-word
SH indp, R5 (indp indica l’indirizzo di memoria in cui voglio scrivere, R5 è il registro che
contiene il dato che voglio scrivere in memoria). L’indirizzo deve essere multiplo di 2. Si può
scrivere SH 31, R5, però il contenuto di R5 verrà memorizzato a partire dalla locazione 30. Quindi
l’indirizzo reale a partire dal quale vengono scritti i 16 bit è:
indr = indp & 0×FFFFFFFE
cioè viene fatto un and logico tra l’indizzo che dà il programmatore e il numero 0×FFFFFFFE.
Facendo così approssimiamo al numero pari immediatamente precedente (se è dispari).
Ragionamento analogo avviene per le store word (SW) che possono essere memorizzate a partire da
un indirizzo multiplo di 4: per fare questo si fa così ⇒ indr = indp & 0×FFFFFFFC.
L’instruction set del DLX conta 92 istruzioni divise in 6 classi:
• Load & Store instructions
• Move instructions
• Arithmetic and logical instructions
• Floating-point instructions
• Jump & branch instructions
• Special instructions
Un’altra caratteristica delle macchine RISC è che il formato delle istruzioni, nella maggior parte dei
casi, ha un formato delle istruzioni fisso. Nel DLX il formato delle istruzioni è di 32 bit.
Abbiamo tre tipi di istruzioni:
• I-type (Immediate)
• R-type (Register)
• J-type (Jamp)
I-type Instruction
I primi 6 bit rappresentano il codice operativo dell’istruzione, e questo vale per tutti e tre i tipi di
istruzioni. Poi abbiamo 5 bit che codificano l’indirizzo sorgente e 5 bit per il registro destinazione;
gli ultimi 16 bit codificano l’immediate.
Alle istruzioni di tipo I appartengono tutte le istruzioni che ammettono come operando un
immediate (immediato, costante numerica).
Consideriamo l’istruzione: AND R1, R2, R3, che vuol dire fare un and logico tra R2 ed R3 e
memorizzare il risultato in R1 ⇒ R1 ← R2 & R3; un’istruzione di questo tipo non è un’istruzione
di tipo I, perché nessuno dei due operandi è una costante. Le istruzioni di tipo I sono istruzioni del
tipo: ANDI R1, R2, 94 oppure ANDI R1, R2, 423000. Quest’ultimo esempio non lo posso tradurre
in un’istruzione perché 423000 non posso codificarlo in 16 bit.
35

Esempi
addi r1, r2, 5 ; r1 = r2 + signext(5), rd = r1 e rs1 = r2, immediate = 0000000000000101
5 è un numero a 16 bit, mentre r2 è un numero a 32 bit, quindi dentro al processore ci sarà un
sommatore i cui ingressi saranno a 32 bit; allora verrà esteso in segno il numero a 16 bit:
16
immediate
sign
Ext
addi r1, r2, -5 ; r1 = r2 + signext(-5), rd = r1 e rs1 = r2, immediate = 1111111111111011.
32
32
+
36

13/04/2004
R-type Instruction
Nelle istruzioni di tipo R entrambi gli operandi si trovano all’interno di un registro. Il formato delle
istruzioni di tipo R è il seguente:
Abbiamo 6 bit che codificano il codice operativo dell’istruzione, 5 bit che codificano
rispettivamente i registri sorgente e il registro destinazione, 5 bit che non vengono utilizzati, e gli
ultimi 6 bit rappresentano la funzione. Questo significa che le istruzioni di tipo R, che sono per
esempio le istruzioni di tipo somma, sottrazione, le operazioni logiche che avvengono sui registri,
sono caratterizzate da un unico codice operativo, cioè il codice operativo dell’add, per esempio, è
uguale al codice operativo della sub, così come è uguale a quello della and, e così via. Per
discriminare l’una dall’altra si utilizzano gli ultimi 6 bit dell’istruzione.
Esistono due tipi di istruzioni di tipo R:
1. Istruzioni di tipo R che operano sui registri GPR
2. Istruzioni di tipo R che operano sui registri FPR
Queste sono caratterizzate da un codice operativo diverso. Nel caso delle istruzioni di tipo R che
operano sui registri FPR solo 5 bit sono utilizzati per discriminare tra le varie funzioni.
J-type Instruction
Il formato delle istruzioni di tipo J è il seguente:
Abbiamo che 6 bit codificano il tipo di istruzione: jump (J), jump & link (JAL), TRAP, ecc…; i
restanti 26 bit individuano una sorta di spiazzamento, che è l’indirizzo target del salto. Per esempio
un’istruzione del tipo “J target”, dove target è una costante numerica, non fa altro che modificare il
PC di una quantità pari a target, cioè deve spostarsi della quantità target, avanti o indietro (se target
è negativo), rispetto a dove si trova in quel momento: PC = PC + sigext(target).
Vediamo alcune istruzioni dell’instruction set.
Load & Store Instruction
Abbiamo due categorie di istruzioni Load/Store:
1. Load/Store che operano sui registri GPR
2. Load/Store che operano sui registri FPR
Tutte le istruzioni load/store appartengono alla classe delle istruzioni di tipo I.
Sia per una load che per una store io devo indirizzare la memoria, e l’indirizzo viene calcolato in
questo modo: viene sommato al contenuto dell’indirizzo sorgente l’immediate ⇒
effective_address = (rs) + sigext(immediate).
Abbiamo in tutto 5 tipi di load e 3 tipi di store:
• LB (load byte), LBU (load byte unsigned), LH (load half-word), LHU (load half-word
unsigned), LW (load word). Per le load che agisco sui byte o sulle half-word dobbiamo
considerare che questi devono essere scritti nei registri che però sono a 32 bit:
Reg
0 0 0
32
8
37

questi 8 bit vengono scritti nella parte meno significativa del registro. Con la LBU i rimanenti
bit vengono scritti con 0, mentre con la LB vengono settati col bit più significativo degli otto bit
che prelevo dalla memoria. Lo stesso vale per le LH e LHU.
• SB (store byte), SH (store half-word), SW (store word): si preleva dal registro un byte, una halfword
o una word e si scrive in memoria.
Il formato delle istruzioni di load e store è il seguente:
LB/LBU/LH/LHU/LW rd, immediate(rs1)
SB/SH/SW immediate(rs1), rd
Per le load il primo parametro identifica il registro di destinazione, e il secondo parametro identifica
l’indirizzo della memoria.
Esempio: LW R7, 54(R0) Questa istruzione accede all’indirizzo di memoria 54 + R0 (ovvero 0),
preleva una word a quest’indirizzo e la memorizza in R7.
Le store memorizzano all’indirizzo immediate(rs1) della memoria il contenuto del registro passato
come secondo parametro (rd).
Esempio: SW 4(R2), R7 Se R2 vale 20 ed R7 vale 10, questa istruzione va all’indirizzo 20+4=24
in memoria, e a partire da questo scrive la word 10.
Esempio di Store Byte
sb 5(r1), r2
supponiamo che r1=9 ed r2=ff. Quello che avviene è la seguente cosa:
Esempio di Load Byte e Load Byte Unsigned
lb r3, 5(r1)
supponiamo che r1=9. Quello che accade è la seguente cosa:
Move Instructions
Le istruzioni move sono istruzioni di tipo R, e servono a trasferire il contenuto di un registro in un
altro registro entrambi appartenenti allo stesso banco dei registri; oppure sono istruzioni che
permettono di trasferire il contenuto di un registro FPR in un registro GPR o viceversa.
• movi2s, movs2i: GPR ↔ IAR
movi2s rd, rs1 ; rd ∈ RS, rs1∈ IAR
movs2i rd, rs1 ; rd ∈ GPR, rs1∈ SR
38

• movf, movd: FPR ↔ FPR
movf rd, rs1 ; rd, rs1∈ FPR
movd rd, rs1 ; rd, rs1∈ FPR even-numbered
per esempio “movf f0, f4” non fa altro che copiare il contenuto del registro f4 nel registro f0:
f0
f1
f2
f3
f4
f5
.
f31
“movd f0, f4” copia i registri f4-f5 nei registri f0-f1
f0
f1
f2
f3
f4
f5
. .
f31
• movfp2i, movi2fp: GPR ↔ FPR
movfp2i rd, rs1 ; rd ∈ GPR, rs1∈ FPR
movi2fp rd, rs1 ; rd ∈ FPR, rs1∈ GPR
. .
. .
per esempio “movi2fp f4, r9” prende il contenuto del registro r9 e lo copia nel registro f4;
questa è una copia bit a bit e non una conversione; quindi per esempio se r9 contiene il numero
72 dentro f4 ho la codifica binaria di 72 e non ho 72 espresso in floating-point.
Arithmetic and Logical Instructions
Abbiamo 4 categorie che ricadono nella classe delle istruzioni aritmetico-logiche:
• istruzioni aritmetiche;
• istruzioni logiche;
• istruzioni di shift dei dati (spostamento dei dati);
• istruzioni di confronto.
Di ogni istruzione abbiamo sia la versione di tipo R che la versione di tipo I.
add, sub: somma e sottrazione. Il formato, ad esempio per la somma, è: add r1, r2, r3. Quello
che fa è sommare i contenuti di r2 ed r3 e il risultato lo mette in r1. Il contenuto dei registri
sorgente è considerato come rappresentato in complemento a due.
Di queste due esistono anche le versioni unsigned.
addu, subu. I contenuti dei registri è visto come numeri senza segno, ovvero è visto come
numero binario naturale puro, e non in complemento a due. Il formato è come quello di prima:
addu r1, r2, r3.
39

Per tutte e quattro le istruzioni sopra abbiamo la versione di tipo I:
addi, subi, addui, subui. Per esempio: addi r1, r2, #17.
Abbiamo anche le istruzioni di moltiplicazione e divisione:
mult, multu, div, divu. Queste operano soltanto su registri di tipo FPR. Il formato è il seguente:
mult f1, f2, f3.
Istruzioni logiche
Le istruzioni logiche sono delle istruzioni che operano a livello di bit.
and, or, xor. Il formato è il seguente: and r1, r2, r3, dove r1 è il registro destinazione ed r2 e r3
sono i registri sorgente.
Di queste abbiamo anche la versione di tipo I.
andi, ori, xori. Il formato è: andi r1, r2, #16, per esempio.
Un’altra istruzione che appartiene a questa classe è l’istruzione
LHI (load high immediate). In questo caso load non si riferisce alla memoria. È un’istruzione di
tipo I. Quando abbiamo visto le istruzioni di tipo I abbiamo detto che l’immediate è un numero
a 16 bit; come facciamo a caricare in un registro un numero più grande di 16 bit? Per caricare un
immediate lungo in un registro si utilizza questa istruzione. Il formato è: lhi r1, 0×ff00, dove r1
è il registro destinazione. L’immediate viene caricato non nella parte meno significativa di r1,
ma nella parte più significativa. Quindi se io scrivo lhi r1, 0×AABB, questa farà la seguente
cosa:
AA BB 00 00 R1
Quindi se io volessi caricare nel registro R1 il numero 0×AABBCCDD basterebbe prima
caricare la parte alta del numero nella parte alta del registro attraverso la lhi e poi fare:
addui r1, r1, 0×CCDD, oppure ori r1, r1, 0×CCDD
AA BB 00 00 R1
OR
00 00 CC DD
AA BB CC DD
Istruzioni di shift
Queste istruzioni fanno scorrere il contenuto di un registro; questo può essere fatto scorrere o a
destra o a sinistra. Abbiamo tre tipi di shift:
sll (shift left logico), srl (shift right logico), sra (shift right aritmetico).
Il formato è: sll r1, r2, r3, dove r1 è il registro destinazione, r2 è il registro sorgente, e r3 è la
quantità di bit da far scorrere.
Abbiamo anche la versione con immediate:
slli, srli, srai. Il formato è: slli r1, r2, #3. A seguito di questa istruzione accade:
R2 0 …………… 0 0 1 0 1
tutti i bit vengono spostati di tre posti a sinistra, e i tre
bit lasciati vuoti vengono settati a 0.
R1
……… 0 0 1 0 1 0 0 0
Per lo shift a destra è lo stesso: se ho il numero 1011 e faccio lo shift di una posizione a destra
srl(1)
ottengo ⇒ 1011 → 0101. Anche in questo caso i bit lasciati vuoti vengono settati a 0.
40

Se io ho un numero e ne faccio lo shift di n posti a sinistra, è come se moltiplicassi quel numero
per 2 n . Analogamente se io faccio lo shift di un numero di n posti a destra è come dividere il
numero per 2 n ; questo vale se il numero è rappresentato in binario naturale.
Nello shift aritmetico la posizione che viene liberata verrà inizializzata col bit che ha
sra(1)
abbandonato quella posizione: 1011 → 1101.
Se il numero è rappresentato in complemento a due con questa istruzione è come dividere il
numero per una potenza di 2:
1 0 1 1 -5
0 1 0 1 5
1 1 0 1 -3
srl(1)
sra(1)
Istruzioni di confronto
slt (set less than), sgt (set greater than), sle (set less equal), sge (set greater equal), seq (set
equal), sne (set not equal).
slt r1, r2, r3 ; (r2

Il formato è il seguente: ltf f0, f1. Riportiamo soltanto gli operandi da confrontare; il risultato di
questa operazione viene memorizzato implicitamente in un registro ad un solo bit, ed è il registro
FPSR (float-point status register): (f0

.float f1, f2, …, fn Con questa alloco float
.double d1, d2, …, dn Con questa alloco double
C’è una direttiva che forza l’allineamento dei dati ad indirizzi di memoria multipli di una certa base:
.align Esempio:
.data 100
.byte 0×ff
.align 2 ; allinea ad un indirizzo multiplo di 2 2
.word 0×aabbccdd
Quello che avviene in memoria è:
.ascii Memorizza la stringa in memoria. Per esempio:
.data 100
.ascii “Hello!”
Quello che accade è:
.asciiz Memorizza la stringa in memoria e pone l’ultimo byte a 0. Per esempio:
.data 100
.ascii “Hello!”
Quello che accade è:
.space Riserva n byte in memoria senza inizializzarli. Per esempio:
.data 100
.space 5
.byte 0×ff
Quello che accade è:
43

15/04/2004
Nella seguente figura è illustrato quello che è chiamato datapath del processore, la via dei dati:
Questo include tutto il percorso che i dati all’interno del processore possono seguire. Quando parlo
di dati è in senso lato, cioè le istruzioni che vengono lette per il processore di fatto sono dei dati da
manipolare opportunamente. Gli elementi che vengono rappresentati sono: tutti gli elementi che
sono in grado di memorizzare informazioni durante questo percorso, e alcuni elementi che
manipolano i dati. Abbiamo due elementi ALU; i rettangoli sono degli elementi di memoria dove
possono essere memorizzate delle informazioni, e gli ovali con la scritta MUX sono dei multiplexer.
In questo disegno non è rappresentata la parte di controllo del processore.
Vediamo passo passo come viene letta, decodificata ed eseguita ognuna delle istruzioni del DLX
che utilizzano questo datapath. In realtà dobbiamo vederla al contrario: noi abbiamo definito il set
di istruzioni del DLX, questo datapath nasce dopo aver definito questo set di istruzioni.
Partiamo dalla prima fase (figura a
sinistra): la prima cosa di cui ci
occupiamo è la lettura dell’istruzione.
C’è un PC che indirizza la memoria,
l’informazione letta dalla memoria
viene prelevata e va a finire all’interno
del processore e in particolare va a
finire nel registro IR. (I collegamenti
fra i vari blocchi dobbiamo
immaginare che siano tante linee
quanti sono i bit del PC).
È da precisare che la Instruction
Memory e la Data Memory
normalmente non stanno all’interno
del processore.
Si vede che l’uscita del PC va ad
blocco ALU, che in questo caso viene
utilizzato solo come un sommatore;
nell’altro input dell’ALU c’è il
numero 4; quindi viene fatta la somma
del contenuto del PC e il numero 4.
Viene considerato 4 perché ogni
44

istruzione occupa 4 byte, e quindi poi si punterà alla prossima istruzione. In parallelo alla lettura
dell’istruzione il sommatore entra in
azione e produce la somma tra il
valore del PC e 4; questo valore
calcolato viene memorizzato in un
registro che si chiama NPC (new
PC).
Questa parte appena descritta si
chiama Instruction fetch: le
operazioni sopra descritte sono
quelle relative al fetch
dell’istruzione, cioè alla lettura
dell’istruzione dalla memoria e alla
memorizzazione al proprio interno
con l’aggiornamento del PC.
Adesso andiamo nella fase di Instruction decode/register fetch. All’interno di questa parte di
architettura che è quella preposta ad eseguire l’operazione di decodifica c’è il banco dei registri del
DLX. La decodifica avviene in una parte non rappresentata qui, che è la logica di controllo. La
decodifica presuppone che il codice operativo contenuto nell’IR venga decodificato e come risultato
di questa decodifica vengono prodotti i segnali di controllo che abilitano alcune parti del processore
a fare alcune cose. La cosa interessante è che mentre faccio la decodifica io posso in parallelo
quello che viene chiamato register
fetch: è quello che riguarda la lettura
di quei registri (operandi sorgente)
all’interno del banco dei registri per
potere utilizzare questi valori durante
l’esecuzione dell’istruzione. Se
ancora non è avvenuta la decodifica
dell’istruzione come faccio a leggere
gli operandi sorgenti? Questo è
possibile nel caso del DLX per un
motivo molto semplice: la codifica
dell’istruzione nel DLX è tale che se
ci dovessero essere degli operandi
sorgenti questi sicuramente saranno
codificati in un campo di bit che
sono sempre gli stessi (dal bit 6 al
10, e da 11 a 15). Si fa questo perché
un pezzo del processore sta facendo
la decodifica e nel frattempo nel caso
in cui dovessero servire quei registri
io li prelevo; nel caso non servono
45

non vengono utilizzati. Lo stesso non si può dire delle scritture, perché se io scrivo su un registro
perdo il vecchio contenuto che non è più recuperabile.
I valori letti dai potenziali registri sorgenti vengono memorizzati nei due registri A e B, che non
appartengono al banco dei registri accessibili all’utente; in particolare in A viene messo il valore del
registro sorgente codificato nei bit da 6 a 10, e in B quello del registro sorgente codificato nei bit da
11 a 15. Se si dovesse trattare di un’istruzione in cui devo utilizzare un’immediate, questo sta nei bit
da 16 a 31 del registro IR, lo prelevo,
lo estendo in segno (da 16 bit a 32
bit) e questi 32 bit vengono
memorizzati all’interno del registro
Imm (immediate); anche questo è un
registro che l’utente non vede, ma
serve solo per eseguire le istruzioni.
Quindi in questa fase ho prodotto tre
informazioni: registro A, registro B e
Immediate. Queste tre informazioni
potenzialmente, qualcuna di queste o
nessuna di queste, potrebbero essere
utilizzate nella fase successiva.
Finita questa fase si passa alla fase
che si chiama Execution/effective
address calculation.
L’istruzione appena decodificata può
essere: un branch, un’istruzione
ALU (register-register ALU
instruction, oppure un’istruzione con
operando immediato), oppure
un’istruzione di load/store. A
seconda di quale tipologia di
istruzione è stata decodificata, nella fase di execution verranno effettuate alcune operazioni.
Vediamo per ognuna di queste quale
parte di architettura viene coinvolta.
Branch:
dobbiamo calcolare se la condizione
è vera o falsa e calcolare l’indirizzo
di salto. Nelle istruzioni di branch il
salto è indicato col displacement:
all’indirizzo a cui punta il PC, che è
quello dell’istruzione seguente,
bisogna sommare il displacement, lo
spiazzamento che mi va ad
individuare l’istruzione target del
salto.
La prima operazione eseguita è la
verifica che il registro A valga 0 o se
sia diverso da 0 e questo lo si fa
attraverso un comparatore. Il
risultato di questa verifica viene
posto in un registro che si chiama
Cond, ed è un registro ad un solo bit.
46

In parallelo viene calcolato
l’indirizzo target del salto sommando
l’immediate al NPC. Il risultato della
somma viene messo all’interno di un
registro, anche questo un registro di
lavoro, che si chiama ALUOutput.
Quindi se si tratta di un’istruzione di
branch alla fine si producono questi
due risultati: l’indirizzo del salto e la
condizione, che a seconda che sia
vera o falsa farà fare il salto oppure
no.
Register-register ALU instruction:
in A e in B ho i due operandi sorgenti. Nel caso di una istruzione di questo tipo Func è codificata
nella parte finale dell’IR (bit da 21 a
31); questo campo decodificato
durante la fase di decodifica non fa
altro che andare a dire all’ALU quale
operazione effettuare. Alla fine il
risultato di queste operazioni viene
memorizzato dentro il registro
ALUOutput.
I-type instruction:
in questo caso vengono considerati i registri A e Imm, e viene effettuata un’operazione tra questi.
L’operazione da fare al solito è codificata nel codice operativo, e attraverso la decodifica viene
generato un opportuno segnale di controllo che fa sì che l’ALU effettui questa operazione.
47

Al solito il risultato viene
memorizzato nel registro
ALUOutput.
Nel caso di un’istruzione di load o di
store devo utilizzare l’ALU per
calcolare l’indirizzo di memoria a cui
devo accedere. In questo caso ad
ALUOutput assegno la somma tra A
ed Imm:
ALUOutput A + Imm.
Ognuna di queste fasi che si stanno descrivendo avviene in un ciclo di clock. Quindi finora sono
trascorsi tre cicli di clock. Nel quarto ciclo di clock viene coinvolta la parte di architettura che
riguarda il Memory access. In questa fase viene eseguita la fase di load o di store se si tratta di
un’operazione di load o di store, mentre se si tratta di un’operazione I-type o R-type in questa fase,
quindi durante questo ciclo di clock, non si deve fare niente. Se l’istruzione era un branch in Cond
avevamo la condizione, e in ALUOutput avevamo l’indirizzo target del salto. Supponendo che si
tratti di un branch vediamo cosa succede: se la condizione è vera dobbiamo aggiornare il PC col
valore che c’è in ALUOutput; se la
condizione è falsa il PC viene
aggiornato col contenuto di NPC.
48

Se si tratta di un’operazione di load
(nel caso di load/store ALUOutput
contiene l’indirizzo di memoria su
cui fare o la load o la store)
ALUOutput indirizza la Data
memory, il contenuto della locazione
indirizzata viene letto e memorizzato
in un registro temporaneo LMD
(load memory data).
Se si tratta di un’operazione di store
l’operando che deve essere scritto in
memoria si troverà sicuramente nel
registro B, e l’indirizzo dove
memorizzare questo operando si
trova in ALUOutput.
Nel caso di una load o di una store in
ogni caso il PC viene aggiornato col
valore del NPC. Il PC viene
aggiornato al quarto ciclo di clock
perché l’esito del brach per come è
fatto questo datapath lo sappiamo
solo alla fine della fase di execution.
Questa che stiamo descrivendo si
chiama versione sequenziale del
DLX.
Al quinto ciclo di clock che cosa rimane da fare?
Se ho un’istruzione di branch questa viene completata nel quarto ciclo di clock. In tutti gli altri casi
il risultato va a finire in un registro. La fase di memorizzazione del risultato se si tratta di
un’istruzione ALU va eseguita andando ad individuare qual è il registro di destinazione e andandovi
a copiare il risultato che sta in ALUOutput. Se invece non è un’istruzione ALU ma un’istruzione di
load il dato che ho letto sta in LMD:
49

questa è quella che si chiama fase di
Write back.
Il registro di destinazione viene
individuato grazie al fatto che in IR è
ancora presente l’istruzione, e questa
contiene il registro destinazione.
Questo è come è fatto un processore sequenziale RISC. Se non fosse RISC più o meno le parti sono
simili, e quello che è molto più complicato è la parte di controllo, perché tipicamente i processori
CISC non hanno un formato delle istruzioni fisso, quindi c’è una quantità di opzioni elevata, e tutte
queste opzioni devono essere tenute in conto nella logica di controllo.
Quella che abbiamo visto viene chiamata implementazione multiciclo del DLX. Multiciclo perché
le varie operazioni sulla stessa istruzione avvengono in un certo numero di cicli. In particolare
normalmente ogni istruzione viene eseguita in cinque cicli di clock. Questo è vero tranne che per
due istruzioni: branch e store finiscono in quattro cicli di clock.
Dato questo tipo di implementazione del DLX e noto che è il set di istruzioni del DLX, se io volessi
calcolare il CPI medio per l’esecuzione di un programma, probabilmente questo CPI è prossimo a 5.
Se per esempio avessi un programma in esecuzione e scopro che c’è un 12% di istruzioni di branch,
naturalmente il CPI non sarà pari a 5, ma sarà CPI = 4*12/100 + 5*88/100 = 4.88. Naturalmente se
questo programma presentasse il 15% di store il CPI medio sarebbe:
CPI = 0.15*4 + 0.12*4 + 0.73*5 = 4.73.
Ci sono delle soluzione che fanno impiegare meno tempo per eseguire le istruzioni del DLX?
Ovvero si può riorganizzare il datapath in modo diverso per guadagnarci in termini di velocità?
La risposta è che si possono fare diverse cose. Una delle cose che si può fare è: abbiamo visto che
nel caso di istruzioni ALU (sia R-type che I-type), il quarto ciclo di clock, ovvero la fase di MEM,
dove normalmente avviene una load o una store, per questo tipo di istruzioni è una fase
assolutamente inutile perché non viene svolta alcuna operazione. Una modifica che si potrebbe fare
all’architettura vista prima è quella che se si sa che è un’istruzione ALU la fase di write back la si fa
al quarto ciclo di clock. In tal caso per esempio se di istruzioni ALU ne abbiamo il 44% otteniamo
un CPI pari a: CPI = 4.44.
Altri miglioramenti che si possono apportare sono dal punto di vista hardware. Abbiamo visto che
nel datapath del DLX sequenziale ci sono due ALU: nell’instruction fetch e nella fase di execute.
Questi due ALU possono essere unificati perché sono utilizzati in periodi di tempo distinti. Se viene
fatta questa modifica i multiplexer davanti all’ALU dovrebbero permettere un ingresso in più.
Un’altra cosa che si potrebbe fare è quella di unificare la memoria. Noi abbiamo utilizzato due
50

memorie: Instruction memory e Data memory. Risparmiamo perché c’è un unico bus di indirizzi e
un solo bus di dati che partono dal processore; quindi risparmiamo hardware.
Tutte queste cose che si potrebbero fare in realtà non le facciamo, perché passare dalla versione che
abbiamo alla versione pipeline è estremamente semplice.
Pipeline
Immaginiamo di avere una
lavanderia organizzata in tre fasi:
lavaggio, asciugatura e stiratura.
Supponiamo di avere quattro
utenti che richiedono questo
servizio, e supponiamo che la fase
di lavaggio duri 30 minuti, la fase
di asciugatura duri 40 minuti e la
fase di stiratura duri 20 minuti.
Vediamo cosa succede come
tempo di smaltimento degli utenti
se lavoriamo in modo
sequenziale.
Ogni utente può entrare solo
quando quello prima di lui è uscito, cioè quando ha eseguito tutte e tre le fasi. Per avere che l’utente
D esca bisogna aspettare un tempo pari a: 30+40+20+30+40+20+30+40+20+30+40+20= 6 ore.
Nella versione pipeline ogni
utente entra in una fase quando
l’utente precedente ha finito
questa fase. Ovviamente il tutto
è molto più veloce e il tempo
impiegato affinché esca l’utente
D è di 3 ore e 30 minuti.
Quello che varia non è il tempo
per eseguire le tre fasi, ma il
tempo d’attesa per essere
servito.
La condizione ideale è che il pipeline sia bilanciato, cioè tutti gli stadi consumino lo stesso tempo.
In questo caso è come se io producessi un’unità di prodotto ogni frazione di tempo che è la stessa
frazione di tempo che viene consumata in uno qualunque degli stadi del pipeline. Se ci mettiamo
all’uscita del sistema e supponiamo che per produrre un’automobile ci sono 6 stadi di 1 ora
ciascuno a regime abbiamo che viene prodotta un’auto ogni ora. Quindi bisogna bilanciare per
quanto possibile gli stadi del pipeline, perché se gli stadi non sono bilanciati e c’è uno stadio che
dura molto più degli altri questo diventa la latenza che condiziona la performance complessiva del
sistema; quindi è inutile ridurre il tempo di uno stadio solo, perché comunque se c’è uno stadio che
è molto lento è questo che condiziona il pipeline. In ogni caso bisogna minimizzare la latenza per
ogni stadio, ma bisogna anche cercare di renderli uguali.
Quali sono i concetti fondamentali del pipeline?
Posso eseguire una sovrapposizione temporale tra diverse fasi di lavoro che vengono svolte su unità
di prodotto diverse. Ma per le istruzioni?
Per una stessa istruzione le varie fasi devono essere svolte in sequenza, però fasi di esecuzioni
diverse possono essere svolte in parallelo su istruzioni diverse: per esempio mentre si fa la
51

decodifica di un’istruzione si può fare il fetch dell’istruzione successiva. Naturalmente il tempo di
esecuzione della singola istruzione non varia, però il tempo medio di esecuzione delle istruzioni si
riduce di un fattore N (nel caso ideale) se tutte le fasi richiedessero lo stesso tempo di esecuzione.
Nel caso del DLX che abbiamo esaminato, se questo potesse andare bene per il pipeline, tutte le fasi
richiedono un periodo di clock e quindi sembrerebbe che tutti gli stadi sono tra di loro bilanciati,
quindi il tempo di esecuzione medio si ridurrebbe di N. Il throughput migliorerebbe di N perché nel
caso pipeline vedremmo uscire un’istruzione ogni ciclo di clock (a regime); questo significa che
avremmo un CPIpipe = 1 (contro un CPIunpipe = N). Se scriviamo la formula del CPUtime nei due casi
abbiamo:
Quindi sostanzialmente abbiamo un fattore di miglioramento pari ad N. Naturalmente questo
avviene nel caso ideale.
Vediamo come si può organizzare il pipeline per l’esecuzione delle istruzioni. In verticale abbiamo
le istruzioni che devono
essere eseguite e in
orizzontale abbiamo i cicli di
clock.
Immaginiamo di fare
riferimento alla versione
sequenziale del DLX.
Nel primo ciclo di clock
viene fatto il fetch
dell’istruzione i; nel secondo
ciclo di clock l’istruzione i passa alla fase di decode, e siccome le risorse hardware che fanno il
fetch sono libere faccio il fetch della seconda istruzione; così dentro il processore ci sono
contemporaneamente due istruzioni:
Procedendo con i cicli di clock arriviamo al quinto ciclo di clock dove esce l’istruzione i. Da questo
momento in poi ogni ciclo di clock ci sarà un write back:
quindi ogni colpo di clock
esce un’istruzione, e di
conseguenza ho un CPI
medio pari a 1.
Bisogna capire se ci sono dei potenziali conflitti sulle risorse.
52

Se manteniamo l’instruction memory e il data memory separati non possono esserci conflitti. In
questo caso l’instruction memory deve essere rispetto a prima 5 volte più veloce perché prima al
massimo leggevo un’istruzione ogni 5 cicli di clock.
Abbiamo visto che nella versione sequenziale durante l’esecuzione il banco dei registri del DLX
veniva usato nella fase di register fetch (secondo ciclo di clock) e nella fase di write back (quinto
ciclo di clock); con una pipeline piena l’istruzione che è nella fase di write back richiederebbe di
accedere al banco dei registri per andare a scrivere un risultato su un registro destinazione, ma
l’istruzione che è al secondo colpo di clock accede ai registri per fare il register fetch; così ho che
due istruzioni diverse usano la stessa risorsa, cioè il banco dei registri, per fare cose diverse.
Un altro problema è quello che riguarda il PC. Prima succedeva che il PC veniva aggiornato al
quarto ciclo di clock; nel caso del pipeline ogni colpo di clock deve essere aggiornato il PC. Ma se
si aggiorna il PC ogni colpo di clock, e per esempio entra un’istruzione di branch che ha la
condizione vera (ma che si sa al quarto ciclo di clock) succede che dopo di questa entrano altre
istruzioni che non dovevano entrare nel processore.
I registri A, B e Imm nello stesso ciclo di clock sono utilizzati nella fase di execution dall’istruzione
i e scritti nella fase di decode dall’istruzione i+1.
L’IR viene scritto nella fase di fetch; questo viene usato in tempi diversi: nella fase di write back un
pezzo di IR serve per dirci qual è il registro destinazione, ma IR nel frattempo è stato sovrascritto
altre quattro volte quindi non ho come recuperare il registro dove scrivere.
Di conseguenza per la versione pipeline il datapath che abbiamo presentato così come è non può
essere utilizzato.
Vediamo una rappresentazione in cui andiamo a rappresentare piuttosto che il nome della fase la
risorsa coinvolta per eseguire quella fase:
entra un’istruzione che coinvolge
l’instruction memory, poi passa
ad utilizzare la risorsa registro e
la risorsa memoria viene usata
dall’istruzione successiva.
Andando avanti, al quarto colpo
di clock se avessimo usato una
memoria unificata avremmo
avuto un conflitto. Al quinto
colpo di clock abbiamo un
conflitto sui registri. Questo si
chiama conflitto strutturale.
Questo conflitto strutturale da
questo punto in poi potrebbe
esserci sempre se c’è una write
back.
Il conflitto strutturale si ha ogni volta che una risorsa viene utilizzata in due fasi diverse per due
istruzioni diverse.
53

Vediamo un programma scritto in assembly:
16/04/2004
; Inizializza un vettore con 5 valori interi e ne visualizza la
somma
; Sezione dati
.data
vett: .word 12
.word 6
.word 19
.word 7
.word 6
msg_somma: .asciiz "\nLa somma e' %d"
.align 2
msg_sm_addr: .word msg_somma
somma: .space 4
.text
.global main
corrisponde a questo indirizzo
main: addi r3,r0,5
addi r2,r0,0
addi r4,r0,0
loop_somma: lw r5,vett(r2)
subi r3,r3,1
add r4,r4,r5
addi r2,r2,4
bnez r3,loop_somma
stampa: sw somma(r0),r4
addi r14,r0, msg_sm_addr
trap 5
fine: trap 0
Ogni programma assembly, in questo caso DLX, inizia con una direttiva specifica: .data.
Questa direttiva vuol dire che da quel punto sta cominciando la sezione in cui noi andiamo ad
allocare i dati del programma, e non le istruzioni. Un’altra cosa importante oltre alle direttive sono
le etichette, che sono delle parole, degli identificatori, con cui noi per comodità indichiamo delle
zone del codice. Quando questo programma verrà trasformato in una serie di parole da mettere in
memoria queste etichette corrisponderanno a degli indirizzi di memoria.
Questo programma memorizza in memoria 5 valori interi, quindi 5 valori a 32 bit. Siccome noi
vogliamo descrivere qual è la zona del codice dove andiamo a depositare questo vettore mettiamo
l’etichetta vett:; è inutile mettere 5 etichette perché con quella sola sappiamo dove si trovano tutti
gli altri elementi del vettore. Subito dopo questa etichetta ci sono delle direttive, .word, che ci
dicono che quello che segue è un numero che deve essere codificato con una parola di 32 bit da
mettere in memoria. Quindi quando il programma verrà avviato se andiamo all’indirizzo di
memoria corrispondente all’etichetta “vett” troveremo quei 5 valori interi. Dopo segue un’altra
54

etichetta: msg_somma:. Questo è un altro dato perché siamo dentro la sezione “.data”. Siccome noi
vogliamo che questo programma ci visualizzi un output abbiamo bisogno di invocare una qualche
funzione. In C abbiamo la printf: questa come parametri ha una stringa di formattazione (“il numero
è: %d”, per esempio) e l’argomento che è il numero da stampare (quello a cui si riferisce %d).
Questa stringa di formattazione non può stare nella parte del codice, ma deve stare da qualche parte
in memoria e poi in qualche modo verrà invocata. Dopo le 5 word del vettore inizia l’allocazione,
tramite la direttiva .asciiz, di una stringa (ci serve la .asciiz perché dobbiamo dire dove finisce la
stringa). Questa stringa può finire in un byte qualunque di una word, quindi ho bisogno di una
direttiva di allineamento, .align 2, perché vogliamo che la prossima cosa che allochiamo, sempre tra
i dati, venga allocata in un indirizzo che è multiplo di 4, cioè all’inizio di una word. In generale la
direttiva .align n fa sì che il successivo indirizzo sia multiplo di 2 n . Subito dopo abbiamo una word
che contiene il valore dell’etichetta msg_somma, ovvero l’indirizzo a cui abbiamo iniziato ad
allocare la stringa (puntatore in C). Successivamente indichiamo che vogliamo lasciati 4 byte liberi
con la direttiva .space 4.
Con la direttiva .text finisce la sezione dei dati e inizia quella del codice vero e proprio del
programma. La direttiva .global dice che l’etichetta che segue è un’etichetta che deve essere visibile
anche ad altri moduli eventualmente linkati col nostro programma.
A partire dall’etichetta main: abbiamo le istruzioni vere e proprie. Siccome noi vogliamo scandire
un vettore e sommarne gli elementi, abbiamo bisogno di un indice che ci dice quanti sono gli
elementi da leggere (in C: for(i=0;i

; Equivalente assembly DLX del codice C :
; printf("Hello! \n real %f , integer %d\n", 1.234, 43543);
.data
msg: .asciiz "Hello! \n real %f , integer %d\n"
.align 2
msg_addr: .word msg
.double 1.234
.word 43543
.text
addi r14,r0,msg_addr
trap 5
trap 0
20/04/2004
N.B. La chiamata della trap altera il valore del registro r1.
Vediamo adesso l’utilizzo di una routine esterna. Immaginiamo che abbiamo la necessità di leggere
da tastiera un numero intero senza segno. Noi teoricamente dovremmo utilizzare la trap associata
alla read. Qualcuno ha utilizzato le chiamate di sistema e ha realizzato il codice il cui risultato è
leggere in un certo registro un valore intero che noi immettiamo da tastiera. Il sorgente di questo
programma è il seguente:
;*********** WINDLX Ex.1: Read a positive integer number *************
;*********** (c) 1991 Günther Raidl *************
;*********** Modified 1992 Maziar Khosravipour *************
;-----------------------------------------------------------------------------
;Subprogram call by symbol "InputUnsigned"
;expect the address of a zero-terminated prompt string in R1
;returns the read value in R1
;changes the contents of registers R1,R13,R14
;-----------------------------------------------------------------------------
.data
;*** Data for Read-Trap
ReadBuffer: .space 80
ReadPar: .word 0,ReadBuffer,80
;*** Data for Printf-Trap
PrintfPar: .space 4
SaveR2: .space 4
SaveR3: .space 4
SaveR4: .space 4
SaveR5: .space 4
InputUnsigned:
.text
.global InputUnsigned
;*** save register contents
sw SaveR2,r2
56

sw SaveR3,r3
sw SaveR4,r4
sw SaveR5,r5
;*** Prompt
sw PrintfPar,r1
addi r14,r0,PrintfPar
trap 5
;*** call Trap-3 to read line
addi r14,r0,ReadPar
trap 3
;*** determine value
addi r2,r0,ReadBuffer
addi r1,r0,0
addi r4,r0,10 ;Decimal system
Loop: ;*** reads digits to end of line
lbu r3,0(r2)
seqi r5,r3,10 ;LF -> Exit
bnez r5,Finish
subi r3,r3,48 ;´0´
multu r1,r1,r4 ;Shift decimal
add r1,r1,r3
addi r2,r2,1 ;increment pointer
j Loop
Finish: ;*** restore old register contents
lw r2,SaveR2
lw r3,SaveR3
lw r4,SaveR4
lw r5,SaveR5
jr r31 ; Return
Noi vogliamo utilizzare questo codice in modo tale da evitare che ogni volta che dobbiamo leggere
un intero senza segno dobbiamo andare ad implementare tutta una serie di cose scomode.
Questo programma definisce un’etichetta globale, in modo tale che se saltiamo a questa etichetta
comincia ad essere eseguito tutto il codice che svolge per noi il compito di leggere da tastiera un
numero senza segno. Per invocare questa procedura faremo un jal (nel registro r31 viene
memorizzato l’indirizzo a cui si dovrà ritornare) : jal InputUnsigned. Noi dobbiamo conoscere
alcune cose: prima che lo chiamiamo dobbiamo settare dei registri e poi dobbiamo sapere in quale
registro memorizza il numero letto da tastiera. Per quanto riguarda l’input dobbiamo mettere in r1
l’indirizzo della stringa di formattazione usata per fare la domanda: R1 indirizzo stringa; per
quanto riguarda l’output abbiamo che il numero letto da tastiera viene memorizzato sempre in r1.
Quando viene utilizzata questa routine avviene che vengono utilizzati dei registri e quindi vengono
cambiati i valori di questi registri: r13 ed r14.
Esempio:
; Questo programma legge 5 numeri e ne visualizza la somma
; Sezione dati
57

.data
vett: .space 20
msg_lett: .asciiz "\nInserire un numero:"
msg_somma: .asciiz "\nLa somma e' %d"
.align 2
msg_sm_addr: .word msg_somma
somma: .space 4
.text
.global main
main: addi r3,r0,5
addi r2,r0, 0
loop_lett: addi r1,r0,msg_lett
jal InputUnsigned
sw vett(r2), r1
addi r2,r2,4
subi r3,r3,1
bnez r3, loop_lett
calcolo: addi r3,r0,5
addi r2,r0,0
addi r4,r0,0
loop_somma: lw r5,vett(r2)
subi r3,r3,1
add r4,r4,r5
addi r2,r2,4
bnez r3,loop_somma
stampa: sw somma(r0),r4
addi r14,r0, msg_sm_addr
trap 5
fine: trap 0
Vediamo adesso un esempio di utilizzo di registri FPR.
Esempio:
;*********** WINDLX Ex.3: Factorial *************
;*********** (c) 1991 Günther Raidl *************
;*********** Modified: 1992 Maziar Khosravipour*************
;--------------------------------------------------------------------------
; Program begin at symbol main
; requires module INPUT
; read a number from stdin and calculate the factorial (type: double)
; the result is written to stdout
;--------------------------------------------------------------------------
.data
Prompt: .asciiz "An integer value >1 : "
58

PrintfFormat: .asciiz "Factorial = %g\n\n"
.align 2
PrintfPar: .word PrintfFormat
PrintfValue: .space 8
main:
.text
.global main
;*** Read value from stdin into R1
addi r1,r0,Prompt
jal InputUnsigned
;*** init values
movi2fp f10,r1 ;R1 -> D0 D0..Count register
cvti2d f0,f10
addi r2,r0,1 ;1 -> D2 D2..result
movi2fp f11,r2
cvti2d f2,f11
movd f4,f2 ;1-> D4 D4..Constant 1
;*** Break loop if D0 = 1
Loop: led f0,f4 ;D0

Vediamo la versione pipeline del DLX:
22/04/2004
Questa versione somiglia molto a quella sequenziale, ma tra i vari stadi vengono interposti dei
blocchi che si chiamano pipeline register. Molti dei problemi che abbiamo evidenziato la scorsa
volta sono relativi al fatto che contemporaneamente io utilizzo la stessa risorsa per istruzioni di
verse. Per evitare questo tipo di problema, se io per esempio sono nello stadio di execution e quindi
mi servono i valori di A e di B che avevo scritto nella fase di register fetch, se questi valori li
conservo da qualche parte libero A e B per poterci scrivere di nuovo. Ogni volta che io leggo
un’istruzione il registro IR viene scritto, e allora questo IR lo conservo e lo faccio viaggiare assieme
all’istruzione, così quello che serve all’istruzione se lo porta dietro. È come se questo parallelismo
nell’esecuzione delle istruzioni da un punto di vista logico richiedesse che ogni fase eseguita
all’interno della pipe su una determinata istruzione avesse bisogno del proprio contesto. Per
realizzare questo tipo di operazione sono stati introdotti questi pipiline register. Quando io scrivo su
IR, questo diventa un campo del pipeline register. Questi pipeline register hanno come campi i
registri che usavamo nella versione sequenziale. Ogni pipeline register ha un suo nome: IF/ID
(instruction fetch/instruction decode), cioè il registro pipeline interfaccia tra lo stadio di fetch e
quello di decode; ID/EX (instruction decode/execute); EX/MEM; MEM/WB.
Facendo in questo modo molti dei problemi visti vengono risolti, ma non tutti.
Adesso passo passo andiamo ad analizzare
cosa succede nella versione pipeline.
All’inizio ho il PC che indirizza
l’instruction memory; il contenuto di
questa va copiato all’interno del pipeline
register, e in particolare nel campo IR di
questo registro: IF/ID.IR Mem[PC].
Questo significa che IR, che è un registro
a 32 bit è un campo di IF/ID, e a questo
campo gli assegno come valore quello che
ho letto dalla memoria all’indirizzo del
PC.
60

A differenza di quanto avveniva nella
versione sequenziale del DLX stavolta
sono costretto ad aggiornare il PC
immediatamente, cioè dopo aver letto
l’istruzione. Questo lo devo fare perché
il prossimo colpo di clock devo leggere
un’altra istruzione. In particolare a
seconda del valore della condizione che
c’è nel registro EX/MEM devo
aggiornare il PC o con PC+4 o con un
altro indirizzo se la condizione
dell’istruzione, che si trova nella fase di
execute e che vado a valutare nella fase
di MEM, è vera (quindi avevo un
branch):
IF/ID.NPC,PCif(EX/MEM.cond)(EX/
MEM.ALUOutput) else (PC+4).
Quindi ogni volta che leggo
un’istruzione devo aggiornare sia il PC che il NPC; entrambi li aggiorno o sommando 4 al quello
che già era il PC oppure andando a copiare il valore di indirizzo target calcolato per un’istruzione
che eventualmente già era entrata nel pipeline e che era un’istruzione di branch. Questo significa
che l’esito di un’istruzione di branch lo conosco soltanto qua; ma così nel frattempo sono entrate
altre istruzioni agli indirizzi successivi che non dovevano entrare.
Nella fase di decodifica in parallelo avvengono due cose: la decodifica dell’istruzione e il register
fetch.
Adesso l’IR che si trova nel pipeline
register IF/ID mi serve per indirizzare il
banco dei registri, fare il register fetch e
andare a produrre i valori da memorizzare
su A, B e Imm (preceduto dall’estensione
in segno):
ID/EX.A Regs[IF/ID.IR6..10]
ID/EX.B Regs[IF/ID.IR11..15]
ID/EX.Imm(IF/ID.IR16)##IF/ID.IR16..32
Se succedesse solo questo quando vado
avanti entra una nuova istruzione che va a
scrivere su IR, quindi perderei l’IR
dell’istruzione che si trova nella fase di
decode. Per evitare questo nella fase di
decode ricopio anche l’IR e il NPC.
Andiamo alla fase di execution. Come sappiamo questa fase può riguardare diverse operazioni a
seconda del codice operativo. In particolare possiamo avere un’istruzione ALU (register-register
oppure register-immediate), un’istruzione Load/Store, oppure un Branch.
Vediamo cosa accade in ognuno di questi casi.
61

Se è un’istruzione ALU register-register
nel campo ALUOutput del registro
pipeline EX/MEM viene messo il
risultato dell’operazione; nel caso in cui
è un’istruzione ALU register-immediate
avviene la stessa cosa con la differenza
che non vengono utilizzati gli operandi
A e B, ma A e Imm:
1) EX/MEM.ALUOutput ID/EX.A
func ID/EX.B
2) EX/MEM.ALUOutput ID/EX.A
op ID/EX.Imm
Sempre nell’ipotesi che si tratti di un’istruzione ALU devo propagare IR e devo settare a 0 il
registro di condizione; setto a zero questo registro perché essendo un’istruzione ALU non devo
preoccuparmi di verificare la
condizione, però da questo valore
dipende l’aggiornamento del PC e
settando a 0 questo registro il PC
verrà incrementato di 4:
EX/MEM.IR ID/EX.IR
EX/MEM.Cond 0
N.B. Non è necessario copiare il NPC
perché questo se serve serve nella
fase di execution per calcolare
l’indirizzo di salto e non nelle
successive.
Se non è una ALU instruction ma una Load/Store avviene la stessa cosa che avveniva per la
versione sequenziale (calcolare l’indirizzo
per accedere al prossimo stadio alla
memoria); inoltre essendo un’istruzione di
load/store devo settare a 0 il registro di
condizione e portare avanti il campo B:
EX/MEM.IR ID/EX.IR
EX/MEM.ALUOutput ID/EX.A +
ID/EX.Imm
EX/MEM.cond 0
EX/MEM.B ID/EX.B
62

Nell’ipotesi in cui sia un’istruzione di
salto nella fase di execution calcolerò il
valore della condizione e il valore
dell’indirizzo effettivo a cui saltare nel
caso si verifichi la condizione:
EX/MEM.ALUOutput ID/EX.NPC +
ID/EX.Imm
EX/MEM.cond ID/EX.A op 0
Ovviamente ricopio anche l’IR:
EX/MEM.IR ID/EX.IR
Passando alla fase di Memory access mi sposto il registro IR; se l’istruzione che è entrata nella fase
di MEM è un’istruzione ALU sposto il campo ALUOutput:
MEM/WB.IR EX/MEM.IR
MEM/WB.ALUOutput EX/MEM.ALUOutput
Se è un’istruzione di Load/Store nella fase di MEM devo o leggere o scrivere la memoria:
MEM/WB.IR EX/MEM.IR
MEM/WB.LMD Mem[EX/MEMALUOutput]
oppure
Mem[EX/MEMALUOutput] EX/MEM.B
63

Nella fase di Write Back possono succedere due cose a seconda che sia un’istruzione ALU o
un’istruzione Load. In entrambi i casi vado a fare la scrittura del risultato sul banco dei registri.
Nel caso di un’istruzione ALU abbiamo:
Nel caso di un’istruzione di Load abbiamo:
Regs[MEM/WB.IR 16..20] MEM/WB.ALUOutput
oppure
Regs[MEM/WB.IR 11..15] MEM/WB.ALUOutput
Regs[MEM/WB.IR11..15] MEM/WB.LMD
Nella fase di write back per indirizzare il registro destinazione sul banco dei registri ho bisogno di
alcuni bit del registro IR di questa stessa istruzione; ecco perché mi trasporto il registro IR fino alla
fase di write back.
Dobbiamo vedere come passare dall’architettura sequenziale a quella pipeline.
Ci sono vari problemi. Sostanzialmente ci sono tre problemi che sono quelli che vengono chiamati
Hazards.
I registri vengono letti ogni volta nella fase di decode e vengono scritti ogni colpo di clock per
l’istruzione che si trova nella fase di write back; questo ci dà un conflitto strutturale. Lo stesso tipo
di conflitto c’è se la memoria è unificata. Questi si chiamano structural hazards (hazards
strutturali), cioè sostanzialmente legati al problema che la stessa risorsa viene utilizzata per
istruzioni diverse per fare operazioni diverse.
Poi ci sono i control hazards, che sono legati all’aggiornamento del PC: come si fa quando è
entrata un’istruzione di branch, visto che l’esito di questa istruzione lo conosco nella fase di MEM e
nel frattempo sono entrate altre tre istruzioni? L’azzardo consiste nell’aver fatto un fetch ogni ciclo
di clock.
Infine c’è quello che viene chiamato data hazard, che è legato al problema della dipendenza fra i
dati: se per esempio ho due istruzioni consecutive che utilizzano un registro, e l’istruzione che entra
64

per prima produce il valore di questo registro (operando destinazione), mentre l’istruzione che entra
per seconda consuma il valore di questo registro (operando sorgente), si ha che il valore di quel
registro viene prodotto nella fase di write back per la prima istruzione, ma quando questa istruzione
è nella fase di write back la seconda istruzione è nella fase di execution, quindi ha già utilizzato il
contenuto del registro che non è quello corretto
i add r1,r2,r3 ← r1 viene utilizzato come registro destinazione
i+1 add r5,r6,r1 ← r1 viene utilizzato come registro sorgente
Quindi l’architettura pipeline avrebbe sconvolto la logica di esecuzione rispetto a quella prevista nel
programma fatto dal programmatore.
Hazard Strutturali
Vediamo per ogni colpo di clock quali sono le risorse del processore utilizzate dalle varie istruzioni
all’interno della pipe.
Al primo ciclo di clock viene coinvolta la memoria (che immaginiamo unificata); al secondo colpo
di clock la prima istruzione entra nella fase di decode, e quindi la risorsa coinvolta è Reg, e la
seconda istruzione coinvolge la MEM per il fetch; al terzo colpo di clock abbiamo tre istruzioni
dentro il pipeline: la prima istruzione utilizza l’ALU, la seconda coinvolge i registri e la terza
utilizza la MEM. Al quarto colpo di clock se la prima istruzione è una Load o una Store utilizzerà la
MEM, e quindi ci sarà un conflitto con l’istruzione che deve fare il fetch. Questo è un hazard
strutturale.
Poiché la prima istruzione è già dentro, quello che si può
fare è ritardare il fetch di un ciclo di clock, in modo tale
che la prima istruzione faccia l’accesso in memoria, la
libera e poi si può fare il fetch dell’altra; questo significa
ritardare tutto di un colpo di clock. Così la quarta
istruzione entrerà nel quinto ciclo di clock. Si dice che
abbiamo introdotto uno stallo, ovvero è stato stallato per
un ciclo di clock il pipeline. Se la seconda istruzione
fosse una Load/Store si introdurrebbero due stalli.
65

Un’altra rappresentazione è la seguente:
Vediamo da un punto di vista concreto come si fa ad introdurre uno stallo.
Supponiamo che nel nostro pipeline sia entrata un’istruzione di Load o di Store e che sia arrivata
nella fase di execution:
Non appena questa istruzione arriva nella fase di MEM si genererebbe un conflitto con l’istruzione
che entra nella fase di fetch (i+3):
Per introdurre uno stallo noi dobbiamo fare in modo che il fetch dell’istruzione i+3 venga fatto al
prossimo colpo di clock. Il PC contiene l’indirizzo dell’istruzione i+3 e con questo indirizzerebbe la
66

memoria, ma non lo deve fare perché nel frattempo la memoria è indirizzata dall’ALUOutput che
mi dice se deve fare una Load o una Store; quindi è come se io disabilitassi l’indirizzamento della
memoria da parte del PC; ma il PC quando finisce la fase di fetch si incrementerebbe all’indirizzo
di i+4, ma così i+3, che non è stata fatta avanzare, verrebbe persa. Quindi devo impedire che il PC
si incrementi, e per fare questo invece che sommare 4 gli sommo 0. Quindi al prossimo colpo di
clock faccio il fetch dell’istruzione i+3 che prima non era riuscito a fare; ovvero l’istruzione i+3
non è stata scritta sul registro IR, ma su questo è stata scritta una Not operation (un’istruzione che
non fa niente):
Per eliminare il conflitto sulla memoria basta utilizzare memorie saparate. Per quanto riguarda i
registri abbiamo un conflitto strutturale perché un’istruzione li usa nella fase di decode e una nella
fase di write back. Per risolvere questo problema vengono utilizzate delle tecniche per
implementare i registri che consentono a questi di essere letti e scritti all’interno di un ciclo di
clock; in particolare nella prima metà del ciclo di clock si esegue la scrittura (write back) e nella
seconda si esegue la lettura (register fetch). Con queste due tecniche abbiamo eliminato qualsiasi
tipo di hazard strutturale.
Data hazard
Supponiamo di avere il seguente segmento di codice:
nella prima istruzione r1 è
un operando destinazione;
in tutte le altre istruzioni r1
è un operando sorgente. Il
valore di r1 viene prodotto
nella fase di write back
della prima istruzione
(viene aggiornato il
registro), ovvero nel quinto
ciclo di clock. Alla
seconda istruzione r1 serve
nella fase di register fetch
ovvero nel terzo ciclo di
clock, quindi il valore di r1
che vado a leggere non è
quello aggiornato e di
conseguenza la seconda
istruzione non verrà
67

eseguita correttamente. Alla terza istruzione r1 serve nel quarto ciclo di clock quindi anche questa
istruzione non viene eseguita correttamente. Alla quarta istruzione r1 serve al quinto ciclo di clock,
e se utilizziamo la tecnica di scrivere nella prima metà del ciclo di clock e leggere nella seconda
metà questa istruzione viene eseguita correttamente. La quinta istruzione viene eseguita
correttamente.
Siccome non posso permettermi di eseguire le istruzioni in modo non corretto devo introdurre degli
stalli: quando faccio il register fetch di un registro ancora non corretto devo evitare che questo
valore si propaghi alla fase successiva; questo è come dire che io ritardo la fese di register fetch fino
a quando non sono sicuro che il valore che andrò a leggere non sia quello corretto:
una volta che ho il valore corretto di r1 posso andare avanti con l’istruzione sub r4,r1,r5:
Facendo così ho perso due colpi di clock (ho introdotto due stalli), perché piuttosto che fare un
decode ne ho dovuti fare tre.
Supponiamo di avere una situazione del seguente tipo:
l’istruzione I–2 nella fase di
MEM, l’istruzione I–1 nella
fase di execution, l’istruzione
I nella fase di decode e
l’istruzione I+1 nella fase di
fetch.
Se c’è un data hazard si
verifica con qualcosa che
avviene nella fase di decode,
perché è qui che faccio il
register fetch, e mi preoccupo
che il register fetch che sto
per fare possa non essere
quello corretto, ovvero leggo
un registro sorgente che deve essere ancora prodotto, cioè è destinazione in un’istruzione che è più
avanti nel pipeline. L’istruzione da cui c’è una dipendenza può stare o nella fase di execution o
nella fase di MEM. Quindi potenzialmente io so che in questo tipo di pipeline il problema del data
hazard si può porre tra l’istruzione che è nella fase di decode e le istruzioni che sono nelle fasi di
execution e MEM. Come faccio a scoprire se c’è un problema di data hazard? Basta andare a vedere
se gli operandi sorgenti dell’istruzione I sono operandi destinazione delle istruzioni I–1 e I–2. Se c’è
68

una dipendenza tra I e I–2 devo aspettare un colpo di clock, mentre se la dipendenza è tra I e I–1
devo aspettare due colpi di clock. Supponiamo che la dipendenza sia tra I e I–1, quando la I–1 si
sposta in avanti la I non può spostarsi, ma qualcosa deve avanzare, e questo qualcosa è una not
operation. Quando viene eseguita la fase di write back per l’istruzione I–1 posso fare il register
fetch per la I, ma per fare questo mi occorre che nel registro pipeline IF/ID ci sia l’istruzione I;
allora devo impedire che IR venga scritto a causa delle instruction fetch che possono avvenire
durante quei due cicli di clock, e poi devo impedire che il PC venga incrementato per non perdere le
istuzioni I+1 e I+2. Per fare questo bisogna “prendere in giro” tutto un pezzo di hardware: quando
la logica di controllo andando a controllare se gli operandi sorgente dell’istruzione I dipendono
dagli operandi destinazione di I–1 e di I–2, trova questa dipendenza (e quindi sa che deve introdurre
uno o due stalli), impedisce all’istruzione I e all’istruzione I+1 di propagarsi, e mette 0 al posto di 4
(per l’incremento del PC).
69

23/04/2004
Abbiamo detto che riusciamo a capire se ci può essere un data hazard analizzando la dipendenza tra
l’istruzione che si trova nella fase di decode e le istruzioni che sono negli stage di execution e di
MEM. Poi a fronte della detection di un hazard bisogna provvedere a introdurre degli stalli (può
essere uno o possono essere due). Introdurre uno stallo significa fare in modo che il register fetch
avvenga soltanto quando il write back l’istruzione con cui c’è la dipendenza è avvenuto.
Vediamo come si fa: supponiamo che tra l’istruzione i+1 e l’istruzione i ci sia un data hazard,
quindi ci mettiamo nelle condizioni in cui bisogna introdurre due cicli di stallo
A questo punto nello stadio di fetch bisogna impedire che s’incrementi il PC (il 4 bisogna farlo
diventare 0),e bisogna impedire che venga scritto il campo IR del registro IF/ID; nella fase di
decode si forza una not operation e bisogna impedire che la fase di register fetch venga completata,
cioè che i registri che vengono letti a fronte della decodifica vanno a finire sul pipeline register
ID/EX, e lo stesso vale per l’immediate:
Dopodiché la not operation va nello stadio di execution e si ripete la stessa procedura di prima:
70

a questo punto ho due not operation che si propagano, e quindi sto perdendo due cicli di clock:
A questo punto si può sbloccare tutto e la i+2 può avanzare:
Quello che abbiamo illustrato è un modo per tamponare situazioni di emergenza che potrebbero
portare alla non corretta esecuzione del programma. L’unico rimedio che abbiamo evidenziato è
quello di introdurre dei cicli di stallo, cioè penalizzare le prestazioni.
C’è qualche soluzione alternativa all’introduzione dei cicli di stallo? C’è qualcos’altro che penalizzi
meno le prestazioni, ovvero che introduca meno cicli di stallo?
Una di queste soluzioni, che poi tipicamente è la soluzione che si utilizza, è la seguente: quando
abbiamo la dipendenza tra l’istruzione che si trova nella fase di decode e quella che si trova nello
stadio di execution normalmente bisogna aspettare fintanto che l’istruzione che è più avanti non
arrivi alla fase di write back e scriva il risultato nei registri e a quel punto può avanzare l’istruzione
successiva; ma quando l’istruzione che produce il risultato si trova alla fine della fase di execution
mette il risultato nel campo ALUOutput del registro EX/MEM; quindi perché bisogna aspettare altri
due cicli di clock per averlo? C’è qualche soluzione per cui lo prendo subito e quindi aspetto meno?
Questo viene fatto, cioè se il risultato di un’operazione è già disponibile si riesce a prendere
anticipando la fase di write back, che nonostante ciò avviene correttamente lo stesso:
71

supponiamo di avere la situazione
a sinistra; si vede che c’è una
dipendenza tra la prima istruzione
e tutte le seguenti. Quando la
prima istruzione arriva nella fase
di execution e quindi
l’ALUOutput contiene il valore
corretto di R1, prendo questo
valore e lo forzo all’ingresso
dell’ALU in modo tale che sia
disponibile per l’istruzione
successiva. Questa tecnica si
chiama forwarding, cioè anticipo
la fornitura del risultato
all’istruzione successiva. Lo
stesso discorso si fa per la terza
istruzione con la differenza che
stavolta il valore di R1 si trova nel campo ALUOutput del registro MEM/WB. Facendo in questo
modo non ho bisogno di introdurre alcuno stallo.
C’è un caso in cui non riusciamo ad eliminare completamente gli stalli.
Supponiamo che il processore pipeline è stato dotato di forwarding, e supponiamo che il codice sia
il seguente:
in questo caso il problema è che
mi serve R1 all’ingresso
dell’ALU al quarto ciclo di
clock; ma R1 viene prodotto
dalla load alla fine della sua
fase di MEM, cioè alla fine del
quarto ciclo di clock, quindi a
me serve qualcosa che avverrà
nel futuro. Questo comporta che
non posso fare il forwarding,
quindi devo fare scattare un
altro ciclo; quello che si fa
allora è introdurre una bolla, e
quindi la fase di execution la
faccio avvenire un colpo di
clock dopo:
fatto questo fornisco all’ingresso
dell’ALU il valore dopo averlo
calcolato e quindi alla fine pago un
ciclo di clock. Questo significa che
malgrado sia attivo il forwarding ci
sono dei casi, in particolare quando
ho una load seguita da un’altra
istruzione che usa il risultato della
load, in cui devo introdurre un ciclo
di clock di stallo.
72

Vediamo come si implementa il forwarding:
Sia quando c’è una dipendenza fra due istruzioni adiacenti sia tra due istruzioni distanziate (di due)
noi ci troviamo a fare, quando usiamo il forwarding, una retroazione dal registro ALUOutput verso
l’ingresso dell’ALU; il registro ALUOutput può stare o sul registro pipeline EX/MEM oppure sul
MEM/WB; questo registro può andare o in un ingresso dell’ALU o nell’altro. Per fare questo metto
due multiplexer più grandi rispetto a quelli che c’erano prima in modo tale che posso decidere cosa
fare arrivare all’ingresso dell’ALU.
Quindi ci sono dei casi in cui quando ci sono dei data hazard bisogna introdurre uno stallo; si può
trovare una qualche soluzione che anche in questa eventualità io posso risparmiarmi questo ciclo di
clock di stallo? A livello hardware no. A livello software c’è qualcosa che si può fare? Ovvero il
compilatore può fare qualcosa? Il compilatore è qualcosa che ha progettato qualcuno che sa che
sotto c’è un’architettura pipeline e di conseguenza sa come funziona, e sa che ogni volta che c’è
un’istruzione del tipo LW Rc, c e dopo un’istruzione del tipo ADD Ra, Rb, Rc ci sarà un data
hazard dovuto al fatto che Rc nella prima è un registro destinazione e nella seconda è un registro
sorgente. Siccome il compilatore ha la responsabilità, ma anche il potere di decidere quali istruzioni
del set d’istruzioni utilizzare e in quale sequenza, se ci sono delle alternative nella compilazione che
possono produrre un’ottimizzazione, potrebbe adottare queste alternative. Vediamo quali sono le
alternative che si possono fare.
Supponiamo che il compilatore deve tradurre le seguenti istruzioni C:
a = b + c;
d = e – f;
Il modo più semplice di tradurre questo codice in Assembler, tipo quello del DLX, è il seguente
(ricordiamo che il processore ha un’architettura di tipo load/store e quindi le variabili sono in
memoria):
LW Rb, b
LW Rc, c
ADD Ra, Rb, Rc
SW a, Ra
LW Re, e
LW Rf, f
SUB Rd, Re, Rf
SW d, Rd
73

In questo codice ci sono dei data hazard che non riesco a risolvere col forwarding. Quello sopra è
quello che si chiama slow code, cioè è quello che produce dei cicli di stallo. Vediamo la versione
ottimizzata, fast code:
LW Rb, b
LW Rc, c
LW Re, e al posto di fare ADD Ra, Rb, Rc faccio LW Re, e, cioè ho messo
ADD Ra, Rb, Rc un’istruzione nel mezzo tra le due istruzioni che creano il data
LW Rf, f hazard
SW a, Ra metto questa tra LW Rf, f e SUB Rd, Re, Rf in modo che non si
SUB Rd, Re, Rf crei il data hazard
SW d, Rd
Questo codice è più veloce e impiega due cicli di clock in meno rispetto al primo.
Vediamo delle analisi fatte su campo per capire cosa significa utilizzare queste tecniche di
compilazione per ridurre gli stalli:
In rosso c’è l’ottimizzazione,
in verde non c’è
l’ottimizzazione. Abbiamo
tre benchmark: gcc, spice,
tex. Sulle ascisse abbiamo la
percentuale di load che
stallano il pipeline. Si vede
come nel caso del gcc si
passa dal 54% al 31% di load
che stallano il pipeline. Nel
caso di spice si passa dal
42% al 14% e nel caso di tex
dal 65% al 25%.
Vediamo come si misura la performance in un pipeline. Nel nostro caso il tipo di ragionamento che
utilizziamo è il seguente: se abbiamo una versione sequenziale, per esempio del DLX, in cui si
impiegano da 4 a 5 cicli di clock per eseguire un’istruzione; quando questa versione la si rende
pipeline cosa ci si guadagna? Ragioniamo in termini di speedup:
I due periodi di clock sono normalmente diversi perché il pipeline richiede hardware aggiuntivo
rispetto alla versione sequenziale, e questa aggiunta significa anche probabilmente latenze
maggiori. Ciononostante trascuriamo questa differenza tra i due periodi dei cicli di clock. Il CPIPIPE
è il CPI che mediamente ottengo nella versione pipeline. Questo lo posso scrivere come la somma
di due contributi: caso ideale CPIIDEAL = 1 e CPI non ideale (numero di clock per istruction dovuti
agli stalli: per esempio se avessi 327 stalli su un totale di un milione di cicli di clock questo numero
vale 327/1.000.000):
Il CPIUNP, che vale tra 4 e 5, lo approssimiamo con la profondità del pipeline, ovvero col numero di
stage, che è 5.
Questa formula è stata ricavata per un caso particolare: pipeline bilanciato.
Il pipeline produce un aumento del throughput: incrementa il numero di istruzioni eseguite
nell’unità di tempo e questo comporta una diminuzione del tempo medio di esecuzione delle
(*)
74

istruzioni, e questo significa che un programma gira in meno tempo anche se la singola istruzione
non viene eseguita più velocemente.
Control hazard
Abbiamo detto che il control hazard si verifica quando c’è un branch. In questo caso bisogna
stallare il pipeline:
Facendo così ho perso tre cicli di clock: il primo fetch e i due stalli.
Supponiamo che in un programma ci sono il 30% di branch; questo significa che nel 30% dei casi
devo introdurre tre clock di stallo. Applichiamo la formula del pipeline per misurare lo speedup (*):
Speedup = 5/(1 + 3*0.3) ≅ 2.5, cioè ho una penalizzazione delle prestazioni di circa il 50% a causa
dei branch.
Una prima cosa che si può fare per cercare di minimizzare questa penalizzazione è quella di fare
una modifica all’hardware del DLX: il problema dei tre cicli di stallo nasce dal fatto che io conosco
nella fase di MEM l’esito del salto; se io lo conoscessi prima introdurrei meno stalli. Quando potrei
sapere se il salto è preso oppure no? Intanto devo sapere che è un salto e poi pormi il problema se è
preso oppure no. Quindi non posso che farlo nella fase di decode. Nella fase di decode so che ho un
salto, ma nel frattempo potrei calcolare la condizione e l’indirizzo target; questo lo posso fare
soltanto se metto dell’hardware aggiuntivo nella fase di decode:
75

Quindi sposto il calcolo della condizione nella fase di decode e metto un altro ALU per calcolare
l’indirizzo target. A questo punto se io so che è un branch ho già l’esito, ho l’indirizzo target, e
quindi devo introdurre solo un ciclo di clock di stallo: Speedup = 5/(1 + 1*0.3) ≅ 3.9.
Ci sono diversi modi per cercare di ridurre ulteriormente gli stalli.
Predict not taken
Da questo momento l’architettura che consideriamo è l’ultima vista: faccio la detection dello zero e
il calcolo dell’indirizzo target nel secondo ciclo di clock; nel frattempo il fetch che avevo fatto lo
dovrei ripetere, è questo lo stallo; se questo fetch è stato fatto e scopro nel frattempo che questo
fetch è quello giusto, perché il salto non è preso, perché devo rifare il fetch? È come dire che faccio
funzionare il processore come se lui si aspettasse che il salto non venga preso. Per questo si chiama
“predict not taken”, cioè io predico che il salto non sia preso. Se effettivamente il salto non è preso
non si perde nessun ciclo di clock:
Dovessi scoprire nella fase di decode che il salto è preso si deve far propagare una not operation e si
fa il fetch all’indirizzo target:
Abbiamo visto che se io introducessi sempre lo stallo lo speedup sarebbe: Speedup = 5/(1+0.3)≅3.9.
Supponiamo che ho il 30% di branch e scopro che il 50% è taken e il 50% è untaken. Con la tecnica
del predict not taken posso abbattere ulteriormente questo valore, che mi esprime il numero di cicli
di clock di stallo per instruction; in questo caso quando il salto non è preso non ho dei cicli di clock
di stallo, quindi nel 50% del 30% invece devo introdurre uno stallo; quindi il denominatore diventa:
1 + 0.3 × 0.5 × 1. Questo significa che sto migliorando ulteriormente le performance.
Nel data hazard abbiamo scoperto che se riuscivamo a riorganizzare il codice potevamo ridurre il
numero di stalli. È possibile anche nel caso del control hazard ristrutturare il codice per cercare di
diminuire il numero di cicli di clock di stallo da introdurre? La risposta è sì. La tecnica del Delayed
branch (delay slot) dice questo: quando si fa un branch e si è nella sua fase di decode nel frattempo
si fa un fetch di un’altra istruzione; non si può fare in modo che sia sempre un fetch utile anche se
non è il fetch dell’indirizzo target, se il salto è preso? Questo clock che viene subito dopo il branch
si chiama delay slot. Se il salto viene preso verrà preso due colpi di cicli di clock dopo, ma quel
ciclo ci clock intermedio è stato usato per un’istruzione che doveva comunque essere eseguita; il
risultato è che dal pipeline io vedo uscire sempre un’istruzione e non uno stallo.
Supponiamo che abbiamo un’istruzione di branch, di cui conosco l’esito nella fase di decode, se io
(compilatore) ristrutturo il codice in modo che dopo il branch metto un’istruzione che comunque ha
76

senso fare, sia che il salto sia preso sia che il salto non sia preso, ho risolto il problema.
Consideriamo il caso del salto non preso:
Mentre faccio il decode del branch vado a fare il fetch dell’istruzione successiva che può andare
avanti; se il salto è non preso dovrò fare l’istruzione successiva al branch, cioè l’istruzione i+2, che
è quella che seguiva il branch prima della ristrutturazione del codice.
Se il salto invece viene preso non cambia niente:
L’istruzione che segue l’istruzione che il compilatore ha messo subito dopo il branch sarà il branch
target.
Quindi nei due casi io comunque ho eseguito l’istruzione i+1, cioè ho fatto entrare nella pipe
quell’istruzione, che ha fatto sì che non mi ha fatto introdurre nessun ciclo di stallo.
Vediamo quali sono i casi che si possono verificare.
Supponiamo di avere il seguente segmento di codice:
subito dopo il branch (if R2=0 then) c’è un delay slot che sarebbe il ciclo di
clock successivo in cui bisogna decidere quale istruzione fare entrare nel
pipeline. Il compilatore vede che l’istruzione ADD R1,R2,R3 è indipendente
dall’istruzione successiva dato che genera R1 come operando destinazione.
Allora se questa istruzione la metto subito dopo il branch, cioè significa che
ogni volta che eseguo il branch sicuramente eseguo anche questa, cambia
qualcosa nel programma? Cambierebbe qualcosa se a volte la eseguo e a
volte no, ma viene eseguita sempre. Quindi tutte le
volte che il compilatore trova che l’istruzione che precede il branch non
dipende da quest’ultimo la mette subito dopo e quindi ha risolto il problema.
In poche parole inverte il branch con l’istruzione che la precede, e quindi
quello slot di tempo che potrebbe provocare uno stallo, a questo punto non
provoca alcuno stallo, perché tanto vado ad eseguire un’istruzione che
comunque doveva essere eseguita. Quando ho un codice di questo tipo nel
100% dei casi non ho bisogno di introdurre stalli.
Supponiamo di avere il seguente codice:
stavolta non è possibile fare quello fatto sopra perché l’istruzione che
precede il branch produce un risultato che è sorgente nell’istruzione
successiva, quindi di fatto c’è una dipendenza, di conseguenza non posso
mettere l’istruzione ADD R1,R2,R3 dopo il branch perché non saprei come
fare a vedere se R1 è uguale a zero oppure no. Supponiamo che il
compilatore sappia che è molto probabile che il salto venga preso, allora
77

prende l’istruzione che è all’indirizzo target e la mette subito dopo il branch
ricordando che non deve saltare più alla stessa istruzione, ma all’indirizzo
successivo, perché altrimenti verrebbe eseguita due volte per ogni ciclo.
Quindi il compilatore copia quell’istruzione anche dopo il branch, e non la
sposta perché a quell’istruzione posso arrivare anche da altre vie del
programma. Si pone un problema: se il salto non viene preso? Viene
eseguita una SUB R4,R5,R6 che prima non doveva essere eseguita; questo
può provocare problemi perché la SUB modifica R4, e se questo serve dopo è chiaro che questa
cosa non si può fare, ma il compilatore l’ha fatta e quindi il programma non viene eseguito
correttamente. Ma il compilatore sa se può azzardare questa cosa perché conosce il codice. Se per
caso R4 viene utilizzato in seguito il compilatore non può mettere quell’istruzione e mette al suo
posto una not operation (è come se stesse introducendo uno stallo).
Consideriamo il caso duale, cioè quello in cui scommetto sul fatto che il salto non sia preso:
se io ho indicazione per cui il salto non è preso a questo punto il compilatore
prende un’istruzione successiva al branch, che tanto dovrà essere eseguita
visto che il salto non viene preso, e la sposto come istruzione nel delay slot.
Se il salto non viene preso risparmio un ciclo di
clock di stallo; se il salto viene preso prima di
eseguire l’istruzione target eseguo un’istruzione che
non doveva essere eseguita. Anche in questo caso ci
potrebbero essere problemi; ma anche in questo caso
il compilatore ha il codice e quindi sa se questa cosa si può fare oppure no, e
se non si può fare potrebbe andare a scegliere un’istruzione che è innocua
(se c’è), nel senso che non va a modificare nulla di quello che segue
l’istruzione target se il salto viene preso; altrimenti va a mettere una not operation.
Nell’ipotesi in cui il processore deve introdurre uno stallo come si fa?
A sinistra abbiamo il caso in cui ancora
non è stata fatta l’ottimizzazione,
ovvero in cui bisogna introdurre tre
cicli di clock di stallo. Supponiamo che
il branch sia nella fase di decode, e
quindi l’istruzione i+1 sta facendo il
fetch, quello che devo fare è non fare
avanzare la i+1, ma una not operation, e
quindi a questo punto io devo stallare
per un numero di cicli di clock che è
quello richiesto nel nostro caso;
ovviamente non devo far modificare il
PC finché non sa l’esito del branch.
Vediamo in dettaglio:
78

entra il branch nella fase di decode e si fa il fetch dell’istruzione i+1. A questo punto non faccio
l’incremento del PC, blocco l’accesso in memoria e anche la scrittura dell’IR e faccio entrare una
not operation:
A questo punto la not operation si propaga e nello stadio di fetch entra un’altra not operation:
Si ripete lo stesso di prima per un altro ciclo di clock:
A questo punto le cose sono due: il branch o è preso o non è preso; naturalmente questo lo scopro
nello stadio di MEM.
Consideriamo il caso in cui il branch è preso:
naturalmente vado a finire all’istruzione target
79

Se il salto non è preso:
entrerà nello stadio di fetch l’istruzione i+1
80

29/04/2004
Abbiamo già visto che c’è una grande differenza nel trend di crescita delle performance del
processore rispetto alla crescita delle RAM dinamiche. Di seguito sono riportate le performance del
microprocessore, che crescono del 60% circa ogni anno, e che rispetto all’evoluzione delle
prestazioni della RAM dinamica, che vede crescere in modo significativo la densità ma vede
crescere poco la sua performance, c’è una differenza (CPU-DRAM Gap) di circa il 50% per anno:
Da un punto di vista relativo è come se la memoria fosse sempre più lenta rispetto al processore, e
quindi c’è il rischio che questo gap vanifichi i progressi che si possono ottenere nel campo dei
computer. Abbiamo visto che questo problema è stato affrontato ed è stata trovata una soluzione.
Questa soluzione fa leva su due concetti fondamentali:
1. principio di località, temporale e spaziale: quella temporale dice che se sto referenziando un
item nel prossimo futuro esso sarà referenziato con alta probabilità; quella spaziale dice che se
sto referenziando un item è probabile che gli item che sono nella zona verranno refernziati;
2. misure sperimentali.
Questi due concetti hanno di mostrato che nell’80% degli accessi durante l’esecuzione di un
programma, anche molto grosso, si fa riferimento soltanto al 10%-15% del codice. Questa è una
grande scoperta perché a questo punto prendendo i vantaggi che vengono dall’elettronica che dice
che un hardware più piccolo è anche più veloce, possiamo dire che, se riesco a concentrare in questa
piccola memoria questo 10%-15% di codice, sto diminuendo questo gap di performance tra CPU e
memoria. Tutto questo, località più riscontro di tipo tecnologico sulla memoria, porta a pensare di
organizzare il sistema memoria come una gerarchia. In questa organizzazione della gerarchia le
cose stanno come sono mostrate nella seguente figura:
questa gerarchia è costituita da un insieme di livelli, il primo
dei quali (quello più vicino alla CPU) si chiama memoria
Cache, poi abbiamo la Main Memory, poi abbiamo i Dischi,
e poi eventualmente i Tape. Il concetto sostanzialmente è
quello che se io mi metto su un livello della gerarchia, su
questo è come se avessi una finestra di dimensione limitata
sul livello successivo. La cosa fondamentale è che le
informazioni scambiate tra il processore e la cache sono
istruzioni e dati, cioè significa che il processore quando
81

accede alla memoria, e quindi quando accede in cache, lo fa o per andare a leggere un’istruzione o
per andare a leggere, attraverso un’istruzione di load, o per andare a scrivere, attraverso
un’istruzione di store, un dato (word, byte, ecc…). Per quanto riguarda l’informazione che può
essere scambiata tra cache e main memory, abbiamo che l’unità di informazione è il blocco (ha
come dimensione un’insieme di word). Questo significa che nella cache l’organizzazione è a
blocchi, e la dimensione di ognuno di questi è uguale a quella dei blocchi della main memory.
Quando succede che il processore accede in cache e vuole fare riferimento a una word, se questa
non è presente (miss) succede che tutto il blocco che la contiene deve essere rimpiazzato da un
blocco di main memory che contiene quell’informazione. La comunicazione tra memoria e disco è
a pagine.
Il livello più basso della gerarchia è il più ampio dal punto di vista di capacità di memorizzazione,
ma è anche il più lento, mentre man mano che saliamo nella gerarchia le cose si invertono. Se
consideriamo anche i costi abbiamo che man mano che saliamo nella gerarchia anche i costi
salgono.
Se è vero che l’organizzazione nella cache è a blocchi allora significa anche che per accedere a una
word all’interno di un blocco l’indirizzo, sia per quanto riguarda la main memory sia per quanto
riguarda la cache, è fatto nel seguente modo:
Immaginiamo che la main memory organizzi le informazioni nel seguente modo:
×
ognuno di questi è una word, e ognuno di quelli orizzontali è un
blocco; questo significa che per accedere alla word (×) devo
indirizzare il blocco su cui sta la word e poi dire all’interno del
blocco quale word mi interessa. La cache è anch’essa organizzata
in blocchi della stessa dimensione di quelli della main memory:
quando succede un miss, cioè
quando accedendo ad un blocco
della cache il processore sta
andando ad accedere a questa
word, per esempio, e non la trova, quello che avviene è che il
blocco dove il dato cercato dal processore sta rimpiazzerà questo.
Per gestire in questo modo la memoria l’indirizzo ha una parte che
viene chiamata indirizzo di blocco (block address), e una parte che viene chiamata block offset.
L’indirizzo di blocco identifica il blocco, mentre il block offset identifica quale word all’interno del
blocco sto andando a referenziare. Se il blocco è costituito da quattro word, per esempio, il block
offset è costituito da 2 bit.
Per quanto riguarda i parametri che caratterizzano una gerarchia di memoria abbiamo:
• hit rate: frazione di accessi fatti alla cache che hanno portato ad un accesso positivo;
• miss rate: è il complementare dell’hit rate;
• tempo medio di accesso alla memoria (average memory-access time): se io volessi misurare il
tempo medio di accesso al sistema memoria immaginando che all’interno di questo sistema ci
sia una gerarchia costituita da due livelli (cache e main memory), questo è dato dalla formula
Average memory-access time = Hit time + Miss rate × Miss penalty, dove hit time è il tempo di
accesso alla memoria cache;
• miss penalty: è o il numero di cicli di clock o il tempo speso per andare a reperire il blocco
dalla main memory e portarlo nella cache.
Il miss penalty a sua volta può essere visto come somma di due termini:
• tempo di accesso (access time): è il tempo per accedere ad una word nella main memory;
• tempo di trasferimento (transfer time): è il tempo che si impiega per trasferire questo dato
selezionato sulla cache. Questo tempo dipende dalla banda disponibile tra la main memory e la
×
82

cache, ovvero dall’ampiezza del data bus tra main memory e cache; più ampio è il data bus
minore è il transfer time.
Vediamo cosa succede al tempo medio di accesso applicando la formula:
Questi diagrammi sono tracciati per una determinata dimensione di cache. Abbiamo detto che miss
penalty è costituito dalla somma di due contributi: tempo di accesso che è costante, perché la
selezione di un blocco e all’interno di questo una word con l’offset non dipende dalla dimensione
del blocco; tempo di trasferimento che varia linearmente con la dimensione del blocco, a parità di
data bus. Il miss rate presente l’andamento della figura centrale: quando il block size cresce il miss
rate diminuisce perché se è vero il principio di località spaziale quando io accedo e trovo un dato,
siccome è probabile che accederò ai dati sequenziali a quello, significa che probabilmente starò
all’interno dello stesso blocco, e quindi più ampio è il blocco più località spaziale sto catturando;
c’è un punto che si chiama pollution point in cui si inverte la pendenza: all’aumentare la dimensione
del blocco diminuisce il numero di blocchi presenti in cache e quindi si incomincia a penalizzare la
località temporale, rischiando di fare continuamente swap tra main memory e cache. Se applica la
formula Average memory-access time = Hit time + Miss rate × Miss penalty otteniamo l’ultimo
grafico.
Per spiegare la nostra gerarchia di memoria il progettista quando si appresta ad eseguire il progetto
di una gerarchia di memoria deve rispondere a quattro domande:
1. Dove può essere posto nel livello superiore, nel caso nostro nella memoria cache? Questo si
chiama Block placement, ovvero quando io devo portare un blocco di main memory nella
cache, questo blocco dove lo vado a mettere?
2. Quando io processore voglio andare ad accedere ad un’informazione lo faccio attraverso il suo
indirizzo, che corrisponde ad una word nella main memory; come faccio a vedere se
quest’informazione e presente nella cache dato che ho quell’indirizzo che va a referenziare
l’informazione nella main memory? Ovvero come faccio ad utilizzare l’indirizzo del processore
per andare a vedere se il dato cercato sta nella cache? Questo si chiama Block identification.
3. Quando il processore cerca un’informazione in cache e si verifica un miss, bisogna andare a
recuperare il blocco di main memory dove l’informazione risiede e portarlo in cache. Se io
porto un blocco in cache, immaginando che sia sempre piena, quale dei blocchi butto per far
spazio al blocco caricato dalla main memory? Questo problema si chiama Block replacement.
4. Cosa avviene quando c’è una scrittura? Quando il processore deve scrivere e vuole modificare
un dato (in cache), supponendo che lo trova modifica questo dato, e da questo momento in poi
ho una copia che non è più consistente con quello che c’è in main memory. Questo può essere
un problema? Siccome la risposta è sì, quale strategia di scrittura utilizzo (Write strategy)?
Rispondere a queste quattro domande è sufficiente a progettare, se siamo nell’ottica della
progettazione, o a comprendere, se siamo nell’ottica dello studio, un sistema di gerarchia di
memoria.
83

Guardiamo la seguente figura:
in basso abbiamo la main memory dove ognuna delle barrette rappresenta un blocco di
informazione (stiamo considerando 32 blocchi); sopra abbiamo la cache costituita da 8 blocchi. Se
io voglio accedere al blocco 12 della main memory e posizionarlo in cache, in quale degli 8 blocchi
può andare a finire? Ci sono tre strategie possibili:
1. Direct mapped: si prende l’indirizzo di blocco di main memory, in questo caso 12, si fa
l’operazione in modulo col numero di blocchi che ci sono in cache, in questo caso 8, e si piazza
il blocco nel risultato di quest’operazione ⇒ 12 mod 8 = 4. Facendo così scopriamo che i primi
8 blocchi vengono mappati negli 8 blocchi della cache (blocco 0 della main memory nel blocco
0 della cache, blocco 1 nel blocco 1, ecc…); il blocco 8 verrà mappato nel blocco 0 della cache
(8 mod 8 = 0), e così via. Questo significa che dato un blocco di main memory questo può
andare a finire in uno e uno solo posto in cache.
2. Fully associative: quando ho un blocco di main memory e lo voglio piazzare in cache posso
farlo in uno qualunque dei blocchi della cache.
3. Set associative: si divide la memoria cache in un certo numero di insiemi; ciascun insieme
contiene più blocchi. Immaginiamo che la cache fatta da 8 blocchi la suddividiamo in 4 insiemi
contenenti 2 blocchi. Un blocco di main memory può finire in uno e uno solo degli insiemi della
cache; in questo caso l’operazione di modulo si fa con 4, perché tale è il numero di insiemi.
All’interno dell’insieme la strategia è fully associative, nel senso che il blocco lo posso mettere
dove voglio.
Come si fa quando il processore emette un indirizzo a sapere dove in cache potrebbe stare quello
che sta cercando?
Vediamo di risolvere questo problema
nel caso in cui la strategia di placement
sia il direct mapped. Supponiamo che
quella a destra sia la main memory: è
costituita da 32 blocchi ciascuno
costituito da 4 word. Supponiamo che la
cache sia fatta da 8 blocchi. I blocchi 0,
8, 16 e 24 vanno a finire nel blocco 0
della cache; quindi nel blocco 0 della
cache potrebbero alloggiare 4 blocchi
della main memory in base a questa
84

strategia di placement. Lo stesso discorso si fa per i blocchi 7, 15, 23 e 31 della main memory che
vanno a finire nel blocco 7 della cache. Lo stesso vale per tutti gli altri blocchi: ciascun blocco della
cache può potenzialmente ospitare 1 su 4 possibili blocchi di main memory. Il processore può
accedere ad una word che ha un suo indirizzo; quest’indirizzo abbiamo visto che viene splittato in
due campi: block address e block offset. Come si fa a partire da quest’indirizzo a sapere dove
cercare all’interno della cache se quel dato è presente oppure no? Supponiamo che il dato che sta
cercando il processore sta nel blocco 0 della main memory; in base alla strategia di mapping
sappiamo che dobbiamo andare a cercare nel blocco 0 della cache. Supponiamo che vogliamo
leggere la seconda word, e quindi andiamo a leggere la seconda word del blocco 0 della cache. In
cache c’è il blocco 0 o il blocco 8, oppure gli altri blocchi possibili?
Quindi ho bisogno nella cache di aggiungere dell’informazione che non sia soltanto l’informazione
che dalla main memory ho portato sulla cache, ma devo ricordare quel blocco a quale blocco di
main memory si riferisce. Questa informazione aggiuntiva è quello che viene chiamato tag. Nel
nostro caso siccome ogni blocco della cache può provenire da 4 diverse alternative di main memory
per il campo tag basteranno solo 2 bit. La caratteristica dei 4 blocchi di main memory è che hanno
soltanto i due bit più significativi dell’indirizzo di blocco che si differenziano; questi due bit sono
quelli che costituiranno il tag di quel blocco nella cache. Questo significa che pago un prezzo
perché non è vero che la cache è soltanto la copia di un pezzo di main memory, ma devo aggiungere
dell’informazione che non sarebbe necessaria se usassi solo la main memory.
L’indirizzo del processore, nel caso in cui il suo sistema di memoria è quello che abbiamo visto,
come lo utilizziamo per andare ad identificare l’informazione all’interno della cache?
Supponiamo di avere uno spazio d’indirizzamento che ha 32 blocchi, ciascuno con 4 word e di
conseguenza con 128 word totali. Immaginiamo di avere un processore che in totale possa
indirizzare 128 word. Questo significa che il campo degli indirizzi del processore deve essere di 7
bit:
sappiamo che, se c’è una cache di 8 blocchi, e se abbiamo ogni
blocco di dimensione 4 word, due bit servono per il block offset,
e verranno utilizzati quando andrò in cache per andare a
selezionare la word interessata se trovo il blocco cercato, due bit
mi servono per il tag, e tre bit che servono per identificare il
blocco della cache dove dovrebbe essere il dato. Una volta
selezionato il blocco della cache grazie al campo index vengono
confrontati i due bit di tag (della cache e dell’indirizzo) per
vedere se sono uguali, e se è così vuol dire che ho trovato l’informazione trovata, altrimenti c’è un
miss.
Proviamo a rispondere alla terza domanda: quale blocco sostituire quando c’è un miss?
Tipicamente si fa riferimento a due strategie: random e LRU (less recent used).
Quando c’è un miss e si va in main memory a prendere un blocco non è detto che si può scegliere.
Nel caso direct mapped la politica di sostituzione è imposta: l’unico posto dove il blocco può andare
a finire è quello che si deve liberare, perché non c’è alcuna scelta. Il problema si pone su quelle
strategie di placement che lasciano libertà: set associative o fully associative.
LRU è la politica che dice: in base al concetto di località temporale se c’è un blocco presente in
cache e non lo si usa da un sacco di tempo, più tempo passa e meno probabilmente vi si accederà;
questo significa che laddove c’è libertà se il mio blocco può andare a finire all’interno di un set
verrà scartato il blocco meno recentemente utilizzato.
La politica random dice: se si può scegliere tra più possibilità il blocco da sostituire verrà scelto in
maniera random.
Si può vedere che se si considera la strategia set associative a due vie (cioè con due blocchi
all’interno del set) la LRU presenta un miss rate del 5,18%, mentre se si utilizza una politica
random il miss rate peggiora a 5,69% (per una cache di 16 KB); la stessa cosa si nota anche
85

all’aumentare dell’associatività. La cosa che si può osservare è che man mano che aumenta la
dimensione della cache la differenza dei miss rate tra le due politiche si attenua:
Quindi per cache di dimensioni adeguate le due politiche danno risultati simili, di conseguenza si
sceglie quella più economica, ovvero quella random. Se dovessi implementare la LRU dovrei, in
ogni blocco della cache, non solo avere il campo tag, ma anche un qualcosa che mi segna l’età del
blocco, e quindi un overhead nella ricerca del blocco da sostituire.
L’ultima domanda è quella legata al write.
Il processore deve scrivere (store) e supponiamo che ci sia un hit (trova in cache la word da
modificare); abbiamo detto che facendo questa operazione di scrittura stiamo violando la
consistenza tra le due copie, quella in cache e quella in main memory; questo potrebbe essere un
problema. Per risolvere questo problema la tecnica più semplice a cui si può pensare è: tutte le volte
che si scrive in cache si va a scrivere anche sulla main memory (write through); questo significa
che il processore scrive in cache, e contemporaneamente il cache controller utilizza l’indirizzo
fornito dal processore per andare a scrivere quel dato sulla copia che c’è in main memory.
Ovviamente facendo così tutte le volte che c’è una scrittura penalizzo il processore perché devo
aspettare di finire la scrittura sulla main memory che è più lenta. In questo caso si risolve il
problema attraverso di un write buffer: il processore scrive in cache e contemporaneamente il dato
viene copiato nel write buffer (buffer fatto di un certo insieme di blocchi o di word), fatto questo il
processore può andare avanti, e poi il cache controller si occupa di copiare quello che c’è nel write
buffer sulla main memory, sgravando il processore da questo compito.
La write through, in generale nei sistemi, mi mantiene la consistenza tra le due copie, ma accede
spesso alla main memory, il che significa consumare banda disponibile sulla main memory che oltre
dal processore può essere acceduta anche da altri dispositivi (per esempio il DMA).
L’altra politica di scrittura quando si verifica un hit è quella che viene chiamata write back: quando
si deve effettuare un’operazione di scrittura si scrive solo nella cache, non interessandoci della
consistenza; non aggiornando il dato nella main memory può succedere che se c’è un miss prendo
un blocco della cache e lo butto, e se su quel blocco erano avvenute delle scritture, tutti gli
aggiornamenti non presenti in main memory li ho persi; quindi la write back così semplicemente
non può funzionare. Allora quello che si fa è che tutte le volte che si deve buttare un blocco, prima
di buttarlo si deve andare a copiare sulla main memory. Ovviamente si può migliorare il tutto
pensando che non si deve fare sempre: non è detto che il blocco che butto è stato modificato e
quindi non è necessario copiarlo sulla main memory. Per fare questo è necessario aggiungere
un’informazione sulla cache, ovvero un bit che dice se il blocco è stato modificato oppure no;
questo bit tipicamente si chiama clean or dirty. Questo significa che il cache controller si deve
preoccupare quando c’è un replacement di copiarlo oppure no sulla main memory.
Pro e contro delle due tecniche:
• non succede mai che un miss in lettura, quando utilizzo una politica write through, provoca una
scrittura in main memory, perché la main memory è sempre aggiornata;
• nel caso di write back un miss in lettura può implicare una scrittura sulla main memory;
86

• i vantaggi del write back sono: se su un blocco in cache ho fatto molte scritture quando questo
viene sostituito si riflette in una sola scrittura sulla main memory, cioè consuma pochissima
banda.
Vediamo come funziona il write through:
quando il processore scrive in cache, il dato
viene copiato anche nel write buffer, il
quale essendo un piccolo buffer fa sì che la
scrittura può avvenire alla stessa velocità
della scrittura sulla cache; dopodiché il
write buffer viene scaricato nella main
memory. Naturalmente il write buffer diventa una struttura FIFO, e il problema del progettista del
sistema memoria è di quanto deve essere lungo il write buffer: c’è un servente che svuota il buffer
con la velocità tipica di come una scrittura può avvenire sulla DRAM, e c’è un produttore che
riempie il buffer potenzialmente con la velocità del processore, quindi se il buffer è pieno bisogna
far aspettare il processore per un tempo pari alla scrittura di un intero blocco sulla main memory.
Per fortuna la frequenza delle scritture normalmente in un programma è abbastanza bassa rispetto
alle letture.
Se devo fare un’operazione di write e c’è un miss che cosa dovrebbe succedere normalmente? Si
prende il blocco dalla main memory, lo si porta in cache e poi si scrive. Se si segue questa logica si
dice che si sta utilizzando una politica di write allocate. Si può anche seguire un’altra tecnica:
write not allocate. Questa tecnica fa riferimento ad un’osservazione di tipo pratico: siccome le
scritture hanno una bassa frequenza (si verificano raramente), è vero che se si verifica un miss si
dovrebbe prendere il blocco portalo in cache e scriverlo, ma questo miss si è verificato su una
scrittura, allora forse questo dato che è stato modificato può darsi che non verrà utilizzato per tanto
tempo; questo potrebbe giustificare l’idea che quando si presenta una scrittura si va a modificare
soltanto l’informazione sulla main memory (non si pone il problema di modificarlo in cache perché
non c’è, si è verificato un miss) e non si alloca il blocco sulla cache; in questo caso si scommette sul
fatto che probabilmente quel blocco nel prossimo futuro non sarà acceduto.
Vediamo come un blocco viene identificato in cache:
in alto abbiamo l’indirizzo di
CPU; quando la CPU emette
l’indirizzo non dice quale parte è
il campo tag, quale l’index e quale
l’offset, perché non sa come sarà
fatta la cache, ma è il cache
controller che attribuisce il
significato ai campi dell’indirizzo.
Con l’index il cache controller
seleziona dove dovrebbe stare
l’informazione che sta cercando il
processore. Si vede che sono state
separate la parte della cache che
contiene il tag e la parte della
cache che contiene i dati, però
questo è stato fatto mettendoli in corrispondenza: la parola 0 del chip dei tag contiene i bit per il
blocco 0, ecc. L’offset serve a selezionare la word all’interno del blocco selezionato. Attraverso
l’index viene selezionato oltre al blocco anche il suo tag (ci dice quale blocco di main memory, dei
possibili, è presente nella cache) che deve essere uguale al campo tag dell’indirizzo del processore
per verificarsi un hit; di conseguenza c’è un comparatore, e a seconda se c’è un hit o un miss il dato
87

selezionato che proviene dalla cache passa e va a finire alla CPU. Se le due parti della cache fossero
unite sequenzialerei il confronto del tag e il prelevamento del blocco: prima faccio il confronto e poi
se il blocco è quello giusto vuol dire che devo leggere i dati (indirizzo la word); questo significa che
si peggiorano le performance in termini di tempo di accesso alla cache.
88

06/05/2004
Esempio: fully associative.
Non ci sono regole sul placement, quindi potenzialmente il blocco cercato può stare in qualunque
punto della cache. Come faccio a dire dove può stare una cosa che cerca il processore? Se la
scansione è sequenziale, la fully associative promette una performance migliore della direct mapped
e inoltre il miss rate migliora. Perché? Nella direct mapped non ho alcuna scelta di dove mettere il
blocco e quindi se ho un miss devo buttare il blocco dove andrà a finire quello preso dalla main
memory: ci sono dei conflitti, o ci sta uno oppure un altro. Nella fully associative questo problema
non c’è, potrei decidere di allocare quattro blocchi e potrei metterli tutti e quattro in cache. Come
faccio la fase di ricerca del blocco? Se la faccio sequenziale devo fare tanti accessi. Alternativa: la
faccio in parallelo.
Il campo index si è ridotto, il campo tag si allarga (perché qualunque blocco della main memory
può finire in qualunque punto della cache ⇒ ho bisogno di maggiore informazione per sapere dove
è finito).
Organizzo la cache come parte dati e parte tag:
A livello hardware è difficile farlo; inoltre si spende tempo. Ne segue che la fully associative si può
parallelizzare, però costa in termini economici e di tempo. Ciò nonostante la fully associative non
viene esclusa del tutto. Non si può fare una scelta a priori. Bisogna vedere quale programma deve
girare su quella macchina.
Set associative cache
Poiché l’index individua il set devo procedere in parallelo per vedere quale tra i blocchi del set è
quello che contiene l’informazione che voglio. Suppongo di avere una cache associativa a due vie
(ogni insieme ha due blocchi). Il numero di vie significa quanti blocchi ci sono dentro un insieme, il
campo index mi dice dove cercare in cache e il campo tag mi dice quello che c’è dentro la cache
(quale blocco è). La cache viene divisa in due parti: in una mettiamo i blocchi 0 di tutti i set,
nell’altra i blocchi 1 di tutti i set (un set quindi è in orizzontale).
Ogni blocco di dati ha
associato il corrispondente tag.
Seleziono entrambi i blocchi e
in parallelo accedo anche ai
tag di quei blocchi, li
confronto, quindi li mando in
un comparatore che farà uscire
1 o 0 a seconda che il blocco è
presente oppure no. C’è un
multiplexer (il dato può
arrivare da una delle due vie), che seleziona il blocco che ha dato l’hit; l’hit tramite l’OR ci dice se
il blocco è presente oppure no.
89

2-way Set Associative, address to select word
Qui le due vie sono una sull’altra:
confronto con due comparatori diversi i
tag; se uno dei due confronti è vero,
tramite il multiplexer preleverò il dato
da ricercare e lo porterò in CPU.
Questo multiplexer che non è presente
nella direct mapped introduce un ritardo
e questo può dare problemi e portare
alla necessità di dilatazione del clock
della CPU. Questa dilatazione può far sì
che la direct mapped, che ha un miss
rate più alto, ma non ha questo
multiplexer, potrebbe avere un TCPU più
piccolo di quello della set associativa.
Quindi il miss rate più elevato non
sempre significa avere TCPU più alti.
Il dato è disponibile solo dopo che sono
terminati tutti i confronti. Nel caso del
direct mapped il dato può uscire in
parallelo al compare perché non deve
attraversare il multiplexer ⇒ si anticipa
la fornitura del dato al processore ⇒ la direct mapped è più semplice ⇒ è più veloce della set
associativa.
All’aumentare dell’associatività aumenta la complessità, quindi aumentano dimensione e latenza.
Riepilogando gli svantaggi di una set associativa rispetto ad una direct mapped sono:
• abbiamo bisogno di N comparatori rispetto ad uno;
• maggiori ritardi dovuti al multiplexer;
• il dato arriva dopo l’Hit/Miss decision e la selezione del set; ne segue che la velocità di accesso
al dato da parte del processore è penalizzata (oltretutto per considerare un dato sicuro è
necessario che il processore lo possieda per un certo tempo).
Structural hazard
Nel caso di gerarchia di memoria è preferibile, dal punto di vista del miss rate, una cache unificata o
separata?
Usare una cache unificata per dati e istruzioni può essere non conveniente. Come abbiamo visto una
memoria unificata presenta un hazard strutturale con le load/store. Un modo per risolvere il
problema è dividere la cache in cache dati e cache istruzioni. La CPU sa se l’indirizzo riguarda dati
o istruzioni. La cache separata ci permette di ottimizzare separatamente ogni singola cache:
differenti capacità, dimensioni dei blocchi, associatività.
La seguente tabella mostra i vari miss rate per i vari tipi di cache:
poiché i valori sono riferiti alla cache
unificata bisogna confrontare i dati
nell’instruction cache e data cache di 16k con
quelli della cache unificata di 32k.
90

Per calcolare il miss rate medio della cache separata dobbiamo conoscere la percentuale di accesso
in memoria per i due tipi di cache.
Con cache separate raddoppia l’hardware, replico i segnali di controllo, ecc… I miss sui dati e sulle
istruzioni non avvengono contemporaneamente. Se le unisco avrei un miss rate più basso di quello
dei dati, ma più alto di quello delle istruzioni, ne segue che devo separale, altrimenti tutte le volte
che accedo in memoria perdo un colpo di clock.
Cache performance
Vediamo come valutare l’impatto che ha la gerarchia di memoria sul CPU time. Il nostro obiettivo è
ottimizzare la performance dal punto di vista della CPU.
CPU time = (CPU execution clock cycles + Memory stall clock cycles) × clock cycle time
Memory stall clock cycles = Memory accesses × Miss rate × Miss penalty
(In questa formula il miss penalty deve essere espresso in cicli di clock)
CPU time = Ic × (CPIexecution + Mem accesses per instruction × Miss rate × Miss penalty) × Clock
cycle time
Supponiamo di dimezzare il periodo di clock:
• Ic non varia
• CPIexecution, non varia perché è in termini di numero di cicli di clock e non in termini di
frequenza
• Mem. accesses per instruction, non varia (a parità di programma) perché dipende dal benchmark
che è lo stesso per entrambe le versioni
• Miss rate, non varia perché è la frazione di volte in cui non trova il dato rispetto agli accessi
totali
• Miss penalty, varia perché in questa formula è misurato in cicli di clock.
In particolare il miss penalty raddoppia perché raddoppia il numero di cicli per raggiungere il
ritardo introdotto dalla main memory.
Importantissimo:
CPUtime = Ic × (CPIexecution + Misses per instruction × Miss penalty) × Clock cycle time
Se dimezziamo la frequenza del ciclo di clock: CPIexecution non varia perché dipende dal numero di
cicli di clock, il numero di miss non varia perché dipende dal benchmark, il miss penalty (è espresso
in cicli di clock) raddoppia perché è un numero diviso il periodo, perciò si avrebbe:
new CPU time = Ic× CPIexecution × T/2 + Ic × miss per instruction × 2 miss penalty × T/2
Il secondo addendo rimane invariato, il primo si dimezza ma se il contributo del CPI non era elevato
non è cambiato molto! Se diminuisco il numero di cicli di clock varia il CPI ma non gli altri
elementi. Il CPU time migliora (ma di poco perché il secondo addendo è predominante rispetto al
primo). Il secondo addendo infatti non varia perché il miss penalty raddoppia e il periodo di clock si
dimezza.
91

Esercizio
.data
vett: .space 20
msg_input: .asciiz “\nNum?”
msg_output: .asciiz “\nN: %d”
.align 2
arg_printf .word msg_output
num: .space 4
.text
.global main
main:
addi r2,r0,0
addi r5,r0,5
loop_input:
addi r1,r0,msg_input
jal InputUnsigned
slei r7,r1,7
andi r8,r1,1
or r9,r7,r8
beqz r9,falso
sw vett(r2),r1
addi r2,r2,4
falso:
subi r5,r5,1
bnez r5,loop_input
srli r10,r2,2
addi r2,r0,0
loop_output:
beqz r10,fine
lw r11,vett(r2)
sw num,r11
addi r14,r0,arg_printf
trap 5
subi r10,r10,1
addi r2,r2,4
j loop_output
fine: trap 0
Cicli di clock totali = 356
Ic = 224
FCK = 1 GHz
1) Caso ideale (dati presi dal DLX): TCPU = Ncicli_totali × TCK = 356 × 1 ns =356 ns
CPI = Ncicli_totali / Ic = 356/224 = 1,59
11/05/2004
92

2) Cache unificate: cache da 1k, blocco da 16 byte, associatività 2 e miss penalty pari a 30 cicli di
clock. Col dinero ottengo Nmiss = 450
TCPU = (Ncicli_totali + Nload/store + Nmiss × miss penalty) × TCK = (356+65+450×30) × 1 ns = 1,39 µs
CPI = (Ncicli_totali + Nload/store + Nmiss × miss penalty)/Ic = 13921/224 = 62,1
3) Cache separate: cache dati da 1k, blocco della cache dei dati da 32 byte, associatività 4 della
cache dei dati e miss_penalty_dati pari a 30 cicli di clock; cache delle istruzioni da 2k, blocco
della cache delle istruzioni da 32 byte, associatività 4 della cache delle istruzioni e
miss_penalty_istru pari a 40 cicli di clock. Col dinero ottengo: Nmiss_dati = 17 e Nmiss_istr = 114
TCPU=(Ncicli_totali+Nmiss_dati×miss_penalty_dati+Nmiss_istr×miss_penalty_istr)×TCK=
=(356+17×30+114×40) × 1 ns = 5,43 µs
CPI = (Ncicli_totali + Nload/store + Nmiss × miss penalty)/Ic = 5426/224 = 24,22
93

Esempi su come calcolare lo speedup.
Esempio
Tv
Tn
CT
1 h 4 h
CT Roma
1 h 2 h
Calcoliamo lo SE e la FE :
FE = 4/5
SE = 4/2
Speedup = 1/(1- FE + FE / SE) = 5/3
13/05/2004
Esempio:
ponendoci nel caso visto la scorsa lezione con le cache unificate, calcolare lo Speedup complessivo
qualora la miss penalty della cache unificata diventi 15 cicli.
FE = (450 • 30 • TCK)/[(356 + 65 + 450 • 30) • TCK] = 13500/13921 = 0,97
SE = (450 • 30 • TCK)/(450 • 15 • TCK) = 2
Speedup = 1/(1 - FE + FE / SE) = 1,94
Esempio
Calcolare lo speedup ottenuto qualora si faccia una modifica che abbia come effetto il ridurre a 1/3
il numero di miss nella cache dei dati (caso cache separate dell’esercizio della scorsa lezione).
TCPU
Roma
TCPU
FI
FI
(356 + 65 + 450×30) × TCK
TCPU_ideale hazard strutturali (load/store) Nmiss • miss penalty
(356 + 17 × 30 + 114 × 40) × TCK
TCPU_ideale Nmiss_dati • miss_penalty_dati Nmiss_istr • miss_penalty_istr
FE = (17 • 30 • TCK)/[(356 + 17 • 30 + 114 • 40) • TCK] = 13500/13921 = 0,09
SE = (17 • 30 • TCK)/(17/3 • 30 • TCK) = 3
Speedup = 1/(1 - FE + FE / SE) = 1,05
Utilizzando dinero, che è un cache simulator, abbiamo visto come è possibile andare a vedere come
variano le performance della gerarchia di memoria al variare dei vari parametri della gerarchia
stessa. Questi parametri quali potrebbero essere? Se io ho una cache organizzata con un certo
numero di blocchi, che cosa succede per esempio al miss rate, o all’average memory-access time, se
faccio variare la dimensione del blocco a parità di dimensione di cache? Oppure ho una cache direct
mapped di una certa dimensione, che cosa succede a parità di dimensione se la faccio diventare set
associative a 2 vie, oppure a 4 vie? In poche parole che cosa succede se aumento il livello di
associatività?
Ci sono delle tecniche che posso individuare per migliorare il miss rate, il miss penalty e l’hit time?
Ricordiamo che l’average memory-access time è dato dalla somma dell’hit time e del prodotto di
miss rate e miss penalty. È ovvio che per migliorare l’average memory-access time, quindi per
diminuire il tempo di accesso, posso intervenire cercando di abbassare l’hit time, oppure posso
94

intervenire sul miss rate o sul miss penalty, perché abbassando uno o l’altro il prodotto miss rate per
miss penalty diminuisce.
Proviamo a vedere quali tecniche promettono di ridurre il miss rate.
A questo punto bisogna parlare delle origini dei misses: quando voglio inventare una tecnica per
cercare di migliorare le prestazioni, mi devo chiedere perché si verificano i misses. Sono state
identificate tre cause che possono produrre un miss; queste cause vanno sotto il nome delle 3 C:
• Compulsory: è chiamato anche cold start misses. Quando per la prima volta si va a
referenziare un item, questo potrebbe benissimo non essere in cache; questo succede perché
sfruttiamo il principio di località, e quindi diciamo che se accediamo a qualcosa, nel caso della
località spaziale, sicuramente gli item vicini hanno un’alta probabilità di essere acceduti; ma la
prima volta che si accede a qualcosa e che non era vicino a qualcos’altro probabilmente ancora
in cache non c’è.
• Capacity: i misses dovuti a questa causa sono spiegabili col principio di località; se ho una
cache da 4k avrò un miss rate legato a questa capacità; se utilizzo una cache da 256k piuttosto
che da 4k significa che posso mettervi dentro molti più blocchi di main memory, e quindi la
probabilità di miss diminuisce.
• Conflict: è legato al conflitto che si va a generare su certi tipi di organizzazioni di cache; per la
direct mapped abbiamo visto che ci sono blocchi di main memory che vanno a finire sullo stesso
blocco di cache. Questa competizione genera un conflitto perché nel caso in cui un programma
va ad accedere a blocchi in conflitto tra di loro ogni volta solo uno di questi può stare in cache.
Questo fenomeno si attenua man mano che aumenta l’associatività, perché se c’è un conflitto a
livello di blocchi e non di set, all’interno di un set di una set associativa abbiamo più alternative
di dove piazzare un singolo blocco; questo significa che ho una minore competitività tra i
blocchi e questo significa anche che laddove due blocchi acceduti da un programma dovessero
finire sullo stesso set non avrei problemi di conflitto. Aumentando l’associatività il problema
diventa sempre minore perché il conflitto diminuisce e quindi significa che i misses legati a
questo problema diminuiscono.
Per quanto riguarda queste tre cause abbiamo un diagramma che riporta al variare della dimensione
della cache il miss rate:
riportiamo il miss rate facendo
variare all’interno della cache
l’associatività (partiamo da
una direct mapped (1-way) e
arriviamo ad una set
associativa a 8 vie). La fully
associativa è quella che
elimina ogni tipo di conflitto.
Abbiamo visto anche che per
una fully associativa gestire
l’hardware è complicato. Si è
dimostrato che il
miglioramento è significativo
in termini di conflitto man
mano che si passa da una
direct mapped verso la fully
associativa. Andando oltre le 8 vie si vede che non si ha più nessun tipo di miglioramento, e questo
si vede al solito con l’approccio basato su misure, ovvero si vede che con moltissimi programmi
con una set associativa a 8 vie di fatto non ci sono più quasi completamente conflitti. Questo
significa che una memoria pienamente associativa non ha motivo di esistere, ma al massimo si
arriverà ad una set associativa a 8 vie.
95

Nel grafico si vedono le varie componenti di miss. La linea in rosso rappresenta il compulsory miss:
si vede che al variare della dimensione della cache i misses legati al compulsory restano costanti;
questo succede perché il compulsory non dipende dalla dimensione della cache, ma è legato al fatto
che quando si va a referenziare per la prima volta qualcosa in cache si ha un miss.
Un’altra componente è quella relativa al coflict miss: le strisce di colore diverso fanno vedere cosa
sommo in termini di misses legati ai conflitti alla curva legata alla memoria set associativa a 8 vie;
spostandoci verso la direct mapped il miss rate aumenta. Tutta la striscia compresa tra la direct
mapped e la set associativa a 8 vie (colori: blu, giallo, viola e azzurro) è quella legata ai conflitti.
La striscia in verde è quella legata al capacity miss. Ovviamente tutte le curve assumono un
andamento decrescente all’aumentare della dimensione della cache.
Vediamo una regola pratica:
consideriamo per esempio una cache da 4k organizzata in modo direct mapped; su questa
sperimentiamo un determinato miss rate.
Ma se aumentassimo l’associatività per
caso lo stesso miss rate lo potremmo
sperimentare con una cache più piccola?
La risposta è sì: se consideriamo la set
associativa a 2 vie abbiamo una cache di
dimensione circa 2k. Questo significa
che il miss rate che ottengo con una
cache direct mapped di 4k è pari al miss
rate che ottengo con una cache di 2k
organizzata in modo set associativo a 2
vie.
A questo punto cominciamo a vedere quali tecniche possiamo inventarci per ridurre il miss rate,
sapendo che quest’ultimo è dovuto alle tre cause viste sopra.
Poniamoci delle domande:
• se a parità di dimensione della cache faccio variare la dimensione del blocco, qualcuna delle tre
cause è influenzata?
• se io cambio l’associatività quale delle tre cause è coinvolta?
• se agisco a livello di compilatore quale delle tre cause è influenzata?
Cominciamo con la prima tecnica: variamo la dimensione dei blocchi.
Abbiamo 5 casi, corrispondenti
a 5 dimensioni di cache.
Osserviamo che c’è una fase
iniziale, comune a tutte e 5 le
curve, in cui all’aumentare della
dimensione del blocco
diminuisce il miss rate.
Aumentare la dimensione dei
blocchi provoca il fatto che
dentro ognuno di essi ci entrano
più informazioni; questo
significa che la componente di
miss che probabilmente
miglioro è il compulsary: se io
ho un cold start miss e
trasferisco sulla cache un blocco
grande è probabile che anche gli altri item che non sono stati referenziati li trovo in cache proprio in
96

virtù del principio di località, e quindi per questi item non avrò un cold start miss. Tutto questo è
vero fino ad un certo punto, perché tutto va relazionato alla dimensione della cache: se continuo a
far crescere la dimensione del blocco il risultato è che all’interno della cache avrò pochissimi
blocchi per cui comincia il problema del conflict miss.
Siamo sicuri che riducendo il miss rate gli altri due componenti, hit time e miss penalty, non
peggiorino? La cosa che peggiora sicuramente è il miss penalty: fare un blocco più ampio significa
che quando c’è un miss aumenta la quantità di informazione che si deve trasferire dalla main
memory alla cache, e quindi aumenta il miss penalty.
La seconda tecnica per diminuire il miss rate è quella di aumentare l’associatività. Se aumento
l’associatività diminuiscono i conflict miss. Però all’aumentare dell’associatività peggiora l’hit
time: in una set associativa ci deve essere un multiplexer tra cache e CPU, quindi mi trovo una
latenza che sperimento nella maggior parte delle volte (tutte le volte che c’è un hit quel multiplexer
deve essere attraversato).
Osserviamo la seguente tabella: vediamo come varia l’average memory-access time (A.M.A.T.) al
variare della dimensione della cache e al variare dell’associatività. Per una cache da 1k
all’aumentare dell’associatività il
tempo medio di accesso alla cache
diminuisce perché diminuisce il
conflict miss. Tutto questo è vero
finché non arriviamo ad una cache
da 8k dove si vede che passando da
una direct mapped ad una set
associativa a 2 vie peggiora
l’A.M.A.T. perché peggiora l’hit
time (questo è legato al periodo di
clock del processore che si allunga
passando da direct mapped a set
associativa a 2 vie, a 4 vie, ecc…).
si vede che a partire da una cache
da 16k aumentare l’associatività
non porta alcun beneficio.
La seguente tecnica è una tecnica che segna un punto di svolta rispetto alle tecniche precedenti,
perché fa migliorare il miss rate senza intervenire né sull’hit time né sul miss penalty.
Questa tecnica si chiama Victim cache (cache vittima). Ho la mia cache (tag e dati); quando ho un
miss devo sostituire un blocco il che implica
prendere questo blocco e portarlo in main memory e
quello giusto dalla main memory lo porto in cache.
Qualcuno ha pensato: il blocco che tolgo piuttosto
che portarlo in main memory lo lascio vicino alla
cache, perché se era in cache vuol dire che era stato
acceduto, e se lo si toglie può essere causa di miss.
Allora si organizza una piccola memoria fully
associativa da associare alla cache in modo tale che
quando si scarta un blocco dalla cache lo piazzo in
questa cache fully associativa piuttosto che nella
main memory. Questo significa che adesso quando
si ha un miss piuttosto che andare in main memory a
cercare il blocco prima si va a vedere se si trova in
questa cache fatta da pochi blocchi.
Jouppi, che è quello che un po’ ha inventato questa
memoria vittima, ha dimostrato che con una
97

memoria associativa con soltanto 4 entry, cioè con solo 4 blocchi, organizzata in maniera fully
associativa, si rimuoveva dal 20% al 95% dei conflitti di una cache direct mapped da 4KB. Questa
tecnica è stata utilizzata concretamente in macchine reali.
La quarta tecnica è quella che si chiama pseudo-associativa. Abbiamo già visto che in una
memoria set associativa, per esempio a 2 vie, abbiamo bisogno di un multiplexer e di fare in
parallelo i due confronti dei tag; tutto questo fa si che il tempo di accesso a quella memoria sia più
lungo che un accesso ad una memoria direct mapped; d’altra parte è anche vero che la set
associativa a 2 vie ha meno conflitti. Quindi a me piacerebbe avere il tempo di accesso di una direct
mapped e i conflitti di una set associativa. Organizzo una memoria associativa a 2 vie, ma il cache
controller la gestisce come se fosse direct mapped. Quando si va ad individuare il set attraverso
l’index, ma nel set ci sono due blocchi (se è associativa a 2 vie) e di conseguenza viene fatto un
confronto dei tag in parallelo; allora diamo una sorta di default: si va a cercare sempre il primo dei
due blocchi, così è come se si facesse sempre un accesso diretto. Quello che può succedere è che se
ci va bene risparmiamo tempo, mentre se ci va male dobbiamo andare a controllare l’altro blocco.
Sicuramente beneficiamo di una riduzione dei miss legati ai conflitti, sicuramente il tempo medio
legato di accesso è più basso, però c’è un problema: se ci va bene impieghiamo un tempo, mentre se
ci va male impieghiamo un tempo un po’ più lungo.
Questa tecnica ci tornerà utile piuttosto che come cache di primo livello, ma come cache di secondo
livello, dove il processore non accede direttamente.
Un’altra tecnica utilizzata per la riduzione del miss rate è quella che si chiama hardware
prefetching. Se c’è un miss significa che si deve andare nella main memory per prendere un blocco
e portarlo in cache; siccome c’è sempre il principio di località forse anche il blocco successivo di
main memory potrebbe servire; naturalmente non lo prendo per andare a rimpiazzare un blocco che
già c’è in cache, però faccio un prefetching: il blocco su cui c’è stato un miss lo alloco in cache,
mentre il blocco successivo lo vado a mettere in uno stream buffer, che è un buffer piccolo e veloce
che sta vicino alla cache, così è pronto per essere acceduto. Allora quello che si fa è che se c’è un
miss prima di andare in main memory si va a vedere se nello stream buffer c’è qualcosa che ci
interessa. Jouppi ha dimostrato che un data stream buffer si riusciva a catturare il 25% di miss da
una cache di 4KB; con 16 streams fino al 72% dei miss. Il prefetching va a diminuire la banda della
main memory.
L’ultima tecnica è quella che riguarda il compilatore. Abbiamo già visto per esempio nel caso del
pipeline come il compilatore ci può aiutare a ridurre il data hazard ristrutturando il codice. Per
quanto riguarda la località si può fare qualcosa col compilatore? Consideriamo il caso dei dati: un
array se si potesse portare tutto in cache non avrei problemi; ma se l’array è di una certa dimensione
non si riesce a portarlo tutto in cache; ma se io accedo a righe successive e l’array nella main
memory è memorizzato per colonne caricando le colonne commetterei una sciocchezza perché gli
elementi contigui non sono le colonne. Questo significa che c’è un’incompatibilità tra come è
memorizzato l’array e come sarebbe meglio memorizzarlo per cercare la località. Allora il compito
del compilatore è ristrutturare il codice in modo tale che invece che fare l’accesso per righe
successive lo si fa per colonne.
Nella figura accanto è riportato cosa si ottiene
quando il compilatore adotta alcune tecniche
per ottimizzare la località. Si vede come il
perfomance improvement man mano che si
utilizzano diverse tecniche può essere di 1,5-
2,5. E questo è legato solo al compilatore.
98

18/05/2004
Abbiamo visto che l’average memory-access time è dato dalla somma di due contributi: hit time e
prodotto tra miss rate e miss penalty. È chiaro che ridurre l’hit time, il miss rate, e il miss penalty
sono tutti e tre obiettivi nobilissimi, ma non sempre si riesce a ridurne uno senza andare a
influenzarne un altro.
Passiamo alle tecniche per la riduzione del miss penalty.
La prima tecnica è quella che parla del read priority over write on miss. Supponiamo che
utilizziamo una cache con politica di scrittura write through, ovvero quando si fa una scrittura in
cache si scrive anche in main memory, e per evitare di penalizzare il processore a causa della
lentezza di quest’ultima si interpone tra cache e main memory un write buffer; ci sono dei casi in
cui le cose si complicano: c’è un miss in lettura, supponiamo, e quello che dovrebbe accadere è che
il cache controller va in main memory individua il blocco cercato e lo va a piazzare in cache; ma
siamo sicuri che il blocco che va a prendere in main memory e porta in cache è aggiornato?
Potrebbe essere non aggiornato perché magari l’aggiornamento sta ancora nel write buffer e non c’è
stato ancora il tempo di andarlo a copiare sulla main memory. A questo punto se si volesse usare
una politica di tipo conservativo dovrebbe succedere che tutte le volte che c’è un read miss prima di
andare in main memory e prendere il blocco da portare in cache si aspetta che si svuoti tutto il write
buffer; se il write buffer è a quattro posizioni significa che ogni volta che c’è un miss in lettura, che
sono i miss più frequenti dato che le letture sono più frequenti delle scritture, sperimento un miss
penalty che è molto più lungo di quello che sarebbe richiesto se andassi direttamente in main
memory. Per abbassare il miss penalty piuttosto che aspettare di svuotare il write buffer si potrebbe
andare a vedere se c’è conflitto tra il blocco che devo portare in cache dalla main memory e i
blocchi che sono presenti nel write buffer; conflitto significa che il blocco che sto cercando è
presente all’interno del write buffer. La tecnica nominata su ci dice di dare la priorità alle letture
sulle scritture: se c’è quel tipo di conflitto è inevitabile che si deve aspettare di svuotare il write
buffer, mentre se il conflitto non c’è prima di svuotare il write buffer vado ad asservire il read miss,
cioè vado in main memory prendo il blocco e lo porto in cache.
Adesso supponiamo di avere una cache con politica di scrittura write back; quando c’è un miss in
lettura bisogna andare a caricare un blocco dalla main memory e scartarne uno dalla cache; il blocco
scartato dalla cache ha un bit (clean or dirty) attraverso il quale si sa se copiare questo blocco in
main memory per aggiornarlo oppure no. In questo caso se c’è un read miss si scarica tutto il blocco
dalla cache su un write buffer e si fa avanzare il read miss, cioè si dà la priorità alla lettura sulla
scrittura.
La seconda tecnica si chiama subblock placement. Una componente del miss penalty è legata al
tempo di trasferimento delle informazioni del blocco dalla main memory alla cache, e questo
significa che se ho un bus da 32 bit e ho un blocco di 4 word da 32 bit devo fare quattro
trasferimenti. Allora si potrebbe pensare di fare blocchi di dimensione più piccola, però questo
significa che a parità di dimensione di cache aumenta il numero di tag; questo potrebbe non essere
un problema se la cache fosse esterna al processore, ma visto che normalmente c’è un pezzo di
cache integrate nel processore sprecare spazio per i tag potrebbe essere troppo oneroso. Per cui si
cerca di coniugare queste due esigenze (da un lato avere blocchi di piccola dimensione per
diminuire il miss penalty e dall’altro evitare che ci siano troppi bit per i tag) e per questo è nata la
tecnica del subblock placement: ogni blocco della cache (direct mapped) viene diviso in
sottoblocchi, per esempio nel nostro caso in 4
sottoblocchi, e a tutto il blocco viene associato
un unico tag. Facciamo un esempio in lettura:
se accedo ad un’informazione, in parallelo
confronto il tag e accedo alla word; per ognuna
delle word c’è un bit associato, che viene
chiamato bit di validità; se questo bit è 1 e il
confronto dei tag è corretto vuol dire che la
99

word è quella cercata e quindi non si verifica un miss; se il bit di validità è 0 vuol dire che la word
non è valida e quindi c’è un miss; in quest’ultimo caso si accede alla main memory si trasferisce
soltanto il sottoblocco interessato (tipicamente ha la dimensione di una word) e quindi il transfer
time tra main memory a cache è limitato soltanto ad un sottoblocco e di conseguenza sto abbattendo
il miss penalty. Nel caso in cui il confronto dei tag non dà esito positivo vuol dire che c’è un miss;
in questo caso si va in main memory si trasferisce la word cercata e contemporaneamente si cambia
il tag mettendo quello corretto, e si mettono a 0 tutti gli altri bit di validità che eventualmente sono
messi a 1.
La terza tecnica è la seguente: quando ho un miss, in generale, prendo un blocco dalla main
memory lo porto in cache e poi il processore può accedere alla word cercata; per esempio se
abbiamo blocchi di 8 word e il processore sta accedendo alla word 5, quando c’è il miss il
processore deve aspettare che il blocco venga trasferito tutto in cache; in alternativa si potrebbe
pensare: il blocco viene trasferito word dopo word, o a gruppi di word a seconda del parallelismo
tra main memory e cache, e non appena la word cercata è stata copiata in cache il processore vi può
accedere e il cache controller può continuare a copiare il resto del blocco. Questo comporta un
abbassamento del miss penalty. Questa tecnica è quella che viene chiamata Early Restart.
Qualcuno ha detto un’altra cosa ancora: se c’è un miss su una word, perché non si fa in modo che la
prima word del blocco che si deve trasferire non è proprio quella che sta cercando il processore?
Facendo così si trasferisce la prima word, il processore la legge e poi il cache controller continua a
trasferire l’intero blocco dalla main memory. Fare questo significa complicare l’hardware del cache
controller perché deve essere in grado di fare non sempre la stessa operazione, ma l’algoritmo di
trasferimento dipende dalla word cercata. C’è un problema: data la word al processore il cache
controller deve poi continuare a trasferire il resto del blocco nella cache, però questo lo fa alla
velocità della main memory, e quindi se è vero che esiste il principio di località spaziale è probabile
che la prossima word a cui accederà il processore sarà la word vicina a quella per cui c’è stato il
miss, ma questa word non è ancora in cache; quindi probabilmente da un lato diminuisce il miss
penalty, ma dall’altro sto aumentando il miss rate.
Un’altra tecnica è quella di organizzare la cache a più livelli. Il progettista normalmente si trova
davanti ad un dilemma: avere cache molto veloci (di conseguenza piccole), ma grandi per avere un
basso miss rate.
Dalla figura accanto si vede come
all’aumentare della dimensione della cache
aumenti significativamente il tempo di accesso
alla cache.
Quindi dal punto di vista della velocità sarei
portato a scegliere cache piccole perché sono
più veloci, ma cache piccole significa elevato
miss rate. Tra l’altro cache piccole significa che
le posso anche integrare all’interno del
processore, e questo implica che sono ancora
più veloci, perché la maggior parte del tempo
su un accesso in memoria si perde nella latenza
che riguarda la comunicazione esterna tra
processore e memoria.
Qualcuno ha pensato di potere raggiungere entrambi gli obiettivi: sia cache veloci che cache grandi.
Come? Organizzando la cache a due livelli: metto una piccola cache, che è quella che si interfaccia
direttamente al processore (o esterna o interna al processore, e in quest’ultimo caso organizzata in
modo direct mapped, che è la più veloce in assoluto), e tra questa piccola cache e la main memory
interpongo un altro livello di cache. Quest’ultima cattura molti dei miss generati dalla piccola cache
e quindi il miss penalty che pago è quello del trasferimento del blocco dal secondo livello di cache
100

al primo, che essendo una RAM statica mi fa sperimentare un miss penalty più basso di quello che
si sperimenta trasferendo un blocco dalla main memory, che è una RAM dinamica.
Siamo sicuri che questa combinazione tra queste due cache effettivamente abbia un average
memory-access time più basso che una singola cache magari più grande e meno veloce? Siamo
sicuri che il miss rate complessivo sia più basso del miss rate che sperimenterei in una cache a
livello unico?
Facciamo dei conti: (L1 = livello 1, che è quello più vicino al processore; L2 = livello 2)
AMAT = Hit TimeL1 + Miss RateL1 × Miss PenaltyL1
Miss PenaltyL1 = Hit TimeL2 + Miss RateL2 × Miss PenaltyL2
Sostituendo otteniamo:
AMAT = Hit TimeL1 + Miss RateL1 × (Hit TimeL2 + Miss RateL2 × Miss PenaltyL2)
In questo caso si definiscono un local miss rate e un global miss rate:
• il local miss rate è la frazione di accessi che producono un miss diviso il numero di accessi a
quello stesso livello di cache. In poche parole il miss rate di livello 2, che sarebbe il local miss
rate per la cache di livello 2, è dato dal numero di accessi al livello 2 che generano un miss
diviso il numero di accessi totali al livello 2. Gli accessi totali al livello 2 non sono tutti gli
accessi del processore, ma sono solo quegli accessi del processore che hanno generato un miss
sul livello 1. Il local miss rate nel livello 1 si definisce sempre allo stesso modo, però questa
volta il numero di accessi a questo livello è il numero totale di accessi che genera il processore;
• il global miss rate per un certo livello di cache è il rapporto tra il numero di miss che si
sperimentano in quel livello diviso il numero totale di accessi in memoria generati dal
processore. Nel caso della cache di livello 1 il local miss rate e il global miss rate coincidono;
nel caso della cache di livello 2 questi due sono completamente diversi, e in particolare il global
miss rate è dato dal prodotto Miss RateL1 × Miss RateL2.
Se io vado a considerare il local miss rate della cache di livello 2, mi aspetto che questo sia elevato,
perché siccome è il rapporto tra il numero di miss sul livello 2 e il numero di accessi sulla cache di
livello 2, questi ultimi vengono scremati dalla cache di livello 1, quindi anche se ci sono pochi miss,
questi diviso un basso numero di accessi mi dà un miss rate che può essere elevato.
Siamo sicuri che miss rate nella cache a due livelli sia confrontabile con quello nella cache a un solo
livello? A noi potrebbe andare bene che sia uguale, perché migliorando il miss penalty ci sto già
guadagnando.
Nel seguente grafico viene riportato il local miss rate del livello 2, che è intorno al 70% e poi va a
scendere, e poi è riportato il confronto tra il global miss rate del livello 2 e il miss rate della cache a
un unico livello della stessa dimensione:
si assume che la cache di livello 1 sia di 32k, e si fa variare
la dimensione della cache di livello 2. Si vede che il local
miss rate fino a quando la dimensione della cache di
secondo livello è minore di 32k è elevatissimo;
all’aumentare della dimensione della cache di secondo
livello il local miss rate diminuisce, però mantenendosi
sempre a livelli di 15%-18%.
Guardando il global miss rate si vede che, fino a quando la
cache di secondo livello è più piccola o uguale alla cache
di primo livello, questo è maggiore del miss rate della
cache ad un solo livello, il che significa che ci stiamo
perdendo. Aumentando la dimensione della cache di
secondo livello il global miss rate diventa praticamente
uguale al miss rate del caso di cache ad un solo livello. Da
256k in su le due curve coincidono.
101

Questi grafici dimostrano che la scommessa di tentare di fare una cache a due livelli si può vincere,
perché in realtà se la cache di secondo livello si fa sufficientemente grande i miss rate sono
confrontabili, e quello che ci guadagno è il miss penalty più basso, e anche il fatto che potendo
integrare il primo livello all’interno del processore posso avere un clock cycle time più veloce.
Il fatto di aver organizzato la cache a due livelli mi dà una maggiore libertà sulle tecniche di
ottimizzazione per ridurre il miss rate che io posso implementare sulla cache di secondo livello.
L’aumento dell’associatività sappiamo che riduce il miss rate, ma fa peggiorare l’hit time. Se io
faccio una cache con un’elevata associatività e questa è la prima cache che vede il processore , il
fatto che peggiora l’hit time significa far andare più lento il processore. Se io però ho un secondo
livello di cache posso organizzare il primo livello come direct mapped, e per il secondo livello
posso incrementare l’associatività per diminuire il miss rate, o le altre tecniche di cui abbiamo
parlato la scorsa lezione, senza impattare negativamente sul processore. Quindi molte delle tecniche
che abbiamo studiato che potrebbero non andare bene per una cache ad un unico livello,
incominciano a trovare applicazione per una cache a due livelli.
Vediamo alcune cose sulla riduzione dell’hit time.
La prima cosa che consente di ridurre l’hit time è quella di fare cache semplici (direct mapped) e
piccole.
Adesso vediamo una tecnica che si propone l’hit time in scrittura. Quando accedo in cache per una
lettura posso fare in parallelo il confronto del tag e l’accesso al dato, mentre se ho l’operazione di
scrittura questo parallelismo non è possibile, perché se io confronto il tag e contemporaneamente
scrivo, se il confronto del tag mi ha dà esito negativo modificherei qualcosa che non avrei dovuto.
Questo vuol dire che mentre un hit per un’operazione di lettura potrebbe richiedere un ciclo di
clock, un write dovrebbe chiederne due. Qualcuno si è inventato un pipeline write: quando si deve
scrivere si organizzano le scritture in pipeline. Come? Supponiamo di avere un dato da scrivere in
cache; utilizziamo un ciclo di clock per vedere se c’è un hit oppure no; in questo ciclo di clock oltre
a fare quest’operazione di ricerca del tag verrà messo il dato da scrivere insieme all’indirizzo che
serve per scrivere in cache in un buffer che si chiama
Delayed Write Buffer. Quando scriverò quello che c’è nel
write buffer in cache? Non appena c’è la prossima scrittura
confronto il tag e in parallelo svuoto il write buffer in
cache (nella parte dati; questa scrittura non è relativa a
questo tag, ma a quello precedente) e il dato da scrivere in
questa scrittura si copia nel delayed write buffer. Lo stesso
si fa per le scritture successive.
Se io accedo in cache in lettura e il dato che mi serve è
quello che si trova ancora nel delayed write buffer leggerei
un dato inconsistente. Quindi non solo devo organizzare
questo pipelining, ma devo anche curarmi tutte le volte che
c’è un miss il lettura di andare a vedere se quello che sto cercando è nel write buffer che ancora non
è stato scaricato. Nella figura si vede che tag e dati sono separati; c’è il delayed write buffer dove si
va a scrivere solo se c’è un hit; c’è un multiplexer all’ingresso della cache perché vi si può accedere
o normalmente o attraverso il delayed write buffer.
L’organizzazione a sottoblocchi della cache si presta a implementare un tecnica per migliorare l’hit
time in scrittura. Confronto il tag e in parallelo scrivo; si possono verificare tre casi:
• Se il bit di validità era 0 significa che ho scritto su qualcosa che non era valido; se il tag era
quello giusto avrei dovuto scrivere proprio in quel punto, e quindi l’unica cosa da fare è mettere
il bit di validità a 1.
• Se il bit di validità era 1 e il tag era quello giusto non devo neppure modificare il bit di validità.
• Il tag non è quello giusto; quello che faccio è scrivere il tag del dato che ho scritto in cache e
metto a 0 tutti i bit di validità che sono a 1.
Il risultato è che riesco a fare una scrittura ogni ciclo di clock.
102

Guardiamo un quadro sinottico utile a rivedere tutto quello che abbiamo fatto per quanto riguarda
le tecniche di ottimizzazione. Abbiamo quattro colonne: miss rate, miss penalty, hit time,
complessità: + (migliora), – (peggiora)
Main memory performance
Nella formula dell’AMAT compare il miss penalty che dipende dall’access time alla main memory
e dal transfer time tra main memory e cache. Posso usare qualche trucco per organizzare la main
memory in modo tale che il miss penalty diminuisca? Si possono fare alcune cose.
Ci sono tre soluzioni:
La prima soluzione (a) è quella banale: abbiamo il processore, un bus della dimensione della word
della CPU, poi c’è la cache che è organizzata a blocchi e ha parallelismo di una word (significa che
con un accesso esce una word, e un blocco significa che occupa più word consecutive), poi un bus
sempre di dimensione di una word e infine la main memory organizzata a blocchi come la cache.
Con questa organizzazione cosa succede quando c’è un miss? Tutto il blocco della cache va
sostituito e quindi si devono fare tanti accessi quante sono le word del blocco (dato che il bus è
grande quanto una word). Quindi sperimento un miss penalty legato a tutti questi tempi di accesso e
tempi di trasferimento.
Un’organizzazione che mi riduca questo miss penalty è la (b): organizzo la cache e la main memory
in modo da aumentare il loro parallelismo, cioè tutta una locazione di main memory e di cache
coincide con un intero blocco, e poi si fa il bus di dimensione pari a tutto il blocco (se è fatto da 4
word da 32 bit il bus deve essere da 128 bit). In questo caso quando c’è un miss faccio un accesso
solo alla main memory; quindi abbasso il miss penalty perché il tempo di accesso lo pago solo una
volta e lo stesso per il tempo di trasferimento. Il problema di questa organizzazione è la
103

ealizzazione del bus. Pago un altro prezzo: quando il processore accede alla cache lo fa per leggere
o per scrivere una word; se la cache adesso ha un parallelismo maggiore di una word quando vi
accedo escono tutte le word della locazione, quindi devo selezionare la word che mi interessa
attraverso un multiplexer. Facendo così peggioro l’hit time che è il caso più frequente, e quindi il
miglioramento del miss penalty potrebbe essere vanificato.
La terza tecnica (c) è quella del memory interleaving: piuttosto che organizzare un bus grande
quanto quello della seconda tecnica, lo facciamo della dimensione di una word, e il parallelismo
della cache anch’esso di una word; facendo così togliamo il multiplexer. Organizzo la main
memory in banchi fisicamente separati; ogni banco ha un parallelismo di una word (ogni blocco ha
una word su ogni banco). Quando si deve selezionare un blocco si deve mandare l’indirizzo di
questo blocco a tutti i banchi della main memory, e questo lo faccio in parallelo; questo significa
che con un solo accesso ottengo quattro word (se ho 4 banchi); quindi il tempo di accesso lo pago
solo una volta, mentre il tempo di trasferimento lo pago 4 volte perché il bus è di una word.
Esempio:
supponiamo che per indirizzare la memoria ci voglia 1 ciclo di clock, 6 cicli per accedere (cioè il
tempo di accesso è di 6 cicli di clock), e 1 ciclo per trasferire il dato; supponiamo che il blocco della
cache sia formata da 4 word. Vediamo nei tre casi cosa succede:
a) miss penalty = 4 × (1 + 6 + 1) = 32 cicli di clock
b) miss penalty = 1 + 6 + 1 = 8 cicli di clock
c) miss penalty = 1 + 6 + 4 × 1 = 11 cicli di clock.
104

25/04/2004
Riduzione del miss rate
L’obiettivo è ridurre il tempo medio di accesso alla memoria che, considerando una gerarchia di
memoria con un solo livello (CPU, cache e main memory), possiamo esprimere con la seguente
formula: AMAT = Hit time + Miss rate × Miss penalty.
Abbiamo visto che una tecnica di riduzione del miss rate è quella di fare i blocchi più grandi.
Un’altra tecnica è quella di utilizzare cache con un più alto grado di associatività. Lo svantaggio di
utilizzare questa tecnica è quello che aumenta l’hit time. Supponiamo di avere il processore che
emette un indirizzo che viene partizionato in un campo offset (spiazzamento della parola all’interno
del blocco), un campo index (che indirizza il set della cache in cui è contenuto il blocco che
contiene la word che stiamo cercando) e un campo tag (permette di stabilire se sul blocco che
abbiamo individuato è effettivamente mappata la parola che stiamo cercando). Consideriamo una
tag index ofs
addr
µP
cache direct mapped. Di solito realmente
abbiamo due banchi suddivisi: banco dei
1 W tag e il banco che contiene i dati. Con
index indirizziamo entrambi i banchi che
tags Block
emettono in uscita tag e blocco; il tag lo
confrontiamo con un comparatore col tag
che viene fuori dall’indirizzo e questo
. .
confronto ci dice se c’è un hit o meno. Il
blocco è composto da N word, in
generale, invece il processore non richiede
blocchi ma word, quindi c’è un
MUX multiplexer che estrae dal blocco la parola
tag Block
che il processore richiede, e questo lo fa
attraverso il campo ofs.
Hit
?
N
Aumentiamo il grado di associatività (per esempio a due vie) di questa cache: ho un altro banco per
addr
tag index ofs µP
?
?
tags block
. .
tags block
MUX
Block
. . MUX
1 W
N
i tag e un altro banco per i
blocchi. Tutti i blocchi 0 di
tutti i set sono mappati nel
primo banco dei dati e tutti
i blocchi 1 sono mappati
nell’altro banco; lo stesso
vale per i tag. Con l’indice
indirizzo parallelamente
sia il banco 0 sia il banco
1, e ognuno dei banchi
risponderà con i tag e i
blocchi. Parallelamente
confronto i tag: uno dei
due restituirà un hit oppure
entrambi un miss; ho una
logica che in base a come
rispondono i due
comparatori mi dà il
105

segnale di selezione del multiplexer che mi fa passare il blocco 0 o il blocco 1. A questo punto ho il
blocco che contiene la word che il processore vuole leggere, e poi un multiplexer mi seleziona la
word interessata. Il multiplexer in più rispetto alla direct mapped fa sì che l’hit time aumenti. Più
aumenta il numero di vie più ingressi ha il multiplexer e di conseguenza più lento è. (N.B. Anche se
ho più comparatori non aumenta l’hit time perché questi lavorano in parallelo).
Un’altra tecnica per ridurre il miss rate (senza effetti collaterali) è quella che utilizza le cache
vittime. Un’altra tecnica che abbiamo visto è quella che fa uso delle cache pseudo-associative.
Esistono altre tecniche per la riduzione del miss rate:
• il prefetching delle istruzioni e/o dei dati (hardware prefetching);
• il prefetching controllato dal compilatore;
(entrambe hanno bisogno di un supporto hardware)
• le ottimizzazioni di compilazione, che non richiedono modifiche hardware:
♦ Merging Arrays;
♦ Loop Interchange;
♦ Loop Fusion;
♦ Blocking.
Hardware Prefetching
Accanto alla cache abbiamo un altro buffer di memoria che può ospitare anche un solo blocco e
funziona nel seguente modo: quando c’è un miss devo caricare un blocco dalla memoria alla cache;
invece che caricare un solo blocco, carico quel blocco, ma ne carico anche un altro che non
memorizzo in cache ma in quel buffer; questo lo faccio per sfruttare la località spaziale.
Vediamo i vantaggi che si possono avere.
Per l’Alpha 21064 con 8 KB di instruction cache, per un benchmark si è sperimentato un miss rate
= 1.10%. Supponiamo di utilizzare un hardware di prefetching. Il miss rate in questo buffer di
prefetch supponiamo sia del 25% (di solito questi sono i valori per un buffer di prefetch che
contiene solo una word). Supponiamo che l’hit time sia di 2 cicli di clock. Supponiamo anche che
quando ho un miss, ma trovo il dato nel buffer di prefetch, sperimento un ciclo di clock.
Consideriamo che il miss penalty sia di 50 cicli di clock.
Calcoliamo l’AMAT:
AMAT = Hit time + (se lo trovo in cache)
Miss rate × Prefetch hit rate × 1 + (se abbiamo un miss però abbiamo un hit sul buffer di prefetch)
Miss rate × (1 – Prefetch hit rate) × Miss penalty= (se un miss anche nel buffer di prefetch)
= 2.415
Se guardiamo il sistema da un punto di vista di più alto non sappiamo che il sistema diciamo che:
AMAT = Hit time + Miss rate × Miss penalty.
Vogliamo paragonare il miss rate di una macchina senza prefetching con una con prefetching; se
sostituiamo i numeri otteniamo:
Effective Miss rate = (AMAT – Hit time)/Miss penalty =0.83%; questo è il miss rate osservato
dall’utente finale a cui non interessa se è un miss dovuto al fatto che non è stato trovato in cache o
nel buffer di prefetch. Quindi abbiamo ottenuto una notevole riduzione del miss rate (da 1,1% a
0.83%). Questo valore è quello che si sarebbe ottenuto se si fosse utilizzata una cache di 16 KB
senza buffer di prefetch (utilizzando sempre lo stesso benchmark).
Compiler-Controlled Prefetching
Un’altra tecnica è quella di arricchire l’instruction set di un’istruzione nuova, che chiamiamo
istruzione di prefetch, in cui noi forziamo il cache controller a prendere un blocco dalla memoria,
anche se non ci sono stati miss, e metterlo in cache. Supponiamo che il nostro instruction set
disponga di istruzioni di questo tipo, che consentono quindi il controllo software dei dati in cache;
supponiamo anche che questa operazione possa essere fatta senza bloccare la cache: mentre
106

abbiamo il dato che si sta spostando dalla memoria alla cache, quest’ultima, che è dotata di più
porte, può continuare a fornire il processore di istruzioni e di dati.
Consideriamo un cache di 8 KB direct mapped, con blocchi di 16 byte. Questo di seguito è un
frammento di codice C: abbiamo due matrici a e b di double (8 byte)
double a[3][100], b[101][3];
...
for(i=0;i

prefetch(b[j+7][0]);
prefetch(a[0][j+7]);
a[0][j]= b[j][0]*b[j+1][0];
}
for(i=1;i

Il numero di cicli di clock nel caso di prefetch è il seguente:
Quindi abbiamo che il codice con le istruzioni di prefetch è 14650/3400 = 4,3 volte più veloce.
Entrambe le tecniche che abbiamo visto sono ottimizzazioni del miss rate che determinano una
modifica dell’hardware o dell’instruction set. Vediamo adesso una tecnica di ottimizzazione del
miss rate che modifica l’hardware, ma modifica soltanto il software. Queste ottimizzazioni possono
agire sia sulla parte del codice sia sulla parte dei dati del programma. Nella parte di codice il linker
può ordinare le funzioni del nostro programma in modo tale che non creino conflitti; per esempio se
ho un ciclo for che chiama due funzioni, il linker può pensare di fare in modo che queste due
funzioni siano allocate in locazioni di memoria in modo tale che vengono mappate nella cache in
zone che non creino tra loro conflitti. Ovviamente il compilatore deve essere conscio dell’hardware
che c’è sotto.
Merging Arrays
Questa tecnica migliora la località spaziale. Molto spesso abbiamo degli array a cui accediamo nello
stesso momento, con gli stessi indici, e hanno la stessa dimensione. Consideriamo il seguente
programma:
int val[SIZE];
int key[SIZE];
for(i=0;i

for(i=0;i

molto probabilmente lo avremo in cache perché l’abbiamo utilizzato nell’istruzione precedente, e lo
stesso vale per c[i][j].
Blocking
Con questa tecnica viene modificato l’algoritmo per ridurre il numero di miss. Questa tecnica
migliora la località temporale.
Se abbiamo un algoritmo che opera su una struttura dati grossa, l’algoritmo viene diviso in tanti
piccoli algoritmi che operano su zone piccole della struttura dati. Per esempio il seguente codice fa
il prodotto di due matrici:
for (i=0; i