qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH 08/19] target-alpha: use new float64_unordered() function
Date: Thu, 14 Apr 2011 09:27:10 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9

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, I suspect that the Correct result on real HW
also depends on the OS completion handler, and I know that at
least for Linux that code was written before UNDZ was added.
So I don't know if even real HW produces the correct result
when considering Underflow priority over Inexact.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]