Sat Jan 23 07:53:17 CET 2010
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 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'
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.