Memory used by the program

[Horacius ReX]

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

[Nick Keighley]

Re: Memory used by the program

On 22 Sep, 09:51, Horacius ReX <horacius....@g mail.comwrote:

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

[Horacius ReX]

Re: Memory used by the program

On Sep 22, 11:56 am, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

On 22 Sep, 09:51, Horacius ReX <horacius....@g mail.comwrote:
>

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" ?

[Gordon Burditt]

Re: Memory used by the program

>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 .

[Nick Keighley]

Re: Memory used by the program

On 22 Sep, 16:10, Horacius ReX <horacius....@g mail.comwrote:

On Sep 22, 11:56 am,Nick Keighley<nick_k eighley_nos...@ hotmail.com>
wrote:

On 22 Sep, 09:51, Horacius ReX <horacius....@g mail.comwrote:

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

[Ian Collins]

Re: Memory used by the program

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.

[Horacius ReX]

Re: Memory used by the program

On Sep 23, 12:37 am, gordonb.ca...@b urditt.org (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]

Re: Memory used by the program

On Sep 23, 10:26 am, Ian Collins <ian-n...@hotmail.co mwrote:

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

[Ian Collins]

Re: Memory used by the program

Horacius ReX wrote:

On Sep 23, 10:26 am, Ian Collins <ian-n...@hotmail.co mwrote:

>>

>>- 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.