Endianness reversing is implemented too many times in 3.9a7029. It is like a collection of successive independant coding accumulated.
We must reverse bytes in wordArray at startup if we transfer image on another machine, or for binary I/O. There are only four cases: we have long 1234, we want 4321 at startup, the VM does that for us... nothing to do for Binary I/O, Bitmap class>>swapBytesIn:from:to: does swap long (32 bits) we have short 12,34 we want 21,43 at startup, VM does scramble 4321, we have two implementations: ArrayedCollection>>swapHalves and ShortIntegerObject>>swapShortObjects for binary I/O, this is re-implemented a lot of times!
My proposition is to have three generic BitBlt tricks Bitmap class>>swapLongIn:from:to: Bitmap class>>swapShortIn:from:to: Bitmap class>>swapHalvesIn:from:to: Maybe a swapLongLong would be usefull too...
Then to define reverseEndianness everywhere, with default: pointers | bytes => do nothing word => Bitmap swapLongIn: self from: 1 to: self basicSize
Redefined reverseEndianness in ShortIntegerArray SoundBuffer & co Bitmap swapShortIn: self from: 1 to: self basicSize
Then to define restoreEndianness generic: SmalltalkImage current isLittleEndian ifTrue: [self reverseEndianness]
Then to call uniformely swapHalves at startup for short things...
I can proceed with theses changes, but cannot test bigEndian... Any objection to these changes ? Note that this should speed up ShortIntegerArray streaming on x86...
Note that a service like swapShortAt: swapLongAt: swapLongLongAt: is missing in ByteArray, though usefull to store/retrieve information in native format (especially for FFI). And BitBlt trick should not work for ByteArray... Or should it ?
Nicolas
squeak-dev@lists.squeakfoundation.org