So you think that suggesting assembler is Off topic, and not sensible? 
When you ask for advise to get the most compressed code from a system, 
even though you specifically wanted a compiler option, the ONLY real 
answer is to use assembler.

Just as Paul wants to put all the myths about GCC to bed, lets do the 
same for assembler/C.

The ONLY rational reason for refusing to consider assembler in a size 
constrained application, where you feel that using a compiler will 
possibly exceed available memory is the lack of confidence to take 
advantage of it.

Using Pauls data. The difference between IAR and RAL is trivial. If you 
were beyond memory limits with either of these compilers, as your 
original post suggests might happen, then a new compiler isn't going to 
solve your problem.

Your only other option is to move to a processor with more memory. A 
drastic move in most cases

Although perhaps a little flippant, my comment was meant quite 
seriously, to off handedly dismiss the use of any tool is poor 
engineering practice in my opinion. I have NEVER dismissed C, I use it 
on PC applications all the time, I heve never even dismissed the 
possibility of using it on an MSP430. I just see it as having more 
disadvantages than advantages for the systems I design. If the day ever 
comes where I have a system to design that doesn't need to be efficient 
I'll use C just for the added experience.

If I thought that Prolog would produce a better result for my client I 
would use it.

Al



rattencremesuppe wrote:
> Hi Shaun,
> 
> 
>>I have done a comparison between GCC 3.2.3 and the IAR compiler
> 
> that was
> 
>>packaged with my FET kit. (I don't know what version)
>>
>>GCC produced significantly smaller code, as the IAR compiler pulled
> 
> in
> 
>>library functions to handle shift operations and simple integer
> 
> maths.
> 
> Thank you very much for your answer. I didn't really expect anymore to
> get a sensible on-topic reply to my question and was about to
> unsubscribe.
> Now I'm convinced that this mailing list can still be helpful.
> 
> Thanks,
> Patrick
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

Andreas, 

> > I pick patricia.  Tried to compile, but
again, the GCC library is 
> > lacking rudimentary things such as sscanf and gets, unless 
> I can find 
> > them somewhere else.  Ok, need to get on, so comment out the scanf 
> > stuff.
> > 
> > In the end:
> > 
> > GCC code+const: 4,396
> > RAL code+const: 2,924
> 
> I finally found out why GCC performed so bad in your tests: 
> the benchmarks contain quite a lot of unused functions, and 
> GCC before 3.4 has the strange habit of not removing them 
> from the linked object.

It's a bummer, isn't it?  All that time it's been in development
too...
;-)

> If I do it manually I get 3244 bytes; 

And who would want to do that manually...

> with printf removed it is 1458. 

Bust we're ~1600 bytes with printf *in* vs GCC's 3244, so we're
still
half the size of GCC. 

> Comparing such small programs with linked printf
is IMO a bit 
> questionable because the implementations usually have 
> different functional ranges, and if one is a few bytes larger 
> than the other this makes 20% in a small program like this, 
> but is negligable in a full x*10K project).

...but you can't have it both ways again.  The first project was fairly
big, the order of 40K which is 2/3 of a 60K device--but you discounted
that with the "unoptimized float library" card.  Having produced an
integer-only-no-data-no-library version, CrossWorks is still half the
size of GCC.

I selected another benchmark from the set and CrossWorks still produces
smaller code than GCC, even after your plucking and manually massaging
the code.  I don't think that GCC producing twice the amount of code as
CrossWorks is "negligible", and CrossWorks has more than a 20%
advantage
over GCC on both these samples.  With all library code removed, on the
large benchmark of 2/3 of the memory capacity of an MSP, other compilers
still beat GCC.

No two ways about it, however you slice and dice the data: GCC isn't as
efficient as IAR's EW430 product nor our CrossWorks product, but is fine
for some projects. If GCC always produced the best code, tool companies
would go out of business overnight--it hasn't happened, and I don't
expect it to happed any time soon.

Let's just put this to bed; the original question is well and truly
answered, and the answer is certainly not GCC (as demonstrated).

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors 

Paul Curtis wrote:

>>with printf removed it is 1458. 
> 
> 
> Bust we're ~1600 bytes with printf *in* vs GCC's 3244, so
we're still
> half the size of GCC. 

I would still like to know how much of this is printf code, if it isn't 
too much work.

