Re: [PATCH] FPU IEEE 754 for MIPS r5900

[Richard Sandiford <rdsandiford at googlemail dot com>]

"JÃrgen Urban" <JuergenUrban@gmx.de> writes:
> I used the SPU code in GCC as example for creating an
> r5900_single_format structure. The patch is attached to the e-mail. I
> want to submit this patch.

Thanks.  Are there any real differences though?  E.g. in your version
you set has_sign_dependent_rounding, but that's not necessary when the
only rounding mode is towards zero.  has_sign_dependent_rounding says
whether rounding X vs. -X can give numbers of different magnitude.
(It was actually because of r5900 that this distinction was added.)

I'm also not sure it makes sense to choose a different NaN encoding
when NaNs aren't supported anyway.

It would be good if we could reuse spu_single_format directly.

> To be able to use it, you need to use mipsr5900el and
> "--with-float=single". "--with-float=hard" results in double float
> because of MIPS ISA III.

This isn't quite right as-is.  The code that applies the --with-float
setting is:

#define OPTION_DEFAULT_SPECS \
  ... \
  {"float", "%{!msoft-float:%{!mhard-float:-m%(VALUE)-float}}" }, \

in mips.h.  So -mdouble-float wouldn't override --with-float=single, etc.

single vs. double has traditionally been a separate choice from hard
vs. soft (which is a bit unfortunate given that single vs. double makes
no sense for soft float).  Maybe we should have --with-fpu=single and
--with-fpu=double instead.

> I didn't changed the default in config.gcc. It is still soft float,
> because floating point doesn't behave as defined by IEEE 754. I don't
> see much improvement. This is the case on the PS2 and the PS3. For
> example inf minus inf should be NaN, but on both systems it is 0.
> I tested it on r5900 and the PS3 SPU. Both calculates the same result
> despite the MODE_HAS_* implementation. This means that there is a
> patch needed in the generic part (i.e. not mips) of the GCC.

But the format doesn't have an infinity representation, does it?
The IEEE infinity encoding is instead treated as a large number.
So it sounds like a bug if GCC is treating any (r5900|spu)_single_format
value as infinity to be begin with.

> @@ -989,7 +991,7 @@
>  /* True if trunc.w.s and trunc.w.d are real (not synthetic)
>     instructions.  Both require TARGET_HARD_FLOAT, and trunc.w.d
>     also requires TARGET_DOUBLE_FLOAT.  */
> -#define ISA_HAS_TRUNC_W		(!ISA_MIPS1)
> +#define ISA_HAS_TRUNC_W		(!ISA_MIPS1 || TARGET_MIPS5900)
>  
>  /* ISA includes the MIPS32r2 seb and seh instructions.  */
>  #define ISA_HAS_SEB_SEH		((ISA_MIPS32R2		\

This part shouldn't be necessary.  The ISA_* and TARGET_MIPS* macros are
kept in sync, so it can never be the case that ISA_MIPS1 && TARGET_MIPS5900.
(E.g. -mips1 -march=r5900 is rejected.)

Thanks,
Richard