This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Why pass HAVE_32BIT_GPRS to OPCODE_IS_MEMBER?
- To: binutils at sources dot redhat dot com
- Subject: Re: Why pass HAVE_32BIT_GPRS to OPCODE_IS_MEMBER?
- From: Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de>
- Date: Wed, 8 Aug 2001 11:48:54 +0200
cgd@broadcom.com wrote:
> ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes:
> > Why differentiate between forced and non-forced 32bit GPRS?
> > The assembler should handle both identically.
>
> So, I think the answer to this is that by some chain of logic you
> might end up with 'non-canonical 32-bit values' (i.e. 32-bit values
> but where bits 63:32 != bit 31) in registers, if you're in
> forced-32-bit mode.
Such code is broken by definition. Every 32bit value has to be
properly sign-extended on a 64bit MIPS CPU. Otherwise it's
behaviour is undefined, at least WRT the MIPS IV spec.
[snip]
> To go back to the original patch message:
>
> http://sources.redhat.com/ml/binutils/1999-12/msg00123.html
Ah, that's the patch which also introduced the setting of mips_64
in -mgp{32,64}. This is wrong because mips_64 denotes the use of
-mabi=64, not the use of 64bit insns.
> It and the messages that preceeded it:
>
> http://sources.redhat.com/ml/binutils/1999-10/msg00133.html
> http://sources.redhat.com/ml/binutils/1999-10/msg00135.html
>
> shed some light on the issue.
Especially about the 'or' vs. 'addu' thing. I already assumed that
'or' is the wrong choice, and Ian says there so, too.
[snip]
> I don't know how abi=32 code is intended to be run. if it simply
> defines calling conventions, and not processor mode,
For our purpose it defines register widths and calling conventions,
but not the processor mode.
> then you need to
> use 'or' rather than 'addu'. If it defines processor mode as well,
> then addu would be sufficient.
No, addu is ok for any ISA conforming code due to the requirement
of proper sign extension.
> In any event, my personal preference is to nuke the gp32 arg to
> OPCODE_IS_MEMBER, and assemble "move" as a macro, and use -mtune to
> schedule preference of 'or' vs. 'add'.
Even without the need for 'or' this would be the IMHO cleaner
solution.
Thiemo