From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27467 invoked by alias); 29 Jul 2014 10:33:48 -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 27451 invoked by uid 89); 29 Jul 2014 10:33:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Jul 2014 10:33:46 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 2986DB9113053; Tue, 29 Jul 2014 11:33:41 +0100 (IST) Received: from KLMAIL02.kl.imgtec.org (10.40.60.222) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Jul 2014 11:33:42 +0100 Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by klmail02.kl.imgtec.org (10.40.60.222) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Jul 2014 11:33:42 +0100 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 11:33:41 +0100 From: Matthew Fortune To: Richard Sandiford CC: "binutils@sourceware.org" , "Moore, Catherine" , "macro@codesourcery.com" , "Joseph Myers (joseph@codesourcery.com)" Subject: RE: [PATCHv4] Add support for O32 FPXX ABI Date: Tue, 29 Jul 2014 10:33:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235320EB5121@LEMAIL01.le.imgtec.org> References: <6D39441BF12EF246A7ABCE6654B0235320EB4042@LEMAIL01.le.imgtec.org> <87fvhnma8u.fsf@talisman.default> <6D39441BF12EF246A7ABCE6654B0235320EB4A44@LEMAIL01.le.imgtec.org> <871tt5urqn.fsf@googlemail.com> In-Reply-To: <871tt5urqn.fsf@googlemail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00226.txt.bz2 This is now committed. Tested with mips(64)?el?-linux-gnu and mips(64)?-mti-elf. Thanks for all the work on this Richard. Richard Sandiford writes: > Matthew Fortune writes: > > but the bigger reason is that the micromips mtc1/mfc1 instructions are > > not INSN_COPROC_MOVE_DELAY so there is no flag to detect them. This > > has never been a problem before as there has always been 32 single > > precision registers for micromips but now that may be restricted to 16 > > depending on ABI. I could just attach a new flag to the micromips > > instructions which lack any other flag but it seems clearer to attach > > it to the others too. The only other option is to add > > INSN_COPROC_MOVE_DELAY to the mtc1/mfc1 instructions in micromips even > > though that is something of a lie. What do you think is cleanest? >=20 > I think the last one is probably best. We could remove the _DELAY > from the name too, since the delay is only conditional anyway. I'll leave a rename to a separate commit. > > I would also like to get rid of all the ctc1/cfc1/cttc1/cftc1 > instructions > > that allow the use of floating point register names: $f0. The problem > with > > these is that they don't actually write floating point registers but > they > > will interact with the oddspreg logic as their operands have type > > OP_REG_FP. Anything relying on ctc1 $0, $f[0-31] is probably expecting > the > > wrong thing to happen anyway. If that's OK I'll do a separate patch? >=20 > It's always dangerous to change something long-standing like that, but > I agree it's weird. OTOH "ctc1 $0, $31" could be seen as confusing too > (it isn't GPR 31). >=20 > Let's assume it's OK for now and see if there are any objections. I'll do this as a separate commit as well. Thanks, Matthew