www.MegaLab.it

Vantaggi di un processore in un unico chip

Certo, oggi fa ridere un chip cosi, ma all'epoca fu una cosa rivoluzionaria, e ci si rese conto che un microprocessore era superiore a un'accozzaglia di chip interconnessi tra di loro da bus, per tutta una serie di motivazioni, che elencherò brevemente:

1) occupa meno spazio

2) ha dei consumi minori

3) produce meno calore

4) è più affidabile di un'insieme di chip saldati su una scheda madre

5) è più veloce, dato che i segnali elettrici devono percorrere cammini più brevi, quindi è possibile operare a frequenze più elevate

6) è più economico da produrre in grosse quantità

Come nasce l'approccio CISC

La situazione che si presentava, a chi progettava allora i chip era questa: le memorie costavano un'occhio della testa, i compilatori erano poco efficienti, quindi perché non progettare chip che eseguissero in hardware anche istruzioni molto complesse?

Per capire meglio, faccio uno stupido esempio abbiamo il seguente programma:

# A=3 # B=cubo(A)

Il programma non fa altro che prendere un valore A=3, memorizzare in B il cubo di questo valore. Ovviamente il programma non serve a niente di utile, ma vediamo come verrebbe lo stesso programma dopo che il compilatore produce in uscita il linguaggio assembler:

# MOV A,3 memorizza in A il valore 3 # MUL B,A,A moltiplica il valore di A per se’ stesso e mette il risultato in B # MUL B,B,A moltiplica B per A e memorizza il risultato in B

L'elevamento al cubo, come vedete, viene eseguita da due istruzioni separate nel linguaggio assembler, mentre noi nel linguaggio di alto livello la eseguiamo in un'unica operazione.

Questo accade perché l'ipotetico processore che dovrebbe eseguire il calcolo, non ha in hardware la funzione eleva al cubo, quindi quando il compilatore riceve come target per la compilazione quel tipo di processore, traduce l'istruzione con due istruzioni separate equivalenti.

In pratica l'ISA (Instruction Set Architecture) di quel processore, tra le operazioni che può eseguire, non contempla la funzione cubo.

Se invece la nostra ISA disponesse di un'istruzione di eleva al cubo, il codice assembler sarebbe stato del tipo:

# MOV A,3 memorizza in A il valore 3 # CUB B,A calcola il cubo di A e memorizza il risultato in B

A differenza di prima, adesso il codice assembler ha lo stesso numero di istruzioni del codice di alto livello, ed è anche più compatto.

Operando in questo modo, è più facile per chi programma in assembler scovare eventuali errori di programmazione (quando viene fatto il debug dell'applicazione).

Un approccio di questo tipo, dove si cerca di avere un'ISA che abbia tutte le istruzioni possibili, e che faciliti il debug, è detto approccio CISC (Complex Instruction Set Computing), in pratica un'architettura composta da un insieme di istruzioni complesse.

È vero che abbiamo aiutato i programmatori a effettuare il debug del software (problema parecchio sentito all'epoca, poiché le memorie erano costose e i programmi dovevano essere quanto il più possibile ottimizzati), ma la fase di decodifica delle istruzioni complesse, è stata demandata al microprocessore.

Ogni nuova CPU che veniva introdotta, doveva essere retrocompatibile con quelle precedenti, altrimenti non si sarebbero potuti far girare i vecchi applicativi.

Le istruzioni CISC

Parliamo ora della memoria, dato che all'epoca non esisteva il concetto di cache (una piccola memoria molto veloce da affiancare alla RAM per velocizzare l'accesso ai dati), e bisognava mantenere la compatibilità con i set di istruzioni precedenti, la maggior parte delle istruzioni prevedevano molti accessi in RAM, sia in lettura che in scrittura.

La maggior parte delle istruzioni CISC, fa uso di modalità di indirizzamento complesso, per ridurre la dimensione del codice compilato.

Per fare un esempio, per eseguire la somma di due celle di memoria:

# MOV A, %30 # MOV B, %90 # SUM C,A,B # STR C, %100

Questo codice, non fa altro che prendere i due valori da sommare in memoria centrale, il primo all'indirizzo 30 e il secondo all'indirizzo 90, li somma, e poi memorizza il risultato nell'indirizzo di memoria 100.

In totale abbiamo 4 operazioni, che per la filosofia CISC sono troppe.

Per ridurre le dimensioni del codice compilato, basterebbe aggiungere al set di istruzioni, un'istruzione che esegua quelle già viste, prendendo quei 3 parametri come argomento, ad esempio:

# SUM %100,%30,%90

Un bel risparmio di righe di codice, e anche un risparmio in fase di debug.

I problemi dell'approccio CISC

Certo, come penso immaginate, tutta questa semplicità ha un costo, dato che diminuisce notevolmente l'efficienza di esecuzione del codice.

Se riduciamo il numero di istruzioni che compongono il programma, rendendole più complesse, è anche ovvio che il processore per eseguire queste istruzioni complesse, avrà bisogno di più cicli di clock.

I problemi di questo approccio sono i seguenti:

1) le istruzioni hanno molti accessi in memoria centrale, che essendo lenta, rallenta anche l'esecuzione del programma

2) abbiamo molto istruzioni nell'ISA, alcune anche molto complesse; esse vanno decodificate prima di poter essere eseguite.

Quest'ultimo punto, incide su un parametro importante per calcolare le performance di una CPU, le istruzioni eseguite per ciclo di clock.

Per eseguire un'istruzione del tipo SUM %100, %30, %90, il processore doveva eseguire un certo numero di istruzioni, fra cui 3 accessi in memoria, due in lettura e uno in scrittura, e poi il calcolo vero e proprio.

Tutte queste istruzioni devono essere eseguite in maniera sequenziale, e nel giusto ordine. Il processore, può eseguire le istruzioni in due modi, per esecuzione diretta (eseguendo senza doverle decomporre in istruzioni più semplici), e per interpretazione, scomponendo l'istruzione in tante istruzioni più semplici.

Poiché l'ISA che stiamo descrivendo avrebbe centinaia di istruzioni, eseguirle direttamente richiederebbe per l'implementazione in hardware un numero improponibile di transistor! (non posso spiegare tecnicamente come si implementano i circuiti che poi eseguono i calcoli veri e propri, che probabilmente farebbe capire meglio la cosa, ma mi riprometto prima o poi di fare un'articolo al riguardo, ma forse sarebbe solo per i duri di stomaco : -)).

La soluzione a questo problema, è quella di avere all'interno del processore una ROM (memoria in sola lettura) che contiene la traduzione delle istruzioni complesse in sequenze di istruzioni semplici.

Praticamente, non siamo più noi (o il compilatore) a scomporre le istruzioni complesse in tante istruzioni semplici, ma è il processore che si preoccupa di scomporle in istruzioni direttamente eseguibili in hardware.

Questa operazione di decodifica, è un punto fondamentale dei processori CISC, dato che, più sono complesse le istruzioni, più tempo ci vorrà per decodificarle.

Non so se vi siete accorti, che a poco a poco vi stò elencando tutta una serie di svantaggi dell'approccio CISC, che poi portarono alla nascita della filosofia RISC.