Forum libero

E io non entro nel merito, e` che almeno l'intenzione di avere un'informazione meno bacata non mi puo` non sembrare buona. Tralasciando tutto il resto.

Si`, da tempo.
Dal 20 febbraio scorso, lo dissi anche in un vecchio thread dall'altra parte.

Credo sia merito di Nettare: Telecom ha cablato la zona un paio di settimane dopo che si erano resi disponibili quelli di Nettare, ovviamente per evitare concorrenza.

Che il kernel dei Win 9x fa un gocciolino cacare. Niente di nuovo. Con qualcuno mi dovevo pur sfogare...

No no, affatto.

E` che segui qui, segui li`, stampa questo, fai quell'altro... ogni tanto do' un'occhiata ma se rispondo sempre *veramente* ci perdo tempo. Non sto facendo il prezioso perche` mi state tutti sui fondelli eccetera, e io sono superiore eccetera... no no, scelta pragmatica e anche un po' sofferta.

Giocare a carte, chiaccherare con amici, pisciare il cane fuori, tentare di conquistare il mondo per le 6.

No no a volte ci sono... e` il solito discorso di perdere tutto il giorno qui.

> > In realta` no. Perche' il bug potrebbe essere
> > tranquillamente nelle barriere tra un modulo e
> > l'altro che ha costruito.
>
> Le mie esperienze di programmazione (*) sono
> troppo limitate per capire cosa intendi
> esattamente. Attenderò che arrivi alex.tg per
> sentire che ne
> dice.

Intende che un linguaggio hi-level ti impone (o meglio suggerisce con forza) un paradigma, un modello da seguire, che stabilisce il modo in cui sorgenti diversi interagiscono e che e` progettato per limitare al minimo i molti inconvenienti a cui potresti andare incontro tentando di legarli.

Con l'assembly uno invece puo` al massimo suggerire una "forma normale" che aiuti a prevenire questi problemi, solo che non lega la sua sintassi a questa forma, e quindi l'assemblatore non puo` controllare quel che poi il programmatore decide di fare (per scelta o per errore).

> Ma infatti la difficoltà di quest'approccio sta
> nel dedurre il flusso del programma leggendo
> righe, ed è ovvio che un linguaggio ad alto
> livello condensa più operazioni in meno
> righe.

http://0x44.com/tmp/text_reader.txt

Infatti e` un linguaggio molto logorroico. Ma non direi che e` cosi` difficile da dedurre...

> È ovvio che alex.tg ha sviluppato a tal punto
> l'abilità-abitudine di leggere il flusso
> direttamente dal codice macchina, che per lui la
> cosa non rappresenta alcun problema, come chi sa
> leggere la musica sente il brano riprodursi come
> da un disco mentre passa l'occhio su quelle che
> per me sono cacchine di
> mosca.

Forse c'e` del vero, ma io non sono affatto un fenomeno. A ogni modo, resta vero che non ho detto e non diro` mai "venite tutti a programmare in Linoleum che e` la panacea di tutti i mali".

> Come gestire codice assembly. Negli anni
> sessanta/settanta ci sono state diverse imprese
> che sono fallite perche' la loro codebase era in
> assembly.

Be', io ho la pretesa che un certo tipo di assembly possa essere relativamente molto piu` mantenibile che l'assembly nativo di che so... un vetusto MC6510, magari. Con questo, non ho difficolta` a credere che non abbiano retto il passo. E` chiaro che i linguaggi ad alto livello, che TUTTAVIA non disprezzo affatto, abbiano vantaggi netti in termini di produttivita`. Non e` in discussione.

> Vedi, un altro vantaggio dello scrivere codice ad
> alto livello e` che e` molto piu`
> autodocumentante di un blob
> assembly.

Ovvio. Tuttavia, non essere troppo digitale. C'e` blob e blob e ci sono livelli piu` o meno decifrabili di "blobbismo". Anche il C ha rivestito in tempi andati un ruolo di assembly multipiattaforma, e tutto sommato ha avuto un discreto successo. Io con la versione 2 includero` diversi esempi fatti per essere particolarmente leggibili, e che - incredibile ma vero - considero discretamente self-commenting. Sono esempi e sono brevi, ma anche sulla scala di progetti intermedi penso si potranno ottenere risultati interessanti in termini di mantenibilita`. Oh, poi i tempi sono cambiati, e` vero, e roba scritta Linoleum ha senso come codebase solo in certi ambiti di nicchia, il che non lo nega nessuno e tantomeno io. Il discorso iniziale verteva esclusivamente sulla velocita`.

> Inoltre anche una sola riga di assembly la
> considero piu` complicata di una riga di c++
> perche' per capire la riga di assembly devi
> leggere un numero imprecisato di righe precedenti

Comprensibile ma va be', quello succede anche in altri linguaggi, ovunque ci siano dipendenze dalle istruzioni precedenti.

> per capire cosa contengono stack e registri,
> l'analisi rischia addirittura di diventare
> globale e non statica se ci sono dei label di
> mezzo

