This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Why pass HAVE_32BIT_GPRS to OPCODE_IS_MEMBER?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]