freemint
68030 without FPU and 680[46]0 EC/LC compatibility
Our archives are not very friendly towards users without FPU:
-
freemint-latest-02060-tt_falcon_clones.zipdoesn't really imply that this build is targeted solely on FPU users -
freemint-latest-000-st_ste.zipdoes boot on 030 and 68LC0[46] however there won't be any memory protection available - CPU builds are even more confusing: all of the 02060, 030, 040 and 060 not only require FPU but they do so because all of them are compiled against
-m68020-60mintlib/gemlib, making it really pointless to offer in the first place - 060fpsp.prg is (not yet) included in our builds, therefore even 68000 applications crash on machines without CT60 TOS (which has the emulator built-in) ... this also applies for Milan/Hades users, perhaps we should make use of https://github.com/th-otto/fpsp
* `freemint-latest-02060-tt_falcon_clones.zip ` doesn't really imply that this build is targeted solely on FPU users
Correct me if i'm wrong, but there isn't any FPU code used in the kernel or in the drivers. Only in other apps like QED etc. maybe. Apart from that, it's the same situation as with all binaries compiled against mintlib.
* `freemint-latest-000-st_ste.zip` does boot on 030 and 68LC0[46] however there won't be any memory protection available
And that is an issue? Why should someone use the st archive on 030, when there is a archive for tt? Its the purpose of the st/ste archives to omit explicit 030 and MMU support, in order to save some memory.
making it really pointless to offer in the first place
Not completely pointless. A binary compiled with m68020-60 will use library calls for some functions, while a binary compiled with -m68030 will not.
perhaps we should make use of https://github.com/th-otto/fpsp
Either that, or update the code in sys/arch/060sp, and build it. The version in https://github.com/th-otto/fpsp behaves slightly different regarding messages, i don't know how happy @agranlund would be about it ;)
Correct me if i'm wrong, but there isn't any FPU code used in the kernel or in the drivers
Yes, that's why I am referring to the whole archives, that's what the user sees (booting into the desktop with TosWin2 refusing to start, ifconfig refusing to start etc)
Its the purpose of the st/ste archives to omit explicit 030 and MMU support, in order to save some memory.
Currently it is the only way how to boot a FreeMiNT snapshot on a FPU-less machines.
A binary compiled with m68020-60 will use library calls for some functions, while a binary compiled with -m68030 will not.
The difference is so minimal that I don't think this is worth considering...
I admit, it was me who didn't notice the obvious fault with m68020-60 linking and went ahead with the full set of CPU builds. These days I'm inclined to just get rid of them all and provide one more bootable archive with 020+ kernels and userspace tools compiled against 68000. An extension to this idea is the approach outlined in https://github.com/freemint/m68k-atari-mint-gcc/issues/1#issuecomment-1691288681, i.e. add support for -m68020-60 -msoft-float multilib but provide only mintlib/gemlib/cflib snapshots as the bare minimum to build FPU-less FreeMiNT snapshot.
Currently it is the only way how to boot a FreeMiNT snapshot on a FPU-less machines.
Most of these have an EC030, so there is no MMU either. So i still don't see the point of enabling MMU support in the 000 archives.
The difference is so minimal that I don't think this is worth considering...
That sounds strange. The main purpose of the cpu builds is to supply kernels optimized for any hardware. If the difference is not noticable, then we would not need them.
But actually i think we don't need to change the build system for that. Its just a matter of the scripts, and which binaries are put into which archive.
add support for -m68020-60 -msoft-float
I already explained that a few times. Although it might sound nice, it's imho too late. None of the compilers we provide do support such a setting, and i don't like the idea to have to spend several weeks of work to change a few hundred Makefiles and scripts just to support a hypothetical configuration that nobody uses.
Simplest solution would be to remove the FPU check in the startup code of mintlib (like libcmini already did), and just let the application crash if it actually uses FPU code.
Most of these have an EC030, so there is no MMU either. So i still don't see the point of enabling MMU support in the 000 archives.
However 68LC0[46]0 does have the MMU, so the use case is valid.
If the difference is not noticable, then we would not need them.
My thinking exactly. ;)
But actually i think we don't need to change the build system for that. Its just a matter of the scripts, and which binaries are put into which archive.
Yes, it's a simple change. I just don't want to forget about this one as it becomes asked about more and more frequently: there are new batches of CT63 but the full 060s are slowly disappearing (and/or selling for ridiculous prices). So people got interested in the LC models.
i don't like the idea to have to spend several weeks of work to change a few hundred Makefiles and scripts just to support a hypothetical configuration that nobody uses.
You again read only the first sentence. :) That's why I explicitly wrote "provide only mintlib/gemlib/cflib snapshots as the bare minimum to build FPU-less FreeMiNT snapshot". Nothing else needs to be done, you don't even need to update your GCCs if you don't want to (GitHub Actions use the "our" gcc). But this is a technical detail, the main point is linking against FPU-less libraries.
Simplest solution would be to remove the FPU check in the startup code of mintlib (like libcmini already did), and just let the application crash if it actually uses FPU code.
Easier to implement, yes, but I'm not huge fan of this path. If something is compiled against -m68020-60 and the gcc manual says it uses the FPU whenever it wants, the right thing to do is to either not use that switch or consider it as FPU code. But that's for another debate, like https://github.com/freemint/m68k-atari-mint-gcc/issues/1. ;)
However 68LC0[46]0 does have the MMU, so the use case is valid.
And how many user do have a LC030? That would provide non-optimal kernels for all ST user, for the sake of some hypothetical user with an LC030. The more critical thing for ST users is IMHO memory, and i think it is more important for them to leave everything out that is not needed.
is linking against FPU-less libraries.
Hm, do i understand you correct, you want to compile with -m68020-60, but link using -m68000? That's quite dangerous.
All in all imho too much ugly hacks that have to be implemented, with a great potential of breaking things. You should first find out how many users would benefit from that, and who is actually using mint.
And how many user do have a LC030? That would provide non-optimal kernels for all ST user, for the sake of some hypothetical user with an LC030.
Not sure to what you are referring to, I have never said that the 000 archive and/or kernel should be extended to support 030+ CPUs. Just that we need another archive for such user base, in the simplest form 030/040/060 kernel + 000 user space applications.
Hm, do i understand you correct, you want to compile with -m68020-60, but link using -m68000? That's quite dangerous.
It is and that is why I don't want to do it, see above. So either normal -m68000 builds or -m68020-60 -msoft-float (with the help of a patched gcc), nothing fancy.
how many users would benefit from that, and who is actually using mint.
You can add download statistics on your server once available. ;) As I said, this task doesn't require anything fancy, so while it's easy to do, I don't see a reason to ignore such a demand, however small in the beginning.
Not sure to what you are referring to, I have never said that the 000 archive and/or kernel should be extended to support 030+ CPUs.
Well if you say that there is an issue that the st archive does not support memory protection, this would be implied. But maybe i misunderstood that.
So either normal
-m68000builds or-m68020-60 -msoft-float(with the help of a patched gcc), nothing fancy.
But why do you need such a patched gcc at all? Why not just put the m68000 binaries (of qed etc, not the kernel) in such an archive? Only thing you to watch out are binaries that are build in the freemint repo itself, mostly those from the tools directory.
It seems that there is some wall between us. ;)
So either
normal -m68000 builds
or
-m68020-60 -msoft-float (with the help of a patched gcc)
In other words, we are in agreement.
CT60 TOS (which has the emulator built-in)
Any idea how to detect that the FPSP is already installed on CT60? It does not seem to use XBRA from what i've seen, and just overwrites the 0xf4 vector. Should we just check for the CT60 cookie?
Other things that i noticed: the version that i assembled (originally taken from a disassembly of the Hades and Milan packages), uses moves in the copyin/copyout functions when called from supervisor (both in the 040 and 060 versions). https://github.com/th-otto/fpsp/blob/f247747c396dc1811c30b09f3606b161d22850b6/fpsp060/skel060.S#L206 Linux does the same: https://github.com/torvalds/linux/blob/5189dafa4cf950e675f02ee04b577dfbbad0d9b1/arch/m68k/ifpsp060/os.S#L122
Our version here (and also the CT60 package it seems) ignores the supervisor state.
Should we just check for the CT60 cookie?
I guess that's the easiest route, yes.
Other things that i noticed: the version that i assembled (originally taken from a disassembly of the Hades and Milan packages), uses moves in the copyin/copyout functions when called from supervisor
Huh, interesting. Even though we don't use the FCs, it still sounds like a good idea to use MOVES, doesn't it? I wonder whether our FPSP/CT60TOS explicitly removed it or Linux (and following up in Hades and Milan) they explicitly added it.
Updated the 060sp so that it can now be completely build from sources.
@agranlund : could you please test this, whether it works for your use case? It is still not contained in the archives, but you can just do "cd sys/arch/060sp; make"
Should we just check for the CT60 cookie?
I guess that's the easiest route, yes.
Considering cases like https://github.com/th-otto/fpsp/issues/1 I'd say we shouldn't check for anything. If one runs a FPSP, be it a PRG or within FreeMiNT, we should just use it.
It's way easier to update a PRG / FreeMiNT than provide a new CT60 TOS ROM.
But then we should use a different XBRA_ID. Currently, the version in mint uses 'MCSP', the same as the program for the Milan. We need to check atleast our own ID to prevent double installation.
Do we need to chain anything, actually? Why not just replace the vector(s) without calling the old ones?
Is there more trickery involved so we need the XBRAs?
Using XBRA is the only more-or-less reliable way of detecting whether a vector was already hooked, which is needed if we want to atleast prevent double-installation. The 060sp in mint only uses XBRA for the 0x2c (fline) and 0xf4 (unimplemented integer) vectors. And yes, in some cases we have to jump to the previous vector, eg. when the fline opcode is really invalid also on 68882.
And that is an issue? Why should someone use the st archive on 030, when there is a archive for tt? Its the purpose of the st/ste archives to omit explicit 030 and MMU support, in order to save some memory.
As a Suska owner, i would buy it. The Suska III-C and the Suska III-B has a, so called, 68K30L CPU core. In essence, it's a 68030 but without MMU, Caches and FPU (https://download.experiment-s.de/Configware/releasenotes.txt)
My initial comment was due to a misunderstanding and is already solved.
I don't know whether a 030 without MMU works (i think that suska board is the only one with such a CPU), but MMU support is currently always compiled in for 030 CPUs.
Although it is theoretically possible, i don't think that we want to create an extra target for this case (unless the 030 version does not work on your board).
Although it is theoretically possible, i don't think that we want to create an extra target for this case (unless the 030 version does not work on your board).
I just wanted to point out that there is such a thing, not often but still. To be honest, I don't know how many Suskas have been made or sold and whether it's even worth setting up an extra target for it.
If someone tells me how I can switch individual features on or off (just like linux configure script) then I can build the target myself.
You just have to remove $(MMU_SUPPORT) from https://github.com/freemint/freemint/blob/929c06cbf647855fde3b2f023cd936562c68fa1b/sys/KERNELDEFS#L66
Then do a make clean; make 030 from the toplevel, or the sys directory. Note that this will create a kernel with 1-19-cur as the $SYSDIR, in case you want to place it into some bootable build.
But as already mentioned, if the normal 030 kernel works on your system, all that it saves it a bit of code in the kernel (about ~10k)
Just that we need another archive for such user base, in the simplest form 030/040/060 kernel + 000 user space applications.
Exactly. The 020-060 kernel bootable build boots on my STE with MonSTerbo, but the applications that are compiled against mintlib does not start because I don't have an FPU. The same would apply to users with a standard Falcon. Also, it is missing the ST module folder. The ST bootable build works fine, but the ST kernel has less features (e.g. no RAM-disk) and of course is not optimized for the 020.
The missing ST module folder in the 020-060 build will affect users with other 020/030 accelerators as well.
Good point about the ST modules. I wouldn't have realised that even if booting 020+ kernel, the _MCH would be still ST.