search

freemint / m68k-atari-mint-gcc

Fork of GNU's gcc with support for the m68k-atari-mint target
https://github.com/freemint/m68k-atari-mint-gcc/wiki
Other
26 stars 7 forks source link

68030 target without FPU #1

Open vinriviere opened 7 years ago

vinriviere commented 7 years ago

All TT have 68030 and FPU. Falcon computers have 68030, but not all of them have FPU.

We already have the -m68020-60 target which generates efficient code for 68020/68030/68040/68060 but requires an FPU.

Would it make sense to add a new GCC target -m68030 without FPU for those Falcon without FPU?

mikrosk commented 7 years ago

I had been facing this dilemma when working on mxPlay and zView which have only 020-60 and 5475 builds available.

The outcome after all those years is that I've been asked many times to create a lite 68000 version but never a FPU-less 030 version. I'd say these days all "power users" do have the FPU. Or all the code and plugins are float-less, I don't know.

But, what would be pretty useful is to change the mintlib's CPU detection to include the FPU as well. So if someone runs a m68020-60 binary on a Falcon without the FPU, it would print a warning to the console that the program may crash if using FPU instructions.

vinriviere commented 7 years ago

I know that Patrice Mandin recompiles GCC just to have that FPU-less 030 version. I think this might matter for PmDoom for example, as 68030 has mulu.l instructions. To be benchmarked. Anyway, knowing that the GCC binaries are not suitable for everyone's needs makes me uncomfortable.

Adding a new 68030 soft-float multilib to GCC is easy. On the other hand, an additional multilib takes more time to compile GCC, and makes binary packages of GCC and all libraries bigger. I don't want to add that option if it is considered useless and not going to be widely used.

mikrosk commented 7 years ago

Yep, I hear you. Anyway, for his special needs I'd say he's fine with making a proper Makefile. I.e. for the given file (which I assume is part of an inner loop) override CFLAGS for -m68030 and let the rest for -m68000. Thanks to your changes few years back, even mixing FPU and non-FPU code is fine now.

For me it's a funny situation because I'd had the same strange feeling ("I have to provide 030 binaries if its for Falcon!") but after a few projects where I had to package, maintain and test separate builds I've realised how pointless it is. Users will never notice whether the menu is drawn in 350ms or 400ms and for the critical parts always extra care is needed.

Just my two cents, I'd love to hear opinion of others.

simonsunnyboy commented 7 years ago

From a user's point of perspektive, this is the correct way, specifiy the CPU target with a single option. This should include 030 without FPU. I personally have collected some obscure make settings but I am really unsure if the binaries will work properly on a Falcon without FPU (mine has)

vinriviere commented 7 years ago

@mikrosk The MiNTLib already has proper FPU detection in startup code (I added that long ago). Any program compiled with -m68020-60 and run on FPU-less Falcon issues a strong error message and does not run at all.

mikrosk commented 7 years ago

@vinriviere that's what I was referring to (but totally forgot the FPU part). Maybe it's enough to detect 020+ CPU and let the user know about the lack of the FPU as a warning. Because let's face it -- whole FreeMiNT, mintlib and gemlib are completely float-less.

vinriviere commented 7 years ago

By thinking twice, it would make sense to compile everything by default with -m68020-60 without FPU. Then provide FPU binaries only when it is worth, i.e. for POV-Ray and Quake.

mikrosk commented 7 years ago

Also an option but you'd break the rules set by gcc:

-m68020-60 Generate output for a 68060, without using any of the new instructions. This results in code that can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060.

vinriviere commented 7 years ago

"-m68020-60 -msoft-float" may do the trick (untested).

mikrosk commented 7 years ago

Well, that's essentially another target, isn't it. How it's done on architectures which (used to) run on the EC models? Do they pretend it's a full featured m68020-60 or did they create a separate target, like /usr/lib/m68020-60sp? I can imagine gcc is configured in either case as -m68020-60 -msoft-float as default.

vinriviere commented 7 years ago

Official generic m68k-elf target provided by GCC 6.3.0:

