On 2006-02-17, Boudewijn Dijkstra <boudewijn@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
Compiler for AT91 ARM processors
Started by ●February 15, 2006
Reply by ●February 17, 20062006-02-17
Reply by ●February 17, 20062006-02-17
Op Fri, 17 Feb 2006 16:22:49 +0100 schreef Grant Edwards <grante@visi.com>:> On 2006-02-17, Boudewijn Dijkstra <boudewijn@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,382From 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/
Reply by ●February 17, 20062006-02-17
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.
Reply by ●February 18, 20062006-02-18
In article <45mbs0F7btanU1@individual.net>, paul@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
Reply by ●February 18, 20062006-02-18
In article <MPG.1e6079d29d7db054989735@newsgroups.comcast.net>, first.last@comcast.net says...> In article <45mbs0F7btanU1@individual.net>, paul@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
Reply by ●February 18, 20062006-02-18
In article <MPG.1e605b39dcfe687098a12c@newsgroups.comcast.net>, Mark Borgerson <mborgerson.at.comcast.net> says...> In article <MPG.1e6079d29d7db054989735@newsgroups.comcast.net>, > first.last@comcast.net says... > > In article <45mbs0F7btanU1@individual.net>, paul@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
Reply by ●February 18, 20062006-02-18
On Fri, 17 Feb 2006 15:22:49 -0000, Grant Edwards <grante@visi.com> wrote:>On 2006-02-17, Boudewijn Dijkstra <boudewijn@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,382A 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
Reply by ●February 19, 20062006-02-19
In article <MPG.1e608850e9cd7285989736@newsgroups.comcast.net>, first.last@comcast.net says...> In article <MPG.1e605b39dcfe687098a12c@newsgroups.comcast.net>, Mark > Borgerson <mborgerson.at.comcast.net> says... > > In article <MPG.1e6079d29d7db054989735@newsgroups.comcast.net>, > > first.last@comcast.net says... > > > In article <45mbs0F7btanU1@individual.net>, paul@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
Reply by ●February 19, 20062006-02-19
In article <MPG.1e6079d29d7db054989735@newsgroups.comcast.net>, Gene S. Berkowitz <first.last@comcast.net> writes>In article <45mbs0F7btanU1@individual.net>, paul@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 /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 19, 20062006-02-19
"Chris Hills" <chris@phaedsys.org> wrote in message news:xJGuRTDh+M+DFAwY@phaedsys.demon.co.uk...> In article <MPG.1e6079d29d7db054989735@newsgroups.comcast.net>, Gene S. > Berkowitz <first.last@comcast.net> writes >>In article <45mbs0F7btanU1@individual.net>, paul@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.
