qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Musta
Subject: Re: [Qemu-devel] [PATCH 1/9] softfloat: Introduce float32_to_uint64_round_to_zero
Date: Mon, 31 Mar 2014 13:07:17 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]