CSCE 531 Compiler Construction Ch.7: Code Generation

Slides:



Advertisements
Similar presentations
Programming Languages and Paradigms
Advertisements

1 Languages and Compilers (SProg og Oversættere) Code Generation.
1 Compiler Construction Intermediate Code Generation.
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering CSCE 531 Compiler Construction Final Lecture of the Semester Spring 2010 Marco.
Prof. Necula CS 164 Lecture 141 Run-time Environments Lecture 8.
Chapter 7 User-Defined Methods. Chapter Objectives  Understand how methods are used in Java programming  Learn about standard (predefined) methods and.
Representação do código objeto public class Instruction { public byte op; // op-code (0..15) public byte r; // register field (0..15) public byte n; //
Contextual Analysis (Chapter 5) 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture.
1 Languages and Compilers (SProg og Oversættere) Bent Thomsen Department of Computer Science Aalborg University With acknowledgement to Norm Hutchinson.
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering CSCE 531 Compiler Construction Ch. 3: Compilation Spring 2007 Marco Valtorta.
1 Languages and Compilers (SProg og Oversættere) Lecture 11 Bent Thomsen Department of Computer Science Aalborg University With acknowledgement to Norm.
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering CSCE 531 Compiler Construction Ch.8: Interpretation Spring 2008 Marco Valtorta.
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering CSCE 531 Compiler Construction Ch. 3: Compilation Spring 2008 Marco Valtorta.
CS 536 Spring Run-time organization Lecture 19.
3/17/2008Prof. Hilfinger CS 164 Lecture 231 Run-time organization Lecture 23.
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering CSCE 531 Compiler Construction Ch.7: Code Generation Spring 2008 Marco Valtorta.
Run time vs. Compile time
Run-time Environment and Program Organization
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering CSCE 531 Compiler Construction Ch.1 Spring 2010 Marco Valtorta
CSC 8310 Programming Languages Meeting 2 September 2/3, 2014.
Imperative Programming
Compilation (Chapter 3) 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture.
Runtime Environments Compiler Construction Chapter 7.
Compiler Construction
Introduction (Chapter 1) 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture.
5-1 5 Compilation  Overview  Compilation phases –syntactic analysis –contextual analysis –code generation  Abstract syntax trees  Case study: Fun language.
1 Languages and Compilers (SProg og Oversættere) Bent Thomsen Department of Computer Science Aalborg University With acknowledgement to Norm Hutchinson.
Languages and Compilers (SProg og Oversættere) Bent Thomsen Department of Computer Science Aalborg University.
Runtime Organization (Chapter 6) 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture.
Runtime Organization (Chapter 6) 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture.
Language Translation A programming language processor is any system that manipulates programs expressed in a PL A source program in some source language.
Contextual Analysis (Chapter 5) 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture.
 Fall Chart 2  Translators and Compilers  Textbook o Programming Language Processors in Java, Authors: David A. Watts & Deryck F. Brown, 2000,
1 Languages and Compilers (SProg og Oversættere) Lecture 9 (1) Bent Thomsen Department of Computer Science Aalborg University With acknowledgement to Norm.
Overview of Compilation Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Principles Lecture 2.
Code Generation (Chapter 7) 1 Course Overview PART I: overview material 1Introduction 2Language processors (tombstone diagrams, bootstrapping) 3Architecture.
1 Languages and Compilers (SProg og Oversættere) Semantic Analysis.
UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering CSCE 330 Programming Language Structures Operational Semantics (Slides mainly.
Run-Time Environments Presented By: Seema Gupta 09MCA102.
Implementing Subprograms
Lecture 9 Symbol Table and Attributed Grammars
Chapter 10 : Implementing Subprograms
Compiler Design (40-414) Main Text Book:
Chapter 7 User-Defined Methods.
A Simple Syntax-Directed Translator
Constructing Precedence Table
Course Overview PART I: overview material PART II: inside a compiler
Compilers Principles, Techniques, & Tools Taught by Jing Zhang
Implementing Subprograms
Run-time organization
Languages and Compilers (SProg og Oversættere)
Stacks Chapter 4.
Implementing Subprograms
Implementing Subprograms
Chapter 6 Intermediate-Code Generation
The Metacircular Evaluator
The University of Adelaide, School of Computer Science
PZ09A - Activation records
Languages and Compilers (SProg og Oversættere)
Activation records Programming Language Design and Implementation (4th Edition) by T. Pratt and M. Zelkowitz Prentice Hall, 2001 Section
UNIT V Run Time Environments.
6.001 SICP Variations on a Scheme
Course Overview PART I: overview material PART II: inside a compiler
Course Overview PART I: overview material PART II: inside a compiler
Activation records Programming Language Design and Implementation (4th Edition) by T. Pratt and M. Zelkowitz Prentice Hall, 2001 Section
Languages and Compilers (SProg og Oversættere)
Course Overview PART I: overview material PART II: inside a compiler
Implementing Subprograms
Languages and Compilers (SProg og Oversættere)
Chapter 10 Def: The subprogram call and return operations of
Presentation transcript:

CSCE 531 Compiler Construction Ch.7: Code Generation Spring 2013 Marco Valtorta mgv@cse.sc.edu

Acknowledgment The slides are based on the textbooks and other sources, including slides from Bent Thomsen’s course at the University of Aalborg in Denmark and several other fine textbooks We will also use parts of Torben Mogensen’s online textbook, Basics of Compiler Design The three main other compiler textbooks I considered are: Aho, Alfred V., Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, & Tools, 2nd ed. Addison-Welsey, 2007. (The “dragon book”) Appel, Andrew W. Modern Compiler Implementation in Java, 2nd ed. Cambridge, 2002. (Editions in ML and C also available; the “tiger books”) Grune, Dick, Henri E. Bal, Ceriel J.H. Jacobs, and Koen G. Langendoen. Modern Compiler Design. Wiley, 2000

What This Lecture is About A compiler translates a program from a high-level language into an equivalent program in a low-level language. Triangle Program Compile TAM Program Run Result

Programming Language specification A Language specification has (at least) three parts: Syntax of the language: usually formal: EBNF Contextual constraints: scope rules (often written in English, but can be formal) type rules (formal or informal) Semantics: defined by the implementation informal descriptions in English formal using operational, axiomatic, or denotational semantics

The “Phases” of a Compiler Source Program Syntax Analysis Error Reports Abstract Syntax Tree Contextual Analysis Error Reports Decorated Abstract Syntax Tree Code Generation Chapter 7 Object Code

Multi Pass Compiler A multi pass compiler makes several passes over the program. The output of a preceding phase is stored in a data structure and used by subsequent phases. Dependency diagram of a typical Multi Pass Compiler: Compiler Driver Chapter 7 calls calls calls Syntactic Analyzer Contextual Analyzer Code Generator input Source Text output AST Decorated AST Object Code

Issues in Code Generation Code Selection: Deciding which sequence of target machine instructions will be used to implement each phrase in the source language. Storage Allocation Deciding the storage address for each variable in the source program. (static allocation, stack allocation etc.) Register Allocation (for register-based machines) How to use registers efficiently to store intermediate results. We use a stack based machine. This is not an issue for us

~ Code Generation Source Program Target program let var n: integer; var c: char in begin c := ‘&’; n := n+1 end PUSH 2 LOADL 38 STORE 1[SB] LOAD 0 LOADL 1 CALL add STORE 0[SB] POP 2 HALT ~ Source and target program must be “semantically equivalent” Semantic specification of the source language is structured in terms of phrases in the SL: expressions, commands, etc. => Code generation follows the same “inductive” structure. Q: Can you see the connection with denotational semantics?

“Inductive” Code Generation “Inductive” means: code generation for a “big” structure is defined in terms of putting together chunks of code that correspond to the sub-structures. Example: Sequential Command code generation Semantic specification The sequential command C1 ; C2 is executed as follows: first C1 is executed then C2 is executed. Code generation function: execute : Command -> Instruction* execute [C1 ; C2] = execute [C1] execute [C2] instructions for C1 instructions for C1 ; C2 instructions for C2

“Inductive” Code Generation Example: Assignment command code generation Code generation function: execute [I := E] = evaluate [E] STORE address [I] instructions for E yield value for E on top of the stack instruction to store result into variable These “pictures” of the code layout for a particular source language construct are called code templates. Inductive means: A code template specifies the object code to which a phrase is translated, in terms of the object code to which its subphrases are translated.

“Inductive” Code Generation Example: code generation for a larger phrase in terms of its subphrases LOAD f LOAD n CALL mult STORE f execute [f := f*n] execute [f := f*n; n := n-1] LOAD n CALL pred STORE n execute [n := n-1]

Specifying Code Generation with Code Templates For each “phrase class” P in the abstract syntax of the source language: Define code function fP : P -> Instruction* that translate each phrase in class P to object code. We specify the function fP by code templates. Typically they look like: fP […Q…R…] = … fQ [Q] fR [R] note: A “phrase class” typically corresponds to a non-terminal of the abstract syntax. This in turn corresponds to an abstract class in the Java classes that implement the AST nodes. (for example Expression, Command, Declaration)

Specifying Code Generation with Code Templates Example: Code templates specification for Mini Triangle RECAP: The mini triangle AST Program ::= Command Program Command ::= V-name := Expression AssignCmd | let Declaration in Command LetCmd ... Expression ::= Integer-Literal IntegerExp | V-name VnameExp | Operator Expression UnaryExp | Expression Op Expression BinaryExp Declaration ::= ... V-name::= Identifier SimpleVName

Specifying Code Generation with Code Templates The code generation functions for Mini Triangle Phrase Class Function Effect of the generated code Program Command Expres- sion V-name Decla- ration run P execute C evaluate E fetch V assign V elaborate D Run program P then halt. Starting and finishing with empty stack Execute Command C. May update variables but does not shrink or grow the stack. Evaluate E, net result is pushing the value of E on the stack. Push value of constant or variable on the stack. Pop value from stack and store in variable V Elaborate declaration, make space on the stack for constants and variables in the decl.

Code Generation with Code Templates The code generation functions for Mini Triangle Programs: run [C] = execute [C] HALT Commands: execute [V := E] = evaluate [E] assign [V] execute [I ( E )] = CALL p where p is address of the routine named I

Code Generation with Code Templates Commands: execute [C1 ; C2] = execute [C1] execute [C2] execute [if E then C1 else C2] = evaluate [E] JUMPIF(0) g JUMP h g: execute [C2] h: C1 C2 E g: h:

Code Generation with Code Templates Commands: execute [while E do C] = JUMP h g: execute [C] h: evaluate[E] JUMPIF(1) g C E execute [while E do C] = g: evaluate [E] JUMPIF(0) h execute[C] JUMP g h: Alternative While Command code template: E C

Code Generation with Code Templates Repeat Command code template: execute [repeat C until E] = g: execute [C] h: evaluate[E] JUMPIF(0) g execute [let D in C] = elaborate[D] execute [C] POP(0) s if s>0 where s = amount of storage allocated by D C E

Code Generation with Code Templates Expressions: evaluate [IL] = note: IL is an integer literal LOADL v where v = the integer value of IL evaluate [V] = note: V is variable name fetch[V] evaluate [O E] = note: O is a unary operator evaluate[E] CALL p where p = address of routine for O evaluate [E1 O E2] = note: O is a binary operator evaluate[E1] evaluate[E2]

Code Generation with Code Templates Variables: note: Mini triangle only needs static allocation (Q: why is that? ) fetch [V] = LOAD d[SB] where d = address of V relative to SB assign [V] = STORE d[SB] where d = address of V relative to SB

Code Generation with Code Templates Declarations: elaborate [const I ~ E] = evaluate[E] elaborate [var I : T] = PUSH s where s = size of T elaborate [D1 ; D2] = elaborate [D1] elaborate [D2] THE END: these are all the code templates for Mini Triangle. Now let’s put them to use in an example.

Example of Mini Triangle Code Generation execute [while i>0 do i:=i+2] = JUMP h g: LOAD i LOADL 2 CALL add STORE i h: LOAD i LOADL 0 CALL gt JUMPIF(1) g evaluate [i+2] execute [i:=i+2] evaluate [i>0] Note: Picture shows a few steps but not all

Special Case Code Templates There are often several ways to generate code for an expression, command, etc. The templates we defined work, but sometimes we can get more efficient code for special cases => special case code templates. Example: evaluate [i+1] = LOAD i LOADL 1 CALL add evaluate [i+1] = LOAD i CALL succ more efficient code for the special case “+1” what we get with the “general” code templates

Special Case Code Templates Example: some special case code template for “+1”, “-1”, … evaluate [E + 1] = evaluate [E] CALL succ evaluate [1 + E] = evaluate [E] CALL succ evaluate [E - 1] = evaluate [E] CALL pred A special-case code template is one that is applicable to phrase of a special form. Such phrases are also covered by a more general form.

Special Case Code Templates Example: “Inlining” known constants. execute [let const n~7; var i:Integer in i:=n*n] = LOADL 7 PUSH 1 LOAD n CALL mult STORE i POP(0) 2 elaborate [const n~7] elaborate [var i:Integer] execute [i:=n*n] This is how the code looks like with no special case templates

Special Case Code Templates Example: “Inlining” known constants. Special case templates for inlining literals. elaborate [const I ~ IL] = no code fetch [I] = special case if I is a known literal constant LOADL v where v is the known value of I execute [let const n~7; var i:Integer in i:=n*n] = PUSH 1 LOADL 7 CALL mult STORE i POP(0) 1

Code Generation Algorithm The code templates specify how code is to be generated => determines code generation algorithm. Generating code: traversal of the AST emitting instructions one by one. The code templates determine the order of the traversal and the instructions to be emitted. We will now look at how to implement a Mini Triangle code generator in Java.

Representation of Object Program: Instructions public class Instruction { public byte op; // op-code 0..15 public byte r; // register field (0..15) public byte n; // length field (0..255) public short d; // operand f. (-32767..+32767) public static final byte // op-codes LOADop = 0, LOADAop = 1, ... public static final byte // register numbers CBr = 0, CTr = 1, … SBr = 4, STr = 5, … public Instruction(byte op,byte n, byte r,short d) { ... } }

Representation of Object Program: Emitting Code public class Encoder { private Instruction[] code = new Instruction[1024]; private short nextInstrAddr = 0; private void emit(byte op,byte n, byte r,short d) { code[nextInstrAddr++]=new Instruction( op,n,r,d); } ... lots of other stuff in here of course ...

Developing a Code Generator “Visitor” generate code as specified by execute[C] generate code as specified by evaluate[E] Return “entity description” for the visited variable or constant name. generate code as specified by elaborate[D] return the size of the type Program visitProgram generate code as specified by run[P] Command visit…Command Expression visit…Expression V-name visit…Vname Declaration visit…Declaration Type-Den visit…TypeDen Phrase Class visitor method Behavior of the visitor method

Developing a Code Generator “Visitor” For variables we have two distinct code generation functions: fetch and assign. => Not implemented as visitor methods but as separate methods. public void encodeFetch(Vname name) { ... as specified by fetch template ... } public void encodeAssign(Vname name) { ... as specified by assign template ...

Developing a Code Generator “Visitor” run [C] = execute [C] HALT public class Encoder implements Visitor { ... /* Generating code for entire Program */ public Object visitProgram(Program prog, Object arg ) { prog.C.visit(this,arg); emit a halt instruction return null; }

Developing a Code Generator “Visitor” RECAP: execute [V := E] = evaluate [E] assign [V] /* Generating code for commands */ public Object visitAssignCommand( AssignCommand com,Object arg) { com.E.visit(this,arg); encodeAssign(com.V); return null; }

Developing a Code Generator “Visitor” execute [I ( E )] = evaluate [E] CALL p where p is address of the routine named I public Object visitCallCommand( CallCommand com,Object arg) { com.E.visit(this,arg); short p = address of primitive routine for name com.I emit(Instruction.CALLop, Instruction.SBr, Instruction.PBr, p); return null; }

Developing a Code Generator “Visitor” execute [C1 ; C2] = execute[C1] execute[C2] public Object visitSequentialCommand( SequentialCommand com,Object arg) { com.C1.visit(this,arg); com.C2.visit(this,arg); return null; } LetCommand, IfCommand, WhileCommand => later. - LetCommand is more complex: memory allocation and addresses - IfCommand and WhileCommand: complications with jumps

Developing a Code Generator “Visitor” evaluate [IL] = LOADL v where v is the integer value of IL /* Expressions */ public Object visitIntegerExpression ( IntegerExpression expr,Object arg) { short v = valuation(expr.IL.spelling); emit(Instruction.LOADLop, 0, 0, v); return null; } public short valuation(String s) { ... convert string to integer value ...

Developing a Code Generator “Visitor” evaluate [E1 O E2] = evaluate [E1] evaluate [E2] CALL p where p is the address of routine for O public Object visitBinaryExpression ( BinaryExpression expr,Object arg) { expr.E1.visit(this,arg); expr.E2.visit(this,arg); short p = address for expr.O operation emit(Instruction.CALLop, Instruction.SBr, Instruction.PBr, p); return null; } Remaining expression visitors are developed in a similar way.

Controls Structures We have yet to discuss generation for IfCommand and WhileCommand execute [while E do C] = JUMP h g: execute [C] h: evaluate[E] JUMPIF(1) g C E A complication is the generation of the correct addresses for the jump instructions. We can determine the address of the instructions by incrementing a counter while emitting instructions. Backwards jumps are easy but forward jumps are harder. Q: why?

Control Structures Backwards jumps are easy: The “address” of the target has already been generated and is known Forward jumps are harder: When the jump is generated the target is not yet generated so its address is not (yet) known. There is a solution which is known as backpatching 1) Emit jump with “dummy” address (e.g. simply 0). 2) Remember the address where the jump instruction occurred. 3) When the target label is reached, go back and patch the jump instruction.

Backpatching Example public Object WhileCommand ( WhileCommand com,Object arg) { short j = nextInstrAddr; emit(Instruction.JUMPop, 0, Instruction.CBr,0); short g = nextInstrAddr; com.C.visit(this,arg); short h = nextInstrAddr; code[j].d = h; com.E.visit(this,arg); emit(Instruction.JUMPIFop, 1, Instruction.CBr,g); return null; } dummy address backpatch execute [while E do C] = JUMP h g: execute [C] h: evaluate[E] JUMPIF(1) g

Constants and Variables We have not yet discussed generation of LetCommand. This is the place in MiniTriangle where declarations are. Calculated during generation for elaborate[D] execute [let D in C] = elaborate[D] execute [C] POP(0) s if s>0 where s = amount of storage allocated by D How to know these? fetch [V] = LOAD d[SB] where d = address of V relative to SB assign [V] = STORE d[SB] where d = address of V relative to SB

Constants and Variables Example Accessing known values and known addresses let const b ~ 10; var i:Integer; in i := i*b PUSH 1 LOAD 4[SB] LOADL 10 CALL mult STORE 4[SB] elaborate[const … ; var …] execute [i:=i*b]

Constants and Variables Example Accessing an unknown value. Not all constants have values known (at compile time). let var x:Integer; in let const y ~ 365 + x in putint(y) Depends on variable x: value not known at compile time. When visiting declarations the code generator must decide whether to represent constants in memory or as a literal value => We have to remember the address or the value somehow.

Constants and Variables Example Accessing an unknown value. let var x:Integer; in let const y ~ 365 + x in putint(y) PUSH 1 LOADL 365 LOAD 4[SB] CALL add STORE 5[SB] LOAD 5[SB] CALL putint elaborate[var x:Integer] elaborate[const y ~ 365 + x] execute [putint(y)]

Constants and Variables Entity descriptions: When the code generator visits a declaration: 1) it decides whether to represent it as a known value or a known address 2) if its an address then emit code to reserve space. 3) make an entity description: an object that describes the variable or constant: its value or address, its size. 4) put a link in the AST that points to the entity description Example and picture on next slide

