IDE for Atmel ARM processor

I mean starting from -O2 -Os. The settings of Os do not switch on many of the space saving optimizations or switch off optimizations that are bad for codesize (Andras mentioned a few). So at least some of the gap between GCC and commercial compilers is explained by a bad choice of default settings.

The difference between -O0 and -O2 is much more than 5% - I don't have recent numbers, but it is more like 50%.

The variation between compilers of different vendors (at their best settings) is easily over 30% for codesize, and 50% for performance.

I know companies who would do anything to get just a 0.5% codesize improvement so they can add a new feature in their latest phone without increasing the flash size. It all depends...

Anyway finding the best compiler and options is easier compared to rewriting your code for space. Using assembler is never worth the effort - modern compilers generate better code than the average assembly programmer. Of course if the code was designed with codesize in mind you may not have a problem in the first place.

Wilco

Reply to
Wilco Dijkstra
Loading thread data ...

You could file a bug on that.

Yes, I would expect much better than 5%.

Their options remain the same: switch to assembler for all/part; refactor; change compilers. I'd be amazed if they had exhausted all space saving possibilities in the source code.

That's less true of microcontrollers than it is of larger systems. It's certainly not true of most C programmers :-)

Compactness is usually a natural side effect of simple design and thoughtful modularity.

Reply to
toby

This is 16 or 32MBytes of flash, so assembler is obviously out of the question. Improving the source code is not trivial for projects of this size. It turns out it is cheaper/faster/lower risk to upgrade to a compiler which simply squeezes the code by a few more percent.

It depends a lot on which architecture. Compilers on 8/16-bit systems have a difficult task due to the complex instruction sets. 32-bit RISCs make it a lot more difficult for an assembly programmer to beat a good compiler even on small amounts of code.

Few assembly programmers will use global inlining or common subexpression elimination to improve codesize, but compilers can do this routinely and consistently on any amount of code. As compilers get better the usefulness of assembler is restricted to code that is difficult to write in C (eg. process switch) or inner loops where saving a single instruction can speed up the application by a few percent.

Absolutely - and good coding practices. But a lot of code is borrowed from previous projects (because of cost, risk or time to market), and often you have to make the best of what is available.

Wilco

Reply to
Wilco Dijkstra

That's pretty much what I was saying; although maybe your generalisation remains true of the "average" assembly programmer. :) Spend enough time at

formatting link
and you realise it's far from true for top assembly programmers.

Yes, I have seen this first hand...

--Toby

Reply to
toby

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.