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/