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

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

Re: [avr-gcc-list] Program size


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] Program size
Date: Thu, 25 Oct 2001 17:18:41 +0200 (MET DST)

Andries Posthumus <address@hidden> wrote:

> How do I know, what is the size of program memory and ram used when
> code was compiled ?

avr-size is your friend.  Run it on the (final) ELF file, and it'll
display you some values:

   text    data     bss     dec     hex filename
    812       2       7     821     335 test2.out

»text« is the size of the program memory (instructions and possibly
constant strings you've put there using »__attribute__((progmem))«).

»data« is the usage of initialized RAM (variables at global level or
with storage class »static« that have an initializer).  Since the
initialization has to be performed by the AVR before entering the main
program, those values increase the actual ROM usage (the initializer
values are stored behind the program text, and the runtime system
initializes the RAM from there).

»bss« is also part of the RAM, but contains uninitialized data.  The
runtime environment ensures these data are zeroed out before starting
main().

Thus, the above program would effectively consume 814 bytes of ROM,
and 9 bytes of RAM.

The remaining values are there because they always used to be there in
the Unix pendant of the size command; they have no useful meaning for
the AVR toolchain.

A note about data initialization: it's a common misconception for many
C newbies to declare variables at the global level or with a static
storage class like that:

int somenumber = 0;

void
somefunc(void)
{
        static int somecounter = 0;

        ...
}

just to »make sure« those variables have a »well-defined 0 value« when
entering main().  Technically however, this means you instruct the
compiler to move out those variables from bss to data.  As explained
above, this will cause additional ROM consumption on the AVR, since
the initializer values have to be carried in ROM.  The net effect
(from the program's point of view) of all this is nil; the C standard
already ensures that global and static variables are set to 0 at
startup.  (This is a simplified statement in terms of the standard,
but good enough for our consideration here.)  The runtime code
implements this C standard requirement, and zeroes out the bss.

So, always write it like that:

int somenumber;

void
somefunc(void)
{
        static int somecounter;

        ...
}

> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Please don't post HTML articles.

p.s.: No, there's no 100 % agreed explanation what »bss« actually
stands for.  The most likely version is that some old compiler used it
as an instruction standing for »block starting symbol«, and Unix has
inherited it from there.  But there are other explanations for it as
well.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/



reply via email to

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