Re: wip-rtl, solstice edition

[Andy Wingo <wingo@pobox.com>]

On Mon 25 Jun 2012 22:52, ludo@gnu.org (Ludovic Courtès) writes:

>>  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.
>
> Yes.  The one at
> <https://gitorious.org/guile-dlhacks/guile-dlhacks/blobs/master/dlhacks/elf.scm>
> could use more comments, docstrings, and tests, if you ask me.  :-)

It's the same one that's in master :)  Agreed, though.  I would note
that in wip-rtl it is tested by rtl.test, though not as a unit.

>>  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.
>
> I’m afraid that writing tests after code may either not happen, or may
> be unable to uncover bugs if it’s written by the same person, or may be
> difficult for someone without a clear picture of the API.
>
> WDYT?
>
> That said, I’ll look into all this as time permits, and see what I can
> contribute myself.

Yes I see what you are saying.  It was only recently that things came
together enough to be testable at all (to have the circle between
assembler, linker, and loader).  However, the instructions themselves
are fairly well documented; do see

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/vm-engine.c;h=3f575880d5210a1ab5bd4a28b429a0807864be43;hb=refs/heads/wip-rtl#l941

So for this purpose, writing tests should be possible.  WDYT?

> Didn’t you once say “2.2 will have native compilation”?  ;-)

:)

> Seriously though, that seems like a good plan.  I wonder what Noah’s
> attempts at JITing the 2.0 bytecode would have achieved, though, if we
> think of both JIT and the new VM as an “interim solution” before AOT
> native compilation.

It would have been possible but not ideal.  Rewriting the VM to
e.g. have fixed-size stack frames, only two virtual registers, separate
debugging information, statically allocate constants, etc. would still
be necessary, and at that point a refactor to the VM would be more
difficult.

IMO anyway :)

Cheers,

Andy
-- 
http://wingolog.org/