Archeology: Endianness need a little cleanup
ncellier at ifrance.com
Fri May 19 00:37:03 UTC 2006
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
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 ?
More information about the Squeak-dev