From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51990 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZOXf-0005fV-EC for qemu-devel@nongnu.org; Sun, 02 Jan 2011 09:04:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZOXe-0003wA-3Y for qemu-devel@nongnu.org; Sun, 02 Jan 2011 09:04:15 -0500 Received: from mail-vw0-f45.google.com ([209.85.212.45]:43025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZOXc-0003w6-Qk for qemu-devel@nongnu.org; Sun, 02 Jan 2011 09:04:14 -0500 Received: by vws12 with SMTP id 12so5229988vws.4 for ; Sun, 02 Jan 2011 06:04:12 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20110102132320.GU3615@hall.aurel32.net> References: <1292500278-26215-1-git-send-email-peter.maydell@linaro.org> <1292500278-26215-2-git-send-email-peter.maydell@linaro.org> <20110102132320.GU3615@hall.aurel32.net> Date: Sun, 2 Jan 2011 14:04:11 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel@nongnu.org, Nathan Froyd On 2 January 2011 13:23, Aurelien Jarno wrote: > On Thu, Dec 16, 2010 at 11:51:17AM +0000, Peter Maydell wrote: >> IEEE754 doesn't specify precisely what NaN should be returned as >> the result of an operation on two input NaNs. This is therefore >> target-specific. Abstract out the code in propagateFloat*NaN() >> which was implementing the x87 propagation rules, so that it >> can be easily replaced on a per-target basis. > I am basically find with the idea. I have tried to implement that for > MIPS, but it seems your current implementation doesn't allow correct > propagation for MIPS: if one of the two operand are a sNaN, the result > should be a *default* qNaN. So if the input is a QNaN it's passed through but if it's an SNaN you get the default QNaN? I guess it makes sense since MIPS has SNAN_BIT_IS_ONE and you can't just silence a NaN by flipping the bit (because you might end up with a non-NaN if the final significand is all-zeroes). [...and the existing code that tries to do that is therefore wrong, presumably for both MIPS and HPPA.] Could we have a target-specific "silence this SNaN" function? Then the top level functions could use those rather than doing their own bit-flipping, and I think that would do the right thing for MIPS (you'd implement silence-NaN as "return the default QNaN", and you implement pickNaN() to return the SNaN.) > It seems that we should pass the operands to the pickNaN() function and > return the result instead of a flag. That means having one pickNaN > function per float type, but that can probably be handled by macros or > by having a common function for targets on which its possible to do so. As you might have guessed I was definitely trying to avoid having to actually pass the operands to pickNaN()... > Note however that the current implementation provides the correct > result, as the result is converted in op_helper.c: > > =C2=A0 =C2=A0if (GET_FP_CAUSE(env->active_fpu.fcr31) & FP_INVALID) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wt2 =3D FLOAT_QNAN32; ...incidentally, I don't know MIPS but this code looks a bit suspect to me: set_float_exception_flags(0, &env->active_fpu.fp_status); \ wt2 =3D float32_ ## name (fst0, fst1, &env->active_fpu.fp_status); = \ update_fcr31(); \ if (GET_FP_CAUSE(env->active_fpu.fcr31) & FP_INVALID) \ wt2 =3D FLOAT_QNAN32; \ Isn't it clearing the FP exception flags for each instruction when they ought to be cumulative? -- PMM