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.
Nigel – your comment about is spot on. First thing I do with any new compiler or tool chain is RTFM.
So many of my colleagues dont (and never have, over the years) and it makes my almost cry with frustration. The GUI era has made things even worse, people think they dont NEED to read because the GUI saves them the effort.
And then… there are those who insist on always building a product using the GUI but forget or don’t know how to check all the GUI config files into version control – and then when they change you can’t see what that changes were. These days I build EVERYTHING using batch or make files because its 100% repeatable and not prone to accidentally clicking some change of option – and then discovering the mistake 3 months after shipping. (And no, the “debug / release” options in GUIs don’t cut the mustard either!)
Having used GCC for years on Sun workstations and PCs – it has its place. But for deep embedded micros I’ve been pretty underwhelmed; and recently by the poor optimisers for at least some micros. If code size matters, then spending a day or 2 doing compiler benchmarking really pays off.
Example: If I need to ship a product on a bigger micro, and that bigger micro costs $0.20 more, and I can ship (say) 50,000 products / year then that bigger micro costs $10,000 (per year). If I spend a couple of days of my time it costs (say) $1000, and if I then buy a professional compiler at $5000, I’m still $4000 ahead at the end of my first year. Or the economic payback period is about 8 months. Now ANY businessman will take you up on an investment opportunity like that.
I work with a lot of different microcontrollers and processors. gcc is generally my first choice, even if the budget for a particular project or customer would cover expensive commercial tools. gcc saves me time – it is much faster and easier to download and install gcc for most microcontrollers than to order commercial tools, wait for delivery, then fight with their licensing and node locking systems.
After installation, each commercial toolset has its own idea of a half-baked IDE to get used to, and its own set of documentation to read (yes, I read through the manuals for my tools). With gcc, it is the same compiler, the same setup, and the same documentation – all I need to consider is the target-specific details and possibly small changes from version to version. I can use the same editor and build system that I always use.
When considering support, I’ve found that support for commercial compilers vary enormously. I know of a big name toolset vendor that apparently has more technical support staff dedicated to licensing, dongle and installation issues than it has for actual compiler support. And my experience with some vendors is that I know more about the target, C programming and standards, and often their own compiler than the support staff do. With typical gcc ports, you have a mailing list for support – you send an email and the people that answer reply are either interested and technically competent users, or they are the compiler developers themselves. Unless you are a huge customer, you simply can’t get that sort of direct developer contact from most commercial vendors.
Additionally, I’ve generally found gcc to be a better compiler than most commercial tools I’ve used. It often generates better code, it has more powerful and useful extensions, far better inline assembly support than almost any other compiler, and much better error checking and warnings than other toolsets.
Having said all that, I don’t always choose gcc, and I don’t always recommend it to other people. Different users and different projects have different needs. And there are commercial vendors that really do give excellent value for money, and excellent support. There are also large differences in the usability of gcc for different targets, and from different sources. Downloading gcc from the official FSF sources and building it yourself is certainly a specialist job. But purchasing and downloading a binary package from http://www.codesourcery.com, along with a support contract, is no different from making any other commercial toolchain purchase – except that you get much better value for money, and you get support from the people making the compiler.
It is with good reason that manufacturers such as TI, Atmel, Freescale, Intel, etc., contribute to and encourage gcc development. It is with good reason that TI sells Cortex-M3 evaluation boards with gcc (from Code Sourcery or Code Red) on an equal footing with Kiel and IAR. It is with good reason that Atmel made a gcc port for their AVR32 while designing the processor.
There are times when gcc is the best choice for a particular job, and times when it is not. But any consultant who does not consider gcc when considering toolchains for a target, is simply not doing a good job.