Recommendations for ARM compilers

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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,
--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: Recommendations for ARM compilers
My suggestion is Keil.

You also can use realtime OS of their production.

Visit www.keil.com

Mickey



Re: Recommendations for ARM compilers
Quoted text here. Click to load it

Have you tried the RVCT compilers? Specifically the latest versions?
 
-p
--
Paul Gotch
CoreSight Tools
We've slightly trimmed the long signature. Click to see the full one.
Re: Recommendations for ARM compilers

Quoted text here. Click to load it

What kind of bugs? ADS1.2 was at the time a big quality improvement
over previous releases, and many people are still using it today despite
its age... (interestingly it still beats the latest GCC!)

I would try out its successor RVCT2.2 which gives an easy upgrade
path, especially if you're using any language extensions. It supports
full C++ which is something ADS wasn't very good at.

Wilco



Re: Recommendations for ARM compilers
Last year I evaluated RVCT, ADS and a few other tool sets for a new project
using an ARM966 based ASIC.  I went with IAR Embedded Workbench for the ARM
and I have been very happy with it.  We use an ARM MultiICE that works ok
and we also use the Segger J-Link that works very well.  IAR has support
for the Abatron BDI2000 using the RDI interface.  They have a free trial
version that you can download if you want to try it out.


Re: Recommendations for ARM compilers

Quoted text here. Click to load it

