Re: guile-vm 0.3

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> So any sense of where things stand?  If we can help, we'd like to.

I can't really speak for the VM, but what I would like to see is some
investigation of existing `butch' Scheme or Lisp compilers.  In what
way could they be used with Guile?  For example, can Stalin be
modified to compile modules in a non-closed world, emitting the simple
mid-level language for the compiler in guile-lightning?

Guile-lightning has or will have only `low-level' expertise.  That is,
it knows for example how to compile parameter passing gotos into stack
and register shuffling code, and how to inline primitive operations
once it has been told that it should do so.  It does not know how to
represent general closures or when to is safe to inline a call to a
function.  It does not know about type propagation, but you can tell
it to use special versions of primitive operations that omit certain
type checks.

Thus, guile-lightning should take care of the machine specific
details, presenting a language to the upper layers that should be as
simple to target as C.  Simpler, in fact, since it takes care of the
idiosyncratic control flow features of Scheme.

I'm still thinking about where the right point is to interface with a
VM.  Do we (ultimately) want a system that has either a native
compiler or a VM?  Or a system that always has a VM, and on some
platforms also a native compiler?  I'm not sure yet.  In any case,
having the compiler in guile-lightning generate byte-codes instead of
JIT instructions seems quite reasonable.  I kinda like the dual
approach: a VM is useful even when we have a native compiler (for
debugging and compactness), and when we fuse the two on such a low
level, there should be little problem with maintaining them.


Anyway, I'm going to add register allocation to guile-lightning
now... this is soo much fun. :-)