Siamo giunti finalmente al termine di questa serie di articoli incentrati sul sempreverde nonché mai domo dibattito sui RISC e i CISC. Riporto di seguito l’elenco dei precedenti articoli, così da rendere più facile recuperarli:
Il definitivo RISC vs CISC – 1: Livelli di astrazione vs benchmark
Il definitivo RISC vs CISC – 2: Le definizioni
Il definitivo RISC vs CISC – 3: La propaganda (anti-CISC)
Il definitivo RISC vs CISC – 4: Come i RISC divennero CISC
Il definitivo RISC vs CISC – 5: Come i CISC… sono rimasti CISC!
Non credo che dovrebbero esserci più dubbi su cosa sia un RISC e, di conseguenza cosa sia un CISC. Né, soprattutto, il fatto che sostanzialmente non esistono più processori RISC da parecchio tempo e che quelli che vengono spacciati come tali siano, in realtà (definizioni alla mano), dei CISC.
La (nuova) macrofamiglia L/S (o LS): Load/Store
A questo punto e mio avviso non ha più alcun senso continuare a parlare di RISC, quando i processori che si fregiano di questo titolo hanno visto cadere quasi tutti pilastri su cui erano basati. Tranne uno: il vincolo di accedere alla memoria esclusivamente tramite le cosiddette istruzioni di load/store.
Per essere più chiari, non si deve cambiare il significato di processore RISC, poiché questo termine risulta ben definito (e valido) e ancora oggi riecheggiano e vengono addirittura propagandati tutti e quattro i pilastri su cui è basato.
Si dovrebbe, invece, semplicemente utilizzare un nuovo termine al posto di RISC: L/S o LS, per identificare la macrofamiglia di processori che abbiano in comune il ricorso alle suddette load/store quali uniche istruzioni a cui facciano capo gli accessi alla memoria. Ovviamente i RISC (i vecchi che rientrano in questa definizione. I nuovi sono CISC, come già dimostrato) ne sarebbero, per definizione, un sottoinsieme (stretto).
Non si deve riscrivere la storia
Ridefinire (silenziosamente) il significato di RISC per soddisfare le (mutate) esigenze di qualche docente dimostrerebbe, invece, soltanto una dolosa mancanza di onestà intellettuale.
Questo perché la storia è importante e i fatti dovrebbero essere verificati invece di attingere ciecamente ai frutti della propaganda, per quanto questa sia stata ben impacchettata e venduta come una deliziosa leccornia. Soprattutto, non si dovrebbe cadere nella sua trappola: il progetto volto a riscriverla pur di assecondare i nuovi piani e far sparire le precedenti prese di posizione.
Lo ricorda molto bene ancora una volta George Orwell quando, nell’altro suo celeberrimo romanzo, 1984, descrive la maniacale operazione di sistematica riscrittura della storia a seconda delle decisioni e delle nuove direzioni intraprese dall’Intelligencija che governava il paese. Ma, soprattutto, possiamo certamente notare come il “bispensiero” sia assolutamente centrale nella propaganda dei fautori dei RISC: «La menzogna diventa verità e passa alla storia» e «Chi controlla il passato controlla il futuro: chi controlla il presente controlla il passato».
Orwell, insomma, è stato di nuovo profetico nei suoi scritti e chiunque li abbia letti e conosca anche la storia dei processori e delle loro architetture non dovrebbe avere difficoltà alcuna nel vedere che quanto in essi descritto si applichi fedelmente alle macrofamiglie RISC e CISC.
In principio…
Voglio esprimere, infine, la mia opinione su alcuni argomenti correlati a quest’atavica diatriba.
Un’altra cosa che personalmente trovo ridicola è la pretesa di giudicare i vecchi processori con lenti attuali, ignorando completamente il contesto storico e le esigenze dell’epoca.
Prendiamo nuovamente il vituperato 8086: l’uso dei famigerati prefissi permetteva di controllare/manipolare le istruzioni eseguite in modo molto semplice, efficiente ed economico. Il progetto del processore non era complicato, utilizzava pochi transistor e otteneva un’eccellente densità di codice. Di cos’altro c’era bisogno all’epoca (1978)?
Nessuno poteva immaginare che ciò avrebbe creato problemi in futuro, visto che lo avremmo saputo molto, ma molto più tardi. Tuttavia, parlare ora di questo e puntare il dito contro il processore per quelle decisioni… devo dire che lascia molto a desiderare, come minimo.
A mio avviso usare i prefissi per estendere l’architettura a 32 bit è stata ancora un’idea accettabile anche quando è stato commercializzato l’80386, tenendo conto dell’ISA ereditata, gli obiettivi e la tecnologia dell’epoca. Non si può, come già detto, ignorare la storia e lo specifico contesto in cui alcuni prodotti sono arrivati.
Puntare, quindi, il dito sulle architetture del passato sulla scorta delle esperienze nonché avanzamenti tecnologici successivi alle epoche in cui certe decisioni siano state prese lo trovo a dir poco demenziale, se non offensivo nei confronti dell’intelligenza.
…e il senno di poi
Tutt’altra cosa si può dire, invece, della sua estensione a 64 bit, x86-64: i tempi (arrivò nel 2003) erano abbastanza maturi per capire che tale eredità impattava ormai troppo sulle implementazioni dell’architettura. Quindi un’idea migliore sarebbe stata quella di proporre un’ISA ridisegnata, almeno nella nuova modalità a 64 bit.
Che è esattamente ciò che ARM ha realizzato qualche tempo fa per la sua AArch64 AKA ARMv8: un’architettura nuova di zecca che è stata progettata eliminando i colli di bottiglia e gli oneri di quella a 32 bit, estendendo anche l’ISA.
È stato un bel lavoro di riscrittura e ripensamento che sicuramente avrebbe potuto essere fatto anche per x86-64, invece di applicare un’altra orribile pezza su x86 e complicare ulteriormente l’ISA, come già ampiamente discusso su queste pagine (in particolare nell’articolo conclusivo sulla nuova architettura di Intel, APX).
In ogni caso certe scelte sono ormai state prese e tornare indietro non è possibile (si è accumulato troppo software). Rimane la delusione derivata dalla consapevolezza di ciò che si sarebbe potuto fare e che, purtroppo, non si è fatto (di cui probabilmente parlerò in un’altra serie, più avanti).
Un futuro migliore
Perché certamente di meglio sarebbe stato possibile, avendo cura di prendere altre decisioni. Infatti progettare processori CISC, anche moderni, non implica necessariamente che debbano essere pessimi / “brutti” per definizione nonché forieri di problemi: dipende interamente da come siano stati architettati!
Ovviamente il meglio si potrebbe ottenere avendo a disposizione un “foglio in bianco”, dove disegnare liberamente le proprie idee, senza vincoli e retaggi da portarsi dietro: ciò potrebbe portare a soluzioni molto interessanti a problemi comuni.
Con ciò si chiude la serie, che spero abbia contribuito se non a chiarire la querelle (capisco che sia difficile rimuovere dei preconcetti ormai saldati nella mente), quanto meno a instillare il dubbio su quanto ormai viene propagandato sfacciatamente da più di 40 anni…
