There is a generator available: generate.pl. This is a perl program that generates input that can be used to test your simulator. The program includes many parameters (all variables set at the top of the program), so you can modify how it works. To run the program, save it as "generator.pl" and run "perl generator.pl" from the Unix command line.

The generator uses random numbers based on gaussian probability distribution (a bell curve) so that it generates addresses that are near each other. The program allows you to set the maximum number of concurrent simulated processes, total number of memory accesses, the size of virtual memory, number of accesses per quantum (as an average and standard deviation), etc.

This code is available for your use, but no claims are made about whether it is the best (or even a particularly good) representation of the memory access patterns of real processes. The generator is a minimal improvement over one based on generating addresses according to a uniform distribution (which is certainly not representative of what is observed in real programs).

There are a number of samples available here. The README files contain a description of the input files and the output produced by Dave's simulator.

NFU - which is an LRU approxiation.

Your NFU algorithm should keep a counter for each page frame, indicating how many times the page has been reference (actually the counter is the number of time intervals in which the page was accessed.). The algorithm requires the time interval parameter - every interval memory accesses you should read the R bits (and add to the counters), and clear all the R bits. See the book for a more complete description.

Use either, just tell use what you are using. It makes more sense to use read/write operations, but either is fine...

Yes. This is described on Page 218 (in the description of second chance). "What second chance is doing is looking for an old page that has not been referenced in the previous clock interval".

The assignment says you can assume the number of pages will be a power of two (so if you rely on this you may not be able to run the FIFO test code made available).

However, there is no reason that the number of pages of physical memory must be a power of 2. In reality it would be difficult to purchase memory so that you didn't have a power of 2 (assuming the page size is also a power of 2), but keep in mind that it is feasible that the OS reserves some pages for itself (so the pages left for the virtual memory software to use could easily be something other than a power of 2). At a minimum, the OS must make sure that the pages that hold the page fault handling software must be kept in memory!

We won't test your code with anything other than a power of 2.

You can assume we won't reference any virtual page greater than 100 (128 is fine) when testing. Depending on how you implement the page tables, it shouldn't really make any difference (unless you implement page tables as fixed size arrays).