Betatesting SoftIEEE FPU emulator

[Samurai_Crow]

Originally Posted by Thomas Richter

Sorry, I'm completely confused on what you are proposing here. First, you say "coprocessor circuits present in the 68020 and 68030 were offloaded to an external chip on the 68040 and 68060". Nothing was "offloaded to an external chip" there. Actually, nothing was offloaded to external hardware. The missing opcodes are offloaded to external software (the fpsp.resource). So do you want to say "I plan an external chip that replaces the fpsp.resource"? If so, softIEEE has no role here. This process works (a bit) different compared to SoftIEEE, and it would need to go through a CPU library, or lacking this, an fpsp.resource.



What has Gunnar to do with all this? Even if you disable the FPU on his design, the FPU remains active for elementary math and would continue to process data for such elementary operations in only 56 bits rather than the full precision offered by SoftIEEE. Thus, at best you can offload some transcendental functions to an external chip, but whether it makes sense to go through the emulator trap rather than his "millicode" I cannot judge.



Third, what has all this to do with a vector unit, and how does SoftIEEE plays in here? As said, going through an emulator trap does not make sense, it would be only slower than scalar math operations carried out multiple times, so as a software interface to an external chip it makes little sense. I



If you propose to use SoftIEEE as some kind of "prototype system" where you catch (lacking hardware) the instructions by software - well, you can do that as of today. It would make sense there as temporary solution just to test the chip until the full interface becomes available in silicon. Just implement a softieee.library. Will I do that? No - that's not the purpose of the project, but the interface is open and documented, so it is doable, and I can help you to understand how the interface works.



If you plan to do that as an external chip for the 68LC040 to provide an FPU - that is possible, though again not exactly fast, so I'm not sure how competitive such a design could be.



If you plan that as an external chip for Gunnar's 68EC080, I guess you better talk to Gunnar to get it linked to the system as some sort of coprocessor interface. Good luck with that. The chip currently lacks the ability to re-route all FPU instructions, and even if you can re-route the transcendental functions as a subset to an external chip, it would likely not perform very well, but that's not my problem at all.



Last but not least, I doubt any soft of FPU can be implemented on a CPLD, these chips are much too tiny for such complex operations. You can probably implement a CORDIC logic in an FPGA to get the missing functions, but you would still need to find a way how to interface this chip to either a Mot chip, or Gunnar's EC080. For the 68040 and related chips, there is no coprocessor interface, thus some software layer is necessary. Yes, SoftIEEE can do that (minus vector instructions), and the answer is that you then need the right softieee.library. Doable, read the documentation, then ask me in case you have additional questions.



Thus, to conclude: Please write a concise project proposal of what exactly you are attempting to do. I cannot really make much sense of what you have written so far - sorry.

Thanks for your suggestions. I won't waste any more of your thread.

[OldB0y]

Originally Posted by alenppc

You can grab the NovaCoder's softfloat version (posted in the Quake thread) and it should be slightly faster, although the 3660 is an awful card so probably not by much.

Cool, can you point me in the direction of this thread - I can't seem to locate it with the search function. Cheers!

[TCD]

Originally Posted by OldB0y

Cool, can you point me in the direction of this thread - I can't seem to locate it with the search function. Cheers!

https://eab.abime.net/showthread.php?t=64697

[alenppc]

Originally Posted by OldB0y

Cool, can you point me in the direction of this thread - I can't seem to locate it with the search function. Cheers!

Specifically this post:



https://eab.abime.net/showpost.php?p...&postcount=287


Keep in mind that an integer version of Quake source exists as well, but it has not been ported onto the Amiga. That one would make a major difference in performance.

[Reynolds]

Originally Posted by alenppc

Specifically this post:



https://eab.abime.net/showpost.php?p...&postcount=287


Keep in mind that an integer version of Quake source exists as well, but it has not been ported onto the Amiga. That one would make a major difference in performance.

