This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] MIPS EVA ASE Support
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: David Daney <ddaney dot cavm at gmail 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: Wed, 12 Jun 2013 00:08:45 +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> <87li6hj9v5 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
On Tue, 11 Jun 2013, Richard Sandiford wrote:
> > 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.
FWIW EVA is not officially classified as an ASE either, just an optional
feature of the base architecture (I guess it's not application-specific or
something). However I don't think we need to pay much attention to that
peculiarity in the internals (although we probably want in any
documentation added); if we really cared we could opt for calling the flag
OPT_EVA rather than ASE_EVA, but then we'd have an extra namespace burden
-- to make sure we don't take OPT_* for something else elsewhere (and also
the use of a more common OPT prefix would rise a likelihood of a clash
with another target).
> 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.
FWIW I share this opinion.