| | Categorie Articoli | | > Prove | | > Attualità | | > Approfondimenti | | > Interviste | | Altro su HIRC | | > Segnalaci una notizia | | > Advertising | | > Forum |  | | Ultime dal forum | | Visualizza HIRC del | | |
| | PowerPC Processor Element | Il PPE (PowerPC Processor Element) è lo strato “convenzionale” del Cell Broadband Engine, si tratta infatti di un processore RISC general purpose “in-order” dual-issue dual-threaded, pienamente compatibile con il set di istruzioni PowerPC.
E’ fondamentalmente un processore a 64-bit, ma può funzionare anche in modalità “compatibile” a 32-bit; inoltre supporta le estensioni SIMD VMX per il calcolo vettoriale. Può eseguire qualsiasi codice compilato per PowerPC.
La prima implementazione prevede 32KB di cache L1 (16KB dati e 16KB istruzioni) e 512KB di cache L2.
Come per tutte le architetture RISC, le istruzioni possono avere come operandi solo registri oppure valori immediati.
Sebbene IBM non abbia discusso pubblicamente i dettagli del PPE, (il quale, ricordiamo, pur essendo compatibile con l’ISA PowerPC non deriva da alcun processore IBM PowerPC in produzione), il simulatore permette di estrapolare informazioni riguardanti struttura ed organizzazione dei registri, come si può vedere dall’immagine precedente.
 | | Uno screenshot che ritrae i registri principali delle unità logiche PPE all'interno del simulatore |
