Looking at some of the links associated with the paper "A nanopass framework ... " you find:
http://www.cs.indiana.edu/eip/compile/ which may answer your question and help those looking at Maru. david On Sun, Apr 14, 2013 at 5:35 PM, David Barbour <[email protected]> wrote: > Do you have a list of the common 'kinds' of passes? Because any domain > specific model be optimizing only conjunctions of only a few kinds. > > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich <[email protected] > > wrote: > >> I had another idea the other day that could profit from a >> domain-specific model: a model for compiler passes. I stumbled upon the >> nanopass approach [1] to compiler construction some time ago and found that >> I like it. Then it occurred to me that if one could express the passes in >> some sort of a domain-specific language, the total compilation pipeline >> could be assembled from the individual passes in a much more efficient way >> that would be the case if the passes were written in something like C++. >> >> In order to do that, however, no matter what the intermediate values in >> the pipeline would be (trees? annotated graphs?), the individual passes >> would have to be analyzable in some way. For example, two passes may or may >> not interfere with each other, and therefore may or may not be commutative, >> associative, and/or fusable (in the same respect that, say, Haskell maps >> over lists are fusable). I can't imagine that C++ code would be analyzable >> in this way, unless one were to use some severely restricted subset of C++ >> code. It would be ugly anyway. >> >> Composing the passes by fusing the traversals and transformations would >> decrease the number of memory accesses, speed up the compilation process, >> and encourage the compiler writer to write more fine-grained passes, in the >> same sense that deep inlining in modern language implementations encourages >> the programmer to write small and reusable routines, even higher-order >> ones, without severe performance penalties. Lowering the barrier to >> implementing such a problem-specific language seems to make such an >> approach viable, perhaps even desirable, given how convoluted most >> "production compilers" seem to be. >> >> > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
