1.
Descrizione CPU
Figura
1 Diagramma a blocchi dell'Athlon
Gli
elementi principali che compongono la CPU Athlon sono illustrati
dallo schema a blocchi riportato. Si possono notare la cache
L1 da 128 KB separata per Istruzioni e Dati, il blocco di fetch
e decode, la Instruction Control Unit (ICU) a 72 ingressi ,
i due scheduler indipendenti per numeri interi e floating point,
le 6 unità per interi (3 Integer Executive Unit (IEU) e 3 Addres
Generation Unit (AGU)) e le 3 unità per floating point (Fadd,
Fmul e Fstore) che fanno dell' Athlon il primo processore x86
superscalare a 9 vie, la Load/Store Unit (LSU), la Bus Interface
Unit (BIU) e il controller per la cache L2 esterna.
Le
tre unità floating point costituiscono una FPU che agisce alla
stregua di un coprocessore matematico con un proprio controllo
del out-of-order (in aggiunta naturalmente a quello del processore)
deputato a tutte le operazioni per istruzioni x87, MMX e 3DNow!.
2. Fetch e Decode
Come altri processori x86 moderni l’Athlon prende le
istruzioni x86 di lunghezza variabile (da 1 a 15 bytes) e deve
tradurle in istruzioni semplici, chiamate OPs e che nel K6 erano
chiamate Rops, che saranno trattate dalle unità di esecuzione.
Le istruzioni x86 sono per prima cosa esaminate nella cache
per determinarne la lunghezza e la natura (ad esempio se prevedono
branch) e le informazioni relative immagazzinate nella precoded
cache che supporterà l’allineamento a 16 byte delle istruzioni
e le operazioni di branch prediction.
Durante
la fase di FETCH 16 bytes sono prelevati dalla
cache istruzioni e successivamente nello stadio di SCAN
della pipeline il quale ha il compito di discernere quali istruzioni
x86 sono abbastanza "semplici" da poter essere decodificate
via hardware, come fanno i processori RISC, e quali necessitano
invece di una decodifica, più lenta, mediante sequenze di microcodice.
Quindi
all’uscita dallo stadio di Scan si hanno per le istruzioni x86
due percorsi alternativi: il Direct Path
Decoder per la decodifica hardware e il Vector Path Decoder.
Nel primo, tramite 3 buffer da 8 byte in coda, si possono immagazzinare
fino a 24 bytes di istruzioni che durante lo stadio di ALIGN1
sono sufficienti ad essere inviati come tre istruzioni x86 (mediamente
lunghe 2.5 bytes) allo stadio ALIGN2 che ne
completa l’allineamento e le invia a 3 decoder paralleli (stadio
EDEC o early decode) che ne ricava 3 MacroOPs
(MOPs) e esegue altre operazioni come aggiornamento dei flag,
determina i puntatori ai registri ect. Le MOPs sono istruzioni
di lunghezza fissata contenenti un gruppo di OPs in genere due.
Nel
Vector Path Decoder invece a uno
stadio MECTL (Microcode Engine Control) che
predispone le istruzioni all’ingresso di una microcode ROM segue
lo stadio MEROM durante il quale ad ogni istruzione
x86 viene associata la corretta sequenza di microcodice. Nello
stadio successivo MEDEC le linee di microcodice
sono tradotte in un massimo di 3 MOPs. Nello stadio successivo
IDEC le MOPs sono riordinate in ordine di programma con le MOPs
del Direct Path Decoder e passate alla ICU in numero di 3 a
ciclo.
Questa
suddivisione di istruzioni x86 in MOPs consente una gestione
migliore rispetto a quella "asimmetrica" del Pentium che poteva
avere stalli in caso di particolari sequenze di istruzioni complesse
che non potevano essere decodificate dai decoder semplici (che
si occupavano ad esempio di operazioni registro-registro) rendendo
quasi irraggiungibile il limite di 6 microistruzioni per ciclo
al Reorder Buffer del Pentium III. Questa capacità dell’Athlon
di decodificare 3 istruzioni per ciclo viene messa in crisi
per istruzioni complesse denominate "vector" inerenti soprattutto
a operazioni particolarmente complesse (e rare) operanti su
dati di tipo diverso come ad esempio operazioni FPU con operandi
interi.
Come
vedremo successivamente la pipeline del Athlon è di 10 stadi,
per gli interi, e quindi un predizione errata dei branch potrebbe
essere assai dannosa. Per assolvere alla predizione delle diramazioni
l’Athlon si avvale di una Branch History Table (BHT) a 4096
ingressi con algoritmo di predizione a due soli bit (da confrontarsi
con il BHT a 8192 ingressi del K6 ritenuto adesso evidentemente
sovradimensionato), con un Branch Target Buffer (BTB) a 2048
ingressi per immagazzinare gli indirizzi predetti di un branch
e infine il return stack address (RAS) a 12 ingressi (contro
i 16 del K6) che riesce a predire correttamente gli indirizzi
di ritorno delle procedure che vengono chiamate, in successione,
da locazioni differenti; ciò incrementa notevolmente i benefici
dei loop (sequenze CALL / RET) contenenti chiamate a funzioni.
Contrariamente
al caso del K6 la predizione è fatta nel secondo stadio della
pipeline (stadio di Scan) anziché nel primo (stadio di Fetch)
dove invece avviene l’accesso alla BHT. La predizione è quindi
mandata al fetch stage per dirigere il fetch nel ciclo successivo
quindi per predizioni corrette si ha un solo ciclo di attesa.
In caso di predizione errata invece si incorre in un minimo
di 10 cicli di penalità ma AMD assicura che il livello di predizione
è assolutamente analogo a quello del K6 (circa 95%) e comunque
una predizione più sofisticata avrebbe comportato una complicazione
eccessiva.
LITHIUM.IT, tutta la tecnologia della rete .
