On Sun, 1 Mar 2020, Richard Henderson wrote:
On 3/1/20 4:13 PM, Programmingkid wrote:
Ok, I was just looking at Intel's x87 chip documentation. It supports
IEEE 754 floating point operations and exception flags. This leads me
to this question. Would simply taking the host exception flags and
using them to set the PowerPC's FPU's flag be an acceptable solution to
this problem?
In my understanding that's what is currently done, the problem with PPC as
Richard said is the non-sticky versions of some of these bits which need
clearing FP exception status before every FPU op which seems to be
expensive and slower than using softfloat. So to use hardfloat we either
accept that we can't emulate these bits with hardfloat or we need to do
something else than clearing flags and checking after every FPU op.
While not emulating these bits don't seem to matter for most clients and
other PPC emulations got away with it, QEMU prefers accuracy over speed
even for rarely used features.
No.
The primary issue is the FPSCR.FI flag. This is not an accumulative bit, per
ieee754, but per operation.
The "hardfloat" option works (with other targets) only with ieee745
accumulative exceptions, when the most common of those exceptions, inexact, has
already been raised. And thus need not be raised a second time.
Why exactly it's done that way? What are the differences between IEEE FP
implementations that prevents using hardfloat most of the time instead of
only using it in some (although supposedly common) special cases?
Per the PowerPC architecture, inexact must be recognized afresh for every
operation. Which is cheap in hardware but expensive in software.
And once you're done with FI, FR has been and continues to be emulated
incorrectly.
I think CPUs can also raise exceptions when they detect the condition in
hardware so maybe we should install our FPU exception handler and set
guest flags from that then we don't need to check and won't have problem
with these bits either. Why is that not possible or isn't done? The
softfloat code has a comment that working with exceptions is not pleasent
but why? Isn't setting flags from a handler easier than checking
separately for each op? If this is because of differences in how flags are
handled by different targets we don't have to do that from the host FPU
exception handler. That handler could only set a global flag on each
exception that targets can be checked by targets and handle differences.
This global flag then can include non-sticky versions if needed because
clearing a global should be less expensive than clearing FPU status reg.
But I don't really know, just guessing, somone who knows more about FPUs
probably knows a better way.
Regards,
BALATON Zoltan