Re: guile-vm-0.0

[Keisuke Nishida <kxn30 at po dot cwru dot edu>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> > Yes, I think my VM will work on top of the existent evaluator.
> > Both have different benefits, and probably two can cooperate.
> 
> Hmm, I'm not sure if I would want to have two evaluators in Guile.
> Just one should be enough to maintain.  Making the two cooperate might
> be possible, but not too easy, especially when you consider the two
> tail-calling each other.

Such a low-level cooperation is not necessary, but probably it is true
that my VM will become able to evaluate any expression in time.  In any
event, I'll depend on your evaluator until my VM becomes completed.

> And, your VM has a real compiler, wihch behaves differently when it
> comes to macros and probably other things.  I think there is little
> reason, to maintain a slightly incompatible second evaluator when the
> primary evaluator (your VM, not the current one!) has good debugging
> support (which is the only real reason to keep a pure interpreter).

Debugging support is the concern I have about my VM.  Since bytecodes
loose information about source code, I'm not sure if I can provide a
good debugging interface. (Nobody want to trace assemble code)

> >  o To dump the bytecode in a file and improve loading time.
> 
> Yes.  This has some complications of its own, and I have experimented
> a little bit with that already.

I think the only thing necessary is a linkage loader.  It must convert
a bytecode to an executable program.  However, I already have it :)
`byte-assemble' produces a list of instructions:

  guile> (define code '(let ((a 1) (b 2)) (+ a b)))
  guile> (byte-assemble (parse code (make-top-level-env)))
  (%pushi 1 %pushi 2 %bind 2 %pushl:0:1 %loadl:0:0 add2 %return)

`make-bytecode' and `make-program' create an executable program:

  guile> (define code (list->vector '(%pushi 1 %pushi 2 %bind 2
  %pushl:0:1 %loadl:0:0 add2 %return)))
  guile> (make-program (make-bytecode code) #f)  ; #f means top-level
  #<program 0x8092a88>

So putting the following lines in a file already works:

  (define vm (make-vm))
  (vm-run vm (make-program (make-bytecode #(%pushi 1 %pushi 2 %bind 2
  %pushl:0:1 %loadl:0:0 add2 %return)) #f))

With some more techniques and module support, I think fast loading is
done.  (A binary loader may be even faster.  I wrote it before..)

> Right on!  In fact, this is one big reason, why I consider killing my
> tree-code evaluator idea: you seem to be a damn good hacker, I can't
> keep up with you anyway.

Thanks :)  I believe I am potentially a good hacker, but I need more
experience.