[<<][libprim][>>][..]
Sun Jan 3 22:14:07 CET 2010

Distractions

Did I reach the goal?  (The goal was to replace the current VM with
something faster and easier to understand).

I do think this approach is simpler.  Although the direct
implementation is quite straightforward also, the particular turns I
took don't all make sense.  One of them is the `ktx' idea.  The reason
is of course the tension between wanting to write the VM as a pure
data structure transformer, while wanting to keep the primitives close
to C function semantics.  This doesn't work well when continuations
are part of the game, and the garbage collector has to be tamed using
state.

The new VM is simpler in that it has only two kinds of continuations:
`let' expressions and `begin' forms (2-expression begin or `seq').
This requires some complication on the compiler side however: the
subset of scheme the VM supports is smaller.

Whether it is faster I haven't checked.  It would really surprise me
though if it is not.  It produces a lot less intermediate state: only
continuation chains and environments.


So what did we learn?  The interesting balance between operations that
save context and setup a continuation, and the subsequent handling of
the continuations: the move from direct style (function returns to the
point after invocation) to CPS style: we tell the machine what to do
next at the point the current evaluation finishes.

This was already a revelation this summer working on the more explicit
interpreter, but the VM and the closer connection to C functions makes
it all a bit more earthy.


Is there any beef in this?  Yes.  I'm not so far removed from being
able to self-host the compiler.  Toplevel defs + some transferrable
bytecode format.  It would be interesting to be able to cross-compile
from any standard Scheme.




[Reply][About]
[<<][libprim][>>][..]