$ m68k-elf-gcc -print-multi-lib
.;
m68000;@mcpu=68000
m68040;@mcpu=68040
m68060;@mcpu=68060
mcpu32;@mcpu=cpu32
m51qe;@mcpu=51qe
m5206;@mcpu=5206
m5206e;@mcpu=5206e
m5208;@mcpu=5208
m5307;@mcpu=5307
m5329;@mcpu=5329
m5407;@mcpu=5407
m54455;@mcpu=54455
m5475;@mcpu=5475
mfidoa;@mcpu=fidoa
softfp;@msoft-float
m68040/softfp;@mcpu=68040@msoft-float
m68060/softfp;@mcpu=68060@msoft-float
m5475/softfp;@mcpu=5475@msoft-float
mfidoa/softfp;@mcpu=fidoa@msoft-float

Note: @ must be replaced by - to see actual compile options.

We cans see that -m68020-60 is not used at all by that target. That may make sense, as it is mainly used on embedded systems where the CPU can't change. We should have a look at 680x0 targets for other general operating systems to see what is used.

mikrosk commented 7 years ago

Oh, I was pretty close. :) So yeah, the question is whether we want to get rid of the FPU altogether, add another target (m68030/softfp looks like a good candidate to me) or do nothing. :)

I keep my original opinion (i.e. do nothing) but I wouldn't feel terribly offended with -m68030 -msoft-float would lead to /usr/lib/m68030/softfp. I'd generally ignore it (and if you think about it, from freemint point of view nothing but the number of libm targets has to change) and others can create symlinks for libc.a, libgem.a etc to /usr/lib/m68020-60 and have float-less libm.a (and perhaps other, custom, libs) in /usr/lib/m68030/softfp.

th-otto commented 7 years ago

