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

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 21 02:05:38 UTC 2018


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.

> 
> Dave
> 


More information about the Vm-dev mailing list