Re: ppc instructions in gas

Re: ppc instructions in gas

[Richard Henderson]

On Wed, May 05, 1999 at 04:52:32PM -0600, Cort Dougan wrote:
> The signed change at the top makes sense with what the manual says.  The
> operand in questions should be a 16-bit unsigned immediate value not signed
> (as it was before).
[...]
>    /* The SI field in a D form instruction when we accept a wide range
>       of positive values.  */
>  #define SISIGNOPT SI + 1
> -  { 16, 0, 0, 0, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT },
> +  { 16, 0, 0, 0, /*PPC_OPERAND_SIGNED |*/ PPC_OPERAND_SIGNOPT },

Looking at this again, I wonder if this change is correct.

Which instruction were you trying to fix?  "liu" perhaps? 
As-is, it affects instructions like "addis", and you can't
really add +50000, can you?


r~

Re: ppc instructions in gas

[Richard Henderson]

On Thu, May 06, 1999 at 04:11:59PM -0600, Cort Dougan wrote:
> } Which instruction were you trying to fix?  "liu" perhaps? 
> } As-is, it affects instructions like "addis", and you can't
> } really add +50000, can you?
>
> You're right, addis takes a signed 16-bit number.  Things like lis and oris
> take an unsigned 16-bit number, though.  They both use SISIGNOPT.

Then the right thing to do is make those insns use UI instead.

Not having a ppc manual handy, can you provide a complete list
of the incorrect instructions?  Or better yet, a patch?  ;-)


r~

Re: ppc instructions in gas

[Richard Henderson]

On Thu, May 06, 1999 at 05:16:40PM -0600, Cort Dougan wrote:
> Ah-ha!  The problem is this:
> 
> We do immediate loads of (for example) 0xffff.  Even with lis (which takes
> a signed 16-bit value) this works with 32-bit.  It shouldn't since 0xffff
> is > +32k.  When I assemble with -Wa,-mppc64 it doesn't work and complains
> that 0xffff is > +32k.
> 
> Eh?  Any idea what's going on?

In gas/config/tc-ppc.c --

1067              if ((operand->flags & PPC_OPERAND_SIGNOPT) != 0
1068                  && ppc_size == PPC_OPCODE_32)
1069                max = (1 << operand->bits) - 1;

Looks like there's some backward compatibility thing going on. 

You said lis takes a signed value?  Meaning that the register
gets 0xffffffffffff0000?  If so, in my opinion the assembler is
correct to bitch at you for 0xffff as an operand.


r~

Re: ppc instructions in gas

[Richard Henderson]

On Thu, May 06, 1999 at 06:08:06PM -0600, Cort Dougan wrote:
> As it is, gcc (32-bit mode) generates
> code that will do a lis of 0xffff (the unsigned value) which shouldn't work
> according to the manual.  When I do this for 64-bit with egcs it will not
> assemble.

We should fix gcc then.  That should not be hard at all.

> Right, it should complain for both 32 and 64 bit.  It only complains for
> 64-bit now, though.  So I don't know if I should fix our asm (probably not,
> even though according to the manual it's incorrect but gcc generates the
> same code).
> 
> If I can change those operands to be unsigned it will still load a 16 bit
> value correctly but will allow things to work according to the manual and
> the egcs generated code.
> 
> Can we make these critters unsigned?  I don't know of any code that
> requires they be signed anywhere.

I'm not real comfortable just changing it.  Who knows what sort
of code is out there.  I wouldn't be adverse to reducing the
error to a warning in 32-bit mode though.


r~

Re: ppc instructions in gas

[Richard Henderson]

On Thu, May 06, 1999 at 06:57:54PM -0600, Cort Dougan wrote:
> } We should fix gcc then.  That should not be hard at all.
> 
> Ok.  Patch gcc to emit correct code and modify the asm we have in the
> kernel?  Know of any cute gas methods of converting 0xffff and its ilk to a
> signed value?

Pardon?  "gas methods"?

> } I'm not real comfortable just changing it.  Who knows what sort
> } of code is out there.  I wouldn't be adverse to reducing the
> } error to a warning in 32-bit mode though.
> 
> I'd prefer to actually do the right thing in my asm and if gcc did the same
> that would all the better.  So the check in binutils to allow unsigned
> values is probably a workaround for gcc?

