Developing/compiling software
in [Embedded]
|
From: ChrisQ on 29 Sep 2009 17:15 David Brown wrote: > > I think the same thing applies to most languages. I guess we can blame > this idiosyncrasy (or rather, idiocy) of C on the slow Dec Writer > keyboards - K&R were more concerned about avoiding keystrokes than on > making a good structured modular programming language. The default > "int" is in the same category. If all you have is a int, everything looks like a hammer etc, or have I mixed that up a bit. C may not be perfect, but it's kept me in lunch for more years than I care to remember, Still enjoy the challenge and and still learning new stuff every day. What more could you ask for a way of earning a living, with half the world in employment slavery ?. Everything is a compromise and C was originally designed in the days before computing as it is today. Code generated from it drives a large proportion of the world's engineering, apps, medicine, leisure and more, so perhaps they didn't do such a bad job... Regards, Chris
From: Ulf Samuelsson on 29 Sep 2009 17:52 >>> >>> Beyond that, avr-gcc pushes registers if they are needed - pretty >>> much like any other compiler I have used. If your interrupt function >>> calls an external function, and you are not using whole-program >>> optimisation, then this means pushing all ABI "volatile" registers - >>> an additional 12 registers. Again, this is the same as for any other >>> compiler I have seen. And as with any other compiler, you avoid the >>> overhead by keeping your interrupt functions small and avoiding >>> external function calls, or by using whole-program optimisations. >>> >>>> The IAR is simply - better - . >>>> >>> >>> I'll not argue with you about IAR producing somewhat smaller or >>> faster code than avr-gcc. I have only very limited experience with >>> IAR, so I can't judge properly. But then, you apparently have very >>> little experience with avr-gcc - >> >> I don't disagree with that. >> I have both, but I quickly scurry back to the IAR compiler >> if I need to show off the AVR. >> > > You have colleagues at Atmel who put a great deal of time and effort > into avr-gcc. You might want to talk to them about how to get the best > out of avr-gcc - that way you can offer your customers a wider choice. > Different tools are better for different users and different projects - > your aim is that customers have the best tools for their use, and know > how to get the best from those tools, so that they will get the best out > of your devices. > > On the other hand, I fully understand that no one has the time to learn > about all the tools available, and you have to concentrate on particular > choices. It's fair enough to tell people how wonderful IAR and the AVR > go together - but it is not fair enough to tell people that avr-gcc is a > poor choice without better technical justification. > > There is a difference between saying the one compiler is better than the other, and saying that the second rate compiler is a poor choice. Statistically, the avr-gcc compiler is used by more than 50% of the AVR developers, and for many, "free of charge" is a much more important parameter than efficient code generation. Others would like to have a compiler which is not dongle protected due to bad experience with the vendor, and that is another reason to go avr-gcc, instead of IAR. BR Ulf Samuelsson
From: Ulf Samuelsson on 29 Sep 2009 17:53 >>> >>> Beyond that, avr-gcc pushes registers if they are needed - pretty >>> much like any other compiler I have used. If your interrupt function >>> calls an external function, and you are not using whole-program >>> optimisation, then this means pushing all ABI "volatile" registers - >>> an additional 12 registers. Again, this is the same as for any other >>> compiler I have seen. And as with any other compiler, you avoid the >>> overhead by keeping your interrupt functions small and avoiding >>> external function calls, or by using whole-program optimisations. >>> >>>> The IAR is simply - better - . >>>> >>> >>> I'll not argue with you about IAR producing somewhat smaller or >>> faster code than avr-gcc. I have only very limited experience with >>> IAR, so I can't judge properly. But then, you apparently have very >>> little experience with avr-gcc - >> >> I don't disagree with that. >> I have both, but I quickly scurry back to the IAR compiler >> if I need to show off the AVR. >> > > You have colleagues at Atmel who put a great deal of time and effort > into avr-gcc. You might want to talk to them about how to get the best > out of avr-gcc - that way you can offer your customers a wider choice. > Different tools are better for different users and different projects - > your aim is that customers have the best tools for their use, and know > how to get the best from those tools, so that they will get the best out > of your devices. > > On the other hand, I fully understand that no one has the time to learn > about all the tools available, and you have to concentrate on particular > choices. It's fair enough to tell people how wonderful IAR and the AVR > go together - but it is not fair enough to tell people that avr-gcc is a > poor choice without better technical justification. > > There is a difference between saying the one compiler is better than the other, and saying that the second rate compiler is a poor choice. Statistically, the avr-gcc compiler is used by more than 50% of the AVR developers, and for many, "free of charge" is a much more important parameter than efficient code generation. Others would like to have a compiler which is not dongle protected due to bad experience with the vendor, and that is another reason to go avr-gcc, instead of IAR. BR Ulf Samuelsson
From: David Brown on 29 Sep 2009 19:08
ChrisQ wrote: > David Brown wrote: > >> >> I think the same thing applies to most languages. I guess we can >> blame this idiosyncrasy (or rather, idiocy) of C on the slow Dec >> Writer keyboards - K&R were more concerned about avoiding keystrokes >> than on making a good structured modular programming language. The >> default "int" is in the same category. > > If all you have is a int, everything looks like a hammer etc, or have I > mixed that up a bit. > > C may not be perfect, but it's kept me in lunch for more years than I > care to remember, Still enjoy the challenge and and still learning new > stuff every day. What more could you ask for a way of earning a living, > with half the world in employment slavery ?. > To paraphrase Churchill - C is the worst of all possible programming languages, except for all the others. > Everything is a compromise and C was originally designed in the days > before computing as it is today. Code generated from it drives a large > proportion of the world's engineering, apps, medicine, leisure and more, > so perhaps they didn't do such a bad job... > When C was designed, there were plenty of other languages that were far safer, better structured, and in many ways more powerful - Algol and Pascal being the obvious examples. There are a number of points where C could have been much better, for very little cost - avoiding implicit ints and making file-scope objects static are clear examples. The lack of a proper interface-implementation separation is perhaps the biggest failing - people /still/ can't agree on a sensible style of how to name headers and C files, and what should go in each file. I suppose C++ shows that C is not as bad as it is possible to get. It's fair enough to say that C's limitations and design faults are because K&R were writing it for a specific use, and it worked fine for that job. And it's also fair enough to say that any design is a compromise. But when C was designed, other current languages were significantly more "modern" in their structure and safety - C was a big step back in those areas. |