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
