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

[Eliot Miranda]

Hi David,

On Tue, Apr 18, 2017 at 3:41 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> On Tue, Apr 18, 2017 at 09:57:54AM -0700, Cl??ment Bera wrote:
> >
>
> <snip>
>
> > For each primitive, we need to evaluate the performance with and without
> > the primitive. In each case, we either move the primitive to numbered
> > primitive or we just use normal Smalltalk code.
>
> Please no more numbered primitives. We should be eliminating numbered
> primitives,
> not adding more.
>
> The only justification I can see for a numbered primitive today is to
> identify
> it as one of the small number of primitives that absolutely must be
> available
> when porting the VM to a new platform, especially if that platform may not
> easily support the loading of functions by name. Aside from that, we should
> insist that /all/ primitives be named primitives.
>

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

- numbered primitives are compact in terms of metadata (3 bytes per
method); named primitives need the 4 slot literal to hold them, the name
symbol and the module name.  In the VM they also add overhead with the
various string tables to refer to them.  These tables are compact for
numbered primitives, and there is a table in the interpreter and a
different table in the JIT; the tables for named primitives are much less
compact, and tedious to search, bulking up the code still further.

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

Instead I would like to see numbered primitives used for core language
facilities; those needed in a headless image, and see some numbered
primitives (for example primitiveMousePoint primitiveTestDisplayDepth
primitiveSetDisplayMode primitiveInputSemaphore primitiveGetNextEvent
primitiveInputWord primitiveBeCursor primitiveBeDisplay
primitiveScanCharacters primitiveScreenSize primitiveMouseButtons
primitiveKbdNext primitiveKbdPeek) be moved out into suitable modules
(GUIPlugin for example).  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.
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170418/9a9f446d/attachment.html>