compilers and language processing tools · content of lecture 1.introduction 2.syntax and type...

Compilers and Language Processing ToolsSummer Term 2013

Arnd Poetzsch-HeffterAnnette Bieniusa

Software Technology GroupTU Kaiserslautern

c© Arnd Poetzsch-Heffter 1

Content of Lecture

1. Introduction2. Syntax and Type Analysis

2.1 Lexical Analysis2.2 Context-Free Syntax Analysis2.3 Context-Dependent Analysis (Semantic Analysis)

3. Translation to Intermediate Representation3.1 Languages for Intermediate Representation3.2 Translation of Imperative Language Constructs3.3 Translation of Object-Oriented Language Constructs3.4 Translation of Procedures

4. Optimization and Code Generation4.1 Assembly and Machine Code4.2 Optimization4.3 Register Allocation4.4 Further Aspects


Content of Lecture (2)

5. Selected Topics in Compiler Construction5.1 Just-in-time Compilation5.2 Garbage Collection5.3 XML Processing (DOM, SAX, XSLT)


3. Translation to IntermediateRepresentation

c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 4

Translation of Imperative Language Constructs

3.1 Translation of Imperative Language Constructs



Introduction

Focus:• Differences between source languages and target

languages/target machines• Most important translation techniques for different programing

paradigms (procedural/object-oriented)

Learning Objectives:• Overview of imperative and procedural language constructs• Languages for intermediate representation• Translation of object-oriented language constructs• Translation techniques for procedural language constructs



Language Constructs of Procedural Languages

From a conceptional and semantical view point, procedural languageshave the following constructs:• Domains with operations (often typed)

I pre-defined: int, boolean, ...I user-defined: records, classes, ...I implicitly defined: field types, address types, function types

• VariablesI simple and compound typesI global, local, statically/dynamically allocatedI define memory state

• ExpressionsI computation of values with implicit intermediate resultsI possibly in combination with execution control and state

modification



Language Constructs of Procedural Languages (2)

• StatementsI simple and combined statementsI define execution control and state modification

• ProceduresI abstraction of parametrized statementsI may be recursiveI may be nested

Modules usually do not have a semantic meaning and are onlyrelevant for the name analysis and for binding and loading.



Nested Procedures

Example from [Wilhelm, Maurer; Fig. 2.9]

Übersetzung geschachtelter ProzedurenGeschachtelte/lokale Prozeduren werden z.B.

von Pascal und Ada unterstützt

Beispiel: (geschachtelte Prozeduren)

von Pascal und Ada unterstützt.

proc P(a)

var b

Ab

b.

2.9

)

var b

var c

proc Q

var a

proc R

elm

/Ma

ure

r,var b

begin

... b ...

... a ...

c

mt a

us W

ilhe... c ...

end

begin

... a ...

... b ...

sp

iel sta

mm... call Q ...

end

proc S

var a

begin

(da

s B

eisbegin

... a ...

... call Q ...

end

begin

12.06.2007 237© A. Poetzsch-Heffter, TU Kaiserslautern

... a ...

... call Q ...

end


Languages for Intermediate Representation

3.1 Languages for Intermediate Representation



Motivation

We could go directly from the AST to machine code, but ...

JavaC

C++Pascal

ML

Sparc

MIPS

Pentium

JavaC

C++Pascal

ML

IR

Sparc

MIPS

Pentium

Intermediate representation

• front end: lexical analysis, parsing, semantic analysis• back end: machine specific optimization, translation to machine

language• intermediate code: machine and language independent

optimization



Specifics of intermediate representation

A good IR is• convenient to produce from source language• convenient to translate into machine language• small, with clear and simple semantics

Design of IR:• IR languages are comparable to data structures in algorithm

design, i.e., for each task, an intermediate language is more orless suitable.

• Intermediate languages can conceptually be seen as abstractmachines.



Typical differences: Source language vs. IR

• Data types and memory:array and field deferencing vs. load/store on heap or stack

• Expressions:simpler

• Statements:compound statements vs. (conditional) jumps

• Method calls:I various number of arguments vs. simple callI explicit management of recursion (→ stack frames)


Languages for Intermediate Representation SIRL: A simple IR language

3.1.1 SIRL: A simple IR language



SIRL: Introduction

SIRL is very similar to the IR language Piglet of compiler project

Data types and memory:• Values in SIRL are integers and addresses• SIRL programs work on a byte-addressable memory



SIRL: Expressions

CONST(i) integer constant i or address iNAME(n) symbolic constant n [code label]TEMP(t) temporary t , similar to a machine registerBINOP(o,e1,e2) binary operator o with operands e1 and e2MEM(e) contents of a word of memory at address eCALL(f ,[e1, . . . ,en]) procedure callESEQ(s,e) statement expression; execute statement s

for side-effects, expression e for result



SIRL: Operators

Binary arithmetic and logical operators:PLUS, MINUS, MUL, DIV integer arithmetic operatorsAND, OR, XOR integer bitwise logical operatorsLSHIFT, RSHIFT integer logical shift operatorsARSHIFT integer arithmetic right-shift

Relational operators:EQ, NE integer equality and non-equality (for both

signed and unsigned)LT, GT, LE, GE integer inequalities (signed)ULT, UGT, ULE, UGE integer inequalities (unsigned)



SIRL: Statements

MOVE(TEMP(t), e) Evaluate e and move it into t .MOVE(MEM (e1),e2) Evaluate e1 yielding address a; evaluate e2

and move it into a.EXP(e) Evaluate e and discard result.JUMP(e,[l1, . . . , ln]) Transfer control (jump) to address e;

l1, . . . , ln are all possible values for e. Of-ten used: JUMP(l).

CJUMP(o,e1,e2,t ,f ) Evaluate e1, then e2; compare their resultsusing relational operator o. If true, jump tolabel t , else jump to label f .

SEQ(s1,s2) Statement s1 followed by statement s2.LABEL(n) Define constant value of name n as current

code address. NAME(n) can then be usedas targets of jumps, calls, etc.

NOOP skip statement



SIRL: Program structure

Program ::= MAIN StmtList END Procedure*StmtList ::= ( Label? Stmt )*Procedure ::= Label [ IntLiteral ] ESEQ

where Stmt, ESEQ, Label are as defined above



Examples

Translate the following MiniJava statements to SIRL:1. if (x < y) x = y; else x = 0;

2. y = z[5];



Examples

1. if (x < y) x = y; else x = 0;

• Assume, x corresponds to TEMP 5, y corresponds to TEMP 27.• Define three (new) label names L1, L2, and L3.

CJUMP (LT, TEMP 5, TEMP 27, L1, L2)L1 MOVE (TEMP 5, TEMP 27)

JUMP L3L2 MOVE (TEMP 5, CONST 0)L3 ...



Examples

2. y = z[5];

• Assume y corresponds to TEMP 27, and the base address ofarray z is a.

• Let w be the word size of MiniJava (e.g. 4 bytes).• Calculate the offset for the array at index 5

MOVE (TEMP 27, MEM (+(a, *(CONST 5, CONST w))))

Here, we use o(e1,e2) as abbreviation for BINOP(o,e1,e2).


Languages for Intermediate Representation 3-Address Code

3.1.2 3-Address Code



3-address code

3-address code (3AC) is a common intermediate language with manyvariants.

Properties:

• only elementary data types (but often arrays)• no nested expressions• sequential execution, jumps and procedure calls as statements• named variables as in a high level language• unbounded number of temporary variables



3-address code (2)

A program in 3AC consists of

• a list of global variables

• a list of procedures with parameters and local variables

• a main procedure

• each procedure has a sequence of 3AC commands as body



3AC commands

Syntax Explanation

x := y bop zx : = uop zx:= y

x: variable (global, local, parameter, temporary)y,z: variable or constantbop: binary operatoruop: unary operator

goto Lif x cop y goto L

jump or conditional jump to label Lcop: comparison operatoronly procedure-local jumps

x:= a[i]a[i]:= y a one-dimensional array

x : = & ax:= *y*x := y

a global, local variable or parameter& a address of a* dereferencing operator



3AC commands (2)

Syntax Explanation

param xcall preturn y

call p(x1, ..., xn) is encoded as:(block is considered as one command)param x1

...

param xn

call p

return y causes jump to return addresswith (optional) result y

We assume that 3AC only contains labelsfor which jumps are used in the program.



Basic blocks

A sequence of 3AC commands can be uniquely partitioned into basicblocks.

A basic block B is a maximal sequence of commands such that• at the end of B, exactly one jump, procedure call, or return

command occurs• labels only occur at the first command of a basic block



Basic blocks (2)

Remarks:• The commands of a basic block are always executed sequentially,

there are no jumps to the inside• Often, a designated exit-block for a procedure containing the

return jump at its end is required. This is handled by additionaltransformations.

• The transitions between basic blocks are often denoted by flowcharts.



Example: 3AC and basic blocks

Consider the following C program:Beispiel: (3AC und Basisblöcke)

Wir betrachten den 3AC für ein C-Programm:

int a[2];

int b[7];

int skprod(int i1, int i2, int lng) {... }

int main( ) {

a[0] = 1; a[1] = 2;

b[0] = 4; b[1] = 5; b[2] = 6;

skprod(0 1 2);skprod(0,1,2);

return 0;

}

3AC mit Basisblockzerlegung für die Prozedur main:

main:

a[0] := 1a[0] := 1

a[1] := 2

b[0] := 4

b[1] := 5

b[2] := 6

param 0

param 1

param 2

call skprod


return 0



Example: 3AC and basic blocks (2)

3AC with basic block partitioning for main procedure

Beispiel: (3AC und Basisblöcke)

Wir betrachten den 3AC für ein C-Programm:

int a[2];

int b[7];

int skprod(int i1, int i2, int lng) {... }

int main( ) {

a[0] = 1; a[1] = 2;

b[0] = 4; b[1] = 5; b[2] = 6;

skprod(0 1 2);skprod(0,1,2);

return 0;

}

3AC mit Basisblockzerlegung für die Prozedur main:

main:

a[0] := 1a[0] := 1

a[1] := 2

b[0] := 4

b[1] := 5

b[2] := 6

param 0

param 1

param 2

call skprod


return 0




Procedure skprod:Prozedur skprod mit 3AC und Basisblockzerlegung:

int skprod(int i1, int i2, int lng) {

int ix, res = 0;

for( ix=0; ix <= lng-1; ix++ ){

res += a[i1+ix] * b[i2+ix];

}

skprod:

}

return res;

}

