[v5,04/10] softfloat: Drop [u]int16 types in favor of [u]int_fast16_t

AIX already didn't use our definition, so let's start ripping out this one:
As pointed out by Peter Maydell, int16 is currently int on most
supported platforms, so let's replace it with int_fast16_t,
allowing the system to use a wider type if appropriate.

Note that Darwin uses [u]int16_t now, whereas Haiku uses [u]int32_t.

v5:
* Rebased. Convert new use of int16.

v3:
* Split off. Use [u]int_fast16_t rather than [u]int16_t.

v2:
* Rebased. Fix two new instances of int16.

Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: malc <av1474@comtv.ru>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
---
 fpu/softfloat-macros.h |   18 ++++----
 fpu/softfloat.c        |  116 ++++++++++++++++++++++++------------------------
 fpu/softfloat.h        |    8 +---
 3 files changed, 69 insertions(+), 73 deletions(-)

On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote:
> AIX already didn't use our definition, so let's start ripping out this one:
> As pointed out by Peter Maydell, int16 is currently int on most
> supported platforms, so let's replace it with int_fast16_t,
> allowing the system to use a wider type if appropriate.

Do you have a rationale about the use of the fast version of the types?
As you said it allows the compiler to use a wider type if appropriate,
and this usually doesn't play very well when shifts are involved, which
is the case of the softfloat code. Have you verified that each
conversion is correct? On the other hand I really doubt it has a 
measurable impact on speed.

I would really go for uint16_t for now. This might be changed to the fast 
version in a second step if we are sure everything is correct, but let's
don't mix the two steps for now.

