Data composition transformation

Started by
1 comment, last by dcosborn 18 years, 10 months ago
I'm writing some resource loading code that I'm hoping to make as cross-platform as possible. I've dealt with endian issues using an explicit conversion function that I call whenever necessary to transform the data from its original endianness (as defined by the file format) to the processor's native one. Its pretty general purpose and could deal with other composition issues such as different bit-orderings and weird byte-orders like {B1,B0,B3,B2}. So far I've only been calling the function for multi-byte data types (shorts, ints, floats). I'm thinking that if a processor uses a reversed bit ordering for instance, it would affect bytes as well and I should run the function even on single-byte data types. Is this a reasonable concern? Are there, in reality, any processors that use strange bit-orderings or byte-orderings other than the standard little-endian and big-endian ones?
Advertisement
The bit order is generally not an issue except perhaps when dealing monochrome bitmaps or raw serial data.
Almost all other IO methods are byte oriented and thus handle such issues automatically.

The only cases of middle-endian representations I know of are planar display modes on most little endian machines (i.e 2, 4 or 16 color modes on IBM-PCs), which has a big-endian bit order but a little-endian byte order (thus causing trouble when shifting bitmaps around), and the PDP-11's 32-bit words which has an odd byte order (2-3-0-1).
Thanks, thats exactly what I was looking for.

This topic is closed to new replies.

Advertisement