Once the code passes the syntax check, and gets optimized, it's passed to the assembly stage. The assembly stage reads the tokens and produces the assembly code. This assembly code is implementation specific. Different compilers will do different things. And will make different assembly code for their targeted devices. This may seem redundant, but it's an important stage for how things get linked, and other things. I'm not talking about it because it gets complex. REAL COMPLEX. I barely understand it.

+1 on your overview. i took formal languages and systems programming at OSU. a good concise summary.

when it comes to code generation, a number of compilers now emit language independent p-code for use by the linker. i believe MS has gone this route with their PC language tools.

on the PC, the linker hooks up the method calls to the called code, and creates a relocatable exe file. this will typically contain two types of code, address dependent machine code, and address independent machine code. on execution, the relocating loader loads the exe into ram at some address (the OS tells it where to put it), and performs address fixup on the address dependent code, then the IP and such are set (most likely by the OS), and control passes to the app.

Yeah. and if I remember correctly, and I could most likely be wrong, part of the reason is that it's unknown where in memory everything will exist

Originally, it was primarily to support dynamic linking. If you load a set of libraries at runtime, those aren't necessarily always going to be loaded at the same offset, depending on the order you load them.

part of the reason is that it's unknown where in memory everything will exist.

that _is_ the reason. it has to be able to load anywhere, so it can co-exist in ram with other apps. wouldn't work too well if all apps expected to be loaded at some specific address. what if you tried to run two of them at once?

( I believe anyways I'm fuzzy on this).

nope, you got it all right.

With DLLs, they were designed to be shared between apps, intstead of statically linking the same lib to three different apps that happen to be in ram at once. . so when your app loads, your DLL may already be in use by another app - and loaded at some aribrary address. i think a large part had to do with the large static libs MS used in their apps, and in windows, and windows apps. usually its only the most common DLLs that actually get shared. and custom app specific DLLs almost never do.

that _is_ the reason. it has to be able to load anywhere, so it can co-exist in ram with other apps. wouldn't work too well if all apps expected to be loaded at some specific address. what if you tried to run two of them at once?

Replace "apps" with "dynamic libraries" and it'll be correct. Each application already has its own address space all for itself, and maps segments of dynamically loaded libraries into its address space.