Re: [PATCH] MIPS gas: Cleanup address insn conditionals

[Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>]

Maciej W. Rozycki wrote:
> On Mon, 16 Jun 2003, Thiemo Seufer wrote:
> 
> > >  Hmm, this effectively disables addresses in the ranges of 0x7fff8000 -
> > > 0x7fffffff and 0xffff8000 - 0xffffffff for certain operations for the n32
> > > ABI.  The latter is probably out of the scope of the ABI, but the former
> > > certainly is not.
> > 
> > Well, IRIX works this way, and the n32 ABI documentation mandates the
> > use of add/addi.
> 
>  The only n32 reference I have is "MIPSPro N32 ABI Handbook" and it indeed
> uses trapping instructions, namely "add" and "sub", but only for address
> arithmetics and not loading.  Which seems to make more sense; actually
> regardless of the ABI used.  But only a little, as such a trap would only
> be of any use for a kernel; for userland an address error exception would
> be triggered if the resulting address was ever used.  And that's the job
> of a compiler, not gas, anyway. 

I have to correct myself: IRIX works _not_ that way. It happily uses the
non-overflowing variants, and sys/asm.h doesn't distinguish between o32
and n32 WRT.

> > > Does any of the ABI documents contain any specific
> > > comment on a special treatment of the range?  Why do you think such an
> > > overflow check should be done -- what advantages are there?  Certainly
> > > "addu" and "addiu" cannot result in improper sign-extension of low 32-bit
> > > halfs of registers. 
> > 
> > Right, the idea of catching improper sign-extension was only valid
> > for n64 (where it isn't done). I'll fix the comment.
> 
>  Well, then the same note applies to 0x7fffffffffff8000 -
> 0x7fffffffffffffff (invalid for old 64-bit processors such as R4k or R10k,
> but perfectly fine for the MIPS64 ISA) and 0xffffffffffff8000 -
> 0xffffffffffffffff.  I fail to see any advantage for trapping on address
> loads for these, too.

Well, AFAICS there actually isn't much benefit, a kernel or standalone
program could probably trap address overflows easier, but even that
sounds a bit dubious.

Alexandre, when you changed the NewABI addressing, was there a reason
for it besides the N32 ABI Handbook?


Thiemo