On 2006-02-17, Boudewijn Dijkstra <b...@indes.com> wrote:

>> And assuming that it does in fact out perform GNU. This is not at all
>> obvious to me, in fact the reverse seems more likely.
>>
>> <http://www.compuphase.com/dhrystone.htm>;
>
> Interesting article, but fairly irrelevant for a comparison between GNU  
> and IAR (which is not Keil).
>
><http://www.iar.se/index.php?show=4082_ENG&reflogin=4082_ENG>;

Follow the link in the article.  It includes benchmark data for
IAR and ARM, as well as KEIL.  GCC beat IAR quite soundly on
both codesize and Dhrystone performance.  In face, IAR was by
far the worst on code size, and tied for last on execution
speed.

                     Image size          Dhrystones/sec

  GCC ARM              4536                 51,488
  GCC Thumb            3660                 44,239
  IAR                 19892                 40,983
  Keil                10330                 39,370
  ARM ADS             10256                 59,382

-- 
Grant Edwards                   grante             Yow!  Don't hit me!! I'm in
                                  at               the Twilight Zone!!!
                               visi.com            

Op Fri, 17 Feb 2006 16:22:49 +0100 schreef Grant Edwards <g...@visi.com>:
> On 2006-02-17, Boudewijn Dijkstra <b...@indes.com> wrote:
>
>>> And assuming that it does in fact out perform GNU. This is not at all
>>> obvious to me, in fact the reverse seems more likely.
>>>
>>> <http://www.compuphase.com/dhrystone.htm>;
>>
>> Interesting article, but fairly irrelevant for a comparison between GNU
>> and IAR (which is not Keil).

> Follow the link in the article.  It includes benchmark data for
> IAR and ARM, as well as KEIL.  GCC beat IAR quite soundly on
> both codesize and Dhrystone performance.  In face, IAR was by
> far the worst on code size, and tied for last on execution
> speed.
>
>                      Image size          Dhrystones/sec
>
>   GCC ARM              4536                 51,488
>   GCC Thumb            3660                 44,239
>   IAR                 19892                 40,983
>   Keil                10330                 39,370
>   ARM ADS             10256                 59,382

 From the links in the article (still on the Keil website):
"The Dhrystone benchmarks tests the C library as much as it tests the C  
compiler, which may not be fair when many embedded software engineers use  
custom libraries (e.g. for use with an RTOS)."

"Dhrystone consists of standard code and concentrates on string handling.   
It is heavily influenced by hardware and software design, compiler and  
linker options, code optimizing, cache memory, wait states, and integer  
data types."

So the only valid conclusion is that these benchmarks show that GCC is  
quite efficient in string handling.  Whereas the IAR-benchmarks test  
real-world embbedded applications.


>> <http://www.iar.se/index.php?show=4082_ENG&reflogin=4082_ENG>;

Sorry, wrong link.
<http://www.iar.se/p43943/p43943_eng.php>;


-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Boudewijn Dijkstra wrote:

> So the only valid conclusion is that these benchmarks show that GCC is  
> quite efficient in string handling.  Whereas the IAR-benchmarks test  
> real-world embbedded applications.
> <http://www.iar.se/p43943/p43943_eng.php>;

They only show code size... and (see other posts) you can't be sure if 
they've optimised appropriately.

In article <4...@individual.net>, p...@scazon.com says...
> Boudewijn Dijkstra wrote:
> 
> > So the only valid conclusion is that these benchmarks show that GCC is  
> > quite efficient in string handling.  Whereas the IAR-benchmarks test  
> > real-world embbedded applications.
> > <http://www.iar.se/p43943/p43943_eng.php>;
> 
> They only show code size... and (see other posts) you can't be sure if 
> they've optimised appropriately.



..and I'll take this opportunity to point out that GCC supports C++, 
while IAR supports only the Embedded C++ subset, and Keil doesn't 
support it at all (at present).

--Gene

