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?


H . J . Lu wrote:
[snip]
> > >    The gp32 arg is set when you need to force 32-bit register usage on
> > >    a machine with 64-bit registers; see the documentation under -mgp32
> > >    in the MIPS gas docs.  */
> > 
> > This comment is possibly misleading. There are three ways to restrict
> > the assembler to 32bit GPRs: Explicitly by the programmer (-mgp32),
> > implicitly by the ABI (-mabi=32) and implicitly by the ISA (-mips{1,2,32}
> > or -march=FOO), where only the latter one can change over an assembly
> > run. So we need to check only two states: Programmer+ABI and ISA.
> > The current code checks for three which may get inconsistent.
> 
> There are
> 
> /* 32-bit code running on a ISA3+ CPU.  */
> #define INSN_GP32                 0x00100000
> 
> #define OPCODE_IS_MEMBER(insn, isa, cpu, gp32)                          \
>     ((((insn)->membership & isa) != 0                                   \
>       && ((insn)->membership & INSN_GP32 ? gp32 : 1)                    \
> 
> #define G6      INSN_GP32
> 
> {"move", "d,s", 0x00000025, 0xfc1f07ff, WR_d|RD_s, I1|G6   },/* or */
> 
> "move" is the only one affected by this. I am enclosing a new patch here.

Oh, that's all ok, but I advocated against your HAVE_FORCED_32BIT_GPRS.

[snip]
> > > +   (mips_gp32 || mips_32bit_abi)
> > > +
> > 
> > Why differentiate between forced and non-forced 32bit GPRS?
> > The assembler should handle both identically.
> 
> I don't know.

After reading the archived email mentioned by Chris,
http://sources.redhat.com/ml/binutils/1999-12/msg00123.html
and especially
http://sources.redhat.com/ml/binutils/1999-10/msg00132.html
I assume the use of 'or' instead of the usual 'addu' was not a
thoughtful decision but a 'low cost fix' to get working code.

So I vote to use 'addu' instead of 'or'.


Thiemo


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