Introduzione
Il 24 gennaio 1984 fu immesso sul mercato il primo Macintosh. Si trattava di una macchina rivoluzionaria, che avrebbe cambiato il mondo dell’informatica e la vita di milioni di utenti: lavorare al computer finalmente poteva essere alla portata di tutti. Sul primo Mac c’era una CPU Motorola 68000, così chiamata per il numero di transistor integrati al suo interno, che era appunto 680000. Il Motorola 68000 era un processore CISC e con le sue varianti ha equipaggiato i Macintosh fino a marzo 1994, data di uscita dei Power Macintosh.
I Power Macintosh erano dotati di una CPU RISC PowerPC 601 prodotta dal consorzio formato da IBM, Motorola ed Apple e per anni con la loro potenza hanno contribuito a rendere i Macintosh insuperabili rispetto ai personal computer basati su architettura intel e sistema operativo windows. Dopo undici anni dall’ultima svolta Steve Jobs, alla Worldwide Developers Conference (WWDC) del 2005, annuncia la nuova transizione: sritorna ad un architettura CISC con i processori Intel. I Processori PowerPC non riuscivano più a soddisfare le necessità dei Macbook di avere grandi potenze a basso consumo. I PowerPC scaldavano troppo, calore significa energia e quindi consumo della batteria. Con i nuovi processori Intel si sarebbero potute realizzare macchine meno pesanti, più potenti e con un’autonomia maggiore. La nuova architettura avrebbe inoltre consentito di usare Windows in maniera nativa, attirando verso la casa di Cupertino milioni di nuovi clienti. Oggi stiamo usando queste macchine meravigliose con soddisfazione, godendo i frutti offerti dalla maturità dell’architettura, ma all’orizzonte si prospetta un nuovo cambiamento epocale: un nuovo passaggio ai processori RISC con i processori ARM. Le ragioni sono di nuovo la necessità di realizzare macchine più potenti caratterizzate da un minore consumo energetico. Vi è poi la voglia di non dipendere da intel per la progettazione dei processori che saranno progettati direttamente da apple e realizzati da TMSC: Apple potrà così sfornare, come sta facendo con i suoi iDevice, i nuovi MacBook insieme ai nuovi processori. Una scelta di marketing, ma anche la comprensibile necessità di razionalizzare la produzione. Molte volte, infatti, è successo che l’uscita dei nuovi processori intel seguisse di pochi mesi l’immissione sul mercato di un prodotto Apple, mentre ai fini commerciali e per l’utilizzatore finale sarebbe stato meglio il contrario. I cambiamenti spaventano perché sono fonte di problemi. Vanno attuati solo in caso di estrema necessità e devono essere ben ponderati ed organizzati. Portano nuovi compagni di viaggio ma ne lasciano sempre indietro qualcuno. Nel seguito di questo articolo analizzando le due transizioni passate cercheremo di immaginare cosa ci dobbiamo aspettare dalla terza. Sarà necessario partire da qualche piccolo approfondimento tecnico, non ce ne vogliano gli studenti del corso di Architettura dei Calcolatori per le necessarie approssimazioni dovute al taglio divulgativo con cui vogliamo trattare l’argomento.
Offerte del momento |
|
|---|---|
 |
 |
| Apple AirPods con 50€ di sconto | Apple Watch serie 3 con 10€ di sconto |
Archittetura Cisc e RISC a confronto
Passando da Motorola a PowerPC si è passati da un’architettura CISC ad una RISC; con il passaggio da PowerPC a Intel si è fatto il contrario. Con l’avvento dei processori ARM si ritornerà alla filosofia RISC. CISC è l’acronimo di Complex Instruction Set Computing, mentre RISC significa Reduced instruction set computing. Ogni famiglia di processori ha codificato al suo interno un set d’istruzioni di base. Combinando queste istruzioni il compilatore riesce a fare eseguire le operazioni previste dallo sviluppatore dell’applicazione. Per raggiungere lo stesso risultato posso lanciare un’unica operazione complessa o un insieme di operazioni più semplici in sequenza. Lo sviluppatore attraverso il linguaggio di programmazione a lui più congeniale, ad esempio Swift o il vecchio Objective-C, crea il programma. Il compilatore traduce le istruzioni del linguaggio ad alto livello in linguaggio macchina. In pratica ogni istruzione ad alto livello viene tradotto in più istruzioni a basso livello, quelle che compongono il set d’istruzioni del processore. Con un set di istruzioni complesse (CISC) ogni istruzione del linguaggio ad alto livello viene tradotto in un numero minore d’istruzioni in linguaggio macchina rispetto a quanto avverrebbe con un processore a set d’istruzioni ridotto (RISC). Un’istruzione CISC che svolge un determinato compito impiega un numero di cicli di clock corrispondente alla complessità della sua azione. Lo stesso avviene con le istruzioni RISC, ma in questo caso il numero di cicli di clock sarà minore, uno o poco più, dato che le istruzioni RISC in genere sono molto meno complesse rispetto alle CISC. Naturalmente il compito da svolgere rimane lo stesso e quindi impiegando per svolgerlo più istruzioni semplici od un numero minore di istruzioni complesse il risultato non dovrebbe cambiare. In realtà le cose stanno in maniera diversa. Spesso con l’architettura CISC per svolgere un compito semplice si è costretti ad utilizzare un’istruzione complessa che produce effetti non dannosi ma che rallentano il flusso delle operazioni con cicli di clock inutili perché di quella particolare operazione ci serve solo un una parte. Con l’architettura RISC questo non succede, per raggiungere il suo scopo il compilatore aggregherà solo le istruzioni atomiche strettamente necessarie riuscendo spesso a risparmiare preziosi cicli di clock. All’epoca del passaggio da PowerPC a intel, i processori intel furono preferiti per la loro capacità di consumare meno energia. Era il 2005 ed le rispettive ottimizzazioni ed ibridazioni tra i due modelli di calcolo erano andate nella direzione di una drastica riduzione del divario prestazionale: tutto si giocava sull’efficienza dei compilatori e sulla micro architettura interna. Intel in quel periodo era vincente e Steve Job non ebbe dubbi sul da farsi.
Emulazione vs virtualizzazione
Tute le volte che Apple ha cambiato l’architettura dei suoi prodotti, per mantenere la compatibilità con il software della generazione precedente ha dovuto fare ricorso all’Emulazione. L’emulazione è necessaria quando l’hardware del sistema con il quale si vuole mantenere la compatibilità, o del quale si vogliono fare funzionare le applicazioni, viene completamente emulato dal programma di controllo in quanto risulta incompatibile con quello presente sulla macchina ospitante. Il processo di emulazione risulta più lento rispetto alla virtualizzazione, a causa della traduzione delle istruzioni dal formato del sistema ospite a quello del sistema ospitante. La virtualizzazione, invece, viene adottata quando il sistema operativo che si vuole ospitare sulla macchina ospitante è compatibile con il suo hardware e si deve semplicemente implementare l’isolamento necessario a separare il sistema ospitato dall’hardware fisico della macchina ospitante. Va da sé che la virtualizzazione è molto più veloce e affidabile dell’emulazione. Allo stato attuale, per esempio, è molto facile ospitare su un Mac una macchina virtuale windows, come è molto semplice creare un dual boot con i due sistemi. Col passaggio ad ARM le macchine windows potranno essere solo emulate ed il dual boot sarà impossibile. Microsoft ha realizzato un porting di windows su ARM, ma al momento non tutte le applicazioni che girano su piattaforma x86 sono compatibili con il nuovo sistema, né c’è garanzia che lo saranno in futuro. Si tratta molto spesso di importanti applicazioni per la gestione dei video e delle immagini.
1994: il passaggio da Motorola a PowerPC
Il passaggio da Motorola a PowerPC fu molto graduale e lento. All’inizio della transizione il sistema operativo conteneva pochi moduli compilati nativamente per il PowerPC. Per garantire il funzionamento di tutte le parti del sistema operativo è delle applicazioni utente, venne sviluppato un micro kernel sul quale funzionava un emulatore del Motorola 68LC040. Una parte del sistema operativo chiamatala Mixed Mode Manager era deputata a stabilire in tempo reale se il codice in esecuzione dovesse essere processato in maniera nativa dal processore PowerPC o dall’emulatore 68LC040. Un sistema molto utilizzato per la distribuzione delle applicazioni a cavallo delle sue architetture fu l’utilizzo di programmi fat binary. In pratica, l’applicazione veniva compilata per sia processore Motorola 68000 che per il PowerPC. Il codice per PowerPC (nel formato PEF) veniva inserito all’interno del data fork del programma, mentre il codice per 68000 veniva mantenuto nel resource fork. Le dimensioni dei file eseguibili, con questo sistema, erano circa il doppio di quelle della singola architettura, cosa che, in un periodo in cui le dimensioni tipiche di un disco erano 80 MegaByte, poteva rappresentare un problema. Si produssero così molte utility di terze parti che eliminavano dagli eseguibili la parte inutilizzabile dalla macchina su chi erano installati. 
Il periodo dal 1994 al 2001 per Apple fu uno dei più travagliati. Bisognava contrastare l’avanzata di Windows con un sistema operativo MacOS che non era all’altezza dei processori e mancava di due componenti fondamentali: la protezione della memoria ed il preemptive multitasking. MacOS 8.5, siamo nel 1998, sarà il primo sistema operativo ad essere usato solo su sistemi PowerPC, il successivo MacOS 8.6 introduce il multitasking. Il sistema era comunque ancora debole, ma lo sarebbe stato ancora per poco. MacOS 9 fu il sistema di passaggio a MacOS X. Con MacOS 9 furono rilasciate le API Carbon che dovevano essere utilizzate da chi avesse voluto realizzare applicazioni adatte al sistema operativo attuale ma pronte per funzionare su MacOS X . MacOS uscì il 24 marzo 2001 ed era il sistema a base UNIX con il quale MacOS chiudeva con il passato non essendo più installable su macchine con processore Motorola. I vecchi programmi erano comunque supportati o attraverso Carbon o attraverso l’uso di un emulatore chiamato Classic che riproduceva virtualmente MacOS 9.2 sul quale giravano tutte le App di MacOS 9 e quasi tutte quelle di Ststem 7 e MacOS 8.
2005: il passaggio da PowerPc a intel
Steve Jobs annuncia il passaggio pa PowerPC ad Intel alla WWDC del 6 giugno 2005. C’era bisogno di processori più potenti, più piccoli e più parchi nei consumi. Intel prometteva 70 unità di performance contro le 15 dei PowerPC, il passaggio fu coraggioso quanto obbligato. La transizione fu operativa in poco più di un anno; il tempo intercorso tra l’annuncio e il rilascio delle prime macchine dotate di processore intel servì agli sviluppatori per adeguare i loro prodotti alla nuova piattaforma. Apple, fin dall’inizio dello sviluppo di Mac OS X, aveva segretamente compilato il sistema operativo per la piattaforma X86 oltre a quella PowerPC compilando cinque diverse versioni di Mac OS X in grado di essere eseguite anche con macchine dotate di chipset Intel. 
Per girare su CPU Intel il software precedente doveva essere ricompilato dagli sviluppatori con la nuova versione di xCode oppure essere eseguito con “Rosetta”, un emulatore presente in MacOS X. Rosetta non risolveva, però, tutte le situazioni ed avere idea dei suoi limiti ci può far capire meglio a quale genere di problematiche si va incontro quando si cambia radicalmente l’architettura del processore. – Le applicazioni progettate per qualsiasi versione di Mac OS precedenti a Mac OS X vale a dire Mac OS 9, Mac OS 8, Mac OS 7 etc.. non potevano essere eseguite. – l’emulatore Classic, che come detto emulava Mac OS 9 nei Mac con PowerPC, non era supportato – i salvaschermo scritti per l’architettura PowerPC non erano supportati – Non erano supportate applicazioni che inserivano preferenze nel pannello delle preferenze di sistema – non erano supportate applicazioni che o progettate specificamente per il procesore G5 – Non erano supportate applicazioni che per funzionare si basavano su estensioni del kernel PowerPC – non erano gestite le estensioni del Kernel – non funzionavano applicazioni Java con librerie JNI – non funzionavano gli Applet Java nelle applicazioni tradotte da Rosetta. Ad esempio un programma di navigazione Web tradotto da Rosetta molto probabilmente non avrebbe potrebbe potuto caricare applet Java. Inoltre, per girare al meglio sotto archittetura Intel con Rosetta un applicazione compilata per PowerPC necessitava di una quantità di memoria dal doppio al triplo di quella necessaria per girare su un Mac PowerPc. Rosetta accompagnò per molto tempo la transizione ad Intel, il suo supporto terminò nel 2011 con Mac OS X Snow Leopard. Per le nuove applicazioni, Xcode, a partire dalla versione 2.1, permetteva di effettuare una compilazione che dava luogo ad eseguibili chiamati Universal Binary che includevano sia la versione compilata per PowerPC che quella compilata per x86 della stessa applicazione. Apple aveva usato una tecnica simile, chiamata Fat binary, durante la transizione dai processori della serie Motorola 68000 al PowerPC.
2020 il passaggio da intel a ARM
Con ARM Apple potrà dotare i suoi MacBook prima, ed i computer fissi successivamente, di processori pensati specificatamente per le sue linee di prodotti, facendo un ulteriore passo avanti nell’integrazione tra il suo software ed il suo hardware. Sarà una transizione lenta e difficile, una transizione, però, necessaria. Le incognite sono molte e riguardano diversi aspetti; domande che troveranno risposte, si dice, alla prossima WWDC del 22 giugno 2020. Per vedere le nuove macchine, con ogni probabilità dotate di processori ARM a 12 core con processo produttivo 5 nanometri, bisognerà aspettare il 2021. Per forza di cose il sistema operativo per la nuova architettura dovrà disporre di un ambiente di emulazione dell’architettura precedente. I programmi che utilizziamo, non ancora ricompilati per la nuova architettura, continueranno, in massima parte, a funzionare. Li installeremo e lanceremo alla solita maniera, non ci accorgeremo del lavoro dello strato di emulazione sottostante se non per il calo di prestazioni. Quanto questo calo sarà evidente dipenderà dall’efficienza del nuovo emulatore. La riuscita della transizione dipenderà dal supporto e dagli strumenti che verranno dati agli sviluppatori. Molto probabilmente mentre scriviamo queste righe alcune software house, le più importanti, stanno già lavorando in gran segreto con la nuova architettura, utilizzando i nuovi compilatori, in modo da avere alla partenza un certo numero di applicazioni sviluppate in maniera nativa per la nuova piattaforma. Già adesso con Catalyst è possibile convertire con poco sforzo applicazioni nate per ed iPad in modo da funzionare sul Mac, con un ARM anche sui Mac il processo sarà ancora più efficiente e veloce, ma chi pensa che il futuro dei MacBook sia un tablet con appiccicata una Magic Keyboard sbaglia di grosso: le due linee rimarranno separate anche se saranno dotate di processori della stessa famiglia. Sul fronte Windows, invece, a meno di qualche colpo di genio, sarà un bagno di sangue. Chi si affida a BootCamp e alla virtualizzazione per trarre il meglio dalle due piattaforme, non passi immediatamente al nuovo e stia per un certo periodo di tempo alla finestra a guardare l’evolversi della situazione facendo passare ottimizzazioni, miglioramenti ed assestamenti. La buona notizia è che anche Windows sta lavorando per portare Windows 10 su ARM. Le vecchie applicazioni x86 sono fatte girare sotto emulazione, mentre quelle scaricate dallo store Microsoft sono compilate per la nuova architettura. Quello che non funziona sono i driver di periferica che devono essere riscritti per ARM.
Conclusioni
Questo cambiamento è un male necessario. I molti utenti Mac che hanno di recente speso parecchio in macchine professionali dovranno riconsiderare i tempi di ritorno dell’investimento. Ci sarà un lungo periodo di interregno in cui le due architetture conviveranno, poi il supporto ad Intel terminerà. Chi può aspetti il più possibile per cambiare computer. In molti saranno costretti a passare o ritornare a Windows. Non è tempo di facili entusiasmi, la strada che dovremo percorrere è in salita. A guidarci in questo lungo cammino ci sarà Apple. Speriamo che sappia con precisione dove vuole portarci e che il prezzo da pagare per il viaggio non sia troppo caro. Claudio Di Tursi
Se stai per fare un acquisto su Amazon e desideri supportare Applephilosophy, clicca sul banner qui sotto. Per ogni acquisto il blog riceverà una piccolissima percentuale. Ovviamente NON spenderai un centesimo di più di quanto avresti speso per gli stessi acquisti andando direttamente su Amazon.