Re: [Qemu-devel] [PATCH] target-i386: implement FPREM and FPREM1 using softfloat only

[Peter Maydell]

On 29 June 2012 02:50, Catalin Patulea <address@hidden> wrote:
> On Thu, Jun 28, 2012 at 2:25 PM, Peter Maydell <address@hidden> wrote:
>> No new code should be using the uint64 &c types (which are
>> "at least NN bits wide") -- uint64_t or uint_fast64_t please.
> Ok, changed some {int -> flag} and {uint64 -> uint64_t}.
>
> There are some int32s left, but these seem to be tied to
> extractFloatx80Exp's return type, which is int32 despite the
> underlying floatx80.high being an int16_t. Is this intentional? Fixing
> this would imply many other changes so I would punt on this for now.

We haven't yet managed to do the full conversion away from the
softfloat custom int32 types to the POSIX ones...

>> > +    // handle unsupported extended double-precision floating encodings
>> > +    if (floatx80_is_unsupported(a) || floatx80_is_unsupported(b))
>> > +    {
>> > +        float_raise(float_flag_invalid, status);
>> > +        *r = floatx80_default_nan;
>> > +        return -1;
>> > +    }
>>
>> So are we mishandling unsupported 80bit floats in other operations
>> (eg addition), or do those functions just opencode things?
> Yes, I believe addition (and likely others) mishandles these. I put
> together a small C program that clears FP exceptions, adds two long
> doubles, and checks FP exceptions. (I do these things using glibc
> functions like feclearexcept - I don't think this is any different
> from doing it at the machine level, but just to be sure - are you
> aware of any issues with this approach?)

Well, you're relying on the compiler and libc not to insert
any other FPU operations into your code sequences, but it's
probably OK. For ARM testing I use
https://wiki.linaro.org/PeterMaydell/Risu , but getting that
to properly support x86 is probably at least a few days work
so if you're happy with your current testing approach that's fine.

> I'm not sure what you mean by "opencode".

do they just do the relevant checks as a bit of inline C
(rather than calling out to a function to do the checking)?

-- PMM