<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Christoph,<div dir="ltr"><br><blockquote type="cite">On Dec 7, 2020, at 9:55 AM, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">



<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Hi all, hi Eliot,</p>
<p><br>
</p>
<p>I constructed the following code snippet which evaluates to true when running it using the production execution machinery:</p>
<p><br>
</p>
<p>nil == thisContext pop</p>
<p><br>
</p>
<p>I guess this is fine, because what alternatives would the execution machinery have? It could terminate the whole VM or we could introduce something like #cannotReturn: for invalid stack frame objects. Probably the current implementation is the best despite
 an invalid position in the context stack has been addressed.</p></div></div></blockquote><div><br></div>Well, if you evaluated that snippet within some outer stack state I dare say you could generate invalid results.  For example, I would wonder what this does:<div><br></div><div>    true == (nil == thisContext pop. true)</div><div><br></div><div>and this (and the above) will likely generate different effects in the StackInterpreter and the Cog vm, because effectively the Cog JIT preprocesses the bytecodes and executes the code generated from that preprocessing, rather than a literal interpretation of the bytecode.<br><blockquote type="cite"><div dir="ltr"><div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p><span style="font-size: 12pt;">However, the simulation machinery treats the same snippet differently, and it throws:</span></p>
<p><br>
</p>
<p><span>Error: subscript is out of bounds: 0</span><br>
</p>
<p><span><br>
</span></p>
<p><span>I wonder whether it is acceptable to have diverging behaviors for such an ill-defined edge case between simulation and production (btw did I choose the right terms for them? :)). Might it a better alternative to raise a Warning (#notify:) only and
 then return nil such as the VM appears to do?</span></p></div></div></blockquote>It’s a very good question.  I’m going to provide a very lazy and pragmatic answer, forced by lack of resources to address the issue properly.  It’s clear that the behaviour is at best undefined.  It is good that the simulation produces an error. The only regrettable thing is that what is reported is a low-level error rather than a high-level one that says, fir example, “undefined behaviour encountered”.  Achieving a specification which states that this is undefined behaviour allows the JIT to get away with not dealing with the issue, and that’s important because dealing with the issue such that the JIT could detect this as an error would likely destroy lots of performance gains it is able to make by assuming it is given valid defined execution sequences.</div><div><br></div><div>That’s a long winded way of saying that, given limited resources, I’m giving the same response as a doctor that when told by a patient that it hurts when the patient does X says “then stop doing X”.<br><blockquote type="cite"><div dir="ltr"><div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p><span style="font-size: 12pt;">Best,</span></p>
<p><span>Christoph</span></p></div></div></blockquote><div><br></div><div>_,,,^..^,,,_ (phone)</div></div></body></html>