In un precedente articolo ho parlato di “misura dei bit” dell’architettura di un sistema, e ho intenzionalmente tirato fuori una definizione ricorsiva, che faceva uso di altre definizioni per finalizzare se stessa.
Ciò non per sadismo o mancanza di rispetto nei confronti dei lettori (che hanno sollevato ugualmente e giustamente il problema nei commenti), ma perché avevo intenzione di parlare in termini più generali di cosa s’intende per “misura”, delle variabili che possono concorrere al suo calcolo, e soprattutto dell’arbitrarietà della scelta dell’algoritmo utilizzato allo scopo.
Ho voluto, quindi, metter da parte il concetto di misura del singolo componente del sistema, dandolo per scontato / assodato, anche se qualche traccia delle mie idee l’ho lasciata sia nell’articolo che nei commenti, con la promessa di tornare appositamente sull’argomento…
Premetto che le mie considerazioni riguarderanno principalmente le CPU, ma potranno facilmente e intuitivamente essere riportate anche a GPU, APU, PPU, DSP, e in generale a qualunque processore (inteso come elemento che esegue dei calcoli).
Come l’architettura di un sistema è costituita da diversi componenti, allo stesso modo una CPU al suo interno conta diversi elementi. Questi possono in qualche misura essere “misurabili” e, contrariamente a un intero sistema (dove avevo necessariamente forzato l’ipotesi che a ogni componente fosse possibile attribuire una precisa misura), spesso è possibile stabilire in maniera oggettiva su quanti bit lavorano.
Forti di queste maggiori certezze, la tentazione potrebbe essere quella di pensare che, almeno per loro, la decidibilità della misura delle CPU sia concreta. In realtà l’eterogeneità degli elementi interni in generale è tale da presentare esattamente gli stessi problemi di scelta.
Anche qui, quindi, mettiamoci subito l’anima in pace: è molto difficile che si possa definire in maniera oggettiva una misura, in termini di bit, di una CPU.
Passando ai singoli elementi che la costituiscono, vediamo che ne esistono di diversi tipi:
- registri dati
- registri indirizzi
- registri indice
- PC (Program Counter)
- SP (Stack Pointer)
- registro dei flag
- registri speciali
- bus dati interno
- bus dati esterno
- bus indirizzi interno
- bus indirizzi esterno
- collegamenti punto-punto
- AGU
- ALU
- FPU
- SIMD
Ovviamente non sono tutti presenti all’interno di qualunque CPU, ma è possibile che alcuni di essi non ci siano, oppure che siano dotate di elementi addizionali. Ciò non toglie la valità del ragionamento, che è facilmente applicabile anche a casi qui non contemplati.
Una spiegazione per ognuno di essi si rende necessaria, per lo meno per capire di cosa sto parlando.
Un registro dati serve a contenere dei dati sui quali possiamo effettuare la maggior parte delle operazioni (“movimento”, aritmetiche, logiche, campi di bit, stringhe, array, BCD, ecc.). In genere ne è sempre presente almeno uno (chiamato accumulatore) oppure un certo numero (si parla di registri dati general purpose), ma ci sono architetture che non ne hanno (come il TMS 9900 che sfrutta la memoria o i Transputer che usano lo stack).
Un registro indirizzi permette di memorizzare direttamente degli indirizzi di memoria (virtuali o fisici) per poi farvi riferimento tramite le istruzioni di load/store (specificando opportune modalità d’indirizzamento), oppure manipolandolo tramite un ristretto numero di operazioni (“movimento”, e aritmetiche; queste ultime in genere limitate soltanto a somme, sottrazioni e confronti, quindi escludendo moltiplicazioni, divisioni, and, or, ecc.). Il 68000 è un esempio di architettura che ne fa ampio uso.
Un registro indice viene usato per poter indirizzare in maniera indiretta la memoria, semplificando l’uso di array e strutture dati (struct o record). Come per i registri indirizzo, viene specificato nelle modalità d’indirizzamento, e manipolato con un ristretto numero di operazioni. E’ molto comune nelle architetture, e i due concetti (registri indirizzi e indice) si “fondono” se l’ISA non è segmentata, cioé un indirizzo di memoria è contenuto interamente in un registro indice.
Un esempio di architettura per la quale si applica l’uno o l’altro concetto è lo Z8000 , che nella versione più avanzata sfrutta i segmenti (quindi i registri sono classificabili come indice) e in quella più economica no (quindi i registri sono di tipo indirizzo). Ovviamente ci sono anche architetture che non fanno distinzione fra registri dati e/o indice e/o indirizzi, come il PDP-11 .
Il PC è un registro di tipo indirizzo o indice che punta all’attuale o prossima (a seconda delle implementazioni) istruzione da eseguire.
Lo SP è un registro di tipo indirizzo o indice che punta all’attuale o successiva (a seconda delle implementazioni) locazione di memoria di tipo stack (quindi usata per variabili temporanee e/o indirizzi di ritorno da chiamate a subroutine) che risulta disponibile.
Per lo SP i casi sono diversi: ci sono architetture che hanno un apposito registro dedicato (16032), che riservano un registro dati/indirizzo/indice allo scopo (8086), oppure che non hanno un vero e proprio stack, in quanto possono usare qualunque registro (ARM).
Il registro dei flag serve a memorizzare il risultato delle ultime operazioni aritmetiche o logiche, per poi essere utilizzate in istruzioni di salto condizionale. Generalmente c’è un registro dedicato allo scopo (chiamato appunto registro di flag), ma ovviamente esistono delle eccezioni.
Le prime versioni dell’ARM (fino alla 3) integravano i flag nei 6 bit alti del PC (limitando, di fatto, lo spazio d’indirizzamento a 64MB), mentre i MIPS non hanno flag (si usano apposite istruzioni per generare il risultato dei confronti).
Il termine registri speciali è molto generico e in tal modo ho voluto indicare tutto ciò che non rientra nei precedenti, ma che rimane pur sempre un registro, e quindi accessibile come tale direttamente o indirettamente. Di esempi ce ne sarebbero praticamente per qualunque architettura, ma ne faccio giusto qualcuno.
Il TMS 9900 ha un registro indirizzo per puntare alla zona di memoria in cui mappa tutti i registri dati, i MIPS hanno due registri che contengono il risultato della moltiplicazione o divisione, e gli 8086 hanno 4 registri per specificare l’indirizzo base dei 4 segmenti che possono gestire contemporaneamente (codice, dati, stack ed “extra”).
Il bus dati interno serve a trasportare dati dai registri alle unità di calcolo (e viceversa ovviamente), oppure alla memoria. Da parecchi anni ha ormai poco senso parlare di singolo bus dati, perché le esigenze di parallelismo hanno portato ad averne di diversi che operano “in concorrenza”. Inoltre possono essere presenti bus dati di capienza diversa a seconda del tipo di dato trasportato. Per le GPU questa entità è estremamente importante.
Per il bus dati esterno vale all’incirca lo stesso concetto di quello interno, perché esistono architetture che permettono di generare più richieste di lettura o scrittura allo stesso tempo, avendo integrati più memory controller indipendenti. Comunque quelle più diffuse sono dotate di un solo bus dati esterno. Anche qui, per le GPU è molto importante il bus dati esterno.
Il bus indirizzi interno è utilizzato per trasportare i dati relativi agli indirizzi di memoria a cui si vuole accedere. Valgono più o meno le stesse considerazioni del bus dati interno, tranne per il fatto che la dimensione dei dati è sempre la stessa (e avrebbe poco senso altrimenti, a mio avviso, perché parliamo sempre di accedere a locazioni di memoria, la cui codifica è sempre uniforme).
Anche per il bus indirizzi esterno valgono le stesse considerazioni del bus dati esterno.
I collegamenti punto-punto servono a collegare mono o bidirezionalmente esclusivamente due entità, eliminando quindi la necessità di “arbitri” per la gestione della risorsa (le linee su cui viaggiano le informazioni). Al contrario del bus a cui, per definizione, possono attaccarsi una moltitudine di periferiche (anche se quella che ne fa maggior uso generalmente è la CPU) e servono appositi meccanismi di regolazione degli accessi.
In genere si sfruttano per il collegamento a southbridge, ma in sistemi SMP è ormai comune il loro uso per poter interfacciare fra di loro due o più microprocessori, che si scambiano dati per mantenere coerenti le loro cache oppure per permettere a un processore di accedere alla memoria gestita da un altro (in caso di sistemi NUMA). Un processore può avere diversi collegamenti punto-punto (ad esempio gli Opteron della serie 8x ne hanno ben tre).
Le AGU sono unità dedicate alla generazione degli indirizzi (Address Generation Unit), e servono per effettuare tutti i calcoli necessari per ottenere l’indirizzo (virtuale) finale per quanto riguarda una richiesta di accesso alla memoria.
A seconda dell’implementazione della CPU, possono essercene anche più d’uno (ad esempio i Pentium III ne hanno tre, perché possono eseguire fino a tre istruzioni per ciclo di clock, e ognuna di essere può avere un riferimento alla memoria).
Le ALU sono le classiche unità di calcolo che si sobbarcano l’onere di effettuare somme, sottrazioni, moltiplicazioni, divisioni, ma anche and, or, xor, manipolazioni di campi di bit, ecc. a seconda della complessità dell’ISA. Ovviamente per esigenze di parallelismo possono essercene più d’una, e spesso capita che siano specializzate (alcune possono eseguire più o meno operazioni rispetto ad altre). Operano sempre su registri dati/indirizzi/indici.
L’FPU è l’unità di calcolo che in genere si occupa di eseguire le operazioni di calcoli dei valori in virgola mobile (floating point), ma che permette di eseguirne anche con interi, per rendere più facile operazioni di tipo misto (capita non di rado di eseguire, ad esempio, somme fra valori interi e in virgola mobile). Come per le ALU, possono essercene più d’una e anche specializzate, ma in genere hanno appositi registri su cui lavorano, la cui dimensione può essere diversa da quella degli altri registri.
Infine le SIMD sono unità di calcolo vettoriale che hanno preso piede da un po’ di anni perché permettono di velocizzare notevolmente questo tipo di calcoli. Valgono esattamente le stesse considerazioni delle ALU (generalmente hanno appositi registri).
Ho volutamente tralasciato il concetto di spazio d’indirizzamento dell’I/O, perché riguarda architetture abbastanza vecchie (questo concettualmente, perché è vero che è presente nello Z80, ma anche in 8086 e successori), e comunque in genere sfruttano le stesse risorse (bus dati e indirizzo) per questo tipo di accesso.
Dopo questa lunga, ma necessaria, carrellata (che non è, e non pretende di essere esaustiva sulle tipologie di entità esistenti all’interno delle CPU, e in generale dei processori, ma che abbraccia quelle sicuramente più comuni e note), penso sia chiaro per quale motivo per le CPU, come per i sistemi in cui esse sono presenti, non sia possibile stabilire in maniera oggettiva una loro “misura” in bit.
In buona sostanza ci sono troppe variabili di cui tener conto, e non esiste metodo oggettivo che permetta di sceglierne una, un sottoinsieme, una loro media, ecc.. Inoltre ogni entità citata può riservare delle sorprese, perché… non è sempre possibile determinare una loro oggettiva misura in bit, in quanto a loro volta esistono suoi elementi costitutivi a cui è possibile attribuire “misure” diverse.
Torna, quindi, prepotentemente la famigerata ricorsione, ma potete star tranquilli: non ho intenzione di scendere di un ulteriore livello d’astrazione con un nuovo articolo. Mi limiterò a citare, ove applicabile, dove e perché torna in gioco la composizione di elementi diversi (riproponendo, quindi, il problema della misura del “contenitore”).
E’ opportuno, invece, spendere qualche parola facendo alcuni esempi di “misura” di una CPU considerando una sola delle entità precedentemente citate. In questo modo spero di mettere in chiaro non tanto se una CPU sia misurabile in termini di “n bit”, quanto più che altro perché non sarebbe opportuno farlo tenendo conto soltanto di un certo componente.
Tenendo conto dei soli registri dati, lo Z80 sarebbe un CPU a 8 bit, perché tale è la dimensione di questi elementi. Però questo processore è in grado di “accoppiarli” per eseguire anche operazioni a 16 bit.
Prendendo i registri indice, sempre lo Z80 sarebbe una CPU a 16 bit.
Il PC a 16 bit farebbe del 6502 una CPU a 16 bit.
Lo SP a 16 bit renderebbe tale il 6800.
Il registro dei flag del 68000 è a 16 bit (addirittura a 8 bit in modalità utente).
I machine register (registri speciali) introdotti dal Pentium sono a 64 bit.
Per i bus dati interni preferisco citare la GPU della PlayStation 2 (come avevo anche promesso nei commenti del precedente articolo), che ne possiede tre per un totale di ben 2560 bit (1024 per la lettura, 1024 per la scrittura e 512 bit per la lettura e scrittura).
Come bus dati esterno, quello del 68000 era a 16 bit, mentre quello del Pentium a 64 bit.
Il bus indirizzi interno del PentiumPro è a 36 bit.
Il bus indirizzi esterno del 68008 è a 20 bit.
Il collegamento punto-punto HyperTransport introdotto con gli Athlon64 ha una dimensione configurabile dai 2 ai 32 bit.
L’ALU del 68000 è in grado di eseguire operazioni aritmentiche a 8, 16 e 32 bit, ma in quest’ultimo caso richiede più tempo, in quanto internamente i sommatori sono a 16 bit (ed ecco perché ritorna la famigerata “ricorsione”). Ma il 68000 ha anche ALU dedicate per eseguire velocemente la somma a 32 bit per il PC e per la modalità d’indirizzamento con autoincremento di un registro indirizzi.
L’FPU dell’8086 è in grado di eseguire operazioni su interi fino a 64 bit, e in virgola mobile fino a 80 bit.
Infine le due unità SIMD contenute nella CPU della PlayStation 2 operano su registri a 128 bit (ma il core è basato sul RISC 5900 a 64 bit della famiglia MIPS).
Non ho trovato esempi citabili per i registri indirizzi, ma non sarebbe certamente una chimera una CPU dotata di registri dati a 8 bit, e registri indirizzi a 16 bit. Un esempio del tutto simile si potrebbe fare anche per le AGU, per le quali non ho ugualmente fornito un esempio reale.
A questo punto possiamo dire che di certezze ve ne siano veramente poche quando si tratta di applicare una misura in “bit” di un processore. Il che, beninteso, non vuole dire che sia impossibile; banalmente basterebbe realizzarne uno per il quale tutte le entità in gioco lavorino esattamente con dati della medesima dimensione.
Ma spesso la voglia di etichettare è tale per cui se si chiede a un programmatore a quanti bit sia una certa CPU che conosce, stranamente una risposta è in grado di fornirla subito. Avrà utilizzato, a questo punto, un proprio metro di giudizio, ma quale?
Da programmatore espongo l’idea che mi sono fatto. A me interessa lavorare con l’ISA della CPU, quindi coi registri e le istruzioni che su di essi operano. Quindi considero una CPU a “n bit” se i registri dati/indirizzi/indici sono a “n bit”, e se su buona parte delle operazioni posso operare a “n bit”.
Quindi anche se un 68000 ha più istruzioni che operano a 8 bit (ad esempio quelle per i dati BCD), ha i registri a 32 bit e buona parte delle istruzioni operano con queste quantità.
Uno Z80 lo considero a 8 bit perché, pur avendo registri a 16 bit (o combinabili come tali) ne ha pure a 8 bit, e le operazioni a 16 bit sono in numero decisamente più ridotto rispetto a quelle a 8 bit.
Il progettista di una scheda madre, invece, avrà un altro metro di giudizio. Ad esempio, un 68000 ha un bus dati esterno a 16 bit, quindi comunica con la memoria e le periferiche a 16 o 8 bit, per cui per lui sarà una CPU a 16 bit. E un 68008, col suo bus dati esterno a 8 bit, lo tratterà come CPU a 8 bit.
Chi avrà lavorato alle SPE di Cell le considerarà come processori a 128 bit, perché operano per lo più su dati con questa dimensione.
Infine per chi realizza GPU, invece, potrebbe essere più importante il bus dati interno, perché lo scambio di dati internamente è più critico rispetto a quello dei dati esterni.
Si tratta di posizioni perfettamente lecite, perché lo stesso oggetto viene visto in maniera diversa a seconda del contesto in cui si opera.
Ovviamente ci sono anche persone che soffrono di ansia da prestazione, per cui sapere che hanno un oggetto con più bit rispetto a un altro (qualunque sia la metodologia usata per la misura) le fa stare meglio.
Poi ci sono i markettari che, pur di vendere, farebbero carte false per tirare fuori un numero quanto più grande possibile, così da far colpo sull’immaginario collettivo (in particolare sulle persone precedentemente menzionate). Ed ecco spiegato perché la PlayStation 2 è stata venduta come console a 128 bit; anche se forse hanno peccato un po’ d’ingenuità, visto che potevano contare su una GPU a ben 2560 bit…
spesso inizio a leggere interssato questi articoli… poi mi scappa l’occhio sullo scroller… vedo il wall-o-text e chiudo ^_^
articoli più brevi plz
Come si fa ad essere sintetici parlando di queste tematiche? ce ne sarebbe da scrivere… :)
quando leggo transputer e emotion engine mi brillano gli occhi….
…la cpu della ps2 è stato un vero capolavoro…
cosi’ come i transputer nei primi anni 90…
Quando mi chiedono se la INTEL è miglior produttore di microprocessori al mondo gli rispondo che il miglior produttore di microprocessori al mondo è IBM senza alcun dubbio…ma la INTEL rimarrà alla storia per la piu’ straordinaria campagna di marketing della fine degli anni 90 ed inizio 2000 in tutti i campi produttivi e non solo per quello informatico….
INTEL è un simbolo…i processori INTEL non sono in alcun modo migliori degli altri anzi….basti vedere ARM e company…ma la gestione aziendale e del marketing ha permesso di raggiungere livelli di profitto inimmaginabili…grazie essenzialmente all’imposizione dell’architettura X86 che reputo sia una della peggiori nella storia dell’elettronica computazionale….
la cpu della ps2 è un capolavoro niente a che vedere con l’architettura della PS3 che CELL a parte reputo sia alquanto banale…
…spero che arriverà il momento di abbandonare l’architetura X86 e di migrare verso nuovi orizzonti…
Mi sembra molto difficile che si riesca a scalzare ormai Intel dal trono. Purtroppo.
@Mario: ti capisco, perché questo probabilmente è il più lungo articolo che abbia scritto.
D’altra parte se leggi quello precedente, altri lettori avrebbero voluto che trattassi già allora l’argomento.
In teoria avrei potuto spezzare quest’articolo in due parti, ma ti assicuro che una telenovela a puntate sarebbe stata controproducente.
Un po’ come quando finisce “Il signore degli anelli” e vorresti vedere subito “Le due torri”; poi finisci anche questo, e già vorresti assaporare “La compagnia dell’anello”. Insomma, per alcuni appassionati gli argomenti di tecnologia vanno letteralmente divorati, anche se c’è da perderci tempo.
Quando si sceglie di dare un taglio a un articolo di un certo spessore inevitabilmente c’è chi apprezzerà e chi, purtroppo, rimarrà scontento. C’è poco da fare. Mi spiace.
Non credo che il cell della ps3 non è un buon prodotto, anzi riuscendolo a domare si ottengono delle prestazioni piuttosto interessanti.
D’altro canto un po’ anche quello che avremo nel futuro prossimo con larabee e fusion sugli x86.
Potreste fare due versioni dell’articolo, una sintetica e una “espansa” cliccando un link che porta a quella completa.
Certo che però è più complesso…
brutto vedere quanto anche i fruitori di un blog tecnico si uniformino verso il basso chiedendo articoli piu’ brevi appena si entra sul tecnico
complimenti invece x l’articolo :)
@blackshard: Cell è una CPU orientata allo stream processing. In questo campo ha delle eccellenti prestazioni, ma non è indicata per calcoli di altro tipo.
@Dreadnought: già soltanto per realizzare quest’articolo e mettere assieme informazioni e pensieri ho impiegato quasi un giorno. :’|
E’ un’idea che sottoporrò al vaglio del mio responsabile, anche se mi pare difficile da realizzare per il target che si propone AD.
Comunque grazie per l’osservazione e a tutti per l’apprezzamento.
Mi accodo alla critica di floc. Questo e’ un blog tecnico ed e’ un piacere leggere articoli che non si riducono a 5 righe. Mi ricorda molto lo spirito pionieristico di Ars Technica.
Non cambiate il format di questo blog, e’ quello che lo rende cosi’ interessante da leggere e sopratutto una ventata di aria fresca in un mondo in cui la mediocrita’ e superficialita’ delle news/articoli di approfondimento e’ ormai dappertutto. ^_^
Domanda forse idiota, ma confidando sul fatto che non esistono domande idiote ma solo risposte idiote, provo a farla lo stesso :-)
Visto che è tornato in auge qui il discorso sulla farraginosità dell’architettura x86 e contando sul fatto che il trend porta lentamente ma inevitabilmente verso i sistemi a 64 bit…
… ma non si può cavare via dalle nuove CPU almeno la compatibilità con la modalità reale, il codice a 16 bit e quant’altro? Ma che probabilità ci sarà mai che un utente si compri un Core i7 per eseguirci un’applicazione MS-DOS (cosa peraltro impossibile in ogni caso, se stai usando un sistema operativo a 64 bit)? Se fosse tecnicamente possibile fare questo taglio, ci sarebbe un minimo di semplificazione dell’architettura o il guadagno sarebbe trascurabile?
Ciao
Filippo
@10
Il guadagno sarebbe trascurabile. E se fai questa domanda non hai idea di quanto software legacy mission critical è in circolazione. Ed ovviamente guai a toccarlo o riscriverlo!
@ 11 : Ma la domanda che fa filippo1974 e’ interessante.
Siamo sicuri che software dell’era dos a16 bit abbia senso farli girare nativamente su i7 e successivi ?
Voglio dire gia’ adesso, XP 64 e penso anche Vista 64 fanno totalmente a meno del sottosistema a 16 bit. Dove e’ la retrocompatibilita’ cosi’ tanto auspicata ?
E chiaro ormai che il trend per il supporto di applicazioni legacy andra’ fatto a livello software tramite virtual machines, e a questo punto e’ lecito chiedersi se sia strettamente necessario che l’hardware sottostante supporti ancora la modalita’ reale etc…
OT
Personalmente credo che il valore aggiunto di Appunti Digitali risieda proprio nella cura dedicata ai temi trattati.
Non c’è verso di entrare sul tecnico in 2 righe cercando di mantenere un tono divulgativo, senza essere semplicistici.
L’alternativa sarebbe quindi tornare ad argomenti più banali, che si prestino ad essere esauriti in poche righe, ma, portandoci a questo livello perderemmo l’interesse di una parte consistente della nostra audience, per metterci alla pari o giù di lì, con gli adolescenti brufolosi che rimasticano & sputano le banalità che circolano sulla rete, a caccia di qualche click da google.
Io credo che gli sforzi dei nostri autori valgano bene 5 minuti del tempo dei lettori, e i risultati che vedo ogni settimana me lo confermano.
Alla luce di queste considerazioni, rigiro la domanda a voi: siete certi che alleggerire i contenuti ci farebbe bene? Io non credo.
/OT
Alessio di Domizio ha scritto :
“Alla luce di queste considerazioni, rigiro la domanda a voi: siete certi che alleggerire i contenuti ci farebbe bene? Io non credo.
”
Io credo che farebbe un danno piu’ che altro. Ce’ gia’ il vostro sito partner che si occupa di fornire news “leggere” anche purtroppo a livello di recensioni.
Io vi considero alla stregua di Nature o di Science.
Un posto dedicato alla lettura di articoli di approfondimento per dei lettori eruditi. Non inseguite a tutti i costi un livello “mediocre” non farebbe ne’ alla vostro blog ne’ tantomeno ai vostri lettori.
@ Anonimo Codardo
La mia domanda nasce evidentemente da una non conoscenza, come dici tu, di quanto software “vecchio” sia ancora utilizzato e quanto questo possa essere mission-critical.
Io mi chiedo solo se questo tipo di software verrà mai fatto girare su una macchina attuale (o peggio futura): contando che su una CPU x86 con estensioni a 64 bit (x64) fatta funzionare in modalità x64, il software a 16 bit *NON CI PUO’ GIRARE* (non è una menata di Windows, è una limitazione hardware delle CPU x86), e contando che i sistemi a 64 bit sono in costante crescita, mi domando fino a quando avrà ancora un senso portarsi dietro la retrocompatibilità fino all’8086, come in effetti oggi avviene.
Se mi dici: non ha senso, ma comunque anche levandola non cambierebbe nulla, né a livello di semplicità architetturale né sul piano dell’efficienza (consumi energetici in primis) allora ritiro tutto, anche se un po’ mi dispiace :)
Ciao
Filippo
Come al solito un articolo interessante.
Sicuramente la complessità di una CPU negli anni è aumentata e la diversità del bit size dei vari elementi ne è una prova.
Personalmente, e per semplicità, considero l’architettura di una CPU nel numero di bit che Accumulatore/ALU può operare nel singolo ciclo di clock.
Così, ad esempio, entrambe le cpu intel 8088 e 8086 sono a 16 bit ma poichè il bus verso il mondo esterno dell’8088 è ad 8 bit le performance (a parità di condizione) dell’8086 sono migliori.
@filippo1974: come ti è stato già risposto, il costo della soluzione è irrisorio (vedi anche il mio articolo su ARM vs Intel, in cui parlo specificamente della decodifica delle istruzioni), e in ogni caso con l’affermazione delle architetture a 64 bit scomparirà e verrà, quindi, relegata all’emulazione la vecchia ISA 8086 (perché non si può virtualizzare una risorsa che non c’è, per cui non si può ricorrere a questo prezioso e utilissimo meccanismo; e qui rispondo anche a goldorak).
@nico: però così stai legando anche al tempo la capacità di un dispositivo di effettuare un’operazione. Quindi un problema puramente prestazionale, come lo era col 68000.
Solo che il 68000 alcune operazioni a 32 bit le eseguiva comunque velocemente (incremento del PC e autoincremento di un registro indirizzi).
Quindi sarebbe difficile, anche col tuo “metro” (ovviamente legittimissimo, sia chiaro! :)), dare una risposta in questo caso.
Puo’ essere ancora piu’ complicato, dato che non sempre all’aumentare dei bit aumentano le prestazioni. Se puo’ essere vero su x86-64 (grazie ad un maggior numero di registri rispetto alle modalita’ a 32 bit), su altri processori il codice a 64 bit puo’ portare ad un degrado di prestazioni (d’altronde il codice a 64bit occupa piu’ memoria e rende le cache meno efficienti).
Sun per esempio consigliava di compilare a 32 bit su Solaris e SPARC64 tutti i programmi che non necessitassero di accedere a piu’ di 4GB di RAM. In questo caso si aveva un miglioramento delle prestazioni del 15-20%.
Esattamente. Avevo intenzione di parlarne in un prossimo articolo, ma citando PowerPC come architettura che presentava il calo di prestazioni col passaggio ai 64 bit.
Il cell è un ottimo processore, purtroppo l’utilizzo del gfx di estrazione Nvidia rende la ps3 una console per cosi’ dire “normale”, avrei preferito che ci fosse un cell + gfx in un’unico cpu package e un bus unico verso la ram…
per quanto riguarda l’architettura x86 il problema non è mantenere la compatibilità con i vecchi sistemi x86 o i nuovi, il problema sono le decine di istruzioni ormai presenti in questa architettura tra x86+x64+MMX+SSE+VIRTUALIZZAZIONE insomma un enorme calderone…
avere un microcode piu’ snello ed efficente permetterebbe di semplificare l’architettura e soprattutto di far quadrare meglio l’economia interna della CPU…migliori consumi e piu’ efficenza……
Il Cell è un ottimo stream processor, non una CPU che può andare bene per qualsiasi cosa. E’, quindi, un microprocessore altamente specializzato.
Per la PS3, non credo che sarebbe migliorata di molto mettendo assieme CPU e GPU nello stesso package.
Innanzitutto Cell è un microprocessore enorme e all’epoca la tecnologia non lo avrebbe permesso. Considera che questa soluzione arriverà per la 360 soltanto quest’anno (se non erro) e la XCPU possiede all’incirca la metà dei transistor di Cell (le GPU sono comparabili).
Per quanto riguarda l’uso di un bus unico, sono titubante. Adesso la PS3 ha due bus, per cui può eseguire due accessi concorrenti alle rispettive memorie, e credo sia la soluzione migliore.
Per com’è stata concepita la PS3, una soluzione con bus unico tipo la 360 non avrebbe prodotto gli stessi risultati (ci sarebbe stata troppa contesa fra CPU e GPU per l’accesso alla memoria).
Sugli x86 concordo sulla semplificazione dell’architettura, che è troppo incasinata (avrei preferito che AMD avesse effettuato una bella reingegnerizzazione con x86-64), ma dal discorso toglierei fuori le estensioni SIMD.
Questo perché tutte le architetture ormai dispongono di queste unità di calcolo e aggiungono tante istruzioni dedicate allo scopo.
Dai un’occhiata a questo: http://personals.ac.upc.edu/alvarez/media/media_isa.html
I problemi che si porta dietro x86 sono la modalità reale 8086, e la presenza sia di IA32 che di AMD64 come set d’istruzioni. Sarebbe stato meglio avere soltanto quest’ultimo, ma ci siamo arrivati soltanto qualche anno fa, ma non se ne può fare una colpa a Intel o AMD perché i processori a 64 bit hanno preso piede soltanto negli ultimi anni. Prima sarebbero stati transistor inutili e, anzi, avrebbero creato soltanto problemi.
Ma l’implementazione attuale, con la coesistenza di modalità diverse, non è tanto pesante. Le unità di decodifica delle istruzioni fanno un ottimo lavoro, e la presenza di più ISA la riterrei trascurabile con tutti i milioni (ormai miliardi) di transistor che ci sono in una CPU.
Rimane il fatto che, come avevo rimarcato nel mio precedente articolo su ARM e Intel, la struttura e la mappatura degli opcode nell’ISA x86 è realizzata veramente malissimo. Troppo incasinata, e richiede una sezione di decodifica complicata.
che il cell non possa andare bene per qualunque cosa non sono d’accordo in quanto comunque è una cpu “general purpose” avere un bus diretto con il raster engine direttamente nel package della cpu eviterebbe di avere due bus esterni alla cpu visto che la memoria XDR riesce a gestire il volume di dati…
per quanto riguarda l’architettura x86 purtroppo sono 15 anni che si vuol mandare in pensione questa architettura senza successo…la paura da parte di intel di perdere fette di mercato ha sempre la meglio…ma stiamo arrivando al punto di non ritorno…con le tecnologie multi-thread avere un’architettura CISC è anacronistico…
Homero, se sei lo stesso utente del forum di hwupgrade, sai benissimo che è la stessa Intel che ha cercato di uccidere la sua creatura, con Itanium che avrebbe dovuto arrivare perfino sui desktop.
La madre non è riuscita a uccidere il figlio, perché il mercato gliel’ha impedito. E tutti, dico proprio tutti, ci ritroviamo ancora a usare x86. Credo sia il caso di essere realisti e metterci l’anima in pace: è molto difficile che un’altra architettura, per quanto buona, bellissima, ecc. riuscirà mai a prendere il suo posto.
Per quanto riguarda il multi-thread, non vedo perché un’architettura CISC non possa trarne ampii benefici.
Tornando a Cell, questa non è una CPU general purpose. Perfino IBM la chiama “stream processor”, e non può essere certamente la sola PPE (unica unità “general purpose”) a contribuire alla sua “generalità”. L’architettura rimane fortemente sbilanciata (e specializzata) a causa della presenza delle 8 SPE, che… sono fatte per elaborare stream di dati.
Poi, per carità, potresti benissimo sfruttare le SPE per fare eseguire loro compiti general purpose, ma prova a immaginare quanto lavoro ed enorme spreco di risorse ci sarebbe per realizzare un banalissimo emulatore 6502 (figuriamoci emulare un intero Commodore 64).
Infine, già adesso Cell ed RSX hanno un “bus” (in realtà è un collegamento punto-punto, il FlexIO) dedicato per la loro comunicazione, che garantisce una banda elevata per il trasporto dei dati.
Quindi la situazione non sarebbe cambiata molto. Anzi, a mio avviso sarebbe peggiorata perché la sola XDR non è affatto sufficiente a garantire la banda necessaria sia a Cell che a RSX per portare a termine i rispettivi lavori.
Già adesso la sola GDDR3 non è sufficiente a RSX, visto che l’accesso al framebuffer e alle texture si porta via quasi tutta la banda, e i programmatori devono fare i salti mortali per cercare di sfruttare le risorse e poter implementare roba come HDR e AA (in genere i titoli PS3 ne sono sprovvisti, oppure usano o l’AA Quincux o l’HDR; è molto difficile vedere titoli che sfoggino contemporaneamente AA 4X MSAA e HDR).
con le tecnologie multi-thread avere un’architettura CISC è anacronistico…
si potrebbe quasi dire che l’ architettura x86 fosse già anacronistica 25 anni fa, date le sue limitazioni, la sua complessità, la sua mappatura degli opcode, i suoi compromessi di design (in parte dovuti alla fretta di finalizzare il progetto iniziale), e il modo in cui questi, assieme alla priorità data alla compatibilità all’ indietro, ne poi hanno condizionato lo sviluppo
ma si tratta di problemi che riguardano l’ x86 e solo quella , visto che già nello stesso periodo esistevano architetture a loro volta CISC ma molto più pulite ed eleganti e non meno prone (se non di più) a scalare e ad essere aggiornate in successive generazioni
vedi lo zilog z8000, o il motorola 68000, negli anni 80 usato sui principali sistemi home e personal – ma non solo – (cosa che spesso mi porta a chiedermi come sarebbe cambiata la storia dell’ informatica, se IBM vi avesse basato il PC/AT originale, in luogo del 286 a 6(!) mhz che ha invece adottato) – se poi si considera che con le cpu successive della serie, motorola cercò di semplificare il set di istruzioni rimuovendone e TRAPpandone alcune, invece di aggiungerne…
MA, mi sfugge il motivo per cui il sw multithread (o meglio, il fatto che oggi, prima decade del nuovo millennio, si faccia tanto parlare di parallelizzare il codice per sfruttare al meglio le cpu multicore) mal si concili con una ISA di tipo CISC in genere, od anche con l’ essere x86 di tipo CISC, ed implicitamente renda necessario migrare a un’ architettura differente (magari RISC con istruzioni a lunghezza fissa – che semplificano la decodifica ma implicano una maggiore pressione sulla cache e sulla memoria, visto che lo stesso numero di bit è usato per istruzioni alu come per istruzioni senza parametri – e con più numerosi registri general purpose – che richiedono un numero maggiore di cicli per il salvataggio e recupero durante il context switch )
Mi unisco al coro di quelli che chiedono di non semplificare gli articoli, internet è pieno di articoli superficiali e “leggeri”.
I miei complimenti a Cesare e a tutta la redazione per gli articoli sempre interessanti, mi raccomando continuate così.
L’arte del marketing e l’ansia da prestazione: la “misura” in “bit” di CPU & affini…
In un precedente articolo ho parlato di “misura dei bit” dell’architettura di un sistema, e ho intenzionalmente tirato fuori una definizione ricorsiva, che faceva uso di altre definizioni per finalizzare se stessa.
Ciò non per sadismo o mancanza…