Implementing TI mode (128-bit) and the 2nd pipeline for the MIPS R5900

[Woon yung Liu <ysai187 at yahoo dot com>]

Hi,

I am attempting to complete support for the MIPS R5900.

I would like to ask for advice regarding implementing support for TI mode and the second integer multiplication/division pipeline. I don't have much experience with the MIPS ABIs and so on, so I would like input from the GCC folks on how things are generally done around here.
I apologize in advance, if my explanations are not sufficiently clear or if I am using the wrong terms.

Regarding TI mode, the R5900 has 128-bit GPRs and proprietary instructions (MMI) for supporting 128-bit data types, but is currently described as a 64-bit target within GCC. This means that any data types larger than DI mode (64-bit) will be split across multiple registers.
The 128-bit MMI is mostly for working with vectors (from 4x32 bit to 16x8 bit).

In my current attempt at adding support for the TI mode, the MMI definitions are added into a MD file for the R5900 and some functions (i.e. mips_output_move) were modified to allow certain moves for the TI mode of the R5900 target. However, while it seems like TI-mode integers can now be passed between functions and used with the MMI (within one 128-bit GPR), GCC still treats 128-bit moves as complex moves (split across two 64-bit registers); its built-in functions expect both $a0 and $a1 to be used if the first argument is a 128-bit value. To return a 128-bit value, both $v0 and $v1 are used.

This means that the existing built-in functions will not work properly with the new MMI instructions and with the user-code that GCC generates (i.e. MMI-aware code will use only $a0 and ignore $a1, while existing code will expect both to contain the halves of the TI-mode integer).

Is there a recommended way to implement support for such an unconventional architecture, in GCC? I doubt that my patch would be accepted, if I were to work around this by simply implementing TI-mode versions of every function within mips.md.


Otherwise, I believe that there are two solutions to the problem with the calling convention (but again, I have no idea which is better):
1. Keep the target as 64-bit. Support for MMI will be either compromised (i.e. made to assemble and split the 128-bit vectors upon entry/exit) or totally omitted. Perhaps omission would be best so that there will never be a compromise in performance.

2. Promote the word size of the R5900 to 128-bit. I think that SONY might have done this, as the code from their late games used lq/sq (quard-word load/store) to preserve registers. However, I think that this goes against the existing ABIs, doesn't it? Plus the MMI instruction set is proprietary and isn't used in any other MIPS.

Regarding support for the 2nd integer multiplication/division pipeline, I have added the hi1/lo1 registers (and added constraints for them) and they were mde as new alternatives for existing instructions that target the R5900. The hi1/lo1 registers are for the 2nd integer multiplication/division pipeline.

Would my design be likely acceptable? No other MIPS has the hi1/lo1 registers.

If I carry on with my current design, I suppose that I need to make it so that the hi1/lo1 registers are never used for other MIPS targets. I didn't find a RTL constraint that meant something like "nothing", so I made the new constraints define MD1_REGS (hi1/lo1) as their MD_REGS (hi/lo) equivalents if the target is not the R5900 (much like the DSP ACC register constraint, ka). But unlike the DSP ACC register constraint (ka), my constraints are used as alternatives alongside whatever (i.e. x for hi/lo or ka for hi/lo/acc) that was originally there. Would this be acceptable, given that there will be two similar alternatives for some instructions when the target is not the R5900?


Thank you for your attention, and have a nice day
-W Y