Sure, this is what I have as a test as I wanted to look at function call
overhead, and the compiler used is "powerpc-eabi-gcc (eCosCentric GNU
tools 4.3.2-sw) 4.3.2", after a bunch of messing around I ended up using
this to invike the compiler, not that it seemed to make any difference,
"powerpc-eabi-gcc -S println.c -finline-functions -fbtr-bb-exclusive
-fdefer-pop -fwhole-progr". I lay no claim to brilliance with compiler
options I was primarily just trying to see if the options had any
effect.
#define unsigned int size_t
#include <stdio.h>
char *pstr ="42";
void myCall(char *cptr)
{
sprintf(cptr,"Hello baby %f %u", atoi(pstr),atof(pstr));
}
void main(int argc, char **argv)
{
char cptr[32];
myCall(&cptr[0]);
printf("%s\n",cptr);
}
/* END */
On Sun, 2009-04-05 at 21:45 +0100, Andrew Haley wrote:
> marian Szczepkowski wrote:
> > We are looking at GCC and another compiler for use on an embedded
> > powerpc project and in comparing the two compilers I get this,
> >
> >>From GCC
> > lis 9,pstr@ha
> > lwz 0,pstr@l(9)
> > mr 3,0
> > crxor 6,6,6
> > bl atoi
> > mr 29,3
> >
> >>From vendor
> > 172 lwz r3, 532(r31)
> > 173 bl atof
> > 174 bl _d_dtof
> > 175 stw r3, 12(sp)
> >
> >
> > GCC appears to be doing some extra work here and I am at a loss to work
> > out what it is doing this for, why the crxor 6,6,6 from my reading this
> > is the floating point exception in the CR, and GCC does this every time,
> > as here...
> >
> > lwz 3,8(31)
> > lis 9,.LC1@ha
> > la 4,.LC1@l(9)
> > mr 5,29
> > mr 6,0
> > crxor 6,6,6
> > bl sprintf
> >
> > Can some one explain this seemingly irrelevant extra step..
>
> Can you supply a small test case that generates this code?
>
> Andrew.
