CS322 Winter’09: Languages and Compiler Design II - Project #5: SPARC Assembly - Prof. Jin, Study Guides, Projects, Research of Computer Science

Project #5 for cs322 winter’09: languages and compiler design ii, where students are required to implement a sparc assembly code generator for the ir tree language. The operand representation, register management, and implementation hints for various instructions. Students are expected to write a java class, codegen, with the given interface and methods.

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/19/2009

koofers-user-yj6-1
koofers-user-yj6-1 🇺🇸

10 documents

1 / 2

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS322 Winter’09: Languages and Compiler Design I I 2/24/09
Prof. Jingke Li (FAB 120-06, [email protected]), Classes: TTh 2-3:50pm, URBAN 304, Office Hours: TTh 10-11am.
Project #5: SPARC Assembly Code Generation
(Due Tuesday 3/10/09 @ 5pm)
This (last) project is to implement the final component of the MINI compiler, a SPARC assembly code
generator for the IR Tree language. This codegen module should be implemented as a self-contained Java
class (like the interpreter in Project 4), Codegen, with the following interface:
public Codegen(PROG p) {...} --- the constructor takes an IR program as input
public void go() {...} --- the main trigger for the codegen module
Operand Representation
In the codegen, all operands, including constants, addresses, and intermediate results, are stored in ob jects
of the class Operand. For each kind of operands, there is a subclass for representing it:
abstract class Operand {}
public class Reg extends Operand // register
{ static final int RESERVED=-1, FREE=0, USE=1, TEMP=2;
String name; int status; }
public class RegOffset extends Operand { Reg r; int o; } // Stack location
public class Imm13 extends Operand { int i; } // 13-bit immed value
public class Imm32 extends Operand { int i; } // 32-bit immed value
public class AddrName extends Operand { String s; } // global address name
Register Management
The codegen uses a simple register allocation scheme. The register allo cator keeps track of each register’s
status: reserved,free,used, or temp. Upon an allocation request, the allocator simply allocates the next
available register. If there is no more registers available, it just throws an exception. When a temp is assigned
to a register, it will stay there until the end of the program. A special status, temp, is used to prevent the
register from being freed. The register allocator routines are:
// requesting an arbitrary free register;
// throws an exception if none is free
// (Note that the status of the reg will be set to ’use’;
// if it is to be used for a temp, the status needs to be
// changed to ’temp’ after the call is returned.)
private Reg getReg() throws CodegenException { ... }
// requesting a specific register r;
// throws an exception if r is not free
private void getReg(Reg r) throws CodegenException { ... }
// freeing a register, skipping if it holds a temp
void freeReg(Reg r) { ... }
// freeing all used registers, including those holding temps
void freeAllRegs() { ... }
1
pf2

Partial preview of the text

Download CS322 Winter’09: Languages and Compiler Design II - Project #5: SPARC Assembly - Prof. Jin and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!

CS322 Winter’09: Languages and Compiler Design II 2/24/ Prof. Jingke Li (FAB 120-06, [email protected]), Classes: TTh 2-3:50pm, URBAN 304, Office Hours: TTh 10-11am.

Project #5: SPARC Assembly Code Generation

(Due Tuesday 3/10/09 @ 5pm)

This (last) project is to implement the final component of the MINI compiler, a SPARC assembly code generator for the IR Tree language. This codegen module should be implemented as a self-contained Java class (like the interpreter in Project 4), Codegen, with the following interface:

public Codegen(PROG p) {...} --- the constructor takes an IR program as input public void go() {...} --- the main trigger for the codegen module

Operand Representation

In the codegen, all operands, including constants, addresses, and intermediate results, are stored in objects of the class Operand. For each kind of operands, there is a subclass for representing it:

abstract class Operand {}