Regarding the warning message issued from the startup code: i don't think that this is the right to do. First off, most users won't see that message anyway, unless they happen to have a toswin window open. Secondly, the startup code cannot know wether the program actually makes use of floating point, most programs won't. And most importantly, if you want to create a GEM program, but still provide a '030 version (knowing that you dont' need fp support), it would be absolutely bad to have the program spit message on the console, especially on single-tos. Also, i don't see much point in having the program abort or something on startup, if it uses FP on a machine without an FPU it will crash anyway. The most obvious solution would be to have something like a fpsp in the mint kernel in case of a missing FPU, but that might be quite some work.

mikrosk commented 7 years ago

@th-otto intriguing idea. Not only we wouldn't need another target, you'd enable the last remaining FPU-less users to enjoy virtually any FPU executable out there (will less performance, of course, but this isn't such an issue as the FPU is used mainly for precalcs on standard Falcon).

th-otto commented 7 years ago

Of course that would be slower than an application compiled for soft-fp, due to the additional overhead of the exceptions. And the drawback is, that you can't use the already existing FPSP for 040 or 060 that are e.g used for linux-68k, because you have to emulate ALL instructions, not only the missing ones. But i know quite some applications that don't do much floating calculations, but still need support for it at rarely used places, e.g when calling difftime(), or when averaging some ratios.

mikrosk commented 7 years ago

Btw, 'brown' guys have decided to take the -msoft-float path as well: http://d-bug.mooo.com/beyondbrown/post/gcc-6

vinriviere commented 7 years ago

Really, the current situation is not satisfactory at all. Currently, we can't produce binaries for FPU-less Falcon. This is exactly the same problem on Amiga/Vampire, where the Apollo 68080 is currently like a 68040 without FPU. Current binaries compiled with -m68020-60 can't run on those machines, because they expect an FPU, even if 99% of them (except POV-Ray) don't use it at all.

Starting from GCC 4 (or maybe my own config?), -m68020-60 requires FPU. As far as I understand, this was not the case with GCC 2.95. We should consider reverting that change.

My proposition is to use 5 multilibs :

So this covers all the possible machines.

The above list doesn't include anything specific for 68030, 68040 and 68060. But as I understand, compared to 68020, those processors have no new tremendous user-mode instructions which would bring huge benefits in user programs (of course, they bring many benefit for supervisor stuff, already used by FreeMiNT kernel).

As softfp will be the default, we will have to choose the name of the subdirectory for FPU libraries. ARM just uses "fpu", which is not a bad choice. Another good alternative would be "68881".

So regarding to subdirectories, we would have:

And do not forget we have to multiply this list by 2 to enable mshort libraries (this means an additional mshort subdir for each), because they are required by :

This means that libgcc and GemLib must be built 10 times! Annoying, but not really a problem when builds are automated.

Other libraries (such as MiNTLib) will only have to be built 5 times.

Then every user program will be free to provide appropriate binaries, usually:

Does the above cover all the real-world cases?

There are also some decisions to take, that will last:

th-otto commented 7 years ago

The above list doesn't include anything specific for 68030, 68040 and 68060. But as I understand, >compared to 68020, those processors have no new tremendous user-mode instructions which would >bring huge benefits in user programs

They do. Try do run the kronos benchmark on Aranym, one time with the 68040 module, and another time with 68030 module. There are huge differences.

So regarding to subdirectories, we would have: lib : for 68000 soft-float

There is another problem regarding this. The native gcc for mint in the sparemint package produces 020-60 binaries by default. So the /lib directory contains those libraries, while the lib/m68000 directory has the softfloat libraries. That makes it difficult to setup a correct installation in all makefiles for packages that produce libraries.

name of the FPU directory : fpu, 68881 or something else.

The default in the gcc configuration for m68kbare for the msoft-float directory is softfp. So i would think hardfp might be a logical name.

vinriviere commented 7 years ago

They do. Try do run the kronos benchmark on Aranym, one time with the 68040 module, and another time with 68030 module. There are huge differences.

Kronos only asks for a "module" on FPU tests. How could this be related to non-FPU stuff?

And in which way Kronos 68030 and 68040 tests are related to each other? That's closed source, we don't even know what is tested...

I would still be interested to know if GCC is able to generate significantly better FPU-less code with -m68040 compared to -m68020-60.

mikrosk commented 7 years ago

@vinriviere

Starting from GCC 4 (or maybe my own config?), -m68020-60 requires FPU. As far as I understand, this was not the case with GCC 2.95. We should consider reverting that change.

I don't think so. Man pages are pretty clear on this:

-m68020-60 Generate output for a 68060, without using any of the new instructions. This results in code that can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060.

Even if the note is related to 060 compatibility, it's clear it's using FPU instructions in general.

68000 + FPU : for completeness. Who is going to use that in the real world ?

What FPU? 68000 can have only the peripheral mode FPU and I doubt there's some support in gcc for that. Or you mean like "Run on your TT but we're going to use only 68000 instructions?" I'd skip this.

As softfp will be the default

See above. Don't do -m68020-60 softfp by default. Anyone googling for answers would be confused.

My proposal is therefore more straight-forward:

68020-60 soft-float : optimized for TT/Falcon, including CT60

I don't think so -- you must use hard float for CT60 builds, esp. if you want asm <-> C cooperation. You certainly don't want to have double c = a + b; written as anything else than fadd.x fp0, fp1. So all you want for CT60 is -m68060 linked with /usr/lib/68020-60/lib[cm].a. (it doesn't matter libm.a would use fsin and friends, nobody uses them in loops on CT60).

@th-otto:

The native gcc for mint in the sparemint package produces 020-60 binaries by default.

Huh? Since when? I think you're wrong here.

th-otto commented 7 years ago

Huh? Since when? I think you're wrong here.

$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/c/usr/bin/../libexec/gcc/m68k-atari-mint/4.6.4/lto-wrapper Target: m68k-atari-mint Configured with: ../gcc-4.6.4/configure --target=m68k-atari-mint --host=m68k-atari-mint --enable-languages=c,c++ --disable-nls --disable-libstdcxx-pch --with-gmp=/home/mikro/gcc/binary-package/m68020-60/gmp-5.1.2/usr --with-mpfr=/home/mikro/gcc/binary-package/m68020-60/mpfr-3.1.2/usr --with-mpc=/home/mikro/gcc/binary-package/m68020-60/mpc-1.0.1/usr --prefix=/usr CFLAGS='-O2 -fomit-frame-pointer' CXXFLAGS='-O2 -fomit-frame-pointer' --with-cpu=m68020-60 Thread model: single gcc version 4.6.4 (MiNT 20130415) (GCC)

$ gcc -print-multi-lib .; m68000;@m68000 m5475;@mcpu=5475 mshort;@mshort m68000/mshort;@m68000@mshort m5475/mshort;@mcpu=5475@mshort

as opposed to cross-compiler: $ m68k-atari-mint-gcc -print-multi-lib .; m68020-60;@m68020-60 m5475;@mcpu=5475 mshort;@mshort m68020-60/mshort;@m68020-60@mshort m5475/mshort;@mcpu=5475@mshort

My proposal is therefore more straight-forward:

I agree. That will make it much easier to use existing package of other libraries. In Vincents proposal, all of them would have to be rebuild, or at least the libraries moved around. Not that a rebuild & update to newer versions would be bad...

vinriviere commented 7 years ago

@mikrosk

What FPU? 68000 can have only the peripheral mode FPU and I doubt there's some support in gcc for that.

Ah, this makes sense. As I understand, this "peripheral mode FPU" is also called SFP004 in other places, and it is an Atari-specific device, mapped to Atari-specific address space. IIRC, PML might have support for that, but I agree, this is completely useless nowadays.

The key point of your information is: on 68000, FPU instructions can never be implemented in hardware. At most, they could be emulated by software with a Line-F emulator. And even in that case, I would bet that soft-float libraries would be faster. So just let's forget that.

Regarding to your multilib proposition:

It is important to make the right choices now, as they will last.

th-otto commented 7 years ago

but having to use 2 options -m68020-60 -msoft-float to build normal Falcon software is something like >a bad smell..

The question is what is a "normal" Falcon. I wouldn't be surprised if most of the Falcons nowadays actually have a FPU.

The risk is that people may forget to use -msoft-float and build binaries which require FPU by default >(like current situation), while their software actually don't use FPU at all.

If there software does not use any math functions, then it makes no difference when they forget -msoft-float ;)

But i think the key is that for packages that provide -m68000 and -m68020-60 versions, the latter is usually meant for software that does use the FPU, and hence FPU should be the default, as it is now. So the only real change that needs to be done is to provide extra archives for 020+ without fpu.

mikrosk commented 7 years ago

@th-otto

--with-cpu=m68020-60

Oh crap, somebody has taken one of my early experimental builds and packaged that as an RPM. The m68k one available on my website is definitely producing m68000 by default. Please consider gcc 2.95's behaviour as default.

If there software does not use any math functions, then it makes no difference when they forget -msoft-float ;)

The issue is that check for FPU during startup. You'd get an error that this software requires FPU (even if it doesn't).

