Principles of Programming Languages

Similar documents
Intermediate Code Generation

Module 26 Backpatching and Procedures

Intermediate Code Generation Part II

UNIT-3. (if we were doing an infix to postfix translator) Figure: conceptual view of syntax directed translation.

CMPSC 160 Translation of Programming Languages. Three-Address Code

Principles of Programming Languages

ΕΠΛ323 - Θεωρία και Πρακτική Μεταγλωττιστών

Compilerconstructie. najaar Rudy van Vliet kamer 140 Snellius, tel rvvliet(at)liacs(dot)nl. college 7, vrijdag 2 november 2018

Principles of Programming Languages

Theory of Compilation Erez Petrank. Lecture 7: Intermediate Representation Part 2: Backpatching

Principles of Programming Languages

CSE443 Compilers. Dr. Carl Alphonce 343 Davis Hall

CS2210: Compiler Construction. Code Generation

Syntax-Directed Translation

Formal Languages and Compilers Lecture X Intermediate Code Generation

UNIT IV INTERMEDIATE CODE GENERATION

NARESHKUMAR.R, AP\CSE, MAHALAKSHMI ENGINEERING COLLEGE, TRICHY Page 1

2 Intermediate Representation. HIR (high level IR) preserves loop structure and. More of a wizardry rather than science. in a set of source languages

THEORY OF COMPILATION

Principle of Compilers Lecture VIII: Intermediate Code Generation. Alessandro Artale

Intermediate Code Generation

Chapter 6 Intermediate Code Generation

Intermediate Representa.on

CMPT 379 Compilers. Anoop Sarkar. 11/13/07 1. TAC: Intermediate Representation. Language + Machine Independent TAC

Intermediate Code Generation

Intermediate Code Generation

Intermediate Code Generation

Dixita Kagathara Page 1

Intermediate Code Generation

Intermediate Representations

CS322 Languages and Compiler Design II. Spring 2012 Lecture 7

intermediate-code Generation

Time : 1 Hour Max Marks : 30

Principles of Programming Languages

Module 25 Control Flow statements and Boolean Expressions

Prof. Mohamed Hamada Software Engineering Lab. The University of Aizu Japan

Concepts Introduced in Chapter 6

Concepts Introduced in Chapter 6

Compilerconstructie. najaar Rudy van Vliet kamer 124 Snellius, tel rvvliet(at)liacs(dot)nl

CSc 453 Intermediate Code Generation

Intermediate Code Generation

Control Structures. Boolean Expressions. CSc 453. Compilers and Systems Software. 16 : Intermediate Code IV

CSE443 Compilers. Dr. Carl Alphonce 343 Davis Hall

COP5621 Exam 3 - Spring 2005

Syntax-Directed Translation. Concepts Introduced in Chapter 5. Syntax-Directed Definitions

Intermediate Code Generation

CSc 453. Compilers and Systems Software. 16 : Intermediate Code IV. Department of Computer Science University of Arizona

CSCI565 Compiler Design

opt. front end produce an intermediate representation optimizer transforms the code in IR form into an back end transforms the code in IR form into

CSE443 Compilers. Dr. Carl Alphonce 343 Davis Hall

Compiler Optimization Intermediate Representation

Semantic analysis and intermediate representations. Which methods / formalisms are used in the various phases during the analysis?

PSD3A Principles of Compiler Design Unit : I-V. PSD3A- Principles of Compiler Design

Computer Science Department Carlos III University of Madrid Leganés (Spain) David Griol Barres

PRINCIPLES OF COMPILER DESIGN

Alternatives for semantic processing

Intermediate Code Generation

Compiler Theory. (Intermediate Code Generation Abstract S yntax + 3 Address Code)

Acknowledgement. CS Compiler Design. Intermediate representations. Intermediate representations. Semantic Analysis - IR Generation

Compilers. 5. Attributed Grammars. Laszlo Böszörmenyi Compilers Attributed Grammars - 1

Generating 3-Address Code from an Attribute Grammar

SYNTAX DIRECTED TRANSLATION FOR CONTROL STRUCTURES

Page No 1 (Please look at the next page )

