What about multi word arithmetic with additional exponent field? Three
doubles are more then enough to represent 80b and to have enough precision
to enable exact rounding to 64b mantissa in case of division and square
root, and to take care of flags which are probably trickiest part to get
absolutely right or at least almost always right. There are three cases for
emulation:
1) native x87, no emulation needed
2) doubles, with true fused multiply add instruction - a bit slower but not
that much, code is somewhat subtle, some would say dirty
3) doubles, no fused madd (or it has two roundings) - few times slower then
2nd case and somewhat messier
2nd and 3rd case can be done with double word or triple word, 2nd case with
double word is especially fast with all benefits of inlining. Additional
exponent would not be used that much, except in rare cases so total impact
on speed should not be large.
libm instructions should not be problem for two reasons: there are not same
on Intel and AMD CPUs (at least, this was case about 10 year ago, but
results were consistent on several generations) and both have error of few
ulps so call to libm is actually more accurate, and they are not used much
in these days as call to libm is both faster and more accurate.
----- Original Message -----
From: "nathan binkert" <[email protected]>
To: "gem5 Developer List" <[email protected]>
Sent: 3. септембар 2013 19:47
Subject: Re: [gem5-dev] x86 kvm status?
I'm curious, does this conversion mean that you lose precision? I'm
not sure I care, but it would be good to be sure that people know that
we don't do x87 correctly if so.
Did anyone ever consider using softfloat?
http://www.jhauser.us/arithmetic/SoftFloat.html
Nate
On Tue, Sep 3, 2013 at 10:32 AM, Andreas Sandberg
<[email protected]> wrote:
On 08/29/2013 11:49 PM, Steve Reinhardt wrote:
What is the status of using kvm for x86 simulation? I know Andreas S.
has
committed a bunch of patches, but I see that x86 is still not listed
in the is_isa_kvm_compatible()
function in the SConstruct. Does that mean there are still known
issues?
Currently, the main issue that has kept me from submitting the patches is
the x87 interface. gem5 uses 64-bit doubles internally to represent
floating
point numbers, while the hardware uses 80-bits. The problem boils down to
converting between the two. My current version is using a gcc-specific
80-bit float type, which is something I need to fix before submitting. I
have the code[1] to do the conversion in software, but I haven't had time
to
integrate it into gem5 yet.
Apart from the FP issues, things should work fine. I've seen less than
10%
slowdown compared to native when executing SPEC and features like CPU
switching and checkpointing work.
Unfortunately, I don't expect to get time to prepare the code for review
until mid/late September.
//Andreas
[1] https://github.com/andysan/libfputils
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
