27 November 2022, 14:25 | #121 | |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,200
|
Quote:
|
|
28 November 2022, 12:26 | #122 |
Registered User
Join Date: Jan 2009
Location: Letchworth/UK
Posts: 87
|
Cool, can you point me in the direction of this thread - I can't seem to locate it with the search function. Cheers!
|
28 November 2022, 12:38 | #123 | |
HOL/FTP busy bee
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,014
|
Quote:
|
|
28 November 2022, 14:59 | #124 | |
Registered User
Join Date: Apr 2012
Location: Canada
Age: 44
Posts: 910
|
Quote:
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. |
|
29 November 2022, 08:22 | #125 | |
Alien Breeder
Join Date: Dec 2007
Location: Szigetszentmiklos / Hungary
Age: 46
Posts: 1,113
|
Quote:
|
|
04 December 2022, 05:11 | #126 |
10MARC
Join Date: Jul 2018
Location: Tucson, AZ, USA
Posts: 214
|
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. |
11 December 2022, 00:43 | #127 |
Registered User
Join Date: Mar 2007
Location: Stasin/Poland
Posts: 47
|
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.
|
11 December 2022, 08:31 | #128 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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? |
11 December 2022, 14:59 | #129 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,470
|
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. |
17 December 2022, 15:06 | #130 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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). |
31 December 2022, 13:24 | #131 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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 |
31 December 2022, 14:07 | #132 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,049
|
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.
|
31 December 2022, 14:23 | #133 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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. |
02 January 2023, 13:21 | #134 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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. |
04 January 2023, 08:07 | #135 |
Registered User
Join Date: Jan 2010
Location: turkey
Posts: 30
|
This is TF1260 100mhz sysinfo output, Before MFlops :0.09 now:0.91
|
04 January 2023, 12:17 | #136 |
Registered User
Join Date: Nov 2011
Location: Arnsberg Germany
Age: 45
Posts: 201
|
|
04 January 2023, 12:32 | #137 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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 |
04 January 2023, 12:59 | #138 |
Registered User
Join Date: Nov 2011
Location: Arnsberg Germany
Age: 45
Posts: 201
|
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. |
04 January 2023, 17:51 | #139 |
Registered User
Join Date: Nov 2018
Location: Belfast
Posts: 1,542
|
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. |
04 January 2023, 18:41 | #140 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
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. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
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 |
|
|