Forum libero

> > um...
> >
> >
> >
> > A occhio, da un lato hai il codice C-like e dall'altro una forma intermedia universale che pero` e` difficilissima da leggere.
>
> Nessuno deve leggerla. Non è programmare direttamente in meta-assembly lo scopo di LLVM, né essere facile da capire per creature con meno di 20 piedini.
>
> > Essenzialmente Lino mira ad essere umanamente leggibile anche in forma low-level.
>
> Giusto. E questo perché? Perché dai per scontato che qualcuno, oggi, voglia ancora programmare il proprio PC in assembly (o meta-assembly). Perciò è ovvio che vuoi farlo facile da leggere e da capire.

Non ci vedo tutta questa bestiaccia nell'assembly. Una volta che hai fior di librerie, un progetto applicativo lo costruisci a botte di chiamate a funzioni e subroutine di libreria, e strumenti per gestire lo stato (vettori di stato, closures...). Quel che ti manca alla fine non e` cosi` tanto, fra i punti piu` "devianti" c'e` che in Lino non hai la serializzazione automatica delle espressioni, non scrivi:

a = b + c

ma

a = b;
a + c;

e il register naming te lo fai a mano. Pero` in entrambi i casi puoi intervenire a fondo e ottimizzare in modi che un compilatore e` ben difficile che veda. E non e` poi cosi` difficile, a meno che tu non detesti fare 'ste cose a mano e vabbe', allora Lino non ti piacera` mai, ma io non ti costringo davvero a usarlo...

> Il tuo progetto IMO può essere utile in due modi:
> - o come meta-assembly cross-platform per microcontrollori (PIC, ARM, ...) dove ancora esiste qualcuno che apprezzi un linguaggio del genere

Avrebbe un'utilita` che non lo sfrutta del tutto, anzi lo sfrutta in minima parte, ma immagino si possa fare. I sistemi embedded di capacita` molto ridotte non sarebbero probabilmente in grado di far girare la virtual machine, o non avrebbe senso tentare di implementarcela se non in forma minimalista (cosa che e` prevista comunque: c'e` una forma minima che taglia quasi tutte le interfacce col sistema ospite). Ma si`, puo` fare quella parte.

> - o come layer intermedio fra un linguaggio ad alto livello che "compila" in Lino e un processore qualsiasi supportato da Lino, ovvero una cosa simile a LLVM

Cosa che hanno gia` provato a fare nei primi anni dopo la prima release di Lino. Un certo Vladimir Klicik aveva scritto un pre-processore ad alto livello che emetteva codice L.in.oleum, si chiamava Backslash. Fu azzoppato dal fatto che l'autore non ebbe piu` tempo di seguirlo e io cominciai a... spostare il pavimento.

Comunque e` possibile, si`. Forse non vedi poi la controparte del mero sorgente L.in.oleum, che e` la sua virtual machine dedicata, quel che chiamo modulo di run-time. E` molto compatto e molto astratto (ci perde in flessibilita`, questo e` vero), e permette a L.in.oleum di astrarsi non soltanto dall'architettura del processore, ma anche da quella del sistema operativo ospite. E` molto spartano e nel suo modo di funzionare ridefinisce gran parte di come un'applicazione concretizza richieste al sistema sottostante, che e` un aspetto non trascurabile: c'e` molta inventiva, o re-inventiva ponderata, anche nel modulo di run-time e nel funzionamento della parte che s'interfaccia col codice L.in.oleum, parte che si chiama non a caso isokernel.

> > Guarda, a essere sinceri all'inizio avevo pensato anch'io a una cosa che - almeno visivamente - si presentava con l'IF di LLVM, e ai tempi (1999) si chiamava BULK. La derivazione e` nel codice genetico di Linoleum ancora oggi: le sigle di BULK sono ancora nel set d'istruzioni di L.in.oleum. Ad esempio l'assegnazione si chiama SET, la moltiplicazione si chiama "internamente" MUL.f, MUL.n o MUL.i a seconda che sia a virgola mobile, intera senza segno, intera con segno, l'assegnazione sullo stack si chiama SES (SEt on Stack), eccetera... ma BULK non era fatto per essere leggibile, mentre L.in.oleum ha operazioni simboliche in una forma compatta e secondo me molto comprensibile, e la versione 3 arriva anche a portare un po' di struttura (un minimo di blocchi condizionali, tanto per de-spaghettificare tutto quel che ha senso de-spaghettificare, cioe` gran parte di quel che non ha senso ottimizzare per estrema compattezza).
>
> Non metto in dubbio che sia un bel linguaggio, che sia comprensibile e facile da usare una volta che te lo sei imparato.