@vinriviere

-m68020-60 -msoft-float to build normal Falcon software is something like a bad smell... The risk is that people may forget to use -msoft-float and build binaries which require FPU by default (like current situation), while their software actually don't use FPU at all.

True but then you will get the famous message box and exit (we can add something as "please compile your software with -msoft-float if 020 without FPU is required"). So the author would get feedback that hey, it doesn't work! And he would investigate and realise he's missing the soft float switch. And also -- this is how it used to work, so it's nicer to add new feature than change existing, known for what, 20 years?

Plus as @th-otto says, there's so few FPU-less Falcons... nobody has ever complained that zView doesn't run without FPU, but many people did complain it doesn't run on plain ST.

vinriviere commented 7 years ago

@atic-atac Any opinion regarding to this issue?

atic-atac commented 7 years ago

It's a genuine target, so we should cater for it, although I'm surprised that no-one has said anything before now on an FPU-less Falcon.

vinriviere commented 7 years ago

At least Patrice Mandin recompiles its own GCC due to lack of Falcon soft-fp target. It is a shame that users can't be satisfied.

vinriviere commented 7 years ago

And also -- this is how it used to work, so it's nicer to add new feature than change existing, known for what, 20 years?

Ok. So you prefer to avoid changing anything regarding to default options, library directories, etc.

Here is a test: 0001-Add-soft-float-multilibs.patch

Result is:

$ m68k-atari-mint-gcc -print-multi-lib
.;
m68020-60;@m68020-60
m5475;@mcpu=5475
mshort;@mshort
m68020-60/mshort;@m68020-60@mshort
m68020-60/softfp;@m68020-60@msoft-float
m68020-60/mshort/softfp;@m68020-60@mshort@msoft-float
m5475/mshort;@mcpu=5475@mshort

