appunto informatica algoritmo compressione

Negli ultimi tempi AROS un “remake” di AmigaOS di cui sembra stia avendo uno sviluppo notevole; 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 il wiki dedicato al progetto : finalmente è stato realizzato un realizzato interamente col codice di AROS, e in grado di far funzionare i giochi cosiddetti “non DOS” quelli che “ammazzano” il s.o. 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 al pari di e per memorizzare il codice oggetto e quello eseguibile delle applicazioni, mentre AmigaOS è nato e utilizza da sempre quello . 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’ . ELF non è stato esteso, ma è stata aggiunta ugualmente la possibilità di integrare codice e dati di più architetture tramite il neonato , che però si presenta sostanzialmente come un . L’idea è quella di introdurre il concetto di hunk condivisi , che racchiudono informazioni utilizzabili da più di un’architettura, evitando inutili duplicazioni. 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. 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 per intenderci . 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. 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!
appunto informatica algoritmo compressione
Tags: appunto informatica algoritmo compressione
| Some Articles: appunto informatica algoritmo compressione | Original post: appunto informatica algoritmo compressione | Technorati tag: appunto informatica algoritmo compressione | Virgilio tag: appunto informatica algoritmo compressione