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
c© Arnd Poetzsch-Heffter 2
Content of Lecture (2)
5. Selected Topics in Compiler Construction5.1 Just-in-time Compilation5.2 Garbage Collection5.3 XML Processing (DOM, SAX, XSLT)
c© Arnd Poetzsch-Heffter 3
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 5
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 6
Translation of Imperative 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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 7
Translation of Imperative Language Constructs
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 8
Translation of Imperative Language Constructs
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 9
Languages for Intermediate Representation
3.1 Languages for Intermediate Representation
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 10
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 11
Languages for Intermediate Representation
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 12
Languages for Intermediate Representation
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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 13
Languages for Intermediate Representation SIRL: A simple IR language
3.1.1 SIRL: A simple IR language
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 14
Languages for Intermediate Representation 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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 15
Languages for Intermediate Representation SIRL: A simple IR language
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 16
Languages for Intermediate Representation SIRL: A simple IR language
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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 17
Languages for Intermediate Representation SIRL: A simple IR language
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 18
Languages for Intermediate Representation SIRL: A simple IR language
SIRL: Program structure
Program ::= MAIN StmtList END Procedure*StmtList ::= ( Label? Stmt )*Procedure ::= Label [ IntLiteral ] ESEQ
where Stmt, ESEQ, Label are as defined above
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 19
Languages for Intermediate Representation SIRL: A simple IR language
Examples
Translate the following MiniJava statements to SIRL:1. if (x < y) x = y; else x = 0;
2. y = z[5];
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 20
Languages for Intermediate Representation SIRL: A simple IR language
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 ...
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 21
Languages for Intermediate Representation SIRL: A simple IR language
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).
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 22
Languages for Intermediate Representation 3-Address Code
3.1.2 3-Address Code
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 23
Languages for Intermediate Representation 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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 24
Languages for Intermediate Representation 3-Address Code
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 25
Languages for Intermediate Representation 3-Address Code
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 26
Languages for Intermediate Representation 3-Address Code
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 27
Languages for Intermediate Representation 3-Address Code
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 28
Languages for Intermediate Representation 3-Address Code
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 29
Languages for Intermediate Representation 3-Address Code
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
28.06.2007 296© A. Poetzsch-Heffter, TU Kaiserslautern
return 0
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 30
Languages for Intermediate Representation 3-Address Code
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
28.06.2007 296© A. Poetzsch-Heffter, TU Kaiserslautern
return 0
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 31
Languages for Intermediate Representation 3-Address Code
Example: 3AC and basic blocks (3)
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
28.06.2007 297© A. Poetzsch-Heffter, TU Kaiserslautern
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 32
Languages for Intermediate Representation 3-Address Code
Example: 3AC and basic blocks (4)
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
28.06.2007 297© A. Poetzsch-Heffter, TU Kaiserslautern
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 33
Languages for Intermediate Representation 3-Address Code
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
28.06.2007 298© A. Poetzsch-Heffter, TU Kaiserslautern
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 34
Languages for Intermediate Representation 3-Address Code
Characteristics of 3-Address Code
• Control flow is explicit.• Only elementary operations• Rearrangement and exchange of commands can be handled
relatively easily.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 35
Languages for Intermediate Representation Other Intermediate Languages
3.1.3 Other Intermediate Languages
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 36
Languages for Intermediate Representation Other Intermediate Languages
Further Intermediate Languages
We consider• 3AC in Static Single Assignment (SSA) representation• Stack Machine Code
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 37
Languages for Intermediate Representation Other Intermediate Languages
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 38
Languages for Intermediate Representation Other Intermediate Languages
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 39
Languages for Intermediate Representation Other Intermediate Languages
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
28.06.2007 300© A. Poetzsch-Heffter, TU Kaiserslautern
a := a + b a := a + b 3 2 2
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 40
Languages for Intermediate Representation Other Intermediate Languages
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
28.06.2007 301© A. Poetzsch-Heffter, TU Kaiserslautern
...
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 41
Languages for Intermediate Representation Other Intermediate Languages
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
28.06.2007 301© A. Poetzsch-Heffter, TU Kaiserslautern
...
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 42
Languages for Intermediate Representation Other Intermediate Languages
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).
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 43
Languages for Intermediate Representation Other Intermediate Languages
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 44
Languages for Intermediate Representation Other Intermediate Languages
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
28.06.2007 303© A. Poetzsch-Heffter, TU Kaiserslautern
Zwischenergebnisse werden auf einem Laufzeitkeller
verwaltet.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 45
Languages for Intermediate Representation Other Intermediate Languages
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
28.06.2007 303© A. Poetzsch-Heffter, TU Kaiserslautern
Zwischenergebnisse werden auf einem Laufzeitkeller
verwaltet.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 46
Languages for Intermediate Representation Other Intermediate Languages
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
28.06.2007 304© A. Poetzsch-Heffter, TU Kaiserslautern
Weitere Zwischensprachen werden insbesondere auch
im Zusammenhang mit Optimierungen eingesetzt.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 47
Languages for Intermediate Representation Other Intermediate Languages
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:
Weitere Zwischensprachen werden insbesondere auch
28.06.2007 304© A. Poetzsch-Heffter, TU Kaiserslautern
Weitere Zwischensprachen werden insbesondere auch
im Zusammenhang mit Optimierungen eingesetzt.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 48
Translation of Imperative Language Constructs
3.2 Translation of Imperative Language Constructs
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 49
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
3.2.1 Basic Concepts and Memory Organization
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 50
Translation of Imperative Language Constructs 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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 51
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
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 )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 52
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
TOYC - a sublanguage of C (Expressions)
Exp = ArtihmExp | Relation | BoolExp | IntConst| ArrayAccess | VarExp
ArithmExp = Add | SubAdd, Sub ( Exp left, Exp right )Relation = Lt | EqLt, Eq ( Exp left, Exp right )BoolExp = And | Or | NotAnd, Or ( Exp left, Exp right )Not ( Exp e )
IntConst ( int i )ArrayAccess ( UsedId uid, Exp e )VarExp ( UsedId uid )ExpList * Exp
UsedId ( Ident id )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 53
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 54
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 55
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 56
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
Memory organization - example
stack
free memory
heap
static data
code
high address
low address
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 57
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
Layout of typical stack frame
For procedures with results, additional memory is needed (where?)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 58
Translation of Imperative Language Constructs Basic Concepts and Memory Organization
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 59
Translation of Imperative Language Constructs Translation of Variables and Data Types
3.2.2 Translation of Variables and Data Types
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 60
Translation of Imperative Language Constructs 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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 61
Translation of Imperative Language Constructs Translation of Variables and Data Types
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 62
Translation of Imperative Language Constructs Translation of Variables and Data Types
Primitive data types in TOYC
• TOYC only supports four byte integers as primitive values• true and false are handled by 1 and 0
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 63
Translation of Imperative Language Constructs Translation of Variables and Data Types
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 .
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 64
Translation of Imperative Language Constructs Translation of Variables and Data Types
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 65
Translation of Imperative Language Constructs Translation of Variables and Data Types
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 )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 66
Translation of Imperative Language Constructs Translation of Variables and Data Types
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 67
Translation of Imperative Language Constructs Translation of Variables and Data Types
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 68
Translation of Imperative Language Constructs Translation of Variables and Data Types
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 )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 69
Translation of Imperative Language Constructs Translation of Variables and Data Types
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 70
Translation of Imperative Language Constructs Translation of Variables and Data Types
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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 71
Translation of Imperative Language Constructs Translation of Variables and Data Types
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 72
Translation of Imperative Language Constructs Translation of Variables and Data Types
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 73
Translation of Imperative Language Constructs Translation of Variables and Data Types
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;
12.06.2007 215© A. Poetzsch-Heffter, TU Kaiserslautern
}
...
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 74
Translation of Imperative Language Constructs Translation of Variables and Data Types
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 75
Translation of Imperative Language Constructs Translation of Variables and Data Types
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 76
Translation of Imperative Language Constructs Translation of Variables and Data Types
Dynamic Memory Management (3)
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 77
Translation of Imperative Language Constructs Translation of Variables and Data Types
Dynamic Memory Management (4)
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 78
Translation of Imperative Language Constructs Translation of Variables and Data Types
Dynamic Memory Management (5)
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 79
Translation of Imperative Language Constructs Translation of Expressions and Statements
3.2.3 Translation of Expressions and Statements
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 80
Translation of Imperative Language Constructs 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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 81
Translation of Imperative Language Constructs Translation of Expressions and Statements
Translation of Statements
Aspects for translation of statements
• Translation of compound statements to jumps
• Generation of unique labels
• Treatment of procedure calls (next subsection)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 82
Translation of Imperative Language Constructs Translation of Expressions and Statements
Example: Translation of simplified TOYC - fragment
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 )
Exp = ArtihmExp | Relation | BoolExp | IntConst| ArrayAccess | VarExp
ArithmExp = Add | SubAdd, Sub ( Exp left, Exp right )Relation = Lt | EqLt, Eq ( Exp left, Exp right )BoolExp = And | Or | NotAnd, Or ( Exp left, Exp right )Not ( Exp e )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 83
Translation of Imperative Language Constructs Translation of Expressions and Statements
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 84
Translation of Imperative Language Constructs Translation of Expressions and Statements
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 85
Translation of Imperative Language Constructs Translation of Expressions and Statements
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 86
Translation of Imperative Language Constructs Translation of Expressions and Statements
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 87
Translation of Imperative Language Constructs Translation of Expressions and Statements
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 88
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribute definitions
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 89
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for VarExp
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 90
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for IntConst
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 91
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for ArrayAccess
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 92
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for Not
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 93
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for And
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 94
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for Or
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 95
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for Add
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 96
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for Lt
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 97
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for If
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 98
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for While
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 99
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for VarAssign
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 100
Translation of Imperative Language Constructs Translation of Expressions and Statements
Attribution for ArrAssign
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 101
Translation of Imperative Language Constructs Translation of Expressions and Statements
Recommended Reading:
• Wilhelm, Maurer: Sec. 2.4, pp. 12 –16
• Appel: Sec. 7.2
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 102
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
3.2.4 Simplifying the Intermediate Representation
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 103
Translation of Imperative Language Constructs 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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 104
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
Example: Source language
Stmt = Move | CJump | Label | StmtListMove ( Temp Exp )CJump ( Exp String )Label ( String)StmtList * Stmt
Exp = Temp | BinExp | StmtExpTemp ( String )BinExp ( Exp Exp )StmtExp ( StmtList Exp )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 105
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
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 )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 106
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
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()
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 107
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 108
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
Attribution for
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 109
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
Attribution for
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 110
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
Attribution for
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 111
Translation of Imperative Language Constructs Simplifying the Intermediate Representation
Attribution for
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 112
Translation of Object-Oriented Language Constructs
3.3 Translation of Object-Oriented LanguageConstructs
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 113
Translation of Object-Oriented Language Constructs Concepts of Object-Oriented Programming Languages
3.3.1 Concepts of Object-Oriented ProgrammingLanguages
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 114
Translation of Object-Oriented Language Constructs Concepts of Object-Oriented Programming Languages
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 115
Translation of Object-Oriented Language Constructs Concepts of Object-Oriented Programming Languages
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;
}
public void drucken() {
super.drucken();
System.out.println( "Mnr:"+ matrikelnr);
i
26.06.2007 254© A. Poetzsch-Heffter, TU Kaiserslautern
System.out.println( "Sem:" + semester);
}
}
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 116
Translation of Object-Oriented Language Constructs Concepts of Object-Oriented Programming Languages
Example: Object-Oriented Language Concepts (2)
Beispiel: (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;
}
public void drucken() {
super.drucken();
System.out.println( "Mnr:"+ matrikelnr);
i
26.06.2007 254© A. Poetzsch-Heffter, TU Kaiserslautern
System.out.println( "Sem:" + semester);
}
}
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 117
Translation of Object-Oriented Language Constructs Concepts of Object-Oriented Programming Languages
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
26.06.2007 255© A. Poetzsch-Heffter, TU Kaiserslautern
mit Selektion von Verbundkomponenten
Als Zielsprache verwenden wir hier C.
The example demonstrates classes, object creation, inheritance (withsubtyping and specialization) and dynamic method binding.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 118
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
3.3.2 Translation into Procedural Languages
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 119
Translation of Object-Oriented Language Constructs 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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 120
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 121
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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 ;
int gebdatum; /* in der Form JJJJMMTT */
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){
26.06.2007 256© A. Poetzsch-Heffter, TU Kaiserslautern
(Person this,int datum){
return (this->gebdatum%10000)==(datum%10000);
}
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 122
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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 ;
int gebdatum; /* in der Form JJJJMMTT */
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){
26.06.2007 256© A. Poetzsch-Heffter, TU Kaiserslautern
(Person this,int datum){
return (this->gebdatum%10000)==(datum%10000);
}
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 123
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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;
int gebdatum; /* in der Form JJJJMMTT */
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 “
26.06.2007 257© A. Poetzsch-Heffter, TU Kaiserslautern
impliziten Argument in der „Unterklasse“.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 124
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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;
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;
int gebdatum; /* in der Form JJJJMMTT */
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 “
26.06.2007 257© A. Poetzsch-Heffter, TU Kaiserslautern
impliziten Argument in der „Unterklasse“.Type conversions for implicit arguments of subclass are necessary.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 125
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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 ) {
Oberklasse lassen sich nach geeigneter
Typkonvertierung unverändert verwenden:
(String* n,int gd,int mnr,int sem ) {
Student* this =
(Student*) malloc(sizeof(Student));
this->name = n;
this->gebdatum = gd;
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 );
26.06.2007 258© A. Poetzsch-Heffter, TU Kaiserslautern
p ( \ , );
}
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 126
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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
Oberklasse lassen sich nach geeigneter
Student* StudentK
(String* n int gd int mnr int sem ) {
Oberklasse lassen sich nach geeigneter
Typkonvertierung unverändert verwenden:
(String* n,int gd,int mnr,int sem ) {
Student* this =
(Student*) malloc(sizeof(Student));
this->name = n;
this->gebdatum = gd;
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 );
26.06.2007 258© A. Poetzsch-Heffter, TU Kaiserslautern
p ( \ , );
}
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 127
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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.
26.06.2007 259© A. Poetzsch-Heffter, TU Kaiserslautern
g
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 128
Translation of Object-Oriented Language Constructs Translation into Procedural Languages
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 129
Translation of Object-Oriented Language Constructs Translation of Classes
3.3.3 Translation of Classes
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 130
Translation of Object-Oriented Language Constructs 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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 131
Translation of Object-Oriented Language Constructs Translation of Classes
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).
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 132
Translation of Object-Oriented Language Constructs Translation of Classes
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
26.06.2007 261© A. Poetzsch-Heffter, TU Kaiserslautern
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 133
Translation of Object-Oriented Language Constructs Translation of Classes
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.
26.06.2007 262© A. Poetzsch-Heffter, TU Kaiserslautern
Object Reference
Class and Method
Information for Class C
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 134
Translation of Object-Oriented Language Constructs Translation of Classes
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 135
Translation of Object-Oriented Language Constructs Translation of Classes
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
26.06.2007 263© A. Poetzsch-Heffter, TU Kaiserslautern
Oberklasse in Ober- und Unterklasse-Objekten
die gleiche Relativadresse besitzen.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 136
Translation of Object-Oriented Language Constructs Translation of Classes
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 137
Translation of Object-Oriented Language Constructs Translation of Classes
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 138
Translation of Object-Oriented Language Constructs Translation of Classes
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:
26.06.2007 264© A. Poetzsch-Heffter, TU Kaiserslautern
c:
Object ReferenceClass and Method
Information for Class C
Descriptor
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 139
Translation of Object-Oriented Language Constructs Translation of Classes
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 140
Translation of Object-Oriented Language Constructs Translation of Classes
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).
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 141
Translation of Object-Oriented Language Constructs Translation of Classes
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 142
Translation of Object-Oriented Language Constructs Translation of Classes
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
26.06.2007 267© A. Poetzsch-Heffter, TU Kaiserslautern
(Aus Gründen der Übersichtlichkeit haben wir aufdie Angabe von Klasseninformation verzichtet.)
Object Reference
all objects share mtab
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 143
Translation of Object-Oriented Language Constructs Translation of Classes
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 144
Translation of Object-Oriented Language Constructs Translation of Classes
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
26.06.2007 268© A. Poetzsch-Heffter, TU Kaiserslautern
} a2:p
b:
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 145
Translation of Object-Oriented Language Constructs Translation of Classes
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.
26.06.2007 269© A. Poetzsch-Heffter, TU Kaiserslautern
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 146
Translation of Object-Oriented Language Constructs Translation of Classes
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 147
Translation of Object-Oriented Language Constructs Translation of Classes
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 148
Translation of Object-Oriented Language Constructs Problems of Multiple Inheritance
3.3.4 Problems of Multiple Inheritance
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 149
Translation of Object-Oriented Language Constructs 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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 150
Translation of Object-Oriented Language Constructs Problems of Multiple Inheritance
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
26.06.2007 271© A. Poetzsch-Heffter, TU Kaiserslautern
werden, dass sie auch als A-, B-, C- und D-Objekte
auftreten können?
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 151
Translation of Object-Oriented Language Constructs Problems of Multiple Inheritance
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?
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 152
Translation of Object-Oriented Language Constructs Problems of Multiple Inheritance
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
26.06.2007 272© A. Poetzsch-Heffter, TU Kaiserslautern
(Nachteil: nicht modular, gesamtes Programm
muss bekannt sein).
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 153
Translation of Object-Oriented Language Constructs Problems of Multiple Inheritance
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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 154
Translation of Object-Oriented Language Constructs Further Aspects of Object-Oriented Languages
3.3.5 Further Aspects of Object-Oriented Languages
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 155
Translation of Object-Oriented Language Constructs Further Aspects of Object-Oriented Languages
Further aspects of object-oriented languages
• Static methods• Nested classes• Virtual classes• Encapsulation aspects• Dynamic loading• Reflection
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 156
Translation of Object-Oriented Language Constructs Further Aspects of Object-Oriented Languages
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();
26.06.2007 273© A. Poetzsch-Heffter, TU Kaiserslautern
}
}
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 157
Translation of Object-Oriented Language Constructs Further Aspects of Object-Oriented Languages
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
26.06.2007 274© A. Poetzsch-Heffter, TU Kaiserslautern
Questions:
• Are there errors?• What is the output and why?
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 158
Translation of Object-Oriented Language Constructs Further Aspects of Object-Oriented Languages
Literature
Recommended Reading:
• Wilhelm, Maurer: Sect. 5.2 and 5.3. (pp. 182 – 195)• Appel: Sect. 14.1–14.3, (pp. 303 – 310)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 159
Translation of Procedures
3.4 Translation of Procedures
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 160
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 161
Translation of Procedures
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 162
Translation of Procedures
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.
12.06.2007 229© A. Poetzsch-Heffter, TU Kaiserslautern
• Zu jedem Ausführungszeitpunkt gibt es einen aktiven
Pfad in dem Baum.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 163
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 164
Translation of Procedures
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 165
Translation of Procedures
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 166
Translation of Procedures
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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 167
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 168
Translation of Procedures
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
12.06.2007 233© A. Poetzsch-Heffter, TU Kaiserslautern
wobei PLAB die Ansprungmarke der Prozedur ist.
[LABEL (“PROCBEG_”+M)] +<Prolog> +CSL +<Epilog> +[JR $ra]
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 169
Translation of Procedures
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
12.06.2007 233© A. Poetzsch-Heffter, TU Kaiserslautern
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)
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 170
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 171
Translation of Procedures
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
12.06.2007 235© A. Poetzsch-Heffter, TU Kaiserslautern
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
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 173
Translation of Procedures
Stack frame for procedure foo
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 174
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 175
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 176
Translation of Procedures
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
12.06.2007 239© A. Poetzsch-Heffter, TU Kaiserslautern
end
here vp, vq, vr addressable
here vp, vq addressable
here vp addressable
here vp addressable
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 177
Translation of Procedures
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:
12.06.2007 240© A. Poetzsch-Heffter, TU Kaiserslautern
Ist PG eine von PA aufrufbare Prozedur, dann gilt:
PST(PG) ! PST(PA) + 1
denotes accessible
variables
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 178
Translation of Procedures
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
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 179
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 180
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 181
Translation of Procedures
Stack frame with static predecessor
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 182
Translation of Procedures
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
Translation of Procedures
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 )
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 184
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 185
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 186
Translation of Procedures
Discussion
Remarks:
• The SPR chain can relatively easily be realized.
• Addressing of non-local variables can be inefficient.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 187
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 188
Translation of Procedures
Stack frame with local display
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 189
Translation of Procedures
Snapshot of stack for example with local display
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 190
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 191
Translation of Procedures
Global display
Observation:Many entries in the local display are identical.
Goal:Store display in global memory region. This memory area is calledglobal display.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 192
Translation of Procedures
Snapshot of stack for example with global display
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 193
Translation of Procedures
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.
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 194
Translation of Procedures
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).
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 195
Translation of Procedures
Summary: Memory Management
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 196
Translation of Procedures
Literature
Recommended reading:
• Wilhelm, Maurer: Sect. 2.9, pp. 31 – 53
c© Arnd Poetzsch-Heffter Translation to Intermediate Representation 197