wip-rtl, solstice edition

[Andy Wingo]

Hello all,

A few changes in master and wip-rtl.

First of all, I have changed the on-disk format for .go files to be ELF,
even for the old Guile 2.0-style bytecode.  This increases the file size
somewhat, though the memory footprint is the same.  What it gives us,
though, is extensibility.

In that regard, I have rebased wip-rtl on top of master.  If you have
existing wip-rtl checkouts, you'll have to be sure that they are
current.

Finally, I merged in the DWARF parser from guile-dlhacks.  It's not used
yet.  As I said in my mail to Noah, my first idea is to emit DWARF based
on macro-instructions in the assembly.  We'll see.

For me, my next steps are:

 1) Convert the ELF parser and linker to use symbols instead of the raw
    ELF codes, as the DWARF parser does.  It's more convenient and not
    significantly different, performance-wise.

 2) Add enough debugging information so that procedure-name works, and
    that we can determine the bounds of procedures.  (Determining where
    a procedure ends is a precondition for being able to disassemble
    it!)

 3) Create tests for all of the opcodes.  This task is somewhat
    decoupled from the previous tasks; if people want to help out, see
    libguile/vm-engine.c and test-suite/tests/rtl.test.

 4) Update the tools (debugger, frame printer, etc) to be able to deal
    with the new debugging format.

There are also some fundamentals of the VM that need nailing down.  One
is that the VM needs some more operations that take immediate operands.
That's pretty easy.  We should also think about inline caches.  It seems
like the way to go for toplevel calls and references, though it will
take some thinking for it to be reasonable in a VM.

But after those things are done, we still need to bridge the gap between
Tree-IL and RTL assembly.  We will probably have to scrap GLIL, though I
can't tell yet.

So, that's the status.  Apologies for there being no overview yet; I
will try to write something about that soon.  I reckon we are about a
month away from a VM that works well, and has good debugging
information, and two or three months away from a merge to master
(meaning, we compile all of Scheme).  At that point we could look to
release the first 2.2 beta release, aiming at a final 2.2 sometime early
next year.

Regards,

Andy
-- 
http://wingolog.org/