Menu
▾
▴
freemint-discuss
|
From: David G. <dga...@gm...> - 2018-02-19 21:02:41
|
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. > |
|
From: Thorsten O. <ad...@th...> - 2018-02-19 23:46:59
|
On Montag, 19. Februar 2018 09:45:07 CET David Gálvez wrote: > but it's still no clear to me what is state of these macros in > gcc 7. Can use them safely? Yes i think so. Those lowercase versions have always been there for all m68k platforms, with and without underscores (if you don't use -ansi), while the uppercase versions have only been patched in by the mint patch, for compatibility with some very old ports. Also, there is no uppercase equivalent for -m68030 or better, they all define only __M68020__. So, although that is fixed now, the code should check for __mc68020__ instead. |
|
From: Thorsten O. <ad...@th...> - 2018-02-20 00:07:11
|
Edit: in the mint kernel, things might be different. Some macros like M68000 are explicitly defined in cdefs.h, which is generated by the Makefile. But you are right, there all still a few places that check for __M68020__ instead. maybe that is because of this strangeness: ifeq ($(kernel),020) MINT = mint020.prg CPU = 020 KERNELDEFS = -DM68000 kernel_nocflags = -DWITH_MMU_SUPPORT endif Note that only M68000 is defined there, not M68020. If you are going to use the compiler generated symbols instead, keep in mind that switches like -m68020-60 will define *all* macros from __mc68020 to __mc68060, but the compiler will generate code that still runs on 68020. |
|
From: Vincent R. <vin...@fr...> - 2018-02-20 14:29:48
|
On 20/02/2018 at 00:46, Thorsten Otto wrote: > Yes i think so. Those lowercase versions have always been there for all m68k > platforms, with and without underscores (if you don't use -ansi), while the > uppercase versions have only been patched in by the mint patch, for > compatibility with some very old ports. Also, there is no uppercase equivalent > for -m68030 or better, they all define only __M68020__. So, although that is > fixed now, the code should check for __mc68020__ instead. I agree with you. From the top of my head, I went to the same conclusion long ago. Of course, we should use new official GCC defines. -- Vincent Rivière |
|
From: David G. <dga...@gm...> - 2018-02-25 05:18:03
|
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 |
|
From: David G. <dga...@gm...> - 2018-03-22 12:50:14
|
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. |
|
From: David G. <dga...@gm...> - 2018-04-21 14:53:31
|
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. |
|
From: Vincent R. <vin...@fr...> - 2018-04-21 14:58:23
|
On 21/04/2018 at 16:53, David Gálvez wrote: > "#if !(defined(M68000) || defined(__mcoldfire__))") IIRC (not sure): - defined(M68000) means: "we are building the MINT000.PRG" - defined(__mcoldfire__) means: "we are building the MINTV4E.PRG" (as we don't have a specific define) A specific define can be useful when building several kernels with the same CPU options (which definitely happens in EmuTOS). -- Vincent Rivière |
|
From: David G. <dga...@gm...> - 2018-04-21 15:15:45
|
2018-04-21 16:58 GMT+02:00 Vincent Rivière <vin...@fr...>: > On 21/04/2018 at 16:53, David Gálvez wrote: >> >> "#if !(defined(M68000) || defined(__mcoldfire__))") > > > IIRC (not sure): > > - defined(M68000) means: "we are building the MINT000.PRG" > - defined(__mcoldfire__) means: "we are building the MINTV4E.PRG" (as we > don't have a specific define) > > A specific define can be useful when building several kernels with the same > CPU options (which definitely happens in EmuTOS). > I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS, add it in the sources wherever the M68040 macro is used and then remove the -DM68040 flag when compiling the MINTV4E.PRG. Also I have seen that when compiling MINT020.PRG, the -D68000 flag is used, this seems wrong to me. I think about creating the M68020 machine flag too that is missing now. |
|
From: Vincent R. <vin...@fr...> - 2018-04-21 15:17:44
|
On 21/04/2018 at 17:15, David Gálvez wrote: > I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS, > add it in the sources wherever the M68040 macro is used and then > remove the -DM68040 flag when compiling the MINTV4E.PRG. Exactly the thing to do. I planned to do that, but was too shy... -- Vincent Rivière |
|
From: Thorsten O. <ad...@th...> - 2018-04-21 15:36:23
|
On Samstag, 21. April 2018 17:15:38 CEST David Gálvez wrote: > I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS, > add it in the sources wherever the M68040 macro is used and then > remove the -DM68040 flag when compiling the MINTV4E.PRG. It might depend. As Vincent pointed out, if you are using the same compiler flags for different targets, then you have to use some define in the Makefile (but i would prefer something else than M68000 since that might clash again). When it comes to distinguish between whether you can use code for a specific processor, you are better off using the compiler defined macros like __mcoldfire__. No need to add a separate define for this in the Makefile, that will makes things just more complicated than necessary, and again add confusion which macro to test. I think i already mentioned this, but you just have to keep in mind that - m68020-60 will define all macros from __mc68020__ upto __mc68060__, while - m68060 will *only* define __mc68060__, so there might be places that currently test for __mc68020__ only, where they actually want to know whether 68020 and above instructions can be used, and thus have to be changed to test for any of the macros. But setting up the Makefile to use something like -mc68020 -DM68020 is imho confusing, and again you will have a mix of tests. |
|
From: Vincent R. <vin...@fr...> - 2018-04-21 16:25:30
|
On 21/04/2018 at 17:36, Thorsten Otto wrote: > It might depend. As Vincent pointed out, if you are using the same compiler > flags for different targets, then you have to use some define in the Makefile > (but i would prefer something else than M68000 since that might clash again). I completely agree. In EmuTOS, I have chosen verbose defines based on the Makefile target name. i.e. TARGET_512, TARGET_FIREBEE, etc. Could become TARGET_000, TARGET_V4E in FreeMiNT. Verbose, but no possible confusion. -- Vincent Rivière |
|
From: David G. <dga...@gm...> - 2018-04-21 16:34:06
|
2018-04-21 17:36 GMT+02:00 Thorsten Otto <ad...@th...>: > On Samstag, 21. April 2018 17:15:38 CEST David Gálvez wrote: >> I'm thinking about creating the machine flag "COLDFIRE" in KERNELDEFS, >> add it in the sources wherever the M68040 macro is used and then >> remove the -DM68040 flag when compiling the MINTV4E.PRG. > > It might depend. As Vincent pointed out, if you are using the same compiler > flags for different targets, then you have to use some define in the Makefile > (but i would prefer something else than M68000 since that might clash again). > When it comes to distinguish between whether you can use code for a specific > processor, you are better off using the compiler defined macros like > __mcoldfire__. No need to add a separate define for this in the Makefile, that > will makes things just more complicated than necessary, and again add > confusion which macro to test. > OK I see, then I'll add __mcoldfire__ checks wherever M68040 is used, remove -D68040 flag in MINTV4E.PRG build flags. and I won't create a new COLDFIRE flag if it's not necessary. > I think i already mentioned this, but you just have to keep in mind that - > m68020-60 will define all macros from __mc68020__ upto __mc68060__, while - > m68060 will *only* define __mc68060__, so there might be places that currently > test for __mc68020__ only, where they actually want to know whether 68020 and > above instructions can be used, and thus have to be changed to test for any of > the macros. > Yes I think you did but I got confused by the old __M680x0__ macro behavior. Fortunately there aren't to many instances where __mc68020__ is used, the ones that I swapped in the commit and I've seen one in the ext2 code that should be corrected for sure. > But setting up the Makefile to use something like -mc68020 -DM68020 is imho > confusing, and again you will have a mix of tests. At the end creating the M68020 machine flag isn't necessary but I think that the -D68000 when compiling MINT020.PRG should be removed, I've searched for the commit where this was added and there is no explanation about why -D68000 is needed in the 68020 kernels. |
|
From: Thorsten O. <ad...@th...> - 2018-04-21 17:06:07
|
On Samstag, 21. April 2018 18:33:57 CEST David Gálvez wrote: > I > think that the -D68000 when compiling MINT020.PRG should be removed, IIRC there were some early checks whether the detected cpu actually matches the way the kernel was compiled (but i'm not sure wether that really ever worked, it might be already too late when some code compiled with -m68020 is executed on plain m68000; that would require to ensure that all code up to that point really runs on all machines, including coldfire, and you can't use kprintf() or similar to diagnose the problem since that will again might use code for a wrong processor). |
|
From: David G. <dga...@gm...> - 2018-04-21 16:54:43
|
2018-04-21 17:36 GMT+02:00 Thorsten Otto <ad...@th...>: > I think i already mentioned this, but you just have to keep in mind that - > m68020-60 will define all macros from __mc68020__ upto __mc68060__, while - > m68060 will *only* define __mc68060__, so there might be places that currently > test for __mc68020__ only, where they actually want to know whether 68020 and > above instructions can be used, and thus have to be changed to test for any of > the macros. I've noticed a variation of this issue, where there is a check for the 68000 with __mc68000__ or mc68000 and there will be "false positives" when compiling for the 68020 and above: https://github.com/freemint/freemint/blob/76262f82c1594aa0c59ee72803824924daf6026c/sys/libkern/unaligned.c#L35 https://github.com/freemint/freemint/blob/76262f82c1594aa0c59ee72803824924daf6026c/sys/libkern/asm/quickmove.S#L49 https://github.com/freemint/freemint/blob/76262f82c1594aa0c59ee72803824924daf6026c/tools/crypto/crypt.c#L135 |
|
From: Thorsten O. <ad...@th...> - 2018-04-21 17:16:41
|
On Samstag, 21. April 2018 18:54:34 CEST David Gálvez wrote: > I've noticed a variation of this issue, where there is a check for the As for the unaligned_putl function: that seems to be only used in very few cases, and not in speed-critical code, so maybe that ifdef, and the check for odd address can be removed there completely, and just use always the safe code. For the other cases, the check has to be changed. |
|
From: Thorsten O. <ad...@th...> - 2018-04-21 17:00:34
|
On Samstag, 21. April 2018 18:25:19 CEST Vincent Rivière wrote: > .e. TARGET_512, TARGET_FIREBEE, etc. > > Could become TARGET_000, TARGET_V4E in FreeMiNT. > Verbose, but no possible confusion. TARGET_FIREBEE makes sense in EmuTOS, to distinguish it from other bare-metal coldfire targets. But for Mint there is only one such target IIRC. If needed, we should use TARGET_FIREBEE too there, but TARGET_V4E does not make much sense, as you can use the already existing macros when you need to know the target processor. |
|
From: Markus F. <mf...@mu...> - 2018-04-22 05:26:37
|
Note that FreeMiNT works fine on other ColdFire boards (like the M5484 Evaluation Board) as well. It's just that it never found its way into the Makefile as specific target but requires manual fiddling with CONFIGVARS. Am 21.04.2018 um 19:00 schrieb Thorsten Otto: > On Samstag, 21. April 2018 18:25:19 CEST Vincent Rivière wrote: >> .e. TARGET_512, TARGET_FIREBEE, etc. >> >> Could become TARGET_000, TARGET_V4E in FreeMiNT. >> Verbose, but no possible confusion. > TARGET_FIREBEE makes sense in EmuTOS, to distinguish it from other bare-metal > coldfire targets. But for Mint there is only one such target IIRC. If needed, > we should use TARGET_FIREBEE too there, but TARGET_V4E does not make much > sense, as you can use the already existing macros when you need to know the > target processor. > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Vincent R. <vin...@fr...> - 2018-04-24 22:07:58
|
On 22/04/2018 at 07:13, Markus Fröschle wrote: > Note that FreeMiNT works fine on other ColdFire boards (like the M5484 > Evaluation Board) as well. > > It's just that it never found its way into the Makefile as specific > target but requires manual fiddling with CONFIGVARS. I'm unsure what you mean... Anyway, the official mintv4e.prg works fine with both FireBee (EmuTOS and FireTOS) and ColdFire, this is why there is no specific support in the Makefile. And as it is unlikely to go out of RAM on such machines, it is OK to put all features inside mintv4e.prg and then enable them at runtime when proper hardware is detected. Finally, considering the above statement, it can explain why there is no specific define to specify the current target... as current target is just a CPU (ColdFire V4e) with support for any hardware. -- Vincent Rivière |
|
From: Markus F. <mf...@mu...> - 2018-04-25 04:30:43
|
You still need to set NO_AKP_KEYBOARD (unless you have an Eiffel, that is). Am 25.04.2018 um 00:07 schrieb Vincent Rivière: > On 22/04/2018 at 07:13, Markus Fröschle wrote: >> Note that FreeMiNT works fine on other ColdFire boards (like the M5484 >> Evaluation Board) as well. >> >> It's just that it never found its way into the Makefile as specific >> target but requires manual fiddling with CONFIGVARS. > > I'm unsure what you mean... > Anyway, the official mintv4e.prg works fine with both FireBee (EmuTOS > and FireTOS) and ColdFire, this is why there is no specific support in > the Makefile. > And as it is unlikely to go out of RAM on such machines, it is OK to > put all features inside mintv4e.prg and then enable them at runtime > when proper hardware is detected. > > Finally, considering the above statement, it can explain why there is > no specific define to specify the current target... as current target > is just a CPU (ColdFire V4e) with support for any hardware. > |
|
From: Vincent R. <vin...@fr...> - 2018-04-25 14:00:10
|
On 25/04/2018 à 06:30, Markus Fröschle wrote: > You still need to set NO_AKP_KEYBOARD (unless you have an Eiffel, that is). You are right. My next plan was to convert NO_AKP_KEYBOARD to something dynamically detected. But you know, laziness and other things to do... -- Vincent Rivière |
Thanks for helping keep SourceForge clean.
X