There are 2 new variants for libraries:

Note that for the m68020-60+mshort+softfp variant, softfp directory is inside mshort (and not the opposite). This way, no library moved. Only 2 new softfp directories appeared in the lib tree.

In order to test, I have recompiled libgcc, MiNTLib and PML for this new m68020-60/softfp variant. Then I have recompiled PmDoom with these new options, it works fine on FPU-less Amiga/Vampire. I attentively observed the result when linking with -Wl,-t: new softfp libraries are used, as expected. But as I had not recompiled and installed GemLib and SDL, the default libraries (68000 ones) are used instead. This is not a blocking problem, as long ago we agreed to use a compatible ABI for all variants.

So if someone fails to provide a 68020-60/softfp variant of a library, then the 68000 version will be used instead. This is somehow counter-intuitive, but that's GCC rules.

Shall we go ahead? If we decide to do so, we must explicitly support that new m68020 68020-60/softfp variant. This means adding support for it in all libraries. Specially the ones distributed with the cross-tools. For other ones, there is no hurry.

Other option would be: we don't care about FPU-less Falcon and unfinished Amiga/Vampire. Just use 68000 binaries on those machines. However, this doesn't fit the case of Falcon-specific games: compiling for 68000 excludes usage of 68030-specific features (mulu.l, etc.), while compiling with 68020-60 excludes FPU-less Falcons.

th-otto commented 7 years ago

This is somehow counter-intuitive, but that's GCC rules.

That's true, and it might cause trouble especially when using mshort. That will silently link to a total incompatible library. But not much we can do about it, avoiding that would require to identify the libraries somehow, but that is hardly possible with a.out. You get similar problems on x86_64 machines when trying to compile with -m32 and some brain-damaged configuration unconditionally adds -L/usr/lib64 to the search path, but there the linker will warn about that and skip those libraries.

Shall we go ahead?

Imho looks good.

Other option would be: we don't care about FPU-less Falcon and unfinished Amiga/Vampire.

Just two more lib directories isn't that bad. And for most libraries this will be only one, only a few are prepared for -mshort. And thanks to Travis nobody cares about compilation times ;)

However, this doesn't fit the case of Falcon-specific games: compiling for 68000 excludes usage of >68030-specific features (mulu.l, etc.),

That might not be optimal, but it should still work at least.

mikrosk commented 7 years ago

If we decide to do so, we must explicitly support that new m68020 68020-60/softfp variant. This means adding support for it in all libraries.

Is this really necessary? At least gemlib and mintlib could just symlink <prefix>/m68020-60 as they don't use any fpu code. There's pretty good chance the resulting binaries will be byte-to-byte same anyway.

vinriviere commented 7 years ago

Well, I just don't want to take the risk to provide wrong libraries, in (the unlikely) case some FPU code is generated by GCC in some hidden place. Then if the user is fine with mixing libraries in his own code, that will be his own responsibility.

The key point is: if we decide it is worth to fix the case of FPU-less Falcon, let's to that together, and support that solution. I will not undertake all that work if finally it is not used.

th-otto commented 7 years ago

At least gemlib and mintlib could just symlink /m68020-60 as they don't use any fpu code.

mintlib does use fpu code. The printf functions, difftime(), some functions in the sunrpc library, functions like strtod() etc...

@vinriviere I agree. There is no point in risking to provide wrong libraries only to safe some compilation time. At least the libraries hosted here should be recompiled by that new gcc version.

vinriviere commented 7 years ago

@mfro0 @czietz Any opinion?

czietz commented 7 years ago

@vinriviere Sorry, since I do not own anything better than an ST ‒ I wish I did ‒, I haven't ever used targets other than the plain 68000 one. So I don't think I can really contribute a meaningful opinion here.

That being said, your proposal in https://github.com/freemint/m68k-atari-mint-gcc/issues/1#issuecomment-309670346 sound good.

mfro0 commented 7 years ago

@mfro0 @czietz Any opinion?

Sure.

