dead

[cdimauro]

• 

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.

Ecco, questa è la fregatura: ti serve anche un assembler. Pensavo bastasse descrivere l'architettura, con tanto di opcode, e poi sarebbe stato il backend di LLVM a generare direttamente il codice binario...

[cdimauro]

• 

Io avevo un'altra idea. Peccato. Mi sarebbe piaciuto descrivere l'ISA, e poi ottenere il binario. Ma tutto questo lavoro per un esperimento non lo faccio, anche perché passare da gas per assemblare non mi alletta di certo...

[cdimauro]

• 

A me interessava esclusivamente generare il binario, e generare delle statistiche sulla lunghezza del codice e delle istruzioni emesse.

[cdimauro]

• 

La mia ISA è più complicata più di x64 + Larrabee (Xeon Phi) + 68K messi assieme. Per cui... rinuncio.

[cdimauro]

• 

Avevo una mezza idea, ma esclusivamente per ricerche personali in materia di ISA.

E mi serviva LLVM perché è in grado di compilare parecchi progetti ormai, per cui potevo generare statistiche per tutte le ISA che supporta (che poi sono quelle più interessanti), e tirare fuori i numeri che mi servono.

[cdimauro]

• 

Come puoi intuire, la mia è lunghezza variabile, con opcode anche ben più lunghi dei tuoi 8 byte, ma nonostante tutto è molto facile da decodificare (penso ai livelli di una Thumb-2) e... con una densità di codice comparabile a x86.
Però è complicata a livello di opcode: tanteeeee modalità d'indirizzamento, e centinaia e centinaia di istruzioni.

Ecco perché di scrivere anche un assemblatore non se ne parla: perderei una quantità immane di tempo. Anzi, impiegherei già un casino soltanto per implementare l'emitter per il codice binario, e mi sarei volentieri fermato qui. Anzi, non comincio neppure a queste condizioni.

[cdimauro]

• 

Beh, ne hai modalità d'indirizzamento complicatucce, ma per il resto mi sembra un'ISA molto semplice. Immagino che tu l'abbia pensata per essere sintetizzata velocemente su FPGA, e per occupare poche LE.

La mia ha ben altri obiettivi. Anzi, correggo quanto scritto sopra: è una sorta di x86 + Larrabee + 68K + ARM32/64.

Adesso però mi fiondo a letto. Domani si lavora...

[Z80Fan]

• 

Ecco, questa è la fregatura: ti serve anche un assembler. Pensavo bastasse descrivere l'architettura, con tanto di opcode, e poi sarebbe stato il backend di LLVM a generare direttamente il codice binario...

A me interessava esclusivamente generare il binario, e generare delle statistiche sulla lunghezza del codice e delle istruzioni emesse.

Ah ecco, tu hai un'esigenza diversa: io avevo già considerato che, nel progettare una nuova architettura, si avesse già il simulatore e un assembler pronti.

Però con LLVM puoi anche fare da assemblatore, e disassemblatore addirittura; ovviamente nella creazione del backend prima arrivi a un punto dove puoi mostrare l'assembly (anche per testare il backend), e poi quando è corretto passi a scrivere il generatore di binario (cioè aggiungere quelle classi che servono).

Prova a dare una letta a questa guida:
http://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html

Cmq x86 (e forse ARM, ma non sono sicuro) è un'architettura che sfrutta la generazione codice diretta senza assembly intermedio, quindi se hai dubbi nell'implementazione puoi controllare quella.

Per questa fase va bene così, tanto lavoro in asm su un solo file alla volta che posso spezzare in file .inc da includere sfruttando #include "file.inc" esattamente come si fa in C, pero' supportare il formato obj sarà una feature da aggiungere appena possibile, in questo modo avrò una toolchain funzionante nel modo giusto

C to asm -> asm to obj -> all obj  to bin

Con LLVM puoi fare anche una cosa più simpatica: invece di generare vari file oggetto e poi unirli insieme con un linker, puoi fare così:

C to .bc -> all .bc to .bc -> final .bc to bin

Praticamente puoi dire a Clang di compilare il tuo C in LLVM IR (".bc", il linguaggio intermedio di LLVM), poi prendi tutti i .bc generati e con llvm-link li riduci in un file .bc singolo, fai passare questo .bc attraverso opt (passaggio opzionale, ma così opt fa un altro giro di ottimizzazioni che non fa male) e infine fai "compilare" il .bc in assembly o in codice oggetto da llc.