Constants and Variables let const b ~ 10; var i:Integer; in i := i*b RECAP: Applied occurrences of Identifiers point to their declaration LetCommand SequentialDeclaration ConstDecl VarDecl Ident Int.Exp Ident Ident Ident Ident b 10 i i i b known value size = 1 value = 10 known address address = 4 size = 1

Constants and Variables let var x:Integer; in let const y ~ 365 + x in putint(y) LetCommand Note: There are also unknown addresses. More about these later. VarDecl Ident x ConstDecl Ident y Q: When do unknown addresses occur? known address address = 4 size = 1 unknown value address = 5 size = 1

Values and Addresses Known value: this describes a value bound in a constant declaration whose right side is a literal Unknown value: this describes a value bound in a constant declaration whose right side must be evaluated at run-time, or an argument value bound to a constant parameter Known address: this describes an address allocated and bound in a variable declaration Unknown address: this describes an argument address bound to a variable parameter Entity descriptions are used in all these cases; for unknown entities, the addresses are known at run-time, and the code generated will fetch unknown entities at run-time

Static Storage Allocation Example 1: Global variables Tam Address: a 0[SB] b 1[SB] c 2[SB] d 3[SB] let var a: Integer; var b: Boolean; var c: Integer; var d: Integer; in ... Note: In this example all globals have the same size: 1. This is not always the case.

