Guile 2.2 TODO

[Andy Wingo <wingo@pobox.com>]

Hi!

So, the RTL VM and the CPS compiler landed.  I think the consensus is
that Guile 2.2 is basically what's in master, all compiled to RTL.
Anything else we manage to get in is great but that's the fundamental
bit.

To that end, we should start to think about what is necessary to finish
the job, now that we're close.  I'm going to try to leave off things
that aren't necessary but would be nice to have, such as particular
optimization passes.  Those can always be added later.

* Test cases

I'm going to go ahead and mention this one first -- though it's more
part of "the way to get there" and not of "where we're going", writing
tests will be really useful to determine which parts of the compiler are
working and which are not.  This is the easiest, most productive way for
someone interested in this work to contribute.  Add a test to
test-suite/tests/rtl-compilation.test and commit the patch!  If it
fails, even better.

* Source information.

The plan here would be to use DWARF.  We don't use DWARF yet, so there
are a few parts of this.

  - Add a DWARF parser; see the wip-dwarf branch for that.  

  - Emit debugging info entries (DIEs) for each function in a
    compilation unit, into the .debug_info section.  Initially they
    would be minimal, just having the function's address and maybe its
    name.

  - Add machinery to (system vm debug) to get a DIE for a procedure, if
    it is present.

  - Add a macro-instruction to the assembler that records source
    location info.  Have the assembler collect this info.

  - Have the assembler write out source location info into a .debug_line
    section, and link the DIE to that info.

  - Add an appropriate interface to (system vm debug) to parse out line
    number information.  Perhaps model this interface on what is already
    in (system vm program).

  - Shim the existing (system vm program) interfaces to call the new
    (system vm debug) interfaces for RTL programs.

* Local variable information.

This is similar.  Assuming source information is done, you have to add
DW_TAG_variable entries for each variable to their function's DIE, and
link those entries to location lists in the .debug_loc section.  A
location list specifies the bytecode ranges for which a variable is
live.  Then you have to parse it out as well; the existing interfaces in
(system vm program) can be a guide.

This involves some compiler hacking, because we don't explicitly compute
liveness ranges.  I expect we'd have to compute an order in which to
emit labelled expressions (continuations), and use that order in the
slot allocator, the bytecode emitter, and of course when emitting
live/dead labels.  Maybe not, though; maybe it would be sufficient to
just associate live-set used in the slot allocator with each
continuation.  Dunno.

Ideally this gets linked up to the disassembler too.

* Replace bytecode trampolines with RTL trampolines.

foreign.c, control.c, gsubr.c, and continuations.c all have inline
bytecode trampolines to implement calls to "foreign" things.  These need
to be replaced with RTL trampolines.  This can be done now, I think, and
doesn't depend on anything else, given that the two VMs interoperate.

* Prompt, abort, and call/cc.

These bits have stub implementations in the VM and aren't yet
implemented in the compiler.  I think Mark Weaver is on this though, so
hopefully this situation shouldn't last too long.

* Compiling all of Guile to RTL.

As I mentioned, guild compile -t rtl foo.scm will compile to RTL, and
that interoperates fine with the old VM (modulo tail calls).  We can try
this by hand, file by file, checking that things work.  Then we would
switch the order of the compilers in (language tree-il spec) to make CPS
preferred over GLIL.

* Rip out GLIL, assembly, bytecode, objcode, the old VM, etc..

This will be a final glorious set of commits :)

* Update documentation

The manual will need updating.  I'm OK with putting this off to the end.


I think that's pretty much it.  Obviously it would be nice to get a lot
of other things into 2.2 but this is the necessary bit.  I think we
should shoot for a 2.1.0 release around 1 December; dunno.

WDYT?  If no one else is up to it, I'll get on source location info in a
couple weeks.

Andy
-- 
http://wingolog.org/