Praticamente è come una poor man's LTO, però secondo me è molto efficace e molto interessante come concetto, sicuramente superiore dal dover scrivere linker complessi che elaborano il codice macchina binario; un'altra dimostrazione dei vantaggi dell'IR.

[cdimauro]

• 

Come puoi intuire, la mia è lunghezza variabile, con opcode anche ben più lunghi dei tuoi 8 byte, ma nonostante tutto è molto facile da decodificare

no, per me e' un casino da gestire in quel modo, ho fatto molta fatica a scrivere il decode del 68000 nel relativo simulatore e me la sono cavata solo grazie a tecniche di maschera, se analizzi il decoder di un MIPS e' gestito a classi che fissano modelli di pattern ed in quei pattern fanno decodificano cose che sono messe sempre nello stesso modo ed interpretate sempre nello stesso modo, introdurre eccezioni significa in HDL introdurre fsm, il che imputtana tutto il progetto, a cominciare dai vettori di test.

difatti mi chiedo come facciano in intel, a me viene il mal di testa gia' con la mia CPU bovina che e' sempliciotta, la loro … richiede molto + mind power

Anche volendo, non glielo posso chiedere. Sarà qualche trade secret.

Comunque a dispetto della complessità, la mia ISA è di gran lunga più semplice da decodificare, con dei pattern precisi.

[cdimauro]

• 

Ecco, questa è la fregatura: ti serve anche un assembler. Pensavo bastasse descrivere l'architettura, con tanto di opcode, e poi sarebbe stato il backend di LLVM a generare direttamente il codice binario...

A me interessava esclusivamente generare il binario, e generare delle statistiche sulla lunghezza del codice e delle istruzioni emesse.

Ah ecco, tu hai un'esigenza diversa: io avevo già considerato che, nel progettare una nuova architettura, si avesse già il simulatore e un assembler pronti.

Però con LLVM puoi anche fare da assemblatore, e disassemblatore addirittura; ovviamente nella creazione del backend prima arrivi a un punto dove puoi mostrare l'assembly (anche per testare il backend), e poi quando è corretto passi a scrivere il generatore di binario (cioè aggiungere quelle classi che servono).

Prova a dare una letta a questa guida:
http://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html

Cmq x86 (e forse ARM, ma non sono sicuro) è un'architettura che sfrutta la generazione codice diretta senza assembly intermedio, quindi se hai dubbi nell'implementazione puoi controllare quella.

Ottimo. E' proprio quello che mi serve. Ma devo dare per forza un'occhiata anche a 68K e ARM, perché nella mia ISA ci sono diversi elementi che sono simili, e vorrei vedere un po' come le hanno implementate. Poi mi manca Xeon Phi, ma è l'ultimo dei miei pensieri.

Comunque è prematuro guardare a LLVM. Prima ho altro da fare. Ma appena posso un'occhiata al link gliela do. Grazie.

[cdimauro]

• 

Modalita' di indirizzamento che posso usare introducendo pero' cicli di calcolo dovute alle ALU dei EA
-(rn) -> NON IMPLEMENTABILE
r1(r2) -> EA = reg[r1] * reg[r2]
r1(r2) r3 -> EA = (reg[r1] * reg[r2]) + r3

Cmq queste sono tentato dal NON implementarle per il motivo che rompono la regolare cadenza con cui vengono scanditi gli opcode in termini di cicli macchina, oltre al fatto che costano delle EA ALU addizionali e quindi + roba da fare testare etc.

Però quelle ALU addizionali sono comode per migliorare le prestazioni.

L'effetto collaterale della BRA invece me lo tengo perché mi piace parecchio 

Ehm, quale sarebbe? Non me lo ricordo adesso.

[TheKaneB]

• 

Comunque giusto per cronaca, qui si parla quasi di necessità di un codice intermedio per il multitarget, ma in realtà è uno step che si può saltare. Ciò che serve veramente è una AST e poi da quella si genera codice reale. Questo implica riscrivere un backend da zero per ogni architettura (oppure appoggiandosi ad uno esistente spesso duplicando codice), questa soluzione in genere è la migliore per avere il massimo della libertà per lo sfruttamento delle potenzialità di una architettura e per non perdere tempo sullo translate da codice intermedio astratto a codice reale. L'instruction selection comporta un sacco di compromessi nelle scelte

Vero. Forse si usa molto la tecnica del linguaggio intermedio per modularizzare più facilmente il progetto e renderlo così più mantenibile da team separati? Anche se, in effetti, non vedo quale sarebbe il problema nell'esportare direttamente l'AST, anche in forma serializzata (XML?) se necessario.

[TheKaneB]

• 

In parte sì, ma io intendo una serializzazione vera e propria di tutto l'albero, cioè la messa su file dell'intera struttura dati invariata. Probabilmente andando nel pratico conviene di più quel metodo, visto che tutti i maggiori compilatori si sono stabilizzati su questo metodo.

[Z80Fan]

• 

In parte sì, ma io intendo una serializzazione vera e propria di tutto l'albero, cioè la messa su file dell'intera struttura dati invariata. Probabilmente andando nel pratico conviene di più quel metodo, visto che tutti i maggiori compilatori si sono stabilizzati su questo metodo.

Probabilmente è più semplice da elaborare,. Cmq, nel caso dell'IR di LLVM, esiste sia in forma testuale (utile da leggere per le persone), sia in forma binaria (memorizzata o su file o in memoria). La documentazione dice che il formato binario è simile a un XML (quindi una albero). Il formato testuale invece è così:

Codice: [Seleziona]

; ModuleID = 'base.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

; Function Attrs: nounwind uwtable
define i32 @foo(i32 %a, i32 %b) #0 {
  %1 = alloca i32, align 4
  %2 = alloca i32, align 4
  store i32 %a, i32* %1, align 4
  store i32 %b, i32* %2, align 4
  br label %3

; <label>:3                                       ; preds = %6, %0
  %4 = load i32* %1, align 4
  %5 = icmp sgt i32 %4, 0
  br i1 %5, label %6, label %11

; <label>:6                                       ; preds = %3
  %7 = load i32* %2, align 4
  %8 = mul nsw i32 %7, 2
  %9 = load i32* %1, align 4
  %10 = sub nsw i32 %8, %9
  store i32 %10, i32* %2, align 4
  br label %3

; <label>:11                                      ; preds = %3
  %12 = load i32* %2, align 4
  ret i32 %12
}

; Function Attrs: nounwind uwtable
define i32 @main() #0 {
  %1 = alloca i32, align 4
  %a = alloca i32, align 4
  store i32 0, i32* %1
  %2 = call i32 @foo(i32 3, i32 4)
  store i32 %2, i32* %a, align 4
  %3 = load i32* %a, align 4
  ret i32 %3
}

attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.ident = !{!0}

!0 = metadata !{metadata !"Ubuntu clang version 3.4-1~exp1 (trunk) (based on LLVM 3.4)"}
Generato compilando senza nessuna ottimizzazione (-O0) a partire da questo programmino inutile:

Codice: [Seleziona]

int foo(int a, int b)
{
    while(a>0)
        b = b*2 - a;

    return b;
}

int main()
{
    int a = foo(3,4);
    return a;
}

È in formato SSA, quindi con infinite variabili temporanee %xxx (xxx = numero), e come si vede ogni volta che una variabile è usata viene anche specificata la dimensione dell'operando.

[cdimauro]

• 

Comunque giusto per cronaca, qui si parla quasi di necessità di un codice intermedio per il multitarget, ma in realtà è uno step che si può saltare. Ciò che serve veramente è una AST e poi da quella si genera codice reale. Questo implica riscrivere un backend da zero per ogni architettura (oppure appoggiandosi ad uno esistente spesso duplicando codice), questa soluzione in genere è la migliore per avere il massimo della libertà per lo sfruttamento delle potenzialità di una architettura e per non perdere tempo sullo translate da codice intermedio astratto a codice reale. L'instruction selection comporta un sacco di compromessi nelle scelte

Vero. Forse si usa molto la tecnica del linguaggio intermedio per modularizzare più facilmente il progetto e renderlo così più mantenibile da team separati?

Credo che i vantaggi siano due: il primo è che più facile realizzare backend per architetture diverse usando un SSA piuttosto che un AST.

Il secondo è che l'SSA permette tutta una serie di ottimizzazioni che sono semplici più implementare rispetto all'AST.

Anche se, in effetti, non vedo quale sarebbe il problema nell'esportare direttamente l'AST, anche in forma serializzata (XML?) se necessario.

No, ti prego, XML nooooooo!