Compilers construction DD2488 lecture 2 Torbj orn Granlund Nada, - - PowerPoint PPT Presentation

compilers construction dd2488 lecture 2
SMART_READER_LITE
LIVE PREVIEW

Compilers construction DD2488 lecture 2 Torbj orn Granlund Nada, - - PowerPoint PPT Presentation

Compilers construction DD2488 lecture 2 Torbj orn Granlund Nada, tg@gmplib.org Compilers construction DD2488 lecture 2 Torbj orn Granlund Nada, tg@gmplib.org These slides will be available from the course web page Course news Please


slide-1
SLIDE 1

Compilers construction DD2488 lecture 2

Torbj¨

  • rn Granlund Nada, tg@gmplib.org
slide-2
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
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
SLIDE 4

Today’s subjects

◮ Activation records ◮ Translation to intermediate code

slide-5
SLIDE 5

PART1: Activation records

slide-6
SLIDE 6

The ”Stack”

The stack is main abstraction for method calls

slide-7
SLIDE 7

The ”Stack”

The stack is main abstraction for method calls

◮ Typically grows downwards

slide-8
SLIDE 8

The ”Stack”

The stack is main abstraction for method calls

◮ Typically grows downwards ◮ Operations: PUSH and POP

slide-9
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
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
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
SLIDE 12

Activation records

Activation record = data a method needs during execution and for returning to its caller

slide-13
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
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
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
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
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
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
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
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
SLIDE 21

lower addresses . . . . .

  • utgoing

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
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
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
SLIDE 24

PART2: Translation to Intermediate Representation

slide-25
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
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
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
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
SLIDE 29

Intermediate Representation properties

slide-30
SLIDE 30

Intermediate Representation properties

◮ Convenient for parse tree visitor to generate

slide-31
SLIDE 31

Intermediate Representation properties

◮ Convenient for parse tree visitor to generate ◮ Convenient to translate to actual assembly code

slide-32
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
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
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
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
SLIDE 36

Translation to IR—issues

Plain expressions are easy, right? x = y + z * (a + b - t * t) * (b + 4711)

slide-37
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
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
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
SLIDE 40

Mangling IR

Directly after translation, statements in IR will closely reflect statements in source code program

slide-41
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
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
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)) . . .