di  -  mercoledì 24 novembre 2010

Ogni programmatore che si rispetti conosce l’importanza del riutilizzo del codice, e di quanto sia consigliabile strutturare e modularizzare il codice in modo da facilitarne il riuso in diverse applicazioni.

Esistono diversi modi per raggiungere lo scopo, più o meno efficaci (compreso l’uso del solo incapsulamento sfruttando i costrutti sintattici dei linguaggi che supportano il paradigma di programmazione orientata agli oggetti), ma non mi soffermerò sull’argomento, che non rappresenta il tema dell’articolo.

Su AmigaOS la strada maestra è rappresentata dalle cosiddette librerie, concetto cardine che permea l’intero sistema operativo, il quale espone API e funzionalità proprio sotto forma di singole librerie dedicate a precisi scopi.

Fra le più comuni e conosciute sono exec.library (che rappresenta praticamente il kernel), graphics.library (per gestire la grafica, compresi sprite, Blitter e Copper), intuition.library (si occupa dell’interfaccia grafica: quindi finestre, caselle di testo, ecc., e ovviamente gli eventi), dos.library (filesystem, processi, & co.), e tante altre che si trovavano già nella ROM oppure nei dischetti (quelle meno importanti / usate).

L’idea è quella di organizzare il codice suddividendolo in funzioni (che possono accettare anche dei parametri, e restituire eventualmente un valore; in tutti i casi sfruttando i registri della CPU), che vengono esposte all’esterno tramite un meccanismo di vettori indirizzati da ben precisi offset relativi a una certa struttura:

Un’applicazione che vuol richiamare un’API di una libreria deve prima “aprire la libreria” (tramite l’API OpenLibrary fornita dall’unica libreria di sistema che risulta sempre aperta, exec.library) ottenendo quello che si chiama in gergo (puntatore alla) “base della libreria” (Library Base in figura), che verrà sempre passato in un preciso registro del processore (A6 nel caso dei 68000).

Ottenuto il riferimento a quest’oggetto, tutte le API possono essere invocate eseguendo un salto all’indirizzo che si ottiene dalla base sottraendo un ben preciso offset, a multipli di 6 byte.

Le prime 4 API (offset -6, -12, -18, e -24) sono riservate per la gestione della libreria da parte del s.o.; vengono invocate rispettivamente quando ne viene richiesta l’apertura, la chiusura, e l’eliminazione dalla memoria (se nessuna applicazione ne fa uso e il sistema ha bisogno di recuperare memoria); l’ultima è riservata.

La prima API “utile” a un programma è, quindi, quella che si trova all’offset -30, la seconda a -36, e così via. Il motivo per cui è stato scelto di procedere a passi di 6 byte è molto semplice: a tale indirizzo è generalmente (perché non è sempre vero!) presente un’istruzione JMP (del Motorola 68000) all’indirizzo vero e proprio della funzione, che occupa esattamente 2 (per l’opcode principale) + 4 (per l’indirizzo a 32 bit) byte.

Per una normalissima applicazione l’uso di una libreria finisce qui (a parte il fatto che va obbligatoriamente chiusa prima di terminare l’esecuzione!), in quanto l’unico scopo è quello di invocarne le API, appunto, ma a volte può essere utile accedere ai dati presenti a partire dalla “base”.

Questo perché librerie come Exec (ma anche altre) espongono delle strutture dati che, sebbene ne sia deprecato l’accesso (in quanto fonte primaria di problemi e incompatibilità varie, poiché in teoria potrebbero cambiare in base alle versioni), consentono di ottenere l’elenco dei task, giusto per fare un esempio.

Tali informazioni si trovano in quella che in figura viene denominata Data Area, cioè un’area di dati privati della libreria. Il formato è definito strettamente per quella particolare libreria e, come già detto, sulla carta è possibile che cambi in base alla versione (anche se non è mai stato fatto per non rompere la compatibilità con le applicazioni scritte male che ne fanno uso).

Infine la parte chiamata Library Structure è costituita da struttura fissa e standard (per chi mastica un po’ di C):

Viene utilizzata esclusivamente dal sistema per la gestione della stessa (apertura, chiusura, eliminazione, ma anche rintracciabilità nel caso in cui si faccia una ricerca delle librerie aperte).