In article <M...@newsgroups.comcast.net>, 
f...@comcast.net says...
> In article <4...@individual.net>, p...@scazon.com says...
> > Boudewijn Dijkstra wrote:
> > 
> > > So the only valid conclusion is that these benchmarks show that GCC is  
> > > quite efficient in string handling.  Whereas the IAR-benchmarks test  
> > > real-world embbedded applications.
> > > <http://www.iar.se/p43943/p43943_eng.php>;
> > 
> > They only show code size... and (see other posts) you can't be sure if 
> > they've optimised appropriately.
> 
> 
> 
> ..and I'll take this opportunity to point out that GCC supports C++, 
> while IAR supports only the Embedded C++ subset, and Keil doesn't 
> support it at all (at present).
> 
If code size and efficiency are important criteria for an embedded 
system, you're probably not going to use C++ or any other object-
oriented language.   I save those languages for the PC where 
memory and processor speed stopped being constraints some years back.

Mark Borgerson

In article <M...@newsgroups.comcast.net>, Mark 
Borgerson <mborgerson.at.comcast.net> says...
> In article <M...@newsgroups.comcast.net>, 
> f...@comcast.net says...
> > In article <4...@individual.net>, p...@scazon.com says...
> > > Boudewijn Dijkstra wrote:
> > > 
> > > > So the only valid conclusion is that these benchmarks show that GCC is  
> > > > quite efficient in string handling.  Whereas the IAR-benchmarks test  
> > > > real-world embbedded applications.
> > > > <http://www.iar.se/p43943/p43943_eng.php>;
> > > 
> > > They only show code size... and (see other posts) you can't be sure if 
> > > they've optimised appropriately.
> > 
> > 
> > 
> > ..and I'll take this opportunity to point out that GCC supports C++, 
> > while IAR supports only the Embedded C++ subset, and Keil doesn't 
> > support it at all (at present).
> > 
> If code size and efficiency are important criteria for an embedded 
> system, you're probably not going to use C++ or any other object-
> oriented language.   I save those languages for the PC where 
> memory and processor speed stopped being constraints some years back.
> 
> Mark Borgerson

[Slaps forehead] Too late, been doing it for years now.
An embedded system can be large and inefficient in ANY language,
and can be fast and compact in C++.

--Gene

On Fri, 17 Feb 2006 15:22:49 -0000, Grant Edwards <g...@visi.com>
wrote:

>On 2006-02-17, Boudewijn Dijkstra <b...@indes.com> wrote:
>
>>> And assuming that it does in fact out perform GNU. This is not at all
>>> obvious to me, in fact the reverse seems more likely.
>>>
>>> <http://www.compuphase.com/dhrystone.htm>;
>>
>> Interesting article, but fairly irrelevant for a comparison between GNU  
>> and IAR (which is not Keil).
>>
>><http://www.iar.se/index.php?show=4082_ENG&reflogin=4082_ENG>;
>
>Follow the link in the article.  It includes benchmark data for
>IAR and ARM, as well as KEIL.  GCC beat IAR quite soundly on
>both codesize and Dhrystone performance.  In face, IAR was by
>far the worst on code size, and tied for last on execution
>speed.
>
>                     Image size          Dhrystones/sec
>
>  GCC ARM              4536                 51,488
>  GCC Thumb            3660                 44,239
>  IAR                 19892                 40,983
>  Keil                10330                 39,370
>  ARM ADS             10256                 59,382


A much better comparison than the Keil comparison can be found at:
http://www.raisonance.com/products/STR7/benchmark.php

It also clearly shows that gcc is quite good when compared with the
other compilers. The biggest problem is that the newlib libraries are
quite big. Porting or writing a library more appropriate to small
embedded systems is all that its needed for gcc.

Regards
  Anton Erasmus

