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

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

Hi Richard,

Thank you for your input!


>[ Apologies for assumptions being made here, since I can't find an instruction 

> set reference for the r5900 anymore.  ]


Publicly-available information on it is so scarce, that I don't think that you (or anyone) should have to feel bad about this.
If not for the PS2SDK leaks (and perhaps PS2Linux, which not everyone could get), I doubt that there would have been any instruction set reference at all!

> You probably don't want to be using TImode for MMI support anyway, since, in 
> the broader context this instruction set extension is about SIMD.
>

> Thus e.g. V16QImode and V8HImode might be more appropriate.

You're right, thanks. After giving it some thought, I realized that TI mode support is impossible because:
1. there is a lack of basic arithmetic operations (no addition, subtraction, multiplication and division) to support TI mode fully.

2. the MIPS backend seems to assume that all arithmetic operations are supported for all available modes, so having missing operations is a no-no.

3. due to the current register size (UNITS_PER_WORD) definition, allocating a TI mode register will cause two consecutive registers to be allocated instead (like the HILO pseudo register) of one (other than just being wrong, it is probably wasteful).


Due to number 3, that also means that I cannot actually properly implement support for any vector mode because they're all 128-bit vectors. :(
If I was to simply ignore the upper 64 bits, then implementing the MMI instruction set would be less meaningful because it wouldn't be helpful for making PlayStation 2 games; the 128-bit vectors can be used in 3D vector calculation, which is eventually fed directly to the GS (the graphics chip) via DMA for drawing.

Do you know if there is a solution to this problem?

The LQ/SQ instructions, if not used with the other MMI instructions, could also be used to speed up memory copying. But they operate on the full 128-bit GPRs, and are hence unusable without a 128-bit mode.


I understand that this is simply a problem of trying to implement something that isn't supported by any other MIPS target, so it isn't going to be surprising to me if there isn't way to get this done.

> You can't.  For a given set of inputs, one must provide all of the valid ways > that one can perform the operation as alternatives.


Thank you for clarifying this.