The Procedure Abstraction Part III: Symbol Tables, Storage Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at Rice University have explicit permission to make copies of these materials for their personal use. §5.7 in EaC Lexically-scoped Symbol Tables The problem • The compiler needs a distinct record for each declaration • Nested lexical scopes admit duplicate declarations The interface • insert(name, level ) – creates record for name at level • lookup(name, level ) – returns pointer or index • delete(level ) – removes all names declared at level Many implementation schemes have been proposed (see § B.4) • We’ll stay at the conceptual level • Hash table implementation is tricky, detailed, & fun Symbol tables are compile-time structures the compiler use to resolve references to names. We’ll see the corresponding run-time structures that are used to establish addressability later. Example procedure p { B0: { int a, b, c int a, b, c procedure q { B1: { int v, b, x, w int v, b, x, w procedure r { B2: { int x, y, z int x, y, z …. …. } } procedure s { B3: { int x, a, v int x, a, v … … } } … r … s … } } … q … … } } Example procedure p { B0: { int a, b, c int a0, b1, c2 procedure q { B1: { int v, b, x, w int v3, b4, x5, w6 procedure r { B2: { int x, y, z int x7, y8, z9 …. …. } } procedure s { B3: { int x, a, v int x10, a11, v12 c … … } } b, w … r … s … a11, b4, c2, x, a, v } } … q … … v12, w6,, x10, } } no y or z Picturing it as a series of Using the rewrite rules from Algol-like procedures COMP 210 for lexical scopes Lexically-scoped Symbol Tables High-level idea • Create a new table for each scope • Chain them together for lookup “Sheaf of tables” implementation ... p • insert() may need to create table q a • it always inserts at current level s b • lookup() walks chain of tables & x returns first occurrence of name • v ... • delete() throws away table for level p, if it is top table in the chain b c a If the compiler must preserve the x table (for, say, the debugger ), this w idea is actually practical. v Individual tables can be hash tables. Lexically-scoped Symbol Tables High-level idea • Create a new table for each scope • Chain them together for lookup Remember p ... q a a11, b5, c2, s the names v , w , x , b 12 6 , 10 visible in s x no y or z • v ... If we add the subscripts from the a b c COMP 210 rewrite rules, the x relationship between the code and w the table becomes clear v Lexically-scoped Symbol Tables High-level idea a11, b4, c2, • Create a new table for each scope v12, w6,, x10, • Chain them together for lookup no y or z procedure p { p ... int a0, b1, c2 procedure q { q a0 s int v3, b4, x5, w6 procedure r { b1 x int x7, y8, z9 • 10 …. v3 ... } procedure s { a b c 11 4 2 int x10, a11, v12 x5 … w6 } … v } 12 … } Implementing Lexically Scoped Symbol Tables Stack organization Implementation • insert () creates new level growth pointer if needed and inserts at nextFree • lookup () searches linearly nextFree from nextFree–1 forward v a • delete () sets nextFree to s (level 2) x the equal the start location w of the level deleted. x Advantage b • Uses much less space q (level 1) v c Disadvantage b • Lookups can be expensive p (level 0) a Implementing Lexically Scoped Symbol Tables Stack organization a11, b4, c2, Implementation v12, w6,, x10, • insert () creates new level no y or z growth pointer if needed and inserts at nextFree • lookup () searches linearly nextFree from nextFree–1 backward v 12 a 11 • delete () sets nextFree to s (level 2) x 10 the equal the start location w 6 of the level deleted. x 5 Advantage b 4 • Uses much less space q (level 1) v 3 c 2 Disadvantage b 1 • Lookups can be expensive p (level 0) a 0 Implementing Lexically Scoped Symbol Tables Threaded stack organization Implementation • • insert () puts new entry at the growth head of the list for the name • • lookup () goes direct to location • delete () processes each element • v in level being deleted to remove a from head of list h(x) • x s Advantage w • lookup is fast • x b Disadvantage v q • delete takes time proportional to c number of declared variables in b level (though inserts+deletes are • a p still O(n)) Implementing Lexically Scoped Symbol Tables Threaded stack organization a , b , c , Implementation 11 4 2 • v12, w6,, x10, • insert () puts new entry at the no y or z growth head of the list for the name • • lookup () goes direct to location • delete () processes each element • v 12 in level being deleted to remove a 11 from head of list h(x) 10 • x s Advantage w 6 • lookup is fast • x 5 b 4 Disadvantage v 3 q • delete takes time proportional to c 2 number of declared variables in b 1 level (though inserts+deletes are • a 0 p still O(n)) The Procedure as an External Interface OS needs a way to start the program’s execution • Programmer needs a way to indicate where it begins The “main” procedure in most languaages • When user invokes “grep” at a command line UNIX/Linux specific discussion OS finds the executable OS creates a process and arranges for it to run “grep” “grep” is code from the compiler, linked with run-time system Starts the run-time environment & calls “main” After main, it shuts down run-time environment & returns • When “grep” needs system services It makes a system call, such as fopen() Where Do All These Variables Go? Automatic & Local • Keep them in the procedure activation record or in a register • Automatic lifetime matches procedure’s lifetime Static • Procedure scope storage area affixed with procedure name &_p.x • File scope storage area affixed with file name • Lifetime is entire execution Global • One or more named global data areas • One per variable, or per file, or per program, … • Lifetime is entire execution Placing Run-time Data Structures Classic Organization • Better utilization if stack & heap grow S G S C t l H toward each other t o a & o e a • Very old result (Knuth) d t b a c e i a p • Code & data separate or k c l interleaved 0 high • Uses address space, Single Logical Address Space not allocated memory • Code, static, & global data have known size Use symbolic labels in the code • Heap & stack both grow & shrink over time • This is a virtual address space How Does This Really Work? The Big Picture virtual address Compiler’s view spaces S G S G S G S G S S S S C t l H C t l H C t l H C t l H t t t t o a & o e o a & o e o a & o e o a & o e a a a a d t b a d t b a d t b a ... d t b a c c c c e i a p e i a p e i a p e i a p k k k k c l c l c l c l OS’s view ... 0 high Hardware’s view Physical address space_ Where Do Local Variables Live? A Simplistic model • Allocate a data area for each distinct scope • One data area per “sheaf” in scoped table What about recursion? • Need a data area per invocation (or activation) of a scope • We call this the scope’s activation record • The compiler can also store control information there ! More complex scheme • One activation record (AR) per procedure instance • All the procedure’s scopes share a single AR (may share space) • Static relationship between scopes in single procedure Used this way, “static” means knowable at compile time (and, therefore, fixed). Translating Local Names How does the compiler represent a specific instance of x ? • Name is translated into a static coordinate < level,offset > pair “level” is lexical nesting level of the procedure “offset” is unique within that scope • Subsequent code will use the static coordinate to generate addresses and references • “level” is a function of the table in which x is found Stored in the entry for each x • “offset” must be assigned and stored in the symbol table Assigned at compile time Known at compile time Used to generate code that executes at run-time Storage for Blocks within a Single Procedure B0: { • Fixed length data can always be at a int a, b, c B1: { constant offset from the beginning int v, b, x, w of a procedure B2: { In our example, the a declared at int x, y, z level 0 will always be the first data …. element, stored at byte 0 in the } fixed-length data area B3: { The x declared at level 1 will always int x, a, v be the sixth data item, stored at … byte 20 in the fixed data area } … The x declared at level 2 will always } be the eighth data item, stored at … byte 28 in the fixed data area } But what about the a declared in the second block at level 2? Variable-length Data B0: { Arrays int a, b If size is fixed at compile time, store in … assign value to a fixed-length data area B1: { If size is variable, store descriptor in int v(a), b, x B2: { fixed length area, with pointer to variable int x, y(8) length area ….