Osservando la crescita esponenziale delle prestazioni dei nostri computer e i benchmark che anno dopo anno sfondano nuovi traguardi che prima sembravano irraggiungibili, viene naturale pensare che i produttori di CPU e GPU mirino sempre a produrre i chip più veloci che la tecnologia rende possibile. Non è così: come qualsiasi azienda, anche i chip makers hanno innumerevoli compromessi da soddisfare, tra cui prestazioni, consumo energetico, il costo del silicio e dello sviluppo delle tecnologie, lo sforzo ingegneristico richiesto, i limiti di validazione e testing, e altri ancora.
Circa due mesi fa, Glenn Hinton, Lead Architect per lo sviluppo della microarchitettura Nehalem, fece una presentazione in cui discusse la storia e le sfide dietro la realizzazione di questa architettura. Le slide e il video sono disponibili a questo link (è il settimo talk):
http://www.stanford.edu/class/ee380/winter-schedule-20092010.html
In questa serie di due articoli userò lo sviluppo di Nehalem come case study per illustrare i compromessi e le decisioni architetturali che stanno dietro la realizzazione di un processore di ultima generazione. In questo articolo discuterò della timeline, della decisione di Intel di sviluppare una singola architettura per tutti i segmenti di mercato (la strategia “converged core”), e dei requisiti fondamentali di tale architettura. Nel prossimo andremo più in profondità e analizzeremo le scelte ingegneristiche rigurdanti pipeline, core, cache e gestione dell’energia.
Timeline
La maggior parte dello sviluppo di Nehalem fu portato avanti nel sito Intel in Oregon (il più grande sito americano della compagnia di Santa Clara), su un arco di tempo di più di 5 anni. La ricerca di base sulla microarchitettura risale a prima del 2003; nel 2003-04 vennero prese la maggior parte delle decisioni architetturali, e il lavoro di ingegnerizzazione (sviluppo, validazione e testing) occupò più di 3 anni, dal 2005 al 2007 e oltre. I primi prodotti basati su Nehalem vennero lanciati nel 2008. Vale la pena ricordare che al culmine del processo di sviluppo di un chip di questa classe vi lavorano alcune migliaia di persone: questo significa che il lavoro è nell’ordine delle decine di milioni di ore-uomo.
Il modello di sviluppo "tick-tock" di Intel: il Nehalem è la nuova microarchitettura del processo a 45 nm.
Converged core: compromessi
All’inizio degli anni 2000, Intel sviluppava due diverse microarchitetture: una ad alte prestazioni (Pentium 4) nel sito di Hillsboro, Oregon, per desktop e server, e una a basso consumo (Banias) in quello di Haifa, Israele, per i portatili.
Se da un lato avere architetture dedicate per diversi ambiti permette di ottimizzare i processori per quei requisiti (alte performance VS bassi consumi), dall’altro richiede il doppio dello sforzo ingegneristico. Per questo Intel decise di sviluppare una singola architettura che andasse bene per tutti i segmenti di mercato (tranne per l’ultra-mobile, coperto da Atom): poter dedicare un maggior numero di risorse e personale ad un singolo progetto permette da un lato di ottimizzare e “rifinire” al meglio il chip (recuperando in parte lo svantaggio dato dai molti compromessi sui requisiti contrastanti) e dall’altro di usare meno risorse per lo sviluppo, abbassando i costi.
Nehalem è il primo vero rappresentante di questa strategia “converged core”: per questo l’analisi dei compromessi architetturali è particolarmente interessante.
Mobile, desktop, server
I tre segmenti di mercato che Nehalem deve coprire sono mobile, desktop e server. I requisiti principali per ognuno sono:
- Mobile:
- bassa potenza: fondamentale per aumentare la durata delle batterie e per non fondere il computer; questo significa avere a disposizione degli “sleep state” a bassissimo consumo e un power management molto aggressivo e dinamico
- 1/2/4 core, con cache scalabile
- moderata banda verso la RAM, a basso consumo
- basso costo (grandi volumi)
- ottime prestazioni single-threaded, dal momento che la maggior parte delle applicazioni per laptop non sfruttavano il multi-threading
- Desktop:
- 1/2/4 core, con cache scalabile
- buona banda verso la RAM
- ottime prestazioni per applicazioni multimediali e high-end gaming
- basso costo (grandi volumi)
- ottime prestazioni single-threaded
- Server:
- 4+ core, a basso consumo per poterne mettere di più nello stesso package
- largo uso di ECC su cache, TLBs, eccetera
- ampia banda verso la RAM, supporto di enormi quantità di RAM (che impone un maggior numero di bit di indirizzamento, con tutto l’overhead che ciò comporta)
- cache, TLBs, BTBs più grandi
- supporto per sistemi multisocket
- supporto a lock veloci e altre ottimizzazioni per codice multi-threaded
- power management aggressivo
- SMT (simultaneous multi-threading)
A questo punto i capi del progetto hanno dovuto togliersi il cappello da ingegnere e mettere su il cappello della compagnia. In quegli anni, Intel era indietro nei server (dove risentiva della concorrenza degli Opteron) e prevedeva (correttamente) che ci sarebbero stati sempre più laptop ad erodere le quote dei desktop. Quindi, scelsero di realizzare il meglio che potevano per applicazioni server e mobile, e lasciare che il segmento desktop si arrangiasse con quello che rimaneva.
Convergenze, divergenze, must-have
Laptop e server sono due segmenti molto diversi; tuttavia, esistono alcuni importanti punti di convergenza. Dall’inizio degli anni 2000, il fattore principale che ha limitato la crescita in frequenza delle CPU, e che ha di necessità spinto la corsa al multi-core, è stata la dissipazione di calore (e, diverso ma collegato, la fine dello scaling della tensione di alimentazione). Sia per i laptop che per i server avere basso consumo per core è fondamentale: per i laptop, per problemi di batteria e calore; per i server, per permettere di inserire molti core nello stesso package e rimanere nel power envelope dei blade.
I punti di divergenza sono, purtroppo, molti: i server hanno bisogno di grosse quantità di RAM, che si portano dietro la necessità di larghi spazi d’indirizzamento (inutili ai laptop) che richiedono area e potenza. Hanno anche necessità di avere molti più controlli ECC, largamente inutili in ambito laptop e desktop, e supporto per velocizzare programmi multi-threaded (poco comuni in ambito consumer, specie a quell’epoca). Tuttavia, questi erano tutti dei must-have per il segmento server, ed è stato necessario inserirli.
Laptop e desktop, dal canto loro, avevano bisogno di alte prestazioni in programmi single-threaded: si è dovuti prestare particolare attenzione alla progettazione di un’architettura capace di scalare su molti core senza penalizzare troppo le prestazioni del singolo core.
Conclusioni
Lo sviluppo dell’architettura di una moderna CPU richiede un enorme lavoro per conciliare i requisiti dei diversi segmenti di mercato. In questo articoli si è preso come riferimento il Nehalem, ma lo stesso discorso si potrebbe fare con processori AMD (basti pensare alla prossima architettura, Bulldozer, che ha come obiettivo quello di equipaggiare processori da 10W a 100W di TDP).
Il prossimo articolo sarà un po’ più tecnico, e vedremo come i requisiti discussi oggi influenzino la scelta della pipeline, la struttura dei core, la gerarchia di memoria (cache in primis) e le tecnologie per la gestione dell’energia.
Complimenti, una aggiunta ben gradita alle rubriche già presenti.
Attendo con ansia la più interessante seconda parte…
Bye.
Complimenti a Pleg per l’articolo. Senza dubbio un ottimo “acquisto” per Appunti Digitali! ;-)
Articolo e prospettive di sviluppo della rubrica davvero interessanti.
Dopo la rubrica sulle GPU a cura di yossarian, un alter-ego sulle CPU era d’obbligo.
Attendo impaziente la prossima puntata! :)
la verità è che sono piu avanti di quello che ci vogliono fare credere. volendo potrebbero produrre cpu da 16core a 4Ghz ma non lo fanno perchè hanno stabilito gia i periodi di vendita per quel prodotto (tra 3-4 anni)…
se li mettessero ora in vendita avremo gli i7 quad core da 2,6 ghz a 50 euro e ciò non va bene ovviamente per un azienda come intel.
ciao, complimenti per l’articolo e benvenuto su AD.
Posso vantarmi di essere stato io a spingere pleg a scrivere su AD.
E speriamo che non sia soltanto di passaggio. :D
Un benvenuto anche da parte mia. :)
@sontemi: se così fosse penso che Intel potrebbe tranquillamente spazzare via qualunque concorrente e avere il monopolio del mercato. La realtà è ben diversa, e questi articoli di pleg mostrano come gli ingegneri devono fare i conti con tutta una serie non indifferente di limitazioni e vincoli vari da soddisfare.
oddio ultimamente con gli articoli di yoss di eleonora e ora con pleg mi sembra che ad stia diventando sempre più un punto di riferimento
@ sontemi
Cesare ha gia’ risposto, ma credo valga la pena ripetere il concetto: lo scopo di questo mio articolo e’ proprio quello di dare un contesto alle CPU che vediamo sul mercato. Le prestazioni sono solo uno dei mille fattori che un’azienda deve considerare. Certamente Intel potrebbe costruire un processore a 16 core e a 4 GHz, ma servirebbero parecchi anni solo per fare la validazione e il testing, costerebbe cento volte di piu’ di un processore che c’e’ sul mercato oggi, e consumerebbe magari 500 watt (ogni riferimento a certe GPU e’ puramente casuale).
La “verita’”, per dirla colle tue parole, e’ che fare un mostro di potenza che risulta invendibile e irrefrigerabile non ha senso. Esistono innumerevoli compromessi, e si’, certamente Intel ha gia’ deciso cosa fara’ uscire nei prossimi 3–5 anni: considerando che lo sviluppo di un prodotto prende 5+ anni, se non lo facessero fallirebbero prima di cominciare!
Al momento, staranno rifinendo quello che uscira’ l’anno prossimo, stanno testando quello che uscira’ tra 2 anni, stanno finendo di progettare quello che uscira’ tra 3, sono nel pieno dello sviluppo di quello che uscira’ tra 4, un piccolo gruppo di CPU Architect sta facendo simulazioni per decidere l’architettura di quello che uscira’ fra 5, qualche gruppo di ricerca sta pensando a cosa potrebbe servire tra 6, e qualcuno (piu’ probabilmente in qualche universita’) sta pensando a cosa si potra’ fare tra 10, per poter generare idee interessanti da vendere all’industria.
@ all
Grazie, e spero di riuscire in futuro a scrivere qualcosa di sufficientemente interessante per gli “addetti ai lavori” e contemporaneamente comprensibile per gli “appassionati”.
Avendo già avuto modo di leggere svariati interventi di Pleg, sia su hwupgrade che qui su AD, mi unisco ai complimenti, e agli auguri che la collaborazione duri il più a lungo possibile.
In fatto di processori decisamente NON sono un esperto, e sono sicuro che non riuscirò a seguire fino in fondi gli articoli più tecnici, ma lo stesso vale per la rubrica sulle GPU di yossarian, e questo non mi impedisce di leggerla più che volentieri, di apprezzarla, e di imparare comunque qualcosa. :-)
Pleg, il compito che ti aspetta (insegnare qualcosa sui processori a un ignorante patentato come me) è tremendo e non lo augurerei al mio peggior nemico :-D, ma confido che ce la farai: buon lavoro!
E grazie anche a yossarian per averti convinto a farlo!
A volte sento la leggenda metropolitana secondo la quale i militari americani avrebbero una tecnologia avanti di 20 anni ..
In realtà noi staremmo usando delle CPU indietro di 20 anni!
Ha un fondamento ?
Secondo quanto scritto qui, direi di no!
Non mettetevi a ridere!! :-)
@ CountDown_0
Grazie, spero di riuscirci!
Ho speso gli ultimi 2 anni ad accumulare quel genere di conoscenza, adesso e’ ora di distillarla, organizzarla, e renderla il piu’ “digeribile” possibile.
@ Fausto
Non c’e’ niente da ridere, anzi! La questione che poni e’ molto, molto complicata.
Partirei dall’affermazione “noi staremmo usando delle CPU indietro di 20 anni”. Questo, come dicevo prima, non e’ proprio vero: perche’ bisogna capire cosa si debba prendere come punto di riferimento. Le CPU che abbiamo adesso sono il risultato di mille vincoli e tradeoff e scelte eccetera, e non e’ corretto dire che potremmo “avere di piu'”… perche’ devi vedere cosa perdi dall’altra parte. Potremmo avere le stesse CPU che girano a 5 GHz… ma consumerebbero 300 Watt e sarebbero inutili. Oppure, potremmo mettere 64 core on-die, ma sarebbe esageratamente costoso, con rese bassissime, e inutle nella maggior parte dei casi (perche’ non sappiamo scrivere facilmente codice generico che scali su un numero di core cosi’ grande). Eccetera.
Per la storia dei militari, forse e’ ancora piu’ complessa! E’ vero che ci sono agenzie che fanno ricerche all’avanguardia in alcuni settori chiave (pensa al DARPA americano: hanno finanziato Arpanet, da cui e’ nata Internet; hanno avuto un ruolo chiave nell’invenzione del GPS, e di certi motori a razzo per missili e aerei, eccetera). E molta di questa ricerca militare ha, in seguito, ricadute civili (Internet, i motori degli aerei civili, la guida satellitare). Ma e’ vero anche il contrario! Moltissimi sistemi militari sono costruiti (in parte) con roba civile, opportunamente “irrobustita”. E la cosa e’ vera soprattutto per l’elettronica! I processori e i DSP che usano i militari sono roba Intel, Texas Instruments, eccetera, perlopiu’ di derivazione civile (i cosiddetti “COTS”: Commercial Off The Shelf). Gli Itanium erano stati classificati come “munizione” per controllarne l’export (sono troppo potenti per esportarli ai cinesi o agli iraniani, per esempio :) , cosi’ come parecchia crittografia (fino ad una decina di anni fa). E la roba militare gira su UNIX, Linux… e Windows !
Semplicemente, nel campo dei processori, aziende come Intel, AMD e IBM sono troppo avanti, per costruire qualcosa di meglio il Pentagono dovrebbe spendere piu’ soldi che per lo scudo spaziale… e non ha alcuna intenzione di farlo :)
Ciao, articolo interessantissimo, non vedo l’ora di leggere la seconda parte. Avrei una domanda per quanto riguarda gli step produttivi. Rispetto alle fasi di progettazione di una architettura (quelle da te citate nell’articolo, ad esempio, per nehalem) quando si inizia a parlare di step produttivo e quando si inizia a sviluppare lo step successivo?
Esempio: lo step c0 dei nehalem richiedeva voltaggi più elevati e saliva qualcosa meno in frequenza, poi lo step d0 ha limato i voltaggi e ha permesso di salire d+ in frequenza.
thanks.
Ciao Fabio,
espando un pochino la timeline, per spiegare alcuni sotto-step (nota: sto comunque semplificando molto, e linearizzando certi processi che in realta’ hanno loop di feedback dentro loop di feedback, eccetera).
Come detto, prima lavorano i Chip Architect, che prendono tutte le decisioni microarchitetturali, e che producono una descrizione completa del chip in un linguaggio software (generalmente in C/C++, ma ho visto usare anche Matlab per chip piu’ piccoli).
Poi la palla passa ai Designer, che prendono il C come riferimento e lo convertono in una descrizione hardware dei circuiti logici (ricetta: prendere qualche tonnellata di VHDL/Verilog, cuocere per uno/due anni, farcire di SystemC/SystemVerilog/e/OpenVera, e cospargere abbondantemente di script Perl/bash).
A questo punto la descrizione harwdare viene “compilata” (cioe’ tradotta in porte logiche: il termine corretto sarebbe “sintetizzata”) e viene generata la descrizione del circuito fisico vero e proprio, che si manda in Fab a trasformare in chip.
Parallelamente, i gruppi di verification e testing creano tutte le strutture che servono a testare il chip, sia dal punto di vista della correttezza logica che della funzionalita’ elettrica.
Ok, dopo questa piccola spiega che voleva essere breve ma si e’ trasformato in un altro articolo :) diventa piu’ facile rispondere alla tua domanda: quando i Designer hanno finito la loro descrizione logica, avrai quello che possiamo chiamare “step A”. Questo step andra’ giu’ lungo la pipeline di lavoro descritta prima. A quel punto, un po’ di designer verranno trasferiti ad altri progetti, altri aiuteranno a testare e debuggare il chip, e altri… cominceranno a lavorare al prossimo step, lo “step B”. Eccetera.
In soldoni: se c’e’ necessita’, appena finito uno step si parte col successivo. I vari step andranno giu’ nella pipeline di lavoro uno dopo l’altro, e la loro uscita sul mercato verra’ determinata da fattori sia tecnologici che di mercato.
PS: precisazione: diversi step potrebbero essere prodotti a “livelli” diversi. Se c’e’ qualche magagna da sistemare a livello logico (come il bug della cache dei Phenom) allora saranno i Designer a generare la nuova descrizione hardware, che diventera’ un nuovo chip. Se invece c’e’ solo da limare qualcosa in tensione/frequenza, magari e’ sufficiente che il gruppo di sintesi (che sta, nella pipeline di lavoro, dopo il design) faccia una nuova sintesi dello stesso codice, o faccia piccole modifiche alla sintesi precedente.
@Pleg: grazie per la risposta esauriente.
altra domanda: ma in sostanza il programma c/c++ che viene creato “simula” ciò che il processore fa nella realtà? (se eventualmente vuoi spiegarlo in un prossimo articolo no problem :) )
Si’, il programma C/C++ (in realta’ ce ne possono essere piu’ d’uno, a diversi livelli di dettaglio) e’ un descrizione esatta dell’intero processore. “Esatta” vuol dire proprio di ogni singola feature, precisa nel comportamento fino all’ultimo colpo di clock e all’ultimo byte di ogni buffer, eccetera. E’ un programmone enorme, come puoi immaginare, che nessuno vedra’ mai al di fuori dell’azienda :)
E’ necessario averlo per poter simulare l’architettura e decidere quali feature mettere e quali no, come dimensionare l’intera CPU, ecc., prima di mettersi fisicamente a realizzarla. Una volta che hai il silicio, non si torna piu’ indietro.
Immagino un programma descrittivo consimile è utilizzato per gli emulatori hardware per console ?
Magari nei futuri articoli potresti farci qualche esempio con i sorgenti di suddetti emulatori…
A proposito del programma di simulazione. Segue i singoli step del segnale di clock con tutti i fronti di salita/discesa catene di ritardo o per la sincronia se ne occupa la squada successiva ?
@ streamX
Non sono sicuro di cosa intendi per “emulatore” (perche’ ormai ho sentito usare le parole “emulatore” e “simulatore” per indicare piu o meno qualsiasi cosa… sono tra le parole utilizzate in modo piu’ confuso che abbia mai sentito).
Ma se ho capito quel che intendi, la risposta e’ no. Li’ ti interessa soltanto replicare l’ISA della macchina, in modo da far girare un qualunque assembly.
Un simulatore architetturale, invece, simula proprio il funzionamento interno del processore. E’ mostruosamente lento, a seconda del dettaglio della simulazione potrebbero volerci ore a simulare un millisecondo di funzionamento.
@ Ciano
La squadra successiva. Un simulatore architetturale si occupa solo della microarchitettura (tutte le unita’ funzionali, le pipeline, le cache, gli I/O, i buffer interni, i registri, eccetera), non scende a livello di circuito (perche’ ancora non c’e’ :)
I simulatori circuitali invece scendono al livello di dettaglio che dici tu. Puoi simulare il VHDl (o Verilog), o addirittura la netlist (cioe’ il listato di porte logiche). Li’, volendo, puoi vedere ogni singolo clock, il ritardo di ogni singola porta logica, eccetera. E’ tanto preciso quanto lo sono le librerie di tecnologia che ti da’ la Fab (sperabilmente, puoi calcolare i ritardi delle porte fino al picosecondo).
Questi possono essere DAVVERO lenti: mi e’ capitato di lanciare simulazioni che prendevano una giornata intera per simulare… un microsecondo di evoluzione del circuito (su una workstation Sun con 64 core e 128 giga di RAM…)
Quindi al codice generato a questo livello dai in pasto un procramma in assebly e vedi come funziona la previsione dei salti, hypertreading, eventi cache miss.
Esatto. In questo modo puoi far girare alcuni bench (chiamati “tracce”: sequence di istruzioni assembly) e calibrare la microarchitettura. Puoi decidere che ti serve una cache piu’ grande, o piu’ veloce, calibrare il numero di registri rinominati, la grandezza della reservation station, gli algoritmi di coerenza della cache, eccetera. Ogni singola feature.
Fico.
Mi piacerebbe vedere un po di codice tanto per capire come si organizza un programma del genere.
Uno dei simulatori piu’ usati in ambito accademico e’ M5:
http://www.m5sim.org/wiki/index.php/Main_Page
I simulatori dei processori Intel e AMD, invece, non li vedremo mai :) sono solo per uso interno loro. A volte ne danno dei pezzi a ricercatori in universita’, ma allora devi firmare clausole di non divulgazione.
Anche nVidia deve avere un bel cluster per simulare i loro CIP.
Che il ritardo di Fermi sia dovuto al tempo di calcolo delle simulazioni ? :)
Leggevi ora sulla wiki di m5:
# Full-system capability.
* Alpha: M5 models a DEC Tsunami system in sufficient detail to boot unmodified Linux 2.4/2.6, FreeBSD, or L4Ka::Pistachio. We have also booted HP/Compaq’s Tru64 5.1 operating system in the past, though we no longer actively maintain that capability.
* SPARC: M5 models a single core of a UltraSPARC T1 processor with sufficient detail to boot Solaris in a similar manner as the Sun T1 Architecture simulator tools (building the hypervisor with specific defines and using the HSMID virtual disk driver).
* MIPS/ARM/x86: In progress
Quanto ci mettera un sistema operativo per avviarsi in un affare del genere. Non è certo come la virualizzazione o gli emulatori che interpretano il codice arrembly di altri processori.
Beh un problema e’ che quei simulatori ti permettono di simulare l’architettura, ma non hai ancoa informazioni sulla tecnologia. Cioe’: devi prendere decisioni architetturali che andranno implementate su una tecnologia che ancora non esiste… fai delle stime e dici “ok, fra 2 anni avremo una tecnologia fatta cosi’, quindi possiamo metterci dentro 3 miliardi di trasistor e arrivare a 1 GHz e avere consumi accettabili”, e 2 anni dopo scopri che non e’ cosi’… ma le decisioni le hai gia’ prese, non puoi tornare indietro e rifare tutto. E sei fregato.
Pleg, mi è venuta una curiosità: supponendo che AMD sia stata colta totalmente alla sprovvista dal progetto Atom, venendone a conoscenza solo quando è stato annunciato ufficialmente, quanto ci avrebbe messo a sviluppare “da zero” una soluzione analoga? In tanti ci chiediamo a cosa sia dovuta la lentezza nell’entrare nel settore dei netbook/nettop, visto che ha lasciato il monopolio a Intel per anni… Si può supporre che i ritardi siano da imputare alla lunghezza della progettazione e sviluppo? Pensavo che fosse molto più veloce sviluppare una CPU, specialmente una di fascia bassa, ma ora che ho letto il tuo articolo mi è venuto il dubbio che le cose non stiano così…
A partire da zero, servirebbe comunque qualche anno. Sicuramente sono processori piu’ semplici da progettare (e testare) rispetto a CPU di fascia alta, ma se uno ha sempre progettato solo CPU di fascia medio-alta… deve mettere su un team apposito, e deve fare un po’ di gavetta prima di riuscire a tirare fuori qualcosa di buono (il problema della fascia bassa e’ riuscire a progettare qualcosa che consumi pochissimo, che e’ un problema ingengeristico molto diverso rispetto al progettare qualcosa che vada molto veloce).
Penso che per progettare qualcosa di simile all’atom AMD partirebbe da un progetto di una CPU ad alta efficenza e comincerebbe a tagliare poi il resto lo fà la tecnica produttiva riducendo le dispersioni.
Ritornando un attimo ai simulatori di CPU.
Pleg, hai un software da consigliarmi per simulare i PIC della Microchip ?
Mi sto approciando alla programmazione dei PIC, e cercavo qualcosa per verificare il software nelle prime stesure senza caricarlo in un PIC, anche perche fare il debug sui PIC non è semplice come in un simulatore dove vedi registri e porte step by step.
Il problema e’ che AMD e Intel non facevano processori “ad alta efficienza”, ma “ad alte prestazioni”.
Si tratta di progettare due cose completamente diverse. Con l’Atom Intel ha dovuto costruire qualcosa di completamente nuovo: nuova pipeline, nuovo core, nuovo modo di fare multithreading (intendiamoci: nuovo per lei, ARM e altri fanno ‘sta roba da decenni).
Per i PIC… caschi male, non ne ho mai usati. Ma posso chiedere ad un mio amico e poi passarti le info (pero’ andrebbe fatto in privato, i commenti qui non sono il posto giusto :)
Per i PIC va bene lo stesso, si parlava di simulatori di processori e i PIC sono processori molto semplici.
Ciao
Anyway, riporto quello che mi ha risposto il mio amico:
”
Microchip mette a disposizione un IDE di programmazione/simulazione dei pic. Io uso ancora quello, non ho ancora trovato nulla di meglio (free intendo). Si può scaricare direttamente dal sito di microchip:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002
il Software si chiama mplab IDE è completamente gratuito, facile da usare; ha tutto quello che serve per iniziare. Ha persino la possibilità di programmare il pic in c con un compilatore in student version. Può imporre stimoli agli ingressi, mettere dei break point, visualizzare gli stati di tutti i registri e di tutte le variabili etc etc.
“
Forse mi sbaglio ma la AVX sono un’estensione delle SSE.
Ne parlo perchè ho programmato più volte con i registri SSE e MMX.
In realtà non è vero che non ci sono registri SIMD.
A memoria a partire dal P4 ci sono istruzioni SIMD per il calcolo in virgola mobile e dal p1 per il calcolo a virgola fissa.
Onestamente non ho idea di che area abbia una unità SSE/AVX ma ritengo che sia sempre irrisoria rispetto all’area della cache.
Quindi, a mio avviso, il bilancio che fai sulla progettazione dell’area SIMD è un po’ esagerato.
Probabilmente è più un discorso di utilizzo, in quanto ormai la potenza media di una CPU è di gran lunga sufficiente per la maggior parte degli utilizzi e introdurre altre strutture SIMD porterebbero si a benefici ma in campi ben precisi. In fatti non a caso, nelle SSE4, sono state introdotte funzioni specifiche per la criptazione che vanno tanto bene nei server.
Le AVX non sono estensioni delle SSE. E’ vero che utilizzano gli stessi registri e unità di calcolo (non avrebbe senso averne altri), ma hanno una codifica completamente diversa, e la possibilità di specificare 3 o 4 registri (con le SSE soltanto 2).
Non ricordo istruzioni per il calcolo in virgola fissa. Quali sarebbero?