Hello! Andy Wingo <wi...@pobox.com> skribis:
> This patchset implements the CPS compiler I've been working on over the > last couple months. At the end of it, you can > > guild compile -t rtl foo.scm > > and, if there are no bugs or unimplemented bits, at that point you have > a loadable .go with RTL code. (Try readelf -a on the .go!) Woow, wonderful! > As a little example: > > (+ 1 2) > > Here + is a primcall, so we would get: > > ($letk ((kone ($kargs (oneb) > ($letk ((ktwo ($kargs (two) > ($continue ktail > ($primcall + one two))))) > ($continue ktwo ($const 2)))))) > ($continue kone ($const 1))) > > Here all CPS language constructs are prefixed with "$". Everything else > is a variable, except the + in the primcall. Thanks for the example that nicely complements a first-time read of Kennedy’s paper. [...] > If you ever worked with the old (language tree-il compile-glil) module, > you know it's very hairy, mostly because it's mixing code emission with > semantic transformations. Nowhere is this more evident than the > so-called "labels allocation" strategy, in which we try to allocate > procedures as basic blocks, if they all return to the same place. It's > a funky pass. It turns out this concept is well-studied and has a name, > "contification", and is cleanly expressed as a source-to-source pass > over CPS. So compile-rtl.scm is dumb: it just loops over all > expressions, emitting code for each of them, and emitting jumps and > shuffling registers as needed (based on a prior analysis pass). That’s really appreciable. :-) > OK. WDYT, Ludo? Comments? OK to merge? :) Well, I guess so! Thanks to Noah for getting you started, and to Mark and you for getting this far! (I’m going to browse the patches, mostly so I can learn from this.) Ludo’.
