[Stackless] Ann: Stackless Python is DEAD! Long live Stackless Python

[Christian Tismer]

Gordon McMillan wrote:

> On 18 Jan 2002 at 16:33, Sam Rushing wrote:
> 
> 
>>Let me see if I understand this correctly - you are in
>>effect changing C's execution model to one that uses a
>>linked list of heap-allocated frames?  With
>>PyEval_EvalCodeEx() being the 'frame granularity'? 


Thought so, but I have to admit that I'm not sure yet.

> I'm not sure I understand your restatement (nor am I 
> entirely confident I understand Christian's). My 
> simple-minded picture is that positions 0..K of the
> stack (the part before we did anything weird) stay
> the same. But Christian swaps in / out K+1..top (varying 
> size) as needed.


Which direction is your brain's stack? Mine is upside
down, due to too much debugging. I think we mean the
same. I'm only modifying a certain area in the context
of a recusive call, re-using the stack space of the
first call.

Let's make a picture...

Stack situation before we do nasty things

    top: earlier C calls
    +------------------+
a  |                  | topmost PyEval_EvalCodeEx
    +------------------+
    |                  | and eval_frame
    +------------------+
    .                  .
    .                  . some number of intermediate
    .                  . C functions
    +------------------+
b  |                  | current PyEval_EvalCodeEx
    |                  | before calling eval_frame
    +------------------+

Now we save the area from b to a into a safe place,
and we move the current stack frame b up to a:

     top: earlier C calls
    +------------------+
b  |                  | current PyEval_EvalCodeEx
    |                  | before calling eval_frame
    +------------------+

eval_frame is now called, as if we we the one and only
invocation here:

     top: earlier C calls
    +------------------+
b  |                  | current PyEval_EvalCodeEx
    +------------------+
    |                  | and eval_frame
    +------------------+

When eval_frame is done, we restore the stack layout:

     top: earlier C calls
    +------------------+
a  |                  | topmost PyEval_EvalCodeEx
    +------------------+
    |                  | and eval_frame
    +------------------+
    .                  .
    .                  . some number of intermediate
    .                  . C functions
    +------------------+
b  |                  | current PyEval_EvalCodeEx
    |                  | after calling eval_frame
    +------------------+

PyEval_EvalCodeEx now continues normally and returns
through all the intermediate C functions, until it
returns to a. This is as usual.

The only change is that we "duck" while eval_frame
is called. Since this technique is used for every
recursive call, the C stack never grows.

This was the simple case which is easy to understand.
A little more complicated is switching between
uthreads/coroutines. The area which I labelled with
"top" doesn't need to be always identical. There are
situations, like the imports at python startup time,
where the topmost interpreter gets a different stack
location than the one which drives the interactive
console, for instance.
I'm not totally clear yet what exactly needs to be
saved/restored for a switch.
Maybe it would be easiest for me if I only allow
switches if the stacktop is the same?
I could use some hints from you, please think :-)

>>Seems like this could run into trouble with an optimizing
>>compiler...
>>
> 
> There may well be a conflict, but it's confined to one C 
> call, (and one that probably defies most optimizations 
> anyway). As Tim pointed out in an off-list email, there's
> deep magic required on platforms that have specialized
> HW stacks (he used ICON on SPARK as an example).


Yes, but I don't intend to switch to a different stack,
I just modify some entries and the stack pointer, nothing
else than the C compiler does. How can this be so complicated?

Well, I can't forsee it - ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net/
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
      where do you want to jump today?   http://www.stackless.com/


_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless