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/