Archimedes: l’antenato di iPhone era l’home computer più veloce dell’epoca

di |
arm logo icon 800

Si chiama Archimedes il nonno o meglio l’antenato di iPhone: è stato il primo computer a funzionare con un processore ARM. Un processore per molti versi rivoluzionario voluto e finanziato da Apple negli anni ’80

L’antenato di iPhone non è un datato e ingombrante computer Apple, ma un home computer creato in Regno Unito nella metà degli anni ’80: si chiama Archimedes ed è stato costruito da Acorn. Le peculiarità di Archimedes sono diverse, quelle che qui ci interessano sono principalmente due: è stato il primo computer a funzionare con un processore ARM e lo sviluppo del suo processore innovativo è stato voluto e finanziato da Apple.

Una foto di un prototipo di ARM1 progettato da ARM e costruito da VLSIL’origine dei processori ARM e la storia di Archimedes sono note in Regno Unito dove intere generazioni hanno compiuto i primi passi nell’universo allora nascente dell’informatica proprio con un computer Acorn: il primo Electron, poi BBC Micro e successivamente con diversi modelli e generazioni di Archimedes. Mentre i processori Intel allora impiegati nei PC compatibili funzionavano e funzionano tuttora con tecnologia CISC, sigla di Complex Instruction Set Computer, Acorn cercava un’alternativa efficiente, veloce ed economica per costruire un processore proprietario, che l’avrebbe resa indipendente dai fornitori di CPU.

Il risultato di questo progetto allora segretissimo è proprio il processore ARM, sigla che inizialmente indicava Acorn RISC Machine ma che successivamente si trasformò in Advanced RISC Machine, quando la società si progettazione e sviluppo fu scorporata da Acorn per diventare ancora più indipendente. La tecnologia RISC, da Reduced Instruction Set Computer, indica un processore dotato di set di istruzioni volutamente limitato, ma in grado di eseguirle molto più velocemente, una semplificazione fondamentale per ridurre il numero di transistor e i consumi.

Archimedes acorn
Quando fu presentato il primo Archimedes nel 1987 funzionava con ARM2, il primo ad essere costruito di questa famiglia destinata a diventare diffusissima, assicurando a questo home computer prestazioni da capogiro, naturalmente per l’epoca. Per esempio mentre il Motorola 68000 (circa 70mila transistor) impiegato in Amiga, Atari ST e anche nel primo Macintosh di Apple funzionava a 8 MHz ed era in grado di erogare circa 1 MIPS, milioni di istruzioni al secondo, ARM2 (circa 30mila transistor, la metà!) alla stessa velocità erogava una potenza compresa tra 4,5 e 4,8 MIPS. Le prestazioni elevate, la bontà del sistema operativo e del software a corredo valsero ad Archimedes il titolo di home computer più veloce.

La società fondatrice Acorn ha smesso di produrre computer pochi anni dopo, ma la costola ARM, finanziata da Apple, ha continuato a migliorare l’architettura ARM fino ai livelli oggi evidenti e sotto gli occhi di tutti. Anche se Intel per marchio e marketing è il nome comunemente associato ai processori, la quantità di dispositivi che funzionano con ARM è di una scala decisamente superiore. Non solo tablet e smartphone, ma anche router, NAS, televisori smart, schede di controllo, console portatili e molto altro ancora funzionano con un processore con architettura ARM.

La storia della nascita di ARM è interessante ma la parte migliore, secondo molti, deve ancora arrivare. Con il continuo miglioramento e potenziamento i processori ARM potrebbero presto uscire dai dispositivi super compatti in cui il risparmio energetico è essenziale: tra non molto potrebbero arrivare anche nei computer portatili e forse chissà persino nei desktop.

