From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Henderson To: Cort Dougan Cc: gas2@sourceware.cygnus.com Subject: Re: ppc instructions in gas Date: Thu, 06 May 1999 16:56:00 -0000 Message-id: <19990506165624.A24549@cygnus.com> References: <19990504180843.A31050@attis.cs.nmt.edu> <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990506161159.A27229@attis.cs.nmt.edu> <19990506153554.B10994@cygnus.com> <19990506171639.A26711@attis.cs.nmt.edu> <19990506171639.A26711@attis.cs.nmt.edu> X-SW-Source: 1999/msg00097.html 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~