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.
Chris
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
