Compiler:  when you type gcc, what happens?

A compiler, at its most basic, translates one language to another.

A C compiler generally translates from C to assembler, and the assembler gets translated to object code, which is kind of like machine language but not completely.  The object code describes how memory should be moved around and what operations are done on the memory and on the register and so forth, but object may very well make reference to methods and data that don't actually exist.

For example, if you're writing code and C and you use the printf method, that printf method doesn't exist in your code, so the object code makes reference to a location in memory called printf...but it's not present in the object code.

When you call a method, what you are actually doing is saving your return location in memory, and then jumping to the beginning of that method.

So, what happens after you compile is that your code goes through the "linking" phase.  Your object code is linked with other object code.  Most major programs have several pieces of C code that are compiled separately and then linked together.

In the linking phase, objects are linked together with libraries.  What a library is is a collection of objects that have already been linked together to form a single unit, but it's still not an executable.

In the end, you have an executable built from objects you made, libraries you made, and system libraries that were there before you got started.  (That's where printf is.)  The executable now is ready to go and all the methods are loaded, and what object file they were originally a part of is no longer relevant.

Now, you also have dynamically linked libraries.  DLL's are linked to your program at compile time.  The methods and data stored in the DLL's are loaded from these files at runtime.  If your program requires a method from a DLL, then the DLL is opened when you need that method and that method is read in.

On a physical computer, you have essentially one chunk of memory, and you have a bunch of processes wanting to use that memory.

And so, memory is apportioned out to the processes that are running, usually contiguously.  So one process might the section of memory from A to B-1, another processor might have have the section of memory from B to C-1, and so forth.

When you write a program, you might to have a line like c = d+e.  But what is c?  What are d and e?  Where can I find them?  If variables are global variables, there are specific locations for them.  c might be located at 0x4398d7.  If they are local variables, they exist on the stack somewhere, so the if d located 0x8 bytes from the top of the stack, then some arithmetic will have to be done, to add 0x8 to the stack pointer to find out where d is located.  At compile time, you don't know c's value but you do know where is located (in global memory).  You don't know d's value and you don't know d's location (local variable on the stack) so at runtime, you have to a little math even to find d before you look up the value stored within d.

Either way, that's STILL not the right answer.  The reason that's not the right answer is that there are multiple processes all using this big hunk of memory.  So, your variable c may be located at 0x4398d7, but that's not the true location in physical memory, you don't know where it is in physical memory; it might in a different place, each time you run the program.  So, the 0x4398d7 is sometimes called the "logical address".  That's the address of memory RELATIVE to the beginning of the hunk of memory this process occupies.

So, if your process has been assigned the memory from A to B-1, your variable c is loated at 0x4398d7 + A.  And so, the OS is computing all of this while you run your program.