1 / 53

Topic 3 -Binding Time and Symbol Tables

Topic 3 -Binding Time and Symbol Tables. Dr. William A. Maniatty Assistant Prof. Dept. of Computer Science University At Albany CSI 511 Programming Languages and Systems Concepts Fall 2002 Monday Wednesday 2:30-3:50 LI 99. Introduction to Binding.

sally
Download Presentation

Topic 3 -Binding Time and Symbol Tables

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Topic 3 -Binding Time andSymbol Tables Dr. William A. Maniatty Assistant Prof. Dept. of Computer Science University At Albany CSI 511 Programming Languages and Systems Concepts Fall 2002 Monday Wednesday 2:30-3:50 LI 99

  2. Introduction to Binding • Binding refers to associating an entity with a value, such as • Variable name with address0 • Result of expression with ephemeral storage • Constant with its value • Seperately compiled function with address

  3. Binding Time • Binding time refers to when entities are associated with their values is made.

  4. Design Binding Times • There are extra binding times available to programming language designers. • Language Design Time - Choose fundamental primitives, reserved words, etc. • Compiler/Interpreter Implementation Time -How to internally represent language constructs. • Programming Time - Language users pick the algorithms and data structures.

  5. Object - What does it mean? • The word Object has many meanings in program languages. • Object Module -A compiled (but not linked) module of a program. • Object (OOP sense) - An instance of a class in Object Oriented Programming. • Object (Programming Language Sense) -The entities which are bound to values. • Use the programming language for now.

  6. Binding Time Design Issues • Late binding of objects indicates that interpreters. • Dynamic Type Systems • Care needs to be taken to avoid ambiguity when binding. • Name Space Collisions • Polymorphism (Overloading)

  7. Object Attributes • Objects have many attributes • Lifetime (Persistence) • Type • Scope • Value/Address • Language should: • Precisely specify attributes • Be Orthogonal -Separate Controls

  8. Object Persistence vs. Lifetime • Persistence -Persistant objects last longer than the process that created it. • Examples - Files, databases. • Memory for nonpersistent objects is called volatile (you lose data if powered down). • Lifetime - When is the storage allocated to an object available?

  9. Events Impacting Object Lifetime • Life Time has several aspects. • Creation of objects • Creation of bindings • References to variables/subroutines/types/etc. • (Re)activation and Deactivation of bindings • Destruction of bindings • Destruction of Objects

  10. Allocation andObject Lifetime • How can objects be allocated? • Statically -Exist during Program's Lifetime • Stack -Used for ephemeral objects and ephemeral objects. • Heap Objects -Have controlled lifetimes • Deallocation: How is it indicated? • Explicitly - Destructors/free/delete • Implicitly - Garbage collection • Initialization - Separate (Constructors)

  11. Static Allocation • Done at compile time • Literals (and constants) bound to values • Variables bound to addresses • Compiler notes undefined symbols • Library functions • Global Variables and System Constants • Linker (and loader if DLLs used) resolve undefined references.

  12. Stack Based Allocation • Stack Layout determined at compile time • Variables bound to offsets from top of stack. • Layout called stack frame or activation record • Compilers use registers • Function parameters and results need consistent treatment across modules • C/C++ use prototypes • Eiffel/Java/Oberon use single definition

  13. Parameter Passing Conventions • Actual Parameters -at the call site • Formal Parameters - at the subroutine declaration • Address - a memory location, data objects containing addresses can be called: • Pointer - use explicit dereferencing operation. • Reference - use implicit dereferencing.

  14. Parameter Passing Conventions • Call by value - Copy to the function • Call by reference - Pass reference • Call by address - Pass address to function • Call by result - Pass result back to caller • Call by value result - Copy inputs to the function and copy results to caller. • Parameters can be on stack or in registers.

  15. Call Site Code Generation for Stack Allocation • Call Setup • Push Register Values on stack (if caller saves) • Push parameters on stack (or load into registers) • Call Function • Push Return Address on stack • Goto Function's Start Address • Call Cleanup (if caller saves)

  16. Subroutine Code Generation for Stack Allocation • Prologue -Push Registers that will be overwritten on stack (if callee saves) • Body of function • Call Cleanup (if caller saves) • Copy results (if any) • Pop Parameters off stack. • Pop registers • Return

  17. Stack and Frame Layout • Stack here grows toward low addresses.

  18. Heap Allocation • Heap provides dynamic memory management. • Not to be confused with binary heap or binomial heap data structures. • Under the hood, may periodically need to request additional memory from the O/S. • Requested large regions (requests are expensive). • Done using a library (e.g. C) • Or as part of the language (C++, Java, Lisp).

  19. Heap Data Structures • Must track allocated/Free Memory. • Metadata is added (pointers, size, etc).

  20. Memory Management • Holes can form where memory is freed. • Coalesce adjacent holes • Small holes fragment the memory. • Suppose you allocate a smaller chunk, which hole do we take it from? • First fit - The first hole found that it fits into • Best fit - The smallest segment it fits into • Worst fit - The largest segment it fits into

  21. When to Free Memory • Depends on language. • Explicit deallocation -needed for library approaches (e.g. C). • Implicit Deallocation - aka garbage collection • Garbage is unreferenced memory. • Compaction moves allocated memory to contiguous addresses (coalescing all holes). • Can cause timing variations (care is needed in real time systems).

  22. Speeding Up Searching for a Free Block • Recall all fitting scheme require finding sufficiently large blocks. • Idea: Organize Free List according to block size. • Fibbonacci Heap - Use Fibbonacci numbers for block sizes. • Buddy System -Use Block sizes of 2k

  23. Introduction to Scope • Scope refers to the region of a program during which a binding is active. • Consider the following code segment, what should the output be?

  24. Scope Rules • Two popular answers to the problem. • Static (lexical) scope -Use compile time analysis. Normally in block structured languages, the containing scope is preferred, output is 1 in this case. • Dynamic Scope -Value found at run time by resolving to nearest stack frame in which the value is defined, output is 2 in this case. • Lexical scope is more popular.

  25. Variants of Static Scope • Single Global Scope (BASIC) - simplest • Global and Local (Fortran) • Fortran Common Blocks • Supports separate compilation • Gives base address of region • Each program specifies (possibly different) layout • Block Structured (Pascal)

  26. Modules and Separate Compilation • Modules support encapsulation (much like classes). • Found in Modula 2, Euclid, Oberon and Ada. • For separate compilation • define interfaces (data and subroutines) • Export statements - published interfaces • Import statements - uses published interfaces • Classes are extensions of modules

  27. More Notation • Fundamental question: Does the scope need to be explicitly imported to be visible? • Yes - Referred to as closed scope. • No - Referred to as open scope. • Aliasing -having more than one way to refer to the same object.

  28. Classes and Scope • Classes provide encapsulation in object oriented programming (OOP). • Supports aggregating heterogeneous data and operations together. • Interfaces are published • C++ public section in classes • Internals can be hidden (ala private section in C++) • Constructors and destructors supported.

  29. OOP Features • I think of OOP as providing • Encapsulation -groups data with operations • Inheritance -permits extension of more general base classes (and overriding behaviors) • Polymorphism (overloading) - allows operators/subroutines to have behaviors dependent on the types of arguments and results expected.

  30. Dynamic Scope • Dynamic scoping prefers the instance defined in the most recently invoked function. • Not very popular currently (hard to debug) • Found in interpreted languages (APL, older Lisp dialects, e.g. EMACS Lisp). • Fans claim that it makes customizing subroutines easier.

  31. Another Dynamic vs. Static Scope Example

  32. Symbol Table Design Criteria • Symbol tables require: • Fast insertion • Fast lookup • Occasional deletion (should be fast). • Which motivates the use of hash tables. • But ordinary hash tables are not good with nesting (ala classes/records/subroutines)

  33. Operations on Symbol Tables (Static Scope) • A Symbol Table should support: • Entering Scope • Leaving Scope • Inserting a symbol (with scope information) • Looking up a symbol (with scope information) • It is often useful to store symbol table in object/executables • e.g. For debugging or source level analysis

  34. LeBlanc-Cook Symbol Table Lookup 1/5 • LeBlanc-Cook Symbol Table Lookup • Each Scope is assigned a serial number • Elements are never deleted from the table • A Scope Counter is maintained • The first scope is 0 • Every new scope encountered increments the counter • To track nesting, a scope stack is maintained. • Push to enter scope, pop when leaving scope

  35. LeBlanc-Cook Symbol Table Lookup 2/5 • Put all symbols in a single hash table. • Keywords not inserted (can use another hash). • Entries indexed using both name and scope. • To lookup a name • Look in the hash table for (name,scope) pair. • If not found: • Parent scope is found using stack • Test if parent scope is open or exports symbol

  36. LeBlanc-Cook Symbol Table Lookup 3/5 • About Hashing and Hash Functions: • Is the universe of keys known in advance? • Yes - perfect minimal hashing may be possible. • No - must handle collisions • e.g. Quadratic Rehash or Chaining • Symbol Table Algorithm has to handle collisions if hashing is used.

  37. LeBlanc-Cook Symbol Table Lookup 4/5

  38. LeBlanc-Cook Symbol Table Lookup 5/5

  39. LeBlanc-Cook Symbol Table (An Example)

  40. Dynamic Scope and Symbol Table Management • Dynamic scope has different symbol table management needs than static scope • Needs insert, lookup, enter scope, leave scope. • Just like static scope • Competing Approaches: simplicity vs. speed • Association Lists -Simple, fast scope entry/exit. • Central Reference Table -Like Leblanc-Cook sans reference stack. • Faster Lookup (common case?), slower scope entry/exit.

  41. Association Lists • Association Lists (A-Lists) combine list and stack treatment. • When a new scope is entered • Push its symbols on the stack • Use a unidirectional linked list to implement stack. • To find an item • Scan stack starting at top of stack. • When leaving a scope • Pop all symbols in scope from the stack.

  42. Central Reference Tables (1) • Central Reference Tables use hashing • Elements are keyed by symbol • Each element is a stack • So we have one stack per symbol • Newest Scope is on top • Use a unidirectional linked list to implement stack.

  43. Central Reference Tables (2) • To insert a symbol/scope • Hash on symbol, push symbol/scope on stack. • To find a symbol in a scope • Hash to symbol's stack • Use scope at top of stack. • When leaving scope • Pop all symbols in that scope from top of their respective stacks.

  44. Resolving Static Scope at Run Time • Consider a function F containing G. • i.e. F and G are nested functions • Suppose G uses an identifier in F's scope. • How can G find F's frame pointer at run time? • If G is always invoked by F, just do base + offset • Called static chaining - offset computed at compile time. • But what if G is separated by recursive invocations • Use pointer jumping (exploit transitivity and associativity) • Called dynamic chaining - requires run time support

  45. An Example Requiring Dynamic Chaining

  46. Subroutine Closures • Consider when a function, F, is passed as an argument to another function, G • E.g. Comparison Operators for sorting • When G invokes F, how can we determine the scope? • Subroutine closures describe a function's scope and instruction space address

  47. Overloading Defined • An overloaded function or operator selects its semantics based on the types of its parameters and result • Implicit overloading - provided by language • e.g. addition in Pascal can handle real or integers • Write and Writeln in Pascal • Explicit overloading - programmers resolve actions • e.g. Overloaded operators and methods in C++

  48. Some thoughts on Overloading • Should user defined overloading of operators be permitted? • Pro: Permits consistent interface • e.g. A = B * C; good for integer, real, complex ... • Cons: You may need to read the entire program to understand a single line of code. • e.g. A = B * C; What if B and C are objects? Inheritance? • What to do with ephemeral objects? e.g A * B * C

  49. More Thoughts • Meyer's Eiffel overloads A(i) • Single parameter function • Single index array • Because functions and arrays are often interchangeable! • Operator vs. function overloading • Operator - Syntactic Sugar • Function - Programmers know to read code

  50. Challenges of Overloading • Compiler needs to be smart about types • Separate compilation hard • e.g. Unix Linker - Predates C++ • Name Space Mangling • Can break system tools (profilers/debuggers) • Compiler creates a unique name based on operator/function name and parameter/result types. • No standard defined • Hard to link code compiled by different compilers

More Related