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
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.
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
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!!
What's an "offbase startup function"?
--
Grant Edwards grant.b.edwards Yow! My EARS are GONE!!
at
gmail.com
I didn't imagine that being a problem, either.
Jon
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.
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
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.