IR part 2 - PowerPoint PPT Presentation

1 / 37
About This Presentation
Title:

IR part 2

Description:

Mooly Sagiv and Roman Manevich. School of Computer Science. Tel-Aviv University. 2. Announcements. What is expected in PA3 documentation (5 pts) ... – PowerPoint PPT presentation

Number of Views:41
Avg rating:3.0/5.0
Slides: 38
Provided by: RomanMa8
Category:

less

Transcript and Presenter's Notes

Title: IR part 2


1
Winter 2006-2007Compiler ConstructionT9 IR
part 2 Runtime organization
Mooly Sagiv and Roman Manevich School of Computer
Science Tel-Aviv University
2
Announcements
  • What is expected in PA3 documentation (5 pts)
  • Testing strategy lists of tests and what they
    check (scope rules, type rules etc.)
  • How did you conduct the semantic analysis in
    which order do you do things
  • Dont document the most obvious things(The
    input to CUP is in IC.cup), dont repeat stuff
    already in PA3.pdf
  • Document non-obvious choices (We build the type
    table after parsing, we do not handle situation
    X, we handle special situation Y like so)
  • Output format (e.g., first we print type table
    then we print)
  • Know thy groups code

3
Today
LexicalAnalysis
Syntax Analysis Parsing
AST
SymbolTableetc.
Inter.Rep.(IR)
CodeGeneration
  • Today
  • IR
  • Specific LIR language
  • Translating HIR nodes
  • Runtime organization
  • Objects
  • Polymorphism
  • Next time
  • Simple lowering techniques
  • Runtime organization
  • Activation records (frames)
  • PA4

4
Recap
Symtab hierarchy
Global type table
A ? E1 T
Additional semantic checks
Type checking
A ? E1.length int
Move tomatoes,R1 Move potatoes,R2 Add R2,R1 ...
LIR
5
Low-level IR (LIR)
  • An abstract machine language
  • Generic instruction set
  • Not specific to a particular machine
  • Low-level language constructs
  • No looping structures, only labels
    jumps/conditional jumps
  • We will use two-operand instructions
  • Advantage close to Intel assembly language
  • LIR spec. available on web-site
  • Will be used in PA4
  • Subject to changes
  • LIR from T8 only for demonstration purposes

6
LIR instructions
Immediate(constant)
Memory(variable)
Note 1 rightmost operand operation
destination Note 2 two register instr - second
operand doubles as source and destination
7
Example
Move 42,R1 Move R1,x _test_label Move
x,R1 Compare 0,R1 JumpLE _end_label Move
x,R1 Move 1,R2 Sub R1,R2 Move R2,x Jump
_test_label _end_label
  • x 42
  • while (x gt 0)
  • x x - 1

Compare results stored in global compare register
(implicit register)
Condition depends on compare register
(warning code shown is a naïve translation)
8
Translating expressions example
  • TRx 42

visit
Move x, R1
Add R2, R1
Move 42, R2
visit(right)
visit(left)
Add R2, R1
Move x, R1
Move 42, R2
Very inefficient translation can we do better?
9
Translation (IR lowering)
  • How to translate HIR to LIR?
  • Assuming HIR has AST form(ignore non-computation
    nodes)
  • Define how each HIR node is translated
  • Recursively translate HIR (HIR tree traversal)
  • TRe LIR translation of HIR construct e
  • A sequence of LIR instructions
  • Temporary variables new locations
  • Use temporary variables (LIR registers) to store
    intermediate values during translation

10
Translating expressions
Fresh virtual (LIR) registergenerated by
translation
Binary operations(arithmetic and comparisons)
R1 TRe1 R2 TRe2 R3 R1 OP R2
  • TRe1 OP e2

Shortcut notationto indicate target registerNOT
LIR instruction
Unary operations
TROP e
R1 TRe R2 OP R1
11
Translating (short-circuit) OR
R1 Te1 Compare 1,R1 JumpTrue _end_label R2
Te2 Or R2,R1 _end_label
  • TRe1 OR e2

(OR can be replaced by Move operation since R1 is
0)
12
Translating (short-circuit) AND
R1 Te1 Compare 0,R1 JumpTrue _end_label R2
Te2 And R2,R1 _end_label
  • TRe1 AND e2

