This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


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

Re: arm-coff-gcc function prologue w/ unsigned short parameter


> By declaring x as "unsigned short", you are saying that only the bottom 16 
> bits contain meaningful data; but you then try to use all 32 (assuming 
> that the top 16 are zero).

Perhaps I was wrong, but I was under the impression that the ARM core
cannot deal with just 16 bits of a register unless loading or storing it
to memory.  All ALU manipulations _must_ operate on all 32 bits.  Is
this the case?  If so, then would it not be a requirement to zero the
top 16 bits of a register containing an unsigned short value before
operating on it?  And if not, then why does gcc religiously do so, even
under -O2 optimization (short of this one bug I'm investigating)?

> What you really need to write for swabw is
>
> static unsigned short
> swabw(unsigned short x)
> {
>     unsigned y = x;
>     __asm__("orr %0, %0, %0, lsl #16 ; mov %0, %0, lsr #8" : "+r" (y) );
>     return y & 0xffff;
> }
>
> This will then ensure that the top bits of 'y' are all zero.

Thanks for the tip, Richard.  I think I'll put this in our official
version of swabw, as under -O2, it doesn't generate any extra instructions.
In fact, it comes out exactly the same as my version, except that the
erroneous asr #16 modifier is replaced with the correct lsr #16.

However, as I said before, I see this happening in other places that
do not have any inline assembly.  I just haven't been able to come up
with a very short example, suitable for posting here, that exhibits the
bug using pure ANSI C.  So though your fix addresses this one instance
nicely, the problem, in general, remains.

To elaborate on my assumption/question above, how, in theory, should gcc
be dealing with 16-bit values on the arm, which natively wants only to
deal with 32-bit values?


-------------------------------------------
Carl Miller               Firmware Engineer
chaz@gordian.com              Gordian, Inc.
(714) 850-0205       http://www.gordian.com

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


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