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

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

gcc targets an enormous number of architectures, and nobody can
reasonably expect it to be the best compiler for all of them.
Nonetheless it remains the de facto standard on many architectures
simply because it does a pretty good and reliable job. 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 don't know whether
> they have changed them to be the default since then, but that would be
> the obvious thing to do - I can't imagine anybody remember even half
> of them! I also wonder whether the latest GCC has finally dropped that
> expensive 60's style frame pointer...
> 
> Wilco

Wilco Dijkstra wrote:
> "Andras Tantos" <andras_tantos@yahoo.com> wrote in message
> news:42d6fc61$1@news.microsoft.com...
> 
> 
>>If that's true (half the codesize just by switching compilers) I have a hard
>>time imagining that only be due to miss-optimizations. There's a
>>little-known fact of GCC: by default they put all non-referenced functions
>>in modules into the final binary. This is due to their default sectioning of
>>the object modules. To enable 'garbage-collection', you would have to
>>specify:
>>
>>-fdata-sections -ffunction-sections for the compiler and
>>--gc-sections for the linker
> 
> 
> Shouldn't the compiler and linker do this automatically? Removing
> unused functions is an essential feature that should be on by default.
> 
> 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. I don't know whether
> they have changed them to be the default since then, but that would be
> the obvious thing to do - I can't imagine anybody remember even half
> of them! I also wonder whether the latest GCC has finally dropped that
> expensive 60's style frame pointer...
> 

I'd like to see how the other compiler compares with
GCC and option -Os. When looking at the generated
assembly code (-S or -Wa,-ahlms), it's hard to believe
that a compiler could generate 50 % smaller code
if it compiles it all.

-- 

Tauno Voipio
tauno voipio (at) iki fi

"Andras Tantos" <andras_tantos@yahoo.com> wrote in message
news:42d6fc61$1@news.microsoft.com...

> If that's true (half the codesize just by switching compilers) I have a hard
> time imagining that only be due to miss-optimizations. There's a
> little-known fact of GCC: by default they put all non-referenced functions
> in modules into the final binary. This is due to their default sectioning of
> the object modules. To enable 'garbage-collection', you would have to
> specify:
>
> -fdata-sections -ffunction-sections for the compiler and
> --gc-sections for the linker

Shouldn't the compiler and linker do this automatically? Removing
unused functions is an essential feature that should be on by default.

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. I don't know whether
they have changed them to be the default since then, but that would be
the obvious thing to do - I can't imagine anybody remember even half
of them! I also wonder whether the latest GCC has finally dropped that
expensive 60's style frame pointer...

Wilco

"Tsvetan Usunov" <tusunov@my-deja.com> wrote in message
news:dd52331e.0507150259.24d67db5@posting.google.com...
> Chris Hills <chris@phaedsys.org> wrote in message
news:<yY6+VkG+gs1CFAs3@phaedsys.demon.co.uk>...
>
> > It still doesn't get away from the fact that the they reckon just be
> > recompiling with a commercial compiler instead of GNU the code size was
> > halved.
>
> It's hard to believe this, all our tests show that GCC produces almost
> same or little bigger code size than the commercial compilers in most
> of the cases. There are specific situations where GCC produces same or

On which architecture? GCC is embarassingly behind the best commercial
compilers, especially on ARM, and it is questionable whether it could ever
reduce the gap. My figures show it is at least 8 years behind state of the art -
the code the latest GCC produces for Thumb is worse than that of 8+ year old
ARM compilers, and Thumb code produced by GCC is *larger* than ARM
code produced by the ARM compiler... Performance is about as bad as its
codesize.

So I can believe halving the code is quite feasible - you can save about
30% in the compiler, and the rest is likely due to the libraries.

> less sized code, there are others when GCC produces bigger code -
> everything depend on how much time you have spent to learn how your
> compiler assembly your code, where it puts the function parameters,
> how it compiles "case" and "if" statements etc. and to know where what
> to use.

You should not need to change your code to suit your compiler - a good
compiler can produce high quality code from any source, whether good
or bad. Of course well-written source will produce good code on any
compiler.

> On top of this in some commercial compilers when you put the highest
> optimization possible your code will stop work or start behave weird
> ;) so you should use the optimization with extra care (!) and spent
> more time on testing.

This is not true in general. In many compilers all (or most) optimizations
are enabled by default - there is no point in adding optimizations if you
then don't enable them! Many of the problems with optimizations are
caused by programmers writing illegal C/C++ and expecting the compiler
to not break their program. Any optimizations that go beyond the standard
(eg. assume no aliasing) are typically well documented, and are only for
programmers who know what they are doing.

> So bottom line is that GCC is doing just fine, but I can't say that
> there is decent ARM debugger on the market though which to work
> flawless in Windows environment (or I do asking too much ... ;)

GCC is just fine if you don't require the best compiler. You get what
you pay for - it's that simple.

Wilco

Chris Hills <chris@phaedsys.org> wrote in message news:<yY6+VkG+gs1CFAs3@phaedsys.demon.co.uk>...

> It still doesn't get away from the fact that the they reckon just be
> recompiling with a commercial compiler instead of GNU the code size was
> halved.

It's hard to believe this, all our tests show that GCC produces almost
same or little bigger code size than the commercial compilers in most
of the cases. There are specific situations where GCC produces same or
less sized code, there are others when GCC produces bigger code -
everything depend on how much time you have spent to learn how your
compiler assembly your code, where it puts the function parameters,
how it compiles "case" and "if" statements etc. and to know where what
to use.
I'm not so good assembly writer as assembly needs you to be quite
focused when you write or you easily shoot your leg, but few years ago
I had to write CRC code for AVR assembler, then out of couriousity
re-wrote the same on C and compiled with AVR GCC - it made the code
1/2 size than my original assembly code(!).
On top of this in some commercial compilers when you put the highest
optimization possible your code will stop work or start behave weird
;) so you should use the optimization with extra care (!) and spent
more time on testing.

So bottom line is that GCC is doing just fine, but I can't say that
there is decent ARM debugger on the market though which to work
flawless in Windows environment (or I do asking too much ... ;)


Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430 
(http://www.olimex.com/dev)

Andras Tantos wrote:
> >>Yes, or just semi-competent programmers. I picked up a firmware project
> >>recently (in C) and fully expect to be able to *halve* the code size
> >>with a bit of obvious refactoring.
> >
> > It still doesn't get away from the fact that the they reckon just be
> > recompiling with a commercial compiler instead of GNU the code size was
> > halved.
>
> If that's true (half the codesize just by switching compilers) I have a hard
> time imagining that only be due to miss-optimizations.

It's certainly implausible on any architecture I'm familiar with, but I
defer to Mr Hills' ARM-specific knowledge.

> There's a
> little-known fact of GCC: by default they put all non-referenced functions
> in modules into the final binary. This is due to their default sectioning of
> the object modules. To enable 'garbage-collection', you would have to
> specify:
>
> -fdata-sections -ffunction-sections for the compiler and
> --gc-sections for the linker
> 
> Do you know if they did that?
> 
> Regards,
> Andras Tantos