The difference between -O1 and -O2 are significant in my testing.
I wonder what is preventing any optimisation from taking place in your
setup.

It will be interesting to get to the bottom of this anomaly.

Regards
Shaun

-----Original Message-----
From: Paul Curtis [mailto:plc@plc@...]
Sent: Wednesday, September 15, 2004 12:40 PM
To: msp430@msp4...
Subject: RE: [msp430] Re: which C-compiler produces the smallest code
size ?


Shaun, 

> That is a shockingly bad result that does not
confirm with 
> what I have observed.
> 
> What version of MSP-GCC are you using?

>msp430-gcc --version
msp430-gcc (GCC) 3.2.3
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

> Have you compiled with the -Os flag for size, or
with -O2 
> flag for greater optimisation?

I said I used -O1.  Using msp430-size to get combined const and code
sizes, and with -mmcu=msp430x149 and various options I get:

-O1              45,286
-Os              45,376
-O1 -Os          45,376
-O2              45,390
-O2 -Os          45,382

Thus, using -O1 and -Os together or -Os on its own is no better than
-O1.  So, -Os is just a no-op as far as I can see.

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



.

 
Yahoo! Groups Links



 


NOTICE OF CONFIDENTIALITY

The information contained in this e-mail message and in the documents
attached herewith (hereinafter "the message") is intended only for
the
individual or the entity named above and is intended to be confidential.

The reading of the message or any retention, copying, dissemination,
distribution, disclosure of the existence of the message or of its contents,
or any other use of the message or any part thereof, by anyone other than
the intended recipient is strictly prohibited.  If you received this message
and you are not the intended recipient or agent responsible for the delivery
of this message to the intended recipient, please refrain from reading it
and notify us immediately by telephone +27 (11) 921-7900, so that we can
co-ordinate with you, erasure of the message.

Although this e-mail and its attachments are believed to be free of any
virus or other defect, it is the responsibility of the recipient to ensure
that they are virus-free, and no responsibility is accepted by this firm for
any loss or damage arising from receipt or use thereof.

Paul Curtis wrote:
> Andreas,
> 
> 
>>>                GCC    IAR      RAL
>>>                      EW430  XWorks
>>>             ------  ------  ------
>>>Code size:   29,998  16,732  16,198
>>>Const ssize: 15,286  15,801  15,770
>>>             ------  ------  ------
>>>             45,284  32,553  31,968
>>>
>>>The interesting thing here is CODE SIZE not CONST SIZE (which is a 
>>>fixed-size array).  The code produced by CrossWorks and by 
>>
>>IAR is half 
>>
>>>the size of GCC.  HALF THE SIZE!  30K vs 16K.  ...and GCC produces 
>>>small code...
>>
>>Interesting. How did you get code size & const size numbers on GCC? 
>>msp430-size shows only the combined size, which is 24514 for 
>>the unlinked object
> 
> 
> Simple, I removed all string constants from the source and removed the
> resized the image arrays to a single byte and recompiled.  Subtract the
> two and you get the appropriate sizes.
> 
> So, 24K for the unlinked object?  Oh, and IAR and CrossWorks still beat
> it when compiling in all their library code *and* all the other

24K _with_ constants.

>>(comparing library function sizes doesn't 
>>really make sense if you want to compare the code generation quality).
> 
> 
> No, you can't have this both ways.  You can't say "well, GCC
has
> unoptimized libraries, so we'll just discount those..." and say
"well,
> code generation quality is really good!" because it's the overall
> package that counts.  There's no getting away from the fact you *need*
> to use those libraries.  I can compare unlinked code sizes too, but it
> makes no odds, GCC is not good in this crap game.

I told you the mspgcc float library was unoptimized and big; so what do 
you want to prove with showing that a program linked to it is big?

Please give me the numbers of an integer example. qsort_small, patricia, 
dijkstra, dhrystone, anything you want, and let's do another comparison.

