C++ support in ARMCC (Keil) compiler/toolchain ?

Last time I checked, the Keil chain was a commercialized version of the GNU compiler.

When I do embedded C++, I get GCC from GNU and build it for my target. I've never had that take more than 1/2 a day.

The ARM is a very well supported target in the GCC tool chain.

RK RK

Then either your check was rather completely flawed, or your memory is.

Keil _tolerates_ people using GCC as a compiler for ARM projects within their IDE to some extent, but that's about all the relation they ever had to GNU tools.

Keil had their own C compiler for ARMs, but that was basically abandoned after ARM took over Keil a while ago. Nowadays, the Keil ARM compiler is ARM's own one.

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

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

Are there any web sites available that compares the amount of overhead C++ carries compared to just plain C ?

hamilton

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 !

The compiler bundled uVision is a slightly customised version of the ARM Compiler which is also part of RVDS.

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

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

-p

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++)

Agreed.

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.

I'll search for the cache analysis I mentioned above. Sure would be nice to have google running on my repository! :-/