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

[David G. <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?


----------------------------------------------
th-otto commented 9 hours ago •

Do you know if gcc 7 still creates a M68020 macro for them?

what i usually do to check things like that:

echo "" | m68k-atari-mint-gcc -dM -E - | grep -i m680

(adding switches you want to test)

And mirko is right, gcc 7 does not define m68020 (or the uppercase
version) anymore. Thats bad. Even worse, when using m68020-60, m68020
is defined, but not m68000 (the latter should be defined for any m68k
target).

I don't think its the fault of our port, but i will check that.

edit: ok the test with -dM did not work in this case. The reason is
that this only prints the symbols that are generated by the code, but
M68020 etc. are generated by entries in the spec file (you can see it
by using gcc -dumpspecs). So for the compiled code, these symbols are
still visible.

Owner

mikrosk commented 9 hours ago

M68020 etc. are generated by entries in the spec file (you can see it
by using gcc -dumpspecs). So for the compiled code, these symbols are
still visible.

@th-otto are you sure? I've tested #ifdef __M68020__ directly with a C
source file and wasn't defined for anything but -m68020-40 and
-m68020-60. Or did I misunderstand your comment?

Contributor

th-otto commented 9 hours ago

@Mikro no i'm not sure :) that said, i haven't tested to compile a
program. But it is defined in the spec file, and it has been like also
for gcc 4.6.4, so i assumed they behave the same in that manner.

Contributor

th-otto commented 6 hours ago

Hm there is definitely something wrong with the definitions coming
from the spec file, but i coudn't figure out yet what. It has been the
same definition for ages (CPP_SPEC in config/m68k/mint.h). However
there is a simple solution: just test for mc68020 instead. The
uppercase versions are old relicts anyway.

Edit: i just saw that the definition of asm_cpu_spec is different
between 4.6.4 and 7.2. That definition wasn't touched by our mint
patch, so i guess it has changed for m68k in general, and seems to
cause different behaviour now.



2018-02-18 23:58 GMT+01:00 Miro Kropáček <mir...@gm...>:
> Hi David,
>
> if the interpretation you've mentioned in
> https://github.com/freemint/freemint/issues/70 holds for all drivers (i.e.
> that the delay is supposed to wait at least X microseconds) there shouldn't
> be any regressions IMHO -- the new formula must definitely take longer than
> the previous stub.
>
> As for your question about "__M68020__": gcc 7.2 emits them only for
> -m68020-40 and -m68020-60 (no, not even -m68020!). It definitely seems like
> some kind of deprecated macro kept only for the minimal backward
> compatibility.
>