**L’ARCHITETTURA X86 E IL SUO PASSATO GLORIOSO**
Sì, è vero, il titolo ricorda un po’ il film thriller del 1990, tratto dal romanzo di Stephen King. In realtà, quello che vogliamo fare è spiegare il motivo per cui l’**architettura x86** non deve essere necessariamente abbandonata. Punto di riferimento per qualsiasi personal computer, da quando il primo processore **Intel 8086** fu presentato nel 1978, l’architettura x86 è tornata oggi al centro di un acceso dibattito.
Periodicamente, nuvole nere sembrano addensarsi su x86 con tanti esperti che ne prevedono la fine imminente. Se da un lato **Pat Gelsinger**, CEO di Intel, afferma di non vedere all’orizzonte una reale minaccia da parte dei SoC ARM nel settore dei PC, dall’altro lato l’azienda ha rafforzato e continua a investire sulle sue capacità produttive. Nei suoi stabilimenti, **Intel** prevede di realizzare sempre più chip ARM e RISC-V per conto terzi.
**UN BREVE IDENTIKIT DELL’ARCHITETTURA X86**
L’architettura x86, feudo storico di Intel e AMD, è profondamente legata all’approccio di Von Neumann, è caratterizzata da un set di istruzioni complesso (CISC, *Complex Instruction Set Computer*), supporta l’esecuzione superscalare (più istruzioni possono essere eseguite per singolo ciclo di clock), *out-of-order* (riordinamento delle istruzioni per accelerarne l’esecuzione) e *speculativa* (caricamento delle istruzioni successive ai salti nel programma, senza sapere se una condizione sarà effettivamente soddisfatta). Originariamente sviluppata, come abbiamo visto in precedenza, per il processore Intel 8086 (chip a 16 bit), l’architettura x86 si è poi evoluta per supportare processori a 32 e 64 bit.
Dopo quasi mezzo secolo di sviluppo, il **set di istruzioni x86** è diventato ancora più complesso, richiedendo notevoli risorse per il *fetch* e la decodifica delle istruzioni. Sono insomma necessarie maggiori risorse da parte del processore per recuperare (*fetch*) e **decodificare le istruzioni** prima di poterle eseguire.
**LA DIATRIBA TRA CISC E RISC DOVREBBE ESSERE MORTA E SEPOLTA**
L’approccio **CISC** mirava a compiere un’operazione con meno istruzioni, sebbene più complesse. Introdotto negli anni ’70, CISC si scontrava con la filosofia **RISC** che aveva come obiettivo quello di utilizzare meno e più semplici istruzioni in modo da snellire la progettazione dell’Hardware. Le architetture **MIPS** e **ARM** nacquero negli anni ’80 proprio seguendo i principi della filosofia RISC.
Come avevamo già avuto modo di sottolineare nell’articolo sulla sfida tra ARM64 e x86-64, il set di istruzioni non conta niente se non si mettono sui piatti della bilancia gli aspetti legati alla **progettazione dei chip**. Già ben oltre 10 anni fa, appariva insensata la diatriba tra sostenitori dell’approccio CISC e quelli dello schema RISC, figuriamoci ai giorni nostri: la progettazione e l’implementazione dell’architettura sono molto più importanti dell’insieme di istruzioni utilizzato (**ISA**, *Instruction Set Architecture*).
Insomma, etichette come “CISC” e “RISC” riflettono solo l’origine lontana di un **set di istruzioni**. Riportano alla mente il ricordo di dibattiti filosofici che potevano essere rilevanti al massimo più di tre decenni fa ma che oggi sono assolutamente anacronistici.
**ARCHITETTURA X86 MOLTO PIÙ SIMILE A QUELLE CONCORRENTI DI QUANTO SI POSSA RITENERE**
Se guardiamo alle CPU moderne, sia x86 che ARM, scopriremo che – indipendentemente dall’architettura utilizzata – hanno molte cose in comune. I concetti di **esecuzione superscalare**, speculativa e *out-of-order* con rinominazione dei registri sono presenti in tutti i casi, nell’architettura x86 così come in quelle concorrenti.
Come abbiamo visto nell’articolo su come funziona un processore, in un processore con esecuzione “**in ordine**“, le istruzioni sono eseguite nell’ordine in cui sono ricevute dalla CPU stessa. Con l’approccio *out-of-order*, invece, il processore può eseguire le istruzioni in un **ordine diverso** da quello in cui sono state ricevute, a condizione che le dipendenze delle istruzioni siano rispettate.
Questo significa che il processore può **saltare l’esecuzione di istruzioni** che dipendono da dati ancora non disponibili, eseguendo invece altre istruzioni indipendenti. Si tratta di una soluzione che permette al processore di sfruttare al massimo le risorse disponibili e mantenere attivi i suoi componenti di esecuzione, aumentando così le prestazioni complessive.
La gestione delle istruzioni spesso coinvolge l’utilizzo dei registri, piccole aree di memoria all’interno del processore utilizzate per immagazzinare dati su base temporanea. La **rinominazione dei registri** consente al processore di assegnare dinamicamente registri fisici a istruzioni in esecuzione, anche se queste istruzioni fanno riferimento allo stesso registro logico. Più istruzioni possono essere eseguite contemporaneamente utilizzando gli stessi **registri logici**, poiché ciascuna istruzione riceve un registro fisico dedicato temporaneo. Questo aiuta ad evitare conflitti e rallentamenti dovuti alla condivisione di registri da parte di istruzioni diverse e consente al processore di eseguire più **istruzioni in parallelo**, migliorando così l’efficienza complessiva dell’esecuzione.
Sono inoltre sfruttate complesse gerarchie di cache a più livelli e prefetcher per evitare problemi prestazionali nell’accesso al contenuto della DRAM.
**COME SI COMPORTANO I PROCESSORI REALIZZATI CON ARCHITETTURE DIVERSE RISPETTO A X86**
Nessuna CPU moderna, sia essa x86 oppure di tipo **ARM, RISC-V, MIPS, Loongarch** utilizza direttamente i bit dell’istruzione per controllare l’esecuzione come avveniva, ad esempio, con lo storico microprocessore MOS 6502 del 1975. Tutte decodificano invece le istruzioni in un formato interno comprensibile per il motore di esecuzione *out-of-order* e per le sue unità funzionali.
Questo **processo di decodifica** converte le istruzioni dall’*encoding* specifico dell’architettura in una serie di micro-operazioni (*micro-ops*) o altri elementi interni che possono poi essere trattati ed eseguiti.
Diversamente, l’architettura del **MOS 6502** richiedeva che ogni istruzione fosse codificata con un determinato schema di bit. Il processore interpretava direttamente questi bit per eseguire l’istruzione corrispondente. Un approccio semplice ma limitato, che richiedeva un’architettura specifica per ogni istruzione.
**LA DECODIFICA DELLE ISTRUZIONI È COMUNQUE COSTOSA**
La **decodifica** è costosa indipendentemente dall’architettura scelta, anche se ci si servisse di un approccio puramente RISC e di istruzioni a lunghezza fissa. x86, quindi, non è un “*unicum*” e anche i core ARM utilizzano meccanismi, come una cache di micro-operazioni, per “archiviare” le istruzioni utilizzate di recente nel formato decodificato.
La **crescita dei set di istruzioni** e l’aumento del numero di istruzioni non sono caratteristiche distintive dell’architettura x86. Anche ARM e MIPS, per esempio, hanno evidenziato numerose revisioni, con l’introduzione di tante estensioni addizionali.
Se da un lato x86-64 utilizza **estensioni vettoriali** come SSE, AVX(2) e AVX-512, ARM a 64 bit (aarch64) integra a sua volta estensioni vettoriali quali ASIMD, SVE e SVE2. Semmai, come confermato dal leggendario progettista di chip **Jim Keller**, RISC-V è un po’ l’*outsider* che tutti dovrebbero temere perché questa architettura non deve gestire alcuna “eredità”. Non c’è nessun pesante fardello che lega RISC-V al passato.
RISC-V è all’inizio del suo ciclo di vita e non è stata aggiunta alcuna inutile complessità: per questo motivo **Tenstorrent**, la società guidata da Keller, ha puntato proprio su RISC-V, piattaforma che sarà protagonista nel giro di 5-10 anni, cominciando dal settore dei data center.
**X86 SPINGE SULL’ASPETTO DELLA COMPATIBILITÀ**
In un articolo pubblicato qualche settimana fa, si mette alla berlina l’”arcaica” *8086 real mode*. Si tratta di una modalità di funzionamento dei processori x86 introdotta proprio con la famiglia Intel 8086 nel 1978 e che continua ad essere supportata nei moderni processori x86-64.
La **modalità reale** è spesso utilizzata durante il processo di avvio del sistema operativo, in quanto consente al BIOS di eseguire le sue funzioni di inizializzazione hardware ed effettuare l’avvio. Una volta che il sistema operativo è caricato, può passare alla **modalità protetta** o a una modalità a 64 bit, che offrono maggiori livelli di protezione, gestione delle risorse e supporto per le funzionalità…
**LA SITUAZIONE COMPATIBILITÀ NEGLI ALTRI ECOSISTEMI**
Se si guarda ad altri ecosistemi si notano differenze evidenti: diversi dispositivi mobili necessitano di **Immagini personalizzate**, anche se sono dello stesso produttore e rilasciate solo pochi anni dopo. Gli aggiornamenti del sistema operativo comportano la creazione e la convalida delle immagini della ROM per ogni dispositivo, ponendo un onere enorme sui produttori dei singoli device.
Gli Smartphone basati su **SoC ARM** tendono a uscire dal supporto ufficiale del produttore decisamente prima che le prestazioni garantite agli utenti comincino a degradarsi davvero. Utilizzando ROM personalizzate e beneficiando del supporto della comunità, i possessori di smartphone ARM possono usare i loro dispositivi per qualche anno in più (godendo comunque di aggiornamenti e patch di Sicurezza non ufficiali). Il quadro è comunque ben lungi dall’essere quello ideale.
Mettiamo da parte le limitazioni sui requisiti hardware forzosamente inserite da Microsoft, ad esempio, con Windows 11. Intel e AMD hanno voluto investire sulla compatibilità, semplificando la distribuzione del Software e permettendo agli utenti di **massimizzare l’utilizzo dell’hardware**, per quanto più tempo possibile.
Tornando alla modalità reale, Intel vuole comunque semplificare x86 e ha pianificato l’eliminazione della *real mode*. L’intento, però, è quello di ritirare funzionalità quando i tempi sono davvero maturi, senza forzare la mano.
**ARCHITETTURA ARM PROTAGONISTA ANCHE NEI DATA CENTER**
Una CPU deve combinare alte prestazioni con un solido ecosistema software che la supporti. ARM (aarch64) gode di un ecosistema software solido e core CPU davvero performanti. I chip di derivazione ARM **Ampere Altra**, per fare un nome tra i più “lanciati”, sono disponibili tra le offerte cloud pubbliche di Google, Microsoft e Oracle. Amazon stessa si serve della piattaforma **ARM Neoverse** per AWS.
Come abbiamo rimarcato altrove, ARM64 può sfidare l’architettura x86 storicamente utilizzata da Intel e AMD (a parte che anche AMD sta lavorando su SoC ARM che debutteranno nel 2025 e sosterranno il funzionamento di PC Windows on ARM) ma il successo arriverà eventualmente in forza di design hardware azzeccati ed ecosistemi software ricchi e ben congegnati. In attesa della futura consacrazione di RISC-V.
*Credit immagine in apertura: iStock.com – greg801*
**CONCLUSIONI**
In conclusione, l’architettura x86 ha dimostrato una notevole longevità e adattabilità nel corso degli anni, continuando a evolversi e ad affrontare sfide sempre nuove. Nonostante le critiche e i dibattiti sul suo futuro, l’x86 resta un pilastro fondamentale nell’ambito dei processori e dei personal computer. La sua compatibilità e la sua capacità di adattarsi alle richieste del mercato sono elementi che continuano a garantirle un ruolo centrale nella Tecnologia moderna. Se da un lato architetture alternative come ARM e RISC-V stanno guadagnando terreno, l’x86 si dimostra ancora una forza da non sottovalutare, capace di resistere alle sfide del tempo e di mantenere la sua rilevanza nel panorama tecnologico attuale.