Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Sir_Spritely

Understanding what happens under the hood

This topic is 5369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am trying to understand completely what actually occurs from loading a C++ aplication into Visual C++. To compiling the program to running the program. I know this is huge and very very ranged. I have a lot of it down just not sure about some of what happens. For example, when I load in the program, are all the program elements assigned memory locations at this point? Once I compile the program are all elements assigned memory addresses then? Or are all elements assigned memory locations once I click RUN from the menu? If anyone knows any really decent resources on this I would appreciate the URL. Or if you want to have a go at explaining it, I would appreciate that also.

Share this post


Link to post
Share on other sites
Advertisement
I don''t know what you mean by "elements", but here''s a simplified description.

When you load your program''s source into VC++, your program does not yet exist in a computer-understandable form. It''s just a bunch of text, nothing more.

When you press the compile button, the compiler goes over all the text and then converts it into assembly code, which is still just text, but in a very primitive form that can be easily translated into machine code. Finally, an assembler converts the assembly code into a bunch of numbers that the CPU can interpret, and those are stored in an EXE file.

When you press Run, the EXE file is loaded into memory, and your CPU starts executing the instructions it contains.

Share this post


Link to post
Share on other sites
What I am trying to understand is, when a program is loaded into something like MS Vis Studio 6 for example. The program is stored in memory. Now does each element of the program (by element I mean variable, function etc) get assigned a memory address at this stage, or is the program just one big ball in a memory address?

Does each element get split into individual addresses at compile time then or is it at run-time?

In a nutshell I am trying to understand what happens in regard to memory locations at the point when the program is loaded into MS Vis Studio 6, the point following the program being compiled and the point once Run has been selected.

Help appreciated.

Share this post


Link to post
Share on other sites
Unfortunately theres so much stuff that happens that it takes you two semester long courses at a uni to understand it (actually probably two more if you want to really really understand it). If you really want to know, buy a book on compilers such as the Dragon book.....

Share this post


Link to post
Share on other sites
What you load in VS is not a program, it''s only the source code, the concept memory location doesn''t apply here. In the output of the compiler there will still be symbols instead of memory addresses, a global variable a will still show up as "a" in the .obj file the compiler generates. The compiler will convert local variables to stack locations or registers, these are not absolute memory locations. The .objs generated by the compiler will be combined by the linker, the linker will decide in what location to place the variables. These locations will show up like that in the machine code.
When the program is loaded, the machine code is copied varbatim to the "code segment", the addresses of global variables will refer to space in the separate "data segment", the addresses are relative to the start of the segment. The Operating System decides where the segments get placed in the physical or virtual memory.

Share this post


Link to post
Share on other sites
Okay, I''m getting the loading part. So when I choose Load and the program name in MS Vis Studio, none of the variables or functions are assigned memory locations. This is because all that is loaded is in effect as ascii file.

When I choose Compile, the ascii text is converted to machine code or assembly language which the processor understands.

Then when I choose Run, the processor executes the machine code instructions.

Objects created on the stack or in static storage are allocated memory locations at compile-time.

Objects created on the heap are allocated memory storage at run-time.

Am I on the right track here? Thanks for the help so far

Share this post


Link to post
Share on other sites
quote:
Original post by Sir_Spritely
Objects created on the stack or in static storage are allocated memory locations at compile-time.


Not exactly. I suppose you could sort of say that things in static storage are allocated at compile time, in a way. But objects on the stack are, naturally, created on the stack, at runtime.

Share this post


Link to post
Share on other sites
I think I am getting confused with the actual meaning of compile-time and run-time.

I have compile-time as when I press compile from the menu. Which is when the ascii is converted into machine code. So when I create elements on the stack I must know the quantity, lifetime and type. Otherwise what? What happens and can someone put in an example code and explanation?

By Run-Time I presume once I have pressed Run on the menu and the first line of machine code has been executed by the processor, is this correct? In which case elements created on the heap at/during run-time are created dynamically. So the compiler knows nothing about these elements? No memory is allocated by the compiler at compile-time because they don't exists yet?

So elements on the stack in which the compiler knows about them such as the quantity, lifetime and size etc, memory locations are assigned at compile time? Or are memory locations for objects created on the stack still assigned at run-time? In which case dynamic objects created on the heap can only be assigned memory locations at run-time. So there is literally no difference then between dynamic object creation and normal object creation because both are created and assigned memory locations at run-time right?

Any more help on this is really appreciated.

[edited by - Sir_Spritely on March 7, 2004 10:00:39 AM]

Share this post


Link to post
Share on other sites
Compile time is when the compiler transforms source code files into object files. Link time is when object files are linked together into an executable file. Most of the time these happen one after the other and thus both fall under compile time.

Run time is when the program runs, regardless of whether it's launched from within an IDE (eg. Visual C++), a shortcut, windows explorer, the start run menu, a command prompt or what have you. Run time is when the program is running, doing whatever it's programmed to do.

A compiler doesn't allocate memory - at least it's not helpful to think of it that way, imo. A compiler supplies instructions, some of those instructions allocate memory when executed.

quote:

So elements on the stack in which the compiler knows about them such as the quantity, lifetime and size etc, memory locations are assigned at compile time? Or are memory locations for objects created on the stack still assigned at run-time? In which case dynamic objects created on the heap can only be assigned memory locations at run-time. So there is literally no difference then between dynamic object creation and normal object creation because both are created and assigned memory locations at run-time right?



The operating system sets up the stack as a reserved section of virtual memory in the address space of the process. Every thread has it's own stack. The default stack size on windows is 1 Mb. Before the thread begins execution, two pages of the reserved stack memory are committed. The compiler deals with instructions for manipulating the stack but not with assigning memory at run time. An object created on the heap belongs to the process. An object created on the stack, belongs to the thread that owns that stack. As a thread executes it pushes values on to the stack and pops them off when they are no longer needed in order to keep the stack properly balanced. This is important because it allows functions to return where you coded them too. The arguments to a function are pushed on to the stack, then the function is called. The call instruction also pushes the return address of the function on the stack. Then space is made on the stack to accomodate local variables. The word "made" suggests allocation, but that's not the case, it's just a limitation of speech. What happens is that the pointer to the top of the stack is adjusted to allow for using these stack entries. A stack is really an array of 262144 DWORDS with a pointer that indexes where the latest value is stored. For ints and other basic data types placed on the stack, no explicit clean up code is needed. The compiler supplies the instructions that move the stack pointer back to where it was before the function was called, thereby cleaning up those local variables. The next function call will overwrite the location where they used to be, like they never were there. If a local variable is used to hold a pointer to dynamically allocated memory - an object, a chunk or what have you - that memory has to be freed before exiting the function because otherwise that pointer gets lost - it gets overwritten with something else - and thus the memory that it points to can no longer be freed. In C++ the compiler often supplies the code to call an object's deconstructor before the function returns, but there are a variety of particulars that you should study for yourself.



[edited by - lessbread on March 9, 2004 3:58:17 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!