Re: [Freemint-discuss] __M680x0__ macros in gcc 7 (was Re: [Freemint-list] Broken udelay() for m68000)

[David G. <dga...@gm...>]

2018-03-22 13:50 GMT+01:00 David Gálvez <dga...@gm...>:
> 2018-02-19 10:02 GMT+01:00 David Gálvez <dga...@gm...>:
>> 2018-02-19 9:45 GMT+01:00 David Gálvez <dga...@gm...>:
>>> Move this discussion from github to the list.
>>>
>>> So if I understand correctly __M680x0__ (with uppercase) is MiNT's
>>> specific and it's deprecated, I've seen 7 use instances in the
>>> kernel's code, by coincidence 4 in files I'm working with right now,
>>> then the alternative is the compiler general  __mc680x0__ (with lower
>>> case), but it's still no clear to me what is state of these macros in
>>> gcc 7. Can use them safely?
>>>
>>>
>>
>> I have just read this in the gcc 7.3.0 manual:
>>
>> "GCC defines the macros __mcarch and __mcarch__ when tuning for 680x0
>> architecture arch. It also defines mcarch unless either -ansi or a
>> non-GNU -std option is used. If GCC is tuning for a range of
>> architectures, as selected by -mtune=68020-40 or -mtune=68020-60, it
>> defines the macros for every architecture in the range."
>>
>> So  in theory it's safe and nothing has been changed regarding these
>> macros between compiler's version.
>>
>> I'm going to remove what is left of the uppercase macros and swap them
>> by the lowercase ones
>>
>
> I've now replaced the old MiNT's specific macros by the generic ones.
> I've left untouched the M680x0 macros (without underscores) that are
> defined during the compile's time (see KERNELDEFS).
> Those seems to have some extra purpose, for example the macro M68040
> is defined when compiling the ColdFire kernel.
>
> Still there are some defines that mix both macros types (like this one
>  "#if !(defined(M68000) || defined(__mcoldfire__))")
> https://github.com/freemint/freemint/blob/1196c6f665b6eed314b419ce560f445ebaeae5a1/sys/arch/intr.S#L749
> If this is not on purpose we could replace them too for code consistency.

The commit broke things. When compiling with -m68060 the __M68020__
macro is defined but not the __mc68020__, so replace one for the other
wasn't a good idea.
Now to fix this I have doubts if using the M680x0 macros (without
underscores) defined in KERNELDEFS or the ones defined by the
compiler.