Quello ci ho pensato io a metterlo in dubbio, fino almeno alla versione 3 che sta arrivando alla fine della sua costruzione. La versione 3 delinea un linguaggio tutto sommato niente male, entro limiti che io stesso mi sono imposto. Come mi ci trovero` con la versione 3 poi lo faro` sapere quando avro` cominciato a farci qualcosa d'interessante.

> Né che tu ci sia giustamente affezionato o giustamente fiero.

Fiero lo saro` solo alla fine, forse. Affezionato si`, ma soprattutto prima di mollarlo devo avere buone ragioni se no e` tutto veramente lavoro buttato. Se a volte ho avuto la tentazione di mollarlo e` stato piu` che altro perche` i miei interessi si erano allontanati dall'informatica in generale, non perche` non lo ritenessi di per se` degno di sopravvivere.

> Metto in dubbio che, così com'è, ovvero stand-alone, possa servire a qualcuno.

Serve a me.

> Come ho detto qui sopra... ci sono ancora nicche dove potrebbe essere usato, ma finché vuoi tenerlo come oggetto stand-alone o vuoi tenerlo fuori dai microcontrollori dubito che qualcuno giorno senza la necessità di usarlo per qualcosa di concreto sui PC.

Sara` stata una mia impressione ma ho faticato a tenere indietro la gente dopo la prima versione. Dalla versione 2 ho cominciato una campagna di silenzio con avvisi intermittenti: "fermi", "aspettate", "non e` pronto", "e` embrionale", "e` vernice fresca". Non vorrei che lo usassero finche` non lo considero sintatticamente stabile, perche` poi se la prendono quando le cose smettono di funzionare passando da una versione all'altra. Gia` adesso m'e` toccato rendere il compilatore 3 retrocompatibile con la versione 2.

Oddio, la cosa non m'e` del tutto dispiaciuta, visto che posso posporre il porting del compilatore stesso alla versione 3. Infatti e` ancora in Linoleum 2, compilato da se` stesso nella versione che supporta anche il codice v3.

> Vuoi sapere un altro settore che mi è appena venuto in mente in cui il tuo Lino potrebbe essere davvero utile? Nel kernel di Linux. Ci sono parti che sono scritte in assembly puro e che per ogni nuovo processore vanno riscritte da capo. Se le avessero scritte in Lino basterebbe solo aggiungere quell'architettura a Lino e ricompilare per il nuovo processore. Lì avrebbe senso anche stand-alone. Magari spingi in questa direzione... parlane con Linus. Fate due esperimenti. Se ho ragione il tuo Lino avrà un successo bestiale.

Sissi`, ma non adesso. Se no mi salta addosso tutta la comunita` Linux quando esce la versione 4 non retrocompatibile. Spero non debba mai uscire, ma non si sa mai.

Fra un po' magari si`.

Scritto da: altg
> > > > Ma non trovate che manchi un anello di congiunzione tra l'alto livello e l'assembly nativo (quello specifico di una piattaforma)?
> > >
> > > http://en.wikipedia.org/wiki/GNU_Assembler
> >
> >

.globl  _start
> > 
> > .text
> > _start:
> > movl    $len, %edx
> > movl    $msg, %ecx
> > movl    $1, %ebx
> > movl    $4, %eax
> > int     $0x80
> > 
> > movl    $0, %ebx
> > movl    $1, %eax
> > int     $0x80
> > .data
> > msg:
> > .ascii  "Hello, world!\n"
> > len =   . - msg

> >
> > Boh? Dove sarebbe cross-platform? Assume che esistano registri da eax a edx, e che il dispatcher di sistema sia sull'interrupt 80h? Quello e` pressoche` assembly nativo, o l'esempio e` sbagliato?

No, opcode e nomi dei registri sono tutti dipendenti dall'architettura, gas si limita ad assemblare per qualunque architettura esistente. E` il backend di gcc che internamente ha una sua rappresentazione dell'assembly che pero` e` solo parzialmente indipendente dall'architettura per questioni di ottimizzazione.

> >
> > > http://en.wikipedia.org/wiki/Llvm
> >
> > E` interessante. L.in.oleum non e` inteso essere un back-end, comunque non e` molto dissimile. Mi chiedo se esistesse nel 2001, LLVM.
>
> Ah, no:
>
> Initial release 2003
>
> Troppo tardi, ero gia` partito e ora non mollo certo per loro.

L'importante non e` chi inizia per primo ma chi finisce per primo.