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