Messages in this thread | | | Date | Mon, 10 Nov 2008 11:49:22 +0000 | From | "Will Newton" <> | Subject | Re: [RFC-PATCH 1/5] unaligned: introduce common header |
| |
On Mon, Nov 10, 2008 at 4:22 AM, Harvey Harrison <harvey.harrison@gmail.com> wrote:
(add back lkml cc that I mistakenly dropped)
> On Sat, 2008-11-08 at 12:47 +0000, Will Newton wrote: >> On Wed, Nov 5, 2008 at 6:16 PM, Harvey Harrison >> <harvey.harrison@gmail.com> wrote: >> >> > The memmove-based arches (m32r, xtensa, h8300) are likely going to be fine with this change >> > barring compiler bugs that made them go with memmove in the first place. >> >> As I understand it the need for the memmove implementation is not >> compiler bugs but default struct alignment. The packed struct >> implementation will only work with compilers where structs can be >> aligned on byte boundaries, it's fairly common for RISC architectures >> to align structs to 4 or 8 byte boundaries. > > Which I believe is disabled entirely using __attribute__((packed)), no?
As far as I am aware the packed attribute is handled in this way for some toolchains (arm in particular). Not everybody does it, and for good reasons. For example if I have this struct on an architecture with 8 byte default struct alignment:
struct foo { u64 big_data; u8 small_data; u32 medium_data; } __attribute__((packed));
Should big_data be accessed as 8 byte load instructions rather than one 64bit load instruction? It's a pretty large performance penalty to pay when all I really want is for medium_data to be accessed correctly.
| |