Recommendations for ARM compilers

On 18 Jun 2005 13:27:56 +0100 (BST), paulg@at-cantab-dot.net wrote in
comp.sys.arm:

> In comp.sys.arm Jack Klein <jackklein@spamcop.net> wrote:
> > I am following up on my own post because several people who were kind
> > enough to answer me asked about the problems we had with the ARM ADS
> > 1.1 tools.
> 
> For reference from the compiler/linker point of view
> 
> ADS 1.1 -> ADS 1.2 -> RVCT 1.2 -> RVCT 2.0 -> RVCT 2.1 -> RVCT 2.2
> 
> So ADS 1.1 is 2 or 3 generations behind the current tools depending on how
> you cound. A large number of new features have been added since ADS 1.1 and
> lots of bugs have been fixed.
> 
> > somewhere around (but not exactly) 256 files, somehow the linker
> > garbled one file name and threw out an error about being unable to
> > find the object file.
> 
> > We fixed that one after I posted to these two groups and somebody
> > suggested linking each set of related files into a library, and having
> 
> Did you report the problem to ARM? In any case this sounds as though it has
> long since been fixed.

   [snip]

We bought the tools through an ARM reselling third-party, and ARM will
not support them directly when you do this.  For a variety of reasons,
including the total incompetence of their support, we have decided
that we do not wish to continue dealing with this vendor.

ARM RVCT is quite expensive, and I am unsure about how well it will
work with our BDI2000 JTAG debuggers, which we are quite happy with
and not planning to replace.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

On Thu, 16 Jun 2005 22:30:31 -0500, Jack Klein <jackklein@spamcop.net>
wrote:

>I would appreciate any recommendations or experiences good or bad with
>tool sets, we can check out the debugger and flash support issues with
>the tool vendors.

You could always try gcc and the GNU toolchain. Get the source and compile
yourself (using either Cygnus libs or MingW on Windows), or visit
www.microcross.com for ready-to-go Windows binaries.

I'm using the Microcross tools, which came bundled with Netsilicon's Net+OS,
and I've never had any problems with them.

Mit freundlichen Gr&#4294967295;&#4294967295;en

Frank-Christian Kr&#4294967295;gel

Jack Klein wrote:
> We've just released a product with an ARM920T (Atmel's AT91RM9200).
> We are not happy with the tools and tool vendor we used.  The vendor
> is an ARM reseller, and the package we have includes the ADS 1.1
> compiler/linker and the vendor's own debugger.
> 
> We have found that ADS 1.1 is buggy, and the vendor's debugger is
> really poor.  ADS 1.2 did not fix these bugs.
> 
> Now that we've released the first model of the product, we have a
> little time before additional models, new accessories, etc., and we
> can investigate changing tools.
> 
> So I am interested in recommendations for commercial (not gcc, thank
> you) C compiler and tool packages.
> 
> A few more specifics:
> 
> 1.  No ARM9 specific code is used, the binaries could run on an ARM7.
> 
> 2.  No Thumb code, full 32-bit all the way.
> 
> 3.  We own several Abatron BDI2000 Ethernet JTAG debuggers (and really
> like them!), so we need tools that support it and allow programming
> off-chip flash through the debugger.
> 
> I would appreciate any recommendations or experiences good or bad with
> tool sets, we can check out the debugger and flash support issues with
> the tool vendors.
> 
> Thanks,

I've had excellent luck with IAR...  Although expensive, they have 
support beyond all others.

James Kosin

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:ma67b11sitj009tr58ct9r4a7t01k2m3th@4ax.com...
> I am following up on my own post because several people who were kind
> enough to answer me asked about the problems we had with the ARM ADS
> 1.1 tools.

Thanks for the explanation, see my responses below.

I agree with Paul that it's best to report any bugs you find. Bugs in compilers
are generally very rare (MUCH rarer than the bugs in the code it is compiling,
more like 1 in a million rather than 1 in 1000), but they do occur in all.
Usually the first time I test a new compiler on my test suites I find several
problems - and that's just the internal errors or crashes while compiling the
code (not counting syntax errors as no 2 compilers accept identical syntax...).

Reporting bugs gives the vendor a chance to improve the quality of their
product, which in the end benefits all customers. You would typically be
given a workaround if there is any (which is safer and often less intrusive
than inventing your own workarounds). Many vendors supply free patch
releases which just contain bugfixes, so it is always recommended to
upgrade to the latest available.

> 1.  We have a large application and as more of the features were added
> and the number of source files grew, we ran into a linker problem.  At
> somewhere around (but not exactly) 256 files, somehow the linker
> garbled one file name and threw out an error about being unable to
> find the object file.

This sounds like you ran into the command-line length limit in Windows.
The solution is to use via files which have no limit.

> 2.  We had a real nasty problem with pointers to members of
> structures.  Our architecture, originally developed on a 32-bit x86
> processor for a different RTOS, used message queues for inter task
> communication.

<sniped code example>

> The ADS 1.1 compiler GOT THE ADDRESS WRONG.  It was off by 4 or 8, I
> forget which.  We walked through the code at the assembly level with
> the debugger.  When it came to taking the address of a member of a
> structure from a pointer to the structure, IT JUST PLAIN ADDED THE
> WRONG OFFSET.
>
> We did try ADS 1.2 on this one, and it had the same problem.

