Qualche giorno fa Agner Fog, un esperto di architetture x86, ha rilasciato sul suo blog un articolo relativo alle problematiche di quest’ISA relativamente alla sua implementazione, estensione e utilizzo da parte dei programmatori.
I punti salienti sono stati riassunti da AnandTech e consistono sostanzialmente nel fatto che ci sono troppe istruzioni (oltre un migliaio secondo l’autore), ne sono presenti ancora di obsolete, la decodifica è complicata, c’è una guerra che si combatte a colpi di estensioni fra i produttori di CPU x86, e infine il supporto di tutte queste aggiunte / variazioni è troppo costoso.
Debbo dire che mi trovo abbastanza d’accordo con quanto espresso (d’altra parte sono cose ben note a chi studia o lavora con quest’ISA), ma ritengo sia necessario effettuare dei distinguo e delle precisazioni, per meglio comprendere la portata di alcune affermazioni.
Che x86 sia un pastrocchio nato male (8086) credo sia un pensiero comune, e pochi sarebbero disposti ad affermare il contrario. Agli enormi limiti strutturali Intel ha posto rimedio nel tempo, estendendo lo spazio d’indirizzamento (80286), portando gli agognati 32 bit (80386), e il concetto di SIMD (le famose MMX), trovando principalmente in AMD un valido avversario che ha introdotto i 64 bit (x86-64) e alcune interessanti estensioni SIMD (3DNow!), con Via infine a fare da gregario ma con qualche contribuito (AES, generazione di numeri casuali, SHA 1 e SHA-256).
Questo processo di estensione ha comportato una rivisitazione della tabella degli opcode, che essendo a 8 bit è arrivata velocemente a saturazione (già con l’8086 gli slot era quasi del tutto assegnati), per cui si è dovuto escogitare il meccanismo dei prefissi per aggiungere nuove tabelle di opcode (sempre a 8 bit) sfruttando i pochi spazi vuoti rimasti. In parte l’argomento è stato trattato in un mio precedente articolo (in cui mettevo a confronto le ISA ARM e x86 in prospettiva dei consumi).
Da qui le istanze di Agner, che rimarca come tutto ciò penalizzi non soltanto le implementazioni, che necessitano di sezioni di decodifica decisamente complesse che comportano un aumento della dimensione del chip e dei consumi, oltre a richiedere specifico supporto da parte degli sviluppatori per poterne sfruttare le capacità (se c’è una nuova funzionalità e non la si sfrutta, o la si sfrutta male, sostanzialmente occupa soltanto spazio e assorbe energia).
In realtà l’argomento decoder delle istruzioni x86 non è così semplice da trattare (come ho sottolineato nell’articolo che ha messo a confronto le unità di decodifica di ARM e x86), e ciò perché le implementazioni più recenti (da un po’ di anni a questa parte) rappresentano già un ottimo nonché flessibile strumento che difficilmente richiederà un aumento spropositato del numero di transistor dedicati allo scopo.
La situazione è, insomma, relativamente stabile, com’è possibile visionare dalla sezione di decodifica dell’Athlon 64, ad esempio, che è ben visibile nonché dettagliatamente spiegata nell’immagine che si trova in questo link . Da notare che si tratta di una piccola parte dell’intero chip (in cui è evidente come la parte del leone la facciano i 512KB di cache L2), e a sua volta la funzione di decodifica è ridotta a pochi elementi che occupano anch’essi poco spazio.
Se consideriamo che il primo Athlon64 integra e ha il pieno supporto per le seguenti ISA:
- l’originale 8086
- l’80286 (modalità protetta a 16 bit)
- l’80386 e successive estensioni (80486, Pentium, e PentiumPro in primis)
- l’x86-64
e per le seguenti estensioni:
- MMX
- 3DNow!
- SSE 1 & 2
è comprensibile come il decoder, per quanto sicuramente molto complesso, non rappresenti più un problema di primaria e strategica importanza, anche nell’ottica delle future estensioni SSE5 da parte di AMD, e AVX da Intel (che ovviamente richiederanno un suo aggiornamento e ulteriore complicazione).
Lo è sicuramente su scale minori come Atom, ad esempio, che ha bisogno di contenere il numero dei transistor e il consumo, in quanto si colloca su una ben precisa nicchia di mercato. Non lo è su scale maggiori, dove il numero di transistor è decisamente più elevato e riservato a ben altre aree, com’è possibile in parte visionare da quest’altro link (in particolare per i chip di cui è disponibile uno spaccato particolareggiato delle varie sezioni).
Per quanto riguarda il numero di istruzioni, bisogna vedere in che modo vengano conteggiate. Penso che il migliaio lo si raggiunga sicuramente in termini di opcode conteggiati con relativi prefissi, ma non credo sia la strada giusta da seguire. E’ necessario tenere presente che i prefissi o parte dei bit dello stesso opcode “abilitano” o “disabilitano” particolari funzionalità, ma sempre della medesima istruzione.
Questo si verifica non soltanto per l’architettura x86, ma anche per tante altre. Per fare un esempio completamente diverso, l’istruzione LDM (Load Multiple registers) degli ARM prevede diverse modalità d’indirizzamento, nonché modalità di funzionamento e aggiornamento dei registri indirizzi, ma nell’elenco delle istruzioni ne risultano appena tre che fanno capo a essa.
Non v’è dubbio che il numero di istruzioni degli x86 sia in generale molto elevato rispetto alle altre CPU, ma sicuramente non siamo nell’ordine del migliaio (quelle legacy, poi, rappresentano una piccola parte). Inoltre c’è da aggiungere che la maggior parte ormai è legata alle estensioni SIMD, che rappresentano praticamente l’unica fonte di novità su questo fronte (molto difficilmente ne vengono introdotte all’ISA principale, e quando ciò avviene si tratta pochissime e magari singolari unità).
Infine sull’argomento supporto la situazione è effettivamente quella descritta: a conti fatti soltanto Intel viene supportata, perché ha in mano la maggioranza del mercato ed è l’unica che produce compilatori di qualità (ma supporta anche il GCC) che, per ovvie ragioni, funzionano bene o esclusivamente sui suoi prodotti. I concorrenti non hanno sufficiente know-how o risorse da dedicare allo scopo, e ciò inevitabilmente gli si ritorce contro.
L’unico spiraglio di concorrenza è rappresentato dalle estensioni relative alla virtualizzazione, visto che il supporto dev’essere garantito dai programmatori, che a questo punto però si ritrovano a dover scrivere codice diverso a seconda dell’ISA. In pratica l’onere è spostato sulle loro spalle, e ciò è sicuramente seccante.
In ogni caso, sia per le estensioni all’ISA che per quelle relative alla virtualizzazione, il risultato è che il codice prodotto, dovendo tenere conto di tutto ciò, occupa anche molto più spazio, poiché contiene i diversi code path che verranno selettivamente scelti al momento dell’esecuzione a seconda della CPU su cui gira il codice.
Secondo l’autore dell’articolo buona parte dei problemi esposti finora si risolverebbero se l’evoluzione dell’architettura fosse affidata a un collegio di aziende anziché all’arbitrarietà delle singole. Questo è in parte vero, perché eviterebbe sicuramente che ognuno reinventi la ruota (cioè istruzioni & opcode diversi per fare esattamente la stessa cosa) e costringa poi gli altri a supportarla, ma non sarebbe la soluzione definitiva, e questo per due motivi.
Il primo è che, anche se di “ruota” ce ne fosse soltanto una, la nuova richiederebbe comunque una soluzione ad hoc per poter essere sfruttata, che si dovrebbe necessariamente affiancare a quelle esistenti per le altre architetture. Quindi i code path continuerebbero a esserci in futuro, ma soltanto in numero limitato (uno in più alla volta, anziché n, uno per ogni azienda che ha tirato fuori la sua estensione proprietaria).
Il secondo è che in tutto ciò non si tiene conto dell’implementazione della medesima ISA, che può essere molto diversa e richiedere pertanto una soluzione ad hoc per essere adeguatamente sfruttata. Prendiamo ad esempio il Pentium 3, il 4 e il Pentium-M (che si sono susseguiti nel tempo): mettendo per il momento da parte le unità SIMD, si tratta di tre implementazioni diverse della stessa ISA, che richiedono codice diverso per ottenere le migliori prestazioni.
Questo lo si evince in particolare andando a leggere il manuale di Intel per le ottimizzazioni, che raccomanda anche soluzioni decisamente diverse a seconda della particolare implementazione. Lo stesso si potrebbe dire dei microprocessori di AMD, visto che fra K6-2/3, K7 e K8 ci sono delle differenze anche notevoli che richiedono code path specifici per ottenere le migliori prestazioni.
In definitiva il problema dei code path diversi continuerebbe comunque a esistere sia per le inevitabili estensioni (il mercato si evolve, e le ISA pure perché devono soddisfarne le esigenze) sia per le diverse implementazioni (tanto più se confrontiamo un Core Duo 2 con un Atom: le differenze sono abissali), ed è bene che i programmatori ne prendano atto…
“che a tirato”
Per il resto, articolo molto interessante.
“se l’evoluzione dell’architettura fosse affidata a un collegio di aziende” …. la vedo dura :)
Corretto grazie (e condivido l’opinione :-P)
Ottimo articolo
P.s. Correzione “confrontiamo un *Code* Duo 2 con un Atom”
Ciao
Grazie. Qualcosa scappa sempre anche dopo numerose letture. -_-
E’ un piacere leggere articoli cosi’ ;)
ormai lo Yoss’ Day e il CDM’s Day sono appuntamenti fissi :) ancora complimenti, una delle poche testare italiane che tiene testa ai mostri sacri stranieri (AT, ArsTechnica, HardOcp, Beyond3d etc etc) per quanto riguarda la completezza e la profondità degli articoli
Anche se è vero che lo spazio occupato sul die non è così esteso, con le tue considerazioni sminuisci un pò troppo l’importanza dello stadio di decodifica.
Ricordiamoci che entra in gioco per ogni singola istruzione eseguita da un processore. Quindi a parte le SIMD (e forse le AMD64) per tutto il resto è la parte di un processore x86 più attiva di questi tempi. Una sua semplificazione dovrebbe ridurre i consumi molto più di ciò che farebbe pensare la sola superficie occupata.
Ricordo che un transistor che lavora consuma di più di uno che non lavora.
Non ne ho sminuito l’importanza, ma gli ho dato il giusto peso. Lo puoi notare anche dal precedente articolo (a cui questo è, in parte, collegato) dov’è stato affrontato proprio il tema del decoder nell’ottica prestazioni / consumi.
Tra l’altro non è nemmeno corretto dire che è sempre attivo. I decoder di oggi sono estremamente evoluti e permettono di memorizzare nelle cache alcune informazioni utili alla decodifica, che permettono di sfruttare dei decoder molto più semplificati (vedi il caso degli Athlon).
Altra tecnica è di decodificare una sola volta le istruzioni in micro-ops, memorizzandole nella cache codice L1 (vedi l’architettura NetBurst del Pentium 4).
Certo, semplificarli aiuterebbe molto per quanto riguarda numero di transistor e consumi, ma… bisognerebbe cambiare ISA. E non mi pare che si possa discutere questo. :D
Sono d’accordo con Denis… e con Cesare :)
Voglio dire: il front end, come numero di transistor, e’ sicuramente piccolo, ma come fa notare Denis e’ anche uno dei piu’ attivi (deve funzionare SEMPRE, ad ogni ciclo di clock). Inoltre, la banda di fetch e’ il limite superiore alle performance del processore (non puoi elaborare piu’ istruzioni di quante ne decodifichi), e in certi casi istruzioni complesse rallentano il fetch e quindi tutto il resto (da qui l’estrema importanza dei compilatori, come sottolienato nell’articolo).
Per Cesare: quando parli di “informazioni nelle cache” immagino tu ti riferisca al predecoding. Certo, il predecoding aiuta molto lo stadio di front-end… ma a che prezzo! La dimensione delle cache cresce, e non di poco. Se ricordo bene, i K5 avevano 5 bit extra per ogni byte di istruzione, un aumento del 60% ! E quella e’ area == costo == energia, ed essendo a livello di L1, costa abbastanza (anche quella e’ sempre acceduta ad ogni ciclo). E quindi, impatta anche a livello di bus di comunicazione (i tuoi 64 bit sono diventati 104 :) (conti spannometrici, eh! non so quanto prefetch fa un Nehalem, per esempio).
E se vuoi memorizzare direttamente le uops, come nella trace cache del P4… diventa ancora peggio! Quel blocco consumava cosi’ tanto che infatti e’ scomparso nelle microarchitetture successive.
Peraltro, non e’ che avere istruzioni RISC sia la soluzione a tutti i mali: anche quelle, ora, usano un po’ di predecodifica in cache (per identificare i branch, ad esempio), anche se meno di x86. E cmq, occupano molto piu’ spazio, quindi siamo un po’ daccapo :)
Scusate per la tirata :)
io ho una curiosità! nn si potrebbe realizzare una cpu SOLO con isa x86-64 e senza 8086, 80286, 80386 e successive estensioni (80486, Pentium, e PentiumPro in primis)? ovviamente da usare solo cn sistemi a 64 bit! se uso un sistema a 64 bit e solo programmi a 64 bit che me ne frega di tutto quello che c’era prima?
@pleg. Sì, mi riferisco ai bit di pre-decodifica, che sono (quasi) 5 anche nei K8. La linea di cache è di 128 bit, a cui si aggiungono diversi altri bit (pre-decodifica, branch-selector, parità) per un totale di 204 bit fra dati veri e propri e informazioni “accessorie”. E sono veramente tanti (ma fanno il loro sporco lavoro :D).
Il bus di comunicazione, comunque, riguarda esclusivamente l’unità di decodifica e la cache L1, per cui non influisce su tutto il resto (nel senso che i bit aggiuntivi sono assolutamente trasparenti “fuori” dalla cache L1).
Per quanto riguarda il P4, è vero che consumava molto, ma non è stato del tutto rimosso il concetto su cui era basata la sua architettura. Ad esempio nei Nehalem c’è una forma di trace cache che riguarda le istruzioni eseguite all’interno dei loop.
Adesso non ricordo con esattezza i numeri, ma se non ricordo male la sezione di decodifica può arrivare a cachare fino a una ventina di micro-op disabilitando, quindi, il decoder in questi casi (è del tutto inutile che continui a lavorare). E un decoder disattivato è un bel risparmio per quanto riguarda i consumi (anche se, come dicevo, con CPU che integrano più di un miliardo di transistor non so quanto possa incidere).
E’ una soluzione di compromesso. Il classico colpo al cerchio e alla botte, perché l’idea di sfruttare le micro-op già decodificate non è male di per sé, anzi; ma lo è stato sfruttare il concetto per tutto (eliminando completamente la vecchia cache L1 per il codice), perché in questo modo s’è anche ridotto notevolmente lo spazio per mantenere le istruzioni in cache a causa della dimensione fissa e lunga delle micro-op (anche qui non ricordo con esattezza i numeri, ma era qualcosa nell’ordine dei 110 bit circa).
Sul resto concordo e, anzi, commenti come quello di Denis e i tuoi sono benvenuti, perché permettono di chiarire alcune cose che non ho potuto trattare vuoi per il tema, per la lunghezza dell’articolo, o per pura mia dimenticanza o ignoranza (c’è anche questo, ed è un fattore non trascurabile :D).
@ zephyr83 : eh eh se fosse cosi’ semplice come dici tu a quest’ora avremo IA 64 sui nostri pc invece di x64.
Fatto sta che volente o nolente ci dobbiamo portare dietro una retrocompatibilita’ necessaria dettata in larga parte dal predominio/monopolio Microsoft.
E lo scotto che paga x86, il doppio filo tra Intel e Microsoft.
Apple non ebbe alcun problema nel passare da una isa ad un’altra di per giunta completamente incompatibile con la precedente. Come fece ? Disse ai suoi sviluppatori o cosi’ o la porta. E tutti si adeguarono. ^_^
@zephyr83: in teoria sarebbe fattibile, ma non molto utile considerando la marea di codice a 32 bit che esiste ancora.
Comunque la risposta è sì: implementare esclusivamente l’ISA x86-64 è possibile, con l’aiuto però di un BIOS o EFI apposito che sia nativo per questa modalità (perché normalmente al reset, almeno col BIOS, la CPU parte in modalità reale 8086, e soltanto dopo avviene il passaggio alla modalità protetta a 32 o 64 bit).
Ciò semplificherebbe il decoder, ma rimarrebbe abbastanza complicato a causa di tutto il discorso sui prefissi e per come sono implementati gli opcode. Doveva pensarci bene AMD a sistemare l’ISA almeno nella modalità a 64 bit, ma l’esigenza di rimanere quanto il più possibile compatibili all’indietro e, soprattutto, di sfruttare la logica di decodifica già presente, penso l’abbia indotta alla definizione della nuova ISA in maniera conservativa.
@goldorak: concordo. Tra l’altro sarebbe ora di relegare le vecchie ISA (quanto meno 8086 e 80286) alla pura emulazione: questo permetterebbe di semplificare il decoder, al prezzo di una minor velocità di esecuzione (che non credo sia vitale per programmi che risalgono agli anni ’80).
@ Cesare di Mauro : con me spalanchi una porta aperta. ^_^
Bios, modalita’ reale, e tutto il “ciarpame” con rispetto parlando che ci trasciniamo dagli anni 80 andrebbero ELIMINATI senza se e senza ma.
Io lo vedo di buon occhio un chip a 64 bit la cui ISA e’ totalmente incompatibile con x86. Per questo in un certo senso mi e’ dispiaciuto che IA 64 non abbia avuto il successo sperato in quanto preso Intel fu presa in contropiede da AMD.
@ Cesare
Se ricordo correttamente, la mini uop cache del Nehalem per piccoli loop e’ di 28 uops (ma son dettagli). Mi ricorda un po’ quello che fanno alcuni DSP.
Ultima cosa prima di scappare! abbiamo tutti dimenticato di citare l’altro impatto che ha un’ISA complessa come la x86: la latenza! Per decodificare x86 bisogna dedicarci parecchi stadi di pipeline; questo allunga la pipeline, aumenta le penalita’ di branch misprediction (riducendo le performance), e quindi richiede di usare predittori piu’ precisi (e quindi piu’ complessi e consumosi)…
@goldorak. A me invece no: IA64 era una pessima ISA. :D Sulla carta un gioiello di ricerca & ingegneria, ma poi le prestazioni general purpose lasciavano a desiderare a causa del fardello spostato sulle spalle dei compilatori (per eliminare la logica out-of-order).
Se ISA nuova dev’essere, allora né CISC né RISC: preferisco un CRISP progettato come si deve, che sia un compromesso fra i pregi della compattezza del codice tipico dei CISC e la leggerezza del decoder dei RISC. ;)
@pleg: concordo, ma anche i RISC ormai hanno pipeline parecchio lunghe, e pure lì latenza e penalizzazioni si fanno sentire. :P
Bhe fra qualche anno però potrebbe essere possibile che iniziano a realizzare cpu solo cn isa x86-64. Vedo che ormai windows seven viene installato sempre più nella versione a 64 bit. Se si adeguano anche i programmi nn ci sarà più bisogno anche delle vecchie isa. Ma in questo caso, cn una cpu solo x86-64 però poi neanche cn la virtualizzazione funzionerebbero i vecchi sistemi operativi e i programmi vero? Bhe allora forse ci vorrà più di qualche anno mi sa :D però magari qualche versione particolare potrebbero rilasciarla lo stesso, magari per apple o per sistemi in cui il risparmio energetico è importante o su workstation dedicate
Soltanto x86-64 a disposizione più che di virtualizzazione bisognerebbe parlare di emulazione, e questa è decisamente lenta.
Per le vecchie architetture a 16 bit che ho citato prima non ci sarebbero problemi, ma per quelle a 32 bit sì, eccome, proprio perché sono troppo diffuse e ci sono ancora vagonate di software che sono o val la pena di essere utilizzati.
Sì, qualche esperimento si potrebbe fare. E’ da parecchio tempo che penso a un’ISA x86-64-only che abbia integrata giusto qualche funzionalità atta all’accelerazione dell’emulazione delle vecchie ISA. Sarebbe un buon compromesso e permetterebbe di risparmiare un bel po’ di transistor.
@ Cesare di Mauro : io non sarei cosi’ perentorio nel decretare l’ISA del IA 64 come scadente. E vero che spostava l’onere sul compilatore per avere del codice “prestante”, ma se ce’ una cosa che Intel sa fare coi fiocchi sono proprio i compilatori.
E un po’ lo stesso dibattato che si riscontra tra la visione AMD/ATI e Nvidia sulle gpu. I primi fanno affidamente su una ottimizzazione software, Nvidia invece preferisce delegare all’hardware l’ottimizzare del flusso di istruzioni.
Le prestazioni di IA 64 erano scadenti quando si trattava di eseguire codice x86 perche’ emulava ogni singola istruzione.
Ma per codice a 64 bit puro beh li la storia cambia.
Purtroppo non è così e non riguarda l’esecuzione di codice x86. I compilatori di Intel, per quanto buoni, non possono fare miracoli; soprattutto non possono conoscere la situazione a runtime e decidere in quel preciso momento cosa è meglio fare.
Difatti e come dicevo prima, le prestazioni di Itanium nel codice general purpose hanno sempre lasciato a desiderare, costringendo Intel a integrare abnormi quantitativi di cache L3 per cercare di mitigarne gli effetti.
Sulle prestazioni floating point nulla da dire, ma è anche vero che sono quelle più “linealizzabili” e “prevedibili” come pattern di accesso alla memoria e di utilizzo delle risorse. Tant’è che negli ultimi anni non a caso s’è imposto il modello SIMD. ;)
Tra l’altro è singolare che proprio HP abbia elaborato il modello EPIC per Itanium, a fronte delle ricerche che aveva già effettuato col suo progetto Dynamo, e che avrebbero dovuto suggerirle esattamente l’opposto, cioè di non affidarsi alla compilazione (statica) del codice.
Credo che l’enorme cache L3 fosse utile proprio per quelle applicazioni di number crunching dove l’Itanium andava forte.
Secondo me il problema dell’Itanium non era tanto la compilazione statica, quanto il fatto che, per superare le limitazione del paradigma VLIW puro, alla fine e’ venuto fuori quasi un processore superscalare out-of-order normale (come livello di complessita’ architetturale): se guardi lo schema, sembra un OOO normale, manca solo il reorder buffer :)
E quindi, alla fin fine non guadagni molto ne’ in semplicita’ della microarchitettura, ne’ in area (e quindi in costo), ne’ in consumo di potenza. O meglio: guadagni si’ non poco, ma non abbastanza da stare “avanti a Moore”: o la tua nuova microarchitettura riesce a darti un ordine di grandezza in piu’ rispetto alla vecchia, o nessuno vorra’ passarci, perche’ bastera’ aspettare qualche anno per colmare quel margine (questo discorso lo fece Gelsinger in persona qualche anno fa, quando ancora sperava nell’Itanium :)
Comunque, sembra che ormai ci stiamo dirigendo verso modelli multi-threaded e vettoriali per estrarre parallelismo e continuare a scalare con le performance, e il VLIW non fara’ ritorno nelle nostre CPU.
Il modello VLIW non l’ho mai visto bene per le CPU.
E a quanto ha detto chi ha avuto modo di lavorare con Itanium, i bundle contengono spesso delle NOP: segno che il compilatore, per quanto bravo, miracoli non ne può fare. Da cui le scarse prestazioni general purpose.
Poi sul number crunching nulla da dire: come capacità in virgola mobile è, forse, la migliore CPU.
Noto una certa somiglianza, in questo delicato argomento, con quanto stava accadendo qualche anno fa con le GPU: mi ricordo che anche in questo ambito era nata una discussione dovuta alle difficoltà degli sviluppatori nel creare tutti i possibili path, nel codice degli shaders, per poter “venire incontro” alle peculiarità delle varie GPU (si parla dei tempi delle prime GPU con supporto alle DirectX 9, quindi GeForce FX contro Radeon 9×00). Allora, MS corse ai ripari diramando specifiche più stringenti per le successive versioni delle DirectX, in modo da restringere la libertà di azione ai produttori di GPU. Non so però se qualcosa di simile (l’idea di far definire la ISA x86 ad un consorzio di Aziende) possa essere “esportabile” al mondo delle CPU. Sempre rimanendo in ambito GPU, se pensiamo che le specifiche delle OpenGL sono in effetti decise da un consorzio di Aziende, però alla fine ciascuno ci caccia sempre dentro le sue estensioni proprietarie, non mi pare che i risultati siano granché confortanti :-) Che ne pensate?
Ciao
Filippo
wow, è quasi più interessante leggere i commenti che l’articolo.
Comunque complimenti a tutti ;)
Grazie :)
@Filippo1974: sì, il pomo della discordia è esattamente lo stesso. Con OpenGL la situazione è quella che hai descritto, ed è anche stato il motivo per cui le DX le hanno superate: troppe estensioni da un lato, e dall’altro la sola MS che impone il da farsi. Poiché gli sviluppatori reclamano giustamente stabilità delle API, queste ultime hanno avuto il sopravvento.
Con le CPU la situazione è peggiore, e difficilmente ci saranno cambiamenti. Un consorzio che delinei lo sviluppo di x86, con Intel che ne detiene saldamente in mano le licenze, mi pare difficile da realizzabile.
Invece cn arm questo nn succede vero? oppure si? ad esempio, fra un cortex A8 e uno snapdragon nn ci sn alcune differenze? se nn sbaglio qualcomm ci ha messo un bel po’ del suo su snapdragon. in questo caso nn si può fare un discorso simile a inel e amd?
Sì che si può fare. Ottimizzare il codice per un ARM9 e un Cortex-A8 è abbastanza diverso, se si vuole sfruttare le peculiarità della CPU.
Per SnapDragon il discorso è simile, ma considera che c’è sempre un core ARM “classico”, a cui vengono aggiunte funzionalità specifiche.
Quindi possiamo dire che le attuali cpu intel e amd non sono nè risc nè cisc ma un “misto”?
ho fatto questa domanda nel forum di HU ma non ci sono state molte repliche.Non sono un tecnico quindi scusate se la domanda è posta male: sono architetture risc con una “tabella di traduzione” per istruzioni risc o cosa?
A livello di ISA (Instruction Set) sono dei CISC, e questo significa che per i programmatori sono a tutti gli effetti dei CISC.
Internamente tutte le istruzioni vengono convertite in micro-op, che sono istruzioni per un RISC dedicato che fa il lavoro vero e proprio. Ma questo processore RISC però NON è accessibile all’esterno: è del tutto trasparente.
Quindi, ricapitolando: all’esterno (e per i programmatori) sono CISC. Internamente si fa uso di un RISC dedicato.
Ne parlerò meglio in futuro articolo.
@ maurilio968
Brevemente. Possiamo distinguere 3 livelli:
* architettura (ISA): questo e’ il “contratto” tra l’hardware e il software, specifica tutte le istruzioni che i programmatori possono usare e che l’hardware si impegna ad eseguire correttamente (piu’ altre cose, come la semantica degli accessi alla memoria, eccetera). I programmatori possono usare queste istruzioni come vogliono, e i progettisti di hardware possono eseguirle come vogliono, non ci sono vincoli sopra o sotto: questo permette flessibilita’ sia a chi programma che a chi costruisce chip. Intel, 40 anni fa (o cose cosi’), invento’ x86, ed e’ valida (cioe’ “rispettata” dall’hardware) da allora.
* microarchitettura: questa e’ al di sotto dell’ISA, completamente dentro al chip e invisibile dall’esterno (dal punto di vista della correttezza formale del programma, non dal punto di vista delle prestazioni). E’ l’organizzazione interna del processore, fatta di cache, datapath, unita’ funzionali, bus, eccetera. Questa cambia ogni tot anni (due anni, secondo la strategia tick-tock di Intel). Quando si parla di “architettura della CPU”, in realta’ si intende la “microarchitettura” (questo livello qui).
* implementazione: questo e’ il circuito vero e proprio, il silicio. Puo’ cambiare spesso (per la stessa microarchitettura), specie quando implementano fix, piccole variazioni per migliorare qualche aspetto, soluzione di qualche semplice bug, eccetera.
Ora, l’architettura (ISA, x86) fu sviluppata nei tardi anni ’60 – inizio anni ’70, ed era CISC. Il fatto e’ che non puo’ piu’ essere cambiata (passatemela…): voglio dire che ormai esistono miliardi di processori, e decine di miliardi di linee di codice, scritte per x86. Cambiare l’architettura significherebbe dover rimpiazzare ogni processore x86 esistente, e ricompilare ogni linea di codice scritta per processori Intel negli ultimi 40 anni. Capisci che la cosa e’ assolutamente fuori discussione.
Negli anni ’80, la ricerca sulle architetture evidenzio’ certi limiti dell’architettura CISC. Venne proposta come alternativa il RISC, cioe’ un Instruction Set molto piu’ compatto, con poche istruzioni. L’obiettivo era di spostare molta della complessita’ dall’hardware verso il software (nei compilatori, per essere precisi, visto che la tecnologia dei compilatori cominciava a fare grossi passi in avanti). Questo avrebbe permesso di costruire hardware piu’ semplice, e soprattutto di sbloccare certe tecnologie (pipelining, esecuzione fuori ordine…) che sono impratiche da realizzare per un’ISA CISC, ma vengono molto bene per un’ISA RISC (appunto).
Ora, vedi da te il problema: se vuoi avere hardware piu’ veloce, devi muoverti verso un’architettura piu’ RICS-like. Ma non puoi, data la quantita’ di hardware e software gia’ esistente (come dicevo prima). Che fare?
Il dibattito CISC vs RISC ha infuriato per buona parte degli anni ’80 in ambito accademico, e poi negli anni ’90 gli ingegneri Intel (e non solo) riuscirono a fare il miracolo: un pezzo del processore, in testa al datapath, si incarica di “tradurre” al volo le vecchie istruzioni CISC in nuove istruzioni RISC-like (“uops” nel gergo Intel) che vengono poi eseguite dentro il processore. La cosa non e’ facile come sembra :)
Con questo riesci ad avere la botte piena e la moglie ubriaca :) continui a garantire la compatibilita’ col vecchio codice, ma dentro lo riorganizzi, spezzetti e riassembli come ti fa piu’ comodo. Quindi, l’architettura (il “contratto” tra hardware e software) non cambia mai, ma la microarchitettura puo’ cambiare eccome: tanto e’ invisibile dall’esterno!
Lascio il resto al futuro articolo di Cesare, che sara’ sicuramente molto piu’ dettagliato :)
Praticamente hai già detto tutto tu. :D
Mi riservo di trattare una riflessione sull’argomento CISC vs RISC che tengo nel cassetto da parecchio tempo. O:-)
Ottimo. comincio a capirne di più.
Aspetto l’articolo, o la serie di articoli, di Cesare Di Mauro.
Butto là un idea a Cesare e agli altri redattori di AD:
Secondo me la serie di articoli di Cesare e di yossarian sonomolto validi.Spesso sono molto valide anche tante risposte di utenti competenti che completano o consentono di approfondire l’argomento.
Non si potrebbe raccogliere gli articoli che hanno attinenza tra loro (includendo magari gli interventi degli utenti degni di nota) in dei PDF, come fossero degli articoli su riviste specializzate, e pubblicarli sotto licenza creative commons ?
I pdf potrebbero recare il logo di AD ed essere scaricabili dalle pagine di AD. Magari si potrebbero inserire anche pagine con pubblicità attinente al monfo IT in modo NON invadente, cioè non tra le pagine del PDf ma per es. all’inizio e alla fine.
Questo compenserebbe le mancate visite al singolo articolo sulle pagine di AD.
Senza contare poi che tali pdf potrebbero essere distribuiti legalmente tramite altri circuiti (per esempio il vituperato torrent qui sarebbe ottimo) e questo farebbe conoscere AD a molta più gente.
In giro non ci sono articoli divulgativi di questo livello in lingua italiana, secondo me farebbero “il botto”.
Intanto ti ringrazio per i complimenti. Giro l’idea all’editore e vediamo cosa ne pensa. ;)
Bene, intanto ho riportato l’intervento di Pleg e ho linkato questo articolo nella discussione che avevo aperto su HU qui
http://www.hwupgrade.it/forum/showthread.php?p=30031323#post30031323
ciao e buon lavoro.
Vorrei segnalare in proposito un articolo di Joan De Gelas, esperto di Anandtech, il quale si schiera totalmente a favore della tesi di Agner Fog, riportando alcuni “hard data” fra cui una considerazione che mi pare fondamentale: la difficile portabilità delle VM al variare delle estensioni della macchina di origine e destinazione. In questo senso mi pare che la questione si sostanzi pienamente come fidelizzazione forzata degli utenti da parte dei produttori di CPU, altrimenti detto lock-in.
http://anandtech.com/weblog/showpost.aspx?i=661
È l’ennesima incarnazione del problema degli standard in ambito informatico: una volta che esistono al di fuori del dominio di una specifica azienda, ognuno cerca di “tirarli per la giacchetta” con estensioni proprietarie, al fine di ostacolare la fluidità della concorrenza.
@ maurilio968
Thanks, spero che quello che ho scritto fosse comprensibile :)
@ Alessio
Vero, vero… ma perche’ Intel dovrebbe mai mollare la _sua_ ISA a qualche consorzio esterno e perderne il controllo? E poi consorzio fatto da chi? Intel e AMD? Mi sembra alquanto irrealistico :)
Scusate perdo colpi… ho ripostato un link già presente nell’articolo di Cesare :-(
@ pleg
Hai ragione, non esiste un motivo per i protagonisti di questa transizione e IMHO non esiste in questo campo la possibilità di uno standard industriale di terze parti esterne.
Mi domando: arriverà un punto in cui le inefficienze arriveranno ad una massa critica tale da giustificare un ripensamento del modello? O toccherà al software di coprire il gap?
Credo che sia una domanda da un miliardo di dollari :)
Mi sa che il problema si stia “verticalizzando”: non dovremo piu’ preoccuparci di sviluppare solo un’ISA piu’ moderna, ma di sviluppare un nuovo, intero ecosistema: nuovi modelli di programmazione che permettano lo sfruttamento del parallelismo in modo piu’ intuitivo per il programmatore (es: http://ppl.stanford.edu/wiki/index.php/Delite), librerie adeguate, compilatori che riescano a sfruttare l’hardware parallelo al meglio, hardware che riesca ad esportare modelli di parallelismo che scalino bene e che siano piu’ facilmente utilizzabili dai programmatori, eccetera. Sara’ da ripensare l’intera struttura — in questo senso, saranno anni eccitanti :)
Perche’ “i pasti gratis sono finiti” (Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm). L’hardware parallelo e’ qui e ci rimarra’.
PS: un’altra cosa interessante e’ quella che fanno i tizi della Maxeler, in Gran Bretagna. Loro sviluppano un intero sistema hardware-software integrato per risolvere un problema specifico.
Ho visto che hanno sviluppato anche un loro s.o.. :)
Beh, è una soluzione che paga sicuramente in termini puramente prestazionale, ma è anche altamente specifica.