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

[tim Rowledge]

I think people are confusing numbered/named and internal/external.

Whether you find the code for a prim via a simple list by indexing from a number found in the method header, or via a name held in the literal frame, the end result is pretty much identical; the pointer to the code gets put in the method cache (on plain interpreters) or into the translated ncode (on Cog VMs). Or, on Cog and for a bunch of important prims, the actual code for the prim is compiled right there into the ncode.

Internal prims - those currently in the primitiveTable and those in modules compiled to be internally linked and included in the static linking part of the VM build - are slightly faster than external prims in execution because the latter (currently but perhaps not inevitably) go via the interpreterProxy table when they need to call vm code to do things like testing a class oop or index. The internal prims simply access the global vars or functions directly. See the usages of SQUEAK_BUILTIN_PLUGIN in the VMMaker code & output sources.

It is entirely possible to have named primitives simply as part of the core vm code, for example ‘primitiveDisablePowerManager’. 

The only cost difference between numbering for primitives and naming is that the *initial* lookup for a named primitive will be a bit slower. A named, external, primitive will be even slower for the very first lookup since the module will have to be loaded. If for some reason your platform or current vm design can’t do loading of dynamic libraries you just need to compile your vm with everything internal.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
fallacio (n): speaking logical fallacies