Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » MSPGCC
  • » [Mspgcc-users] Attn Steve Underwood, mspgcc online manual section 7, "tips and tricks", opinions and questions - static [RSS Feed]

#1 Nov. 4, 2005 21:29:59

A.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] Attn Steve Underwood, mspgcc online manual section 7, "tips and tricks", opinions and questions - static


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 ... is that for file levelstatics only ... or for statics inside functions too?----- Original Message -----From: <nobo***@*eb.de>To: <mspgcc-us***@*ists.sourceforge.net>
Sent: Friday, November 04, 2005 8:27 PMSubject: Re: Attn Steve Underwood, mspgcc online manualsection 7, "tips and tricks", opinions and questions - staticHi,

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-us***@*ists.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 fixedRAMlocation."

The initialisation & recursion etc issues caused by the second usage also
cause problems!

Isn't C wonderful? :)

Richard----- Original Message -----From: "Steve Underwood" <ste***@*oppice.org>To: <mspgcc-us***@*ists.sourceforge.net>
Sent: Friday, November 04, 2005 3:16 PM
Subject: Re: 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 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-us***@*ists.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.Downloadit 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-us***@*ists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mspgcc-users-------------------------------------------------------
SF.Net email is sponsored by:Tame your development challenges with Apache's Geronimo App Server.Downloadit 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.nethttps://lists.sourceforge.net/lists/listinfo/mspgcc-users

Offline

#2 Nov. 5, 2005 08:48:25

n.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] Attn Steve Underwood, mspgcc online manual section 7, "tips and tricks", opinions and questions - static


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-us***@*ists.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 ... is that for file level
> statics only ... or for statics inside functions too?
>
> ----- Original Message -----
> From: <nobo***@*eb.de>
> To: <mspgcc-us***@*ists.sourceforge.net>
> Sent: Friday, November 04, 2005 8:27 PM
> Subject: Re: 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-us***@*ists.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***@*oppice.org>
> >> To: <mspgcc-us***@*ists.sourceforge.net>
> >> Sent: Friday, November 04, 2005 3:16 PM
> >> Subject: Re: 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 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-us***@*ists.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-us***@*ists.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-us***@*ists.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

Offline

#3 Nov. 8, 2005 07:46:38

Robert D.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] Attn Steve Underwood, mspgcc online manual section 7, "tips and tricks", opinions and questions - static


Hello all!

Augmentics. schrieb: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 ... is that for file levelstatics only ... or for statics inside functions too?"static" will store the variable in the RAM. And by C standard
the used RAM is set to zero in the start-up code. By this,
all statics get initialized with zero unless you explizitly
change the start-up code.

But I think it is a good idea to write the initialization
to the code even if it is unnecessary. The compiler should
eliminate this and only initialization with different values
should be done during start-up.


Robert Dominicus-Schleutermann

--
Robert Dominicus-Schleutermann Telefon : +49 36203 96314
Software+Systeme Erfurt GmbH Telefon : +49 36203 96301
Fichtenweg 8 Fax : +49 36203 96333
D-99198 Erfurt-Kerspleben
eMail:mailto:robert.dominicus-schleuterm...@sse-erfurt.de

Offline

  • Root
  • » MSPGCC
  • » [Mspgcc-users] Attn Steve Underwood, mspgcc online manual section 7, "tips and tricks", opinions and questions - static [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of November
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support