7. Enhanced 3DNow!

Alla uscita delle 70 istruzioni SSE del Pentium III, temendo di perdere il vantaggio acquisito con la tempestiva uscita delle 3DNow! e per via delle novità affermatesi nel campo multimediale, AMD decise di aggiungere ulteriori 24 istruzioni alle 3DNow! primitive (mutuandone alcune dalle SSE direttamente) portandole così a 45 istruzioni in totale.

Grazie al meccanismo di stack renaming e per le note considerazioni circa l’aggiunta di registri dedicati svolte a suo tempo per le 3DNow! base si è continuato a condividere gli 8 registri con MMX (e x87) con il consueto data-type di 64 bit composti da due elementi da 32 bit (singola precisione). Le istruzioni sono così classificabili:

• 19 istruzioni di estensione al set MMX per applicazioni multimediali audio, video e per incremento delle funzionalità di movimento dati e prefetching;
• 5 istruzioni di estensione al set 3DNow! per accelerare applicazioni di comunicazione e audio;

Le istruzioni di estensione al set 3DNow! agiscono naturalmente su floating point e supportano applicazioni DSP (Digital Signal Processing) quali la gestione software modem, ADSL e MP3. Tutte queste istruzioni sono utilizzate per conversione da intero a 16 bit a FP a 32 bit e viceversa con troncamento (PFI2W e PF2IW), scambio di due FP all’interno di un registro dalle posizioni High e Low (PSWAPD) e due funzioni di accumulazione negativa (PFNACC) o mista cioè negativa o positiva (PFPNACC). Tutte queste istruzioni sono progettate per lavorare con flussi di dati interi a 16 bit, monodimensionali, tipici di applicazioni audio, che vengono convertiti in FP a 32 bit per aumentarne la gamma dinamica durante le operazioni di elaborazione (con percorsi a tratti vettoriali e a tratti scalari) per poi essere riconvertiti a 16 bit interi in uscita.

Le istruzioni di estensione al set MMX prevedono istruzioni praticamente identiche a molte del set SSE sia perché effettivamente utili sia per favorire la compatibilità con le applicazioni ottimizzate per il Pentium III. Abbiamo quindi la PAVGB assolutamente identica alla PAVGUSB del set originario 3DNow! (utilizzata per la codifica MPEG) introdotta perché ha la stessa sintassi e la stessa codifica dell'equivalente SSE e affiancata da PAVGW, operante su word (dati a 16 bit) che dell’analoga SSE condivide anche il nome.

Vi è poi la PSADBW, anch’essa progettata per accelerare la codifica MPEG la quale cerca, per quanto possibile, di riutilizzare le stesse porzioni di immagine in fotogrammi successivi (ad es. un pallone che si muove in una sequenza animata cambia poco di aspetto fra un frame e l'altro, anche se cambia posizione), perciò si scompone l'immagine in macroblocchi di pixel e per ognuno di essi si cerca di vedere se nel fotogramma precedente c'era un macroblocco, magari in posizione differente, che assomiglia molto a quello nuovo, così da poter codificare solo le differenze fra i due e lo spostamento di coordinate occorso. Tale ricerca viene fatta applicando una "funzione d'errore", che somma le differenze in valore assoluto fra i pixel dei due macroblocchi per calcolare l'errore complessivo; considerato un macroblocco del nuovo frame, lo si confronta tramite la funzione d'errore con tutti quelli del frame precedente, e si sceglie quello che ha l'errore più basso. PSADBW per ogni coppia di pixel omologhi fra i due operandi, fa la differenza in valore assoluto e fa la somma di tutti i valori trovati. Ancora una volta si confronti tale istruzione con la omonima delle SSE e così via per molte altre.

Infine abbiamo le istruzioni per il prefetching. La versione originale delle 3dnow! prevede due sole istruzioni per tale scopo, PREFETCH e PREFETCHW che nel K6-2 non differivano praticamente che per il nome. Entrambe caricano in anticipo una cache-line (32 byte nel caso del K6-2 e 64 byte nel caso dell’Athlon) nella cache L1, ma la prima va usata per dati che devono essere solo letti, mentre la seconda è ottimizzata per dati che verranno modificati. La differenza, nel caso della PREFETCHW, è che la cache-line precaricata viene già marcata come "modificata". Le cache supportano dei protocolli che indicano la quantità e il tipo degli accessi per mantenerne la coerenza, infatti quando una linea che è stata modificata deve essere espulsa da una cache per essere rimpiazzata da nuovi dati, il suo contenuto deve essere copiato nei livelli inferiori della gerarchia di memoria (cache L2 e memoria principale), mentre ciò non è necessario in caso di dati che sono stati solo letti.

Nel caso la linea che ha subito il prefetch debba essere effettivamente modificata l’uso dell’istruzione PREFETCHW in luogo della PREFETCH permette di risparmiare i cicli di clock (10-15) che sarebbero necessari per aggiornare lo stato della linea e che invece nel caso della PREFETCH comporterebbero una penalità visibile. Nell’Athlon si possono accodare fino a 6 istruzioni prefetch pendenti, operanti su dati diversi, per cui si può fare il prefetch su diversi flussi di dati concorrenti.

Inoltre Athlon può usare tutte le principali istruzioni di prefetch e streaming store di SSE come ad esempio il PREFETCHNTA che consente di immagazzinare dati solo nella cache L1 evitando, se il dato non è presumibilmente a breve richiesto, di doverlo rimuovere anche dalla L2, come MOVNTQ utilizzata per immagazzinare singoli byte in un registro MMX per scritture di dati senza lettura tipiche appunto di grandi flussi di dati, caratteristica comune nelle applicazioni multimediali, secondo un’ottica di write-combining. La gestione del write-combining (WC), che ricordiamo consiste nel raggruppare più write di memoria per trasferirli in un singolo ciclo di scrittura per ridurre il traffico di bus, è implementata nell’Athlon per mezzo di un buffer WC da 64 byte che raccoglie i write.

Come per il Pentium III per risolvere la debolezza dell’ordinamento degli accessi di memoria, si e prevista l’istruzione SFENCE che assicura, prima di procedere ad uno store, che gli store precedenti la propria esecuzione sono presenti in memoria cioè sono globalmente visibili. Essendo la dimensione di una cache-line di 64 byte, contro i 32 byte del Pentium III, bisogna evitare, nel caso di codice che deve girare su più piattaforme, che le aree di memoria interessate da diversi prefetch si sovrappongano eccessivamente quando il codice gira sull’Athlon.

Credits

Avete letto una delle più appronfondite analisi dell'architettura dell'Athlon disponibili in lingua Italiana. Ringraziamo Fantini Filippo, Stocchi Stefano e il Prof. Gianni Conte dell'Università degli Studi di Parma. Il lavoro originale è disponibile on-line a questo indirizzo: http://www.ce.unipr.it/~stocchi/ dove potete trovare anche altri interessantissimi articoli. Per contattare gli autori inviare una mail al seguente indirizzo: conte@CE.UniPR.IT

	Vuoi essere avvertito quando usciranno nuovi Articoli ? Iscriviti anche tu alla comunità di Lithium.it ed entra nel nostro forum
	REGISTRATI ALLA NEWSLETTER >>
	REGISTRATI AL FORUM >>

Introduzione
Descrizione CPU - Fetch e Decode
ICU e Pipeline degli interi e dei Floating Point
Cache
EV6 BUS
>> Enhanced 3Dnow!

>> ELENCO COMPLETO DEGLI ARTICOLI <<