Lecture

1
Lecture 7, April 24, 2007

• More about IR1
• Library Functions
• Canonicalization
• OO runtime issues
• Object size
• initialization

2
Assignments

• Project 1 due Wednesday, May 3, 2007
• Recall Midterm Exam on Tuesday May 1, 2007. In
  class, 1.5 hours, two days before Project 1 is
  due.

3
IR1 simplifications

• As we move into the backend of the compiler we
  are making some simplifications.
• We have only integer and Boolean values (no more
  floating point values)
• All values require 32 bits to store (including
  booleans)
• Values and pointers (addresses) take up the same
  amount of space (32 bits).
• Every value takes up exactly wdSize bytes (where
  wdSize 4)

4
Semantics of Exp

• datatype EXP
• BINOP of ProgramTypes.BINOP EXP EXP
• RELOP of ProgramTypes.RELOP EXP EXP
• CALL of EXP EXP list
• MEM of EXP
• NAME of string ( method names
  )
• TEMP of int ( registers
  )
• PARAM of int ( method parameters
  )
• MEMBER of EXP int ( instance variables
  )
• VAR of int ( local vars of methods
  )
• CONST of string
• STRING of string
• ESEQ of STMT list EXP
• Expressions represent values, But some values
  (mostly new array and new object) require actions
  to complete. ESEQ allows us to embed actions in
  expressions.
• We will discuss some of the highlights next.

5
BINOP and RELOP

• These are straightforward translations of their
  ProgramTypes.sml counter parts.
• Binops translate directly.
• Relop LT, GT etc, translate as if their were GT
  etc. operators just like ADD, TIMES etc.
• Binops AND and OR generally appear in the tests
  of the statements While and If. We use short
  circuit translations to translate these.
• If And or OR appears in an expression (rather
  than a statement) we can still use shortcircuit
  evaluation by using the ESEQ expression, using a
  local temp and generating statements (inside the
  ESEQ) to move either true or false into the local
  temp. (this is already done in the template code
  handed out).

6
Library functions.

• Several missing operations can be translated into
  library functions.
• A library function is a function supplied by the
  runtime environment. Possible library functions
  include, Boolean negation, and unary minus,
  malloc, coerce, etc.
• A library function translates to a call.
• CALL (NAME unary_minus) VAR 1
• CALL (NAME negate) VAR 3
• We use the NAME expression to name library
  functions as well as the functions we generate to
  implement methods.
• We will develop other library functions as we go
  along.

7
MEM

• MEM has no direct counter-part in
  ProgramTypes.sml
• Its meaning is to fetch the contents of a memory
  location.
• Its value is the value of that memory location.
• It is always a 32 bit value.
• Several other expression constructors have as
  their value memory locations. These constructors
  are appropriate arguments to MEM.
• They include TEMP, PARAM, MEMBER, and VAR

8
Addresses

• Variables, methods, members, and parameters all
  have there values stored in memory locations.
• Most of these addresses are fixed offsets from
  some known address. I.e. the current object
  pointer or the activation record pointer.
• The runtime system will define these known
  addresses.

9
(PARAM n)

• This means the address of the nth parameter.
• There will be some fixed location for parameters
• We will need to add the correct offset for the
  nth parameter to this address.
• Under the assumption that all values take up
  wdSize bytes, the offset n wdSize , but we
  leave this abstract at this stage.

10
(Var n)

• This means the address of the nth local variable
  of the current method.
• There will be some fixed location for local
  variables.
• We will need to add the correct offset for the
  nth local to this address.
• Under the assumption that all values take up
  wdSize bytes, the offset n wdSize , but we
  again leave this abstract at this stage.

11
(MEMBER(X,n))

• This means the value of the nth member (instance
  variable) of the object stored at address X
• We will need to add the correct offset for the
  nth local to this address.
• Note that X is itself an address.
• MEMBER(x,n) MEM(x wdSize n)
• under the assumption that all instance variables
  take up wdSize bytes.

12
this.x

• Recall that instance variables without an object
  prefix, are really this.x
• What is the address of this?
• This refers to the current object. The object
  which includes the method being executed.
• x.f(1,3)
• The object of a method call is an implicit
  parameter 0th
• parameter.

13
Printing

• Printing is handled library functions.
• We will need 1 library function for each kind of
  object we can print.
• In general wed need a Basic type tag in the
  ProgramTypes PrintE constructor to support this.
• Lets assume we print only Integer values. Then we
  need only two library functions.
• One for printing literal strings (PrintT) called
  (NAME prStr) , and one for (PrintE) called
  (NAME prInt)

