Compiler Construction I

Size: px

Start display at page:

Download "Compiler Construction I"

Jared Russell
6 years ago
Views:

1 TECHNISCHE UNIVERSITÄT MÜNCHEN FAKULTÄT FÜR INFORMATIK Compiler Construction I Dr. Michael Petter, Dr. Axel Simon SoSe / 30

2 Topic: Semantic Analysis 2 / 30

3 Semantic Analysis Chapter 1: Type Checking 3 / 30

4 Goal of Type Checking In most mainstream (imperative / object oriented / functional) programming languages, variables and functions have a fixed type. for example:, void*, struct { x; y; }. Types are useful to manage memory to avoid certain run-time errors In imperative and object-oriented programming languages a declaration has to specify a type. The compiler then checks for a type correct use of the declared entity. 4 / 30

5 Type Expressions Types are given using type-expressions. The set of type expressions T contains: 1 base types:, char, float, void,... 2 type constructors that can be applied to other types example for type constructors in C: records: struct { t 1 a 1 ;... t k a k ; } poer: t * arrays: t [] the size of an array can be specified the variable to be declared is written between t and [n] functions: t (t 1,..., t k ) the variable to be declared is written between t and (t 1,..., t k) in ML function types are written as: t 1... t k t 5 / 30

6 Type Definitions in C A type definition is a synonym for a type expression. In C they are roduced using the typedef keyword. Type definitions are useful as abbreviation: typedef struct { x; y; } po_t; to construct recursive types: Possible declaration in C: struct list { info; struct list* next; } struct list* head; more readable: typedef struct list list_t; struct list { info; list_t* next; } list_t* head; 6 / 30

7 Type Checking Problem: Given: a set of type declarations Γ = {t 1 x 1 ;... t m x m ; } Check: Can an expression e be given the type t? Example: struct list { info; struct list* next; }; f(struct list* l) { return 1; }; struct { struct list* c;}* b; * a[11]; Consider the expression: *a[f(b->c)]+2; 7 / 30

8 Type Checking using the Syntax Tree Check the expression *a[f(b->c)]+2: + 2 [ ] a ( ) f. c Idea: traverse the syntax tree bottom-up for each identifier, we lookup its type in Γ constants such as 2 or 0.5 have a fixed type b the types of the inner nodes of the tree are deduced using typing rules 8 / 30

9 Type Systems Formal consider judgements of the form: Γ e : t // (in the type environment Γ the expression e has type t) Axioms: Regeln: Const: Γ c : t c (t c type of constant c) Var: Γ x : Γ(x) (x Variable) Ref: Γ e : Γ & e : t t Deref: Γ e : t Γ e : t 9 / 30

10 Type Systems for C-like Languages More rules for typing an expression: Array: Array: Struct: App: Op: Cast: Γ e 1 : t Γ e 2 : Γ e 1 [e 2 ] : t Γ e 1 : t [ ] Γ e 2 : Γ e 1 [e 2 ] : t Γ e : struct {t 1 a 1 ;... t m a m ; } Γ e.a i : t i Γ e : t (t 1,..., t m ) Γ e 1 : t 1... Γ e m : t m Γ e(e 1,..., e m ) : t Γ e 1 : Γ e 2 : Γ e 1 + e 2 : Γ e : t 1 t 1 can be converted to t 2 Γ (t 2 ) e : t 2 10 / 30

11 Example: Type Checking Given expression *a[f(b->c)]+2 and Γ = { struct list { info; struct list* next; }; f(struct list* l); struct { struct list* c;}* b; * a[11]; }: + 2 [ ] a ( ) f. c b 11 / 30

12 Example: Type Checking Expression *a[f(b->c)]+2: + 2 [ ] [ ] a ( ) (struct list ) f. struct list struct {struct list c;} struct {struct list c;} b c 12 / 30

13 Equality of Types Summary type checking: Choosing which rule to apply at an AST node is determined by the type of the child nodes determining the rule requires a check for equality of types type equality in C: struct A {} and struct B {} are considered to be different the compiler could re-order the fields of A and B independently (not allowed in C) to extend an record A with more fields, it has to be embedded o another record: typedef struct B { struct A a; field_of_b; } extension_of_a; after issuing typedef C; the types C and are the same 13 / 30

14 Structural Type Equality Alternative erpretation of type equality (does not hold in C): semantically, two type t 1, t 2 can be considered as equal if the accept the same set of access paths. Example: struct list { info; struct list* next; } struct list1 { info; struct { info; struct list1* next; }* next; } Consider declarations struct list* l and struct list1* l. Both allow l->info l->next->info but the two declarations of l have unequal types in C. 14 / 30

15 Algorithm for Testing Structural Equality Idea: track a set of equivalence queries of type expressions if two types are syntactically equal, we stop and report success otherwise, reduce the equivalence query to a several equivalence queries on (hopefully) simpler type expressions Suppose that recursive types were roduces using type equalities of the form: A = t (we omit the Γ). Then define the following rules: 15 / 30

16 Rules for Well-Typedness t t s t A s t s t t A = s struct {s 1 a 1 ;... s m a m ; } struct {t 1 a 1 ;... t m a m ; } s 1 t 1 s m t m 16 / 30

17 Example: A = struct { info; A next; } B = struct { info; struct { info; B next; } next; } We ask, for instance, if the following equality holds: struct { info; A next; } = B We construct the following derivation tree: 17 / 30

18 Proof for the Example: A = struct { info; A next; } B = struct { info; struct { info; B next; } next; } struct{ info; A next; } B struct{ info; A next; } struct{ info;... next; } A... A struct{ info; B next; } struct{ info; A next; } struct{ info; B next; } A B A B struct{ info; A next; } B 18 / 30

19 Implementation We implement a function that implement the equivalence query for two types by applying the deduction rules: if no deduction rule applies, then the two types are not equal if the deduction rule for expanding a type definition applies, the function is called recursively with a potentially larger type during the construction of the proof tree, an equivalence query might occur several times in case an equivalence query appears a second time, the types are by definition equal Termination? the set D of all declared types is finite there are no more than D 2 different equivalence queries repeated queries for the same inputs are are automatically satisfied termination is ensured 19 / 30

20 Overloading and Coercion Some operators such as + are overloaded: + has several possible types for example: +(,), float +(float, float) but also float* +(float*, ), * +(, *) depending on the type, the operator + has a different implementation determining which implementation should be used is based on the arguments only Coercion: allow the application of + to and float. instead of defining + for all possible combinations of types, the arguments are automatically coerced this coercion may generate code (z.b. conversion from to float) coersion is usually done towards more general types i.e has type float (since float ) 20 / 30

21 Coercion of Integer-Types in C: Promotion C defines special conversion rules for egers: promotion unsigned char signed char unsigned short signed short unsigned... where a conversion has to happen via all ermediate types. subtle errors possible! Compute the character distribution of str: char* str = "..."; dist[256]; memset(dist, 0, sizeof(dist)); while (*str) { dist[(unsigned) *str]++; str++; }; Note: unsigned is shorthand for unsigned. 21 / 30

22 Subtypes on the arithmetic basic types char,, long, etc. there exists a rich subtype hierarchy here t 1 t 2, means that the values of type t 1 1 form a subset of the values of type t 2; 2 can be converted o a value of type t 2; 3 fulfill the requirements of type t 2. Example: assign smaller type (fewer values) to larger type t 1 x; t 2 y; y = x; extend the subtype relationship to more complex types 22 / 30

23 Example: Subtyping Observe: string extractinfo( struct { string info; } x) { return x.info; } we would like extractinfo to be applicable to all argument records that contain a field string info use deduction rules to describe when t 1 t 2 should hold the idea of subtyping on values is related to subtyping as implemented in object-oriented languages 23 / 30

24 Rules for Well-Typedness of Subtyping t t s t A t A = s s t s t struct {s j1 a j1 ;... s jm a jm ; } struct {t 1 a 1 ;... t k a k ; } s 1 t 1 s k t k struct { u, v} x; struct { u} y; y = x; 24 / 30

25 Rules and Examples for Subtyping s 0 (s 1,..., s m ) t 0 (t 1,..., t m ) s 0 t 0 t 1 s 1 t m s m Examples: Attention: For functions: struct { a; b; } struct {float a; } () float (float) (float) float () the return types are in normal subtype relationship for argument types, the subtype relation reverses 25 / 30

26 Co- and Contra Variance Definition Given two function types in subtype relation s 0 (s 1,... s n ) t 0 (t 1,... t n ) then we have co-variance of the return type s 0 t 0 and contra-variance of the arguments s i t i für 1 < i n Example from function languages: float float These rules can be applied directly to test for sub-type relationship of recursive types 26 / 30

27 Subtypes: Application of Rules (I) Check if S 1 R 1 : R 1 = struct { a; R 1 (R 1 ) f ; } S 1 = struct { a; b; S 1 (S 1 ) f ; } R 2 = struct { a; R 2 (S 2 ) f ; } S 2 = struct { a; b; S 2 (R 2 ) f ; } a S 1 R 1 f S 1 (S 1 ) R 1 (R 1 ) S 1 R 1 R 1 S 1 27 / 30

28 Subtypes: Application of Rules (II) Check if S 2 S 1 : R 1 = struct { a; R 1 (R 1 ) f ; } S 1 = struct { a; b; S 1 (S 1 ) f ; } R 2 = struct { a; R 2 (S 2 ) f ; } S 2 = struct { a; b; S 2 (R 2 ) f ; } S 2 S 1 a, b f S 2 (R 2 ) S 1 (S 1 ) S 2 S 1 a S 1 R 2 f S 1 (S 1 ) R 2 (S 2 ) S 1 R 2 S 2 S 1 28 / 30

29 Subtypes: Application of Rules (III) Check if S 2 R 1 : R 1 = struct { a; R 1 (R 1 ) f ; } S 1 = struct { a; b; S 1 (S 1 ) f ; } R 2 = struct { a; R 2 (S 2 ) f ; } S 2 = struct { a; b; S 2 (R 2 ) f ; } a S 2 R 1 f S 2 (R 2 ) R 1 (R 1 ) S 2 R 1 a R 1 R 2 f R 1 (R 1 ) R 2 (S 2 ) R 1 R 2 S 2 R 1 29 / 30

30 Discussion for presentational purposes, proof trees are often abbreviated by omitting deductions within the tree structural sub-types are very powerful and can be quite ricate to understand Java generalizes records to objects/classes where a sub-class A inheriting form base class O is a subtype A O subtype relations between classes must be explicitly declared inheritance ensures that all sub-classes contain all (visible) components of the super class a shadowed (overwritten) component in A must have a subtype of the the component in O Java does not allow argument subtyping for methods since it uses different signatures for overloading 30 / 30

Data Types. Every program uses data, either explicitly or implicitly to arrive at a result.

Data Types. Every program uses data, either explicitly or implicitly to arrive at a result. Every program uses data, either explicitly or implicitly to arrive at a result. Data in a program is collected into data structures, and is manipulated by algorithms. Algorithms + Data Structures = Programs