memory frames in programs

This is a discussion on memory frames in programs within the C Programming forums, part of the General Programming Boards category; How many different memory frames are there to a program when it is executed and what are they? I'm well ...

  1. #1
    Registered User
    Join Date
    Jan 2008
    Posts
    69

    memory frames in programs

    How many different memory frames are there to a program when it is executed and what are they? I'm well aware of the stack and heap, but I've often heard of internal string tables and internal registries, among other things. How and where are constants stored? I've searched high and low on Google, but I'm not finding anything relevant to what I'm looking for. Can any of the experts on here provide some insight?

  2. #2
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Do you mean a processors internal registers?

    "internal string tables" returns 5 entries on google so it is fair to say it is not specifically recognised term in any capacity. It could mean a table inside a building with some pieces
    of string on it for example. It is a non recognised term.

  3. #3
    Registered User
    Join Date
    Jan 2008
    Posts
    69
    I guess my question wasn't clear. I'm having trouble trying to figure out how to phrase the question. Let me try to simplify and then we can build from there.

    When you have a constant in your program, whether it's explicitly defined via the #define directive or as a string somewhere in your program, how does the compiler handle those? Are they stored on the stack or somewhere else?

    When you compile a program and its size is determined to be x bytes, what is used to determine the file size when it's compiled and how is it structured internally?

  4. #4
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    compiler and OS specific, I think
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  5. #5
    Registered User cbastard's Avatar
    Join Date
    Jul 2005
    Location
    India
    Posts
    167
    Long time no C. I need to learn the language again.
    Help a man when he is in trouble and he will remember you when he is in trouble again.
    You learn in life when you lose.
    Complex problems have simple, easy to understand wrong answers.
    "A ship in the harbour is safe, but that's not what ships are built
    for"

  6. #6
    Registered User
    Join Date
    Jan 2008
    Posts
    69
    Perfect. That's exactly what I was looking for. Thanks for the help!

  7. #7
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by cs32 View Post
    When you have a constant in your program, whether it's explicitly defined via the #define directive or as a string somewhere in your program, how does the compiler handle those? Are they stored on the stack or somewhere else?
    That completely depends on the compiler and operating system. True constants typically exist as immediate values in the program code itself, meaning they have no specific location at all. Actual global variables are typically organized into a single region called "data." The stack is usually only used during program execution for function call frames, so nothing should ever get placed there, except automatic variables during execution.

    When you compile a program and its size is determined to be x bytes, what is used to determine the file size when it's compiled and how is it structured internally?
    The answer to that would fill a bookshelf.

  8. #8
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    Quote Originally Posted by cs32 View Post
    How many different memory frames are there to a program when it is executed and what are they? I'm well aware of the stack and heap, but I've often heard of internal string tables and internal registries, among other things. How and where are constants stored? I've searched high and low on Google, but I'm not finding anything relevant to what I'm looking for. Can any of the experts on here provide some insight?
    A "string table" (194000 google hits) is the place in the program's "load image" (2920000 gits)
    where so-called "string literals" (169000 gits) are stored.

    An executable file is actually a data file for the operating system, and is thus both
    OS as well as CPU specific. However, it must contain a few things. Obviously, it must
    have an image of the code. It must also have an "initialized data section" to keep
    all of the pre-initialized, but potentially modifiable data. It also has a string table
    containing all of the string literals your program uses. These are usually not modifiable.

    These data are just reams of binary numbers that are
    slapped into place during loading of the program
    before execution. In the code section, references to string
    literals become addresses pointing into the loaded string table.

    Constants, optimally, become part of the code section of the program, so they
    disappear as data, although you could say that they are data kept in the code section.

    "Heap" usually refers to where dynamic memory is allocated (e.g., malloc()).

    "Stack" is where the so-called "automatic" variables go (those defined in a function and
    not static). A stack is used because it's okay if they come and go, and specifically to
    enable "recursion".

    To ask where in RAM all of this is placed is a entirely different question, all about
    operating systems and how they hand out (and swap around) memory.

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    The linked PDF has several strange things in it. The very first sentence doesn't make ANY sense to me. I

    It has got a picture that shows how the different sections may be arranged. But bear in mind that for example in Linux the stack is at a higher address than the heap [and the stack is at the "highest available address"], rather than at a lower address as depicted in the linked PDF, and there is absolutely nothing saying that the data section can't be before the code section for example [not that I have seen such a setup other than in systems where the code is in ROM at a higher address].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by matsp View Post
    The linked PDF has several strange things in it. The very first sentence doesn't make ANY sense to me. I

    It has got a picture that shows how the different sections may be arranged. But bear in mind that for example in Linux the stack is at a higher address than the heap [and the stack is at the "highest available address"], rather than at a lower address as depicted in the linked PDF, and there is absolutely nothing saying that the data section can't be before the code section for example [not that I have seen such a setup other than in systems where the code is in ROM at a higher address].

    --
    Mats
    The first sentence reads better if you read it as a title.
    It looks like lecture notes.
    There are np hard rules about how a computer has to work.
    People work on one system and assume all others are the same, then even start
    teaching it like it is gospel.

  11. #11
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    Quote Originally Posted by matsp View Post
    The linked PDF has several strange things in it. The very first sentence doesn't make ANY sense to me.
    It has got a picture that shows how the different sections may be arranged. But bear in mind that for example in Linux the stack is at a higher address than the heap [and the stack is at the "highest available address"], rather than at a lower address as depicted in the linked PDF, and there is absolutely nothing saying that the data section can't be before the code section for example [not that I have seen such a setup other than in systems where the code is in ROM at a higher address].
    The sentence "this is how a process is placed into its virtual address space"
    could perhaps mean "this is the placement of the different elements that make up
    a process (a running program in memory), built from the information in the executable
    file, such as how much stack space and static data space to reserve, the actual code
    and initialized data, etc."

    The term "virtual address space" means that your program "thinks" its in a big address
    space (along with shared components, like dll's), instead of the real RAM address space.
    The OS/CPU map virtual to real addresses, even swapping pieces of code/data in and
    out, generally back to different real addresses but always mapped to the same virtual
    address.

    The only reason I can think of for having the code at the bottom is to
    ensure that 0 is not a valid data address. Also, since the code doesn't
    grow, it should be right up against the bottom or top of the available virtual address space.
    Since both the data and stack segments also do not grow, they should be placed
    either up against the code or up against the top of memory.
    The heap then simply starts at the top or bottom of what's left.
    The stack or heap can both grow either way.

    The following code on my PC/XP produces confusing results.
    It looks like dynamics and locals are below the code!
    Look at the distance between the two globals (16 bytes for 4-byte values).
    Look at the distance between the dynamics!
    What are the results for your Linux machine?
    Code:
    /* Output on PC/XP
     * global1  global2  local1   local2   dynamic1 dynamic2 function
     * 00403030 00403020 0022ff8c 0022ff88 003d3dd8 003d3e38 00401334
     */
    #define mint() ((int*) malloc( sizeof( int )))
    int global1;
    int global2;
    int main() {
        int local1;
        int local2;
        int *dynamic1 = mint();
        int *dynamic2 = mint();
        printf( "global1  global2  local1   local2   dynamic1 dynamic2 function\n" );
        printf( "%08x %08x %08x %08x %08x %08x %08x\n",
                &global1, &global2, &local1, &local2, dynamic1, dynamic2, main );
    }
    Last edited by oogabooga; 01-09-2008 at 01:48 PM.

  12. #12
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    is it release or debug build?
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  13. #13
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by vart View Post
    is it release or debug build?
    What difference would that make? Aside from possibly that the memory allocations are done slightly more compact in release because the debug version stores some extra info to track for example where the allocation was made, or sticking some extra blocks of "crumble-zone" at either end of the allocation to identify simple over-run problems.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #14
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    Crumble zone! Never heard of that one.
    Is it an identifiable pattern (like disk sync-bytes)
    or just some extra space (but why?).

    As far as release or build, embarassingly, I'm not quite sure.
    I'm using a PC with WinXP and msys, minGW. I complied
    simply as "gcc whatever.c" and ran the resulting a.exe.
    I'm currently digging through the documentation (which I have
    been meaning to do) to see what's what.

  15. #15
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by oogabooga View Post
    Crumble zone! Never heard of that one.
    Is it an identifiable pattern (like disk sync-bytes)
    or just some extra space (but why?).
    Crumble zone, guard band, whatever you want to call it. Typically it is set to some repetitive pattern like 0x55AA55AA. Certainly not just zeros, because overruns typically write zeros and that would make them invisible.

    As far as release or build, embarassingly, I'm not quite sure.
    I'm using a PC with WinXP and msys, minGW. I complied
    simply as "gcc whatever.c" and ran the resulting a.exe.
    Then it is not a "debug" build. But it doesn't really matter. The extra data in a debug build is only used by the debugger, not the program itself.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 02-06-2009, 11:27 AM
  2. Newbie question: pointers, other program's memory
    By xxxxme in forum C++ Programming
    Replies: 23
    Last Post: 11-25-2006, 12:00 PM
  3. Memory allocation and deallocation
    By Micko in forum C++ Programming
    Replies: 3
    Last Post: 08-19-2005, 06:45 PM
  4. Accessing memory of other programs
    By Inquirer in forum C Programming
    Replies: 4
    Last Post: 10-07-2003, 03:43 PM
  5. Accessing Video Memory Information...need help
    By KneeLess in forum C++ Programming
    Replies: 8
    Last Post: 08-24-2003, 03:53 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21