public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* arm-elf inline assembly problem (gcc bug?)
@ 2002-10-27 20:48 Jeremy Linton
  2002-10-28  0:34 ` Momchil Velikov
  0 siblings, 1 reply; 2+ messages in thread
From: Jeremy Linton @ 2002-10-27 20:48 UTC (permalink / raw)
  To: gcc-help

I am running a self built gcc 3.0.3 from a few months ago. Its been
working fine until last a week or so when I wrote the following code.


//reads a single byte from the IO port set by PioSetAddress
unsigned char PioReadChar(void)
{
   PioController->WO_OutputDisable=0xFF; //set the data pins for input
   PioController->WO_InputFilterEnable=0xFF;
   int ret;
   //each PIO toggle takes ~90ns
   __asm__("mov r5,#0x400\n\t"
     "mov r6,#0x1000\n\t"
     "str r5,[%3]\n\t"
     "str r6,[%1]\n\t"

     "ldr %0,[%2]\n\t" //reading the byte a few times is a cheap way to
figure out my delay
     "ldr %0,[%2]\n\t" //since I know exactly how long (in real time)
the ldr is taking...
     "ldr %0,[%2]\n\t"
     "ldr %0,[%2]\n\t"
     "ldr %0,[%2]\n\t"

     "str r6,[%3]\n\t" //damn!!??  gcc 3.0.3 sometimes reuses a register
for both %0 and %3!
     "str r5,[%1]\n\t"
     "str r5,[%1]\n\t"//stick in the min change time of 135ns
     "str r5,[%1]\n\t"

     : "=r" (ret)
     : "r" (&PioController->WO_ClearOutputData),"r"
(&PioController->RO_PinDataStatus) , "r"
(&PioController->WO_SetOutputData)
     : "r5", "r6"
    );

   return ret;
}


which sometimes is giving me output which looks like (it varies
depending on the -O).


0x1017e0 <_Z11PioReadCharv+52>: str     r5, [r3]
0x1017e4 <_Z11PioReadCharv+56>: str     r6, [r0]
0x1017e8 <_Z11PioReadCharv+60>: ldr     r0, [r2] <--- Note the R0 reuse
0x1017ec <_Z11PioReadCharv+64>: ldr     r0, [r2]
0x1017f0 <_Z11PioReadCharv+68>: ldr     r0, [r2]
0x1017f4 <_Z11PioReadCharv+72>: ldr     r0, [r2]
0x1017f8 <_Z11PioReadCharv+76>: ldr     r0, [r2]
0x1017fc <_Z11PioReadCharv+80>: str     r6, [r3]
0x101800 <_Z11PioReadCharv+84>: str     r5, [r0] <--- core dump, r0 has
the value loaded not the original r0 value
0x101804 <_Z11PioReadCharv+88>: str     r5, [r0]
0x101808 <_Z11PioReadCharv+92>: str     r5, [r0]


I've been compiling it like.
arm-elf-gcc -DUNIX -g -c -O -Wall -fno-exceptions -fno-rtti Ethernet.cpp

Anyone have any suggestions? Has this problem been fixed in a newer gcc?
I don't want to go through the pain of upgrading if it there haven't
been any bugs like this fixed.  I would explicitly control the register
assignments, but I'm not sure how to do it with the arm.

BTW: remove the ".NOSPAM"  for a functional address.


                Thank you for you time,
                                    Jeremy Linton





^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: arm-elf inline assembly problem (gcc bug?)
  2002-10-27 20:48 arm-elf inline assembly problem (gcc bug?) Jeremy Linton
@ 2002-10-28  0:34 ` Momchil Velikov
  0 siblings, 0 replies; 2+ messages in thread
From: Momchil Velikov @ 2002-10-28  0:34 UTC (permalink / raw)
  To: Jeremy Linton; +Cc: gcc-help

On Sun, 27 Oct 2002 22:47:51 -0600
Jeremy Linton <jli1010.NOSP_M@hotmail.com> wrote:
> 0x1017e0 <_Z11PioReadCharv+52>: str     r5, [r3]
> 0x1017e4 <_Z11PioReadCharv+56>: str     r6, [r0]
> 0x1017e8 <_Z11PioReadCharv+60>: ldr     r0, [r2] <--- Note the R0
> reuse

See the documentation for the '&' constraint modifier. Basically,
you need ``: "=&r" (ret)''.

~velco

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-10-28  8:34 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-27 20:48 arm-elf inline assembly problem (gcc bug?) Jeremy Linton
2002-10-28  0:34 ` Momchil Velikov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).