> No two ways about it, however you slice and dice
the data: GCC isn't as
> efficient as IAR's EW430 product nor our CrossWorks product, but is
fine
> for some projects. If GCC always produced the best code, tool companies
> would go out of business overnight--it hasn't happened, and I
don't
> expect it to happed any time soon.

I don't think that GCC produces the best code, but _in my experience_ 
the code was usually about as good as IAR's, rather better than worse, 
and definetely far from being 100% larger; and I don't seem to be the 
only one with this impression. Maybe it's because I don't know all the

optimization tricks with IAR, maybe it's because an image processing 
algorithm does not represent the typical MSP430 application... who knows.

Andreas, 

> > No two ways about it, however you slice and
dice the data: 
> GCC isn't 
> > as efficient as IAR's EW430 product nor our CrossWorks 
> product, but is 
> > fine for some projects. If GCC always produced the best code, tool 
> > companies would go out of business overnight--it hasn't 
> happened, and 
> > I don't expect it to happed any time soon.
> 
> I don't think that GCC produces the best code, but _in my 
> experience_ the code was usually about as good as IAR's, 
> rather better than worse, and definetely far from being 100% 
> larger; and I don't seem to be the only one with this 
> impression. Maybe it's because I don't know all the 
> optimization tricks with IAR, maybe it's because an image 
> processing algorithm does not represent the typical MSP430 
> application... who knows.

The thing is, GCC does not have an overall view of the application being
built.  It builds it in bits and stitches the bits together.  CrossWorks
does the same but has more intelligence.  CrossWorks can do things on
basic blocks and extended basic blocks that would defeat many other
linkers: inter-module code motion, inter-module cross-jumping,
inter-module code factoring, inter-module tail merging, inter-module
code hoisting, inter-module block locality improvement.  The list of
optimizations that are done post-compile is quite extensive now.

If you don't do this style of optimization, you're stuck in 80s
Unixland
and are not in the game.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors 

Hi,

Ok, I'll bite.

> So you think that suggesting assembler is Off
topic, and not sensible? 

My question was "which C-compiler produces the smallest code size" and
yes, suggesting assembler here is off-topic, obviously.

It's like asking, for example, which car uses the least amount of
fuel, and one recommends a bicycle. Just to have a stupid analogy 
(yes, car analogies suck, I know ;))

> The ONLY rational reason for refusing to consider
assembler in a size 
> constrained application, where you feel that using a compiler will 
> possibly exceed available memory is the lack of confidence to take 
> advantage of it.

There are reasons why I have to use C in this project.

If I'm running short of flash space, I can still re-code big functions
in assembler. But I want to do this only as the last resort, because
there are other requirements as well (development time,
maintainability, portability) for which C is better suited than assembler.

Sorry, I didn't want to start a flame war here ;)

Regards,
Patrick

Hi Patrick,
 
Read my previous mail on this topic.
It is not necessary to rewrite in asm (but is still a good ideea), just try to
read the asm that the compiler generate and adjust the C code to obtain better
results. You'll find a lot of stupid things in there. The main point is
that a compiler cannot see your goal (and the resources invested in this kind of
compilers are low so compilers are smart by this measure). 
One hint: try to use inline as much as possible and leave the compiler do his
job. It worked for me and IAR.
One obs: a smaller code (even in C) means loosing "(development time,
maintainability, portability)" 

Have fun doing it,
Avram

 


rattencremesuppe <tricknology@tric...> wrote:
Hi,

Ok, I'll bite.

> So you think that suggesting assembler is Off
topic, and not sensible? 

My question was "which C-compiler produces the smallest code size" and
yes, suggesting assembler here is off-topic, obviously.

It's like asking, for example, which car uses the least amount of
fuel, and one recommends a bicycle. Just to have a stupid analogy 
(yes, car analogies suck, I know ;))

> The ONLY rational reason for refusing to consider
assembler in a size 
> constrained application, where you feel that using a compiler will 
> possibly exceed available memory is the lack of confidence to take 
> advantage of it.

There are reasons why I have to use C in this project.

If I'm running short of flash space, I can still re-code big functions
in assembler. But I want to do this only as the last resort, because
there are other requirements as well (development time,
maintainability, portability) for which C is better suited than assembler.

Sorry, I didn't want to start a flame war here ;)

Regards,
Patrick

__________________________________________________
 

Hi,

