05 December 2022, 13:35 | #1 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
fpsp.resource released
fpsp.resource v40.2/60.2 disk load code ©SpeedGeek 2023
M68060 Software Package Copyright © 1993, 1994 Motorola Inc. All rights reserved. INTRODUCTION: This is just my own implementation of the mysterious fpsp.resource introduced with OS3.9. The reason for this late implementation was the lack of documentation for the mystery feature and I always seem to have have more projects to do than I have actually have time for. The fpsp.resource was conceptually a pretty good idea, but IMO hindered by poor implementation. This made it even worse than the NSDpatch feature of OS3.9. At least NSD had documentation and a support "Patch" for the legacy devices which were NEVER EVER going to be updated for NSD support! So, now you can have fpsp.resource support for the legacy 68040 and 68060 libraries which are NEVER EVER going to be updated for the mystery feature! REQUIREMENTS: - 68040 or 68060 CPU with FPU - MathIEEE libraries which can use the fpsp.resource or - FastIEEE patch from Aminet (for OS3.1 math libraries) DISCLAIMER: Use at your risk. No warranty expressed or implied, etc. NOTES: The LoadFPSP tool checks for the 040/060 FPU and will report an error if not found. This is a disk load implementation of an AmigaOS "resource". Hence, it is not intended to be ROM resident or survive a reboot. Also, the installation tool does NOT support removing the fpsp.resource from the system because this would crash any applications which have dependencies. The fpsp.resource should be loaded into the FASTEST (preferably 32 bit) RAM in the system. Finally, it must be loaded before any of the applications which can use it. At present, the AmigaOS MathIEEE libraries are the ONLY supported* applications using the fpsp.resource. The LoadFPSP tool does not report revision information. *MuRedox was excluded because it has a dependancy on MMUlib. SPEED COMPARISONS: The fpsp.resource will not make the AmigaOS MathIEEE libraries as fast as the HSmathlibs. But it will certainly make them faster and more multitasking friendly than the exception trap handlers of the 68040 and 68060 libraries. UPDATE: The 040 version is now included in the archive. This is due to the so called 060 emulation of FINT and FINTRZ only emulating the "Not Normal" numbers and not the actual instructions. The 040 version emulates the instructions and is needed to avoid the exception trap for the case of "Normal" operands. The trade off for 040 users is this version is larger and may be a little slower on the transcendental functions. For 060 users the instructions execute in hardware so the 060 version should be faster in all cases. HISTORY: - v40-60 First release - v40.1-60.1 Added code to Dyadic function to copy source tag to destination tag. This should fix a possible bug with this function. Updated notes regarding the LoadFPSP tool limitations. - v40.2-60.2 The Dyadic function now copies the destination operand from FP1 and tags it. This means it's entirely up to the user to place a valid destination number in FP1. The bonus feature was eliminated to minimize the code addition. Last edited by SpeedGeek; 15 October 2023 at 03:36. |
05 December 2022, 16:06 | #2 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Look, I really write documentation, so please don't call something "mysterious" in case you aren't able to locate documentation. As also said on a1k, you find the documentation for the fpsp.resource in the MuManual archive. Besides, you could simply ask, there is nothing to hide.
The implementation is exactly the one from Motorola, thus there is no "separate implementation" of the resource. It's using the same code base, obviously. This is, of course, intentional. One chance less to create bugs, that's why. |
05 December 2022, 17:41 | #3 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
Quote:
Was the documentation released on the Haage&Partner.de website? No. Was the documentation released with the OS3.9 FAQ? No. Was the documentation released with the FastIEEE patch on Aminet? No. Now, should I look for the documentation 15-20 years later in the MuManual archive on Aminet? Again, No. But I was looking for some MMUlib documentation (Because I had your MMUlib running in 8K page mode for experimental purposes) and found the fpsp.resource documentation there quite by accident. |
|
05 December 2022, 18:13 | #4 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Yes, you should. It's all part of the same project. I suggest simply to ask in case you need something, it's a lot easier for anyone, and you don't need to guess how the interface looks like. I'm all for open documentation.
|
05 December 2022, 19:38 | #5 | |
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,546
|
Quote:
Mysterious is right. I gather it has something to do with the FPU instructions that Motorola whipped out of the 040 and 060. As a coder, why would I need to care about this fpsp.resource? |
|
05 December 2022, 19:57 | #6 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
For all the reasons explained in post #1 and because the updated 68040.library 44.2 (released with OS3.9) did not support the fpsp.resource.
That really depends on what you are coding and if your code needs IEEE floating point support on a 68040 or 68060 with FPU system. |
05 December 2022, 22:01 | #7 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Actually, you did not provide any?
Quote:
In fact, nowadays the CBM-provided 68040.library is less compatible than mine, but that's >20 development years later whereas the original CBM code is at a stand-still. Nobody cared about it anymore in the past years. Quote:
The resource was actually not an attempt to provide a source or interface for transcental mathematical functions. The source for that would be the system math libraries. That is the Os interface. If you would want to use the FPU, just use the FPU instructions and the CPU libraries would provide their emulation magic. The interface would look completely different it would be a front-end exposed to the average user as math library. The only reason for the resource was to provide an entry point for those system services that would benefit from a more direct call path into the emulation core, namely exactly the math libraries and MuRedox. That was a much better, and straight-forward approach to supply the missing math functions for the math.libraries. Do not re-invent the wheel if you do not have to. The mot math functions are in good shape and have been tested. Everything you cook up yourself may require additional time to become stable. So the average user would never be in contact with the resource as such, only indirectly through the math libraries or MuRedox. |
||
06 December 2022, 10:01 | #8 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
Yes, I did explain it and the comparison made was quite accurate. NSD was functional "Out of the Box" with OS3.9 but the fpsp.resource was not. You do not have to agree with my opinion and I do not have to agree with yours. However, pointless bickering for the purpose of derailing this thread will not be allowed.
Quote:
Last edited by SpeedGeek; 19 December 2022 at 18:30. |
|
06 December 2022, 10:30 | #9 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
The necessary modifications within the CPU libraries to provide the resource are actually quite minimal. The fpsp.resource interface is exactly made to make this very easy for the CPU libraries as it is more or less a direct call to the function dispatcher of the mot fpsp code. Last edited by SpeedGeek; 19 December 2022 at 18:30. |
|
02 July 2023, 03:55 | #10 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
|
26 July 2023, 17:53 | #11 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
** NEWS UPDATE **
The 040 version is now included in the archive. This is due to the so called 060 emulation of FINT and FINTRZ only emulating the "Not Normal" numbers and not the actual instructions. The 040 version emulates the instructions and is needed to avoid the exception trap for the case of "Normal" operands. The trade off for 040 users is this version is larger and may be a little slower on the transcendental functions. For 060 users the instructions execute in hardware so the 060 version should be faster in all cases. Last edited by SpeedGeek; 26 July 2023 at 20:25. |
11 October 2023, 16:11 | #12 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
** 2ND NEWS UPDATE **
v40.1-60.1 released! - Added code to Dyadic function to copy source tag to destination tag. This should fix a possible bug with this function. Updated notes regarding the LoadFPSP tool limitations. |
15 October 2023, 03:37 | #13 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 839
|
** 3RD NEWS UPDATE **
v40.2-60.2 released! - The Dyadic function now copies the destination operand from FP1 and tags it. This means it's entirely up to the user to place a valid destination number in FP1. The bonus feature was eliminated to minimize the code addition. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Resource | kamelito | support.Apps | 0 | 22 April 2021 15:50 |
Resource | jarre | request.Apps | 3 | 22 September 2018 16:08 |
ReSource 6.06 | yoki | request.Apps | 6 | 04 November 2009 17:29 |
ReSource | drago | request.Apps | 2 | 08 July 2008 00:30 |
Resource | Amigaboy | request.Apps | 2 | 16 August 2001 05:15 |
|
|