Module 27 Switch-case statements and Run-time storage management

Object Code (Machine Code) Dr. D. M. Akbar Hussain Department of Software Engineering & Media Technology. Three Address Code

Compilers. Intermediate representations and code generation. Yannis Smaragdakis, U. Athens (original slides by Sam

CSCI565 Compiler Design

Syntax-Directed Translation Part II

PART 6 - RUN-TIME ENVIRONMENT. F. Wotawa TU Graz) Compiler Construction Summer term / 309

COMPILER CONSTRUCTION (Intermediate Code: three address, control flow)

Principles of Programming Languages

Principle of Complier Design Prof. Y. N. Srikant Department of Computer Science and Automation Indian Institute of Science, Bangalore

ΕΠΛ323 - Θεωρία και Πρακτική Μεταγλωττιστών. Lecture 8a Syntax-directed Transla1on Elias Athanasopoulos

Code Genera*on for Control Flow Constructs

CSCI Compiler Design

CSCI Compiler Design

Intermediate representation

Intermediate Representations

Compiler. --- Intermediate Code Generation. Zhang Zhizheng.

Intermediate Representations

Syntax-Directed Translation Part I

Languages and Compiler Design II IR Code Generation I

Intermediate Code Generation

Intermediate-Code Generat ion

PRINCIPLES OF COMPILER DESIGN UNIT IV SYNTAX DIRECTED TRANSLATION AND TYPE CHECKING

Syntax-Directed Translation

EDA180: Compiler Construc6on Context- free grammars. Görel Hedin Revised:

Advanced Topics in MNIT. Lecture 1 (27 Aug 2015) CADSL

The analysis part breaks up the source program into constituent pieces and creates an intermediate representation of the source program.

Semantic Analysis computes additional information related to the meaning of the program once the syntactic structure is known.

Syntax-directed translation. Context-sensitive analysis. What context-sensitive questions might the compiler ask?

Intermediate Representations

Intermediate Code & Local Optimizations

Semantic Analysis and Intermediate Code Generation

Semantic Actions and 3-Address Code Generation

Context-sensitive analysis. Semantic Processing. Alternatives for semantic processing. Context-sensitive analysis

Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at Rice University have explicit

CMSC430 Spring 2009 Midterm 2 (Solutions)

PART 4 - SYNTAX DIRECTED TRANSLATION. F. Wotawa TU Graz) Compiler Construction Summer term / 309

Principles of Programming Languages

Transcription:

Principles of Programming Languages h"p://www.di.unipi.it/~andrea/dida2ca/plp-16/ Prof. Andrea Corradini Department of Computer Science, Pisa Lesson 11! Intermediate-Code Genera=on Intermediate representa=ons Syntax-directed transla=on to three address code

Intermediate Code Genera=on (II) Facilitates retarge&ng: enables agaching a back end for the new machine to an exis=ng front end Tokens Parsing Syntax-Directed Defini=ons Syntax-Directed Transla=on Schemes Intermediate code Back end Target code 2

Summary Intermediate representa=ons Three address statements and their implementa=ons Syntax-directed transla=on to three address statements Expressions and statements Logical and rela=onal expressions Transla=ng short-circuit Boolean expressions and flow-ofcontrol statements with backpatching lists 3

Intermediate Representa=ons Graphical representa&ons (e.g. AST and DAGs) Pos2ix nota&on: opera=ons on values stored on operand stack (similar to JVM bytecode) Three-address code: (e.g. triples and quads) x := y op z Two-address code: x := op y which is the same as x := x op y 4

Syntax-Directed Transla=on of Abstract Syntax Trees Produc=on S id := E E E 1 + E 2 E E 1 * E 2 E - E 1 E ( E 1 ) E id Seman=c Rule S.nptr := mknode( :=, mkleaf(id, id.entry), E.nptr) E.nptr := mknode( +, E 1.nptr, E 2.nptr) E.nptr := mknode( *, E 1.nptr, E 2.nptr) E.nptr := mknode( uminus, E 1.nptr) E.nptr := E 1.nptr E.nptr := mkleaf(id, id.entry) 5

