[Vm-dev] Signed at:[put:] primitives for bits classes

[David T. Lewis]

On Wed, Jun 20, 2018 at 07:05:38PM -0700, Eliot Miranda wrote:
>  
> Hi David,
> 
> > On Jun 20, 2018, at 4:37 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > 
> >> On Wed, Jun 20, 2018 at 11:46:26AM -0700, Eliot Miranda wrote:
> >> 
> >> Hi All,
> >> 
> >>    right now we have a lot of different at:[put:] primitive variations.
> >> Spur supports 8 bit (variableByteSubclass:), 16 bit
> >> (variableDoubleByteSubclass:), 32 bit (variableWordSubclass:) and 64 bit
> >> (variableDoubleWordSubclass:) formats natively.  V3 supports only 8 & 32
> >> bit.  This message is about simplifying things in Spur.
> >> 
> >> The primitives at: 60 & at:put: 61, provide unsigned access to 8, 16, 32 &
> >> 64 bit formats.  These primitives are implemented in the JIT for maximum
> >> performance.
> >> 
> >> The primitives at: 63 & at:put: 64, provide Character access to 8, 16, & 32
> >> bit formats (characters are in the range 0 to 2^30 - 1).  These primitives
> >> are implemented in the JIT for maximum performance.
> >> 
> >> The primitives at: 143 & at:put: 144 provide 16-bit signed access to bits
> >> classes, irrespective of format.  These are used to implement 16-bit sound
> >> samples above the 32 bit (variableWordSubclass:) format.  These primitives
> >> have no JIT implementation.
> >> 
> >> The primitives at: 165 at:put: 165 provide 32-bit signed access bits
> >> classes, irrespective of format.  These are used to implement various
> >> 32-bit signed 2's complement tables above the 32 bit
> >> (variableWordSubclass:) format.  These primitives have no JIT
> >> implementation.
> >> 
> >> Since primitives 143 & 144 don't respect the format of the underlying
> >> instance their semantics are effectively locked down.  But since, in
> >> current usage, 164 & 165 match the formats of the classes in which they're
> >> implemented, and I'm unaware of any abuses, these could be extended.
> >> 
> >> 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.
> >> 
> >> Objections?
> >> 
> > 
> > No objection at all, but if you extend the semantics of 164 and 165 as
> > proposed, wouldn't you simply install those newly extended implementations
> > into the 143 and 144 slots such that existing senders in the image get
> > the expected results without knowing that you changed anything? I'm
> > assuming that the goal is to simplify and improve the implementation within
> > the VM as opposed to freeing up the numbering assignments of 143 and 144
> > for other purposes.
> 
> The goal is to have the same effect as efficient JITted implementations
> of 143 & 144.  Given this only involves changing unsigned to signed when
> creating my modified versions of 60 & 61, the easiest way is to extend
> the semantics of 164 & 165, which also means no new primitive numbers.
> They???re no longer a scarce resource, except that the vm has a single
> table rather than a pages table (which VW has), si keeping numbers in
> numbered primitive low saves work for the moment.
>

For the proposed change to extend semantics of 164 and 165: +1, good idea.

As for changing the image to take advantage of the improvement, it would
not be good to introduce a tight coupling between the image version and
the VM version for purposes of performance unless there is a real and
measurable performance improvement. I don't know if that is the case here,
so I can't say if changing e.g. SoundBuffer>>at: to call different
primitive numbers is a good idea.

There is one sure way to find out: Try it and measure the results :-)

Dave