410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

18
410/510 1 of 18 Week 5 – Lecture 1 • Semantic Analysis Compiler Construction

Transcript of 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

Page 1: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 1 of 18

Week 5 – Lecture 1

• Semantic Analysis

Compiler Construction

Page 2: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 2 of 18

Semantic Analysis

– Type checking– Flow checking

• Break– ‘leave the enclosing (for, while, switch) block’– Can’t break out of any arbitrary construct

– Uniqueness checks• Labels in case/switch statements

– Some of these can be done during parsing– Type checking is the dominant one of these– We can distinguish between:

• Static checking– performed by the compiler

• Dynamic checking– performed during execution

Page 3: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 3 of 18

General Properties of Semantic Analysis

• Varies with language semantics• Specific solutions for different languages• No ‘semantic analyzer generator’ tools

– There is no Flex or Bison equivalent in general use

• Specific implementations• Mainly different traversals of a syntax tree• Goals:

– Generate error messages– Prevent run-time errors cause by type incompatibility– Gather type information needed for code generation

Page 4: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 4 of 18

Type Systems

• Types are a central part of modern programming languages– Prevent errors, simplify run-time checking– Do more work in the compiler and less in source/execution

• Usually ‘basic’ or primitive ‘types’:– int, real, boolean, atom

• User-defined types– Basic (including enumerated types) or – Constructed (arrays of integers)

Page 5: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 5 of 18

Type Expressions

• All types in programming languages are either basic types or are derived from basic types using– Type constructors

• Type constructors include:– Arrays

• A: array[10] of char;• A is a new type expression arrays of arrays of …

– Records (struct)– Pointers– Functions– Class

• Language definition must list:– Basic types + type constructors

Page 6: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 6 of 18

Type Operations

• Notation:– Function f(a,b: int): real

• Domain Range• int int real• Domain type: int int • Range type: real

Page 7: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 7 of 18

Type Operations

• Type System– Rules for assigning type expressions to the various parts of a program– Can be specified using attribute grammars

• Type Inference– Determining the type of an item from information about its contents, structure, context etc

• Type Checking– Using type information to ensure parts of the program make sense under the type rules

of the language

Page 8: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 8 of 18

Type Equivalence

• In our(510s) semantic analyzer a nice function to have available would be:– Function typeEqual(type1, type2: TypeExp): Boolean– TypeExp TypeExp Boolean

• For basic types this is easy• For constructed types there are different options:

– Structural equivalence– Name equivalence– Declaration equivalence

Page 9: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 9 of 18

Structural Type Equivalence

• Still some different choices:– Arrays: force size equivalence– Records: relax order equivalence

record

Var(x) Var(y)

int real

recordx: int;y: real;

end

2 variables are of the same type if the syntax treesrepresenting them are of exactly the same structure

- algorithm on pg 354

Page 10: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 10 of 18

Name Equivalence

• Introduce type name for type expressions• Two type expressions are equivalent only if

– Same basic type, or– Same type name

• Strong name equivalence:– Type1 = int– Type 2 = int– Type1 Type2

• Retain structural equivalence (option):– var1: array[10] of int;– var2: array[10] of int;– var1 = var2 ?

• Compare type expressions not just names• getTypeExp(typeName) operation on the symbol table

Page 11: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 11 of 18

Declaration Equivalence

• type1 = type2– Establishes an alias (rather than a new type)

• type 1 = int• type 2 = int

– type1 is equal to type2 under declaration equivalence

• type3 = array[10] of char;• type4 = array[10] of char;• type5 = type3

– type3 and type5 are equivalent (using aliases)

– Neither type3 or type5 are equivalent to type4• Unless we add structural equivalence

Page 12: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 12 of 18

A type checker

P -> D ; ED -> D ; D | Type Var-listType -> int | float | ^Type | array[num] of TypeVar-list -> id, Var-list | idE -> literal_char | num | id | E mod E | E [E] | E^

int key;Key mod 1999;

^integer key;key^ mod 1999

Page 13: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 13 of 18

Attribute Grammars

• Attributes are properties of language constructs, e.g.:– Types

– Expression values

• Where the semantics closely follow the syntax then we can associate attributes with language symbols– X is a grammar symbol

– a is an attribute

– X.a is the value of the attribute

Grammar Rule Semantic Rule

E E + E { Attribute calculations }

Page 14: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 14 of 18

Attributes

• val is the attribute• + difference

– token, meaning

• Semantic Rule is an– Attribute equation

Grammar Rule Semantic Rule

E E + EE E1 + E2

{ E.val = E1.val + E2.val }

E

Exp1 Exp2

val = 2 val = 5

val = 7

Page 15: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 15 of 18

Type Attributes

• P and D decl don’t have an attribute– Attributes don’t have to be specified for all symbols

Grammar Rule Semantic Rule

P D ; ED D ; DD Type Var-list Var-list.dtype = type.dtypeType char Type.dtype = charType int Type.dtype = intType ^T1 Type.dtype = pointer(T1.type)Type array[num] of Type1 Type.dtype = array(num.val,

T1.type)Var-list1 id, Var-list2 id.dtype = dvar-list1.dtype

Var-list2 = dvar-list1.dtypeVar-list id id.type = dvar-list.dtype

Page 16: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 16 of 18

Type Checking Expressions

Grammar Rule Semantic Rule

E literal_char {E.type = char}E num {E.type = int}E id {E.type = lookup(id.entry)}

E E1 mod E2 {E.type = if E1.type == int andE2.type == int then int

else type_error}E E1 [E2] {E.type = if E2.type == int and

E1.type == array(s, t) then t else type_error}E E1 ^ {E.type = if E1.type == pointer(t) then t

else type_error

Page 17: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 17 of 18

A type checker

P -> D ; SD -> D ; D | Type Var-listS -> id = E S -> if E then SS -> while E do SS -> S ; S Type -> int | float | ^Type | array[num] of TypeE -> literal | num | id | E mod E | E [E] | E^

Int key;key = key mod 1999

^int key;key^ = key^ mod 1999

Page 18: 410/510 1 of 18 Week 5 – Lecture 1 Semantic Analysis Compiler Construction.

410/510 18 of 18

Type Checking Statements

Grammar Rule Semantic Rule

S id = E {S.type = if id.type == E.type then void

else type_error}

S if E then S1 {S.type = if E.type == boolean then S1.type

else type_error}

S while E do S1 {S.type = if E.type == boolean then S1.type

else type_error

S S1 ; S2 {S.type = if S1.type == void and

S2.type == void then void

else type_error}