[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/2] target/i386: fix IEEE x87 floating-point exception raisi
From: |
Richard Henderson |
Subject: |
Re: [PATCH 2/2] target/i386: fix IEEE x87 floating-point exception raising |
Date: |
Tue, 19 May 2020 11:24:27 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 5/19/20 11:12 AM, Joseph Myers wrote:
> On Tue, 19 May 2020, Richard Henderson wrote:
>
>> To retain the hard float fast path, we need to leave float_flag_invalid set
>> when the accrued exception bit is set. To me this suggests keep all of the
>> FPUS_* bits in fp_status and only convert to FPUS_* when we read the fp
>> status
>> word.
>
> There is no hard float fast path that I can see for floatx80. The issue
> of the fast path might be relevant for fixing SSE exception handling
> (which has some similar issues to x87), but not for floatx80.
Oops, yes. Wasn't thinking for a moment.
> Note that another bug in the x87 emulation is the lack of setting C1 for
> most instructions with inexact results based on the direction of rounding
> (which will require a new feature to be added to the softfloat code to
> record that information so the x87 emulation can use it).
Wow, I don't believe I ever knew about that detail.
This looks similar to the indication that PPC gives (and qemu does not
implement) in FPSCR.FR ("The last instruction incremented the fraction during
rounding").
I guess it's not quite the same -- ppc indicates the fraction was incremented,
while x87 indicates that the value rounded up. Which could be computed from
(fraction incremented) ^ sign, I suppose.
r~