Lecture Outline

• COOL operational semantics

Operational Semantics of Cool
• Motivation

Lecture 13 • Notation

• The rules

Prof. Aiken CS 143 Lecture 13 1 Prof. Aiken CS 143 Lecture 13 2

Motivation Evaluation Rules So Far

• We must specify for every Cool expression • We have specified evaluation rules indirectly
what happens when it is evaluated – The compilation of Cool to a stack machine
– This is the “meaning” of an expression – The evaluation rules of the stack machine

• The definition of a programming language: • This is a complete description

– The tokens  lexical analysis – Why isn’t it good enough?
– The grammar  syntactic analysis
– The typing rules  semantic analysis
– The evaluation rules
 code generation and optimization
Prof. Aiken CS 143 Lecture 13 3 Prof. Aiken CS 143 Lecture 13 4

Assembly Language Description of Semantics Programming Language Semantics

• Assembly-language descriptions of language • A multitude of ways to specify semantics

implementation have irrelevant detail – All equally powerful
– Whether to use a stack machine or not – Some more suitable to various tasks than others
– Which way the stack grows
– How integers are represented • Operational semantics
– The particular instruction set of the architecture – Describes program evaluation via execution rules
• on an abstract machine
• We need a complete description – Most useful for specifying implementations
– But not an overly restrictive specification – This is what we use for Cool

Prof. Aiken CS 143 Lecture 13 5 Prof. Aiken CS 143 Lecture 13 6

1
Other Kinds of Semantics Introduction to Operational Semantics

• Denotational semantics
– Program’s meaning is a mathematical function • Once again we introduce a formal notation
– Elegant, but introduces complications
• Need to define a suitable space of functions
• Logical rules of inference, as in type checking
• Axiomatic semantics
– Program behavior described via logical formulae
• If execution begins in state satisfying X, then it ends in
state satisfying Y
• X, Y formulas
– Foundation of many program verification systems

Prof. Aiken CS 143 Lecture 13 7 Prof. Aiken CS 143 Lecture 13 8

Inference Rules Example Operational Semantics Rule

• Recall the typing judgment • Example:

Context  e1 : 5
Context  e : C Context  e2 : 7
(in the given context, expression e has type C) Context  e1 + e2 : 12

• The result of evaluating an expression can

depend on the result of evaluating its
• We try something similar for evaluation
subexpressions
Context  e : v
(in the given context, expression e evaluates to • The rules specify everything that is needed to
value v) evaluate an expression

Prof. Aiken CS 143 Lecture 13 9 Prof. Aiken CS 143 Lecture 13 10

Contexts are Needed for Variables Variable Environments

• Consider the evaluation of y  x + 1 • A variable environment is a map from variable

– We need to keep track of values of variables names to locations
– We need to allow variables to change their values – Tells in what memory location the value of a
during evaluation variable is stored
– Keeps track of which variables are in scope
• We track variables and their values with:
– An environment : tells us where in memory a • Example:
variable is stored E = [a : l1, b : l2]
– A store : tells us what is in memory
• E(a) looks up variable a in environment E

Prof. Aiken CS 143 Lecture 13 11 Prof. Aiken CS 143 Lecture 13 12

2
Stores Cool Values

• A store maps memory locations to values • Cool values are objects

• Example: – All objects are instances of some class
S = [l1  5, l2  7]
• X(a1 = l1, …, an = ln) is a Cool object where
– X is the class of the object
• S(l1) is the contents of a location l1 in store S
– ai are the attributes (including inherited ones)
– li is the location where the value of ai is stored
• S’ = S[12/l1] defines a store S’ such that
S’(l1) = 12 and S’(l) = S(l) if l  l1

Prof. Aiken CS 143 Lecture 13 13 Prof. Aiken CS 143 Lecture 13 14

Cool Values (Cont.) Operational Rules of Cool

• Special cases (classes without attributes) • The evaluation judgment is

Int(5) the integer 5 so, E, S  e : v, S’
Bool(true) the boolean true read:
String(4, “Cool”) the string “Cool” of length 4 – Given so the current value of self
– And E the current variable environment
• There is a special value void of type Object – And S the current store
– No operations can be performed on it – If the evaluation of e terminates then
– Except for the test isvoid – The return value is v
– Concrete implementations might use NULL here – And the new store is S’

