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.