Negli ultimi tempi AROS (un “remake” di AmigaOS di cui abbiamo parlato in precedenza) sembra stia avendo uno sviluppo notevole; in particolare si è riaperto il fronte del porting sulle gloriose macchine 68000.
L’obiettivo è quello di sempre, e di cui ho parlato anche nell’apposito articolo: ottenerne una versione in grado di rimpiazzare il vecchio AmigaOS, essendo quindi del tutto compatibile sia a livello sorgente che binario.
I primi risultati si cominciano a vedere, come potete leggere da questa notizia (qui il wiki dedicato al progetto): finalmente è stato realizzato un Kickstart realizzato interamente col codice di AROS, e in grado di far funzionare i giochi cosiddetti “non DOS” (quelli che “ammazzano” il s.o. e prendono possesso dell’hardware della macchina), cioè la stragrande maggioranza.
Tutto ciò è frutto del lavoro di Jason McMullan e Toni Wilen (famoso mantainer di WinUAE), a cui sono stati assegnati rispettivamente il primo e il secondo dei due bounty aperti allo scopo.
Wilen, in particolare, ha interesse a inserire una ROM basata su AROS in WinUAE, in modo da poter utilizzare immediatamente l’emulatore, e soprattutto sempre in maniera legale (sulle ROM originali permane giustamente il copyright).
Oltre alla realizzazione di una ROM del Kickstart, anche la compatibilità binaria con AmigaOS comporterà un certo impegno, se consideriamo che AROS ha adottato il formato ELF (al pari di MorphOS e AmigaOS 4) per memorizzare il codice oggetto e quello eseguibile delle applicazioni, mentre AmigaOS è nato e utilizza da sempre quello Hunk.
L’adozione di ELF (qui ne trovate una dettagliata descrizione in italiano) penso sia stata dettata da pura convenienza, visto che la toolchain GNU (particolarmente utilizzata nei progetti open source), supporta nativamente e genera sia file oggetto che eseguibili in questo formato.
Non credo, invece, nelle motivazioni esposte in questa pagina relativa alla scrittura di un sistema di plugin per AmigaOS 4. Non v’è dubbio che ELF sia complessivamente un formato più flessibile di Hunk, ma per quest’ultimo l’hunk per la memorizzazione delle informazioni di debug è completamente free format (come si dice in gergo), per cui è possibile memorizzarle in qualunque modo, come si può vedere dalla pagina 254 (260 usando un lettore di PDF) dell’AmigaDOS Manual.
Inoltre informazioni addizionali si possono introdurre in appositi hunk, visto che la struttura di questo formato è facilmente (e semplicemente) estendibile per sua natura (un parser minimale scritto in Python lo trovate qui).
Il linking dinamico tramite simboli è assente, è vero, ma in AmigaOS lo strumento principe da utilizzare è sempre stato quello delle librerie (di cui parlerò in un futuro articolo). Sistemi operativi diversi utilizzano meccanismi diversi, ma sono un’altra cosa, appunto: qui stiamo parlando di un ben preciso s.o..
In compenso Hunk è in grado di supportare i cosiddetti fat binary, cioè file oggetto e/o eseguibili in grado di poter essere letti e utilizzati per architetture diverse in un unico file. E’ stato, infatti, esteso per supportare i PowerPC e i classici 68000 allo stesso tempo.
ELF non è stato esteso, ma è stata aggiunta ugualmente la possibilità di integrare codice e dati di più architetture tramite il neonato FatELF, che però si presenta sostanzialmente come un contenitore di file ELF. In pratica i file ELF per le diverse architetture sono appesi a un file unico, provvisto di un apposito header che li elenca.
L’extended hunk, invece, sfrutta la stessa struttura degli hunk, aggiungendone semplicemente due nuovi tipi per supportare la nuova architettura. Tutto il resto rimane esattamente così com’è, anche se a mio avviso sarebbe stato meglio condividere quante più informazioni possibile, in modo da ridurre la dimensione dei file.
L’idea è quella di introdurre il concetto di hunk condivisi, che racchiudono informazioni utilizzabili da più di un’architettura, evitando inutili duplicazioni. Basti pensare alle sezioni BSS (dati non inizializzati), oppure a porzioni di hunk dei dati (ad esempio variabili di tipo byte, oppure array di byte, stringhe, immagini, ecc.), o tabelle dei simboli.
Sempre in ottica di riduzione dello spazio, sarebbe stato utile introdurre la possibilità di comprimere le informazioni presenti negli hunk, con appositi algoritmi (possibilmente diversi a seconda del tipo di hunk e/o dei dati memorizzati).
Non si tratta di idee nuove, in quanto esistono filesystem come NTFS che già lo consentono, ma a livello di intero file (mentre sarebbe meglio mantenere la struttura degli hunk, e comprimere soltanto i dati veri e propri, in modo da facilitare il parsing dell’eseguibile) e con un solo algoritmo.
Per AmigaOS esistevano anche altre soluzioni, come il mitico PowerPacker col quale era possibile comprimere proprio gli eseguibili col suo formato, mentre grazie al programmino PPLoadSeg (inserito nella prima riga della startup-sequence) il s.o. veniva patchato opportunamente per riconoscere i file compressi e decomprimerli al volo all’atto del caricamento.
Da tempo penso a tutt’altro, invece. Poiché esistono diversi tipi di hunk identificati da un apposito intero a 32 bit, utilizzando magari i bit da 16 a 23 sarebbe possibile specificare quale dei 256 possibili decompressori (registrati nel sistema) utilizzare per i dati memorizzati.
In questo modo l’operazione di caricamento dell’eseguibile non richiede parser complicati o pezze al s.o., ma è quest’ultimo che gestisce il tutto, facendosene completamente carico e al più demandando all’esterno l’operazione di decompressione tramite apposite librerie (modello XPK per intenderci).
Sfruttando i bit da 24 a 29, invece, sarebbe possibile specificare quale algoritmo di decriptazione fra i 64 possibili utilizzare per le informazioni presenti nell’hunk. Anche qui tutto in maniera trasparente e sotto il controllo del s.o..
Si tratta di un paio di idee che mi trascino da parecchi anni, e che, da utente di AmigaOS, m’avrebbero sicuramente fatto molto comodo (d’altra parte quasi tutti gli eseguibili e le librerie li avevo compressi col PowerPacker, appunto), aggiungendo notevole flessibilità e capacità al s.o..
Tornando ad AROS e alla compatibilità binaria coi 68000, visto che i compilatori GNU generano oggetti ed eseguibili ELF, sarà necessario un apposito convertitore in Hunk per ottenere dei file realmente utilizzabili.
Ciò introdurrà per forza di cose una discrepanza. Da una parte avremo ELF per tutte le architetture che AROS supporta finora, e dall’altra Hunk per i soli 68000. Un solo formato, omogeneo, sarebbe una soluzione idealmente migliore, ma portare tutto a ELF equivarrebbe a rompere l’agognata compatibilità col passato, obiettivo che questo s.o. si porta dietro fin dal suo concepimento.
Tornare ad Hunk significherebbe, al contrario, rompere la compatibilità con quanto sviluppato finora, ma c’è da dire che AROS ha come obiettivo la compatibilità a livello di sorgenti per le diverse architetture supportate, per cui una ricompilazione delle applicazioni dovrebbe essere sufficiente allo scopo.
Ci sarebbe, in ogni caso, da modificare Hunk per introdurre il supporto alle architetture a 64 bit (come ai tempi è stato fatto per ELF), ma il formato è molto semplice, e quest’operazione si farebbe molto facilmente e in poco tempo.
E’ ovvio che qualunque soluzione (biforcazione, tutto ELF, o tutto Hunk) presenta pro e contro, ma da amighista di lunga data apprezzo quest’ultima, che ritengo tutt’ora molto valida (con le dovute estensioni: stiamo parlando di un formato nato 25 anni fa, mentre ELF è molto più recente!).
In ogni caso e con le poche risorse in gioco, credo ci sia poco da scegliere o, peggio ancora, da recriminare. E’ un problema (se lo possiamo considerare tale) a priorità decisamente più bassa, specialmente alla luce del fatto che ci vorrà ancora tempo per ottenere un completo sostituto ad AmigaOS/68K, che speriamo arrivi presto…