res:= 0

ix := 0

t0 := lng-1

if ix<=t0

true false

t1 := i1+ix

t2 := a[t1]

t1 := i2+ix

t3 := b[t1]

t1 := t2*t3

return res

t1 := t2*t3

res:= es+t1

ix := ix+1





Procedure skprod as 3AC with basic blocks

Prozedur skprod mit 3AC und Basisblockzerlegung:

int skprod(int i1, int i2, int lng) {

int ix, res = 0;

for( ix=0; ix <= lng-1; ix++ ){

res += a[i1+ix] * b[i2+ix];

}

skprod:

}

return res;

}

res:= 0

ix := 0

t0 := lng-1

if ix<=t0

true false

t1 := i1+ix

t2 := a[t1]

t1 := i2+ix

t3 := b[t1]

t1 := t2*t3

return res

t1 := t2*t3

res:= es+t1

ix := ix+1




Intermediate Language Variations

3 AC after elimination of array operations (at above example)

Variation im Rahmen einer Zwischensprache:

3-Adress-Code nach Elimination von Feldoperationen

anhand des obigen Beispiels:

skprod:p

res:= 0

ix := 0

t0 := lng-1

if ix<=t0

t1 := i1+ix

tx := t1*4

ta := a+tx

true false

return res

t2 := *ta

t1 := i2+ix

tx := t1*4

tb := b+tx

t3 *tbt3 := *tb

t1 := t2*t3

res:= res+t1

ix := ix+1




Characteristics of 3-Address Code

• Control flow is explicit.• Only elementary operations• Rearrangement and exchange of commands can be handled

relatively easily.


Languages for Intermediate Representation Other Intermediate Languages

3.1.3 Other Intermediate Languages



Further Intermediate Languages

We consider• 3AC in Static Single Assignment (SSA) representation• Stack Machine Code



Single Static Assignment Form

If a variable a is read at a program position, this is a use of a.

If a variable a is written at a program position, this is a definition of a.

For optimizations, the relationship between use and definition ofvariables is important.

In SSA representation, each variable has exactly one definition. Thus,relationship between use and definition in the intermediate language isexplicit.



Single Static Assignment Form (2)

SSA is essentially a refinement of 3AC.

The different definitions of one variable are represented by indexingthe variable.

For sequential command lists, this means that• at each definition position, the variable gets a different index.• at the use position, the variable has the index of its last definition.



Example: SSA

In SSA-Repräsentation besitzt jede Variable genau

eine Definition. Dadurch wird der Zusammenhang

ischen An end ng nd Definition in derzwischen Anwendung und Definition in der

Zwischensprache explizit, d.h. eine zusätzliche

def-use-Verkettung oder use-def-Verkettung wird

unnötig.

SSA ist im Wesentlichen eine Verfeinerung von 3AC.

Die Unterscheidung zwischen den Definitionsstellen

wird häufig durch Indizierung der Variablen dargestelltwird häufig durch Indizierung der Variablen dargestellt.

Für sequentielle Befehlsfolgen bedeutet das:

• An jeder Definitionsstelle bekommt die Variable

einen anderen Indexeinen anderen Index.

• An der Anwendungsstelle wird die Variable mit

dem Index der letzten Definitionsstelle notiert.

a := x + y

Beispiel:

a := x + y 1 0 0

b := a – 1

a := y + b

b := x * 4

a := a + b

b := a - 1

a := y + b

b := x * 4

a := a + b

1 1

2

2

0

0 1


a := a + b a := a + b 3 2 2



SSA - Join Points of Control Flow

At join points of control flow, an additional mechanism is required:

An Stellen, an denen der Kontrollfluß zusammen-

führt bedarf es eines zusätzlichen Mechanismus:führt, bedarf es eines zusätzlichen Mechanismus:

3 2 2a := x + y a := a – b1 0 0

?b := a3

...

Einführung der fiktiven Orakelfunktion“ ! dieEinführung der fiktiven „Orakelfunktion !, die

quasi den Wert der Variable im zutreffenden Zweig

auswählt:

3 2 2a := x + y a := a – b1 0 0

a := !(a ,a )b := a

43

1 34


...



SSA - Join Points of Control Flow (2)

Introduce an "oracle" Φ that selects the value of the variable of the usebranch:

An Stellen, an denen der Kontrollfluß zusammen-

führt bedarf es eines zusätzlichen Mechanismus:führt, bedarf es eines zusätzlichen Mechanismus:

3 2 2a := x + y a := a – b1 0 0

?b := a3

...

Einführung der fiktiven Orakelfunktion“ ! dieEinführung der fiktiven „Orakelfunktion !, die

quasi den Wert der Variable im zutreffenden Zweig

auswählt:

3 2 2a := x + y a := a – b1 0 0

a := !(a ,a )b := a

43

1 34


...



SSA - Remarks

• The construction of an SSA representation with a minimal numberof applications of the Φ oracle is a non-trivial task.(cf. Appel, Sect. 19.1. and 19.2)

• The term single static assignment form reflects that for eachvariable in the program text, there is only one assignment.Dynamically, a variable in SSA representation can be assignedarbitrarily often (e.g., in loops).



Further intermediate languages

While 3AC and SSA representation are mostly used as intermediatelanguages in compilers, intermediate languages and abstractmachines are more and more often used as connections betweencompilers and runtime environments.

Java Byte Code and CIL (Common Intermediate Language, cf. .NET)are examples for stack machine code, i.e., intermediate results arestored on a runtime stack.

Further intermediate languages are, for instance, used foroptimizations.



Stack machine code as intermediate language

Homogeneous scenario for Java:Sprachlich homogenes Szenario bei Java:

C1.java

C2.javajikes

C1.class

C2 class

Java ByteCode

C2.java

C3.java javac2

C2.class

C3.class

JVM

Sprachlich ggf. inhomogenes Szenario bei .NET:

ProgrammeIntermediate

C# -

C il

prog1.cs prog1.il

verschiedener

Hochsprachen

Intermediate

Language

Compilerprog2.cs prog2.il

prog3.il

CLR

Haskell -

Compilerprog3.hs

Java-ByteCode und die MS-Intermediate Language

sind Beispiele für Kellermaschinencode, d.h.

Z i h b i d f i L f itk ll


Zwischenergebnisse werden auf einem Laufzeitkeller

verwaltet.



Stack machine code as intermediate language (2)

Inhomogeneous scenario for .NET:

Sprachlich homogenes Szenario bei Java:

C1.java

C2.javajikes

C1.class

C2 class

Java ByteCode

C2.java

C3.java javac2

C2.class

C3.class

JVM

Sprachlich ggf. inhomogenes Szenario bei .NET:

ProgrammeIntermediate

C# -

C il

prog1.cs prog1.il

verschiedener

Hochsprachen

Intermediate

Language

Compilerprog2.cs prog2.il

prog3.il

CLR

Haskell -

Compilerprog3.hs

Java-ByteCode und die MS-Intermediate Language

sind Beispiele für Kellermaschinencode, d.h.

Z i h b i d f i L f itk ll


Zwischenergebnisse werden auf einem Laufzeitkeller

verwaltet.



Example: Stack machine code

Beispiel: (Kellermaschinencode)

package beisp;

class Weltklasse extends Superklasse

implements BesteBohnen {

Qualifikation studieren ( Arbeit schweiss){

return new Qualifikation();

}}

}

Compiled from Weltklasse.java

class beisp Weltklasse extends beisp Superklasseclass beisp.Weltklasse extends beisp.Superklasse

implements beisp.BesteBohnen{

beisp.Weltklasse();

beisp.Qualifikation studieren( beisp.Arbeit);

}

Method beisp.Weltklasse()

0 aload_0

1 invokespecial #6 <Method beisp.Superklasse()>

4 return

Method beisp.Qualifikation studieren( beisp.Arbeit )

0 new #2 <Class beisp.Qualifikation>

3 dup

4 invokespecial #5 <Method beisp.Qualifikation()>

