On Mon, Sep 08, 2014 at 01:09:17PM -0700, Eliot Miranda wrote:
> On Mon, Sep 8, 2014 at 11:58 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> 
> > On 08.09.2014, at 20:45, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> > Instead of creating an exception handler why not modify the interpreter to
> > answer nil?  I know the answer is that the Interpreter doesn't, and fails.
> >  But we've had years in which we could change the Interpreter to match
> > vmParameterAt: and instead of doing the good thing (have the Interpreter
> > answer nil for values answered by Cog VMs), we force the standard system to
> > waste time.  We should optimize the common case (trunk running on Cog) not
> > penalize it to cover the uncommon case (trunk running on Interpreter VM).
> >

All of the VMs, including Cog, behave identically in this regard. If you
request a VM parameter that is not understood by the VM, the primitive fails.

> >
> > Nah, if performance really was an issue we could just remove the
> > primitiveFailed in vmParameterAt:. No need to change the VM.
> >
> 
> That's a good idea.  Change the primitiveFailed to ^nil.
> 

It would be a good idea if performance was actually an issue. It is not.

This is a case where using exceptions makes good sense. If some arbitrary
VM cannot satisfy a primitive request, it should fail the primitive.
Answering nil as a flag for primitive failed is bad karma, and should
not be done unless there is a good reason for doing so. Improving the
performance of #isRunningCog is not a good reason.

BTW there is another method with the same problem:

  isRunningCogit
    "Answers if we're running on the Cog JIT"

There are no senders of #isRunningCogit in the image, so it does not need
to be fixed.  But the #isRunningCog bug was breaking the unit tests, so
it needed fixing.

Dave