[Python-Dev] 'stackless' python?

[rushing at nightmare.com]

M.-A. Lemburg writes:

 > Wouldn't it be possible to move all the C variables passed to
 > eval_code() via the execution frame ? AFAIK, the frame is
 > generated on every call to eval_code() and thus could also
 > be generated *before* calling it.

I think this solves half of the problem.  The C stack is both a value
stack and an execution stack (i.e., it holds variables and return
addresses).  Getting rid of arguments (and a return value!) gets rid
of the need for the 'value stack' aspect.

In aiming for an enter-once, exit-once VM, the thorniest part is to
somehow allow python->c->python calls.  The second invocation could
never save a continuation because its execution context includes a C
frame.  This is a general problem, not specific to Python; I probably
should have thought about it a bit before posting...

 > Don't know if moving the C stack stuff into the frame objects
 > will get you the desired effect: what about other things having
 > state (e.g. connections or files), that are not even touched
 > by this mechanism ?

I don't think either of those cause 'real' problems (i.e., nothing
should crash that assumes an open file or socket), but there may be
other stateful things that might.  I don't think that refcounts would
be a problem - a saved continuation wouldn't be all that different
from an exception traceback.

-Sam

p.s. Here's a tiny VM experiment I wrote a while back, to explain
what I mean by 'stackless':

http://www.nightmare.com/stuff/machine.h
http://www.nightmare.com/stuff/machine.c

Note how OP_INVOKE (the PROC_CLOSURE clause) pushes new context
onto heap-allocated data structures rather than calling the VM
recursively.