On 3/2/20 3:42 AM, BALATON Zoltan wrote:
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?
While it is possible to read the host's ieee exception word after the hardfloat
operation, there are two reasons that is undesirable:
(1) It is *slow*. So slow that it's faster to run the softfloat code instead.
I thought it would be easier to find the benchmark numbers that Emilio
generated when this was tested, but I can't find it.
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?
If we have to enable and disable host fpu exceptions going in and out of
softfloat routines, we're back to modifying the host fpu control word, which as
described above, is *slow*.
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.
I don't know if anyone has tried that variant, where we simply leave the
exceptions enabled, leave the signal handler enabled, and use a global.
Feel free to try it and benchmark it.