Shaun Parsons wrote:
> The difference between -O1 and -O2 are significant
in my testing.
> I wonder what is preventing any optimisation from taking place in your
> setup.

I'm sure the optimisation is fine, it's the float library that makes
the 
program so big.

Andreas, 

[ snip - uninteresting stuff removed ]

> I told you the mspgcc float library was
unoptimized and big; 
> so what do you want to prove with showing that a program 
> linked to it is big?

It's relevant for those people who are making a decision not solely
based on unlinked code sizes.  So, I'll remove all dependencies on
floats and library routines.

> 
> Please give me the numbers of an integer example. 

Sure.

I removed all floats from the code, all printfs, and nearly all constant
data (44 bytes remain) and here's the results:

For a linked application:

GCC, const(44)+code: 22,650  -O1 -Os
RAL, const(44)+code: 12,556

Makes no odds.  GCC is still a pretty awful compiler on this example
without any scent of a float or library routine in the
sources--CrossWorks generates about half what GCC does.  GCC generates
twice as much code as CrossWorks.

I've replaced the zip file at www.rowley.co.uk/msp430/mibench.zip with
the code I used to generate these results.

What can you suggest now that will reduce the 22K of user code that GCC
produces to even compete with the 12K of code that CrossWorks produces?

> qsort_small, patricia, dijkstra, dhrystone,
anything you 
> want, and let's do another comparison.

I've provided numbers for a single benchmark, sure, yet you ignore the
results, evidently.  I've now bent the standard benchmark to your liking
by removing all float code and library code.  The results still stand.

The question is, can GCC generate smaller code for this benchmark than
CrossWorks?  Pick another benchmark, it'll be the same.  CrossWorks will
generate the smallest code of any commercial or free compiler, period.
GCC is just *no* competition in this regard.

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

Andreas, 

> Shaun Parsons wrote:
> > The difference between -O1 and -O2 are significant in my testing.
> > I wonder what is preventing any optimisation from taking 
> place in your 
> > setup.
> 
> I'm sure the optimisation is fine, it's the float library 
> that makes the program so big.

I'm sure it's not.  I'm sure that GCC is a pretty darn useless
compiler
in this example.

-- Paul.

Paul,

i just started using MSPGCC this monday after my project no longer 
fitted into the IAR Kickstart limits. I need to integrate a bluetooth 
stack during the next weeks, which i cannot do using assembler. There is 
already a Crossworks MSP430 installation on my workstation (evaluation, 
now inactive).

Until now my project has about 10 kBytes of firmware, 60 % of that 
handmade in assembler. I ordered the first 200 of my MSP430 hardware 
modules last week and i could not at the same time order a commercial  
MSP430 software package.

So in my case the GNU idea holds perfectly: Basic computer tools should 
be free because they are a part of culture that enables us to do what we 
are educated to do. By the way, there is a special MSPGCC user group 
online with lots of hints. MSPGCC seems to be useful for many people.

I did not meet any true problems until now, except
- the available MSP-Insight debugger GUI seems to be outdated. And
- it will be a pain to transscript existing assembler files to the GCC 
notion, although i somehow
   remember having used something similar in the ADSP VisualDSP 
environment, which is obviously
   based on GCC. If GCC was choosen by Analog Devices for their signal 
processors it should be OK.

Anyway, i will not buy a commercial MSP430 IDE until my project reaches 
the 48K or 60K limit. By then, with the help of MSPGCC it will have 
earned enough money to buy crossworks or some other package. I hope this 
will not take forever and  there will be commercial offers to choose from..

Regards
Dieter Teuchert

Paul Curtis wrote:

