This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS HAVE_32BIT_ADDRESSES bogon ?
cgd@broadcom.com wrote:
[snip]
> > 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?
Yes, at least when it comes to address calculation.
[snip]
> 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?)
The SGI assembler chooses this by the addressing mode and gives
warnings when it encounters the wrong type. In gas it makes a
difference, and since it was hacked to work with 64bit addresses
in code loaded in 32bit address space this can't be changed
without breakage. I don't know a good way out there besides of
maybe adding warnings.
> 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.)
That's right, I introduced the dbl param later than the 64bit
addressing to call load_register the right way. Alredy changed
in my local tree, but first I must care about the breakages Eric
reports WRT my 64bit addressing changes.
> 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...)
I don't know how embedded PIC is actually used. If the embedded PIC
users are happy with the old behaviour it's reasonable to stay with
it for them.
Thiemo