Using GCC 4.7

[lpcware]

Content originally posted in LPCWare by tentner on Fri Jun 07 01:37:02 MST 2013
Hi,

my project is quite code size restricted. I found that GCC 4.7 (https://launchpad.net/gcc-arm-embedded) produces smaller code than the GCC 4.6.2 supplied with the current version of LPCXpresso. However, simply copying the .exe-files from the 4.7 into the respective folders of the LPCXpresso installation did not work (compilation fails because some files are not found). I guess Code Red has made some change to GCC.

I would like to continue to use the LPCXpresso IDE.

Has anyone managed to use GCC 4.7 together with the IDE, or does anyone know when the next LPCXpresso version will be released and if it will use GCC 4.7?

Regards,

Thomas

[lpcware]

Content originally posted in LPCWare by PorkyBrain on Thu Jul 11 10:10:11 MST 2013
I am very interested in GCC 4.7 because a few meta programming bugs (e.g. static constexpr intitialization) are hampering my creativity.

I would also love to see a better newlib, it seems to use large amounts of resources for no apparent reason some times. See here: http://stackoverflow.com/questions/17515362/lpcxpresso-with-cortex-m3-what-is-libc-alib-a-impure-o-a...

If anyone has any success in getting this installed Please post here, it would be very much appreciated!

[lpcware]

Content originally posted in LPCWare by frame on Fri Jun 07 10:49:52 MST 2013

---

Quote:
I can almost guarantee that the code will NOT be 50% smaller.

---

However, this is possible.
Some high-prized commercial compilers do a rather extensive dead-code elimination by default.
GCC supports this as '-flto' - but only if the compiler was build with LTO support.
And in my experience, there had still been a 20 - 30% difference in code size.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Jun 07 08:09:01 MST 2013
I can almost guarantee that the code will NOT be 50% smaller.

As I said in my original email, I think that any difference will be in library size and if you use Redlib, then it will be quite minimal. My guess is a maximum of 5%, but I will be very interested in your results.

[lpcware]

Content originally posted in LPCWare by tentner on Fri Jun 07 07:45:00 MST 2013
I am not sure if the CORTEX-M branch of gcc can really be called mature. When I hear that KEIL produces 50% smaller code, I would say that there is still room for improvement ;).

I have contacted KEIL to see if I can get a useful eval-version to check if this is correct.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Jun 07 07:38:02 MST 2013
Actually, 1% is still pretty good for a (mature) compiler!

[lpcware]

Content originally posted in LPCWare by tentner on Fri Jun 07 07:26:15 MST 2013
Now I managed to compile to project (more or less). Essentially the code_red-libs were missing, this could be solved by copying them to the respective 4.7.3 folders.

However, 4.7 always used the floating point printf version, I guess the code_red approach for this (CR_INTEGER_PRINTF) is an extension to GCC.

So to make a fair comparison, I used floating point printf for both versions.

Over the complete project, 4.7.3 is (only) 1.0% better than 4.6.2 :(.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Jun 07 03:02:34 MST 2013
4% is a huge gain (for a compiler) between versions and I would be very surprised (but also very pleased) if it amounted to that much over the whole project.

Why are you unable to build the whole project with GCC4.7?

[lpcware]

Content originally posted in LPCWare by tentner on Fri Jun 07 02:42:51 MST 2013
My project is > 100KB, so the lib-size is not really dominating, I guess. Of course this nano-lib would be a benefit, I guess.

I did not manage to compile the complete project, I just compiled some single files and looked at the list-files. My impression was a code size reduction of about 4% (but this is not representative at all), which would be about 4K for free in my project.

I also evaluated the IAR and COSMIC compilers, but there output did not impress me. The KEIL eval version appears to have listing-files disabled, which makes it quite useless for evaluation... But the numbers you mentioned sound impressive.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Jun 07 02:30:57 MST 2013
In my experience, the code size between different compilers is tiny. You find some compilers 'win' with one benchmark but 'lose' with another.

The HUGE difference is almost always caused by libraries.

GCC 4.7 (which I haven't tried) is claiming
* Additional code size optimizations
* Newlib-nano: newlib branch optimized for code size
So there may be some gains from both of these, especially (I suspect) in using newlib-nano when compared with newlib. How much difference this will actually make to your project, only you can tell.

If you have gcc 4.7 installed, why don't you just compile your source with it (from the command line). LPCXpresso generates makefiles, so all you would need to do is change your PATH to use the new compiler.

Perhaps you can tell us the results.

[lpcware]

Content originally posted in LPCWare by frame on Fri Jun 07 02:19:16 MST 2013
I never tried this approach.
And I believe that all gcc variants produce about the same code size,
assuming identical versions and build settings. Differences do often
stem from link-in libraries, which confuse the matter.

From my experience, the Keil compiler is actually the best option
if judged by code density and performance. No wonder, as Keil is owned
by ARM, so one could expect a certain quality.
On the downside, there is of course the heavy price for a license...

I experienced a size reduction to about 50% when switching from gcc to Keil.
In this case, it was Crossworks (commercial product) vs. Keil, and the code sizes
where at about 95kB (Crossworks) and 44kB (Keil) for a non-trivial project size,
and equal build settings.