Prof. Aiken CS 143 Lecture 13 15 Prof. Aiken CS 143 Lecture 13 16

Notes Operational Semantics for Base Values

• “Result” of evaluation is a value and a store

– New store models the side-effects so, E, S  true : Bool(true), S so, E, S  false : Bool(false), S

s is a string literal
• Some things don’t change i is an integer literal n is the length of s
– The variable environment so, E, S  i : Int(i), S so, E, S  s : String(n,s), S
– The value of self
– The operational semantics allows for non- • No side effects in these cases
terminating evaluations (the store does not change)

Prof. Aiken CS 143 Lecture 13 17 Prof. Aiken CS 143 Lecture 13 18

3
Operational Semantics of Variable References Operational Semantics for Self

E(id) = lid
S(lid) = v
so, E, S  id : v, S • A special case:

so, E, S  self : so, S

• Note the double lookup of variables
– First from name to location
– Then from location to value

• The store does not change

Prof. Aiken CS 143 Lecture 13 19 Prof. Aiken CS 143 Lecture 13 20

Operational Semantics of Assignment Operational Semantics of Conditionals

so, E, S  e : v, S1 so, E, S  e1 : Bool(true), S1

E(id) = lid so, E, S1 e2 : v, S2
S2 = S1[v/l id]
so, E, S  if e1 then e2 else e3 : v, S2
so, E, S  id  e : v, S2
• The “threading” of the store enforces an
evaluation sequence
• Three step process – e1 must be evaluated first to produce S1
– Evaluate the right hand side – Then e2 can be evaluated
 a value v and new store S1
– Fetch the location of the assigned variable
– The result is the value v and an updated store
• The result of evaluating e1 is a Bool. Why?
Prof. Aiken CS 143 Lecture 13 21 Prof. Aiken CS 143 Lecture 13 22

Operational Semantics of Sequences Operational Semantics of while (I)

so, E, S  e1 : v1, S1 so, E, S  e1 : Bool(false), S1

so, E, S1  e2 : v2, S2 so, E, S  while e1 loop e2 pool : void, S1
…
so, E, Sn-1  en : vn , Sn
so, E, S  { e1; …; en; } : vn, Sn • If e1 evaluates to false the loop terminates
– With the side-effects from the evaluation of e1
• Again the threading of the store expresses
– And with result value void
the intended evaluation sequence
• Only the last value is used
• Type checking ensures e1 evaluates to a Bool
• But all the side-effects are collected
Prof. Aiken CS 143 Lecture 13 23 Prof. Aiken CS 143 Lecture 13 24

4
Operational Semantics of while (II) Operational Semantics of let Expressions (I)

so, E, S  e1 : Bool(true), S1 so, E, S  e1 : v1, S1

so, E, S1 e2 : v, S2 so, ?, ? e2 : v, S2
so, E, S2  while e1 loop e2 pool : void, S3 so, E, S  let id : T  e1 in e2 : v2, S2
so, E, S  while e1 loop e2 pool : void, S3
• Note the sequencing (S  S1  S2  S3)
• In what context should e2 be evaluated?
• Note how looping is expressed
– Environment like E but with a new binding of id to a
– Evaluation of “while …” is expressed in terms of the fresh location lnew
evaluation of itself in another state
– Store like S1 but with lnew mapped to v1
• The result of evaluating e2 is discarded
– Only the side-effect is preserved
Prof. Aiken CS 143 Lecture 13 25 Prof. Aiken CS 143 Lecture 13 26

Operational Semantics of let Expressions (II) Operational Semantics of new

• We write lnew = newloc(S) to say that lnew is a • Informal semantics of new T

location not already used in S – Allocate locations to hold all attributes of an
– newloc is like the memory allocation function object of class T
• Essentially, allocate a new object
– Initialize attributes with their default values
• The operational rule for let:
– Evaluate the initializers and set the resulting
so, E, S  e1 : v1, S1 attribute values
lnew = newloc(S1) – Return the newly allocated object
so, E[lnew/id] , S1[v1/l new]  e2 : v2, S2
so, E, S  let id : T  e1 in e2 : v2, S2

Prof. Aiken CS 143 Lecture 13 27 Prof. Aiken CS 143 Lecture 13 28