In article <M...@newsgroups.comcast.net>, 
f...@comcast.net says...
> In article <M...@newsgroups.comcast.net>, Mark 
> Borgerson <mborgerson.at.comcast.net> says...
> > In article <M...@newsgroups.comcast.net>, 
> > f...@comcast.net says...
> > > In article <4...@individual.net>, p...@scazon.com says...
> > > > Boudewijn Dijkstra wrote:
> > > > 
> > > > > So the only valid conclusion is that these benchmarks show that GCC is  
> > > > > quite efficient in string handling.  Whereas the IAR-benchmarks test  
> > > > > real-world embbedded applications.
> > > > > <http://www.iar.se/p43943/p43943_eng.php>;
> > > > 
> > > > They only show code size... and (see other posts) you can't be sure if 
> > > > they've optimised appropriately.
> > > 
> > > 
> > > 
> > > ..and I'll take this opportunity to point out that GCC supports C++, 
> > > while IAR supports only the Embedded C++ subset, and Keil doesn't 
> > > support it at all (at present).
> > > 
> > If code size and efficiency are important criteria for an embedded 
> > system, you're probably not going to use C++ or any other object-
> > oriented language.   I save those languages for the PC where 
> > memory and processor speed stopped being constraints some years back.
> > 
> > Mark Borgerson
> 
> [Slaps forehead] Too late, been doing it for years now.
> An embedded system can be large and inefficient in ANY language,
> and can be fast and compact in C++.

I guess that's so.  My own biases may be showing, as I have been working
on embedded systems with less than   64K of code space for most of the
last 20 years.   It's only in the last year or two that I've been using
hardware with the RAM and processor power to make C++ a workable 
alternative  to standard C.   I would guess that writing good C++ for
small systems involves concious decisions to avoid some features that
lead to increased size and slower speed.   But the same is true of 
C.


Mark Borgerson

In article <M...@newsgroups.comcast.net>, Gene S.
Berkowitz <f...@comcast.net> writes
>In article <4...@individual.net>, p...@scazon.com says...
>> Boudewijn Dijkstra wrote:
>> 
>> > So the only valid conclusion is that these benchmarks show that GCC is  
>> > quite efficient in string handling.  Whereas the IAR-benchmarks test  
>> > real-world embbedded applications.
>> > <http://www.iar.se/p43943/p43943_eng.php>;
>> 
>> They only show code size... and (see other posts) you can't be sure if 
>> they've optimised appropriately.
>
>
>
>..and I'll take this opportunity to point out that GCC supports C++, 
>while IAR supports only the Embedded C++ subset, and Keil doesn't 
>support it at all (at present).
>
>--Gene
>


Why do you think EC++ was developed in the first place? (and it wasn't
by IAR)  EC++ is used on systems where full C++ compilers are available
because EC++ is a good idea for embedded systems. There are several
compilers which have a C++/EC++ switch. 

IAR could implement full C++ on several of their targets if they wanted
to and it was a good idea.  

The fact that GCC does not support EC++ is not a plus point for GCC it
is a negative point. 


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c...@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <c...@phaedsys.org> wrote in message 
news:xJGuRTDh+M+D...@phaedsys.demon.co.uk...
> In article <M...@newsgroups.comcast.net>, Gene S.
> Berkowitz <f...@comcast.net> writes
>>In article <4...@individual.net>, p...@scazon.com says...
>>> Boudewijn Dijkstra wrote:
>>>
>>> > So the only valid conclusion is that these benchmarks show that GCC is
>>> > quite efficient in string handling.  Whereas the IAR-benchmarks test
>>> > real-world embbedded applications.
>>> > <http://www.iar.se/p43943/p43943_eng.php>;
>>>
>>> They only show code size... and (see other posts) you can't be sure if
>>> they've optimised appropriately.
>>
>>
>>
>>..and I'll take this opportunity to point out that GCC supports C++,
>>while IAR supports only the Embedded C++ subset, and Keil doesn't
>>support it at all (at present).
>>
>>--Gene
>>
>
>
> Why do you think EC++ was developed in the first place? (and it wasn't
> by IAR)  EC++ is used on systems where full C++ compilers are available
> because EC++ is a good idea for embedded systems. There are several
> compilers which have a C++/EC++ switch.
>
> IAR could implement full C++ on several of their targets if they wanted
> to and it was a good idea.
>
> The fact that GCC does not support EC++ is not a plus point for GCC it
> is a negative point.

I thought EC++ was dead as a standard.