fpsp.resource released

[SpeedGeek]

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.

[Thomas Richter]

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.

[SpeedGeek]

Originally Posted by Thomas Richter

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.

Was the documentation released with the NDK3.9? No.
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.

[Thomas Richter]

Originally Posted by SpeedGeek

Now, should I look for the documentation 15-20 years later in the MuManual archive on Aminet?

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.

[Bruce Abbott]

Originally Posted by SpeedGeek

The fpsp.resource was conceptually a pretty good idea, but IMO hindered by miserably poor implementation.

In what way was the implementation 'miserably poor'?

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?

[SpeedGeek]

Originally Posted by Bruce Abbott

In what way was the implementation 'miserably poor'?

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.

Originally Posted by Bruce Abbott

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?

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.

[Thomas Richter]

Originally Posted by SpeedGeek

For all the reasons explained in post #1

Actually, you did not provide any?

Originally Posted by SpeedGeek

and because the updated 68040.library 44.2 (released with OS3.9) did not support the fpsp.resource.

No, it didn't. H&P back then decided not to ship the generic Mu-based libraries as they were afraid of compatibility issues created by them, and it was also pretty early into my project. I didn't want to argue... What you find in 3.9 is just a re-cap of the original CBM 68040.library (pretty much targetted at the CBM-built 68040 cards and not useful for third party vendors) with the fpsp code upgraded to the latest mot source. That's it.



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.

Originally Posted by SpeedGeek

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.

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.

[SpeedGeek]

Originally Posted by Thomas Richter

Actually, you did not provide any?

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.

Originally Posted by Thomas Richter

No, it didn't. H&P back then decided not to ship the generic Mu-based libraries as they were afraid of compatibility issues created by them, and it was also pretty early into my project. I didn't want to argue... What you find in 3.9 is just a re-cap of the original CBM 68040.library (pretty much targetted at the CBM-built 68040 cards and not useful for third party vendors) with the fpsp code upgraded to the latest mot source. That's it.

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.

That's exactly why the fpsp.resource should have been developed separately from the CPU libraries. The compatibility issue was always a problem and there was no easy way patch the CPU libraries for fpsp.resource support.

[Thomas Richter]

Originally Posted by SpeedGeek

That's exactly why the fpsp.resource should have been developed separately from the CPU libraries. The compatibility issue was always a problem and there was no easy way patch the CPU libraries for fpsp.resource support.

Huh? Look, nobody stops you (and you actually did that) to provide an independent resource if you'd want to. But the point here was that the libraries contained the code for the transcendental functions anyhow, so making the routines available in cpu libraries in the form of a resource avoids code duplications and creates only minimal overhead.

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.

[SpeedGeek]

Originally Posted by Bruce Abbott

In what way was the implementation 'miserably poor'?

I removed the word "miserably" from post #1 (But the documentation in the archive won't be updated unless there is a reason to update the release version).

[SpeedGeek]

** 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.

[SpeedGeek]

** 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.

[SpeedGeek]

** 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.