memory required for a c program

Discussion in 'C Programming' started by Hemal, Sep 25, 2006.

  1. Hemal

    Hemal Guest

    Hi All,

    I need to know the memory required by a c program. Is there any
    tool/utility which can give me the memory usage in terms of DATA
    segment, TEXT segment, BSS segment etc.

    I am working on linux platform and my target is ARM processor. But i
    guess it should not matter. Actually i need to know both RAM & ROM
    usage.

    I searched the messages posted on this group as well as on the embedded
    group but could not find anything meaningful. Would appreciate the
    help.

    Regards
    Hemal
    Hemal, Sep 25, 2006
    #1
    1. Advertising

  2. Hemal

    Guest

    Hemal wrote:
    > Hi All,
    >
    > I need to know the memory required by a c program. Is there any
    > tool/utility which can give me the memory usage in terms of DATA
    > segment, TEXT segment, BSS segment etc.
    >
    > I am working on linux platform and my target is ARM processor. But i
    > guess it should not matter. Actually i need to know both RAM & ROM
    > usage.
    >
    > I searched the messages posted on this group as well as on the embedded
    > group but could not find anything meaningful. Would appreciate the
    > help.
    >
    > Regards
    > Hemal


    look for "size" in the compilers bin directory

    -Lasse
    , Sep 25, 2006
    #2
    1. Advertising

  3. In article <>,
    Hemal <> wrote:

    >I need to know the memory required by a c program. Is there any
    >tool/utility which can give me the memory usage in terms of DATA
    >segment, TEXT segment, BSS segment etc.


    You might be able to get some of those, but it isn't difficult to
    prove that there cannot be any general tool which can reliably
    examine source and calculate the amount of stack and heap required
    by arbitrary programs.

    (For example, you can write a simple iterative search for odd
    "perfect numbers", and when you find one, allocate that number
    of bytes. Despite extensive searches, there are no known odd
    perfect numbers, but there is also no proof that they cannot
    exist, so in order for a program to be able to analyze the source
    and predict its memory usage, the examining program would first have to
    solve the "odd perfect number" problem...)


    >I am working on linux platform and my target is ARM processor. But i
    >guess it should not matter.


    Yes, it matters a lot, as a number of operating systems do not
    use DATA or TEXT or BSS segments at all.

    >Actually i need to know both RAM & ROM
    >usage.
    >
    >I searched the messages posted on this group as well as on the embedded
    >group but could not find anything meaningful. Would appreciate the
    >help.


    It is not surprising you didn't find it in comp.lang.c, as such
    tool would be platform dependant and we strongly avoid discussion of
    platform dependancies here. You should check a linux programming
    group.


    [Off topic]
    If your platform offers the elfdump or dwarfdump tools, you might
    be able to dig out some information of interest.

    Also, your platform's linker might support a "registry file",
    possibly named so_locations .

    --
    All is vanity. -- Ecclesiastes
    Walter Roberson, Sep 25, 2006
    #3
  4. Hemal

    Hemal Guest

    Thanks. "size" gave me the information & i believe it is ROM size.

    Although below question may not belong to this group but in
    continuation to above question

    Is there any difference between RAM & ROM size for same code & if yes
    why? My understanding is ROM size is large as it contains additional
    ReadOnly TEXT section.

    Thanks
    -Hemal

    wrote:
    > Hemal wrote:
    > > Hi All,
    > >
    > > I need to know the memory required by a c program. Is there any
    > > tool/utility which can give me the memory usage in terms of DATA
    > > segment, TEXT segment, BSS segment etc.
    > >
    > > I am working on linux platform and my target is ARM processor. But i
    > > guess it should not matter. Actually i need to know both RAM & ROM
    > > usage.
    > >
    > > I searched the messages posted on this group as well as on the embedded
    > > group but could not find anything meaningful. Would appreciate the
    > > help.
    > >
    > > Regards
    > > Hemal

    >
    > look for "size" in the compilers bin directory
    >
    > -Lasse
    Hemal, Sep 25, 2006
    #4
  5. Hemal

    Hemal Guest

    Thanks for your help but i couldn't make out from what you mean by "odd
    perfect numbers".

    -Hemal
    Walter Roberson wrote:
    > In article <>,
    > Hemal <> wrote:
    >
    > >I need to know the memory required by a c program. Is there any
    > >tool/utility which can give me the memory usage in terms of DATA
    > >segment, TEXT segment, BSS segment etc.

    >
    > You might be able to get some of those, but it isn't difficult to
    > prove that there cannot be any general tool which can reliably
    > examine source and calculate the amount of stack and heap required
    > by arbitrary programs.
    >
    > (For example, you can write a simple iterative search for odd
    > "perfect numbers", and when you find one, allocate that number
    > of bytes. Despite extensive searches, there are no known odd
    > perfect numbers, but there is also no proof that they cannot
    > exist, so in order for a program to be able to analyze the source
    > and predict its memory usage, the examining program would first have to
    > solve the "odd perfect number" problem...)
    >
    >
    > >I am working on linux platform and my target is ARM processor. But i
    > >guess it should not matter.

    >
    > Yes, it matters a lot, as a number of operating systems do not
    > use DATA or TEXT or BSS segments at all.
    >
    > >Actually i need to know both RAM & ROM
    > >usage.
    > >
    > >I searched the messages posted on this group as well as on the embedded
    > >group but could not find anything meaningful. Would appreciate the
    > >help.

    >
    > It is not surprising you didn't find it in comp.lang.c, as such
    > tool would be platform dependant and we strongly avoid discussion of
    > platform dependancies here. You should check a linux programming
    > group.
    >
    >
    > [Off topic]
    > If your platform offers the elfdump or dwarfdump tools, you might
    > be able to dig out some information of interest.
    >
    > Also, your platform's linker might support a "registry file",
    > possibly named so_locations .
    >
    > --
    > All is vanity. -- Ecclesiastes
    Hemal, Sep 25, 2006
    #5
  6. In article <>,
    Hemal <> wrote:
    >Thanks for your help but i couldn't make out from what you mean by "odd
    >perfect numbers".


    http://en.wikipedia.org/wiki/Perfect_number

    The exact meaning wasn't relevant to the discussion; the
    point was that it was there was no known theoretical way to
    solve the problem.

    Recapping, the point was that there *cannot* be a program
    which reliably predicts run-time memory usage of arbitrary programs,
    even if full source (or executable) is available.

    The proof that such programs *cannot* exist was a simple proof by
    contradiction: assume that such a program, P, exists; now run P on
    a program Q. Q is a program that finds a certain number by trial
    (test each number in turn) when there is no analytic way
    to find those kinds of numbers. Add a twist to the program Q such
    that once it has found the number, it allocates an amount of memory
    equal to the number it has found. Now, in order for P run on Q to
    predict how much memory Q will allocate, P would have to be able to
    analyze Q and solve what Q would find: only once P knows analytically
    the answer to Q can P know how much memory Q would eventually allocate.
    However, in order for P to know analytically what Q will do, P
    would have to find an analytic way to calculate something that
    our premises said does not *have* an analytic solution. Since P
    cannot do the impossible, we conclude that program P does not exist.


    There are, though -some- programs that can be analyzed for memory use;
    there just isn't any way to analyze -every- program.

    But you didn't ask for a tool to analyze the memory usage of a
    -particular- program, you {implicitly} asked for a tool to analyze
    the memory usage of whatever programs you happen to construct. You
    were looking for a general analysis tool... and those CANNOT exist
    (at least and give the correct answer :) )
    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
    Walter Roberson, Sep 26, 2006
    #6
  7. Hemal

    CBFalconer Guest

    Hemal wrote:
    >
    > I need to know the memory required by a c program. Is there any
    > tool/utility which can give me the memory usage in terms of DATA
    > segment, TEXT segment, BSS segment etc.
    >
    > I am working on linux platform and my target is ARM processor.
    > But i guess it should not matter. Actually i need to know both
    > RAM & ROM usage.


    This is system specific, and thus off-topic on c.l.c.
    comp.unix.programmer might be able to help. In general you should
    look at your system documentation for a way to make the link phase
    emit a loadmap.

    --
    Some informative links:
    <news:news.announce.newusers
    <http://www.geocities.com/nnqweb/>
    <http://www.catb.org/~esr/faqs/smart-questions.html>
    <http://www.caliburn.nl/topposting.html>
    <http://www.netmeister.org/news/learn2quote.html>
    <http://cfaj.freeshell.org/google/>
    CBFalconer, Sep 26, 2006
    #7
  8. Hemal

    Snis Pilbor Guest

    Walter Roberson wrote:
    > In article <>,
    > Hemal <> wrote:
    > >Thanks for your help but i couldn't make out from what you mean by "odd
    > >perfect numbers".

    >
    > Recapping, the point was that there *cannot* be a program
    > which reliably predicts run-time memory usage of arbitrary programs,
    > even if full source (or executable) is available.
    >
    > The proof that such programs *cannot* exist was a simple proof by
    > contradiction: assume that such a program, P, exists; now run P on
    > a program Q. Q is a program that finds a certain number by trial
    > (test each number in turn) when there is no analytic way
    > to find those kinds of numbers. Add a twist to the program Q such
    > that once it has found the number, it allocates an amount of memory
    > equal to the number it has found. Now, in order for P run on Q to
    > predict how much memory Q will allocate, P would have to be able to
    > analyze Q and solve what Q would find: only once P knows analytically
    > the answer to Q can P know how much memory Q would eventually allocate.
    > However, in order for P to know analytically what Q will do, P
    > would have to find an analytic way to calculate something that
    > our premises said does not *have* an analytic solution. Since P
    > cannot do the impossible, we conclude that program P does not exist.
    >


    This is completely off-topic nitpicking, but the odd perfect number
    approach is not a real proof. This is a common error in computability
    theory: people assume that highly difficult tasks are uncomputable,
    which can hardly be further from the truth. There's a famous trick
    question, "Let f(x)=1 if God exists, 0 if not. Is f(x) computable?"
    The answer is of course "yes" since the constantly 1 function and the
    constantly 0 function are both computable and f is one of these.

    A correct proof that a general memory-predictor is impossible is more
    subtle than meets the eye, because a looping program can, during its
    infinite loop, chew up more and more memory, so the trick (which you're
    essentially trying to use) of allocating a big block upon halting,
    doesn't really work. No matter how big a block we choose, for all we
    know the program might chew up precisely that much memory and yet still
    not halt, so our memory-predictor sheds no light on the halting problem
    that way. Probably the easiest way to prove the program in question is
    impossible, is Rice's theorem. Of course it would be nice if someone
    can come up with an easier proof, since Rice's theorem is rather
    overkill here...
    Snis Pilbor, Sep 26, 2006
    #8
  9. In article <>,
    Hemal <> wrote:

    >Although below question may not belong to this group but in
    >continuation to above question


    >Is there any difference between RAM & ROM size for same code & if yes
    >why? My understanding is ROM size is large as it contains additional
    >ReadOnly TEXT section.


    That'd be implementation dependant...

    ROM can be large; ROM can be small; RAM can be large, RAM can be small.
    Some systems have none of one; some have none of the other.

    You might have a program that needs a lot of writable memory (RAM) to
    do its calculations, even though the code might be small and the
    number of constants to look up might be small. For example, it
    might calculate the exact value of 3 multiplied by itself a billion
    times. Just a lot of repeated calculations.

    You might have a program that can do the bulk of its work from static
    lookup tables, without needing much working memory. For such a program,
    the static tables could be put in ROM and a small RAM used.

    Pure ROM systems (no RAM other than CPU registers) can be found in
    a few embedded systems such as toasters.

    Pure RAM systems, with no ROM (or equivilent) at all, are more
    difficult, but can be constructed from "static RAM", "non-volatile RAM",
    and similar memory types that are writable but do not lose information
    when the power is removed. Failing that, there's always hardware-level
    bootstrapping :)
    --
    Programming is what happens while you're busy making other plans.
    Walter Roberson, Sep 26, 2006
    #9
  10. Hemal

    Snis Pilbor Guest

    Snis Pilbor wrote:
    > Walter Roberson wrote:
    > > In article <>,
    > > Hemal <> wrote:
    > > >Thanks for your help but i couldn't make out from what you mean by "odd
    > > >perfect numbers".

    > >
    > > Recapping, the point was that there *cannot* be a program
    > > which reliably predicts run-time memory usage of arbitrary programs,
    > > even if full source (or executable) is available.
    > >
    > > The proof that such programs *cannot* exist was a simple proof by
    > > contradiction: assume that such a program, P, exists; now run P on
    > > a program Q. Q is a program that finds a certain number by trial
    > > (test each number in turn) when there is no analytic way
    > > to find those kinds of numbers. Add a twist to the program Q such
    > > that once it has found the number, it allocates an amount of memory
    > > equal to the number it has found. Now, in order for P run on Q to
    > > predict how much memory Q will allocate, P would have to be able to
    > > analyze Q and solve what Q would find: only once P knows analytically
    > > the answer to Q can P know how much memory Q would eventually allocate.
    > > However, in order for P to know analytically what Q will do, P
    > > would have to find an analytic way to calculate something that
    > > our premises said does not *have* an analytic solution. Since P
    > > cannot do the impossible, we conclude that program P does not exist.
    > >

    >
    > This is completely off-topic nitpicking, but the odd perfect number
    > approach is not a real proof. This is a common error in computability
    > theory: people assume that highly difficult tasks are uncomputable,
    > which can hardly be further from the truth. There's a famous trick
    > question, "Let f(x)=1 if God exists, 0 if not. Is f(x) computable?"
    > The answer is of course "yes" since the constantly 1 function and the
    > constantly 0 function are both computable and f is one of these.
    >
    > A correct proof that a general memory-predictor is impossible is more
    > subtle than meets the eye, because a looping program can, during its
    > infinite loop, chew up more and more memory, so the trick (which you're
    > essentially trying to use) of allocating a big block upon halting,
    > doesn't really work. No matter how big a block we choose, for all we
    > know the program might chew up precisely that much memory and yet still
    > not halt, so our memory-predictor sheds no light on the halting problem
    > that way. Probably the easiest way to prove the program in question is
    > impossible, is Rice's theorem. Of course it would be nice if someone
    > can come up with an easier proof, since Rice's theorem is rather
    > overkill here...


    Ah, upon further consideration, I realized Rice's theorem doesn't even
    apply, since this is a question which depends upon the model of
    computation, not just the functions themselves.

    But I managed to think up a proof.

    Theorem: Assuming we're working on an ideal computer with infinite
    memory, no program P exists which can predict how much memory an
    arbitrary program Q will require.

    Proof: Suppose such a program P exists. We'll now solve the halting
    problem. Suppose n is an integer, so we need to give an algorithm to
    tell whether the program with machine code n, when run on input n, will
    halt. Proceed as follows. Write a program Q which simulates the
    program with machine code n, with input n, but set it up so the
    simulation always invokes twice as much memory as the simulated program
    asks for. Also ensure that the simulator itself uses an even number of
    bytes for any overhead it needs (even if this means allocating
    additional dummy memory). Throughout the simulation, keep track of the
    maximum memory required by the simulator at any point so far. If the
    simulated program ever halts, then Q will free all memory, and allocate
    a block of odd size, and so big that it is bigger than the biggest
    amount of memory required hitherto. Now the program with machine code
    n, given input n, will halt if and only if Q will require an odd number
    of bytes, and we can determine this by plugging Q into P. So we've
    solved the halting problem, absurd, therefore no such P exists.
    Snis Pilbor, Sep 26, 2006
    #10
    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. Just D.
    Replies:
    0
    Views:
    446
    Just D.
    Mar 10, 2006
  2. Sourin

    code using more memory than required

    Sourin, Aug 25, 2003, in forum: C Programming
    Replies:
    3
    Views:
    291
    Eric Sosman
    Aug 25, 2003
  3. Ian Collins
    Replies:
    1
    Views:
    394
    Liviu
    Mar 28, 2010
  4. Jonathan Lee
    Replies:
    1
    Views:
    415
    Jonathan Lee
    Mar 30, 2010
  5. Pablo

    object required, problem with memory?

    Pablo, Jun 18, 2004, in forum: ASP General
    Replies:
    0
    Views:
    132
    Pablo
    Jun 18, 2004
Loading...

Share This Page