On 2011-01-27, David Brown <david@westcontrol.removethisbit.com> wrote:> > 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. >If I wrote code which assumed that .bss was cleared at startup then I would certainly be caught by this as I consider it part of the standard that .bss is cleared to 0x00 at startup. However, I have a policy that I always initialise at startup _all_ variables whose first use within the code is something other than to be assigned a value, even when I am just initialising that variable to it's implictly assigned value. I do this because I do not like implictly assigned variables and I like to make it explicit within the code that the following code which accesses that variable assumes a starting value of zero. Also, at various warning levels, some C compilers will throw warnings about uninitialised variables and I also have a policy of actively eliminating compiler warnings in my code when possible. I am also influenced by the fact that I write code in other languages and the rules are sometimes different in those languages. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
TI's Code Composer does not clear bss data
Started by ●January 27, 2011
Reply by ●January 27, 20112011-01-27
Reply by ●January 27, 20112011-01-27
On 2011-01-27, David Brown <david.brown@removethis.hesbynett.no> wrote:> I can understand crappy tools. [...]> 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,TI did the same thing with the JTAG interface. They made a conscious decision to violate the spec in ways that make it impossible to use in a JTAG chain. I was never too crazy about the AVR architecture when compared with the MSP430, but at least the AVR JTAG interface worked right.> 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.Yep, it's a total of maybe 5 lines of assembly code.> It would take much less time to write the code than it did to > document the flaw in the manual.Having the startup code behave according to the standard (and possibly providing an option to "optimize" it) is obviously the right thing to do -- obvious to everybody except TI. -- Grant Edwards grant.b.edwards Yow! Is something VIOLENT at going to happen to a gmail.com GARBAGE CAN?
Reply by ●January 27, 20112011-01-27
On 2011-01-27, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:> If I wrote code which assumed that .bss was cleared at startup then I > would certainly be caught by this as I consider it part of the > standard that .bss is cleared to 0x00 at startup.I write code that assumes the same thing -- but I also always confirm that the startup code does it.> However, I have a policy that I always initialise at startup _all_ > variables whose first use within the code is something other than to > be assigned a value, even when I am just initialising that variable > to it's implictly assigned value. > > I do this because I do not like implictly assigned variables and I > like to make it explicit within the code that the following code > which accesses that variable assumes a starting value of zero.One might assume that a decent compiler would place all variables that are initialized to 0 into the bss section so that explicitly initializing a variable to 0 doesn't create extra overhead. That said, we all know there are a lot of bad compilers around.> Also, at various warning levels, some C compilers will throw warnings > about uninitialised variables and I also have a policy of actively > eliminating compiler warnings in my code when possible.A compliant compiler should never warn about a static variable being "uninitialized" since according to the C standards all static variables are, by definition, initialized. -- Grant Edwards grant.b.edwards Yow! HAIR TONICS, please!! at gmail.com
Reply by ●January 27, 20112011-01-27
On 27.01.2011 22:47, Grant Edwards wrote:> A compliant compiler should never warn about a static variable being > "uninitialized" since according to the C standards all static > variables are, by definition, initialized.Close, but not quite correct. Compliancy has nothing to do with that. Now, sanity, or quality of implementation, that's a totally different kettle of fish. A compliant compiler is entitled to warn ("emit diagnostics") about whatever it bloody well pleases. A diagnostic like Oh, puleeze! Come on, mon, you know perfectly well that 13-letter variable names are not allowed in line 5 of a source file! can be emitted without in any way risking your compiler's compliancy level.
Reply by ●January 27, 20112011-01-27
On 2011-01-27, Hans-Bernhard Br?ker <HBBroeker@t-online.de> wrote:> On 27.01.2011 22:47, Grant Edwards wrote: > >> A compliant compiler should never warn about a static variable being >> "uninitialized" since according to the C standards all static >> variables are, by definition, initialized. > > Close, but not quite correct. Compliancy has nothing to do with that.I guess compilers do issue warnings about all sorts of "legal" things such as if (i = foobar()) { } That's perfectly legal, yet I do appreciate being warned about it.> Now, sanity, or quality of implementation, that's a totally different > kettle of fish. > > A compliant compiler is entitled to warn ("emit diagnostics") about > whatever it bloody well pleases. A diagnostic like > > Oh, puleeze! Come on, mon, you know perfectly well that 13-letter > variable names are not allowed in line 5 of a source file! > > can be emitted without in any way risking your compiler's compliancy > level.I guess that's true as long as the correct code is generated. -- Grant Edwards grant.b.edwards Yow! I know things about at TROY DONAHUE that can't gmail.com even be PRINTED!!
Reply by ●January 27, 20112011-01-27
On 2011-01-27, Hans-Bernhard Br�ker <HBBroeker@t-online.de> wrote:> On 27.01.2011 22:47, Grant Edwards wrote: > >> A compliant compiler should never warn about a static variable being >> "uninitialized" since according to the C standards all static >> variables are, by definition, initialized. > > Close, but not quite correct. Compliancy has nothing to do with that. > Now, sanity, or quality of implementation, that's a totally different > kettle of fish. > > A compliant compiler is entitled to warn ("emit diagnostics") about > whatever it bloody well pleases. A diagnostic like > > Oh, puleeze! Come on, mon, you know perfectly well that 13-letter > variable names are not allowed in line 5 of a source file! > > can be emitted without in any way risking your compiler's compliancy level.Indeed. :-) The gcc Ada front end has successfully compiled a number of my Ada programs while still telling me _exactly_ why they were going to then fail at runtime. I was sure I had seen this uninitialised warning in the distant past, but I just compiled a test C program (which didn't explictly initialise a static variable before using it) with a gcc 4.x compiler and I didn't get a warning. However, my main reason for initialising zero valued variables in the code is that I don't like implictly assigned variables. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●January 27, 20112011-01-27
On 2011-01-27, Grant Edwards <invalid@invalid.invalid> wrote:> On 2011-01-27, David Brown <david.brown@removethis.hesbynett.no> wrote: > >> 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, > > TI did the same thing with the JTAG interface. They made a conscious > decision to violate the spec in ways that make it impossible to use in > a JTAG chain. I was never too crazy about the AVR architecture when > compared with the MSP430, but at least the AVR JTAG interface worked > right. >That's just crazy. :-( Was this some attempt at vendor lock in (ie: was there a need to buy a TI approved JTAG interface device) or was there another reason ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
Reply by ●January 27, 20112011-01-27
On Jan 27, 3:14=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org- Earth.UFP> wrote:> However, I have a policy that I always initialise at startup _all_ variab=les> whose first use within the code is something other than to be assigned a > value, even when I am just initialising that variable to it's implictlyI could not agree with your post more completely. Today I might be writing code on an elegant, well-tested compiler fully compliant with the standards of the day. Tomorrow I might want to import that sourcecode into a hellhole of a broken, buggy compiler (Microchip targets come to mind), and my best defense is to make sure that my code assumes as little as possible about the quality of the compiler. Yeah, I know .bss ought to be zero. When I write startup code, I zero it. I have absolutely no faith in RandomCRTLibraryProviderXYZ to obey any kind of laws or best practices, so I don't rely on anyone else's implementation for this. Anyone who has ever tried to use an Atmel app note will realize that even code that comes direct from chip manufacturers is frequently of hideous quality.
Reply by ●January 28, 20112011-01-28
On 28/01/2011 00:57, Simon Clubley wrote:> On 2011-01-27, Grant Edwards<invalid@invalid.invalid> wrote: >> On 2011-01-27, David Brown<david.brown@removethis.hesbynett.no> wrote: >> >>> 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, >> >> TI did the same thing with the JTAG interface. They made a conscious >> decision to violate the spec in ways that make it impossible to use in >> a JTAG chain. I was never too crazy about the AVR architecture when >> compared with the MSP430, but at least the AVR JTAG interface worked >> right. >> > > That's just crazy. :-( > > Was this some attempt at vendor lock in (ie: was there a need to buy a > TI approved JTAG interface device) or was there another reason ? >I don't know the details in this case (I haven't looked at the low-level workings of the msp430 jtag interface). But ultimately, jtag is a silly choice of interface for debugging - it's got a /huge/ overhead if you want to follow all the rules correctly. Most chips that have a jtag debugger interface have some sort of non-standard shortcut to put their jtag interface into "debug" mode rather than testpin mode. Some of these play well with other jtag devices, others only work well if they are the only device on the jtag bus. While the best idea is to have a shortcut technique that works along with other devices on the board, it's usually only the big chips that bother. When you have an FPGA or a processor in a 400 pin bga package, it is conceivable that you will also have a jtag chain for testing pin connections between that package and a bga package memory device. But I expect it is a negligible proportion of msp430 users who will want other jtag devices on the same chain. In reality therefore, very few people will care if the interface follows jtag standards or is completely different - such as Freescale's BDM, or AVR's debugwire. What people /do/ care about, are several other points: The interface should be standard across the family. Different msp430 devices have slightly different jtag interface arrangements - some need hardware reset pins, others don't. Some need clock pins, others don't. The full debug interface should be documented, and those documents available to anyone who wants them. /That/ is the big problem, and the vendor lockin mechanism. Atmel AVR's are just as bad - in both cases, you can get limited information so that you can re-program the devices over the jtag interface, but you cannot get full information about debugging them. Freescale and ARM both give full information (AFAIK). The interface should be a straightforward synchronous serial interface transferring all data and commands in blocks of 8 bits (or multiples of 8 bits), and work well with long blocks of transfer data. In other words, it should be easy to make a cheap and fairly fast interface using devices like the FTDI2322 USB chip. As far as I know, TI's jtag interface works like that. Examples of debug interfaces that don't fit that model well are Freescale's Coldfire BDM - it uses 17-bit transfers, with one bit in the reply being a "ready/busy" bit that is supposed to pause the transfers. If you follow those rules precisely, you get a download speed of about 1K per second using an FTDI 2232 interface. Finally, if you want to sell USB based jtag interfaces, you should be consistent about the chips used and the drivers needed. Both TI and Olimex (who make cheap TI jtag interfaces) have been a serious pain here - they have regularly come out with new revisions of their interfaces that have no changes in functionality, but require new drivers and library files on the PC. It's stupid and unnecessary, and breaks third-party software to save a couple of cents on production - customers would not complain if the purchase price was a couple of cents more for a guarantee of backwards compatibility.
Reply by ●January 28, 20112011-01-28
On 27/01/2011 21:14, Simon Clubley wrote:> On 2011-01-27, David Brown<david@westcontrol.removethisbit.com> wrote: >> >> 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. >> > > If I wrote code which assumed that .bss was cleared at startup then I > would certainly be caught by this as I consider it part of the standard > that .bss is cleared to 0x00 at startup. > > However, I have a policy that I always initialise at startup _all_ variables > whose first use within the code is something other than to be assigned a > value, even when I am just initialising that variable to it's implictly > assigned value. > > I do this because I do not like implictly assigned variables and I like to > make it explicit within the code that the following code which accesses that > variable assumes a starting value of zero. > > Also, at various warning levels, some C compilers will throw warnings about > uninitialised variables and I also have a policy of actively eliminating > compiler warnings in my code when possible. >Good C compilers warn about using uninitialised data. But statically allocated data /is/ initialised - to zero. A complier that warns about global data being uninitialised has a broken warning system (or, like CCS, it is a broken compiler/toolchain). It is a different matter for non-static locals - they must be explicitly initialised, and it is good for the compiler to warn you about them. And in such cases, you are typically not "actively eliminating compiler warnings", you are "actively eliminating code bugs" ! Generally, I agree with you about explicit being better than implicit. I would never write code that uses the implicit "int" that exists in many places in C - to me, "long" is a description and "long int" is the type (actually, I would prefer the more explicit int32_t).> I am also influenced by the fact that I write code in other languages and > the rules are sometimes different in those languages. >Yes, different languages have different rules - Pascal, for example, does not have implicit initialisation of data. I find it annoying that you can't give an initialisation value when declaring a variable (unless you count the truly bizarre idea of calling it a "constant" so that it can be initialised, and then using it as a variable anyway). And I appreciate the idea of writing a sort of "subset" of the languages - either unconsciously from habit (I used to put an unnecessary semicolon after closing brackets in C, after years of putting a semicolon after an "end" in Pascal) or consciously for consistency or to aid porting.
