Class 30: Canonical trees

Held Wednesday, November 18, 1998

Handouts

• Assignment: Presentations
• Assignment: Final Project

Notes

• I seem to be missing my Green Tiger book. If I could borrow one for a few days, I'd appreciate it. Found it!

Making the transition to assembly code

• We've gradually made the transition from Tiger programs as sequences of characters to Abstract syntax trees (ASTs), and from ASTs to Intermediate representation trees (IRTs).
• How do we make the transition from IRTs to assembly code?
• We begin by considering some of the differences between IRTs and assembly code:
  • IRTs permit bidirectional conditional branches, while typical assembly codes permit only unidirectional conditional branches (branch to X if Y holds)
  • IRTs permit complex arguments to the various instructions while typical assembly codes restrict the complexity of arguments
  • IRTs permit sequencing within the arguments to various instructions, while typical assembly codes permit only a single sequence
• We've also noted that some pieces of code (which Appel designates ``code fragments'') do not yet have a place within the program. These include function bodies and strings.
• We'll approach each of these issues separately.
  • First, we'll look at sequencing. (Today)
  • Next, we'll look at organizing code fragments. (Friday)
  • Finally, we'll consider the simplification of complex expressions. (Next week)

Canonical IRT Trees

• We'll begin by defining a particular form of IRTs which Appel calls ``canonical trees''.
• Note that we will be translating general IRTs to a sequence of canonical trees.
• Canonical trees do not contain SEQ or ESEQ. These are handled by the sequencing mentioned above.
• Canonical trees restrict the use of CALL, so that each CALL is only used in a MOVE (which stores the result somewhere) or EXP (which throws away the result).

Building Canonical Trees

• So, how do we transform non-canonical trees into sequences of canonical trees?
  • We try to propagate the SEQ and ESEQ nodes up in the tree.
  • We add some new temporaries to hold the results of CALL nodes.
• We'll use a technique known as rewriting to move nodes through the tree.
• ESEQ(s1, ESEQ(s2, e))
  • ``Do s1, then s2, then evaluate e''
  • Can be written ESEQ(SEQ(s1,s2), e)
• BINOP(op, ESEQ(s,e1), e2)
  • ``Do s1, then evaluate e1, then evaluate e2, then apply op''
  • Can be written ESEQ(s, BINOP(op, e1, e2))
• BINOP(op, e1, ESEQ(s, e2))
  • ``Evaluate e1, then do s1, then evaluate e2, then apply op''
  • We can't simply do s before e1 since s may have side-effects.
  • We'll need to evaluate e1 first and put it in a new temporary.
  • ESEQ(MOVE(TEMP(t), e1), ESEQ(s, BINOP(op,TEMP(t), e2)))
  • Note that the nesting of ESEQs is then handled by a different rule.
  • Note also that we can do something much simpler if we can verify that e1 doesn't use anything modified by s. In that case, we might write
    ESEQ(s, BINOP(op, e1, e2)).

History

• Created Wednesday, November 18, 1998 (with the full contents).
• On Friday, November 20, 1998, deleted some uncovered material.