(AND can be replaced by Move operation since R1
is 1)
13
Translating array and field access
R1 TRe1 R2 TRe2 MoveArray R1R2, R3
  • TRe1e2

Give class type of e1 need to compute offset of
field f
TRe1.f
R1 TRe1 MoveField R1.cf,R3
Need to identify class type of e1 from semantic
analysis phase
Constant representing offset of field f in
objects of class type of e1(we shall discuss
object representation soon)
14
Translating statement block
TRs1 TRs2 TRs3 TRsN
  • TRs1 s2 sN

15
Translating if-then-else
R1 TRe Compare 0,R1 JumpTrue
_false_label Ts1 Jump _end_label _false_label T
s2 _end_label
  • TRif (e)
  • then s1
  • else s2

Fresh labels generated during translation
Fresh labels generated during translation
16
Translating if-then
R1 TRe Compare 0,R1 JumpTrue
_end_label TRs1 _end_label
  • TRif (e) then s

Can avoid generatinglabels unnecessarily
17
Translating while
  • TRwhile (e) s

_test_label R1 TRe Compare 0,R1 JumpTrue
_end_label TRs Jump _test_label _end_label
18
Translating call/return
R1 TRe1 Rn TRen StaticCall
C_foo(x1R1,,xnRn),R
  • TRC.foo(e1,,en)

formal parameter name
actual argument register
R1 TRe1 R2 TRe2 VirtualCall
R1.cfoo(xR2),R
TRe1.foo(e2)
R1 TRe Return R1
TRreturn e
Constant representing offsetof method f in
dispatch tableof class type of e1
19
Translation implementation
  • Define classes for LIR instructions
  • Define LoweringVisitor
  • Apply visitor to translate each method
  • Mechanism to generate new LIR registers(keep
    track of registers for next phase)
  • Mechanism to generate new labels
  • For each node type translation returns
  • List of LIR instructions TRe
  • Target register
  • Splice lists instructions.addAll(TRe)(input
    is a tree, output is a flat list)

20
Example revisited
  • TR
  • x 42
  • while (x gt 0)
  • xx-1

TRx 42 TR while (x gt 0) xx-1
Move 42,R1 Move R1,x TR while (x gt 0)
xx-1
Move 42,R1 Move R1,x _test_label Move
x,R1 Compare 0,R1 JumpLE _end_label Move
x,R1 Move 1,R2 Sub R2,R1 Move R1,x Jump
_test_label _end_label
Move 42,R1 Move R1,x _test_label Move
x,R1 Compare 0,R1 JumpLE _end_label TRxx-1 Jump
_test_label _end_label
spliced list for TRxx-1
(actually a DFS walk)
21
Naïve translation
  • Pretend all LIR registers are local variables
  • Increases memory needed for each procedure during
    runtime
  • Expensive access vs. accessing real
    registers(spilling)
  • Generate fresh LIR register per HIR node
  • Lifetime of registers very limited
  • Allow consecutive labels
  • Code bloat

22
Better translation
  • Pretend all LIR registers are local variables
  • Ideally leave it to register allocation phase to
    store LIR registers in machine registers
  • In this project we ignore this inefficiency
  • Limit register allocation to single LIR
    instructions
  • Generate fresh LIR register per HIR node
  • Reuse registers
  • Avoid generating registers for HIR leaves
  • Allow consecutive labels
  • Avoid generating consecutive labels
  • Optimizations techniques discussed next time

23
Runtime organization
  • Representation of basic types
  • Representation of allocated objects
  • Class instances
  • Dispatch vectors
  • Strings
  • Arrays
  • Procedures
  • Activation records (frames)

Discussed next time(relevant mostly for PA5)
24
Representing data at runtime
  • Source language types
  • int, boolean, string, object types, arrays etc.
  • Target language types
  • Single bytes, integers, address representation
  • Compiler maps source types to some combination of
    target types
  • Implement source types using target types
  • Compiler maps basic operations on source types to
    combinations of operations on target types
  • We will limit our discussion to IC

25
Representing basic types in IC
  • int, boolean, string
  • Simplified representation 32 bit for all types
  • boolean type could be more efficiently
    implemented with single byte
  • Arithmetic operations
  • Addition, subtraction, multiplication, division,
    remainder
  • Could be mapped directly to target language types
    and operations
  • Exception string concatenation implemented using
    library function __stringCat

