Stackless/microthreads merge news

[Christian Tismer]

Jeff Senn wrote:
> 
> Christian Tismer <tismer at tismer.com> writes:
> > > In fact, he commented that making C itself stackless would be too hard
> > > to really consider seriously and nobody in the community would
> > > appreciate it at all.
> >
> > Yes. It would be hard to make portable.
> > Instead, I'm trying to get rid of C and want
> > to use a language where I can control stacks
> > more easily. The last barrier in Stackless Python is
> > to make a couple of internal functions stackless as well,
> > but it is so hard in C that I need another bytecode
> > interpreter to do that.
> > Well, guess what that should be.
> 
> Hm -- I've been trying to find a way to explain the "stackless zen".
> 
> It seems that we all (people who write high level software) take the
> program stack, as a method of flow control and messaging between
> function invocation, as a given.  Really the stack is just another
> data/object type -- not any more special than a queue or a heap...

That's the right perception. The problem is that current compiler
layout doesn't give us a chance to handle the stack as yet another
data structure in a portable way.
The C stack today has the builtin promise that, after calling
some functions, you will walk back exactly in reverse order.
Stacklessness means breaking this promise.
This cannot be done with the C stack in a portable way.

> Given our usually math notation, methods of functional composition and
> early compiler/OS development I'm not surprised that the stack is
> viewed so.  (Consider as a counter example how asynchronous circuit
> design is done and microcode is developed)
> 
> IMHO this dependence on making the stack of higher importance has made
> the implementation of multi-"threaded" operating systems complex and
> limited the ways in which alternative approaches could reduce the
> difficulty of implementation of async/parallel systems.

Yes. After all, I consider the stack-oriented hardware that
is everywhere around today as a huge design mistake.
Early processors didn't have that. It evolved in support
for high level languages, and the designers stopped to
think of alternatives. Not it appears that even these high
level languages are the showstopper, and all this stack-enforcement
is completely artificial.

Stacklessness doesn't mean "no stack whatsoever". For many small
tasks, stacks are the way to go.
It means "have a stack where it makes sense, but don't be forced to."

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     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