Administrative details

Submit your solution online by 2:45pm on Wednesday, December 5. Do this by creating a directory named proj5 that contains a file named proj5.c. From within that directory, type "submit proj5".

Problem

The files are provided in the directory ~cs61c/files/proj/5 augment a solution to proj3 to add a simulation of the cache. Complete the program by filling in appropriate procedures in proj5.c.

Simulator usage

The code in sim.c is similar to its proj3 counterpart. It is used as follows:

Simulator Files

The following is a list of the framework files and their purposes. Download, or copy them from ~cs61c/files/proj/5/.

• proj5.c contains the empty functions that you must implement, and proj5.h contains their declarations.
• sim.c is the top-level file where the main routine of the simulator is defined. It parses the command-line arguments, opens the file with the program to be simulated, creates a new computer structure, and simulates the input program.
• proj3.o is a working version of your proj3 code, which has been modified to use the cache functions as described below.  Alternatively you may wish to modify and use your proj3.c solution.
• proj3.h is a modified version of the proj3 header, that you can use with your proj3 solution if you'd prefer to use yours to our proj3.o.
• memory.h contains data types and function prototypes used by memory.c and proj5.c.
• memory.c contains stubs for all of the functions to emulate the memory system, including the cache.
• bool.h defines boolean types.
• makefile is a script that builds an executable from a bunch of source and object files. This makefile is provided for your convenience. You do not need to modify it. Simply type "gmake" at the shell prompt to build your simulator.

You are to complete the simulator by writing the unfinished code in the file proj5.c. Do not change the framework code or add any more source files; just fill in the frameworks where indicated. You may provide additional helper functions. The procedures that you must complete in proj5.c are:

• newCache()
• cacheContains()
• cacheContents()
• updateCacheContents()
• addCacheEntry()
• Cache entries should be initialized to "invalid" at the start of the simulation.

AutoGrading Corner Cases

While these may seem like trivial corner cases, to some extent these details do reflect the real operation of a cache.  Of course, some of this is merely an outgrowth of our need to rely on the autograder, for which we really do apologize.

• All four of the main cache access functions (cacheContains(), cacheContents(), updateCacheContents() and addCacheEntry()) should increment accessCount exactly once.
• cacheContains() should not increment the access count on a cache miss.
• The lastUsedTime of a cache block should be set to the accessCount after it has be incremented.
• You must initialzie all of your cache words to 0 in newCache.
• You should not change the contents of a cache block when it is marked invalid (i.e. only the valid bit should change, not the data).
• If there are multiple invalid blocks from which addEntry() must select one to replace with a valid entry, it should always select the first one (lowest index within the set).

Testing

You should have more than enough code to test a processor at this point, given proj3 and proj4. However, you will need to be sure to exercise your cache thoroughly. A test program such as cache.s from lab12 is a decent start, though it certainly isn't the whole story.

Errors

There are two possible errors which can arise in the code you need to write. These are both documented in the comments for the relevant code.