Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

Hi Adrian,

On 18/6/25 20:04, John Paul Adrian Glaubitz wrote:
> Hello Geert,
> 
> On Wed, 2025-06-18 at 11:56 +0200, Geert Uytterhoeven wrote:
>>> Coldfire already uses a different alignment (for the stack):
>>>
>>> /* ColdFire and fido strongly prefer a 32-bit aligned stack.  */
>>> #define PREFERRED_STACK_BOUNDARY \
>>>    ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)
>>>
>>> It's instruction set is also not fully compatible AFAIK.
>>
>> Sure, but you will impact it regardless.
> 
> Could you please elaborate this a bit more, please?
> 
> Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
> would certainly be able to toggle the alignment settings independent of
> what's done on classic m68k.

The net out is that it is the same gcc compiler, m68k-linux-gcc.
ColdFire just needs specific code generation via command line switches,
like -m5200 (or -m5206e or -m5307 or -mcfv4e, etc). This is the same way
you would specify 680x0 level - m68020, -m68030, etc.

The bulk of the instruction set is the same. Asm code will look totally
familiar to anyone who knows m68k :-)   One notable difference is that
there is a more limited set addressing modes for some instructions.

FWIW ColdFire currently uses the same ABI as all other m68k, so it uses
2-byte alignment today.


> In the Linux kernel, Coldfire is also a separate
> arch, so the alignment settings can also be handled there separately if necessary.

ColdFire is not handled as a separate architecture in linux, it is just a
variant of m68k - so uses arch/m68k in the source.


> It's not really necessary to enforce this on Coldfire. However, since buildroot
> builds completely from source, it wouldn't even be a problem to change the alignment
> there as well.

Yes, that is totally right in my experience. Certainly in my ColdFire work
it is pretty much always a build-everything approach via buildroot or similar.
I wouldn't think an ABI change would actually worry too many ColdFire uses,
they don't use distributions like debian on them. (I would love to hear from
anyone who does!).

Regards
Greg



> PS: I would like to lead a discussion on how to implement this properly and
> not continue to have one why this shouldn't be done as the latter is continuing
> to take a lot of energy.
> 
> Adrian
>