4 ms·

Really great work. Thumbs up. As an experienced programmer who only recently got into compilers, I have a few, open ended, somewhat advanced, questions about t

by fizixer 11y ago

Really great work. Thumbs up. As an experienced programmer who only recently got into compilers, I have a few, open ended, somewhat advanced, questions about the transformer phase (for anyone to comment, thanks in advance). It appears to me that the transformer is like the guts of the compiler, everything else is more like support system. And more often than not, the purpose of transformation ends up being 'optimization', but of course you could do transformation for other purposes. However this phase ends up being very hairy logic if the programmer is not careful. Anyway, my questions are: - is there any consensus on creating a DSL for providing transformation rules instead of hand coding them in the programming language? - There is the nanopass compiler framework in scheme [0]. Is that one of the superior ways of doing things? or are there any serious criticisms about that technique? - Is there a relationship between compiler transformations and 'term-rewriting systems'? - OMeta/OMeta2 pattern matching on context-free-languages? Whether it's nanopass-framework, OMeta2, term-rewriting system, or some other DSL, I guess what I'm trying to get at is how can that phase be made more 'formal', so I guess at this point we get into the area of 'formal systems' and 'formal semantics' etc, etc. I would appreciate if there is recommended reading (books, survey papers, etc) on this topic. [0] https://github.com/akeep/nanopass-framework https://github.com/akeep/nanopass-framework

naasking 11y ago
Here's one data point: * Automatic Generation of Peephole Superoptimizers: http://lambda-the-ultimate.org/node/2800 http://lambda-the-ultimate.org/node/2800
bluetomcat 11y ago
I wrote a shift-reduce parser for a minimalistic C-like language where the grammar is entirely specified as a static table. The precedence rules are resolved through a "should_shift" function where the parser asks whether it should perform the reduction for a matched rule, or shift one token more: https://github.com/bbu/simple-interpreter https://github.com/bbu/simple-interpreter
skybrian 11y ago
There are a wide variety of techniques. Some compilers use a single IR (intermediate language) as the input and output for each optimization pass. Others use multiple IR's depending on the phase. If you have a bunch of optimization passes and each pass visits the entire program, the compiler can become slow pretty quickly. Also, there's nothing preventing passes from running in the wrong order, and they may have implicit dependencies that aren't well documented.

by fizixer 11y ago

naasking 11y ago

Here's one data point: * Automatic Generation of Peephole Superoptimizers: http://lambda-the-ultimate.org/node/2800 http://lambda-the-ultimate.org/node/2800

bluetomcat 11y ago

I wrote a shift-reduce parser for a minimalistic C-like language where the grammar is entirely specified as a static table. The precedence rules are resolved through a "should_shift" function where the parser asks whether it should perform the reduction for a matched rule, or shift one token more: https://github.com/bbu/simple-interpreter https://github.com/bbu/simple-interpreter

skybrian 11y ago

There are a wide variety of techniques. Some compilers use a single IR (intermediate language) as the input and output for each optimization pass. Others use multiple IR's depending on the phase. If you have a bunch of optimization passes and each pass visits the entire program, the compiler can become slow pretty quickly. Also, there's nothing preventing passes from running in the wrong order, and they may have implicit dependencies that aren't well documented.