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

[David T. Lewis]

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.

Dave