[PATCH] Basic support for MIPS r5900

["Jürgen Urban"]

Hello Richard,

> Thanks, looks good.  The comments I have are only minor and seemed easier
> to spell out as a revised patch, attached below.  The changes are:
>
> * removing the config.sub bit, which looked redundant.  We already have
>   the up-to-date upstream config.sub.
>
> * removing the target_cpu_default setting.  I realise this was taken
>   from mips64-elf, but it was redundant here, there, and elsewhere.
>   I've just committed a patch to remove the existing cases.
>
> * removing the TUNE_5900 definition.  I prefer not to define these
>   kinds of macro until they're used.
>
> * removing the ISA_HAS_LDC1_SDC1 setting.  I realise what you did
>   describes the reality of the processor, but the problem is that
>   the patch doesn't provide an alternative for 64-bit loads and
>   stores when -mfp64 is used.  That combination also isn't rejected,
>   so we're likely to get an internal compiler error instead.
>
>   This change shouldn't affect the soft-float case you describe.
>   It also shouldn't be important for the single-float code.
>
> * tweaking the mips_reorg_process_insns comment slightly
>
> * fixing a few minor formatting issues
>
> Does this version look OK to you?  I'll commit it if so.

This is OK and the generated code is still working on the PS2 in my test run.

> > How much other changes will be currently accepted here? There is other
> > stuff which I want to prepare and submit here, e.g.:
> > 1. disable use of dmult and ddiv (ABI n32).
> > 2. use trunc.w.s instead of cvt.w.s (to get single float working for
> > normal range calculations; i.e. calculating without inf or nan).
> > 3. fix use of ll/sc in libgomp, either increase mips ISA level or use
> > syscall (which is broken in Linux 2.6.35.4).
> > 4. fix libgcc to build a real muldi3 function for ABI n32 (not the
> > multi3 function which is stored in muldi3.o file).
> > 5. add support for configure parameters --float=single and
> > --float=double in addition to --float=soft and --float=hard.
> > 6. rework floating point to support single float with ABI n32 (either
> > break the ABI or store floating point values in general purpose
> > registers like soft float).
> > 7. change libgcc or mips.md in way so that the non IEEE 754 compatible
> > FPU of the r5900 gets compatible.
>
> Well, I'm afraid that's hard to say in advance.  It really depends
> on what the changes look like.  (1) and (2) sound harmless enough,
> although (1) should probably only be done in conjunction with (4).
> I'm not sure what (3) involves.  (5) sounds like a good idea.
> (6) is worth doing, but anything ABI-related gets extra-paranoid
> treatment. :-)
>
> I'm not sure about (7) though.  I'd imagine trying to get true IEEE
> conformance out of the R5900 FPU would be pretty difficult and carry
> quite a bit of runtime overhead, especially with the subnormal handling.
> Is it really worth it?  Do you have any particular use cases in mind?

My target was to get existing C programs working (e.g. all mipsel programs from Debian 5 or 6, all mips64el programs from Fedora 12 or 13). The programs should work like programs on normal mipsel or mips64el Linux. I don't know what in the different programs is used.

> FWIW, the Cygnus/Red Hat version of the port just stuck with the R5900
> behaviour and made GCC understand it (MODE_HAS_* & various other bits).
> This code was then updated and extended for the SPU.  I'd have expected
> the support to be in reasonably good shape because of the SPU.

I assume that you mean the cell processor of the PS3 and not the Sound Processing Unit of the PS2.
The macros MODE_HAS_* in the GCC look promising.

Best regards
Jürgen