On 7 February 2011 17:00, Christophe Lyon <christophe.l...@st.com> wrote:
>
> Some CPUs have a status flag imposing to return floatxx_default_nan
> whatever the input value, when converting from one FP format to
> another. Implement this, using the already existing default_nan_mode
> status flag (currently used on ARM and SH4 at the moment).
>
> Signed-off-by: Christophe Lyon <christophe.l...@st.com>
Your subject is a bit long, which can make it wrap annoyingly in git logs.
I'd suggest something like:
===begin===
softfloat: Honour default_nan_mode for float-to-float conversions
Honour the default_nan_mode flag when doing conversions between
different floating point formats, as well as when returning a NaN from
a two-operand floating point function. This corrects the behaviour
of float<->double conversions on both ARM and SH4.
===endit===
> +/*----------------------------------------------------------------------------
> +| The pattern for a default generated haft-precision NaN.
> +*----------------------------------------------------------------------------*/
"half-precision".
> @@ -2767,11 +2767,7 @@ bits16 float32_to_float16( float32 a, flag ieee
> STATUS_PARAM)
> aExp = extractFloat32Exp( a );
> aSign = extractFloat32Sign( a );
> if ( aExp == 0xFF ) {
> - if (aSig) {
> - /* Make sure correct exceptions are raised. */
> - float32ToCommonNaN(a STATUS_VAR);
> - aSig |= 0x00400000;
> - }
> + if ( aSig ) return commonNaNToFloat16( float32ToCommonNaN( a
> STATUS_VAR ) STATUS_VAR );
> return packFloat16(aSign, 0x1f, aSig >> 13);
> }
> if (aExp == 0 && aSign == 0) {
This is float32_to_float16() but it looks like you've missed
float16_to_float32() ?
Otherwise, looks good, and I can confirm that it fixes
behaviour of VCVT.F32.F64 and VCVT.F64.F32 when
the FPSCR.DN bit is set.
-- PMM
