68060 sources

[DrZiplok]

No-one wanted them without 060 or with LC. So the rest of the boards seem without value.

I'm not always shopping, but I just bought 5 last month. The 64M and stackable mezzanine cards are worth $$ if you can find the right buyer.

You're right that nobody wants the LC or EC versions that doesn't already have one.

[Chritoph]

y

Also LC060s are abundant and cheap. They can run at ~100 mhz, people just need to start compiling using the -nofpu option. Even if they don't, with SoftIEEE, you can still run FPU code and get more performance out of it than with a 68882, people just need to stop being snobs about the FPU.

Well...
This SoftIEEE?

SoftIEEE.jpg

75MHz Rev 4 + SoftIEEE = 0.13MFlops:

Rev4-75.jpg

25MHz 68882 = 0.66MFlops, ~5x faster:

68882-25.jpg

40MHz 68040 = 7.67MFlops, 59x faster:

040-40.jpg

50MHz 68050 = 28.01MFlops, 215x faster:

Rev6-50.jpg

100MHz 68050, 56.00MFlops, 430x faster:

Rev6-100.jpg

SoftIEEE is no option in my opinion, at least not the one in that benchmark. Is there a less precise but faster version of it?

[terriblefire]

I think SoftIEEE is misunderstood. Certainly people like Speedgeek over on EAB completely miss the point.

The point is for compatibility. Its there just to stop things crashing that are compiled with FPU support that dont really use FPUs. Things that might casually do a tiny bit of float math but dont rely on it for performance. The way amiga binaries seem to be built are such that anything that uses hardware FPU instructions just crash.

SoftIEEE is there to prevent the crash on EC/LC processors. Nothing more. Nothing less.

[mikro]

I think SoftIEEE is misunderstood. Certainly people like Speedgeek over on EAB completely miss the point.

The point is for compatibility. Its there just to stop things crashing that are compiled with FPU support that dont really use FPUs. Things that might casually do a tiny bit of float math but dont rely on it for performance. The way amiga binaries seem to be built are such that anything that uses hardware FPU instructions just crash.

SoftIEEE is there to prevent the crash on EC/LC processors. Nothing more. Nothing less.

Ah, this so nicely proves my fear about the same functionality requested in Atari world. :D We have a similar situation, 020+ binaries are compiled with FPU support. Sometimes the binaries don't really require FPU and people were complaining why the FPU check makes the application exit, i.e. whether the application couldn't just continue and/or have some bits emulated, ideally on the kernel level, similar to your SoftIEEE.

My reply back then was exactly this: people will start reporting low performance numbers, bad frame rate etc and I will end up explaining again and again that dude, this isn't meant to run your FPU games/demos, this is just a workaround.

Well, thanks for a look into my bleak future. :D

[terriblefire]

My reply back then was exactly this: people will start reporting low performance numbers, bad frame rate etc and I will end up explaining again and again that dude, this isn't meant to run your FPU games/demos, this is just a workaround.

Indeed. I just dont want to investigate crashes that arent crashes.

[agranlund]

My reply back then was exactly this: people will start reporting low performance numbers, bad frame rate etc and I will end up explaining again and again that dude, this isn't meant to run your FPU games/demos, this is just a workaround.

Indeed. I just dont want to investigate crashes that arent crashes.

My take on all this is that ideally fpu emulation would be built into the kernel just like it is on Linux, NetBSD, etc.
Slow is better than crash, especially for all those things that use fpu things sparingly.
And if you’re into computers as old as these none of this should come as a surprise? Pre-Pentium x86 came with and without FPU too and somehow we understood what we had and why the SX models ran some programs slower…

Even so, crash on fpu access is better than the Atari situation which prevents building 030/060 binaries at all (*) since our gcc crt0 inserts the FPU check and refuse programs to run at all, even those 99% of apps which don’t even use fpu.

(*) sure, one can use libcmini to get around it, or compile as -m68020-60 but link as -m68000 but still, it’s nuts and if you don’t know the workarounds your non-fpu apps wont work on LC.
I guess none if it mattered back in the days when full 060 where cheap but with todays prices LC makes a ton of sense especially if you aim to run it around 100mhz.

[mikro]

And if you’re into computers as old as these none of this should come as a surprise? Pre-Pentium x86 came with and without FPU too and somehow we understood what we had and why the SX models ran some programs slower…

As one technical person to another, I absolutely understand and support your POV. However as a person who sort of maintains the FreeMiNT kernel / minimalistic distro built around it... I'm 100% confident that every now and then I would keep reading about "freemint slowing things down" (some applications check for the FPU and if not found, deliberately choose a non-FPU code path for instance), replying to the same questions again and again.

Same as I do with the FPU error message, btw. The only difference is that now I can easily explain "no FPU, no fun" and with the FPU emulator I would need to explain how the FPU emulator works, why some other application seems to work OK, how to detect whether you have a real FPU or software emulated one etc etc etc...

Trust me, I have been doing this for about 8 years. Users never learn.

[Steve]

@mikro are there users out there with an LC / EC / non-FPU dumb enough to complain about slow FPU benchmarks, when they don't have an FPU? :)

[alexh]

No but there are users out there with LC / EC / non-FPU smart enough to complain that applications which used to run well are now slow because the application has inadvertently launched the FPU version instead of the fixed point version because it wrongly detected FPU support

[agranlund]

No but there are users out there with LC / EC / non-FPU smart enough to complain that applications which used to run well are now slow because the application has inadvertently launched the FPU version instead of the fixed point version because it wrongly detected FPU support

Are these real or theoretical applications?
And do they overshadow the amount of programs not launching at all even though they are not even using fpu instructions?

With LC, you are going to need to run only 68000 compiled versions.
Chances are if you are making something that requires a lot of grunt, you probably compile it for 68020-60 because well, it will only run on fast things anyway.
And then you hopefully realise that option somehow makes your non-FPU application not run without an FPU which is incredibly weird, and try to work around it.

Don't get me wrong, I completely do get the value behind being able to say "no FPU, no fun".
It hurts nowadays because it translates to "no $500, no fun" when technically the $50 option would have worked just fine in the majority of cases - FPU emulator or not.

Somehow the x86 world with far more configs and instruction set addons have survived without those kinds of auto-checks, and with having to explicitly tell the compiler which, if any, versions of SSE, AVX, etc you actually need.
Would be quite strange if Windows applications by default went "no SSE5, no fun" and you're only making some simple text editor or whatnot :)