Michael van der Gulik schrieb:
>
>
> On Feb 11, 2008 12:29 PM, tim Rowledge <tim at rowledge.org
> <mailto:tim at rowledge.org>> wrote:
>
>
>
...
>
>     A stack is linear last-in first-out. In C you branch to a
>     subroutine, a stackframe is built on the stack and you excute code
>     based on that. When you return from the subroutine all the memory
>     in that stackframe is known to be free to reuse immediately if
>     wanted by the next subroutine call. 
>
...
>
>
> Oh - that's what he meant by a linear stack - stack frames are
> contiguous in memory.
Actually, it's pretty simple to use a linear stack in memory without
giving up the semantics of Smalltalk blocks.
There are two uses of the creating context in a block:
1. Access to variables shared between the block and the context or other
blocks.
2. Non-local return (i.e. a method return from a block)
For the first kind of use, variables could be placed into a separate
array whose lifetime is independent of that of the creating context.
The non-local return is a bit more tricky. One possibility is to keep a
pointer to the stack segment and the position of the frame within that
segment in the array of variables, and point to that array from the
stack frame. When a non-local return is attempted, the return code must
check whether the block is executed in the same process as the creating
context, and whether the frame corresponding to the creating context
still exists (by just checking whether it points to the array of variables).

VA Smalltalk does something like that.
For non-reflective block semantics, that's enough. I think it is not too
difficult to do continuations as well using such a stack architecture.
In the case of VA, things get complicated mostly because it is not
possible to manipulate the stack frame array directly without causing
all sorts of havoc. I think Instantiations is working on this to allow
Seaside to run on VA ST.

One nice side effect of a "linear" stack without separate context
objects is that you can overlap stack frames, i.e. objects pushed onto
the sender's stack frame in preparation can become part of the called
method's stack frame without copying. Of course, you need to get the
frame linkage slots out of the way somehow, but that's not too difficult
either.

The implementations in BrouHaHa and VW which try to hide the "cheating"
are ingenious, but I think that a linear stack implementation can be
exposed to the image without causing too much trouble, making the VM
design much simpler.

Cheers,
Hans-Martin