Di Steve Jobs si può dire che sia sfacciato e cinico, ma certamente non che viva nel mondo dei sogni. E’ grazie al suo freddo, a volte spietato, pragmatismo che Apple è tornata a essere grande, a imporsi come status symbol, e i suoi prodotti a essere oggetto di venerazione nonché ispirazione o copia, nel bene o nel male che sia.
Soltanto grazie al suo enorme carisma e alla capacità di imporre le sue idee, la sua volontà, in maniera così convincente, Apple è riuscita in un’impresa che sembrava ridicola o, nella meno colorita delle ipotesi, disperata: il traghettamento di quella massa di fanatici integralisti dai PowerPC agli x86 di Intel.
In pochi minuti Jobs è riuscito a trasformare la delusione serpeggiante dei fedelissimi in uno smisurato tripudio per il nuovo, meraviglioso, corso che OS X aveva intrapreso, con una frase che rimarrà nella storia: “Il cuore del Mac è il sistema operativo più che l’hardware“.
D’altra parte non aveva scelta: i PowerPC avevano da tempo perso la leadership prestazionale, e nonostante i benchmark artefatti con cui Apple ne sbandierava ai quattro venti la superiorità, la verità non poteva più essere nascosta grazie anche alla rapida diffusione del web che in poco tempo metteva alla berlina questi tentativi.
Tanto che il passaggio al nuovo venne immediatamente suggellato con grafici che mostravano prestazioni fino a 4 volte superiori rispetto ai “vecchi” Mac, i quali, fino a quel momento, avevano potuto vantare velocità anche doppie rispetto ai PC. Misteri della matematica di casa Cupertino…
L’arrivo dell’architettura Pentium-M/Banias di Intel, che permetteva di ottenere anche consumi decisamente ridotti, è stato il colpo di grazia che ha indotto Jobs a una presa di coscienza sfociata poi alla dolorosa, ma necessaria, decisione.
Che il cuore del Mac fosse ormai OS X era piuttosto evidente da tempo, considerato che dal 1984 al 2005 (anno della svolta) gli elementi hardware distintivi dai PC si erano ridotti sostanzialmente al solo processore con annesso chipset dedicato: tutto il resto era stato man mano “importato” da un mondo odiato, ma che sicuramente faceva comodo.
Ciò che Jobs capì 6 anni fa, cioè l’inopportunità di proseguire con una famiglia di processori ormai non competitiva su tutti gli aspetti (anche quello economico), continua a non voler essere preso in considerazione o, meglio ancora, ignorato da una comunità ancora visceralmente legata al concetto di biodiversità, a trovare quindi un elemento (hardware) distintivo da tutto il resto.
Col fallimento della Commodore e l’arrivo delle nuove schede acceleratrici basate su PowerPC, l’Amiga (o, meglio, ciò che viene inteso con questa etichetta) sembra essersi legato indissolubilmente con questa famiglia di processori, in un connubio che non ha nulla di razionale, ma esclusivamente per fattori empatici e/o nostalgici (ma i nostalgici di lunga data ricordano ancora i 68000).
Aggrapparsi a un microprocessore non ha alcun senso, e questo già da parecchi anni. Fino alla prima metà degli anni ’90 programmare in assembly era una pratica abbastanza diffusa, con gli anni ’80 che hanno rappresentato un periodo d’oro, ma l’interesse è andato via via scemando a causa della sproporzione esistente fra i risultati e il tempo impiegato per ottenerli.
Oggi, infatti, l’uso di questo linguaggio è relegato in ambiti di nicchia dove, ad esempio, le risorse a disposizione sono troppo poche (ad esempio su microcontrollori di fascia bassa), in piccole parti del kernel e/o dei driver di un sistema operativo, o ancora per parti critiche di un’applicazione o gioco.
Perso il forte interesse verso questo linguaggio, automaticamente si perde anche quello per le caratteristiche intrinseche di un’architettura, e ci si concentra su fattori più pragmatici per la valutazione di una CPU: prestazioni, costo, consumi, dissipazione di calore, ed eventuali caratteristiche accessorie (presenza di un’unità SIMD o di una GPU integrata, ad esempio).
Preso atto della situazione non troppo felice discussa nel precedente articolo, ci si dovrebbero rimboccare le maniche e cercare una valida alternativa che consenta di spostare la comunità Amiga su una piattaforma hardware più conveniente sulla quale far girare AmigaOS & derivati per quello che, contrariamente ai pensieri e ai sogni di alcuni, non può avere velleità alcuna, se non quella di rappresentare un hobby.
Le risorse a disposizione purtroppo sono ben poche anche per le società che operano in questo settore, per cui bisognerebbe sfruttarle meglio e valorizzarle il più possibile.
Il team di MorphOS già da tempo non punta sull’hardware, ma preferisce attingere al mercato dell’usato, cioè le vecchie macchine Apple dotate di PowerPC che si trovano a buon mercato e offrono buone prestazioni allo scopo, specialmente in rapporto al costo d’acquisto. Al momento vengono supportati modelli dotati di G4, in attesa degli agognati G5 che dovrebbero riceverlo a breve. Dopo si troverà sostanzialmente in un vicolo cieco, non avendo altro hardware da sfruttare.
Hyperion col suo AmigaOS 4 punta, invece, su macchine nuove, come l’AmigaOne X1000 e la Sam 460 di cui abbiamo già parlato, ma per accaparrarsele bisogna spendere cifre in assoluto molto elevate a fronte di una dotazione hardware che può lasciare delle perplessità (com’è emerso anche dai commenti ai rispettivi articoli).
Inoltre l’X1000 non è ancora stato commercializzato, per cui bisognerà attende ancora qualche mese. Hyperion può continuare a supportare nuove macchine ovviamente, ma tutto dipenderà dai volumi, e il costo elevato rappresenta un forte deterrente nonché una restrizione del potenziale mercato.
L’unica realtà che si è smarcata dal legame con uno specifico hardware, ma che alle spalle non ha alcuna azienda affidandosi esclusivamente al tempo libero di alcuni sviluppatori, è AROS, che già da anni ha preferito puntare sugli x86, da tempo ne supporta anche l’evoluzione a 64 bit (AMD64) che rappresenta il futuro per quest’architettura, coprendo anche i PowerPC, con un bounty aperto per il supporto agli ARM, e con recente supporto ai 68000 che di giorno in giorno si fa sempre più concreto.
Passare da un’architettura a un’altra non è cosa semplice, ma non rappresenta nemmeno un’opera titanica. Fortunatamente i s.o. moderni sono scritti con un linguaggio ad alto livello (usualmente il C), e soltanto poche e piccolissime parti richiedono la scrittura di codice assembly, come già detto.
La documentazione a disposizione non manca di sicuro, e tra l’altro esistono molti progetti di s.o. (portati avanti anche da singole persone!) che girano su variegate architetture da cui si può prendere spunto o eventualmente anche pezzi di codice che possono facilitare la migrazione, driver e supporto alle periferiche inclusi.
MorphOS, ad esempio, adotta il medesimo stack USB di AROS, Poseidon, e non per questo il s.o. perde di valore. Reinventare la ruota, specialmente con le poche risorse su cui si può continuare, non è un demerito, ma al contrario una scelta ampiamente apprezzabile. Sarebbe, anzi, auspicabile una maggior collaborazione nella comunità Amiga, per ridurre la frammentazione e ottimizzare le risorse.
Portare il s.o. non è, comunque, l’unico dei problemi. Dopo il s.o. è ovvio che si dovrà pensare anche alle applicazioni già scritte, ma quante sono? Avrebbe senso sviluppare un emulatore (magari dotato di compilatore JIT) PowerPC per farle girare sul nuovo hardware? A mio avviso quest’ultima strada è troppo costosa in rapporto ai benefici ottenibili.
Parliamo, infatti, di applicazioni abbastanza recenti, per cui è più facile che siano a disposizione i sorgenti, o che comunque la società o il programmatore titolari siano in grado di ricompilarle fornendo degli eseguibili nativi. Il codice scritto bene generalmente non richiede altro che una ricompilazione, specialmente se la toolchain utilizzata è la stessa (quella GNU rappresenta praticamente lo standard di fatto per questi s.o.).
Un grosso scoglio è rappresentato, invece, dalla retrocompatibilità con le vecchie applicazioni 68000 per AmigaOS, sulla quale hanno puntato molto AmigaOS 4 e MorphOS, sfruttando ciascuno delle soluzioni proprietarie (Petunia e Trance) per integrarle in maniera trasparente a quelle native e, soprattutto, con ottime prestazioni che, sembra, si avvicinino molto a quelle PowerPC.
Petunia è scritto in assembly, per cui lo sforzo sarebbe notevole (a parte il fatto che l’autore non sembra interessato), e per Trance penso valga lo stesso, visto il tipo di “applicazione”. Ma anche pensando di non effettuarne il port, affidandosi quindi al solo strato di emulazione 68000, rimarrebbero due grossi problemi, uno immediato e un altro che è soltanto posticipato.
Il primo riguarda la cosiddetta endianess, cioè in che modo la CPU memorizza valori interi che richiedono più di un byte. I 68000 sono stati da sempre big-endian mentre gli x86 sono little-endian. Per le applicazioni native scritte secondo i canoni della buona programmazione, questo non è mai stato un problema, ma per il layer di emulazione adottato da AmigaOS 4 e MorphOS, invece lo è, ed è pure pesante.
Preciso che non si tratta di cattiva programmazione, come si potrebbe pensare da una superficiale lettura della frase, ma di una questione puramente contingente dovuta all’architettura adottata e al meccanismo messo in piedi per garantire la retrocompatibilità, unita a buona velocità d’esecuzione e integrazione con l’esistente (nativo).
Ciò avviene grazie a quelle che in gergo vengono chiamate trap (trappole). Un’applicazione 68000, infatti, gira all’interno di un ambiente che ricalca quello del vecchio AmigaOS, ma nel momento in cui effettua delle chiamate al s.o., queste vengono intercettate e smistate alle API native, quindi con codice PowerPC e beneficiando del nuovo ambiente.
Prendiamo per esempio l’API OpenScreen della libreria intuition.library:
il cui unico parametro è un puntatore a una struttura NewScreen:
Quando un’applicazione 68000 deve invocarla, alloca e riempie opportunamente una struttura di tipo NewScreen, e ne passa il puntatore all’API OpenLibrary.
MorphOS e AmigaOS 4 hanno inserito una trap all’indirizzo in cui si trova l’API OpenLibrary (lato 68000), che provvede a reindirizzare la chiamata alla versione nativa di OpenLibrary, che prende la struttura NewScreen e si occupa di portare effettivamente a termine l’operazione, ritornando poi il risultato all’applicazione 68000 (un puntatore alla struttura Screen, allocata e riempita opportunamente lato PowerPC / nuovo s.o.).
Questo meccanismo funziona benissimo fintanto che l’endianess dei due processori rimane la stessa, ma smette di funzionare in caso contrario. Infatti se il nuovo s.o. girasse su una macchina little-endian, tutti i campi di tipo WORD (e LONG) nonché i puntatori risulterebbero completamente errati, in quanto il codice 68000 li avrebbe riempiti memorizzando prima i byte più significativi fino a quelli meno significativi, mentre il processore “nativo” li leggerebbe esattamente al contrario (dal meno significativo al più significativo).
Come si può intuire, si tratta di un problema di difficile soluzione, e infatti al momento AROS non offre un layer di emulazione 68000 simile a quello di AmigaOS 4 e MorphOS.
Da questo punto di vista l’adozione di ARM quale architettura sulla quale far girare le nuove versioni di questi s.o. rappresenta la scelta migliore, in quanto è in grado di lavorare indifferentemente in modalità big-endian o little-endian.
Al momento non ci sarebbero consistenti vantaggi prestazionali rispetto ai PowerPC, ma sicuramente sul piano economico si tratta di soluzioni di gran lunga più abbordabili (basti pensare, ad esempio, ai tablet che arriveranno in massa a invadere il mercato).
In ogni caso anche l’adozione di ARM rimanderebbe di qualche anno la soluzione a questo problema, perché verrebbe riaperto col passaggio ai famigerati 64 bit (previsti nel 2015 per i nuovi ARM).
Infatti se l’endianess non porrebbe più grattacapi, i puntatori di dimensione doppia (8 byte anziché 4) ne presenterebbero altri non risolvibili (se non castrando lo spazio d’indirizzamento a 4GB totali, perdendo il beneficio principale del passaggio ai 64 bit).
Questo perché i puntatori lato 68000 rimarrebbero sempre a 32 bit, mentre quelli dell’architettura nativa sarebbero a 64 bit, che… non possono essere “compressi” o “ridotti” a 32 bit per essere utilizzabili nell’ambiente 68000. Discorso, questo, che si applica anche alle architetture PowerPC a 64 bit, ovviamente.
Si capisce bene, e concludo, come l’adozione di ARM o x86 come nuova architettura al momento (cioè finché non verrà tirata fuori il classico uovo di Colombo) pone davanti a una drastica scelta: barattare l’ottimo livello di retrocompatibilità raggiunto finora, con le migliori prestazioni (nonché quantitativi di memoria utilizzabili) di s.o. e applicazioni native.
Sarebbe interessante, a questo punto, conoscere l’opinione di chi ci lavora in merito agli argomenti trattati, e cosa ne pensano del futuro dei loro sistemi.
