ARM Development Tools

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

Translate This Thread From English to

Threaded View
We have ARM's compiler/assembler/linker, currently ADS 1.1, from a
third party vendor with a proprietary OS and debugger.  No IDE is
included with the ARM tools.

We now have the opportunity to upgrade our development seats to either
ADS 1.2 or RealView.

I haven't been able to find any comparisons on ARM's web site as to
the differences between ADS 1.2 and RealView.

I would appreciate any links to comparisons between the two tool sets.

I would also appreciate any experiences or opinions from anyone who
has used both tool sets, on the differences between them and which
they prefer.

In both cases, these will be command line tools used from a make file,
so differences between the CodeWarrior and RealView IDEs are not a
consideration, just in the tools themselves.

Thanks,

--
Jack Klein
Home: http://JK-Technology.Com
We've slightly trimmed the long signature. Click to see the full one.
Re: ARM Development Tools

Quoted text here. Click to load it

Try the RVCT 2 FAQ

http://www.arm.com/support/rvct2_faq

The major enhancements of RVCT 2 over the compilers included in ADS 1.2
are:
- Full ISO C++ Support by way of the EDG (Edison Design Group) front-end
(including namespaces, templates, intelligent implementation of Run-Time
Type Information (RTTI), but excluding exceptions - this is planned for
RVCT 2.1)
- Typically 5% performance improvement for ARM-state code (compiled with
armcc --arm -Otime -cpu ARM9E)
- Typically 2% code size reduction for Thumb-state code (compiled with
armcc --thumb -Ospace -cpu ARM9E)
- Support for ARM Architecture v6
- Compliance with the ARM C/C++ Embedded Application Binary Interface
(EABI)
- ARM and Thumb compilation per-function (using "#pragma arm" and
"#pragma thumb")
- Five floating-point models (selected with "--fpmode")
- Re-engineered Inline Assembler and new Embedded Assembler

Quoted text here. Click to load it

RVDS 2.0 includes ADS 1.2 within itself see:

http://www.arm.com/devtools/RVDeveloperSuite

So if you upgrade to that then you can use either compiler as your whim
takes you.

Re: ARM Development Tools

"Paul"  wrote in message

Quoted text here. Click to load it

Would I be entirely wrong (or just plain overly cynical) to read those lines
as: "increases code size for ARM-state code" and "increases execution time
for Thumb-state code".  The 2% just doesn't seem worthy of mention
otherwise.

Cheers,
Alf
--
snipped-for-privacy@remove.the.obvious.ieee.org


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com ).
We've slightly trimmed the long signature. Click to see the full one.
Re: ARM Development Tools
Quoted text here. Click to load it

If you're compiling ARM you probably want fast code; if you're compiling
THUMB, you probably want compressed code.



Re: ARM Development Tools

Quoted text here. Click to load it

I think you'd be overly cynical :)

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

Re: ARM Development Tools

Quoted text here. Click to load it
lines

You must have seen too many optimistic marketing claims to be that
cynical...
This one is correct, and yes you're wrong.

It's not widely known, but it is a fact that most compiler optimizations
make
code faster as well as smaller. So smaller code almost always means faster
code,
and faster code means smaller code. Even optimizations that are
traditionally
seen as being bad for codesize (like inlining) can actually improve codesize
significantly. I've seen large C++ applications improve by between 10 and
20%
(over not inlining at all or always inlining when 'inline' is used).

It is also possible to tradeoff a codesize gain against performance. Say
you've
got a 2% codesize and a 3% performance improvement. You may then find an
optimization that gives 2% performance but costs 1% in codesize. Then you
have an overall 5% performance improvement yet still a 1% codesize gain.

Quoted text here. Click to load it

Thumb is widely known for it's compact code, so improving this widens the
gap. It also allows you to put in a few more features in your ROM/flash.
8MBytes is common nowadays, so 2% means an extra 80000 instructions -
that's a few more games or annoying ringtones in your mobile!

Wilco



Re: ARM Development Tools

Quoted text here. Click to load it

The Eschalot has a cute take on that "stinky" problem:

