CMPE 152: Compiler Design March 5 Class Meeting

Slides:



Advertisements
Similar presentations
CH4.1 Type Checking Md. Fahim Computer Engineering Department Jamia Millia Islamia (A Central University) New Delhi –
Advertisements

CPSC 388 – Compiler Design and Construction
Chapter 6 Type Checking. The compiler should report an error if an operator is applied to an incompatible operand. Type checking can be performed without.
CS 153: Concepts of Compiler Design August 25 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak
Cs164 Prof. Bodik, Fall Symbol Tables and Static Checks Lecture 14.
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 14 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 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
CS412/413 Introduction to Compilers Radu Rugina Lecture 11: Symbol Tables 13 Feb 02.
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 153: Concepts of Compiler Design September 14 Class Meeting
Constructing Precedence Table
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 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
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
Chapter 6 Intermediate-Code Generation
CMPE 152: Compiler Design September 11/13 Lab
CMPE 152: Compiler Design October 4 Class Meeting
CMPE 152: Compiler Design August 21/23 Lab
CMPE 152: Compiler Design September 20 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 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 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 April 18 – 30 Labs
CMPE 152: Compiler Design April 16 Class Meeting
CMPE 152: Compiler Design March 28 Class Meeting
CMPE 152: Compiler Design March 19 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 March 5 Class Meeting Department of Computer Engineering San Jose State University Spring 2019 Instructor: Ron Mak www.cs.sjsu.edu/~mak

Now that we can parse declarations … We can parse variables that have subscripts and fields. Example: We can perform type checking. A semantic action. Chapter 10 var9.rec.flda[b][0,'m'].flda[d] := 'p’

Type Checking Ensure that the types of the operands are type-compatible with their operator. Example: You can only perform an integer division with the DIV operator and integer operands. Example: The relational operators AND and OR can only be used with boolean operands. Ensure that a value being assigned to a variable is assignment-compatible with the variable. Example: You cannot assign a string value to an integer variable.

Type Specifications and the Parse Tree Every Pascal expression has a data type. Add a type specification to every parse tree node. “Decorate” the parse tree with type information. wci/intermediate/IcodeNode.h virtual TypeSpec *get_typespec() const = 0; virtual void set_typespec(TypeSpec *spec) = 0; wci/intermediate/icodenodeimpl/IcodeNodeImpl.h private: TypeSpec *typespec; // data type specification public: TypeSpec *get_typespec() { ... } void set_typespec(TypeSpec *spec) { ... }

Class TypeChecker Static boolean methods for type checking: isInteger() areBothInteger() isReal() isIntegerOrReal() isAtLeastOneReal() isBoolean() areBothBoolean() isChar() areAssignmentCompatible() areComparisonCompatible() equalLengthStrings() wci/intermediate/typeimpl/TypeChecker.h

Class TypeChecker, cont'd wci/intermediate/typeimpl/TypeChecker.cpp bool TypeChecker::is_integer(TypeSpec *typespec) {     return    (typespec != nullptr)            && (typespec->base_type() == Predefined::integer_type); } bool TypeChecker::are_both_integer(TypeSpec *typespec1,                                    TypeSpec *typespec2)     return is_integer(typespec1) && is_integer(typespec2); ... bool TypeChecker::is_at_least_one_real(TypeSpec *typespec1, TypeSpec *typespec2)     return (is_real(typespec1) && is_real(typespec2)) ||            (is_real(typespec1) && is_integer(typespec2)) ||            (is_integer(typespec1) && is_real(typespec2));

Assignment and Comparison Compatible In classic Pascal, a value is assignment-compatible with a target variable if: both have the same type the target is real and the value is integer they are equal-length strings Two values are comparison-compatible (they can be compared with relational operators) if: one is integer and the other is real

Assignment Compatible bool TypeChecker::are_assignment_compatible(TypeSpec *target_typespec,                                             TypeSpec *value_typespec) {     if ((target_typespec == nullptr) || (value_typespec == nullptr))     {         return false;     }     target_typespec = target_typespec->base_type();     value_typespec  = value_typespec->base_type();     bool compatible = false;     if (target_typespec == value_typespec)         compatible = true;     else if (is_real(target_typespec) && is_integer(value_typespec))     else {         compatible =    target_typespec->is_pascal_string()                      && value_typespec->is_pascal_string();     return compatible; } Same type real := integer Both are strings wci/intermediate/typeimpl/TypeChecker.cpp

Type Checking Expressions The parser must perform type checking of every expression as part of its semantic actions. Add type checking to class ExpressionParser and to each statement parser. Flag type errors similarly to syntax errors.

Method ExpressionParser::parseTerm() Now besides doing syntax checking, our expression parser must also do type checking and determine the result type of each operation. case PT_STAR: {     if (TypeChecker::are_both_integer(result_typespec,                                       factor_typespec))     {         result_typespec = Predefined::integer_type;     }     else if (TypeChecker::is_at_least_one_real(result_typespec,                                                factor_typespec))         result_typespec = Predefined::real_type;     else         error_handler.flag(expr_token, INCOMPATIBLE_TYPES, this);     break; } integer * integer  integer result one integer and one real, or both real  real result wci/frontend/pascal/parsers/ExpressionParser.cpp

Type Checking Control Statements ICodeNode *IfStatementParser::parse_statement(Token *token) throw (string) {     token = next_token(token);  // consume the IF     ICodeNode *if_node =             ICodeFactory::create_icode_node((ICodeNodeType) NT_IF);     Token *expr_token = new Token(*token);     ExpressionParser expression_parser(this);     ICodeNode *expr_node = expression_parser.parse_statement(token);     if_node->add_child(expr_node);     TypeSpec *expr_typespec = expr_node != nullptr                                   ? expr_node->get_typespec()                                   : Predefined::undefined_type;     if (!TypeChecker::is_boolean(expr_typespec))     {         error_handler.flag(expr_token, INCOMPATIBLE_TYPES, this);     } ... } wci/frontend/pascal/parsers/IfStatementParser.cpp

ExpressionParser::parseFactor() Now an identifier can be more than just a variable name. ICodeNode *ExpressionParser::parse_factor(Token *token) throw (string) { ... switch ((PascalTokenType) tokenType) case IDENTIFIER: return parse_identifier(token); } wci/frontend/pascal/parsers/ExpressionParser.cpp

ExpressionParser.parseIdentifier() Constant identifier Previously defined in a CONST definition. Create an INTEGER_CONSTANT, REAL_CONSTANT, or a STRING_CONSTANT node. Set its VALUE attribute. Enumeration identifier Previously defined in a type specification. Create an INTEGER_CONSTANT node. CONST pi = 3.14159; TYPE direction = (north, south, east, west);

ExpressionParser.parseIdentifier() Variable identifier Call method variableParser::parse().

Syntax Diagram for Variables The outer loop back allows any number of subscripts and fields. A variable can have any combination of subscripts and fields. Appear in an expression or as the target of an assignment statement. Example: var9.rec.flda[b][0,'m'].flda[d] := 'p' The parser must do type checking for each subscript and field.

Parse Tree for Variables Assume that b and d are enumeration constants and that b =1 and d = 3 VARIABLE nodes can now have child nodes: SUBSCRIPTS FIELD

Class VariableParser Parse variables that appear in statements. Subclass of StatementParser. Do not confuse with class VariableDeclarationsParser. Subclass of DeclarationsParser. Parsing methods parse() parse_field() parse_subscripts()

VariableParser::parse() Parse the variable identifier (example: var9) Create the VARIABLE node.

VariableParser::parse() cont’d Loop to parse any subscripts and fields. Call methods parse_field() or parse_subscripts(). Variable variable_type keeps track of the current type specification. The current type changes as each field and subscript is parsed.

VariableParser::parse_field() Get the record type’s symbol table. Attribute RECORD_SYMTAB of the record variable’s type specification.

VariableParser::parse_field() cont’d Verify that the field identifier is in the record type’s symbol table. Create a FIELD node that is adopted by the VARIABLE node.

VariableParser::parse_subscripts() Create a SUBSCRIPTS node. Loop to parse a comma-separated list of subscript expressions. The SUBSCRIPTS node adopts each expression parse tree.

VariableParser::parse_subscripts() Verify that each subscript expression is assignment-compatible with the corresponding index type.

Demo Pascal Syntax Checker III Parse a Pascal block Type checking declarations statements with variables Type checking