I might be biased - as I own, for example, an m54455 machine (FPU-less ColdFire) that I'd like to see running MiNT one day - but my assumption is it would be worse (i.e. more disappointing to users) having MiNT crash (or exit) on an FPU-less machine than running the same thing a few percent slower on anything that has an FPU.

"Real speed junkies" are probably rather able to compile something themselves that 100% fits their config anyway (although I'd expect you won't really recognize any FPU speedup anyway with MiNT alone).

On the machines in question, I'd assume performance isn't so much an issue as to provide something that runs as universal as possible.

So my vote would be: provide as much optimization as possible for the slower machines (like 68000 and maybe 68000 + SFP), while having something available as versatile as possible for the faster ones (i.e. create the m68020-60 version with soft-FPU, which equals - as I understand - your proposal #1).

vinriviere commented 7 years ago

May I implement what I proposed, in our official MiNT GCC patch?

mikrosk commented 7 years ago

Since you know at least one developer who would really appreciate that and there's maybe 20 active developers at all, I'd say go ahead. Ideally if you could provide Makefile patches for all the 'mainstream' libs (cflib, gemlib, mintlib).

I was shortly considering yet another way -- only -m68000, -m68030 (which would have defaulted into 030+softfp) and -m68060 (060+FPU) but this could make people aiming Milan/Aranym (040) uncomfortable ("Should I choose the 030 or 060 target?") so then I got -m68030, -m68040, -m68060 libraries. The main benefit would be 100% 040/060 compatible code, because -m68020-60 emits stuff which is 060-unfriendly like the bit field instructions or removed FPU instructions.

But then I realised that we would loose the universal target which -m68020-60 provides ("I have no clue what my user base is but it should run somewhat efficiently on all 020+ machines") so having FPU+softp versions of exactly that seems like the best thing (plus -m68060 code links well with -m68020-60 mintlib where certain overhead, as in any library, is assumed).

vinriviere commented 7 years ago

@mikrosk Can you prove that -m68020-60 emits stuff which is 060-unfriendly? From what I understand, it is supposed to be the opposite: friendly with all 68020 / 68030 / 68040 / 68060. In other words, only using the intersection of all instruction sets.

mikrosk commented 7 years ago

@vinriviere it works the other way around: -m68020-60 promises not to use any 040/060 instructions (move16 in particular). gcc's man page explicitly mentions that. Personally I've seen it generate the bit field instructions when manipulating, well, bit fields, but I don't haven an example at hand.

mikrosk commented 7 years ago

I don't haven an example at hand

This was disturbingly easy to provide:

struct A {
    int x :3;
    int y :4;
};

void g(struct A a);

void f() {
    struct A a;
    a.x = 2;
    a.y = 3;
    g(a);
}

m68k-atari-mint-gcc -m68020-60 -O2 -c test.c -o test.o

m68k-atari-mint-objdump -d test.o

test.o:     file format a.out-zero-big

Disassembly of section .text:

00000000 <_f>:
   0:   2f0e            movel %fp,%sp@-
   2:   2c4f            moveal %sp,%fp
   4:   4240            clrw %d0
   6:   7202            moveq #2,%d1
   8:   efc0 1403       bfins %d1,%d0,16,3
   c:   123c 0003       moveb #3,%d1
  10:   efc0 14c4       bfins %d1,%d0,19,4
  14:   2f00            movel %d0,%sp@-
  16:   4eb9 0000 0000  jsr 0 <_f>
  1c:   588f            addql #4,%sp
  1e:   4e5e            unlk %fp
  20:   4e75            rts
vinriviere commented 7 years ago

Sorry for my ignorance, but what's wrong with the bfins instruction on 68060? It is present in the manual, without any specific warning. Also, GCC generates the same code with -m68060, which is supposed to be optimal for that processor.

mikrosk commented 7 years ago

:scream: this must be the surprise of the year for me. For years I would have sworn that the bit field instructions are a no-no for the 060. Wow. I guess my confusion comes from the fact that I often used the M68K PRM which does list only them as 020-040 only but that's because it doesn't list the 060 at all. :-)

At least I've learned about -mno-bitfield switch and taken a closer look on the switches again:

-m68020-60 Generate output for a 68060, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060.

