From owner-svn-src-head@FreeBSD.ORG Wed Jun 2 21:25:23 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C4461065674; Wed, 2 Jun 2010 21:25:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 9449B8FC08; Wed, 2 Jun 2010 21:25:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o52LJ3EY044192; Wed, 2 Jun 2010 15:19:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 Jun 2010 15:19:15 -0600 (MDT) Message-Id: <20100602.151915.496568814199104007.imp@bsdimp.com> To: jmallett@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <201006021106.o52B63PZ035362@svn.freebsd.org> <201006020842.49509.jhb@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, jhb@FreeBSD.org Subject: Re: svn commit: r208737 - in head: contrib/binutils/bfd contrib/binutils/gas/config contrib/binutils/include/elf contrib/binutils/include/opcode contrib/binutils/opcodes contrib/gcc/config contrib/gcc/... X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 21:25:23 -0000 In message: Juli Mallett writes: : On Wed, Jun 2, 2010 at 05:42, John Baldwin wrote: : > On Wednesday 02 June 2010 7:06:03 am Juli Mallett wrote: : >> =A0 o) Fix our GCC spec to define __mips64 for 64-bit targets, not= __mips64__, the : >> =A0 =A0 =A0former being what libgcc, etc., check and the latter se= emingly being a : >> =A0 =A0 =A0misspelling of a hand merge from a Linux spec. : > : > I wonder if it would be useful to define both? =A0The macros we che= ck for : > architecture-specific code for other architectures all have both le= ading and : > trailing underscores (e.g. __i386__, __amd64__, etc.). =A0Being abl= e to use : > __mips64__ instead of __mips64 for that in kernel sources, etc. wou= ld be : > more consistent. : = : __mips64 is a mistake and adding __mips64__ and using it would be a : bigger one, I think, since it's kind of confusing and not actually : useful enough to use consistently. MIPS64 is the name of a particula= r : ISA, but not all 64-bit ISAs (indeed, the earliest 64-bit ISA is : MIPS-III) are derived from it. __mips64 implies a 64-bit ABI, but : there isn't a clean split between non-__mips64 ABIs and __mips64 ABIs= : such that those are the only two things you'd ever need to check for.= : We intend to support the n32 ABI in userland, which has 64-bit : registers. Conditionals related to that kind of thing would become : (__mips64__ || __mips_n32). I think it makes more sense to be : consistent and use macros related to specific ABIs, macros related to= : specific ISAs and sometimes the macros related to the length of long : and the size of a pointer, since there are some ABIs that we might : support (o64) which can support strange combinations of those. What Juli said and __mips64 is neither an architecture nor a machine. All the other examples you gave are architectures. Warner