Newsgroup: it.comp.programmare
Titolo: Generatore di parser

Salve,
leggevo su wikipedia che:
"The ideal compiler compiler takes a description of a programming language 
and a target instruction set architecture, and automatically generates a 
usable compiler from them"
Ma un un generatore di parser simile (battezziamolo ICC, Ideal Compiler 
Compiler), potrebbe ad esempio essere usato sul sistema operativo X e 
generare un compilatore che a sua volta genera codice funzionante sul 
sistema Y?
O si potrebbe solo decidere l'istruction set, in modo da poterlo ottimizzare 
per determinate cpu, ma sempre sullo stesso sistema operativo?
In tal caso ci vorrebbe un ICC per Linux che ad esempio consente di generare 
compilatori utilizzabili su Linux per cpu intel e amd, un altro per Windows 
che fa la stessa cosa ma su sistemi Windows, etc... ? 

 programma Jj
Ma Y � sia il linguaggio in cui sar� generato P che il linguaggio che sar� 
generato da P(Zx)?
E' come se ad esempio, ICC producesse in C++ un compilatore Java, e tale 
compilatore generasse un programma C++, invece che bytecode o codice 
macchina.
 

 all'instruction set.
Non mi risulta proprio. Visto che una grammatica non ha informazione
sulla semantica delle istruzioni, come potrebbe il povero bison
inventarsi le istruzioni che stanno alla base di a = b?
Quello che bison ti da e' un aggeggio che parserizza il sorgente e
chiama il tuo codice quando acchiappa certi costrutti. Il tuo codice poi
fara' la cosa giusta.
Anche oggetti piu' avanzati, come ANTLR non si spingono oltre
l'autogenerazione di un AST.
-- 
-riko

 che fa la stessa cosa ma su sistemi Windows, etc... ? 
E' abbastanza fantasiosa sta cosa... tipicamente, dato un interprete,
sarebbe possibile generare automaticamente un compilatore (teorema snm,
proiezioni di futamura). Ma di fatto non ci sono garanzie che il
compilato sia molto piu' snello dell'interprete stesso.
-- 
-riko

 compilato sia molto piu' snello dell'interprete stesso.
Ok 

 semplificare.
Rispetto a?
-- 
-riko

 il codice target  (opzionalmente) .
Ma in quella definizione l'instruction set � proprio quello 
dell'architettura hardware su cui tale compilatore dovr� funzionare.
Infatti genera un compilatore utilizzabile. 

 il codice target  (opzionalmente) .
Ma potrebbe anche non produrre *affatto* codice target. Anzi, di questi
tempi spesso e volentieri non lo fa.
-- 
-riko

 tempi spesso e volentieri non lo fa.
Il codice target quale sarebbe? 

 Il codice target quale sarebbe? 
codice nell'instruction set del target.
Ovvero, non c'e' scritto da nessuna parte che il parser in una passata
butti fuori il compilato. Anzi, tipicamente non e' affatto cosi' da
tempo.
-- 
-riko

 tempo.
Ma l'istruction set non � legato alla cpu?
Puoi fare un esempio con linguaggi reali?
Per esempio un parser Java generato in C++. Dove e' IS in questo caso? 

 Per esempio un parser Java generato in C++. Dove e' IS in questo caso?
IMHO state facendo un casino allucinante o io non sto capendo quello che
dite. 
Il parser riconosce un linguaggio. Tipicamente al riconoscimento sono
"associate" delle azioni. Una volta queste azioni erano tipicamente la
generazione del codice target. Oggi no.
Tipicamente hai un linguaggio L in cui e' scritto il compilatore, un
linguaggio L' che compili e un linguaggio L" che e' il target. Piu' una
serie di linguaggi intermedi (o rappresentazioni intermedie) L1...LN.
Ah, e volendo il parser potrebbe essere generato a partire da un
sorgente scritto nel linguaggio L'''.
-- 
-riko


Suppongo che in un caso del genere verranno generate
delle chiamate alla macchina virutale. So benissimo
che non può essere implementata nel modo che sto per
dire, ma in via di principio me la posso immaginare
come un modello client-server. In un'istruzione
semplice di assegnazione come a=3; arriverà al
server una sequenza di pacchetti del tipo "cerca
nella lista la variabile a / prendi 3 e / mettilo
dentro la locazione di memoria al relativo indirizzo".
Più interessante sarebbe sapere cosa accade nella
realtà con le necessarie ottimizzazioni che si
possono fare sui costrutti ad alto livello, tipo
portare fuori da un loop la medesima istruzione di
cui sopra. Non so fino a che punto si può spingere
un interprete, anche perché non ho mai giocato con
un sistema come Java e macchine virtuali. Suppongo
che tra il livello del sorgente e la macchina
virtuale esista un linguaggio intermedio dove un
caso come quello sopra potrebbe essere intercettato
prima di generare la sequenza di chiamate alla
macchina virtuale, in altri casi non so.
ciao!
Apx.
-- 
"Non portare mai la tua donna alla
baia dei Porci. Lei capirà"

 delle chiamate alla macchina virutale.
Non vedo perche' supporre... Se il target sara' la JVM verranno
semplicemente generate istruzioni della JVM. Non "chiamate". Istruzioni.
Bytecode. Poi sara' una JVM software o una hardware? Boh. Chissene.
Bytecode.
Puoi anche compilare in codice nativo. Nel caso niente istruzioni della
JVM, niente "chiamate alla macchina virtuale". Istruzioni della macchina
e chiamate al runtime. Ma le chiamate al runtime le hai anche in C, C++,
D, Objective-C. Tutti compilati e tutti con un runtime sempre crescente.
-- 
-riko

 linguaggio L' che compili e un linguaggio L" che e' il target.
Ma qu� siamo gi� ad un livello successivo, ovvero quando il compilatore � 
gi� pronto all'uso. 

 e in questo caso � il C++.
Allora non si riferisce necessariamente a quello legato ad una CPU. 

 gi� pronto all'uso. 
Ci sono anche compilatori non pronti all'uso? A parte quelli non ancora
finiti, intendo... :)
-- 
-riko

 finiti, intendo... :)
Diciamo che consideravo compilatore anche il parser generato dal generatore 
di parser e che ancora non pu� essere usato per creare programmi perch� ad 
esempio bisogna implementare la gestione degli errori, etc... o forse anche 
tu intendevi questo e lo consideri pronto all'uso a prescindere 
dall'implementazione di altri aspetti (come gestione degli errori appunto) 
che potrebbero essere considerati un dettaglio implementativo?
Tra parser, generatori di parser, compilatori e meta-compilatori questo 
thread sembra un gioco di parole :D 

 che potrebbero essere considerati un dettaglio implementativo?
Scusa, ma non sto capendo *assolutamente* piu' nulla.
Un generatore di parser prende una grammatica formale specificata in
qualche modo (tipicamente simil BNF) e alle cui produzioni e' agganciato
del codice eseguibile.
Quello che fa quel codice, dipende. Dipende da chi lo scrive, dipende da
quello che vuoi che faccia.
Il parser generator prende sto file e genera un sorgente in genere
scritto nello stesso linguaggio nel quale hai scritto le azioni
agganciate. Parlando di yacc, e' C. Le azioni le scrivi in C e ti trovi
un bel file .c.
Questo cosa e'? Boh. Potrebbe essere un compilatore fatto e finito.
Potrebbe essere un interprete fatto e finito. Potrebbe essere solo il
front'end di qualcos'altro. Tipo un modulo che ti da in mano un AST.
Poi quello che fai con questo ast chi lo sa... ci fai un interprete, un
compilatore, un tool di analisi statica, un lint. Fine.
La gestione degli errori e' una terza cosa completamente ortogonale a
tutto questo.
-- 
-riko

 tutto questo.
Ma potrebbe ad esempio far parte di quel codice eseguibile che si aggancia 
alla produzione del generatore di parser? 

 alla produzione del generatore di parser? 
-- 
-riko

 prenditi flex e bison e prova a fare un mini compilatore.
Concettualmente sapevo grosso modo come funziona, mi interessava solo 
valutare cosa potesse fare un vero ICC :-P