7 areturn7 areturn

Bemerkung:

Weitere Zwischensprachen werden insbesondere auch



im Zusammenhang mit Optimierungen eingesetzt.



Example: Stack machine code (2)

Beispiel: (Kellermaschinencode)

package beisp;

class Weltklasse extends Superklasse

implements BesteBohnen {

Qualifikation studieren ( Arbeit schweiss){

return new Qualifikation();

}}

}

Compiled from Weltklasse.java

class beisp Weltklasse extends beisp Superklasseclass beisp.Weltklasse extends beisp.Superklasse

implements beisp.BesteBohnen{

beisp.Weltklasse();

beisp.Qualifikation studieren( beisp.Arbeit);

}

Method beisp.Weltklasse()

0 aload_0

1 invokespecial #6 <Method beisp.Superklasse()>

4 return

Method beisp.Qualifikation studieren( beisp.Arbeit )

0 new #2 <Class beisp.Qualifikation>

3 dup

4 invokespecial #5 <Method beisp.Qualifikation()>

7 areturn7 areturn

Bemerkung:




im Zusammenhang mit Optimierungen eingesetzt.



3.2 Translation of Imperative Language Constructs


Translation of Imperative Language Constructs Basic Concepts and Memory Organization

3.2.1 Basic Concepts and Memory Organization



Introduction

Difficulties of learning about translation:• Translation is source language dependent• Translation is target language dependent

Explanation approach:• Basic concepts in detail using

I a TOYC procedural language as sourceI SIRL as target language

• Other language features in a less detailed manner



TOYC - a sublanguage of C (Decls & Statements)

Program ( GlobDeclList )GlobDeclList * GlobDeclGlobDecl = Var | Array | ProcVar ( Ident id )Array ( Ident id, int size )Proc ( Ident id, ParamList parl, LocDeclList ldl, Stmt body )ParamrList * ParamParam ( Ident id )LocDeclList * Var

Stmt = VarAssign | ArrAssign | Call | StmtList | If | WhileVarAssign ( UsedId uid, Exp rhs )ArrAssign ( UsedId uid, Exp ixe, Exp rhs )Call ( UsedId uid, ExpList )StmtList * StmtIf ( Exp c, Stmt then, Stmt else )While ( Exp c, Stmt body )



TOYC - Context conditions

Every TOYC program declares• an array input containing the program input at the start of

program• an array output for the program results• a parameterless procedure main



Translation of TOYC to SIRL

Main aspects of the translation:• mapping global variables, arrays, parameters, local variables to

the “storing facilities” of SIRL:I main memoryI temporaries

• realizing array accesses by address computations• translation of expressions• translation of statements• translation of procedures



Memory organization - basic ideas

Memory is organized into segments:• static data: for global variables and arrays (this segment also

stores constant strings and other static data)• stack: because of recursion, actual parameters, local variables

and arrays need storage for every active procedure incarnation:I stack grows with a call: a new stack frame is pushedI stack shrinks after a call: last stack frame is popped

(managed by SIRL’s CALL expression)• heap: for dynamically allocated variables (not needed for TOYC)• code: for storing the program code (not needed for SIRL)



Memory organization - example

stack

free memory

heap

static data

code

high address

low address



Layout of typical stack frame

For procedures with results, additional memory is needed (where?)



Memory organization for TOYC to SIRL

• global variables and arrays are stored in memory• parameters and local variable are stored in temporaries;

procedure with n parameters usesI TEMP(0),..., TEMP(n − 1) for the parametersI TEMP(n), ... for the local variables

• CALL expression implicitly manages the different copies of thetemporaries


Translation of Imperative Language Constructs Translation of Variables and Data Types

3.2.2 Translation of Variables and Data Types



Translation of variables and data types

The translation of variables and data types comprises:

• handling of primitive data types• conversion of data types (e.g. int→ float)• memory organisation• translation of arrays• translation of records and classes• implementation of dynamic objects



Primitive data types

Usually, the primitive data types of source languages are supported bythe target language:• int, long→ 4 byte word with integer arithmetic• float, double→ accordingly

Potentially, data types have to be encoded:• boolean→ 1 byte or 4 byte words

Problem, if target language does not comply to requirements ofsource language, e.g.• floating point arithmetic is not handled according to IEEE standard• overflows are not dealt with correctly

(cmp. Java FP-strict expressions)• operations for conversion are missing on target machine



Primitive data types in TOYC

• TOYC only supports four byte integers as primitive values• true and false are handled by 1 and 0



Translation of arrays

Efficient translation of arrays is important for many tasks.

One-dimensional static arrays

• Allocate memory in the segment for static data (starting at sd)• Address computation with base address of array, index of array

element and size of element type

Consider the array declaration T tarr[57]:

• Let Rrel contain the relative address of the array tarr• Let Ri contain the index i of the array component

If k = sizeof (T ), then the address of tarr[i] is sd + Rrel + k ∗ Ri .



Translation of arrays for TOYC

• every array in TOYC has an attribute baseAddr holding its baseaddress sd + Rrel

• an access myarr [i] to an array myarr is translated to

MEM (+(baseAddr(myarr), *(e(i), CONST 4))))

where e(i) is the expression for i• Code example for array access in SIRL: see lecture• Translation example from TOYCarray to SIRL: see lecture



TOYCarray - a sublanguage of TOYC

Program ( GlobDeclList )GlobDeclList * GlobDeclGlobDecl = Var | Array | ProcVar ( Ident id )Array ( Ident id, int size )Proc ( Ident id, StmtList body )

Stmt = VarAssign | ArrAssignVarAssign ( UsedId uid, Exp rhs )ArrAssign ( UsedId uid, Exp ixe, Exp rhs )StmtList * Stmt

Exp = IntConst | ArrayAccess | VarExpIntConst ( int i )ArrayAccess ( UsedId uid, Exp e )VarExp ( UsedId uid )UsedId ( Ident id )



More about translation of arrays

Multi-dimensional static arrays

Consider as example the Pascal declaration

var a:array[-5..5][1..9] of integer;

which corresponds to 99 integer variables:

a[-5, 1] ... a[-5,9]...a[5,1] ... a[5,9]

Matrix is stored in rows in memory. Storing in rows is more efficientthan storing columns as second index is often incremented in innerloops.



More about translation of arrays(2)

Translation of access to a[E1,E2]:

Assume results of evaluating E1 and E2 are stored in t1 and t2.

As a is a static array, we know the dimensions at compile time.

a[t1,t2] is the r-th component of a linear array with

r = (t1− (−5)) ∗ ((9− 1) + 1) + (t2− 1)= 9 ∗ t1 + 45 + t2− 1= 9 ∗ t1 + t2 + 44

Translation:Store the address of the 44-th component as base address of the arrayin symbol table. Then it suffices to add 9 ∗ t1 + t2 to base address.



General Translation of Arrays

General array declaration of dimension k

var a: array [u1..o1], ...., [uk..uk] of T;

Storing rows yields the following adress for accessing a[R1, ..., Rk]:

r = (R1− u1) ∗ size(array [u2..o2, ...,uk ..ok ] of T )+ (R2− u2) ∗ size(array [u3..o3, ...,uk ..ok ] of T )+ . . .+ (Rk − uk) ∗ size(T )



General Translation of Arrays (2)

For i = 1, . . . , k − 1, it holds that

size(i) := size(array [u{i + 1}..o{i + 1}, ...,uk ..ok ] of T )

size(k) = size(T )

This impliessize(i − 1) = size(i) ∗ (oi − ui + 1)

Simplification yields:

r =k∑

i=1

Ri ∗ size(i)−k∑

i=1

ui ∗ size(i)

At runtime, only the first summand has to be computed for which codehas to be generated.



Array Access

Remarks:• Computation of array indices offers great potential for

optimizations.• For translation of dynamic arrays, addressing has to be

generalized appropriately. (cf. Wilhelm/Maurer, Sect. 2.6.2)



Translation of Records

Translation of records is similar to translation of arrays:• Determine size and memory layout• Compute adresses for selection of record components and pointer

dereferencing• Translation of record operations, e.g. assignments to record

components

Recommended Reading: Wilhelm, Maurer, Section 2.6.2



Implementation of Dynamic Objects

Dynamic objects = dynamically allocated variables and objects in thesense of OO programing

Dynamic objects are stored on the heap:• number/size of dynamic objects is not known at compile time,

objects are created at runtime• dynamic objects often have a designated lifetime which disallows

handling them on the stack

Memory representation and addressing of components is similar tostatic records.



Implementation of Dynamic Objects (2)

Example:

Implementierung dynamischer Objekte

Dynamische Objekte werden hier als Sammelbegriff fürDynamische Objekte werden hier als Sammelbegriff fürdynamisch allozierte Variable und Objekte im Sinne der OO-Programmierung verwendet.

Dynamische Objekte werden auf der Halde verwaltet:Dynamische Objekte werden auf der Halde verwaltet:

• Ihre Anzahl ist im Allg. zur Übersetzungszeit nicht

bekannt. Deshalb werden sie erst zur Laufzeit erzeugt.

• Sie haben eine Lebensdauer die eine kellerartigeSie haben eine Lebensdauer, die eine kellerartige

Behandlung im Allg. nicht zulässt.

