Memory used by the program

Discussion in 'C Programming' started by Horacius ReX, Sep 22, 2008.

  1. Horacius ReX

    Horacius ReX Guest

    Hi,

    I am developing some code in C which first I compile on my linux
    machine and afterwards
    I test on another special hardware which has almost no debug
    capabilities at all. Usually I get a lot of errors in the latter,
    because I have memory size limitations. So, I wonder what are the best
    practices to know for a given program, once it is compiled and
    before its execution:

    - what will be the stack size available for the program
    - what will be the size of the code
    - what will be the size of the allocated data (global variables, etc)
    - if it is also possible to estimate the size of the heap used

    Thanks in advance
    H
    Horacius ReX, Sep 22, 2008
    #1
    1. Advertising

  2. On 22 Sep, 09:51, Horacius ReX <> wrote:

    > I am developing some code in C which first I compile on my linux
    > machine and afterwards
    > I test on another special hardware which has almost no debug
    > capabilities at all. Usually I get a lot of errors in the latter,
    > because I have memory size limitations. So, I wonder what are the best
    > practices to know for a given program, once it is compiled and
    > before its execution:
    >
    > - what will be the stack size available for the program
    > - what will be the size of the code
    > - what will be the size of the allocated data (global variables, etc)
    > - if it is also possible to estimate the size of the heap used


    I'm afraid this is all very platform specific. And on "special"
    hardware probably even more restricted.

    On embedded platforms you may be able to specify the stack size
    at compile or load time.

    You should be able to deduce the size of your executable and the
    size of staically allocated data by examining the image (somehow).

    Heap you should be able to calculate at run time by tracking
    malloc() and free().

    Try a ng group specialising in embedded software.


    --
    Nick Keighley

    Many astrologers think that this concentration on [the sun-sign
    column] has
    done untold damage to serious astrology.
    The Independent
    Nick Keighley, Sep 22, 2008
    #2
    1. Advertising

  3. Horacius ReX

    Horacius ReX Guest

    On Sep 22, 11:56 am, Nick Keighley <>
    wrote:
    > On 22 Sep, 09:51, Horacius ReX <> wrote:
    >
    > > I am developing some code in C which first I compile on my linux
    > > machine and afterwards
    > > I test on another special hardware which has almost no debug
    > > capabilities at all. Usually I get a lot of errors in the latter,
    > > because I have memory size limitations. So, I wonder what are the best
    > > practices to know for a given program, once it is compiled and
    > > before its execution:

    >
    > > - what will be the stack size available for the program
    > > - what will be the size of the code
    > > - what will be the size of the allocated data (global variables, etc)
    > > - if it is also possible to estimate the size of the heap used

    >
    > I'm afraid this is all very platform specific. And on "special"
    > hardware probably even more restricted.
    >
    > On embedded platforms you may be able to specify the stack size
    > at compile or load time.
    >
    > You should be able to deduce the size of your executable and the
    > size of staically allocated data by examining the image (somehow).
    >
    > Heap you should be able to calculate at run time by tracking
    > malloc() and free().
    >
    > Try a ng group specialising in embedded software.
    >
    > --
    > Nick Keighley
    >
    > Many astrologers think that this concentration on [the sun-sign
    > column] has
    > done untold damage to serious astrology.
    >                         The Independent


    Ok, what do you mean with "image" ?
    Horacius ReX, Sep 22, 2008
    #3
  4. On 22 Sep, 16:10, Horacius ReX <> wrote:
    > On Sep 22, 11:56 am,Nick Keighley<>
    > wrote:
    > > On 22 Sep, 09:51, Horacius ReX <> wrote:


    > > > I am developing some code in C which first I compile on my linux
    > > > machine and afterwards
    > > > I test on another special hardware which has almost no debug
    > > > capabilities at all. Usually I get a lot of errors in the latter,
    > > > because I have memory size limitations. So, I wonder what are the best
    > > > practices to know for a given program, once it is compiled and
    > > > before its execution:

    >
    > > > - what will be the stack size available for the program
    > > > - what will be the size of the code
    > > > - what will be the size of the allocated data (global variables, etc)
    > > > - if it is also possible to estimate the size of the heap used


    in general you can't find heap size without running the program.
    You could look at the heap size on the linux system
    and use that as an indication of the special hardware
    heap size (they won't, in general, match as the size of
    allocated objects will be different- and malloc overheads).

    <snip>

    > > You should be able to deduce the size of your executable and the
    > > size of staically allocated data by examining the image (somehow).


    <snip>

    > > --
    > >Nick Keighley

    >
    > > Many astrologers think that this concentration on [the sun-sign
    > > column] has
    > > done untold damage to serious astrology.
    > >                         The Independent


    you shouldn't normally quote sigs (the bit after "-- ")


    > Ok, what do you mean with "image"


    executable. (note must stop reading The Standard for fun)


    --
    Nick Keighley

    Quantum Boggum Sort:
    Q1. use a source of quantum noise (eg. radioactive decay) to
    randomly permutate an array.
    Q2. if the array is not ordered, destroy the universe (*)
    Q3. if you reached this step your universe has sorted the array
    in O(n) time.
    (*) [100] this is left as an exercise
    Nick Keighley, Sep 23, 2008
    #4
  5. Horacius ReX

    Ian Collins Guest

    Horacius ReX wrote:
    >
    > Hi,
    >
    > I am developing some code in C which first I compile on my linux
    > machine and afterwards
    > I test on another special hardware which has almost no debug
    > capabilities at all. Usually I get a lot of errors in the latter,
    > because I have memory size limitations. So, I wonder what are the best
    > practices to know for a given program, once it is compiled and
    > before its execution:
    >
    > - what will be the stack size available for the program


    This is can be worked out from a map file. Most if not all embedded
    compilers can generate one.

    > - what will be the size of the code


    Map file.

    > - what will be the size of the allocated data (global variables, etc)


    Map file.

    > - if it is also possible to estimate the size of the heap used
    >

    If you are resource constrained, go for a static design then you won't
    have to worry.

    --
    Ian Collins.
    Ian Collins, Sep 23, 2008
    #5
  6. Horacius ReX

    Horacius ReX Guest

    On Sep 23, 12:37 am, (Gordon Burditt) wrote:
    > >I am developing some code in C which first I compile on my linux
    > >machine and afterwards
    > >I test on another special hardware which has almost no debug
    > >capabilities at all.

    >
    > Just about everything you are asking for is system-specific.
    >
    > Do the host system and the target system at least have the same
    > CPU architecture?  Code size can be radically different for the
    > same program on, say, the PDP-8 vs. the x86 architecture.
    >
    > >Usually I get a lot of errors in the latter,
    > >because I have memory size limitations. So, I wonder what are the best
    > >practices to know for a given program, once it is compiled and
    > >before its execution:

    >
    > >- what will be the stack size available for the program

    >
    > The stack size *available* depends on your hardware and how you
    > lay out the address.  If space is really, really tight you may
    > have to move the split between, say, stack and data for every
    > recompilation to make it fit.
    >
    > You probably want the stack size *required*, which is harder to figure.
    >
    > Each function call requires a certain amount of stack, generally
    > the size of all auto variables for that function plus some overhead
    > for linkage, unless you're using variable-length arrays or alloca().
    > For [3456]86 architecture, I'll guess about 32 bytes of linkage
    > overhead.  Look at generated code for a more accurate answer.  You
    > may also need some initial stack overhead for whatever calls main(),
    > like command-line arguments if these are used.
    >
    > The requirement of the whole program is the worst-case requirement
    > of all functions, which depends on what functions call what other
    > functions.  If the program is recursive, this might be near-infinite,
    > in which case your limited-memory system should likely be using a
    > different non-recursive algorithm.
    >
    > For example:
    > main() uses 100 bytes and calls A, B, and C.
    > A uses 200 bytes and calls C.
    > B uses 800 bytes and doesn't call anything.
    > C uses 300 bytes and doesn't call anything.
    > D uses 15000 bytes (but nobody calls it).
    >
    > The worst case paths are:
    >
    > main+A+C = 100+200+300 = 600.
    > main+B = 100+800 = 900.
    > main+C = 100+300 = 400.
    >
    > The worst case here is main calling B, 900 bytes.
    >
    > >- what will be the size of the code
    > >- what will be the size of the allocated data (global variables, etc)

    >
    > If the executable produced has headers like those produced by standard
    > Linux tools (and the version you run *on Linux* will almost certainly
    > have them), the size(1) command will give you the size of code,
    > (initialized) data, and uninitialized data.  (This does not, however,
    > include the size of any shared libraries (on Linux) or the BIOS or
    > OS on the target system.)
    >
    > Other tools such as objdump may give you finer detail on portions of
    > the object code.
    >
    > >- if it is also possible to estimate the size of the heap used

    >
    > This is a runtime issue.  If possible, put monitoring in the program
    > that runs on Linux to track the maximum amount of simultaneously
    > allocated memory from malloc().  Otherwise, estimate it by hand.
    > The result may depend on input to the program.  It might even depend
    > on *timing* of input to the program (e.g. if this thing is acting
    > as a router and it buffers packets if it can't handle them fast
    > enough, up to a limit.)
    >
    > malloc() has overhead.  On a 32-bit machine, rounding the requested
    > amount up to a multiple of 4 and add 4 is typical of a couple of
    > malloc() implementations.


    thanks for a so good and complete answer !
    Horacius ReX, Sep 23, 2008
    #6
  7. Horacius ReX

    Horacius ReX Guest

    On Sep 23, 10:26 am, Ian Collins <> wrote:
    > Horacius ReX wrote:
    >
    > > Hi,

    >
    > > I am developing some code in C which first I compile on my linux
    > > machine and afterwards
    > > I test on another special hardware which has almost no debug
    > > capabilities at all. Usually I get a lot of errors in the latter,
    > > because I have memory size limitations. So, I wonder what are the best
    > > practices to know for a given program, once it is compiled and
    > > before its execution:

    >
    > > - what will be the stack size available for the program

    >
    > This is can be worked out from amapfile.  Most if not all embedded
    > compilers can generate one.
    >
    > > - what will be the size of the code

    >
    > Mapfile.
    >
    > > - what will be the size of the allocated data (global variables, etc)

    >
    > Mapfile.
    >
    > > - if it is also possible to estimate the size of the heap used

    >
    > If you are resource constrained, go for a static design then you won't
    > have to worry.
    >
    > --
    > Ian Collins.


    where can one get extensive documentation about the info generated in
    a map file ?

    i achieved to get it, but no google, nothing about it

    thanks
    Horacius ReX, Sep 25, 2008
    #7
  8. Horacius ReX

    Ian Collins Guest

    Horacius ReX wrote:
    > On Sep 23, 10:26 am, Ian Collins <> wrote:
    >>
    >>> - what will be the size of the allocated data (global variables, etc)

    >> Mapfile.
    >>
    >>> - if it is also possible to estimate the size of the heap used

    >> If you are resource constrained, go for a static design then you won't
    >> have to worry.
    >>

    *Please* don't quote signatures.
    >
    > where can one get extensive documentation about the info generated in
    > a map file ?
    >

    From your compiler's documentation.

    --
    Ian Collins.
    Ian Collins, Sep 26, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sune
    Replies:
    14
    Views:
    850
    Chris Thomasson
    Aug 26, 2007
  2. Sune
    Replies:
    5
    Views:
    417
    Darko
    Jul 13, 2007
  3. Casey Hawthorne
    Replies:
    1
    Views:
    696
    Arne Vajhøj
    Mar 18, 2009
  4. Ian Collins
    Replies:
    1
    Views:
    392
    Liviu
    Mar 28, 2010
  5. Ted Byers
    Replies:
    23
    Views:
    409
    Peter J. Holzer
    Nov 15, 2008
Loading...

Share This Page