<div dir="ltr">Each primitive is supposed to check the number of arguments it is called with. If the number is not what it expects, it must fail, and leave the stack untouched (so that the primitive method can run the failure code).<div><br></div><div>The same primitive can also handle different numbers of arguments, e.g.</div><div><div><br></div><div><font face="monospace, monospace" style="background-color:rgb(238,238,238)">SystemNavigation default browseAllSelect: [:cm | cm primitive = 254]</font></div></div><div><br></div><div><div>- Bert -</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 20, 2016 at 3:41 PM, Ben Coman <span dir="ltr">&lt;<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Just checking my understanding of how something works.  I think I<br>
heard somewhere that its the primitive&#39;s job to drop its arguments off<br>
the stack.<br>
<br>
So it would seem(??) that starting with VM1/Image1 having primitive<br>
#primX ... if VM2 had modified that primitive to take an optional<br>
argument such that Image2 invoked that primitive as #primX: ,  then<br>
Image2 could not be backward compatible with VM, because Image2 would<br>
be adding the argument to the stack that would not be removed by VM1.<br>
<br>
The reason I ask is I was considering having a go at the VM clock<br>
improvements issue [1] I logged.  As well as implementing the clock<br>
skewing algorithm Eliot suggested, I was also wanting to provide Image<br>
access to the two clocks used by that algorithm - so the algorithm<br>
performance could be monitored from the Image.<br>
<br>
cheers -ben<br>
<br>
[1] <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/36" rel="noreferrer" target="_blank">https://github.com/<wbr>OpenSmalltalk/opensmalltalk-<wbr>vm/issues/36</a><br>
</blockquote></div><br></div>