IDE for Atmel ARM processor

"toby" <toby@telegraphics.com.au> wrote in message
news:1121539198.219713.291460@g43g2000cwa.googlegroups.com...
>
>
> Wilco Dijkstra wrote:
> > ...
> > It is well known that the default settings of GCC are terrible. Last year
> > there was a paper on the GCC conference that showed how using 20+
> > options could reduce codesize by 5% on ARM.
>
> Which default settings do you mean? Regarding optimisation, gcc
> "defaults" to -O0 if one forgets to specify anything else.

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.

>Switching to
> -O2 should make at least a 5% difference, but even 5% is well within
> the range of variation I'd expect from different vendors' compilers.

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.

> Few applications
> could not tolerate 5% larger code, and those that cannot, should
> perhaps consider assembler or finding smarter C programmers, since that
> factor alone can certainly account for a 50%+ code bloat even with the
> best available compiler!

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

Wilco Dijkstra wrote:
> "toby" <toby@telegraphics.com.au> wrote in message
> news:1121539198.219713.291460@g43g2000cwa.googlegroups.com...
> >
> >
> > Wilco Dijkstra wrote:
> > > ...
> > > It is well known that the default settings of GCC are terrible. Last year
> > > there was a paper on the GCC conference that showed how using 20+
> > > options could reduce codesize by 5% on ARM.
> >
> > Which default settings do you mean? Regarding optimisation, gcc
> > "defaults" to -O0 if one forgets to specify anything else.
>
> 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).

You could file a bug on that.

> So at least some
> of the gap between GCC and commercial compilers is explained by a
> bad choice of default settings.
>
> >Switching to
> > -O2 should make at least a 5% difference, but even 5% is well within
> > the range of variation I'd expect from different vendors' compilers.
>
> The difference between -O0 and -O2 is much more than 5% - I don't
> have recent numbers, but it is more like 50%.

Yes, I would expect much better than 5%.

>
> The variation between compilers of different vendors (at their best
> settings) is easily over 30% for codesize, and 50% for performance.
>
> > Few applications
> > could not tolerate 5% larger code, and those that cannot, should
> > perhaps consider assembler or finding smarter C programmers, since that
> > factor alone can certainly account for a 50%+ code bloat even with the
> > best available compiler!
>
> 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...

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.

>
> 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.

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

> Of course if the code was designed with
> codesize in mind you may not have a problem in the first place.

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

> 
> Wilco

"toby" <toby@telegraphics.com.au> wrote in message
news:1121569023.660893.100080@z14g2000cwz.googlegroups.com...
> Wilco Dijkstra wrote:
> > "toby" <toby@telegraphics.com.au> wrote in message
> > news:1121539198.219713.291460@g43g2000cwa.googlegroups.com...

> > 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...
>
> 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.

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.

> > 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.
>
> That's less true of microcontrollers than it is of larger systems. It's
> certainly not true of most C programmers :-)

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.

> > Of course if the code was designed with
> > codesize in mind you may not have a problem in the first place.
>
> Compactness is usually a natural side effect of simple design and
> thoughtful modularity.

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

Wilco Dijkstra wrote:
> ...
>
> > > 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.
> >
> > That's less true of microcontrollers than it is of larger systems. It's
> > certainly not true of most C programmers :-)
>
> 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.

That's pretty much what I was saying; although maybe your
generalisation remains true of the "average" assembly programmer. :)
Spend enough time at http://www.hugi.scene.org/compo/hcompo.htm and you
realise it's far from true for top assembly programmers.

>
> 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.
>
> > > Of course if the code was designed with
> > > codesize in mind you may not have a problem in the first place.
> >
> > Compactness is usually a natural side effect of simple design and
> > thoughtful modularity.
>
> 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.

Yes, I have seen this first hand...

--Toby

> 
> Wilco