Re: powerpc-eabi assembler

[Peter Popov <ppopov at redcreek dot com>]

Ian Lance Taylor wrote:
> 
>    Date: Mon, 20 Dec 1999 03:19:45 +0000
>    From: Pete Popov <ppopov@pacbell.net>
> 
>    >>    li r5, 0xfffe
>    >>
>    >>    initads.s:194: Error: operand out of range (65534 not between -32768 and 32767)
>    >>
>    >>    It complains that the operand is out of range, when in fact,
>    >>    if should just translate the 0xfffe t0 -2.   Does anyone know if
>    >>    this is an assembler bug, or is it a feature?
>    >>
>    >> It's a feature.  You're asking the assembler to load 0xfffe into r5.
>    >> That can't be done in one li instruction.  You can load 0xfffffffe,
>    >> but you can't load 0x0000fffe.
> 
>    The instruction "li r5,0xfffe" should, in fact, load 0xfffffffe in
>    register r5, not 0x0000fffe.  The syntax is "li r5,SIMM"; the signed
>    bit is extended so you should end up with 0xfffffffe in r5.
> 
> I read that differently from you.  The instruction uses a SIMM field,
> which means that at execution time the 16 bit operand is sign
> extended.  To me that says that when you write assembler code, you
> must supply an operand whose value is such that when the low order 16
> bits are sign extended, you get the same value.  An attempt to supply
> a different value should be flagged as an error, because at execution
> time a value other than the one you supplied will be used.

When you put it this way, it does make sense.

> Consider the instruction "li r5,65534".  A natural reading of the
> assembler code is that this will load the value 65534 into r5.  In
> fact, it will not; it will load the value -2 == 0xfffffffe ==
> 4294967294 into r5.  Similarly, a natural reading of "li r5,0xfffe" is
> that it will load the value 0xfffe == 65534 into r5.  In fact, it will
> not.
 
>    If choking on "li r5,0xfffe" is truly a feature, how would you load
>    0xfffffffe in a register in one single instruction?  Doing so (loading
>    0xfffffffe in a register in one instruction) is definitely possible, but
>    not as long as the assembler doesn't accept 0xfffe as the equivalent of "-2".
>    It forces you to manually convert negative numbers to decimal, which just
>    doesn't make any sense.
 
> The assembler doesn't accept 0xfffe as the equivalent of -2, because
> they are not equivalent.  It does, however, accept 0xfffffffe as the
> equivalent of -2, because they are equivalent, assuming a 32 bit
> processor.  The instruction you are looking for is "li r5,0xfffffffe".

Thank you for the thorough explanation -- I appreciate the feedback.
Your explanation makes sense, so I think it's the Diab Data assembler
that's broken in this case.  And, the instruction "li r5, 0xfffffffe"
does indeed work, so I've got what I was looking for.

Pete

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com