MIPS HAVE_32BIT_ADDRESSES bogon ?

[cgd@broadcom.com]

ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes:
> > 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?
> 
> The SGI assembler seems to use consistently the lowest ISA
> required for the job. I don't know what might or might not
> break when overflow behaviour is changed.

Umm, so, 'add' (etc.) are used in preference to 'dadd' for N32, even
though the minimum ISA for N32 is MIPS III?


> > 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?
> 
> la uses addiu, dla uses daddiu. What's wrong with this?

Now that I think about it some more, nothing i guess.  (To be honest,
I'd forgotten about dla!  That's what I get for writing mail late at
night... 8-)

However, this raises an interesting (to me 8-) point:

If you use 'dla' you _do_ know you're trying to load a 64-bit address,
right?  So, the code that handles M_LA_AB and M_DLA_AB determine address
size via a calculation that at least includes 'dbl'?  (If you say 'la'
and you "have 64-bit addresses" in general, are you expecting to get a
64-bit address or a 32-bit address?  If so, it'd have to be 'dbl ||
HAVE_64BIT_ADDRESSES' in a few places?)

Similarly, it looks like there's redundant code in load_address; the
HAVE_64BIT_ADDRESSES checks in there could (I think) be replaced with
checks of 'dbl' (and perhaps an assertion that if 'dbl' is set,
HAVE_64BIT_GPRs is set).  (Right now, it looks like the 'dbl' arg to
that fn is always set via HAVE_64BIT_ADDRESSES.)


Hmm, OK, anyway, I'm still concerned about embedded PIC.  I'm thinking
that it's probably not-unreasonable to assume 64-bit addresses if
64-bit GPRs and embedded PIC, since that's what the code used to do.
I worry about adding the flag, because that means that existing
code/Makefiles may break...  (But on the other hand, the binutils MIPS
code has changed enough that there's no real guarantee that things
will work right in that regard, anyway...)



chris