[PATCH v3 2/2] MIPS: Sync oprand char usage between mips and micromips

[Maciej W. Rozycki]

On Fri, 16 Jun 2023, YunQiang Su wrote:

> We should try our best to make mips32 using the same oprand char with
> micromips. So for mips32, we use:

 This patch groups several unrelated changes together, which should have 
been submitted as individual self-contained patches.  Beyond the value of 
consistency itself it would enable them to be reviewed individually and in 
principle let ones that were good be accepted right away without the need 
to disentangle them from the problematic ones.  It also helps backporting 
downstream where you can then cherry-pick whole individual patches, rather 
than having to extract pieces of larger combined changes.

>   ^  is added for 5bit sa oprand for some new DSPr2 instructions:
> 	APPEND, PREPEND, PRECR_SRA[_R].PH.W
> 	the LSB bit is 11, like RD.

 This change is not needed, we only ever synchronise operand codes between 
regular MIPS and microMIPS instructions where there is a shared purpose 
and no existing operand code to fit at least with one of the ISAs.

>   +t is removed for coprocessor 0 destination register.
> 	'E' does the samething.

 I have committed this part as a change on its own.  Thank you for your 
contribution.

>   +t is now used for RX oprand for MFTR/MTTR (MT ASE)

 See the note below on CFC2/MFC2/etc.

>   ?  is added for sel oprand for MFTR/MTTR (MT ASE)
> 	For mips32, the position of sel in MFTR/MTTR is same with mfc0 etc,
> 	while for micromips, they are different.

 Same situation as with "^" above.

> We also add an extesion format of cftc2/cttc2/mftc2/mfthc2/mttc2/mtthc2:
> 	concatenating rs with rx as the index of control or data.

 This change cannot be considered right now, because we have no semantics 
defined for the corresponding direct rather than thread context accesses, 
i.e. CFC2/MFC2/etc., which makes it pointless to add these MT encodings 
only.  If we ever have direct accesses defined, then the expansion of the 
COP2 register space in assembly/disassembly syntax will need to be applied 
as a single self-contained change across all the instructions affected.

 Note that there is an issue of operand interpretation here because of the 
assembly syntax referring to the top of the COP2 register space for legacy 
reasons, and the different span of the space (number of bits assigned in 
the instruction encoding) between the base architecture and the MT ASE.

 Is there an actual use case for this feature at this point?  This might 
help determine how to proceed.

  Maciej