This is the mail archive of the 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]


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.


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