SittingDuck

How do I deal with global variables, from the point of view of writing a compiler?

How do I know the address that the variable will be in?

DaWei

You don't. Different systems (and languages) have different conventions, but nowadays they're mostly all relative. It's part of the job of what you're writing to conform to any external requirements and make your own determinations where there aren't any to conform to. You have a fair bit of reading ahead of you. Mere compilation is only a part of the job, albeit not a trivial part.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Scorpions4ever

One way to do this is to allocate global variables to a separate section of memory (the DATA segment) and allocate one CPU register to point to the base of that section. All you need to know is the relative offsets of each global variable from the base .

lectricpharaoh

If you're writing a compiler, you need to know how your target platform formats its executable files. If you're aiming for a Win32 target, you'll want to look up specs on the PE (portable executable) format.

In addition to the actual code, your binary image will contain information about what segments/sections your program has, what type they are (code, data, readable, executable, etc), and other stuff (for example, Windows often has embedded 'resources', like icons and bitmaps).

For many modern platforms, you have three usual segments/sections: One for code (often called "TEXT" or something similar; it is a readable, executable segment), one for static data (often called "DATA"; it is readable and writable), and one for stack (often "BSS"; it is readable, writable, and it behaves as a stack, meaning it's addressed with the stack register, and it expands down, rather than up). Sometimes, you will have additional segments, but most often these are just more data segments.

Having said all that, what compilers usually emit is object code, not executable code. This means you have to determine which object file format is best suited to your needs, emit code in that format, and then feed it to a linker. This in turn necessitates that you choose an object file format that has a compatible linker available, given your target platform.

As you can gather, it's not a trivial task- and that's without actually generating the code!

Still, once you have all those issues ironed out, handling globals will be easy. You will maintain some kind of symbol table, with the names, types, and addresses of each reference. From the types, you can calculate the address of each item relative to some predefined starting point (ie, the beginning of the data segment), since the address of an item will be the address of the starting point (for the first item), and the address of the previous item plus the size of the previous item plus any padding for memory alignment (for subsequent items).

Local variables are likewise handled similarly, except the symbol table will be local in scope, and variables will be relative to the current stack position, rather than the global data segment.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick