[Vm-dev] Is there a smarter way to get the performance of numbered prims without the headaches? (was: Signed at:[put:] primitives for bits classes)

[David T. Lewis]

On Wed, Jun 20, 2018 at 12:53:29PM -0700, Eliot Miranda wrote:
>  
> On Wed, Jun 20, 2018 at 12:24 PM, tim Rowledge <tim at rowledge.org> wrote:
> >
> > > On 20-06-2018, at 11:46 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > >
> > > I propose extending the semantics of 164 & 165 so that they match 60 & 61,
> > > except that they provide signed access to 8, 16, 32 & 64 bit pure bits
> > > formats, and providing JIT implementations for maximum performance.  Doing
> > > so should be easy; they are very close to the JIT implementations of 60 & 61.
> > >
> > > Once this is done we could eliminate use of 143 & 144 if we changed
> > > SoundBuffer to use primitives 164 & 165 and to have a
> > > variableDoubleWordSubclass: format.
> >
> > Sounds like a sensible simplification to me; less code is better code in
> > general! How many releases should we go through before removing 143/4 ?
> 
> I don't think it's pressing to remove them.  They're not very complex and
> they're layered on top of existing Interpreter support for at:put:
> (commonAt et al).

Let me take this as an opportunity to issue an official RFT (Request for
Fresh Thinking).

Starting with three assertions that I claim to be true:

  1) Numbered primitives are needed for performance, required by the the JIT.

  2) Named primitives are good.

  3) Numbered primmitives are evil.

Is there some way that we might achieve the benefits of numbered primitives
for performance, while also using named primitives on the image side for
maintainability and comprehension?

In other words, could we invent some scheme whereby primitives are identified
by name in the image, and those names become associated with primitive numbers
at load time? Here, "load time" is a hand-waving reference to either "assign
the numbers at image load time" or "assign an integer primitive number at
the time of first resolving the primitive name to a function address".

In the image, named references to primitives are good. In the VM, integer
references to primitive functions are good. Is it possible to have both?

I am thinking that a solution might involve statically defined primitive
numbers assigned in #initializePrimitiveTable, augmented by dynamically
assigned primitive numbers allocated at primitive function load time.

Dave