Abstract Syntax Trees E.nptr a * (b + c)! E.nptr * E.nptr a! ( E.nptr ) Pro: easy restructuring of code and/or expressions for intermediate code op=miza=on Cons: memory intensive E.nptr b! + E.nptr c *! a! +! b! c! 6

Abstract Syntax Trees versus DAGs a := b * -c + b * -c! := a + * * := a + * b uminus b uminus b uminus c Tree c DAG c Repeated subtrees are shared Implementa=on: mkleaf and makenode are redefined. They do not create a new node if it exists already. 7

Pos]ix Nota=on a := b * -c + b * -c! a b c uminus * b c uminus * + assign Pos]ix nota=on represents opera=ons on a stack Pro: easy to generate Cons: stack opera=ons are more difficult to op=mize Bytecode (for example) iload 2 // push b iload 3 // push c ineg // uminus imul // * iload 2 // push b iload 3 // push c ineg // uminus imul // * iadd // + istore 1 // store a 8

Three-Address Code (1) a := b * -c + b * -c! := t1 := - c t2 := b * t1 t3 := - c t4 := b * t3 t5 := t2 + t4 a := t5 b a + * uminus b * uminus Linearized representation of a syntax tree c Tree c 9

Three-Address Code (2) a := b * -c + b * -c! := a + * t1 := - c t2 := b * t1 t5 := t2 + t2 a := t5 b uminus DAG c Linearized representation of a syntax DAG 10

Three-Address Statements Addresses are names, constants or temporaries Assignment statements: x:= y op z, x:= op y Indexed assignments: x:= y[i], x[i]:= y Pointer assignments: x:= &y, x:= *y, *x:= y Copy statements: x:= y Unconditional jumps: goto lab Conditional jumps: if x relop y goto lab Function calls: param x ; call p, n (or y = call p, n) ; return y 11

Implementa=on of Three-Address Statements: Quads Sample expression a := b * -c + b * -c! Three-address code t1 := - c t2 := b * t1 t3 := - c t4 := b * t3 t5 := t2 + t4 a := t5 # Op Arg1 Arg2 Res (0) uminus c t1 (1) * b t1 t2 (2) uminus c t3 (3) * b t3 t4 (4) + t2 t4 t5 (5) := t5 a Quads (quadruples) Pro: easy to rearrange code for global op=miza=on Cons: lots of temporaries 12

Implementa=on of Three-Address Statements: Triples Sample expression a := b * -c + b * -c! Three-address code t1 := - c t2 := b * t1 t3 := - c t4 := b * t3 t5 := t2 + t4 a := t5 # Op Arg1 Arg2 (0) uminus c (1) * b (0) (2) uminus c (3) * b (2) (4) + (1) (3) (5) := a (4) Triples Pro: temporaries are implicit Cons: difficult to rearrange code 13

Implementa=on of Three-Address Statements: Indirect Triples # Stmt (0) (14) (1) (15) (2) (16) (3) (17) (4) (18) (5) (19) Program # Op Arg1 Arg2 (14) uminus c (15) * b (14) (16) uminus c (17) * b (16) (18) + (15) (17) (19) := a (18) Triple container Pro: temporaries are implicit & easier to rearrange code 14

Syntax-Directed Transla=on into Three-Address Code ProducEons S id := E while E do S S ; S E E + E E * E - E ( E ) id Synthesized attributes: S.code three-address code for S S.begin label to start of S or nil S.after label to end of S or nil E.code three-address code for E E.place a name holding the value of E num gen(e.place := E 1.place + E 2.place) Code generation t3 := t1 + t2 15

Syntax-Directed Transla=on into Three-Address Code (cont d) ProducEons S id := E S while E do S 1 E E 1 + E 2 E E 1 * E 2 E - E 1 E ( E 1 ) E id E num S S 1 ; S 2 Semantic rules S.code := E.code gen(id.place := E.place); S.begin := S.after := nil (see next slide) E.place := newtemp(); E.code := E 1.code E 2.code gen(e.place := E 1.place + E 2.place) E.place := newtemp(); E.code := E 1.code E 2.code gen(e.place := E 1.place * E 2.place) E.place := newtemp(); E.code := E 1.code gen(e.place := uminus E 1.place) E.place := E 1.place E.code := E 1.code E.place := id.name E.code := E.place := newtemp(); E.code := gen(e.place := num.value) S.code := S 1.code S 2.code S.begin := S 1. begin S.after := S 2.after 16

