Forums

Which GCC Version to use with ARM7 ?

Started by Rasmus Fink May 17, 2006
Hi,

For a new product we are going to use an ARM7 and are now going to make
an important choice : Should we stay with IAR or should we use GCC. We
are current leaning a bit towards GCC but we need som extra input here :

What version should we use ?

3.x.x is not the newest but I beleive many of its bugs are known.
4.1.0 is the newest and generally considered stable.

What are your experiences regarding code density, bugs and snags on the
different versions of GCC ?

Cheers
Rasmus
"Rasmus Fink" <i.hate.spammming@me.dk> wrote in message 
news:446ad00c$0$46988$edfadb0f@dread15.news.tele.dk...
> Hi, > > For a new product we are going to use an ARM7 and are now going to make > an important choice : Should we stay with IAR or should we use GCC. We > are current leaning a bit towards GCC but we need som extra input here : > > What version should we use ? > > 3.x.x is not the newest but I beleive many of its bugs are known. > 4.1.0 is the newest and generally considered stable. > > What are your experiences regarding code density, bugs and snags on the > different versions of GCC ? > > Cheers > Rasmus
I get asked this question a lot as I use several ARM7 compilers. What people normally neglect to say, as you do, is what your criteria for selection is. Cost, usability, vendor support???? I have had no problem with either IAR of GCC V4.x.x (see http://www.gnuarm.org if you are using a Windoze host). IAR *could* save you a lot of time if you want to do some complex debugging, or have many download/debug cycles, and therefore pay for itself many times over. To confuse you more, if this is a commercial venture and you are considering GCC then you might also consider http://www.rowley.co.uk as an alternative. Regards, Richard. http://www.FreeRTOS.org *Now for ARM CORTEX M3!*
Rasmus Fink <i.hate.spammming@me.dk> writes:

> Hi, > > For a new product we are going to use an ARM7 and are now going to make > an important choice : Should we stay with IAR or should we use GCC. We > are current leaning a bit towards GCC but we need som extra input here : > > What version should we use ? > > 3.x.x is not the newest but I beleive many of its bugs are known. > 4.1.0 is the newest and generally considered stable. > > What are your experiences regarding code density, bugs and snags on the > different versions of GCC ?
I don't think I have ever found a bug with gcc-arm. No problems with the compiler, it is excellent. I have been using the GNUARM distribution which comes with "Newlib". What device (ram and rom size) are you targetting? This may affect your library choice. Newlib is very powerful but needs care, and avoidance/replacement of some areas, if using with smaller devices. Rowley Associates <http://www.rowley.co.uk/> package gcc with their own debugger and libraries, this may be an option for you. Not used them but looks good. They sell low cost debugging hardware too it would appear. -- John Devereux
> I don't think I have ever found a bug with gcc-arm.
Some of the earlier 3.x.x versions had big problems in ISR code generation and ARM/THUMB interworking. I think this has been fixed for some time now. Regards, Richard. http://www.FreeRTOS.org *Now for ARM CORTEX M3!*
"Richard" <nospam@thanks.com> wrote in message
news:aBBag.70601$wl.46470@text.news.blueyonder.co.uk...
> > I don't think I have ever found a bug with gcc-arm. > > Some of the earlier 3.x.x versions had big problems in ISR code generation > and ARM/THUMB interworking. I think this has been fixed for some time
now. Pre-3.4.x had very poor Thumb code generation (not much optimization, lots of unnecessary moves etc) but has improved dramatically. I use 3.4.3 and 4.1.0 with little to choose - 99% thumb. When targetting ARM7 with no cache Thumb is almost always a performance win as well as a space win. Peter
Thanks for the input, guys.

It's nice to hear that the 4.x.x is considered stable not only by its 
authors. Have any of you compared the code size generated by V3.x.x vs 
4.x.x ?

The device is a AT91SAM7S256, so code space is right now not really an 
issue, _YET_ - but the expected product life time is ~7 years, so much 
can still happen...

/Rasmus

Richard wrote:
>> I don't think I have ever found a bug with gcc-arm. > > Some of the earlier 3.x.x versions had big problems in ISR code generation > and ARM/THUMB interworking. I think this has been fixed for some time now. > > Regards, > Richard. > > http://www.FreeRTOS.org > *Now for ARM CORTEX M3!* > >
"Rasmus Fink" <rfi@lortemail.dk> wrote in message
news:446aec08$0$47058$edfadb0f@dread15.news.tele.dk...
> Thanks for the input, guys. > > It's nice to hear that the 4.x.x is considered stable not only by its > authors. Have any of you compared the code size generated by V3.x.x vs > 4.x.x ? > > The device is a AT91SAM7S256, so code space is right now not really an > issue, _YET_ - but the expected product life time is ~7 years, so much > can still happen... > > /Rasmus > > Richard wrote: > >> I don't think I have ever found a bug with gcc-arm. > > > > Some of the earlier 3.x.x versions had big problems in ISR code
generation
> > and ARM/THUMB interworking. I think this has been fixed for some time
now.
> >
I found 4.1.0 to be a tiny bit bigger than 3.4.3 but also to feel a bit faster. I'm guessing a few things product inline code rather than call support routines resulting in a little bloat in return for speed. Peter
"John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message 
news:87r72t9h2x.fsf@cordelia.devereux.me.uk...
> Rasmus Fink <i.hate.spammming@me.dk> writes: > >> Hi,
<SNIP>
> Rowley Associates <http://www.rowley.co.uk/> package gcc with their > own debugger and libraries, this may be an option for you. Not used > them but looks good. They sell low cost debugging hardware too it > would appear. > > -- > > John Devereux
For GNU tools we have used both Rowley and Microcross. Of the two we find the Microcross to be generally better. The IDE for debugging seems rather finicky on the Rowley. The linker config is also better on the Microcross. -- Scott Validated Software Corp.
Peter Dickerson wrote:
> "Rasmus Fink" <rfi@lortemail.dk> wrote in message > news:446aec08$0$47058$edfadb0f@dread15.news.tele.dk... >> Thanks for the input, guys. >> >> It's nice to hear that the 4.x.x is considered stable not only by its >> authors. Have any of you compared the code size generated by V3.x.x vs >> 4.x.x ? >> >> The device is a AT91SAM7S256, so code space is right now not really an >> issue, _YET_ - but the expected product life time is ~7 years, so much >> can still happen... >> >> /Rasmus >> >> Richard wrote: >>>> I don't think I have ever found a bug with gcc-arm. >>> Some of the earlier 3.x.x versions had big problems in ISR code > generation >>> and ARM/THUMB interworking. I think this has been fixed for some time > now. > > I found 4.1.0 to be a tiny bit bigger than 3.4.3 but also to feel a bit > faster. I'm guessing a few things product inline code rather than call > support routines resulting in a little bloat in return for speed. > > Peter >
For smaller programs, gcc 4.1 has the potential to produce smaller and faster code by compiling the entire program at once, letting it do inter-procedural optimisations even across modules.
David Brown <david@westcontrol.removethisbit.com> writes:

> > For smaller programs, gcc 4.1 has the potential to produce smaller and > faster code by compiling the entire program at once, letting it do > inter-procedural optimisations even across modules.
Something related to this that I found makes a big difference for me is the compiler switches: -ffunction-sections -fdata-sections -Wl,--gc-sections This puts every function and every data object into its own section. The -gc-sections link option then strips out sections that are not used. This happens even if they are global and appear in the same module (source file) as items that *are* used. You also need to modify the link control file changing *(.data) to *(.data.*) and *(.text) to *(.text.*) To pick up the modified section names. This then allows you e.g. to write libraries with lots of extra functions in them, many of which functions might not get used in every application. This seems to work fine in 3.4 (as well as 4.1, presumably). -- John Devereux