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