[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TODO for 2.0

From: Ken Raeburn
Subject: Re: TODO for 2.0
Date: Mon, 19 Apr 2010 13:09:37 -0400

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]