![]() |
![]() |
#181 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,490
|
*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,917
|
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,490
|
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,917
|
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,490
|
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: 61
Posts: 850
|
Quote:
![]() |
|
![]() |
![]() |
#187 |
Registered User
Join Date: Jun 2019
Location: Tokyo
Posts: 70
|
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 |
![]() |
![]() |
#188 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,490
|
Quote:
The 68882 FPU on your motherboard is only accessible through an 68030. You could in principle provide an 68882 FPU as a memory mapped device, and provide this to SoftIEEE through a softieee.library that, instead of emulating FPU operations in software, provides the data to the 68882 and computes the resuls there. Thus, in general, what you *would* need to do is to implement your own softieee.library using the API as described in the SoftIEEE archive, and the SoftIEEE patch would be happy about it. Thus, if you want to do that, I can certainly help you with technical details (even though I believe the API of the softieee.library is described clearly enough, but anyhow). The issue is just that this will not provide you a speed advantage. A 68882 requires tenths of cycles (20 to 80) for elemenary operations, and the SoftIEEE patch still needs to receive the source data, and your softieee.library would need to take this data, feed it into the 68882 working as I/O device, implementing the co-processor hardware manually as I/O operations. The net result will be quite slow, and my best guess is that it would be slower than emulating the FPU in software. Anyhow, my doors are open. If you want to experiment with this idea, you are welcome, but please don't be disappointed if this does not provide you a speed advantage over what you have now. |
|
![]() |
![]() |
#189 |
Registered User
Join Date: Jun 2019
Location: Tokyo
Posts: 70
|
Thank you very much for the detailed explanation - love to hear some of the background on how things work! Based on this it is clear to me that the outcome would not improve over what already exists, therefore pursuit of this will never provide any gains.
Really appreciate it! RDP |
![]() |
![]() |
#190 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,663
|
|
![]() |
![]() |
#191 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,490
|
Not really. A 68060 requires a single cycle for an floating point addition. A 68882 about 20 cycles. Now take that into perspective how many cycles you need to emulate the FPU instruction, read the source, fill it into the 68882 mapped as IO device, read the result, copy the result out to memory... and then compare it with how many cycles you need to actually *perform* the addition in software. It's not really that much different.
But anyhow... If you want to try that, sure. It would be interesting to see how it performs, but as said, I won't hold my breath. |
![]() |
Currently Active Users Viewing This Thread: 3 (0 members and 3 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 |
|
|