Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function

[Peter Maydell]

On 14 April 2011 17:27, Richard Henderson <address@hidden> wrote:
> On 04/14/2011 08:39 AM, Peter Maydell wrote:
>>>  Exponent underflow and disabled:
>>>    Supply +0, no exception delivered to user.
>>>
>>>  Exponent underflow and enabled:
>>>    Supply +-MIN denorm, Underflow delivered to user.
>>>
>>>    Footnote 3, Overflow and Underflow have priority over Inexact.
>>
>> Thanks. Does "no exception delivered to user" mean also
>> "and do not set FPCR bit UNF" ?
>
> Yes.
>
>> The reason I thought it might set Inexact is that I was looking
>> at page 4-79, which says:
>>
>> "If both the UNFD (underflow disable) bit and the UNDZ (underflow
>>  to zero) bit are set in the FPCR, the implementation sets the
>>  result of an underflow operation to a true zero result. The
>>  zeroing of a denormal result by UNDZ must also be treated as an
>>  inexact result."
>
> Hum.  It looks like we can choose between these results then,
> depending on the intersection of the FPCR disable bits, and
> the per-instruction trapping mode bits (see section 4.7.7.2).
>
> I *think* what would be best for Alpha is if, within softfloat,
> both conditions are signaled, and then we can filter the result
> that is actually needed via helper_fp_exc_raise?  It's hard to
> say without actually doing the work...

Unfortunately doing that is bad for other architectures because
they tend to let the softfloat status flags act directly as
the cumulative exception flags, so if softfloat sets flags they
don't want you've suddenly imposed a burden of saving and
restoring flags or something similarly ugly.

It sounds like maybe what we need is to have a
 signed char float_ftz_flags
or similar in float_status which should be set to the
float_flags which should be passed to float_raise() when
we flush an output denormal to zero. Then we can set that to
float_flag_underflow for ARM, leave it at 0 for other
architectures [preserve existing semantics] and set it to
float_flag_underflow | float_flag_inexact for Alpha.

Or the other approach would be to do something like
how the 'denormal-input-went-to-zero' case is handled: have
an extra float_flag for float_flag_output_denormal, and let
targets either (a) special-case it or (b) merge it with
whichever of underflow or inexact they like when constructing
the guest-visible floating point status flags. I kind of like
that better, actually.

-- PMM