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/...

[Juli Mallett]

On Wed, Jun 2, 2010 at 05:42, John Baldwin <jhb at freebsd.org> wrote:
> On Wednesday 02 June 2010 7:06:03 am Juli Mallett wrote:
>>   o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the
>>      former being what libgcc, etc., check and the latter seemingly being a
>>      misspelling of a hand merge from a Linux spec.
>
> I wonder if it would be useful to define both?  The macros we check for
> architecture-specific code for other architectures all have both leading and
> trailing underscores (e.g. __i386__, __amd64__, etc.).  Being able to use
> __mips64__ instead of __mips64 for that in kernel sources, etc. would 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 particular
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.

Thanks,
Juli.