Quote:
Originally Posted by hexaae
...if I replace OS3.9 LIBS:math#?.library with Peter Keunecke's versions for WinUAE, it solves 80bit Host FPU gfx glitches... From OS32 fresh install HD setup: not reproducible (!). Could different mathlibs affect WinUAE 64/80bit Host calcs?
|
Yes, the mathlibs are setting the precision and the rounding mode globally for a task when it opens these libs. And there are indeed differences between all available versions of mathlibs. Most of these libs set the precision to 32 bit Float for the mathieeesingXXX.libs and to 64 bit Double for the mathieeedoubXXX.libs, older libs may use "round to zero", OS 3.2 uses "round to nearest even" now, I guess. My libs always set the precision to 80 bit Extended or LongDouble, and always to "round to nearest", only the Fix() function uses "round to zero", but restores "round to nearest" afterwards.
Usually, demos are using inline FPU instructions instead of calling mathlibs functions for their main routines. But sometimes
these tasks are calling the mathlibs for some other reasons, too. This can happen when they've used a compiler for the GUI or configuration page or whatever or it also could be another library that is used by the demo task, which opens the mathlibs. Then it also depends on which mathlibs are opened last; i.e. the mathieeesingXXX.libs could reduce the precision to 32 bit Float and round to zero in the worst case for all the following FPU instructions of the demo task.
If you are starting the demo from a shell then even the shell or console or another instruction that was executed before could have opened the mathlibs already (maybe ?) and the demo will be the same task later with the same FPU configuration.
Check your demo files with Multiview and the exe.datatype or with a hex viewer for the mathieee libs.