EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

Re: IAR workbench or Rowley CrossWorks

Started by sig5...@hotmail.com January 19, 2007
Two years ago when I was testing compilers, I had the IAR kit. I looked at the comparisons too that said this compiler was faster or smaller etc. But ya know, all that really doesn't matter very much when you get down to writing actual code and you run into bugs in the compiler. At that point you just want it to work and all the speed or size comparisons matter very little.

I ran into several bugs in the IAR/EWARM compiler and IAR were not sure when they would get fixed. After spending several frustrating weeks on it, I decided to try the "free-be" GNUARM. It worked right off the bat, and I was able to get my code off the ground much quicker than with IAR. So it didn't seem to make much sense to pay $$$$ for a proprietary compiler with bugs that gave me more grief than the free GNUARM.

I use UltraEdit for my IDE. It has all the features I need, and I use it for many different jobs Verilog, Asm, etc. Most of the IDE's with compilers do not give me what I want and I end up going back to UltraEdit anyway to write my code.

While C is suppose to be portable, that's just not the case. Every compiler has different extensions, pragmas, attributes, etc. I thought it was better to go the GCC route because the compiler supports so many different CPUs.

So for me UltraEdit+GNUARM/GCC was all I needed. It gets the job done. There are bugs and wierd things in GCC too I don't like. But I figure all of the systems have short comings so take the cheapest route. If using IAR would have really been easier or faster, I would have paid the money. But that wasn't the case. For me, a $$$$ compiler better do something a Hell of a lot better than a free one or it just ain't worth the money.

Chris.

An Engineer's Guide to the LPC2100 Series

I couldn't agree more on your point about working with something that
generates bad code: I've used GCC off and on for well over ten years
now, and have never encountered a case of it generating incorrect
code (from correct source that is: plenty of examples of bad code
from bad source!). Contrast this with a couple of cases I've
experienced of commercial compilers generating erroneous code that
took in one case two or three weeks to track down. The cost of that
time made any license fee irrelevant (the irony being of course that
it was the licensed commercial compiler that was causing the problem).

The downside is the extra work involved in setting GCC up for a
particular target and in sourcing an IDE. We use Ashling tools as a
front-end for GCC for LPC2xxx and other ARM work, and are very happy
with them (no connection by the way). For developing commercial
applications, the cost of such tools is worth it, I think, just for
the speed of getting up and running and support when required (though
as I said, I've never had to use support for the core compiler).

While I take your point about 'C' not being portable in general, it
is quite possible to write 'C' that is portable across multiple
platforms and multiple compilers. The keys are to stick to ANSI 'C',
never use compiler extensions, isolate target dependent items to
separate compilation units and generally be aware of what is and
isn't a portable technique. We have a large code base of
communications software that compiles on about six different
compilers on about eight different architectures with no
modifications. Once the support functions for a new platform are
written (e.g. "disable_interrupt" etc.), it's a matter of compile and
go.

As for performance and code size, I've yet to see an "apples to
apples" comparison that showed GCC to be either significantly worse
or better than the best commercial alternative.

Hopefully this experience will be of benefit to anyone making the
choice.

Brendan.

--- In l..., wrote:
>
> Two years ago when I was testing compilers, I had the IAR kit. I
looked at the comparisons too that said this compiler was faster or
smaller etc. But ya know, all that really doesn't matter very much
when you get down to writing actual code and you run into bugs in the
compiler. At that point you just want it to work and all the speed
or size comparisons matter very little.
>
> I ran into several bugs in the IAR/EWARM compiler and IAR were not
sure when they would get fixed. After spending several frustrating
weeks on it, I decided to try the "free-be" GNUARM. It worked right
off the bat, and I was able to get my code off the ground much
quicker than with IAR. So it didn't seem to make much sense to pay
$$$$ for a proprietary compiler with bugs that gave me more grief
than the free GNUARM.
>
> I use UltraEdit for my IDE. It has all the features I need, and I
use it for many different jobs Verilog, Asm, etc. Most of the IDE's
with compilers do not give me what I want and I end up going back to
UltraEdit anyway to write my code.
>
> While C is suppose to be portable, that's just not the case. Every
compiler has different extensions, pragmas, attributes, etc. I
thought it was better to go the GCC route because the compiler
supports so many different CPUs.
>
> So for me UltraEdit+GNUARM/GCC was all I needed. It gets the job
done. There are bugs and wierd things in GCC too I don't like. But
I figure all of the systems have short comings so take the cheapest
route. If using IAR would have really been easier or faster, I would
have paid the money. But that wasn't the case. For me, a $$$$
compiler better do something a Hell of a lot better than a free one
or it just ain't worth the money.
>
> Chris.
>
>
>

The 2024 Embedded Online Conference