Re: [Qemu-devel] [PATCH 1/9] softfloat: Introduce float32_to_uint64_round_to_zero

[Tom Musta <tommusta@gmail.com>]

On 3/31/2014 12:48 PM, Peter Maydell wrote:
> On 26 March 2014 20:45, Tom Musta <tommusta@gmail.com> 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 <tommusta@gmail.com>
>> Tested-by: Tom Musta <tommusta@gmail.com>
>> ---
>>  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.