about memory model

Discussion in 'C Programming' started by kumar, May 26, 2008.

  1. kumar

    kumar Guest

    hi
    i want to know where & how the C variables gets stored
    i mean like volatile , pointer and string variables gets stored ,
    whether it is on stack or some other places
    if is there any clear document , plz suggest the link
    kumar, May 26, 2008
    #1
    1. Advertising

  2. kumar

    Ian Collins Guest

    kumar wrote:
    > hi
    > i want to know where & how the C variables gets stored
    > i mean like volatile , pointer and string variables gets stored ,
    > whether it is on stack or some other places
    > if is there any clear document , plz suggest the link


    The word is "please".

    The best place to find the answer is in your compiler or platform
    documentation. The details of where variables are stored are
    implementation specific.

    --
    Ian Collins.
    Ian Collins, May 26, 2008
    #2
    1. Advertising

  3. On Mon, May 26, 2008 at 12:29:21AM -0700, kumar wrote:
    > hi
    > i want to know where & how the C variables gets stored
    > i mean like volatile , pointer and string variables gets stored ,
    > whether it is on stack or some other places


    The nice thing with C is that you do not have to think about this
    when you program in standard C. Whenever you think about these details
    you loose the portability of your program, since the storage of the
    variables is left for the discretion of the implementors.

    The concept of stack is not part of the language, but variables with
    automatic storage (local variables without the static keyword) are
    stored by most systems on some sort of stack. The global variables
    and those declared with the static keyword are stored in a designated
    section of memory, and they are initialised before main() is called.
    The memory for dynamical variables are asked from the operating system,
    whenever you call malloc(). There is an other storage class specifier,
    register, which suggests that the variable should be stored in a cpu register,
    but compilers are free to ignore that keyword (but all have to document
    the effect of the register keyword.)
    The qualifiers (e.g. const, volatile) do not affect the storage, but they
    do have an impact on the access to those variables.

    It is difficult to tell more without knowing your system and your intentions.
    It is not polite to ask if you really need the information you have asked for,
    but it is difficult to resist.

    Szabolcs
    Szabolcs Borsanyi, May 26, 2008
    #3
  4. kumar

    Flash Gordon Guest

    Szabolcs Borsanyi wrote, On 26/05/08 10:18:
    > On Mon, May 26, 2008 at 12:29:21AM -0700, kumar wrote:
    >> hi
    >> i want to know where & how the C variables gets stored
    >> i mean like volatile , pointer and string variables gets stored ,
    >> whether it is on stack or some other places

    >
    > The nice thing with C is that you do not have to think about this
    > when you program in standard C. Whenever you think about these details
    > you loose the portability of your program, since the storage of the
    > variables is left for the discretion of the implementors.
    >
    > The concept of stack is not part of the language, but variables with
    > automatic storage (local variables without the static keyword) are
    > stored by most systems on some sort of stack. The global variables


    On a lot of systems at least some of them are stored in registers and
    never written to if the compiler can avoid it.

    <snip>

    > The qualifiers (e.g. const, volatile) do not affect the storage, but they
    > do have an impact on the access to those variables.


    Incorrect. On a lot of systems const will cause "variables" to be stored
    in some form of read-only memory, either actual ROM or a page that the
    OS will mark as read only when it loads the program.

    > It is difficult to tell more without knowing your system and your intentions.
    > It is not polite to ask if you really need the information you have asked for,
    > but it is difficult to resist.


    Any questions about the specifics of how/where an implementation stores
    variables belong on a group dedicated to that implementation rather than
    here.
    --
    Flash Gordon
    Flash Gordon, May 26, 2008
    #4
  5. kumar

    Flash Gordon Guest

    Malcolm McLean wrote, On 26/05/08 12:30:

    <snip>

    Ignoring the lack of requirement for a stack or heap the following is
    just plain WRONG

    > volatile variables can be modified outside the C program. So all these
    > optimisations have to be turned off. A volatile variable will always be
    > kept in the same place in memory so the outside routine - usually an
    > interrupt - can find it to modify it.


    If it is a local non-static volatile variable (i.e. an automatic
    volatile object) then there is absolutely NO requirement that it is kept
    in the same place in memory, and in general it will be created where
    ever happens to be convenient when the scope is entered. If the scope is
    a function that is called recursively it is almost impossible for the
    variable to be always created at the same location!
    --
    Flash Gordon
    Flash Gordon, May 26, 2008
    #5
  6. kumar

    kumar Guest

    On May 26, 4:30 pm, "Malcolm McLean" <> wrote:
    > "kumar" <> wrote in message news:
    > > hi
    > > i want to know where & how the C variables gets stored
    > > i mean like volatile , pointer and string variables gets stored ,
    > > whether it is on stack or some other places
    > > if is there any clear document , plz suggest the link

    >
    > In C you have a stack and a heap. When you call a function, local variables
    > are pushed on the stack. The return address might also be pushed on the
    > stack, or there might be a special stack for it.
    > When you call malloc() you take a chunk for memory from the heap. This
    > doesn't get reused automatically, and persists until you explicitly call
    > free().
    >
    > pointers are just ordinary variables. There's no special storage space for
    > them.
    >
    > Global variables go into a special area of memory created at program
    > startup. They persist for the entire life of the program. Local variables
    > with "static" are really global variables in disguise. They also persist the
    > entire life of the program, and are stored in the same place as the globals.
    >
    > However be aware that optimisers can produce any code whatsoever, as long as
    > it has the same effect as the code you would "naturally" expect from a
    > translation of C into assembly. So variables might be kept in registers, or
    > optimised away entirely, or funny things might be done to make cache usage
    > more efficient.
    >
    > volatile variables can be modified outside the C program. So all these
    > optimisations have to be turned off. A volatile variable will always be kept
    > in the same place in memory so the outside routine - usually an interrupt -
    > can find it to modify it.
    >
    > --
    > Free games and programming goodies.http://www.personal.leeds.ac.uk/~bgy1m



    i am practicing the system programming , that's why i am concerned
    about variables storage
    and now i got about it
    kumar, May 26, 2008
    #6
  7. On Mon, 26 May 2008 07:28:06 -0700 (PDT), kumar <>
    wrote:

    >i am practicing the system programming , that's why i am concerned
    >about variables storage
    >and now i got about it


    But there is no requirement for Compiler 1 to use the same approach to
    storing variables as Compiler 2. The same is true for different
    versions of Compiler 1. The answer to your original question remains
    implementation specific.


    Remove del for email
    Barry Schwarz, May 26, 2008
    #7
  8. Flash Gordon <> writes:
    > Szabolcs Borsanyi wrote, On 26/05/08 10:18:

    [...]
    >> The qualifiers (e.g. const, volatile) do not affect the storage, but they
    >> do have an impact on the access to those variables.

    >
    > Incorrect. On a lot of systems const will cause "variables" to be
    > stored in some form of read-only memory, either actual ROM or a page
    > that the OS will mark as read only when it loads the program.

    [...]

    That can happen only if the initial value can be determined at
    compilation time.

    For example, this is a valid declaration (if it appears within a
    function, and assuming the required headers have been #included):

    const time_t now = time(NULL);

    For that matter, if an object's initial value can be determined at
    compilation time and the compiler can determine that it's never
    modified, the compiler is free to store it in ROM even if it's not
    declared const (though in that case it *should* have been declared
    const).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 26, 2008
    #8
  9. "Malcolm McLean" <> writes:
    [...]
    > In C you have a stack and a heap.

    [...]

    Wrong, and I'm sure you know better.

    In most C *implementations* you have a stack and a heap. The C
    language itself (i.e., the standard) doesn't refer to either. It
    states how certain objects are required to behave; the structures
    known as a "stack" and as a "heap" are usually, but by no means
    always, the most convenient way to meet those requirements.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 26, 2008
    #9
  10. kumar

    Ian Collins Guest

    Keith Thompson wrote:
    >
    > For that matter, if an object's initial value can be determined at
    > compilation time and the compiler can determine that it's never
    > modified, the compiler is free to store it in ROM even if it's not
    > declared const (though in that case it *should* have been declared
    > const).
    >

    String literals being one example.

    --
    Ian Collins.
    Ian Collins, May 26, 2008
    #10
  11. On Mon, May 26, 2008 at 11:23:02AM +0100, Flash Gordon wrote:
    > Szabolcs Borsanyi wrote, On 26/05/08 10:18:
    >>
    >> The concept of stack is not part of the language, but variables with
    >> automatic storage (local variables without the static keyword) are
    >> stored by most systems on some sort of stack. The global variables

    >
    > On a lot of systems at least some of them are stored in registers and
    > never written to if the compiler can avoid it.
    >


    Thanks, you are right, indeed. Optimising compilers use registers extensively,
    unless the address of the variable is asked for. (Or could they use registers
    even then?...)

    > <snip>
    >
    >> The qualifiers (e.g. const, volatile) do not affect the storage, but they
    >> do have an impact on the access to those variables.

    >
    > Incorrect. On a lot of systems const will cause "variables" to be stored
    > in some form of read-only memory, either actual ROM or a page that the
    > OS will mark as read only when it loads the program.


    Thank you for correcting me.
    I wonder if the volatile qualifier could have an impact on the way of storage...

    Szabolcs
    Szabolcs Borsanyi, May 26, 2008
    #11
  12. "Malcolm McLean" <> writes:
    > "Jack Klein" <> wrote in message
    >> There are, of course, several platforms where this is just plain
    >> completely incorrect.
    >>

    > The OP wants an explanation of how C's memory is laid out, not a
    > formal definition of the memory model.


    And you gave him an explanation of how *some* C implementations do it.

    It's important to understand the distinction between the language and
    an implementation of the language. Please don't blur that
    distinction.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, May 26, 2008
    #12
  13. kumar

    Flash Gordon Guest

    Szabolcs Borsanyi wrote, On 26/05/08 20:34:
    > On Mon, May 26, 2008 at 11:23:02AM +0100, Flash Gordon wrote:
    >> Szabolcs Borsanyi wrote, On 26/05/08 10:18:
    >>> The concept of stack is not part of the language, but variables with
    >>> automatic storage (local variables without the static keyword) are
    >>> stored by most systems on some sort of stack. The global variables

    >> On a lot of systems at least some of them are stored in registers and
    >> never written to if the compiler can avoid it.

    >
    > Thanks, you are right, indeed. Optimising compilers use registers extensively,
    > unless the address of the variable is asked for. (Or could they use registers
    > even then?...)


    If it is not declared volatile the compiler may be able to keep it in a
    register for long stretches of code, an easy example being any stretch
    of code where no pointers are used.

    >>> The qualifiers (e.g. const, volatile) do not affect the storage, but they
    >>> do have an impact on the access to those variables.

    >> Incorrect. On a lot of systems const will cause "variables" to be stored
    >> in some form of read-only memory, either actual ROM or a page that the
    >> OS will mark as read only when it loads the program.

    >
    > Thank you for correcting me.
    > I wonder if the volatile qualifier could have an impact on the way of storage...


    That's easy. If the variable is declared volatile const rather than just
    const is may well *not* me placed in read-only memory :)
    --
    Flash Gordon
    Flash Gordon, May 26, 2008
    #13
  14. kumar

    Flash Gordon Guest

    Keith Thompson wrote, On 26/05/08 19:21:
    > Flash Gordon <> writes:
    >> Szabolcs Borsanyi wrote, On 26/05/08 10:18:

    > [...]
    >>> The qualifiers (e.g. const, volatile) do not affect the storage, but they
    >>> do have an impact on the access to those variables.

    >> Incorrect. On a lot of systems const will cause "variables" to be
    >> stored in some form of read-only memory, either actual ROM or a page
    >> that the OS will mark as read only when it loads the program.

    > [...]
    >
    > That can happen only if the initial value can be determined at
    > compilation time.


    True.

    > For that matter, if an object's initial value can be determined at
    > compilation time and the compiler can determine that it's never
    > modified, the compiler is free to store it in ROM even if it's not
    > declared const (though in that case it *should* have been declared
    > const).


    True, but rather harder for the implementation to prove where there are
    multiple compilation units. I know for definite of one compiler for
    embedded systems which puts all const qualified variable with static
    storage duration in a seperate memory section specifically so that you
    can allocate it to ROM but it does not put non-const qualified variables
    in that section even if they are never modified. I suspect (without
    proof) that this is probably quite common.
    --
    Flash Gordon
    Flash Gordon, May 26, 2008
    #14
  15. kumar

    Chris Torek Guest

    >On Mon, May 26, 2008 at 11:23:02AM +0100, Flash Gordon wrote:
    >>On a lot of systems at least some [local variables] are stored
    >>in registers and never written to if the compiler can avoid it.


    In article <>
    Szabolcs Borsanyi <> wrote:
    >Thanks, you are right, indeed. Optimising compilers use registers
    >extensively, unless the address of the variable is asked for. (Or
    >could they use registers even then?...)


    They could, although exactly how depends on both the compiler and
    the target architecture. Consider, e.g., the following C code
    fragment:

    for (i = 0; i < n; i++)
    do_something(i);
    maybe_alter(&i);
    if (i != n)
    do_something_else();
    for (i = 0; i < n; i++)
    do_third_thing(i);

    Here, "i" is a likely candidate for "register-ization" to make
    the two loops run faster. In between the two loops, however, we
    pass &i to a function that might change it.

    A reasonably clever compiler could easily rewrite this as:

    for (i1 = 0; i1 < n; i1++)
    do_something(i1);
    i2 = i1;
    maybe_alter(&i2);
    if (i2 != n)
    do_something_else();
    for (i3 = 0; i3 < n; i3++)
    do_third_thing(i3);
    i2 = i3; /* if needed -- actually "i4" (if i is used below) */

    It is now clear that i1 and i3 can be stored in a machine register
    (the same machine register, in fact) even if i2 must live in RAM.

    If the CPU has the ability to take the address of a register --
    this is rare these days but was not uncommon once, and could perhaps
    become popular again someday -- one need not even rewrite the
    variable names to make this optimization possible.

    >I wonder if the volatile qualifier could have an impact on the
    >way of storage...


    Yes, it often does. (In fact, cases where it fails to prevent
    "registerization" tend to be compiler bugs. These bugs do happen
    though.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: gmail (figure it out) http://web.torek.net/torek/index.html
    Chris Torek, May 26, 2008
    #15
    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. PKJ
    Replies:
    1
    Views:
    385
    Victor Bazarov
    Oct 22, 2004
  2. Replies:
    2
    Views:
    439
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Oct 3, 2006
  3. Replies:
    1
    Views:
    483
    Andreas Wollschlaeger
    Oct 6, 2006
  4. Chris Thomasson

    Some quick c++ memory-model concerns...

    Chris Thomasson, Sep 3, 2006, in forum: C++
    Replies:
    0
    Views:
    377
    Chris Thomasson
    Sep 3, 2006
  5. Replies:
    0
    Views:
    347
Loading...

Share This Page