[<<][libprim][>>][..]
Sat Jan 23 07:53:17 CET 2010

VM cont..

I'm running in circles.  Maybe the machine needs to be designed around
_let() instead?  I.e. to create a frame or to not create a frame?

Maybe it's time to leave it as is, bootstrap the system and see how
fast it runs.  Then try to create a next version.

Let's cleanup the code a bit first. OK.

The idea is this: at the point where we have let's intermediate state
active (list of values + list of expressions) we need to decide
whether this state should be saved to introduce a new frame or not.

It looks like this means breaking out the current expression list and
the list of collected values.

So let's turn it around: the VM's core function is to perform `let':
interpret a linear sequence of opcodes, and collect their results in a
value rib.  Once the rib is complete, add the rib to the environment
and execute a body.

A body is then:
  - a new let
  - an application  (gather arguments + change environment)


Dybvig[1] uses 5 registers:

  - a: accumulator
  - x: next expression
  - e: current environment
  - r: current value rib
  - s: current stack

Using a value rib in the presence of continuations requires some
special care when the continuation is captured during a `let'
expression.

It's really quite complex: there are a lot of possible optimizations.
I wonder if it's possible to formulate the different implementation
trade-offs in a more modular fashion, and use partial evaluation te
generate an implementation.

Looks like guile has display closures too[2].


[1] http://www.cs.unm.edu/~williams/cs491/three-imp.pdf
[2] http://wingolog.org/archives/2009/07/26/the-good-hack



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