On 01/29/2013 01:13 PM, John Ferlan wrote: >>> Mathematically what you propose with the memcpy() works; however, I come >>> from an architecture where a memcpy to an unaligned address causes a >>> fault >> >> Such a memcpy() implementation would be flawed, and should be reported >> as a bug to that vendor; thankfully, these days, most libc do not have >> that flaw. The C standard guarantees that memcpy() is required to work >> on unaligned copies (for a certain definition of work; you may still end >> up splicing together unrelated portions of adjacent integers when >> reading things back as integers, but byte-for-byte, the operation is >> well-defined). >> > > Alpha and Itanium have some (silent unless noise enabled) heartache when > the "to" address is "0x7ffe8f2b8cf1" (or x2, x3, x5, x6, x7, etc). > Ending with x0 & x8 are preferred while x4 & xc tolerated. If the noise > isn't turned on, the application performs poorly due to excessive > alignment faults. No one's arguing that alignment doesn't matter - it is very much in the compiler's favor to align things, because performance is noticeable on unaligned copies. But the point remains that memcpy() is required to work on unaligned memory, even if the compiler does a good job at normally aligning things so that most uses of memcpy don't have to suffer speed penalties. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list