AFAIK Quake can be started with disabling FPU routines. At least the frontend I use has a tickbox with that function. (Can't recall if it really works or not, though)

[Dynamic_Computi]

Brilliant as always, @Thomas Richter - I am installing a new BFG in my Amiga 3000 tomorrow for a review and look forward to trying this out with my 68LC060. I am sure it will be slow, but it will mean I don't have to remove and reinstall my FPU aware software like Art Department and ImageFX!
I will report back with my findings if I run into any issues.

[rzookol]

btw. as FPU is inside 060EC and 060LC just disabled, maybe it is easier to force enabling it than to use such emulator? Is it doable? I would prefer halfworking fpu than emulated one.

[Thomas Richter]

The LC CPUs are produced from a different mask set, you cannot enable the FPU on these chips. Either, it is not present at all, or it is disabled by hardware (burning a fuse on the mask).

Either way, Motorola had its reasons for disabling the FPU. Is it really helpful to compute something, and then getting an incorrect result, or sometimes getting an incorrect result?

[alexh]

In later LC/EC chips the die physically have no FPU/MMU. They have their own mask set according to the Motorola PCNs.

Earlier LC/EC marked chips they are there, they are not disabled in any way, they are detectable but not guaranteed to work. Presumably the applications they were being sold into (telecoms?) were supposed to just not use them.

[Thomas Richter]

In the next days, the 40.4 of SoftIEEE should appear in Aminet for download.

I had now access to my 68060 board in the A2000 again, and as always, testing on real hardware under real conditions revealed a couple of additional problems the 40.4 fixes.

- Emulation of frestore on the 68060 was broken. Its test for the stack frame format was wrong, and thus the instruction always reported an "invalid stack frame", thought the frame was fine, just the test was wrong.
- Emulation of fsave is supposed to place the invalid operand of a previous floating point exception on the stack frame. Unfortunately, the operands were taken from the activation record of fsave, which does not have any operands, and thus some nonsense appeared there. Now, SoftIEEE records the operands upon creating the exceptions, and fsave stores them away on the stack.
- The (already reported) and so long unknown 68060 erratum triggered also on fsave, and thus a workaround is required for this instruction, too. To remind you, documentation says that the "FPU disabled" exception includes the effective address of the FPU operation, but for some instructions, it just contains nonsense. "fmovem from memory" was already identified as a problematic instruction, and now "fsave" is another one. For safety reasons, I also enabled the manual EA computation for all types of fmovem, and fsave and frestore, which should hopefully be fine.

Just interesting to see that even a Rev.6 68060 contains surprises and is all but problem-free. As this erratum was unknown by Motorola, it is probably no surprise it was never fixed.

Also on Aminet is the 1.105 of the low-level debugger COP which supports now SoftIEEE if activated by a command line switch. If so, the debugger provides access to the emulated FPU registers and states such that you can debug an FPU-using program even on an emulated FPU.

Running higher-level debuggers on SoftIEEE such as MonAm was already working (well, at least after applying the fsave work-around and the frestore bug, but those were software problems and not related to the 68060 erratum).

[Thomas Richter]

And the best for the rest (of the year 2022)...

As indicated earlier in this thread, I already had the possibility in mind to replace the lengthly FPU emulation through SoftIEEE by a faster just-in-time compiler that replaces the FPU instructions to calls into the softieee.library.

Now, finally, I have a new beta version of MuRedox and SoftIEEE ready for exactly that. Expected speedup over SoftIEEE alone is approximately three-fold. That's still a factor of 3 behind the mathieeedoubbas.library, but you can use native FPU code on LC processors and make it a bit (actually quite a bit) faster than through FPU emulation alone.

Installation instructions are quite simple:
1) Install the MMULib package (if not already done)
2) Install SoftIEEE (from the attached archive) and run it,
3) Install MuRedox from the attached archive and run it.

Voila, on LC processors, you now have a FPU and a jitter that patches FPU instructions on the fly.

