1. We probably don't need 80-bit precision when doing x87-arithmetics,
but we need it for other reasons: 1) to transfer state to and from KVM.
2) the x87 is expected to support loading and storing of 80-bit floats.
I've seen programs using this feature to convert between 80-bit floats
and 64-bit floats.
2. The problem here is that the standard libraries assume that the x87
is present, libc contains fair amount of hand-coded x87 assembly. I had
a hard time getting things to work because of this. I'm pretty sure that
I've seen GCC to generating x87 code for operations like modulo even
though it is configured to generate SSE code, but I can't remember the
details at the moment.
3. I have actually been running gem5 on ARM, but I must admit that it
seems unlikely that someone is would simulate x86 on ARM. I don't really
like the idea of losing portability, besides we should continue to
support clang since a lot of people are using it. I would be OK using
gcc extensions in the KVM module, but we need to support 80-bit loads &
stores in the ISA as well. We might want to do FP conversion in software
anyway to correctly handle overflows etc. Anyway, it wouldn't be hard
supporting FP conversion in software, there is both the library that
Nathan pointed to and my code, so it's just the small matter of doing it.
//Andreas
On 09/03/2013 10:18 PM, Steve Reinhardt wrote:
Thanks for the reply, Andreas. I'm glad to hear things are mostly working.
Like Nate, I'm a little confused about the x87/FP situation. What are the
issues there? It seems like there are several distinct but related things
that (could be) involved:
1. How much do we care about 80-bit precision for x87? I can see where
being able to get the same precise answer whether we're running in KVM or
not would be very desirable, but unless things actually break without it,
I'd stop short of saying it's an absolute requirement (as long as we
advertise that limitation, of course).
2. How much do we use x87 anyway? 64-bit apps can assume SSE, so x87 isn't
necessary for FP, and my understanding was that we didn't support much of
x87 in our x86 ISA implementation in the first place.
3. How much do we care about portability, both across compilers and across
architectures? Obviously KVM support depends on running on an x86 machine.
If we have that same restriction for full 80-bit x87 support (i.e., only
on x86 hosts), I don't see a big problem with that. I doubt x86 gem5 ever
gets run on any other host. Assuming that we're running on an x86 machine,
it makes sense to use the built-in x87 hardware to get 80-bit support and
not emulate it in software. If gcc extensions are the only way to do that,
then I'm willing to make that compromise as well. If (for example) clang
doesn't provide access to 80-bit FP on x86 hosts, I'm willing to write that
up as a limitation of clang and not something we need to solve. Of course,
that's easy for me, since I don't use clang...
Thoughts?
Steve
On Tue, Sep 3, 2013 at 10:47 AM, nathan binkert <[email protected]> wrote:
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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
