[MarcoGT]

CISC = Complex Istructions Set Computing

RISC = Reduced Instruction Set Computing



Come potete notare dagli acronimi la differenza sostanziale sta nel set di istruzioni; ogni CPU ha un proprio set di istruzioni (si parla di istruzioni in linguaggio macchina, ossia in assembler); il set di istruzioni è l'insieme delle istruzioni che una CPU può eseguire; le istruzioni di base sono:

-- istruzioni di accesso alla memoria (load / store);
-- istruzioni "su registri" (add, sub...);
-- istruzioni di salto (condizionato e non);

queste, come già detto, sono istruzioni "base"; ossia, una CPU con questo set di istruzioni è in grado di fare poco, anzi, pochissimo
Ovviamente le CPU odierne (parlando di P4 e Athlon, a 32bit, non che a 64bit la storia cambi di molto) hanno un set molto più esteso che comprende le istruzioni per la multimedialità (MMX e SSE) e non solo queste ovviamente.

CISC: è un'architettura costituita da un set di istruzioni complesse; all'epoca in cui "sono nati" processori CISC non esisteva il concetto di una memoria veloce ma piccola (la cache dei processori odierni) da affiancare al processore e dato che ogni nuovo set di istruzioni deve essere retrocompatibile, la maggior parte delle istruzioni prevedeva molti accessi in memoria (RAM) per lettura / scrittura; la memoria di sistema (RAM) è schematizzabile come come un array, cioè un insieme ordinato di celle aventi una certa dimensione in byte; il processore è schematizzabile, per i nostri scopi, come un elemento che, dietro i comandi impartiti da una logica di controllo (le operazione che la CPU deve compiere sono impartite da una CU, Control Unit che lavora su microistruzioni), preleva i dati dalla memoria centrale (fase di read o load), li elabora (fase di execute), e una volta processati scrive i risulati finali (fase di write back o store) nuovamente in memoria.
Il problema di una tale soluzione è che il concetto di memoria è molto "nebuloso": un dispositivo di memorizzazione può essere un registro (che funziona alla velocità di clock del processore in cui è inglobato), una cache, una RAM di sistema o ,alla peggio, l'intero Hard Disk!

La maggior parte delle istruzioni CISC fanno uso di modalità di indirizzamento complesso sempre nell'ottica di ridurre la dimensione del codice compilato. Un esempio banale per capire l'approccio CISC all'uso della memoria: abbiamo due valori immagazzinati in due celle di memoria, esempio la cella numero 100 e la cella numero 230. Dobbiamo fare la moltiplicazione fra i contenuti delle due celle e scrivere il risulato nella cella numero 300. Il modo di procedere corretto sarebbe allora questo:

Codice assembler per l'operazione di moltiplicazione fra due valori immagazzianti in memoria centrale:

MOV A, %100; muovi (move) nel registro A il contenuto della cella 100
MOV B,%230; salva in un altro registro, detto B, il contenuto della cella 230
MUL C,A,B; moltiplica A per B e scrivi il risultato nel registro C
STR C, %300; scrivi (store) il valore di C nella cella numero 300

Osserviamo che, in totale, abbiamo 4 istruzioni in assembler. Troppe per i progettisti, secondo la filosofia CISC. Perchè non fare una singola istruzione di moltiplicazione che preveda tutte queste operazioni una volta decodificata dal processore? Se venisse aggiunta nell'ISA del processore, basterebbe scrivere:

MUL %300,%230,%100

per impartire l'ordine al processore di salvare il contenuto della memoria nei registri, fare la moltiplicazione e scrivere il risualtato nuovamente in memoria.
Tutto quello che abbiamo visto sui CISC è "molto bello", davvero, ma avviene a scapito di un paramentro: l'efficienza nella esecuzione del codice. Guardiamo infatti a questa formula:

time/program = [ (instructions/program) x (cycles/instruction) x (time/cycle) ]

il membro a sinistra dell'uguaglianza è il paramentro fondamentale che esprime l'efficienza di un processore ad eseguire il dato programma. Più il time/program è basso, meno tempo impiega la CPU a portare a termine il compito. La filosofia CISC tende ad abbattere il termine instructions/program, cioè il numero di istruzioni che compongono il programma. Abbiamo già visto come abbiamo effettuato una riduzione del 75%, portando il numero di istruzioni in assembler da 4 ad 1 semplicemente aggiungendo una nuona istruzionea all'ISA iniziale, nel calcolo di un semplice prodotto! Il problema però è dato dal fatto che se il primo termine a secondo membro scende, magari salgono a dismisura il secondo ed il terzo, cioè il numero di cicli necessari per eseguire la singola istruzione e la durata del singolo colpo di clock. Quindi tutta la fatica fatta per semplificare l'assembler andrebbe a farsi benedire! Cerco di chiarirvi le idee con un esempio estremo: posso fare in modo, al limite, di avere pochissime istruzioni macchina che descrivano un intero programma, ma se poi ogni istruzione richiede un giorno per essere decodificata ed eseguita, perchè troppo complessa, ho peggiorato tutto!

I problemi dell'approccio CISC sono proprio questi:
1) le istruzioni contengono un sacco di store e load, cioè di accessi in scrittura e lettura in e dalla memoria centrale la quale, essendo lenta, causa un rallentamento complessivo del sistema.
2) le istruzioni sono tante, complesse, e vanno decodificate prima di poter essere eseguite. E qui veniamo al secondo punto nel calcolo delle performance di un microprocessore : il critical path, la direct execution e la ROM di decodifica.

Cominciamo da quest' ultime due:

La Direct Execution e la ROM di decodifica

Per esecuzione diretta, o direct execution, si intende la capacità del processore di elaborare l'istruzione in linguaggio macchina senza doverla decomporre in elementi più semplici.