CMPE 152: Compiler Design September 18 Class Meeting

Slides:



Advertisements
Similar presentations
1 Compiler Construction Intermediate Code Generation.
Advertisements

Pascal By: Liane Tom. Outline o Background o Data types and Syntax o Procedures and Functions o Advantages o Disadvantages.
CS 153: Concepts of Compiler Design August 25 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak
CS 152: Programming Language Paradigms April 9 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak
CS 153: Concepts of Compiler Design September 2 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
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 153: Concepts of Compiler Design September 16 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
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 September 30 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
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 153: Concepts of Compiler Design September 28 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
Lecture 9 Symbol Table and Attributed Grammars
CS 432: Compiler Construction Lecture 9
CS 153: Concepts of Compiler Design September 14 Class Meeting
CS 153: Concepts of Compiler Design August 29 Class Meeting
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 September 7 Class Meeting
CS 153: Concepts of Compiler Design October 3 Class Meeting
CS 153: Concepts of Compiler Design December 5 Class Meeting
CS 153: Concepts of Compiler Design November 30 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
CMPE 152: Compiler Design September 4 Class Meeting
CMPE 152: Compiler Design September 6 Class Meeting
CMPE 152: Compiler Design August 30 Class Meeting
CMPE 152: Compiler Design September 13 Class Meeting
CMPE 152: Compiler Design October 2 Class Meeting
CMPE 152: Compiler Design October 4 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
CMPE 152: Compiler Design December 6 Class Meeting
CMPE 152: Compiler Design September 27 Class Meeting
CS 153: Concepts of Compiler Design November 6 Class Meeting
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
CMPE 152: Compiler Design February 21/26 Lab
Symbol Table 薛智文 (textbook ch#2.7 and 6.5) 薛智文 96 Spring.
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 February 19 Class Meeting
CMPE 152: Compiler Design March 7 Class Meeting
CMPE 152: Compiler Design April 18 – 30 Labs
CMPE 152: Compiler Design March 5 Class Meeting
CMPE 152: Compiler Design April 16 Class Meeting
CMPE 152: Compiler Design December 4 Class Meeting
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 26 Class Meeting
CMPE 152: Compiler Design September 19 Class Meeting
Presentation transcript:

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

Multipass Compilers A compiler or an interpreter makes a “pass” each time it processes the source program, either: The original source text, or The intermediate form (parse tree)

Three-Pass Compiler We’ve designed a 3-pass compiler or interpreter. Pass 1: Parse the source in order to build the parse tree and symbol tables. Pass 2: Work on the parse tree to do some optimizations. Example: Create CASE statement jump tables. Pass 3: Walk the parse tree to generate object code (compiler) or to execute the program (interpreter).

Multipass Compilers, cont’d Having multiple passes breaks up the work of a compiler or an interpreter into distinct steps. Front end, intermediate tier, back end: Modularize the structure of a compiler or interpreter Multiple passes: Modularize the work of compiling or interpreting a program.

Multipass Compilers, cont’d Back when computers had very limited amounts of memory, multiple passes were necessary. The compiler code for each pass did its work and then it was removed from memory. The code for the next pass was loaded into memory to do its work based on the work of the previous pass.

Multipass Compilers, cont’d Example: The FORTRAN compiler for the IBM 1401 could work in only 8K of memory and made up to 63 passes over a source program. See: http://www.cs.sjsu.edu/~mak/CS153/lectures/IBM1401FORTRANCompiler.pdf

Scripting Engine We now have a simple scripting engine! We can execute: Expressions Assignment statements Control statements Compound statements Variables that are untyped

What’s Next? Parse Pascal declarations Type checking Parse procedure and function declarations Runtime memory management Interpret entire Pascal programs.

Chapter 9 Parsing Declarations The declarations of a programming language are often the most challenging to parse. Declarations syntax can be difficult. Declarations often include recursive definitions. You must keep of track of diverse information. Many new items to enter into the symbol table.

Pascal Declarations Classic Pascal declarations consist of 5 parts, each optional, but always in this order: Label declarations Constant definitions Type definitions Variable declarations Procedure and function declarations We will examine 2, 3, and 4 next. We’ll do procedures and functions in a couple of weeks.

Pascal Declarations The CONST, TYPE, and VAR parts are optional, but they must come in this order. Note that constants and types are defined, but variables are declared. Collectively, you refer to all of them as declarations.

Pascal Constant Definitions Example constant definition part: CONST factor = 8; epsilon = 1.0e-6; ch = 'x'; limit = -epsilon; message = 'Press the OK button to confirm your selection.'; Classic Pascal only allows a constant value after the = sign. No constant expressions.

Pascal Type Definitions A Pascal simple type can be: scalar (integer, real, boolean, char) enumeration subrange Not reserved words!

Pascal Simple Type Definitions Examples of subrange and enumeration type definitions: CONST factor = 8; TYPE range1 = 0..factor; {subrange of integer (factor is constant)} range2 = 'a'..'q'; {subrange of char} range3 = range1; {type identifier} grades = (A, B, C, D, F); {enumeration} passing = A..D; {subrange of enumeration} week = (monday, tuesday, wednesday, thursday, friday, saturday, sunday); weekday = monday..friday; weekend = saturday..sunday;

Pascal Array Type Definitions index type element type An array type specification has an index type and an element type. The index type must be a simple type (subrange or enumeration). The element type can be any type. Including another array type (multidimensional arrays).

Pascal Array Type Definitions Examples of array definitions. TYPE ar1 = ARRAY [grades] OF integer; ar2 = ARRAY [(alpha, beta, gamma)] OF range2; ar3 = ARRAY [weekday] OF ar2; ar4 = ARRAY [range3] OF (foo, bar, baz); ar5 = ARRAY [range1] OF ARRAY [range2] OF ARRAY[c..e] OF enum2; ar6 = ARRAY [range1, range2, c..e] OF enum2; Type definitions ar5 and ar6 above are equivalent ways to define a multidimensional array. A Pascal string type is an array of characters. The index type must be an integer subrange with a lower limit of 1. str = ARRAY [1..10] OF char;

Pascal Record Type Definitions A record field can be any type. Including another record type (nested records).

Pascal Record Type Definitions Examples of record definitions: TYPE rec1 = RECORD i : integer; r : real; b1, b2 : boolean; c : char END; rec2 = RECORD ten : integer; r : rec1; a1, a2, a3 : ARRAY [range3] OF range2;

Pascal Variable Declarations Variable declarations are syntactically similar to record field declarations: Examples: VAR var1 : integer; var2, var3 : range2; var4 : ar2 var5 : rec1; direction : (north, south, east, west); Types can be named or unnamed.

Declarations and the Symbol Table Identifiers from Pascal declarations that we will enter into a symbol table, names of: constants types enumeration values record fields variables Information from parsing type specifications: simple types array types record types

Scope and the Symbol Table Stack Scope refers to the part of the source program where certain identifiers can be used. Everywhere in the program where the definitions of those identifiers are in effect. A program creates a scope whenever it has identifiers that can only be used in a certain part of the program. Example: Local variables of a function. Closely related to nesting levels and the symbol table stack.

Scope and the Symbol Table Stack, cont’d Global scope Nesting level 0: At the bottom of the symbol table stack. All predefined global identifiers such as integer, real, boolean, char. Program scope Nesting level 1: One up from the bottom of the stack. All identifiers declared at the “top level” of a program (not in a procedure or function).

Scope and the Symbol Table Stack, cont’d Record definitions, procedures, and functions each has a scope. Scopes in a Pascal program are nested. An identifier can be redefined within a nested scope. Within the nested scope, the definition in the nested scope overrides the definition in an outer scope. Example: A function can have a local variable x which overrides a program variable x. Each scope must have its own symbol table.

Scope and the Symbol Table Stack, cont’d As the parser parses a program from top to bottom, it enters and exits nested scopes. Whenever the parser enters a scope, it must push that scope’s symbol table onto the symbol table stack. Whenever the parser exits a scope, it must pop that scope’s symbol table off the stack.

Scope and the Symbol Table Stack, cont’d Scope example: Program symbol table Global symbol table Note that the program name Test is defined in the global scope at level 0.

New Methods for Class SymTabStackImpl wci::intermediate::symtabimpl::SymTabStackImpl.cpp SymTab *SymTabStackImpl::push() {     SymTab *symtab = SymTabFactory::create_symtab(++current_nesting_level);     stack.push_back(symtab);     return symtab; } SymTab *SymTabStackImpl::push(SymTab *symtab)     ++current_nesting_level; SymTab *SymTabStackImpl::pop()     SymTab *symtab = stack[current_nesting_level];     stack.erase(stack.begin() + current_nesting_level);     current_nesting_level--; Push a new symbol table onto the stack. Push an existing symbol table onto the stack. Pop a symbol table off the stack. Recall that we implemented SymTabStackImpl as an vector<SymTab *>.

Class SymTabStackImpl wci::intermediate::symtabimpl::SymTabStackImpl.cpp SymTabEntry *SymTabStackImpl::lookup_local(const string name) const {     return stack[current_nesting_level]->lookup(name); } SymTabEntry *SymTabStackImpl::lookup(const string name) const     SymTabEntry *found_entry = nullptr;     // Search the current and enclosing scopes.     for (int i = current_nesting_level;          (i >= 0) && (found_entry == nullptr); --i)     {         found_entry = stack[i]->lookup(name);     }     return found_entry; Method lookup() now searches the current symbol table and the symbol tables lower in the stack. It searches in the current scope and then outward in the enclosing scopes.