Buying IAR C

Hello,

Does anyone know how much can cost IAR C for a single 8-bit platform?

formatting link
How can I buy it ?

IAR C seems to be by far the greatest C compiler for embedded platforms, at least for the weaker 8-bit platforms like '51 and PIC. It is the only only one that can generate reentrable code on these platforms, having good IDE, debugger, profiler as well.

Regards, Nickolai Leschov St.-Petersburg, Russia

Reply to
Nickolai Leschov
Loading thread data ...

formatting link

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

8-bit micros, each with their pros and cons. Figure out what microcontrollers you are using, what your requirements are for your tools, and what your budget is, and look around at all options before leaping to conclusions about suppliers. IAR is certainly a major player in this field, but it is by no means alone.
Reply to
David Brown

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

formatting link

Reply to
Vladimir Vassilevsky

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

Reply to
Meindert Sprang

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

formatting link

Reply to
Vladimir Vassilevsky

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

Nickolai Leschov wrote:

formatting link

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

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

Reply to
Mark Borgerson

greatest for

comparison

I

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.

Reply to
Moon Shine

formatting link

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.

Reply to
Neil

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.

--
Regards,
Richard.
 Click to see the full signature
Reply to
FreeRTOS.org

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?

--
Grant Edwards                   grante             Yow!  Actually, what
                                  at               I'd like is a little toy
 Click to see the full signature
Reply to
Grant Edwards

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.

--
Regards,
Richard.
 Click to see the full signature
Reply to
FreeRTOS.org

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

Reply to
Wilco Dijkstra

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]

--
Regards,
Richard.
 Click to see the full signature
Reply to
FreeRTOS.org

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

Reply to
Wilco Dijkstra

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.

Reply to
David Brown

GCC doesn't implement sprintf().

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

--
Grant Edwards                   grante             Yow! ... I want a COLOR
                                  at               T.V. and a VIBRATING BED!!!
 Click to see the full signature
Reply to
Grant Edwards

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?

--
Grant Edwards                   grante             Yow! I've got an IDEA!!
                                  at               Why don't I STARE at you
 Click to see the full signature
Reply to
Grant Edwards

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.

--
Grant Edwards                   grante             Yow! over in west
                                  at               Philadelphia a puppy is
 Click to see the full signature
Reply to
Grant Edwards

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

Reply to
Wilco Dijkstra

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.