Home Original page

PATCH RFC: Fix ARM bug by splitting up iwmmxt_movsi_insn

Richard Earnshaw rearnsha@arm.com
Mon Oct 13 16:16:00 GMT 2003 
> On Mon, Oct 13, 2003 at 10:12:47AM +0100, Richard Earnshaw wrote:
> > > +   switch (which_alternative)
> > > +   {
> > > +   case 0: return \"mov%?\\t%0, %1\";
> > > +   case 1: return \"mvn%?\\t%0, #%B1\";
> > > +   case 2: return \"ldr%?\\t%0, %1\";
> > > +   case 3: return \"str%?\\t%1, %0\";
> > > +   case 4: return \"tmcr%?\\t%0, %1\";
> > > +   case 5: return \"tmrc%?\\t%0, %1\";
> > > +   default: return arm_output_load_gr (operands);
> > > +  }"
> 
> If you do this then you need to fix arm_output_load_gr also.  At the
> minimum:
> 
>   if (GET_CODE (operands [1]) != MEM
>       || GET_CODE (sum = XEXP (operands [1], 0)) != PLUS
>       || GET_CODE (reg = XEXP (sum, 0)) != REG
>       || GET_CODE (offset = XEXP (sum, 1)) != CONST_INT
>       || ((INTVAL (offset) < 1024) && (INTVAL (offset) > -1024)))
>     return "wldrw%?\t%0, %1";
> 
> But wldrw is the unpredicable instruction which started all this.

If that's true then the tables in GAS are wrong as well.

  {"wldrw",      0xec100200, 5, ARM_CEXT_IWMMXT, do_iwmmxt_word_addr},
                            ^^
says that a condition code may appear after the fifth character (it should 
be zero if that isn't allowed).

The same is also true of wstrw:

  {"wstrw",      0xec000200, 5, ARM_CEXT_IWMMXT, do_iwmmxt_word_addr},

Argh! no, it gets worse...

In do_iwmmxt_word_addr() we have

  if (wc_register (reg))
    {
      inst.instruction |=  0xf0000100;
      inst.instruction &= ~0x00400000;
    }

Where's the test that the user hasn't emitted a conditional instruction 
that wasn't legal?

Is it really the case that whether or not wstrw is conditionally 
executable or not depends on the registers it was given?

R.
More information about the Binutils mailing list