Hi,
there is no difference between a file and a function static.
I'm often using static because if complete initialisation is not done,
the results can be random results and compiler and environment
dependent bugs.
Regards,
Rolf
-------------------------------------------------------------------------------------------
mspgcc-users@lists.sourceforge.net schrieb am 04.11.05 22:31:27:
>
> >> 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.
>
> I'd forgotten about that [if I ever knew it!] ... is that for file level
> statics only ... or for statics inside functions too?
>
> ----- Original Message -----
> From: <nobo...@web.de>
> To: <mspgcc-users@lists.sourceforge.net>
> Sent: Friday, November 04, 2005 8:27 PM
> Subject: Re: [Mspgcc-users] Attn Steve Underwood, mspgcc online manual
> section 7, "tips and tricks", opinions and questions - static
>
>
> >
> > 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
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
