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, David Daney wrote:

> >   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).

 Well, I have seen rev. 5 mentioned recently, but I have yet to see actual 
architecture documentation.  So for FSF projects such as binutils that 
rely on (require) public documentation rev. 3 is the most recent.

> 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.

 Yes, of course, all the usual infrastructure implied.

> It would be nice to give floating point instructions the same treatment..

 I'm not sure what you mean -- paired-single support?  I think this is the 
only optional part of the FPU instruction set that we have not subsetted 
correctly -- the MIPS V ISA has never been implemented by itself and its 
added instruction set became optional with the MIPS64r1/MIPS32r2 ISA.  
Then we've got the MIPS-3D ASE instructions correctly covered and the 
remaining FPU instructions are tied to the respective ISAs they have been 
introduced with.  Have I missed anything?


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