From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51563 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pmsgq-0005t8-45 for qemu-devel@nongnu.org; Tue, 08 Feb 2011 13:53:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pmsgl-0004EE-BP for qemu-devel@nongnu.org; Tue, 08 Feb 2011 13:53:24 -0500 Received: from mail-ew0-f45.google.com ([209.85.215.45]:35084) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pmsgk-0004Dx-VF for qemu-devel@nongnu.org; Tue, 08 Feb 2011 13:53:23 -0500 Received: by ewy10 with SMTP id 10so3256953ewy.4 for ; Tue, 08 Feb 2011 10:53:21 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D5182BF.9050002@st.com> References: <4D50252A.2000100@st.com> <4D5182BF.9050002@st.com> Date: Tue, 8 Feb 2011 18:53:21 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH v3] Softfloat: Add support to softfloat to return floatxx_default_nan when, the corresponding target status flag is set. From: Peter Maydell Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christophe Lyon Cc: "qemu-devel@nongnu.org" On 8 February 2011 17:51, Christophe Lyon wrote: > On 08.02.2011 16:59, Peter Maydell wrote: >> This is float32_to_float16() but it looks like you've missed >> float16_to_float32() ? > > Well, actually I somewhat managed to persuade myself that it was not necessary to patch float16_to_float32(), but looking at it again it seems there are more bugs in that function: > - the ieee parameter shouldn't be used (my ARM ARM does not mention a different behaviour when AH bit is set) In the ARM ARM pseudocode, FPUnpack() of a 16 bit value looks at the FPSCR AH bit, so float16_to_float32() does need to depend on the ieee flag. > - it calls float32ToCommonNaN(a) where 'a' is a float16 instead of a float32 It's only doing that to raise the exception, but you're right that it ought to do things properly... > - this means implementing float16ToCommonNaN, thus float16_is_signaling_nan() ...like that, yes. I'm just working through a set of bugs in float32_to_float16 and float16_to_float32 where they generally mishandle various things. I have also just noticed this error in your patch: +static bits16 commonNaNToFloat16( commonNaNT a STATUS_PARAM) +{ + bits16 mantissa = a.high>>57; That should be ">> 54". (We're shifting a mantissa which is in a 64 bit value down so that the top bits of it end up in the bottom 10 bits (corresponding to the size of mantissa on a float16); so we want to shift by 64-10 == 54.) -- PMM