# Architetture dei processori/Very Long Instruction Word

Storia · Set di istruzioni · Processore monolitico · Unità di decodifica · Unità predizione dei salti · Arithmetic Logic Unit · Floating Point Unit · Cache · Pipeline · Single Instruction Multiple Data · Memory Management Unit · Processore superscalare · Processore vettoriale · Very Long Instruction Word · Pentium 4 · Itanium 2 · Evoluzioni future ·
Le architetture Very Long Instruction Word sono basate sull'utilizzo del parallelismo intrinseco presente delle istruzioni. Similmente ai microprocessori superscalari queste CPU sono dotate di più unità di calcolo indipendenti (per esempio due moltiplicatori) per permettere alla CPU di eseguire più calcoli contemporaneamente (per esempio due moltiplicazioni). L'idea è di togliere al processore l'oneroso compito di ottimizzare al massimo il parallelismo delle istruzioni per affidarlo al compilatore.

## Progetto

In un progetto superscalare il numero di unità di calcolo non è visibile nel set di istruzioni. Ogni istruzione codifica una sola istruzione, per molti microprocessori è di 32 bit o meno.
Invece ogni istruzione VLIW codifica più istruzioni elementari specificando ogni istruzione per ogni unità di calcolo. Per esempio un dispositivo VLIW con 5 unità di calcolo sarà dotato di istruzioni con cinque campi, ogni campo specifico per ogni unità di calcolo. Ovviamente le istruzioni VLIW sono molto più lunghe delle classiche istruzioni, sono lunghe almeno 64 bit ma spesso sono di 128 bit o più.
Sin dalle prime architetture ci si è resi conto che aggiungendo unità di calcolo alle macchine si potevano incrementare le prestazioni senza aumentare i costi in maniera eccessiva. Nelle CPU superscalari è la CPU stessa che durante l'esecuzione decide dinamicamente quali istruzioni mandare in esecuzione in parallelo. nelle CPU VLIW è il compilatore che durante la fase di traduzione decide quali istruzioni vadano eseguite in parallelo.
Per esempio una CPU può essere in grado di eseguire due moltiplicazioni contemporaneamente. Supponendo che la CPU riceva le due moltiplicazioni, la prima sarà mandata in esecuzione nella prima unità ma se la seconda moltiplicazione dipendesse dal risultato della prima questa non potrebbe essere mandata in esecuzione e al suo posto verrebbe effettuato un blocco in hardware. In un'istruzione VLIW il compilatore individuerebbe il conflitto e introdurrebbe una NOP (istruzione nulla) per la seconda unità di calcolo. Questo riduce di molto la complessità della CPU.
Inoltre un compilatore VLIW può riconoscere il problema delle due moltiplicazioni e quindi anticipare una istruzione che non ha precondizioni per poter incrementare le prestazioni della CPU evitando l'utilizzo dell'istruzione NOP. Un simile approccio viene seguito anche da alcune CPU superscalari moderne che però dovendo eseguire queste decisioni in tempo reale forniscono modeste prestazioni e incrementano ulteriormente la complessità del progetto.
Un simile problema si presenta se il risultato di un'istruzione viene utilizzato per definire se uscire da un ciclo o no. Molte CPU moderne scelgono in anticipo un percorso in modo da poter caricare i dati corrispondenti. Alcune CPU sono dotate di una unità di predizione delle diramazioni che effettua una analisi del codice per prevedere la diramazione più probabile. Questi metodi incrementano la complessità del progetto e corrompono la filosofia originaria delle architetture RISC anche perché la CPU deve contenere anche l'elettronica che in caso di errore della predizione elimina le istruzioni in esecuzione e elimina le eventuali modifiche già eseguite.
In un'architettura VLIW il compilatore utilizza delle euristiche o dei profili per predeterminare in anticipo il ramo più probabile. Avendo il compilatore molto più tempo della CPU e la possibilità di analizzare tutto il codice e non solo qualche istruzione le sue previsioni sono molto più precise di quelle effettuate da una CPU in tempo reale. Comunque il compilatore sviluppa il codice con il ramo più probabile già codificato nel codice e fornisce anche il codice per eliminare le istruzioni già eseguite nel caso la previsione non sia quella corretta.

## Problematiche

Il principale problema di questa architettura è l'estrema dipendenza dei programmi dal compilatore. Un programma ottimizzato per un processore VLIW per lavorare in modo efficiente sulla generazione successiva di microprocessori va quasi sempre ricompilato. Questo rende problematico per un utente cambiare il computer dato che anche il suo parco software andrebbe adattato al nuovo processore a meno che i programmi non siano in grado scritti con un linguaggio come il Java che essendo in realtà compilato durante l'esecuzione possa essere adattato alla macchina durante l'esecuzione. Un'altra strategia è utilizzare uno strato software che interpreti il vecchio codice e lo adatti al nuovo processore ma in questo caso si ha un deperimento delle prestazioni che può essere anche molto marcato. Questa strategia viene utilizzata per esempio dal processore Efficeon della Transmeta che interpreta codice Intel X86 standard e internamente lo traduce in codice VLIW per la CPU.

## Evoluzioni

L'architettura VLIW ha indubbiamente molti vantaggi ma i suoi problemi ne rendono problematico l'utilizzo in processori per computer. La necessita di ricompilare il codice per ogni generazione di processori in particolare si scontra con la necessita degli utenti di poter mantenere il parco software. Per eliminare questi problemi diverse società hanno sviluppato delle evoluzioni dell'architettura VLIW, tra le varie evoluzioni la più famosa è l'architettura EPIC sviluppata da Intel e HP congiuntamente. L'architettura EPIC (Explicitly Parallel Instruction Computing) raggruppa le istruzioni elementari in parole come una classica architettura VLIW e inserisce inoltre delle informazioni sul parallelismo tra le varie parole. In questo modo le varie generazioni del processore possono variare internamente la loro architettura senza troppi problemi. Le informazioni sul parallelismo permettono di realizzare unità di decodifica che sfruttano il parallelismo efficientemente ma sono nel contempo semplici dato che l'analisi del codice parallelo e la sua suddivisione è stata effettuata dal compilatore. Inoltre l'architettura EPIC per migliorare le prestazioni aggiunge molti registri (diverse centinaia) per evitare di implementare l'unità di ridenominazione dinamica dei registri, aggiunge delle istruzioni predicative per evitare lo svuotamento delle pipeline e altre innovazioni per velocizzare i cambi di contesto tra le subroutine e per migliorare la gestione della cache. L'architettura EPIC è stata implementata da Intel nei processori Itaniun e Itanium 2. Questa famiglia di processori dopo un avvio molto stentato nel settore dei server ha ultimamente conquistato quote di mercato. La prima versione dell'Itanium forniva prestazioni deludenti, le cache di primo e secondo livello erano piccole ed il codice EPIC per via delle istruzioni aggiuntive risulta più ingombrante dell'equivalente codice per x86. Quindi le cache potevano contenere porzioni di codice ridotto e i continui accessi alla memoria penalizzavano il processore. Le successive generazioni dell'Itanium fornirono i processori di cache generose per arrivare fino all'Itanium 2 MP 9050, un processore dotato di due core separati con cache di primo livello da 32 Kilobyte per core, 512 Kilobyte di cache di secondo livello per core e 24 Megabyte di cache di terzo livello unificata. Ovviamente tutta questa memoria incide sul numero di transistor che in questo modello arrivano ad essere 1.72 Miliardi.