Re: Opinions on Rowley CrossWorks for ARM

Chris Hills wrote:
In article <454af9a0$0$8084$8404b019@xxxxxxxxxxxxxxx>, David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes
Chris Hills wrote:
In article <4549fa49$0$8717$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Paul Curtis <plc@xxxxxxxxxxxx> writes
"Chris Hills" <chris@xxxxxxxxxxxx> wrote in message
news:1UeXJWNowQSFFAJM@xxxxxxxxxxxxxxxxxxxxxxx
In article <newscache$lxp18j$pg2$1@xxxxxxxxxxx>, Christian Walter
<wolti@xxxxxx> writes
* They use the GNU C/C++ compiler tools which are somewhat "industry
standard" tools. Specially the good integration for inline assembler
in GCC is a big plus for embedded systems if you are doing low level
stuff.

Hardly I would not recommend GCC for embedded use.

That's because you sell "Industry Standard" compilers.

I would conjecture you advocate Keil and IAR only because you are a reseller
of those products. :-)
Paul Curtis, Rowley Associates Ltd.
And I can suggest you only advocate Gcc because you sell that?


There is a big difference here. You have been dismissing gcc out of hand, without giving any reasoning or evidence, or indication that you have even tried it, and without directly stating your commercial bias (I know people can follow the links in your sig.).

I have been programming for nearly 30 years. I have only been in the distribution business a few years. I have used many compilers in anger.


I know that (from previous threads), and that is why you are in a position to give useful technical information about the differences between compilers. Tell us why Keil's debugger is much better than Rowley's, or IAR's IDE saves time and therefore money. All I'm asking is that you give us good reasons to choose the tools you recommend, rather than just saying you dislike gcc.

Paul has been advocating the compiler his company makes and sells, and saying why gcc is a suitable choice in industry.

Fair enough. However there is a tendency for GCC advocates to automatically dismiss any criticism of Gcc that comes from anyone who is involved in anyway with any commercial compiler. Though they don't accept the argument in reverse.


I can give plenty of criticism of gcc (some general to gcc, some regarding other parts of the toolchain, others specific to particular targets).

There are fanatics for all sorts of products, but most people who use gcc are aware of its pros and cons, and choose to use it despite its warts. Sometimes that is because of particular requirements (such as the host operating system, or availability of source code, lack of licensing issues, price), and sometimes they have a free choice but feel gcc provides the best value for money (including time), or produces the best code, or is most compatible with other tools.

The people providing gcc toolchains, especially those providing them for free, are (in my experience) often far more honest about limitations or problems than people selling commercial tools.

I don't sell or resell tools, so I'm not biased.

That does not hold true. You are assuming the only bias is from those who sell tools. See my last comment.


Ok, no one is entirely unbiased. I have my likes and dislikes, just as everyone else does. But I use closed source and open source, and I try to choose the right tool for the job at the time. My first contribution to this thread was in defence of a commercial toolchain that was dismissed because of its website, and my second was in defence of a toolchain that was dismissed simply because it is gcc.

Get the best tool for the job - and that depends on both the job and who's doing it.

I agree.

. I don't like to see toolchains dismissed because their website looks too cheerful,

I have made no comment on the Rowley web site (people in glass houses etc :-) Rowley are compiler developers not web designers. However the comments made re the Rowley web site I think were meant as constructive criticism from some one who wanted to recommend Rowley to his management. .


I know it was not you that commented on the website (ImageCraft's site, not Rowley's). My point was that I think all compilers should get a fair hearing based on their merits, not prejudices.

and I don't like to seem them dismissed because they are gcc (no other reason has been given).

I was dismissing Gcc not Rowley per-say. Rowley do a very good MSP430 compiler


Exactly - you are dismissing gcc simply because it is gcc.

If tools like IAR and Keil are so much better, then surely you can come up with better reasons than telling us

