> 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 :-)...
>
Reply by ChrisQ●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 ●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 Jon Kirwan●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 Grant Edwards●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 function
What's an "offbase startup function"?
--
Grant Edwards grant.b.edwards Yow! My EARS are GONE!!
at
gmail.com
Reply by Grant Edwards●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 Jon Kirwan●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 Arlet Ottens●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 ChrisQ●January 31, 20112011-01-31
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
Reply by ChrisQ●January 31, 20112011-01-31
Tauno Voipio wrote:
> On 30.1.11 10:17 , ChrisQ wrote:
>> Tauno Voipio wrote:
>>
>> Much more work to do, but a couple of other things. The stm32F series
>> has an external memory interface which should make it easy to drive
>> memory or mapped lcd controller devices. Both also have fancy dma modes,
>> but the nxp series also has a scatter gather dma mode via linked lists
>> in memory, which could be very usefull in optimising io bandwidth.
>> Together with the low end 1100 nxp series, they could replace just about
>> all applications here, including 8 bit. They are relatively cheap as
>> well. Time will tell, but nothing else seems to get close in capability
>> at present.
>>
>> What do you think and have you done any work with Cortex ?...
>
>
> There was an accident - the 10 years old production
> documents of an AT91 ARM7TDMI -based intelligent sensor
> card got destroyed, and the customers want a replacement.
>
> Our team had to create something fast, and we eneded up
> with a LM3S818 Cortex-M chip. Porting the old code to the
> new processor was done in two weeks and as a surprise to
> everybody, it worked. The toolkit in use is the GNU Compiler
> suite (GCC + GDB and binutils) for both targets. The most
> complicated thing in the porting was to change the multi-
> thread kernel for the newer interrupt and thread switching
> hardware mechanisms.
>
> The Cortex-M is surprisingly fast, especially for handling
> interrupts and thread switches.
Two weeks :-) - Illustrates better than anything how the use of near
common architectures can save time, not to mention the benefit in terms
of software reuse.
Have you got the Joseph Yiu book on the M3 ?. Bought a copy on abe over
the holiday and it's full of usefull info, code examples etc. Fills in
most of
the gaps in the data sheets and mfr code...
Regards,
Chris