From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23311 invoked by alias); 13 Dec 2013 16:39:17 -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 23302 invoked by uid 89); 13 Dec 2013 16:39:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f182.google.com Received: from mail-we0-f182.google.com (HELO mail-we0-f182.google.com) (74.125.82.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 13 Dec 2013 16:39:15 +0000 Received: by mail-we0-f182.google.com with SMTP id q59so2121005wes.41 for ; Fri, 13 Dec 2013 08:39:12 -0800 (PST) X-Received: by 10.181.12.71 with SMTP id eo7mr3332596wid.28.1386952751970; Fri, 13 Dec 2013 08:39:11 -0800 (PST) Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n2.emea.ibm.com. [195.212.29.76]) by mx.google.com with ESMTPSA id q19sm8707960wiw.4.2013.12.13.08.39.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2013 08:39:10 -0800 (PST) From: Richard Sandiford To: Andrew Bennett Mail-Followup-To: Andrew Bennett ,"Maciej W. Rozycki" , "binutils\@sourceware.org" , rdsandiford@googlemail.com Cc: "Maciej W. Rozycki" , "binutils\@sourceware.org" Subject: Re: [PATCH] Add MIPS ufr macro instruction In-Reply-To: <0DA23CC379F5F945ACB41CF394B982774DE91E@LEMAIL01.le.imgtec.org> (Andrew Bennett's message of "Wed, 11 Dec 2013 12:19:59 +0000") References: <0DA23CC379F5F945ACB41CF394B982774C835E@LEMAIL01.le.imgtec.org> <87vc01erxi.fsf@talisman.default> <87siuzcpp4.fsf@talisman.default> <0DA23CC379F5F945ACB41CF394B982774CB15B@LEMAIL01.le.imgtec.org> <0DA23CC379F5F945ACB41CF394B982774CE268@LEMAIL01.le.imgtec.org> <8738mm3pgb.fsf@talisman.default> <0DA23CC379F5F945ACB41CF394B982774DAC1A@LEMAIL01.le.imgtec.org> <87fvq07ufx.fsf@talisman.default> <0DA23CC379F5F945ACB41CF394B982774DE91E@LEMAIL01.le.imgtec.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Date: Fri, 13 Dec 2013 16:39:00 -0000 Message-ID: <87vbysiu3a.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-12/txt/msg00190.txt.bz2 Hi Andrew, Looks good, thanks, but is there any reason not to use mips_cp1_names_mips3264 for all MIPS32 and MIPS64 targets? I realise some of them don't have an FPU, but if we see (presumably emulated) FPU instructions anyway, then I think we might as well follow the architecture names for the registers. E.g.: Andrew Bennett writes: > @@ -525,43 +571,43 @@ const struct mips_arch_choice mips_arch_choices[] = > { "sb1", 1, bfd_mach_mips_sb1, CPU_SB1, > ISA_MIPS64 | INSN_SB1, ASE_MIPS3D, > mips_cp0_names_sb1, > mips_cp0sel_names_sb1, ARRAY_SIZE (mips_cp0sel_names_sb1), > - mips_hwr_names_numeric }, > + mips_cp1_names_numeric, mips_hwr_names_numeric }, SB1 did have an FPU. If you agree, then the patch is OK with every ISA_MIPS32* and ISA_MIPS64* entry having mips_cp1_names_mips3264. If not then let me know :-) If you don't have commit access yet then please feel to sign up using: https://sourceware.org/cgi-bin/pdw/ps_form.cgi listing me as approver. Thanks, Richard