Re: MIPS HAVE_32BIT_ADDRESSES bogon ?

[cgd at broadcom dot com]

ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes:
> > I'm wondering if maybe HAVE_32BIT_ADDRESSES should be defined as:
> > 
> > 	(HAVE_32BIT_GPRS
> > 	 || ((bfd_arch_bits_per_address (stdoutput) == 32
> > 	      || ! HAVE_64BIT_OBJECTS)
> > 	     && mips_pic != EMBEDDED_PIC))
> 
> Does EMBEDDED_PIC _always_ have 64 bit addresses or only in combination
> with -mlong64?

It's possible to code a program entirely in assembler which uses
EMBEDDED_PIC, and 64-bit addresses.  (Given that it's for embedded
use, that's not as insane a statement as it might seem...  Certainly
it's a reasonable thing for e.g. small test programs.)

So, it's certainly possible to have 64-bit addresses w/o the C
compiler flag -mlong64.


> If the latter, it's better to check for -mlong64 for this
> purpose, an option which doesn't exist in gas yet.

I actually think this is a bit insane.  The notion of having to
explicitly tell the assembler that higher-level langauge 'pointers'
and 'longs' (what's a long to the mips assembler?  that thing that
.long generates as 4 bytes?  8-) seems ... wrong.

What's the _harm_ in generating 'd' ops for embedded-pic if there are
64-bit GPRs?  (heck, what's wrong with using them for e.g. n32?!)

I guess I actually don't get, in general, the harm of using the 'd'
ops when ptr size is 32 bits.  is this to make _sure_ you get
overflow?  do e.g. SGI assemblers do this?


Actually, this led me to an "uh oh!": mips-opc.c is quite happy to
unconditinoally implement e.g. 'la' as addiu...  that seems ... wrong,
eh?


chris