I have taken over a project for the msp430 that has been built with TI's Code Composer Studio IDE and compiler. One thing that I have noticed in the documentation is the following paragraph: In ANSI/ISO C, global and static variables that are not explicitly initialized must be set to 0 before program execution. The C/C++ compiler does not perform any preinitialization of uninitialized variables. Explicitly initialize any variable that must have an initial value of 0. Is it just me, or do others think that this goes against C behaviour since the term "C standard" was first coined, and is likely to cause all sorts of hard-to-find bugs in code that is written with the assumption that "static int x" is the same as "static int x = 0" ? I have never heard of any toolchain that does not clear the bss at startup (unless you specifically write your own non-standard startup code) - I have only seen it before in CCS for the TMS320 DSP's that I had to work with some 10-12 years ago. At the time, when I finally figured out the cause of my problems, I assumed it was either a bug in the toolset or that I somehow had an odd option set that disabled clearing the bss. People here in c.a.e. have used a wide variety of compilers - and some here have written compilers. Is this a "feature" that anyone has seen elsewhere? Is it something that would catch you out, because you write code assuming that the bss is cleared? I'd like to know if my stunned reaction here is justified. mvh., David
TI's Code Composer does not clear bss data
Started by ●January 27, 2011
Reply by ●January 27, 20112011-01-27
On Jan 27, 7:58=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote:> because you write code assuming> mvh., > > DavidThe more experienced I get, the less assuming I do. ** I think that it is a "good thing" that they told you that they did not initialize BSS. ** There are times when you do NOT want want the BSS scrubbed at reset. I think stunned is over-reacting.
Reply by ●January 27, 20112011-01-27
On Thu, 27 Jan 2011 08:30:15 -0800, d_s_klein wrote:> The more experienced I get, the less assuming I do. > > ** I think that it is a "good thing" that they told you that they did > not initialize BSS. > ** There are times when you do NOT want want the BSS scrubbed at reset.The few cases where you don't want variables cleared are easily solved by creating custom initialization code, and/or adding another type of segment where you can put those variables in. Writing code that depends on the fact that BSS is not cleared makes an even bigger assumption, and will most likely fail when you port it to a different toolchain.
Reply by ●January 27, 20112011-01-27
On 2011-01-27, David Brown <david@westcontrol.removethisbit.com> wrote:> I have taken over a project for the msp430 that has been built with TI's > Code Composer Studio IDE and compiler. One thing that I have noticed in > the documentation is the following paragraph: > > In ANSI/ISO C, global and static variables that are not > explicitly initialized must be set to 0 before program > execution. The C/C++ compiler does not perform any > preinitialization of uninitialized variables. Explicitly > initialize any variable that must have an initial value of 0. > > Is it just me, or do others think that this goes against C behaviour > since the term "C standard" was first coined, and is likely to cause all > sorts of hard-to-find bugs in code that is written with the assumption > that "static int x" is the same as "static int x = 0" ?I've never seen a _compiler_ that did pre-initialization of static variables. That's always been the responsibility of the startup code, the linker/loader, or whatever it is that runs before the C program is started. Are you saying that the TI's CC tool suite includes startup code that doesn't clear the "bss" section? If so, then yes, that's broken. It's no wonder that nobody (TI FAEs included) ever recommends CC for MSP430 development.> I have never heard of any toolchain that does not clear the bss at > startup (unless you specifically write your own non-standard startup > code) - I have only seen it before in CCS for the TMS320 DSP's that I > had to work with some 10-12 years ago. At the time, when I finally > figured out the cause of my problems, I assumed it was either a bug in > the toolset or that I somehow had an odd option set that disabled > clearing the bss.TI Code Composer has a pretty bad reputation. I too was forced to use for TMS320 development and I was unimpressed. The only thing I've heard about CC on the '430 plaform is "don't use it, use IAR or Gnu."> People here in c.a.e. have used a wide variety of compilers - and some > here have written compilers. Is this a "feature" that anyone has seen > elsewhere? Is it something that would catch you out, because you write > code assuming that the bss is cleared? I'd like to know if my stunned > reaction here is justified.Yes, shipping startup code that doesn't clear bss seems pretty broken to me. -- Grant Edwards grant.b.edwards Yow! I am NOT a nut.... at gmail.com
Reply by ●January 27, 20112011-01-27
On 2011-01-27, d_s_klein <d_s_klein@yahoo.com> wrote:> On Jan 27, 7:58?am, David Brown <da...@westcontrol.removethisbit.com> > wrote: > >> because you write code assuming > >> mvh., >> >> David > > The more experienced I get, the less assuming I do. > > ** I think that it is a "good thing" that they told you that they did > not initialize BSS.Yes, it's a good thing that they told him about it. It's a bad thing that they didn't clear bss.> ** There are times when you do NOT want want the BSS scrubbed at > reset.If you don't want them cleared, you put them _in_a_different_section_.> I think stunned is over-reacting.I'm not stunned, but that's becuase it's Code Composer. I'd be stunned if it were IAR or mspgcc that wasn't following the rules. -- Grant Edwards grant.b.edwards Yow! What's the MATTER at Sid? ... Is your BEVERAGE gmail.com unsatisfactory?
Reply by ●January 27, 20112011-01-27
On 01/27/2011 07:58 AM, David Brown wrote:> I have taken over a project for the msp430 that has been built with TI's > Code Composer Studio IDE and compiler. One thing that I have noticed in > the documentation is the following paragraph: > > In ANSI/ISO C, global and static variables that are not > explicitly initialized must be set to 0 before program > execution. The C/C++ compiler does not perform any > preinitialization of uninitialized variables. Explicitly > initialize any variable that must have an initial value of 0. > > Is it just me, or do others think that this goes against C behaviour > since the term "C standard" was first coined, and is likely to cause all > sorts of hard-to-find bugs in code that is written with the assumption > that "static int x" is the same as "static int x = 0" ? > > I have never heard of any toolchain that does not clear the bss at > startup (unless you specifically write your own non-standard startup > code) - I have only seen it before in CCS for the TMS320 DSP's that I > had to work with some 10-12 years ago. At the time, when I finally > figured out the cause of my problems, I assumed it was either a bug in > the toolset or that I somehow had an odd option set that disabled > clearing the bss. > > People here in c.a.e. have used a wide variety of compilers - and some > here have written compilers. Is this a "feature" that anyone has seen > elsewhere? Is it something that would catch you out, because you write > code assuming that the bss is cleared? I'd like to know if my stunned > reaction here is justified.There's a reason I refer to it as "code composter". I've seen tool chains (not the compiler, as has been pointed out) that fail at this task. Most of them just lack decent start up code, some of them do not support a bss segment or do not support letting the startup code know where the bss segment starts and ends. One of the joys of embedded programming is working around crappy tools. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Reply by ●January 27, 20112011-01-27
On 27.01.2011 19:12, Grant Edwards wrote:> I've never seen a _compiler_ that did pre-initialization of static > variables. That's always been the responsibility of the startup code, > the linker/loader, or whatever it is that runs before the C program is > started.Yes. But it's certainly the responsibility of the compiler to tell the other parts of the tool chain about those static variables that aren't initialized explicitly. To this extent, compiler do pre-initialize statics. And of course, "the compiler" as mentioned in the text quoted by the OP was rather certainly meant to refer to the entire toolchain, not just the compiler proper.> Yes, shipping startup code that doesn't clear bss seems pretty broken > to me.ACK. Startup code can usefully support a configurable _option_ that turns off BSS clearing. But it's brutally dumb to ship start-up code with that option active by default.
Reply by ●January 27, 20112011-01-27
On 2011-01-27, Hans-Bernhard Br?ker <HBBroeker@t-online.de> wrote:> On 27.01.2011 19:12, Grant Edwards wrote:>> Yes, shipping startup code that doesn't clear bss seems pretty broken >> to me. > > ACK. Startup code can usefully support a configurable _option_ that > turns off BSS clearing. But it's brutally dumb to ship start-up code > with that option active by default.TI has never been accused of being smart about anything relating to support for their parts. The parts themselves are often impressive enough, but the toolchains, refusal to disclose debug info, and so on all seem seem to be intended to annoy as many customers as possible. Vendors like Microchip and Atmel do a much better job at support. -- Grant Edwards grant.b.edwards Yow! Life is a POPULARITY at CONTEST! I'm REFRESHINGLY gmail.com CANDID!!
Reply by ●January 27, 20112011-01-27
On 27/01/11 19:17, Tim Wescott wrote:> On 01/27/2011 07:58 AM, David Brown wrote: >> I have taken over a project for the msp430 that has been built with TI's >> Code Composer Studio IDE and compiler. One thing that I have noticed in >> the documentation is the following paragraph: >> >> In ANSI/ISO C, global and static variables that are not >> explicitly initialized must be set to 0 before program >> execution. The C/C++ compiler does not perform any >> preinitialization of uninitialized variables. Explicitly >> initialize any variable that must have an initial value of 0. >> >> Is it just me, or do others think that this goes against C behaviour >> since the term "C standard" was first coined, and is likely to cause all >> sorts of hard-to-find bugs in code that is written with the assumption >> that "static int x" is the same as "static int x = 0" ? >> >> I have never heard of any toolchain that does not clear the bss at >> startup (unless you specifically write your own non-standard startup >> code) - I have only seen it before in CCS for the TMS320 DSP's that I >> had to work with some 10-12 years ago. At the time, when I finally >> figured out the cause of my problems, I assumed it was either a bug in >> the toolset or that I somehow had an odd option set that disabled >> clearing the bss. >> >> People here in c.a.e. have used a wide variety of compilers - and some >> here have written compilers. Is this a "feature" that anyone has seen >> elsewhere? Is it something that would catch you out, because you write >> code assuming that the bss is cleared? I'd like to know if my stunned >> reaction here is justified. > > There's a reason I refer to it as "code composter". > > I've seen tool chains (not the compiler, as has been pointed out) that > fail at this task. Most of them just lack decent start up code, some of > them do not support a bss segment or do not support letting the startup > code know where the bss segment starts and ends. >Yes, I know technically that it is the startup code rather than the compiler itself that clears the bss. But there are two sorts of libraries that come as part of any C toolchain - the C standard library (containing things like "printf" and "strlen", as required by the standards), and the compiler support library (containing things like software floating point routines and other code that supports the C language itself). The C startup code is part of that support library, and thus much more tightly integrated with the compiler than the standard library, which may often be swapped out. Still, it would have been more accurate for me to say it is a flaw in the toolchain rather than the compiler itself.> One of the joys of embedded programming is working around crappy tools. >I can understand crappy tools. I've used many tools, with many flaws, bugs, failures, and missing parts. I can understand the reasons for providing such tools - small markets, lack of time, lack of money, shipping something "good enough", etc. I've seen C compilers that can't work with nested arrays, or which have 16-bit longs, or which don't support function pointers. I can appreciate the reasons for that (even if I don't like it), and I can work around them. But this is something different - it is a concious decision to make the tool incompatible and non-standard in a surprising way that must surely have caused developers a great deal of wasted time and effort, as well as causing people to ship buggy products if they have not noticed this issue. Clearing the bss is not exactly rocket science - it needs a couple of marker symbols in the linker file, and a short loop in the startup code. It would take much less time to write the code than it did to document the flaw in the manual.
Reply by ●January 27, 20112011-01-27
On 27/01/11 17:30, d_s_klein wrote:> On Jan 27, 7:58 am, David Brown<da...@westcontrol.removethisbit.com> > wrote: > >> because you write code assuming > >> mvh., >> >> David > > The more experienced I get, the less assuming I do. >When I buy a C compiler, I assume it conforms at least roughly to the C standards. I don't assume a perfect match, but I assume uninitialised variables will be cleared in the same way that I assume it will generate correct code for simple arithmetic.> ** I think that it is a "good thing" that they told you that they did > not initialize BSS.No, it is a good thing that I happened to notice this information when reading through the manual. How many people actually /read/ these manuals cover to cover? Myself and about a dozen other people the world over - other people are going to read the relevant paragraphs after wasting hours, days, or more trying to debug non-reproducrable problems.> ** There are times when you do NOT want want the BSS scrubbed at > reset. > > I think stunned is over-reacting.
