FMOVE.? FPx,Dn and FACOS need round to zero mode
 

The results of FMOVE.? FPx,Dn for byte, word and long integer are trash if extended precision round to nearest is used. For WinUAE 1.0 it was once forced to extended precision round to zero, but some years later somebody added the clamping bounds (which is ok) and disabled the rounding to zero. Round to zero was even somewhere recommended by Intel if I recall it correctly, but I can't find that statement anymore. I won't expect any side effects for clamping bounds.

Toni, could you please enable the rounding to zero in compemu_fpp.cpp at line ~280, ~300 and ~316 again, at least temporarily for WinUAE.7z.

Another candidate for round to zero mode is FACOS, but this time for all precisions. This is already done for the Jit, but not for the 80 bit non-Jit code. The problem with round to nearest mode is that FACOS(1) won't return exactly 0.

"Not enough information". Test examples required and real explanation. I am not going to change something without more information. ("are trash" is same as "it does not work")

Unfortunately, I don't have a working Amiga with a 68881 anymore to check the FMOVE.? FPx,Dn to see whether the 68881 is truncating or rounding the floating point number to an integer value.

The problem was that the IEEE Fix() functions needs rounding to zero and now I have forced that mode already in my Libs before the FMOVE is executed. With the default rounding mode it gets wrong results. If you think that the FMOVE is emulated correctly, then leave it as it is. The Motorola Manual only mentions rounding to the size or precision of the destination, but says nothing about the directed rounding mode.

For ACOS(1) I've written a small test that should return 0. In Jit mode the result is wrong for the first 5 loops until the Jit starts working. But maybe you know a better method to calculate ACOS(x) than using Pi/2 - ASIN(x)?

I tried simple test that counts down from 5, each time subtracting 0.1 and then doing fmove.w fpx,d0 and I can't see any differences between any emulation modes and real hardware. (Note that this method returns unexpected values, for example 3.5 rounds to 3 but 4.5 to 5. Because 0.1 is not exact value in IEEE floating point: 3FFB CCCCCCCC CCCCCCCD)

Again: actual test case/code required! There may be differences in some situations but I don't do blind changes. EDIT: and because IEEE floating point values can and will surprise were easily.

acos() is totally different thing and it makes sense to require specific rounding, until last operation.

If there is no difference to real hardware then it's better not to change it. I can live with it now since I've forced round to zero mode anyway. But your test results are indeed very interesting. As humans we are used to think in decimal digits, but the computers are rounding with dual numbers, which may have unexpected effects. The trash that I mentioned was shown in some text output for the decimal results of the HS benchmarks which obviously uses Fix() for the formatting of the printf() function. But that's "fixed" now. :)