RE: [PATCH] Add XPA ASE and MIPS R5 microMIPS support

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> Andrew Bennett <Andrew.Bennett@imgtec.com> writes:
> > +{"mfhc0",		"t,G",		0x000000f4, 0xfc00ffff,
> 	WR_1|RD_C0,		0,		0,		XPA,	0 },
> > +{"mfhc0",		"t,G,H",	0x000000f4, 0xfc00c7ff,	WR_1|RD_C0,
> 		0,		0,		XPA,	0 },
> > +{"mfhgc0",		"t,G",		0x000004f4, 0xfc00ffff,
> 	WR_1|RD_C0,		0,		0,		IVIRT|XPA,	0 },
> > +{"mfhgc0",		"t,G,H",	0x000004f4, 0xfc00c7ff,	WR_1|RD_C0,
> 		0,		0,		IVIRT|XPA,	0 },
> 
> Genuine question: is this really "IVIRT or XPA" or "IVIRT and XPA"?
> Would be good to have virt in the test if it's relevant.

I believe this is an 'and' which is the same issue as we already have
in the mips-opc implementation of these instructions. I can't remember
exactly how the ASE field works but I guess deriving another bit for
the combined IVIRT+XPA won't actually be that hard.

> Looks good otherwise.  Until now it's been safe to use the r2 flag for
> r3 and r5, since no instructions have been conditional on r3 or r5
> alone.
> This patch is the first to add a true r5 (microMIPS) instruction.
> 
> Is the idea that we'll just rely on .mips.abiflags to enforce r5ness
> from now on?

From my perspective yes but I am generally not in favour of tracking
R2->R5 differences too closely I think it will cause more problems
for users than benefit. The new instruction (eretnc) is a priv-mode
instruction so the impact it can realistically have on binary
compatibility is minimal.

There is already logic in the ABI flags/eflags code to understand that
the E_MIPS_ARCH_32R2 is actually representative of R2,R3,R5. To the
extent that it may be worth codifying that by renaming the flag name.
The same applies to R6 as well; E_MIPS_ARCH_32R6 is likely to mean R6
and any later compatible architecture. Perhaps the EF bits are best
left reserved for any future generational changes to MIPS? (not that
I really expect there to be any.)

> Even though that's more flexible long-term, maybe it
> would make sense to have an r5 EF_* anyway, so that there's no gap
> between R2 and R6 (which both have flags).

I'm not sure if there was massive benefit in the end to having R6
defined with an EF_* but it ended up having one anyway. I guess it
made the compatibility check for R<6 and R>=6 easier as it is just a
flags test.

Do you (or anyone else) have a strong opinion on this or are you just
probing to see if it was considered?

Thanks,
Matthew

> 
> Thanks,
> Richard