In this project you will add TBL support and lazily-constructed multi-level page tables to project3.
Your job is to modify your Project3 solution to support in two phases:
- Lazily Constructed Multi-Level Page Tables (Phase I)
- Translation Look-aside Buffer (Phase II)
You are provided with: project4_cs439.zip
wget http://cs.utexas.edu/~rockhold/CS439/project4/project4_cs439.zip
This is in Eclipse-importable format.
config_?_v.txt that your output must match (requires you to implement lazy allocation of you multi-level Page Table structures.)config_?_vv.txt that contain the references solution's output when run with the -vv flag.config_?_v.txt that your output must match (requires you to implement TLB, also using your implementation of lazy allocation of you multi-level Page Table structures.)config_?_vv.txt that contain the references solution's output when run with the -vv flag.Makefile for building, testing, and turning in your project.README file you need to complete prior to turnin.This project is designed to be completed in two phases. Finish phase I before starting on phase II.
In phase I, the simulator uses only PTEs (just like project3), but this time your PTEs must be lazily allocated.
Phase II runs the simulator using TLBs (and still PTEs, of course). As in phase I, your PTEs must be lazily allocated.
This project uses the same simulator package from project 3.
So, setting up Eclipse Run/Debug Configurations are the same as project 3.
Likewise, the provided Makefile has the same targets as before, e.g. classes, clean, along with targets to run and diff tests for both phases.
The same -v and -vv flags are used by the simulator to control the level of verbosity.
As in project 3, there are 6 different configuration files named config_N, where N is (1,2,3,4,5, or 6). These are common to each phase.
The same configuration values that were in project3 are in project4.
In phase I, you will run the simulator in PTE "mode".
This is accomplished by NOT specifying the -t flag. (the "t" in -t stands for TLB).
So, to run config_1 in phase I to generate output to compare against what's expected:
$ make config1_pt
or
$ make classes
$ java -cp bin simulator.Simulator -v config_1
You can use the Makefile to run all the tests for phase I with:
$ make configs_pt
You can set it as a Run or Debug configuration in Eclipse with project:project4_cs439, Main class:simulator.Simulator, Program Arguments: -v config_1
Note that you can produce the "very verbose" output by specifying -vv instead of -v
The very-verbose reference output is located in the outputs_pt directory with file names that include vv.
IOS.setFrameReferencedTime() on PTE "hits" as it does in phase I.) See ICPU.getTLBEntries().SystemInfo.getTLBEntryCount() and is guaranteed to be a power of 2.In phase II, you will run the simulator in TLB "mode".
This is accomplished by specifying the -t flag. (the "t" in -t stands for TLB).
So, to run config_1 to generate output to compare against what's expected:
$ make config1_tlb
or
$ make classes
$ java -cp bin simulator.Simulator -v -t config_1
You can use the Makefile to run all the tests for phase I with:
$ make configs_tlb
You can set it as a Run or Debug configuration in Eclipse with project:project4_cs439, Main class:simulator.Simulator, Program Arguments: -v -t config_1
Note that you can produce the "very verbose" output by specifying -vv instead of -v
The very-verbose reference output is located in the outputs_tlb directory with file names that include vv.
The Simulator supports 3 levels of logging, implemented in the base.Debug class:
Debug.log(String message) will always output the specified message.Debug.info(String message) will produce output if Simulator is run with either the -v flag, or the -vv flag.Debug.user(String message) will produce output only if the Simulator is run with the -vv flag.The reference solution for OS and CPU is sprinkled with a few uses of Debug.user() messages.
For your reference, I've included output files in the outputs_pt directory that were produced running the reference solution with the -vv flag.
These files are named config_?_vv.txt (note the double v's).
So, if you get stuck, you can look these over to get a sense of what the reference solution is doing.
If you want, you can sprinkle your code with calls to Debug.user("...") at what should be the same places where they likely appear in the reference solution.
Likewise, you can sprinkle calls to Debug.user() throughout your code, knowing full well that they won't interfere with getting the correct output when you test you code (we only test your solution with -v, not -vv.)
You need to fill out the README file.
When you're finished with the project, use the make target:
make turnin
which will create a tar.gz file of your work and invoke turnin for you.
If you'd like to create the tar.gz file and look it over, you can create it without doing the turnin using:
make turnin_setup