[Python-Dev] 'stackless' python?

Christian Tismer tismer at appliedbiometrics.com
Wed May 19 22:10:16 CEST 1999


Jeremy Hylton wrote:

[TP+CT about frame copies et al]

> Wouldn't it be easier to increase the refcount on the frame object?
> Then you wouldn't need to worry about the recounts on all the objects
> in the frame, because they would only be decrefed when the frame is
> deallocated.

Well, the frame is supposed to be run twice, since there are
two incarnations of interpreters working on it: The original one,
and later, when it is thown, another one (or the same, but, in
principle). 
The frame could have been in any state, with a couple
of objects on the stack. My splitting function can be invoked
in some nested context, so I have a current opcode position,
and a current stack position.
Running this once leaves the stack empty, since all the objects are
decrefed. Running this a second time gives a GPF, since the stack is
empty.
Therefore, I made a copy which means to create a duplicate frame
with an extra refcound for all the objects. This makes sure
that both can be restarted at any time.

> It seems like the two other things you would need are some way to get
> a copy of the current frame and a means to invoke eval_code2 with an
> already existing stack frame instead of a new one.

Well, that's exactly where I'm working on.

> (This sounds too simple, so it's obviously wrong.  I'm just not sure
> where.  Is the problem that you really need a seperate stack/graph to
> hold the frames?  If we leave them on the Python stack, it could be
> hard to dis-entangle value objects from control objects.)

Oh, perhaps I should explain it a bit clearer?
What did you mean by the Python stack? The hardware machine stack?

What do we have at the moment:
The stack is the linked list of frames. Every frame has a
local Python evaluation stack. Calls of Python functions produce
a new frame, and the old one is put beneath. This is the control
stack. The additional info on the hardware stack happens to be
a parallel friend of this chain, and currently holds extra info,
but this is an artifact. Adding the current Python stack level
to the frame makes the hardware stack totally unnecessary.

There is a possible speed loss, anyway.
Today, the recursive call of ceval2 is optimized and quite
fast. The non-recursive Version will have to copy variables
in and out from the frames, instead, so there is of course
a little speed penalty to pay.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home




More information about the Python-Dev mailing list