Class 34: Generating assembly code
Held Monday, November 30, 1998
- 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.
- 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
- 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
- The pattern for "load" might be
- 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
- 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
- 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)).
- 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
- 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.)
- 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
- You should know what dynamic programming is from CSC152.
- There are times that the algorithms (particularly maximal munch)
- 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
- Some operations can't be described as a simple tree pattern (e.g.,
operators with side effects). Appel suggests we ignore them.
- 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''
- 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
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.
- Created Wednesday, November 25, 1998, as a blank outline.
- On Monday, November 30, 1998, filled in the details (some taken
from outline 32).
Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.
Source text last modified Wed Dec 2 10:32:24 1998.
This page generated on Wed Dec 2 11:45:12 1998 by SiteWeaver.
Contact our webmaster at firstname.lastname@example.org