[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] struct align



Miro Kropacek wrote:
> I don't say gcc is wrong I just
> want to know the reason why it behaves in this way :)

Hello.

Most of the GCC behavior is target-independant.
Specific configuration for each supported target CPU can be found in the GCC sources in a subfolder located in gcc/config. Furthermore, it can be configured even more for a specific target (such as m68k-atari-mint). That's why GCC behaves differently on different targets: it has been configured differently.

The standard configuration file for m68k is gcc/config/m68k/m68k.h
It is overridden by gcc/config/m68k/mint.h

The parameter you are interested in here is BIGGEST_ALIGNMENT :
In gcc/config/m68k/m68k.h:
/* No data type wants to be aligned rounder than this.
   Most published ABIs say that ints should be aligned on 16-bit
   boundaries, but CPUs with 32-bit busses get better performance
   aligned on 32-bit boundaries.  */
#define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16)

The macro TARGET_ALIGN_INT is defined to 1 only when compiling with the -malign-int option.

So for m68k targets (including MiNT) :
- by default, ints are aligned on multiple of 2. This is suboptimal for modern CPUs, but the system ABI is respected. - if you compile with the -malign-int option, ints are aligned on multiple of 4 (like on Linux), this is optimal for the 68030+, but the ABI is broken.


Just a note about MS Windows include files. Every definition of a structure used by the Win32 API is surrounded with nonstandard alignment directives. In that way, the system structures always use the alignment required by the ABI regardless of the compiler options. The programmer can adjust the global alignment settings at compile time for its private structures, it will not affect the system structures so it will not break the ABI. I think the MiNTLib should behave like this... if is not already the case.

--
Vincent Rivière