[Vm-dev] Re: [squeak-dev] Trying to understand thisContext

[Eliot Miranda]

Hi Matthias,

On Tue, Jun 9, 2015 at 8:40 AM, matthias.springer <me at matthiasspringer.de>
wrote:

>
> Hi Eliot,
>
> OK, so "thisContext basicSize" should return the value of the stack
> pointer.
> Thank you for the explanation. I think I got it working now and have a
> better understanding of how thisContext works.
>
> What I am still wondering is how "ContextPart>>stackPtr" works and what its
> purpose is (why not just call the primitive). The method comment says that
> it should only be used in the inspector etc.
>

So I *think* that in an Interpreter VM, stackPtr simply answers the stackp
inst var and that gets written back to a context on send, so given that
stackPtr is sent, even to thisContext, stackp will reflect the relevant
value.  i.e. in an Interpreter VM there's nothing magic about the stackp
inst var.

But in a StackInterpreter or CoInterpreter stackp is indeed handled
specially.  A context may or may not be "married", i.e. having an
associated stack frame which it is a proxy for.  If it isn't married, then
stackp holds the actual value.  If the context /is/ married then the VM
needs to compute stackp from the stack frame.  You can read my blog post on
context-to-stack mapping
<http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/>
for details.  So the VM needs to handle sender, pc and stackp inst var
access in context specially, and these are inst vars 0, 1 & 2.

For efficiency the VM /must/ avoid checking on every 0, 1 or 2 offset inst
var access whether the receiver is a context.  It would kill performance.
The bytecode set has at least two forms of inst var fetch bytecode, a short
form, typically for inst vars 0 through 15, and a long form, typically for
offsets > 15.  The bytecode compiler arranges to generate the long form for
all ContextPart inst vars.  So the VM can assume it doesn't need to check
in the short form bytecodes, and the check in the kong form bytecodes is
cheap, because a) it checks if the index is <= 2 (a very cheap check)
before checking for a context receiver, and b) the long form will only be
used for index < 15 for contexts and subclasses, so the expensive check for
the receiver being a context is only performed on contexts and subinstances.

In the long-form inst var access then, if the index is found to be <= 2 and
the receiver is a married context then
a) on fetch the value of the inst var is computed from the context's stack
frame
b) on store the context will typically be divorced and converted into a
vanilla context

Does this make sense?


Also, interestingly, I ran the previously mentioned code in the same image
> (Squeak 4.5 or so...) but with different underlying VMs, so the bytecode is
> actually the same; still the VMs behave differently. I was expecting that
> "thisContext" behaves the same on all VMs, but that does not seem to be the
> case.
>

Hmmm, then I guess that the bug is that in the Interpreter VM the the stack
pointer is not written back into the context object on sending stackPtr?

Still need to look into the Spur bootstrapping...
>

and remember I'm very happy to give you a tour of the code, e.g. using
Skype, if you'd like it.  Welcome!
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150609/69cefbcf/attachment.htm