Buying IAR C

There is no "greatest" compiler - there are many available for different

The typical price for a commertial embedded compiler package is at the order of $2400.

snipped-for-privacy@iar.com

IAR is the greatest compiler for AVR, but definitely not the greatest for the others.

The best compilers are Keil for x51 and Hitech for PIC.

Eh?

Vladimir Vassilevsky DSP and Mixed Signal Consultant

Would it be possible to questimate the code size IAR generates in comparison with ICCAVR? I have a project which completely fills an ATMega162 and I would like to have some space for extra features without a hardware redesign.

Meindert

It was discussed many times; IIRC IAR beats AVRGCC and ICC in the code size by a factor of 1.3 to 1.5. The cross call optimization of IAR is very impressive.

You can probably gain several kbytes of space.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

B26C60D6FB2112CAE994D09F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit

Nickolai Leschov wrote:

The keyword is the definition of "greatest". In the compilers that we directly compete, we are finding that they typically generate about 30% more code than we on the same application.

Walter Banks

I don't know about ICCAVR vs IAR, but a colleague told me that IAR allowed a level of detail in linking and code placement on the MSP430 that made a project feasible with IAR that didn't fit with other compilers.

Mark Borgerson

greatest for

comparison

I can give you a comparison of WINAVR (GCC) vs. IAR on AVR platform. With optimization turned on, IAR code was 30% smaller than GCC.

If you Need re-entrable code on a PIC or 8052 you may have not chosen the best CPU for the job. Keil for the 8052 will generate re-entrant code if you tell it too. The program will be bigger, slow and use more RAM. The compiler can not make magic. The compiler is limit by the architecture.

Make sure you are comparing like for like. By default IAR will remove unreferenced code, while GCC will not, although I'm sure IAR will still be smaller.

Also the GCC libraries can get pulled in which make the code size larger.

Right. GCC will remove unreachable code, and it can be told to remove unreferences functions and variables at link time, but you have to add a couple command-line flags to enable that feature.

What libraries? I'm only aware of one: libgcc.

You mean that IAR doesn't have a library of compiler functions to implement operations that the underlying architecture doesn't support directly (e.g. 32 bit multiply on an AVR)? The IAR compiler emits in-line code for _everything_ including floating point operations?

I was really just referring to the GCC implementation of functions such as sprintf(), which are not necessarily optimal for small embedded systems and can suddenly cause your code size to increase if you are not careful.

sprintf(), which are not necessarily

increase if you are not careful.

Or something basic like 64-bit division or floating point operations where GCC's libraries use a generic implementation rather than one optimised for the target architecture. None of the GCC libraries I tried are suitable for embedded systems, not even newlib. They seem to be made for big systems running Linux, not systems where every byte and cycle counts.

Wilco

Which is why people like Rowley (CrossWorks) provide their own library implementations. [although your point of view is a little stronger than my own, I would hopefully never design a system where I was down to counting every byte and cycle anyway, although I accept in severely cost sensitive apps this might not be feasible]

implementations.

Indeed. One of the ARM libraries I wrote for GCC is about 6 times as small as the standard one. With that kind of improvement possible it is a no brainer...

hopefully never design a system where I was

cost sensitive apps this might not be

It's actually surprising how much money companies are willing to pay for optimizations that make their code a few percent faster/smaller. On multi million units the cost saving of avoiding a larger flash (or faster core) is more than worth it. I often go to great lengths in saving bytes and cycles for customers, including things like compressing the intialization data of the initialized data section to reduce flash footprint...

Wilco

avrlibc is the main library for avr-gcc. It has certainly been the case that some parts of the library were bigger than necessary, although the most recent release has improved things (the floating point code has been re-written, for example).

No, he means that the equivalent functions in the avrlibc libraries are bigger than those in the IAR libraries. In some cases at least, it is true - although there has been substantial improvement recently. How large or small an issue it is will depend very much on the actual routines used.

GCC doesn't implement sprintf().

I presume you're talking about glibc, and that's not part of gcc.

sprintf(), which are not necessarily

increase if you are not careful.

What "gcc libraries" are you talking about? Are we talking about libc implimentations or about compiler code generation?

Oh. I wasn't aware that avrlibc was part of (or somehow tied to gcc).

OK, the thread seems to have morphed from comparing compilers to comparing libc implementations.

sprintf(), which are not necessarily

increase if you are not careful.

I already mentioned Newlib which is one of the GCC libraries (others are glibc, tinylibc, dietlibc etc). The examples I gave are compiler helper functions which are in the main GCC source tree.

Wilco