<div dir="ltr">Hi Matthias,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 8:40 AM, matthias.springer <span dir="ltr"><<a href="mailto:me@matthiasspringer.de" target="_blank">me@matthiasspringer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Eliot,<br>
<br>
OK, so "thisContext basicSize" should return the value of the stack pointer.<br>
Thank you for the explanation. I think I got it working now and have a<br>
better understanding of how thisContext works.<br>
<br>
What I am still wondering is how "ContextPart>>stackPtr" works and what its<br>
purpose is (why not just call the primitive). The method comment says that<br>
it should only be used in the inspector etc.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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 <a href="http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/">my blog post on context-to-stack mapping</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>In the long-form inst var access then, if the index is found to be <= 2 and the receiver is a married context then</div><div>a) on fetch the value of the inst var is computed from the context's stack frame</div><div>b) on store the context will typically be divorced and converted into a vanilla context</div><div><br></div><div>Does this make sense?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, interestingly, I ran the previously mentioned code in the same image<br>
(Squeak 4.5 or so...) but with different underlying VMs, so the bytecode is<br>
actually the same; still the VMs behave differently. I was expecting that<br>
"thisContext" behaves the same on all VMs, but that does not seem to be the<br>
case.<br></blockquote><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Still need to look into the Spur bootstrapping...<br></blockquote><div><br></div><div>and remember I'm very happy to give you a tour of the code, e.g. using Skype, if you'd like it. Welcome!</div></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>