From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2Mmp-0008H7-Hh for qemu-devel@nongnu.org; Wed, 02 Jul 2014 11:49:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2Mmk-0002FW-Cw for qemu-devel@nongnu.org; Wed, 02 Jul 2014 11:49:31 -0400 Received: from zeniv.linux.org.uk ([2002:c35c:fd02::1]:47106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2Mmk-0002F4-5k for qemu-devel@nongnu.org; Wed, 02 Jul 2014 11:49:26 -0400 Date: Wed, 2 Jul 2014 16:49:23 +0100 From: Al Viro Message-ID: <20140702154923.GO18016@ZenIV.linux.org.uk> References: <53B1AEEF.8010108@twiddle.net> <20140630205635.GG18016@ZenIV.linux.org.uk> <53B2E9CA.4040802@twiddle.net> <20140701175036.GJ18016@ZenIV.linux.org.uk> <53B2FE3B.6050306@twiddle.net> <20140702040508.GK18016@ZenIV.linux.org.uk> <20140702055027.GL18016@ZenIV.linux.org.uk> <20140702061723.GM18016@ZenIV.linux.org.uk> <53B424BD.6070705@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B424BD.6070705@twiddle.net> Sender: Al Viro Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Peter Maydell , QEMU Developers 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.