Syntax-Directed Transla=on into Three-Address Code (cont d) ProducEon S while E do S 1 Semantic rule S.begin := newlabel() S.after := newlabel() S.code := gen(s.begin : ) E.code gen( if E.place = 0 goto S.after) S 1.code gen( goto S.begin) gen(s.after : ) S.begin: S.after: E.code if E.place = 0 goto S.after S.code goto S.begin 17

Example (check it at home!) i := 2 * n + k; while i do i := i - k! t1 := 2 t2 := t1 * n t3 := t2 + k i := t3 L1: if i = 0 goto L2 t4 := i - k i := t4 goto L1 L2: 18

How does the code access names? The three-address code generated by the syntaxdirected defini=ons shown is simplis=c It assumes that the names of variables can be easily resolved by the back-end in global or local variables We need local symbol tables to record global declara=ons as well as local declara=ons in procedures, blocks, and records (structs) to resolve names We will see all this later in the course 19

Transla=ng Logical and Rela=onal Expressions Boolean expressions intended to represent values: a or b and not c t1 := not c t2 := b and t1 t3 := a or t2 Boolean expressions used to alter the control flow: a < b if a < b goto L1 t1 := 0 goto L2 L1: t1 := 1 L2: 20

Short-Circuit Code The boolean operators &&, and! are translated into jumps. Example: if ( x < 100 x > 200 && x!= y ) x = 0; may be translated into: if x < 100 goto L2 iffalse x > 200 goto L1 iffalse x! = y goto L1 L2: x=0 L1: 21

