Re: TODO for 2.0

[Ken Raeburn]

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