This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] MIPS gas: Cleanup address insn conditionals
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Cc: Eric Christopher <echristo at redhat dot com>, binutils at sources dot redhat dot com
- Date: Mon, 16 Jun 2003 16:31:07 +0200 (MET DST)
- Subject: Re: [PATCH] MIPS gas: Cleanup address insn conditionals
- Organization: Technical University of Gdansk
- Reply-to: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
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.
> > 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.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +