Has anyone else observed that the latest kickstart MSP430 compiler from IAR has an extremely serious code generation bug when configured with optimizations=high,size?
IAR C/C++ Compiler for MSP430 V4.10E/W32 [Kickstart] (4.10.5.3) C:\Program Files\IAR Systems\Embedded Workbench 5.0\430\bin\icc430.exe
2/15/2008 11:03:06 AM, 15015936 bytes
I have a test case that demos the problem perfectly, but it's tied to specific hardware. The symptom is that a pointer, if declared locally, is being sent off into random-land after one iteration of a loop. If the same declaration is moved out into global scope, or if optimization is turned off, the problem disappears. Target is MSP430F2012.
I haven't yet groveled through the assembly output to see exactly what the difference between the two output flavors is. But this is such an astoundingly show-stopping bug I'm appalled it escaped.
What did IAR support say about it when you told them?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Kickstart has no support. Of course, last time I was working with a bought version of their compiler, and found a [different] bug, the answer was "buy the latest upgrade".
Of course not it is a FREE size limited eval version. However that does not mean you can't report bugs to the support team. Why wouldn't you?
Because you had a very old version (IAR compilers have 12 months support) and they had fixed the bug in a later version. It would only be "buy" a new version if you were out of support. Which you would be or you would have got the update for free.
You do like trying to make mountains out of molehills.
If you find a bug in ANY compiler (not just IAR) that is fixed in a newer version they tell you to get the latest version. If you are on support it is usually free. You only have to pay if it is a very old version.
However if you want to use an old version that is your look out.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I am not particularly familiar with IAR for MSP430, however I have seen several times that the IAR for AVR can loose a local variable if the function is complex enough and the optimization is set to maximum. Declaring this variable as static helps.
Why are you so astounded? *Every* C/C++ compiler that I ever worked with did have bugs. If one doesn't see any bugs in compiler, that simply means that he haven't yet done any serious projects with it.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
Sure. The latest version of compiler with the fresh not yet known bugs. Porting a working project to the next revision of a compiter is PITA.
Yes, this is one of the problems. They can't make money from just making bug fixes to the current software, so they have to release new versions.
There is a phylosophycal principle: "It is better to be the first, then to be the best". I wonder if it is a universal law or just a current direction of the development of the civilization.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
If you fix bugs in a compiler you get a new version. These are usually free in the first year after purchase as part of the compiler price.
It cost money to do support and continue development. How would you fund it? Triple the cost of the compiler to start with to cover the ongoing work?
This does not apply to compilers. You seem to understand very little. The problem with compilers is that it is never ending.
As you appear not to know silicon vendors fix and patch chips requiring changes to the compiler. Silicon vendors release new version and additions to the family requiring changes to the compiler. The C standard changes (frequently) requiring changes to the compiler and or the library. Then there are changes to the simulator and linker for many of the reasons above.
Then there are changes to Windows that affect the whole system...
Compiler development is an on going task. Not a 1 off release. I recall a customer complaining to me that he should have a free upgrade to a 6 year old compiler because it did not support a new part (with new memory system) that had just been released!
It is a universal law of civilisation since the dawn of time.
However most software tools tend to go for small changes and release often after the initial release.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I prefer keeping the projects with the complete old toolchains and not to jump to the latest and greatest unless it is really required. If a compiler bug was spotted, then it is not dangerous any more.
If you fixed the bugs you only got a new build of the old version. By releasing the bug fixes you acknowledged that you can't get the things right at the first time, however the good thing is that you care. The new version should have a difference.
This is the problem of the compiler people, not mine. What point are you trying to make? I have no illusion that the compiler development is different from any other sw development. Same kind of lousy and pitifull business.
The life is hard. Is that what you are trying to prove?
Sure. Let's blame Bill Gates for everything.
Not my problem.
Oh well. I'd better go join the linuxopaths with their GCC...
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
There's a difference here between what is often termed "updates" and "upgrades". An "upgrade" means a new versions of the tool, typically with new features, and is something you can only expect to get while on a support contract of some kind. You don't "upgrade" the tools you use for a project without good reason, and when a project is finished, you keep track of the tool versions used in its development.
"updates" (or "service packs"), on the other hand, are minor changes - often bug fixes, but occasionally small additional changes (perhaps support for a new chip variant). They are usually safe to use without changing your project, and are often freely available to any licensed user.
Thus changing from gcc 4.2.2 to gcc 4.3.0 is an upgrade, and may require changes to the project. Changing to 4.2.3 is merely an update to fix a couple of bugs.
It is not unreasonable to expect a compiler supplier to provide updates for a certain time after purchase - you should not have to upgrade just to get a bug fix. (Note that I have no idea what IAR's policy is in this - I'm just expressing general comments.)
So your software development is a "lousy and pitiful business" and you judge all the rest by your standards?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
IAR in common with nearly all compilers I know of give you free updates AND upgrades for 12 months. After that you have to buy support.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Following is what the latest Kickstart version I have (came with the=20 EZ2500 kit) says when About... is clicked. Considering that practically=20 every component has a different version and build #, it's virtually=20 impossible to ever say with certainty what "version" of IAR anyone has.
--Gene
IAR Assembler for MSP430 V4.09A/W32 (4.9.1.9) D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\a430.exe
9/26/2007 9:38:38 AM, 688128 bytes
IAR C/C++ Compiler for MSP430 V4.09A/W32 [Kickstart] (4.9.1.3) D:\Program Files\IAR Systems\Embedded Workbench 4.0\430\bin\icc430.exe
As with ALL compiler suites. You are either being deliberately obtuse or don't understand the tools. Neither trait is good for a developer.
The package has a release number (on the CD, zip file etc) and the individual components also have release numbers as you listed. It is called version control. Something that happens in professional software development.
I used to have this problem a lot with Keil C51 when asking what version of the compiler someone was using. I often got the version of the IDE.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
The software development is lousy and pitiful business. The ones who state the different either have no clue, or deliberately lying, or never wrote anything longer then "Hello World".
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
That may be true de jure, but not de facto. If you report the bug on the MSP430 mailing list, I'd bet a doughnut that somebody from IAR will respond.
Um, that's pretty much how commercial software works. If you were using mspgcc, you could just fix the problem, submit the patch, and get on with your work. Worst case, you could report the problem and wait for a day or two while somebody else fixes it. For free.
--
Grant Edwards grante Yow! We're going to a
at new disco!
visi.com
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I'm not sure that someone qualified to write good embedded code for the MSP430 is also qualified to patch the code generator of mspgcc.
I've written a lot of embedded code for the MSP430 and other embedded systems, but I've never even LOOKED at the source for the code generator of any compiler! That may be because I got into embedded systems from oceanography---and have never taken any computer science course other than a freshman introductory course---and that in 1968! Oddly enough, I did teach computer science at the U for a few years---sophomore and junior level courses in architecture and assembly-language programming.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
IE a Kickstart compiler that has "no support" was:-
/////////////////// It is documented that Hi optimization level is a very very aggressive level that must be always tested against the application. At level LOW the user will get ALL the industry standard optimization techniques, most of the new techniques are represented at the hi level.
There are several guidelines how to deal with these situation, the IAR compiler support optimization on the function level, using #prgama optimization in case you really want to use the high level, declaring variables as volatile will help the optimizer decide whether to optimize out a variable or not, avoiding empty delay loops and simply including a __no_operation() intrinsic function inside an empty loop will help the optimizer decide etc... If you have a specific sample code that we can compile and link and debug, then send it over to fwd to development .
///////////////////
So it is Documented... You did read the documentation? If you would like to send IAR some sample code they will look at the problem.
So much for "no support" you did not even ask!
You just made assumptions and tried to discredit a compiler company. Rather unprofessional of you to say the least.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.