Perché qualcuno dovrebbe voler CISC?

Nella nostra lezione sui sistemi informatici siamo stati introdotti al processore MIPS. È stato (ri) sviluppato nel corso del termine ed è stato in effetti abbastanza facile da capire. Utilizza un design RISC , ovvero i suoi comandi elementari sono regolarmente codificati e ce ne sono solo alcuni per mantenere semplici i fili.

È stato detto che il CISC segue una filosofia diversa. Ho guardato brevemente il set di istruzioni x86 ed ero scioccato. Non riesco a immaginare come qualcuno vorrebbe costruire un processore che utilizza un set di comandi così complesso!

Quindi immagino che ci debbano essere buoni argomenti per cui grandi parti del mercato dei processori utilizzano architetture CISC. Quali sono?

C'è una tendenza storica generale.

Ai vecchi tempi, i ricordi erano piccoli, e quindi i programmi erano assolutamente piccoli. Inoltre, i compilatori non erano molto intelligenti, e molti programmi erano scritti in assembler, quindi è stato considerato una buona cosa poter scrivere un programma usando poche istruzioni. Le condutture delle istruzioni erano semplici e i processori hanno raccolto un'istruzione alla volta per eseguirla. Le macchine all'interno del processore erano comunque piuttosto complesse; le istruzioni di decodifica non erano considerate un peso.

Negli anni '70, i progettisti di CPU e compilatori si resero conto che avere istruzioni così complesse non era poi così utile. Era difficile progettare processori in cui quelle istruzioni fossero davvero efficienti, ed era difficile progettare compilatori che ne approfittassero davvero. L'area del chip e la complessità del compilatore sono state spese meglio per attività più generiche come registri più generici. L' articolo di Wikipedia su RISC spiega questo in modo più dettagliato.

MIPS è la massima architettura RISC, motivo per cui viene insegnata così spesso.