Beispiel: (dynamische Objekte)Beispiel: (dynamische Objekte)

typedef struct listelem {

int head;

struct listelem* tail; }* list;

# define listelemSIZE sizeof(struct listelem{

int h; struct listelem* t;})

list append( int i list l ) {list append( int i, list l ) {

list lvar = (list) calloc(1,listelemSIZE);

lvar->head = i;

lvar->tail = l;

return lvar;


}

...



Dynamic Memory Management

Dynamic memory management• is handled by runtime environment• can be supported by compiler• can partially be handled by user program

Runtime environment provides operations for dynamic memorymanagement:• for the programmer, e.g. in C malloc, calloc, realloc, free• for the compiler as in Pascal, Java, Ada• no memory deallocation by programer possible, but garbage

collection by runtime environment e.g. in Java



Dynamic Memory Management (2)

General Problem: Provide memory blocks of different sizes from alinear memory and reuse memory after it has been freed

Simple memory management by linear list of free memory areas

Structure of free memory area of variable length:

user datasize

header

free usedused free used

freelist




List of free memory areas:user datasize

header

free usedused free used

freelist

Procedure to allocate and deallocate memory:

• Allocate memoryI Search memory area B of appropriate sizeI Update references:

• If area has exactly required size, remove it from list.• Else update header of area, create header for rest of free memory

and add this area instead of the old area to list.




I Return pointer to memory cell after header (size information has tobe kept.)

I If no memory area of required size is found, new memory has to berequested from the OS

• Free memoryI Find header for memory area to be freed by pointer to this areaI If previous or next memory areas are free, join the areasI Add resulting memory area to list




Remarks:

• If program writes over assigned memory area, references or sizeinformation can be destroyed with bad consequences.

• If memory cannot be allocated in bytes, alignment restrictionshave to be obeyed.

• For practical use the above principle can be improved byI non linear searchI search for exact memory areas, avoiding defragmentationI support for joining memory areas after deallocation


Translation of Imperative Language Constructs Translation of Expressions and Statements

3.2.3 Translation of Expressions and Statements



Translation of Expressions

Aspects for translation of expressions• Management of intermediate results• Translation of source language operations

I no counterpart in target languageI addressingI context-dependent, e.g.: boolean expression in condition is handled

differently from boolean expression in assignment

• Treatment of procedure calls (next subsection)



Translation of Statements

Aspects for translation of statements

• Translation of compound statements to jumps

• Generation of unique labels

• Treatment of procedure calls (next subsection)



Example: Translation of simplified TOYC - fragment (2)

In the first version, we consider a simplified translation where• TOYC expressions are translated to SIRL expressions• boolean expression for “and” (&&), “or” (||), “not” (!) are omitted• the context of the expression is not considered

The attributions for

IntConst ( int i )ArrayAccess ( UsedId uid, Exp e )UsedId ( Ident id )

are as described in the previous subsection.For the extended attribution of

VarExp ( UsedId uid )

and of the expressions: see lecture



Discussion and extension

Shortcomings:• bad code for conditionals• we haven’t covered boolean expression

Approach to overcome shortcomings:• context-dependent translation for relational expressions• translation of non-strict boolean expression using jumps



Context-dependent translation

We illustrate a translation that uses context information by thetranslation of non-strict boolean expressions.

More precisely, we translate TOYC to SIRL’ where

SIRL’ = SIRL - { CJUMP(o,e1,e2, t , f ) } + { CJUMP(e, label) }

i.e., we use a different conditional jump instruction

Semantics: (similar to Piglet)CJUMP(e, label) Jump if e evaluates to 0; otherwise

continue execution with next statement



Context-dependent translation of TOYC

The translation of expressions has to distinguish two contexts:• In contexts: If, While, BoolExp

generate a conditional jump (jcx = true: jump context)• In contexts: VarAssign, ArrAssign, ArithmExp, Relation,

ArrayAccess, or ExpListgenerate a SIRL-expression that returns a value (jcx = false:value context)

where jcx is the inherited attribute denoting the kind of context.



Examples for context-dependent translation

Let’s assume a, b, and c are stored in temporaries TEMP(a),TEMP(b),and TEMP(c) resp.

Translate:

a = (a || b) && (c+1);

if( a && ((!b) || c) ) Stmt1 else Stmt2

Result: see lecture



Attribute definitions



Attribution for VarExp



Attribution for IntConst



Attribution for ArrayAccess



Attribution for Not



Attribution for And



Attribution for Or



Attribution for Add



Attribution for Lt



Attribution for If



Attribution for While



Attribution for VarAssign



Attribution for ArrAssign



Recommended Reading:

• Wilhelm, Maurer: Sec. 2.4, pp. 12 –16

• Appel: Sec. 7.2


Translation of Imperative Language Constructs Simplifying the Intermediate Representation

3.2.4 Simplifying the Intermediate Representation



Goals and techniques

Goals:• Simplification of the IR for later phases• Translation of one IR language to another one

Techniques:• Attribute grammars• Term rewriting:

I Define rules of how source patterns are replaced by target patternsI Apply the rules as long as possible



Example: Target language

The simpler language has:• no recursive expressions, simplified jump• no statement expression

SStmt = SMove | SCJump | Label | SStmtListSMove ( Temp SExp )SCJump ( SExp String )

SExp = Temp | SBinExpSBinExp ( Temp Temp )



Example: Attributes

Idea:• Statements have an attribute of type SStmtList

• Expressions have an attribute of typeI SStmtList: for the statements needed for the evaluationI SExp: for the expression evaluating the resultI String: for the generation of unique temporary names

More precisely:

syn SStmt Stmt.code()syn SStmt Exp.code()syn SExp Exp.sexp()syn String Exp.uniqueStr()



Example: Attribute rules

The following slides present the attribute rules for Move, CJump,StmtExp, BinExp.

The rules for StmtList, Label, and Temp are straightforward.

Notation: We use• @ as infix operator to append two statement lists• [e1, ...,en] to construct a list from elements e1, ...,en



Attribution for


Translation of Object-Oriented Language Constructs

3.3 Translation of Object-Oriented LanguageConstructs


Translation of Object-Oriented Language Constructs Concepts of Object-Oriented Programming Languages

3.3.1 Concepts of Object-Oriented ProgrammingLanguages



Concepts of Object-Oriented Programming Languages

We consider a class-based language and use Java as an example.

Important Concepts:• Classes and Object Creation• Encapsulation• Subtyping and Inheritance• Dynamic Method Binding



Example: Object-Oriented Language ConceptsBeispiel: (objektorientierte Sprachkonzepte)

class Person {

String name;String name;

int gebdatum; /* in der Form JJJJMMTT */

Person( String n, int gd ) {

name = n;

gebdatum = gd;gebdatum gd;

}

public void drucken() {

System.out.println("Name:"+ this.name);

System.out.println("Geb:"+ this.gebdatum);

}

boolean hat_geburtstag ( int datum ) {

return (this.gebdatum%10000) ==

(datum%10000);

}}

}

class Student extends Person {

int matrikelnr;

int semester;int semester;

Student(String n,int gd,int mnr,int sem) {

super( n, gd );

matrikelnr = mnr;

semester = sem;semester sem;

}


super.drucken();

System.out.println( "Mnr:"+ matrikelnr);

i


System.out.println( "Sem:" + semester);

}

}



Example: Object-Oriented Language Concepts (2)

Beispiel: (objektorientierte Sprachkonzepte)

class Person {

String name;String name;


Person( String n, int gd ) {

name = n;

gebdatum = gd;gebdatum gd;

}


System.out.println("Name:"+ this.name);

System.out.println("Geb:"+ this.gebdatum);

}

boolean hat_geburtstag ( int datum ) {

return (this.gebdatum%10000) ==

(datum%10000);

}}

}

class Student extends Person {

int matrikelnr;

int semester;int semester;

Student(String n,int gd,int mnr,int sem) {

super( n, gd );

matrikelnr = mnr;

semester = sem;semester sem;

}


super.drucken();

System.out.println( "Mnr:"+ matrikelnr);

i


System.out.println( "Sem:" + semester);

}

}



Example: Object-Oriented Language Concepts (3)

class Test {

public static void main( String[] argv ) {

int i;

Person[] pf = new Person[3];Person[] pf new Person[3];

pf[0] = new Person( "Meyer", 19631007 );

pf[1] = new Student("M\"uller",19641223,758475,5);

pf[2] = new Student("Planck",18580423,3454545,47);

for( i = 0; i<3; i = i+1 ) {

pf[i].drucken();pf[i].drucken();

}

} }

Das Beispiel zeigt Klassen, Objekterzeugung, Vererbung (mit Subtyping und Spezialisierung) sowieVererbung (mit Subtyping und Spezialisierung) sowie dynamisches Binden von Methoden.

Anhand des obigen Beispiels erläutern wir die

3.2.2 Umsetzung mitprozeduralen Sprachen

Anhand des obigen Beispiels erläutern wir die grundlegenden Übersetzungsschemata:

Klassen, Klassentypen ! Verbundtypen, Zeigertypen

Objekterzeugung ! Allokation dyn. Variablen/ObjekteObjekterzeugung ! Allokation dyn. Variablen/Objekte

Methoden, Konstruktoren ! Prozeduren

