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]

Re: [MIPS] Add saa and saad instructions for octeon

On Wed, 16 Nov 2011, Richard Sandiford wrote:

> >  Why don't you use an octeonp@ override instead just like some other tests
> > do?  You can trivially refer to an octeon@ dump; see some r3000@ files for
> > examples.
> Trivially, but somewhat tediously.  In practice, it's more likely that
> octeon@ dumps will apply to octeon+ too, so I think a hierachy of
> overrides makes sense.  In the unlikely event that only octeon (but not
> octeon+) needs to differ from the default, then we can use octeon+@
> redirects then.  Which would be good, because it makes the unusual
> case more explicit.
> So I think the mips.exp part of the patch is OK.  We can generalise
> it later, e.g. for the r3000 cases you mentioned.

 OK, agreed.  I think we need a more systematic way of expressing this to 
cover cases where the distribution of variations makes the number of 
overrides merely referring to another dump unreasonably large.  Aside from 
r3000 (which is trivial and aliases to mips1 -- you even suggested we 
might remove it altogether the other day) that would cover cases like the 
legacy ISAs (MIPS I-V) requiring one dump and all the new ISAs (MIPS32+) 

 And actually your observation might be the correct hint not only for 
octeon, but overall as well.  An override would apply from the 
architecture specified up.  Now it just needs to be cleverly coded to 
avoid unnecessary filesystem accesses. :)  Not a big hassle, probably.  
Occasional references to another dump may still be necessary though.


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