CMPE 152: Compiler Design September 4 Class Meeting

Slides:



Advertisements
Similar presentations
CS 153: Concepts of Compiler Design September 2 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
Advertisements

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 14 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 August 26 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
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
Lecture 9 Symbol Table and Attributed Grammars
CS 432: Compiler Construction Lecture 9
CS 153: Concepts of Compiler Design September 14 Class Meeting
A Simple Syntax-Directed Translator
Constructing Precedence Table
CS 432: Compiler Construction Lecture 5
CS 153: Concepts of Compiler Design August 29 Class Meeting
CS 153: Concepts of Compiler Design September 12 Class Meeting
CS 153: Concepts of Compiler Design October 17 Class Meeting
CS 153: Concepts of Compiler Design October 5 Class Meeting
CS 432: Compiler Construction Lecture 10
CS 153: Concepts of Compiler Design September 7 Class Meeting
CS 153: Concepts of Compiler Design October 3 Class Meeting
CMPE 152: Compiler Design February 6 Class Meeting
CMPE 152: Compiler Design September 25 Class Meeting
CS 3304 Comparative Languages
CMPE 152: Compiler Design September 6 Class Meeting
CMPE 152: Compiler Design August 30 Class Meeting
CS 432: Compiler Construction Lecture 7
CMPE 152: Compiler Design September 11 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 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
Compiling Control Statements
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 14 Class Meeting
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
CMPE 152: Compiler Design February 28 / March 5 Lab
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 March 5 Class Meeting
CMPE 152: Compiler Design April 16 Class Meeting
CMPE 152: Compiler Design March 7/12 Lab
CMPE 152: Compiler Design September 3 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 4 Class Meeting Department of Computer Engineering San Jose State University Fall 2018 Instructor: Ron Mak www.cs.sjsu.edu/~mak

Quick Review of the Framework Chapter 4 Quick Review of the Framework TO: FROM: Our next topic: The symbol table

The Symbol Table: Conceptual Design Goal: The symbol table should be source language independent. Each entry in the symbol table has a name attributes At the conceptual level, we don’t worry about implementation.