public class Reg extends Operand // register { static final int RESERVED=-1, FREE=0, USE=1, TEMP=2; String name; int status; } public class RegOffset extends Operand { Reg r; int o; } // Stack location public class Imm13 extends Operand { int i; } // 13-bit immed value public class Imm32 extends Operand { int i; } // 32-bit immed value public class AddrName extends Operand { String s; } // global address name

Register Management

The codegen uses a simple register allocation scheme. The register allocator keeps track of each register’s status: reserved, free, used, or temp. Upon an allocation request, the allocator simply allocates the next available register. If there is no more registers available, it just throws an exception. When a temp is assigned to a register, it will stay there until the end of the program. A special status, temp, is used to prevent the register from being freed. The register allocator routines are:

// requesting an arbitrary free register; // throws an exception if none is free // (Note that the status of the reg will be set to ’use’; // if it is to be used for a temp, the status needs to be // changed to ’temp’ after the call is returned.) private Reg getReg() throws CodegenException { ... }

// requesting a specific register r; // throws an exception if r is not free private void getReg(Reg r) throws CodegenException { ... }

// freeing a register, skipping if it holds a temp void freeReg(Reg r) { ... }

// freeing all used registers, including those holding temps void freeAllRegs() { ... }

Implementation Hints

  • MOVE — Generate code for src and bring result to a reg; if dst is a temp, then generate a mov instruction, else generate an address based on dst and then generate a store instruction.
  • JUMP — Generate a ba instruction followed by a nop.
  • CJUMP — First generate a cmp instruction; then generate a conditional branch instruction.
  • CALLST/CALL — For system routines (i.e. prInt, prString, error, and malloc) , pass parameters through the registers %o0 and %o1. For user-defined routines, pass parameters through the stack.
  • LABEL — Straightforward.
  • RETURN — if there is an expression, generate code for it and bring its to register RegRV. Then emit "ret" and "restore".
  • BINOP — Generate a corresponding binop instruction. Note that Sparc’s operands are quite restrictive: only the second operand of a three-operand instruction may be an (13-bit) immediate value; the first must be a register. It is probably easiest just to bring all values into registers uniformly, at least to start with. The integer division instruction sdiv requires the use of a special register %y. The content of %y needs to be cleared before the execution of sdiv.
  • MEM — The exp component is translated into an Operand node, which should represent an address. If the MEM appears on the left-hand-side of a MOVE statement, it should be translated into a store instruction; otherwise it should be translated into a load instruction. We can default the genMem routine to translate a MEM into a load, and have the genMove routine handle the store case directly.
  • TEMP --- Check the tempTable to see if the temp has been assigned a register already; if so, return that register; otherwise, get a new register and save the info in the table.
  • MEMBER --- Bring the base address (i.e. the obj component) into a register and then generate a RegOffset operand. The first member should have an offset of 0.
  • VAR --- Note that the SPARC supports register+offset addresses in ld and st instructions. So for a VAR node, the codegen should generate a RegOffset operand; using %fp as the base register. The first var should have an offset of -4.
  • PARAM --- Similar to the VAR case; but the offset value needs to be adjusted by the reserved space (i.e. 68 bytes).
  • (NAME wSZ) --- Translate to constant 4.
  • CONST --- Generate either a 13-bit or 32-bit constant value.

Code Organization

The codegen program should be called Codegen.java and placed in a subdirectory codegen. As usual, a tar file is provided to you, which contains the following:

  • ir/ — the IR tree node definitions
  • irpsr/ — an IR tree parser program
  • codegen/ — a starting version of the codegen Codegen0.java and a driver TestCodegen.java
  • tst/ — a set of test programs
  • runc, runa — scripts for running the codegen and assembly programs, respectively.

The quality of the assembly code is measured by two counts: number of instructions and number of registers; both are automatically reported at the end of the assembly code. After making your codegen work correctly, you should try to improve the quality of its output, using the provided .s files as a reference.

Submit your program Codegen.java to [email protected]. Please keep a copy of your submitted files aside, in case there is a need for re-submission.