Many people have done that. I recall a whole lot of benchmarks put up but they were all dismissed because they came from commercial sources. The only benchmarks the Gcc supporters would except were the ones that showed Gcc was as good as all the commercial compilers and ignored the fact that the benchmarks were from a commercial company that provided Gcc (no it wasn't Rowley)


I haven't tried any compilers for ARM, but I've seen plenty of these benchmarks around. Many of the comparisons with ARM gcc were with earlier versions of the compiler, which everyone (including the gcc developers) will tell you generated inefficient code. Comparisons of newer versions would give a different picture - I'd expect gcc to be in the same region as other optimising compilers, just as it is on many other targets. There are well-established techniques for generating good code for architectures rich in registers and with orthogonal instruction sets, and for many types of source code you will get similar generated code from any good compiler (the same applies to the avr, msp430, and ColdFire architectures with which I am familiar). Any benchmark which shows great variation is suspect.

Anyway, all benchmarks must be viewed with more than a pinch of salt. Even if the test code used bore any relationship to the code you are using in the real world, benchmarks are almost invariably arranged by someone with a point to make - compiler developers want their product to look good compared to others. Add to this that many commercial software developers have licenses that specifically limit the user's right to publish benchmark information, and published benchmarks are effectively worthless. As a potential customer, your only choices are to ask around for opinions, and download trial versions and test them out yourself.

The reaction I have had from inside several compiler companies is you can't reason with religion.


I'm not asking you to reason with rabid fanatics - I don't see any in this thread. I'm asking you to reason with people who want to know about compiler toolchains. By dismissing gcc simply because it is gcc, and refusing to give any rational reasoning (I don't see your dislike of gcc fans as a good reason not to use the tools), you are the one leading the thread into "religion". Please, give rational technical or economic arguments for why the O/P and others should buy particular toolchains, or why they should avoid other toolchains, and leave out the biases.

they are not quite as vastly expensive as they seem

They are not expensive. You are using a distorted benchmark. The IAR and Keil compilers are slightly on the higher side of the average for compilers. You are basing your "average" on one compiler at one end of the price distribution. Or should we judge all cars on the price of a Trabant?


What is "expensive" or not depends entirely on your requirements. I'm sure that in many cases, IAR and Keil work out as excellent value for money. But in other cases, they are very expensive. On the occasion (a fair few years ago) in which I was seriously considering IAR's AVR compiler, there is no doubt - it was extremely expensive compared to the competition, which was from ImageCraft. That was based on my requirements. I've no doubt that in other circumstances, IAR's compiler would have been the right choice.

, and anyway professionals can afford to pay lots. The only positive thing you've said about them is that they are popular (which is significant, but not decisive).

I could go on about passing the industry standard test suits etc but then it degenerates in the fact that the industry standard test suits cost money... and that there is a gcc test suite (which is unregulated) There is no level playing field for a discussion and you can't argue with religion.


You are right - there is no level playing field, and it would be somewhat boring if there were. gcc and high-end commercial compilers are suitable for different uses. For some uses, passing industry standard test suites is vital - for others, it is irrelevant. There are many non-technical issues surrounding buying a compiler - some people insist on having the source code, others might want a supplier that provides a warranty, some want test suite certification, others want freedom from license management issues. When these issues don't apply to you, it's easy to see them as "religion".
.

Relevant Pages

  • Re: Whats the story with the "end of XP"?
    ... Support gives them access to the larger body ... The same compiler suite may be "best" in both ... In the case of ByteCraft compilers, you are truly expert in your field, you work closely and rapidly with customers if there are any issues, and you have top class testing and quality control. ... understanding the inner workings of a relatively simple compiler like GCC ...
    (comp.arch.embedded)
  • [RFC][PATCH-2.6] Clean up and merge compiler-*.h
    ... the kernel headers in include/linux to include/linux-abi. ... * Common definitions for all gcc versions go here. ... -/* Some compiler specific definitions are overwritten here ...
    (Linux-Kernel)
  • Re: LPC900/80C51 Compiler Toolchain
    ... >> supported by GCC, and so they invest. ... > if they already have their in-house compiler. ... one of the main companies in the Symbian consortium ... vendor to provide a good compiler for Atmel AVRs and eventually became ...
    (comp.arch.embedded)
  • Newbie packages question
    ... checking for gcc... ... checking for C compiler default output file name... ... checking if the linker is GNU ld... ... checking how to recognise dependent libraries... ...
    (Debian-User)
  • Lib X11 compile problem /Xlib.h:3573: error: syntax error before "_X_SENTINEL"
    ... checking for gcc... ... checking for C compiler default output file name... ... checking how to recognise dependent libraries... ...
    (comp.os.linux.x)