Assignment 1: One-Level Cache Simulator Due: Wednesday 04/04/12 (before class)

Transcription

1 Assignment 1: One-Level Cache Simulator Due: Wednesday 04/04/12 (before class) In this assignment, you will write a one-level cache simulator. You will take in the blocksize (in bytes), the total cache size (in bytes or kilobytes), the associativity, and write policy, using the following flags: -b <blksz> -B <cachesz> -K <cacheszkb> -W <t/b> -a <assoc> Assume that kilobytes prefixes refer to 1024 (not 1000). The W flag indicates the write policy, with t indicating write-through and no write-allocate, while b indicates write-back and write-allocate behavior. Setting <assoc> to 0 indicates fully-associative. Your GetFlags routine should ensure that the block size is a power of two (why must this be true?). Default behavior should be the equivalent of: -b 32 -K 16 -W t -a 1 For those of you who are unfamiliar with getting command-line arguments in C, here is a code fragment that would do so if our only flag was b: int main(int nargs, char **args)... for (i=1; i < nargs; i++) { if (args[i][0]!= - ) PrintUsage(args[0], i); switch(args[i][1]) { case b : if (++i == nargs) PrintUsage(args[0], i); *blksz = atoi(args[i]); break; default: PrintUsage(args[0], i); In your header, you will print this given information, plus the number of sets in the cache (conceptually, the number of rows), the number of total blocks the cache holds, the total size of the cache exluding tag storage (either in kilobytes if a multiple of 1024, else in bytes), the amount of extra storage (in bytes; rounded down if necessary) required to store the tags, the number of bits taken up by the block offset, the number of bits in the index, and the number of bits in the tag, with some other statistics (as shown in the example). You should assume a machine with a 24-bit address space. The simulator will read in a memory trace, which has the following form: <R/W>:<address> Where R indicates a read access, and W indicates a write, and <address> indicates the memory address being referenced expressed as a hex number. For each access, you will print the address (in hex), and access type, the address as a binary number (see below for help) the tag, the set number, the block offset, the way of the associativity that it was found in (Way), and the way that was updated (UWay), and the number of main memory reads and writes caused by this access. If the 1

2 block was not found in the cache, then Way will be -1, while UWay will indicate what way the memory location was stored in. If the block is found in the cache, then Way indicates what way it was found in, and a UWay of -1 indicates that we did not update the cache at all, a UWay of of -2 indicates that we only updated our LRU bits for this access, and any positive UWay indicates we actually had to store a value to that way location. You can format your output lines as: "%6x%c %26s %8d %5d %3d %4d %4d %4d %4d\n" Notice that there are 26 bits of space for for the binary address: this is because you need to insert spaces between the block offset and index bits (see printouts later for details). You will implement LRU replacement policy. The summary statistics are printed after the entire trace has been processed. They will indicate the number of hits and misses in the cache, the hit and miss rate, the number of main memory reads, and the number of main memory writes (including dirty bit evictions). In this assignment you must use and store the tag, not the full address in order to determine if an address is in the cache. Further, you are allowed to use only integer bit-level operations to compute the tag, set number, and block offset (i.e. no division, modulo or scanning the output of a string function such as Int2Bits). The TA will examine the code, and if these restrictions are not adhered to, your final grade will be 75% of your achieved score. In this assignment, you will need to implement all the functions yourself. I have provided you with a Makefile and example trace file at: ~whaley/classes/spring12/cs3853/cachesim/makefile ~whaley/classes/spring12/cs3853/cachesim/trace.in Students who are unfamiliar with bit-level operations will need to work on them. Here are two useful routines to get you started: unsigned int GetMask(int nset) /* * RETURNS: int with nset least significant bits set to 1, others to 0 */ { unsigned int mask, i; assert(nset <= 32); /* otherwise default int won t work */ /* * Following two implementations are equivalent, but loop-based one may * be easier to understand at first */ #ifdef FAST mask = (((long long)1))<<nset) - 1; #else for (mask=i=0; i < nset; i++) mask = (1<<i); #endif return(mask); char *Int2Bits(unsigned int bits) /* * RETURNS: string indicating binary bit pattern in integer bits */ 2

3 { static char cbits[nbits+1]; /* NBITS macro defined elsewhere */ int i; cbits[nbits] = \0 ; for (i=0; i < NBITS; i++) cbits[nbits-1-i] = (bits == ((1<<i) bits))? 1 : 0 ; return(cbits); This whole assignment should be written in a single file, called cachesim.c, which will be compiled using the provided Makefile on a UTSA Linux machine (eg. elk01). At the top of the program, put a comment that includes your name and the assignment number. You should the source code for cachesim.c to lul@cs.utsa.edu before class on the due date. In order to aid in debugging, and to enable you to match my output exactly, you can run my executable from any UTSA Linux machine: ~whaley/classes/spring12/cs3853/cachesim/xcachesim Your output should match mine exactly. For debugging, you have the examples worked in class, as well as the cases given here, but you should also make your own input files, and run tests with varying inputs. To help you with generating input files, I have provided a program that simulates addresses like they would come from array accesses in a loop. For flags, it takes the number of iteration of the loop (-N), the bytesize of the elements of the array (-S), and the number of arrays to simulate (-n). Addresses and accesses are then randomly generated, so if you want different results, you should vary the seed using the -s flag. You can also use the simulator to generate particular access starting at given addresses using the -a flag, instead of using the random model. The -a expects an argument saying how many arrays to simulate, and then for each array it takes an argument whether the array is read or write, and what address it should start at. Therefore -a 2 R0ac WF8 -S 1 simulates two character arrays in a loop, where the array beginning at 0xac is read, and the array beginning at 0xF8 is written. Note that beginning addresses will be aligned to the element size. If you want to test particular attributes (write-back eviction, etc), you usually need to plan the file, but for large testing, generating a bunch of lines is handy. You can also mix generated traces with hand-tuned ones, for targeted and widespread tests. This program is available ~whaley/classes/spring12/cs3853/cachesim/xarraygen The provided Makefile also has a target set up to allow you to automatically compare your output to mine using the unix tool diff. Assuming your memory trace is stored in the file mytrace.in, and that you want to simulate a direct-mapped cache with a cache line size of 8 bytes and and a total size of 4 kilobytes you would get the following: elk01>make diff trace=mytrace.in conf="-k 4 -a 1 -b 8" rm -f stud.out prof.out./xcachesim -K 4 -a 1 -b 8 < mytrace.in > stud.out /home/whaley/classes/spring12/cs3853/cachesim/xcachesim -K 4 -a 1 -b 8 < mytrace.in > prof.out diff stud.out prof.out What we would hope to see is that the diff command shows no output at all, which means that your simulator produces the same answer as mine. If the above invocation shows difference (even if merely in spacing), then you need to debug until you find the problem (note that after each diff invocation, the file stud.out will contain the complete output from your simulator, and prof.out will contain the complete output from my simulator). Usually, the problem will be in your code, 3

4 but the first student to discover a particular error in my simulator output will receive extra credit on the assignment. Using this framework, you can build a variety of test tracefiles, and whenever you make a change, quickly retest all the inputs. The tracefile generator can be used for some heavy automated testing, but you should also construct cases that will do particular things (eg., force an eviction, or use all ways in a set, or provide certain access based on LRU, etc). Remember that you need to test with varying arguments using the conf macro as well. I recommend you tackle this problem in the following way, testing at each step against the provided executable using the appropriate input: 1. Compute and print header info, and make it match mine exactly. 2. Get your routine to correctly compute tag, set, and block offset. 3. Add 1-way associative simulator. Treat all accesses as reads. As long as you create read-only tracefiles, you can get your output to exactly match mine. 4. Add support for write-through and write back handling of writes. 5. Add counters to allow for summary info, and make sure it matches mine exactly. 6. Add support for N 1 associativity, including LRU replacement and the fact that N = 0 really means fully associative. Collaboration: As I have given you access to my executable for testing, and have discussed the general implementation strategy, students should not collaborate in any way on this assignment. If you need debugging help, ask the TA during the recitation (preferred), or a fellow student not enrolled in this class. Do not consult with anyone on detailed implementation issues. 4

5 Example runs: >cat trace.in R:c0e7 W:376 R:c0ef W:37e R:c0f7 W:386 R:c0ff W:38e R:c107 W:396 R:c10f W:39e R:c117 W:3a6 R:c11f W:3ae >./xcachesim < trace.in 16KB 1-way associative cache: Block size = 32 bytes Number of [sets,blocks] = [512,512] Extra space for tag storage = 640 bytes ( 3.91%) Bits for [tag,index,offset] = [10, 9, 5] = 24 Write policy = Write-through Hex Binary Address Set Blk Memory Address (tag/index/offset) Tag Index off Way UWay Read Writ ======= ========================== ======== ===== === ==== ==== ==== ==== c0e7r W c0efr eW c0f7r W c0ffr eW c107r W c10fr eW c117r a6W c11fr aeW nref=16, nread=8, nwrite=8 hits = 6, hit rate = 0.38 misses = 10, miss rate = 0.62 main memory reads=2, main memory writes=8 5

6 >./xcachesim -W b < trace.in 16KB 1-way associative cache: Block size = 32 bytes Number of [sets,blocks] = [512,512] Extra space for tag storage = 640 bytes ( 3.91%) Bits for [tag,index,offset] = [10, 9, 5] = 24 Write policy = Write-back Hex Binary Address Set Blk Memory Address (tag/index/offset) Tag Index off Way UWay Read Writ ======= ========================== ======== ===== === ==== ==== ==== ==== c0e7r W c0efr eW c0f7r W c0ffr eW c107r W c10fr eW c117r a6W c11fr aeW nref=16, nread=8, nwrite=8 hits = 11, hit rate = 0.69 misses = 5, miss rate = 0.31 main memory reads=5, main memory writes=0 6

7 >cat traceevict.in W:10 W:810 W:1800 R:14 W:2000 W:2800 W:3000 >./xcachesim -W b -a 4 -b 32 -B 2048 < traceevict.in 2KB 4-way associative cache: Block size = 32 bytes Number of [sets,blocks] = [16,64] Extra space for tag storage = 120 bytes ( 5.86%) Bits for [tag,index,offset] = [15, 4, 5] = 24 Write policy = Write-back Hex Binary Address Set Blk Memory Address (tag/index/offset) Tag Index off Way UWay Read Writ ======= ========================== ======== ===== === ==== ==== ==== ==== 10W W W R W W W nref=7, nread=1, nwrite=6 hits = 1, hit rate = 0.14 misses = 6, miss rate = 0.86 main memory reads=6, main memory writes=2 7