Static Storage Allocation Example 2: Static allocation with nested blocks: overlays Tam Address: a 0[SB] b 1[SB] c 2[SB] d 1[SB] let var a: Integer; in begin ... let var b: Boolean; var c: Integer; in begin ... end; let var d: Integer; end Same address! Q: Why can b and d share the same address?

Static Storage Allocation: In the Code Generator Entity Descriptions: public abstract class RuntimeEntity { public short size; ... } public class KnownValue extends RuntimeEntity { public short value; public class UnknownValue extends RuntimeEntity { public short address; public class KnownAddress extends RuntimeEntity {

Static Storage Allocation: In the Code Generator Entity Descriptions: public abstract class AST { public RuntimeEntity entity; // mostly used for Decls ... } Each nonterminal node of the AST has an entity field. Note: This is an addition to the AST class and requires recompilation of a lot of code if added late in the compiler implementation, but there seems to be no way around it!

Static Storage Allocation: In the Code Generator public Object visit...Command( ...Command com, Object arg) { short gs = shortValueOf(arg); generate code as specified by execute[com] return null; } public Object visit...Expression( ...Expression expr, Object arg) { generate code as specified by evaluate[com] return new Short(size of expr result); public Object visit...Declaration( ...Declaration dec, Object arg) { return new Short(amount of extra allocated by dec);

Static Storage Allocation: In the Code Generator The visitor is started … public void encode(Program prog) { prog.visit(this, new Short(0)); } Amount of global storage already allocated. Initially = 0

Static Storage Allocation: In the Code Generator Some concrete examples of visit methods elaborate [var I : T] = PUSH s where s = size of T public Object visitVarDeclaration( VarDeclaration decl, Object arg) { short gs = shortValueOf(arg); short s = shortValueOf(decl.T.visit(this, null)); decl.entity = new KnownAddress(s, gs); emit(Instruction.PUSHop, 0, 0, s); return new Short(s); } Remember the address/size of the variable

Static Storage Allocation: In the Code Generator elaborate [D1 ; D2] = elaborate [D1] elaborate [D2] public Object visitSequentialDeclaration( SequentialDeclaration decl, Object arg) { short gs = shortValueOf(arg); short s1 = shortValueOf(decl.D1.visit(this,arg)); short s2 = shortValueOf(decl.D2.visit(this, new Short(gs+s1))); return new Short(s1+s2); }

Static Storage Allocation: In the Code Generator execute [let D in C] = elaborate[D] execute [C] POP(0) s if s>0 where s = amount of storage allocated by D public Object visitLetCommand( LetCommand com, Object arg) { short gs = shortValueOf(arg); short s = shortValueOf(com.D.visit(this,arg)); com.C.visit(this,new Short(gs+s)); if (s > 0) emit(Instruction.POPop,0,0,s) return null; }

Static Storage Allocation: In the Code Generator fetch [I] = special case if I is a known literal constant LOADL v where v is the known value of I fetch [V] = LOAD d[SB] where d = address of V relative to SB public void encodeFetch(Vname name, short s) { RuntimeEntity ent = VName.I.decl.entity; if (ent instanceof KnownValue) { short v = ((KnownValue)ent).value; emit(Instruction.LOADLop, 0, 0, v); } else { short d = (entity instanceof UnknownValue) ? ((UnknownValue)ent).address : ((KnownAddress)ent).address ; emit(Instruction.LOADop, 0, Instruction.SBr, d); }

Stack Allocation, Procedures and Functions Now we will consider: 1) how procedures and functions are compiled 2) how to modify code generator to compute addresses when we use a stack allocation model (instead of static allocation)

RECAP: TAM Frame Layout Summary Arguments for current procedure they were put here by the caller. arguments LB dynamic link static link return address Link data local variables and intermediate results Local data, grows and shrinks during execution. ST

RECAP: Accessing Global & Local Variables Example: Compute the addresses of the variables in this program Var Size Address let var a: array 3 of Integer; var b: Boolean; var c: Char; proc Y() ~ let var d: Integer; var e: ... in ... ; proc Z() ~ let var f: Integer; in begin ...; Y(); ... end in begin ...; Y(); ...; Z(); end [0]SB [3]SB [4]SB a b c d e f 3 1 1 ? [2]LB [3]LB 1 [2]LB

RECAP: TAM addressing schemas overview We now have a complete picture of the different kinds of addresses that are used for accessing variables and formal parameters stored on the stack. Type of variable Global Local Parameter Non-local, 1 level up Non-local, 2 levels up ... Load instruction LOAD +offset[SB] LOAD +offset[LB] LOAD -offset[LB] LOAD +offset[L1] LOAD +offset[L2]

How To Characterize Addresses now? When we have a static allocation model only, an address can be characterized by a single positive integer (i.e. the offset from SB) Now we generalize this to stack allocation (for nested procedures) Q: How do we characterize an address for a variable/constant now? A: We need two numbers. - nesting level - offset (similar to static allocation) Q: How do we compute the addresses to use in an instruction that loads or stores a value from/to a variable?

How To Characterize Addresses Example: Compute the addresses of the variables in this program Var Size Addr Accessing let var a: array 3 of Integer; var b: Boolean; proc foo() ~ let var d: Integer; var e: ... proc bar() ~ let var f: Integer; in ...bar body... in ...foo body... ; in ... global code ... a b d e f 3 1 (0,0) (0,3) (1,0) (1,1) (3,0) 0[SB] 3[SB] ? How to access depends on … where are you accessing from! 1 ? 1 0[LB] accessing e from foo body => accessing e from bar body => 1[LB] 1[L1]

New Fetch / Assign Code Templates fetch [I] = LOADL(s) d[r] s = Size of the type of I d from address of I is (d, l) r determined by l and cl (current level) How to determine r l = 0 ==> r = SB l = cl ==> r = LB otherwise ==> r = L(cl-l)

How To Modify The Code Generator An info structure to pass as argument in the visitor (instead of “gs”) public class Frame { public byte level; public short size; } Before it was sufficient to pass the current size (gs) of the global frame since without procedures all storage is allocated at level 0. With subprograms we need to know the current level and the size of the frame.

How To Modify The Code Generator Different kind of “address” in entity descriptors public class EntityAddress { public byte level; public short displacement; } public class UnknownValue extends RuntimeEntity { public EntityAddress address; ... } public class KnownAddress extends RuntimeEntity {

How To Modify The Code Generator Changes to code generator (visitor) Example: public Object visitVarDeclaration( VarDeclaration decl, Object arg) { Frame frame = (Frame)arg; short s = shortValueOf(decl.T.visit(this,null)); decl.entity = new KnownAddress(s,frame); emit(Instruction.PUSHop, 0, 0, s); return new Short(s); } etc. Q: When will the level of a frame be changed? Q: When will the size be changed?

Change of frame level and size In the visitor/encoding method for translating a procedure body, the frame level must be incremented by one and the frame size set to 3 (space for link data) Frame outerFrame … Frame localFrame = new Frame(outerFrame.level +1, 3); The encoder starts at frame level 0 and with no storage allocated: public void encoder(Program prog) { Frame globalFrame = new Frame(0,0); prog.visit(this, globalFrame); }

Procedures and Functions We extend Mini Triangle with procedures: Declaration ::= ... | proc Identifier ( ) ~ Command Command | Identifier ( ) First , we will only consider global procedures (with no arguments).

Code Template: Global Procedure elaborate [proc I () ~ C] = JUMP g e: execute [C] RETURN(0) 0 g: C execute [I ()] = CALL(SB) e

Code Template: Global Procedure Example: let var n: Integer; proc double() ~ n := n*2 in begin n := 9; double() end 0: PUSH 1 1: JUMP 7 2: LOAD 0[SB] 3: LOADL 2 4: CALL mult 5: STORE 0[SB] 6: RETURN(0) 0 7: LOADL 9 8: STORE 0[SB] 9: CALL(SB) 2 10:POP(0) 1 11:HALT var n: Integer proc double() ~ n := n*2 n := n*2 n := 9 double()

Procedures and Functions We extend Mini Triangle with functions: Declaration ::= ... | func Identifier ( ) : TypeDenoter ~ Expression | Identifier ( ) First , we will only consider global functions (with no arguments). This is all pretty much the same as procedures (except for the RETURN)

Code Template: Global Function elaborate [func I () : T ~ E] = JUMP g e: evaluate [E] RETURN(s) 0 g: C where s is the size of T evaluate [I ()] = CALL(SB) e

Nested Procedures and Functions Again, this is all pretty much the same except for static links. When calling a (nested) procedure we must tell the CALL where to find the static link. Revised code template: execute [I ()] = CALL(r) e e from address of I is (d, l) r determined by l and cl (current level) evaluate [I ()] = CALL(r) e

Procedures and Functions: Parameters We extend Mini Triangle with ... Declaration ::= ... | proc Identifier (Formal) : TypeDenoter ~ Expression | Identifier (Actual) Formal ::= Identifier : TypeDenoter | var Identifier : TypeDenoter Actual ::= Expression | var VName

Procedures and Functions: Parameters Parameters are pushed right before calling a proc/func. They are addressed like locals, but with negative offsets (in TAM). let proc double(var n:Integer) ~ n := n*2 in ... arguments UnknownAddress LB dynamic link static link return addres address = (1,-1) local variables and intermediate results ST

Code Templates Parameters elaborate [proc I(FP) ~ C] = JUMP g e: execute [C] RETURN(0) d g: where d is the size of FP execute [I (AP)] = passArgument [AP] CALL(r) e passArgument [E] = evaluate [E] passArgument [var V] = fetchAddress [V] Where (l,e) = address of routine bound to I, Cl = current routine level R = display-register(cl,l)

Code Templates Parameters An “UnknownAddress” extra case for fetch and assign fetch [V] = if V bound to unknown address LOAD d[r] where (d,l) = address where the LOADI(s) unknown address will be stored at runtime. s is the size of the type of V assign [V] = LOAD d[r] STOREI(s) where d = address where the unknown address will be stored a runtime.

Runtime Entities Overview Known Unknown const lucky ~ 888 const foo ~ x + 10 Value Address Routine value: 888 address: (level,offset) the address where value will be stored var counter : Integer A var parameter address: (level,offset) of the address where the pointer will be stored. address: (level,offset) of the variable. proc double() ~ ... A procedure or function parameter. address: (level,offset) address where closure object will be stored. address: (level,offset) of the routine (label e in template)

Code generation summary Create code templates inductively There may be special case templates generating equivalent, but more efficient code Use visitors pattern to walk the AST recursively emitting code as you go along Back patching is needed for forward jumps It is necessary to keep track of frame level and allocated space That’s it folks! At least for MiniTriangle on TAM