Hi,
static is also good for initialising recursively with zero/null,
because a static delaration without explicit initialisation means
recursively initialisation with zero/null.
That's good for initialisation of big objects, e. g. of type pthread_t.
Regards,
Rolf
mspgcc-users@lists.sourceforge.net schrieb am 04.11.05 18:02:26:
>
> >> that people can't really get the hang of. static is even worse.
>
> That's because it has TWO meanings, depending on context:
> "private to this file" and "don't store on stack - store in a fixed RAM
> location."
>
> The initialisation & recursion etc issues caused by the second usage also
> cause problems!
>
> Isn't C wonderful? :)
>
> Richard
>
>
> ----- Original Message -----
> From: "Steve Underwood" <ste...@coppice.org>
> To: <mspgcc-users@lists.sourceforge.net>
> Sent: Friday, November 04, 2005 3:16 PM
> Subject: Re: [Mspgcc-users] Attn Steve Underwood, mspgcc online manual
> section 7, "tips and tricks", opinions and questions
>
>
> > Kris Heidenstrom wrote:
> >
> >>Hi all,
> >>
> >>I couldn't find an email address for Steve Underwood, who wrote the very
> >>good online manual for mspgcc, so I'm posting
> >>this message on the mspgcc-users forum (even though I'm not a user :-)
> >>
> >>In response to the "tips and trick [sic] for efficient programming"
> >>section. I agree with most of these recommendations
> >>and thank you for a good quality piece of work. I think some explanations
> >>would be appropriate, rather than just the
> >>guidelines. I have specific comments on a few points:
> >>
> >>
> >>>5. Avoid using global variables of small size - it is a waste of RAM.
> >>>
> >>
> >>I don't understand this at all. It's normal for an embedded program to
> >>have lots of global variables, and many of these
> >>will be bytes. If you mean what you wrote, I disagree and I don't see your
> >>point. If you mean something else, perhaps
> >>you could make the wording clearer. By "small size" do you mean smaller
> >>than a byte?
> >>
> > Have you looked at the typical embedded programmer's work? 90% of all
> > their variable are global. It derives from poor assembly language
> > programming, I guess, and the style is carried over to poor C programming.
> >
> >>>6. Avoid using volatiles, unless they are really necessary.
> >>>
> >>
> >>No one would ever declare a variable volatile unless there was a good
> >>reason to. Are you saying that the compiler can
> >>optimise better with variables which aren't volatile? That's normal for
> >>any compiler AFAIK.
> >>
> > Do you have any idea how small a percentage of embedded C programmers
> > understand what volatile really means, and where it is needed?
> >
> > Lots of people who have used the IAR tools complain about GCC being
> > broken, because changes to a global are not sensed. The IAR compiler is
> > too dumb to optimise away most things, and you can be sloppy and leave out
> > all the volatiles. Most programmers do. At the other extreme, some people
> > put volatile in front of everything. That looses you a lot of space and
> > speed optimisation with GCC.
> >
> > const is another important keyword, especially for embedded systems, that
> > people can't really get the hang of. static is even worse.
> >
> >>>7. Use int instead of char or unsigned char if you want an 8 bit integer.
> >>>
> >>
> >>What? An unsigned char _is_ 8 bits wide. Do you mean the case where you
> >>need eight bits _plus sign_? That would be a
> >>9-bit integer.
> >>
> > If you use a char or unsigned char as a simple small integer, like a loop
> > counter, the code will be bigger and slower than using the natural integer
> > of the machine - an int. Perhaps I use expand the wording there.
> >
> >>>18. If you execute
> >>> while ((long) a & 0x80000l);
> >>> the program will hang, unless 'a' is declared volatile. So, do it!
> >>>
> >>
> >>That would be a really weird and pointless thing to write, unless you
> >>_know_ that 'a' is volatile and _will_ be changed
> >>elsewhere, e.g. by an interrupt handler. And I think you mean "So, _don't_
> >>do it!"
> >>
> > Maybe the wording could be better. My intention by "do it" is do declare
> > the thing volatile. I should change the order too, to group this with
> > other volatile related points.
> >
> >>>19. Delay loops are very sophisticated routines.
> >>>[...]
> >>>
> >>
> >>I don't think delay loops are necessarily "poor programming style" in the
> >>context of an embedded system where the MCU
> >>clock frequency is known and the device has a (fairly) predictable number
> >>of cycles per instruction. If you want to
> >>delay by a few microseconds, a loop is the obvious way - you could use a
> >>timer (if you have one spare), with or without
> >>an interrupt, but this would add lots of overhead, and a very short tight
> >>delay would not be achievable. True the
> >>maximum execution time is not defined if interrupts are used and
> >>interrupts are enabled during the loop, but this is
> >>often not the case - it depends on the context in which the code is used.
> >>In any case, it's not always necessary to have
> >>a maximum limit on the delay time - for a safety timeout, for example,
> >>it's just necessary to avoid getting stuck
> >>forever in a loop somewhere due to some hardware failure. Instead of
> >>saying words to the effect of "don't do it", you
> >>could suggest how to trick the compiler into not optimising the loop away
> >>into the ether. For example, adding an
> >>"asm("nop")" (or mspgcc's equivalent) in the body of the loop might be
> >>enough; if there's no recommendable way to do
> >>this, perhaps you should add a feature to the compiler to specifically
> >>support short delays, e.g. it could generate the
> >>loop itself, given a number of CPU cycles for the delay. Short delay loops
> >>are common in embedded systems software; some
> >>conventions that apply to other programming situations apply less or not
> >>at all to an embedded system. Just a
> >>suggestion.
> >>
> > Delay loops are often the only appropriate way to get a small predictable
> > delay. There's nothing wrong with that. There is something wrong with
> > for (i = 0; i < 10; i++);
> > GCC will optimise it clean away, unless i is a global volatile. Even if i
> > a global volatile, the speed of the loop is totally uncertain. The
> > brief_pause routine I show in the manual is what I would call a good pause
> > routine - compact and basically predictable. Sure, and interrupt could
> > extend it, but these things are usually there to impose a well defined
> > minimum delay. Adding _NOP() is wasteful - maybe only a little, but still
> > poor style when you are programming a 1k chip.
> >
> >>
> >>>Do not do anything unless you know what you're doing :)
> >>>
> >>
> >>Very good advice for all embedded systems programmers!
> >>
> >>
> > Steve
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server.
> > Download
> > it for free - -and be entered to win a 42" plasma tv or your very own
> > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
> >
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
