From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45565 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PN9Lk-0005hl-Pi for qemu-devel@nongnu.org; Mon, 29 Nov 2010 14:25:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PN9Lj-00039t-5A for qemu-devel@nongnu.org; Mon, 29 Nov 2010 14:25:20 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:61343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PN9Lj-00039o-1i for qemu-devel@nongnu.org; Mon, 29 Nov 2010 14:25:19 -0500 Received: by qyk1 with SMTP id 1so251047qyk.4 for ; Mon, 29 Nov 2010 11:25:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20101129174928.GE8544@codesourcery.com> References: <1290538431-13170-1-git-send-email-peter.maydell@linaro.org> <1290538431-13170-9-git-send-email-peter.maydell@linaro.org> <20101129174928.GE8544@codesourcery.com> Date: Mon, 29 Nov 2010 19:25:18 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH 08/12] ARM: Return correct result for single<->double conversion of NaN 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: Nathan Froyd Cc: qemu-devel@nongnu.org On 29 November 2010 17:49, Nathan Froyd wrote: > On Tue, Nov 23, 2010 at 06:53:47PM +0000, Peter Maydell wrote: >> + =C2=A0 =C2=A0/* ARM requires that S<->D conversion of any kind of NaN = generates >> + =C2=A0 =C2=A0 * a quiet NaN by forcing the most significant frac bit t= o 1. >> + =C2=A0 =C2=A0 */ >> + =C2=A0 =C2=A0if (float64_is_signaling_nan(r)) { >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0return make_float64(float64_val(r) | (1LL <= < 51)); >> + =C2=A0 =C2=A0} > As with other NaN-handling patches, I don't think the bit-twiddling here > is a good idea. =C2=A0Having a float*_maybe_silence_nan function in softf= loat > would be a better approach. I guess this (like the other one you commented on) boils down to how you want to approach the boundary between qemu proper and the softfloat library. There are three approaches I can see: (a) live with the softfloat API as it is, and add bit twiddling as necessary for particular target CPU special casing in the per-cpu functions (which is what I was doing here and with the 'is it a NaN?' function in the other patch) (b) add to and extend the softfloat API whenever you have some floating-point related thing it doesn't currently support (which I did with the "add conversions to int16_t" patch because it was a big chunk of bit twiddling, but which I felt was a bit invasive to do for this sort of minor tweak, especially since softfloat is a copy of a third-party library) (c) do something suboptimal where the softfloat API provides some-API-but-not-quite-the-ideal-API (which I'm not particularly keen on and is what I see the "is_nan() || is_signalling_nan()" approach as) My original patchset tends to (a) except where (b) is clearly more sensible; if people would prefer (b) all the time I'm happy to do things that way; (c) doesn't seem very attractive to me and I would rather do (b) in those situations. -- PMM