arm

  • bravodillo

    Apple, tu vo’ fare l’Europeo, l’Europeo, l’Europeo…

  • frabelli

    Quasi un ritorno al passato per Apple? Con i PPC poi intel ora. La storia continua.

  • Marco

    Caro Daniele, è vero che il 68K faceva 1 MIPS ma di istruzioni CISC, che non sono paragonabili con le istruzioni RISC. Per svolgere uno stesso compito infatti ai CISC occorrono molte meno istruzioni dei RISC. Alla fine una Execution Unit di un CISC non è poi tanto dissimile dal RISC, solo che ad essa si aggiunge il micro ed il nano codice.
    In pratica per ogni istruzione CISC, la Execution Unit esegue il suo micro-codice di istruzioni semplici che svolgono quei compiti che nei RISC vengono programmati esternamente tramite l’Assembler.
    Basta pensare alla istruzione SCASB che con il suffisso REPE ricerca caratteri in una stringa. Per volgere lo stesso compito in un RISC servono decine di istruzioni.
    Per rendersi conto di quanto strano sia il mondo, l’evoluzione del RISC ha portato a creare il suo esatto opposto, un processore “extremely-CISC” basato sul concetto di VLIW (Very Long Instruction Word) ed alla architettura Merced IA64 ormai defunta. Curiosa la vita.

    • Aros

      no ho capito tutto ma tutto veramente interessante, grazie per l’intervento, bello imparare. in poche parole le istruzioni CISC sono veloci quanto le RISC? per esempio per apple tornare ai Risc o ARM non cambierebbe molto se non nei consumi del processore?

    • Robertino68

      Scusa la mia ignoranza, ma mi sfugge qualcosa, perché sapevo il contrario. È l’architettura Risc servono meno istruzioni rispetto all’architettura CISC e non il contrario.

      • RISC e CISC sono due concetti desueti… ormai non c’è più differenza tra i due.

        • Robertino68

          Perché ormai entrambi i casi i chip sono ibridati. Lo stesso Intel frutta architettura Risc e CISC nello stesso Soc.

      • Marco

        Non vorrei fare un piccolo trattato su architetture di processori 🙂 mettiamola così (spero chi è del settore non storca il naso) i CISC sono nati quando la memoria costava molto, la velocità sui bus (molto stretti) era bassa e si cercava, con codice molto compatto, di far svolgere nel processore la maggior parte dei compiti. Questo fatto, oltre che per compatibilità con la legacy, ha costretto ad introdurre suffissi, “post-fissi” e ad altri espedienti che dis-allineano il codice e provocavano grossi problemi alla Execution Unit della generazione successiva nell’interpretare le istruzioni e allocare le risorse necessarie (banchi di registri, moltiplicatori, shift registers, etc.).
        In questo ambito sono nati i RISC. Il concetto era semplice, se rendo striminzito il micro-codice faccio una execution unit molto semplice e molto veloce con un suo array di registri facili da indirizzare lascio al SW anziché al microcodice il compito di eseguire lavori complessi. Chiaramente se nel CISC bastava una istruzione a cercare una stringa, nel RISC ne servivano di più, ma interpretate più velocemente, si trattava di un trade-off che al tempo pagava molto.
        In tutto questo si aggiunge il fatto che non sempre nei CISC è facile spiegare la compilatore che vuoi parsare una stringa e di usare proprio quella istruzione specifica, col risultato che non sempre il compilato è efficiente e sfrutta le ultime novità della CPU.
        Giusto per rende idea di quanto “Devil’s in details” i primi RISC non avevano gestione della memoria virtuale integrata, mentre il microcodice iAPX386 (da cui deriva quello attuale x86) sopportava già sia la segmentata che la paginata o una combinazione delle due, con un notevole incremento di lavoro nella CPU (della PMMU interna in realtà) e complicazione dell’instruction-set.
        Ora se voi volevate implementare un OS con memoria virtuale come UNIX, Linux o Windows potevate scegliere iAPX386 e usare le funzionalità interne comunque molto efficienti perché usavano memorie associative, o, su un RISC, scrivere quella parte in SW usando delle unità PMMU esterne con notevole aggravio delle prestazioni (ricordo che la traslazione d’indirizzo si ripercuote in overhead ad ogni accesso di memoria).
        Morale, la CPU x86 è appesantita dal microcodice che supporta le funzionalità PMMU rendendolo meno efficiente nei benchmark, ma presenta poi un vantaggio quando usato nel mondo reale.
        Ai posteri (ed ai benchmark) l’ardua sentenza.
        Successivamente, il silicio ha cominciato a scendere di costo, si sono introdotti nuovi espedienti per velocizzare l’esecuzione come pipeline multiple, a più stadi, code di pre-fetch e branch prediction unit. All’inizio questo andava soprattutto a vantaggio dei RISC (ricordo a metà anni ’90 l’Alpha di Digital era un mostro di potenza rispetto a x86) ma ha poi finito di beneficiare anche i CISC. In un mondo dove la compatibilità con la legacy è tutto, si è riusciti ad aggiungere quelle funzionalità che han fatto la fortuna dei RISC negli x86 (che intanto erano diventati x64) col risultato di colmare molto del gap tra i due mondi.
        La parola fine l’han messa altre esigenze che sono apparse nell’equazione del mercato delle CPU come l’efficienza energetica ed il processo produttivo. Ricordo che le CPU vengono progettate sul principio che le loro piste funzionino “a parametri concentrati” cioè che il segnale su di esse si comporti come un onda quadra e non si accavalli nel corso di una transizione. Per far questo, se vuoi aumentare la velocità devi ridurre le dimensioni del circuito, ed Intel ha sempre mantenuto un vantaggio in questo ambito. Oltre a questo lo stesso processo provvede a ridurre le tensioni e di conseguenza i consumi. L’economia di scala ha fatto i resto e ha decretato la fine di architetture come PPC, MIPS (impiegati come micro-controllori in giochi e applicare domestiche) e la mera sopravvivenza di mondi come SPARC, POWER e HP-PA.
        Oggi ARM si fa forte della relativa semplicità del suo microcodice rispetto ad x86-64, ma tutta la glue-logic della CPU rimane necessaria per entrambi rendendo molto meno evidente il gap tra i due. Io personalmente non lascerei la compatibilità binaria per l’incremento di efficienza a livello attuale, perlomeno su un PC/MAC.

    • Ed è proprio per via di questa “degradazione concettuale” che negl’ultimi anni, con l’ avvento delle nuove CPU a 64bit, è stata intrapresa un’ evoluzione più razionale e radicale dell’ ISA da Apple (con le sue ARM64 del SoC A7) ed ARM (con le sue ARMv8 AArch64)…
      Infatti AArch64 è molto diverso da AArch32 perché le istruzioni “a lunghezza fissa” del set ridotto erano penalizzanti e “perdevano” di efficacia ed agilità in confronto alle istruzioni “a lunghezza variabile” consentite da un set più ampio.

      Ormai non c’è più quel limite e le possibilità vanno ben oltre quelle rese accessibili in precedenza cogli escamotage – tipo quello delle estensioni THUMB – ma dubito che Apple decida così, di punto in bianco, di abbandonare Intel nei Desktop dato che nel lucroso ambiente corporate la compatibilità a Windows è il motivo principale dell’ adozione del Mac che genere un indotto per singolo prodotto elevato – altro che iPhone…

  • Robertino68

    Non capisco l’attinenza tra iPhone e il PC Archimedes. A parte il chip di uguale architettura, non vedo un nesso comune tra i due dispositivi.