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

David T. Lewis lewis at mail.msen.com
Tue Jul 12 00:13:50 UTC 2016


On Tue, Jul 12, 2016 at 07:58:11AM +0800, Ben Coman wrote:
> 
> On Tue, Jul 12, 2016 at 7:35 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > 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).
> 
> I guess this will be important to me when I get back to looking at
> porting to the Xen Rump kernel.
> cheers -ben
> 

That is the sort of thing I had in mind. But what I do not know is whether
using numbered or named primitives for the callout would make any difference
to you if you were bringing up a new kind of VM on the Xen Rump kernel.
Maybe it would be just as easy/difficult either way?

Dave

> 
> >
> > 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
> >


More information about the Vm-dev mailing list