14
Translating Methods

• Each method is translated into a Func
• To translate you need to
• Create a proper name. Classname_methodname
• You may need to track the current class so the
  classname is available
• Translate the methods variable declarations into
  a (possibly empty) STMT list
• Translate the methods body into a STMT list
• Merge the two STMT list. Put the variable one
  first.
• As you do this you will need to prepare the
  correct environment that tracks the Vkind of
  variables.
• Return a FUNC object. Be sure and get the
  (ProgramTypes.Type list) right in the Func node
  as these will needed in the second phase.

15
Translating Methods

• fun pass1M className env (MetDecl(loc,rng,name,par
  ams,vars,body))
• let fun paramTypes (Formal(typ,nm)) typ
• fun paramEnv count
• paramEnv count ((Formal(typ,nm))xs)
  
• (nm,Vparam count)(paramEnv
  (count1) xs)
• fun varTypes (VarDecl(loc,typ,nm,init))
  typ
• fun varEnv count
• varEnv count ((VarDecl(loc,typ,nm,init))
  xs)
• (nm,Vlocal count)(varEnv (count1)
  xs)
• val initEnv (paramEnv 1 params) _at_ env
• fun initIR count
• initIR count (VarDecl(loc,typ,nm,SOME
  init) vs)
• (MOVE(VAR count,pass1E initEnv
  init))
• initIR (count1) vs
• initIR count (VarDecl(loc,typ,nm,NONE)
  xs)
• initIR (count1) xs
• val varIR initIR 1 vars
• val bodyEnv (varEnv 1 vars) _at_ initEnv
• val bodyIR pass1S bodyEnv (Block body)

16
Canonicalization

• Usually we like to think of expressions as being
  side effect free.
• Because of ESEQ, this is clearly not true.
• We need to evaluate expressions in a canonical
  order in order to make sure we always get effects
  in the same order.
• Consider x.f(new person, new int 3)
• Both arguments translate to side effecting code.
  Which effects should happen first. Maybe in this
  case it doesnt matter, but we should have a
  fixed evaluation order.

17

• Consider f(g(5),7)
• Translation into X86 may require the use of
  specific registers.
• When calls are nested inside calls, if were not
  carefull the register usage can get mixed up.

18
General fix part 1

• Always use a new temporary register to name the
  value of a method call.
• Load this value immediately after the method
  returns.
• Use only this new register name in subsequent
  code.
• CALL(NAME f,CONST 1)
• ESEQ(MOVE (TEMP 100
• ,CALL(NAME f,CONST 1)
• )
• ,TEMP 100)

19
General fix part 2

• Translate every expression into a pair
• The first part of the pair is the statements in
  the expression, the second part of the pair is a
  pure expression (with no embedded ESEQ)
• 2 f (1) g(3)
• 2
• ESEQ(temp100 f(1),temp100)
• ESEQ(temp101 g(3),temp101)
• ( temp100 f(1), temp101 g(3) ,
  2temp100temp101)

20
Canonicalization of Statements

• Since statements can have expressions we need to
  canonicalize statements as well.
• MOVE(f(3), g(5))
• t1 f(3), t2 g(5), MOVE(t1,t2)
• The general case is to translate any statement
  into a list of statements. Statements lifted out
  of embedded expressions are incorporated into the
  resulting list of ststements.

21
ML code

• fun canonicalE x
• case x of
• BINOP(m,a,b) gt
• let val (sa,ea) canonicalE a
• val (sb,eb) canonicalE b
• in (sa_at_sb,BINOP(m,ea,eb)) end
• CALL(f,xs) gt
• let val temp newTemp()
• val (sf,ef) canonicalE f
• val (xsStmt,xsL) canonicalL xs
• in (sf _at_ xsStmt _at_
• MOVE(temp,CALL(ef,xsL)) ,temp)
• end

see next slide for canonicalL
22
canonicalL

• How do we canonicalize a list of expressions?
• and canonicalL (,)
• canonicalL (x xs)
• let val (xStmt,xL) canonicalE x
• val (xsStmt,xsL) canonicalL xs
• in (xStmt _at_ xsStmt, xL xsL) end

23
Statements

• and canonicalS x
• case x of
• MOVE(a,b) gt
• let val (sa,ea) canonicalE a
• val (sb,eb) canonicalE b
• in sa _at_ sb _at_ MOVE(ea,eb) end
• STMTlist xs gt
• List.concat (map canonicalS xs)

List.concat has type (a list) list -gt a list
24
Fair Warning

