> I have seen this, but you might try adding -msoft-float or
> -mhard-float to the makefile
>
> I'm not sure if the 6446 has an fp coprocessor, but it might be worth
a
> try.
>
Our toolchain was built with hard float support, so compiling
applications with -msoft-float causes GCC to barf at best, since there
are calling convention and other differences in the code generated with
each option. We're attempting to build our own toolchain with
-msoft-float and migrate to the 2.6.26 git kernel, although that is
proving difficult in and of itself.
There may be an external fpu available for DM6446, but we're locked into
our hardware design at this point, so that option is out.
I'm still mystified as to why std::cout << std::string causes Houdini
fpu code...
Thanks for the reply, I'm glad we're not just seeing things :)!
Ryan
> 2008/8/27 Ryan Talbot <[EMAIL PROTECTED]>:
> > Apologies if this is an inappropriate forum for this question, but
we're
> > wondering if anyone else has run into this behavior on a DM6446
using
> > gcc/g++.
> >
> >
> >
> > We've been getting disappointing performance with our DM6446
> application,
> > and have been running OProfile in an attempt to root up bottlenecks.
> While
> > doing so, we noticed do_fpe() and other associated NWFPE floating
point
> > emulation calls were topping out the symbol list in opreport. We
> stripped
> > all of the floating point operations out of the application, and yet
the
> > NWFPE symbols persisted in the opreport. In an attempt to narrow
the
> > location of the offending code, we noticed that if we stripped out
> things
> > that dealt with C++ std::string, the NWFPE calls disappeared!
> >
> >
> >
> > Perplexed, we wrote a Hello World! app:
> >
> >
> >
> > //////////////////////////////////////////
> >
> > #include <iostream>
> >
> > using namespace std;
> >
> >
> >
> > int main()
> >
> > {
> >
> > while(1)
> >
> > {
> >
> > cout << "Hello World!";
> >
> > }
> >
> > return EXIT_SUCCESS;
> >
> > }
> >
> > //////////////////////////////////////////
> >
> >
> >
> > Only to find, that when profiling this app, the NWFPE calls were at
the
> top
> > of the opreport (all told, about 25% of snapshots were taken from
within
> > some part of the NWFPE in the kernel)! We then replaced the 'cout'
line
> > with:
> >
> >
> >
> > int i=i+1;
> >
> >
> >
> > The NWFPE calls disappeared. Replacing 'cout' with 'printf' also
> prevents
> > the NWFPE symbols from showing up in an opreport. Surely the code
for
> 'cout
> > << "Hello World!"' doesn't cause floating point instructions to be
> emitted...
> > right? This issue appeared in our main app when C++ strings were
> > constructed, as well. Objdump does not reveal any floating point
> > instructions that I can see.
> >
> >
> >
> > This happens regardless of optimization settings.
> >
> >
> >
> > Has anyone run into a similar phenomenon? We're really scratching
our
> heads
> > on this one.
> >
> >
> >
> > arm-linux-gcc version 3.4.6 glibc-2.3.6 built by a 3rd party using
> > crosstool-0.42, Linux 2.6.18. We are using hardware floating point
> > emulation since that's what was provided to us by our 3rd party LSP,
but
> > we're in the process of building our own soft-float toolchain
(that's
> > another story...). Regardless, these calls shouldn't be showing up
the
> way
> > they are...
> >
> >
> >
> > Any insight sincerely appreciated,
> >
> > Ryan
> >
> >
> >
> >
>
////////////////////////////////////////////////////////////////////////
//
> ////////////
> >
> > Ryan Talbot
> >
> > Instrumentation Engineer
> >
> >
> >
> > Virginia Tech Transportation Institute
> >
> > 3500 Transportation Research Plaza
> >
> > Blacksburg, VA 24061
> >
> >
>
////////////////////////////////////////////////////////////////////////
//
> ////////////
> >
> > _______________________________________________
> > Davinci-linux-open-source mailing list
> > [email protected]
> >
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> >
> >
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
