CSCI 310 Project 6
The last task of the semester is to generate IRTs from your code.
The process goes in two phases. The first establishes frame information, the second builds statement trees for each method in the code.
Building frame info
Cass Decls
The visitor
- calculates base offset, greater than 0 if this is an extended class
- sets offset for each variable
- allocates/generates an IRT describing the memory access of the class variable
--> depends on the this variable, which is stored in
Mips.MipsFrame.SL (a register just for the static link /
this variable).
- allocates/generates an IRT describing the allocation of
memory for this object and initialization of the variables.
If this is an extended class it means you need to be able to
get access to the initialization tree of the
parent. (i.e. should generate an "allocate memory" subtree
and a initialize memory subtree so the initialize subtree can
be handed out to classes extending you).
Method Decls
The visitor
- allocates a frame with a label describing this method,
usually something like class$methodname. If you want to
overload parameters, you'll need a more complicated name.
- uses the frame to store the offset needed for parameters,
local variables, etc. (Does this by incrementing as
necessary while visiting.) Remember the stack grows down so
this offset is a negative value.
- generates temps to represent local variables, parameters
[you may assume few enough parameters to keep in registers].
(Remember to update the offset in case you need to dump the
registers, however.)
- generate an IRT for each local variable/parameter,
describing the memory access for it.
Note 1: One way to approach this is to start with the symbol table and
replace/update the entries for classes, methods, variables with the
information you are gathering here -- since your symbol table lookup
will find the correct binding for each identifier, this guarantees
your IRT generation will then find the correct pieces.
Note 2: Mips/MipsFrame.java is supplied (has permanent registers
allocated, as are the Temp and Label generators.
Generating the IRTs for each method
In the Second pass (another visitor):
Each expression causes an IRT to be generated. Identifiers will have
had IRTs desribing their use/access generated in the first pass, so
this is really just a matter of gluing that tree into the tree you
create for the expression.
Statements similarly build IRTs.
Method bodies can be treated as statements. Build the tree describing
the statements, then add a statement moving the return value into the
RV register. (Don't forget to start the whole thing with the
appropriate label generated during the first pass.) A pair consisting
of the method's frame and this statement tree is then added to a
global ProcedureFragment list (an arraylist). This list is the
ultimate product of the IRT process.
(Recall that we discussed all the statements and what their IRTs look
like, so this part is a matter of using the Tree creatures
appropriately.
What's Given
p6.tar contains
- Frame/* -- base classes for Frame-related stuff.
- Mips/MipsFrame.java -- Mips frame stuff including the initial
generator of a frame. You'll create objects of this type for your frames.
- Mips/InReg.java -- generates register temps
- Mips/InFrame.java -- generates memory-based accesses (useful for objects)
- Temp/Temp.java -- for Temps
- Temp/Label.java
- Temp/LabelList.java
- Util/BoolList.java -- list of booleans (from text, used in frame; you
can modify to not use this if you like).
- Tree/* all the IRT statement and expression files.