Thanks for the responses. It makes sense that, at the very least, we'll need some portable conversion facilities between the 64-bit and 80-bit representations.
I'm not in favor of losing portability either, but I'm relatively pragmatic, so if a loss of portability saves orders of magnitude of effort or performance, or worse yet is the difference between something happening and not happening, then I'm willing to live with it. Steve On Tue, Sep 3, 2013 at 2:35 PM, Andreas Sandberg <[email protected]>wrote: > > 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<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<https://github.com/andysan/libfputils> >>>> >>>> >>>> ______________________________**_________________ >>>> gem5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>>> >>> ______________________________**_________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>> >>> ______________________________**_________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >> >> > ______________________________**_________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
