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