Le vicissitudini dei sistemi Amiga “NG” sono state oggetto di attenzione già diverse volte in queste pagine. L’ultimo caso riguarda lo spropositato costo di acquisto della CPU dell’AmigaOne X1000, che è arrivato a toccare i 1000 dollari.
D’altra parte dovendo attingere a del materiale per realizzare macchine a uso “desktop” (sarebbe forse meglio dire “personale”), per la famiglia PowerPC non esistono più delle alternative valide, per cui bisogna ricorrere a costosissimi fondi di magazzino, come quelli citati, oppure al settore embedded, quindi riciclando roba pensata per router et similia.
Nei forum Amiga si continua a favoleggiare di nuovi processori che arriveranno da Freescale, ma che continuano a essere pensati per il suddetto settore, quindi tutt’altro che ottimali per un uso “desktop“: tanti piccoli core impaccati, ognuno con discrete prestazioni single thread.
Fanno un po’ tenerezza le citazioni dei membri della famiglia POWER di IBM, autentici mostri macina numeri, non v’è dubbio, ma destinati a ben altri scopi. Segno, questo, che i più affezionati integralisti coltivano (e vivono) sogni del tutto irrealizzabili, aggrappandosi a qualunque cosa o notizia abbia appiccicata l’etichetta PowerPC.
E così via coi processori progettati da IBM per i suoi supercomputer BlueGene (prodotti che notoriamente si possono comprare nel supermercato dietro l’angolo), oppure il continuo rispolvero delle console (queste sì che si possono trovare a buon mercato ovunque), autentico cavallo di battaglia degli affezionati a questa famiglia di microprocessori.
Purtroppo anche da quest’ultimo fronte arrivano pessime notizie. La prossima Playstation verrà realizzata da AMD e non da IBM, e sfrutterà le sue ben note APU, basate su x86. Microsoft non sembra essere da meno, in quanto già da tempo le voci che si susseguono per la prossima console hanno parlato di core ARM, e successivamente di core x86; magari la realtà starà in mezzo, con un sistema eterogeneo di core x86 e ARM a spartirsi precisi compiti.
Rimane patriotticamente Nintendo con la Wii U, erede della Wii (aka GameCube 1.5), che continua ad affidarsi a IBM e, quindi, ai PowerPC. Dalle voci che circolano, però, la sua potenza di calcolo sarà paragonabile o leggermente superiore alle console di questa generazione. Roba di 6-7 anni fa, insomma. Nulla di cui potersi vantare o da prendere come esempio o speranza a cui aggrapparsi disperatamente…
Ce n’è abbastanza per comprendere che questa strada non è più conveniente, e bisogna cercare delle valide alternative sulle quali poggiarsi. L’ha capito persino Apple, prima forza a puntare sui PowerPC creando il relativo consorzio con IBM e Motorola, che quest’epoca d’oro era finita, sancendo il definitivo passaggio a Intel 7 anni fa, e abbandonando senza troppi rimpianti un progetto che ormai aveva fatto il suo tempo.
Non lo capiscono o non vogliono capirlo i fanatici amighisti “new gen”, in una sorta di difesa dell’ultimo baluardo della fede costituita. PowerPC o morte. Perché per essere amighisti, oggi, non si può essere “omologati”: ARM o, peggio ancora, x86. La biodiversità, in quest’ambito, è ancora un valore; forse IL valore sopravvissuto, ormai. Ma di questo ne abbiamo già discusso nel precedente articolo.
Eppure i vantaggi di un passaggio a un’architettura più prospera, come quelle citate, sono innumerevoli. Componenti a basso costo, con prestazioni elevate (ma anche consumi ridotti), e un supporto eccezionale oltre che estremamente longevo (difficile pensare al declino di x86 e/o ARM), con un parco macchine già disponibile e vastissimo. Cose, anche queste, arcinote.
Cose che dovrebbero essere prese in seria considerazione da chi tira le redini della piccola carovana amighista, specialmente nel momento in cui il prezzo di una CPU, già molto cara inizialmente, raddoppia di colpo.
Oggi una CPU x86 che offre caratteristiche “fisiche” comparabili (numero di core, frequenza, dimensione delle cache, banda verso la memoria, ecc.) costa meno di un ventesimo (sì, avete letto bene, poiché parliamo della più bassa fascia di mercato) del PA6T della defunta P.A. Semi, pur rimanendo nettamente superiore in termini prestazionali, e potendo anche contare su una GPU integrata (eccellente quella in dotazione dei prodotti AMD). Gli ultimi listini di Intel e AMD sono a dir poco impietosi.
Piuttosto che regalare fiumi di denaro per una CPU obsoleta (il cui unico valore aggiunto è rappresentato dall’essere un PowerPC; quindi papabile per AmigaOS 4 in primis; al momento), sarebbe di gran lunga più saggio investire la differenza finanziando il porting di AmigaOS 4 (ma MorphOS si trova nelle stesse condizioni) verso x86 o ARM.
Non sappiamo quante macchine prevedeva il piano del benefattore Trevor Dickinson. Si è parlato di qualche centinaio; alcuni si sono spinti ben oltre azzardando addirittura qualche migliaio (praticamente buona parte della comunità Amiga avrebbe comprato un X1000: del tutto irrealistico). Numeri non ne sono mai stati divulgati, e non si capisce bene il perché.
Comunque qualche cifra la si può tirare fuori giusto per illustrare rozzamente l’idea. Supponiamo che ci siano da realizzare altre 50 macchine, ma che si voglia impiegare x86 come architettura. Con 200 dollari si può pagare una scheda madre di discreta fattura, un processore dotato anche di GPU, e 8GB di RAM. Altri 200 serviranno per il case, l’alimentatore e l’hard disk, e infine 100 per la licenza di AmigaOS. Totale: 500 dollari (tasse incluse).
Aggiungendo 1000 dollari per il porting di AmigaOS su x86, si arriva a 1500. Da qui ai 2682 (senza tasse; più circa 100 di licenza AmigaOS 4) a cui sono state vendute le prime macchine X1000 si va ben oltre i 1000 dollari, che si possono ripartire fra spese di distribuzione, guadagni, e magari anche un forte sconto per gli acquirenti finali.
Vendere 50 macchine in queste condizioni significa mettere da parte ben 50 mila dollari per il porting di AmigaOS 4. Ricordiamo che per portare AmigaOS 3.1 (più alcune parti di 3.5 e 3.9) da Motorola 68000 a PowerPC la cifra concordata fra Amiga Inc. e Hyperion fu della metà, quindi 25 mila dollari. E’ vero che in quest’arco di tempo quel valore è aumentato a causa dell’inflazione, ma non è di certo raddoppiato e in ogni caso lo sforzo non è comparabile.
x86 (ma il discorso, in misura minore, vale anche per ARM), infatti, è un’architettura diffusissima, e non manca di certo documentazione, esempi, siti di riferimento, e perfino interi sistemi operativi open source dai quali attingere informazioni e/o codice per facilitare e accorciare i tempi. C’è talmente abbondanza di materiale, che singole persone si permettono il lusso di scrivere nuovi s.o. da zero per x86 per puro diletto…
Inoltre a venire in aiuto dei “cugini” potrebbe essere ancora una volta quello che è sempre stato ritenuto il brutto anatroccolo della comunità Amiga: AROS. Già in passato AmigaOS per le versioni 3.5 e 3.9 aveva attinto al suo codice per alcune cose, e lo stesso ha fatto il team di MorphOS per molto altro, per cui eventuali “puristi” avrebbero ben poco da schifarsi se l’operazione venisse nuovamente ripetuta.
AROS gira già su x86 (e x64), ed è disponibile per altre architetture (ARM attualmente non è disponibile in versione nativa, ma soltanto hosted), inclusa la gloriosa 68000. Dunque tutto ciò che serve per far partire un altro kernel si potrebbe tranquillamente riciclare, riducendo i costi di questa parte del porting. Per la compilazione dei sorgenti non dovrebbe esserci alcun problema, perché la toolchain di sviluppo dovrebbe essere quella GNU per tutti; nel bene e nel male.
AROS può essere utile anche per prendere spunto (anche pezzi di codice) per le API e operazioni di più basso livello. Alla fine parliamo pur sempre di s.o. AmigaOS/like, che hanno esigenze comuni e spesso identiche, le cui problematiche sono state già affrontate dagli sviluppatori di questo s.o.. Ovviamente ce ne saranno altre, ad esempio legate all’uso dell’MMU, ma documentazione ed esempi non mancano di certo per x86, per cui possono essere risolte velocemente.
Comunque in un’operazione di questa portata il maggior intoppo è rappresentato dalle applicazioni. Nello specifico, ce ne sono di due tipi: “native” / PowerPC, e “legacy” / 68000.
Per quelle native non dovrebbero esserci problemi, visto che generalmente vengono aggiornate, quindi dovrebbe essere sufficiente una ricompilazione cambiando il target della CPU per ottenere gli eseguibili funzionanti per la nuova piattaforma hardware.
L’unico grattacapo potrebbe essere rappresentato dalla presenza di codice assembly PowerPC, ma inizialmente dovrebbe essere sufficiente passare al normale codice C/C++ (o altro), eventualmente pensando dopo a tradurre quelle parti in assembly x86, se ciò fosse necessario.
A mio avviso non ha senso prendere in considerazione l’idea di realizzare un emulatore PowerPC per far girare questo tipo di applicazioni su x86, per quanto detto. Posto che esistono già emulatori e compilatori JIT da PowerPC a x86 (per cui il lavoro non sarebbe poi tanto), è inutile sprecare preziose risorse allo scopo, quando c’è ben altro da fare.
Il dramma potrebbe essere rappresentato dalle applicazioni 68000, di cui difficilmente esistono sorgenti (altrimenti sarebbero già state portate per PowerPC, appunto, e la stessa cosa si potrebbe fare per farle girare su x86 o altro), che generalmente sono ancora molto utilizzate.
AmigaOS 4 e MorphOS offrono due soluzioni (Petunia e Trance), per farle girare (quasi) in maniera completamente trasparente rispetto a quelle PowerPC, trattandole quindi “alla pari”. Sono, infatti, in grado di condividere e manipolare praticamente tutto, persino le strutture del s.o.; croce e delizia della tradizione AmigaOS.
Poiché la mera emulazione risulterebbe troppo lenta, entrambi gli strumenti consentono di compilare al volo codice 68000 in binario PowerPC, accelerando parecchio la velocità d’esecuzione delle vecchie applicazioni, che traggono parecchio giovamento da questa funzionalità.
C’è da dire che in realtà eseguire codice 68000 per AmigaOS 4 rappresenta anche una necessità, visto che alcune parti del vecchio AmigaOS continuano a rimanere come binario 68000 e non sono mai state portate su PowerPC (quindi il porting, alla fine, non è nemmeno stato completato). AREXX è l’esempio più noto, ma a questo punto non è escluso che possano esservi altre parti del s.o. nella stessa situazione.
AREXX per buona parte è disponibile anche su AROS, per cui si potrebbe riciclare tutto il lavoro che è stato fatto. Inoltre non mancano di certo emulatori per 68000, e compilatori JIT che generano codice x86.
Ciò che frena, in questo caso, è la diversa “endianess“, cioè l’organizzazione in memoria dei dati costituiti da più di un byte (2 o 4 byte, visto che i 68000 sono macchine a 32 bit). 68000 e PowerPC sono big-endian, mentre x86 è little-endian. ARM nativamente è little-endian, ma è in grado di cambiare al volo modalità, passando a leggere e scrivere dati in formato big-endian.
Da tutto ciò sembrerebbe che x86 sia tagliata fuori dai giochi, ma non è affatto così, perché è sempre possibile convertire dati dall’una all’altra endianess. Il problema è il costo dell’operazione, che potrebbe risultare troppo penalizzante in termini puramente prestazionali.
Convertire una word a 16 bit (due byte) è piuttosto semplice con x86: una volta letta, oppure prima di scriverla, è sufficiente eseguire una sola istruzione di rotazione di 8 bit della word per ottenere il risultato richiesto. Il costo dipende dall’implementazione specifica dell’architettura x86, ma da parecchi anni è di 1 ciclo di clock (quindi non molto). Nel caso in cui il dato si trovasse nei registri AX, BX, CX, o DX, si potrebbe utilizzare, invece, una ancora più comoda e generalmente più efficiente istruzione XCHG (XCHG AL,AH, ecc.).
Un discorso analogo vale per le word a 32 bit (quattro byte), che per la conversione richiedono un’apposita istruzione introdotta da Intel con l’80486, BSWAP. A seconda dell’implementazione, richiede 1 o due cicli di clock; un costo abbastanza sostenibile, anche questo (specialmente con architetture out-of-order).
In condizioni migliori dovrebbero trovarsi gli Atom, coi quali Intel ha introdotto l’istruzione MOVBE, che serve a leggere o scrivere dati direttamente in formato big-endian, quindi senza alcuna operazione di conversione preliminare. E’ difficile trovare dati su latenza e throughput, ma trattandosi di istruzioni di MOV mi aspetto che siano allineati a quelle normali (quindi eccellenti).
Oltre agli Atom, dovrebbero essere presenti nei futuri core Haswell di Intel, e negli Steamroller di AMD (si trovano anche nei suoi core a basso consumo, a partire da Jaguar, il successore di Bobcat).
La situazione, quindi, non è così drammatica per gli x86, e inoltre è destinata a migliorare enormemente grazie all’introduzione della suddetta istruzione MOVBE, che verrà implementata in tutte le future architetture x86 (e x64).
E’ possibile, poi, applicare ulteriori ottimizzazioni in casi particolari (ad esempio nel caso di MOVE eseguite da memoria a memoria, con le MOVE16 dei 68040, le MOVEM, e altro ancora). Facendo ricorso a tecniche di data-flow analysis si può anche eliminare codice ridondante, o ancora ottimizzare altri casi particolari.
C’è, insomma, parecchio margine per aumentare le prestazioni, e probabilmente molte ottimizzazioni saranno già presenti nei compilatori JIT 68000 per x86, ma i problemi più grossi per far convivere e trattare come “first class” le applicazioni 68000 su x86 sono altri, e uno si trova celato nelle implementazioni dei compilatori.
Si tratta, infatti, dell’allineamento delle strutture dati, in particolare per dati di 16 o più bit. In questi casi i compilatori provvedono al cosiddetto “padding“, cioè a riempire opportunamente i dati che non sono perfettamente allineati alla loro dimensione (esempio: una word a 16 bit che sta a un indirizzo dispari; si aggiunge un byte prima dell’inizio della word, in modo che risulti allineata 16 bit).
Lo si fa esclusivamente per questioni di velocità per x86, mentre per alcune architetture RISC (anche le versioni più vecchie degli ARM) lo richiedono espressamente, perché non sono in grado di leggere word disallineate (cosa che, peraltro, capitava anche sui 68000, dove l’allineamento minimo per word a 16 e 32 bit era di 16 bit, in mancanza del quale veniva sollevata un’apposita eccezione).
Per x86 non c’è alcun problema, perché fin dall’antenato 8086 è sempre stato possibile leggere word disallineate; in questi casi l’unica motivazione che porta al padding / allineamento dei dati è quella prestazionale, come già detto.
Quindi volendo mantenere piena compatibilità ed esecuzione completamente trasparente delle applicazioni 68000 su x86, sarebbe necessario compilare AmigaOS 4 e MorphOS con apposite direttive che escludano qualunque allineamento, in modo tale che la medesima struttura dati (ad esempio Node, Library, ecc.) utilizzata da un’applicazione 68000 per comunicare col s.o. x86 abbia fisicamente la stessa dimensione e i campi si trovino, oltre che della medesima dimensione, esattamente allo stesso offset.
In questo modo una struct allocata o manipolata da un’applicazione 68000 può essere tranquillamente passata al s.o. x86 (o ad altre applicazioni “native”), e viceversa per le strutture allocate da x86 e passate al mondo 68000.
Fortunatamente per sistemare i problemi di allineamento / padding esiste un’apposita direttiva di compilazione per GCC & compagnia: -fpack-struct . Una volta specificata, il compilatore “impacchetta” le strutture senza ricorrere al padding, facendo occupare ai dati esattamente e soltanto lo spazio richiesto dalla loro dimensione effettiva.
A questo punto sembrerebbe tutto risolto, ma in realtà è rimasto il secondo, ben più grave problema rispetto al padding. Essere in grado di convertire, o leggere/scrivere velocemente dati in formato big-endian, e viceversa, non è sufficiente per risolvere i problemi di comunicazione fra i due mondi con endianess diversa.
Se il s.o. alloca una struttura e la inizializza, per poi passarla alle applicazioni, i dati costituiti da word (sempre 16 o 32 bit) saranno memorizzati in formato little-endian. Nessun problema per le applicazioni native x86, ma quando una 68000 andrà leggere questi dati, effettuerà la citata conversione, ottenendo… spazzatura (tranne per casi banali, come ad esempio il valore zero e il puntatore nullo).
Idem per un’applicazione 68000 che alloca una struttura, ma provvede poi lei a inizializzarla opportunamente: i dati che scriverà sono in formato big-endian, mentre il s.o. (e le altre applicazioni) li leggeranno come little-endian…
E’ bene precisare che queste difficoltà esistono esclusivamente per le strutture che devono essere condivise fra i due mondi con diverse endianess, perché un’applicazione 68000 può tranquillamente creare strutture a uso interno o passarle ad altre applicazioni 68000 senza alcun problema, e la stessa cosa vale per quelle native.
In questo caso le architetture ARM hanno già la soluzione pronta: possono lavorare sempre in modalità big-endian, per cui tutto viene risolto a monte. x86 non è in grado di farlo, quindi serve cercare altre soluzioni.
Una è quella di “intrappolare” tutti gli accessi a word che avvengono in strutture “pubbliche” (scambiate fra tutti gli attori), sfruttando delle apposite macro che ne regolano la manipolazione, e memorizzando sempre tutti questi dati in formato big-endian.
Questo significa che se c’è, ad esempio, un campo word a 16 bit, si utilizzerà la macro READ16 (ad esempio) per leggerne il contenuto. Questa provvederà a leggere i due byte, scambiarli, e restituire finalmente il risultato. Idem per tutte le scritture.
Ciò vuol dire pure che si dovrà passare in rassegna tutto il codice, individuare le strutture “pubbliche” utilizzate, e sostituire gli accessi diretti ai campi con le macro di cui sopra.
In questo modo sia il s.o. x86 che le applicazioni native lavoreranno sostanzialmente in big-endian in questi casi, con una certa penalizzazione a livello prestazionale (descritta in precedenza), garantendo alle applicazioni 68000 di trovare i dati nel formato che si aspettano.
I s.o. AmigaOS/like non sono molto grandi e complessi, ma in ogni caso parliamo sempre di un’operazione di revisione e modifica di codice che impegnerebbe parecchio tempo per una piccola azienda o team di sviluppatori, per cui molto difficilmente praticabile.
Si tratterebbe, in ogni caso, di lavoro che sarebbe poi buttato via nel giro di qualche anno, quando si presenterà la necessità di passare ad architetture a 64 bit per superare il limite attuale dei 2GB di spazio d’indirizzamento per tutto (s.o. e applicazioni).
Questo perché almeno i puntatori passeranno dai 32 bit attuali ai 64 bit, ovviamente per indirizzare memoria ben oltre i 4GB teorici (in realtà ci sarebbero tecniche come la PAE che lo consentono rimanendo con puntatori a 32 bit, ma si tratta di soluzioni complicate da implementare). Ciò significa che le strutture di cui abbiamo parlato finora sono gioco forza destinate a cambiare sia come dimensione che come posizione dei campi in esse contenute (un puntatore di dimensione doppia fa “slittare” di 4 byte avanti tutti i campi che lo seguono).
Dunque con le architetture a 64 bit diverrà impossibile per AmigaOS 4 e MorphOS poter gestire le applicazioni 68000 in maniera trasparente, come fanno adesso, per cui dovranno rinunciare a questi strumenti e passare ad altre soluzioni, come ad esempio una sandbox in cui farle girare cercando di condividere le risorse fra i due mondi in maniera meno invasiva. Cioè la soluzione adottata già da AROS con Janus-UAE, e dal quale, ancora una volta, si potrebbe attingere.
Per quanto detto, pensare di passare a un’architettura PowerPC a 64 bit sarebbe letteralmente un suicidio, perché non ci sarebbe alcun vantaggio, visto che si dovrebbe rinunciare comunque a Petunia e Trance, e dunque quello di operare con un’architettura big-endian risulterebbe sostanzialmente nullo da questo punto di vista.
In conclusione, se questi s.o. AmigaOS/like vogliono garantire un futuro ai loro appassionati e affezionati utenti, prima o poi dovranno decidere di fare questo grande passo, come ha dovuto fare anche ARM, che alla fine di quest’anno proporrà ARM64, la sua nuova architettura a 64 bit. Perché l’esigenza di manipolare grosse quantità di dati coinvolge tutti ormai, anche gli utenti AmigaOS/like.
Meglio, quindi, portarsi avanti e traghettare l’utenza verso una nuova piattaforma, investendo adesso quei soldi per l’operazione, che altrimenti andrebbero sprecati pagando a peso d’oro una CPU morta e sepolta, e ritardando un cambiamento che sarà inevitabile…
UPDATE. Sebbene la fonte sia da prendere accuratamente con le molle, sembra che AMD sia impegnata non soltanto con la GPU, ma anche con la CPU della prossima XBox.
em
