IEEE-Libs for WinUAE or Amiga 68881/2 FPU
 

IEEE-libs for WinUAE or AMiGA 68881/2 FPU




IEEE-Libs v45.881 r14: Download


Changes in release 11:
=====================

Always set the rounding to extended precision round to zero.

Safer fallback to the original libs when no FPU is detected.
The fallback is only supported with PatchMSB or RemLib from
Thomas Rapp, but not with LoadModule, LoadResident or a ROM.

Removed the segment list pointer from the resident module to
make it possible to add these libraries to a custom ROM, but
this has not been tested and is not recommended, because if
these libraries are resident it's not possible to fallback to
the original AmigaOS libs when no FPU is found in the system.


Description:
===========

These libraries are translating all floating point function
calls directly into FPU instructions instead of doing integer
calculations as done by the original AmigaOS IEEE libraries.
In case that no FPU is detected, the original libs are loaded.


The standard installation, this is a safe setup:
===============================================

1) Copy c/PatchMSB to C:
2) Make a directory Libs:NoFPU
Copy your AmigaOS mathieeelibs to Libs:NoFPU ; as fallback
Copy the contents of libs/ to Libs:
3) Insert a line below SetPatch in your startup-sequence:

SetPatch QUIET
...
PatchMSB ; installs the same functions as in MSB-library
; remove all other patches for IEEE libraries
4) Reboot


Legal basis:
===========

My libraries and sources are freeware and freely distributable.
I don't give any warranties. You're using this software on your
own risk and you are responsible for any damage it might cause!

That are no news, that's 13 years old ... (just old wine in new bottles). :D

Name is confusing - till now I was sure they use some UAE-specific hacks :)

No, there is only the Pow(a, b)=a^b function left, which is a bit optimized for the PC FPU. Usually you would do e^(b*ln(a)), but the PCs don't have direct support for e^x and ln(x), thus I'm using 2^x and log2(x) instead, and these instructions are also directly available in the Amiga 68881/2 FPU.

All other PC specific "hacks", as once used in release 8, are functions in WinUAE for long. On the Amiga side all IEEE functions are translated into optimized 68881/2 FPU instructions, no other "hacks" are left. So you can use the MathLibsUAE also on a real Amiga with 68881/2 FPU. That was always possible, even with those r8 "hacks". ;)

Peter on AfA OS you advise to use them or I can make it pleasant :nervous

N.B. I posted the news because I had not found anything about the forun :)

Yes, you can install them under AfA_OS as shown in my readme. AmiSh:t is doing that too.

Btw, you've made a nice mathlibs logo on ikir's italian news page, Carlo. :great

Yes Peter I have already installed the libraries on AFA and they seem to be fine, for the logo or made a simple mixture. I'm not very good with graphics like my two sons now in their thirties, they started with DeluxPaint.

logo on ikir's, also Dual-Png icon :D

Hello PeterK, I am currently fixing up some (soft) float related issues on AROS m68k, and would be interested in integrating something similar to your libraries in our IEEE libs.

Would you be interested in helping or allow the use of your code for such a thing?

Hello Kalamatee,

how can I help you with my simple code? Most of the functions are just mapped to the FPU instructions. Only a few like Pow(), Floor() and Ceil() are based on my personal coding attempts. If you find anything useful for your IEEE libs, feel free to pick out whatever you need. In case that you don't understand some parts of my code or have doubt that it could work correctly, we could discuss the details per email if you like, since this is more a news thread here.

@AMIGASYSTEM
Thanks a lot for the nice icon. Ok, 30000 bytes of stack seems to be a little overkill, but that's on the safe side, for sure. I just don't know if the next release takes another 13 years before I can add your icon to the package. :)

I did not insert the stack 30000, the system automatically generated it after the conversion of the two images png :confused

Shock! :shocked
I just noticed that accidentally I made a stupid little mistake in my IEEE DP compare function. I don't know wtf has driven me to replace a TST.L D1 instruction with OR.L D3,D1 ???

But then I checked the compare function for possible wrong results caused by this mistake, and I'm very glad now to realize that this "bug" seems to have no negative effects. It's still all ok. :)

Update: No, this small mistake is not even a bug as supposed, in fact it's a tiny optimization of the code. Some special cases are done a bit faster now. :crazy