Per ogni unità logica sono disponibili i seguenti registri:
-32 GPR (registri generali) 64-bit
-32 FPR (registri in virgola mobile) 64-bit
-32 VMXFPR (registri vettoriali per le unità VMX) 128-bit
Ciascuna delle unità logiche è inoltre dotata di una serie di registri interni indispensabili per il funzionamento del processore, tra questi vi sono quelli fondamentali:
-PC (Program Counter) 64-bit
-MSR (Machine Status Register) 64-bit
-CR (Condition Register) 32-bit
-LR (Link Register) 64-bit
-XER (Fixed Point Exception Register) 64-bit
-FPSCR (Floating Point Status and Control Register) 64-bit
Di questi registri fondamentali il Program Counter non ha certo bisogno di “presentazioni”, vale la pena invece di spendere qualche parola in più sul MSR in quanto assume un ruolo cruciale non solo per il PPE (definendo ad esempio la modalità operativa a 32 o 64-bit) ma per tutto il Cell. Le unità di calcolo vettoriale ausiliarie (le SPE) infatti sono estremamente semplici e si limitano ad eseguire i compiti che vengono loro assegnati; non eseguono alcun controllo, ad esempio, di protezione della memoria: questi compiti, legati essenzialmente alla distinzione tra modo utente e modo supervisore vengono svolti dal PPE.
Il Condition Register è diviso in 8 campi da 4-bit; il primo campo CR0 (bit 0-3) è relativo alle condizioni verificate da un calcolo in virgola fissa, mentre CR1 è relativo ai calcoli in virgola mobile, gli altri invece possono essere utilizzati per memorizzare i risultati di una operazione AND, OR o XOR tra i valori dei bit di CR0 e CR1. I primi quattro bit del registro hanno i seguenti significati riferiti all’ultima operazione eseguita:
-bit 0 (LT): risultato negativo
-bit 1 (GT): risultato positivo
-bit 2 (EQ): risultato zero
-bit 3 (SO): summary overflow (dato duplicato anche nel registro XER)
Per informazioni estensive sui calcoli in virgola fissa e mobile si utilizzano i registri XER e FPSCR. Infine, ultimo registro fondamentale è il Link Register (LR): le architetture PowerPC infatti non fanno alcuna distinzione tra i salti generici ed i salti a sottoprogramma (non esiste alcuna istruzione “automatizzata”), bensì tutte le istruzioni di salto (condizionato o incondizionato) possono specificare attraverso un bit alto (chiamato LK) che venga salvato nel registro LR l’indirizzo di ritorno al “programma principale” (cioè l’indirizzo dell’istruzione che segue quella di salto).
La memoria è byte-addressable, ed è accessibile in byte, halfword, word e double word; lo schema di memorizzazione, a differenza delle normali architetture PowerPC è unicamente big endian.
Siccome questo processore supporta l’esecuzione di due thread in parallelo, le unità logiche sono due, abbiamo quindi in totale 64 registri generali, 64 registri in virgola mobile e 64 registri per operandi VMX, così come un “duplicato” di ogni registro interno. Difatti ogni PPE viene visto a livello logico come due processori, e la presenza di registri dedicati per ogni unità logica consente l’effettiva esecuzione di due thread in parallelo, pur mantenendo unità di esecuzione, cache e memoria in comune.
Questo approccio consente indubbiamente di sfruttare meglio le unità di esecuzione non solo eseguendo più operazioni insieme (a patto che i due thread non richiedano operazioni in contemporanea alla stessa unità di esecuzione), ma soprattutto evitando che queste restino inutilizzate in caso di stallo della pipeline.
Ormai soluzioni del genere sono diffuse anche nel mercato consumer (basti pensare alla tecnologia Intel HyperThreading) e consentono di aumentare considerevolmente il numero effettivo di istruzioni eseguite nell’unità di tempo, con un costo relativamente ridotto sul silicio (soprattutto se confrontato ad altre soluzioni come l’esecuzione Out Of Order).
Essendo un processore dual-issue in-order, questo è l’unico modo per eseguire fino a due operazioni in parallelo, infatti le istruzioni di un processo vengono eseguite sequenzialmente da ognuna delle due unità logiche una dopo l’altra, così come sono nel programma, senza cercare di parallelizzarle. Ogni unità logica può quindi richiedere l’esecuzione di una istruzione per ciclo di clock, a patto che, come detto in precedenza, questa non debba essere eseguita da una unità di esecuzione che risulta occupata da una istruzione richiesta dall’altra unità logica.
Rispetto all’esecuzione OOO (Out-Of-Order) questa soluzione presenta numerosi vantaggi ed alcuni svantaggi: i vantaggi sono indubbiamente una maggiore semplicità del design (il che si traduce in meno spazio occupato sul silicio e nella possibilità di funzionare a frequenze più elevate), ed una certa “immunità” agli stalli della pipeline; gli svantaggi invece riguardano il fatto che per poter sfruttare il parallelismo le applicazioni devono essere multithreaded, e cioè il “problema” è spostato al programmatore.
Quindi mentre l’esecuzione OOO può portare vantaggi a qualsiasi applicazione senza necessità di modificarla, l’approccio scelto per il PPE può portare a prestazioni estremamente basse nell’esecuzione di codice single-threaded. Questo aspetto, trovandoci di fronte ad una architettura nuova, è poco significativo in quanto è necessario comunque sviluppare nuovi programmi senza preoccuparsi della retrocompatibilità.
Sebbene il PPE possa svolgere qualsiasi compito, nel modello di un sistema Cell ideale, dovrebbe servire soltanto ad eseguire i compiti più semplici ed a gestire le risorse di sistema, in altre parole dovrebbe essere limitato all’esecuzione del solo sistema operativo.
|
Vuoi segnalarci una tua notizia? Clicca qui!
| | | Comments | | | | Annunci | | | Attualità | | Fujitsu presenta la soluzione e roadmap Mobile WiMAX System-on-chip | | Nuovo masterizzatore DVD esterno Sony DRX-820UL | | Nokia 770 Internet Tablet e Google Talk insieme | | Core 2 Duo, gioco di parole per i nuovi processori Intel | | Recensione Crucial Gizmo! Overdrive 1GB online | | LCD con tempo di risposta di 2ms da Acer | | ATi ha acquisito la finlandese BitBoys | | AMD ritira 3000 CPU Opteron difettose | | Intel punta decisa verso i 32 nanometri | | Intel vPro: nuova piattaforma per PC aziendali | | Prove | | Crucial Gizmo! Overdrive 1GB: capacità e prestazioni | | Crucial Gizmo!: 1GB per foto, musica e pinguini | | Raffreddamento a liquido: quando il gioco si fa duro | | Sapphire Radeon X1300: alta definizione per tutti | | Enermax Liberty 500W: la libertà fatta alimentatore | | Genius Ergo 300: mouse piccolo ma non troppo | | Royaltek GPS RBT 2001 | | Crucial Ballistix Tracer DDR500: semplicemente estreme | | HP Business Desktop dx5150: potenza per ufficio | | Dal Radeon X600 all'X800: generazioni a confronto in casa Sapphire | |
|
