Class 34: Generating assembly code

Held Monday, November 30, 1998

Notes

• Today at noon, Tony Stubblebine gave a talk on Perl. I hope some of you were there. Come next Monday at noon to hear more.
• Tomorrow at 4:30, Clif Flynt will be discussing cool applications of Tcl. Clif is a prospective faculty member, and you should go see him. You get one point of extra credit for going and giving me a report. You get free pizza, too.
• Wednesday at 9:00, Clif Flynt will be teaching CS151. Please go, observe, and report. Get another point of extra credit (but no free pizza).
• I'm still working on coding. I hope to have everything ready for Friday, but I'm not sure I"ll make it.
• On Wednesday from 7:30-8:30 and Thursday from 7:00 to 8:00, the department will be hosting a forum on changes to the Mathematics Major and upper level courses. You are welcome to attend. Let me know if you'd like a document summarizing the changes.
• On Thursday at 4:30, Professor James Broffitt, chair of the University of Iowa's Department of Statistics and Actuarial Science on Credibility and Batting Averages, which describes a technique called credibility or shrinkage estimation for combining data from several populations to estimate the mean for the population. The technique has applications in many areas, including actuarial science and baseball.
• Please read chapter 10 for Wednesday and chapter 11 for Friday. You may need to read chapter 12 to finish your project, but we probably won't cover it in class.
• You all seem to know your assigned times and topics, so I won't make the mistake of misstating them again.

Selecting Instructions

• How do we convert the complex canonical trees permitted by IRTs to the simpler assembly language instructions?
• It turns out that it depends on the assembly code we're generating.
  • Some assembly codes include array-like addressing modes, others do not.
  • Some assembly codes require that all addresses be in registers, others do not.
  • Some assembly codes have an ``auto-increment'' flag, others do not.
  • ...
• So, we're now at a point in which we need to consider the actual assembly code we're generating (at least when we write a program).
• We select instructions by generating tree patterns with corresponding assembly-code replacements.
• For example, suppose we have MOVE(MEM(i), MEM(j)) in our tree, but the architecture supports only load, store, and copying between registers.
  • The pattern for "store" might be MOVE(MEM(...), ...).
  • The pattern for "load" might be MEM(...).
  • We can therefore write the tree as

    LOAD R(123) MEM(j)
    STOR MEM(i) R(123)
    

  • This does assume that we've also done something intelligent with i and j.
• Our goal is to tile the tree with patterns, which can then be used to generate code.
• As in the IRTs, we will need to distinguish tiles/instructions that ``return values'' (this time, in registers) and tiles that do not return values.

Tiling the tree with maximal munch

• The simplest technique for tiling the tree is a greedy, top-down algorithm known as maximal munch.
• You tile the root with the biggest tile possible and then recurse on the children.
• This requires that it is possible to tile every type of node (otherwise, some tiles may be illegal).
  • For example, suppose that we can tile OP(MEM(*), MEM(*)), OP(*,*), and MEM(R(*)), but not R(*). (Okay, this is unlikely, but ...).
  • Then we don't want to use the biggest tile for the root of OP(MEM(R(1)),MEM(R(2)).

Optimal and optimum tiling

• There are clearly many tilings possible for a typical IRT. How do we choose the best one?
• We'd like the one of least cost to execute.
  • However, this requires that we understand which instructions will be executed more or fewer times.
  • As a compromise, we measure cost in terms of a simple sum of the costs of the individual instructions.
• An optimum tiling is the tiling with minimum cost when compared to all tilings for the tree.
• An optimal tiling is a kind of local minimum: no two tiles can be combined into a tile of lower cost.
• (Note that we may later attempt to improve the actual instructions generated by this phase of the compiler.)

Optimum tiling

• Can we compute the optimum tiling of a tree? Yes.
• Here's a top-down algorithm:

  for each tile that covers the root
    compute the optimum tiling of each subtree of that tile
    compute the cost using those tilings and the current tile
  pick the minimum of those tiles
  

• Does this algorithm work? Yes. We need to put some tile on the root. This ensures that we put the one that leads to the lowest total cost for the tree.
• Is this algorithm efficient? No. It tends to lead to repeated work, and can be exponential.
• Can we make it more efficient? Yes. We can employ dynamic programming.
  • You should know what dynamic programming is from CSC152.

Problem areas

• There are times that the algorithms (particularly maximal munch) have difficulties.
• We've already seen one: cases in which it is not possible to tile an arbitrary subtree can lead to difficulties.
• As given, we've made some assumptions about legal arguments. In particular, we haven't distinguished types of registers. Some architectures do distinguish types of registers (e.g., address and data registers).
• Some operations can't be described as a simple tree pattern (e.g., operators with side effects). Appel suggests we ignore them.

Issues for your compiler

• Since you won't be generating actual assembly code, you may wish to select a different mechanism for this stage of your compiler (which will, in fact, be the final required stage).
  • As in the case of generating assembly code, you will need to turn trees of instructions into sequences of instructions.
  • However, the ``instructions'' you will be generating will be the same kinds of things as are in your tree. In effect, you will be simplifying the tree.
  • You won't need to keep track of registers (although you may choose to do so).
• What will you need to do?
  • Identify trees that don't meet the criteria for ``straight-line'' IRTs.
  • Correct those trees.
• Most typically, you will find instances in which nodes have arguments that are ``too deep'' and replace them with sequences of more shallow trees. For example MOVE(MEM(BINOP(PLUS,T(10),T(11))), 5) should be replaced by BINOP(PLUS,T(10),T(11)); MOVE(MEM(ACC), 5)
• You may want to use something like Maximal munch to do this, or you may find some more ad-hoc technique appropriate. You may also find that a modified version of the canonicalize function will help.

History

• Created Wednesday, November 25, 1998, as a blank outline.
• On Monday, November 30, 1998, filled in the details (some taken from outline 32).