Please don't ask "Which C compiler is the best?"

1 post / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

(Moderator's note: as this appears to be a FAQ, Johan's
answer goes sticky on top, and remains locked so to be not
spammed with too many personal opinions. Please send any
criticism to Johan directly, so he might edit his article,
and/or start a separate discussion thread after thinking
twice about it.)

Please don't ask "Which compiler is the best?"

We can not give you any meaningful answer. The only thing that will come out of it is a more or less illuminated debate where the one thing that everyone agrees on is that everyone else is wrong. This phenomenon is called "the compiler wars".

Why there is no answer to the question "Which AVR C compiler is the best?"

1. You have to start by defining "best". What aspect are you wanting the compiler to be best in? Running fast? Producing fast code? Producing small code? Having syntactic constructs for AVR/embedded work (e.g. must you have things like PORTB.3 = 1; rather than PORTB |= 1<<3;)? What about support for different AVR parts (e.g. memory challenged Tinys, very new devices, devices with "huge" flash)?

2. Are we talking about the compiler proper, or are we talking about an IDE solution? Are you confident in setting up build instructions, such as makefiles, yourself or do you want a IDE with wizards and such to make your life easier? Do you want/need automatic code generation, so that you don't have to cram every last detail in the data sheet to get an interrupt service routine written or make your timer tick? Are you prepared to abandon your own favourite editor?

3. To make a meaningful comparison of the output of the compiler (the generated code) we must have a realistic application ported to all the different compilers. Testing a ridiculously small application (eg. "blink-a-LED") will not yield meaningful results as startup code and basic run-time-support will take up almost all of the application and this is a one-off cost that would be relatively much smaller for a realistic app. Although the idea has been aired here a couple of times no-one has volunteered to port a realistic app to to the different compilers. (The closest thing that I know of is that the AVR Butterfly demo application has been ported from IAR to avr-gcc, and I suspect that this isn't a "straight port" but rather one with some change in functionality. This still leaves at least two compilers out of the game.)

If you do a thorough search through the forums you might find descriptions of where a specific compiler behaves extremely bad in a certain situation. If this situation is a crucial part of your app, or is the only thing that your AVR will do, then don't choose that compiler. You might also find cases where a certain compiler behaves better than the others in a certain situation. If this situation is all your app will be about then, by all means, choose that compiler. None of those cases will tell you much about the quality of the compiler(s) in general, though.

4. Are we talking about price? With respect to what? Your wallet? Or any of the points above? What is your time worth in money (are you prepared to pay money for things that probably will save time, or are you on a null money budget and can invest time instead)?

Just as you won't get any universally true answers to the question "Which car is the best?" you won't get any universally true answers to the question ""Which AVR C compiler is the best?". Jut as with cars, you will get different answers depending on what demands you have, and just as with cars you will get a lot of highly opinionated answers by people who are devoted to the compiler they use. (BMWs aren't that great!).

Can't I ask anything about the different compilers?

Yes you can. If you have a question on how the different compilers behave in a specific situation then you might well get good answers. (You'd have to be very specific, though, or the result will only be another round in the compiler wars. Fellow 'freak Lee Theusch keeps an unofficial count which is closing in on round 100 and have never even been close to a winner.)

But I need to select a compiler...

At least three compilers can be gotten for free, or a very small amount of money. Some of these will have limitations on how large apps they will build and/or how long they will function.

In the end I suspect that you fall more or less in one of the two categories below:

You are a professional embedded systems developer and need to cram out every last byte/cycle of a specific AVR as you will manufacture in thousands or more. In such a case you should have resources to allocate for an in-house evaluation of the different compilers. Your competitors won't do this for you, and if you are a business that can't do a satisfactory compiler evaluation yourself you will have to do what all businesses do - buy one from someone competent enough to do it for you - or just pick one and live with the consequences.

You are a hobbyist aiming to build one or just a few specimen of your app. In such a case you will probably be much more helped by a toolchain that fits your "modus operandi" and your wallet. Download one of the free or very low priced compilers and start out with that one. If you don't like it - switch to another one. Treat it as a learning experience. There's no such thing as a free lunch, even for a hobbyist.


Well, there you go. No flame-wars please. Constructive criticism welcome.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.


"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]