This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] MIPS EVA ASE Support
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: David Daney <ddaney dot cavm at gmail dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, "Pinski\, Andrew" <Andrew dot Pinski at caviumnetworks dot com>, "Moore\, Catherine" <Catherine_Moore at mentor dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 11 Jun 2013 10:05:18 +0100
- Subject: Re: [PATCH] MIPS EVA ASE Support
- References: <FD3DCEAC5B03E9408544A1E416F11242F8FC6EE7 at NA-MBX-01 dot mgc dot mentorg dot com> <87fvwz9hsg dot fsf at talisman dot default> <FD3DCEAC5B03E9408544A1E416F11242F8FC9639 at NA-MBX-01 dot mgc dot mentorg dot com> <87bo7g99yn dot fsf at talisman dot default> <FD3DCEAC5B03E9408544A1E416F11242F8FC9A3B at NA-MBX-01 dot mgc dot mentorg dot com> <87ip1l7oz9 dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1306102316550 dot 16287 at tp dot orcam dot me dot uk> <51B65EA9 dot 7000300 at gmail dot com>
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