26
Pointer types
  • Represent addresses of source language data
    structures
  • Usually implemented as an unsigned integer (4
    bytes)
  • Pointer dereferencing retrieves pointed value
  • May produce an error
  • Null pointer dereference
  • Insert code to check fragile operations (in PA5)
  • Only implicit in our case

27
Object types
  • Basic operations
  • Field selection
  • computing address of field, dereferencing
    address
  • Method invocation
  • Identifying method to be called, calling it
  • How does it look at runtime?

28
Object types
  • class Foo
  • int x
  • int y
  • void rise()
  • void shine()

DispacthVectorPtr
x
y
Runtime memory layout for object of class Foo
Field offsets
DispacthVectorPtr
Method offsets
0
rise
x
0
1
shine
y
1
2
Compile time information forFoo class type
29
Field selection
Foo f int q q f.x
DispacthVectorPtr
x
y
Runtime memory layout for object of class Foo
Field offsets
DispacthVectorPtr
Method offsets
0
Move f,R1 MoveField R1.1,R2 Move R2,q
rise
x
1
0
shine
y
1
2
Compile time information forFoo class
typegenerated during LIR translation
30
Implementation
  • Store map for each ClassType
  • From field to offset (starting from 1, since 0
    reserved for DispatchVectorPtr)
  • From method to offset

31
Object types and inheritance
DispacthVectorPtr
  • class Foo
  • int x
  • int y
  • void rise()
  • void shine()

x
prefixfrom Foo
y
z
Runtime memory layout for object of class Bar
Field offsets
DispacthVectorPtr
0
rise
x
1
prefixfrom Foo
class Bar extends Foo int z void twinkle()
void rise()
y
shine
2
z
twinkle
3
Compile time informationfor Bar class type
32
Object types and polymorphism
  • class Foo
  • void rise()
  • void shine()

Pointer to Bar
f
DVPtr
x
y
z
class Bar extends Foo void rise()
Runtime memory layout for object of class Bar
Initializes value of DVPtr for Bar
class Main void main() Foo f new
Bar() f.rise()
Foo dispatch vector
Bar dispatch vector
_Foo_rise
_Bar_rise
_Foo_shine
_Foo_shine
_Bar_twinkle
Runtime static information
33
Dynamic binding
class Foo void rise() void shine()

class Main void main() Foo f new
Bar() f.rise()
Foo dispatch vector
Bar dispatch vector
class Bar extends Foo void rise()
_Foo_rise
_Bar_rise
_Foo_shine
_Foo_shine
_Bar_twinkle
  • Finding the right method implementation
  • Done at runtime according to object type
  • Using the Dispatch Vector (a.k.a. Dispatch Table)

34
Dispatch vectors in depth
class Main void main() Foo f new
Bar() f.rise()
class Foo void rise() void shine()

class Bar extends Foo void rise()
0
0
1
Pointer to Bar
f
DVPtr
rise
_Bar_rise
x
shine
_Bar_shine
Pointer to Foo inside Bar
y
Bar Dispatch vector
Method code
z
Object layout
  • Vector contains addresses of methods
  • Indexed by method-id number
  • A method signature has the same id number for all
    subclasses

35
Dispatch vectors in depth
class Main void main() Foo f new
Foo() f.rise()
class Foo void rise() void shine()

class Bar extends Foo void rise()
0
0
1
Pointer to Foo
f
DVPtr
rise
_Foo_rise
x
shine
_Foo_shine
y
Foo Dispatch vector
Object layout
36
Object creation
Foo f new Bar()
DispacthVectorPtr
x
LIR translation computesobject for each class
type size of objectFoo xyzDVPtr
111 1 4 (16 bytes)
y
Runtime memory layout for object of class Foo
LIR translation computesobject for each class
type field offsets and method offsets for
DispatchVector
Field offsets
DispacthVectorPtr
Method offsets
0
Library __allocateObject(16),R1MoveField
R1.0,_Bar_DVMove R1,f
rise
x
0
1
shine
y
1
2
Compile time information forFoo class
typegenerated during LIR translation
Label generated for class type Bar during LIR
translation
37
See you next week
Write a Comment
User Comments (0)
About PowerShow.com