avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] RE: data segment init code & .data size calculations


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] RE: data segment init code & .data size calculations
Date: Mon, 13 Sep 2004 11:11:58 +0200
User-agent: Mutt/1.5.6i

As Erik Christiansen wrote:

> > >Just a nit: .bss is not for `locals', but for global/static
> > >variables that default to the initialization value of 0 (or
> > >NULL).

> > So far I thought that uninitialized data (static/global) go to
> > .bss and initialized ones go to .data.

> Yep.

That's exactly what I wrote, except that `uninitalized' is a misnomer
in that context: it means you didn't write an initializer for them,
but the C standard guarantees you that they are initialized to
0/0.0/NULL.  (Note: this applies to all global or static data *only*!
Automatic variables lacking an initializer do indeed have random
data.)

> > Do you mean, that also e.g. static int a=0; goes to bss?

> Nope, ...

Starting with GCC 3, actually yes.  GCC is now smart enough to detect
the superfluous initialization with 0, and moves the variable to .bss
then.  Previously, it didn't (and probably many other compilers don't
do it either), which means that you wasted space by writing a
superfluous initializer.  On general purpose machines (like PCs), this
means the file size will uselessly grow up (.bss doesn't take up space
in the file, only its total length is recorded so the startup code can
zero the respective region, while .data takes space in the file), on
microcontrollers, it's wasting precious ROM (to carry the initializer
data) for just nothing.

Thus, many C programmers (me included :) consider it poor style to
write superfluous initializers.

> ... but it is a convention, that the "uninitialized data" is actually
> initialised to zero.

It's not a convention, it's a guarantee given by the C standard.
Thus, you are absolutely allowed (and encouraged, see above :) to rely
on this.

> There are said to be C programs that won't work unless this is
> so. (Though few of us would admit to writing them. :)

I admit.  If the standard says I can rely on it, there's no point in
arguing over it.  If a program fails then anyway, it's been because it
didn't run in an environment that was conforming to the C standard.
In that case, it means the program was just random brabble to the
compiler anyway, since such an environment could violate any other
clause of the standard as well.

AVR-GCC/avr-libc has this .noinit section as an extension, where you
can place a variable into that won't get an automatic initialization.
This is intented for variables that ought to survive a hardware reset
of the MCU.  Of course, it's up to the programmer then to find a way
how to initially place some useful data into them.  Usually this would
be something like examining the reset source, and initializing them
only for a power-up reset (which of course requires that you don't
force an external reset on power-up).

-- 
J"org Wunsch                                           Unix support engineer
Wir stellen aus! Auf der SYSTEMS 2004  vom 18.-22. Oktober in München
Halle B 3, Stand 320-206 (Partner-Stand von Sun Microsystems)
Halle B 2, Stand 605 "Die Musterfirma"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]