• Project 2, to be assigned on May 3rd, includes,
  in part, the completion of cannonicalization.
• It will also include the finalization of offsets
• And it will include some simple optimization.

25
Run-time issues

• So far, in IR1, we have glossed over all the
  important run-time issues of an OO language.
• thanks to Jenke Li for these notes
• Classes and objects
• storage allocation
• static class variables
• dynamic class variables
• Method Invocations
• static methods
• static binding methods
• dynamic binding methods
• mini Javas method invocation
• Others
• local variables and parameters
• non-local (class) variables
• Activation record size
• this pointer

26
Storage for Class objects

• Observations
• Static class variables are established per class.
  They should be allocated once in a single static
  place
• Dynamic class variables are cloned once for every
  new object. They are allocated space inside the
  object.
• General Strategies
• A class descriptor for each class
• pointer to parent class
• pointers to (local) methods
• storage for static variables
• An object record for each class
• pointer to class descriptor
• storage for local class (dynamic) variables
• storage for inherited variables.

27
Object Record Layout

• Objects contain space not only for variables that
  belong to the this class, but also for all
  ancestor classes.
• How should we layout variables so that the offset
  of all of them can be determined statically by
  the compiler?
• For single inheritance, we can use the prefixing
  method.

28
Prefix Method

• When a class B extends a class A
• those variables of B that are inherited from A
  are laid out in a record implementing B, in the
  same order they appear in the record implementing
  A.
• The compiler can assign a fixed offset for every
  variable in the object record.
• The offset will be the same for a class and for
  all its subclasses.
• Compiled methods can access variables by their
  offset, and not their name.

29
An Example

• class A int i1, j2
• class B extends A int m 3, n 4
• class C extends A int k 5
• class D extends C int l 6
• class Test
• A a new A
• B b new B
• C c new C
• D d newd D
• As rec Bs rec Cs rec Ds record
• i i i i
• j j j j
• m k k
• n l

30
Deciding Object size

• To decide an objects size
• inherited class information must be known
• class A int i1, j2 2wdSize
• class B extends A int m 3, n 4 As size
  2wdSize
• class C extends A int k 5 As size
  1wdSize
• class D extends C int l 6 Cs size
  1wdSize
• class Test
• A a new A // allocate 2wdSize
• B a new B // allocate 4wdSize
• C c new C // allocate 3wdSize
• D d new D // allocate 4wdSize

31
What if class declarations appear out of order?

• class D extends C int l 6
• class C extends A int k 5
• class A int i1, j2
• class B extends A int m 3, n 4
• Solution
• Perform a topological sort on class decls based
  upon inheritance relationship, then collect the
  size information.

32
Deciding Class Variable Offsets

• Once object sizes are known (computed), variable
  offsets can be computed easily.
• Rule.
• The offset of a subclasss first instance
  variable is the parent classes object size.
• Example
• class A int i1 // 0
• , j2 // 1 wdSize
• class B extends A int m 3 // 2wdSize
• , n 4 // 3wdSize
• class C extends A int k 5 // 2wdSize
• class D extends C int l 6 // 3wdSize

33
Class Variable Initialization

• Class variable must always be initialized
• either by the compiler
• or the user
• Initialization happens at object creation time
• User-provided initialization code is in the class
  declaration.
• Solution Collect initialization info while
  processing class decls. Propogate the
  initialization expression downwards. Use this
  info when generating new expression code.

34
Example

• class A int i1 // 0
  1
• , j2 // 1 wdSize
  2
• class B extends A int m3 // 2wdSize
  3
• , n 4 // 3wdSize
  4
• class C extends A int k 5 // 2wdSize
  5
• class D extends C int l 6 // 3wdSize
  6

35
new A New Objects

• Object size
• Variable Offsets
• Variable initialization
• canonicalize the initialization statements
  (stored in symbol table) to get a list of
  statements and expressions. (initS,initExps)
• ESEQ(
• initS _at_
• t1 vars wdsize
• ,t2 malloc(t1)
• ,t3 0
• ,t2t3 (get 0 initExps)
• ,t3 t3 wdSize
• ,t2t3 (get 1 initExps)
• . . ., t2)

36
Accessing an Objects instance variables

• O.x
• Obtain objects address by translating O
• Obtain variables offset
• add the two together.
• Recall that any value, parameter, etc which is an
  object, can be treated as an address.

37
Next time

• Next time we will make more concrete assumptions
  about translating mini-Java
• We will begin to define a semantics for IR1 by
  making an interpreter for it.