252210:compilerdesign · 6.5programstartup! howdoweturnasequenceofinstrucfons(compiler’...

252-‐210: Compiler Design 6.5 Program startup 7.0 Code genera5on

Thomas R. Gross Computer Science Department ETH Zurich, Switzerland

Outline

§  6.1 IntroducFon

§  6.2 Basic types §  6.3 Object instances and references §  6.4 Inheritance §  6.5 Program startup

§  7.0 Code generaFon

2

6.5 Program startup

§  How do we turn a sequence of instrucFons (compiler output) into a process (“execuFon of program”)?

§  (Recall) In JavaLi, a complete program (“applicaFon”) must contain a class Main with method main() §  Execu5on starts with main()

class Main {

void main() {

… ☚

}

} 3

§  Ideally, starFng the program with main() is the same as invoking main() in some context.

§  <some object>.main()

4

§  Ideally, starFng the program with main() is the same as invoking main() in some context.

§  <some object>.main()

§  Compiler produces startup code §  Use services of opera5ng system and loader

§  Set up environment as if it was created by invocaFon of “new” operator (somewhere)

5

Steps

§  Create instance of class Main §  Although there is no “new Main()” in the program §  Call this instance Mi

§  Keep reference miref to Mi

§  Create vtable for Main §  Put it above the stack §  Put it in the heap §  (Think about aMacks in real systems …) §  Ini5alize table with entry for main()

§  Invoke miref.main()

6

12

Start: Create heap Get heap ptr Setup stack, init TOS register Create Mi , set miref Init vtable Invoke miref.main() Main.main: …. Return Otherclass.method: …. Return

heap-‐ptr

TOS

miref

Mi

vtable for Main

main

7.0 Code generaFon

Input: IR (operator trees, AST)

⇓

Output: Machine code (assembly code)

§  Crucial part of compiler §  In many compilers, most effort devoted to code genera5on (and

establishing that condi5ons for op5miza5on are met) §  Many compilers start with exis5ng front-‐end/seman5c analyzers

§  Key requirement: correctness

14

Code generator

Major acFviFes of a code generator

1.   Code selecFon §  Decide on machine instruc5on(s) that are generated for a given IR

node §  … or group of IR nodes

15

Code selecFon

§  Consider x = y – x – 1 §  Assume x is in %eax, y is in %ecx

§  One possible code sequence subl %eax, %ecx

movl %ecx, %eax

decl %eax

movl %eax, x

§  Another opFon notl %eax

addl %ecx, %eax

movl %eax, x 16

Code selecFon §  swap x, y

§  Assume x is in %eax, y is in %ecx

§  OpFon 1: movl %eax, %edx

movl %ecx, %eax

movl %edx, %ecx

§  OpFon 2 xchg %eax, %ecx

§  Finding good sequences (maybe) far from easy

§  Not always clear what sequence is fastest §  May depend on processor model 17

Code generator




18

Code generator




2.   Code scheduling §  Determines order of execu5on of (unrelated) instruc5ons

19

Code scheduling

§  Not much to do for single small tree

§  OpFons for mulFple trees

§  Consider a = b + c; x = y + 1; §  Assume that memory read access takes 2 cycles

20

§  OpFon 1 movl b, %eax

…

addl c, %eax

…

movl %eax, a

movl y %ecx

…

incl %ecx

movl %ecx, x

21


…

addl c, %eax

…

movl %eax, a

movl y %ecx

…

incl %ecx

movl %ecx, x

22


movl y %ecx

addl c, %eax

incl %ecx

movl %eax, a

movl %ecx, x


…

addl c, %eax

…

movl %eax, a

movl y %ecx

…

incl %ecx

movl %ecx, x

§  Not always clear what is faster §  Processors reorder instrucFons on-‐the-‐fly

23


movl y %ecx

addl c, %eax

incl %ecx

movl %eax, a

movl %ecx, x

Code generator




2.   Code scheduling §  Determines order of execu5on of (unrelated) instruc5ons

3.   Register allocaFon and assignment §  Alloca5on: decide which operand goes into a register §  Assignment: decide which register holds a given operand

24

Register allocaFon

Consider (in some class C)

int inc(int x) { return x+1;}

int foo(int p) {

int a, b, c;

a = p + 1;

b = inc(a);

c = a + b;

return c;

}

25

Register allocaFon

§  Assume that method inc uses (and destroys) the %eax register. §  Return value in %eax

§  Method foo has two opFons

§  OpFon 1: use %eax for first stmt §  Evaluate (p+1) into %eax. §  Invoke inc §  Reload a into %ebx §  Add %ebx to %eax

26

§  OpFon 2: don’t use %eax for first stmt §  Evaluate (p+1) into %ebx §  Invoke inc §  Add %ebx and %eax

§  2nd opFon saves (re)loading a §  Register requirements of inc may not be known at the Fme

that foo is compiled.

27

Bad (interesFng) news

28

Code selecFon

Register allocaFon Code scheduling

Different register use for

a = b + c;

x = y + 1;


…

addl c, %eax

…

movl %eax, a

movl y %eax

…

incl %eax

movl %eax, x

30


…

addl c, %eax

…

movl %eax, a

movl y %eax

…

incl %eax

movl %eax, x

31


movl y %eax

addl c, %eax

incl %eax

movl %eax, a

movl %eax, x

✗

Outline

§  7.1 Access to operands §  7.2 Assignment statement (again)

§  7.3 CondiFonal statement

§  7.4 Loops §  7.5 Method invocaFon

§  Plan §  First step: simple (but complete) code generator

§  (next)* homework

§  Then: register alloca5on/flow analysis §  (next)*+1 homework

32

Simple code generator

§  Template based §  Complexity controlled by number and scope of templates

§  No detailed look at machine properFes §  Sacrifice op5miza5on opportuni5es

§  No code scheduling §  Hardware does a good job for scheduling “nearby” instruc5ons §  Need more compiler technology to let compiler shine where hardware

fails

33

7.1 Operand access

§  Operands appear in assembly language statements §  x86 rule: one source, one source/des5na5on

§  Or only one source/des5na5on

§  x86 rule: One operand may be in memory §  But not more than one §  Therefore: if there are two operands, one must be in register

§  Or immediate value

§  x86 rule: There are only 6 available (int) registers

34

Operand access

§  Approach: produce code (select instrucFons) and assume unlimited number of registers §  “Virtual registers” §  Later phase maps virtual registers to real registers.

§  Given an IR (sub)tree §  Two operands? §  Pick one to stay in memory, get new virtual register

35

Kinds of operands

§  Constants §  Method-‐local variables

§  Fields §  Parameters

§  Formal parameters §  Actual parameters (arguments)

§  Array elements

§  Return values CombinaFons are possible ! code generator should be

modular 36

Constants

§  Already covered in Assignment 1

§  If we need to put a value into a register §  Pick a virtual register §  Move constant to register §  Use operand as needed

§  Some instrucFons may allow use of immediate values as operands §  No need to get a register §  Oken constraints on size of constant, kind of constant, posi5on of

operand §  x + 1.0 §  4 – y §  x + 2 147 483 648 (maxint = 2 147 483 647)

38

Fields

§  Field b in some instance of instance of class B

class B {

int a, b;

}

B bref

bref.b

…

this.b

39

Fields

§  (Recall) Symbol table contains class name, field name(s), field type(s)

40

§  Field b located at fixed offset (bo) from the start of the memory block §  Offset bo is found in the symbol table

bref bookkeeping informa5on, e.g., link to vtable

b a

offset bo

Fields

§  To access b in an instance of B: §  Get reference to this instance

§  Put it into a register §  Add offset bo to get the field’s b loca5on §  Use address to read/write the field

§  Offset for field b is determined by Space for bookkeeping +  Space for fields assigned to a posi5on between bookkeeping and b

§  Compiler decides on order §  Offset is determined either before code genera5on or on the fly

§  Offset easy to determine for JavaLi, different types (bit, bytes,…) and alignment constraints may cause complicaFons in other languages 42

Arrays

§  Issue is dealing with array elements §  JavaLi (and many other languages) do not allow arrays to be operands

§  Array element determined by (at least one) array index

int [] X;

X = new int[..];

§  X[i] §  Index i (key i) §  i-‐th element

§  X[expression] §  Expression that evaluates to an integer, may include other array

elements 43

§  X[0] §  First element

int [][] Y;

Y = new int[..][..]

§  Y[expression1, expression2]

Extension to arbitrary number of dimensions

44

Arrays

§  (Linear) arrays are stored in a sequence of consecuFve bytes §  Linear = 1-‐dimensional §  Simple address arithme5c §  Works for arrays of instances, arrays in a field, and arrays as local

variables of a method

§  Need to determine §  Size of array (block) §  Addressing

§  First, 1-‐d arrays, then n-‐dim arrays §  OK, 2-‐dim arrays

45

Array size

§  JavaLi (like Java) iniFalizes an array reference with the new() operator.

int [] iarray;

iarray = new int[N]

§  or in general t_array = new t[N]

§  Size of block of memory for array §  Given size_t – size for element t – then §  array_size = N × size_t

46

§  size_t for type t §  Easy for built-‐in types §  May have to be computed for other types

§  Lookup in symbol table

§  Need to map array to block of memory §  Consider some_type [] X X = new some_type[N]

47

§  Memory block: sequence of bytes

48

0

size_t × N -‐1

§  Base: locaFon of X[0] §  LocaFon of X[j]: add or subtract offset

0

size_t × N -‐1

MulF-‐dimensional arrays

49

X[0,0] X[0,1] X[0, M-‐2] X[0, M-‐1]

X[0,1] X[1,1] X[1, M-‐2] X[1, M-‐1]

X[L-‐1,0] X[L-‐1,1] X[L-‐1, M-‐2] X[L-‐1, M-‐1]

§  Array with N = L × M elements

§  Not all languages support mulF-‐dimensional arrays directly §  Oken, 2-‐d array = 1-‐d array of 1-‐d arrays §  3-‐d array = 1-‐d array of 2-‐d arrays = 1-‐d array of 1-‐d arrays of 1-‐d arrays

§  Memory sequence of bytes (words)

§  Store row-‐aner-‐row §  “row-‐major” order

54

X[0,0] X[0,1] X[0, M-‐2] X[0, M-‐1]

X[0,1] X[1,1] X[1, M-‐2] X[1, M-‐1]

X[L-‐1,0] X[L-‐1,1] X[L-‐1, M-‐2] X[L-‐1, M-‐1]

X[0,0]

X[0,1]

….

X[0, M-‐1]

X[1,0]

…

X[1, M-‐1]

…

X[L-‐1, 0]

…

X[L-‐1, M-‐2]

X[L-‐1, M-‐1]

§  Memory sequence of bytes (words)

§  Store column-‐aner-‐column

§  “Column-‐major” order

58

X[0,0] X[0,1] X[0, M-‐2] X[0, M-‐1]

X[0,1] X[1,1] X[1, M-‐2] X[1, M-‐1]

X[L-‐1,0] X[L-‐1,1] X[L-‐1, M-‐2] X[L-‐1, M-‐1]

X[0,0]

X[1,0]

….

X[L-‐1, 0]

X[0,1]

…

X[L-‐1, 1]

…

X[0, M-‐1]

…

X[L-‐2, M-‐1]

X[L-‐1, M-‐1]

§  Language specificaFon (should) determine scheme §  Row-‐major: C, C++ §  Column-‐major: FORTRAN

§  Does not maoer for program wrioen in a language but maoers when calling a library or program wrioen in another language §  Unless language exposes address arithme5c §  May need to rewrite/restructure program to use libraries

59

Finding X[i, j]

§  Address of X[i,j] = base(X) + i × size_row + j × size_element

60

row 0

row 1

….

row (i − 1)

X[i, 0]

X[i, j−1]

X[i, j]

base

i rows

j elelments

Access to X[expression]

§  Evaluate expression §  Generate code for expression

§  Check if v=value(expression) is in 0 … N−1 §  Get base(X) §  Get s = size_element

§  Size of each element

§  Address AX[expression] = base(X) + s × v

61

CombinaFons

§  Use simple paoerns

§  SoluFon must work for all combinaFons §  Op5miza5on can wait

§  Examples §  aref.xref[i].b §  aref[i].yref[j].f §  a.b.c.d.e.f.g.h.i.j.k §  … §  a[b[c[d[e[f.j]]]]]]

62

<one>.<two>.<three>

§  Approach: §  Loop:

§ Get address for next part (i.e., <…>) §  Leave address in register

§  Access: § Use address to perform read/write § R/W may be part of instruc5on

63

Detour: fixed sized arrays

§  Arrays given consecuFve sequence of bytes §  Arrays have N elements (say 0 … N-‐1) §  Fixed at some point in 5me (during execu5on, at compile 5me)

§  Access to element with index < 0: error

§  Access to element ≥ N (e.g., K)

64

To grow the array

§  Create a new array §  At least large enough to hold element K

§  Copy the old (exisFng) elements

67

252210:compilerdesign · 6.5programstartup! howdoweturnasequenceofinstrucfons(compiler’...

Documents