* 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).