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?
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.
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?
compiler and OS specific, I think
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
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"
Perfect. That's exactly what I was looking for. Thanks for the help!Originally Posted by cbastard
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.
The answer to that would fill a bookshelf.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?
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.
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.
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.
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 02:48 PM.
is it release or debug build?
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
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.
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.
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.
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.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.
