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: [PATCH] MIPS SIMD Architecture (MSA) patch

On Tue, 8 Oct 2013, Chao-Ying Fu wrote:

> >  Do you plan to release microMIPS instruction encoding 
> > documentation as 
> > well?
>   We will need probably two weeks to revise and publish the microMIPS MSA spec
> to the imgtec website.  Please wait.


> >  Is the use of MSA and FP operations in a single binary mutually 
> > exclusive?  If so, then you need to check for conflicting 
> > use.  If not, 
> > then you need to use a separate variable/struct member to 
> > remember and 
> > report the first significant MSA BFD; abi_msa_bfd seems the 
> > likely name 
> > candidate.
>   MSA and FP instructions can co-exist in a single binary.
> Or, only MSA instructions exist in a single binary, theoretically.
> Ex: We only use the integer SIMD instructions, and move data
> between MSA registers and integer registers.
> I want to keep the FP gnu attribute code as-is, and don't check
> if the MSA gnu attribute may conflict with the FP gnu attribute.
> My intention is that the only usage of MSA gnu attribute is to tell if this
> binary uses 128-bit MSA.

 OK, so you do need that separate abi_msa_bfd variable/struct member to 
keep the two sets of attributes separate.  The reason is the first BFD 
that sets the FP attribute may not be the same one that sets the MSA 

> >  Also I've noticed the MSA module adds new branch 
> > instructions -- have you 
> > wired them into our branch relaxation support (GAS's --relax-branch 
> > option) -- if it's at all possible?  Assuming that it is, 
> > then it's OK, at 
> > least initially, as far as I am concerned, if you did not, 
> > but either way 
> > please add some test coverage, following either relax.? or 
> > relax-bc1any.? 
> > from gas/testsuite/gas/mips/ as applicable.
>   I haven't added branch relaxation support.  I think all possible MSA branches are there,
> so it should be ok to support branch relaxation.  Need to work on it.

 Great! -- if you can do it shortly, then I think it would be a wasted 
effort to make a test case to cover the current semantics and providing a 
test case with a follow-up patch will be fine.  If you think however, that 
you may not be able to implement branch relaxation soon, then please cook 
up a quick test case to have current code covered.


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