On 2011-01-28, Arlet Ottens <usenet+5@c-scape.nl> wrote:> On Fri, 28 Jan 2011 11:14:14 -0800, wicore wrote: > >> So tell me how you would write a simple bss-init routine for TI >> TMS320C3x/c4x? These are floating point DSPs where binary 0 equals 1.0. > > That needs help from the compiler. Either the compiler needs to put > uninitialized floats in the DATA section, with proper 0.0 initialization, > or it needs to put them in a special BSS_FLOAT section where the start up > code can loop through all variables, assigning them 0.0Both are correct (assuming static floats are to be initialized to 0.0), and both are trivial to imlement. -- Grant Edwards grant.b.edwards Yow! Do you have exactly at what I want in a plaid gmail.com poindexter bar bat??
TI's Code Composer does not clear bss data
Started by ●January 27, 2011
Reply by ●January 28, 20112011-01-28
Reply by ●January 28, 20112011-01-28
On 2011-01-28, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:> Since wicore's posting was directed to me, I would also say that > personally I am much more tolerant of implementation issues when a > language is ported to a new architecture type which contains > architectural specific issues which were probably not considered when > the language was designed. > > However, the OP is using a more traditional architecture on which > this kind of initialisation is clearly expected as standard.I think we could assume that the rules for C were mostly developed by people working on PDP-11 processors. The MSP430 would feel very familiar to anybody who had worked with a PDP-11. The TMS320 not so much. Still, it's still trivial to do the right thing on a TMS320. Just because something is easy and correct doesn't mean that TI will choose to do it that way... -- Grant Edwards grant.b.edwards Yow! I'm having a at quadrophonic sensation gmail.com of two winos alone in a steel mill!
Reply by ●January 28, 20112011-01-28
On Fri, 28 Jan 2011 19:51:43 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote:>On 2011-01-28, Arlet Ottens <usenet+5@c-scape.nl> wrote: >> On Fri, 28 Jan 2011 11:14:14 -0800, wicore wrote: >> >>> So tell me how you would write a simple bss-init routine for TI >>> TMS320C3x/c4x? These are floating point DSPs where binary 0 equals 1.0. >> >> That needs help from the compiler. Either the compiler needs to put >> uninitialized floats in the DATA section, with proper 0.0 initialization, >> or it needs to put them in a special BSS_FLOAT section where the start up >> code can loop through all variables, assigning them 0.0 > >Both are correct (assuming static floats are to be initialized to >0.0), and both are trivial to imlement.I think they aren't necessarily trivial to initialize. C requires 'semantic zero' and as pointed out above, this isn't always the same binary image for floats and doubles as might be used for integers on the same cpu. The static floats may be an element within a static structure rather than an elementary data type, so they cannot be so easily extracted and placed into a BSS_FLOAT as that would imply dragging the rest of the structure there, as well. Even with everything in the same static segment destined for startup initialization to semantic zeros, that problem remains. So I'd imagine that init code on such a cpu would be easier to handle if the compiler and linker cooperated to produce a non-volatile "image" and simply copied it into the segment prior to starting main(). Or a list of "patch up" pointers to those items which are initialized to something other than binary zero? Jon
Reply by ●January 28, 20112011-01-28
On Fri, 28 Jan 2011 19:54:56 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote:>On 2011-01-28, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: > >> Since wicore's posting was directed to me, I would also say that >> personally I am much more tolerant of implementation issues when a >> language is ported to a new architecture type which contains >> architectural specific issues which were probably not considered when >> the language was designed. >> >> However, the OP is using a more traditional architecture on which >> this kind of initialisation is clearly expected as standard. > >I think we could assume that the rules for C were mostly developed by >people working on PDP-11 processors.That seems to be the case. Apparently, the PDP-11 exposed some problems in B and BCPL. http://cm.bell-labs.com/cm/cs/who/dmr/chist.html>The MSP430 would feel very >familiar to anybody who had worked with a PDP-11.About like a staple-gunned, sawdust-board knock-off bookshelf reminds me of one decently designed and fabricated from select Cherry pieces that the cheap version was intended to mimic. It's when you put hands on the two that you know which is much better than the other. Jon>The TMS320 not so >much. Still, it's still trivial to do the right thing on a TMS320. > >Just because something is easy and correct doesn't mean that TI will >choose to do it that way...
Reply by ●January 28, 20112011-01-28
On 28.01.2011 21:04, Jon Kirwan wrote:> I think they aren't necessarily trivial to initialize.Well, that would depend on the skill level of the person making the assessment. One person's trivial can still go way over another one's head. And people who dare consider themselves compiler writers had better be on the upper end of that spectrum. I.e. people for whom this is too hot should get out of compiler kitchen.> C requires 'semantic zero' and as pointed out above, this > isn't always the same binary image for floats and doubles as > might be used for integers on the same cpu. The static > floats may be an element within a static structure rather > than an elementary data type, so they cannot be so easily > extracted and placed into a BSS_FLOAT as that would imply > dragging the rest of the structure there, as well.Indeed. That's about the point at which the very simplistic scheme of separating statics into .bss and .data starts to break down, and a more generic scheme of compressing the collection of initializers becomes preferable. Once you realize that the concept of BSS vs. DATA is really just poor man's run length encoding, it becomes clear how to proceed from there: use a proper data compression algorithm in the linker to pack the complete ROM image of initialized data (including the implicitly initialized ones), and have the startup code unpack that into RAM, instead of just copying it. While at it, this also removes the problem the traditional BSS/DATA scheme has with variables like unsigned int big_array[50000] = { 25 }; which would end up as a 50 KBytes full of zeroes in the DATA segment's ROM image for no particularly good reason.
Reply by ●January 29, 20112011-01-29
On 28/01/11 21:04, Jon Kirwan wrote:> On Fri, 28 Jan 2011 19:51:43 +0000 (UTC), Grant Edwards > <invalid@invalid.invalid> wrote: > >> On 2011-01-28, Arlet Ottens<usenet+5@c-scape.nl> wrote: >>> On Fri, 28 Jan 2011 11:14:14 -0800, wicore wrote: >>> >>>> So tell me how you would write a simple bss-init routine for TI >>>> TMS320C3x/c4x? These are floating point DSPs where binary 0 equals 1.0. >>> >>> That needs help from the compiler. Either the compiler needs to put >>> uninitialized floats in the DATA section, with proper 0.0 initialization, >>> or it needs to put them in a special BSS_FLOAT section where the start up >>> code can loop through all variables, assigning them 0.0 >> >> Both are correct (assuming static floats are to be initialized to >> 0.0), and both are trivial to imlement. > > I think they aren't necessarily trivial to initialize. > > C requires 'semantic zero' and as pointed out above, this > isn't always the same binary image for floats and doubles as > might be used for integers on the same cpu. The static > floats may be an element within a static structure rather > than an elementary data type, so they cannot be so easily > extracted and placed into a BSS_FLOAT as that would imply > dragging the rest of the structure there, as well. Even with > everything in the same static segment destined for startup > initialization to semantic zeros, that problem remains. So > I'd imagine that init code on such a cpu would be easier to > handle if the compiler and linker cooperated to produce a > non-volatile "image" and simply copied it into the segment > prior to starting main(). Or a list of "patch up" pointers > to those items which are initialized to something other than > binary zero? > > JonSo it is not a simple process to make all uninitialised data 0 on the TMS320C3x. I don't /care/. The C standards say the compiler toolchain must do it, so any C compiler will clear uninitialised data to arithmetic 0 or pointer 0, as appropriate. If it doesn't do that, it is not a compliant C compiler. There are lots of architectures that are horrible for C. It is hard to implement efficient local variables on an 8051 - yet people writing C compilers for the 8051 make the effort, because it is part of the requirements of the language they are implementing. If it is hard to write a bss initialiser for the TMS320C3x, then the CCS have no options but to work hard and write one. Anyway, it is not that hard - a few c.a.e. regulars (yourself included) have come up with at least 3 different ways to do it. And no matter what challenges there might be for the TMS320C3x, it is a trivial task for the msp430.
Reply by ●January 29, 20112011-01-29
On Sat, 29 Jan 2011 19:22:29 +0100, David Brown <david.brown@removethis.hesbynett.no> wrote:>On 28/01/11 21:04, Jon Kirwan wrote: >> On Fri, 28 Jan 2011 19:51:43 +0000 (UTC), Grant Edwards >> <invalid@invalid.invalid> wrote: >> >>> On 2011-01-28, Arlet Ottens<usenet+5@c-scape.nl> wrote: >>>> On Fri, 28 Jan 2011 11:14:14 -0800, wicore wrote: >>>> >>>>> So tell me how you would write a simple bss-init routine for TI >>>>> TMS320C3x/c4x? These are floating point DSPs where binary 0 equals 1.0. >>>> >>>> That needs help from the compiler. Either the compiler needs to put >>>> uninitialized floats in the DATA section, with proper 0.0 initialization, >>>> or it needs to put them in a special BSS_FLOAT section where the start up >>>> code can loop through all variables, assigning them 0.0 >>> >>> Both are correct (assuming static floats are to be initialized to >>> 0.0), and both are trivial to imlement. >> >> I think they aren't necessarily trivial to initialize. >> >> C requires 'semantic zero' and as pointed out above, this >> isn't always the same binary image for floats and doubles as >> might be used for integers on the same cpu. The static >> floats may be an element within a static structure rather >> than an elementary data type, so they cannot be so easily >> extracted and placed into a BSS_FLOAT as that would imply >> dragging the rest of the structure there, as well. Even with >> everything in the same static segment destined for startup >> initialization to semantic zeros, that problem remains. So >> I'd imagine that init code on such a cpu would be easier to >> handle if the compiler and linker cooperated to produce a >> non-volatile "image" and simply copied it into the segment >> prior to starting main(). Or a list of "patch up" pointers >> to those items which are initialized to something other than >> binary zero? >> >> Jon > >So it is not a simple process to make all uninitialised data 0 on the >TMS320C3x. I don't /care/. The C standards say the compiler toolchain >must do it, so any C compiler will clear uninitialised data to >arithmetic 0 or pointer 0, as appropriate. If it doesn't do that, it is >not a compliant C compiler. > >There are lots of architectures that are horrible for C. It is hard to >implement efficient local variables on an 8051 - yet people writing C >compilers for the 8051 make the effort, because it is part of the >requirements of the language they are implementing. If it is hard to >write a bss initialiser for the TMS320C3x, then the CCS have no options >but to work hard and write one. > >Anyway, it is not that hard - a few c.a.e. regulars (yourself included) >have come up with at least 3 different ways to do it. And no matter >what challenges there might be for the TMS320C3x, it is a trivial task >for the msp430.I was merely arguing with 'trivial.' Had the word been 'simple,' I probably would have had no reaction. Trivial things are uninteresting, straightforward, and without nuance. Jon
Reply by ●January 30, 20112011-01-30
On 29/01/11 21:44, Jon Kirwan wrote:> On Sat, 29 Jan 2011 19:22:29 +0100, David Brown > <david.brown@removethis.hesbynett.no> wrote: > >> On 28/01/11 21:04, Jon Kirwan wrote: >>> On Fri, 28 Jan 2011 19:51:43 +0000 (UTC), Grant Edwards >>> <invalid@invalid.invalid> wrote: >>> >>>> On 2011-01-28, Arlet Ottens<usenet+5@c-scape.nl> wrote: >>>>> On Fri, 28 Jan 2011 11:14:14 -0800, wicore wrote: >>>>> >>>>>> So tell me how you would write a simple bss-init routine for TI >>>>>> TMS320C3x/c4x? These are floating point DSPs where binary 0 equals 1.0. >>>>> >>>>> That needs help from the compiler. Either the compiler needs to put >>>>> uninitialized floats in the DATA section, with proper 0.0 initialization, >>>>> or it needs to put them in a special BSS_FLOAT section where the start up >>>>> code can loop through all variables, assigning them 0.0 >>>> >>>> Both are correct (assuming static floats are to be initialized to >>>> 0.0), and both are trivial to imlement. >>> >>> I think they aren't necessarily trivial to initialize. >>> >>> C requires 'semantic zero' and as pointed out above, this >>> isn't always the same binary image for floats and doubles as >>> might be used for integers on the same cpu. The static >>> floats may be an element within a static structure rather >>> than an elementary data type, so they cannot be so easily >>> extracted and placed into a BSS_FLOAT as that would imply >>> dragging the rest of the structure there, as well. Even with >>> everything in the same static segment destined for startup >>> initialization to semantic zeros, that problem remains. So >>> I'd imagine that init code on such a cpu would be easier to >>> handle if the compiler and linker cooperated to produce a >>> non-volatile "image" and simply copied it into the segment >>> prior to starting main(). Or a list of "patch up" pointers >>> to those items which are initialized to something other than >>> binary zero? >>> >>> Jon >> >> So it is not a simple process to make all uninitialised data 0 on the >> TMS320C3x. I don't /care/. The C standards say the compiler toolchain >> must do it, so any C compiler will clear uninitialised data to >> arithmetic 0 or pointer 0, as appropriate. If it doesn't do that, it is >> not a compliant C compiler. >> >> There are lots of architectures that are horrible for C. It is hard to >> implement efficient local variables on an 8051 - yet people writing C >> compilers for the 8051 make the effort, because it is part of the >> requirements of the language they are implementing. If it is hard to >> write a bss initialiser for the TMS320C3x, then the CCS have no options >> but to work hard and write one. >> >> Anyway, it is not that hard - a few c.a.e. regulars (yourself included) >> have come up with at least 3 different ways to do it. And no matter >> what challenges there might be for the TMS320C3x, it is a trivial task >> for the msp430. > > I was merely arguing with 'trivial.' Had the word been > 'simple,' I probably would have had no reaction. Trivial > things are uninteresting, straightforward, and without > nuance. >Fair enough. Apologies if my post sounded a bit irritated - this whole issue has annoyed and frustrated me, even though it is easy enough to work around when you know of the problem. It is just so stupid, and so unnecessary to have this flaw in CCS that I go into "rant" mode when posting about it. Obviously it is not /you/ I am annoyed at - you are just helping explain some of the issues involved. So again, sorry if it sounded like I was annoyed at you or your post.
Reply by ●January 30, 20112011-01-30
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. > > mvh., > > DavidAs someone else said, never assume anything. Was doing some work with The Renesas 80c87 series recently, where the ide startup code examples do include code for initialisation, but to make use of it, you have to adhere to their standard layout and view of reality, which may not always be ideal. In any case, it's always the responsibility of the programmer to initialise vars to their required values, usually through explicit module init functions. I do this from habit, even when I know that it has been cleared via the setup asm code. It's so little added effort and makes the intent clearer on the page... Regards, Chris
Reply by ●January 30, 20112011-01-30
On 30.01.2011 16:03, ChrisQ wrote:> In any case, it's always the responsibility of the programmer to > initialise vars to their required values,... and it's the compiler's responsibility to carry out what the programmer wrote, according to the only contract there is between him and the compiler: the definition of the programming language. Compilers that don't fulfill even the most basic aspects of this contract aren't worth the space they take up on the disk even at todays rather modest costs for that commodity.> I do this from habit, even when I know that it has been cleared via > the setup asm code. It's so little added effort and makes the intent > clearer on the page...And while at it, it wastes code space. If you're never in a situation where that might risk breaking your entire project, consider yourself lucky --- or young.
