I'm not really all that up to speed on seaside but my understanding is that 
it is based upon continuations so I'll interpret the question as whether or 
not it would be possible to implement continuations on top of the Digitalk 
VMs.  Without researching the details further I'm not completely sure but I 
believe that the answer would be yes.  Once the stack had been reified as a 
stack object it was fully mutable from Smalltalk code.  This capability was 
certainly used by the debugger and by other subsystems. However, Digitalk 
never documented the reified stack format and I believe that the format 
actually varied between various Digitalk VMs so code that manipulated it was 
dependent upon the underlying VM.

I think what we are really talking about is alternatives for laying the 
design of a Smalltalk implementation and at which layer (and using which 
implementation technology) various abstractions are implemented. A three 
layered execution context implementation  seems quite plausible:
    layer 0:  "native" stack used for interpretation or direct execution of 
JITed bytecode
    layer 1:  native stack reified as a stack object
    layer 2: discrete context objects implemented as a facade over the stack 
object

Translation between layers 0&1 would probably be implemented using highly 
optimized code that was part of the VM.  Translation between layers 1&2 
would be done (probably lazily) by Smalltalk code.  Digitalk neglected to 
formally provide layer 2...

(I quoted "native" stack above because this might or might nor directly 
correspond to processor stack. In some of our implementations we used two 
parallel stacks for execution.  One that we called the "control stack" 
corresponded to the processor stack and contained return addresses and other 
control information including pointers into the second stack.  The second 
stack was the "object stack" and only contained OOPS.  All arguments and 
method/block temps were stored on the object stack. This greatly simplified 
scanning the stack roots by the GC and made if very easy to reify it as an 
array object. )

Allen


----- Original Message ----- 
From: "stephane ducasse" <stephane.ducasse at free.fr>
To: "Allen Wirfs-Brock" <allen at wirfs-brock.com>
Cc: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, January 21, 2007 1:03 PM
Subject: Re: Stack reification and JIT interaction question


> Thanks Allen
>
>> BTW, its interesting that Digitalk's VMs did not have an explicit 
>> thisContext operation and never bothered to have explicit context 
>> objects. When necessary, the execution stack was reified into 
>> unstructured array objects.  If Smalltalk code needed to analyze  these 
>> reified stacks they had to do all the work to parse them into  distinct 
>> activation records. Of course, using some context-like  facade objects 
>> was a big help to such stack processing.  In  hindsight, the absence of 
>> thisContext never seemed to be a major  impediment for VisualSmalltalk 
>> and its absence gave the VM designer  a bit more flexibility in the 
>> design of the actual execution  environment.
>
> do you think that seaside could have been built on top Digitalk?
> I have the impression that it would have been more difficult. Do I 
> interpret correctly that in Digitalk you could not
> change the stack from within Smalltalk?
>
> Stef