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

Clément Bera bera.clement at
Mon Jul 11 18:43:16 UTC 2016

Hi all,

So far I understood that numbered primitives were there for performance.

Let's talk for example of (SmallInteger>>#+). What is the overhead if we
have it as a named primitive and not a numbered primitive ? Is there even
overhead ?

Depending on that overhead I would advise for or against the total removal
of numbered primitives.

In any case we should continue to keep a very limited number of them.

On Mon, Jul 11, 2016 at 7:09 PM, tim Rowledge <tim at> wrote:

> > On 11-07-2016, at 9:59 AM, David T. Lewis <lewis at> 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;
> Useful random insult:- Proof that evolution CAN go in reverse.
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Vm-dev mailing list