[Vm-dev] I would not have thought I ever say that: lets have a
new primitve (was: Re: [squeak-dev] The Trunk: System-cwp.660.mcz)
smalltalk at stefan-marr.de
Wed Jan 15 09:16:58 UTC 2014
On 14 Jan 2014, at 20:01, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> I don't see the difference. In my VMs contexts are only created on demand. The issue is what kind of object proxy to provide for execution context. In VisualAge there is a proxy for a stack segment, essentially a pointer, and the VI must construct stack frames from this. In Cog there is a context which contains a hidden pointer to a single stack frame. Then there are facilities for manipulating the underlying stack through those interfaces. In VisualAge I guess one can rewrite the stack arbitrarily. In Cog, assignments to the sender, pc, stack pointer, etc are supported in the VM by manipulating the underlying stack appropriately. In both cases a context-like object is adequate. I also think that a context-like object is an appropriate proxy for a non-stack-like execution model such as continuation-passing. So viewd from this level of abstraction I think it makes no difference, and hence you might as well provide thisCOntext. You might disallow assigning to the sender in your implementation, but I don't see how thisContext per se severely constrains your implementation; it's just about where in the system (in the image or in the VM) the mapping from the activation proxy to the underlying execution context is done.
> Does this make sense?
Well, I haven’t tried yet, but providing a traditional thisContext seems to me problematic.
While most of the SOM implementation use indeed bytecodes in one form or another, as well as an explicit stack, TruffleSOM doesn’t. It is a classic ‘AST’-based interpreter. It uses the Java stack for representing quite a bit of the execution state, doesn’t have anything like linearized bytecodes, and neither an instruction pointer nor a stack pointer.
So, providing something like a generic thisContext, with the classic capabilities feels very unnatural in that setting. Providing the interface for a debugger or continuations on the other hand, should be much simpler. Hm, well, I’ll have to try it, I guess.
INRIA Lille - Nord Europe
More information about the Vm-dev