Perché l'architettura x86 non deve morire

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.

Ma perché in tanti profetizzano la fine dell’architettura x86? Davvero si metterà la pietra tombale su una soluzione responsabile del funzionamento dei PC per quasi 50 anni?

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 ancora 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 differenti 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.

L’approccio moderno, in contrasto con il MOS 6502, offre maggiore flessibilità ed efficienza. Semplifica inoltre l’implementazione di nuove istruzioni e delle estensioni per l’architettura: le nuove istruzioni possono essere decodificate nel formato interno del processore, senza richiedere modifiche significative sull’hardware.

La decodifica delle istruzioni e 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à avanzate del processore. Nonostante le sue severe limitazioni (si pensi ad esempio all’indirizzamento a 16 bit e all’accesso diretto a 1 MB di memoria fisica), la modalità reale è ancora supportata per motivi di retrocompatibilità.

Le CPU x86-64 mantengono la modalità reale in modo che i sistemi operativi possano continuare ad avviarsi allo stesso modo, sull’hardware di oggi così come su quello più datato risalente a decenni addietro. Il supporto per la modalità reale fa insomma parte della piattaforma dei PC che conferisce alle CPU x86 una compatibilità e longevità senza pari.

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