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
Reply to: