-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 31 December 2003 08:54, Sylvain Munaut wrote:
> Yes, I've seen this before but it's not exactly what I wanted.
>
> I'm not sure I've well understood what I read on other pages/manual.
> What I've understood is :
>
> 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 ).
> But when reading 16 bits or 8 bits ? Also need to be aligned ?
You don't seem to understand how the processor works. ALL READS by the
processor are 32 bits wide, 32 bit aligned, regardless of your operand size
or address. 16 and 8 bit reads are implemented as macros that pull out the
appropriate section of the 32 bit read operation. Now let's say you want to
read a 32 bit value from some address like 0x0000c472. Because the value is
actually in two separate words because your operand's address is not 32 bit
ALIGNED, this generates an alignment fault as this operation requires that
two words must be read, the two 16 bit parts extracted and combined to form
the 32 bit return value. Same goes for a mis-aligned 16 bit read on an odd
address that would span 2 words. Even byte shuffling in a single read to
properly align a 16 or 8 bit quantity pays a penalty. There are serious
performance hits to be taken for misaligned accesses. Because all of this is
hidden by the processor dependent code, applications folks usually don't know
about this, which is why folks like Ralph and others have to constantly keep
beating the RTFM drum. It's a very real concern for us device driver folks,
and also has major implications for system architecture people. It's why you
see things like system A2 connected to peripheral pA0, A3>>pA1, etc.
_Everything_ works better when aligned to a 32 bit boundary. Some things
even need 64 bit alignment (See section 5 of the PXA255 developers manual...)
- -Jeff
- --
Kodachrome: After nearly 70 years, there's still
no better way to preserve an image.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/8t9HvvyQ7TDL7JURAjZZAJ4ik3TSWJXGqBXQCnU9MjnuCgkTiQCfbIc4
PUxDWQagTd/N6UFRJR4DeXg=
=zaF4
-----END PGP SIGNATURE-----
-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ/Etiquette: http://www.arm.linux.org.uk/armlinux/mailinglists.php
|
