From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52604 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnEsu-0004Ic-H7 for qemu-devel@nongnu.org; Wed, 09 Feb 2011 13:35:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnEsr-0004TU-Du for qemu-devel@nongnu.org; Wed, 09 Feb 2011 13:35:24 -0500 Received: from hall.aurel32.net ([88.191.126.93]:39928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnEsr-0004TG-6b for qemu-devel@nongnu.org; Wed, 09 Feb 2011 13:35:21 -0500 Date: Wed, 9 Feb 2011 19:35:26 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH v3] Softfloat: Add support to softfloat to return floatxx_default_nan when, the corresponding target status flag is set. Message-ID: <20110209183526.GA3131@volta.aurel32.net> References: <4D50252A.2000100@st.com> <4D5182BF.9050002@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Christophe Lyon , "qemu-devel@nongnu.org" Hi, On Tue, Feb 08, 2011 at 08:06:57PM +0000, Peter Maydell wrote: > On 8 February 2011 18:53, Peter Maydell wrote: > > On 8 February 2011 17:51, Christophe Lyon wrote: > >> - this means implementing float16ToCommonNaN, thus float16_is_signaling_nan() > > > > ...like that, yes. > > I have a slightly-tested implementation of these functions on my > hard disk now; I'll try to finish testing them tomorrow (my testing > is still falling over on some inputs to VCVTT/VCVTB). > > (cc: Aurelien for the softfloat style questions:) > > I think we should go ahead and define a float16 type. I fully agree with that. I have seen you have already sent patches about that, will look at them later. > Also, at the moment the commonNaNToFloatX(floatYToCommonNaN()) > idiom doesn't do anything to avoid signaling NaNs showing up in > the output. On ARM this got fixed by having the helper.c wrappers > call float*_maybe_silence_nan() but maybe we should do it > in the generic softfloat code? > > ie instead of: > > if ( mantissa ) > return make_float32( > ( ( (bits32) a.sign )<<31 ) | 0x7F800000 | ( a.high>>41 ) ); > else > return float32_default_nan; > > do: > float32 r = make_float32( > ( ( (bits32) a.sign )<<31 ) | 0x7F800000 | ( a.high>>41 ) ); On an unrelated note, if we changes in this function, it might be a good idea to use mantissa instead of a.high>>41. It's the same, but probably easier to read. > if (!mantissa) { > /* target specific, !SNAN_BIT_IS_ONE targets probably > * just set the QNAN bit (true for ARM, SPARC) > * others likely return the default NaN ? > */ > } else { > return float32_maybe_silence_nan(r); > } > > I'm pretty sure the existing code is wrong for SPARC, for instance, > which is supposed to return a float32 qNaN with just the QNAN bit set > if it is presented with a float64 signalling NaN all of whose non-zero > mantissa bits are at the bottom end and don't make it into the float32. > (ARM dodges a bullet here because as it happens our float32 > default_nan has only the QNAN bit set, but SPARC's has all the > mantissa bits set.) > > Opinions? > It makes sense. I will play a bit with a real MIPS machine to see how it behaves and come back with my results. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net