dyn. Bindung ! Verwendung von Prozedurzeigern

mit Selektion von Verbundkomponenten


mit Selektion von Verbundkomponenten

Als Zielsprache verwenden wir hier C.

The example demonstrates classes, object creation, inheritance (withsubtyping and specialization) and dynamic method binding.


Translation of Object-Oriented Language Constructs Translation into Procedural Languages

3.3.2 Translation into Procedural Languages



Translation into Procedural Languages

Translation Schemes:

• Classes, class types→ record types, pointer types• Object creation→ Allocation of dynamic variables/objects• Methods, constructors→ procedures• Dynamic binding→ Use of procedure pointers with selection of

record components

We illustrate these schemes at the above example. The consideredtarget language is C.



Translation of Types and Methods

• Basis data types of Java→ basis data types of C, for example:I int→ intI boolean→ int

(typedef int boolean;)• Reference types of Java→ pointer types of C, for example:

I String→ String*I Person→ Person*

where String and Person are record types in C.



Implementation of Example in C

Fields are realized by record types:

Übersetzung der Typen und Methoden:

Basisdatentypen von Java ! Basisdatentypen von

z.B. int nach int boolean nach int

R f t J ! Z i t C

( typedef int boolean; )

Referenztypen von Java ! Zeigertypen von C

z.B. String nach String*Person nach Person*

wobei String und Person in C geeignete Verbundtypeni d Wi b t ht di I l ti

typedef struct sPerson Person;

struct sPerson {

String* name;

sind. Wir betrachten die Implementierung von Person:

g ;


void (*drucken)( Person* );

boolean (*hat_geburtstag)( Person*, int );

};

Methoden werden als Prozeduren realisiert:

void Person_drucken( Person* this ) {

printf("Name:%s\n", this->name );printf( Name:%s\n , this >name );

printf("Geb:%d\n",this->gebdatum);

}

boolean Person_hat_geburtstag

(Person* this,int datum){


(Person this,int datum){

return (this->gebdatum%10000)==(datum%10000);

}



Implementation of Example in C (2)

Methods are realized by procedures:

Übersetzung der Typen und Methoden:

Basisdatentypen von Java ! Basisdatentypen von

z.B. int nach int boolean nach int

R f t J ! Z i t C

( typedef int boolean; )

Referenztypen von Java ! Zeigertypen von C

z.B. String nach String*Person nach Person*

wobei String und Person in C geeignete Verbundtypeni d Wi b t ht di I l ti

typedef struct sPerson Person;

struct sPerson {

String* name;

sind. Wir betrachten die Implementierung von Person:

g ;


void (*drucken)( Person* );

boolean (*hat_geburtstag)( Person*, int );

};

Methoden werden als Prozeduren realisiert:

void Person_drucken( Person* this ) {

printf("Name:%s\n", this->name );printf( Name:%s\n , this >name );

printf("Geb:%d\n",this->gebdatum);

}

boolean Person_hat_geburtstag

(Person* this,int datum){


(Person this,int datum){

return (this->gebdatum%10000)==(datum%10000);

}



Implementation of Example in C (3)

Constructors are realized as procedures:

Person* PersonK( String* n, int gd ) {

Konstruktoren werden als Prozeduren realisiert:

Person PersonK( String n, int gd ) {

Person* this =

(Person*) malloc( sizeof(Person) );

this->name = n;

this->gebdatum = gd;

hi d k d kthis->drucken = Person_drucken;

this->hat_geburtstag = Person_hat_geburtstag;

return this;

}

Übersetzung von Vererbung/Spezialisierung:

Bzgl. der Verbundkomponenten wird Vererbung g p gim Wesentlichen durch Duplikation realisiert:

typedef struct sStudent Student;

struct sStudent {

String* name;


void (*drucken)( Student* );

boolean (*hat_geburtstag)( Student*, int );

int matrikelnr;int matrikelnr;

int semester;

};

Zu beachten ist die notwendige Typanpassung beimi li it A t i d U t kl “


impliziten Argument in der „Unterklasse“.



Translation of Inheritance and Specialization

Inheritance with respect to record components is realized byduplication:

Person* PersonK( String* n, int gd ) {

Konstruktoren werden als Prozeduren realisiert:

Person PersonK( String n, int gd ) {

Person* this =

(Person*) malloc( sizeof(Person) );

this->name = n;


hi d k d kthis->drucken = Person_drucken;

this->hat_geburtstag = Person_hat_geburtstag;

return this;

}

Übersetzung von Vererbung/Spezialisierung:

Bzgl. der Verbundkomponenten wird Vererbung g p gim Wesentlichen durch Duplikation realisiert:

typedef struct sStudent Student;

struct sStudent {

String* name;


void (*drucken)( Student* );

boolean (*hat_geburtstag)( Student*, int );

int matrikelnr;int matrikelnr;

int semester;

};

Zu beachten ist die notwendige Typanpassung beimi li it A t i d U t kl “


impliziten Argument in der „Unterklasse“.Type conversions for implicit arguments of subclass are necessary.



Translation of Inheritance and Specialization (2)Inheritance with respect to methods can be realized without codeduplication. Methods of superclass can be reused after appropriatetype conversion.

Bzgl. der Methoden lässt sich Vererbung ohne

Codeduplikation umsetzen; die Methoden der

Oberklasse lassen sich nach geeigneter

Student* StudentK

(String* n int gd int mnr int sem ) {


Typkonvertierung unverändert verwenden:

(String* n,int gd,int mnr,int sem ) {

Student* this =

(Student*) malloc(sizeof(Student));

this->name = n;


this->matrikelnr = mnr;

this->semester = sem;

this->drucken = Student_drucken;

this->hat_geburtstag =

(boolean(*)(Student* int))(boolean(*)(Student*,int))

Person_hat_geburtstag;

return this;

}

Spezialisierung wird durch zusätzliche Attribute (s.o.)

und neue Prozeduren realisiert, die ggf. die

überschriebenen Methoden aufrufen:

void Student_drucken( Student* this ) {

Person_drucken( (Person*)this );

printf("Mnr:%d\n", this->matrikelnr );

printf("Sem:%d\n", this->semester );


p ( \ , );

}



Translation of Inheritance and Specialization (3)

Specialization is realized by additional attributes and procedures thatmay call overridden methods:

Bzgl. der Methoden lässt sich Vererbung ohne

Codeduplikation umsetzen; die Methoden der


Student* StudentK

(String* n int gd int mnr int sem ) {


Typkonvertierung unverändert verwenden:

(String* n,int gd,int mnr,int sem ) {

Student* this =

(Student*) malloc(sizeof(Student));

this->name = n;


this->matrikelnr = mnr;

this->semester = sem;

this->drucken = Student_drucken;

this->hat_geburtstag =

(boolean(*)(Student* int))(boolean(*)(Student*,int))

Person_hat_geburtstag;

return this;

}

Spezialisierung wird durch zusätzliche Attribute (s.o.)

und neue Prozeduren realisiert, die ggf. die

überschriebenen Methoden aufrufen:

void Student_drucken( Student* this ) {

Person_drucken( (Person*)this );

printf("Mnr:%d\n", this->matrikelnr );

printf("Sem:%d\n", this->semester );


p ( \ , );

}



Translation of Object Creation & Method Invocation

• Object creation corresponds to call of the constructor.• Method invocation is realized by selection and call of method

belonging to the object

Übersetzung von Objekterzeugung und Methodenaufruf:Methodenaufruf:

• Objekterzeugung entspricht einem „Konstruktoraufruf“;

• Methodenaufruf wird durch Selektion und

void main( String* argv[] ) {

int i;

Aufruf der zum Objekt gehörenden Methode realisiert.

Person* pf[3];

pf[0] = PersonK( "Meyer", 19631007 );

pf[1] = (Person*)

StudentK("M\"uller",19641223,758475,5);

pf[2] = (Person*)pf[2] = (Person*)

StudentK("Planck",18580423,3454545,47);

for( i = 0; i<3; i = i+1 ) {

pf[i]->drucken( pf[i] );

}}

}

Zu beachten ist die doppelte Angabe des Zielobjektspp g jbeim „Methodenaufruf“.

Dynamische Bindung wird also durch Verwendung vonProzedurzeigern erreicht.


g



Translation of Object Creation & Method Invocation (2)

Note the duplicate reference to the target object in a "method call".Dynamic binding is realized by usage of procedure pointers.

Remarks:

• Record components are not "inherited" and have to be re-listed foreach subclass.

• No usage of superclass constructor• Explicit type conversion necessary• Direct pointers to methods of an object use needlessly much

memory.• Dynamic binding only requires dereferencing which is almost as

efficient as an ordinary procedure call.


Translation of Object-Oriented Language Constructs Translation of Classes

3.3.3 Translation of Classes



Translation of Classes

Classes declare:• attributes (in Java: fields)• constructors• methods

In the following, we consider a language that supports only singleinheritance (cf. Java), i.e., each class (except Object) has exactly onesuperclass.



Object layout

Objects are handled as memory areas on the heap:• Each object of class C gets a variable for each inherited and for

each attribute declared in C (object state)• Additionally, it gets a variable for referring to information about

I the class andI its methods, the so-called virtual method table or v-table

• As object identity, often the start address of the memory area isused (or another appropriate address).



Example: Object layout

Objekte werden als Speicherbereiche auf

der Halde verwaltet:

Objektlayout:

der Halde verwaltet:

• Dabei enthält ein Objekt einer Klasse K für

jedes ererbte und jedes in K deklarierte

Attribut eine Variable (Objektzustand).

• Zusätzlich enthält es eine Variable, mittels der

Informationen über Methoden bzw. die Klasse

referenziert werden können.

• Als Identität des Objekts wird häufig die• Als Identität des Objekts wird häufig die

Anfangsadresse des Speicherbereichs

verwendet (bzw. eine geeignete andere Adresse).

Beispiel: (Objektlayout)

class A {

int a1;

private int a2;

Klassen- &

Methoden-

Informationprivate int a2;

}

Information

zu Klasse A

•class:

Objektreferenz

•class:

a1:

a2:

Wie bei Verbunden werden Attributinstanzen/Instanzvariablen


Wie bei Verbunden werden Attributinstanzen/Instanzvariablen

über eine Relativadresse (offset) bzgl. der Objektreferenz

adressiert.

Object Reference

Class and Method

Information for Class A

As for records, attribute instances/instance variables are addressed bya relative address (offset) with respect to the object reference.The size of the instance variables depends on their type. In Java, intand float variables require 4 bytes, long and double variables 8 bytes.



Example: Layout of subclass objects

class A {

int a1;

private int a2;

...

}

class B extends A {class B extends A {

int b;

...

}Klassen- &

Methoden-class C extends B {

int c;

}

Methoden

Information

zu Klasse C

Objektreferenz

•class:

a1:

a2:

j

b:

c:

Die Größe der einzelnen Instanzvariablen hängt selbst-

verständlich von deren Typ ab. So benötigt man in Java

für int- und float-Variablen beispielsweise 4 Byte, für

long- und double-Variablen 8-Byte.


Object Reference

Class and Method

Information for Class C



Sharing of v-tables and prefixing

V-tables can be shared among objects of the same class.For OO languages with single-inheritance, prefixing is used.

class A {int x = 0; int f() {...} }class B extends A {int g() {...} }class C extends B {int g() {...} }class D extends C {int y = 0; int f() {...} }

x x x xy

xy

A A_f B A_fB_g

C A_fC_g

D D_fC_g



Remarks: Object layout

• In the examples, we omitted instance variables of class Object.• Private instance variables of superclasses have to be present in

all instances of subclasses:

Bemerkungen:

• Im obigen Beispiel haben wir Attributinstanzen der

Klasse Object vernachlässigt

• Private Attributinstanzen von Oberklassen müssen

auch in Instanzen von Unterklassen vorhanden sein:

class A {

int a1;

private int a2;

int m() { return a2; }

}

class B extends A {

int b;

int n() { return m(); }int n() { return m(); }

}

• Zur Klassen- und Methodeninformation siehe unten.Zur Klassen und Methodeninformation siehe unten.

• Die Reihenfolge der Attributinstanzen ist wichtig,

um Subtyping zu ermöglichen:

Jedes Unterklassen-Objekt muss überall dort

eingesetzt werden können, wo ein Oberklassen-

Objekt erwartet wird.

Deshalb müssen die Attributinstanzen der

Oberklasse in Ober und Unterklasse Objekten


Oberklasse in Ober- und Unterklasse-Objekten

die gleiche Relativadresse besitzen.



Remarks: Object layout (2)

• Ordering of instance variables is important for subtyping:

Subclass objects can be used wheresuperclass objects are expected.

Thus, the instance variables of the superclass have to have thesame relative addresses in all sub- and superclass objects.



Example: Access to subclass objects

A avar = new B();... a.avar.a2...

The relative address of a2 has to be independent of the dynamic typeof avar.

The dynamic type of a reference-typed expression E in a state S is thecreation type of the object that is obtained by evaluating E in S.



Alternative object layout

In some cases, also an object descriptor is used. Here, the example ofa C object:

Beispiel: (Zugriff auf Unterklassen-Objekte)

A B()A avar = new B();

... avar.a2 ...

d.h. Relativadresse von a2 muss unabhängig vom

dynamischen Typ von avar sein wobei derdynamischen Typ von avar sein, wobei der

dynamische Typ eines referenzwertigen Ausdrucks E

in einem Zustand S der Typ des Objekts ist, das

man bei Auswertung von E in S erhält.

Alternatives Objektlayout:

Teilweise wird auch mit einem Objektdeskriptor

b it t hi B i i l i C Obj ktgearbeitet, hier am Beispiel eines C-Objekts:

Klassen- &

Methoden-Objektreferenz

Information

zu Klasse C•class:

•

Deskriptor

a1:

a2:

b:


c:

Object ReferenceClass and Method

Information for Class C

Descriptor



Alternative object layout (2)

Remarks:• Pros:

I all object descriptors have the same memory requirementsI memory block for instance variables can be more easily moved

(simplifies for instance garbage collection)• Cons:

I more memory per objectI additional dereferencing step for accessing instance variables



Class information

The content (and the extend) of the class information depends on thelanguage.Three typical examples:• Class information is not provided at runtime.• Class information contains all information required for dynamic

type conversion :A avar = new b();B bvar = (B) avar;

• Class information is represented by an object that allowsintrospection (requesting class information at runtime) andreflection (modifying the program at runtime).



Realization of methods

Method information allows accessing methods belonging to an object:• It provides the data structure for realization of dynamic binding• In class-based languages, all objects of a class have the same

methods; thus, method information of all objects of a class can bestored together



Virtual method table

Classically, method information is stored in a virtual method/functionstable. (For simplicity, class information is not shown)

Methodenrealisierung:

Die Methodeninformation ermöglicht den Zugriff aufdie zu einem Objekt gehörenden Methoden:die zu einem Objekt gehörenden Methoden:

• Sie liefert die Datenstruktur zur Realisierung des

dynamischen Bindens.

• Da bei klassenbasierten Sprachen alle Objekte p j

einer Klasse die gleichen Methoden haben, kannman die Methodeninformation aller Objekte einerKlasse gemeinsam speichern. Dadurch spart mangegenüber der Realisierung von 3.2.2 erheblichgegenüber der Realisierung von 3.2.2 erheblichan Speicher.

Wir betrachten hier die klassische Realisierung mit

einer Methodentabelle (virtual method/functions table):

class A {

int a1;

int a2;

int m() { ... }

Alle A-Objekte teilen sich mtab

() { }

int n( int i ) {...}

}

ObjektreferenzA::m

A::n

•mtab:

a1:

a2:

A::n


(Aus Gründen der Übersichtlichkeit haben wir aufdie Angabe von Klasseninformation verzichtet.)

Object Reference

all objects share mtab



Virtual method table (2)

• For each class, there exists exactly one method table. The pointerto the method table is set by the constructor.

• The method table contains pointers to the methodimplementations.

• This technique allows for subtyping, as the relative address of thesubclass methods can be chosen such that there are the sameaddresses in super- and subclasses.

• It further allows method overriding by changing the accordingmethod entry.



Method overriding

• Es existiert also für jede Klasse genau eineMethodentabelle. Der Zeiger auf die Methoden-tabelle wird vom Konstruktor gesetzttabelle wird vom Konstruktor gesetzt.

• Die Methodentabelle enthält Zeiger auf die

Methodenimplementierungen.

• Die Technik ermöglicht Subtyping, da die Relativ-g yp g,

adressen von Oberklasse-Methoden so gewähltwerden können, dass sie in Ober- und Unterklassegleich sind.

• Die Technik ermöglicht Überschreiben durch• Die Technik ermöglicht Überschreiben durch

Ausstausch des entsprechenden Eintrags(s. Beispiel)

Beispiel: (Überschreiben von Methoden)

class A {

int a1; •mtab:A::m

A::nint a2;

int m() { ... }

int n( int i ){...}

}

a1:

a2:

A::n

class B extends A {

int b;

int m() { ... }

void p() { ... }

•mtab:

a1:

B::m

A::n

B::p


} a2:p

b:



Method overriding (2)A method is addressed indirectly by the method table and the relativeaddress:

Adressierung einer Methode jeweils indirekt über

Methodentabelle und Relativadresse:Methodentabelle und Relativadresse:

A avar = new A();

... avar.m() ... // M[avar.mtab]+RA(m)

! A::m

... avar.n(7) ... // M[avar.mtab]+RA(n)

! A::n

A avar = new B();

() // M[ t b]+RA( )... avar.m() ... // M[avar.mtab]+RA(m)

! B::m

... avar.n(7) ... // M[avar.mtab]+RA(n)

! A::n

Wie bei den Instanzvariablen gewährleistet die richtigeWie bei den Instanzvariablen gewährleistet die richtige

Reihenfolge der Einträge in der Methodentabelle,

dass auf ein Unterklassen-Objekt wie auf ein

Oberklassen-Objekt zugegriffen werden kann.

Dabei werden automatisch überschreibende Methoden

ausgewählt, sofern vorhanden.




Method overriding (3)

As for instance variables, the correct ordering of the entries in themethod table allows that a subclass object can be accessed in thesame way as a superclass object.

Overriding methods are selected automatically, if applicable.



Realization of constructors

Constructors are realized by procedures. Source language semanticstypically requires the following for an object of class C:• Allocation of memory of the new C object• Calls of the constructors of all superclasses• Execution of the body of the called constructor of C• Potentially: class loading, initialisation of variables


Translation of Object-Oriented Language Constructs Problems of Multiple Inheritance

3.3.4 Problems of Multiple Inheritance



Multiple inheritance

The translation technique considered so far can only be used forlanguages with single inheritance. In this section, we sketch

• the concept of multiple inheritance• the problems associated with multiple inheritance

Multiple inheritance exists, for instance, in C++ or Eiffel.

With multiple inheritance, a class can inherit from several classes.



Multiple inheritance (2)

Example:Beispiel: (Mehrfachvererbung)

In folgendem Klassendiagramm erbt E mehrfach:

A

k3

k4

B

k1

k2

C D

k5 k2

k3

E

k6

Problematik:Problematik:

• Soll E die Attribute von A doppelt erben, d.h. von

jeder Komponente zwei Kopien besitzen?

(nur relevant im Zusammenhang mit Attributen)

• Wie sollen Namenskonflikte aufgelöst werden?

( E erbt zwei Komponenten mit Namen k2)

• Mit welchen Techniken können E-Objekte so realisiert


werden, dass sie auch als A-, B-, C- und D-Objekte

auftreten können?



Difficulties of multiple inheritance

• Does E inherit the attributes of A twice, i.e., does it contain twocopies of each component? (only relevant for attributes)

• How are name conflicts resolved? (E inherits two componentswith name k2)

• How can E objects be realized such that they can be used as A, B,C or D objects in the same way?



Difficulties of multiple inheritance (2)

Assuming, E inherits twice from A, an E object contains the followingcomponents:Unter der Annahme, dass E von A doppelt erbt,

besitzt ein E-Objekt die folgenden Komponenten:

E

B::k1

B::k2

A::k3

D C B A •

A::k3

A::k4

C::k5

A::k3

A::k4A::k4

D::k2

D::k3

E::k6

Mit obigem Komponentenlayout kann ein E-Objekt

direkt als B- und C-Objekt verwendet werden, nicht

aber als A- oder D-Objekt.

Lösungsansätze:

1. Implizite Typkonvertierung mit Veränderung der

Referenz in den SpeicherbereichReferenz in den Speicherbereich.

(Nachteil: ggf. Problem bei Objektidentität)

2. Adressierung mit klassenspezifischen, global

verwendbaren Relativadressen (s. Appel).

(N ht il i ht d l t P


(Nachteil: nicht modular, gesamtes Programm

muss bekannt sein).



Difficulties of multiple inheritance (3)

With the above object layout, E can be used directly as a B object or asa C object, but not as an A or D object.

Solutions:

• Implicit type conversion with modification of the reference into thememory area (drawback: potentially, problem with object identity)

• Addressing with class-specific, global relative addresses (cf.Appel, Sect. 14.3) (drawback: non-modular, complete programhas to be known)


Translation of Object-Oriented Language Constructs Further Aspects of Object-Oriented Languages

3.3.5 Further Aspects of Object-Oriented Languages



Further aspects of object-oriented languages

• Static methods• Nested classes• Virtual classes• Encapsulation aspects• Dynamic loading• Reflection



Example: Local classes

3.2.5 Weitere Aspekte bei OO-Sprachen

• statische Methoden

• geschachtelte Klassen

• virtuelle Klassen

• Kapselungsaspekte

• dynamisches Laden

• Reflexion

Beispiel: (Lokale Klassen)

class Outer {

Outer w( int j ) {

int i = 2;

class Local extends Outer {

Outer w( int jj ) {

System.out.println("i == " +i);

System.out.println("j == " +j);

return this;

}

}

System.out.println("j == " + j );

return new Local();


}

}



Example: Local classes (2)

public class LocalClassTest {

static public void main(String[] args){

Outer ov = new Outer();

ov.w( 5 ).w( 7 );

ov.w( 7 ).w( 9 );

}

}

Gibt es Fehler?

Was ist die Ausgabe und warum?Was ist die Ausgabe und warum?

Lesen Sie zu Abschnitt 3.2:

Wilhelm, Maurer:

Abschnitt 5 2 und Anfang von 5 3 (S 182 195)• Abschnitt 5.2 und Anfang von 5.3 (S. 182-195)

Appel:

• Sections 14.1-14.3, S. 303-310


Questions:

• Are there errors?• What is the output and why?



Literature

Recommended Reading:

• Wilhelm, Maurer: Sect. 5.2 and 5.3. (pp. 182 – 195)• Appel: Sect. 14.1–14.3, (pp. 303 – 310)


Translation of Procedures

3.4 Translation of Procedures



Translation of procedures and local objects

Most procedural languages support recursion, procedure-localvariables and nested procedures. In the following, we consider• Translation of recursive procedures• Translation of local variables• Translation of nested procedures

We do not consider the translation of procedures as parameters.



Procedures

The declaration of a procedure consists of• the name of the procedure• the declaration of the formal parameters• the declaration of local variables• the body of the procedure

Each dynamic call of a procedure corresponds to a procedureincarnation.

Analogy:• Procedure declaration→ procedure incarnation• Class declaration→ object / class instance



Dynamic call tree

The runtime behaviour of a procedural program can be described by acall tree.

Example (C-Program):

Das Laufzeitverhalten eines prozeduralen Programms

lässt sich durch den Prozeduraufrufbaum beschreiben.

Beispiel: (Prozeduraufrufbaum)

Wir betrachten folgendes C-Programm:

int even(int n){return n==0?1:odd(n-1);}

int odd (int n){return n==0?0:even(n-1);}

i i (){ (2)? (1) dd(1) }int main(){return even(2)?even(1):odd(1);}

main

even

odd

even

odd

even

Bemerkung:Bemerkung:

• Der Prozeduraufrufbaum ist eine abstrakte

Beschreibung des Laufzeitverhaltens und damit

abhängig von den Eingabewerten des Programms.


• Zu jedem Ausführungszeitpunkt gibt es einen aktiven

Pfad in dem Baum.



Dynamic call tree (2)

Remarks:• The call tree is an abstract description of the runtime behavior and

depends on the inputs of the program.• For each execution point, there is an active path in the tree.• In call trees, every node corresponds to a procedure incarnation.

In static or dynamic call graphs, every node corresponds to aprocedure declaration.



Translation of recursive procedures: Tasks

In (S)Piglet:• Each procedure incarnation had its “own set” of temporaries• Temporaries were used to pass parameters/results and to handle

local variables• Piglet semantics/machine handled multiple copies of temporaries

with the same nameIn lower-level machines:• Temporaries need to be managed in registers or memory• Parameter/result passing has to be managed explicitly by the

generated code• Registers have global scope and need to be managed across

procedure calls



Translation of recursive procedures: Basic aspects

• For each procedure incarnation, a stack frame is allocated. Thestack frame contains:

I actual parametersI the return addressI saved registersI further information

• Code is generated to manage the stack frame, in particular:I to pass actual parameter: on the stack or in registersI to save registers:

• caller-save: the caller saves the registers• callee-save: the callee saves the registers

I for the jumps to the procedure and for the returns

• Many aspects depend on the underlying machine and additionalcalling conventions



Layout of typical stack frame

In the following figure:• all parameters are passed on the stack.• Three registers are used to manage the frame

(stack/argument/frame pointer)



Code generation for procedures

Code is generated• at the call site

I to pass current parameters to procedure incarnationI to jump to the code of the procedure bodyI to make the procedure’s result available for subsequent processing

• at the beginning of the procedure (prolog)I saving (callee-safe) registersI set argument pointer

• at the end of the procedure (epilog)I restore registers

Note: Many tasks can be moved from the call site to the prolog andvice versa. As a procedure has only one prolog, but potentially manycall sites, it is more efficient to move the code to the prolog and epilog.



General translation scheme for procedure declarations

Übersetzungsschema für Prozedurdeklaration:

P D lM

ProcDecl

[ Label( “PROCBEG_“ + M) ] +< Prolog > +CSL +CSL +< Epilog > +[ Ret( ) ]

CSLIdent StatListParamList

Übersetzungsschema für Prozeduraufruf wobeiÜbersetzungsschema für Prozeduraufruf, wobei vorausgesetzt ist, dass der Code für die Liste der Parameterausdrücke (ExpList) das Kellernder aktuellen Parameter besorgt:

Call

CPL +[ Jump PLAB ] +< entfernen der Parameter vom Keller >

UsedIdPLAB CPL

ExpList


wobei PLAB die Ansprungmarke der Prozedur ist.

[LABEL (“PROCBEG_”+M)] +<Prolog> +CSL +<Epilog> +[JR $ra]



General translation scheme for procedure calls

Assume that code for list of parameter expressions ExpList pushescurrent parameters on stack.

Übersetzungsschema für Prozedurdeklaration:

P D lM

ProcDecl

[ Label( “PROCBEG_“ + M) ] +< Prolog > +CSL +CSL +< Epilog > +[ Ret( ) ]

CSLIdent StatListParamList

Übersetzungsschema für Prozeduraufruf wobeiÜbersetzungsschema für Prozeduraufruf, wobei vorausgesetzt ist, dass der Code für die Liste der Parameterausdrücke (ExpList) das Kellernder aktuellen Parameter besorgt:

Call

CPL +[ Jump PLAB ] +< entfernen der Parameter vom Keller >

UsedIdPLAB CPL

ExpList


wobei PLAB die Ansprungmarke der Prozedur ist.

CPL +[JAL PLAB] +<Code to remove parameters from stack>

Some machines have special commands for procedure calls (MIPS:JAL, JR)



Translation of procedure-local variables

Analogue to parameters, also procedure-local variables have to bestored in the stack frame, because there is one instance of the localvariables for each procedure incarnation.



Dynamic and static local variables

Local variables are static, if their size is known at compile time, elsethey are dynamic.

Example:

Lokale Variablen heißen statisch, wenn ihreGröße zur Übersetzungszeit bekannt ist, andernfallsdynamisch.

Beispiel: (statische/dynamische Variable)

Im folgenden C-Fragment sind i,j,k statische lokaleVariable; f und g sind dynamische Variable/Felder

void foo( int hsize ) {

int i, j;

Variable; f und g sind dynamische Variable/Felder,da ihre Größe vom Parameter size abhängt.

char f[ 2*hsize ];

int g[ hsize ];

int k;

...

}}

Speicherallokation geschieht im Prolog, bei dynamischen Variablen in Abhängigkeit von denaktuellen Parametern Übersetzer erzeugt dafür Codeaktuellen Parametern. Übersetzer erzeugt dafür Code.

Adressierung:

Prozedurlokale Variable werden relativ zu einem

Bezugspunkt im Kellerrahmen adressiert, z.B. relativ zum Argumentzeiger.

Bei der Adressierung dynamischer Variablen ist

im Allg ein zusätzlicher Indirektionsschritt notwendig


im Allg. ein zusätzlicher Indirektionsschritt notwendig,um statisch Relativadressen für alle lokalen Variablenfestlegen zu können.

where• i,j,k are static local variables• f, g are dynamic variables (arrays), because their size depends on

the parameter hsize.c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 172


Memory allocation for local variables

Memory allocation is done in the prolog of a procedureFor dynamic variables dependent on the actual parameters, code forallocation has to be generated.

Addressing: Local variables are addressed relative to a referencepoint in the stack frame, e.g. argument pointer/frame pointer.

For dynamic variables, an indirection step is necessary to staticallydefine relative addresses for all local variables.



Stack frame for procedure foo



Translation of nested procedures

For each procedure incarnation, there exist instances of the localvariables and of the parameters.

Problems:• How are non-local variables (neither local nor global) addressed?• Which instance of a non-local variable should be accessed?

These problems are also important for many functional languages.



Static and dynamic successors

• The direct static predecessor of a procedure declaration P is theprocedure declaration enclosing P in the source text.

• The direct static predecessor of a procedure incarnation P is thecurrent youngest procedure incarnation of the direct staticpredecessor of P.

• The direct dynamic predecessor of a procedure incarnation P isthe calling procedure incarnation.

• The static and dynamic predecessors are contained in thetransitive closure.



Nested procedures (example)Beispiel: (geschachtelte Prozeduren, die 2.)

proc P

var vp

proc Q

var vq

proc R

var vr

begin

(* hier vp, vq, vr adressierbar *)( p, q, )

call P

end

begin

(* hier vp und vq adressierbar *)(* hier vp und vq adressierbar *)

call R

end

proc S

begin

(* hier vp adressierbar *)

if ... then call S

if ... then call Q

end

begin

(* hier vp adressierbar *)

call S


end

here vp, vq, vr addressable

here vp, vq addressable

here vp addressable

here vp addressable



Call tree for example

Möglicher Prozeduraufrufbaum für das Beispiel:

P ! vp

S

QS

+1

+0 +0! vp

! vp ! vp, vqQ

R

S

+1

-2

! vp ! vp, vq

! vp, vq, vr

P

S

+1

! bedeutet “zugreifbar“ ! vp

! vp

Die Prozedurschachtelungstiefe (PST) ist einwichtiges Merkmal für die Übersetzung geschachtelterProzeduren. Für das obige Beispiel:g p

Prozedur PST aufrufbar

P 0 P, Q, S

Q 1 P Q RQ 1 P, Q, RR 2 P, Q, RS 1 P, Q, S

Ist PG eine von PA aufrufbare Prozedur dann gilt:


Ist PG eine von PA aufrufbare Prozedur, dann gilt:

PST(PG) ! PST(PA) + 1

denotes accessible

variables



Procedure nesting depth

The procedure nesting depth (PND) is important for the translation ofnested procedures.

If PG is a procedure that is callable from PA, then it holds that

PND(PG) ≤ PND(PA) + 1

In the example:

procedure PND callableP 0 P, Q, SQ 1 P, Q, RR 2 P, Q, RS 1 P, Q, S



Translation of nested procedures (approach)

• Which instance of a non-local (neither local nor global) variableshould be accessed?

Answer (Programming language semantics):If PI is a procedure incarnation accessing the non-local variable vof a procedure declaration P, chose the variable instance in thestatic predecessor of PI that belongs to P.

• How are non-local variables be addressed?

Answer (Translation technique):

1. Manage all static predecessors of a procedure incarnation.2. Access stack frame of the respective static predecessor via the

difference of the PND of the current procedure incarnation and theprocedure incarnation of the corresponding static predecessor.



Reference chain of static predecessors

• Each procedure incarnation has a reference to the procedureincarnation of its direct static predecessor (SPR).

• An incarnation is represented by the address of its argumentpointer AP.

• The static predecessor reference (SPR) is stored in the stackframe.



Stack frame with static predecessor



Reference chain of static predecessors

Snapshot of stack for example:

The procedure P has no static predecessors.c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 183


Relevant aspects for code generation

1. Addressing with static predecessor reference chain:

Let V be a variable with PND(V) = n, i.e. V is declared as a localvariable of a procedure P with PND(P) = n. Let RA(V) be the addressof V relative to the the argument pointer.

Let VA be an applied occurrence of V in a procedure Q (6= P) withPND(Q) = m and m > n.

The address of VA is obtained by m − n times dereferencing of thestatic predecessor references:

M[M[. . .M[AP] . . .]]︸︷︷︸m−n times

+RA(V )



Relevant aspects for code generation (2)

Remark:• The difference m − n is known at compile time for each applied

occurrence of a variable.

• The address of VA can in general not be handled directly by theaddressing techniques of the target machine. Instead, separatecommands have to be used that are executed each time thevariable is accessed.



Relevant aspects for code generation (3)

2: Management of static predecessor reference chain:

Let ∆ PND =def PND(caller) - PND (callee). We distinguish two cases:

• ∆ PND = -1: Argument pointer of caller is stored as SPR of callee.

• ∆ PND > -1: Follow SPR chain of the caller for ∆ PND steps. Theresulting SPR is the SPR of the callee.



Discussion

Remarks:

• The SPR chain can relatively easily be realized.

• Addressing of non-local variables can be inefficient.



Local display

Observation:The number of static predecessors of a procedure (incarnation) P isknown at compile time: PND (P).

Thus:All static predecessors of a procedure incarnation can be directlystored in the stack frame (instead of SPR chain).

The stack area to store the static predecessors is called local display.Instead of one word for the SPR, we store PND(P) words.



Stack frame with local display



Snapshot of stack for example with local display



Using local displays

1. Addressing with local display

Let V, n, RA(V), VA and m defined as above, and m >n . The addressof VA is obtained by:

M[AP − 4 ∗ (m − n)] + RA(V )

2. Management of the local display:

Let ∆ PND =def PND(caller) -PND (callee). We distinguish two cases:1. ∆ PND = -1: Display of caller + AP of caller2. ∆ PND > -1: Display of caller - ∆ PND Entries

Remarks:• Addressing of non-local variables is more efficient with local

display.• In general, more memory space on stack is required.



Global display

Observation:Many entries in the local display are identical.

Goal:Store display in global memory region. This memory area is calledglobal display.



Snapshot of stack for example with global display



Using global displays

1. Addressing with global display

Addressing with global display is like addressing with local display, butinstead of AP the address of global display is used.

2. Management of the global display:

Problem: Global display is changed on a procedure call if procedureswith lower PND are executed that are later called by procedures withhigher PND.

Observation: Each procedure incarnation changes maximally onecomponent of the global display, i.e. if PND(caller) - PND (callee) = -1.

Solution: It suffices to save the changed component and to restore itin the epilog of a procedure. For saving the component, a memoryword in the stack frame has to be reserved.



Using global displays (2)

Remarks:

• If there are enough registers, the global display (or parts) shouldbe stored in registers.

• For languages that use procedures as parameters, the displaytechnique has to be adapted.

• The different variants for handling nested procedures show typicalvariation points in compiler design.

The introduced memory management can be seen as a schema thatcan be adapted for given source and target languages (consideringproperties of the target machines, e.g. caches).



Summary: Memory Management



Literature

Recommended reading:

• Wilhelm, Maurer: Sect. 2.9, pp. 31 – 53


compilers and language processing tools · content of lecture 1.introduction 2.syntax and type...

Documents