From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36671) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUgcM-0003uP-VA for qemu-devel@nongnu.org; Mon, 31 Mar 2014 14:07:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WUgcD-0004Dv-SV for qemu-devel@nongnu.org; Mon, 31 Mar 2014 14:07:30 -0400 Message-ID: <5339AED5.8010101@gmail.com> Date: Mon, 31 Mar 2014 13:07:17 -0500 From: Tom Musta MIME-Version: 1.0 References: <1395866754-18673-1-git-send-email-tommusta@gmail.com> <1395866754-18673-2-git-send-email-tommusta@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/9] softfloat: Introduce float32_to_uint64_round_to_zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "qemu-ppc@nongnu.org" , QEMU Developers On 3/31/2014 12:48 PM, Peter Maydell wrote: > On 26 March 2014 20:45, Tom Musta wrote: >> This change adds the float32_to_uint64_round_to_zero function to the softfloat >> library. This function fills out the complement of float32 to INT round-to-zero >> conversion rountines, where INT is {int32_t, uint32_t, int64_t, uint64_t}. >> >> This contribution can be licensed under either the softfloat-2a or -2b >> license. >> >> Signed-off-by: Tom Musta >> Tested-by: Tom Musta >> --- >> fpu/softfloat.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++ >> include/fpu/softfloat.h | 1 + >> 2 files changed, 55 insertions(+), 0 deletions(-) >> >> diff --git a/fpu/softfloat.c b/fpu/softfloat.c >> index 5f02c16..d6df78a 100644 >> --- a/fpu/softfloat.c >> +++ b/fpu/softfloat.c >> @@ -1628,6 +1628,60 @@ uint64 float32_to_uint64(float32 a STATUS_PARAM) >> >> /*---------------------------------------------------------------------------- >> | Returns the result of converting the single-precision floating-point value >> +| `a' to the 64-bit unsigned integer format. The conversion is >> +| performed according to the IEC/IEEE Standard for Binary Floating-Point >> +| Arithmetic, except that the conversion is always rounded toward zero. If >> +| `a' is a NaN, the largest unsigned integer is returned. Otherwise, if the >> +| conversion overflows, the largest unsigned integer is returned. If the >> +| 'a' is negative, the result is rounded and zero is returned; values that do >> +| not round to zero will raise the inexact flag. >> +*----------------------------------------------------------------------------*/ >> + >> +uint64 float32_to_uint64_round_to_zero(float32 a STATUS_PARAM) >> +{ >> + flag aSign; >> + int_fast16_t aExp, shiftCount; >> + uint32_t aSig; >> + uint64_t aSig64; >> + uint64_t z; > > So, float64_to_uint64_round_to_zero() works by temporarily > fiddling with the rounding mode and then calling > float64_to_uint64(). Is there a reason for doing this > function like this rather than in the same way? > > thanks > -- PMM > True. But not all of the *_round_to_zero() routines do this, e.g. float32_to_int64_round_to_zero(). So no matter what I do, it is inconsistent with something. Do you prefer the fiddle-and-reuse approach? (I think I do, actually). If so, I will respin the patch.