Class 30: Canonical trees
Held Wednesday, November 18, 1998
- I seem to be missing my Green Tiger book. If I could borrow one for
a few days, I'd appreciate it. Found it!
- 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
- 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.
- We'll begin by defining a particular form of IRTs which Appel calls
- Note that we will be translating general IRTs to a sequence of
- Canonical trees do not contain
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
- So, how do we transform non-canonical trees into sequences of canonical
- We try to propagate the
nodes up in the tree.
- We add some new temporaries to hold the results of
- We'll use a technique known as rewriting to move nodes through
ESEQ(s1, ESEQ(s2, e))
- ``Do s1, then s2, then evaluate e''
- Can be written
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 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
that case, we might write
ESEQ(s, BINOP(op, e1, e2)).
- Created Wednesday, November 18, 1998 (with the full contents).
- On Friday, November 20, 1998, deleted some uncovered material.
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 Fri Nov 20 11:00:22 1998.
This page generated on Fri Nov 20 11:25:03 1998 by SiteWeaver.
Contact our webmaster at email@example.com