A parte la Library Structure, la struttura della tabella dei vettori e della Data Area richiama alla mente l’implementazione comune della Virtual Method Table dei linguaggi OOP, con la tabella dei metodi virtuali che precede l’area dati privata della classe (che racchiude, ad esempio, la dimensione di un’istanza) e le variabili “statiche” (o di classe).

Poiché la Data Area è un’area privata della libreria e, quindi, condivisa da tutte le applicazioni che l’hanno aperta e ne fanno uso, il modello implementato è sostanzialmente “puro” o rientrante. L’accesso alle informazioni della Data Area (se presente, visto che è opzionale: molte librerie non ne fanno uso!) è, infatti, regolato internamente tramite l’uso di appositi meccanismi di sistema (semafori et similia).

Ciò è particolarmente utile in un ambiente multitasking, dove avere a disposizione strutture thread-safe elimina molti problemi. Il tutto con l’ulteriore, pregevole, vantaggio di rendere il codice “ROMable”, quindi facilmente memorizzabile su ROM, EPROM, ecc., come fece Commodore con le librerie più importanti.

Un’altra caratteristica delle librerie è che sono presenti in copia unica nel sistema. Non esistono, infatti, file diversi per versioni diverse di una stessa libreria. Versioni successive possono aggiungere altre API, sfruttando il già visto meccanismo degli offset negativi, senza intaccare le precedenti.

In questo modo applicazioni vecchie possono girare tranquillamente usando le versioni delle librerie di cui fanno uso, senza per questo richiedere quella particolare versione che era presente al momento della loro distribuzione.

E’ una cosa che continuo ancora oggi ad apprezzare particolarmente. Non ho mai digerito, infatti, il caos dovuto alla presenza di librerie con versioni diverse in altri sistemi operativi (Windows e Linux in primis) e, peggio ancora, i problemi dovuti alla compilazione di una libreria con compilatori diversi, o addirittura con versioni diverse dello stesso compilatore.

Vero è che la stessa cosa si sarebbe potuta fare con AmigaOS (ad esempio si sarebbero potute creare gadtools20.library, gadtools21.library, gadtools31.library, ecc. ecc.), ma l’esempio fornito dal s.o. (che non ha mai avuto librerie con versioni diverse), oltre a linee guida chiare e che praticamente imponevano un certo modello (mentale) di sviluppo, ha contribuito ad accettarlo e a cristallizzare la situazione anche in ambito privato / non di sistema.

Lo svantaggio di quest’approccio è che un bug che affiora in una particolare versione di una libreria può compromettere tutte le applicazioni che ne fanno uso. E’ un rischio concreto e con implicazioni decisamente pesanti, ma lo si risolve con workaround, usando una versione precedente, oppure con le classiche patch (divenute di comune uso proprio in ambito Amiga).

D’altra parte bisogna considerare che anche s.o. moderni generalmente mettono a disposizione singole copie delle loro librerie. Giusto per essere chiari, quante copie esistono di kernel32.dll su Windows 7? Soltanto una, e non una per ogni versione precedente di Windows e/o Service Pack, e i problemi vengono risolti tramite successive patch.

Anche il fatto che le librerie siano “pure” presenta degli svantaggi, anche se ciò dipende dalle “pratiche” in voga negli altri s.o.. Per fare un esempio pratico, prendiamo Python, il linguaggio di programmazione che preferisco e utilizzo a lavoro.

Una volta installato, su Windows mi ritrovo con un piccolissimo file python.exe di qualche decina di KB, e una libreria python25.dll (per la versione 2.5 del linguaggio) di circa 2MB (più una serie di librerie accessorie, ma non le consideriamo ai fini del discorso). E’ chiaro che l’eseguibile aprirà la DLL, che contiene tutto il codice che implementa la virtual machine di questo linguaggio.

Per un porting su AmigaOS mi aspetterei qualcosa di simile, quindi un eseguibile chiamato python costituito da una manciata di KB, e una python.library (o, al limite, una python25.library se non si può fare a meno di avere una libreria diversa per ogni versione; sic!) con tutto il codice della VM.

Invece si trova soltanto il primo, che contiene tutto. Quindi possiamo scordarci di condividere lo stesso codice per tutte le applicazioni che potrebbero far uso della VM Python al loro interno. Codice che, di conseguenza, verrà duplicato ogni volta.

