----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 07 Okt 2010 17:04:36
>> Thanks for all your work (even if I don't use mspgcc4 as it isn't ready for >> critical production environment) > You're welcome. But: > In case somebody reads this and decides to avoid mspgcc4 in favor of a > supposedly production-ready mspgcc3, the parameter non-truncation problem > Kim Toms found seems to be present there too. The difference? Nobody's > going to fix it in mspgcc3. > None of this stuff is what I would call ready for a critical production > environment. Well, most programmers aren't ready for critical production environment too :) No, you got it wrong (I wrote it wrong): The problem is that there are too many new bugs in mspgcc4, so I cannot switch from mspgcc3 to 4 without need to validate (and most likely fix) all of our already tested firmware once again. And chances are high that every project will requires one or another fix before it works again. And many of the already known bugs/limitations are severe, so there is no reason to switch. Unfortunately the original design of our code does not allow to just freeze the working binary and feed it into production. In the production department, each device gets programmed with its own individual version of the firmware (low-count high-price units), which is compiler-optimized for its unique job then instead of having 'unoptimized' generic code for all possible jobs. > If you've been using something for years, and have hand-coded > around the problems and limitations that you've found affect your current > code, there's little motivation to move to a new version that may have new > problems to discover. Yes, that's what I was talking about. > But don't assume that's an indication of quality from > an independent perspective, or that there aren't things going wrong that you > just haven't found yet. Well new bugs in compiler are just like new bugs in new code. Find and fix them. It's the old and already working code which must not be broken by a new compiler. > Dealing with updates is a pain, but I've found that in general the overall > quality improves with time. If I can manage to install a newer version of the compiler in parallel of the existing one (which doesn't work that well for different versions of mspgcc3 because of the usage of system paths prior to looking into its own directories), I can start a new project with the new compiler and subsequently move the old code too. But that's a pain (at least under windows, which is mandatory for our systems) and almost impossible to handle for the production department, where the guys are no computer nerds. :) I'm sure we'll end up with mspgcc4 finally, but until then, it's still a long way and much to do (and I have been assigned to Flex software development for our PC frontend with most of my time now - so nobody has time for porting the firmware and testing it) JMGross ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