> > I finally found out why GCC performed so bad
in your tests: 
> > the benchmarks contain quite a lot of unused functions, and 
> > GCC before 3.4 has the strange habit of not removing them 
> > from the linked object.
> 
> It's a bummer, isn't it?  All that time it's been in
development too...

Thats really strange ;)
I wonder if it takes more than a static callgraph to implement it...

> Let's just put this to bed; the original
question is well and truly
> answered, and the answer is certainly not GCC (as demonstrated).

Perhaps my application is a little bit "special", because I use no
floats and no fancy libraries.

But the thing you mentioned about linker optimisation and inter-module
optimisation could still apply (even if every line of my code is
actually used).

I just noticed that your company offers a full-featured 30-day eval
version.
So I will give it a try, as soon as my firmware has ~10K size or
something like that (provided that porting from GCC to crossworks
doesn't require too much work).

Thanks to all who replied,
Patrick

Hi Paul

Is the Ew430 your own compiler or is it a GCC ?
The CrossWorks for ARM is GNU GCC.
What will the CrossWorks for AVR be ....

Best regards

John 

A happy CrossWorks for ARM user ;)

--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> Andreas, 
> 
> > > No two ways about it, however you slice and dice the data: 
> > GCC isn't 
> > > as efficient as IAR's EW430 product nor our CrossWorks 
> > product, but is 
> > > fine for some projects. If GCC always produced the best code,
tool 
> > > companies would go out of business overnight--it hasn't 
> > happened, and 
> > > I don't expect it to happed any time soon.
> > 
> > I don't think that GCC produces the best code, but _in my 
> > experience_ the code was usually about as good as IAR's, 
> > rather better than worse, and definetely far from being 100% 
> > larger; and I don't seem to be the only one with this 
> > impression. Maybe it's because I don't know all the 
> > optimization tricks with IAR, maybe it's because an image 
> > processing algorithm does not represent the typical MSP430 
> > application... who knows.
> 
> The thing is, GCC does not have an overall view of the application being
> built.  It builds it in bits and stitches the bits together.  CrossWorks
> does the same but has more intelligence.  CrossWorks can do things on
> basic blocks and extended basic blocks that would defeat many other
> linkers: inter-module code motion, inter-module cross-jumping,
> inter-module code factoring, inter-module tail merging, inter-module
> code hoisting, inter-module block locality improvement.  The list of
> optimizations that are done post-compile is quite extensive now.
> 
> If you don't do this style of optimization, you're stuck in 80s
Unixland
> and are not in the game.
> 
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors

Hi Paul

Sorry Ew430 is IAR, but I mean CrossWorks 430.

:=
--- In msp430@msp4..., "johnnorgaard2003" <john_2005@c...>
wrote:
> Hi Paul
> 
> Is the Ew430 your own compiler or is it a GCC ?
> The CrossWorks for ARM is GNU GCC.
> What will the CrossWorks for AVR be ....
> 
> Best regards
> 
> John 
> 
> A happy CrossWorks for ARM user ;)
> 
> --- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> > Andreas, 
> > 
> > > > No two ways about it, however you slice and dice the data: 
> > > GCC isn't 
> > > > as efficient as IAR's EW430 product nor our CrossWorks 
> > > product, but is 
> > > > fine for some projects. If GCC always produced the best
code,
tool 
> > > > companies would go out of business
overnight--it hasn't 
> > > happened, and 
> > > > I don't expect it to happed any time soon.
> > > 
> > > I don't think that GCC produces the best code, but _in my 
> > > experience_ the code was usually about as good as IAR's, 
> > > rather better than worse, and definetely far from being 100% 
> > > larger; and I don't seem to be the only one with this 
> > > impression. Maybe it's because I don't know all the 
> > > optimization tricks with IAR, maybe it's because an image 
> > > processing algorithm does not represent the typical MSP430 
> > > application... who knows.
> > 
> > The thing is, GCC does not have an overall view of the application
being
> > built.  It builds it in bits and stitches the
bits together. 
CrossWorks
> > does the same but has more intelligence. 
CrossWorks can do things on
> > basic blocks and extended basic blocks that would defeat many other
> > linkers: inter-module code motion, inter-module cross-jumping,
> > inter-module code factoring, inter-module tail merging, inter-module
> > code hoisting, inter-module block locality improvement.  The list of
> > optimizations that are done post-compile is quite extensive now.
> > 
> > If you don't do this style of optimization, you're stuck in
80s
Unixland
> > and are not in the game.
> > 
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors

Hi Patrick. I'm certainly not attempting a flame war either, they
serve 
nobody, and lead to ill feeling in the group.

rattencremesuppe wrote:
> Hi,
> 
> Ok, I'll bite.
> 
> 
>>So you think that suggesting assembler is Off topic, and not sensible? 
> 
> 
> My question was "which C-compiler produces the smallest code
size" and
> yes, suggesting assembler here is off-topic, obviously.

Your question was mot quite that, you said:-

"I'm about to start my first MSP430 project. I'll have to write a
fairly complex firmware but can only use the 60K on-chip flash.

I've used the GCC in some Linux projects and while it's a standard and
a portable solution, I suspect that commercial compilers may
outperform it w.r.t smaller code size of compiled C-code.

What compilers do you use, when code size is crucial?"

First paragraph translates. 'I don't have any experience with the 
MSP430, but am about to tackle projects that I expect might exceed the 
maximum memory available.'

AS Andreas (I think it was) suggested, a knowledge of assembler on any 
micro will usually improve your ability to write optimal C for that 
processor.

Second paragraph just translates that you are familiar with GCC, but not 
  compilers from the other vendors for the MSP430, and suspect that GCC 
is not very good at producing small code.

Your third paragraph asks which compiler we (I) use when code size is 
crucial. NOT which compiler produces the smallest code. A subtle but 
major difference.

The real answer is that if code size is crucial don't use a compiler. 
That is the answer I gave. Personally, and from many previous posts I 
believe that IAR or RAL are the two best when it comes to small code 
size and, based on bang for the buck, RAL wins hands down, however 
neither will come as close, especially for a large application, to 
assembler.

> 
> It's like asking, for example, which car uses the least amount of
> fuel, and one recommends a bicycle. Just to have a stupid analogy 
> (yes, car analogies suck, I know ;))

Not quite, it's more like, "My most important specification is fuel 
economy, because I only have $30 in my pocket, and have to drive 1000 
miles, which Humvee is the most economical?" Answer, forget the Humvee, 
buy a Prius, you'll have enough for a maccers on the way, and enough 
change left over to buy your partner a car as well.

Same for my reply, you'll have enough memory left over to add a quick 
game of pong, or space invaders  to the code, and enough money left over 
to buy a laptop to play it on.

> 
> 
>>The ONLY rational reason for refusing to consider assembler in a size 
>>constrained application, where you feel that using a compiler will 
>>possibly exceed available memory is the lack of confidence to take 
>>advantage of it.
> 
> 
> There are reasons why I have to use C in this project.
> 
> If I'm running short of flash space, I can still re-code big functions
> in assembler. But I want to do this only as the last resort, because
> there are other requirements as well (development time,
> maintainability, portability) for which C is better suited than assembler.

The old chestnuts. I reckon that, with a typical design project, from 
initial enquiry to delivered product I'm faster your average bear, the 
code will be highly maintainability, and the protability issue is a myth.

C was simply NOT designed with micros in mind, and, despite being a so 
called standard there are so many implementation issues left open that 
no two compilers are wholly compatible. The number of posts  starting 
"How do I do X in this compiler..." that you meet in every newsgroup, 
for every family is testament to the absolute lack of portability 
between different C compilers, and often between different versions of 
the same compiler.

Finally though I do understand that there are many misguided clients out 
there, convinced by their lack of knowledge that C will solve all their 
problems. ME? at the end of the day its faster to debug my code than 
someone elses.

> 
> Sorry, I didn't want to start a flame war here ;)

Never! It happens, and, when it comes to C vs asm isssues its normally 
myself, aided and abetted by Jon, on many occasions, who takes up the 
banner for asm. It's an old saw horse, and one repeated in all news 
groups, once again, often to the annoyance of many. And it can seem a 
bit religious. For my part I have always hated the fads that pervade 
this industry, and feel that often people are denying themselves the 
opportunity to learn new and valuable skills as a result of dogma. Thus 
I rail against it.

Believe me if someone could produce a C compiler that prodcued code that 
was within 1 or 2% of the size and speed of my hand coded stuff I'd go 
buy it right away. (I don't mean the typical, code me this equation 
challenge, I mean produce me this application). The simple fact is that 
there is nothing that C gains you, or any other language for that 
matter, that can't be done in assembler. the problem is few people are 
taught those skills these days, and learning them is often too expensive 
time wise.

Cheers

Al