8:12 a.m.
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
--
http://www.wiesinger.com/
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
--
http://www.wiesinger.com/
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.
8:09 a.m.
New subject: [Qemu-devel] Re: QEMU regression problems - Update FPU
Any comments on this problem?
Thnx.
Ciao,
Gerhard
--
http://www.wiesinger.com/
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
--
http://www.wiesinger.com/
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
--
http://www.wiesinger.com/
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.
9:16 a.m.
New subject: [Qemu-devel] Re: QEMU regression problems - Update FPU
On 18 February 2011 07:12, Gerhard Wiesinger <lists(a)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
10:45 a.m.
New subject: [Qemu-devel] Re: QEMU regression problems - Update FPU
On Wed, Feb 23, 2011 at 9:16 AM, Peter Maydell <peter.maydell(a)linaro.org> wrote:
On 18 February 2011 07:12, Gerhard Wiesinger
<lists(a)wiesinger.com> wrote:
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
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. 
8:04 p.m.
New subject: [Qemu-devel] Re: QEMU regression problems - Update FPU
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(a)linaro.org> 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).
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.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien(a)aurel32.net http://www.aurel32.net
On 18 February 2011 07:12, Gerhard Wiesinger
<lists(a)wiesinger.com> wrote:
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.
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. 
12:10 p.m.
New subject: QEMU regression problems - Update FPU
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
12:21 p.m.
New subject: QEMU regression problems - Update FPU
On Thu, Feb 24, 2011 at 12:10 PM, Paolo Bonzini <pbonzini(a)redhat.com> wrote:
On 02/23/2011 08:04 PM, Aurelien Jarno wrote:
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
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.
8:03 a.m.
New subject: [Qemu-devel] Re: QEMU regression problems - Update FPU
On Wed, 23 Feb 2011, Peter Maydell wrote:
On 18 February 2011 07:12, Gerhard Wiesinger
<lists(a)wiesinger.com> wrote:
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
--
http://www.wiesinger.com/
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.
8:31 a.m.
New subject: [Qemu-devel] Re: QEMU regression problems - Update FPU
On Thu, Feb 24, 2011 at 08:03:02AM +0100, Gerhard Wiesinger wrote:
On Wed, 23 Feb 2011, Peter Maydell wrote:
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.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien(a)aurel32.net http://www.aurel32.net
On 18 February 2011 07:12, Gerhard Wiesinger
<lists(a)wiesinger.com> wrote:
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.
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.
3253
days inactive
3259
days old
8 comments
5 participants
participants (5)
-
Aurelien Jarno -
Gerhard Wiesinger -
Laurent Desnogues -
Paolo Bonzini -
Peter Maydell