>Andreas, 
>
>  
>
>>Shaun Parsons wrote:
>>    
>>
>>>The difference between -O1 and -O2 are significant in my testing.
>>>I wonder what is preventing any optimisation from taking 
>>>      
>>>
>>place in your 
>>    
>>
>>>setup.
>>>      
>>>
>>I'm sure the optimisation is fine, it's the float library 
>>that makes the program so big.
>>    
>>
>
>I'm sure it's not.  I'm sure that GCC is a pretty darn
useless compiler
>in this example.
>
>-- Paul.
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

-- 
Dipl.-Phys. Dieter Teuchert
Software und Systeme
Postanschrift:



Telefon:
Telefax:
EMail Firma:
EMail perslich:
Internet:
	Rommelstr. 6
D-76571 Gaggenau
Germany

+49 7225 989253
+49 7225 989254
info@info...
dieter@diet...
_http://www.cadt.de_

Andreas, 

> I told you the mspgcc float library was
unoptimized and big; 
> so what do you want to prove with showing that a program 
> linked to it is big?
> 
> Please give me the numbers of an integer example. 
> qsort_small, patricia, dijkstra, dhrystone, anything you 
> want, and let's do another comparison.

I pick dijkstra.  Tried to compile it, but looks like MSP430 GCC is not
up to the job, lacking fscanf and the file I/O stuff that it requires.
Tried replacing that with standard printf/scanf, but then stuck because
scanf doesn't seem to be in the MSP430's libc.

Suggestions?  Ok, let's put aside that as GCC as a system isn't man
enough to compile it... Let's "try another benchmark" from your
list.

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

So, GCC still generates 50% code than CrossWorks.  Bother.  Despite my
best efforts to prove otherwise, it looks like we're winning the battle
against GCC.  Sources at www.rowley.co.uk/msp430/patricia.zip.  Again,
the challenge to any GCC user is to compile the patricia code I posted,
*unmodified* and have msp430-size report a number anywhere near the
2,942 number that CrossWorks produces.

On customer code, CrossWorks generates less code than any other
compiler, period, which is what this all started out with.  You're just
not going to get something that does, I know, because I implemented the
compiler, linker, optimizer, and runtime library.

I didn't want this to turn into an advert, I just want to dismiss the
myth that "GCC is a pretty good compiler".  On the whole, it has the
right price, and it has its place.  But, on the other hand, it's not
going to win awards for its code quality.

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

All, 

> 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

After tweaking some compilation options:

> RAL code+const: 1,628

So, how how much more code does GCC produce over CrossWorks?  Only 2.65
times as much.  But yeah, GCC is a good compiler because you get so much
machine code out out of so little source code...  :-)

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

> So in my case the GNU idea holds perfectly: Basic
> computer tools should 
> be free because they are a part of culture that
> enables us to do what we 
> are educated to do. By the way, there is a special
> MSPGCC user group 
> online with lots of hints. MSPGCC seems to be useful
> for many people.

In my case also MSPGCC works fine and the support is
excellent!

> I did not meet any true problems until now, except
> - the available MSP-Insight debugger GUI seems to be
> outdated.

I used the Eclipse GUI instead of Insight ... excellent!


	
		
__________________________________
 

Paul Curtis wrote:
> Andreas, 
> 
> 
>>I told you the mspgcc float library was unoptimized and big; 
>>so what do you want to prove with showing that a program 
>>linked to it is big?
>>
>>Please give me the numbers of an integer example. 
>>qsort_small, patricia, dijkstra, dhrystone, anything you 
>>want, and let's do another comparison.
> 
> 
> I pick dijkstra.  Tried to compile it, but looks like MSP430 GCC is not
> up to the job, lacking fscanf and the file I/O stuff that it requires.
> Tried replacing that with standard printf/scanf, but then stuck because
> scanf doesn't seem to be in the MSP430's libc.
> 
> Suggestions?  Ok, let's put aside that as GCC as a system isn't
man
> enough to compile it... Let's "try another benchmark" from
your list.
> 
> 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. If I 
do it manually I get 3244 bytes; with printf removed it is 1458. 
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).

Andreas