1 / 20

CS412/413

CS412/413. Introduction to Compilers and Translators Spring ’99 Lecture 14: Canonical Intermediate Code. Administration. Prelim 1 on Monday in class topics covered: regular expressions, tokenizing, context-free grammars, LL & LR parsers, static semantics No class Wednesday

dooley
Download Presentation

CS412/413

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS412/413 Introduction to Compilers and Translators Spring ’99 Lecture 14: Canonical Intermediate Code

  2. Administration • Prelim 1 on Monday in class • topics covered: regular expressions, tokenizing, context-free grammars, LL & LR parsers, static semantics • No class Wednesday • Programming Assignment 2 due Friday • Prelim review tomorrow (Saturday) 7-9 PM CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  3. Where we are abstract syntax tree translation functions intermediate code canonicalization canonical intermediate code code generation assembly code CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  4. Why canonical form? • Intermediate code has general tree form • easy to generate from AST, but... • Hard to translate directly to assembly • assembly code is a sequence of statements • Intermediate code has nodes corresponding to assembly statements deep in expression trees • Canonical form: all statements brought up to top level of tree -- can generate assembly directly CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  5. Statements • Statements corresponding to assembly: • MOVE, JUMP, CJUMP, EXP(CALL(…), MOVE(CALL(…),…), LABEL • Extra constructs to make IR gen easier: SEQ, ESEQ, CALL (as arbitrary expression) • SEQ, ESEQ keep track of what order two statements (or a statement and an expression) are supposed to be evaluated in • need to get rid of these and also move CALL expressions up to top under MOVE or EXP CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  6. SEQ SEQ SEQ SEQ + SEQ ESEQ LABEL CALL SEQ MOVE Canonicalization SEQ SEQ SEQ SEQ SEQ SEQ ... ... MOVE JUMP LABEL EXP ... CALL CALL CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  7. Pulling statements up • Can’t have statement nodes under an expression node • Can only occur because of ESEQ(s,e) • For each expression node type, canonicalize transforms an expression e into statements (s1, s2, s3,…) and a side-effect-free expression e´ • Can implement recursively CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  8. Rewrite rules • Canonicalize e: e (s1, s2, s3,…), e’ e (s1,…, sm ), e’ ESEQ(s, e)  (s, s1,…, sm ), e’ e1  (s1,…, sm), e’1 e2  (s’1,…, s’n), e’2 +(e1,e2)  (s1,…, sm, MOVE(e’1,TEMP(t)), s’1,…, s’n), +(TEMP(t), e’ 2) e1  (s1,…, sm), e’1 e2  (), e’2 +(e1,e2)  (s1,…, sm), +(e’1, e’ 2) CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  9. CALL nodes • CALL nodes call a function which may have side effects • Overwrites return value register at least; can’t be operand at assembly-code level • Therefore, CALL nodes must move to top • Idea: CALL( f, args)Þ (MOVE(CALL(f, args), TEMP(t)), TEMP(t) CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  10. Flattening SEQ nodes • All SEQ nodes now top level or children only of SEQ nodes • No ESEQ nodes -- all statement nodes are children of SEQ nodes • All CALL nodes children of EXP nodes or MOVE nodes at top level • Final step: linearize SEQ nodes: in-order SEQ ... SEQ SEQ SEQ SEQ SEQ SEQ s1 s2 s3 s4 s1 s2 s3 s4 CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  11. Linearization rules •  for statements: s (s1, s2, s3,…) s1 (s1,…sm ) s2  (s’1,…, s’n) SEQ(s1, s2)  (s1,…sm, s’1,…, s’n) e1 (s1,…sm ), e’1 e2 (s’1,…s’n ), e’2 MOVE(e1, e2 )  (s1,…sm , s’1,…s’n , MOVE(e’1 , e’2)) CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  12. Flattened tree • Two recursive transformations s (s1, s2, s3,…) e (s1, s2, s3,…), e’ • Can be applied to any IR tree s • Result: a linear list of statements (s1, s2, s3,…) • All statements one of MOVE, JUMP, CJUMP, EXP(CALL(…), MOVE(CALL(…),…), LABEL CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  13. Conditional jumps • IR is now just a linear list of statements • Still contains CJUMP nodes : two-way branches • Real machines : fall-through branches (e.g. JZ, JNZ) CJUMP e, t, f ... LABEL(t) if-true code LABEL(f) evaluate e JZ f if-true code f: CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  14. Basic blocks • A basic block is a sequence of statements that is always begun at its start and always exits at the end: • starts with a LABEL(n) statement • ends with a JUMP or CJUMP statement • contains no other JUMP or CJUMP statement • contains no interior LABEL that is used as the target for a JUMP or CJUMP from elsewhere CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  15. Fixing conditional jumps • Reorder basic blocks so that (if possible) • the “false” direction of two-way jumps goes to the very next block • JUMPs go to the next block • What if not satisfied? • For CJUMP add another JUMP immediately after to go to the right basic block • How to find such an ordering of the basic blocks? CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  16. Traces • Idea: order blocks according to a possible trace: a sequence of blocks that might (naively) be executed in sequence, never visiting a block more than once • Algorithm: • pick an unmarked block (begin w/ start block) • run a trace until no more unmarked blocks can be visited, marking each block on arrival • repeat until no more unmarked blocks CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  17. 1 2 4 5 3 Example • Possible traces? CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  18. 1 Arranging by traces 1 1 2 4 5 3 2 3 2 4 4 5 5 3 CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  19. Conclusions • Simple code transformations () can transform the IR representation into a canonical form that is similar to assembly code. • Get rid of ESEQ, SEQ nodes • Move CALL to top level • Convert to linear sequence of statements • Make all CJUMP’s one-way jumps by identifying, rearranging basic blocks. • Result: ready to generate assembly code! CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

  20. Reminder • Prelim 1 on Monday in class • topics covered: regular expressions, tokenizing, context-free grammars, LL & LR parsers, static semantics • No class Wednesday • Programming Assignment 2 due Friday • Prelim review tomorrow (Saturday) 7-9 PM CS 412/413 Introduction to Compilers and Translators -- Spring '99 Andrew Myers

More Related