C++ support in ARMCC (Keil) compiler/toolchain ?
in [Embedded]
|
Prev: Tool Chain for Arm Cortex M3 on Linux Host
Next: Recommendation: Low power microcontroller for battery powered logger
From: Paul Gotch on 1 Apr 2010 10:31 Dave Nadler <drn(a)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 --------------------------------------------------------------------
From: Paul Gotch on 1 Apr 2010 10:42 d_s_klein <d_s_klein(a)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 --------------------------------------------------------------------
From: D Yuniskis on 1 Apr 2010 13:02
Hi Dave, Dave Nadler wrote: > On Apr 1, 1:24 am, hamilton <hamil...(a)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! :-/ |