Forum libero

- Scritto da: The Animal
>
> - Scritto da:
> >
> > - Scritto da: The Animal
> > >
> > > - Scritto da: Dr. House
> > > > in quarantena
> > > >
> > > > vi prego di avvicinarvi a quei signori in
> > camice
> > > > bianco
> > > >
> > > > seguirà un gustoso intermezzo musicale per
> > > > chitarra
> > > > elettrica
> > > >
> > > > la dottoressa caddy vi intratterà mentre io
> > vado
> > > > a schiacciare un pisolino e a praticare una
> > sana
> > > > seduta di affari miei della durata di,
> > diciamo,
> > > > tre
> > > > giorni
> > >
> > >
> > > la caddy è quella giovane o quella vecchia?
> >
> > che differenza fa? il buso è buso
>
> cambia il diametro del buso

E` quella vecchia.

- Scritto da:
>
> - Scritto da:
> >
> > - Scritto da:
> > >
> > > - Scritto da:
> > > >
> > > > - Scritto da:
> > > > >
> > > > > - Scritto da:
> > > > > > quanti siamo?
> > > > > >
> > > > > > aggiungiti al trenino (davanti)...
> > > > > >
>

[ ] -> [ ] -> [ ]-> > [ ] -> [ ] -> [ ] -> [ ]

- Scritto da:
> > > Boh, col mio compagno di banco li usavamo per
> > > seguire il flusso e trovare i bachi. Va bè che
> > > era roba piccola che stava in un foglio di
> > > quaderno, massimo
> > > due.
> >
> > Come si chiamava il tuo compagno di banco,
> > Garrone?
>
> Più o meno.
>
> Ammetto di non avere le competenze per giudicare
> se programmare in assembly oggi permetta di fare
> sensibilmente meglio di ciò che può ottenere un
> compilatore, però in teoria il codice dovrebbe
> essere più veloce e più ottimizzabile. Almeno, ai
> tempi di Garrone era
> così.
>
> Non capisco perché consideri Linoleum così
> inutile. Gli svantaggi principali dell'assembly
> (es. del C64) per me erano la mancanza delle
> mappe di memoria e il fatto che nel tempo
> impiegato a impararlo quel processore era già
> divenuto obsoleto. Essendo virtuale, Linoleum non
> soffre di questi
> svantaggi.
>
> Quanto alle cosiddette difficoltà, evidentemente
> dev'essere come il calabrone, gli utenti del
> forum di Linoleum non le conoscono perciò non ne
> soffrono e programmano lo
> stesso.
>
> Poi una cosa che m'è sempre stata sullo stomaco è
> che ad esempio Open office fa più o meno le
> stesse cose di Word 2 sul 286, su una macchina
> centinaia di volte più potente. I programmatori
> in assembler queste cose non le
> fanno.

Per forza fa le stesse cose, un editor di testo cosa vuoi che faccia? Non so di preciso cosa facesse Word 2 ma disegnare un carattere grafico e` molto piu` lento che farlo su una console solo testo (centinaia di volte), lo spell checking e` piuttosto costoso, come anche la riformattazione continua del testo. Detto questo se OpenOffice fosse stato scritto in assembly non ti porresti il problema, perche' lo rilascerebbero tra vent'anni (forse).

- Scritto da:
> > > Boh, pensavo che il diagramma aiutasse a
> seguire
> > > il flusso e quindi a individuare il punto in
> cui
> > > le cose iniziano ad andare
> > > storte.
> >
> > No, i diagrammi di flusso servivano per
> > documentare codice assembly in un linguaggio di
> > alto livello.
>
> Boh, col mio compagno di banco li usavamo per
> seguire il flusso e trovare i bachi. Va bè che
> era roba piccola che stava in un foglio di
> quaderno, massimo
> due.

Come si chiamava il tuo compagno di banco, Garrone?

- Scritto da:
> Boh, pensavo che il diagramma aiutasse a seguire
> il flusso e quindi a individuare il punto in cui
> le cose iniziano ad andare
> storte.

No, i diagrammi di flusso servivano per documentare codice assembly in un linguaggio di alto livello.
-----------------------------------------------------------
Modificato dall' autore il 02 marzo 2008 12.58
-----------------------------------------------------------

