Reply by D Yuniskis April 1, 20102010-04-01
Hi Dave,

Dave Nadler wrote:
> On Apr 1, 1:24 am, hamilton <hamil...@nothere.com> wrote: >> On 3/31/2010 7:11 PM, D Yuniskis wrote: >> >>> hamilton wrote: >>>> Are there any web sites available that compares the amount of overhead >>>> C++ carries compared to just plain C ? >>> In what context? I.e., if you "write C in C++" what >>> overhead did you anticipate? >>> I've often wanted to recode an existing project in C (or C++) >>> to compare the overall size/speed/etc. with C++ (or C). >>> But, even that wold be an unfair comparison as you (at least, *I*) >>> approach designs in C (C++) differently than I do in C++ (C). >> Yes, good point. >> >> Most new "embedded programmers" are from the desktop world. >> >> I would like to know, as you stated, what would be the overhead for the >> same program using C++ constructs. >> >> By your comment, I doubt too many programmers know that there is a >> difference. >> >> I'll look over the Keil web site and see if there is anything there. > > Comparing C and C++ is a bit of apples and oranges. > Properly written C++ can reduce source code size, reduce > execution size and time, improve maintainability. Bad C++
I'd say "that depends". I think a problem with much C++ is people trying to "just apply" already written classes to their problem-at-hand. E.g., similar to trying to use C "standard libraries" blindly. IME, it is even more important to craft your classes *to* the needs of your application (than it is to make the standard C libraries "fit"). I've also seen some analysis that C++ hurts cache performance (except for HUGE cache's) as it doesn't exploit locality of reference as much as C code might (again, loosely referring to "something" representative of C vs. "something else" representative of C++)
> is vastly more horrid than bad C, which can be horrid. > Use of C++ by the inexperienced is usually scary.
Agreed.
> And you'll be unpleasantly surprised if you say > accidentally drag in the C++ library functions for > stream IO into a small micro...
Yes, but that's true if you drag many C standard library functions into that same small micro. I think writing a standard library is a great exercise for developers approaching a new processor. It gives you a quick feel of what various "typical" operations cost. E.g., looking at the code produced by the compiler for many of math.h can quickly assuage -- or reinforce -- fears about using floating point math in a design.
> Hope that helps ! > Best Regards, Dave > > PS: If anybody knows of a well-written doc discussing > C++ for embedded in depth, we'd be much obliged !
I'll search for the cache analysis I mentioned above. Sure would be nice to have google running on my repository! :-/
Reply by Paul Gotch April 1, 20102010-04-01
d_s_klein <d_s_klein@yahoo.com> wrote:
> Any idea what I should be doing with the .tgz file I downloaded from > keil.com? The one that they were required to publish because of the > GPL code in their ARM compiler?
Which tgz file? Do you mean using uVision with CodeSourcery G++ Lite? The ARM compiler distributed with the latest version of uVision is a customised version of the ARM Compiler (http://www.arm.com/products/tools/arm-compiler.php) and is not based on GPL code. -p -- Paul Gotch --------------------------------------------------------------------
Reply by Paul Gotch April 1, 20102010-04-01
Dave Nadler <drn@nadler.com> wrote:
> No, it is their own implementation, and is not based on GCC. > They claim C++ is validated with Plum-Hall, but do not publish the > test results.
> ARM publishes the same compiler with additional chips supported > in a different package, but it is still based on the proprietary > Keil compiler and not GCC.
The compiler bundled uVision is a slightly customised version of the ARM Compiler which is also part of RVDS. http://www.arm.com/products/tools/arm-compiler.php After the acquisition of Keil by ARM the use of the original Keil C compiler for ARM has been superseded by the use of the ARM Compiler (formerly RVCT) which is a full optimising C and C++ compiler. -p -- Paul Gotch --------------------------------------------------------------------
Reply by Dave Nadler April 1, 20102010-04-01
On Apr 1, 1:24=A0am, hamilton <hamil...@nothere.com> wrote:
> On 3/31/2010 7:11 PM, D Yuniskis wrote: > > > hamilton wrote: > >> Are there any web sites available that compares the amount of overhead > >> C++ carries compared to just plain C ? > > > In what context? I.e., if you "write C in C++" what > > overhead did you anticipate? > > > I've often wanted to recode an existing project in C (or C++) > > to compare the overall size/speed/etc. with C++ (or C). > > But, even that wold be an unfair comparison as you (at least, *I*) > > approach designs in C (C++) differently than I do in C++ (C). > > Yes, good point. > > Most new "embedded programmers" are from the desktop world. > > I would like to know, as you stated, what would be the overhead for the > same program using C++ constructs. > > By your comment, I doubt too many programmers know that there is a > difference. > > I'll look over the Keil web site and see if there is anything there. > > thanks > > hamilton
Comparing C and C++ is a bit of apples and oranges. Properly written C++ can reduce source code size, reduce execution size and time, improve maintainability. Bad C++ is vastly more horrid than bad C, which can be horrid. Use of C++ by the inexperienced is usually scary. And you'll be unpleasantly surprised if you say accidentally drag in the C++ library functions for stream IO into a small micro... Hope that helps ! Best Regards, Dave PS: If anybody knows of a well-written doc discussing C++ for embedded in depth, we'd be much obliged !
Reply by hamilton April 1, 20102010-04-01
On 3/31/2010 7:11 PM, D Yuniskis wrote:
> hamilton wrote: >> Are there any web sites available that compares the amount of overhead >> C++ carries compared to just plain C ? > > In what context? I.e., if you "write C in C++" what > overhead did you anticipate? > > I've often wanted to recode an existing project in C (or C++) > to compare the overall size/speed/etc. with C++ (or C). > But, even that wold be an unfair comparison as you (at least, *I*) > approach designs in C (C++) differently than I do in C++ (C).
Yes, good point. Most new "embedded programmers" are from the desktop world. I would like to know, as you stated, what would be the overhead for the same program using C++ constructs. By your comment, I doubt too many programmers know that there is a difference. I'll look over the Keil web site and see if there is anything there. thanks hamilton
Reply by D Yuniskis March 31, 20102010-03-31
hamilton wrote:
> Are there any web sites available that compares the amount of overhead > C++ carries compared to just plain C ?
In what context? I.e., if you "write C in C++" what overhead did you anticipate? I've often wanted to recode an existing project in C (or C++) to compare the overall size/speed/etc. with C++ (or C). But, even that wold be an unfair comparison as you (at least, *I*) approach designs in C (C++) differently than I do in C++ (C).
Reply by hamilton March 31, 20102010-03-31
On 3/31/2010 12:53 PM, Dave Nadler wrote:
> On Mar 31, 12:54 pm, d_s_klein<d_s_kl...@yahoo.com> wrote: >> On Mar 30, 3:06 pm, Hans-Bernhard Br&#4294967295;ker<HBBroe...@t-online.de> >> wrote: >> >>> d_s_klein wrote: >>>> Last time I checked, the Keil chain was a commercialized version of >>>> the GNU compiler. >> >>> Then either your check was rather completely flawed, or your memory is. >> >> I've forgotten things, and made mistakes before. >> >> Any idea what I should be doing with the .tgz file I downloaded from >> keil.com? The one that they were required to publish because of the >> GPL code in their ARM compiler? >> >> Regards, >> RK. > > While I'm waiting for the Keil folks to call back, > I'd sure appreciate any feedback from folks > with C++ experience using the current Keil > product... > > Thanks ! > Best Regards, Dave
Are there any web sites available that compares the amount of overhead C++ carries compared to just plain C ? hamilton
Reply by Dave Nadler March 31, 20102010-03-31
On Mar 30, 12:12=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
> Last time I checked, the Keil chain was a commercialized version of > the GNU compiler.
No, it is their own implementation, and is not based on GCC. They claim C++ is validated with Plum-Hall, but do not publish the test results. ARM publishes the same compiler with additional chips supported in a different package, but it is still based on the proprietary Keil compiler and not GCC. Hope that clears it up a bit, Best Regards, Dave
Reply by Dave Nadler March 31, 20102010-03-31
On Mar 31, 12:54=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
> On Mar 30, 3:06=A0pm, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de> > wrote: > > > d_s_klein wrote: > > > Last time I checked, the Keil chain was a commercialized version of > > > the GNU compiler. > > > Then either your check was rather completely flawed, or your memory is. > > I've forgotten things, and made mistakes before. > > Any idea what I should be doing with the .tgz file I downloaded from > keil.com? =A0The one that they were required to publish because of the > GPL code in their ARM compiler? > > Regards, > RK.
While I'm waiting for the Keil folks to call back, I'd sure appreciate any feedback from folks with C++ experience using the current Keil product... Thanks ! Best Regards, Dave
Reply by d_s_klein March 31, 20102010-03-31
On Mar 30, 3:06=A0pm, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> d_s_klein wrote: > > Last time I checked, the Keil chain was a commercialized version of > > the GNU compiler. > > Then either your check was rather completely flawed, or your memory is. >
I've forgotten things, and made mistakes before. Any idea what I should be doing with the .tgz file I downloaded from keil.com? The one that they were required to publish because of the GPL code in their ARM compiler? Regards, RK.