1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

ARM Development Tools

Discussion in 'Embedded' started by Jack Klein, Oct 29, 2003.

  1. Jack Klein

    Jack Klein Guest

    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
    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++ ftp://snurse-l.org/pub/acllc-c++/faq
     
    Jack Klein, Oct 29, 2003
    #1
    1. Advertisements

  2. Jack Klein

    Paul Guest

    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
    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.
     
    Paul, Oct 29, 2003
    #2
    1. Advertisements

  3. Jack Klein

    Tim Clacy Guest

    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
     
    Tim Clacy, Oct 29, 2003
    #3
  4. Jack Klein

    Unbeliever Guest

    "Paul" wrote in message
    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
     
    Unbeliever, Oct 29, 2003
    #4
  5. Jack Klein

    Tim Clacy Guest

    If you're compiling ARM you probably want fast code; if you're compiling
    THUMB, you probably want compressed code.
     
    Tim Clacy, Oct 29, 2003
    #5
  6. Jack Klein

    paulg Guest

    I think you'd be overly cynical :)

    -p
     
    paulg, Oct 29, 2003
    #6
  7. Jack Klein

    paulg Guest

    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
     
    paulg, Oct 29, 2003
    #7
  8. Jack Klein

    Kevin Bracey Guest

    In message <AjGnb.5065$>
    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, Oct 29, 2003
    #8
  9. Jack Klein

    Dave Hansen Guest

    Apologies for the thread drift...

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

    [...]
    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
     
    Dave Hansen, Oct 29, 2003
    #9
  10. Jack Klein

    Wilco Guest

    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
     
    Wilco, Oct 29, 2003
    #10
  11. Jack Klein

    paulg Guest

    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
     
    paulg, Oct 30, 2003
    #11
  12. Jack Klein

    Tim Clacy Guest

    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.
     
    Tim Clacy, Oct 31, 2003
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.