Tutto ciò è dovuto al fatto che negli altri s.o. le librerie fanno uso di dati privati per ogni applicazione che le apre. In sostanza il codice è sempre lo stesso, ma per ogni applicazione viene creata una nuova sezione di dati specifica per la libreria caricata, in modo che questa possa ritrovarci le informazioni che le sono necessarie per lavorarci.

Questo non si può realizzare con AmigaOS, in quanto la sezione dati privata della libreria è unica, ed è condivisa da tutte le applicazioni, come abbiamo visto.

In questi anni ho pensato a una soluzione, di cui espongo brevemente il concetto. Si potrebbe estendere l’attuale modello di librerie introducendone un altro tipo che segnali al s.o. la necessità di creare una copia dei dati per ogni chiamata alla OpenLibrary.

Quindi la OpenLibrary restituirà un Library Base diversa per ogni task, che conterrà la medesima tabella dei vettori (che verrà semplicemente ricopiata ogni volta), ma Data Area nuova, inizializzata opportunamente (nel codice dell’API interna con offset -6, che abbiamo visto prima).

Per ottenere ciò sarebbe necessario modificare leggermente la gestione delle librerie da parte di AmigaOS, in modo da caricare e istanziare correttamente quelle di questo tipo. Inoltre il compilatore dovrebbe provvedere a isolare tutti i dati globali, referenziandoli poi nel codice tramite offset alla Data Area; includendo, inoltre, il codice di inizializzazione e finalizzazione in quello richiamato dalle apposite API interne.

In questo modo non si stravolgerebbe del tutto il modello attuale, ma verrebbe esteso per includere una vasta gamma di nuove possibilità, specialmente in ottica di integrazione “più Amigaosa” della massa di codice già scritto per altri sistemi e che, inutile nasconderlo, farebbe molto comodo…

