[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] "local return" in gnu as
Miro Kropacek wrote:
But that 'mc68000' definition should be definitely same in all
versions I think...
To save someone (Vincent ;-) work, I tested various #ifdefs. Results are:
gcc 2.95 uses 'mc68000' for 68000 target and 'mc68020' for 68020+.
gcc 4.x uses 'mc68000' everytime (!) plus 'mc680x0' for 680x0 targets
(x>=1).
Thanks for your contribution to keep my holidays quiet :-)
One day I had a look to that GCC defines, and I went to the conclusion
it was quite a mess. I chose to keep the standard GCC 4.x behaviour,
plus some other defines for compatibility with old compilers.
The standard behaviour of GCC 4.x is defined here:
http://gcc.gnu.org/viewcvs/trunk/gcc/config/m68k/m68k.h?view=markup
Search for TARGET_CPU_CPP_BUILTINS
We can see the definition of the mad behaviour you have found: mc68000
is defined everytime, including ColdFire !
Of course, that stuff could be overridden for any target, but it seems
insane to have different defines relative to the CPU for different targets.
For compatibility with GCC 2.95, I have added the following stuff in the
MiNT patch:
+/* The following defines are nonstandard
+ and are kept only for compatibility
+ with older versions of GCC for MiNT. */
+
+#undef CPP_SPEC
+#define CPP_SPEC \
+ "%{m68000:-D__M68000__} " \
+ "%{mc68020:-D__M68020__} " \
+ "%{m68020:-D__M68020__} " \
+ "%{m68030:-D__M68020__} " \
+ "%{m68040:-D__M68020__} " \
+ "%{m68060:-D__M68020__} " \
+ "%{m68020-40:-D__M68020__} " \
+ "%{m68020-60:-D__M68020__} " \
+ "%{!m680*:%{!mc680*:-D__M68000__}} " \
+ "%{m68881:-D__M68881__} " \
+ "%{mshort:-D__MSHORT__}"
The first field is the GCC command line option, the second one is the
define automatically added.
We can see you can test __M68000__ to see if we are compiling for a raw
68000. I think it is also supported by GCC 2.95 for MiNT. However this
define does not seem to be standard for others GCC m68k targets (but who
cares ?).
- removing 'local' and replacing the label with some unique identifier
(\@) (as gas 2.13 don't know ".altmacro" keyword but uses this mode by
default, it seems better to me to replace this alternate notation
instead of checking for 2.95 gcc in asm source...)
I have no knowledge about that, I have not hacked that in the new
binutils patch. I don't know these macro features, but your solution
seem sensible.
Good luck.
--
Vincent Rivière