-m68060 Generate output for a 68060. This is the default when the compiler is configured for 68060-based systems. It is equivalent to -march=68060. This option inhibits the use of 68020 and 68881/68882 instructions that have to be emulated by software on the 68060. Use this option if your 68060 does not have code to emulate those instructions.

Perhaps this really means that on -m68020-60 all integer instructions not present on the 060 are avoided while some FPU instructions are used even if they are emulated. What sounds like a fair compromise, considering the fact that nobody would assume fsin() and friends to perform well on any architecture.

Anyway, one more reason why -m68020-60 is a good choice.

vinriviere commented 5 years ago

Patch proposed there: https://sourceforge.net/p/freemint/mailman/message/36431896/

th-otto commented 5 years ago

On Mittwoch, 3. Oktober 2018 21:37:02 CEST Vincent Rivière wrote:

Do you think it is a good thing to officially adopt this change? This will allow to build software optimized for plain Falcon without FPU I'm not sure about this. If i interpret the patch correctly, -m68020-60 alone will still produce floating instructions, and you have to explicitly specify - msoft-float to support the new target? That would be ok i think. Only problem that we also have to support that at least in mintlib, too, otherwise it does not make much sense.

vinriviere commented 5 years ago

You understood well. The idea was to use both -m68020-60 -msoft-float to trigger the new target. Of course, we will have to rebuild all the libs for this new multilib. Ideally, for maximum flexibility, all build scripts should ask GCC for the list of supported multilibs and do the right thing accordingly (inside some iteration).

Well, regarding to MiKRO's answer on the MiNT Mailing List, I'm now wondering if this whole issue is still relevant. Naively, I feel that ability to create binaries (i.e. PmDoom) optimized for stock Falcon without FPU is legitimate... If I remember well, Patrice Mandin always rebuilds his own GCC exactly for that. It is a shame that official binaries don't fit everyone's needs.

mikrosk commented 5 years ago

Naively, I feel that ability to create binaries (i.e. PmDoom) optimized for stock Falcon without FPU is legitimate... If I remember well, Patrice Mandin always rebuilds his own GCC exactly for that. It is a shame that official binaries don't fit everyone's needs.

Don't forget Patrice had been creating that gcc also for the ability to use 64-bit multiplication. That's why I mentioned that if adding a soft-float target, it should me m68020/msoft-float and not m68020-60/msoft-float.

th-otto commented 5 years ago

On Donnerstag, 4. Oktober 2018 09:07:35 CEST Miro Kropacek wrote:

it should me m68020/msoft-float and not m68020-60/msoft-float.

That wouldn't be quite right. First off, Falcon is 68030 at least, not 68020. And secondly, you could theoretically have some board with 68EC040 (ie 68040 without FPU), where that target might also be useful. Using your naming scheme, that would require to create a lot of more libraries.

mikrosk commented 5 years ago

Using your naming scheme, that would require to create a lot of more libraries.

And that's the reason why I'm reluctant to actually do anything at all. Introduction of an FPU-less target had only one strong reason, ability to run stuff on FPU-less Falcons. That would be sufficient reason for m68020 (or 30, doesn't matter) target.

To make things prettier, we could "transform" m68020-60 target into m68020/m68020-60 along with m68020/msoft-float. That would clean up the current invasive patch, added a target to make people like Patrice happy and keep the status quo otherwise.

Btw, I don't think we need to care about 040/060 EC variants - right now, m68020-60 uses FPU instructions which are emulated even on full 040/060 CPUs, so a FPSP package is implicitly assumed.

mikrosk commented 5 years ago

Just a note, this is the patch which introduced the strict multilib rules (and kind of deprecated -m68020-60 multilib): https://gcc.gnu.org/ml/gcc-patches/2007-01/msg00813.html

AtarianComputing commented 3 years ago

Well, it seems that since the FPU-less TF536 has started to see wider adoption, this issue is raising its head once more. I just installed EasyMiNT and immediately noticed that e2fsck would not run at start as it required an FPU. Then I went ahead to update bash to version 4 and got the same error. I had to install the 68000 binary to actually have a shell.

What can I do about this? I'm not a software dev so everything discussed here is slightly beyond me but not the point that I am completely ignorant.

snap_11