As always, this is beta software, and I kindly ask you here to report on problems you may run into, please with as detailed instructions as possible on how to reproduce them.

There are a couple of restrictions:

- MuRedox currently requires an 68040, 68060 (as before) or (and that is new) a 68LC040 or 68LC060 processor. It will not "jitter" an FPU on a 68030 or 68020. I may lift this restriction later, but emulation there has to go through a somewhat different path. SoftIEEE offers that, MuRedox does currently not.

- MuRedox cannot emulate three rarely used instructions: frestore, fsave and ftrap. The first two are only 2 bytes long, but MuRedox requires 4 bytes for the jump into the replacement function. The only common point of usage is the exec scheduler, but that's replaced by SoftIEEE already, so no loss. ftrap is rarely used at all, and it is not emulated because it can generate an exception.

- Exceptions in general are not emulated. That is, if FPU exceptions are enabled (and they are usually not) MuRedox will not call into the exception vector. That would require a rather lengthly test at the end of each instruction. SoftIEEE emulates it, MuRedox does not. As said before, FPU exceptions are barely used, so hopefully not much of a loss.

- The INEX1 flag is not emulated properly. This flag is set if precision is lost during conversion from packed decimal to extended. Instead, the replacement function sets INEX2, the "generic" precision loss flag. Again, this flag is rarely looked at, but I may include proper emulation later. Note that SoftIEEE does emulate all the FPU flags correctly.

Thus, all the best for 2023, and happy testing!

Thomas

[Don_Adan]

Why dont using AllocTrap from exec for patching 2 bytes instructions? Of course if AllocTrap is finally working correctly. Many years ago i used AllocTrap, and it works, even if it looks like it was buggy for kick 2.0.

[Thomas Richter]

frestore and fsave are of course emulated by SoftIEEE, that's not the issue. However, they cannot be replaced by jitter functions that *do not* go through an emulator trap. The trouble is that calling a "jitted" function takes at least 4 bytes (JSR.W), but there aren't 4 bytes available to patch.

Replacing them by "traps" does not provide any advantage - a trap is nothing but an exception, but then, there is nothing gained as that replaces just one exception (the original one as captured by SoftIEEE) with another exception (that of the trap).

The whole trick of MuRedox is that there are no exceptions involved anymore.

[Thomas Richter]

A short ping at the new year, kindly asking for testing and feedback on the above attachments. Programs like this live from your feedback.

Thank you, and a Happy New Year 2023.

[blasterreal]

This is TF1260 100mhz sysinfo output, Before MFlops :0.09 now:0.91

[jeff b00toNic]

Hope this helps.

AmiQuake


Shadow Warrior: ground texture distortion

[Thomas Richter]

Thanks, I found two bugs that are fixed in the attached version. First, fmove to memory with some addressing modes did not work correctly, and second, the branch instructions were not indexed correctly in the MuRedox cache.

Could you please kindly try the attached version again?

Thank you,
Thomas

[jeff b00toNic]

It seems to be working now!
Textures are fine and AmiQuake is crawling in game.
Would be nice if you could squeeze out more performance.

[rabidgerry]

I have only discovered this thread so I may add the things I have experienced.

Firstly I definitely registers as an FPU on my system. However I couldn't get Doom Attack running any faster than 1fps. Same for DukeNukem 3d and nBlood.

This is no criticism either btw as it's fantastic work to get a soft FPU. This is merely a description of what it was like trying a few FPS games that seem to need a little bit of FPU.

[Thomas Richter]

I afraid it wouldn't get any faster. The current speed is at 1/3 of the speed of mathieeedoubbas, the latter is already quite optimized and offers only 56 bit precision. Even if it would match the speed of doubbas, or even singbas, it would still remain at 3fps or maybe 6fps, below "playable".

SoftIEEE is not supposed to replace a full fledged FPU. If you need the speed of a FPU, get a hardware FPU. It is just supposed to provide an FPU emulation for those programs whose authors were too lazy to go through the system math libraries.