Re: What happened to the ex-Guile VM?

[Keisuke Nishida]

At 20 Mar 2001 22:52:34 +0100,
Marius Vollmer wrote:
> 
> I'm quite in favor of replacing the current evaluator with a `better'
> one.  `Better' is a complicated requirement here, since so many
> fcators are involved.  Speed, of course, but not only speed.
> Maintainability, speed of loading code, debuggability of the executed
> program, portability, easy of hacking it (to implement new
> optimizations, say), interactive responsiveness, standards
> conformance, and probably more.

Maybe ease of development.  I want to have a new one before long.

> In my opinion, the current avaluator fares like this:

Regarding my VM:

- Speed.  Fairly good.  Since the VM itself rarely does conses,
  GC is reduced significantly compared to the current evaluator.

- Maintainability.  Good enough, I think.  The VM, the assembler,
  and the compiler are separated into modules.  All instructions are
  refereed by names, not by opcodes, so adding/removing instructions
  is quite easy.  If you want to abbreviate (local-ref 0) into a
  new instruction (local-ref:0), just add it.  The assembler detects
  it and optimizes automatically.

- Speed of loading code.  Loading a compiled file should be very
  fast (I haven't benchmarked it yet).  Since the size of bytecode
  is likely less than one tenth of equivalent machine code, I/O is
  reduced significantly when you load a huge module.

  Loading a source file is relatively slow, because it must be first
  compiled.  But given a fast evaluator, the compiler should run
  sufficiently fast if you turn optimization off.  The result of
  compilation can be saved in a file, so slowdown at the first loading
  shouldn't be a big problem.

- Debuggability.  To be improved.  Currently, the VM has seven hooks
  (boot-hook, halt-hook, next-hook, enter-hook, apply-hook, exit-hook,
  and return-hook) which can be used for various tasks, including a
  tracer, profiler, and a debugger.  Backtrace can be easily done by
  displaying stack frames.  Source level debugging facilities (e.g.,
  displaying error locations) must be supported soon.

  (Probably I should drop the fast engine and have only this debug
   engine.  Given a JIT compiler like lightning, an improvement of
   speed by 30% is not very attractive.)

- Portability.  Good.  Compiled code (bytecode) is also portable.
  The new loader has no endian problem.

- Ease of Hacking.  I don't know.  Try it ;)

- Interactive responsiveness.  Not bad.  So far, I don't see any delay
  because of compilation, except in the first evaluation when the
  current evaluator is compiling the VM compiler.  (It seems the
 `match' macro requires time.)

- Standards conformance.  Tail-call elimination and continuations are
  supported.  Unfortunately, my VM does not conform to JVM.

I think a VM like this is a good balanced solution for daily
programming.  Many systems, such as RScheme and OCaml, choose a
hybrid of bytecode and machine code.  I think we should follow them.

I'll commit my code to the CVS repository before long, though it is
not working well right now. (I changed part of the design recently.)

Kei