<div dir="ltr"><div dir="auto">Hi Tim, hi All,<br><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Feb 12, 2023, at 10:23 AM, tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">[snip]<br><span></span><br><span>The actual primitives for Cog are *much* more complex. Whilst I wouldn't normally advise looking at the C code for the VM, in this case it might be instructive to peek at the generated gcc3x-cointerp.c file and find the primitiveTerminateTo() routine.</span><br></div></blockquote><div><br></div>No, no and thrice times no!! :-)<span class="gmail_default" style="font-size:small"> There is a story I'll tell you at the end if the email, but first...</span><div><br></div><div>The only times to look at this code are probably</div><div>- when one is checking that Slang has generated the correct code from the VMMaker.oscog package’s Smalltalk code</div><div>- when debugging the VM at the C level instead of the Smalltalk level </div><div><br></div><div>If you do want to look at the code and make sense of it look at the VMMaker.oscog code in an image.  There is a script, image/buildspurtrunkvmmaker64image.sh <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkvmmaker64image.sh</a>, that will build such an image.</div><div><br></div><div>The VM’s interpreter code is the hierarchy of StackInterpreter.</div><div>The VM’s JIT code is the hierarchies of</div><div><span class="gmail_default" style="font-size:small">    </span>Cogit</div><div><div class="gmail_default" style="font-size:small">    CogAbstractInstruction</div><div class="gmail_default" style="font-size:small">    CogObjectRepresentation</div><div class="gmail_default" style="font-size:small">The VM's memory managers are</div><div class="gmail_default" style="font-size:small">    SpurMemoryManager</div><div class="gmail_default" style="font-size:small">    NewObjectMemory</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But on the "do..." menu you'll find</div><div class="gmail_default" style="font-size:small">    openCogSpurMultiWindowBrowser</div><div class="gmail_default" style="font-size:small">    openCogitMultiWindowBrowser</div><div class="gmail_default" style="font-size:small">    openSpurMultiWindowBrowser</div><div class="gmail_default" style="font-size:small">et al which make it much easier to browse this admittedly rather complex system. And in finding methods MessageNames is your friend. It understands patterns separated by semicolons.  So a MessageNames on *terminateTo* will find the code you;re looking for.</div><div><br></div><div class="gmail_default" style="font-size:small">You'll also find workspaces to help you run the VM simulator, generate VM sources, JIOT a method, etc.</div><br><div><br></div><div><div class="gmail_default" style="font-size:small">Now that story. Once upon a time Alan Kay's team were working at Hewlett-Packard. HP were trying to sell 64-bit machines based on the 64-bit HPPA RISC chip. One of the customers used Squeak.  So a team of HP engineers tried to port Squeak to 64-bits by starting with interp.c, the generated code for the 32-bit BackToTheFuture interpreter VM. They spent at least 6 months, and failed.  Alan was alerted and Dan Ingalls, Ian Piumarta and others did a very quick port, 3 months, IIRC, and this is why the original 64-bit Squeak stull only had 31-bit SmallIntegers, etc, [and is why I don't consider this a "real" 64-bit implementation.  It's merely a widening of the 32-bit implementation so that one can have 64-bit oops, but otherwise wastes lots of opportunities (64-bit Spur has 3 tagged (immediate) types, SmallInteger, Character, and SmallFloat64; it also supports 8-bit, 16-bit, 32-bit and 64-bit integer arrays, etc)].</div><br></div><div><div class="gmail_default" style="font-size:small">The moral of this tale is that, no matter how good you are, you won't make head nor tail of the overall VM architecture and functionality looking at Slang's output. The only proper place to try and make sense of the VM is the level at which it is written and debugged, which is in Smalltalk.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default"><ol class="gmail-bibliography" style="box-sizing:border-box;margin-top:0px;margin-bottom:9.5px;list-style-type:none;color:rgb(51,51,51);font-family:Lato,Helvetica,Arial,sans-serif"><li style="box-sizing:border-box;padding:10px 0px"><span id="gmail-ingalls_2020_spe_vm_simulation" style="box-sizing:border-box">Daniel Ingalls, Eliot Miranda, Clément Béra, and Elisa Gonzalez Boix.<span class="gmail-Apple-converted-space"> </span><b style="box-sizing:border-box">“Two Decades of Live Coding and Debugging of Virtual Machines through Simulation.”</b><i style="box-sizing:border-box">Software: Practice and Experience</i><span class="gmail-Apple-converted-space"> </span>50, no. 9 (2020): 1629–50.</span><span class="gmail-Apple-converted-space"> </span><a href="https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.2841" target="_blank" style="box-sizing:border-box;color:rgb(27,60,129);text-decoration:none">https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.2841</a>.</li><li style="box-sizing:border-box;padding:10px 0px"><span id="gmail-miranda_2018_tds" style="box-sizing:border-box">Eliot Miranda, Clément Béra, Elisa Gonzalez Boix, and Dan Ingalls.<span class="gmail-Apple-converted-space"> </span><b style="box-sizing:border-box">“Two Decades of Smalltalk VM Development: Live VM Development Through Simulation Tools.”</b>In<span class="gmail-Apple-converted-space"> </span><i style="box-sizing:border-box">Proceedings of the 10th ACM SIGPLAN International Workshop on Virtual Machines and Intermediate Languages</i>, 57–66. VMIL 2018. New York, NY, USA: ACM, 2018.</span><a href="https://doi.acm.org/10.1145/3281287.3281295" target="_blank" style="box-sizing:border-box;color:rgb(27,60,129);text-decoration:none">https://doi.acm.org/10.1145/3281287.3281295</a>.<br></li><li style="box-sizing:border-box;padding:10px 0px">Available on request.</li></ol></div><br></div><div>_,,,^..^,,,_ (phone)</div><div><br><blockquote type="cite"><div dir="ltr"><span></span><br><blockquote type="cite"><span>On 2023-02-12, at 7:53 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hi Jaromir,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>On Feb 12, 2023, at 5:13 AM, Jaromir Matas <<a href="mailto:mail@jaromir.net" target="_blank">mail@jaromir.net</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hi,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>What is the purpose of the primitive 196 Context>>#terminateTo:?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Strongly related to prim 195 & 197. You have to check each context up the chain to see what exceptions might be dealt with & by which context.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>My understanding is prim 195 (#findNextUnwindContextUpTo:) searches for unwind contexts and prim 197 (#findNextHandlerContextStarting) searches for handler context. But prim 195 (#terminateTo:) is unclear to me. #terminateTo comment says:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>"Terminate all the Contexts between me and previousContext, if previousContext is on my Context stack. Make previousContext my sender."</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Which doesn't say much except it's nilling all context's pc and sender between self and the argument. I wonder what else it does behind the scenes and why :)</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>In a paper from 2009 Eliot wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>"[...] there’s a primitive terminateTo: that does something similar to the context nilling in non-local return. It is a little simpler than non-local return (although not much) but it is just a variation on the same theme so I’ll spare you."</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>I wish Eliot didn't spare us :) Other than that I haven't found any further info.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Because the primitive 196 dates back to 2001 I'm unable to judge whether it's still essential to nil the intermediate contexts (to free stack pages or something).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>In particular I'm trying to understand whether the use of #terminateTo *primitive* in #resumeEvaluating: and #resume:through: is essential or not.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>There are three things that primitive 296, Context>>terminateTo: does, or rather there are two things it does, and it does them in a particular way. It sets senders and pcs of intervening contexts to nil. It sets the sender of the receiver to the argument. If does this atomically.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I can’t say whether the last of these is necessary. If it is, then the primitive is needed, essential. But the primitive merely optimized the former two operations.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>In the StackInterpreter & CoInterpreter it provides a significant optimization because</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>- the primitive avoids creating any contexts; if if were not implemented primitively then  contexts would have to be created for all intervening frames, merely to throw unreferenced ones away</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>- intervening stack pages can be freed without looking at their contents </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>So the primitive is an important optimization for Stack/CoInterpreter.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>But I suspect that atomicity is not crucial and that therefore the terminateTo: primitive is only an optimization.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span> Any additional info greatly appreciated.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>HTH</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Thanks,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Jaromir</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>--</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Jaromír Matas</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:mail@jaromir.net" target="_blank">mail@jaromir.net</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>From: tim Rowledge</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Sent: Sunday, February 12, 2023 5:18</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>To: The general-purpose Squeak developers list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Subject: Re: [squeak-dev] Questions about FullBlock closures</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On 2023-02-11, at 4:04 PM, Jaromir Matas <<a href="mailto:mail@jaromir.net" target="_blank">mail@jaromir.net</a>> wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>If I may, I have a question here: What is the purpose of the primitive 196 Context>>#terminateTo:? Why primitive and why terminating each context along the way? Naively, I'd think checking the two contexts are in the same sender chain and patching them via privSender should do but I'm sure I'm missing something here :)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Exception handling stuff. Strongly related to prim 195 & 197. You have to check each context up the chain to see what exceptions might be dealt with & by which context. Look at e.g. Process>>#terminate for some context.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>tim</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>--</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>When flying inverted, remember that down is up and up is expensive</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span></span><br><span>tim</span><br><span>--</span><br><span>tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a></span><br><span>Useful random insult:- Life by Norman Rockwell, but screenplay by Stephen King.</span><br><span></span><br><span></span><br><span></span><br></div></blockquote></div></div></div></div>