On Wed, Dec 31, 2003 at 02:54:01PM +0100, Sylvain Munaut wrote:
> Yes, I've seen this before but it's not exactly what I wanted.
Okay :)
> When reading a 32 bit word from memory, it has to be 4 bytes aligned,
> else it will trigger an alignment trap ( that will fix the incorrect
> access but with a huge performance loss ).
More or less. The alignment trap handler is of course optional - if
you disable it there is less "overhead". In that case you'll get
whatever the hardware produces naturally - typically some of the bits
will be correct, but will be shifted to the wrong spot, and the other
bits will be from adjacent bytes. In the past, gcc actually relied on
this behaviour and knew how to manipulate it to get the "right" result.
However, the behaviour of the CPU in this case is not part of the
specification, and so you really shouldn't rely on it. Best to avoid
unaligned accesses in the first place.
> But when reading 16 bits or 8 bits ? Also need to be aligned ?
As long as they are "contained" in a 4 byte block, the CPU can read
them in a single operation and will shift the data as necessary.
The general rule is, "data should be aligned on its own boundary", eg.
bytes anywhere, 16-bits aligned on 2-byte boundaries, 32-bits aligned
on 4-byte boundaries. I believe this rule holds for all current CPUs.
--
Ralph Siemsen
www.netwinder.org
-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ/Etiquette: http://www.arm.linux.org.uk/armlinux/mailinglists.php
|
