![]() |
![]() |
#181 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,373
|
*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.
|
![]() |
![]() |
#182 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,778
|
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? |
![]() |
![]() |
#183 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,373
|
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).
|
![]() |
![]() |
#184 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,778
|
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.
|
![]() |
![]() |
#185 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,373
|
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. |
![]() |
![]() |
#186 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 848
|
Quote:
![]() |
|
![]() |
![]() |
#187 |
Registered User
Join Date: Jun 2019
Location: Tokyo
Posts: 69
|
The 608060 cannot have an external FPU. Ok, fine, but..../
This software makes the system think a FPU exists, and runs the code in software. Now for the silly idea/thought: If this software can fool the system into letting FPU calculations run in software, could it also not use the external 68882 that I have on my 25mhz A3000 motherboard (just my setup as an example where a FPU exists)? Or does having a 040/060 accelerator connected disconnect the 68882 from being accessed? I figure offloading FPU calculations to a motherboard FPU would be much faster than a software solution. thanks! RDP |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Demos to test FPU on SX32 MkII (020+FPU) | Rochabian | request.Demos | 1 | 21 April 2020 03:03 |
Betatesting Amiga and C64 Forever 7 | michaelz | support.Amiga Forever | 23 | 22 June 2017 16:58 |
[obsolete] EoB 2 Thread AGA and translations betatesting | Marcuz | project.Amiga Game Factory | 17 | 21 August 2008 22:47 |
Frederic's Emulator inside and Emulator thread | Fred the Fop | Retrogaming General Discussion | 22 | 09 March 2006 07:31 |
|
|