Grant Edwards wrote:> On 2011-01-30, ChrisQ <meru@devnull.com> wrote: >> Arlet Ottens wrote: >> >>> Translating the source reliably also includes clearing the BSS during >>> start up. If you can't depend on the tool chain to translate "int a" >>> correctly, why would you assume it does any better on "int a = 0" ? >>> >> The problem in the latter case is that the compiler has no implicit >> awareness of the startup code that initialises int a = 0;, other than >> reserving symbol table space and context for a. For a static / global >> var outside function scope, the init is implied by including the startup >> code at link time. ie: The compiler can't emit code to initialise a, whereas >> int a = 0; within function scope will result in code to initialise it on >> function entry. > > You're comparing apples and oranges. We were talking about static > variables, and you're talking about automatic ones. >Plenty of room for nit picking here, but imho, all vars should be initialised by the module that uses them, through init functions or elsewhere within the module. Relying on some offbase startup function to do this is s recipe for future bugs. Keep it all encapsulated within the module and there's no doubt as to what's been done and where. No global vars either, other than const data, but I guess that might be considered provocative as well :-)... Regards, Chris
TI's Code Composer does not clear bss data
Started by ●January 27, 2011
Reply by ●January 31, 20112011-01-31
Reply by ●January 31, 20112011-01-31
On Mon, 31 Jan 2011 18:13:44 +0000, ChrisQ wrote:>>> The problem in the latter case is that the compiler has no implicit >>> awareness of the startup code that initialises int a = 0;, other than >>> reserving symbol table space and context for a. For a static / global >>> var outside function scope, the init is implied by including the >>> startup code at link time. ie: The compiler can't emit code to >>> initialise a, whereas int a = 0; within function scope will result in >>> code to initialise it on function entry. >> >> You're comparing apples and oranges. We were talking about static >> variables, and you're talking about automatic ones. >> >> > Plenty of room for nit picking here, but imho, all vars should be > initialised by the module that uses them, through init functions or > elsewhere within the module. Relying on some offbase startup function to > do this is s recipe for future bugs. Keep it all encapsulated within the > module and there's no doubt as to what's been done and where. No global > vars either, other than const data, but I guess that might be considered > provocative as well :-)...I don't agree that using statically initialized variables is a 'recipe for future bugs'. The start up code is usually small, and easily verified to be correct. After all, initializing BSS is just a memset(), and initializing DATA is just a memcpy(). Depending on the correctness of this tiny bit of code is no worse than depending on the rest of the run time library, including such things as memset(), memcpy(), and non-native arithmetic, such as float math on an integer CPU. On the contrary, I think having to write and call all kinds of xxx_init() functions is an easier way to introduce bugs.
Reply by ●January 31, 20112011-01-31
On Mon, 31 Jan 2011 17:31:44 +0000, ChrisQ <meru@devnull.com> wrote:>I still have a look at the TI msp pages from time to time, but I think >you are right in that TI never saw it as a long term expandable >architecture. Otherwise, why would they effectively sit on it for ten >years while the rest of the world moved on ?. I guess in the end, a gp >16 bit register set doesn't translate well to > 16 bits worth of address >space, however it's done...I think there were serious mistakes made in the design (and implementation.) The failure to anticipate a wider addressing space isn't among the ones that bother me most. Jon
Reply by ●January 31, 20112011-01-31
On 2011-01-31, Jon Kirwan <jonk@infinitefactors.org> wrote:> On Mon, 31 Jan 2011 17:31:44 +0000, ChrisQ <meru@devnull.com> > wrote: > >>I still have a look at the TI msp pages from time to time, but I think >>you are right in that TI never saw it as a long term expandable >>architecture. Otherwise, why would they effectively sit on it for ten >>years while the rest of the world moved on ?. I guess in the end, a gp >>16 bit register set doesn't translate well to > 16 bits worth of address >>space, however it's done... > > I think there were serious mistakes made in the design (and > implementation.) The failure to anticipate a wider > addressing space isn't among the ones that bother me most.Or they decided that MSP430 was a small 16-bit CPU that wasn't intended to compete with ARM-based solutions. -- Grant Edwards grant.b.edwards Yow! Oh my GOD -- the at SUN just fell into YANKEE gmail.com STADIUM!!
Reply by ●January 31, 20112011-01-31
On 2011-01-31, ChrisQ <meru@devnull.com> wrote:> Grant Edwards wrote:>>> The problem in the latter case is that the compiler has no implicit >>> awareness of the startup code that initialises int a = 0;, other than >>> reserving symbol table space and context for a. For a static / global >>> var outside function scope, the init is implied by including the >>> startup code at link time. ie: The compiler can't emit code to >>> initialise a, whereas int a = 0; within function scope will result in >>> code to initialise it on function entry. >> >> You're comparing apples and oranges. We were talking about static >> variables, and you're talking about automatic ones. > > Plenty of room for nit picking here, but imho, all vars should be > initialised by the module that uses them, through init functions or > elsewhere within the module. Relying on some offbase startup functionWhat's an "offbase startup function"? -- Grant Edwards grant.b.edwards Yow! My EARS are GONE!! at gmail.com
Reply by ●January 31, 20112011-01-31
On Mon, 31 Jan 2011 19:20:41 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote:>On 2011-01-31, Jon Kirwan <jonk@infinitefactors.org> wrote: >> On Mon, 31 Jan 2011 17:31:44 +0000, ChrisQ <meru@devnull.com> >> wrote: >> >>>I still have a look at the TI msp pages from time to time, but I think >>>you are right in that TI never saw it as a long term expandable >>>architecture. Otherwise, why would they effectively sit on it for ten >>>years while the rest of the world moved on ?. I guess in the end, a gp >>>16 bit register set doesn't translate well to > 16 bits worth of address >>>space, however it's done... >> >> I think there were serious mistakes made in the design (and >> implementation.) The failure to anticipate a wider >> addressing space isn't among the ones that bother me most. > >Or they decided that MSP430 was a small 16-bit CPU that wasn't >intended to compete with ARM-based solutions.I didn't imagine that being a problem, either. Jon
Reply by ●January 31, 20112011-01-31
On Sun, 30 Jan 2011 17:44:50 +0000, ChrisQ <meru@devnull.com> wrote:>Tauno Voipio wrote: >> On 30.1.11 6:06 , ChrisQ wrote: >> >>> msp430 is about as close as you can get to pdp11 architecture, >>> without actually having one, but the limited address space and lack >>> of external address bus limits it's application. Perhaps later >>> versions have addressed this. >> >> >> The basic PDP-11 had 64 kbytes of addresses, of which 8 kbytes at the >> end were reserved for I/O. What's the difference? >> > >Agreed, but the later pdp11's had first 18 and then 22 bits of address, >or 4 Mbytes of address space, which would be quite respectable for embedded >work even by modern standards.Unfortunately 1 MB was the maximum that you could get with core memory, due to the memory bus length limitation. With faulty 16 Kib DRAM chips with only 8 Kib actual memory, you could populate the whole 4 MiB within the memory bus limitations.
Reply by ●January 31, 20112011-01-31
Arlet Ottens wrote:> > I don't agree that using statically initialized variables is a > 'recipe for future bugs'. The start up code is usually small, and > easily verified to be correct. After all, initializing BSS is just a > memset(), and initializing DATA is just a memcpy(). Depending on the > correctness of this tiny bit of code is no worse than depending on > the rest of the run time library, including such things as memset(), > memcpy(), and non-native arithmetic, such as float math on an integer > CPU. > > > On the contrary, I think having to write and call all kinds of > xxx_init() functions is an easier way to introduce bugs. >Modules can have variables or sets of variables that need to be initialised to values (most ?) other than zero and it makes sense that all that stuff should be centered in one place, including that to be set to zero. If you have a function dedicated to the task within the module, it's so much clearer than if some of it is done there and other bits delegated elsewhere in the system. Otherwise there's an implied link and dependency to an external module, together with the assumption that the work will be done. At driver / bsp level, you have to set up all the peripheral hardware registers anyway, so an init function is needed within the module, not elsewhere, if you are fussy about modularity and encapsulation. Different strokes for different folks I guess, such is the nature of the art :-)... Regards, Chris
Reply by ●February 1, 20112011-02-01
On 31/01/2011 23:31, ChrisQ wrote:> Arlet Ottens wrote: > >> >> I don't agree that using statically initialized variables is a 'recipe >> for future bugs'. The start up code is usually small, and easily >> verified to be correct. After all, initializing BSS is just a >> memset(), and initializing DATA is just a memcpy(). Depending on the >> correctness of this tiny bit of code is no worse than depending on the >> rest of the run time library, including such things as memset(), >> memcpy(), and non-native arithmetic, such as float math on an integer >> CPU. >> >> >> On the contrary, I think having to write and call all kinds of >> xxx_init() functions is an easier way to introduce bugs. >> > > > > Modules can have variables or sets of variables that need to be > initialised to values (most ?) other than zero and it makes sense > that all that stuff should be centered in one place, including that to > be set to zero. If you have a function dedicated to the task within the > module, it's so much clearer than if some of it is done there and other > bits delegated elsewhere in the system. Otherwise there's an implied > link and dependency to an external module, together with the assumption > that the work will be done. At driver / bsp level, you have to set up > all the peripheral hardware registers anyway, so an init function is > needed within the module, not elsewhere, if you are fussy about > modularity and encapsulation. >If you want to initialise data to something other than 0, you can do so when the item is defined. It is not dependent on any linking or external module other than the standard startup code that is always present in a C program (unless you have specifically chosen not to have it). And the assumption that all this work will be done is a valid assumption - unless you have CCS. I have no objection to the idea of initialising data inside some sort of init function - my modules almost always have an init function, even if it happens to be empty. And I have no problems with different styles - if you think your programs are clearer with explicit initialisation in an init function, then that's fine. Some people like to collect all global and file-scope variables at the start of the module, others spread them out throughout the module. Some people like to use function-static data whenever possible, others like such data to be file-static. These things are a matter of taste and style. I don't entirely agree with your choices, but they are /your/ choices to make. But it is simply wrong for a compiler vendor to force a particular style because they fail to implement the required parts of the language needed for other styles.> Different strokes for different folks I guess, such is the nature of the > art :-)... >
