Forum libero

> > > straGARAGULP!
> >
> > Avevo calibrato il post sulla mente-spugna da
> > QI>=180 di
> > Sviatofork.
> >
> > > A che punto è la documentazione?
> >
> > Allo stesso punto di prima dell'estate.
> > E allora che me rido a fa'? Boh, era per non
> > piangere.
>
> E io che non ho la spugna di sfiatopork come farò
> a
> imparare?

Ma con la documentazione, no?
Ehm... no aspe', non e` che ti prenda per i fondelli...

mettiamola cosi`, in modo che secondo me riflette sia la realta`, o almeno un modo di descrivere la realta` che a me sembra appropriato, e che allo stesso tempo dovrebbe risultare incoraggiante:

Linoleum e` composto da relativamente poche regole, un po' come la "teoria del tutto" che la fisica va cercando. Cioe`, ora, non ha niente in comune, in termini di gloria, con un "santo graal" del genere, ma ha in comune la semplicita`. Pero` questa non corrisponde necessariamente a immediata leggibilita`, e quel che ne salta fuori puo` essere, nel complesso, quanto mai astruso.

Per chiarire, se uno si spaventa per i dettagli di quel particolare modulo o kernel di run-time, quelli sono scritti in assembly nativo dell'architettura x86 (o IA-32). Quello e` proprio assembly, e l'avevo messo per illustrare dove va a finire il processore in risposta a una richiesta fatta all'isokernel. A chi programma in Linoleum quello che fa il modulo di run-time non interessa, anche perche` lo farebbe in modo diverso a seconda dell'architettura ospite, per girare sulla quale un'applicazione venisse compilata. Potrebbe interessare pero`, per capire come manipolare, quando e se si rende necessario, l'ambiente di esecuzione della propria applicazione, la modalita` in cui l'isokernel risponde alle richieste: questa fa parte delle nozioni relative al "con cosa si ha a che fare".

Nel caso delle chiamate all'isokernel, che so, un giorno qualcuno, volendo "espandere" in qualche modo la funzionalita` dell'isokernel, e sapendo che qualunque chiamata all'isokernel (comune ai threads) si riferisce a quel puntatore, potrebbe ritenere opportuno piazzare del codice attorno a ciascuna chiamata facendo in modo che le chiamate non vadano direttamente all'isokernel, ma a una propria subroutine che lo "espanda", chiamando il suo puntatore originario "tra le altre cose". In soldoni, in quel caso basterebbe sostituire il contenuto della variabile [isokernel] con l'indirizzo alla propria subroutine; una subroutine che, classificandola un po' meglio, al pari dell'isokernel dovrebbe comportarsi come una funzione booleana, ovvero ritornare al chiamante uno stato "errore/successo".

Ma di per se` un listato Linoleum e` costruito sulla base di poche regole ereditate o stabilite (da me) a priori, e da molte regole stabilite dallo sviluppatore della propria applicazione, oppure dalle librerie usate. E` un po' come giocare col pongo, insomma: Linoleum e` flessibile, diventa quel che si vuole. Questo perche`, in onore al suo nome che non si riferisce solo al vecchio pezzo punk dei NoFX, ha anche molto in comune con l'omonima copertura per pavimenti: si usa per rendere relativamente liscia una superficie sconnessa. In quest'ottica, rappresenta un qualcosa su cui costruire un ambiente, ma appunto, si limita al pavimento e non aggiunge mobilia, lasciandola tutta all'arredatore. Le chiamate all'isokernel sono una delle poche regole da prendere in considerazione, sotto la voce: "col sistema ospite, su cui l'applicazione gira, ci si interfaccia cosi`".

Altre regole di base sono:

- l'applicazione ha a disposizione solo una parte della memoria centrale del computer, che si chiama "workspace";

- il workspace e` nient'altro che un lungo vettore di elementi chiamati "unita`" (di memoria), numerati progressivamente da zero in su`;
- ciascuna unita` di memoria e` costituita da tanti bits quanti ne stanno in ogni "parola" del microprocessore: se l'architettura e` a 32 bit, un'unita` ha 32 bits, se e` a 64 bit ne ha 64, e cosi` via;

- il workspace si puo` ridimensionare (cambiando una variabile di controllo chiamata [ramtop] e chiamando l'isokernel), ma dato che questo tipo di modifica e` globale - agisce cioe` sullo stato di TUTTA l'applicazione - di solito e` meglio definire (o scegliere gia` pronto) un modo piu` sofisticato per gestire il workspace unico spezzettandolo e dimensionandolo automaticamente quando una parte dell'applicazione, librerie incluse, richiede un po' di memoria nel workspace: qui entrerebbe in gioco un gestore dell'heap; ma come il resto del mobilio, il gestore dell'heap e` sia opzionale (anche se di fatto spesso necessario, se l'applicazione e` decentemente complessa o usa librerie che vi si appoggiano) che "a scelta" dell'arredatore.

Anche le regole di sintassi sono poche:

- qualsiasi istruzione termina con un punto e virgola;

- quasi ovunque nel sorgente (uniche eccezioni i periodi "libraries" e "stockfile", dove si specificano nomi di file completi di percorsi relativi) ciascuna istruzione e` composta da un "codice simbolico" che identifica l'operazione, e da operandi: il codice simbolico e` composto da tutti i segni non facenti parte dei caratteri con cui si scrivono le espressioni lineari (i caratteri alfanumerici piu` le parentesi quadre, il punto decimale e l'underscore); il resto dell'istruzione sono gli operandi, delimitati dai segni stessi, e costituiti da espressioni;

- le espressioni possono essere anche costituite da un solo "simbolo", inteso come il nome di un registro, di una variabile, di una costante, di un'etichetta di codice o del workspace;

- a seconda di quali simboli si usano nelle espressioni, si realizzano vari tipi di "indirizzamento", cioe` di modi di riferirsi ai contenuti della memoria (del workspace);

- in proposito, una cosa importantissima da capire e` che mettere l'intera espressione tra parentesi quadre realizza quel che si chiama "indirizzamento diretto", cioe` quell'espressione sta a significare, nel ruolo di operando di un'istruzione, che ci si riferisce al CONTENUTO dell'unita` del workspace il cui indirizzo e` il risultato dell'espressione; ad esempio, "[isokernel]" e` proprio un operando del genere: l'espressione e` costituita dalla sola costante chiamata "isokernel", e dato il di cui sopra, significa il contenuto dell'unita` che ha l'indirizzo corrispondente al valore della costante "isokernel".

um... temo che tutto il manuale non possa scrivero qui nei 7000 caratteri del MARGINE del messaggio. Pero` magari da` un'idea.