Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions

[Al Viro]

On Wed, Jul 02, 2014 at 08:26:53AM -0700, Richard Henderson wrote:
> On 07/01/2014 11:17 PM, Al Viro wrote:
> > If we don't want FE_INEXACT seen by fetestexcept() after rounding 4.5, we'd
> > better not use FPCR.INE - *all* variants of actual hardware (at least from
> > 21064A to 21264) set that sucker, and 4.7 in Architecture Reference Manual
> > very clearly requires such behaviour for any subset that isn't completely
> > without floating point support.
> 
> Um, where do you see that?  I see:
> 
> # 4.7.6.4 IEEE-Compliant Arithmetic Without Inexact Exception
> # This model is similar to the model in Section 4.7.6.3, except this
> # model does not signal inexact results either by the inexact status
> # flag or by trapping. [...] This model is implemented by using IEEE
> # floating-point instructions with the /SU or /SV trap qualifiers.
> 
> The important words to me being "does not signal" and "inexact status flag".
> 
> Thus in sysdeps/alpha/fpu/s_nearbyint.c I explicitly use cvttq/svd and not
> cvttq/svid.  By my reading that means no inexact shall be raised.

What does that have to do with exceptions?  cvttq/svd is not going to raise
one; it *does* set that bit in FPCR, though.  What happens afterwards is
that fetestexcept() calls osf_getsysinfo(2) with GSI_IEEE_FP_CONTROL for op.
Which does
                w = current_thread_info()->ieee_state & IEEE_SW_MASK;
                w = swcr_update_status(w, rdfpcr());
and hands the value of w to caller.  Now, look at swcr_update_status()
(in arch/alpha/include/uapi/asm/fpu.h these days) and note that on 21264
it will throw away the status bits of ->ieee_state and use 6 bits from
FPCR instead.

Note, BTW, that appendix B (IEEE conformance) claims (in B.1) conversions as
hardware-implemented, with "Software routines support remainder, round to
integer in floating-point format, and convert binary to/from decimal" right
next to it.