On Apr 19, 2010, at 05:33, Andy Wingo wrote: > Dunno. To be able to write in native endianness and actually see > benefits, the data needs to be aligned, too. Integer widths are > generally chosen as some point in the size/speed vs generality tradeoff. > I would be very hesitant about poking some of these; and I'd like an > opportunity to comment on patches :-)
For maximal benefit, yes, aligned values are best, but many processors can do unaligned loads with more efficiency than reading individual bytes and then assembling them together via logical operations -- x86, for example, can load from an unaligned address, and if I recall correctly, SPARC has a separate unaligned-load instruction. It's not automatically supported by C compilers, which will assume that an object of a given type has at least the required alignment of that type, so when working on such things in my last job (for network protocol messages), I put together a bunch of inline functions for "read unaligned 32-bit value" etc., using GCC's support for packed (and only byte-aligned) structures when available, and doing the byte-by-byte version otherwise. But except for the byte-by-byte version, they need the data to be in native order. Of course, that doesn't work too well for 24-bit values directly, but you could use it for a 16-bit portion, or a 32-bit value if you know there's an extra byte available (e.g., the opcode itself) and which end it occurs on (to eliminate it). Ken