[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: |
Joseph Myers |
Subject: |
Re: [PATCH 2/2] target/i386: fix IEEE x87 floating-point exception raising |
Date: |
Tue, 19 May 2020 18:12:10 +0000 |
User-agent: |
Alpine 2.21 (DEB 202 2017-01-01) |
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.
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).
> When it comes to raising unmasked exceptions... I have a couple of thoughts.
I expect some code will be needed in each individual instruction
implementation, and probably extra softfloat code, to handle unmasked
exceptions. Some exceptions, when unmasked, should result in instructions
not popping inputs from the stack and not updating destinations. The
softfloat case needs to provide information about the exact underflow case
that targets can use when that exception is set to trap. x87 overflow and
underflow, when unmasked and with a register destination, are supposed to
compute and store a result with a biased exponent for use by the trap
handler. The code will also need to know exactly which instructions
should result in a trap handler being called rather than only doing it for
fwait. Stack underflow and overflow need to be checked for, regardless of
exception masking. (There are other issues relating to trapped exception
handling as well, but that's a summary of the main ones I've noticed.)
--
Joseph S. Myers
address@hidden