Pero` stack e registri non sono spauracchi e non dovrebbero esserlo. Forse consideri la loro incarnazione vista in moduli che fanno della compattezza e della performance i loro punti chiave e che per forza di cose devono risparmiare bytes e cicli col contagocce. Ma piu` in generale, se non hai un caso del genere, sono aspetti la cui rilevanza si puo` autolimitare nella stesura del codice. E d'altronde io trovo utile averli a disposizione e controllarli in ogni punto, ed e` forse la ragione principale per cui sto producendo questo aggeggio. Altrimenti mi accontentavo di inserire paragrafi assembly nei punti chiave di un'implementazione in C++. Poi, ovvio, non pretendo che nessuno usi Linoleum oltre a me.

> Intanto scriversela che funzioni in modo
> semidecente non e` per nulla ovvio.

Vero, ma come per un po' tutto esistono modelli collaudati.

> Specialmente
> se lo si vuole fare in assembly.

Anche qui continuo a pensare che c'e` modo e modo di rendere piu` o meno leggibile un listato che e` basato sull'assembly di istruzioni per la maggior parte atomiche.

> Seconda cosa sara` sempre una gestione di memoria
> stile C, il che significa che se la usi
> intensivamente sei
> fottuto.

Mah, a mio parere dipende da come la implementi. Ci possono essere una heap dinamica per uso sporadico e diversi banchi statici per uso intensivo, accomunati da una stessa interfaccia, che e` come ho idea di impostare la cosa (e in parte l'ho gia` impostata, anche se e` ancora un'implementazione frettolosa molto migliorabile).

> Terza cosa il codice che la usa avra` bisogno di
> un livello di indirezione extra (come in C/C++)
> tutto a carico del programmatore - in
> assembly.

Vero. Indirezione che tuttavia, se gestita all'esterno delle fasi in cui il tempo e` un fattore critico, in definitiva non troverei molto influente.

> Quarto se sbaglia (cosa che succede piu`
> facilmente, essendo assembly) sovrascrivera` i
> tag del gestore della memoria precipitando il
> programma
> nell'indebuggabilita`.

Vero, ma personalmente valuto piu` importante la maggior capacita` di controllo. E` un punto di vista (ed e` produttivamente perdente, per carita`).

> Cosa c'e` nei registri conta molto se devi capire
> cosa cazzo sta facendo il
> programma.

Conta, ma se di registri ne hai solo cinque (semplificazione tragica ma utile e necessaria), per come il dizionario li lascia vedere all'applicazione essi sono tutti general-purpose, il loro comportamento e` equalizzato su tutte le piattaforme, e la sintassi delle modalita` d'indirizzamento segue un modello coerente, l'individuazione del ruolo di ciascun registro mi risulta mica tanto difficile. A meno che il listato non sia ottimizzato all'estremo e magari usando sorgenti dedicati a una specifica piattaforma.

> In cosa ti riferivi sopra, alle ottimizzazioni
> tue sul codice C++ o a quelle del
> compilatore?

Alle mie ottimizzazioni. La versione _opt e` ottimizzata ragionandoci su`. L'altra e` fatta ancora "a mano" ma riflette una traduzione molto piu` immediata e meccanica delle istruzioni C.

> Come ti ho detto l'uso per calcoli
> di quel tipo e` un caso d'uso anni '60,

La cosa mi rattrista.

ps.
abbi pazienza il ritardo, contrattempo mentre scrivevo.

> No, perche' sarebbero comunque 16 minuti contro
> mezz'ora. Troppo poco considerato i costi di
> sviluppo e manutenzione di un coso in
> pseudo-assembly.

E dai, quanto pensi che sia difficile la manutenzione di codice Linoleum?

> E sei fortunato che praticamente
> lo stai usando per applicazioni anni '60, se
> facevi qualcosa di moderno non erano 95 righe
> contro 350 erano 95 righe contro
> 3500.

Ma ridai, non arrampicarti troppo sugli specchi. Vuoi che inserisca righe vuote anche nei sorgenti Java e C? O che compatti quelle del sorgente Linoleum? O che elimini certe tag che evidenziano l'architettura load-store? Poi si che diventa ingestibile, ma davvero pensi che scrivere quattro righe al posto di una sia meno mantenibile? A prescindere da come sono organizzate?

> Certo basta microgestire cosa c'e` sullo stack,
> in che ordine e cosa ho messo in quali registri,
> possibilmente allocando tutto staticamente
> perche' gestire qualsiasi operazione di
> allocazione dinamica diventa
> un'impresa.

Basta scriversi una libreria di gestione dell'heap, MA porca miseria! Non e` chiaro? Devo spiegare anche queste sciocchezze? Ma si scherza per davvero?

E l'ordine dei registri conta solo dove devi davvero ottimizzare, il resto e` come discesti te, una traduzione e una lettura TRIVIALE. Abbi pazienza l'alzata di voce...

> E` ovvio, la versione non ottimizzata non e`
> ottimizzata.

*sigh*
Non hai capito.

La MIA versione non era ottimizzata, era una traduzione passo passo del tutto TRIVIALE delle istruzioni C. E` quanto chiunque farebbe - senza pensarci un attimo, neanche minimamente a possibili ottimizzazioni nell'allocazione dei registri - se dovesse tradurre quel codice in assembly.

http://0x44.com/tmp/results.zip