(Forwarded from Layers thread) On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich <gath.na.geala...@gmail.com>wrote:
> Isn't one of the points of idst/COLA/Frank/whatever-it-is-called-today to > simplify the development of domain-specific models to such an extent that > their casual application becomes conceivable, and indeed even practical, as > opposed to designing a new one-size-fits-all language every decade or so? > > 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. > > (If I've just written something that amounts to complete gibberish, please > shoot me. I just felt like writing down an idea that occurred to me > recently and bouncing it off somebody.) > > - Gath > > [1] Kent Dybvig, A nanopass framework for compiler education (2005), > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.72.5578 > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
