Newsgroup: it.comp.hardware.cpu
Titolo: EPIC (Explicitly Parallel Instruction Computing)

EPIC è alla base della famiglia di processori Itanium. EPIC è stata
originariamente sviluppata nei laboratori HP. L'architettura EPIC permette
di superare le limitazioni dell'architettura RISC. Questa architettura
consente al compilatore di trarre vantaggio dalla esecuzione parallela
superando i limiti dei contemporanei processori RISC out-of-order(OOO).
L'obbiettivo principale dell'architettura EPIC è quella di muovere la
complessità hardware dei processori RISC out-of-order al compilatore. Questo
non significa  che l'hardware dei processori EPIC sia semplice. Certamente i
primi processori RISC erano molto più semplici. La differenza stà nel fatto
che gli attuali processori RISC OOO sono molto più complessi che i RISC
originali. Per aumentare il numero di istruzioni eseguite per colpo di clock
(IPC) è necessario incrementare la complessità in modo esponenziale, con dei
limiti ben precisi: difficilmente un processore non-EPIC può eseguire più di
4 istruzioni per colpo di clock, mentre EPIC permette già di eseguire 6
operazioni alla volta, con possibilità di aumentare questo valore nelle
evoluzioni successive. Questo si nota già nelle eccezionali prestazioni
dell' Itanium 2 nonostante funzioni "solo" ad 1 Ghz.
Una delle caratteristiche di EPIC è quello di possedere un numero enorme di
registri integer (ben 128). Questo numero enorme di registri è vantaggioso
nelle chiamate alle procedure. Se i parametri della chiamata (o delle
chiamate) non superano le dimensioni dei registri stacked (che sono ben 96)
tutto viene eseguito all'interno del processore, senza accesso alla cache o
alla memoria esterna. Questo procedimento è particolarmente utile nei
linguaggi di programmazione moderni Object-Orient, che necessitano di
frequenti chiamate alle procedure. Un'altra caratteristica di EPIC è di
avere anche 128 registri float (di qui 32 fixed e 96 rotating).
Come già detto l'attuale implementazione di EPIC (Itanium 2) permette di
eseguire fino a 6 operazioni (2 bundles) per colpo di clock. Nessuno vieta
però di implementare versioni semplificate o più complicate
dell'architettura EPIC. Ad esempio si può costruire una CPU che esegue 3
operazioni (1 bundles) per colpo di clock, come si può realizzare una CPU
che esegue 9 (3 bundles) o 12 (4 bundles) operazioni per colpo di clock. Un
bundles (lungo 128 bits) è l'insieme di 3 istruzioni che l'architettura EPIC
è in grado di elaborare. Una cosa interessante è che a differenza di
implementazioni precedenti di CPU VLIW(Very Long Instruction Word), EPIC non
necessita di ricompilazione se si cambia CPU. L'architettura EPIC permette
di stabilire indipendentemente dalla CPU il numero di operazioni massime che
possono essere eseguite contemporaneamente, senza limiti. Una caratteristica
principale di EPIC è l'operazione "stop": tutte le operazioni contenute tra
due stop vengono chiamate "gruppo di instruzioni", in quanto queste
istruzioni sono eseguibili contemporaneamente perchè sono libere da
interdipendenze. Il codice eseguibile generato dai compilatori EPIC è in
media più lungo di quello di altre CPU RISC, ma non di molto. Saluti.

 media più lungo di quello di altre CPU RISC, ma non di molto. Saluti.
Cosi` come il codice RISC e` piu` lungo di quello CISC.
Il problema, suppongo, sia nel fatto che se
non si e` in grado di mettere 6 istruzioni in
parallelo, bisogna comunque riempire gli slot
con NOP, rendendo sempre il codice a 6 istruzioni.
Di conseguenza la lunghezza del codice aumenta.
bye,
-- 
piergiorgio

Gianluca wrote:
[...]
Non ci hai parlato dell'esecuzione condizionata,
che e` un'altra peculiarita` di VLIW/EPIC.
bye,
-- 
piergiorgio

 EPIC č alla base della famiglia di processori Itanium. EPIC č stata
[snip]
Ehm, scusa.... ma chi te l'ha chiesto?
Comunque devo ammettere che sei piuttosto bravo a fare cut & paste....
-- 
Qui e' Jack Burton, del Pork-Chop Express,
che parla a chiunque sia in ascolto...
http://digilander.iol.it/burton666/index.html


Per la veritą ho tratto le notizie da:
Inside the
Intel Itanium 2 Processor:
an Itanium Processor Family member
for balanced performance
over a wide range of applications
a Hewlett Packard
Technical White Paper
July 2002
Si tratta di una traduzione dall'inglese. E' un documento molto interessante
dove viene spiegata sommariamente l'architettura e le prestazioni di Itanium
2. Saluti.

 July 2002
