It seems that barely a month goes by when I’m not asked my opinion on compilers. Sometimes I’m simply asked what compilers I use, while other times I’m asked my opinion on specific compilers – with GCC being by far the most asked about compiler. I’ve resisted writing about this topic because quite frankly it’s the sort of topic that people get very passionate about – and by passionate I mean frothing at the mouth passionate. It seems that some folks simply can’t accept the fact that someone doesn’t agree with them that XYZ is simply the best compiler ever. Notwithstanding this, the volume of inquiries has reached the point where I really feel the need to break my silence.
First of all lets make some general observations.
- Despite the fact that I’ve been doing this for nearly 30 years and also despite the fact that as a consultant I probably use a wider variety of compilers than someone that works for an employer, the simple fact is that I’ve only had cause to use in anger a limited number of compilers. Thus are Rowley compilers any good? Well their website is decent, the documentation is OK and the IDE very nice. However I’ve never built a real project with their tools and so I really don’t know whether Rowley compilers are any good.
- Many vendors provide compilers for many targets. As such it’s a good bet that if their 8051 compiler is very good, then their ARM compiler is also likely to be excellent. However it isn’t a given. Thus while I whole heartedly endorse the Keil 8051 compiler, I have no opinion on their ARM compiler.
- Compilers vary in price from ‘free’ to ‘cheap’ to ‘expensive’ to ‘they have got to be joking’. I’ve put all of these costs in quotes, because as you’ll see below, one’s perspective on what constitutes ‘free’ or ‘expensive’ is not easily defined.
So, enough with the preamble. Lets start with the ‘free’ and ‘cheap’ compilers, including GCC. Well for me the bottom line (literally) is that I can’t afford to use these compilers. The reason is quite simple. I’m a high priced consultant. I can charge high hourly rates in part because I have exceptionally high productivity. Part of the way I achieve my high productivity is by not wasting my time (and hence my client’s money) on stupid issues unrelated to the problem at hand. Given that a compiler / linker is such a frequently used tool, and given that I’m also the sort of engineer who pushes his tools hard, it’s absolutely essential to me that when I run into a compiler issue I can pick up the phone and get an intelligent response ASAP. One simply can’t do that with ‘free’ or ‘cheap’ compilers, and thus too often one is reduced to browsing the Internet to find the solution to a problem. When this happens, then my ‘free’ compiler rapidly starts to cost an arm and a leg.
What always amazes me about this topic is that so few employers / engineers seem to understand this. It seems that too many folks will eschew paying $2000 for a compiler – and then happily let their engineers bang their heads against a problem for a week – at a rate of at least $1000 a day.
Thus for me, the answer to the question ‘Is GCC a good compiler?’ is ‘no, it isn’t’. Of course if you are a student, or indeed anyone who is cash poor and time rich, then by all means use GCC. I’m sure you’ll be very pleased with the results and that you’ll find it to be a good compiler for you.
What then of the ‘expensive’ and they ‘have got to be joking’ categories? Rather interestingly, although based on limited experience, I’ve found that the very expensive compiler vendors ($10K+) also have lousy support. Instead it’s the ‘expensive’ vendors that actually seem to offer the best combination of functionality, code quality, support and price – and it’s this category that I tend to use the most.
Finally, regarding which compiler vendor I use. I happen to be a fan of IAR compilers. I’ve always found their code quality to be at least ‘good’. Their linker is probably the easiest and most powerful linker I’ve ever used. Their support is very good (thanks Steve 
). Finally their IDE is easy to use and has a very consistent look and feel across a wide range of processors, which is important to me as I tend to switch between architectures a lot.
Nigel, sounds like you fall into the 'cheap' consultant category.'Expensive' consultants support their own development tool chains.Out-sourcing your support to a third-party only works when that third-part is responsive to your needs.
Ouch – and I thought it was only my wife that considered me cheap! I certainly know of consultants that support their own tool chains – and even make a virtue of it. Indeed Bill Gatliff for example has a consulting business largely based on promoting the use of open sourced tools. I'd be interested to know if the 'Expensive' consultants you are referring to bill their clients for the time they spend supporting their own development tool chains.
Peter, our company has two embedded products that implement complex state machines developed by Nigel. One was developed with about $8K worth of IAR tools (compiler + Visual State.) When I need to make a change to that product, I fire up the tools, make my revisions, test them, and ship them.The other was developed with a popular free assembler. I've read the code, and I think I understand it. That being said, I won't touch that code with a ten foot pole – it works and the risk of introducing a bug it too high. This is one of the motivations for development of the former product. My anecdote is probably more a testament to the power of statecharting tools than it is about the rest of the toolchain. Nevertheless, when the right tools are used, the tools are well worth it. (Nigel is as well.)
Reading my comment after posting, I wanted to clarify that it isn't intended as a criticism in any way. What I'm trying to say is, that the more expensive tools gave us a product we can maintain ourselves.
Peter,I think you need to give us some examples of consultancies supporting their own tool chains. At least if we are talking about C/C++ compilers for CPU's at the deeply embedded end of things…Sure, there are a number of highflying consultancies/service companies with their own proprietary compiler/language tools but then we are talking about x86 or other server/workstation type CPU's as the target architecture.There are a number of companies maintaining their own ports of GCC for a few selected CPU's, but in the end they are just as dependent on the open source community as the ordinary developer if they want to stay reasonably in synch with main line development.It's *very* expensive to develop and maintain, not to mention supporting, compiler tools for multiple CPU architectures, which is why there are so few companies out there doing this. (It's even expensive to do it for only one architecture if you for example look at ARM.)There is simply no business even for the most pricey consultanices in developing and maintaining their own AVR, msp430 or m16c compiler for example, because that would imply steering all projects towards that architecture. (Again, x86 etc are a completely different thing.)So, I'm really very interested in hearing about counter examples to what I state above!
Interesting perspective. As a relatively inexperienced embedded developer, I'm still very much in the bang-for-the-buck category (free being the usual goal), and have yet to come across too many gnarly compiler-related issues — although I have no doubt they are out there. I can see where using a well-supported compiler could be cost-effective, though. Thanks for the article.
I've also been around this for a long, long time. The first compiler trouble you have costs a packet. A day spent messing about trying to get the linker to work, or to declare in interrupt handler in this wesks version of gcc…. and you've just blown the cost of buying a full on compiler – even ignoring the support issues. (I've found compiler bugs in some of the expensive compilers as well – but I got them fixed pretty damn quick by the vendors!)Paying money for a reputable compiler is simply, in most cases, a good business practice. Few engineers work out the cost of their own time. They should. It changes the approach you take to compilers, and many other things as well.
Nigel, as a regular reader there's an aspect of compilers I've been hoping to read something about on your blog — ROMability of data. I think it's probably more of an issue for C++ than C, where, if a const structure is initialized statically, the compiler will place it in ROM (although even C compilers differ in how good they are at doing this — I recall a compiler for the AVR that required the programmer to use special key-words).For C++, the rules are a little more arcane (aren't they always?), and whether an instance of a class will be placed in ROM depends on other factors (does the class have user-defined constructors? Does it have virtual methods?). It depends on the compiler's ability to detect that the memory contents could be initialized at compile-time.As an exercise, I'm implementing in C++ a module I developed in C for a previous employer. I certainly feel the C++ code is more readable and maintainable. However, if the constant data is not placed in ROM, the module would not be usable on a small embedded device, and the advantages of using C++ would become irrelevant.The ISO's Technical Report on C++ Performance has something to say about this, but, unsurprisingly, it seems to boil down to, "it depends on the compiler's ability to do static analysis".
I have used both free and paid compilers and can say that encountering bugs in the tool chain are the rarest of problems and occur if not equally then even more often on paid tool chains than free ones as less people use the paid tool chains.
I do agree that in the extremely rare event (it only happened two or perhaps three times for me in over 20 years of embedded programming) you happen across a tool chain bug some good real support would make a world of difference; but the honest truth is once you have identified the problem enough to realize it is in the tool and not your code it is often far easier to just work around it with some creative coding than wait for someone’s support.
The true productivity stopper I have found is not in which tool is being used but simply not knowing enough about the tool you are using (ie. which linker option or pragma does what). Pick your tools out of a hat; whichever they might be, and really learn to use them and you will undoubtably be most productive with those tools. Another productivity stopper is trying some fancy abstraction around coding something that should really be done in a much simpler way.
Great observation! I agree wholeheartedly that not knowing the tool inside out is a productivity stopper – which explains in part why I read compiler manuals so much! I think as a consultant, my situation is a little different in that the nature of the job requires me to switch tools at a higher frequency than a normal gainfully employed engineer. Notwithstanding this I’ve come across plenty of engineers that have never cracked open the reference manual for their tool chain – and thus wonder why they can’t get things done.