Slots 32, 33, and 34 in the special objects array were in use as recently
as Squeak 4.1, and were set to nil by the time of Squeak 4.4. I'm not
sure exactly when those usages were deprecated, but given that some VM
implementations are supporting images of much earlier vintage, would it be
better to assign DoubleByteArray, WordArray, and DoubleWordArray to new
slots appended to the end of the special objects array?
I'm not sure if this has any practical impact, just asking to be safe.
Dave
On Mon, Jan 13, 2020 at 09:47:27AM -0800, Eliot Miranda wrote:
> Hi All,
>
> currently the following slots in the specialObjectsArray are unused in
> both Squeak and Pharo (& I suspect Cuis).
>
> newArray at: 32 put: nil. "was the prototype Float"
> newArray at: 33 put: nil. "was the prototype 4-byte LargePositiveInteger"
> newArray at: 34 put: nil. "was the prototype Point"
>
> The specialObjectsArray already contains ByteArray
> newArray at: 27 put: ByteArray.
>
> I would like to have a full set of little-endian unsigned integer arrays.
> In Spur Squeak these are ByteArray, DoubleByteArray, WordArray (Bitmap is
> big endian), and DoubleWordArray. The VM's at:[put:] directly supports
> these four at the JIT level giving us efficient unsigned access. There is
> also efficient signed access for some signed arrays but these are less
> useful (at least in theVM simulator).
>
> I want to make all four unsigned integer array classs available to plugins
> etc via the interpreterProxy. So here's a formal request to reserve these
> values for use as follows:
> newArray at: 27 put: ByteArray.
> ...
> newArray at: 32 put: DoubleByteArray.
> newArray at: 33 put: WordArray.
> newArray at: 34 put: DoubleWordArray.
>
> _,,,^..^,,,_
> best, Eliot
Locked
