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

Woon yung Liu ysai187@yahoo.com
Tue Jan 19 16:15:00 GMT 2016


> I'm generally against modified calling conventions especially given the

> number of them that MIPS already has. We opted against using new wider

> registers for arguments/returns in MSA instead choosing to consider it

> as an optimised convention rather than the standard.

> 
> What environment are you looking to support this in? Linux, bare metal,

> BSD, other? There's a reasonable amount of housekeeping to consider for

> context switching and debug depending on the environment.


It'll be for the Emotion Engine (EE) of the PlayStation 2, so you could say that it's for a bare metal target.

There is also an ongoing effort to build Linux on it, but that isn't my project.
Its maintainer is Jürgen Urban, the one who previously contributed the patches for the R5900.

> On the topic of TImode... Do you ever truly end up with TImode data with

> the R5900 extensions or is it all vector types? We initially had TImode
> in various places for MSA and removed it all in favour of the vector
> modes which made everything a lot cleaner. If there truly is TImode
> support then things get a little ugly based on what I remember from
> untangling MSA from TImode mainly because of the interaction with
> multiplies.


Given that most of the MMI seemed to be for multimedia (i.e. maxtrix manipulation), I think that it is mostly for vector types.
There are also some generic logic instructions (i.e. por, pxor, pand) for supporting 128-bit data types, which aren't explicitly documented to be for matrixes (there's no mention of sub-words in the 128-bit GPR).


The only time (that I am aware of) when there will be actual TI mode (non-vector) data, would be when the GIF (Graphics Synthesizer interface) DMA tags are generated (each word is 128 bits). Or if data is to be moved quickly to/from RAM.
> As above I suggest this approach but allow vectors to be passed using
> the pre-existing defacto convention and look at optimizing it later.


Okay. Thanks for your input.
I think that this would be the safest anyway.



More information about the Gcc mailing list