dead

[legacy]

• 

dead

[cdimauro]

• 

Vai su LLVM, che ti sbrighi molto prima. Non sarà mai il massimo per ottimizzare il codice a causa della sua struttura, ma genera comunque un buon codice.

[cdimauro]

• 

Ma a te per quale architettura serve? Perché al limite c'è pure vbcc: http://www.compilers.de/vbcc.html

[cdimauro]

• 

Se vuoi fare tutto a mano, per multitarget ti serve solo fare un pass aggiuntivo ed implementare una AST da traversare durante il codegen, con la possibilità di selezionare più di una architettura.

LLVM è buono e va scelto, senza troppe paranoie sulle ottimizzazioni del codice (la vera ottimizzazione si fa sull'algoritmo, il codice asm generato è solo un aspetto secondario)

Non è secondario, te lo posso assicurare. Ho avuto un manager che ha lavorato per anni al compilatore Intel, e che conosce anche LLVM (e i limiti che ha).

LLVM è troppo a compartimenti stagni; per cui è progettato molto bene a livello di interfacce fra i moduli, ma questo è anche il suo limite, perché alcune sezioni non riescono a ottenere tutte le informazioni che servono per generare codice migliore.

Quindi va benissimo per implementare nuove architetture, e il codice che genera è abbastanza buono. Ma per avere di più a livello prestazionale bisogna ricorrere ad altro.

[cdimauro]

• 

Ma a te per quale architettura serve?

immaginaria, ovvero che non esiste, definita su carta e penna ed implementata su simulatore, e' molto simile ad un MIPS (di cui LCC ha un machine description), un pelo + amichevole e con 8 byte fissi per ogni opcode.

Vai su LLVM a occhi chiusi.

[cdimauro]

• 

Il link mi pare troppo semplice e un po' datato, ma dovrebbe almeno rendere l'idea.

[cdimauro]

• 

Non è secondario, te lo posso assicurare.

Non è secondario l'ottimizzazione del codice o il fatto che non si possa ottimizzare ancora di più il codice?

La seconda che hai detto.

Comunque dipende di che ottimizzazioni stiamo parlando (che poi sarebbe meglio chiamare code improvements, dato che l'ottimizzazione dovrebbe essere il punto di massimo). Gran parte delle ottimizzazioni sono correzioni di codice, in cui basterebbe un warning che c'è del codice merda (tipo loop invariant code motion, etc).

Ciò che importa è il register allocation, instruction scheduling e l'addressing. Che venga fatto bene in un backend multitarget dipende molto da come si descrive la macchina e da come si genera il codice di template.

I compilatori non sono il mio campo, per cui non ti so dire altro.

Quindi va benissimo per implementare nuove architetture, e il codice che genera è abbastanza buono. Ma per avere di più a livello bisogna ricorrere ad altro.

Di più quanto? Bisogna anche valutare il livello di complexity che si raggiunge lato compilatore (per un guadagno di quanto?), in ambito scientifico un modulo scheduling è sufficiente.

Gaius Mulley per GNU Modula-2 (GCC-based) ha impiegato 12 anni e non è ancora molto production ready (ma utilizzabile)

Il mio (ex) manager mi ha fatto capire che ovviamente la complessità del compilatore aumenta, ma che le differenze nella qualità del codice generato ci sono.

Non abbiamo parlato di numeri ed esempi. Ti riporto soltanto quello che ci siamo detti in una delle piacevolissime chiacchierate che facevamo.

[cdimauro]

• 

Sto ripescando un mio vecchio progetto che emulava 68000 anche se non lo avevo completato, sopratutto mancano istruzioni e modalità di indizzamento
cmq quanto implementato e' stato sufficiente per eseguire piccoli programmi compilati da gcc-68k ed caricati come binari

Codice: [Seleziona]


mon> help
Simulator Commands:

 help [<cmd>]             Print detailed help about command <cmd>
 exit                     Exit simulator
 md [<addr>] [<addr>]     Memory display
 mf <addr> <addr> <val>   Memory fill
 rd                       Register display
 rm <reg> <val>           Register modify
 ld <app.bin>             Load Binary App
 go [<cnt>]               Execute <cnt> instructions
 tr [<cnt>]               Execute <cnt> instructions with tracing
 rst                      reset the system

mon> ld app.bin 1000
loaded at 1000, done

mon> md 1000
001000 :  13 fc 00 68 00 fe 50 00 13 fc 00 41 00 fe 50 00
001010 :  13 fc 00 6c 00 fe 50 00 13 fc 00 6c 00 fe 50 00
001020 :  13 fc 00 6f 00 fe 50 00 60 00 00 02 46 fc 27 00
001030 :  70 68 13 c0 00 fe 50 00 2e 7c 20 04 ff f0 2e 7c
001040 :  20 04 ff f0 60 00 00 02 46 fc 27 00 2e 7c 00 00
001050 :  20 00 45 f9 00 00 11 6d 4e ba 00 76 4e ba 00 5c
001060 :  4e 71 4e 71 45 f9 00 00 11 3d 4e ba 00 64 14 38
001070 :  00 0f 4e ba 00 70 45 f9 00 00 11 6d 4e ba 00 52
001080 :  4e ba 00 38 45 f9 00 00 11 7e 4e ba 00 44 60 00
001090 :  00 12 4e ba 00 5e 4e ba 00 62 0c 00 00 67 66 00
0010a0 :  ff f2 45 f9 00 00 11 5b 4e ba 00 26 4e 71 45 f9
0010b0 :  00 00 11 04 4e ba 00 1a 4a fc 4e 71 4e 75 61 00
0010c0 :  00 32 0c 00 00 67 66 00 ff f2 61 00 00 2e 4e 75
0010d0 :  10 1a 0c 00 00 10 67 00 00 0a 4e ba 00 1e 4e fa
0010e0 :  ff f0 4e 75 4e 71 4e 71 4e 71 4e 71 5b ca ff f6
0010f0 :  4e 75 30 39 00 fe 50 00 4e 75 13 c0 00 fe 50 00

mon> rm pc 1000
CPU.PC=1000

mon> go
hAllo
waiting for key pressed
hAllo world again, this is me
if you see this line
it means the App is running
on a pretty emulated system
- kill down
app has been forced to exit with 4AFC
returning to mon

mon> rm pc 1000
CPU.PC=0x1000

mon> tr 5
00001000: 13fc move.b  #68,00fe5000.lh
00001008: 13fc move.b  #41,00fe5000.lA
00001010: 13fc move.b  #6c,00fe5000.ll
00001018: 13fc move.b  #6c,00fe5000.ll
00001020: 13fc move.b  #6f,00fe5000.lo

mon> exit
byebye


Ripesco quel progetto, rimuovo il modulo 68000, ed aggiungo la pepita-machine, così si chiama questo accrocchio bovino dalla ISA immaginaria e super semplificata, il tutto perché torna comoda l'impalcatura del simulatore per le periferiche e per l'interfaccia del mon.

Va finito anche il compilatore asm, adesso sto giocano con gli opcode generati a manina, finito l'as si passa al cc, e qui … boh, vedo un po' che si riesce a fare con LLVM, quel link non sembra essere troppo incasinato, pero' … gentoo dai suoi repo fa una fatica bestia a compilare llvm per MIPS nativo (host=target=mips)  il che non mi lascia troppo tranquillo, ovvero … ci sarà sicuramente di aspettarsi qualche sorpresa, soprattutto dai repo git.

In effetti potresti partire da un backend esistente e modificarlo. Ti verrà sicuramente più facile che rifarti tutto da zero, partendo da quella guida.

Mi raccomando: riporta qui i risultati!

[Z80Fan]

• 

Vai su LLVM, che ti sbrighi molto prima. Non sarà mai il massimo per ottimizzare il codice a causa della sua struttura, ma genera comunque un buon codice.

Clang+LLVM (col backend x86 in particolare) è uno dei migliori compilatori che esista: in prestazioni del codice generato è pari o migliore di GCC (ci sono migliaia di test comparativi su Phoronix), nonostante sia molto più giovane e molto meglio fatto (basta solo vedere il numero di linee: 2.5M vs 6M).
In più ha un'evoluzione spaventosa grazie al supporto di aziende come Apple (che è stata la creatrice del progetto), Sony (che ha deciso di usarlo nella toolkit della PS4 al posto di GCC, con gran ringraziamenti degli sviluppatori sopratutto a causa dei migliori messaggi di diagnostica) e AMD (per l'architettura R600 delle GPU).
Ci sono pochi test contro VC++, però sia da esperimenti miei sia alcuni posti trovati qui e là su Internet, è quasi sempre migliore.

Sulla velocità di compilazione non c'è storia: Clang è il compilatore più veloce che esista. Da non dimenticare, l'eccellente supporto agli standard dei linguaggi: Clang 3.4 supporta addirittura le feature di C++14, standard che dovrebbe essere rilasciato questo anno (ma conoscendo la commissione non uscirà prima del 2018 )

Ovviamente, la Intel ha il compilatore migliore... sui suoi processori però, perchè sia supporta solo quella architettura (o quelle due, x86 e x86_64), sia perchè loro sanno perfettamente le prestazioni di ogni singola istruzione con magari dettagli che non sono rilasciati pubblicamente. Se infatti fai girare un programma compilato con ICC su un processore AMD, le prestazioni sono paragonabili a quelle degli altri compilatori se non inferiori, dato che deve scegliere il path generico non ottimizzato.

Ora non mi ricordo bene come funzionasse, ma da qualche tempo hanno aggiunto in LLVM un sistema che permette di specificare il "peso" di ogni istruzione, in modo che il generatore di codice potesse scegliere la combinazione di istruzioni migliore, e il target x86 a quel tempo era l'unico ad avere informazioni dettagliate sul target. Purtroppo non ricordo come si chiama questo modulo e non riesco a ritrovarlo.

Che porta a chiedersi how to write an LLVM backend ?

http://llvm.org/releases/3.4/docs/WritingAnLLVMBackend.html [versione 3.4, l'ultimissima]
e non sono d'accordo che LLVM abbia poca documentazione:
http://llvm.org/releases/3.4/docs/index.html

Io dico: prima ci si legge quella guida (che tra l'altro fa esempi con il backend Sparc), poi dare un'occhiata a un backend già implementato (uno di qualche RISC che sarà più semplice), e poi provare a mettere giù quello personalizzato. Ovviamente per quel tempo si dovrebbe avere ISA, simulatore e assembler già fatti, finiti e finalizzati.

Non so poi cosa hanno nei repository Gentoo, però quando ho compilato LLVM 3.2 da git ufficiale non ho avuto nessun problema, si è compilato senza lamentarsi (con tutti i target abilitati). Più che altro assicurati di avere abbastanza spazio libero su disco, perchè durante il processo vengono generati molti file intermedi.

[cdimauro]

• 

Sono assolutamente d'accordo, anche con quanto scritto da Z80Fan, e infatti se dovessi scegliere un compilatore per un mio progetto mi butterei su LLVM a occhio, proprio per quanto detto.

A me piace molto ottimizzare il codice quando lavoro a basso livello, SE non mi porta via tempo, per cui ho sempre questo pallino in testa (complice il mio background). Ma di perderci tempo appositamente no, non ne ho proprio. Se la prima versione che produco è "good enogh", non vado oltre (a parte forse nel rifattorizzare il codice).

@Z80Fan: sì, parlavamo proprio del compilatore Intel. E dietro c'è gente che fa veramente paura (con alcuni sono in contatto, per alcune questioni di lavoro).

[Z80Fan]

• 

non ne ha poca, ne ha troppa, tutta online, ovvero e non c'e' un book che fa un riassunto comodo come per LCC.

Il problema opposto quindi.
Guarda, io la avevo letta a tempo perso molto tempo fa quella guida, e secondo me spiega bene i passaggi da fare; se non ti piace leggere sullo schermo, puoi stamparla su carta (non è troppo lunga), oppure leggerla su un e-reader.

Secondo me imparare l'architettura LLVM piuttosto che qualcosa di vecchio come LCC ti permette sia di conoscere una moderna architettura di compilatore, sia di avere conoscenza sul potenzialmente più diffuso compilatore nel futuro (molti progetti stanno passando da GCC a Clang, ad esempio FreeBSD).

Anche a me non ha dato rogne per host=target=linux/x86, pero' me ne ha date e non poche per host=target=linux/mips.

Ah ho capito, tu vuoi compilarlo per farlo girare su MIPS.
La prima domanda è: perchè vuoi farti male?
Seconda: ti da problemi a compilare proprio Clang+LLVM, o ti da problemi il compilatore già compilato per compilare nuovi programmi? Se è il secondo caso, stai attento che devi avere anche la toolchain GNU installata, perchè il progetto LLVM ancora manca di alcuni programmi essenziali, in particolare il linker.
Se invece è il primo caso, puoi provare a partire da QUESTO link, e se ancora non riesci metti il problema qua sul forum che insieme probabilmente riusciamo a risolverlo.

Io ti consiglio di compilare Clang+LLVM per x86, e poi da questo ricompilare se stesso per MIPS, invece di compilarlo con GCC direttamente dal dispositivo MIPS.

[TheKaneB]

• 

@Z80Fan: Il devkit PS3 ti consentiva di scegliere tra GCC e SNC ( http://www.snsys.com/products/snc.asp ). GCC era molto lento e non ottimizzava molto (parlo comunque di una vecchia versione customizzata per Sony), mentre SNC ci metteva la metà del tempo o meno a compilare lo stesso progetto e ottimizzava meglio. Parliamo di progetti grossi che impiegavano circa 30-40 minuti su GCC, usando una macchina Core Duo Quad Q6600 (mitico processore!) che era molto potente per il periodo.

Se sono passati a LLVM tanto di guadagnato, perché anche SNC aveva le sue rogne, specialmente con alcune caratteristiche più avanzate del C++ che divergevano leggermente dallo standard (molto ferreo invece con GCC).

PS: Non so se quest'info è roba da NDA, in tal caso presto ci sarà la Yakuza a casa mia...

[Z80Fan]

• 

Se sono passati a LLVM tanto di guadagnato, perché anche SNC aveva le sue rogne, specialmente con alcune caratteristiche più avanzate del C++ che divergevano leggermente dallo standard (molto ferreo invece con GCC).

Info ufficiali di Sony:
http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain.pdf [PDF]

[TheKaneB]

• 

Se sono passati a LLVM tanto di guadagnato, perché anche SNC aveva le sue rogne, specialmente con alcune caratteristiche più avanzate del C++ che divergevano leggermente dallo standard (molto ferreo invece con GCC).

Info ufficiali di Sony:
http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain.pdf [PDF]

Dalle slide vedo che usano ancora SN-DBS per le build distribuite. Quindi immagino che sia la stessa SN-Systems (quella di SNC) ad aver sviluppato la toolchain CLang-LLVM per PS4.

[TheKaneB]

• 

noto anche che le cose che ho detto sono incluse in quelle slide, quindi la NDA è ancora integra... la mia testa è salva