Comments on: Is GCC a 'good' compiler? http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/ Thoughts on embedded systems by Nigel Jones Mon, 06 Sep 2010 14:57:18 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Ashleigh http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-1614 Ashleigh Wed, 18 Aug 2010 00:11:17 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-1614 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. 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.

]]> By: Nigel Jones http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-528 Nigel Jones Sun, 28 Mar 2010 14:55:41 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-528 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. 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.

]]> By: GroovyD http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-522 GroovyD Sun, 28 Mar 2010 04:41:42 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-522 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. 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.

]]> By: Ferdi Pienaar http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-400 Ferdi Pienaar Sat, 06 Feb 2010 01:56:22 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-400 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". 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".

]]> By: The Walrus http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-399 The Walrus Fri, 05 Feb 2010 11:31:54 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-399 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. 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.

]]> By: M. Eric Carr http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-398 M. Eric Carr Wed, 03 Feb 2010 17:20:54 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-398 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. 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.

]]> By: Anonymous http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-397 Anonymous Wed, 03 Feb 2010 16:31:48 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-397 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! 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!

]]> By: Kyle Bostian http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-396 Kyle Bostian Wed, 03 Feb 2010 15:35:44 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-396 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. 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.

]]> By: Kyle Bostian http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-395 Kyle Bostian Wed, 03 Feb 2010 15:33:44 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-395 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.) 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.)

]]> By: Nigel Jones http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/comment-page-1/#comment-394 Nigel Jones Wed, 03 Feb 2010 12:35:28 +0000 http://www.gfcdev.org/test-stack/2010/02/02/is-gcc-a-good-compiler/#comment-394 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. 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.

]]>