Download the tarball: ece412-hw2.tar.gz.
Unpack the tarball by running the command:
This will create a source directory named "ece412", and a build directory named "build-ece412" with the precompiled binaries in it.
Set up the build-ece412 directory:
This will create the build directory tree and a set of symlinks so that you can compile the simulator and library.
Make the simulator:
Run make in the build-ece412/build directory:
This builds the runtime library, and installs it in the directory build-ece412/tools-install.
Compile and run a program:
(lzw is a version of the unix compress program. It creates a buffer of random text, then compresses and decompresses the text). While it is running it prints out the random text and then some statistics:
Files both have length 802 Characters match. Number of cycles run: 1695174 Number of instructions: 1220092 CPI: 1.389382
Make changes to the simulator. The simulator code is in the directory ece412/tools/sim. For this assignment you will mainly be modifying the files rename_stage.h, scoreboard.h and reg_file.h. To rebuild the simulator go to the directory build-ece412/tools/sim and type make.
The simulator you are given models a single-issue in-order pipelined processor. We are eventually going to make the processor out-of-order. This assignment asks you to implement register renaming in a way that is compatible with our eventual goal of out-of-order speculative execution.
In addition to improvements to the fetch unit, and the addition of a renaming stage between decode and scoreboard, the scoreboard stage has been modified to work as a FIFO. Instructions are inserted in-order into the tail of the FIFO by the rename stage, and are retired from the head of the FIFO, also in-order. (Thus, the scoreboard stage now has the structure of a register-update-unit).
Currently the renaming stage isn't doing anything useful. (It simply copies the architectural register number to the physical register number). For this assignment you should implement a larger physical register file and a register alias table for the rename stage.
Conceptually, the hardest part of this assignment is probably going to be the bookkeeping that needs to be done to decide which physical registers are free for reallocation. Of all the schemes we discussed for freeing registers to the allocator, the easiest to implement is to have the retiring instruction free up the physical register used by the previous mapping of the architectural register.
That is, suppose we have an instruction that writes to architectural register 6. When it arrives at the RAT it finds a previous mapping from architectural register 6 to physical register 43. It also finds that physical register 39 is available for allocation, and so modifies the RAT to reflect the new mapping 6 -> 39. When our instruction retires from the reorder buffer then physical register 43 can be freed to the register allocator.
You may work alone or in groups of 2, 3 or 4. Each group should turn in a short (2-4 pages) report on what you implemented and what you learned. How many physical registers did you implement? How small can the physical register file be before you start running out of free registers and need to stall fetch? How did changing the FIFO size and the number of physical registers affect performance? When we implement out-of-order issue will these numbers change?