From: Joshua Lamorie <jpl@xiphos.ca>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] v2p4 porting troubles
Date: Tue, 16 Mar 2004 18:01:37 -0500 [thread overview]
Message-ID: <009b01c40baa$a324f2b0$cb01a8c0@xiphos.ca> (raw)
In-Reply-To: 20040316203653.2844CC0655@atlas.denx.de
We're doing quite the tag team here.
> > (notice that this is the XIo_Out32() function generated by Xilinx XPS)
> Which sort of code does this tool generate? C code? Then it would be
> indeed a compiler probile, and I definitely would like to see this C
> code.
The code from Xilinx is as follows...
void XIo_Out32(XIo_Address OutAddress, Xuint32 Value)
{
__asm__ volatile ("stw %0,0(%1); eieio" : : "r" (Value), "r"
(OutAddress));
}
... which is called from a simple program (found at the end of this email).
When this is compiled with the Xilinx toolchain (gcc 2.95 I think), it
generates the 'real' assembler as follows.
stw r0,0(r9)
However, when we put this into a linux toolchain (crosstools 0.26, or ELDK
3.0) it generates it with r0 and r9 in the opposite spots.
stw r9,0(r0)
We can change the C code to
__asm__ volatile ("stw %1,0(%0); eieio" : : "r" (OutAddress), "r"
(Value));
Which seems to generate it correctly with the linux tools.
We have added this same function inside u-boot to toggle some LEDs as we are
debugging, but without changing anything it generates assembler that uses r4
and r3 and not r0 and r9, so there is no chance of a problem.
But why? What is it about this C code which causes this sort of thing?
What constraints should be used? Where is decent, unambiguous documentation
of gcc inline assembler (instead of poorly explained examples)?
Thank you Wolfgang for your help so far. Your comments have been very
useful.
Joshua
The original test code is as follows.
#define XPAR_IOBRIDGEV2P_PLB_0_BASEADDR 0x40000000
typedef unsigned long Xuint32; /**< unsigned 32-bit */
typedef Xuint32 XIo_Address;
void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
int simpletest();
int _start() {
simpletest(0,0);
}
int simpletest()
{
int i,j,k;
XIo_Out32(XPAR_IOBRIDGEV2P_PLB_0_BASEADDR, 0x55);
while (1) {
for (i=1; i<30000; i++) {
for (j=i; j<5000; j*=2) {
for (k=0; k<1000; k+=5) {
}
}
XIo_Out32(XPAR_IOBRIDGEV2P_PLB_0_BASEADDR, i&0xFF);
}
}
return(0);
}
void XIo_Out32(XIo_Address OutAddress, Xuint32 Value)
{
//__asm__ volatile ("stw %0,0(%1); eieio" : : "r" (Value), "r"
(OutAddress));
__asm__ volatile ("stw %1,0(%0); eieio" : : "r" (OutAddress), "r"
(Value));
}
next prev parent reply other threads:[~2004-03-16 23:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-16 3:05 [U-Boot-Users] v2p4 porting troubles Joshua Lamorie
2004-03-16 15:43 ` Joshua Lamorie
2004-03-16 16:01 ` Wolfgang Denk
2004-03-16 19:41 ` Eric St-Jean
2004-03-16 20:36 ` Wolfgang Denk
2004-03-16 23:01 ` Joshua Lamorie [this message]
2004-03-16 23:40 ` Wolfgang Denk
2004-03-17 9:47 ` Joakim Tjernlund
2004-03-17 11:16 ` Joakim Tjernlund
2004-03-17 2:02 ` Peter Ryser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='009b01c40baa$a324f2b0$cb01a8c0@xiphos.ca' \
--to=jpl@xiphos.ca \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox