Re: Symbol Table, global, local, dynamic allocation, code generation

Hello!


Mitch Mooney <mr.mhmooney@verizon.net> wrote:


>I'm researching how to handle variables, global, local, and dynamic.


>With Global variables I figure I can load the symbol table with scope,
>name, value and generate x86 asm code in the .data segment. Is this
>the basic setup?


Right. Or if you're ok with zero-initialization, you can allocate
space in the .bss segment. In both cases you refer to the symbolic
address in code dealing with the variables which is usually resolved
by the assembler or linker.


>With Local variables I figure I can load the symbol table with scope,
>name, value and OFFSET to generate x86 asm code on the stack, using
>the offset in the symbol table to allow me to access the position in
>the stack. Is this a proper way to do this or just a hack?


Often you just use the frame pointer (in usual x86 conventions
usually in %ebp). The stack frame usually looks like this directly
after the call: (%esp) is the return address, 4(%esp) is the
first argument (in typical C calling conventions!), etc. The typical
function/procedure prologue looks like this:


pushl %ebp
mov %esp, %ebp
; perhaps save callee-saves registers now
subl $xx, %esp ; make space for the local variables


You then address the local variables with negative offsets from %ebp.


If you always know what the difference between the frame base (%ebp)
and the stack pointer (%esp) will be in each code point which addresses
parameters or local variables, you can transform the accesses into
ones using %esp, and get rid of the %ebp handling, which is sometimes
done by gcc's option -fomit-frame-pointer, for example.


>With Dynamic variables I assume its handled like a local
>variables. Anyone with some insight?


In languages like C++ or Java, dynamic variables are in fact a
"pair" of an anonymous memory block, holding the actual data,
allocated on the heap (the compiler generates a function call for
allocation, and if not GC'ed for deallocation too, sometimes those
calls or parts of them might be inlined, many GC'ed language
implementations do that for the fast path [enough space in the
nursery] of allocation), and a local variable which is a pointer/reference
to the memory block. The local variable is handled as any scalar
local variable then.


Of course there can be differences. If a language allows the local
declaration of huge arrays, perhaps with a size only known at run-time
when the procedure is entered, implementations might actually generate
code allocating the data area on a heap and implementing only the
reference to that area (or an array descriptor) as stack-allocated
local variable.


So the above words are only the basic general gist of things.


>I'm waiting on some books, till they arrive I'm relying on information that
>can be found on the net and newsgroups. Any links, or books that can be
>recommended?


Dunno any good links. You could of course have a look at the FAQ
of this newsgroup, which lists a few books and links, available
via http://compilers.iecc.com/


>-Mitch


Hope that helps.


Kind regards,


Hannah.

Return to the comp.compilers page.
Search the comp.compilers archives again.