[Vm-dev] Signed at:[put:] primitives for bits classes
eliot.miranda at gmail.com
Wed Jun 20 18:46:26 UTC 2018
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
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
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 &
Once this is done we could eliminate use of 143 & 144 if we changed
SoundBuffer to use primitives 164 & 165 and to have a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev