Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 153: Concepts of Compiler Design September 30 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak www.cs.sjsu.edu/~mak.

Similar presentations


Presentation on theme: "CS 153: Concepts of Compiler Design September 30 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak www.cs.sjsu.edu/~mak."— Presentation transcript:

1 CS 153: Concepts of Compiler Design September 30 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak www.cs.sjsu.edu/~mak 1

2 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 2 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’

3 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 3 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.

4 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 4 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. In interface ICodeNode : public void setTypeSpec(TypeSpec typeSpec); public TypeSpec getTypeSpec(); In class ICodeNodeImpl : private TypeSpec typeSpec; // data type specification public void setTypeSpec(TypeSpec typeSpec) {... } public TypeSpec getTypeSpec() {... }

5 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 5 Class TypeChecker  Static boolean methods for type checking: isInteger() areBothInteger() isReal() isIntegerOrReal() isAtLeastOneReal() isBoolean() areBothBoolean() isChar() areAssignmentCompatible() areComparisonCompatible() equalLengthStrings() In package intermediate.typeimpl.

6 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 6 Class TypeChecker, cont'd public static boolean isInteger(TypeSpec type) { return (type != null) && (type.baseType() == Predefined.integerType); } public static boolean areBothInteger(TypeSpec type1, TypeSpec type2) { return isInteger(type1) && isInteger(type2); }... public static boolean isAtLeastOneReal(TypeSpec type1, TypeSpec type2) { return (isReal(type1) && isReal(type2)) || (isReal(type1) && isInteger(type2)) || (isInteger(type1) && isReal(type2)); }

7 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 7 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: both have the same type one is integer and the other is real they are equal-length strings

8 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 8 public static boolean areAssignmentCompatible(TypeSpec targetType, TypeSpec valueType) { if ((targetType == null) || (valueType == null)) return false; targetType = targetType.baseType(); valueType = valueType.baseType(); boolean compatible = false; if (targetType == valueType) { compatible = true; } else if (isReal(targetType) && isInteger(valueType)) { compatible = true; } else { compatible = equalLengthStrings(targetType, valueType); } return compatible; } Assignment Compatible Same type real := integer Equal length strings

9 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 9 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.

10 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 10 case STAR: { if (TypeChecker.areBothInteger(resultType, factorType)) { resultType = Predefined.integerType; } else if (TypeChecker.isAtLeastOneReal(resultType, factorType)) { resultType = Predefined.realType; } else { errorHandler.flag(token, INCOMPATIBLE_TYPES, this); } break; } Method ExpressionParser.parseTerm() integer * integer  integer result one integer and one real, or both real  real result  Now besides doing syntax checking, our expression parser must also do type checking and determine the result type of each operation.

11 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 11 Type Checking Control Statements  Method IfStatementParser.parse() public ICodeNode parse(Token token) throws Exception { token = nextToken(); // consume the IF ICodeNode ifNode = ICodeFactory.createICodeNode(ICodeNodeTypeImpl.IF); ExpressionParser expressionParser = new ExpressionParser(this); ICodeNode exprNode = expressionParser.parse(token); ifNode.addChild(exprNode); TypeSpec exprType = exprNode != null ? exprNode.getTypeSpec() : Predefined.undefinedType; if (!TypeChecker.isBoolean(exprType)) { errorHandler.flag(token, INCOMPATIBLE_TYPES, this); } token = synchronize(THEN_SET);... }

12 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 12 ExpressionParser.parseFactor()  Now an identifier can be more than just a variable name. private ICodeNode parseFactor(Token token) throws Exception {... switch ((PascalTokenType) tokenType) { case IDENTIFIER: { return parseIdentifier(token); }... }

13 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 13 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. Set its VALUE attribute. CONST pi = 3.14159; TYPE direction = (north, south, east, west);

14 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 14 ExpressionParser.parseIdentifier()  Variable identifier Call method variableParser.parse().

15 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 15 Syntax Diagram for Variables  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. The outer loop back allows any number of subscripts and fields.

16 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 16 Parse Tree for Variables  VARIABLE nodes can now have child nodes: SUBSCRIPTS FIELD Assume that b and d are enumeration constants and that b =1 and d = 3

17 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 17 Class VariableParser  Parse variables that appear in statements. Subclass of StatementParser. Do not confuse with class VariableDeclarationsParser.  Subclass of DeclarationsParser.  Parsing methods parse() parseField() parseSubscripts()

18 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 18 VariableParser.parse()  Parse the variable identifier (example: var9 )  Create the VARIABLE node.

19 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 19 VariableParser.parse() cont’d  Loop to parse any subscripts and fields. Call methods parseField() or parseSubscripts(). Variable variableType keeps track of the current type specification.  The current type changes as each field and subscript is parsed.

20 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 20 VariableParser.parseField()  Get the record type’s symbol table. Attribute RECORD_SYMTAB of the record variable’s type specification.

21 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 21 VariableParser.parseField() 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.

22 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 22 VariableParser.parseSubscripts()  Create a SUBSCRIPTS node.  Loop to parse a comma-separated list of subscript expressions. The SUBSCRIPTS node adopts each expression parse tree.

23 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 23 VariableParser.parseSubscripts()  Verify that each subscript expression is assignment-compatible with the corresponding index type.

24 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 24 Demo  Pascal Syntax Checker III Parse a Pascal block  declarations  statements with variables Type checking

25 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 25 Assignment #4  Set type definitions and set variable declarations.  Don’t wait until the last minute to start this one!  Do type checking. How do you do type checking for set expressions? What does it mean for two set operands to be type compatible? What does it mean for two sets to be assignment compatible?

26 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 26 Assignment #4  You should be able to parse file input.txt without errors.  Flag all the syntax and type checking errors possible in file errors.txt Your parser should not crash or go into an infinite loop!  Due Friday, October 16.

27 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 27 Pascal Program Header  The program parameters are optional. Identifiers of input and output file variables. Default files are standard input and standard output.  Examples: PROGRAM newton; PROGRAM hilbert(input, output, error);

28 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 28 Pascal Programs, Procedures, and Functions  Procedure and function declarations come last. Any number of procedures and functions, and in any order. A formal parameter list is optional.

29 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 29 Formal Parameter List  By default, parameters are passed by value. The actual parameter value in the call is copied and the formal parameter is assigned the copied value. The routine cannot change the actual parameter value.

30 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 30 Formal Parameter List, cont’d  VAR parameters are passed by reference. The formal parameter is assigned a reference to the actual parameter value. The routine can change the actual parameter value.

31 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 31 PROCEDURE proc (j, k : integer; VAR x, y, z : real; VAR v : arr; VAR p : boolean; ch : char); BEGIN... END; PROCEDURE SortWords; BEGIN... END; FUNCTION func (VAR x : real; i, n : integer) : real; BEGIN... func :=...;... END; Example Procedure and Function Declarations Value and VAR parameters. No parameters. Assign the function return value. Function return type.

32 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 32 Forward Declarations  In Pascal, you cannot have a statement that calls a procedure or a function before it has been declared.  To get around this restriction, use forward declarations. Example:  Instead of a block, you have forward. forward is not a reserved word. FUNCTION foo(m : integer; VAR t : real) : real; forward;

33 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 33 Forward Declarations, cont'd  When you finally have the full declaration of a forwarded procedure or function, you do not repeat the formal parameters or the function return type. FUNCTION foo(m : integer; VAR t : real) : real; forward; PROCEDURE proc; VAR x, y : real; BEGIN x := foo(12, y); END; FUNCTION foo; BEGIN... foo :=...;... END; Use the function before its full declaration. Now the full function declaration.

34 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 34 Records and the Symbol Table Stack

35 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 35 PROGRAM Test; VAR i, j, k, n : integer; PROCEDURE p(j : real); VAR k : char; FUNCTION f(x : real) : real; VAR i:real; BEGIN {f} f := i + j + n + x; END {f}; BEGIN {p} k := chr(i + trunc(f(n))); END {p}; BEGIN {test} p(j + k + n) END {test}. Nested Scopes and the Symbol Table Stack

36 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 36 PROGRAM Test; VAR i, j, k, n : integer; PROCEDURE p(j : real); VAR k : char; FUNCTION f(x : real) : real; VAR i:real; BEGIN {f} f := i + j + n + x; END {f}; BEGIN {p} k := chr(i + trunc(f(n))); END {p}; BEGIN {test} p(j + k + n) END {test}. Nested Scopes and the Symbol Table Stack

37 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 37 PROGRAM Test; VAR i, j, k, n : integer; PROCEDURE p(j : real); VAR k : char; FUNCTION f(x : real) : real; VAR i:real; BEGIN {f} f := i + j + n + x; END {f}; BEGIN {p} k := chr(i + trunc(f(n))); END {p}; BEGIN {test} p(j + k + n) END {test}. Nested Scopes and the Symbol Table Stack

38 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 38 PROGRAM Test; VAR i, j, k, n : integer; PROCEDURE p(j : real); VAR k : char; FUNCTION f(x : real) : real; VAR i:real; BEGIN {f} f := i + j + n + x; END {f}; BEGIN {p} k := chr(i + trunc(f(n))); END {p}; BEGIN {test} p(j + k + n) END {test}. Nested Scopes and the Symbol Table Stack

39 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 39 PROGRAM Test; VAR i, j, k, n : integer; PROCEDURE p(j : real); VAR k : char; FUNCTION f(x : real) : real; VAR i:real; BEGIN {f} f := i + j + n + x; END {f}; BEGIN {p} k := chr(i + trunc(f(n))); END {p}; BEGIN {test} p(j + k + n) END {test}. Nested Scopes and the Symbol Table Stack

40 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 40 PROGRAM Test; VAR i, j, k, n : integer; PROCEDURE p(j : real); VAR k : char; FUNCTION f(x : real) : real; VAR i:real; BEGIN {f} f := i + j + n + x; END {f}; BEGIN {p} k := chr(i + trunc(f(n))); END {p}; BEGIN {test} p(j + k + n) END {test}. Nested Scopes and the Symbol Table Stack

41 Computer Science Dept. Fall 2015: September 30 CS 153: Concepts of Compiler Design © R. Mak 41 PROGRAM Test; VAR i, j, k, n : integer; PROCEDURE p(j : real); VAR k : char; FUNCTION f(x : real) : real; VAR i:real; BEGIN {f} f := i + j + n + x; END {f}; BEGIN {p} k := chr(i + trunc(f(n))); END {p}; BEGIN {test} p(j + k + n) END {test}. Nested Scopes and the Symbol Table Stack


Download ppt "CS 153: Concepts of Compiler Design September 30 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak www.cs.sjsu.edu/~mak."

Similar presentations


Ads by Google