Default Values More Notation

• For each class A there is a default value • For a class A we write

denoted by DA class(A) = (a1 : T1  e1, …, an : Tn  en) where
– Dint = Int(0) – ai are the attributes (including the inherited ones)
– Dbool = Bool(false) – Ti are their declared types
– Dstring = String(0, “”) – ei are the initializers
– DA = void (for any other class A)

Prof. Aiken CS 143 Lecture 13 29 Prof. Aiken CS 143 Lecture 13 30

5
Operational Semantics of new Notes on Operational Semantics of new.

• new SELF_TYPE allocates an object with the • The first three steps allocate the object
same dynamic type as self
• The remaining steps initialize it
T0 = if (T == SELF_TYPE and so = X(…)) then X else T
class(T0) = (a1 : T1  e1,…, an : Tn  en) – By evaluating a sequence of assignments
li = newloc(S) for i = 1,…,n
v = T0(a1= l1,…,an= ln)
S1 = S[DT1/l 1,…,DTn/ln] • State in which the initializers are evaluated
E’ = [a1 : l1, …, an : ln] – Self is the current object
v, E’, S1  { a1  e1; …; an  en; } : vn, S2
– Only the attributes are in scope (same as in typing)
so, E, S  new T : v, S2 – Initial values of attributes are the defaults

Prof. Aiken CS 143 Lecture 13 31 Prof. Aiken CS 143 Lecture 13 32

Operational Semantics of Method Dispatch More Notation

• Informal semantics of e0.f(e1,…,en) • For a class A and a method f of A (possibly

– Evaluate the arguments in order e1,…,en inherited) we write:
– Evaluate e0 to the target object
– Let X be the dynamic type of the target object impl(A, f) = (x1, …, xn, ebody) where
– Fetch from X the definition of f (with n args.) – xi are the names of the formal arguments
– Create n new locations and an environment that – ebody is the body of the method
maps f’s formal arguments to those locations
– Initialize the locations with the actual arguments
– Set self to the target object and evaluate f’s body

Prof. Aiken CS 143 Lecture 13 33 Prof. Aiken CS 143 Lecture 13 34

Operational Semantics of Dispatch Notes on Operational Semantics of Dispatch

so, E, S  e1 : v1 , S1 • The body of the method is invoked with

so, E, S1  e2 : v2 , S2
– E mapping formal arguments and self’s attributes
…
so, E, Sn-1  en : vn , Sn
– S like the caller’s except with actual arguments
bound to the locations allocated for formals
so, E, Sn  e0 : v0, Sn+1
v0 = X(a1 = l 1,…, am = lm)
impl(X, f) = (x1,…, xn, ebody) • The notion of the frame is implicit
lxi = newloc(Sn+1) for i = 1,…,n
E’ = [a1 : l1,…,am : lm][x1/l x1, …, xn/l xn] – New locations are allocated for actual arguments
Sn+2 = Sn+1[v1/l x1,…,vn/lxn]
v0 , E’, Sn+2  ebody : v, Sn+3
• The semantics of static dispatch is similar
so, E, S  e0.f(e1,…,en) : v, Sn+3

Prof. Aiken CS 143 Lecture 13 35 Prof. Aiken CS 143 Lecture 13 36

6
Runtime Errors Runtime Errors (Cont.)

Operational rules do not cover all cases • There are some runtime errors that the type
Consider the dispatch example: checker does not prevent
… – A dispatch on void
so, E, Sn  e0 : v0,Sn+1
– Division by zero
v0 = X(a1 = l 1,…, am = lm)
impl(X, f) = (x1,…, xn, ebody) – Substring out of range
… – Heap overflow
so, E, S  e0.f(e1,…,en) : v, Sn+3

What happens if impl(X, f) is not defined? • In such cases execution must abort gracefully
Cannot happen in a well-typed program – With an error message, not with segfault

Prof. Aiken CS 143 Lecture 13 37 Prof. Aiken CS 143 Lecture 13 38

Conclusions

• Operational rules are very precise & detailed

– Nothing is left unspecified
– Read them carefully

• Most languages do not have a well specified

operational semantics

• When portability is important an operational

semantics becomes essential
Prof. Aiken CS 143 Lecture 13 39