This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MIPS EVA ASE Support


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]