http://www.forumdeitroll.it/m.aspx?m_id=2144314&m_... Scritto da: alex.tg

> > 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.

Il C pero` non e` mai stato realmente assembly, veniva chiamato assembly multipiattaforma piu` per la sua funzione che per altro.

> Io con la versione 2
> includero` diversi esempi fatti per essere
> particolarmente leggibili, e che - incredibile ma
> vero - considero discretamente self-commenting.

Ma non lo sono. Ci metto la mano sul fuoco che non lo sono.

> 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`.

Infatti era un discorso inane.

> > 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.

ma hanno il pregio di essere limitate ad uno scope ben preciso e quindi di non essere globali.

> > 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.

E invece dovrebbero perche'...

> 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.

...o vengono usati (da te o da qualche libreria che stai usando nel codice) e ti esponi ai rischi...

> Ma piu` in
> generale, se non hai un caso del genere, sono
> aspetti la cui rilevanza si puo` autolimitare
> nella stesura del codice.

...oppure replichi a mano il lavoro meccanico che fa il compilatore e quindi sei un deficiente.

> 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.

Io spero, SPERO, che nessuno oltre a te lo usi.

> 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).

Mi pare giusto, aggiungiamo altre dipendenze globali.

> > 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.

non e` una faccenda di velocita` e` una faccenda di codice illeggibile.

>
> > 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`).

E` un punto di vista idiota. E` molto utile scrivere programmi che saranno velocissimi...
...se e quando funzioneranno.

> > 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.

Sempre molto piu` difficile che non doverlo fare per niente.

> 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.

Ok avevo letto male la frase iniziale.

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

La cosa mi rallegra.

- Scritto da: alex.tg
> > 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?

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

> > 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?

Vedi, un altro vantaggio dello scrivere codice ad alto livello e` che e` molto piu` autodocumentante di un blob assembly.
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 per capire cosa contengono stack e registri, l'analisi rischia addirittura di diventare globale e non statica se ci sono dei label di mezzo (questo a meno che il programmatore non ti faccia il favore di descriverti cosa c'e` nello stack e nei registri, che e` una gran mole di documentazione che potrebbe essere - e in ogni caso reale sara` - sbagliata).

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

