Hello,
Good news: Seems to be that 2 of 3 issues have been fixed with QEMU: :-) Summary of previous discussion: http://www.mail-archive.com/qemu-devel@nongnu.org/msg29465.html
2.) Realtime clock: fixed 3.) Base Memory: fixed
Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general?
QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct)
Code: fninit ; init FPU fld1 ; Pushes 1 on the stack, ST0=1 fadd st(0), st(0) ; ST0=ST0+ST0=2 fld1 ; Pushes 1 on the stack, ST0=1, ST1=2 fadd st(1), st(0) ; ST1=ST1+ST0=3, ST0=1 fdivrp st(1), st(0) ; ST0=ST0/ST1=1/3 f2xm1 ; ST0=2^ST0-1 (ST0 must be in range -1 to +1)=2^(1/3)-1=0.25992104989487316476721060727823 fldpi ; pushes pi on the stack; ST0=pi, ST1=0.25992104989487316476721060727823 fyl2x ; ST0=ST1*log2(ST0)=0.25992104989487316476721060727823*1.651496129472318798043279295108=0.42925860786976448643152122341584 fwait ; wait
*.ASM/*.COM file is also present for debugging.
Thnx.
Ciao, Gerhard
On Mon, 12 Apr 2010, Gerhard Wiesinger wrote:
Hello,
Checkit reports some problems under DOS: 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. Seems to be a problem of the instruction set. 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the KVM problem, see my previous post). Seems to be that real-time clock is not working correct. 3.) There is also a problem with the reported base memory under QEMM386 (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB. Therefore base memory test fails. I guess that reporting memory CMOS tables/interrupt functions are not implemented correctly.
Details are listed below.
All issues are NOT present under VMWare Server 2.0 and with real hardware.
QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II Quad Core, x86_64-softmmu.
Any comments?
Thnx.
Ciao, Gerhard
Details: 1.) NPU Trigonometric Functions.................................FAILED *** Step 1, Expected 0.42926, received 0.42926
Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h). Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h). Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h).
2.) Compare Current Time............................................Passed DOS: 16:24:39.89 Real-Time Clock: 16:24:39.00 (.89 apart)
Compare Current Date............................................Passed DOS: 04/11/2010 Real-Time Clock: 04/11/2010.
Real-Time Clock Alarm...........................................FAILED ***
Compare Elapsed Time............................................Passed DOS: 11.97 Seconds Real-Time Clock: 12.00 Seconds (.03 apart)
3.) Known Memory: Base 646K From 0K to 646K (0000000h to 00A17FFh) Base Memory.................................................FAILED *** ERROR at Address 0A0000h, Bits FEDCBA9876543210 ERROR at Address 0A0004h, Bits FEDCBA9876543210 ERROR at Address 0A0006h, Bits FEDCBA9876543210 ERROR at Address 0A0008h, Bits FEDCBA9876543210 ERROR at Address 0A000Ah, Bits FEDCBA9876543210 ERROR at Address 0A000Ch, Bits FEDCBA9876543210 ERROR at Address 0A000Eh, Bits FEDCBA9876543210 ERROR at Address 0A0010h, Bits FEDCBA9876543210 ERROR at Address 0A0012h, Bits FEDCBA9876543210 ERROR at Address 0A0014h, Bits FEDCBA9876543210 ERROR at Address 0A0016h, Bits FEDCBA9876543210 ERROR at Address 0A0018h, Bits FEDCBA9876543210 ERROR at Address 0A001Ah, Bits FEDCBA9876543210 ERROR at Address 0A001Ch, Bits FEDCBA9876543210 ERROR at Address 0A001Eh, Bits FEDCBA9876543210 ERROR at Address 0A0020h, Bits FEDCBA9876543210 ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE.
Any comments on this problem?
Thnx.
Ciao, Gerhard
On Fri, 18 Feb 2011, Gerhard Wiesinger wrote:
Hello,
Good news: Seems to be that 2 of 3 issues have been fixed with QEMU: :-) Summary of previous discussion: http://www.mail-archive.com/qemu-devel@nongnu.org/msg29465.html
2.) Realtime clock: fixed 3.) Base Memory: fixed
Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general?
QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct)
Code: fninit ; init FPU fld1 ; Pushes 1 on the stack, ST0=1 fadd st(0), st(0) ; ST0=ST0+ST0=2 fld1 ; Pushes 1 on the stack, ST0=1, ST1=2 fadd st(1), st(0) ; ST1=ST1+ST0=3, ST0=1 fdivrp st(1), st(0) ; ST0=ST0/ST1=1/3 f2xm1 ; ST0=2^ST0-1 (ST0 must be in range -1 to +1)=2^(1/3)-1=0.25992104989487316476721060727823 fldpi ; pushes pi on the stack; ST0=pi, ST1=0.25992104989487316476721060727823 fyl2x ; ST0=ST1*log2(ST0)=0.25992104989487316476721060727823*1.651496129472318798043279295108=0.42925860786976448643152122341584 fwait ; wait
*.ASM/*.COM file is also present for debugging.
Thnx.
Ciao, Gerhard
On Mon, 12 Apr 2010, Gerhard Wiesinger wrote:
Hello,
Checkit reports some problems under DOS: 1.) NPU functions are not correct: NPU Trigonometric Functions: FAILED. Seems to be a problem of the instruction set. 2.) Real-Time Clock Alarm: FAILED (This might be also the reason for the KVM problem, see my previous post). Seems to be that real-time clock is not working correct. 3.) There is also a problem with the reported base memory under QEMM386 (HIMEM.SYS and EMM386.EXE is correct here). It is 646kB instead of 640kB. Therefore base memory test fails. I guess that reporting memory CMOS tables/interrupt functions are not implemented correctly.
Details are listed below.
All issues are NOT present under VMWare Server 2.0 and with real hardware.
QEMU: 0.12.3 under Fedora 11, 2.6.30.10-105.2.23.fc11.x86 on AMD Phenom II Quad Core, x86_64-softmmu.
Any comments?
Thnx.
Ciao, Gerhard
Details: 1.) NPU Trigonometric Functions.................................FAILED *** Step 1, Expected 0.42926, received 0.42926
Double 'Npu_oldans1' = 0.429259 (3FDB78F91894EFA5h). Double 'Npu_oldans2' = 0.628319 (3FE41B2F769CF0E0h). Double 'Npu_result ' = 0.429259 (3FDB78F91894EFA6h).
2.) Compare Current Time............................................Passed DOS: 16:24:39.89 Real-Time Clock: 16:24:39.00 (.89 apart)
Compare Current Date............................................Passed DOS: 04/11/2010 Real-Time Clock: 04/11/2010.
Real-Time Clock Alarm...........................................FAILED ***
Compare Elapsed Time............................................Passed DOS: 11.97 Seconds Real-Time Clock: 12.00 Seconds (.03 apart)
3.) Known Memory: Base 646K From 0K to 646K (0000000h to 00A17FFh) Base Memory.................................................FAILED *** ERROR at Address 0A0000h, Bits FEDCBA9876543210 ERROR at Address 0A0004h, Bits FEDCBA9876543210 ERROR at Address 0A0006h, Bits FEDCBA9876543210 ERROR at Address 0A0008h, Bits FEDCBA9876543210 ERROR at Address 0A000Ah, Bits FEDCBA9876543210 ERROR at Address 0A000Ch, Bits FEDCBA9876543210 ERROR at Address 0A000Eh, Bits FEDCBA9876543210 ERROR at Address 0A0010h, Bits FEDCBA9876543210 ERROR at Address 0A0012h, Bits FEDCBA9876543210 ERROR at Address 0A0014h, Bits FEDCBA9876543210 ERROR at Address 0A0016h, Bits FEDCBA9876543210 ERROR at Address 0A0018h, Bits FEDCBA9876543210 ERROR at Address 0A001Ah, Bits FEDCBA9876543210 ERROR at Address 0A001Ch, Bits FEDCBA9876543210 ERROR at Address 0A001Eh, Bits FEDCBA9876543210 ERROR at Address 0A0020h, Bits FEDCBA9876543210 ADDITIONAL MEMORY ERRORS WERE NOT LISTED DUE TO LACK OF SPACE.
On 18 February 2011 07:12, Gerhard Wiesinger lists@wiesinger.com wrote:
Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general?
QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct)
This is an error when running QEMU in TCG mode, right? At the moment x86 is the odd-one-out in that it doesn't use CONFIG_SOFTFLOAT for its FPU emulation, so somebody has made an explicit choice of preferring speed over accuracy, and I am unsurprised that there are rounding errors as a result.
-- PMM
On Wed, Feb 23, 2011 at 9:16 AM, Peter Maydell peter.maydell@linaro.org wrote:
On 18 February 2011 07:12, Gerhard Wiesinger lists@wiesinger.com wrote:
Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general?
QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct)
This is an error when running QEMU in TCG mode, right? At the moment x86 is the odd-one-out in that it doesn't use CONFIG_SOFTFLOAT for its FPU emulation, so somebody has made an explicit choice of preferring speed over accuracy, and I am unsurprised that there are rounding errors as a result.
Even if you were using SoftFloat, you'd probably still get wrong results given that this test seems to test trigonometric instructions which aren't implemented in SoftFloat, but are relying on libm.
Laurent
On Wed, Feb 23, 2011 at 10:45:25AM +0100, Laurent Desnogues wrote:
On Wed, Feb 23, 2011 at 9:16 AM, Peter Maydell peter.maydell@linaro.org wrote:
On 18 February 2011 07:12, Gerhard Wiesinger lists@wiesinger.com wrote:
Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general?
QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct)
This is an error when running QEMU in TCG mode, right? At the moment x86 is the odd-one-out in that it doesn't use CONFIG_SOFTFLOAT for its FPU emulation, so somebody has made an explicit choice of preferring speed over accuracy, and I am unsurprised that there are rounding errors as a result.
Even if you were using SoftFloat, you'd probably still get wrong results given that this test seems to test trigonometric instructions which aren't implemented in SoftFloat, but are relying on libm.
Actually that's the reason why i386 doesn't use softfloat, as all the trigonometric use libm, and the bridge between softfloat and libm is not working correctly (plenty of type abuse).
The solution is probably to implement them in softfloat, but it's not something trivial. exp2 and log2 are already in softfloat for float32 type, the same way could be use for other trigonometric functions.
On Wed, 23 Feb 2011, Peter Maydell wrote:
On 18 February 2011 07:12, Gerhard Wiesinger lists@wiesinger.com wrote:
Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general?
QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct)
This is an error when running QEMU in TCG mode, right? At the moment x86 is the odd-one-out in that it doesn't use CONFIG_SOFTFLOAT for its FPU emulation, so somebody has made an explicit choice of preferring speed over accuracy, and I am unsurprised that there are rounding errors as a result.
Yes, QEMU not KVM. Regarding mode: I guess tcg mode because softfloat doesn't compile on x64 (AMD) (How to find out which mode is used, what other modes exist?).
But can't we use the float64 type and use the normal i386 (or higher) instructions and therefore we get: 1.) less accurate but correct emulated results 2.) Have the full speed
Second solution would be to use a more accurate type like now but to use rounding to e.g. float64 after each FPU operation.
Maybe we can also use a define or config switch for accuracy vs. speed.
What do you think?
Ciao, Gerhard
On Thu, Feb 24, 2011 at 08:03:02AM +0100, Gerhard Wiesinger wrote:
On Wed, 23 Feb 2011, Peter Maydell wrote:
On 18 February 2011 07:12, Gerhard Wiesinger lists@wiesinger.com wrote:
Issue 1.) with FPU still present I tracked down the problematic code and it is a rounding error from double precision to 64bit floats: Any ideas how to fix such an issue in general?
QEMU result in ST0: 0.42925860786976457 (wrong emulated) KVM result in ST0: 0.42925860786975449 (correct)
This is an error when running QEMU in TCG mode, right? At the moment x86 is the odd-one-out in that it doesn't use CONFIG_SOFTFLOAT for its FPU emulation, so somebody has made an explicit choice of preferring speed over accuracy, and I am unsurprised that there are rounding errors as a result.
Yes, QEMU not KVM. Regarding mode: I guess tcg mode because softfloat doesn't compile on x64 (AMD) (How to find out which mode is used, what other modes exist?).
But can't we use the float64 type and use the normal i386 (or higher) instructions and therefore we get: 1.) less accurate but correct emulated results 2.) Have the full speed
Second solution would be to use a more accurate type like now but to use rounding to e.g. float64 after each FPU operation.
Maybe we can also use a define or config switch for accuracy vs. speed.
This is not something possible, x86 uses a 80-bit FPU, and floats are rounded to 64-bit when moved to memory. That's actually probably why you see a difference between TCG or native/KVM.
On 02/23/2011 08:04 PM, Aurelien Jarno wrote:
Actually that's the reason why i386 doesn't use softfloat, as all the trigonometric use libm, and the bridge between softfloat and libm is not working correctly (plenty of type abuse).
Besides, I doubt softfloat would want bug-compatible trig function implementations. fsincos for example is a far cry from the precision of the libm function.
Paolo
On Thu, Feb 24, 2011 at 12:10 PM, Paolo Bonzini pbonzini@redhat.com wrote:
On 02/23/2011 08:04 PM, Aurelien Jarno wrote:
Actually that's the reason why i386 doesn't use softfloat, as all the trigonometric use libm, and the bridge between softfloat and libm is not working correctly (plenty of type abuse).
Besides, I doubt softfloat would want bug-compatible trig function implementations. fsincos for example is a far cry from the precision of the libm function.
I agree, these functions certainly don't belong to SoftFloat. They should be implemented in target-i386/op_helper.c. But bit accuracy might be difficult to achieve, unless Intel/AMD properly documented how they compute all these functions.
Laurent
-
Aurelien Jarno -
Gerhard Wiesinger -
Laurent Desnogues -
Paolo Bonzini -
Peter Maydell