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

[David T. Lewis]

On Mon, Jul 11, 2016 at 01:48:22PM -0700, tim Rowledge wrote:
> 
> > On 11-07-2016, at 11:43 AM, Cl??ment Bera <bera.clement at gmail.com> wrote:
> > 
> > So far I understood that numbered primitives were there for performance. 
> 
> Originally they were there as the only method of looking the up, of course. Then after we added named prims for modules the prim table was indeed the route to ???fast prims??? because the lookup time was incurred too often. Then in ???04 I fixed that by expanding the method cache tables to include the function address etc and after that it made no real difference.
> 
> > 
> > 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 ?
> 
> No overhead at all for a lot of key prims since they???re compiled by the Cog to machine code - see CogObjectRepresentation>>#genPrimitiveAdd etc. Well, there would be a very small cost at Cog time I guess, at least the first time a prim is encountered. 
> 
> None of this is really crucial, it???s just a thing I think would clean up the concept of primitives and calling them.
>

We really should try to figure this out, and do whatever measurements
might be needed to determine the real impact.

As far as I can tell there are two possible reasons for using a numbered
primitive, and I do not honestly know if either is valid.

1) Porting to a new platform. The numbered primitives are (or should be)
associated with the set of essential primitives that are necessary to
bootstrap a VM on some new platform, even if that platform is not really an
operating system at all. If we make no assumptions about implementation
language, linkers, loaders, or runtime libraries, then we want the simplest
possible primitive callout mechanism that could possibly work for the set
of essential primitives.

2) Performance. If numbered primitives are actually faster for whatever reason,
then that would be a rationale for using them.

I'm pretty sure we can measure performance and find out if there really is
any difference. This may vary by platform and other factors. But if it really
does not matter, we can cross #2 off the list and not worry about it any more.

I am less sure about #1. There have been various efforts, including SqueakNOS
and others, to make VMs for minimal platforms. Maybe someone with experience
in that area can give some guidance as to whether numbered primitives are
needed for bootstrapping to a new platform (with or without a conventional
operating system).

If performance is not an issue, then we should be able to get rid of many
of the current numbered primitive assignments (this of course happens on
the image side, not the VM, as we have to carry some historical baggage for
compatibility).

And if numbered primitives are not needed for bootstrapping to new
platforms, then there is no real need for them at all. In which case
Tim is right, we should just make them go away.

Dave