http://www.TheEschalot.com/mobile-rola-smellephone.html

;-)

Re: ARM Development Tools

Quoted text here. Click to load it

The C compiler also uses the EDG frontend. The most notable drawback of the
EDG frontend is that you get a totally different set of diagnostics (inferior
IMO - I've yet to see a compiler as satisfyingly strict as Norcroft, with
such a firm grasp of what is and isn't valid C). It's sad that ARM feel they
no longer have the resources to maintain their own compiler.

Quoted text here. Click to load it

By which they mean they've changed the calling standard. Again. Maybe that's
why they haven't got time to work on the compiler core :)

Quoted text here. Click to load it

The joy of standards - you've just got so many of them.

Quoted text here. Click to load it

The inline assembler still does the same job but has had to be re-engineered
to fit into the EDG frontend - there's no benefit to users, as far as i know.
You lose the ability to use real physical registers and real LDM and STM
instructions.

The embedded assembler is a bit odd. What it does is allow you to write:

__asm int fred(void)
{
   blah blah blah
}

and the stuff inside the curly braces goes to armasm and gets spat out in a
separate object file, which the compiler then does a partial link with (if I
understand correctly). There's no direct interaction between the assembler
source and C source, except that you can include C constant expressions in
the assembler with a magic keyword (potentially useful for offsetof and
sizeof), and it has gone through the C preprocessor.

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd                                   Tel: +44 (0) 1223 503464
We've slightly trimmed the long signature. Click to see the full one.
Re: ARM Development Tools
Apologies for the thread drift...

On Wed, 29 Oct 2003 14:34:34 GMT, Kevin Bracey

[...]
Quoted text here. Click to load it

I've got compilers for about 6 or 7 different micros currently
installed on my system.  The quality of their diagnostics varies
widely (even wildly), with the worst being Cosmic's 6808 compiler, the
best being avr-gcc.

The most amusing, perhaps, is an older version of Microsoft C which
will generate a warning for

   extern void fn(unsigned char x);

   void test(void)
   {
      fn(0);
   }

on the call to fn, because conversion of the int 0 to unsigned char
may lose sign information or value bits.

So I use lint (PC-lint, to be specific) to check my code, and turn the
warning level down on the compilers themselves so my code will compile
clean (without warnings).  Helps to make the code more portable as
well as clean.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: ARM Development Tools
Quoted text here. Click to load it

C++ is an absolute nightmare to parse, C isn't remotely as hard but there
some corner cases where the standard is open to interpretation. Maintaining
the existing parser for C and using EDG for C++ wouldn't be workable. I
expect you would have to pay substanially more for the compiler if it had a
custom C++ front end.

Quoted text here. Click to load it

That's a bit harsh. The ATCPS doesn't specify enough to allow mix and match
of object code produced by different compilers and doesn't say anything
about C++ ABI issues. EABI builds upon various standards such as ATCPS, ELF,
DWARF etc. to make guarantees about what will and won't work between object
producers and consumers.

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

Re: ARM Development Tools
Quoted text here. Click to load it

The new EABI simply provides better alignment of large types doesn't it?
Besides, there's a command line swith to continue using the ADS EABI if you
need to.

Quoted text here. Click to load it



Re: ARM Development Tools
Quoted text here. Click to load it

The C++ compiler supplied with RVCT 2.0 is far supperior to ADS 1.2;
however, you can't actually use it with the IDE supplied with ADS 1.2!!!

To use the RVCT 2.0 tools, you have a few options (all unacceptable in my
opinion):

1) No IDE
Back to the coomand line for project management; gruesome for anything but
trivial projects.

2) Visual Studio Custom Build Steps
Gruesome for anything but trivial projects

3) RealView Debugger
Great debugger, but minimalist and painful project management; gruesome for
anything but trivial projects.


Tim Clacy



Re: ARM Development Tools
Quoted text here. Click to load it

His original post said that he would be using the tools via the command line
from makefiles therefore the lack if an IDE is not relevant in this
particular case.

-p
--
Paul Gotch                              Personal: snipped-for-privacy@gotches.com
 "What goes up must come down, ask any system administrator
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline