[PATCH] MIPS EVA ASE Support
Richard Sandiford
rdsandiford@googlemail.com
Tue Jun 11 09:05:00 GMT 2013
David Daney <ddaney.cavm@gmail.com> writes:
> On 06/10/2013 04:00 PM, Maciej W. Rozycki wrote:
>> On Mon, 10 Jun 2013, Richard Sandiford wrote:
>>
>>>> +{"tlbinv", "", 0x0000437c, 0xffffffff, INSN_TLB, 0, I1 },
>>>> +{"tlbinvf", "", 0x0000537c, 0xffffffff, INSN_TLB, 0, I1 },
>>>
>>> Is the idea really to allow these for general microMIPS, even when EVA
>>> isn't selected? There should be a test for it so, and a comment here
>>> saying why.
>>
>> These instructions are not a part of the EVA set. They are optional,
>> their presence wired to the CP0.Config4.IE field and required for certain
>> MMU configurations. OTOH the presence of the EVA instruction set is wired
>> to the CP0.Config5.EVA bit and associated with segmentation control. My
>> understanding of the architecture manual is all systems that support the
>> EVA feature must also support TLB maintenance via the TLBINV/F
>> instructions, but not necessarily the other way round.
>>
>> So overall I think we want to have another knob, perhaps just -mtlbinv
>> (name to be agreed upon), to control these instructions in addition to
>> -meva rather than to enable them for from what would have to be
>> -mips32r3/-mips64r3 (yes, we're at rev. 3 already in case someone missed
>> it ;) ). I don't think we've had a precedent where optional instructions
>> are enabled unconditionally for a sufficiently high ISA level to possibly
>> support them.
>
> Rev. 5 is the most recent as far as I can tell (rev. 4 was skipped).
>
> There do seem to be a bunch of orthogonal features appearing in the ISA
> identified by CP0.ConfigX bits. I think the idea of adding -mtlbinv is
> a good one.
>
> I guess -mtlbinv would also be implied as part of the various
> -mcpu=xxxx options. I think you also need to be able to control it via
> ".set tlbinv" in the source code too.
Agreed. As far as the assembler interface and internals go, it should
be just like another ASE -- and use the new ASE opcodes field -- even
though it isn't officially classified as an ASE.
But if EVA requires these instructions, -meva should be enough on its own,
so I don't think we need to implement -mtlbinv first. It should be OK to add:
#define TLBINV ASE_EVA
to the opcode definition files and use "0, TLBINV" rather than "I1" or "I33".
Then, if -mtlbinv is added, ASE_TLBINV can be ORed into the #define.
Thanks,
Richard
More information about the Binutils
mailing list