NumberedPrimitives must die! (Was: Re: [Vm-dev] VM Maker: VMMaker.oscog-topa.1900.mcz)

[Levente Uzonyi]

IIRC numbered primitives are still a lot quicker (in some important 
cases), because they can directly access the VM internals. I may be wrong 
though.

Levente

On Mon, 11 Jul 2016, tim Rowledge wrote:

>
>
>> On 11-07-2016, at 9:59 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>>
>> I think that as a general policy, it is best never to add a numbered
>> primitive unless there is a specific need to do so. So if you can call the
>> primitive by name, then it would be a good idea to roll back the change.
>
> For a long time I’ve harboured the dream of getting to totally remove the concept of numbered primitives.
>
> I would posit a simple flag in the compiled method header that says ‘primitive name used here’. That would clue in the VM to do the lookup in the normal named-prim manner. The prim code pointer would be cached appropriately - as it is now - and the Cog would have no special problems with it that I can see.
>
> To improve the cleverness of the system I’d have a flag somewhere (set via a named prim, of course) that lets the VM know whether to use the default name/module lookup or to give up and  return an error that would then trigger an image side policy to handle the problem. This would allow us to do crazy things like looking at some database/webstie/paper-tape to find out from where to load a plugin and install it. Or generate a new chunk of code to install somehow. And clearly, then retry the failed call if appropriate.
>
> Clearly, anyone telling the VM they want to take over the prim-call-failure policy would need to know what they are doing. :-J
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Proof that evolution CAN go in reverse.
>
>
>