CS412413

1
CS412/413

• Introduction to
• Compilers and Translators
• March 12, 1999
• Lecture 18 Abstract Data Types and Objects

2
Administration

• Programming Assignment 3, Part I due next Friday
• Prelim 2 date changed to April 16 (in class)
• Homeworks 5 and 6 have merged

3
Outline

• Programming Assignment 3
• Objects and ADTs first-class modules
• Encapsulation
• Subtyping
• Inheritance

4
Programming Assignment 3

• Part I (checkpoint, due March 19)
• translate AST to IR
• canonicalize IR representation
• hoist side-effects, CALLs
• reorder basic blocks to make branches one-way
• support dump routines for both canonical and
  non-canonical IR
• Part II (due April 5)
• convert IR to abstract assembly by tiling
• use simple register allocation to generate code
• support dump routines, generate running code!

5
Suggestions for Part I

• Define internal interfaces first IR
• non-canonical IR
• IR with side-effects hoisted but 2-way branches
• Should be able to use the IR described in Appel
  or in lecture
• Minor modifications may be good idea
• no SEQ nodes in canonical IR
• SEQ nodes with any number of children
• PUSH statement node, etc.
• Document changes you make to IR

6
Code Translation

• Write translation and IR transformation functions
  as recursive methods on AST and IR nodes
• abstract class ASTNode
• abstract IRNode translate(SymTab A)
• abstract class IRNode
• abstract IRNode canonicalize( ) ...
• Problem how to allow incremental development and
  testing?

7
Coding Translations Incrementally

• Write placeholder translation method in ASTNode
  that is inherited by all AST nodes instant
  translation phase!
• Translation can be refined by adding (and
  testing) translation methods to subclasses one by
  one
• Define special IR node IR_AST that is just a
  container for untranslated AST sub-trees.
• Placeholder translation generates this kind of
  node
• Dump routine for this IR node uses AST dump!

8
Dumping IR

• Goal of Part I is to support printout of the
  various intermediate representations
• dump_ast dump the AST
• dump_ir dump the initial translated IR
• dump_cir dump the canonical IR
• Implement dump as recursive traversal but use
  pretty-printer support
• abstract class IRNode
• abstract void dump(PrettyPrinter pp)
• dump_ir, dump_cir use same code

9
Pretty Printing

• Another application of parsing! Tree-structured
  data can be formatted well
• Provided code to support this PrettyPrinter
• 4 key operations
• write (String s) output a string of the text
• begin(int n) begin group, left margin pos n
• end( ) end current grouping unit
• allowBreak(int n) optional line break here --
  if broken, introduce newline, ?left margin n,
  otherwise emit no text

10
Pretty Printing algorithm

• begin end allowBreak
• begin/end mirror expression tree structure
• Format (alph bet)f(gam, del) eps
• (alph bet) f(gam, del) eps
• (alph bet)f(gam, del)
• eps
• (alph bet)
• f(gam, del)
• eps

(alph bet) f(gam, del) eps
11
Choosing breaks optimally

• Break-from-root rule if a break is broken in a
  group, all breaks in containing groups (up to
  root of group tree) must be broken
• Ensures that deeply nested (high-precedence)
  groups are broken last
• (alph bet) f(gam,
• del) epszeta
• (alph bet) f(gam, del)
• epszeta

12
What IR to generate?

• For Part I, how to choose translations for
  statement forms?
• Tip write equivalent C code, compile as
  described in Pentium Code Samples handout to get
  Pentium assembly
• Map assembly backward by hand to IR
• Useful trick for doing Part II, helps to learn
  instruction setand what instructions are worth
  tiling for

13
High-level languages

• So far how to compile simple languages
• Data types primitive types, strings, arrays
• No user-defined abstractions objects
• No first-class function values
• Next 3 lectures supporting abstract data types
  and objects
• semantic checking
• code generation (IR and assembly)
• Iota (Programming Assignment 4) has objects

14
Data types records

• Records (C structs, Pascal records)
• provide named fields of various types
• implemented as a block of memory
• int x String s char c,d,e int y
• accesses to data members compiled to
  loads/stores indexed from start of record
  compiler converts name of field to an offset.

15
Stack vs. heap

• Records have known size can be allocated either
  on stack (e.g. C, Pascal) or heap
• Accesses to stack records are fp-relative --
  dont need to compute address of record
• Stack allocation means cache coherence

x
s
c
d
e
y
int x String s char c,d,e int y
16
Record Limitations

• Records can be used to implement abstractions,
  but fields are exposed
• Example lists of strings with stored length
• List len int, s String, next List
• Abstract operations
• length, cons, first, rest
• Problem list has representation invariant that
  len field must be equal to length of list, but
  any code can break this invariant.

17
Abstract Types

• Next step abstract types, where the
  representation is hidden (or inaccessible from)
  code other than the implementation of the type
  itself (Ada, CLU, ML)
• Purest form type has an interface and an
  implementation. Interface only mentions
  operations, implementation defines
  representation. (E.g. .h and .C files in C)
• External code does not know representation, cant
  violate the abstraction boundary
• Allows same interface to be reimplemented

18
Interface vs. Impl Type
implementation
length cons first rest
interface
List len int, s String, next List
19
Compiling Abstract Types

• An abstract type is a first-class module
• has interface (interface files in Iota),
  implementation (module files in Iota)
• but we can create new instances of the type, each
  with its own state and operations
• Abstract types harder to implement
• size of data not known statically outside own
  implementation -- cant stack-allocate
• Abstract type operations still implementable as
  simple function calls (resolved by linker)

20
Abstract Types

• Implemented just like heap-allocated records
• C objects are abstract types can be
  stack-allocated. How does it work?

21
Private/Protected

• Objects in C are semi-abstract -- interface
  declares representation, only method code hidden
  from outside (mostly)
• class List
• private int len, String s, List l
• public int length( ) List tail( ) ...
• Allows outside code to know how much space List
  objects take, but not to access fields -- allows
  allocation on stack

22
Multiple Implementations

• Abstract types allow an interface to be
  reimplemented, but only one implementation of any
  interface in a given program
• Next step upward allow multiple implementations
  (e.g., Java)
• interface List int length() List tail()
• class LenList implements List int len ...
• class SimpleList implements List

23
Supporting Multiple Implementations

• Problem from interface, dont know which
  implementation we are dealing with.
• x List

LenList
len
s
x
?
next
SimpleList
s
next
24
Compiling Multiple Impls

• Difficult to stack allocate -- need to be able to
  figure out the concrete type of a reference (as
  in C)
• Dont know what code to run when an operation
  (e.g. length) is invoked.
• length(l LenList) l.len
• length(l SimpleList)
• 1 if (l null) 0 else
  length(l.next)

LenList
len
s
next
SimpleList
s
next
25
Dispatch Vectors

• To figure out what code to run, add a pointer to
  every object to a dispatch vector (dispatch
  table, virtual table, )

LenList object
List dispatch vector
code
length
length(l LenList) l.len
first
len
rest
s
next
length(l SimpleList) 1 if (l null)
0 else length(l.next)
SimpleList object
length
first
s
rest
next
26
Summary

• Variety of different mechanisms for providing
  data abstraction
• Increased abstraction power leads to more
  expensive implementations -- more indirections
• Next time static semantics, plus subtyping,
  inheritance, other object-oriented features
• Later optimizations for object-oriented languages