Intanto scriversela che funzioni in modo semidecente non e` per nulla ovvio. Specialmente se lo si vuole fare in assembly.
Seconda cosa sara` sempre una gestione di memoria stile C, il che significa che se la usi intensivamente sei fottuto.
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.
Quarto se sbaglia (cosa che succede piu` facilmente, essendo assembly) sovrascrivera` i tag del gestore della memoria precipitando il programma nell'indebuggabilita`.


> 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...

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

> > 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.

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

Comunque non mi stupirei piu` di tanto se i compilatori non riuscissero ad ottimizzare bene quel codice. Come ti ho detto l'uso per calcoli di quel tipo e` un caso d'uso anni '60, assolutamente raro al giorno d'oggi. Chi fa ancora al giorno d'oggi quella roba la fa in fortran e paga milioni per il compilatore.

- Scritto da: alex.tg
> O se le operazioni di cui viene misurato il
> tempo, nel loop piu` interno (come era intesa
> essere), fossero ripetute milioni di
> volte.

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 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.
E comunque costerebbe sempre molto meno comprare un altro server e parallelizzare. Anzi, costerebbe meno comprarne altri dieci. Nel mondo della programmazione seria il costo piu` grosso e` il costo dei programmatori.

> Il fatto che il programma Linoleum ti sembri non
> gestibile e` un'opinione su cui generalmente
> gravano fossilizzazioni mentali; ci sono ALTRI
> modi di organizzarsi oltre alla gerarchia degli
> oggetti e all'indentazione in programmazione
> strutturata.

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.


> A ogni modo, la cosa che mi ha stupito e` che il
> modo in cui ho disposto le istruzioni e allocato
> i registri nella versione non ottimizzata e`
> letteralmente
> stupido.

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

- Scritto da:
>
> - Scritto da: avvelentani
> >
> > - Scritto da:
> > >
> > > - Scritto da: avvelentani
> > > >
> > > > - Scritto da:
> > > > >
> > > > > - Scritto da: avvelentani
> > > > > >
> > > > > > - Scritto da:
> > > > > > >
> > > > > > > - Scritto da: avvelentani
> > > > > > > >
> > > > > > > > - Scritto da:
> > > > > > > > >
> > > > > > > > > - Scritto da: avvelentani
> > > > > > > > > >
> > > > > > > > > > - Scritto da:
> > > > > > > > > > >
> > > > > > > > > > > - Scritto da:
> > > > > > > > > > > > > > “connessione tra la
> > cultura
> > > > > > > > > > > > > > della modernità e il
> > > > > > totalitarismo”
> > > > > > > > > > > >
> > > > > > > > > > > > > Dopo la pars destruens che
> > l'
> > > > > esimio
> > > > > > > > > > sociologo
> > > > > > > > > > > > > spieghi come si deve fare
> > per
> > > > > > incidere
> > > > > > > > > > > > seriamente
> > > > > > > > > > > > > nel "mondo reale",
> > > cominciando
> > > a
> > > > > > > > spiegare
> > > > > > > > > > come
> > > > > > > > > > > > > cacciare a calci nel culo
> l'
> > > > > > > oligarchia
> > > > > > > > di
> > > > > > > > > > > > > politicanti che ci governa
> > > > > > > > > > > >
> > > > > > > > > > > > Ben detto. Perché per una
> > parte
> > > > > degli
> > > > > > > > utenti
> > > > > > > > > > la
> > > > > > > > > > > > rete sarà senza dubbio
> > > l'ennesima
> > > > > > > > moderneria
> > > > > > > > > > che
> > > > > > > > > > > > fa fighi, ma per altri è un
> > modo
> > > > per
> > > > > > > > > > comunicare,
> > > > > > > > > > > > cercare consimili, ed
> > esprimere
> > > > ciò
> > > > > > che
> > > > > > > > nel
> > > > > > > > > > > > "mondo reale" dominato dalla
> > > > > politica,
> > > > > > > > > > > > dall'economia e dai media è
> > > > divenuto
> > > > > > > > > > > > impossibile.
> > > > > > > > > > >
> > > > > > > > > > > consimili che non guarderai
> mai
> > > > negli
> > > > > > > occhi,
> > > > > > > > > che
> > > > > > > > > > > in un momento di sconforto non
> > ti
> > > > > > saranno
> > > > > > > di
> > > > > > > > > > > aiuto...
> > > > > > > > > >
> > > > > > > > > > francamente, a me non m'ha mai
> > > > > confortato
> > > > > > > > > > nessuno, neanche quelli che
> > conosco
> > > di
> > > > > > > > persona.
> > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > quelli che conosci probabilmente
> non
> > > > sono
> > > > > > > quelli
> > > > > > > > > giusti per
> > > > > > > > > te.
> > > > > > > >
> > > > > > > > ma no, e` brava gente. e`
> > irragionevole
> > > > > > > > pretendere che uno si faccia carico
> > > anche
> > > > > > degli
> > > > > > > > altrui problemi. si fanno due
> > > chiacchiere,
> > > > > si
> > > > > > > > beve qualcosa insieme, si fanno due
> > > > > > > > battute.
> > > > > > >
> > > > > > > ma tu non eri un hikikomori?
> > > > > >
> > > > > > sul forum abbiamo stabilito che ci sono
> > vari
> > > > > > livelli di hikikomorita` e che uno puo`
> > > essere
> > > > > > hikikomori anche se non sta sempre
> chiuso
> > in
> > > > > > camera. la cosa e` perfettamente in
> linea
> > > con
> > > > la
> > > > > > psicazzologia: piu` la "malattia" e`
> > > definita
> > > > > > vagamente piu` pazienti ci
> > > > > > saranno.
> > > > >
> > > > > ma a te sta bene vivere come vivi? senza
> mai
> > > > > trombare?
> > > >
> > > > sinceramente a me di trombare non me ne
> > importa
> > > > niente. mi manca l'amore, ma non ci sono
> > > > portato.
> > >
> > > Cosa intendi per amore.
> >
> > E` troppo lungo da spiegare e mi sa che non vedi
> > al di la` del tuo
> > cazzo.
>
> ma l'amore non esiste, non sapresti definirlo

tentro la testa esiste.

- Scritto da:
>

no