☺
Scritto da
altg
utente che non utiene
il 2014-11-03 21:14:29.0 alle 2014-11-03 21:14:29.0
Trollate totali: 11540
...ma porca miseria, come si semplifica 'sto cazzo di hello world?
Ah, ho cambiato le freccine "comes from", quelle che prima erano <- ora sono rappresentate dall'asciitilde (~). A parte quello, che l'ho fatto perche` vedere freccine di qui e di la` sulla stessa riga lo trovavo distraente, difficile da leggere. Pero` a parte quello, minchia!
Tutto per scrivere "hello world", prima era piu` semplice ma non aveva static typing (che controlla tutti i bindings delle istanze e che fra l'altro gli dice che { Hello_world! } e` una stringa (null-terminated) alla quale viene applicato il metodo "To Text" che la trasforma in un oggetto "text" allocato sull'heap, che lo wrappa in informazioni aggiuntive (per esempio diventa non piu` null-terminated ma di una lunghezza nota, che e` una proprieta` dell'oggetto).
E poi prima non passava da un'opportuna interfaccia: e se poi voglio scriverlo su un file? O su uno schermo grafico? O mandarlo attraverso una socket? Mi toccava sempre cambiare la chiamata a "Say" che prima si riferiva direttamente a un metodo dell'oggetto "text" che assumeva che i testi si scrivessero tutti tramite stdout. Cosi` invece uso un metodo virtuale di "textIo" che POI, a scelta e in questo specifico caso, s'interfaccia con la console (cioe` scrive su stdout, per via di "Bind To console").
Cioe`, non so, dal punto di vista logico mi sembra tutto molto bello, ma come mai mi e` rimasta addosso la sensazione di aver costruito una centrale nucleare per far funzionare un aspirapolvere?
startup displayStatus engage
include string ToText
include textIo on console
include util Pause
to Begin "framed
here messenger ~ textIo::Create -> Bind To console
here message ~ { Hello_world! } as string -> To Text
messenger -> Say message
util::Pause
return
Ah, ho cambiato le freccine "comes from", quelle che prima erano <- ora sono rappresentate dall'asciitilde (~). A parte quello, che l'ho fatto perche` vedere freccine di qui e di la` sulla stessa riga lo trovavo distraente, difficile da leggere. Pero` a parte quello, minchia!
Tutto per scrivere "hello world", prima era piu` semplice ma non aveva static typing (che controlla tutti i bindings delle istanze e che fra l'altro gli dice che { Hello_world! } e` una stringa (null-terminated) alla quale viene applicato il metodo "To Text" che la trasforma in un oggetto "text" allocato sull'heap, che lo wrappa in informazioni aggiuntive (per esempio diventa non piu` null-terminated ma di una lunghezza nota, che e` una proprieta` dell'oggetto).
E poi prima non passava da un'opportuna interfaccia: e se poi voglio scriverlo su un file? O su uno schermo grafico? O mandarlo attraverso una socket? Mi toccava sempre cambiare la chiamata a "Say" che prima si riferiva direttamente a un metodo dell'oggetto "text" che assumeva che i testi si scrivessero tutti tramite stdout. Cosi` invece uso un metodo virtuale di "textIo" che POI, a scelta e in questo specifico caso, s'interfaccia con la console (cioe` scrive su stdout, per via di "Bind To console").
Cioe`, non so, dal punto di vista logico mi sembra tutto molto bello, ma come mai mi e` rimasta addosso la sensazione di aver costruito una centrale nucleare per far funzionare un aspirapolvere?
☺
Scritto da
altg
utente che non utiene
il 2014-11-03 02:31:05.0 alle 2014-11-03 02:31:05.0
Trollate totali: 11540
> > > > >
> > > >
> > > > Mi riesce difficile pensare che, se l'e-cat è una bufala, continuino a parlarne ed effettuare prove di laboratorio.
> > >
> > > Tu pensa che io sento parlare di Biancaneve da quando sono nato, eppure mi dicono che non esiste. che è una favola.
> >
> > Ti sei dimenticato di leggere "prove di laboratorio".
>
> Hai fatto bene a mettere le virgolette:
>
http://attivissimo.blogspot.it/2013/05/e-cat-i-nuo... 
WOW! il tono si adatta benissimo agli sviluppi di Linoleum di stanotte:
“Fusione nucleare fredda: un italiano ce l'ha fatta” annuncia trionfante Valerio Porcu su Tomshw.it. L'E-Cat di Andrea Rossi sarebbe stato sottoposto a “test indipendenti” che forniscono “prove... firmate da scienziati che così rischiano reputazione e carriera”. Addirittura l'apparato sarebbe “in grado di autoalimentarsi”. Il titolo così sicuro, però, stride con un'altra frase: “non si può dire per certo che sia tutto vero”.
"Type system statico: l'autore ce l'ha fatta". Il compilatore sarebbe stato sottoposto a "test indipendenti" (fatti dall'autore su un solo file scritto da lui) che forniscono "prove firmate da uno sviluppatore che cosi` rischia la reputazione sul FdT" (la carriera no, tanto non c'e`). Addirittura l'apparato sarebbe in grado di convalidare il tipo di istanza a cui e` legato un metodo". Non si puo` dire per certo che tutto funzioni o che l'autore abbia una decente certezza di quello che ha aggiunto al compilatore.
> > > >
> > > > Mi riesce difficile pensare che, se l'e-cat è una bufala, continuino a parlarne ed effettuare prove di laboratorio.
> > >
> > > Tu pensa che io sento parlare di Biancaneve da quando sono nato, eppure mi dicono che non esiste. che è una favola.
> >
> > Ti sei dimenticato di leggere "prove di laboratorio".
>
> Hai fatto bene a mettere le virgolette:
>
http://attivissimo.blogspot.it/2013/05/e-cat-i-nuo... WOW! il tono si adatta benissimo agli sviluppi di Linoleum di stanotte:
“Fusione nucleare fredda: un italiano ce l'ha fatta” annuncia trionfante Valerio Porcu su Tomshw.it. L'E-Cat di Andrea Rossi sarebbe stato sottoposto a “test indipendenti” che forniscono “prove... firmate da scienziati che così rischiano reputazione e carriera”. Addirittura l'apparato sarebbe “in grado di autoalimentarsi”. Il titolo così sicuro, però, stride con un'altra frase: “non si può dire per certo che sia tutto vero”.
"Type system statico: l'autore ce l'ha fatta". Il compilatore sarebbe stato sottoposto a "test indipendenti" (fatti dall'autore su un solo file scritto da lui) che forniscono "prove firmate da uno sviluppatore che cosi` rischia la reputazione sul FdT" (la carriera no, tanto non c'e`). Addirittura l'apparato sarebbe in grado di convalidare il tipo di istanza a cui e` legato un metodo". Non si puo` dire per certo che tutto funzioni o che l'autore abbia una decente certezza di quello che ha aggiunto al compilatore.
☺
Scritto da
altg
utente che non utiene
il 2014-11-02 17:54:05.0 alle 2014-11-02 17:54:05.0
Trollate totali: 11540
> > > Spiega anche come fa a riconoscere le tossine ? Magia ?
> >
> > no rispetto al peso molecolare
In altre parole, come faceva il php in origine a fare l'hash delle funzioni: ma dalla lunghezza del nome, no?
> > Questo gel inodore e insapore, privo di glutine, aromi e conservanti, presenta una struttura globulare porosa a base di Silicio, capace di agire a livello gastro-intestinale “legando” selettivamente le sostanze tossiche con un determinato peso molecolare (non lega sali minerali, elettroliti, proteine e immunoglobuline, mantenendo quindi il totale equilibro organico) e rimuovendole naturalmente entro 12 ore dall’assunzione del prodotto.
> >
> > http://www.infosalute.info/articolo.php?id=87&ente...
> >
>
> quando la terminologia scientifica viene usata in modo approssimativo e a sproposito al 99% si tratta di una truffa per accalappiare gonzi ignoranti come te, idyoda
La precisazione "privo di glutine" e` stupenda!
> >
> > no rispetto al peso molecolare
In altre parole, come faceva il php in origine a fare l'hash delle funzioni: ma dalla lunghezza del nome, no?
> > Questo gel inodore e insapore, privo di glutine, aromi e conservanti, presenta una struttura globulare porosa a base di Silicio, capace di agire a livello gastro-intestinale “legando” selettivamente le sostanze tossiche con un determinato peso molecolare (non lega sali minerali, elettroliti, proteine e immunoglobuline, mantenendo quindi il totale equilibro organico) e rimuovendole naturalmente entro 12 ore dall’assunzione del prodotto.
> >
> > http://www.infosalute.info/articolo.php?id=87&ente...
> >
>
> quando la terminologia scientifica viene usata in modo approssimativo e a sproposito al 99% si tratta di una truffa per accalappiare gonzi ignoranti come te, idyoda
La precisazione "privo di glutine" e` stupenda!
☺
Scritto da
altg
utente che non utiene
il 2014-11-02 17:20:32.0 alle 2014-11-02 17:20:32.0
Trollate totali: 11540
> > > > Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
> > >
> > > Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
> >
> > Um... io sono un tipo atipico, come ben puo` confermarti il Prof. Avvelentani. Uno che pensa parecchio lateralmente, quasi di sbieco, solo un po' piu` giu` a babordo.
>
> Non è un approccio per forza di cose sbagliato, ci sono molti che preferiscono il tuo approccio per questione di flessibilità.
>
> > > Niente generatore di parser quindi, né grammatiche del linguaggio.
> >
> > No, mai provato generatori di parsers. Non saprei quanto sarebbe comodo un generatore di parsers, puo` darsi che sarebbe comodo, oppure che per fargli fare quello che vuoi tu debba pregarlo in cinese tradizionale. Boh. Comunque io mi trovo bene a scriverli per conto mio. Quello di Lino4 guarda carattere per carattere in ordine piu` o meno LTR, ma ogni tanto fa una puntatina ahead per distinguere qualche caso, tipo quelli di "-" e "-->", nel senso che si chiede "che viene dopo il trattino?".
>
> Sì, ti tocca litigare un po' per fargli fare quello che vuoi. Un vantaggio è la portabilità, metti che un domani vuoi cambiare l'implementazione in un altro linguaggio/piattaforma, sarà molto più facile visto che la grammatica è quella. L'altro vantaggio è che l'approccio formale evita alcuni tipi di bug nell'implementazione (qualcuno ha detto parser di php?).
Boh, c'erano dei bug nel parser di php?
Vabbe' tanto non me ne sono accorto.
Qui i bug piu` che nel parser li trovo nel semi-assembler: e` difficile testarne tutte le combinazioni di opcode e operandi, e ogni tanto ne salta fuori una che fa ka-boom.
> > >
> > > Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
> >
> > Um... io sono un tipo atipico, come ben puo` confermarti il Prof. Avvelentani. Uno che pensa parecchio lateralmente, quasi di sbieco, solo un po' piu` giu` a babordo.
>
> Non è un approccio per forza di cose sbagliato, ci sono molti che preferiscono il tuo approccio per questione di flessibilità.
>
> > > Niente generatore di parser quindi, né grammatiche del linguaggio.
> >
> > No, mai provato generatori di parsers. Non saprei quanto sarebbe comodo un generatore di parsers, puo` darsi che sarebbe comodo, oppure che per fargli fare quello che vuoi tu debba pregarlo in cinese tradizionale. Boh. Comunque io mi trovo bene a scriverli per conto mio. Quello di Lino4 guarda carattere per carattere in ordine piu` o meno LTR, ma ogni tanto fa una puntatina ahead per distinguere qualche caso, tipo quelli di "-" e "-->", nel senso che si chiede "che viene dopo il trattino?".
>
> Sì, ti tocca litigare un po' per fargli fare quello che vuoi. Un vantaggio è la portabilità, metti che un domani vuoi cambiare l'implementazione in un altro linguaggio/piattaforma, sarà molto più facile visto che la grammatica è quella. L'altro vantaggio è che l'approccio formale evita alcuni tipi di bug nell'implementazione (qualcuno ha detto parser di php?).
Boh, c'erano dei bug nel parser di php?
Vabbe' tanto non me ne sono accorto.
Qui i bug piu` che nel parser li trovo nel semi-assembler: e` difficile testarne tutte le combinazioni di opcode e operandi, e ogni tanto ne salta fuori una che fa ka-boom.
Multiculturalismo a Bruxelles
Ad
https://www.davidicke.com/article/513643/firemen-flee-attacked-migrant-youths-multicultural-molenbeek
“They call us for small fires and attack us while we want to help.”
☺
Scritto da
altg
utente che non utiene
il 2014-11-02 17:01:58.0 alle 2014-11-02 17:01:58.0
Trollate totali: 11540
> > Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
>
> Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
Um... io sono un tipo atipico, come ben puo` confermarti il Prof. Avvelentani. Uno che pensa parecchio lateralmente, quasi di sbieco, solo un po' piu` giu` a babordo.
> Niente generatore di parser quindi, né grammatiche del linguaggio.
No, mai provato generatori di parsers. Non saprei quanto sarebbe comodo un generatore di parsers, puo` darsi che sarebbe comodo, oppure che per fargli fare quello che vuoi tu debba pregarlo in cinese tradizionale. Boh. Comunque io mi trovo bene a scriverli per conto mio. Quello di Lino4 guarda carattere per carattere in ordine piu` o meno LTR, ma ogni tanto fa una puntatina ahead per distinguere qualche caso, tipo quelli di "-" e "-->", nel senso che si chiede "che viene dopo il trattino?".
ps. ah ecco, ho ricontrollato, e` essenzialmente un LALR(2), Look-Ahead Left-to-Right con 2 tokens "presi piu` avanti". Ma non lo scrivo seguendo qualche modello ideale, lo scrivo partendo da un'idea di comodita`, e poi ce lo modello intorno. Per esempio e` +2 perche` appunto trovo convenienti i simboli "-->" e "<--" per push e pop in/da stack, perche` sono molto visibili e questo dovrebbe aiutare a evitare errori, visto che sbagliare a manipolare lo stack a basso livello e` catastrofico.
**Modificato dall'autore il 02.11.2014 17:13**
>
> Sto imparando a parsare come fanno i grandi, volevo vedere come facevi tu.
Um... io sono un tipo atipico, come ben puo` confermarti il Prof. Avvelentani. Uno che pensa parecchio lateralmente, quasi di sbieco, solo un po' piu` giu` a babordo.
> Niente generatore di parser quindi, né grammatiche del linguaggio.
No, mai provato generatori di parsers. Non saprei quanto sarebbe comodo un generatore di parsers, puo` darsi che sarebbe comodo, oppure che per fargli fare quello che vuoi tu debba pregarlo in cinese tradizionale. Boh. Comunque io mi trovo bene a scriverli per conto mio. Quello di Lino4 guarda carattere per carattere in ordine piu` o meno LTR, ma ogni tanto fa una puntatina ahead per distinguere qualche caso, tipo quelli di "-" e "-->", nel senso che si chiede "che viene dopo il trattino?".
ps. ah ecco, ho ricontrollato, e` essenzialmente un LALR(2), Look-Ahead Left-to-Right con 2 tokens "presi piu` avanti". Ma non lo scrivo seguendo qualche modello ideale, lo scrivo partendo da un'idea di comodita`, e poi ce lo modello intorno. Per esempio e` +2 perche` appunto trovo convenienti i simboli "-->" e "<--" per push e pop in/da stack, perche` sono molto visibili e questo dovrebbe aiutare a evitare errori, visto che sbagliare a manipolare lo stack a basso livello e` catastrofico.
**Modificato dall'autore il 02.11.2014 17:13**
☺
Scritto da
altg
utente che non utiene
il 2014-11-02 16:47:40.0 alle 2014-11-02 16:47:40.0
Trollate totali: 11540
> I sorgenti del parser sono scritti in linoleum? Se sono scritti in un linguaggio umanamente comprensibile ce li puoi mostrare?
I sorgenti del parser del compilatore di L.in.oleum 4 sono scritti in javascript. Girano nel browser, appoggiandosi per la lettura delle librerie a un miniserver nodeJS (una versione downscaled di JS Mary Lou). Il linker e` un modulo del webserver che risponde a un POST del disassemblato (l'output testuale del compilatore) all'indirizzo "http://localhost:4048/link".
Il compilatore e` un monoblocco javascript di 13500 righe, poi c'e` l'assembler specifico per x86 che ne conta altre 3150 (ovviamente e` switchabile con altri "semi-assemblers"). Li chiamo semi-assemblers perche` sono assemblers incompleti: si limitano ad assemblare il subset di istruzioni e modalita` d'indirizzamento contemplate dalla sintassi L.in.oleum.
In cima a tutto c'e` il front-end, cioe` il javascript che anima l'interfaccia, e che include un piccolo text editor per editare i sorgenti. Per navigare tra le librerie, le righe "include" vengono evidenziate come links che porta alla corrispondente libreria.
Di parser non ce n'e` uno solo: ce n'e` uno principale che isola le linee dei sorgenti, le istruzioni e le espressioni, ma poi c'e` il parser delle espressioni, quello degli operandi, quello dei ranges (inline arrays) e delle stringhe.
Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
Fra l'altro sono ancora un po' in evoluzione, spuntano spesso degli errorini mentre scrivo le prime librerie: il compilatore e` in rodaggio, insomma...
I sorgenti del parser del compilatore di L.in.oleum 4 sono scritti in javascript. Girano nel browser, appoggiandosi per la lettura delle librerie a un miniserver nodeJS (una versione downscaled di JS Mary Lou). Il linker e` un modulo del webserver che risponde a un POST del disassemblato (l'output testuale del compilatore) all'indirizzo "http://localhost:4048/link".
Il compilatore e` un monoblocco javascript di 13500 righe, poi c'e` l'assembler specifico per x86 che ne conta altre 3150 (ovviamente e` switchabile con altri "semi-assemblers"). Li chiamo semi-assemblers perche` sono assemblers incompleti: si limitano ad assemblare il subset di istruzioni e modalita` d'indirizzamento contemplate dalla sintassi L.in.oleum.
In cima a tutto c'e` il front-end, cioe` il javascript che anima l'interfaccia, e che include un piccolo text editor per editare i sorgenti. Per navigare tra le librerie, le righe "include" vengono evidenziate come links che porta alla corrispondente libreria.
Di parser non ce n'e` uno solo: ce n'e` uno principale che isola le linee dei sorgenti, le istruzioni e le espressioni, ma poi c'e` il parser delle espressioni, quello degli operandi, quello dei ranges (inline arrays) e delle stringhe.
Ma a che ti servono i sorgenti del/dei parser? Per curiosita`?
Fra l'altro sono ancora un po' in evoluzione, spuntano spesso degli errorini mentre scrivo le prime librerie: il compilatore e` in rodaggio, insomma...
☺
Scritto da
altg
utente che non utiene
il 2014-11-02 15:22:57.0 alle 2014-11-02 15:22:57.0
Trollate totali: 11540
> Dico che sarebbe meglio visto che la sintassi intel funziona cosi` da sempre.
Va be', terro` presente, puo` darsi che cambi idea. La sintassi intel e` ben affermata, lo ammetto, pero` la trovo meno descrittiva di "p.-1" perche` assume che uno spiazzamento possa essere direttamente sottratto all'indirizzo di base, mentre in realta` e` aggiunto come valore negativo in complemento a due.
> Ci metterei anche delle parentesi quadre attorno.
Non mi conviene, le sto usando per definire array inline.
Cioe`:
x = [ 1, 2, 3 ]
carica "x" con l'indirizzo di un array statica contenente le words 1, 2, 3 (e poi zero, perche` per default e` null-terminated). Poi dovrei in qualche modo distinguere i casi.
> > Parlando di come funziona L.in.oleum, presuppongo che "allineato" significhi a una parola del processore.
>
> Allineato nel mondo normale significa che l'indirizzo e` un multiplo della dimensione.
Vabbe', se lo dici te... per me "allineato" senza "a cosa" era un errore di sintassi, al massimo sfruttabile per intendere "a una granularita` di default".
> > > Tutti questi vantaggi dell'indirizzare la memoria solo a multipli di 4 io non ce li vedo, il fatto che non io non conosca un assembly che ti obbliga a farlo e che il C allinei le strutture come le allinea mi suggerisce che questi supposti vantaggi non esistano.
> >
> > Intanto il codice che hai postato legge 4 bytes (una "unita`") per volta e "si contorce" per estrarre dal valore composto di 4 byte il primo byte a zero? Se come dicevi "dovesse essere leggibile", leggerebbe byte per byte.
>
> Il codice che ho postato io non e` fatto per essere leggibile, e` fatto per essere veloce. E non e` solo per via dell'allineamento ma anche perche' e` bit-parallelo.
Bit-che?
Legge 4 byte per volta, come fa la reimplementazione L.in.oleum.
E` parallelo tanto quanto lo e` la sua reimplementazione, qualunque cosa tu intendessi per bit-parallelo.
Non legge i singoli bytes per trovare il terminatore, processa intere words.
> Se dopo aver fatto il tuo bel load allineato ti devi andare a pescare i singoli byte a botte di shr e and e` molto piu` veloce e leggibile fare una lettura non allineata.
Leggibile magari si`, veloce no. In generale, se leggi un registro di 32 bit per operare sui bytes che contiene, fai un accesso parallelo di 4 bytes invece che seriale byte per byte.
Certo a meno che uno debba leggere un byte solo, ma a quel punto di solito non fai un ciclo.
> > ARM era stata pensata per avere tutte istruzioni di una word (32 bit) per semplificare la decodifica e il fetching.
>
> http://infocenter.arm.com/help/index.jsp?topic=/co...
>
> LDRB e SDRB ci sono sempre stati.
Chissa` se sono penalizzati.
Gli Intel penalizzano gli accessi non allineati alla word del processore.
> > tre istruzioni in croce. Ok, ci saranno i ritardi di cache 4 volte piu` spesso che se la stringa fosse fatta di bytes,
>
> Hai detto niente!
Ma non intendo dire che quando operi su stringhe di caratteri allineati a una word, lo fai perche` la stringa e` colossale. Le converti a stringhe del genere quando devi manipolare frequentemente la stessa stringa, tipo splittarla o concatenarne frammenti. In generale, stai immaginando casi che secondo me sono molto rari, dove la performance dovuta alla specifica capacita` di leggere singoli bytes farebbe la differenza.
> > > Quindi secondo te il fatto che le istruzioni di jump siano piu` lunghe di qualche byte rispetto a quanto potrebbero essere e` piu` importante del fatto che tutte le stringhe siano 4 volte piu` lunghe di quanto potrebbero essere?
> >
> > La localita` del codice e` almeno altrettanto importante, ma probabilmente di piu`: quella si applica a tutto il codice, le stringhe di testo a 8 bit sono casi particolari. E` un difetto del compilatore abbozzato attuale, ma mi prometto di risolverlo in seguito.
>
> Secondo te cosa prende piu` spazio? Il codice o i dati?
E secondo te cosa viene letto piu` spesso, il codice o i dati?
> Secondo me a te piace il fatto che hai un solo tipo di dato perche' semplifica il tuo codice
Non lo semplifica affatto, tant'e` che se devo gestire bytes singoli mi tocca contorcermi. Certo, l'espansione a 32 bit delle stringhe a quel punto lo semplifica, ma probabilmente non ho chiarito bene che si tratta di casi in cui si sa che le stringhe sono relativamente piccole e che vanno manipolate spesso. Una sorta di processo di "importazione" di una stringa a n bit nel "mondo a words" di L.in.oleum.
> e lo giustifichi con l'efficienza ma e` solo una razionalizzazione a posteriori che scarti tutte le volte che non ti fa comodo per giustificare la tua semplificazione.
Senz'altro mi piace l'idea di avere un solo tipo di dato, si`, ma ha dei vantaggi nelle manipolazioni frequenti di stringhe brevi, e d'altra parte secondo me tu stai ingigantendo il caso delle stringhe ASCII/UTF8 di lunghezza rilevante, che sono praticamente l'unico tipo di dato che verrebbe penalizzato dalla loro espansione e che spesso non dovrebbe essere espanso in primo luogo, a meno di processarle in maniera complessa (come in un text editor, ad esempio).
Per il resto, chiarisco che nessuno impedisce di tenerle in bytes e andarci di operazioni binarie su word intere: non mi stupirei se come per strlen di glib, probabilmente anche chi puo` leggere singoli bytes preferisca gestire words intere nei cicli. Ti faccio notare che la strlen che hai postato e` praticamente una smentita dei vantaggi dell'accesso byte per byte: accede word per word per essere efficiente, parallelizzando il trattamento di 4 byte per volta.
Va be', terro` presente, puo` darsi che cambi idea. La sintassi intel e` ben affermata, lo ammetto, pero` la trovo meno descrittiva di "p.-1" perche` assume che uno spiazzamento possa essere direttamente sottratto all'indirizzo di base, mentre in realta` e` aggiunto come valore negativo in complemento a due.
> Ci metterei anche delle parentesi quadre attorno.
Non mi conviene, le sto usando per definire array inline.
Cioe`:
x = [ 1, 2, 3 ]
carica "x" con l'indirizzo di un array statica contenente le words 1, 2, 3 (e poi zero, perche` per default e` null-terminated). Poi dovrei in qualche modo distinguere i casi.
> > Parlando di come funziona L.in.oleum, presuppongo che "allineato" significhi a una parola del processore.
>
> Allineato nel mondo normale significa che l'indirizzo e` un multiplo della dimensione.
Vabbe', se lo dici te... per me "allineato" senza "a cosa" era un errore di sintassi, al massimo sfruttabile per intendere "a una granularita` di default".
> > > Tutti questi vantaggi dell'indirizzare la memoria solo a multipli di 4 io non ce li vedo, il fatto che non io non conosca un assembly che ti obbliga a farlo e che il C allinei le strutture come le allinea mi suggerisce che questi supposti vantaggi non esistano.
> >
> > Intanto il codice che hai postato legge 4 bytes (una "unita`") per volta e "si contorce" per estrarre dal valore composto di 4 byte il primo byte a zero? Se come dicevi "dovesse essere leggibile", leggerebbe byte per byte.
>
> Il codice che ho postato io non e` fatto per essere leggibile, e` fatto per essere veloce. E non e` solo per via dell'allineamento ma anche perche' e` bit-parallelo.
Bit-che?
Legge 4 byte per volta, come fa la reimplementazione L.in.oleum.
E` parallelo tanto quanto lo e` la sua reimplementazione, qualunque cosa tu intendessi per bit-parallelo.
Non legge i singoli bytes per trovare il terminatore, processa intere words.
> Se dopo aver fatto il tuo bel load allineato ti devi andare a pescare i singoli byte a botte di shr e and e` molto piu` veloce e leggibile fare una lettura non allineata.
Leggibile magari si`, veloce no. In generale, se leggi un registro di 32 bit per operare sui bytes che contiene, fai un accesso parallelo di 4 bytes invece che seriale byte per byte.
mov eax, [esi] ; 1
add esi, 4
mov ebx, eax ; 1
mov ecx, eax
mov edx, eax ; 1
and eax, 0xFF
and ebx, 0xFF00 ; 1
and ecx, 0xFF0000
and edx, 0xFF000000 ; 1
shr ebx, 8 ; 1
shr ecx, 16 ; 1
shr edx, 24 ; 1
; 8
mov al, [esi] ; 2
mov bl, [esi + 1] ; 2
mov cl, [esi + 2] ; 2
mov dl, [esi + 3] ; 2
add esi, 4 ; 1
; 9
Certo a meno che uno debba leggere un byte solo, ma a quel punto di solito non fai un ciclo.
> > ARM era stata pensata per avere tutte istruzioni di una word (32 bit) per semplificare la decodifica e il fetching.
>
> http://infocenter.arm.com/help/index.jsp?topic=/co...
>
> LDRB e SDRB ci sono sempre stati.
Chissa` se sono penalizzati.
Gli Intel penalizzano gli accessi non allineati alla word del processore.
> > tre istruzioni in croce. Ok, ci saranno i ritardi di cache 4 volte piu` spesso che se la stringa fosse fatta di bytes,
>
> Hai detto niente!
Ma non intendo dire che quando operi su stringhe di caratteri allineati a una word, lo fai perche` la stringa e` colossale. Le converti a stringhe del genere quando devi manipolare frequentemente la stessa stringa, tipo splittarla o concatenarne frammenti. In generale, stai immaginando casi che secondo me sono molto rari, dove la performance dovuta alla specifica capacita` di leggere singoli bytes farebbe la differenza.
> > > Quindi secondo te il fatto che le istruzioni di jump siano piu` lunghe di qualche byte rispetto a quanto potrebbero essere e` piu` importante del fatto che tutte le stringhe siano 4 volte piu` lunghe di quanto potrebbero essere?
> >
> > La localita` del codice e` almeno altrettanto importante, ma probabilmente di piu`: quella si applica a tutto il codice, le stringhe di testo a 8 bit sono casi particolari. E` un difetto del compilatore abbozzato attuale, ma mi prometto di risolverlo in seguito.
>
> Secondo te cosa prende piu` spazio? Il codice o i dati?
E secondo te cosa viene letto piu` spesso, il codice o i dati?
> Secondo me a te piace il fatto che hai un solo tipo di dato perche' semplifica il tuo codice
Non lo semplifica affatto, tant'e` che se devo gestire bytes singoli mi tocca contorcermi. Certo, l'espansione a 32 bit delle stringhe a quel punto lo semplifica, ma probabilmente non ho chiarito bene che si tratta di casi in cui si sa che le stringhe sono relativamente piccole e che vanno manipolate spesso. Una sorta di processo di "importazione" di una stringa a n bit nel "mondo a words" di L.in.oleum.
> e lo giustifichi con l'efficienza ma e` solo una razionalizzazione a posteriori che scarti tutte le volte che non ti fa comodo per giustificare la tua semplificazione.
Senz'altro mi piace l'idea di avere un solo tipo di dato, si`, ma ha dei vantaggi nelle manipolazioni frequenti di stringhe brevi, e d'altra parte secondo me tu stai ingigantendo il caso delle stringhe ASCII/UTF8 di lunghezza rilevante, che sono praticamente l'unico tipo di dato che verrebbe penalizzato dalla loro espansione e che spesso non dovrebbe essere espanso in primo luogo, a meno di processarle in maniera complessa (come in un text editor, ad esempio).
Per il resto, chiarisco che nessuno impedisce di tenerle in bytes e andarci di operazioni binarie su word intere: non mi stupirei se come per strlen di glib, probabilmente anche chi puo` leggere singoli bytes preferisca gestire words intere nei cicli. Ti faccio notare che la strlen che hai postato e` praticamente una smentita dei vantaggi dell'accesso byte per byte: accede word per word per essere efficiente, parallelizzando il trattamento di 4 byte per volta.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 23:52:29.0 alle 2014-11-01 23:52:29.0
Trollate totali: 11540
> > > Lo studio delle 'sinapsi' del non-morto qui presente, riserva sempre lollose sorprese!
> >
> > argumentum ad hominem da manuale
> >
> > =>
> >
> > suorcazzata spalmata al tappeto
>
> Ehm, mi sa che siamo noi quelli che si sono fatti fregare. L'aspetto di losai.eu a prima vista non attiva campanelli d'allarme, sembra un sito come tanti ma leggendo qua e là si direbbe un sito ultracattolico.
Nella prima pagina parla di nuovo ordine mondiale e diossido di selenio nelle scie chimiche. MMMmah. Mi ricorda quei siti dove mio cugino pescava a ruota libera notizie sull'avvento di Ison che era grande come Urano e seguita dagli ufetti. Ah gia`, non ho poi controllato com'e` finita per quelli che avevano previsto l'inizio di una nuova era glaciale per il 2013... probabilmente avranno rimandato tutto al 2027.
Comunque, visto che parlavate di Attivissimo, lui propone un bel paio di cartelle per il toto-bufala sul numero di Le Scienze di questo mese, indicate proprio per mettere le mani avanti prima della smentita ufficiale.
> >
> > argumentum ad hominem da manuale
> >
> > =>
> >
> > suorcazzata spalmata al tappeto
>
> Ehm, mi sa che siamo noi quelli che si sono fatti fregare. L'aspetto di losai.eu
a prima vista non attiva campanelli d'allarme, sembra un sito come tanti ma leggendo qua e là si direbbe un sito ultracattolico.Nella prima pagina parla di nuovo ordine mondiale e diossido di selenio nelle scie chimiche. MMMmah. Mi ricorda quei siti dove mio cugino pescava a ruota libera notizie sull'avvento di Ison che era grande come Urano e seguita dagli ufetti. Ah gia`, non ho poi controllato com'e` finita per quelli che avevano previsto l'inizio di una nuova era glaciale per il 2013... probabilmente avranno rimandato tutto al 2027.
Comunque, visto che parlavate di Attivissimo, lui propone un bel paio di cartelle per il toto-bufala sul numero di Le Scienze di questo mese, indicate proprio per mettere le mani avanti prima della smentita ufficiale.
Trova Wakanda!
Ad
https://imgoat.com/uploads/edebb6e872/182095.jpg
Solo il 5% riesce a trovarla! Provaci anche tu!!
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 23:00:14.0 alle 2014-11-01 23:00:14.0
Trollate totali: 11540
> > > > > Buona serata.
> > > >
> > > > Meno male che c'è sassofono: magari fra le sue critiche salta anche fuori qualcosa di utile.
> > >
> > > Sshhh... e` per quello che posto la roba ogni tanto.
> > > Ma se glielo dici e` abbastanza dispettoso da non cacarmela piu`.
> >
> > ormai lo sa
>
> Azz, dovevo star zitto.
> Comunque mi ammutolisce vedere quante cose sa sassofono.
E` un tipo curioso e molto meticoloso. Mi ha un po' colpito il fatto che trovasse NECESSARIO capire perche`, qualora la famosa istruzione sbagliata fosse stata veramente una combinazione non valida di opcode e operandi, il sistema non avesse intercettato l'eccezione.
Comunque, e` un ganzo.
> > > >
> > > > Meno male che c'è sassofono: magari fra le sue critiche salta anche fuori qualcosa di utile.
> > >
> > > Sshhh... e` per quello che posto la roba ogni tanto.
> > > Ma se glielo dici e` abbastanza dispettoso da non cacarmela piu`.
> >
> > ormai lo sa
>
> Azz, dovevo star zitto.
> Comunque mi ammutolisce vedere quante cose sa sassofono.
E` un tipo curioso e molto meticoloso. Mi ha un po' colpito il fatto che trovasse NECESSARIO capire perche`, qualora la famosa istruzione sbagliata fosse stata veramente una combinazione non valida di opcode e operandi, il sistema non avesse intercettato l'eccezione.
Comunque, e` un ganzo.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 20:22:56.0 alle 2014-11-01 20:22:56.0
Trollate totali: 11540
> > 
http://www.ilmessaggero.it/MARCHE/ancona_web_repor...
> >
> >
> >
> >
> >
>
>
> Davvero pensava di poter entrare in una base militare, filmare tutto, sbatterlo su youtube e farla franca?
> È fortunato che non ha trovato qualcuno che gli ha sparato addosso.
Per essere eroico, e` eroico.
Mi ricorda un po' Green Hornet.
> >
> >
> >
> >
> >
>
>
> Davvero pensava di poter entrare in una base militare, filmare tutto, sbatterlo su youtube e farla franca?
> È fortunato che non ha trovato qualcuno che gli ha sparato addosso.
Per essere eroico, e` eroico.
Mi ricorda un po' Green Hornet.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 20:15:17.0 alle 2014-11-01 20:15:17.0
Trollate totali: 11540
> > Buona serata.
>
> Meno male che c'è sassofono: magari fra le sue critiche salta anche fuori qualcosa di utile.
Sshhh... e` per quello che posto la roba ogni tanto.
Ma se glielo dici e` abbastanza dispettoso da non cacarmela piu`.
>
> Meno male che c'è sassofono: magari fra le sue critiche salta anche fuori qualcosa di utile.
Sshhh... e` per quello che posto la roba ogni tanto.
Ma se glielo dici e` abbastanza dispettoso da non cacarmela piu`.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 15:17:58.0 alle 2014-11-01 15:17:58.0
Trollate totali: 11540
> > Il codice di strlen e` questo: http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/lib...
>
> p.s. comunque la tattica per trovare il terminatore confrontando 4 byte per volta e` carina, non la sapevo e ora la importo in text::FromByteString. Intanto, pero`, volevo farti notare che L.in.oleum, allineando tutto a word del processore, nel fare la stessa cosa per poter sfruttare confronti su 4 byte per volta, puo` saltare questo:
>
>
>
> Sei ancora convinto che tutti questi vantaggi non ci siano?
Ho reimplementato in L.in.oleum il ciclo word-per-word visto nella strlen di GCC: e` senz'altro un'ottima idea, per quanto renda il codice praticamente incomprensibile (per rendermi conto di cosa vagamente facesse, ieri sera, ci ho messo un quarto d'ora, per poi non capire come il resto dovesse convertire una stringa da 8 a 32 bit per carattere).
Ma vediamo il filmaggine sull'analisi di quanto efficiente sia il codice prodotto dal compilatore C versus quello ottimizzato a mente (seguendo regole di ottimizzazione multiscalare piuttosto generiche) da un opportuno hikikomori...
In conclusione, il codice C compilato e` efficiente nella scelta dell'algoritmo, che sicuramente e` piu` veloce che iterare su ogni byte (quello che i commenti di strlen definiscono "tradizionale"), ed e` una bella ottimizzazione fatta A MENTE da chi ha scritto quella versione di strlen. Il compilatore, pero`, a parte un'ottima strength reduction sulle righe successive, nel ciclo si caga abbastanza addosso. Buona serata.
>
> p.s. comunque la tattica per trovare il terminatore confrontando 4 byte per volta e` carina, non la sapevo e ora la importo in text::FromByteString. Intanto, pero`, volevo farti notare che L.in.oleum, allineando tutto a word del processore, nel fare la stessa cosa per poter sfruttare confronti su 4 byte per volta, puo` saltare questo:
>
>
> /* Handle the first few characters by reading one character at a time. > Do this until CHAR_PTR is aligned on a longword boundary. */ > for (char_ptr = str; ((unsigned long int) char_ptr > & (sizeof (longword) - 1)) != 0; > ++char_ptr) > if (*char_ptr == '\0') > return char_ptr - str; >
>
> Sei ancora convinto che tutti questi vantaggi non ci siano?
Ho reimplementato in L.in.oleum il ciclo word-per-word visto nella strlen di GCC: e` senz'altro un'ottima idea, per quanto renda il codice praticamente incomprensibile (per rendermi conto di cosa vagamente facesse, ieri sera, ci ho messo un quarto d'ora, per poi non capire come il resto dovesse convertire una stringa da 8 a 32 bit per carattere).
Ma vediamo il filmaggine sull'analisi di quanto efficiente sia il codice prodotto dal compilatore C versus quello ottimizzato a mente (seguendo regole di ottimizzazione multiscalare piuttosto generiche) da un opportuno hikikomori...
ByteString Length "monaural fn
PUSH.r ECX(m) --> m
PUSH.r EAX(n) --> n
PUSH.r EDX(p) --> p = r
MOV.rm,r EDX(p), ESI(r)
LOOP ENTRY do
MOV.r,rm EAX(n), [EDI(w)+4*ESI(r)] n = R
MOV.r,rm ECX(m), [EDI(w)+4*ESI(r)] m = R
SUB.ac,i EAX, 01010101 n - 01010101h
NOT.rm ECX(m) ! m
AND.rm,r EAX(n), ECX(m) n & m
ADD.rm,i ESI(r), 01 r + 1
TEST.ac,i EAX, 80808080 continue if n has no 80808080h
JZ 00000000 ; 00000277 (TBD)
AND.ac,i EAX, 80808080 n & 80808080h
LOOP EXIT end do (auto)
SUB.rm,i ESI(r), 01 r - 1
SUB.rm,r ESI(r), EDX(p) r - p
SHL.rm,i ESI(r), 02 r < log2 bytesPerUnit
TEST.ac,i EAX, FF000000 repeat if n has no firstByte
JNZ 00000000 ; fwrd
ROL.rm,i EAX(n), 08 n [ 8
ADD.rm,i ESI(r), 01 r + 1
TEST.ac,i EAX, FF000000 end repeat if (auto)
JZ 00000000 ; 000002AC (TBD)
POP.r EDX(p) <-- p
POP.r EAX(n) <-- n
POP.r ECX(m) <-- m
RET.near return
---------------------------------------------------------------------------------------------------
MOV.r,rm EAX(n), [EDI(w)+4*ESI(r)] 1 U
MOV.r,rm ECX(m), [EDI(w)+4*ESI(r)] 0 V (ovviamente cached)
SUB.ac,i EAX, 01010101 1 U
NOT.rm ECX(m) 0 V
AND.rm,r EAX(n), ECX(m) 1 U
ADD.rm,i ESI(r), 01 0 V
TEST.ac,i EAX, 80808080 1 U
JZ 00000000 ; 00000277 (TBD) 0 V (se predicted)
---
4 cicli/word
---------------------------------------------------------------------------------------------------
0x000000000040054e <+46>: mov ecx,DWORD PTR [rdx] 1 U
0x0000000000400550 <+48>: add rdx,0x4 0 V
0x0000000000400554 <+52>: lea eax,[rcx-0x1010101] 2 U (AGI* su RCX)
0x000000000040055a <+58>: not ecx 0 V
0x000000000040055c <+60>: and eax,ecx 1 U
0x000000000040055e <+62>: and eax,0x80808080 1 V (write after write su EAX)
0x0000000000400563 <+67>: je 0x40054e <main+46> 1 U (la pipe U non ha prediction)
---
6 cicli/word
*Address Generation Interlock, stallo della pipeline dovuto all'uso di LEA per fare MOV+SUB
In conclusione, il codice C compilato e` efficiente nella scelta dell'algoritmo, che sicuramente e` piu` veloce che iterare su ogni byte (quello che i commenti di strlen definiscono "tradizionale"), ed e` una bella ottimizzazione fatta A MENTE da chi ha scritto quella versione di strlen. Il compilatore, pero`, a parte un'ottima strength reduction sulle righe successive, nel ciclo si caga abbastanza addosso. Buona serata.
Vieni anche tu a scuola in Svezia!
Ad
https://www.breitbart.com/europe/2019/01/11/swedish-journalist-teachers-have-given-up-rising-school-violence/
Qui accettiamo qualunque tipo di animale! Non facciamo discriminazioni noi! Mica siamo razzisti!!!
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 13:37:09.0 alle 2014-11-01 13:37:09.0
Trollate totali: 11540
> Il codice di strlen e` questo: http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/lib...
p.s. comunque la tattica per trovare il terminatore confrontando 4 byte per volta e` carina, non la sapevo e ora la importo in text::FromByteString. Intanto, pero`, volevo farti notare che L.in.oleum, allineando tutto a word del processore, nel fare la stessa cosa per poter sfruttare confronti su 4 byte per volta, puo` saltare questo:
Sei ancora convinto che tutti questi vantaggi non ci siano?
p.s. comunque la tattica per trovare il terminatore confrontando 4 byte per volta e` carina, non la sapevo e ora la importo in text::FromByteString. Intanto, pero`, volevo farti notare che L.in.oleum, allineando tutto a word del processore, nel fare la stessa cosa per poter sfruttare confronti su 4 byte per volta, puo` saltare questo:
/* Handle the first few characters by reading one character at a time.
Do this until CHAR_PTR is aligned on a longword boundary. */
for (char_ptr = str; ((unsigned long int) char_ptr
& (sizeof (longword) - 1)) != 0;
++char_ptr)
if (*char_ptr == '\0')
return char_ptr - str;
Sei ancora convinto che tutti questi vantaggi non ci siano?
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 13:20:00.0 alle 2014-11-01 13:20:00.0
Trollate totali: 11540
> > > > ...di dubbia utilita`, io ne ho trovato uno utile nel gruppo di vitamine B. Ho fatto uno studio a doppio cieco con me stesso (mi sono cecato due volte) e ho verificato che non sembra un effetto placebo. Cioe` no vabbe', intendevo che ho provato a smettere e riprendere, e pare che quando non prendo la pasticca di Be-Total la mattina, verso sera mi deprimo. Al massimo un paio di sere dopo.
> > > >
> > > > L'avevo iniziato a prendere in un momento di debolezza fisica, poi ho notato che mi faceva da antidepressivo e ho continuato. Strano ma vero. Casomai provatelo. Il Be-Total ha la B6, la B12, la B3, quella roba li`, e anche una cosa che si chiama nicotinamide e il cui nome mi fa sospettare che abbia parecchio in comune con la nicotina, anche se non ci capisco un cazzo.
> > >
> > > Invece di usufruire delle ottime benzodiazepine che ti sono state prescritte ti perdi dietro alle vitamine.
> >
> > Quelle erano per quand'ero affetto da GAD, che poi e` mysteriosamente sparito, lasciando gradualmente il posto a una specie di malinconia pervasiva con punte di quasi-depressione. Certo, si puo` dire che quanto meno non mi annoio, ma insieme all'ansia era venuta a mancare l'entusiasmo d'inseguire inutili grandiosi progetti tipo l'Argent o L.in.oleum. Quella pasticchina sembra aver rimesso a posto le cose, per questo mi sento di consigliarla ai depressi del forum interessati a migliorare l'umore. In teoria sono vitamine che agiscono sul metabolismo: se ne avete solo meta`, magari vi fanno avere un bolismo intero e un effetto collaterale potrebbe essere quello di cambiare i nutrienti che arrivano anche al cervello... insomma sonasega™, qualcosa del genere.
> >
> > Le benzodiazepine non le consiglio a nessuno: calmano senz'altro, ma ci sono forti sospetti che influiscano permanentemente sulle capacita` intellettive... va bene, non sara` una gran perdita ma appunto per quello, vista la scarsita`, meglio non buttare via niente. E poi stando a wikipedia mi pare di capire che diano dipendenze con crisi d'astinenza peggiori di quelle da tabacco.
> >
> > La B12 m'era gia` capitato di prenderla in dosi massicce, sotto forma della famosa co-carnetina B12 a base di L-carnitene e B12, ma da sole quelle due robe non mi hanno mai fatto l'effetto dell'intero gruppo B. Siccome 'sta cosa della pasticchina va avanti da circa due mesi senza perdere colpi, comincio a sentirmi giustificato a pensare che funzioni davvero, almeno con me. Vi faro` sapere se smette di funzionare.
>
> M'incuriosisce, devo dire.
Casomai provale. Una al giorno male non fa. Non penso sia facile intossicarsi di vitamine, al limite e` il caso in cui tentar non nuoce.
> > > >
> > > > L'avevo iniziato a prendere in un momento di debolezza fisica, poi ho notato che mi faceva da antidepressivo e ho continuato. Strano ma vero. Casomai provatelo. Il Be-Total ha la B6, la B12, la B3, quella roba li`, e anche una cosa che si chiama nicotinamide e il cui nome mi fa sospettare che abbia parecchio in comune con la nicotina, anche se non ci capisco un cazzo.
> > >
> > > Invece di usufruire delle ottime benzodiazepine che ti sono state prescritte ti perdi dietro alle vitamine.
> >
> > Quelle erano per quand'ero affetto da GAD, che poi e` mysteriosamente sparito, lasciando gradualmente il posto a una specie di malinconia pervasiva con punte di quasi-depressione. Certo, si puo` dire che quanto meno non mi annoio, ma insieme all'ansia era venuta a mancare l'entusiasmo d'inseguire inutili grandiosi progetti tipo l'Argent o L.in.oleum. Quella pasticchina sembra aver rimesso a posto le cose, per questo mi sento di consigliarla ai depressi del forum interessati a migliorare l'umore. In teoria sono vitamine che agiscono sul metabolismo: se ne avete solo meta`, magari vi fanno avere un bolismo intero e un effetto collaterale potrebbe essere quello di cambiare i nutrienti che arrivano anche al cervello... insomma sonasega™, qualcosa del genere.
> >
> > Le benzodiazepine non le consiglio a nessuno: calmano senz'altro, ma ci sono forti sospetti che influiscano permanentemente sulle capacita` intellettive... va bene, non sara` una gran perdita ma appunto per quello, vista la scarsita`, meglio non buttare via niente. E poi stando a wikipedia mi pare di capire che diano dipendenze con crisi d'astinenza peggiori di quelle da tabacco.
> >
> > La B12 m'era gia` capitato di prenderla in dosi massicce, sotto forma della famosa co-carnetina B12 a base di L-carnitene e B12, ma da sole quelle due robe non mi hanno mai fatto l'effetto dell'intero gruppo B. Siccome 'sta cosa della pasticchina va avanti da circa due mesi senza perdere colpi, comincio a sentirmi giustificato a pensare che funzioni davvero, almeno con me. Vi faro` sapere se smette di funzionare.
>
> M'incuriosisce, devo dire.
Casomai provale. Una al giorno male non fa. Non penso sia facile intossicarsi di vitamine, al limite e` il caso in cui tentar non nuoce.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 13:06:53.0 alle 2014-11-01 13:06:53.0
Trollate totali: 11540
> > Comunque mi piace il nuovo schema:
> > - p significa il registro p
> > - P significa [p], indiretto con base p e spiazzamento zero
> > - p.1 significa [p+1]
> > - p.-1 significa [p-1]
> > - p.1.1 significa [p+1+1] cioe` [p+2]
> > - eccetera...
>
> Un capolavoro di inconsistenza.
Perche` la vedi come un'espressione in generale: e` un'indirezione ed e` composta da un registro e un'espressione il cui valore e` lo spiazzamento. In altre parole, non avrebbe senso scrivere:
p/5+1
Il punto serve a separare due cose diverse e secondo me rende piu` chiaro cosa si puo` scrivere dall'una e dall'altra parte, cosi` come la darebbe un registro fuori dalle quadre nella sintassi intel:
edx [1+1]
Comunque potrebbe non essere una cattiva idea quella di ricondurla a un'espressione normale, per poi emettere un errore se l'operatore che segue un registro non e` compatibile con un'indirezione, cioe` permettere p+1 ma lamentarsi per p/5. Che ne dici?
> > > Quindi se uno volesse accedere ad un file mmappato ti ci devi contorcere attorno?
> >
> > Be', se ci sono sequenze non allineate e vengono lette una volta sola, non ci sarebbe altro modo che contorcersi un po'. Riconosco che e` uno svantaggio, ma del resto indirizzare la memoria in unita` piuttosto che in bytes ha molti altri vantaggi.
>
> usi "allineato" in modo non-standard, una stringa di byte e` allineata a qualunque indirizzo, un in16 e` allineato a qualunque indirizzo divisibile per 2, &c.
Parlando di come funziona L.in.oleum, presuppongo che "allineato" significhi a una parola del processore.
> Tutti questi vantaggi dell'indirizzare la memoria solo a multipli di 4 io non ce li vedo, il fatto che non io non conosca un assembly che ti obbliga a farlo e che il C allinei le strutture come le allinea mi suggerisce che questi supposti vantaggi non esistano.
Intanto il codice che hai postato legge 4 bytes (una "unita`") per volta e "si contorce" per estrarre dal valore composto di 4 byte il primo byte a zero? Se come dicevi "dovesse essere leggibile", leggerebbe byte per byte. ARM era stata pensata per avere tutte istruzioni di una word (32 bit) per semplificare la decodifica e il fetching. IA-32 mantiene le istruzioni storiche come lodsb/scasb/stosb solo per retrocompatibilita`, ma non le definirebbe mai efficienti. Il C preferisce essere comodo e non introdurre una scelta radicale come fa L.in.oleum, ma un vettore di dati non allineati a words del processore e` comunque piu` complicato e inefficiente da gestire, e lo obbliga a contorcersi.
> > > Con "ammazzano" intendevo che se lo fai ti becchi un SIGBUS, AFAIK in amd64 ottieni un degradamento delle prestazioni e basta. BTW in ARM esistono anche LDRB/LDRH/STRB/STRH.
> >
> > Poi dici che non t'interessa l'assembly.
>
> Le architetture rilevanti saranno si e no una decina, non c'e` bisogno di essere interessati per avere una vaga familiarita`.
Ti vergogni, sei un timidone!
> > La prima sequenza fino al "je", esclusa la prima istruzione, e` un ciclo che rileva byte posti a zero in un buffer che comincia a rsp (suppongo sia qualcosa di locale sullo stack), poi c'e` qualcos'altro che include delle mov predicate ma che mi sembra incompleto: da nessuna parte si direbbero presenti delle istruzioni di write-back. Legge soltanto? Si puo` avere il sorgente che ha prodotto quel frammento?
>
> Certo:
>
>
>
>
Pff... pensavo tu avessi voluto postare un equivalente dell'intera routine di conversione da 8 a 32 bit per carattere. Ok, il ciclo che cercava la lunghezza della stringa l'avevo identificato e immagino fosse a quello che ti riferivi, ma e` l'unica parte in comune col codice L.in.oleum di cui si parlava.
> Il codice di strlen e` questo: http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/lib...
>
> Il loop e` una ricerca per il primo int32 contenente un byte a 0.
> La seconda parte e` un po' intricata ma con un po' di pazienza si capisce:
> - edx e` l'indirizzo del primo int32 dopo il primo int32 contenente un byte a 0 nella stringa
> - ebx contiene l'indirizzo della stringa (come anche rsp)
> - le istruzioni main+71, main+76 e main+116 sono irrilevanti, servono per configurare printf
> - il test a main+84 e le due successive cmove serve a decidere se il primo byte a 0 sta nei primi 2 byte o negli ultimi 2 byte
> - l'istruzione main+102 e` dove edx viene aggiustato per puntare esattamente all'ultimo byte
> - l'istruzione main+108 e` dove edx diventa la lunghezza della stringa.
Come vedi, si "contorce", legge words di 4 byte intere, e non byte per byte, e in effetti replica letture di 4 byte per volta. Ora posso farti vedere la ricerca della lunghezza di una stringa di 32 bit per carattere in L.in.oleum?
Le istruzioni nel sorgente sono:
In pratica, copia l'indirizzo della stringa (r) in p.
Poi fa un ciclo "each" vuoto, che va avanti per ogni R non zero.
Infine, sottrae p ad r per trovare la differenza, che e` la lunghezza.
Il ciclo vero e proprio, tolto il caso della stringa vuota, e`:
tre istruzioni in croce. Ok, ci saranno i ritardi di cache 4 volte piu` spesso che se la stringa fosse fatta di bytes, ma immagina come sarebbe piu` facile trattare i caratteri di una stringa in questo modo, manipolarli e trasformarli. A partire dal cercarne la lunghezza senza contorsioni.
> Quindi secondo te il fatto che le istruzioni di jump siano piu` lunghe di qualche byte rispetto a quanto potrebbero essere e` piu` importante del fatto che tutte le stringhe siano 4 volte piu` lunghe di quanto potrebbero essere?
La localita` del codice e` almeno altrettanto importante, ma probabilmente di piu`: quella si applica a tutto il codice, le stringhe di testo a 8 bit sono casi particolari. E` un difetto del compilatore abbozzato attuale, ma mi prometto di risolverlo in seguito.
> > - p significa il registro p
> > - P significa [p], indiretto con base p e spiazzamento zero
> > - p.1 significa [p+1]
> > - p.-1 significa [p-1]
> > - p.1.1 significa [p+1+1] cioe` [p+2]
> > - eccetera...
>
> Un capolavoro di inconsistenza.
Perche` la vedi come un'espressione in generale: e` un'indirezione ed e` composta da un registro e un'espressione il cui valore e` lo spiazzamento. In altre parole, non avrebbe senso scrivere:
p/5+1
Il punto serve a separare due cose diverse e secondo me rende piu` chiaro cosa si puo` scrivere dall'una e dall'altra parte, cosi` come la darebbe un registro fuori dalle quadre nella sintassi intel:
edx [1+1]
Comunque potrebbe non essere una cattiva idea quella di ricondurla a un'espressione normale, per poi emettere un errore se l'operatore che segue un registro non e` compatibile con un'indirezione, cioe` permettere p+1 ma lamentarsi per p/5. Che ne dici?
> > > Quindi se uno volesse accedere ad un file mmappato ti ci devi contorcere attorno?
> >
> > Be', se ci sono sequenze non allineate e vengono lette una volta sola, non ci sarebbe altro modo che contorcersi un po'. Riconosco che e` uno svantaggio, ma del resto indirizzare la memoria in unita` piuttosto che in bytes ha molti altri vantaggi.
>
> usi "allineato" in modo non-standard, una stringa di byte e` allineata a qualunque indirizzo, un in16 e` allineato a qualunque indirizzo divisibile per 2, &c.
Parlando di come funziona L.in.oleum, presuppongo che "allineato" significhi a una parola del processore.
> Tutti questi vantaggi dell'indirizzare la memoria solo a multipli di 4 io non ce li vedo, il fatto che non io non conosca un assembly che ti obbliga a farlo e che il C allinei le strutture come le allinea mi suggerisce che questi supposti vantaggi non esistano.
Intanto il codice che hai postato legge 4 bytes (una "unita`") per volta e "si contorce" per estrarre dal valore composto di 4 byte il primo byte a zero? Se come dicevi "dovesse essere leggibile", leggerebbe byte per byte. ARM era stata pensata per avere tutte istruzioni di una word (32 bit) per semplificare la decodifica e il fetching. IA-32 mantiene le istruzioni storiche come lodsb/scasb/stosb solo per retrocompatibilita`, ma non le definirebbe mai efficienti. Il C preferisce essere comodo e non introdurre una scelta radicale come fa L.in.oleum, ma un vettore di dati non allineati a words del processore e` comunque piu` complicato e inefficiente da gestire, e lo obbliga a contorcersi.
> > > Con "ammazzano" intendevo che se lo fai ti becchi un SIGBUS, AFAIK in amd64 ottieni un degradamento delle prestazioni e basta. BTW in ARM esistono anche LDRB/LDRH/STRB/STRH.
> >
> > Poi dici che non t'interessa l'assembly.
>
> Le architetture rilevanti saranno si e no una decina, non c'e` bisogno di essere interessati per avere una vaga familiarita`.
Ti vergogni, sei un timidone!
> > La prima sequenza fino al "je", esclusa la prima istruzione, e` un ciclo che rileva byte posti a zero in un buffer che comincia a rsp (suppongo sia qualcosa di locale sullo stack), poi c'e` qualcos'altro che include delle mov predicate ma che mi sembra incompleto: da nessuna parte si direbbero presenti delle istruzioni di write-back. Legge soltanto? Si puo` avere il sorgente che ha prodotto quel frammento?
>
> Certo:
>
>
> #include <stdio.h>
> #include <string.h>
>
> int main(int argc, char *argv[]) {
> int i;
> char blah[256];
> gets(blah);
> i = strlen(blah);
> printf("%d\n", i);
> return 0;
> }
> >
>
Pff... pensavo tu avessi voluto postare un equivalente dell'intera routine di conversione da 8 a 32 bit per carattere. Ok, il ciclo che cercava la lunghezza della stringa l'avevo identificato e immagino fosse a quello che ti riferivi, ma e` l'unica parte in comune col codice L.in.oleum di cui si parlava.
> Il codice di strlen e` questo: http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/lib...
>
> Il loop e` una ricerca per il primo int32 contenente un byte a 0.
> La seconda parte e` un po' intricata ma con un po' di pazienza si capisce:
> - edx e` l'indirizzo del primo int32 dopo il primo int32 contenente un byte a 0 nella stringa
> - ebx contiene l'indirizzo della stringa (come anche rsp)
> - le istruzioni main+71, main+76 e main+116 sono irrilevanti, servono per configurare printf
> - il test a main+84 e le due successive cmove serve a decidere se il primo byte a 0 sta nei primi 2 byte o negli ultimi 2 byte
> - l'istruzione main+102 e` dove edx viene aggiustato per puntare esattamente all'ultimo byte
> - l'istruzione main+108 e` dove edx diventa la lunghezza della stringa.
Come vedi, si "contorce", legge words di 4 byte intere, e non byte per byte, e in effetti replica letture di 4 byte per volta. Ora posso farti vedere la ricerca della lunghezza di una stringa di 32 bit per carattere in L.in.oleum?
00000273 89F2 MOV.rm,r EDX(p), ESI(r) 00000275 833CB700 CMP.rm,i [EDI(w)+4*ESI(r)], 00 00000279 0F840E000000 JE 0000000E ; 0000028D 0000027F 837CB70400 CMP.rm,i [EDI(w)+4*ESI(r)+04], 00 00000284 8D7601 LEA.r,m ESI(r), [ESI(r)+1] 00000287 0F85F2FFFFFF JNE FFFFFFF2 ; 0000027F 0000028D 29D6 SUB.rm,r ESI(r), EDX(p)
Le istruzioni nel sorgente sono:
p = r each R r - p
In pratica, copia l'indirizzo della stringa (r) in p.
Poi fa un ciclo "each" vuoto, che va avanti per ogni R non zero.
Infine, sottrae p ad r per trovare la differenza, che e` la lunghezza.
Il ciclo vero e proprio, tolto il caso della stringa vuota, e`:
0000027F 837CB70400 CMP.rm,i [EDI(w)+4*ESI(r)+04], 00 00000284 8D7601 LEA.r,m ESI(r), [ESI(r)+1] 00000287 0F85F2FFFFFF JNE FFFFFFF2 ; 0000027F
tre istruzioni in croce. Ok, ci saranno i ritardi di cache 4 volte piu` spesso che se la stringa fosse fatta di bytes, ma immagina come sarebbe piu` facile trattare i caratteri di una stringa in questo modo, manipolarli e trasformarli. A partire dal cercarne la lunghezza senza contorsioni.
> Quindi secondo te il fatto che le istruzioni di jump siano piu` lunghe di qualche byte rispetto a quanto potrebbero essere e` piu` importante del fatto che tutte le stringhe siano 4 volte piu` lunghe di quanto potrebbero essere?
La localita` del codice e` almeno altrettanto importante, ma probabilmente di piu`: quella si applica a tutto il codice, le stringhe di testo a 8 bit sono casi particolari. E` un difetto del compilatore abbozzato attuale, ma mi prometto di risolverlo in seguito.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 02:25:52.0 alle 2014-11-01 02:25:52.0
Trollate totali: 11540
MA checcazzo ne so
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 01:22:08.0 alle 2014-11-01 01:22:08.0
Trollate totali: 11540
> perché non fare anche un Natale-bis e una Pasqua-bis
Io sono ancora per lo spostare il natale al 25 giugno.
E il carnevale a luglio.
Io sono ancora per lo spostare il natale al 25 giugno.
E il carnevale a luglio.
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 01:13:36.0 alle 2014-11-01 01:13:36.0
Trollate totali: 11540
☺
Scritto da
altg
utente che non utiene
il 2014-11-01 01:09:15.0 alle 2014-11-01 01:09:15.0
Trollate totali: 11540