English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 22 June 2018, 23:07   #1
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,903
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.
PeterK is offline  
Old 23 June 2018, 10:53   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,783
"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")

Last edited by Toni Wilen; 23 June 2018 at 12:51.
Toni Wilen is online now  
Old 23 June 2018, 16:56   #3
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,903
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)?
Attached Files
File Type: lha TestAcos1.lha (904 Bytes, 42 views)

Last edited by PeterK; 23 June 2018 at 17:03.
PeterK is offline  
Old 24 June 2018, 09:35   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,783
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.

Last edited by Toni Wilen; 24 June 2018 at 10:07.
Toni Wilen is online now  
Old 24 June 2018, 13:15   #5
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,903
Quote:
Originally Posted by Toni Wilen View Post
... 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) ...
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.
PeterK is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Fightin Spirit (ECS) issue STORY MODE at final round with Jenshi jhonny82 support.Games 50 29 July 2018 21:32
EAB/Lemon Super League 2017: Round 14 - Mystery Round Nominations Graham Humphrey EAB's competition 4 12 October 2017 08:37
It seem the JIT direct mode is not work in fs-uae. direct mode is important bernd roesch support.FS-UAE 27 20 September 2015 21:44
EAB/Lemon Super League 2008: Round 8 - What Lotus III Game Mode? Graham Humphrey EAB's competition 41 20 July 2008 01:49
'Warp Mode' broken in 'windowed mode' NoX1911 support.WinUAE 3 26 May 2007 01:05

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.08934 seconds with 16 queries