SLIDE 1 Compilers construction DD2488 lecture 2
Torbj¨
- rn Granlund Nada, tg@gmplib.org
SLIDE 2 Compilers construction DD2488 lecture 2
Torbj¨
- rn Granlund Nada, tg@gmplib.org
These slides will be available from the course web page
SLIDE 3
Course news
Please see course web page for news Informal session 2 scheduled (Mon, Wed in two weeks) New milestones set for session 2
SLIDE 4
Today’s subjects
◮ Activation records ◮ Translation to intermediate code
SLIDE 5
PART1: Activation records
SLIDE 6
The ”Stack”
The stack is main abstraction for method calls
SLIDE 7
The ”Stack”
The stack is main abstraction for method calls
◮ Typically grows downwards
SLIDE 8
The ”Stack”
The stack is main abstraction for method calls
◮ Typically grows downwards ◮ Operations: PUSH and POP
SLIDE 9
The ”Stack”
The stack is main abstraction for method calls
◮ Typically grows downwards ◮ Operations: PUSH and POP ◮ Stack pointer points at last item PUSHed
SLIDE 10
The ”Stack”
The stack is main abstraction for method calls
◮ Typically grows downwards ◮ Operations: PUSH and POP ◮ Stack pointer points at last item PUSHed ◮ Stack pointer is special CPU register
SLIDE 11
The ”Stack”
The stack is main abstraction for method calls
◮ Typically grows downwards ◮ Operations: PUSH and POP ◮ Stack pointer points at last item PUSHed ◮ Stack pointer is special CPU register ◮ Operating systems supports the stack
.
SLIDE 12
Activation records
Activation record = data a method needs during execution and for returning to its caller
SLIDE 13
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack
SLIDE 14
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack In fact, activation records are the only thing there Contents:
SLIDE 15
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack In fact, activation records are the only thing there Contents:
◮ Incoming parameters
SLIDE 16
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack In fact, activation records are the only thing there Contents:
◮ Incoming parameters ◮ Return address
SLIDE 17
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack In fact, activation records are the only thing there Contents:
◮ Incoming parameters ◮ Return address ◮ Register save area
SLIDE 18
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack In fact, activation records are the only thing there Contents:
◮ Incoming parameters ◮ Return address ◮ Register save area ◮ Space for local variables
SLIDE 19
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack In fact, activation records are the only thing there Contents:
◮ Incoming parameters ◮ Return address ◮ Register save area ◮ Space for local variables ◮ Space for compiler-generated temporaries
SLIDE 20
Activation records
Activation record = data a method needs during execution and for returning to its caller Activation records live on the stack In fact, activation records are the only thing there Contents:
◮ Incoming parameters ◮ Return address ◮ Register save area ◮ Space for local variables ◮ Space for compiler-generated temporaries ◮ Static link
.
SLIDE 21 lower addresses . . . . .
arguments incoming arguments local variables saved registers return address argument n argument 1 static link next frame argument n argument 1 static link frame pointer stack pointer current frame previous frame higher addresses .
SLIDE 22
Managing activation records
The generated code must manage activation records For JVM: Higher abstraction level—details in its documentation For ASM: Lower abstraction level—follow ”ABI”
◮ Compiler computes exact layout ◮ Compiler generates instructions for adjusting stack pointer,
saving registers, updating static link, etc.
SLIDE 23
Static nesting—variable access
long factorial (long n) { long bar (long i) { if (i == n) return n; else return i * bar (i + 1); } return bar (1); }
SLIDE 24
PART2: Translation to Intermediate Representation
SLIDE 25
Compiler passes
text lex tokens tokens parse parse tree + symtab parse tree + symtab semantic analysis parse tree + symtab parse tree + symtab canonicalise IR IR flow analysis IR + dependency graph IR ”optimisations” IR IR instruction selection ASM with ∞ # of regs ASM register allocation ASM ASM allocation fixup ASM ASM stack layout ASM ASM code emission
SLIDE 26
Translation to Intermediate Representation (IR)
IN: Parse tree (and symbol table(s) with type info) OUT: Abstract Intermediate Representation What are the differences between PT and IR?
SLIDE 27
Translation to Intermediate Representation (IR)
IN: Parse tree (and symbol table(s) with type info) OUT: Abstract Intermediate Representation What are the differences between PT and IR?
◮ Parse tree depends on source language, IR is source language
independent
SLIDE 28
Translation to Intermediate Representation (IR)
IN: Parse tree (and symbol table(s) with type info) OUT: Abstract Intermediate Representation What are the differences between PT and IR?
◮ Parse tree depends on source language, IR is source language
independent
◮ IR ”portable assembly”
.
SLIDE 29
Intermediate Representation properties
SLIDE 30
Intermediate Representation properties
◮ Convenient for parse tree visitor to generate
SLIDE 31
Intermediate Representation properties
◮ Convenient for parse tree visitor to generate ◮ Convenient to translate to actual assembly code
SLIDE 32
Intermediate Representation properties
◮ Convenient for parse tree visitor to generate ◮ Convenient to translate to actual assembly code ◮ Allow analysis in optimising compiler
SLIDE 33
Intermediate Representation properties
◮ Convenient for parse tree visitor to generate ◮ Convenient to translate to actual assembly code ◮ Allow analysis in optimising compiler ◮ Start as a full tree, gradually shallowed
SLIDE 34
Intermediate Representation properties
◮ Convenient for parse tree visitor to generate ◮ Convenient to translate to actual assembly code ◮ Allow analysis in optimising compiler ◮ Start as a full tree, gradually shallowed ◮ Infinite number of registers
SLIDE 35
Intermediate Representation properties
◮ Convenient for parse tree visitor to generate ◮ Convenient to translate to actual assembly code ◮ Allow analysis in optimising compiler ◮ Start as a full tree, gradually shallowed ◮ Infinite number of registers
GCC uses two IR’s, ”Tree” and ”RTL”
SLIDE 36
Translation to IR—issues
Plain expressions are easy, right? x = y + z * (a + b - t * t) * (b + 4711)
SLIDE 37
Translation to IR—issues
Plain expressions are easy, right? x = y + z * (a + b - t * t) * (b + 4711) But how about this? x = y + z * (a + factorial(17) - t * t) * ((b++) + binom(n,k))
SLIDE 38
Translation to IR—issues
Plain expressions are easy, right? x = y + z * (a + b - t * t) * (b + 4711) But how about this? x = y + z * (a + factorial(17) - t * t) * ((b++) + binom(n,k)) Conclusion: We have deal with side effects!
SLIDE 39
Translation to IR—issues
Plain expressions are easy, right? x = y + z * (a + b - t * t) * (b + 4711) But how about this? x = y + z * (a + factorial(17) - t * t) * ((b++) + binom(n,k)) Conclusion: We have deal with side effects! Which side-effects exist is language-dependent In Java: function calls and increments In C: function calls, increments, and nested assignments (yuk)
SLIDE 40
Mangling IR
Directly after translation, statements in IR will closely reflect statements in source code program
SLIDE 41
Mangling IR
Directly after translation, statements in IR will closely reflect statements in source code program We gradually break this down to simpler but more statements
SLIDE 42
Mangling IR
Directly after translation, statements in IR will closely reflect statements in source code program We gradually break this down to simpler but more statements In the end, we have statements that are close to assembly code, with side effects sequenced correctly
SLIDE 43
Basic blocks
OK, we have shallowed our tree to a simple sequence: . . . LAB(L1) r23 = ADD(r4711, r23) r3 = MOV(r4711) r4 = LD(r23) r3 = SUB(r3, r4) r3 = MUL(r3, 17) ST(r23, r3) r1 = ADD(r1,1) CMP(r1, 10) JNEQ(LAB(L1)) . . .