On Thu, 29 Nov 2007 16:15:23 +0000 (GMT) Daniel Drake wrote:
> Assuming there aren't too many comments/suggestions on this revision, the
> next version will be submitted for inclusion as
> Documentation/unaligned_memory_access.txt
I just have a few typo/punctuation/grammar fixes. Otherwise it looks
good to me. Thanks.
Acked-by: Randy Dunlap <[email protected]>
> Natural alignment
> =================
>
> The rule mentioned above forms what we refer to as natural alignment:
> When accessing N bytes of memory, the base memory address must be evenly
> divisible by N, i.e. addr % N == 0
add ending '.'
> Why unaligned access is bad
> ===========================
>
> The effects of performing an unaligned memory access vary from architecture
> to architecture. It would be easy to write a whole document on the differences
> here; a summary of the common scenarios is presented below:
>
> - Some architectures are able to transparently perform unaligned memory
> accesses, but there is usually a significant performance cost.
(remove split infinitive:)
- Some architecture are able to perform unaligned memory accesses
transparently, but ...
> - Some architectures raise processor exceptions when unaligned accesses
> happen. The exception handler is able to correct the unaligned access,
> at significant cost to performance.
> - Some architectures raise processor exceptions when unaligned accesses
> happen, but the exceptions do not contain enough information for the
> unaligned access to be corrected.
> - Some architectures are not capable of unaligned memory access, but will
> silently perform a different memory access to the one that was requested,
> resulting a a subtle code bug that is hard to detect!
>
> It should be obvious from the above that if your code causes unaligned
> memory accesses to happen, your code will not work correctly on certain
> platforms and will cause performance problems on others.
> Code that causes unaligned access
> =================================
>
> With the above in mind, let's move onto a real life example of a function
> that can cause an unaligned memory access. The following function adapted
> from include/linux/etherdevice.h is an optimized routine to compare two
> ethernet MAC addresses for equality.
>
> unsigned int compare_ether_addr(const u8 *addr1, const u8 *addr2)
> {
> const u16 *a = (const u16 *) addr1;
> const u16 *b = (const u16 *) addr2;
> return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> }
>
> In the above function, the reference to a[0] causes 2 bytes (16 bits) to
> be read from memory starting at address addr1. Think about what would happen
> if addr1 was an odd address such as 0x10003. (Hint: it'd be an unaligned
> access)
access.)
> Avoiding unaligned accesses
> ===========================
>
> The easiest way to avoid unaligned access is to use the get_unaligned() and
> put_unaligned() macros provided by the <asm/unaligned.h> header file.
>
> Going back to an earlier example of code that potentially causes unaligned
> access:
>
> void myfunc(u8 *data, u32 value)
> {
> [...]
> *((u32 *) data) = cpu_to_le32(value);
> [...]
> }
>
> To avoid the unaligned memory access, you would rewrite it as follows:
>
> void myfunc(u8 *data, u32 value)
> {
> [...]
> value = cpu_to_le32(value);
> put_unaligned(value, data);
> [...]
> }
>
> The get_unaligned() macro works similarly. Assuming 'data' is a pointer to
> memory and you wish to avoid unaligned access, its usage is as follows:
>
> u32 value = get_unaligned(data);
>
> These macros work work for memory accesses of any length (not just 32 bits as
> in the examples above). Be aware that when compared to standard access of
> aligned memory, using these macros to access unaligned memory can be costy in
costly
> terms of performance.
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
