Page 1 of 1
I+O FPU not supported?
Posted: 02 Jun 2021 00:31
by Darklord
So I installed a 68881 FPU into my Mega STe along with the corresponding GAL and
things are mostly fine. Sysinfo says it's there, after running the FPU emulator, FPUTEST
says it passes, but Gembench 6 says "I+O FPU not supported".
Not sure what that means exactly? I know the implementation of the FPU on the Mega
STe is different than the TT and Falcon. (we're back to Line F stuff, right?)
Is that what it's reporting?
Thanks.
Re: I+O FPU not supported?
Posted: 02 Jun 2021 01:00
by exxos
Read the readme ;)
Re: I+O FPU not supported?
Posted: 02 Jun 2021 08:11
by terriblefire
NO IO MAPPED FPU ASM CODE for MSTE & STFM - simply not supported.
IO mapped FPU works different than the FPU on the 030 CPU with Falcon etc. So 2 FPU tests would need to be programmed and wouldn't have any correlation to each other anyway.
IO mapped FPUs are evil. They need you to implement the 020/030 coprocessor interface protocol in software. Ouch yeah.
Re: I+O FPU not supported?
Posted: 02 Jun 2021 19:11
by Darklord
Okay, gotcha. Thanks guys! :)
Re: I+O FPU not supported?
Posted: 02 Jun 2021 19:30
by frank.lukas
Use GemBench 4.03 ...
MSTE.gif
Re: I+O FPU not supported?
Posted: 03 Jun 2021 05:19
by Darklord
Ah.... Thanks Frank.
Re: I+O FPU not supported?
Posted: 03 Jun 2021 19:11
by pixelpusher
terriblefire wrote: 02 Jun 2021 08:11
NO IO MAPPED FPU ASM CODE for MSTE & STFM - simply not supported.
IO mapped FPU works different than the FPU on the 030 CPU with Falcon etc. So 2 FPU tests would need to be programmed and wouldn't have any correlation to each other anyway.
IO mapped FPUs are evil. They need you to implement the 020/030 coprocessor interface protocol in software. Ouch yeah.
Just for reference: I lately checked a 16 MHz Falcon 030 vs. a 16 MHz MSTe using a software LineF emulation. Both switched to a 68881. Using a Fractal (control panel) test program, the speed difference between the hw LineF implementation of the 68030 and the software emulation on the 68k was about 5x in this test, slightly fluctuating with the fractal parameters (due to the constant overhead the LineF software emulation creates).
Granted it was only one test (GB 6 still ignored the LineF emulation, telling me that there was no FPU to test, while GB 4 still seemed to use the IO addr directly to execute its FPU test), but it should give an idea of what to expect speedwise on the 68k and how high the overhead is.
Re: I+O FPU not supported?
Posted: 03 Jun 2021 19:45
by exxos
GB6 doesn't support IO mapped. Simply because the results from GB4 were massively different between IO Mapped and LINE F. The comparison was meaningless.
But as @terriblefire, the overhead is all in software with IO mapped. So you're really only benchmarking RAM speed more than the FPU. Aside from that, almost nothing really uses the LINE F FPU, IO mapped, never heard of any software for it.
If people are *really* that bothered about missing IO mapped FPU tests, then create me a lib I can interface to and I can add it to GB6, but even so, the bulk of the overhead will be simply ram speed because of the instructions overhead. Plus you still cannot really be compared to a LINE F FPU the 030 CPU can access it at full speed without software emulation. So it will always be inherently many times faster than IO mapped. Caches will also increase speed because of faster "RAM loops".
GB6 IIRC looks for the FPU to be registered correctly with cookies.
Re: I+O FPU not supported?
Posted: 03 Jun 2021 20:20
by pixelpusher
exxos wrote: 03 Jun 2021 19:45
GB6 doesn't support IO mapped. Simply because the results from GB4 were massively different between IO Mapped and LINE F. The comparison was meaningless.
But as @terriblefire , the overhead is all in software with IO mapped. So your really only benchmarking RAM speed more than the FPU. Aside from that, almost nothing really uses the LINE F FPU, IO mapped, never heard of any software for it.
If people are *really* that bothered about missing IO mapped FPU tests.. Then create me a lib I can interface to and I can add it to GB6, but even so, the bulk of the overhead will be simply ram speed because of the instructions overhead. Plus you still cannot really be compared to a LINE F FPU the 030 CPU can access it at full speed without software emulation. So it will always be inherently many times faster than IO mapped. Caches will also increase speed because of faster "RAM loops".
GB6 IIRC looks for the FPU to be registered correctly with cookies.
Well it's a chicken-egg situation (and ATARI's not so clever usage of the LineF instructions in the 1.x ROMs made LineF emulations even slower due to necessary address checks for the ROM).
In this fractal test app I can see the advantage of the FPU on the 68020/30/40 even over a good fixed point assembler implementation; compared to a software floating point lib most compilers otherwise would use, even the FPU with or without LineF emulation on a 68k will give you a speedup.
How much will also depend on what instructions or real world fpu applications you actually use or test - also in GB (I haven't found any docs about what is used there - yet).