No, the check to allow unsigned values is a workaround for (to pick a
name out of the hat) NorTel's hand-written assembly code.

So I'm on the right page, "lis" is the only instruction this is an issue
for?  What about the old "liu" insn?  "U" presumably stood for "upper"
not "unsigned"?


r~

Re: ppc instructions in gas

[Ian Lance Taylor]

   Date: Thu, 6 May 1999 15:07:24 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Wed, May 05, 1999 at 04:52:32PM -0600, Cort Dougan wrote:
   > The signed change at the top makes sense with what the manual says.  The
   > operand in questions should be a 16-bit unsigned immediate value not signed
   > (as it was before).
   [...]
   >    /* The SI field in a D form instruction when we accept a wide range
   >       of positive values.  */
   >  #define SISIGNOPT SI + 1
   > -  { 16, 0, 0, 0, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT },
   > +  { 16, 0, 0, 0, /*PPC_OPERAND_SIGNED |*/ PPC_OPERAND_SIGNOPT },

   Looking at this again, I wonder if this change is correct.

   Which instruction were you trying to fix?  "liu" perhaps? 
   As-is, it affects instructions like "addis", and you can't
   really add +50000, can you?

We specifically want to accept a wide range of values, because users
in practice use a wide range of values.  That is, users in practice
use
    lis  4,-0x8000
    lis  4,0x7fff
    lis  4,0xffff
    lis  4,-1
and expect them all to work.  It's true that the PowerPC docs prohibit
the last one.  However, people use it in real code, so gas accepts
it.  The last two instructions above generate the same bytes.

I don't have the context of the original message.  The addis/lis
instruction is documented to take a signed operand.  I don't know why
it makes sense to remove PPC_OPERAND_SIGNED.

Ian

Re: ppc instructions in gas

[Richard Henderson]

On Fri, May 07, 1999 at 03:05:30AM -0000, Ian Lance Taylor wrote:
> I don't have the context of the original message.  The addis/lis
> instruction is documented to take a signed operand.  I don't know why
> it makes sense to remove PPC_OPERAND_SIGNED.

Context is that gcc doesn't emit signed, and some of the ppc linux
kernel sources don't use signed values either.  This worked for 
ppc32 due to the PPC_OPERAND_SIGNOPT hack, and only showed up when
Cort started work on ppc64. 

We iterated enough to conclude that we should in fact fix gcc, and
the kernel sources.  The one remaining question is whether to continue
to silently accept unsigned values for ppc32, or whether we should
warn for them.

Thoughts on that last?


r~

Re: ppc instructions in gas

[Ian Lance Taylor]

   Date: Thu, 6 May 1999 20:13:22 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Fri, May 07, 1999 at 03:05:30AM -0000, Ian Lance Taylor wrote:
   > I don't have the context of the original message.  The addis/lis
   > instruction is documented to take a signed operand.  I don't know why
   > it makes sense to remove PPC_OPERAND_SIGNED.

   Context is that gcc doesn't emit signed, and some of the ppc linux
   kernel sources don't use signed values either.  This worked for 
   ppc32 due to the PPC_OPERAND_SIGNOPT hack, and only showed up when
   Cort started work on ppc64. 

   We iterated enough to conclude that we should in fact fix gcc, and
   the kernel sources.  The one remaining question is whether to continue
   to silently accept unsigned values for ppc32, or whether we should
   warn for them.

   Thoughts on that last?

I believe we should continue to silently accept them.  The patch was
put in there because of existing code which should continue to work.

I now remember that I opposed it at the time, and argued David
Edelsohn (I believe it was) into only accepting unsigned values in 32
bit mode, and requiring people to fix their code as they upgraded to
64 bits.

I even have a vague recollection that the Power liu instruction was
documented to load an unsigned value.  The Power was only 32 bits, so
of course it didn't really matter.  The PowerPC renamed liu to lis,
and made it signed for the 64 bit version.  Power code and Power
programmers naturally used unsigned values, so we made gas permit
unsigned values for lis.

Ian