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

tim Rowledge tim at rowledge.org
Wed Apr 19 21:58:44 UTC 2017


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

Whilst it is true that a numbered prim costs less space in the calling method, we don’t have a huge number of them to worry about unless a large glob of code that makes use of a lot gets loaded. In which case, that’s good and proper and obviously we wouldn’t want a gazillion prims in the default vm (despite which we have a large number of plugins generally compiled in as internal plugins in most VM builds!) and paying the cost only when they’re used is smart.
> 

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

> 
> Instead I would like to see numbered primitives used for core language facilities; those needed in a headless image, and see some numbered primitives

> [snippety-snip]

>  be moved out into suitable modules (GUIPlugin for example).

Yes. Numbered prims ought to be those that make the barest system run and that make it possible to expand. 

>  I would also like the linking machinery to be lifted out of the VM into the image.  The machinery for searching for libraries and plugins is convoluted with the machinery for searching the tables of named primitives within plugins.  All would be much cleaner and transparent if reimplemented in terms of a handful of primitives, imagine loadLibraryOrPlugin, getPluginNameTable, and these being handled in a primitiveFailFor: with named primitives answering an error code such as #'not yet linked' on first invocation.

We’d probably have to have a single rather monstrous prim that could do the simplest form of plugin load/hookup in order to get started; since using any file prims would require a file plugin to be loaded which… .etc. Once you get to deciding to load a proper filesystem you can use those prims to do any clever searching for plugins around your disc or network. It would probably mean requiring that plugin files are kept in one and only one place so as to avoid the search-two-thousand-places-depending-on-PATH-and-Moon code within the vm code.

Like so many other subjects (graphics, anyone?) we’ve discussed this a fair  few times in the past and if we have a good plan for actually doing it I’m all for it.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: LOW: Launch on Warning




More information about the Vm-dev mailing list