La famiglia x86 è un po 'diversa. Originariamente era un'architettura CISC pensata per sistemi con memoria molto piccola (non c'è spazio per istruzioni di grandi dimensioni) e ha subito molte versioni successive. Il set di istruzioni x86 di oggi non è solo complicato perché è CISC, ma perché è davvero un 8088 con un 80386 con un Pentium probabilmente con un processore x86_64.

Nel mondo di oggi, RISC e CISC non sono più la distinzione in bianco e nero che avrebbero potuto essere una volta. La maggior parte delle architetture CPU si è evoluta in diverse tonalità di grigio.

Dal lato RISC, alcune moderne varianti MIPS hanno aggiunto istruzioni di moltiplicazione e divisione, con una codifica non uniforme. I processori ARM sono diventati più complessi: molti hanno un set di istruzioni a 16 bit chiamato Thumb oltre alle istruzioni "originali" a 32 bit, per non parlare di Jazelle per eseguire le istruzioni JVM sulla CPU. I moderni processori ARM hanno anche istruzioni SIMD per applicazioni multimediali: alcune istruzioni complesse pagano dopo tutto.

Dal lato CISC, tutti i processori recenti sono in parte RISC all'interno. Hanno un microcodice per definire tutte queste complesse istruzioni macro. La semplice complessità del processore fa sì che la progettazione di ciascun modello richieda diversi anni, anche con un design RISC, con l'elevato numero di componenti, con pipeline ed esecuzione predittiva e quant'altro.

Quindi perché i processori più veloci rimangono CISC all'esterno? Parte di essa, nel caso della famiglia x86 (32-bit e 64-bit), è la compatibilità storica. Ma non è tutto. All'inizio degli anni 2000, Intel ha provato a spingere l' architettura Itanium . Itanium è un caso estremo di istruzioni complesse (non proprio CISC, però: il suo design è stato soprannominato EPIC ). Elimina persino l'idea all'antica di eseguire le istruzioni in sequenza: tutte le istruzioni vengono eseguite in parallelo fino alla barriera successiva. Uno dei motivi per cui Itanium non ha accettato è che nessuno, che sia Intel o altrove, potrebbe scriverne un compilatore decente. Ora un buon vecchio processore per lo più sequenziale come x86_64, è qualcosa che capiamo.

Il set di istruzioni x86 è un po 'un caso speciale. Penso che il 68K di Motorola e il VAX di DEC siano esempi leggermente migliori di CISC. Ai tempi di un sacco di codice in linguaggio assembly, la gente pensava che un ISA molto regolare e molto inclusivo fosse migliore: credo che chiamassero la differenza tra il codice assembly e il modo in cui la gente pensava il " gap semantico ". Teoricamente, volevi un set di istruzioni che corrispondesse al modo in cui pensavi.

L'altro grande driver di progettazione per CISC sembra essere "ortogonalità": ogni istruzione funzionerebbe con ogni modalità di indirizzamento (registro, indirizzo assoluto, offset relativo, ecc. Ecc.). Puoi vedere il bogey man dell'ortogonalità mostrato nella progettazione API in Distributed Computing Environment (DCE) e in CORBA. Quell'idea non si limita alla progettazione del set di istruzioni.

Un motivo per CISC era di avere una codifica densa per le istruzioni (la memoria era costosa). L'intera idea di RISC era quella di accelerare la CPU recuperando le stesse istruzioni di dimensione per tutto il tempo (nessun passaggio complesso, lento "calcola le dimensioni delle istruzioni"), chiedi loro di fare cose semplici (quindi è veloce capire cosa fare) . La memoria era economica. Questa area di circuiti libera sulla CPU per altre cose (più registri, più unità di elaborazione, quindi diverse istruzioni potrebbero essere eseguite in parallelo se fossero indipendenti). Dato che la CPU era molto più lenta della RAM, questo ha dato i suoi frutti. Ma le CPU sono diventate più veloci (e hanno fatto di più in parallelo, e ...) mentre la RAM non ha ottenuto più veloce (almeno non alla stessa velocità del consumo di dati della CPU a causa del maggiore parallelismo). Scopri la memoria cache, veloce come la CPU ma piccola. Quindi ora la memoria è di nuovo in sovrapprezzo, non per ragioni di costo ma per velocità. Tempo di rinascita della CISC. Nel frattempo, le CPU sono diventate più complesse, al punto che il microprocessore di oggi fa molto di quello che ha fatto un compilatore RISC: suddividere le operazioni in parti elementari, riordinare le istruzioni RISCy interne in modo che possano essere eseguite contemporaneamente quando possibile. RISC era maledetto come "Scarica roba importante al compilatore" per un motivo ...

Il vero vantaggio di CISC è la riduzione della memoria e della pressione della cache e questo da solo lo rende migliore per applicazioni ad alte prestazioni esigenti poiché un grosso collo di bottiglia in tali sistemi è la larghezza di banda della memoria. Data la memoria cache di dimensioni uguali, i processori CISC possono descrivere più informazioni di RISC. Inoltre, poiché le istruzioni CISC comportano diverse micro-operazioni, potrebbero essere possibili miglioramenti dell'architettura che potrebbero fornire il percorso di esecuzione più rapido per quell'istruzione che la scrittura di singole istruzioni potrebbe mai fornire. In breve, i processori CISC sono più efficienti nell'uso della larghezza di banda della memoria, che spesso si traduce in miglioramenti delle prestazioni per applicazioni ad alta intensità di memoria.

Ad esempio, per eseguire R1 = R2 + R3 + R4 + R5 + R6e inserire il risultato nello stack, supponiamo che il codice RISC sia scritto come,

ADD  R1, R2, R3 (4-byte)
ADD  R1, R4, R5 (4-byte)
ADD  R1, R6, R0 (4-byte, R0=0)
PUSH R1         (4-byte)

e come tale richiede 16 byte di spazio.

Venendo al CISC, a causa della possibilità di diversi stili di codifica, le stesse informazioni possono essere rappresentate come segue ...

ADD R1, R2, R3 (4-byte)
ADD R1, R4, R5 (4-byte)
ADD R1, R6     (2-byte)
PUSH R1        (1-byte) 

che richiede solo 12 byte di memoria. Pertanto, l'utilizzo della memoria viene migliorato consentendo al processore di vedere più istruzioni e quindi ridurre i cicli di inattività.

Un aspetto importante che nessuno ha sollevato così è che quasi tutte le CPU CISC sono architetture microcodificate. Un microsequencer e un negozio di controllo consumano molta meno proprietà di un controller cablato e il set di istruzioni può essere modificato senza modificare l'hardware.

I microprocessori erano dispositivi innovativi quando sono entrato nel campo. Una pratica molto comune negli anni settanta e primi anni ottanta era quella di assemblare una CPU usando ALU bit-slice, un'unità di controllo basata su microsequencer e un archivio di controllo in cui il set di istruzioni microcodificato veniva caricato o bruciato. Questi computer erano basati sulla logica transistor-transistor (TTL) serie 7400. L'ALU 78181 a 4 bit è stato utilizzato per costruire molti processori, tra cui i computer DEC PDP-11 e VAX 11 precedenti, Data General Nova, Xerox Alto e il computer desktop Wang.

Avrai difficoltà a trovare qualsiasi computer desktop che non utilizza un processore compatibile x86. Quel set di istruzioni ha battuto MIPS, ha battuto Sparc, ha battuto Alpha, ha battuto Titanic (potrei aver sbagliato a scrivere quel nome). MIPS d'altra parte esiste a malapena oggi. Quindi, non importa cosa pensi oggi, le persone molto intelligenti hanno pensato che il set di istruzioni x86 fosse davvero una buona idea, e hanno fatto un sacco di soldi con esso.

I computer hanno iniziato come RISC perché un set di istruzioni complesso era appena al di là delle capacità degli implementatori. Se si desidera visualizzare un set di istruzioni RISC, consultare il set di istruzioni CDC 6400-6600 e CDC Cyber ​​170-175. È proprio RISC. Circa 10 anni fa ho chiesto ad alcuni progettisti di chip quanto spazio avrebbe richiesto (nell'angolo di un ragionevole chip GPU avanzato). Mi hanno detto di 1mm2, inclusa la RAM della macchina, che occuperebbe il 99% di quello spazio.

Quando le persone potevano costruire macchine CISC, erano effettivamente avvantaggiate. Ricorda che x86 fu rilasciato molto prima di MIPS, 1978 vs. 1985. A quel tempo avevi bisogno di cicli di elaborazione per leggere le istruzioni, decodificarle, eseguirle. Nel 1978 i MIPS avrebbero richiesto quattro cicli per istruzione e per operazione. Se prendi un'istruzione x86 come "aggiungi registro alla memoria", ciò richiederebbe forse 7 cicli per l'istruzione, ma eseguendo 3 operazioni. Questo è stato un grande vantaggio. E più istruzioni diverse hai, e più potente ogni istruzione, maggiore è il vantaggio.

E quando è stata sviluppata l'istruzione x86 a 64 bit con i suoi prefissi da incubo, la complessità dell'insieme di istruzioni non ha più avuto importanza. Il CISC al giorno d'oggi è appena tradotto in RISC e l'intera attività di traduzione è forse l'uno percento del chip.

Questa domanda ha molto a che fare con le tendenze molto recenti nell'informatica che favoriscono un massiccio spostamento verso il mobile e il tablet, favorendo in tal modo RISC cpus, e ha colto Intel (probabilmente il più grande fornitore CISC del mondo) in una svantaggio in una cosiddetta "inflessione" punto" esattamente come il tipo che Grove ha attirato e messo in guardia. La storia breve è che il CISC sembra stia iniziando a sciogliersi sotto il massiccio assalto di paradigma / gamechanging del mobile computing a causa del suo consumo apparentemente intrinsecamente elevato di energia.

Presumibilmente il CISC sarà sempre presente sul desktop, ma il mobile è ampiamente considerato come il nuovo futuro dell'informatica. Molti paesi in via di sviluppo (con grandi potenziali popolazioni che usano il computer) in realtà salteranno ampiamente la fase desktop. Vedi, ad esempio, Rise and Fall del desktop computing

Un eccellente caso di studio di questa domanda è leggere Mike Bell, che lavora per Intel in una nuova posizione, cercando di posizionare Intel meglio nel mercato mobile tramite la CPU Atom tramite un progetto / iniziativa simile a "skunkworks", con un dirigente molto forte supporto. Il mercato della telefonia mobile è strettamente associato all'architettura RISC, e principalmente ai processori ARM, grazie in gran parte alla loro elevata efficienza energetica (consumo di energia), un nuovo criterio chiave per il calcolo di cui la domanda e nessun'altra risposta menzionano. Ecco due articoli recenti in questo senso che rivelano molto del pensiero aziendale interno (e conseguente scramble!) Sull'argomento:

• Intel respinge la "tassa x86", non vede futuro per ARM o per nessuno dei suoi concorrenti

• Un impero colpisce ancora: Intel entra nel mercato mobile

Un fattore non menzionato in altre risposte è economico. Riguarda anche Intel. L'architettura CISC è in gran parte rappresentata dalle famiglie x86 e x64. Tutti discendono dall'umile 8088 utilizzato nel PC IBM originale. Il primato dominante sul mercato di quella serie di computer fece sì che Intel avesse un solido flusso di entrate per R&S. Insieme al fatto che Intel è stata in grado di frenare la concorrenza rinunciando / annullando i suoi accordi di seconda fonte significava che i prezzi della CPU potevano salire a livelli estremi garantendo margini di profitto lordi molto ricchi.

Pertanto, mentre altri produttori di CPU hanno faticato a tenere il passo, Intel è stata in grado di versare miliardi di dollari nello sviluppo di prodotti più recenti e più veloci. La competizione RISC non poteva spendere quasi così tanto denaro. Molti processori RISC sono usciti dal mercato. Alcuni erano:

DEC Alpha, Fairchild Clipper, AMD 29000, SPARC, MIPS, POWER (per uso PC), Hitachi SuperH ...

Ricordo gli esperti di quell'epoca che annunciavano che la guerra RISC vs CISC era finita e che la CISC aveva vinto. No. Ha superato tutti gli altri.

Questa dinamica può mai cambiare? Lo è già. Nessun vantaggio economico è assoluto.

L'unico tallone d'Achille del x86 è il suo vorace appetito per il potere. Ciò ha permesso a un concorrente più piccolo, più agile (ARM) di prosperare nei mercati (come telefoni / tablet / ecc.) In cui contava la parsimonia energetica.

Un ottimo video su questo da parte di un membro del team ARM è Processore ARM - Seminare i semi del successo - Computerphile intorno alle 8:30

Il secondo problema per x86 è il successo della strategia di Intel. Sono riusciti a eliminare quasi tutta la concorrenza. Rallentarono. Da anni ormai, i nuovi processori Intel hanno apportato miglioramenti molto modesti. Peggio ancora, i margini super ricchi sono una dieta dura da rinunciare a qualsiasi azienda.

Oggi, i sistemi basati su ARM (SOC) basati su ARM e i chip x64 concorrenti di AMD stanno nuovamente rendendo il mercato delle CPU un posto interessante. (A PARER MIO)

Ci sono molte ragioni per cui si sceglierebbe di implementare un CISC. Il motivo principale è la compatibilità binaria con un set di istruzioni CISC esistente. Mentre la tecnologia di traduzione binaria del software è migliorata, la compatibilità basata su hardware presenta alcuni vantaggi tecnici (oltre allo svantaggio di una minore memorizzazione nella cache di traduzione) e il vantaggio meno tecnico di sembrare più affidabile.

La densità del codice è forse il secondo motivo più significativo per la scelta del CISC. Renesas RX è stato progettato come CISC appositamente per la densità del codice in quanto si rivolge ai microcontrollori in cui la dimensione della memoria del codice è un fattore di costo significativo. Le istruzioni a lunghezza variabile, le istruzioni complesse (principalmente più modalità di indirizzamento), gli operandi impliciti e il registro inferiore contano tutta la densità del codice di beneficio.

Un motivo storico (e secondo me errato) per la scelta del CISC è stato quello di colmare il divario semantico tra i programmatori che utilizzano un linguaggio di livello superiore e il processore. Poiché le istruzioni complesse possono generalmente essere sostituite da una sequenza di istruzioni più semplici, la complessità di un compilatore di linguaggio di livello superiore per un RISC non deve essere molto più complessa rispetto a un CISC corrispondente alla lingua. RISC evita lo "scontro semantico" (in cui un'istruzione del processore funziona più o meno rispetto a una corrispondente istruzione linguistica) e facilita la riduzione della forza e l'ottimizzazione della pianificazione. (Vedi "Quali sono i compromessi nello sforzo di sviluppo del compilatore relativo a CISC vs. RISC?" Per maggiori dettagli.)

Ci può essere un costo fisso significativo associato all'esecuzione di un'istruzione. Questo incoraggia l'uso di istruzioni relativamente complesse per diffondere questo sovraccarico su lavori più effettivi; ridurre il conteggio dinamico delle istruzioni può migliorare le prestazioni. Quando il costo della logica e della RAM era molto maggiore del costo della ROM, l'incentivo per istruzioni complesse era significativo poiché un'istruzione veniva decodificata cercando il microcodice.

Un motivo per usare il CISC, forse contraddetto da prove storiche, è che il microcodice può essere ottimizzato per ogni microarchitettura mentre le librerie standard possono essere lente nello sfruttare le funzionalità di una nuova implementazione. Il livello di ottimizzazione delle implementazioni software della memcopia rispetto a quello del microcodice per REP MOVSB ​​implica che le biblioteche possono ottenere più attenzione del microcodice. Parte di ciò può provenire dal fornitore del processore indirizzato a una base di utenti più ampia, quindi la giustificazione dello sforzo può essere più difficile rispetto al software open source o interno in cui gli interessi localizzati di sviluppatori o utenti possono distorcere lo sforzo di implementazione.

Essere in grado di spedire una libreria standard ottimizzata con il processore ha notevoli attrattive. L'archiviazione e l'esecuzione di una libreria standard della piattaforma possono essere notevolmente ottimizzate mediante la progettazione di codici hardware-software. La distinzione tra un'istruzione complessa e una chiamata del livello di astrazione della piattaforma può essere sottile (o inesistente). Un progetto RISC potrebbe utilizzare le stesse tecniche di implementazione per la gestione delle chiamate PAL di un CISC per istruzioni complesse, incluso l'uso di operazioni non fornite nel set di istruzioni generale con hardware specializzato, l'utilizzo di cache e decodifica intelligenti e la specifica di operandi di registro (sebbene un CISC lo farebbe spesso usano registri dedicati simili a un ABI per funzione). Il modello mentale associato al CISC può incoraggiare tali ottimizzazioni. Inoltre, gli utenti potrebbero essere meno offesi dall'inclusione forzata di un "

La decodifica di istruzioni relativamente complesse può avere un sovraccarico minore (e forse essere più affidabile nel caso di intenti discernenti) rispetto alla tecnica RISC comparabile di riconoscimento del linguaggio in cui una sequenza di istruzioni è riconosciuta come unità semantica. Questa differenza generale sarebbe più evidente in un'implementazione più piccola, ma il sovraccarico per usare queste informazioni riduce il significato dei risparmi di decodifica.

Ulteriori informazioni contestuali possono facilitare l'ottimizzazione dell'hardware. Ad esempio, quando si incrementa un valore in memoria, l'hardware è in grado di riconoscere che l'indirizzo di memoria viene utilizzato due volte (per il carico e l'archivio), offrendo l'opportunità di memorizzare nella cache la memorizzazione di memorie e memorizzazione nella cache. Istruzioni complesse possono fornire tali informazioni in modo esplicito. In un'istruzione complessa, i valori intermedi hanno una durata esplicita (quella dell'istruzione); con un registro RISC tradizionale i valori devono essere sovrascritti esplicitamente per indicare la fine della vivacità. (Nota: un RISC potrebbe specificare un registro che è sempre azzerato dopo ogni utilizzo, fornendo un mezzo per specificare un valore temporaneo monouso. Tali istruzioni sarebbero moderatamente più complesse.)

Se i dettagli dell'implementazione non sono nascosti dietro un livello di astrazione, diventa più difficile utilizzare diverse microarchitettura per ottimizzare diversi compromessi. Esporre i dettagli microarchitetturali come garanzie architettoniche blocca la microarchitettura nella garanzia di compatibilità. Mentre il software PAL potrebbe essere ottimizzato come le istruzioni complesse, tale richiede un design dei codici hardware-software. La separazione organizzativa e la diversità rendono più difficile la progettazione di codici.

Istruzioni complesse possono fornire un accesso protetto allo stato privilegiato. Ad esempio, istruzioni complesse sono spesso atomiche rispetto agli interrupt. Mentre un set di istruzioni RISC potrebbe fornire un meccanismo a livello di utente per sospendere temporaneamente gli interrupt, possibilmente anche qualcosa come il caricamento collegato in modo che il software ripeti esplicitamente l'operazione se interrotto, purché ciò non sia tipico dei RISC.

Allo stesso modo, un'istruzione complessa potrebbe fornire accesso controllato e / o uso di informazioni privilegiate. Poiché l'operazione eseguita ha controllato la semantica, è possibile evitare l'effettiva violazione dei privilegi. Le alternative orientate al RISC includono il codice PAL (che in genere ha un notevole sovraccarico) e l'accesso mascherato ai registri di configurazione (o copie shadow dei registri) che presentano uno stato privilegiato. Fornire una soluzione generale (RISC) è più difficile che fornire una soluzione a uno o pochi casi speciali (CISC), ma è più potente e meno vulnerabile all'accumulo di casi speciali. Se si ritiene che i casi speciali importanti siano pochi, il CISC può essere più attraente.

Istruzioni complesse possono anche nascondere lo stato al software. Un vantaggio importante di questo sarebbe il salvataggio e il ripristino del contesto. Con le istruzioni che salvano e ripristinano lo stato, l'architettura deve solo comunicare la dimensione del contesto al sistema operativo e non i meccanismi specifici per il trasferimento dello stato in memoria. Ciò consente alle applicazioni in esecuzione su un sistema operativo legacy di utilizzare estensioni ISA che aggiungono stato. (Ancora una volta, il software PAL potrebbe fornire la stessa funzionalità.)

Gran parte della complessità di x86 deriva dalla compatibilità con molte estensioni. Con istruzioni complesse e meno ortogonali (utili per la densità del codice), la rimozione di alcuni lavori che non si sono rivelati comunemente necessari, evitando catene di dipendenze non necessarie (ad esempio, solo un bit di trasporto, solo un registro di quantità di spostamento dinamico), aggiungendo un lavoro che si è trasformato per essere comunemente usato e che può essere ottimizzato all'interno dell'istruzione complessa - ognuno di questi richiederebbe l'aggiunta di una nuova istruzione e rendere l'ISA meno piacevole esteticamente.

In molti casi un RISC non incontrerebbe tali problemi perché le istruzioni sono altamente ortogonali e primitive. In alcuni casi, un RISC potrebbe dover aggiungere nuovi primitivi, ma in genere sarebbe applicabile a più di un uso.

Inoltre, una volta creata l'infrastruttura per supportare istruzioni complesse, le barriere vengono ridotte per ulteriori istruzioni complesse. Cioè, gran parte del costo di istruzioni complesse in non ricorrenti. Gli ISA fortemente RISC subiscono un ostacolo complementare all'introduzione delle funzionalità CISCy.

La frequenza di estensione di x86 può anche essere parzialmente attribuita alla sua popolarità per il calcolo per scopi generici e il modello di processore mercantile (aumentano anche l'importanza della compatibilità binaria). Gli ISA RISC sono stati spesso legati ai fornitori di sistemi che incoraggiano una maggiore attenzione alle applicazioni e alla mancanza di concorrenza per le implementazioni di uno specifico ISA RISC scoraggia in qualche modo l'uso di estensioni di set di istruzioni per il marketing. La popolarità rende anche il costo dello sviluppo di nuove estensioni meno significativo (le spese non ricorrenti sono meno importanti a volume maggiore).

La filosofia di compatibilità x86 probabilmente tende anche ad estendere i meccanismi esistenti piuttosto che fornire una pausa più pulita, il che significa che le nuove funzionalità sono più influenzate dalle funzionalità esistenti. Una maggiore frequenza di estensione incoraggia anche cambiamenti più incrementali, il che incoraggia a riutilizzare i meccanismi, tendendo a ridurre l'ortogonalità.

Confronto tra una presentazione accademica del MIPS classico (che è un sottoinsieme delle versioni moderne del MIPS ed esclude varie estensioni ISA opzionali) al moderno x86 (che ripercorre la compatibilità binaria con l'8086 a 16 bit e la quasi-compatibilità a livello di assembly ancora più indietro) con tutto il suo bagaglio storico non presenta il caso migliore per CISC né un caso realistico per RISC.

Semplicemente prima che ci fossero configurazioni di set di istruzioni ridotte c'erano configurazioni di set di istruzioni. Hanno le loro applicazioni. in particolare in trasferimenti di blocchi di memoria molto grandi con chipset ad alta capacità, che richiederebbero solo 4-16 byte per trasferire un'intera pagina video, anziché un ciclo lungo per sempre. questo sta cambiando e RISC sta diventando lo status quo mentre i set di chip stanno diventando più sofisticati, come le incredibili GPU che si trovano nelle schede video di fascia alta.

La CPU CISC presenta più vantaggi di RISC. Perché il CISC usa meno registro hardware e porte XNOR / XOR rispetto a RISC molte volte !!!! Immagina che i byte di istruzione in CISC verranno eseguiti in sequenza, c'è solo una porta logica e viene usato il registro. Se 1 miliardo di transistor è in grado di produrre circa 300 milioni di porte logiche, è possibile elaborare 300 milioni di operatori o processi (IF, uguale, matematico, variabile, indirizzamento ... ecc.) E più programmi possono essere eseguiti in CISC. Ma in RISC, ci vogliono una dozzina di volte di porte logiche per eseguire un programma in progettazione pipeline. Quindi 300 milioni x 50 volte (50 istruzioni) + 15000000000 contatori di bit !!! nel cosiddetto RISC. CISC usa più hardware per ridurre algothrim software che rallenta la CPU.