From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8803 invoked by alias); 8 Oct 2013 18:20:30 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 8791 invoked by uid 89); 8 Oct 2013 18:20:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_JMF_BL,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: multi.imgtec.com Received: from multi.imgtec.com (HELO multi.imgtec.com) (194.200.65.239) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 08 Oct 2013 18:20:29 +0000 From: Chao-Ying Fu To: "'Maciej W. Rozycki'" CC: "binutils@sourceware.org" Subject: RE: [PATCH] MIPS SIMD Architecture (MSA) patch Date: Tue, 08 Oct 2013 18:20:00 -0000 Message-ID: <81D57523CB07B24881D63DE650C6ED8201903803@BADAG02.ba.imgtec.org> References: <81D57523CB07B24881D63DE650C6ED82019034B4@BADAG02.ba.imgtec.org> In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-Processed: 7_3_0_01192__2013_10_08_19_20_26 X-SW-Source: 2013-10/txt/msg00090.txt.bz2 Maciej W. Rozycki wrote: > Thanks for your contribution. Here are a few notes=20 > addressing some small=20 > issues I've noticed as I skimmed over your proposal; please do not=20 > consider them though to be a full review that Richard will=20 > undoubtedly be=20 > happy to follow with. >=20 > > We would like to contribute a patch to support MIPS SIMD=20 > Architectures (MSA). > > The MSA spec (version 1.07) can be found from=20 > http://www.imgtec.com/mips/mips-simd.asp. >=20 > Do you plan to release microMIPS instruction encoding=20 > documentation as=20 > well? We will need probably two weeks to revise and publish the microMIPS MSA s= pec to the imgtec website. Please wait. =20=20 > Is the use of MSA and FP operations in a single binary mutually=20 > exclusive? If so, then you need to check for conflicting=20 > use. If not,=20 > then you need to use a separate variable/struct member to=20 > remember and=20 > report the first significant MSA BFD; abi_msa_bfd seems the=20 > likely name=20 > 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. > -- etc. I suggest that you match the dot in instruction mnemonics=20 > literally, i.e.: >=20 > +[0-9a-f]+ <[^>]*> 5802 081a sll\.b \$w0,\$w1,\$w2 > +[0-9a-f]+ <[^>]*> 5825 20da sll\.h \$w3,\$w4,\$w5 >=20 > and likewise throughout the remaining test cases. I haven't=20 > checked if we=20 > have any other mnemonics that could match your original=20 > wildcard patterns,=20 > but I think it won't hurt to be strict here. Yes. I will update my tests. >=20 > > Index: opcodes/mips-dis.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /cvs/src/src/opcodes/mips-dis.c,v > > retrieving revision 1.116 > > diff -u -p -r1.116 mips-dis.c > > --- opcodes/mips-dis.c 19 Aug 2013 18:56:59 -0000 1.116 > > +++ opcodes/mips-dis.c 8 Oct 2013 00:30:27 -0000 > > @@ -738,10 +747,22 @@ parse_mips_dis_option (const char *optio > [...] > > if (CONST_STRNEQ (option, "virt")) > > { > > mips_ase |=3D ASE_VIRT; > > - if (mips_isa & ISA_MIPS64R2) > > + if ((mips_isa & INSN_ISA_MASK) =3D=3D ISA_MIPS64R2) > > mips_ase |=3D ASE_VIRT64; > > return; > > } >=20 > This looks like an unrelated bug fix to me that should be applied=20 > separately. Yes. >=20 > Also I've noticed the MSA module adds new branch=20 > instructions -- have you=20 > wired them into our branch relaxation support (GAS's --relax-branch=20 > option) -- if it's at all possible? Assuming that it is,=20 > then it's OK, at=20 > least initially, as far as I am concerned, if you did not,=20 > but either way=20 > please add some test coverage, following either relax.? or=20 > relax-bc1any.?=20 > from gas/testsuite/gas/mips/ as applicable. I haven't added branch relaxation support. I think all possible MSA bran= ches are there, so it should be ok to support branch relaxation. Need to work on it. Thanks a lot! Regards, Chao-ying