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