हအᏆเ ᗮ ᗮ Ⴜเ ዔ ᗮ በዔ ࡐ ᗮ ᒹᗮ Ꭿ เ ஸᗮᏅႼᗮ በᒹ ዔࡐᒏᗮዔᅻ በᗮࡐ ᗮዔ ᗮ ዔዔ हအ ᗮ Ꭿᅻ ஸᗮࡐᗮዔᅻ ᗮዔᅻࡐᐕ ᅻበࡐเýᗮအᅻᗮ ᒹᗮࡐ ᒹᗮအ ᗮዔ ᗮࡐႼზᅻအࡐह በᗮအᎯዔเ ᗮ ᗮ हዔ အ ᗮΥȪΥ >dz Ư dz ݫ ᗮዔᅻࡐ በเࡐዔ အ ᗮအ ᗮ ɼǬ " : हအ በ በዔበᗮအ ᗮ# အเเအᑌ ᗮ ᒹᗮŗ: ࡐበᗮ เเᎯበ ዔᅻࡐዔ ᗮ ᗮ ஸȪᗮνȪ Υ Ï ࡐÃ Ȫᗮ ߖ ዔ ᗮ # ࡐᅻ ᗮ Ꭿ Ⴜበᗮ ࡐበ ᗮအ ᗮዔ ᗮᐕࡐเᎯ ᗮအ ᗮ צ ᗮ በᗮዔᅻᎯ ýᗮहအ ዔᅻအเᗮ အᑌበᗮዔအᗮዔ ᗮ୪ᅻበዔᗮ በዔᅻᎯहዔ အ ᗮအ ᗮ : ࡐ ᗮ ᗮ በᗮ ࡐเበ ýᗮहအ ዔᅻအ በเࡐዔ အ ᗮအ ᗮ အအเ ࡐ ᗮ ᒏႼᅻ በበ အ በᗮ ዔအᗮዔ ᅻ Ÿࡐ ᅻ በበᗮहအ ᗮ အᑌበᗮዔအᗮዔ ᗮ በዔᅻᎯहዔ အ ᗮ ࡐዔ เᒹᗮ အเเအᑌ ஸᗮ : ' ዔበᗮበᎯह ᗮࡐበᗮዔ အበ ᗮஸ ᅻࡐዔ ᗮ ᒹᗮዔ ᗮ အเเအᑌ ஸᗮஸᅻࡐ ࡐᅻгᗮ Transla=ng Flow-of-control Statements ŗ ҿ ҿ Hҿ ɼ Î æ ŗ: ɼ Î æ f ɼ % ' ɼ Î æ : ( (! ¹ ¹ : Þ ዔအᗮ (! ዔအᗮ ( ď ( (! ¹ ዔᗮūҿ (! ዔအᗮ ( ƾ ƿ 2Ŵ ' Ϯ i! အ ዔ ᅻ ࡐเᗮ ᅻ Ⴜᅻ በ ዔበᗮࡐᗮ အအเ ࡐ ᗮ ᒏႼᅻ በበ အ ᗮࡐ ᗮ အ ᔳ ( ď ¹ Ï ࡐÃᗮ ᗮ 2% በዔࡐዔ ዔ Ȫᗮ i! ¹ ࡐเ ᔎ በᗮዔ ᗮᅻᎯ ஸᗮ ᒏࡐ Ⴜเ ᗮအ ᗮᑌ เ ᗮ ᒏწᅻ በበ အ በᗮዔ ࡐዔᗮᑌ ᗮ Synthesized A"ributes: ዔအᗮ (! ΥȪS.code, ДȪᗮ ӕበᗮ ᗮዔ ࡐዔᗮ ᒏࡐ Ⴜเ ýᗮ အዔ ᗮԊ ࡐ ᗮ ¹ ࡐᐕ ᗮࡐᗮበᒹ ዽ ᔳ 0 Ï Η Ɖ เበ ᗮ B.Code ( ዔအᗮ ( ď ह ᗮஸ ᐕ በᗮዔ ᗮዔᅻࡐ በเ ዔ အ ᗮ ዔအᗮዔ ᅻ Ÿࡐ ᅻ በበᗮ በዔᅻᎯहዔ အ በȪᗮ Inherited A"ributes: (! ɧ ࡐኪᗮበዔᅻ ஸበýᗮᎯበᔳ ᗮᎯႼᗮዔ ᗮዔᅻࡐ በเࡐዔ အ በᗮ ࡐ ᗮ Ɩ 2Ŵ labels for jumps: ዔ အ በȷᗮ ݫ ᗮበ ࡐ ዔ हᗮᅻᎯเ በᗮ ୪ ஸᗮዔ ʗᗮ ǎ ࡐዔዔᅻ Ꭿዔ በᗮ ' Ϯ 0 በዔ ࡐ ᗮ ᒹᗮ Ꭿ เ ஸᗮᏅႼᗮ በᒹ ዔࡐᒏᗮዔᅻ በᗮࡐ ᗮዔ ᗮ ዔዔ ஸᗮ B.true, B.false, S.next ( ď हÃᗮ ᑌ เ ᗮ ᅻበࡐเýᗮအᅻᗮ ᒹᗮࡐ ᒹᗮအ ᗮዔ ᗮࡐႼზᅻအࡐह በᗮအᎯዔเ ᗮ ᗮ हዔ အ ᗮΥȪΥȪᗮ ɼǬ " : हအ በ በዔበᗮအ ᗮ# အเเအᑌ ᗮ ᒹᗮŗ: ࡐበᗮ เเᎯበᔳ Ꭿᅻ ᗮνȩ Υюᗮ Ԧအ ᗮ အᅻᗮ Ɓýᗮ Ÿ เበ ƅýᗮࡐ ᗮᑌఆ เ Ÿበዔࡐዔ ዔበᗮ ߖ ዔ ᗮ # ࡐᅻ ᗮ Ꭿ Ⴜበᗮ ࡐበ ᗮအ ᗮዔ ᗮᐕࡐเᎯ ᗮအ ᗮ צ ᗮ ݫ ᗮเࡐ เበᗮ အᅻᗮዔ ᗮ Ꭿ Ⴜበᗮ ᗮ ࡐ ᗮ 2' ࡐᅻ ᗮ ࡐ ࡐஸ ᗮᎯበ ஸᗮ ᅻ ዔ ዔ ᗮ୪ᅻበዔᗮ በዔᅻᎯहዔ အ ᗮအ ᗮ : ࡐዔዔᅻ Ꭿዔ በȪᗮ ࡐ ᗮ ᗮ በᗮ ࡐเበ ýᗮहအ ዔᅻအเᗮ ߖ ዔ ᗮࡐᗮ အအเ ࡐ ᗮ ᒏႼᅻ በበ အ ᗮ ᑌ ᗮࡐበበအह ࡐዔ ᗮዔᑌအᗮเࡐ เበюᗮ! ዔ ࡐዔ เᒹᗮ အเเအᑌ ஸᗮ : ' 22

အᅻᗮ အအแ ࡐ ᗮ ᒏႼᅻ በበ အ በᗮ ᗮዏ ᗮहအ ዏ ᒏዏᗮအ ᗮ Ÿûᗮ Ÿ แበ Ÿûᗮࡐ ᗮᑌ แ Ÿበዏࡐዏ ዏበȪᗮ DF; V T);:u ŏ ò N!3 6T) u GV1!Ou i 9 0 T ΦϏ 0 i \ Ŵ ( ɼ Ď ɼ # \ ɂ # ҿ 9 ʿ T # / 2h i / ƥ i 2 / # È 0 ɴ \ Ƀ ȸ : ( Iɼ Ď ȣɼ # \ 2h ɼ % # ҿ 9 0 T # / 9 0 T : Ǿ i / % i ҿ i / # È 0 # \ È 2h Ù Ù N ' Ϯ Ɠ i \ È 0 # \ È % F 2 ò ' ɼ # \ : Ȟᗮ : % 0 / 9 0 T # ҿ 9 0 T # ŏ ҿ 2 ˋi 2h i ҿ 0 2 ҿ 0 0 \ È ɵ È 0 # \ È : F È N ' Ϯ 0 \ : i ҿ 9 0 T Ɋ% Ƌ i ҿ 2 i 2 / : Ù LJ 0 ǭ2h i \ È % Þ Not relevant for control flow Inherited AGributes 23

- 8 Ž 8# Z K Z = 8 Transla=on of Boolean Expressions हအ ഇዏഇအ ࡐแᗮࡐ ᗮᎯ हအ ഇዏഇအ ࡐแᗮ Ꭿ Ⴜበᗮዏအᗮ အ ᗮအ ᗮዏᑌအᗮแࡐ แበгᗮ (! ഇ ᗮ( ഇበᗮዏᅼᎯ ĉᗮ ࡐ ᗮ( ഇ ᗮ( ഇበᗮ ࡐแበ ȩᗮ >F; V T*;6u N!5 6T) u GV1!Ou ( C (c l l ť(% (c! / ( 4! (c / Ě 0 T (% 4! / ( 4! (% / ( ( 'R (c 4 Ƃ 0 (c 4 \ Ƃ (% ( Jҿ (c PPť(% (c! / Ě 0 T (c / ( (% ƕ! / (! (% 4 ҿ ( ( / (: Z Z 0 (c! \ Z Z (% 4 ( C ᗮ (c (c! ҿ ( (c / ( 4! ( / (c 4 ( C c Éɼ % ( / c 4 Z Z % Ù Z N ȩϯ c ÉIɼ % Z Z N K..N ( \ ( C # ɼ ( 4 / NK..N (! \ ( C ɼ ( / N K..«( Þ \ Inherited AGributes NK..N (4! \ 24

Example if ( x < 100 x > 200 && x!= y ) x = 0; is translated into: if x < 100 goto L2 goto L3 L3: if x > 200 goto L4 goto L1 L4: if x!= y goto L2 goto L1 L2: x=0 L1: By removing several redundant jumps we can obtain the equivalent: if x < 100 goto L2 iffalse x > 200 goto L1 iffalse x! = y goto L1 L2: x=0 L1: 25

Transla=ng Short-Circuit Expressions Using Backpatching Idea: avoid using inherited a"ributes by genera=ng par=al code. Addresses for jumps will be inserted when known. E E or M E E and M E not E ( E ) id relop id true false M ε M : marker nonterminal Synthesized attributes: E.truelist backpatch list for jumps on true E.falselist backpatch list for jumps on false M.quad location of current three-address quad 26

Backpatch Opera=ons with Lists makelist(i) creates a new list containing three-address location i, returns a pointer to the list merge(p 1, p 2 ) concatenates lists pointed to by p 1 and p 2, returns a pointer to the concatenated list backpatch(p, i) inserts i as the target label for each of the statements in the list pointed to by p 27

Backpatching with Lists: Example a < b or c < d and e < f 100: if a < b goto _ 101: goto _ 102: if c < d goto _ 103: goto _ 104: if e < f goto _ 105: goto _ backpatch 100: if a < b goto TRUE 101: goto 102 102: if c < d goto 104 103: goto FALSE 104: if e < f goto TRUE 105: goto FALSE 28

Backpatching with Lists: Transla=on Scheme M ε { M.quad := nextquad() } E E 1 or M E 2 { backpatch(e 1.falselist, M.quad); E.truelist := merge(e 1.truelist, E 2.truelist); E.falselist := E 2.falselist } E E 1 and M E 2 { backpatch(e 1.truelist, M.quad); E.truelist := E 2.truelist; E.falselist := merge(e 1.falselist, E 2.falselist); } E not E 1 { E.truelist := E 1.falselist; E.falselist := E 1.truelist } E ( E 1 ) { E.truelist := E 1.truelist; E.falselist := E 1.falselist } 29

Backpatching with Lists: Transla=on Scheme (cont d) E id 1 relop id 2 { E.truelist := makelist(nextquad()); E.falselist := makelist(nextquad() + 1); emit( if id 1.place relop.op id 2.place goto _ ); emit( goto _ ) } E true { E.truelist := makelist(nextquad()); E.falselist := nil; emit( goto _ ) } E false { E.falselist := makelist(nextquad()); E.truelist := nil; emit( goto _ ) } 30

Flow-of-Control Statements and Backpatching: Grammar S if E then S if E then S else S while E do S begin L end A L L ; S S Synthesized attributes: S.nextlist backpatch list for jumps to the next statement after S (or nil) L.nextlist backpatch list for jumps to the next statement after L (or nil) S 1 ; S 2 ; S 3 ; S 4 ; S 5 100: Code for S1 backpatch(s 1.nextlist, 200) backpatch(s 2.nextlist, 300) backpatch(s 3.nextlist, 400) 200: Code for S2 300: Code for S3 400: Code for S4 500: Code for S5 Jumps out of S 1 backpatch(s 4.nextlist, 31500)

Flow-of-Control Statements and Backpatching The grammar is modified adding suitble marking non-terminals S A { S.nextlist := nil } S begin L end { S.nextlist := L.nextlist } S if E then M S 1 { backpatch(e.truelist, M.quad); S.nextlist := merge(e.falselist, S 1.nextlist) } L L 1 ; M S { backpatch(l 1.nextlist, M.quad); L.nextlist := S.nextlist; } L S { L.nextlist := S.nextlist; } M ε { M.quad := nextquad() } A Non-compound statements, e.g. assignment, func&on call 32

Flow-of-Control Statements and Backpatching (cont d) S if E then M 1 S 1 N else M 2 S 2 { backpatch(e.truelist, M 1.quad); backpatch(e.falselist, M 2.quad); S.nextlist := merge(s 1.nextlist, merge(n.nextlist, S 2.nextlist)) } S while M 1 E do M 2 S 1 { backpatch(s 1.nextlist, M 1.quad); backpatch(e.truelist, M 2.quad); S.nextlist := E.falselist; emit( goto M 1.quad ) } N ε { N.nextlist := makelist(nextquad()); emit( goto _ ) } 33

Summarizing Transla=on from source code to intermediate representa=on can be performed in a syntaxdirected way during parsing We considered transla=on of expressions and statements to three address code, with a simplified handling of names (for example: no defini=ons) More effec=ve transla=on of boolean expressions for flow control require inherited agributes They can be avoided using backpatching 34