Re: FW: A "CJT" in python

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

Jim and all,
   This is an important point. The workspace pointer is NOT equivalent
to a stack pointer, for at least two reasons:
   (1) Its requirements are static and known at load time. There is
never any overflow (that is why it can expand DOWNWARD to a fixed
bottom memory address).
   (2) As a result, non-Transputer CSP (occam) implementations can
run multitasked without stack saving. In DOS, I ran over 200
multitasked communicating programs on a single shared stack of 10 KB or
so, using only the 30 stack bytes per program which was required by the
system for nested program execution (a load listing run from the
command prompt on top would show all 200 programs), plus a little on
top for interrupts and certain instructions.

> From: <jm40@xxxxxxxxx>
> To: <java-threads@xxxxxxxxx>
> Subject: FW: A "CJT" in python
> Date: Sun, 29 Oct 2000 12:17:55 -0000
> Message-ID: <000401c041a2$4506e100$661d02d5@JIM1>
>
> > -----Original Message-----
> > From: Lawrence Dickson [mailto:tjoccam@xxxxxxxxxxxxx]
> > Sent: 28 October 2000 23:11
> > To: Andrew Cooke; java-threads@xxxxxxxxx; occam-com@xxxxxxxxx
> > Subject: Re: A "CJT" in python
> >
> >
> > It could be favorable to CSP... "stackless" hints at
> > that, since occam on the Transputer was stackless (except
> > for a very small interrupt stack) and other implementations
> > (such as the one I worked on in DOS) can also be stackless.
> > Larry Dickson
>
> Well...  I'm not sure I'd agree that the Transputer was "stackless".  The
> workspace pointer is basically another name for the stack pointer is it not?
> Perhaps I am mis-understanding the idea of "stackless".

At context switching between processes of the same priority, no stack
is saved. In my DOS implementations, small stacks would arise due to
certain instructions, but they would go away at a descheduling point.
This is all because of the static nature of occam which allows
pre-allocation of needed workspace.

>
> What the Transputer does have on it's side is a very minimal register
> context - just the Workspace Pointer needs to be saved when switching
> (although this is in part due to the implicit invalidation of the evalution
> stack (A/B/C) after any instruction that is interruptable).

Remember the Transputer could also be programmed in C, and would have
the same stack problems as any other processor. It's a language design
question.

THIS IS VERY IMPORTANT! Most modern programmers, I think, can no longer
even conceive the possibility of operating without massive stacks -
massive multiple stacks in the case of multitasking. Nevertheless it is
possible, and solves a whole lot of robustness and efficiency problems.

Larry Dickson