Betatesting SoftIEEE FPU emulator

[Thomas Richter]

Originally Posted by Karlos

How feasible is it to extract the the IEEE code into a library that simply provides regular functions for performing the operations on floats and doubles, without all the trap emulation? Something like the mathieee#?

*Cough* That *is* actually the design of the whole thing. You have the softieee.library, which is the mathematical core in the form of a user-callable library, and you have the SoftIEEE executable, which does the patching and trap-emulation. Thus, for example, if you use MuRedox, it does not use the trap emulation of SoftIEEE, but its own, and calls into the library.

[Karlos]

Right, but what I meant as an endgame is the ability to compile code that contains float/double operations and have it directly generate binaries for integer-only systems that transparently call the softieee library.

Or does MuRedox make this approach irrelevant?

[Thomas Richter]

That is actually a matter of compiler vendors. Most compilers will be able to emit code that calls into the system mathieee libraries, and those also operate without an FPU (and are then also faster than softieeee as they only implement double and not extended precision and do not need to update the status of the emulated FPU).

[Karlos]

Sure, I get that compilers need to be updated. However, if mathieee libraries are already faster than softieee then there's probably no point to my suggestion. Knowing what you know, could softieee routines be used to build faster versions of the existing mathieee libraries if only 32 and 64 bit routines are used? I would be surprised if those old libraries are the most optimal solution for later 68K CPUs.

[Thomas Richter]

The precision of SoftIEEE depends on the contents of the (emulated) FPU control register, and thus it has to offer extended precision. SoftIEEE will be never as fast as the Os mathieee.libraries, they are really optimized for speed, take arguments in registers, generate output in registers and don't fuzz with things like rounding, emulation of the FPU status register or compute precision. Algorithms are also different - mathieee uses polynomials for the transcendental functions, softieee uses Cordic.
Speed was never really the goal of the project. If you need speed, the best option is a hardware FPU, you cannot beat that.

[SpeedGeek]

Originally Posted by Thomas Richter

The precision of SoftIEEE depends on the contents of the (emulated) FPU control register, and thus it has to offer extended precision. SoftIEEE will be never as fast as the Os mathieee.libraries, they are really optimized for speed, take arguments in registers, generate output in registers and don't fuzz with things like rounding, emulation of the FPU status register or compute precision. Algorithms are also different - mathieee uses polynomials for the transcendental functions, softieee uses Cordic.
Speed was never really the goal of the project. If you need speed, the best option is a hardware FPU, you cannot beat that.

Thanks for explaining why software emulation can not replace the performance of the hardware FPU (only the results). I only wish you had done this a few years ago (before certain members of the Terrible Fire group trolled against my 68LC060.library). Anyway, better late than never.