CMPE 152: Compiler Design October 4 Class Meeting

Slides:



Advertisements
Similar presentations
1 Compiler Construction Intermediate Code Generation.
Advertisements

1 Chapter 7: Runtime Environments. int * larger (int a, int b) { if (a > b) return &a; //wrong else return &b; //wrong } int * larger (int *a, int *b)
1 Pertemuan 20 Run-Time Environment Matakuliah: T0174 / Teknik Kompilasi Tahun: 2005 Versi: 1/6.
CS 152: Programming Language Paradigms April 9 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak
1 Semantic Analysis Aaron Bloomfield CS 415 Fall 2005.
CS 153: Concepts of Compiler Design September 2 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
Compiler Construction
CS 153: Concepts of Compiler Design September 9 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
CS 153: Concepts of Compiler Design October 5 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
CS 152: Programming Language Paradigms April 2 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak
CS 153: Concepts of Compiler Design September 16 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
BİL 744 Derleyici Gerçekleştirimi (Compiler Design)1 Run-Time Environments How do we allocate the space for the generated target code and the data object.
CS 153: Concepts of Compiler Design September 21 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
CS 153: Concepts of Compiler Design October 7 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
CS 153: Concepts of Compiler Design October 10 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
CS 153: Concepts of Compiler Design September 30 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
7. Runtime Environments Zhang Zhizheng
CS 152: Programming Language Paradigms April 7 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak
CS 153: Concepts of Compiler Design October 12 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
CS 153: Concepts of Compiler Design September 23 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
CS 152: Programming Language Paradigms May 12 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak
CS 153: Concepts of Compiler Design September 28 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
Run-Time Environments Presented By: Seema Gupta 09MCA102.
CS 153: Concepts of Compiler Design September 14 Class Meeting
Run-Time Environments Chapter 7
Implementing Subprograms
CS 153: Concepts of Compiler Design October 17 Class Meeting
CS 153: Concepts of Compiler Design October 5 Class Meeting
Review: Chapter 5: Syntax directed translation
CS 153: Concepts of Compiler Design October 3 Class Meeting
CS 153: Concepts of Compiler Design November 28 Class Meeting
CS 153: Concepts of Compiler Design December 5 Class Meeting
CMPE 152: Compiler Design December 5 Class Meeting
CMPE 152: Compiler Design February 6 Class Meeting
CMPE 152: Compiler Design September 25 Class Meeting
Implementing Subprograms
CMPE 152: Compiler Design September 4 Class Meeting
CS 3304 Comparative Languages
CMPE 152: Compiler Design August 30 Class Meeting
CMPE 152: Compiler Design September 18 Class Meeting
CMPE 152: Compiler Design September 13 Class Meeting
CMPE 152: Compiler Design October 2 Class Meeting
CMPE 152: Compiler Design September 11/13 Lab
CMPE 152: Compiler Design October 4 Class Meeting
CMPE 152: Compiler Design August 23 Class Meeting
CMPE 152: Compiler Design August 21/23 Lab
CMPE 152: Compiler Design September 20 Class Meeting
CS 153: Concepts of Compiler Design November 6 Class Meeting
UNIT V Run Time Environments.
CS 432: Compiler Construction Lecture 11
CMPE 152: Compiler Design February 28 Class Meeting
CMPE 152: Compiler Design March 7 Class Meeting
CMPE 152: Compiler Design April 9 Class Meeting
CMPE 152: Compiler Design January 29 Class Meeting
CMPE 152: Compiler Design February 12 Class Meeting
CMPE 152: Compiler Design February 7 Class Meeting
Run Time Environments 薛智文
CMPE 152: Compiler Design February 28 / March 5 Lab
COMPILERS Semantic Analysis
CMPE 152: Compiler Design February 21 Class Meeting
CMPE 152: Compiler Design February 26 Class Meeting
CMPE 152: Compiler Design March 7 Class Meeting
CMPE 152: Compiler Design April 16 Class Meeting
Implementing Subprograms
CMPE 152: Compiler Design March 7/12 Lab
CMPE 152: Compiler Design May 2 Class Meeting
CMPE 152: Compiler Design August 27 Class Meeting
CMPE 152: Compiler Design September 17 Class Meeting
CMPE 152: Compiler Design February 7 Class Meeting
CMPE 152: Compiler Design September 19 Class Meeting
Presentation transcript:

CMPE 152: Compiler Design October 4 Class Meeting Department of Computer Engineering San Jose State University Fall 2018 Instructor: Ron Mak www.cs.sjsu.edu/~mak

Review: The Front End Parser Now it can parse an entire Pascal program. For the main program and each procedure and function: Create a symbol table for the local identifiers. Create a parse tree for the compound statement. The symbol tables and parse trees live in the intermediate tier. The symbol table entry for a program, procedure, or function name points to the corresponding symbol table and parse tree.

Review: The Back End Executor Up until now, it can only execute a main program. Using only the main program’s symbol table and parse tree. It assumes the symbol tables and parse trees were correctly built by the front end. No syntax or type errors. The parse tree structure accurately represents the operator precedence rules.

Review: The Back End Executor, cont’d The back end executor executes the program by walking the parse trees and querying the symbol tables. The executor does not need to know what the source program looks like or even what language it was written in.

Review: Temporary Hacks Store values of variables calculated at run time into the variable’s symbol table entry. Print out debugging information each time we assign a value to a variable. We don’t know how to execute a write or writeln call yet.

Temporary Hacks Removed! A variable is “declared” the first time it appears as the target of an assignment statement. We now can parse variable declarations. A variable can hold a value of any type. Now the parser can check for assignment compatibility.

Back to the Interpreter Back End Execute entire Pascal programs!

The Interpreter The back end executes the source program. Chapter 12 The Interpreter The back end executes the source program. Uses the symbol tables and the parse trees built by the front end parser. One symbol table per main program, procedure, and function for that routine’s local identifiers. The symbol table is pointed to by the routine name’s symbol table entry.

The Interpreter, cont’d One parse tree per main program, procedure, and function. For that routine’s compound statement. Pointed to by the symbol table entry for the routine’s name. The interpreter never sees the original source program. Only the symbol tables and parse trees.

Compile Time vs. Run Time The time during which the front end is parsing the source program and building the symbol tables and the parse trees. It’s called “compile time” whether the back end is a compiler or an interpreter. AKA translation time

Compile Time vs. Run Time The time during which the back end interpreter is executing the source program. English grammar alert! Noun: run time Example: The program executes during run time. Adjective: runtime (or run-time) Example: Division by zero is a runtime error.

Runtime Memory Management The interpreter must manage the memory that the source program uses during run time. Up until now, we’ve used the hack of storing values computed during run time into the symbol table. Why is this a bad idea? This will fail miserably if the source program has recursive procedure and function calls.

Symbol Table Stack vs. Runtime Stack The front end parser builds symbol tables and manages the symbol table stack as it parses the source program. The parser pushes and pops symbol tables as it enters and exits nested scopes. The back end executor manages the runtime stack as it executes the source program. The executor pushes and pops activation records as it calls and returns from procedures and functions. These are similar concepts, so don’t confuse them!

Reminders A VARIABLE node in the parse tree contains a reference to the variable name’s symbol table entry. Set in the front end by method VariableParser::parse() The method that takes two parameters. A symbol table entry contains a reference to its parent symbol table. The symbol table that contains the entry.

Reminders, cont’d Each symbol table has a nesting level field. Therefore, at run time, for a given VARIABLE node, the executor can determine the nesting level of the variable.

Runtime Activation Records An activation record (AKA stack frame) maintains information about the currently executing routine a procedure a function the main program itself

Runtime Activation Records, cont’d In particular, an activation record contains the routine’s local memory. values of local variables values of formal parameters This local memory is a memory map. Key: The name of the local variable or formal parameter. Value: The current value of the variable or parameter. Local memory is a hash table!

Runtime Activation Records, cont’d PROGRAM main1; PROCEDURE proc2a; PROCEDURE proc3; BEGIN ... END; BEGIN {proc2a} proc3; PROCEDURE proc2b; proc2a; BEGIN {main1} proc2b; END. In this example, the names of the routines indicate their nesting levels. AR: proc3 Call a routine: Push its activation record onto the runtime stack. Return from a routine: Pop off its activation record. AR: proc2a AR: proc2b AR: main1 RUNTIME STACK main1  proc2b  proc2a  proc3

Runtime Access to Local Variables PROGRAM main1; VAR j : integer; PROCEDURE proc2b; BEGIN j := 14; END; BEGIN {main1} j := 55; proc2b; END. Accessing local values is simple, because the currently executing routine’s activation record is on top of the runtime stack. AR: proc2b j 14 AR: main1 j 55 main1  proc2b RUNTIME STACK

Runtime Access to Nonlocal Variables PROGRAM main1; VAR i, j : integer; PROCEDURE proc2a; VAR m : integer; PROCEDURE proc3; VAR j : integer BEGIN j := i + m; END; BEGIN {proc2a} i := 11; m := j; proc3; PROCEDURE proc2b; VAR j, m : integer; j := 14; m := 5; proc2a; BEGIN {main1} i := 33; j := 55; proc2b; END. Each parse tree node for a variable contains the variable’s symbol table entry as its VALUE attribute. Each symbol table entry has the variable’s nesting level n. To access the value of a variable at nesting level n, the value must come from the topmost activation record at level n. Search the runtime stack from top to bottom for the topmost activation record at level n. AR: proc3 j 66 AR: proc2a m 55 AR: proc2b j m 14 5 AR: main1 i j 33 11 55 RUNTIME STACK main1  proc2b  proc2a  proc3

The Runtime Display A vector called the runtime display makes it easier to access nonlocal values. This has nothing to do with video displays!

The Runtime Display, cont’d Element n of the display always points to the topmost activation record at scope nesting level n on the runtime stack. The display must be updated as activation records are pushed onto and popped off the runtime stack.

The Runtime Display, cont’d Whenever a new activation record at level n is pushed onto the stack, it links to the previous topmost activation record at level n. This link helps to restore the runtime stack as activation records are popped off when returning from procedures and functions.

Runtime Access to Nonlocal Variables PROGRAM main1; VAR i, j : integer; PROCEDURE proc2a; VAR m : integer; PROCEDURE proc3; VAR j : integer BEGIN j := i + m; END; BEGIN {proc2a} i := 11; m := j; proc3; PROCEDURE proc2b; VAR j, m : integer; j := 14; m := 5; proc2a; BEGIN {main1} i := 33; j := 55; proc2b; END. AR: proc3 j AR: proc2a m 3 2 AR: proc2b j m 1 RUNTIME DISPLAY AR: main1 i j The runtime display allows faster access to nonlocal values. RUNTIME STACK main1  proc2b  proc2a  proc3

Recursive Calls PROGRAM main1 FUNCTION func2 FUNCTION func3 PROCEDURE proc2 PROCEDURE proc3 AR: proc2 AR: func3 AR: proc3 AR: func2 AR: proc3 3 2 AR: proc2 1 AR: main1 RUNTIME DISPLAY RUNTIME STACK main1  proc2  proc3  func2  proc3  func3  proc2

Allocating an Activation Record The activation record for a routine (procedure, function, or the main program) needs one or more “data cells” to store the value of each of the routine’s local variables and formal parameters. TYPE arr = ARRAY[1..3] OF integer; ... PROCEDURE proc(i, j : integer; VAR x, y : real; VAR a : arr; b : arr); VAR k : integer; z : real; AR: proc i x k j y z a b

Allocating an Activation Record, cont’d TYPE arr = ARRAY[1..3] OF integer; ... PROCEDURE proc(i, j : integer; VAR x, y : real; VAR a : arr; b : arr); VAR k : integer; z : real; AR: proc i x k j y z a b Obtain the names and types of the local variables and formal parameters from the routine’s symbol table.

Allocating an Activation Record, cont’d TYPE arr = ARRAY[1..3] OF integer; ... PROCEDURE proc(i, j : integer; VAR x, y : real; VAR a : arr; b : arr); VAR k : integer; z : real; AR: proc i x k j y z a b Whenever we call a procedure or function: Create an activation record. Push the activation record onto the runtime stack. Allocate the memory map of data cells based on the symbol table. No more storing runtime values in the symbol table!

Passing Parameters During a Call PROGRAM main; TYPE arr = ARRAY[1..3] OF integer; VAR index, count : integer; epsilon, delta : real; triplet : arr; PROCEDURE proc(i, j : integer; VAR x, y : real; VAR a : arr; b : arr); ... BEGIN {main} proc(index + 2, count, epsilon, delta, triplet, triplet); END. AR: proc i x 12 j y 84 a b 10 20 30 index count epsilon delta AR: main triplet 10 84 -3.1 0.07 20 30 RUNTIME STACK Value parameters: A copy of the value is passed. VAR parameters: A reference to the actual parameter is passed.

Memory Management Interfaces Implementations: Runtime stack: vector<ActivationRecord *> Runtime display: vector<ActivationRecord *> Memory map: map<string, Cell *> Class MemoryFactory creates: runtime stack runtime display memory map cell

Class RuntimeStackImpl ws::backend::interpreter::memoryImpl::RuntimeStackImpl Implemented by vector<ActivationRecord *> Methods push(ActivationRecord *ar) Push an activation record onto the runtime stack. ActivationRecord pop() Pop off the top activation record. ActivationRecord *get_topmost (int nesting_level) Return the topmost activation record at a given nesting level. (Uses the runtime display!)

Class RuntimeDisplayImpl ws::backend::interpreter::memoryImpl::RuntimeDisplayImpl Implemented by vector<ActivationRecord *> Methods ActivationRecord *get_activation_record (int nesting_level) Get the activation record at a given nesting level. call_update(int nesting_level, ActivationRecord *ar) Update the display for a call to a routine at a given nesting level. return_update(int nesting_level) Update the display for a return from a routine at a given nesting level.

Class MemoryMapImpl Implemented by map<string, Cell *> Methods ws::backend::interpreter::memoryImpl::MemoryMapImpl Implemented by map<string, Cell *> Methods MemoryMapImpl(SymTab *symTab) Allocate the memory cells based on the names and types of the local variables and formal parameters in the symbol table. Cell *get_cell(string name) Return the memory cell with the given name. vector<string> get_all_names() Return the list of all the names in this memory map.

Class ActivationRecordImpl ws::backend::interpreter::memoryImpl::ActivationRecordImpl Fields int nesting_level MemoryMap *memory_map Values of the local variables and formal parameters ActivationRecord *link Link to the previous topmost activation record with the same nesting level in the runtime stack Method Cell *get_cell(string name) Return a reference to a memory cell in the memory map that is keyed by the name of a local variable or formal parameter.