di  -  mercoledì 10 novembre 2010

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…

5 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Sergio
     scrive: 

    Complimenti per l’articolo che entra troppo nel tecnico rispetto alle mie competenze ;)
    Di mio dico solo che è incredibile come alcune delle soluzioni adottate 25 anni fà dai programmatori AmigaOS siano ancora oggi così elastiche ed adattabili alla programmazione odierna. Un altro punto che fà comprendere il fenomeno Amiga.

    Comunque io continuo a sperare che rendano AmigaOS open source, sarebbe la soluzione migliore per il mercato Amiga.

  • # 2
    iva
     scrive: 

    Bell’articolo Cesare, solo una piccola nota:
    non concordo quando dici che hunk e’ piu’ flessibile visto il formato “free” della debug information, dato che non e’ diverso da quello che accade per ELF.
    Infatti ELF specifica solo i nomi riservati delle sezioni per la debug info, non il loro contenuto.

    Dallo standard:
    debug : This section holds information for symbolic debugging. The contents are unspecified.
    All section names with the prefix .debug are reserved for future use.

    Su Linux per esempio il formato della debug info e’ DWARF che va sempre a braccetto con ELF, ma gli standard sono separati e non c’e’ nessuna dipendenza tra i due (a parte la convenzione per i nomi delle sezioni).

  • # 3
    Giacomo
     scrive: 

    AROS sta facendo molti passi in avanti negli ultimi tempi.. se continua così potrebbe arrivare a rimpiazzare WinUAE (sarà per questo che Wilen è entrato nello sviluppo? hmm..)

  • # 4
    Zeirus
     scrive: 

    Ottimo articolo, come tutti quelli redatti da Cesare Di Mauro… Bravo! :)

  • # 5
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ringrazio tutti per i complimenti.

    @Sergio: con AROS che sta maturando così velocemente, penso che non ci sarà bisogno che AmigaOS venga rilasciato come open source. ;)

    @iva: ho riletto la parte in questione, ed effettivamente si presta alla lettura che hai dato.

    Per chiarire meglio, riporto la parte a cui mi riferisco presa dal link segnalato:

    “In AmigaOS4 the executable format has been changed to ELF (Executable and Linkable Format) from the previous hunk executable. Due to this change many possibilities have been added to the OS, which was could not be exploited before. Just to name a few: dynamic linking via symbol resolving on load, extensive debugging information with the help of the DWARF standard and tagging information and special attributes and sections inside the executable. The ELF format is a lot more flexible than the hunk format was.”

    La mia era sostanzialmente una risposta a queste affermazioni, in particolare a quella sul debug.

    @Giacomo: non mi risulta. Finora Toni ha affermato che gli interessa includere una ROM del Kickstart senza infrangere il copyright che ne detiene Commodore.

    Certo, se entrasse nel team di AROS sarebbe un bel colpo, perché è molto in gamba e ha un’enorme conoscenza su come funziona(va)no gli Amiga.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.