vm status update

[Andy Wingo]

Hello,

A small update. Since I wrote last, the compiler now puts program
names in with program metadata, and programs print in a much more
human-readable fashion:

    scheme@(guile-user)> module-ref
    $2 = #<program module-ref (module name . rest)>

Some bugs were fixed in disassembly, allowing the addition of the
following two sections:

    scheme@(guile-user)> ,x module-ref
    [...]
    Arguments:

       0    local[0]: module
       1    local[1]: name
       2    local[2]: rest

    Bindings:

    8-58    local[3]: variable

    [...]

The arguments show how they are allocated. All local variables in a
frame are on the stack, within the frame structure, and are accessed by
index. The other possibility is that a variable is "external", that is,
lexically bound by some enclosed lambda -- these are allocated on the
heap.

The range on the left side of a bindings listing shows the range of
instructions in which that particular local variable is bound, and what
its name is.

Currently, local variables are not reused even if their dynamic extents
are non-contiguous -- an optimization to maybe make later. For example:

    scheme@(guile-user)> ,x (lambda () (let ((x 1)) x) (let ((y 2)) y))
    Disassembly of #<program #(0 14 #f) (x)>:

    nargs = 0  nrest = 0  nlocs = 2  nexts = 0

    Bytecode:

       0    (make-int8 1)                   ;; 1
       2    (local-set 0)
       4    (make-int8 2)                   ;; 2
       6    (local-set 1)
       8    (local-ref 1)
      10    (return)

    Bindings:

     2-4    local[0]: x
    6-11    local[1]: y                     ;; could reuse local 0

    Sources:

       2    #(0 14 #f)
       6    #(0 30 #f)

It seems that the argument printing code has a bug there -- nargs is 0,
but it still prints the program as having args (x).

An important bug was fixed when compiling `or' forms when the value
would be discarded, as in `(begin (or #t (error "what")) 4)' -- an extra
value would be left on the stack. You should recompile all your .go
files when you pull.

Currently I'm working on implementing multiple-values support, mostly as
in Ashley and Dybvig's paper,
http://repository.readscheme.org/ftp/papers/jmashley/lfp94.pdf. Instead
of having the multiple-value return address being a fixed offset behind
the normal return address in the instruction stream, however, I'm just
going to push the MV return address on the stack, behind the normal
return address.

If you are interested in helping with guile-vm, just download it and
give it a whirl, see if it works for you. If your program doesn't do
call/cc it should work fine. I'm interested in any bugs!

Cheers,

Andy
-- 
http://wingolog.org/