ARM Development Tools

Jack Klein wrote in news: snipped-for-privacy@4ax.com:

Try the RVCT 2 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

RVDS 2.0 includes ADS 1.2 within itself see:

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

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

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).
Version: 6.0.528 / Virus Database: 324 - Release Date: 16/10/2003

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

I think you'd be overly cynical :)

-p

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

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: paulg@gotches.com
 "What goes up must come down, ask any system administrator
--------------------------------------------------------------------

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.

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

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

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
182-190 Newmarket Road                        Fax: +44 (0) 1223 503458
Cambridge, CB5 8HE, United Kingdom            WWW: http://www.tematic.com/

[...]

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.

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.

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

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.

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

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.

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

;-)