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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4