Which GCC Version to use with ARM7 ?

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