Hardware Upgrade Forum - View Single Post

maurilio968 · 11-12-2009, 09:33

cito l'intervento di PLEG a commento di un articolo di Cesare Di Mauro su appunti digitali, leggibile QUI

@ 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

11-12-2009, 09:33	#6
maurilio968 Senior Member Iscritto dal: Feb 2006 Messaggi: 1659	cito l'intervento di PLEG a commento di un articolo di Cesare Di Mauro su appunti digitali, leggibile QUI @ 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 __________________ ogni minuto muore un imbecille e ne nascono due.