> Note that Darwin uses [u]int16_t now, whereas Haiku uses [u]int32_t.
> 
> v5:
> * Rebased. Convert new use of int16.
> 
> v3:
> * Split off. Use [u]int_fast16_t rather than [u]int16_t.
> 
> v2:
> * Rebased. Fix two new instances of int16.
> 
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Cc: malc <av1474@comtv.ru>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> ---
>  fpu/softfloat-macros.h |   18 ++++----
>  fpu/softfloat.c        |  116 ++++++++++++++++++++++++------------------------
>  fpu/softfloat.h        |    8 +---
>  3 files changed, 69 insertions(+), 73 deletions(-)
> 
> diff --git a/fpu/softfloat-macros.h b/fpu/softfloat-macros.h
> index 3128e60..7b350c0 100644
> --- a/fpu/softfloat-macros.h
> +++ b/fpu/softfloat-macros.h
> @@ -44,7 +44,7 @@ these four paragraphs for those parts of this code that are retained.
>  | The result is stored in the location pointed to by `zPtr'.
>  *----------------------------------------------------------------------------*/
>  
> -INLINE void shift32RightJamming( uint32_t a, int16 count, uint32_t *zPtr )
> +INLINE void shift32RightJamming( uint32_t a, int_fast16_t count, uint32_t *zPtr )
>  {
>      uint32_t z;
>  
> @@ -70,7 +70,7 @@ INLINE void shift32RightJamming( uint32_t a, int16 count, uint32_t *zPtr )
>  | The result is stored in the location pointed to by `zPtr'.
>  *----------------------------------------------------------------------------*/
>  
> -INLINE void shift64RightJamming( uint64_t a, int16 count, uint64_t *zPtr )
> +INLINE void shift64RightJamming( uint64_t a, int_fast16_t count, uint64_t *zPtr )
>  {
>      uint64_t z;
>  
> @@ -106,7 +106,7 @@ INLINE void shift64RightJamming( uint64_t a, int16 count, uint64_t *zPtr )
>  
>  INLINE void
>   shift64ExtraRightJamming(
> -     uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr )
> +     uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t *z1Ptr )
>  {
>      uint64_t z0, z1;
>      int8 negCount = ( - count ) & 63;
> @@ -143,7 +143,7 @@ INLINE void
>  
>  INLINE void
>   shift128Right(
> -     uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr )
> +     uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t *z1Ptr )
>  {
>      uint64_t z0, z1;
>      int8 negCount = ( - count ) & 63;
> @@ -178,7 +178,7 @@ INLINE void
>  
>  INLINE void
>   shift128RightJamming(
> -     uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr )
> +     uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t *z1Ptr )
>  {
>      uint64_t z0, z1;
>      int8 negCount = ( - count ) & 63;
> @@ -232,7 +232,7 @@ INLINE void
>       uint64_t a0,
>       uint64_t a1,
>       uint64_t a2,
> -     int16 count,
> +     int_fast16_t count,
>       uint64_t *z0Ptr,
>       uint64_t *z1Ptr,
>       uint64_t *z2Ptr
> @@ -287,7 +287,7 @@ INLINE void
>  
>  INLINE void
>   shortShift128Left(
> -     uint64_t a0, uint64_t a1, int16 count, uint64_t *z0Ptr, uint64_t *z1Ptr )
> +     uint64_t a0, uint64_t a1, int_fast16_t count, uint64_t *z0Ptr, uint64_t *z1Ptr )
>  {
>  
>      *z1Ptr = a1<<count;
> @@ -309,7 +309,7 @@ INLINE void
>       uint64_t a0,
>       uint64_t a1,
>       uint64_t a2,
> -     int16 count,
> +     int_fast16_t count,
>       uint64_t *z0Ptr,
>       uint64_t *z1Ptr,
>       uint64_t *z2Ptr
> @@ -580,7 +580,7 @@ static uint64_t estimateDiv128To64( uint64_t a0, uint64_t a1, uint64_t b )
>  | value.
>  *----------------------------------------------------------------------------*/
>  
> -static uint32_t estimateSqrt32( int16 aExp, uint32_t a )
> +static uint32_t estimateSqrt32( int_fast16_t aExp, uint32_t a )
>  {
>      static const uint16_t sqrtOddAdjustments[] = {
>          0x0004, 0x0022, 0x005D, 0x00B1, 0x011D, 0x019F, 0x0236, 0x02E0,
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index 08e4ae0..befd400 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -84,7 +84,7 @@ INLINE uint32_t extractFloat16Frac(float16 a)
>  | Returns the exponent bits of the half-precision floating-point value `a'.
>  *----------------------------------------------------------------------------*/
>  
> -INLINE int16 extractFloat16Exp(float16 a)
> +INLINE int_fast16_t extractFloat16Exp(float16 a)
>  {
>      return (float16_val(a) >> 10) & 0x1f;
>  }
> @@ -215,7 +215,7 @@ INLINE uint32_t extractFloat32Frac( float32 a )
>  | Returns the exponent bits of the single-precision floating-point value `a'.
>  *----------------------------------------------------------------------------*/
>  
> -INLINE int16 extractFloat32Exp( float32 a )
> +INLINE int_fast16_t extractFloat32Exp( float32 a )
>  {
>  
>      return ( float32_val(a)>>23 ) & 0xFF;
> @@ -256,7 +256,7 @@ static float32 float32_squash_input_denormal(float32 a STATUS_PARAM)
>  *----------------------------------------------------------------------------*/
>  
>  static void
> - normalizeFloat32Subnormal( uint32_t aSig, int16 *zExpPtr, uint32_t *zSigPtr )
> + normalizeFloat32Subnormal( uint32_t aSig, int_fast16_t *zExpPtr, uint32_t *zSigPtr )
>  {
>      int8 shiftCount;
>  
> @@ -277,7 +277,7 @@ static void
>  | significand.
>  *----------------------------------------------------------------------------*/
>  
> -INLINE float32 packFloat32( flag zSign, int16 zExp, uint32_t zSig )
> +INLINE float32 packFloat32( flag zSign, int_fast16_t zExp, uint32_t zSig )
>  {
>  
>      return make_float32(
> @@ -307,7 +307,7 @@ INLINE float32 packFloat32( flag zSign, int16 zExp, uint32_t zSig )
>  | Binary Floating-Point Arithmetic.
>  *----------------------------------------------------------------------------*/
>  
> -static float32 roundAndPackFloat32( flag zSign, int16 zExp, uint32_t zSig STATUS_PARAM)
> +static float32 roundAndPackFloat32( flag zSign, int_fast16_t zExp, uint32_t zSig STATUS_PARAM)
>  {
>      int8 roundingMode;
>      flag roundNearestEven;
> @@ -370,7 +370,7 @@ static float32 roundAndPackFloat32( flag zSign, int16 zExp, uint32_t zSig STATUS
>  *----------------------------------------------------------------------------*/
>  
>  static float32
> - normalizeRoundAndPackFloat32( flag zSign, int16 zExp, uint32_t zSig STATUS_PARAM)
> + normalizeRoundAndPackFloat32( flag zSign, int_fast16_t zExp, uint32_t zSig STATUS_PARAM)
>  {
>      int8 shiftCount;
>  
> @@ -394,7 +394,7 @@ INLINE uint64_t extractFloat64Frac( float64 a )
>  | Returns the exponent bits of the double-precision floating-point value `a'.
>  *----------------------------------------------------------------------------*/
>  
> -INLINE int16 extractFloat64Exp( float64 a )
> +INLINE int_fast16_t extractFloat64Exp( float64 a )
>  {
>  
>      return ( float64_val(a)>>52 ) & 0x7FF;
> @@ -435,7 +435,7 @@ static float64 float64_squash_input_denormal(float64 a STATUS_PARAM)
>  *----------------------------------------------------------------------------*/
>  
>  static void
> - normalizeFloat64Subnormal( uint64_t aSig, int16 *zExpPtr, uint64_t *zSigPtr )
> + normalizeFloat64Subnormal( uint64_t aSig, int_fast16_t *zExpPtr, uint64_t *zSigPtr )
>  {
>      int8 shiftCount;
>  
> @@ -456,7 +456,7 @@ static void
>  | significand.
>  *----------------------------------------------------------------------------*/
>  
> -INLINE float64 packFloat64( flag zSign, int16 zExp, uint64_t zSig )
> +INLINE float64 packFloat64( flag zSign, int_fast16_t zExp, uint64_t zSig )
>  {
>  
>      return make_float64(
> @@ -486,11 +486,11 @@ INLINE float64 packFloat64( flag zSign, int16 zExp, uint64_t zSig )
>  | Binary Floating-Point Arithmetic.
>  *----------------------------------------------------------------------------*/
>  
> -static float64 roundAndPackFloat64( flag zSign, int16 zExp, uint64_t zSig STATUS_PARAM)
> +static float64 roundAndPackFloat64( flag zSign, int_fast16_t zExp, uint64_t zSig STATUS_PARAM)
>  {
>      int8 roundingMode;
>      flag roundNearestEven;
> -    int16 roundIncrement, roundBits;
> +    int_fast16_t roundIncrement, roundBits;
>      flag isTiny;
>  
>      roundingMode = STATUS(float_rounding_mode);
> @@ -549,7 +549,7 @@ static float64 roundAndPackFloat64( flag zSign, int16 zExp, uint64_t zSig STATUS
>  *----------------------------------------------------------------------------*/
>  
>  static float64
> - normalizeRoundAndPackFloat64( flag zSign, int16 zExp, uint64_t zSig STATUS_PARAM)
> + normalizeRoundAndPackFloat64( flag zSign, int_fast16_t zExp, uint64_t zSig STATUS_PARAM)
>  {
>      int8 shiftCount;
>  
> @@ -1354,7 +1354,7 @@ float128 int64_to_float128( int64 a STATUS_PARAM )
>  int32 float32_to_int32( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint32_t aSig;
>      uint64_t aSig64;
>  
> @@ -1385,7 +1385,7 @@ int32 float32_to_int32( float32 a STATUS_PARAM )
>  int32 float32_to_int32_round_to_zero( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint32_t aSig;
>      int32 z;
>      a = float32_squash_input_denormal(a STATUS_VAR);
> @@ -1425,10 +1425,10 @@ int32 float32_to_int32_round_to_zero( float32 a STATUS_PARAM )
>  | returned.
>  *----------------------------------------------------------------------------*/
>  
> -int16 float32_to_int16_round_to_zero( float32 a STATUS_PARAM )
> +int_fast16_t float32_to_int16_round_to_zero( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint32_t aSig;
>      int32 z;
>  
> @@ -1477,7 +1477,7 @@ int16 float32_to_int16_round_to_zero( float32 a STATUS_PARAM )
>  int64 float32_to_int64( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint32_t aSig;
>      uint64_t aSig64, aSigExtra;
>      a = float32_squash_input_denormal(a STATUS_VAR);
> @@ -1514,7 +1514,7 @@ int64 float32_to_int64( float32 a STATUS_PARAM )
>  int64 float32_to_int64_round_to_zero( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint32_t aSig;
>      uint64_t aSig64;
>      int64 z;
> @@ -1558,7 +1558,7 @@ int64 float32_to_int64_round_to_zero( float32 a STATUS_PARAM )
>  float64 float32_to_float64( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig;
>      a = float32_squash_input_denormal(a STATUS_VAR);
>  
> @@ -1590,7 +1590,7 @@ float64 float32_to_float64( float32 a STATUS_PARAM )
>  floatx80 float32_to_floatx80( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig;
>  
>      a = float32_squash_input_denormal(a STATUS_VAR);
> @@ -1624,7 +1624,7 @@ floatx80 float32_to_floatx80( float32 a STATUS_PARAM )
>  float128 float32_to_float128( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig;
>  
>      a = float32_squash_input_denormal(a STATUS_VAR);
> @@ -1656,7 +1656,7 @@ float128 float32_to_float128( float32 a STATUS_PARAM )
>  float32 float32_round_to_int( float32 a STATUS_PARAM)
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t lastBitMask, roundBitsMask;
>      int8 roundingMode;
>      uint32_t z;
> @@ -1716,9 +1716,9 @@ float32 float32_round_to_int( float32 a STATUS_PARAM)
>  
>  static float32 addFloat32Sigs( float32 a, float32 b, flag zSign STATUS_PARAM)
>  {
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint32_t aSig, bSig, zSig;
> -    int16 expDiff;
> +    int_fast16_t expDiff;
>  
>      aSig = extractFloat32Frac( a );
>      aExp = extractFloat32Exp( a );
> @@ -1790,9 +1790,9 @@ static float32 addFloat32Sigs( float32 a, float32 b, flag zSign STATUS_PARAM)
>  
>  static float32 subFloat32Sigs( float32 a, float32 b, flag zSign STATUS_PARAM)
>  {
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint32_t aSig, bSig, zSig;
> -    int16 expDiff;
> +    int_fast16_t expDiff;
>  
>      aSig = extractFloat32Frac( a );
>      aExp = extractFloat32Exp( a );
> @@ -1910,7 +1910,7 @@ float32 float32_sub( float32 a, float32 b STATUS_PARAM )
>  float32 float32_mul( float32 a, float32 b STATUS_PARAM )
>  {
>      flag aSign, bSign, zSign;
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint32_t aSig, bSig;
>      uint64_t zSig64;
>      uint32_t zSig;
> @@ -1973,7 +1973,7 @@ float32 float32_mul( float32 a, float32 b STATUS_PARAM )
>  float32 float32_div( float32 a, float32 b STATUS_PARAM )
>  {
>      flag aSign, bSign, zSign;
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint32_t aSig, bSig, zSig;
>      a = float32_squash_input_denormal(a STATUS_VAR);
>      b = float32_squash_input_denormal(b STATUS_VAR);
> @@ -2037,7 +2037,7 @@ float32 float32_div( float32 a, float32 b STATUS_PARAM )
>  float32 float32_rem( float32 a, float32 b STATUS_PARAM )
>  {
>      flag aSign, zSign;
> -    int16 aExp, bExp, expDiff;
> +    int_fast16_t aExp, bExp, expDiff;
>      uint32_t aSig, bSig;
>      uint32_t q;
>      uint64_t aSig64, bSig64, q64;
> @@ -2138,7 +2138,7 @@ float32 float32_rem( float32 a, float32 b STATUS_PARAM )
>  float32 float32_sqrt( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, zExp;
> +    int_fast16_t aExp, zExp;
>      uint32_t aSig, zSig;
>      uint64_t rem, term;
>      a = float32_squash_input_denormal(a STATUS_VAR);
> @@ -2224,7 +2224,7 @@ static const float64 float32_exp2_coefficients[15] =
>  float32 float32_exp2( float32 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig;
>      float64 r, x, xn;
>      int i;
> @@ -2272,7 +2272,7 @@ float32 float32_exp2( float32 a STATUS_PARAM )
>  float32 float32_log2( float32 a STATUS_PARAM )
>  {
>      flag aSign, zSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig, zSig, i;
>  
>      a = float32_squash_input_denormal(a STATUS_VAR);
> @@ -2493,7 +2493,7 @@ int float32_lt_quiet( float32 a, float32 b STATUS_PARAM )
>  int32 float64_to_int32( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint64_t aSig;
>      a = float64_squash_input_denormal(a STATUS_VAR);
>  
> @@ -2521,7 +2521,7 @@ int32 float64_to_int32( float64 a STATUS_PARAM )
>  int32 float64_to_int32_round_to_zero( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint64_t aSig, savedASig;
>      int32 z;
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -2565,10 +2565,10 @@ int32 float64_to_int32_round_to_zero( float64 a STATUS_PARAM )
>  | returned.
>  *----------------------------------------------------------------------------*/
>  
> -int16 float64_to_int16_round_to_zero( float64 a STATUS_PARAM )
> +int_fast16_t float64_to_int16_round_to_zero( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint64_t aSig, savedASig;
>      int32 z;
>  
> @@ -2619,7 +2619,7 @@ int16 float64_to_int16_round_to_zero( float64 a STATUS_PARAM )
>  int64 float64_to_int64( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint64_t aSig, aSigExtra;
>      a = float64_squash_input_denormal(a STATUS_VAR);
>  
> @@ -2662,7 +2662,7 @@ int64 float64_to_int64( float64 a STATUS_PARAM )
>  int64 float64_to_int64_round_to_zero( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, shiftCount;
> +    int_fast16_t aExp, shiftCount;
>      uint64_t aSig;
>      int64 z;
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -2712,7 +2712,7 @@ int64 float64_to_int64_round_to_zero( float64 a STATUS_PARAM )
>  float32 float64_to_float32( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t aSig;
>      uint32_t zSig;
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -2745,7 +2745,7 @@ float32 float64_to_float32( float64 a STATUS_PARAM )
>  | than the desired result exponent whenever `zSig' is a complete, normalized
>  | significand.
>  *----------------------------------------------------------------------------*/
> -static float16 packFloat16(flag zSign, int16 zExp, uint16_t zSig)
> +static float16 packFloat16(flag zSign, int_fast16_t zExp, uint16_t zSig)
>  {
>      return make_float16(
>          (((uint32_t)zSign) << 15) + (((uint32_t)zExp) << 10) + zSig);
> @@ -2757,7 +2757,7 @@ static float16 packFloat16(flag zSign, int16 zExp, uint16_t zSig)
>  float32 float16_to_float32(float16 a, flag ieee STATUS_PARAM)
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig;
>  
>      aSign = extractFloat16Sign(a);
> @@ -2787,7 +2787,7 @@ float32 float16_to_float32(float16 a, flag ieee STATUS_PARAM)
>  float16 float32_to_float16(float32 a, flag ieee STATUS_PARAM)
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig;
>      uint32_t mask;
>      uint32_t increment;
> @@ -2890,7 +2890,7 @@ float16 float32_to_float16(float32 a, flag ieee STATUS_PARAM)
>  floatx80 float64_to_floatx80( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t aSig;
>  
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -2925,7 +2925,7 @@ floatx80 float64_to_floatx80( float64 a STATUS_PARAM )
>  float128 float64_to_float128( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t aSig, zSig0, zSig1;
>  
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -2958,7 +2958,7 @@ float128 float64_to_float128( float64 a STATUS_PARAM )
>  float64 float64_round_to_int( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t lastBitMask, roundBitsMask;
>      int8 roundingMode;
>      uint64_t z;
> @@ -3031,9 +3031,9 @@ float64 float64_trunc_to_int( float64 a STATUS_PARAM)
>  
>  static float64 addFloat64Sigs( float64 a, float64 b, flag zSign STATUS_PARAM )
>  {
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint64_t aSig, bSig, zSig;
> -    int16 expDiff;
> +    int_fast16_t expDiff;
>  
>      aSig = extractFloat64Frac( a );
>      aExp = extractFloat64Exp( a );
> @@ -3105,9 +3105,9 @@ static float64 addFloat64Sigs( float64 a, float64 b, flag zSign STATUS_PARAM )
>  
>  static float64 subFloat64Sigs( float64 a, float64 b, flag zSign STATUS_PARAM )
>  {
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint64_t aSig, bSig, zSig;
> -    int16 expDiff;
> +    int_fast16_t expDiff;
>  
>      aSig = extractFloat64Frac( a );
>      aExp = extractFloat64Exp( a );
> @@ -3225,7 +3225,7 @@ float64 float64_sub( float64 a, float64 b STATUS_PARAM )
>  float64 float64_mul( float64 a, float64 b STATUS_PARAM )
>  {
>      flag aSign, bSign, zSign;
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint64_t aSig, bSig, zSig0, zSig1;
>  
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -3286,7 +3286,7 @@ float64 float64_mul( float64 a, float64 b STATUS_PARAM )
>  float64 float64_div( float64 a, float64 b STATUS_PARAM )
>  {
>      flag aSign, bSign, zSign;
> -    int16 aExp, bExp, zExp;
> +    int_fast16_t aExp, bExp, zExp;
>      uint64_t aSig, bSig, zSig;
>      uint64_t rem0, rem1;
>      uint64_t term0, term1;
> @@ -3358,7 +3358,7 @@ float64 float64_div( float64 a, float64 b STATUS_PARAM )
>  float64 float64_rem( float64 a, float64 b STATUS_PARAM )
>  {
>      flag aSign, zSign;
> -    int16 aExp, bExp, expDiff;
> +    int_fast16_t aExp, bExp, expDiff;
>      uint64_t aSig, bSig;
>      uint64_t q, alternateASig;
>      int64_t sigMean;
> @@ -3444,7 +3444,7 @@ float64 float64_rem( float64 a, float64 b STATUS_PARAM )
>  float64 float64_sqrt( float64 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp, zExp;
> +    int_fast16_t aExp, zExp;
>      uint64_t aSig, zSig, doubleZSig;
>      uint64_t rem0, rem1, term0, term1;
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -3495,7 +3495,7 @@ float64 float64_sqrt( float64 a STATUS_PARAM )
>  float64 float64_log2( float64 a STATUS_PARAM )
>  {
>      flag aSign, zSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t aSig, aSig0, aSig1, zSig, i;
>      a = float64_squash_input_denormal(a STATUS_VAR);
>  
> @@ -3930,7 +3930,7 @@ float64 floatx80_to_float64( floatx80 a STATUS_PARAM )
>  float128 floatx80_to_float128( floatx80 a STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t aSig, zSig0, zSig1;
>  
>      aSig = extractFloatx80Frac( a );
> @@ -6061,7 +6061,7 @@ int float128_compare_quiet( float128 a, float128 b STATUS_PARAM )
>  float32 float32_scalbn( float32 a, int n STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint32_t aSig;
>  
>      a = float32_squash_input_denormal(a STATUS_VAR);
> @@ -6085,7 +6085,7 @@ float32 float32_scalbn( float32 a, int n STATUS_PARAM )
>  float64 float64_scalbn( float64 a, int n STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t aSig;
>  
>      a = float64_squash_input_denormal(a STATUS_VAR);
> @@ -6110,7 +6110,7 @@ float64 float64_scalbn( float64 a, int n STATUS_PARAM )
>  floatx80 floatx80_scalbn( floatx80 a, int n STATUS_PARAM )
>  {
>      flag aSign;
> -    int16 aExp;
> +    int_fast16_t aExp;
>      uint64_t aSig;
>  
>      aSig = extractFloatx80Frac( a );
> diff --git a/fpu/softfloat.h b/fpu/softfloat.h
> index 5d05fa5..f98e50c 100644
> --- a/fpu/softfloat.h
> +++ b/fpu/softfloat.h
> @@ -56,10 +56,6 @@ these four paragraphs for those parts of this code that are retained.
>  typedef uint8_t flag;
>  typedef uint8_t uint8;
>  typedef int8_t int8;
> -#ifndef _AIX
> -typedef int uint16;
> -typedef int int16;
> -#endif
>  typedef unsigned int uint32;
>  typedef signed int int32;
>  typedef uint64_t uint64;
> @@ -288,7 +284,7 @@ float16 float16_maybe_silence_nan( float16 );
>  /*----------------------------------------------------------------------------
>  | Software IEC/IEEE single-precision conversion routines.
>  *----------------------------------------------------------------------------*/
> -int16 float32_to_int16_round_to_zero( float32 STATUS_PARAM );
> +int_fast16_t float32_to_int16_round_to_zero( float32 STATUS_PARAM );
>  unsigned int float32_to_uint16_round_to_zero( float32 STATUS_PARAM );
>  int32 float32_to_int32( float32 STATUS_PARAM );
>  int32 float32_to_int32_round_to_zero( float32 STATUS_PARAM );
> @@ -398,7 +394,7 @@ INLINE float32 float32_set_sign(float32 a, int sign)
>  /*----------------------------------------------------------------------------
>  | Software IEC/IEEE double-precision conversion routines.
>  *----------------------------------------------------------------------------*/
> -int16 float64_to_int16_round_to_zero( float64 STATUS_PARAM );
> +int_fast16_t float64_to_int16_round_to_zero( float64 STATUS_PARAM );
>  unsigned int float64_to_uint16_round_to_zero( float64 STATUS_PARAM );
>  int32 float64_to_int32( float64 STATUS_PARAM );
>  int32 float64_to_int32_round_to_zero( float64 STATUS_PARAM );
> -- 
> 1.7.3.4
> 
> 
>

Am 07.03.2011 um 10:56 schrieb Aurelien Jarno:

> On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote:
>> AIX already didn't use our definition, so let's start ripping out  
>> this one:
>> As pointed out by Peter Maydell, int16 is currently int on most
>> supported platforms, so let's replace it with int_fast16_t,
>> allowing the system to use a wider type if appropriate.
>
> Do you have a rationale about the use of the fast version of the  
> types?
> As you said it allows the compiler to use a wider type if appropriate,
> and this usually doesn't play very well when shifts are involved,  
> which
> is the case of the softfloat code. Have you verified that each
> conversion is correct? On the other hand I really doubt it has a
> measurable impact on speed.
>
> I would really go for uint16_t for now. This might be changed to the  
> fast
> version in a second step if we are sure everything is correct, but  
> let's
> don't mix the two steps for now.

SoftFloat distinguishes between [s]bits* and [u]int*. Wherever exact- 
width semantics were needed, [s]bits* was used (or should have been)  
and this is converted in 03/10. It was Peter's demand [1] that we  
retain this distinction and it was my suggestion to then use  
[u]int_fast*_t, which provides such semantics for POSIX, since the  
colliding use of [u]int* and its accidental uses outside SoftFloat are  
what this series seeks to address. The difference is that with POSIX  
the semantics are system-defined whereas right now they are QEMU- 
defined.

Most of the series was crafted in a semi-automatic fashion, doing a  
search and reviewing each hit before replacing. If we drop the type  
distinction and use uint16_t for both bits16 and uint16 then we cannot  
easily do the second step you propose.

My and, I figured, Peter's intent was to do this conversion without  
changing semantics as far as possible. Softfloat-native turned out  
difficult in that aspect, since it followed the definitions of the  
header rather than the types used in the SoftFloat implementation.  
There, the conversions need more careful review of whether they  
wrongly rely on fixed-width semantics.

But seeing the persistent rate of softfloat bug fixes, I would ask to  
address the license issue sooner than later. Doesn't need to be my  
patch, if someone feels tempted to do better.

Andreas

[1] http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg01552.html

On 7 March 2011 09:56, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote:
>> AIX already didn't use our definition, so let's start ripping out this one:
>> As pointed out by Peter Maydell, int16 is currently int on most
>> supported platforms, so let's replace it with int_fast16_t,
>> allowing the system to use a wider type if appropriate.
>
> Do you have a rationale about the use of the fast version of the types?
> As you said it allows the compiler to use a wider type if appropriate,
> and this usually doesn't play very well when shifts are involved, which
> is the case of the softfloat code. Have you verified that each
> conversion is correct? On the other hand I really doubt it has a
> measurable impact on speed.
>
> I would really go for uint16_t for now. This might be changed to the fast
> version in a second step if we are sure everything is correct, but let's
> don't mix the two steps for now.

As Andreas says, the code as it is at the moment makes the "wider
is OK" vs "exact width only" distinction, it just isn't using the
standard typenames to do it. So changing "int16" to "int16_t" would
be the change of semantics (both in theory and in practice, since at
the moment "int16" is int).

-- PMM

On Tue, Mar 08, 2011 at 12:02:39AM +0100, Andreas Färber wrote:
> Am 07.03.2011 um 10:56 schrieb Aurelien Jarno:
> 
> >On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote:
> >>AIX already didn't use our definition, so let's start ripping
> >>out this one:
> >>As pointed out by Peter Maydell, int16 is currently int on most
> >>supported platforms, so let's replace it with int_fast16_t,
> >>allowing the system to use a wider type if appropriate.
> >
> >Do you have a rationale about the use of the fast version of the
> >types?
> >As you said it allows the compiler to use a wider type if appropriate,
> >and this usually doesn't play very well when shifts are involved,
> >which
> >is the case of the softfloat code. Have you verified that each
> >conversion is correct? On the other hand I really doubt it has a
> >measurable impact on speed.
> >
> >I would really go for uint16_t for now. This might be changed to
> >the fast
> >version in a second step if we are sure everything is correct, but
> >let's
> >don't mix the two steps for now.
> 
> SoftFloat distinguishes between [s]bits* and [u]int*. Wherever
> exact-width semantics were needed, [s]bits* was used (or should have
> been) and this is converted in 03/10. It was Peter's demand [1] that
> we retain this distinction and it was my suggestion to then use
> [u]int_fast*_t, which provides such semantics for POSIX, since the
> colliding use of [u]int* and its accidental uses outside SoftFloat
> are what this series seeks to address. The difference is that with
> POSIX the semantics are system-defined whereas right now they are
> QEMU-defined.

The patch actually changes the semantic. Before int, ie 32 bit was used
for int16. With your changes it can now be 16, 32 or 64 bit depending on
the host. This is the kind of changes we don't want, it means problems
are going to depend on the host for no real reason.

This is actually what you observed later in the series: there are types
mismatch in your patches, though they match on your machine (probably
32-bit), but not on mine.

> Most of the series was crafted in a semi-automatic fashion, doing a
> search and reviewing each hit before replacing. If we drop the type
> distinction and use uint16_t for both bits16 and uint16 then we
> cannot easily do the second step you propose.
> 
> My and, I figured, Peter's intent was to do this conversion without
> changing semantics as far as possible. Softfloat-native turned out
> difficult in that aspect, since it followed the definitions of the
> header rather than the types used in the SoftFloat implementation.
> There, the conversions need more careful review of whether they
> wrongly rely on fixed-width semantics.
> 
> But seeing the persistent rate of softfloat bug fixes, I would ask
> to address the license issue sooner than later. Doesn't need to be
> my patch, if someone feels tempted to do better.
> 

I agree it is something that should be fixed, however given we are
modifying this file for more than 5 years, a few days more or less won't
change anything.

On Mon, Mar 07, 2011 at 11:14:11PM +0000, Peter Maydell wrote:
> On 7 March 2011 09:56, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote:
> >> AIX already didn't use our definition, so let's start ripping out this one:
> >> As pointed out by Peter Maydell, int16 is currently int on most
> >> supported platforms, so let's replace it with int_fast16_t,
> >> allowing the system to use a wider type if appropriate.
> >
> > Do you have a rationale about the use of the fast version of the types?
> > As you said it allows the compiler to use a wider type if appropriate,
> > and this usually doesn't play very well when shifts are involved, which
> > is the case of the softfloat code. Have you verified that each
> > conversion is correct? On the other hand I really doubt it has a
> > measurable impact on speed.
> >
> > I would really go for uint16_t for now. This might be changed to the fast
> > version in a second step if we are sure everything is correct, but let's
> > don't mix the two steps for now.
> 
> As Andreas says, the code as it is at the moment makes the "wider
> is OK" vs "exact width only" distinction, it just isn't using the
> standard typenames to do it. So changing "int16" to "int16_t" would
> be the change of semantics (both in theory and in practice, since at
> the moment "int16" is int).
> 

I understand your point, but OTOH int_fast16_t means at least int16_t so
in practice it doesn't bring anything more than changing to int16_t,
except more pain as the size actually depends on the host.

If we want to change the int here, we should either use int32_t here 
(which matches the size of int), or just look case by case and use the
correct type.

On 7 March 2011 23:37, Aurelien Jarno <aurelien@aurel32.net> wrote:
> I understand your point, but OTOH int_fast16_t means at least int16_t so
> in practice it doesn't bring anything more than changing to int16_t,
> except more pain as the size actually depends on the host.

But at the moment we implement int16 as int, so (a) we'd be telling
the compiler it needed to use a type that was (fractionally) less
efficient and (b) we already know that the code can cope with the
type being wider than 16 bits, because that's how we're compiling
the code today. The thing we should be worrying about is that maybe
there's code that accidentally requires more than 16 bits in an
int16 which would break if you defined it as an int16_t...

> If we want to change the int here, we should either use int32_t here
> (which matches the size of int), or just look case by case and use the
> correct type.

Correct choice between 'bits16' and 'uint16' is actually one of
the areas where I pretty much trust the original softfloat code:
I think it's definitely a retrograde step to throw that away,
and personally I would NAK any patch which merges the two together
into a single typename.

Maybe we should have a patchset that does the uncontroversial
change (bits32->uint32_t &c, which I think should be purely
mechanical) while we argue about this bit?

-- PMM

On Tue, Mar 08, 2011 at 08:29:50AM +0000, Peter Maydell wrote:
> On 7 March 2011 23:37, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > I understand your point, but OTOH int_fast16_t means at least int16_t so
> > in practice it doesn't bring anything more than changing to int16_t,
> > except more pain as the size actually depends on the host.
> 
> But at the moment we implement int16 as int, so (a) we'd be telling
> the compiler it needed to use a type that was (fractionally) less
> efficient and (b) we already know that the code can cope with the
> type being wider than 16 bits, because that's how we're compiling
> the code today. The thing we should be worrying about is that maybe
> there's code that accidentally requires more than 16 bits in an
> int16 which would break if you defined it as an int16_t...

And it might also break with int_fast16_t as it only guarantees int16_t
at the minimum. So using int_fast16_t doesn't bring more safety than
int16_t here.

Also currently we define int16 as int, so it has the same size
everywhere. int_fast16_t size is varying depending on the host.

> 
> > If we want to change the int here, we should either use int32_t here
> > (which matches the size of int), or just look case by case and use the
> > correct type.
> 
> Correct choice between 'bits16' and 'uint16' is actually one of
> the areas where I pretty much trust the original softfloat code:
> I think it's definitely a retrograde step to throw that away,
> and personally I would NAK any patch which merges the two together
> into a single typename.

On most systems uint_fastxx_t types is defined in the preprocessor, so
the compiler can't really exploit this. We are in 2010 and compilers are
able to compile code using 16-, 32- or 64-bit ops for an uint16_t if 
it's faster on this architecture, while guaranteeing that the result 
would be the same than an uint16_t. By using uint_fast16_t we simply
force the compiler to use a 64-bit op on a 64-bit machine, even if it
has only have 16-bits to handle. Also a lot of functions in softfloat
are static or inline functions, so the compiler can do a lot of 
optimizations if the type is not overestimated.

In any case, I would NAK any patch that are using different size
depending on the host, as it is a real nightmare to handle, and there is
no real point to do that. Andreas has shown we can have code that compiles 
on 32-bit, but not on 64-bit. That's the best case, we can also have 
different results on 32-bit than 64-bit, and it's a lot more difficult to
detect.

Am 08.03.2011 um 09:29 schrieb Peter Maydell:

> Maybe we should have a patchset that does the uncontroversial
> change (bits32->uint32_t &c, which I think should be purely
> mechanical) while we argue about this bit?

That should be patch 03 (or 02-03). :)

Andreas

On Tue, Mar 08, 2011 at 07:54:39PM +0100, Andreas Färber wrote:
> Am 08.03.2011 um 09:29 schrieb Peter Maydell:
> 
> >Maybe we should have a patchset that does the uncontroversial
> >change (bits32->uint32_t &c, which I think should be purely
> >mechanical) while we argue about this bit?
> 
> That should be patch 03 (or 02-03). :)
> 

I have just applied patches 01 to 03.