Re: Plan needed for switching m68k to 32-bit alignment
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
> Finn Thain dixit:
>
> >That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
> >case on my Linux/i686 system. 4 != 8:
> >
> >struct baa {
> > int a;
> > long long b;
> >} foo;
>
> That struct is just 12 bytes for you then?
>
Right. i686 and m68k agree on that.
> That’s possible on i386 but almost nowhere else, and has multiple
> penalties on i386 even (cacheline split, loss of atomicity, merging
> of accesses, possible cross-page split, …).
>
Well, the GCC manual says the Power architecture also has ABI variants
with differing alignment rules.
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/RS_002f6000-and-PowerPC-Options.html#index-malign-natural
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html#index-malign-data-1
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html#index-malign-double
> Of course, in this case, the software author ought to have made the
> padding explicit or, better, sorted the struct members. But if all did
> that we wouldn’t have this problem.
>
Right. And I don't think the problem is going to go away. One solution
that is sometimes raised is better tooling. I'm not sure how that would
work. Perhaps a better solution would be language changes to allow a
struct definition to be qualified with an explicit data model.
> >> More importantly, and relevant for Qt, struct baa is also 8-byte
> >> aligned...
> >
> >If the struct itself is not naturally aligned, it too will eventually
> >break someone's assumption of natural alignment.
>
> No, structs are not naturally aligned but aligned to the max() of the
> alignment of its members. Natural alignment is only applied to primitive
> types.
>
Makes sense.
Reply to: