[squeak-dev] RawBitsArray
K K Subbu
kksubbu.ml at gmail.com
Fri May 22 08:27:13 UTC 2020
On 22/05/20 12:21 pm, Nicolas Cellier wrote:
> I should not have redefined bytesPerElement, because most of the time,
> super will behave as intended
moving to bitsPerElement goes well with raw bits model. Perhaps, we
could throw in a padBitsPerElement. bytesPerElement would then become a
convenience method:
bytesPerElement
^(self bitsPerElement + self padBitsPerElement) / 8
The only other time the VM needs to deal with bytes is during endian
swap. We could add beEndian: method to adjust bytes within an element to
match #littleEndian (most processors) or #bigEndian (IP network) order
while sending/receiving a raw object to/from an external source with a
different endian order (image file, network packet etc.)
> We could redefine a slotsPerElement, defaulting to 1, and redefined in
> exceptional cases (like a double complex array would consume 2 slots of
> 8 bytes per element).
This presumes that elements have a slotted structure. I would prefer to
keep raw bits.
> Concerning case of 10 or 12 bits per element, would you store them in
> compact form (all bits concatenated without padding), or rather with
> appropriate padding (in which case we would use a DoubleBytesArray)?
Samples are mostly stored and copied around, so padding would be counter
productive. Extracting them into aligned words wouldn't be
computationally expensive these days.
Regards .. Subbu
More information about the Squeak-dev
mailing list
|