Class 25: Intermediate representation trees

Held Monday, November 2, 1998

Notes

• For those of you who are wondering whether we'll actually finish these compilers, we will. Some of the subsequent sections need not be implemented, and I may build an interpreter for the language of intermediate representation trees (I will build one if necessary). In past years, students have stopped at some intermediate representation (although a more linear one than IRTs).
• Reminder: next Monday (November 9) and Wednesday (November 11) there will be makeup tests.
• If you haven't done so already, make sure to scan through chapter 7. It is dense, but understandable. Plus, it has a great sermon.

Intermediate representation trees

• As we've discussed many times, it is preferable to translate from the high level language to an intermediate language, and then from that language to a concrete assembly language.
• Appel suggests using a form of expression tree that he call intermediate representation trees (IRTs). There are two ``general'' kinds of nodes in the tree:
  • expressions, which return a value (and may also have side effects, typically input, output, or changes to registers or memory);
  • statements, which return no values and are therefore used primarily for side effects.
• It turns out that the use of parts of the expression tree suggests a different separation, in which you have not just expressions and statements, but also conditional expressions which branch to one or two points depending on whether an underlying boolean expression is true or false.
  • Appel notes in the Programming section that it is possible to treat everything in the tree as an expression, but at some cost for efficiency. I will recommend that we do that.
• Note that intermediate representation trees are not a true assembly language in the sense that they permit quite complex arguments to instructions (including sequences of instructions as arguments to an instruction).
  • In chapter eight, we'll see how to change an arbitrary IRT into a sequence of instructions with no subsequencing (although still with possibly deep arguments to instructions).
  • In chapter nine, we'll see how to change a more structured IRT into a sequence of real instructions.

Core instructions

• What kinds of expressions are there? (Alternately, what instructions are there that return values?)
  • Constants
  • Names (gives the address of strings and some other structured data)
  • Temporaries (somewhat like registers, but an unlimited number)
  • Binary operations: addition, subtraction, multiplication, division, bitwase and, bitwise or, xor, left shift, right shift.
  • Memory lookup
  • Function calls
  • Sequencing
• What kinds of statements are there? (Alternately, what instructions are there that don't return values.)
  • Storage (in temporaries or memory)
  • Expressions in which the result is discarded
  • Unconditional branches
  • Conditional branches (which also differ from traditional conditional branches in that they specify both a true branch and a false branch)
  • Sequences
  • Labels
• Eventually, the sequencing operations will go away (or at least be made implicit). For now, we keep them to simplify translation from the core language.

Translating variables

• Recall that there are three ways that we can store variables:
  • In temporaries (registers)
  • In the current stack frame
  • In the stack frame of an ancestor
• How do we represent each of these as an expression tree?
• Temporaries simply use the TEMP ``instruction''.
• If variable v is at offset w in the current stack frame, we use

  MEM(BINOP(PLUS,TEMP(FP),CONST(w))
  

  . That is, we add the constant value w to the frame pointer and then look that up in memory.
• If variable v is at offset w in the parent's stack frame, and the static link is at offset s, we use

  MEM(BINOP(PLUS, MEM(BINOP(PLUS, TEMP(FP), CONST(s))), CONST(w))) 
  

  That is, we look up the location of the parent's frame and then offset by w in that frame.
• Note that Appel writes this with the constants first, as in

  MEM(BINOP(PLUS, CONST(w), MEM(BINOP(PLUS, CONST(s), TEMP(FP))))
  

• If variable v is at offset w in the grandparent's stack frame, the static link in the parent's frame is at offset p, and the static link to the parent's frame is at offset s, then we access v with

  MEM(BINOP(PLUS,
            MEM(BINOP(PLUS,
                      MEM(BINOP(PLUS, TEMP(FP), CONST(s))) // Parent's frame
                      CONST(p))) // Grandparent's frame
            CONST(w))) // Offset of v in grandparent's frame
  

• You can generalize appropriately.

History

• Created Monday, November 2, 1998.
• On Wednesday, November 4, 1998, moved a significant amount to the subsequent outline.