I'll look at project 9.

Why is there a Tree.Print in chap9?

The two differences from what was in chap7x are:

prExp(MEM) Adds the type binding to a MEM printout
prExp(TEMP) Adds the type binding to a TEMP printout

I might want to suggest that the students make these changes at chapter 7,
since I think that I added the type binding them.

I started an analysis of the code generator here. As of 10/15/2005, I moved
it to a file codegen.txt.

set SOURCEDIR=D:\uofm\c4041s2005\src\chap9

If I redo this for another type of machine, what parts will I have to redo?
I think that everything up through chapter 5 is OK, since that is front end
and about MiniJava. I'll have to come up with a new kind of frame for chapter
6. Chapter 7 should be the same, except that I don't need the changes for the
JVM any more. It should not hurt to leave them in. The chapter 8 should be
OK, since it is machine independent. I'll have to totally redo chapter 9 in
the context of the new machine, then add chapters 10 and 11. I suspect I'll
need to redo chapter 12 as well.

So I'll need to redo chapters 6 and 9, in addition to 10 and 11 and probably a
change in 12.

So I need to carefully review chapter 9 to start with and learn the
instructions of the new machine.

I'll start by reviewing and javadocing my chapter 9 code. I'll let chapter 8
go for now and come back to it later.

I need to get rid of the zip file of changes before I look for changed files.
Apparently, it is showing the files inside the zip file as changed as well.

We should write the code to be as general as possible, whenever it is
reasonable, and not cut corners. Later phases can ignore or simplify parts
that we don't need.

I wonder if there is any way that I could generalize the code generator that I
wrote for chapter 9 to take different mnemonics and generate code for
different machines. Probably not, since the tiles are dependent on the JVM.
But it might be worth keeping in mind.

In the intermediate code trees, nodes represent either memory locations or
register names. Register allocation can be thought of as decorating each
intermediate code tree node with the name of the register that is to hold the
result of the computation represented by that node.

Look at replacing as many uses as possible of string + with concat for
efficiency.

Am I looking up the methodBinding too early when generating code for a
function call?

 Create your own free wiki!HelpPublic, not yet premium Privacy Policy RSS