This sounds unlikely, if something as basic as taking the address of a structure
field would be wrong, not a lot of code would work (ADS1.2 is used in
many current mobiles, which do appear to work most of the time...). The
particular circumstances are most likely a lot more complicated than you
describe. Did you manage to narrow it down to a small example that
demonstrates the problem? I am interested in seeing it (apply the obvious
transformation to get my email address).

> 3.  We only bumped into this one a few weeks ago:

<snipped example>

> If I remember correctly, the initialization of some_name to FALSE (0),
> did not happen.  Unless the condition was true, setting it to TRUE
> (1), it remain uninitialized and had random garbage in it.

Again it sounds unlikely the circumstances are as trivial as you describe.
Compilers don't remove initializations unless they are redundant. A far
more likely scenario is that the variable got corrupted later. Do you have
a small example for this one too?

> We did not try ADS 1.2 on problems number 1 and 3, but it did not fix
> number 2.  At that point we had lost enough time to be seriously
> behind schedule and decided we could live with the problems we knew
> and had workarounds for.  We didn't have time to try out other tools
> and make a change without blowing the release data.

Note there are several patch releases available for ADS1.1 and 1.2 on the
ARM website, so it would have been worth trying out those. If all that failed
and you couldn't get a satisfactory answer from your vendor, it would have
been reasonable to tell ARM support about your issues - I'm sure they would
be sympathetic.

Wilco

"Frank-Christian Kruegel" <dontmailme@news.invalid> wrote in message 
news:42b58f8b.50944343@xeon.intern.istda.com...

snip

> You could always try gcc and the GNU toolchain. Get the source and compile
> yourself (using either Cygnus libs or MingW on Windows), or visit
> www.microcross.com for ready-to-go Windows binaries.
>
> I'm using the Microcross tools, which came bundled with Netsilicon's 
> Net+OS,
> and I've never had any problems with them.
>
> Mit freundlichen Gr&#4294967295;&#4294967295;en
>
> Frank-Christian Kr&#4294967295;gel

I'd add a vote here for GNU and Microcross, I've been using their 
distribution of the GNU tools for the ARM (and also for the SH) for several 
releases (GNU 2.95.2 throgh 3.4) and their support has been excellent. I've 
only found one bug which they confirmed and found a workaround for within 24 
hours and corrected on their next release.

I've also used the tools from www.gnuarm.org as well without any problems 
(but no support).

Stan Katz

You may want to try AMPC at http://www.axiomsol.com
It's a C to Java Bytecode compiler
that runs on JVM enabled devices (including ARM based systems).

Napi

>> We did try ADS 1.2 on this one, and it had the same problem.
>This sounds unlikely, if something as basic as taking the address of a structure
>field would be wrong, not a lot of code would work (ADS1.2 is used in
>many current mobiles, which do appear to work most of the time...). The
>particular circumstances are most likely a lot more complicated than you
>describe.

I had a similar problem when a '_packed' qualifier was involved. The
structure
was declared as _packed and then a pointer to its member was passed
to a function as a parameter. Since the function knew nothing about
the _packed, it expected that 32-bit value to be aligned on a word
boundary,
which was not the case.
Rewriting the function declaration as void func(_packed uint32_t *)
solved
the problem.

"tum_" <atoumantsev_spam@mail.ru> wrote in message
news:1119265641.390254.28120@f14g2000cwb.googlegroups.com...
> >> We did try ADS 1.2 on this one, and it had the same problem.
> >This sounds unlikely, if something as basic as taking the address of a
structure
> >field would be wrong, not a lot of code would work (ADS1.2 is used in
> >many current mobiles, which do appear to work most of the time...). The
> >particular circumstances are most likely a lot more complicated than you
> >describe.
>
> I had a similar problem when a '_packed' qualifier was involved. The
> structure
> was declared as _packed and then a pointer to its member was passed
> to a function as a parameter. Since the function knew nothing about
> the _packed, it expected that 32-bit value to be aligned on a word
> boundary,
> which was not the case.
> Rewriting the function declaration as void func(_packed uint32_t *)
> solved
> the problem.

surely taking the address of a _packed member should yield a _packed
pointer. passing that to a function requiring a non-packed pointer should
surely report a warning at least.

Peter

>surely taking the address of a _packed member should yield a _packed
>pointer. passing that to a function requiring a non-packed pointer should
>surely report a warning at least.

There was no warning. And it's a good question to compiler writers
whether it should have been there. AFAIK, this '_packed' thing
is not properly standardized.

On 20 Jun 2005 "tum_" <atoumantsev_spam@mail.ru> wrote:

>>> We did try ADS 1.2 on this one, and it had the same problem.
>> This sounds unlikely, if something as basic as taking the address of a
>> structure field would be wrong, not a lot of code would work (ADS1.2 is
>> used in many current mobiles, which do appear to work most of the
>> time...). The particular circumstances are most likely a lot more
>> complicated than you describe.
> 
> I had a similar problem when a '_packed' qualifier was involved. The
> structure
> was declared as _packed and then a pointer to its member was passed
> to a function as a parameter. Since the function knew nothing about
> the _packed, it expected that 32-bit value to be aligned on a word
> boundary,
> which was not the case.
> Rewriting the function declaration as void func(_packed uint32_t *)
> solved
> the problem.

Please can you ensure you don't remove the attribution lines ("xxx wrote:"),
as it makes the posts difficult to follow.

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/