Sembra che GCC e LLVM-Clang stiano utilizzando parser discendenti ricorsivi scritti a mano e non l'analisi bottom-up generata dalla macchina, basata su Bison-Flex.
Qualcuno qui potrebbe confermare che questo è il caso? E se è così, perché i framework dei compilatori tradizionali utilizzano parser scritti a mano?
Aggiornamento : blog interessante su questo argomento qui
Risposte:
Sì:
GCC ha utilizzato un yacc (bisonte) parser una volta, ma è stato sostituito con un parser ricorsivo discesa scritto a mano ad un certo punto nella serie 3.x: vedi http://gcc.gnu.org/wiki/New_C_Parser per collegamenti alle richieste di patch pertinenti.
Clang usa anche un parser di discesa ricorsivo scritto a mano: vedere la sezione "Un singolo parser unificato per C, Objective C, C ++ e Objective C ++" verso la fine di http://clang.llvm.org/features.html .
foo * bar;potrebbe essere analizzato come espressione di moltiplicazione (con il risultato inutilizzato) o come dichiarazione di una variabile barcon tipo pointer-to- foo. Quale sia corretto dipende dal fatto che un typedeffor foosia in ambito in quel momento, il che non è qualcosa che può essere determinato con una certa quantità di lookahead. Ma questo significa solo che il parser di discesa ricorsivo necessita di qualche brutto meccanismo extra aggiunto per gestirlo.
C'è un teorema popolare che dice che C è difficile da analizzare e C ++ essenzialmente impossibile.
Non è vero.
Ciò che è vero è che C e C ++ sono piuttosto difficili da analizzare usando i parser LALR (1) senza hackerare il meccanismo di analisi e aggrovigliarsi nei dati della tabella dei simboli. GCC infatti usava analizzarli, usando YACC e hackery aggiuntivi come questo, e sì, era brutto. Ora GCC utilizza parser scritti a mano, ma ancora con l'hackery della tabella dei simboli. La gente di Clang non ha mai provato a usare generatori di parser automatizzati; Per quanto ne so, il parser Clang è sempre stato una discesa ricorsiva codificata a mano.
Ciò che è vero, è che C e C ++ sono relativamente facili da analizzare con parser generati automaticamente più potenti, ad esempio parser GLR , e non è necessario alcun hack. Il parser Elsa C ++ è un esempio di questo. Il nostro C ++ Front End è un altro (come tutti i nostri front-end "compilatori", GLR è una tecnologia di analisi davvero meravigliosa).
Il nostro front-end C ++ non è veloce come quello di GCC, e certamente più lento di Elsa; abbiamo investito poca energia nel metterlo a punto attentamente perché abbiamo altri problemi più urgenti (tuttavia è stato utilizzato su milioni di righe di codice C ++). Elsa è probabilmente più lenta di GCC semplicemente perché è più generale. Date le velocità del processore in questi giorni, queste differenze potrebbero non avere molta importanza nella pratica.
Ma i "veri compilatori" che sono ampiamente distribuiti oggi hanno le loro radici in compilatori di 10 o 20 anni fa o più. Le inefficienze allora contavano molto di più e nessuno aveva sentito parlare di parser GLR, quindi le persone facevano quello che sapevano fare. Il clang è certamente più recente, ma i teoremi popolari conservano la loro "capacità di persuasione" per molto tempo.
Non devi più farlo in quel modo. Puoi ragionevolmente usare GLR e altri analoghi parser come front-end, con un miglioramento nella manutenibilità del compilatore.
Che cosa è vero, è che ottenere una grammatica che corrisponda al comportamento del tuo amichevole compilatore di quartiere è difficile. Sebbene praticamente tutti i compilatori C ++ implementino (la maggior parte) dello standard originale, tendono anche ad avere molte estensioni degli angoli oscuri, ad esempio, le specifiche DLL nei compilatori MS, ecc. Se hai un potente motore di analisi, puoi passare il tuo tempo a cercare di ottenere la grammatica finale per abbinare la realtà, piuttosto che cercare di piegare la tua grammatica per soddisfare i limiti del tuo generatore di parser.
EDIT Novembre 2012: da quando abbiamo scritto questa risposta, abbiamo migliorato il nostro front-end C ++ per gestire il C ++ 11 completo, inclusi dialetti varianti ANSI, GNU e MS. Anche se c'erano molte cose extra, non dobbiamo cambiare il nostro motore di analisi; abbiamo appena rivisto le regole grammaticali. Noi fatto dovuto cambiare l'analisi semantica; C ++ 11 è semanticamente molto complicato e questo lavoro sommerge lo sforzo per far funzionare il parser.
EDIT Febbraio 2015: ... ora gestisce la versione completa di C ++ 14. (Vedi ottenere AST leggibile dall'uomo dal codice c ++ per l'analisi GLR di un semplice bit di codice e la famigerata "analisi più irritante" di C ++).
EDIT Aprile 2017: ora gestisce (bozza) C ++ 17.
foo * bar;ambiguità?
Il parser di Clang è un parser a discesa ricorsiva scritto a mano, così come molti altri front-end C e C ++ open source e commerciali.
Clang utilizza un parser a discesa ricorsiva per diversi motivi:
Nel complesso, per un compilatore C ++, non importa molto: la parte di analisi di C ++ non è banale, ma è comunque una delle parti più facili, quindi vale la pena mantenerla semplice. L'analisi semantica, in particolare la ricerca del nome, l'inizializzazione, la risoluzione del sovraccarico e la creazione di istanze dei modelli, sono ordini di grandezza più complicati dell'analisi. Se vuoi una prova, controlla la distribuzione del codice e dei commit nel componente "Sema" di Clang (per l'analisi semantica) rispetto al suo componente "Parse" (per l'analisi).
Il parser di gcc è scritto a mano. . Sospetto lo stesso per il clang. Questo è probabilmente per alcuni motivi:
Questo probabilmente non è un caso di sindrome del "non inventato qui", ma più sulla falsariga di "non c'era nulla di ottimizzato specificamente per ciò di cui avevamo bisogno, quindi abbiamo scritto il nostro".
Strane risposte lì!
Le grammatiche C / C ++ non sono libere dal contesto. Sono sensibili al contesto a causa della barra Foo *; ambiguità. Dobbiamo costruire un elenco di typedef per sapere se Foo è un tipo o meno.
Ira Baxter: Non vedo il punto con la tua cosa GLR. Perché costruire un albero di analisi che comprende ambiguità. Analizzare significa risolvere ambiguità, costruire l'albero della sintassi. Risolvi queste ambiguità in un secondo passaggio, quindi non è meno brutto. Per me è molto più brutto ...
Yacc è un generatore di parser LR (1) (o LALR (1)), ma può essere facilmente modificato per essere sensibile al contesto. E non c'è niente di brutto in esso. Yacc / Bison è stato creato per aiutare nell'analisi del linguaggio C, quindi probabilmente non è lo strumento più brutto per generare un parser C ...
Fino a GCC 3.x il parser C è generato da yacc / bison, con la tabella typedefs costruita durante l'analisi. Con la creazione di tabelle typedef "in parse", la grammatica C diventa localmente libera dal contesto e inoltre "localmente LR (1)".
Ora, in Gcc 4.x, è un parser discendente ricorsivo. È esattamente lo stesso parser di Gcc 3.x, è ancora LR (1) e ha le stesse regole grammaticali. La differenza è che il parser yacc è stato riscritto a mano, lo shift / reduce sono ora nascosti nello stack di chiamate e non c'è "state454: if (nextsym == '(') goto state398" come in gcc 3.x yacc's parser, quindi è più facile patchare, gestire errori e stampare messaggi più belli, ed eseguire alcuni dei passaggi successivi di compilazione durante l'analisi, al prezzo di un codice molto meno "facile da leggere" per un noob di gcc.
Perché sono passati da yacc a discendenza ricorsiva? Perché è abbastanza necessario evitare che yacc parli C ++, e poiché GCC sogna di essere un compilatore multilingue, cioè condividere il massimo del codice tra i diversi linguaggi che può compilare. Questo è il motivo per cui il C ++ e il parser C vengono scritti nello stesso modo.
C ++ è più difficile da analizzare rispetto a C perché non è "localmente" LR (1) come C, non è nemmeno LR (k). Guarda func<4 > 2>quale è una funzione modello istanziata con 4> 2, cioè func<4 > 2>
deve essere letta come func<1>. Questo non è sicuramente LR (1). Ora considera,func<4 > 2 > 1 > 3 > 3 > 8 > 9 > 8 > 7 > 8> . È qui che una discesa ricorsiva può facilmente risolvere l'ambiguità, al prezzo di qualche altra chiamata di funzione (parse_template_parameter è la funzione parser ambigua. Se parse_template_parameter (17tokens) fallisce, riprova parse_template_parameter (15tokens), parse_template_parameter (13tokens) ... Funziona).
Non so perché non sarebbe possibile aggiungere sotto grammatiche ricorsive yacc / bison, forse questo sarà il prossimo passo nello sviluppo del parser gcc / GNU?
Sembra che GCC e LLVM-Clang stiano utilizzando parser discendenti ricorsivi scritti a mano e non analisi bottom-up generate dalla macchina, basate su Bison-Flex.
Bison in particolare non credo possa gestire la grammatica senza analizzare alcune cose in modo ambiguo e fare un secondo passaggio più tardi.
So che Happy di Haskell consente parser monadici (cioè dipendenti dallo stato) che possono risolvere il problema particolare con la sintassi C, ma non conosco generatori di parser C che consentono una monade di stato fornita dall'utente.
In teoria, il ripristino degli errori sarebbe un punto a favore di un parser scritto a mano, ma la mia esperienza con GCC / Clang è stata che i messaggi di errore non sono particolarmente buoni.
Per quanto riguarda le prestazioni, alcune delle affermazioni sembrano infondate. La generazione di una grande macchina a stati utilizzando un generatore di parser dovrebbe risultare in qualcosa che è O(n)e dubito che l'analisi sia il collo di bottiglia in molti strumenti.