Can anyone tell me the pros and cons of gcc vs the arm-cc compiler for ARM Cortex M3 development? I understand that the ARM compiler always used to be said to give smaller code size with the downside that it cost a bit more but can anyone tell me whether that is still true in
How do they compare on execution speed ? My application is power sensitive and increased execution speed might pay for a clock speed reduction which could save power so that would be an issue.
Issues like debugger and IDE support are bigger with me than code size and things like standards compliance are also important, also whether there are other snags / advantages of one against the other would be of interest.
If you appreciate a good IDE, the ARM stinks! Also I'm a little bit surprised about their QA department. Last version V-4.53 came up with some peculiar error-messages regarding temporary files. The file failing was changing from compile to compile (without any source changes). When asking Keil about it, they had to admit that it was a known bug in projects which consists of sub-projects. This is several weeks ago, and no new version has appeared. I don't think I would buy a Keil again.....
gcc optimize for size is -Os. For dead code elimination you would also use -ffunction-sections and -fdata-sections, and link with -gc-sections.
I use this to compile (defines and includes removed): C:\Program Files\CodeSourcery\Sourcery G++ Lite\bin\arm-none-eabi-gcc.exe -x c -fpack-struct=1 -c -gdwarf-3 -mcpu=cortex-m3 -mthumb -mfix-cortex-m3-ldrd
I think Tim is correct look carefully for other sources of differences when
10%-20% size difference is seen. I have written a code generator for the Cortex M3 and I would be surprised if the best to worst code generators would make at most a few percent difference in generated code.
It would be interesting to get a measure of the compiler differences to compile the same code including libraries on both compilers. This may or may not be easy.
When comparing IAR for M32C with Renesas HEW for (Renesas) M32C, I saw a size difference within that range too (being IAR the winner). The reason I was told for that --by a Renesas worker-- was that IAR made their libraries in asm, and Renesas made them in C. Go figure.
The sections/gc options are addictive. Once you get used to them, it becomes pretty painful to have to live without them. They make re-using code way easier, and they also make it a lot easier to enable disable features at link time.
Grant Edwards grant.b.edwards Yow! I'm young ... I'm
at HEALTHY ... I can HIKE
Agreed. They're part of my standard compiler option set; the ones that just get carried from project to project. I can't see why you wouldn't use them across the board, especially for an architecture like ARM with function-local constant pooling.
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
A real pain to prove what actually is used or not used when audited for various bodies.
A real pain when someone else picks up the project and has to wade through a large module within a 'library' to check for no side effects. To ensure the compiler is really not missing something it should not.
Never rely on compiler tricks for correct code reduction of unused code, it may change under your feet or between versions and platforms or targets.
What is wrong with writing libraries correctly?
Paul Carpenter | firstname.lastname@example.org
How so? The linker listing shows exactly what's in the executable.
Yet it's OK to rely on linker tricks for correct code reduction of unused code when using libraries? ;)
I don't understand why you call it "compiler tricks". It's very straight forward, and it's the exact same thing that happens with libraries except it also works with non-global objects.
The main thing I found "wrong" was that with the library approach everything has to be in a single, global name space whether it needs to be visible outside the module or not. In my experience, that produces designs that are hard to understand and maintain. You can end up with unintentional interactions between modules because every module has to expose internal names.
With the sections/gc approach, a "module" can have a well-defined set of globally visible names and can still have it's own private name space. And, here's the important part, "private" things within that name space can be "optional" and won't be included in the executable if they are not used.
I never figured out how to do that with libraries.
Grant Edwards grant.b.edwards Yow! My NOSE is NUMB!
Yes and no, if you have a linker listing some bodies over the years I have had folks want be sure what has been removed has no side effects because linker has removed some parts and left references to removed items. I know silly but I get this sort of thing from time to time with various tools and bodies.
a) if you know the 3rd party library has been wriiten that way.
b) if the compiler vendor and 3rd party library co-operate properly in one case it was specific version of compiler for that family and manufacturer's library.
c) They all document and dont let you guess this is the way this library is supposed to be used.
In one case I was working on one of the smallest members of a family and simple code compile would not fit into device, with a few calls to library. Why because nowhere in the documentation or the default builds on compiler for that processor specifically stated should use -gc option.
I believe the 3rd party library code has only really been tested for builds and on largest device in family.
First of all anyone can write BAD libraries in the 90's I saw a PC based library for then employer that always loaded the WHOLE library, no matter if you only used one or all functions.
Yes and no, for some complex RAM based libraries for image processing cryptography, maths functions etc you end up with some library 'globals' whatever you do because you need them.
For board/processor support libraries you will always have some globals even if they are actually constants just for regiosters, bit/bus width etc.
One processor library gets around most of its globals, by ensuring all functions have a parameterof the base address of the I/O unit you want to address. Making it less encapsulated and less portable across the same family or similar families. Why the hell is unit 0,1,2... passed. Especially as you go up famioly trees these days with lots of peripherals and RAM you could well have loadable binary tasks or code segments that could be loaded on any processor, so common encapsulation helps you, especially if the processor has the library in its ROM.
I have not had problems with module libraries. Lots of people do as in my 90's example above.
However what I am finding in lazy DESIGN, so the library gets structured relying on compiler to do all the real work, so the library gets poorly structured, and becomes less portable.
Ends up with being scared of modules and we are getting back to one big file with all the code in.
Paul Carpenter | email@example.com