Hello, Another quick update on CPS. I just pushed patches that implement closure conversion and use it to compile closures correctly. I think this is a big step forward for the CPS compiler. Since the last email, I've also implemented local mutable variables, and sequences (as part of that).
Somewhat shockingly, I think that's almost every language feature. The other things (dynamic environment, prompts) can actually be done by making closures and calling the functions that implement them - it's just faster to use the RTL instructions. However, I think the primitive procedure generation is robust enough to handle those without too much trouble. The bigger task now is a combination of finding and eliminating bugs and slowly removing the ugly hacks I put in there. I don't think there are too many, but the way the closure conversion handles letrecs and the big case statement in the primitive instruction generator are notable examples. There are also some arbitrary limitations in the code - things like only allowing one argument to a procedure, or one procedure in a letrec. I put those in because I knew I could remove them without fundamentally changing things, and I wanted to sketch out the whole compiler first to get the organization right. Now I need to go through and fix all of that. But overall, I think the CPS compiler is going well. Best, Noah On Fri, Feb 15, 2013 at 7:53 PM, Noah Lavine <noah.b.lav...@gmail.com>wrote: > Hello, > > The wip-rtl-cps branch has been rebased again (on top of wip-rtl). It now > includes support for toplevel references and sets, thanks mostly to Andy's > work on supporting them in RTL. (Although you shouldn't kick that part of > it too hard just yet; I think I know where it will break.) Other highlights > include using the top-level variable support to evaluate "(+ 3 4)" > correctly. > > Overall, I think it's coming along well. The parts of Tree-IL that are > left to implement are local mutable variables (should be easy after > toplevel ones), module references and sets (very similar to top-level > ones), closures, and the dynamic environment stuff. Local mutable variables > are my next project, and then I think closures. > > One question I've had is, can we assume that the variables in the (guile) > module are immutable? I think the current compiler does this. Otherwise > there's no correct way to inline primitive procedures like + unless we have > a way to invalidate our compiled code and recompile it (which I would like > to have anyway, but that's a different story). > > Best, > Noah > >
