[MarcoGT]

...continua...

Per esempio, l'istruzione MUL %300,%230,%100 imponenva una serie di step da eseguire, fra cui tre accessi in memoria, due in lettura (caricamento dei valori delle celle numero 230 e 100) e uno in scrittura (archiviazione del valore del prodotto nella cella 300). Insomma, un bel pò di roba! E tutto quanto deve essere sequenzializzato (in gergo si parla di operazione di scheduling) nella giusta maniera. L'esecuzione diretta prevede che le istruzioni vengano eseguite direttamente, senza una fase di interpretazione delle medesime. Chiaramente, l'hardware deve essere assai complesso per permettere al processore di lavorare in questa maniera. Siccome l'ISA consiste di centinaia di istruzioni, più o meno diverse, è necessario un approccio diverso al problema, in quanto eseguire direttamente istruzioni diversissime fra di loro richiederebbe una quantità improponibile di transistor sul die di silicio.

La soluzione sta in un trucco: il processore contiene all'interno un memoria a sola lettura (una ROM, read only memory), che contiene la "traduzione" delle istruzioni complesse in una sequenza di passi più semplici. In altri termini, anzichè essere noi a fornire al processore istruzioni molto semplici ma numerose in forma di assembler, è il processore medesimo che si preoccupa di "espandere" le istruzioni complesse che gli forniamo noi in istruzioni "atomiche" direttamente eseguibili dall'hardware. Questa operazione di decodifica, che si appoggia su una ROM cablata all'interno del processore medesimo, è un punto fondamentale dei processori CISC. Si può pensare di avere una sorta di CPU nella CPU. Dove sta lo svantaggio? Beh, è evidente: se le istruzioni sono troppo complesse la CPU spreca un sacco di cicli preziosi per decodificarle. Non solo: la ROM è interna al processore, e dunque in un certo senso "ruba via" area di silicio altrimenti destinabile all'incremento del numero dei registri o delle unità di esecuzione (unità per eseguire l'addizione o la moltiplicazione fra interi, oppure operazioni in floating point). Se l'accesso in lettura richiede molti cicli per essere portato a termine, le unità di esecuzione stanno lì a girarsi i pollici, perchè la macchina non è abbastanza ottimizzata da poter eseguire altre operazioni mentre una istruzione viene decodificata. Non so se ve ne stiate rendendo conto, ma stiamo elencando tutti i motivi che hanno portato alla nascita del concetto di macchina RISC Chiarita la differenza fra esecuzione diretta ed esecuzione previa decodificazione tramite ROM, passiamo al concetto di critical path.

Il critical path

Chi è che stabilisce a quanto ammonta il clock di un processore? In altri termini, come faccio a dire "questo processore può raggiungere i 700 MHz di frequenza, mentre quest'altro riesce ad arrivare ad 1GHz"? Bella domanda! Se cercate in giro per siti, leggete fino alla nausea che lo scaling dei transistor verso dimensioni inferiori permette di raggiungere più alte frequenze nominali di funzionamento. È tutto vero, ovviamente, ma la domanda resta senza risposta. Come fannoAMD o Intel (come preferite ) a stabilire sulla carta che un dato processore può toccare certe frequenze? La risposta è: il critical path, ossia il cammino critico. Per cammino critico si intende il percorso più lungo che un segnale deve attraversare nel tempo di un ciclo di clock. Se in qualche punto esiste un percorso che un segnale impiega la bellezza di un microsecondo per percorrere, il clock massimo per quel processore sarà di 1MHz (l'inverso di 1 microsecondo). Non importa se la stragrande maggiornaza degli altri segnali interni impiega per esempio 1 nanosecondo (cioè un millesimo di microsecondo), basta un segnale lento per obbligare tutto il circuito ad andare alla velocità sua, che è quella di 1Mhz al massimo! (Infatti se sulla vosta scehda madre avete due banchi di RAM, uno che lavora a 333MHz e l'altro a 400MHz...entrambi lavoreranno a 333MHz). Inoltre, per problemi legati all'invecchiamento dei componenti, alla deriva termica e al fatto che i transistor non sono mai così precisi come sulla carta, occorre tenersi del margine di progettazione per cui ad 1MHz il dispositivo non andrà mai (a meno che qualche esemplare particolarmente ben riuscito adatto all'overclock non capiti nelle nostre mani.. . Cosa c'entra questo con il CISC? C'entra, perchè un sistema per ovviare al problema del critical path è la pipeline, che nascerà con l'approccio RISC al design di un processore. Il fatto che il un processore CISC, di principio, possa eseguire una sola istruzione alla volta, fa sì che la parte di circuiteria coinvolta nello svolgimento dell'esecuzione più complessa sia quella più lenta, e quindi finisca per fare da tappo alla performance del processore. Tanto per fare un esempio, una moltiplicazione eseguita direttamente, e non tramite successivi steps di addizione, resta tuttavia molto più lenta di una semplice addizione. Anche se la moltiplicazione capitasse una volta ogni 'morte di papa' nel listato assembler, il processore dovrà comunque tenerne conto e pertanto dovrà essere sufficientmente lento da permettere alla moltiplicazione di avvenire senza problemi. Alla fine degli anni Settanta e nei primi anni Ottanta la situazione era cambiata: i compilatori erano divenuti molto più efficienti, le memorie meno costose e i progettisti di microcomputer stavano scoprendo che la "panacea" data dall'implementazione in hardware di istruzioni complicatissime e a volte strampalate stava costituendo un tappo per il miglioramento delle performance. Si cominciò allora a pensare ad un modo diverso di progettare un microprocessore, e le linee guida di progetto possono essere così riassunte: