From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42353 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZWuQ-0007n5-5D for qemu-devel@nongnu.org; Sun, 02 Jan 2011 18:00:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZWuO-00015p-LL for qemu-devel@nongnu.org; Sun, 02 Jan 2011 18:00:18 -0500 Received: from hall.aurel32.net ([88.191.126.93]:58934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZWuO-00015O-Fe for qemu-devel@nongnu.org; Sun, 02 Jan 2011 18:00:16 -0500 Date: Mon, 3 Jan 2011 00:00:05 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH 1/2] softfloat: abstract out target-specific NaN propagation rules Message-ID: <20110102230005.GW3615@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> <20110102150556.GV3615@hall.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: Sender: Aurelien Jarno List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, Nathan Froyd On Sun, Jan 02, 2011 at 03:35:30PM +0000, Peter Maydell wrote: > On 2 January 2011 15:05, Aurelien Jarno wrote: > > On Sun, Jan 02, 2011 at 02:04:11PM +0000, Peter Maydell wrote: > >> Could we have a target-specific "silence this SNaN" function? > > > > You mean a target-specific version of floatXX_maybe_silence_nan()? > > Actually what I had in mind was a target-specific floatXX_silence_snan() > which would be called from the propagateFloatXX_NaN() > and floatXX_maybe_silence_nan() functions. But now you mention > it, just allowing the target to override floatXX_maybe_silence_nan() > (and calling it in propagateFloatXX_NaN()) looks like the better thing. > > > At least having a default version (for !SNAN_BIT_IS_ONE) and a version > > for MIPS, HPPA (which is btw not emulated), etc. > > Yes. (Incidentally, HPPA says the rule for "silence this NaN" is: > * set the first bit of the significand to 0 > * set the second bit of the significand to 1 (implementations can do > this (a) always or (b) only if all the other bits of the significand are 0) > Of course we don't need to actually implement this since > as you say we don't have an HPPA target, but it does suggest > that "silencing rules are target-specific" is the right approach.) > > >> 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, it would be the good way to do it. I am going to do a quick > > hack to see if this solution can work and if it is the case (it seems > > to be), apply your patch. > > Cool. > I confirm this solution works. I have applied your patches, I'll send a patch series to implement correct propagation on MIPS later this week. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net