<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 6 May 2018 at 16:56, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On 10 June 2016 at 20:17, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Hi Ben,<br>
<br>
    this time I'll try and answer your question rather than my brain fart...<br>
<span class="gmail-m_8125352785573086459gmail-"><br>
> On Jun 9, 2016, at 6:46 PM, Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> wrote:<br>
> <br>
> <br>
</span><span class="gmail-m_8125352785573086459gmail-">> Just curious about the difference in instructionPointer between these two...<br>
> <br>
> StackInterpreter>>transferTo:<br>
>     self assertValidExecutionPointe: instructionPointer + 1 r:<br>
> framePointer s: stackPointer.<br>
> <br>
> <br>
> CoIntepreter>>transferTo:from:<br>
>    self assertValidExecutionPointe: instructionPointer r:<br>
> framePointer s: stackPointer.<br>
<br>
</span>In the StackInterpreter, as in the context Interpreter the next bytecode is fetched by pre-incrementing the instructionPointer and then fetching the byte it points to.  Hence it may point to before the first bytecode and hence the + 1 above.  1 is subtracted from a context's pc (2 actually cuz pc is 1-relative and instructionPointer is 0-relative) to derive instructionPointer.<br>
<br>
In the Cog VM instructionPointer may also be a machine code pc. So rather than add one, which only makes sense for interpreted methods, the CoInterpreter's assertValidExecutionPointer:s: allows for the - 1 if a frame us interpreted.  The StackInterpreter's method predates the CoInterpreter.<br></blockquote><div><br></div><div><br></div></span><div>I was just wandering in the vicinity of this again, and had a new query...</div><div><br></div><div>What is the semantic difference in the naming of the arguments (i.e. lsp<=> lisp  and  lfp<=>lifp)  </div><div>between.... ?</div><div>StackInterpreter >> assertValidExecutionPointe: lip    r: lfp    s: lsp    imbar: inInterpreter    line: ln </div><div>CoInterpreter     >> assertValidExecutionPointe: lip    r: lifp    s: lisp   imbar: inInterpreter    line: ln<br></div><div><br></div><div>because search/replacing makes it easier to diff the two methods... </div><div><a href="https://www.diffchecker.com/CL32EXql" target="_blank">https://www.diffchecker.com/<wbr>CL32EXql</a><br></div><div><br></div><div>This shows the StackInterpreter method refactored slightly to extract "methodField" variable similar to the CoInterpreter </div><div>making it easier to compare the two, i.e. red-line-16 and green-line-18 are identical, </div><div>but red-line-13 and green-line-14 set "methodField" using different messages, which however have identical definitions.</div><div><br></div><div>StackInterpreter >> frameMethod: theFP</div><div><span style="white-space:pre-wrap">        </span><inline: true></div><div><span style="white-space:pre-wrap">     </span><var: #theFP type: #'char *'></div><div><span style="white-space:pre-wrap">      </span>^stackPages longAt: theFP + FoxMethod</div><div><br></div><div><div>CoInterpreter >> frameMethodField: theFP</div><div><span style="white-space:pre-wrap">   </span><inline: true></div><div><span style="white-space:pre-wrap">     </span><var: #theFP type: #'char *'></div><div><span style="white-space:pre-wrap">      </span>^stackPages longAt: theFP + FoxMethod</div></div><div><br></div><div>Would it be reasonable to change red-line-13 to send #<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">frameMethodField:<span>  </span></span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">instead?  Hopefully my slight rearrangement of the asserts in red okay.</span></span></span></div><div></div></div></div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">========================</div><div class="gmail_extra">I found it a bit convoluted following where CoInterpreter overrides StackInterpreter >> frameIsBlockActivation: </div><div class="gmail_extra"><br></div><div class="gmail_extra">    StackInterpreter >> frameIsBlockActivation: theFP "<Integer>"</div><div class="gmail_extra"><span style="white-space:pre"> </span><inline: true></div><div class="gmail_extra"><span style="white-space:pre">    </span><var: #theFP type: #'char *'></div><div class="gmail_extra"><span style="white-space:pre">     </span>^(stackPages byteAt: theFP + FoxFrameFlags + 3) ~= 0</div><div class="gmail_extra"><br></div><div class="gmail_extra">    CoInterpreter >>  frameIsBlockActivation: theFP "<Integer>"</div><div class="gmail_extra"><span style="white-space:pre">        </span><inline: true></div><div class="gmail_extra"><span style="white-space:pre">    </span><var: #theFP type: #'char *'></div><div class="gmail_extra"><span style="white-space:pre">     </span>^(self isMachineCodeFrame: theFP)</div><div class="gmail_extra"><span style="white-space:pre">               </span>ifTrue: [self mframeIsBlockActivation: theFP]</div><div class="gmail_extra"><span style="white-space:pre">           </span>ifFalse: [self iframeIsBlockActivation: theFP]</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">But I notice  StackInterpreter >> frameIsBlockActivation: </div><div class="gmail_extra">is identical to...</div><div class="gmail_extra">    CoInterpreter >> iframeIsBlockActivation: theFP "<Integer>"</div><div class="gmail_extra"><span style="white-space:pre">  </span><inline: true></div><div class="gmail_extra"><span style="white-space:pre">    </span><var: #theFP type: #'char *'></div><div class="gmail_extra"><span style="white-space:pre">     </span>^(stackPages byteAt: theFP + FoxIFrameFlags + 3) ~= 0</div><div class="gmail_extra"><br></div><div class="gmail_extra">while...</div><div class="gmail_extra">StackInterpreter >> iframeIsBlockActivation: theFP "<Integer>"</div><div class="gmail_extra"><span style="white-space:pre">      </span>^self frameIsBlockActivation: theFP</div><div class="gmail_extra"><br></div><div class="gmail_extra">So reversing StackInterpreter's definitions of these two methods thus...</div><div class="gmail_extra">    StackInterpreter >> iframeIsBlockActivation: theFP "<Integer>"</div><div class="gmail_extra"><span style="white-space:pre">      </span><inline: true></div><div class="gmail_extra"><span style="white-space:pre">    </span><var: #theFP type: #'char *'></div><div class="gmail_extra"><span style="white-space:pre">     </span>^(stackPages byteAt: theFP + FoxFrameFlags + 3) ~= 0</div><div class="gmail_extra"><br></div><div class="gmail_extra">    StackInterpreter >> frameIsBlockActivation: theFP "<Integer>"</div><div class="gmail_extra"><span style="white-space:pre">       </span>^self iframeIsBlockActivation: theFP</div><div class="gmail_extra"><br></div><div class="gmail_extra">makes the existing CoInterpreter override clearer... </div><div class="gmail_extra">    CoInterpreter >>  frameIsBlockActivation: theFP "<Integer>"</div><div class="gmail_extra"><span style="white-space:pre">     </span><inline: true></div><div class="gmail_extra"><span style="white-space:pre">    </span><var: #theFP type: #'char *'></div><div class="gmail_extra"><span style="white-space:pre">     </span>^(self isMachineCodeFrame: theFP)</div><div class="gmail_extra"><span style="white-space:pre">               </span>ifTrue: [self mframeIsBlockActivation: theFP]</div><div class="gmail_extra"><span style="white-space:pre">           </span>ifFalse: [self iframeIsBlockActivation: theFP]</div><div class="gmail_extra"><br></div><div class="gmail_extra">and also CoInterpreter >> iframeIsBlockActivation becomes redundant.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Can I submit a changeset for these?</div><div class="gmail_extra"><br></div><div class="gmail_extra">cheers -ben</div></div></div>