ecco, per te e per tutti gli altri: se volete leggere qualcosa di piu' 
decente su VLIW/EPIC (e molto altro, in realta') ci sono i technical 
reports HP, su un non meglio precisato sito hp (non ricordo esattamente 
l'indirizzo...). ad esempio si puo' iniziare con l' HPL-96-120.

 
si tratta delle istruzioni a lunghezza variabile di cui parlavo un tempo.
in pratica il compilatore si limita ad individuare tutte le 
operazioni eseguibili contemporaneamente in ogni ciclo di clock, e separa 
in qualche modo (in questo caso con l'operazione "stop") i vari passi.
i vari processori, a seconda delle risorse presenti, eseguono le 
istruzioni, se necessario spezzandole.
non e' una cosa semplice, ma in confronto alle "traduzioni" risc dei 
processori x86 attuali, e' una passeggiata...
supponendo di pari dimensione le singole operazioni, l'unico overhead 
introdotto e' quello dei marcatori di fine istruzione.

 in qualche modo (in questo caso con l'operazione "stop") i vari passi.
Si, ma gli slot vuoti devono comunque essere
riempiti, almeno in un VLIW classico.
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:
 > Lorenzo Micheletto wrote:
 >
 >> Il punto e' che sfruttando l'opcode vero e proprio
 >> come "indice virtuale", se hai una manciata di spazio
 >> ancora disponibile puoi permetterti di _raddoppiare_ i
 >> registri partizionandoli in due set disgiunti.
 >
 >
 > Si, ma ripeto, invece di avere una sola
 > mov, ti trovi con mov, fmov, pmov etc.
"pmov" ?
 > Questo rompe l'ordine della CPU.
IMHO non causa alcuna "rottura", la "tipologia d'uso"
dei registri interi e di quelli floating point e' molto
diversa (es: gli interi li usi anche come puntatori
e su di essi esegui parecchie operazioni che hanno poco
senso per dei float), il passaggio di un valore da un tipo
di registri all'altro poi va fatto sempre con una conversione
di formato, quindi i due set di registri vengono gia
gestiti in modo "differenziato" anche a livello di programma.
 >> Se lo hanno fatto pure con gli Alpha, mi sembra evidente
 >> che la cosa e' vantaggiosa se si cercano prestazioni piu elevate.
 >
 >
 > Eh, ma in altre CPU non lo hanno fatto,
 > hanno mantenuto il set di registri unico.
IMHO in generale una cosa del genere significa che il formato delle
istruzioni non e' stato ottimizzato e che in questo modo
si e' rinunciato ad un buon 2..5% di prestazioni in piu
(dovuto al "raddoppio" dei registri disponibili).
L. Micheletto

 (dovuto al "raddoppio" dei registri disponibili).
No, perche` la CPU in questione ha parecchi registri,
forse per questo non sono stati semplicemente raddoppiati...
bye,
-- 
piergiorgio

 senso per dei float), il passaggio di un valore da un tipo
Ma no, questo e` il punto.
Avere 16+16 registri significa avere "solo"
16 registri per interi, puntatori, etc., e
ben 16 registri "solo" per FP.
E` uno spreco, per esempio il kernel di Linux e`
tutto integer, il che vuol dire che potrebbe usare
solo 16 registri su 32 disponibili.
D'altro canto un SW come matlab si trova ad usare
solo 16 registri FP, su 32 disponibili.
Non e` "lineare", ne` flessibile, meglio avere 32
registri GP e morta la`...
bye,
-- 
piergiorgio

 registri GP e morta la`...
Eh! No! A parita di formato delle istruzioni se rinunci
al "selettore virtuale" basato sull'opcode
non hai 32 registri, ne hai solo 16. :-(
E' proprio qui l'inghippo, nel caso "peggiore"
hai le stesse prestazioni di un set di registri
unificato, ma negli altri casi ottieni prestazioni
piu elevate.
Inoltre, nel caso di mathlab i puntatori alle matrici
ed i contatori di loop stanno sui registri interi.
L. Micheletto

 controllare i registri della MMU...
Non e' che forse ti confondi con la movep ?
(quella per scrivere "a byte alterni")
La pmov proprio non la ricordo (ma al massimo
ho messo le mani sui 68000, non so cosa possono
aver aggiunto poi).
L. Micheletto

 ed i contatori di loop stanno sui registri interi.
Matlab... :-)
Si, in effetti matlab trae molto beneficio dalle
architetture capaci di usare, in parallelo, ALU
ed FPU, dato che gli indici possono venir calcolati
in parallelo con le operazioni FP.
Comunque era solo un esempio...
bye,
-- 
piergiorgio

 aver aggiunto poi).
Ricordo che, credo dal 030 in poi, cioe` sui
modelli con MMU integrata, c'era queste "pmov",
per scrivere/leggere i registri della MMU.
Comunque e` passata parecchio tempo, per cui
non garantisco nulla :-)
bye,
-- 
piergiorgio