19 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
    RunAway
     scrive: 

    Su Linux più che il caos derivato da versioni diverse delle librerie, non ho mai sopportato il fatto che quando una libreria viene aggiornata non si rimuova la vecchia.
    Mi spiego: se rimangono versioni diverse in giro la maggior parte delle volte è perchè ci sono programmi che ancora le richiedono (ovviamente) e perchè tali programmi richiedono ancora quella versione se la libreria si è aggiornata nel frattempo?
    Perchè molto probabilmente essenosi consolidato questo andazzo uno viluppatore sa che non deve preoccuparsi di tenere al passo la sua app col software circostante che nel frattempo progredisce perchè tanto quella lib rimarrà sempre in giro (a scassar le balle a chi necessita quell’app o a creare eventualmente conflitti.
    Insomma alla fine a parte casi particolari (quando una lib nuova non fa cosa che faceva la versione precedente, un’assurdità imho) il caos delle librerie è dovuto alla pigrizia di certi sviluppatori, altrimenti non ci sarebbe.

  • # 2
    j
     scrive: 

    perchè tali programmi richiedono ancora quella versione se la libreria si è aggiornata nel frattempo?
    Perchè molto probabilmente essenosi consolidato questo andazzo uno viluppatore sa che non deve preoccuparsi di tenere al passo la sua app col software circostante che nel frattempo progredisce perchè tanto quella lib rimarrà sempre in giro (a scassar le balle a chi necessita quell’app o a creare eventualmente conflitti.

    parti dal presupposto sbagliato
    tu forse la vedi come uno strumento politico per mettere in movimento l’ ecosistema sw (che in realtà di suo avrebbe bisogno dell’ esatto opposto), ma una libreria non è altro che un pezzo di codice già pronto, a cui altri programmatori accettano (se non c’è di meglio) o scelgono (potendo vagliare più alternative per una stessa funzione, esempio pratico i toolkit) di appoggiarsi, in primis per risparmiare fatica – quella di implementare in proprio le stesse funzionalità – quindi per comodità, o più correttamente, per raggiungere maggiori efficienza ed efficacia nel processo di sviluppo
    ora, una nuova versione di una libreria che non si limiti ad un bugfix può apportare dei vantaggi, ma questi qualunque programmatore pragmatico li valuterebbe rispetto all’ impegno (quindi al costo) che adeguare l’ applicazione progettata in funzione di essa, o lo sviluppo autonomo delle stesse funzioni aggiunte, può richiedere – così come avrà fatto delle valutazioni pragmatiche basando la’ applicazione su quella libreria in prima battuta
    cioè, è una libera scelta del programmatore usare una certa libreria per i suoi scopi, così come continuare a usarla (nè più nè meno di come si è liberi di scegliere tra la merce sullo scaffale in un supermercato… se gli svantaggi o controindicazioni di un articolo superano i benefici, non si compra, semplice)

    Insomma alla fine a parte casi particolari (quando una lib nuova non fa cosa che faceva la versione precedente, un’assurdità imho) il caos delle librerie è dovuto alla pigrizia di certi sviluppatori, altrimenti non ci sarebbe.

    si vede che non sei uno di loro… altrimenti capiresti che un programmatore di applicazioni non ha l’ obbligo di stare dietro ad ogni evoluzione delle librerie che usa
    l’ unico “obbligo” che eventualmente ha nei confronti del suo datore di lavoro, od anche solo della sua utenza, è quello di produrre un ‘ applicazione che *funzioni* e faccia quello che le è richiesto – tutto il resto viene dopo
    soprattutto, che un’ applicazione funzioni (così come è) per più di 6 mesi di fila senza che l’ utente finale debba a sua volta preoccuparsi di installare decine o centinaia di MB di aggiornamenti (e no, installarli automaticamente, cioè di nascosto, è un rimedio peggiore del male) ovvero rispettare criteri legati al ciclo di vita del software, è più importante che stare dietro a(i capricci di chi sviluppa) le librerie impiegate
    nuove versioni delle quali, dotate di funzioni non disponibili prima, verranno valutate al momento di produrre una nuova major release, non prima …

  • # 3
    alessiodp
     scrive: 

    reputo il sistema delle librerie di amiga il migliore in assoluto da replicare in tutti i sistemi operativi del mondo ed embedded…
    ottimo articolo che spero porti insieme agli altri della serie a strutturare un nuovo OS….altro che MacOSX

  • # 4
    pleg
     scrive: 

    @ RunAway

    Senza contare che la nuova versione di una libreria potrebbe tranquillamente essere _meno_ stabile, perche’ magari sono state aggiunte mille nuove feature e riorganizzato il codice e servira’ un po’ di tempo prima di debuggare tutto e raggiungere un nuovo livello di maturita’, quindi uno sviluppatore potrebbe avere ottimi motivi per non usare l’ultima versione di una libreria.

  • # 5
    Smoke.kills
     scrive: 

    Premetto sono ignorante, in informatica, mi limito solo ad utilizzare gli applicativi che mi servono anche se mi sono sempre interessato a livello amatoriale sia di hw che di sw..
    sono sempre stato un Amighista nato ho avuto l’amiga 500,600 e 1200 aga con hd da 20 mb ovviamente ero pischello e li utilizzavo solo per la montagna di giochi piratati che avevo :) forse un migliaio se non di più, avevo tutta la cameretta cosparsa di floppy :) (non che fosse un bene anzi,ma a quei tempi non avevo cognizione di cosa fosse la pirateria) poi dopo vari esperimenti per vedere com’era fatta dentro l’amiga per curiosità ho estratto la rom è l’ho rotta… quanto piangere ancora tutt’ora :( comunque sia, subito dopo mi sono fatto comprare un Pc assemblato con un “bel” Cyrix, comunque l’approccio è stato traumatico cioè il Workbench Amiga se non sbaglio la 3.1 era un mostro in stabilità, facilità e la gui mi piaceva un sacco, per quanto fosse banale l’utilizzo che ne facevo, le sensazioni che percepivo erano di un prodotto meraviglioso, cosa che non ho mai più percepito con i vari pc/windows/linux (Apple l’ho da sempre odiata dal profondo del mio essere), sarò un anacronismo o semplicemente saranno nostalgie di infanzia, però se ci dovesse essere un prodotto che ricalca l’essenza dell’Amiga magari in un portatile e con Amiga Os aggiornato ai 4 applicativi essenziali: foglio di calcolo,foglio di testo,un programma di fotoritocco/cad e un browser, lo comprerei al volo senza rimpiangere il pc :) mi piacerebbe proprio un portatile embedded il cui os sfrutti al 100% tutto l’hw proprietario ,che fornisca la compatibilità con le stampanti e magari con un masterizzatore dvd/bd tanto per evenienza ma non indispensabile :), stop. Possibile che solo io voglia di nuovo l’Amiga aggiornato ai giorni nostri?

    Sig. Cesare di Mauro colga il mio appello, lei che è un programmatore degno di nota si faccia carico del progetto, lo interpreti come la sua missione di vita, trovi una multinazionale che rilevi il marchio Amiga e si faccia finanziare :) penso che molti rivorrebbero avere il gioiellino targato commodore nelle proprie mani.

    mi scuso per il post off topic, ma la pulsione di scrivere è stata incontenibile :)
    voglio navigare in internet con un amiga! lo voglio!

  • # 6
    [D]
     scrive: 

    @Smoke.kills

    Spiacente deludere i tuoi sogni ma esiste già una “nuova amiga” che produce dei nuovi “amiga”: praticamente ricicla dei baracchini ad uso industriale della potenza di un peto (come definire diversamente dei ppc che nel 2010 si piazzano a metà strada tra un g3 ed un g4) e li vende a cifre spaventose. Ovviamente (cioè non è ovvio, ma o si piange o si ironizza) c’è un nuovo amiga os che dice di essere moderno ma non lo è, non ci sono suite d’ufficio valide (ovviamente se si esclude la caterva di programmi emulati per i vecchi amiga, ma chiaramente per far girare quelli o ti compri un vero amiga su ebay o piazzi winuae, sono sempre più amiga dei “nuovi” amiga), non ci sono programmi professionali degni di nota, i giochi ovviamente fanno quello che possono con il poco che c’è (teoricamente si dovrebbe arrivare fino alla radeon 9250, in pratica il supporto 3d è così scadente che Quake 3 gira 100 volte meglio su un Pentium II con Radeon 7500), il supporto ad internet è così limitato (OWB l’unico browser decente è una barzelletta e pare perfino che il suo sviluppo sia stato abbandonato, cosa a dir poco squallida) che pensare di mettere in commercio dei netbook amigosi sarebbe un suicidio economico (questo senza considerare il problema prezzi che sarebbe come gettare sale su una ferita profonda), insomma… una gioia di quelle che ti fa venir voglia di comprarne dieci domani stesso. Ah già dimenticavo, prezzo medio per una “soluzione” amiga: si parte dai 900 euro e si potrà arrivare oltre i 2000, l’usato non meno di 500/600 euro (e chiaramente fatti pure le dovute proporzioni con le potenze che ti ho elencato prima perchè in passato si faceva molto peggio)

  • # 7
    060
     scrive: 

    @D
    Hai il dente avvelenato.
    @Smoke.kills
    Fatti un giro qui http://amiga.ikirsector.it/index.php la comunità è piccola ma resiste..

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

    Concordo con 060. E’ un ottimo punto di riferimento, con gente entusiasta e pronta a dare una mano. :)

    Fine OT. ;)

  • # 9
    amonpaike
     scrive: 

    per eleganza e librerie trovo adorabile anche beeos e quindi haiku

    http://www.osnews.com/story/22903/Writing_Applications_for_Haiku/ (articolo carino sulla scrittura delle aplicazioni per haiku)

    http://api.haiku-os.org/ (librerie haiku)

    http://www.haiku-os.org/legacy-docs/bebook/ (librerie beos)

    http://haikuware.com/directory/start-download/development/sample-code/programming-the-be-operating-system (libro intero)

    http://www.haiku-os.org/docs/userguide/en/contents.html (haiku user guida)

    http://api.haiku-os.org/HIG/ (guida interfaccia)

    tutti documenti eleganti e divertenti da leggere, da ex amighista trovo che haiku ne sia il sistema degno erede :)

  • # 10
    [D]
     scrive: 

    “Hai il dente avvelenato.”

    Un pochettino sì perchè sono anni che tengo un occhio da quelle parti e vedo sempre ripetersi lo stesso scempio. Io 900 euro non li spendo neanche per un PC che almeno è sicuro mi darà soddisfazioni ed utilità a iosa e secondo certi geni dovrei spenderli per un coso dove se mai gli faranno sopra un lettore pdf decente ci sarà da fare colletta per comprare una torta con candeline ?

  • # 11
    amonpaike
     scrive: 

    dente avvelenato o meno i progressi arrivano , e dal mondo opensource :D
    lo sviluppo opensource a pagamento enstusiasma e corre veloce.

    http://www.youtube.com/watch?v=rNZYK5byx6c
    http://www.youtube.com/watch?v=k7uOvf5pOPg
    http://www.youtube.com/watch?v=xz1dyXMdtNE

    http://picasaweb.google.com/magic.aros/AROS#

  • # 12
    [D]
     scrive: 

    Provalo, fallo girare senza riuscire a farlo crashare per più di mezz’ora e poi mi dici dove sono i progressi. Quando non ci sono le basi è deleterio preoccuparsi dello stile.

  • # 13
    Sergio
     scrive: 

    @Cesare Di Mauro
    Ma in questo modo le Librerie non crescono in dimensione ogni volta che si aggiunge qualcosa di nuovo? Portandosi indietro tutto il vecchio codice magari utilizzato da un solo programma?
    Forse spezzettare le Librerie non è la soluzione migliore, però distribuire un programma che supporti solo le funzioni più nuove con allegata una Libreria appesantita anche dal codice “antico” neanche mi sembra una soluzione ottimale. :)
    Ovvio che se questa Libreria fa parte del SO e me la ritrovo già lì, quindi non la devo allegare al programma, il discorso cambia.

    Per quel che riguarda le modifiche alle Librerie, non posso che rispondere col mio cavallo di battaglia, fino a quando non renderanno Open Source AmigaOS, non potremo mai avere un vero sistema di sviluppo e aggiornamento, perché la Hyperion non ha risorse sufficienti e non né avrà mai per fare tutto da sola.

    Il primo vero aggiornamento sarebbe da fare ad Intuition perché l’usabilità è veramente datata e non è più tanto “Intuitiva”.

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

    Indubbiamente, Intuition è datato e va migliorato.

    Riguardo alle tue domande il dubbio è legittimo, ma, al contrario, non c’è spreco. E’ chiaro che una libreria che si arricchisce di funzionalità, la dimensione aumenta, visto che le nuove API portano nuovo codice. Ma non parliamo di stravolgere una libreria includendo funzionalità non attinenti allo scopo per cui è stata scritta; quindi non mi aspetto che, ad esempio, venga aggiunto un enorme numero di API 3D in graphics.library. L’aumento è graduale, sì, ma non eccessivo.

    Al contrario, lo scenario di esplosione della dimensione del codice si verifica quando si ha a che fare con versioni diverse della stessa libreria che sono contemporaneamente presenti; caso, questo, abbastanza comune negli altri sistemi. Questo perché la maggior parte del codice lo ritrovi spesso in tutte le versioni delle librerie. Se, ad esempio, una libreria ha una funzione di conversione di una stringa in numero, difficilmente sparirà in quelle successive: è probabile che verrà mantenute in tutte, con conseguente duplicazione e occupazione di spazio.

    Poi è chiaro che le funzioni “deprecate” ci sono anche nelle librerie di AmigaOS, ma il “costo” rispetto agli altri sistemi risulterà inferiore per quanto detto. Questo se vogliamo tenere in piedi la retrocompatibilità con le applicazioni che le usano.

    @amonpaike e D: siamo off-topic. Vi pregherei di continuare, se lo riterrete opportuno, tenendo presente l’argomento dell’articolo. Grazie. :)

  • # 15
    Nessuno
     scrive: 

    Inoltre il compilatore dovrebbe provvedere a isolare tutti i dati globali, referenziandoli poi nel codice tramite offset alla Data Area; includendo, inoltre, il codice di inizializzazione e finalizzazione in quello richiamato dalle apposite API interne.

    Ciao,
    non mi è chiara questa cosa.
    La libreria usa una area data globale per memorizzare alcuni parametri critici per il proprio uso. Ad esempio il contatore di quante volte è stata aperta. Per il resto, le parti di dati relativi ad ogni istanza della libreria aperta sarebbero facilmente sostituibili dal passare il puntatore ad una struttura allocata dal task stesso ad ogni chiamata che ne facesse uso o implementando una funzione “fissa” da chiamare nell’open della funzione che allocasse tale area e la memorizzasse internamente.
    L’uso di tale area sarebbe comunque protetta (l’utente non dovrebbe avere la possibilità di metterci mano direttamente) e quindi manipolabile solo tramite le stesse funzioni della libreria.
    Altrimenti diventa la manipolazione di una normale struttura pubblica che può essere implementata come già avviene per le strutture create e manipolate tramite la libreria (es, gadget, window o screen, le prime che mi vengono in mente).

    In definitiva ci sarebbe la possibilità di ottenere un’area dati per ogni istanza aperta senza dover assolutamente toccare la modalità di trattamento delle librerie così come è adesso.

    Mi sfugge qualcosa?

    Per il resto, una cosa tremendamente utilissima delle librerie Amiga è il passaggio dei parametri tramite le coppie ID, valore (TagItems) che permettono di estendere le capacità delle funzioni senza dover avere versioni diverse delle stesse all’interno della libreria.

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

    Concordo sui Tag: trovata semplice, ma geniale, per eliminare alla radice il problema dell’estensibilità delle API / strutture senza più toccarle.

    Riguardo al tuo dubbio, mi spiego meglio. E’ chiaro che passare un puntatore alla struttura allocata per quel task è una soluzione abbordabilissima: sarebbe come passare un parametro, come avviene già per diverse strutture utilizzate nelle altre librerie.

    In questo modo, però, si toglierebbe un prezioso registro indirizzi dalla disponibilità della libreria e/o del task. Dico prezioso perché, a differenza dei registri dati (qui ovviamente mi sto riferendo alla famiglia 68000), quelli indirizzo sono di meno, poiché alcuni sono riservati (A7 per lo stack, A6 per la Library Base, A5 o A4 per lo stack frame).
    E ti assicuro che per una virtual machine come quella di Python (ma anche per altre applicazioni) poter disporre di un registro in più è un vero toccasana.

    Con la mia soluzione, invece, si riutilizza lo stesso A6 (Library Base) per memorizzare i dati riservati per lo specifico task che sta richiamando le API della libreria.

    L’altra soluzione non la vedo realizzabile, invece. Come faresti ad accedere ai dati privati del singolo task all’interno della Data Area comune?

  • # 17
    Nessuno
     scrive: 

    Come faresti ad accedere ai dati privati del singolo task all’interno della Data Area comune?

    Scusa non ho capito la domanda. Vorresti accedere all’area comune (quella unica creata insieme alla libreria) oppure all’area privata di un task (la parte di dati che viene creata per ogni task che apre al libreria)?
    Effettivamente pensando al fatto che la struttura della libreria non sarebbe duplicata, non è possibile la seconda opzione di far memorizzare il puntatore all’area dedicata al task all’interno della libreria stessa.
    Per il passaggio del puntatore alla struttura data dedicata al task alle varie funzioni si può usare…. un tag item! ;)
    Effettivamente, a parte alcuni parametri fondamentali da passare esplicitamente nei registri, tutto si può passare (e secondo me dovrebbe essere passato) tramite tag item con un minimo overhead più che giustificabile per l’enorme flessibilità che guadagna l’estendibilità della libreria.

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

    Sì, il punto è che l’area privata normalmente è comune a tutti i task che utilizzano la libreria, per cui non si può memorizzare nulla che appartenga a un singolo task (in realtà si potrebbe, ma sarebbe estremamente complicato, in quanto sarebbe necessario di disporre di apposite API per salvare e recuperare i dati che servono).

    I tag allo scopo renderebbero troppo pesante la chiamata alle API, e non ne varrebbe la pena. Anche perché dovrebbero essere utilizzati praticamente per tutte le API, in quanto lo scopo rimane quello di passare l’intero insieme di variabili globali della libreria (di quel preciso task) all’API.

    Figurati che già vedo male l’idea di dover passare un puntatore a quest’area ogni volta. :P

    Per questo avanzavo l’idea di utilizzare la stessa library base: quella comunque la si deve passare in A6 per richiamare ogni API. ;)

  • # 19
    g
     scrive: 

    @D
    fatti morphos su qualche mac g4 recuperato dalla spazzatura e divertiti se ti và;) non devi neanche registrarti se vuoi solo soddisfare un po’ la curiosità

    Oggi gli Amigalike, tra cui annovero anche amigaos4.1 -per me amiga è morta nel 94- sono degli ambienti dove passare qualche ora un po’ tra i ricordi e un po’ smanettando come i bei tempi… vedendo e testando come “avrebbe potuto essere”, e recuperando magari qualche bel pezzo di software che ci eravamo persi.
    Se poi ti appassioni puoi anche contribuire!

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.