Using ADS 1.2 (from ARM) on a complex ARM7 right now.  Combination of
Multi-ice and BDI-2000's.  Both worked fine until the hw engineers made some
board changes :(

Otherwise works fine.  I have used another companies version of ADS 1.1 and
don't blame you for wanting to switch.  You can buy the current ARM package
(I think they call it RealView now) and it comes with ADS 1.2 on a separate
CD.

Scott




Re: Recommendations for ARM compilers

Quoted text here. Click to load it
Jack, you may want to give our $199 ARM compiler a test drive. It's
fully functional for 45 days. As for debugger support, we emit Elf/Dwarf
and the current release has been tested with Nohau, Lauterbach, ADS,
etc. In our next update (probably next week), we will also have tested
it against Ashling, GNU Elf/Insight, and CrossStudio. So really, any
Elf/Dwarf debugger should work. Email me if you have any other questions.
--

// richard
http://www.imagecraft.com

Re: Recommendations for ARM compilers
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.

I haven't been working much on the ARM code in the product, I've been
coding for a DSP on another board, but I do remember at least four
specific problems, and I can describe three of them.

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.

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
a final link step that linked all the libraries.  Since out
multi-tasking system is composed of about 35 individual tasks, each in
its own directory, we took that advice and it worked.

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.  I'll show some simplifier code...

Each task defines a message enum:

enum TASK_TYPE { TIMER_MSG, DATA_UPDATE_MSG /* etc. };

...then a structure for the data of each message type:

struct timer_data { uint32_t token; uint32_t time; };
struct update_data { int32_t x_pos; int32_t y_pos; };
/* etc. */

...and finally its overall message structure:

struct my_msg
{
   enum TASK_TYPE msg_type;
   union
   {
      struct timer_data t_data;
      struct update_data u_data;
   };
};

A task blocks on a call to retrieve a pointer to a message structure
from its queue.  When it has a message and it is the highest priority
task ready to run, that call returns, and it dispatches the message to
the proper handler function:

for ( ; ; )
{
   struct my_msg *msg = rtos_get_message(queue_id);
   switch (my_msg->msg_type)
   {
      case TIMER_MSG:
         my_timer_handler(&my_msg->msg_data.t_data);
         break;
      case DATA_UPDATE_MSG:
         my_update_handler(&my_msg->msg_data.u_data);
   }
}

In other words, the handler function is called with a pointer to data
structure member of the union inside the message structure.

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.

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

enum ( FALSE, TRUE } bool_t;

void some_func(void)
{
   bool_t some_name = FALSE;

   if (/* some condition */ && /* some other condition */)
   {
      some_name = TRUE;
   }

   /* code */

   if (bool_t)
   {
      /* code */
   }
}

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.

So we had to change all code like that to this:  

   if (/* some condition */ && /* some other condition */)
   {
      some_name = TRUE;
   }
   else
   {
      some_name = FALSE;
   }

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.

Now that version 1.0 went out the door on time, and we've got a little
breathing space, we want to evaluate other tool sets.

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: Recommendations for ARM compilers
Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Did you report the problem to ARM? In any case this sounds as though it has
long since been fixed.

Quoted text here. Click to load it

Again did you report the problem? Incorrect code generation bugs are taken
extremely seriously.

Quoted text here. Click to load it

Again did you report the problem? This also sounds like it has long since
been fixed.

Quoted text here. Click to load it

It would be to your loss to write off the ARM compiler based on your
experiences of ADS 1.1. Try RVCT 2.2 (part of RVDS 2.2) and report any
problems to ARM support.

-p
--
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

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

Quoted text here. Click to load it

   [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
We've slightly trimmed the long signature. Click to see the full one.
Re: Recommendations for ARM compilers

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

<sniped code example>

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

<snipped example>

Quoted text here. Click to load 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?

Quoted text here. Click to load it

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





Re: Recommendations for ARM compilers
Quoted text here. Click to load it

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.


Re: Recommendations for ARM compilers
Quoted text here. Click to load it
structure

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



Re: Recommendations for ARM compilers
Quoted text here. Click to load it

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.


Re: Recommendations for ARM compilers

Quoted text here. Click to load it

Actually it is an error to implicitly cast a packed qualified pointer to a
non-packed pointer. It would be a bug if it allowed you to pass a
packed pointer as if it weren't. Packed behaves a lot like a type
qualifier that sets the natural alignment to 1, so it is quite well specified.
No chance of it getting accepted as in the next C standard of course.

Wilco



Re: Recommendations for ARM compilers

Quoted text here. Click to load it

Mmm, I have to admit I don't know how such a cast can be done.

Quoted text here. Click to load it

That's exactly what happened.
Let's talk (pseudo)C:

typedef __packed struct
{
    uint8_t a[n];
    uint16_t field1;
    uint16_t field2;
    uint16_t field3;
} the_struct;

void update_field( uint16_t * );
...

the_struct THESTRUCT;

...

   // This line does not generate any error/warning
   update_field( &THESTRUCT.field1 );


Re: Recommendations for ARM compilers
atoumantsev snipped-for-privacy@mail.ru says...
Quoted text here. Click to load it

So you are using a non-portable, non-standard and dangerous construct and
the compiler doesn't warn of alignment issues when you do something with
it that violates the processors alignment restrictions.

Why do you feel the need to use packed in the first place?  Every time
I've looked at it, it appeared to be far more trouble than it was worth.  
Most of the adavantages of it appear to be illusory to me.

Robert

Re: Recommendations for ARM compilers


Quoted text here. Click to load it

well, it's not my code. But it's a real life code, part of
the large software project that has been ported from an 8-bit
platform to ARM (and then from ADS 1.2 to GCC).

Quoted text here. Click to load it

That's what I'm actually interested in: should there be a warning
for such a construct?

Quoted text here. Click to load it

I don't feel the need for it at all in this particular example.
What seems to have happened is: in the process of porting
from 8-bit to 32-bit, it became clear that certain structures
has to be __packed (for whatever reason) to make the code work
correctly,
it was also considered worthwhile to apply __packed to all the
structures
in the project to save memory. Luckily, it was the only bug introduced
this way.

[and my apologies to the OP: my remark has led the discussion away from
the original goal (as it always happens in a newsgroup)]


Re: Recommendations for ARM compilers
Quoted text here. Click to load it

A very bad idea if the structure already has aligned fields or the space
saving is very small. Most compilers will generate 4 byte accesses for a
32bit word in a packed structure, and performance will be abysmal.

---druck

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

Re: Recommendations for ARM compilers

Quoted text here. Click to load it

Indeed, and for this reason it is generally a bad idea to pack all fields in
a structure. It is much better to pack just the fields that need to be packed.
This way most fields will be aligned to their natural alignment and thus
accessing them is efficient.

Packing all fields or assuming all pointers have lower than natural alignment
is only feasible on CPUs that have unaligned support in hardware, such as all
new ARM cores.

Wilco



Site Timeline