L’interesse di Apple per la progettazione dei microprocessori è ben noto, specialmente dopo l’acquisizione di PA-Semi lo scorso 2008 (mossa strategica per il suo iPhone), ma… non è stato l’unico caso.
E’ passato, infatti, un ventennio da quando Apple e Acorn, lavorando alla nuova architettura ARM, portarono la seconda a realizzare uno spin-off espressamente votato alla progettazione di CPU: l’attuale e famosissima Advanced RISC Machines Ltd., come ricordato da Alessio Di Domizio nella retrospettiva dedicata all’Archimedes.
Il prodotto di questi sforzi fu l’ARM6, cioé la versione 3 dell’architettura ARM, impiegato da Apple nel suo piccolo e rivoluzionario gioiello tecnologico, il Newton, e da console altrettanto rivoluzionarie come il 3DO di Trip Hawkins & soci, che portava a piena maturazione questa famiglia di processori.
Comincio col precisare che riguardo a questa famiglia di CPU, la nomenclatura è alquanto bizzarra ed è facile arrivare a confondersi, visto che per lo stesso pezzo di silicio si parla di: famiglia, versione dell’architettura, e nome del core, com’è possibile constatare guardando l’apposita paginetta.
Esistono, infatti, tantissime varianti, ma quel che balza immediatamente all’occhio è il fatto che alla stessa famiglia possono appartenere prodotti di versioni diverse dell’architettura, con l’ARM7 che arriva a coprirne addirittura tre (dalla v3 alla v5).
Da programmatore il mio interesse riguarda l’architettura, per cui il mio principale riferimento sarà la versione della medesima, cioé le migliorie che sono state apportate all’ISA, ed eventuali cambiamenti interni che hanno comportato miglioramenti degni di menzione.
Tornando al tema dell’articolo, i miglioramenti introdotti con la versione 3 dell’architettura riguardano principalmente la rimozione del grosso limite di cui avevo già parlato in precedenza, e cioé quello del tetto massimo di 64MB di memoria indirizzabile per codice e dati, considerato che gli indirizzi generabili erano a 26 bit.
La causa era dovuta all’utilizzo di alcuni bit del Program Counter per memorizzare i flag del registro di stato, per cui la soluzione trovata è stata ovviamente quella più logica e naturale: separarli dal PC e memorizzarli in un apposito registro.
Su un altro microprocessore sarebbe stato più semplice, ma l’ARM ha introdotto la pregevole caratteristica di dotare ogni modalità di funzionamento (utente, supervisore, interrupt, ecc.) di versioni dedicate degli stessi registri. In particolare i registri R13-R15 sono sempre specifici per ognuna di esse (e per qualcuna si arriva fino a R8), in modo da non richiederne necessariamente il salvataggio sullo stack o in aree di memoria dedicate.
Pertanto, oltre a questi, si è rivelato indispensabile creare una copia del nuovo registro stato per ogni modalità di funzionamento, in modo da renderla completamente indipendente e isolata dalle altre, come si può vedere nel seguente schema (il registro si chiama CPSR o SPSR, a seconda della modalità d’esecuzione):
Quindi il costo è stato maggiore del previsto rispetto ad altre architetture, ma aggiungere una manciata di nuovi registri (tra l’altro gestiti in maniera trasparente come agli altri che hanno lo stesso meccanismo di utilizzo) non richiede certo notevoli quantità di transistor.
Infatti si è passati dai circa 30mila dell’ARM v2 (ARM2) ai 35mila dell’ARM v3 (ARM6). Una cifra assolutamente irrisoria se consideriamo il notevole beneficio portato da questo cambiamento dell’architettura, che ha visto, tra l’altro, l’introduzione di due nuove e utili (per il sistema operativo) modalità per la gestione delle eccezioni (sollevate a causa dell’abort dell’istruzione corrente, oppure in presenza di un opcode non definito nell’ISA).
Ovviamente cambiamenti di questo genere hanno una portata non trascurabile, in quanto la nuova ISA risulta in parte incompatibile con la precedente, per cui i programmi che facevano affidamento sulla “fusione” di PC e registro di stato dovevano necessariamente essere cambiati per operare correttamente in questa nuova modalità, e sappiamo bene quanto “dolorosa” sia la riscrittura di codice di basso livello (chi lavorava con linguaggi di più alto livello non si sarà nemmeno accorto del cambiamento).
Fortunatamente fu introdutta una modalità di funzionamento interamente retrocompatibile con la precedente ISA a 26 bit, permettendo quindi di facilitare il “traghettamento” dal vecchio al nuovo mondo nella maniera più indolore possibile.
Questo con l’ARM v3, appunto, ma con la v4 l’implementazione della vecchia ISA non risulta più vincolante per chi decide di implementare un microprocessore con licenza ARM, e addirittura con la versione 5 la modalità a 26 bit è considerata obsoleta e tutti gli slot occupati nella tabella degli opcode risultano riservati e impiegabili per futuri utilizzi (ossia nuove istruzioni).
In buona sostanza ARM Ltd. ha deciso di supportare la vecchia architettura per un certo periodo, oltre il quale l’ha del tutto abbandonata relegandola all’oblio o alla nostalgia informatica.
Il contrasto con la linea seguita da Intel con la sua famosissima x86 è evidente, visto che tutt’oggi viene mantenuta piena compatibilità con l’arcivecchia ISA 8086, che dopo ben 31 anni risulta ancora mimetizzata (ma perfettamente funzionante!) anche negli ultimissimi modelli.
Ciò con conseguenti maggiori costi di implementazione e d’esercizio, anche se spesso non in maniera significativa, come ho già avuto modo di discutere in maniera più approfondita in un articolo comparativo fra ARM e x86.
Di certo la neonata (ai tempi) ARM Ltd. si lascia alle spalle un pezzo (sicuramente glorioso) della sua storia, ma con la v3 apre avanti a sé la strada a un futuro decisamente più roseo, com’è testimoniato dagli incredibili successi di vendita (se consideriamo com’è partita Acorn) e dalle diverse versioni ed estensioni dell’architettura…