What to Store in Each Symbol Table Entry Each symbol table entry is designed to store information about an identifier. The attribute keys indicate what information we will store for each type of identifier. Store common information in fixed fields (e.g., lineNumbers) and store identifier type-specific information as attributes. enum class SymTabKeyImpl {     // Constant.     CONSTANT_VALUE,     // Procedure or function.     ROUTINE_CODE, ROUTINE_SYMTAB, ROUTINE_ICODE,     ROUTINE_PARMS, ROUTINE_ROUTINES,     // Variable or record field value.     DATA_VALUE }; wci/intermediate/symtabimpl/SymTabEntryImpl.h

What Needs a Symbol Table? A Pascal program Identifiers for constant, type, variable, procedure, and function names. A Pascal procedure or function Identifiers for formal parameter (argument) names. A Pascal record type Identifiers for field names.

The Symbol Table Stack Language constructs can be nested. Procedures and functions are nested inside a program. Procedures and functions can be nested inside of each other. Record types are defined within programs, procedures, and functions. Record types can be nested inside of each other. Therefore, symbol tables need to be kept on a symbol table stack.

The Symbol Table Stack, cont’d Whichever symbol table is on top of the stack is the local symbol table. The first symbol table created (the one at the bottom of the stack) is the global symbol table. It stores the predefined information, such as entries for the names of the standard types integer, real, char, and boolean. During the translation process, symbol tables are pushed onto and popped off the stack … … as the parser enters and exits nested procedures, functions, record types, etc. Global symbol table

The Symbol Table Stack, cont’d For now, we’ll have only have a single symbol table. Therefore, the local symbol table is the global symbol table. We won’t need multiple symbol tables until we start to parse declarations. Implementing the symbol table stack now will make things easier for us later. Global symbol table

Modifications to Class PascalParserTD     while ((token = next_token(token)) != nullptr)     {         TokenType token_type = token->get_type();         last_line_number = token->get_line_number();         Object value = token->get_value();         string type_str;         string value_str;         if (token_type == (TokenType) PT_IDENTIFIER)         {             string name = to_lower(token->get_text());             SymTabEntry *entry = symtab_stack->lookup(name);             if (entry == nullptr) entry = symtab_stack->enter_local(name);             entry->append_line_number(token->get_line_number());         }         else if (token_type == (TokenType) PT_ERROR)             PascalErrorCode error_code =                                     (PascalErrorCode) cast(value, int);             error_handler.flag(token, error_code, this); Cross-reference only identifiers. If it’s not already in the symbol table, create a new entry. wci/frontend/pascal/PascalParserTD.cpp

Cross-Reference Listing A cross-reference listing verifies the symbol table code: ./Chapter4cpp compile -x newton.pas Modifications to the main Pascal class: Pascal.cpp     parser->parse();     source->close();     symtab_stack = parser->get_symtab_stack();     icode = parser->get_icode();     if (xref)     {         CrossReferencer cross_referencer;         cross_referencer.print(symtab_stack);     } A new utility class CrossReferencer generates the cross-reference listing. Demo

Quick Review of the Framework Chapter 5 Quick Review of the Framework FROM: TO: Next topic: Parsing assignment statements and expressions, and generating parse trees.

Pascal Statement Syntax Diagrams

Pascal Statement Syntax Diagrams, cont’d For now, greatly simplified!

Parse Tree: Conceptual Design More accurately called an abstract syntax tree (AST). BEGIN alpha := -88; beta := 99; result := alpha + 3/(beta – gamma) + 5 END

Parse Tree: Conceptual Design At the conceptual design level, we don’t care how we implement the tree. This should remind you of how we first designed the symbol table.

Parse Tree: Basic Tree Operations Create a new node. Create a copy of a node. Set and get the root node of a parse tree. Set and get an attribute value in a node. Add a child node to a node. Get the list of a node’s child nodes. Get a node’s parent node.

Intermediate Code Interfaces Goal: Keep it source language-independent.

Intermediate Code Implementations

An Intermediate Code Factory Class wci/intermediate/ICodeFactory.cpp ICode *ICodeFactory::create_icode() {     return new ICodeImpl(); } ICodeNode *ICodeFactory::create_icode_node(const ICodeNodeType type)     return new ICodeNodeImpl(type);

Coding to the Interfaces (Again)     // Create the ASSIGN node.     ICodeNode *assign_node =             ICodeFactory::create_icode_node((ICodeNodeType) NT_ASSIGN); ...     // Create the variable node and set its name attribute.     ICodeNode *variable_node =             ICodeFactory::create_icode_node(                              (ICodeNodeType) NT_VARIABLE);     // The ASSIGN node adopts the variable node as its first child.     assign_node->add_child(variable_node); wci/frontend/pascal/parsers/AssignmentStatementParser.cpp

Intermediate Code (ICode) Node Types enum class ICodeNodeTypeImpl {     // Program structure     PROGRAM, PROCEDURE, FUNCTION,     // Statements     COMPOUND, ASSIGN, LOOP, TEST, CALL, PARAMETERS,     IF, SELECT, SELECT_BRANCH, SELECT_CONSTANTS, NO_OP,     // Relational operators     EQ, NE, LT, LE, GT, GE, NOT,     // Additive operators     ADD, SUBTRACT, OR, NEGATE,     // Multiplicative operators     MULTIPLY, INTEGER_DIVIDE, FLOAT_DIVIDE, MOD, AND,     // Operands     VARIABLE, SUBSCRIPTS, FIELD,     INTEGER_CONSTANT, REAL_CONSTANT,     STRING_CONSTANT, BOOLEAN_CONSTANT,     // WRITE parameter     WRITE_PARM, }; Do not confuse node types (ASSIGN, ADD, etc.) with data types (integer, real, etc.). We use the enumerated type ICodeNodeTypeImpl for node types which is different from the enumerated type PascalTokenType to help maintain source language independence. wci/intermediate/icodeimpl/ICodeNodeImpl.h

Intermediate Code Node Implementation class ICodeNodeImpl : public ICodeNode { ... private:     ICodeNodeType type;            // node type     ICodeNode *parent;             // node's parent     vector<ICodeNode *> children;  // node's children     map<ICodeKey, Object> contents; } wci/intermediate/icodeimpl/ICodeNodeImpl.h Each node has an vector<ICodeNode *> of child nodes. Each node has a map<ICodeKey, Object> for the node contents.

A Parent Node Adopts a Child Node ICodeNode *ICodeNodeImpl::add_child(ICodeNode *node) {     if (node != nullptr)     {         children.push_back(node);         ((ICodeNodeImpl *) node)->parent = this;     }     return node; } wci/intermediate/icodeimpl/ICodeNodeImpl.cpp When a parent node adds a child node, we can say that the parent node “adopts” the child node. Keep the parse tree implementation simple!

What Attributes to Store in a Node? public enum ICodeKeyImpl implements ICodeKey { LINE, ID, VALUE; } wci.intermediate.icodeimpl.ICodeNodeImpl.h Not much! Not every node will have these attributes. LINE: statement line number ID: symbol table entry of an identifier VALUE: data value Most of the information about what got parsed is encoded in the node type and in the tree structure.

Statement Parser Class Class StatementParser is a subclass of PascalParserTD which is a subclass of Parser. Its parse() method builds a part of the parse tree and returns the root node of the newly built subtree.

Statement Parser Subclasses StatementParser itself has subclasses: CompoundStatement-Parser AssignmentStatement-Parser ExpressionParser The parse() method of each subclass returns the root node of the subtree that it builds. Note the dependency relationships among StatementParser and its subclasses.

Building a Parse Tree Each parse() method builds a subtree and returns the root node of the new subtree. The caller of the parse() method adopts the subtree’s root node as a child of the subtree that the caller is building. The caller then returns the root node of its subtree to its caller. This process continues until the entire source has been parsed and we have the entire parse tree.

Building a Parse Tree Example: BEGIN alpha := 10; beta := 20 END CompoundStatementParser’s parse() method creates a COMPOUND node. 2. AssignmentStatementParser’s parse()method creates an ASSIGN node and a VARIABLE node, which the ASSIGN node adopts as its first child.

Building a Parse Tree 3. ExpressionParser’s parse() method creates an INTEGER CONSTANT node which the ASSIGN node adopts as its second child. BEGIN alpha := 10; beta := 20 END 4. The COMPOUND node adopts the ASSIGN node as its first child.

Building a Parse Tree Another set of calls to the parse() methods of AssignmentStatementParser and ExpressionParser builds another assignment statement subtree. 6. The COMPOUND node adopts the subtree as its second child. BEGIN alpha := 10; beta := 20 END