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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> 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.

OK.

>> 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?

Just probing.  I was a bit afraid when r3 and r5 were added the way they
were (with r2 flags) that there'd be considerable resistance to adding
"proper" identification later, even in cases where that would be the
consistent thing to do.

I can believe a single priveleged instruction isn't interesting enough
to warrant new flags though.

Thanks,
Richard