<div dir="ltr">Hi David,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 18, 2017 at 3:41 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
On Tue, Apr 18, 2017 at 09:57:54AM -0700, Cl??ment Bera wrote:<br>
><br>
<br>
<snip><br>
<br>
> For each primitive, we need to evaluate the performance with and without<br>
> the primitive. In each case, we either move the primitive to numbered<br>
> primitive or we just use normal Smalltalk code.<br>
<br>
Please no more numbered primitives. We should be eliminating numbered primitives,<br>
not adding more.<br>
<br>
The only justification I can see for a numbered primitive today is to identify<br>
it as one of the small number of primitives that absolutely must be available<br>
when porting the VM to a new platform, especially if that platform may not<br>
easily support the loading of functions by name. Aside from that, we should<br>
insist that /all/ primitives be named primitives.<br></blockquote><div><br></div><div>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...</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>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.</div></div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>