[Vm-dev] Numbered primitives (was: Cog Primitive Performance)

[David T. Lewis]

On Wed, Apr 19, 2017 at 02:58:44PM -0700, tim Rowledge wrote:
> 
> > On 18-04-2017, at 6:46 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > 
> > I beg to differ.  First one cannot eliminate numbered primitives because named primitives are built upon them, i.e. primitive 117, primitiveExternalCall, provides the linkage machinery that named primitives use.  Then???
> 
> I don???t *think* anyone was arguing for removing number prims as a concept (although I have in the past tried to work out how one might do that, without success of course) but for cutting them back as much as possible and using the name mechanism as the default whenever possible. Which seems pretty sensible to me.
> 

Yes that is what I meant. Use the name mechanism as the default whenever possible.

My view: Primitives should be referenced by name, not number, unless there is a really
good reason for doing otherwise. By that I mean meeting one of these two conditions:

1) If, when the primitive cannot be invoked through a numeric primitive lookup, it is
difficult or impossible to port the VM to a new platform. In that case, the primitive
deserves a number in the primitive table.

2) If giving the primitive a number results in an measurable performance improvement
that would be noticed by a real user, then it should get a number.

Otherwise: Reference the primitive by name rather than by number.

> > - the named primitive mechanism nicely defines primitive modules for functionality outside the language, but otherwise doesn't offer much.  Both named and numbered primitives are opaque.
> 
> The reason Andreas & I originally did the module/plugin stuff was the huge spread of extra prims that bloomed back in the dawning of the age of dinosaurs. It was a way to easily configure the vm environment to suit your needs. Actually named prims are a tiny smidge less opaque in that you do at least get to see the name of the bit of code you need to grep for!
> 

In that case, I think that you and Andreas had it exactly right. Named primitives are
easier to grep for, and they are easier to reference in the VMMaker code. More importantly,
I can say from recent experience that trying to make sense of the variations in primitive
table assignments over time is a huge PITA that is completely avoidable through the
use of named primitives.

If this was just a VM issue, I would not worry about it one way or the other. But
numbered primitive references appear in the image, and this can (and most definitely
does) result in images that can only run on a certain specific range of VMs that
may not be easily reproduced 5 or 10 years in the future. I see this as a Very Bad
Thing, and I think that it is well worth the discipline of restricting numbered
primitives usage to prevent it happening.

Dave