* David Miller (davem@xxxxxxxxxxxxx) wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
> Date: Wed, 19 Jan 2011 17:13:27 -0500
>
> > Hrm, I'd like to see what kind of ill-conceived 32-bit architecture would
> > generate a unaligned access for a 32-bit aligned u64. Do you have examples in
> > mind ? By definition, the memory accesses should be at most 32-bit, no ? AFAIK,
> > gcc treats u64 as two distinct reads on all 32-bit architectures.
>
> Sparc 32-bit has 64-bit loads and stores, GCC uses them because the ABI
> specifies that every structure is at least 8 byte aligned.
Ah, that's the answer I was looking for, thanks!
>
> > gcc on my sparc64 box (32-bit userland) disagrees with you here ;) Using
> > gcc (Debian 4.3.3-14) 4.3.3, here is a demonstration that, indeed, "packed"
> > generates aweful code, but that "packed, aligned(4 or 8)" generates pretty
> > decent code:
>
> Amazing, if this works then do it.
>
> But please document this fully with comments and such :-)
I will, I will! ;)
So I guess we go for the following. Is it verbose enough ?
/*
* __u64_packed_aligned:
*
* Forces gcc to use the u64 type alignment, up-aligning or down-aligning the
* target type if necessary. The memory accesses to the target structure are
* efficient (does not require bytewise memory accesses) and the atomic pointer
* update guarantees required by RCU are kept. u64 is considered as the largest
* type that can generate a trap for unaligned accesses (u64 on sparc32 needs to
* be aligned on 64-bit).
*
* Specifying both "packed" and "aligned" generates decent code (without the
* bytewise memory accesses generated by simply using "packed"), and forces
* gcc to down-align the structure alignment to the alignment of a u64 type.
*
* This alignment should be used for both structure definitions and declarations
* (as *both* the type and variable attribute) when using the "section"
* attribute to generate arrays of structures.
*/
#define __u64_packed_aligned \
__attribute__((__packed__, __aligned__(__alignof__(long long))))
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
