Assignment 7, due Mar. 9

On all assignments, your name must be legible as it appears on your University ID card! Assignments are due at the start of class on the day indicated (usually Friday). Exceptions will be by advance arrangement unless there is what lawyers call "an act of God" (something outside your control). Homework must be turned in on paper, either in class or in the teaching assistant's mailbox. Never push late work under someone's door!

1. Background: Look at the code for mush distributed on Mar. 2 as part of the assignment for MP4. Some change were made. This question asks you to describe these changes from the perspective of a user with no access to the source code. You have access to the code, and you can use this to find the changes, and you can experiment with running mush to verify the impact of the changes, but your answer must not refer to the code, only to how the program works from a user perspective.

   a) The behavior of getcommand() has changed. There is one change that a user can observe. (0.4 points)

   If you run interactively or redirect a file into mush, it will prompt for each line. If, somehow, the program were to read from some other file, it would not prompt. Note, however, that this cannot be tested with the code that was distributed, so this could be considered an ill-formed question. Technically, this is a latent feature that can only be observed if changes are made elsewhere in the program, outside of getcommand().

   b) The behavior of launch() has changed. There are two changes that a user can observe. (0.6 points)

   First, the behavior of environment variable substitution was changed. In the previous code, undefined variable references such as $GRIBBLE were left unchanged. In the new code, they are replaced with the empty string. Here is a demonstration of the old behavior:

   [dwjones@fastx07 ~/mush]$ mush
   >echo a $gribble b
   a $gribble b
   

   Here is a demonstration of the new behavior; the double blank between the a and b outputs is evidence of a null argument between them:

   [dwjones@fastx07 ~/mush]$ mush
   >echo a $gribble b
   a  b
   

   The second observable change is that the new version of mush supports shell comments starting with a # as the first nonblank on a line. Here is a demonstration:

   [dwjones@fastx07 ~/mush]$ mush
   ># this is a comment
   >     # so is this
   >echo this #is not a comment
   this #is not a comment
   

2. Background: Consider a bizarrely small machine with the following address formats:

          _ _ _ _ _ _ _ _ _
         |_|_|_|_|_|_|_|_|_|  Virtual address
         |page |   word    |
      _ _ _ _ _ _ _ _ _ _ _
     |_|_|_|_|_|_|_|_|_|_|_|  Physical address
     |  frame  |   word    |
   

   At one instant in time, the page table in the memory management unit contains the following (all information is shown in binary):

   0 0 0: 1 0 1 0 0 0 0 0 1
   0 0 1: 1 0 0 0 0 0 0 1 0
   0 1 0: 1 1 0 0 0 1 0 0 1
   0 1 1: 0 0 0 0 0 0 1 0 1
   1 0 0: 0 0 0 0 1 1 0 0 0
   1 0 1: 0 0 0 0 0 0 1 0 1
   1 1 0: 0 0 0 0 0 1 0 0 1
   1 1 1: 0 0 0 0 1 0 0 0 0
          _ _ _ _ _ _ _ _ _
   index:|_|_|_|_|_|_|_|_|_|  Virtual address
         |r w x| |  frame  |
         rights
   

   For each of the following virtual addresses, give the corresponding physical address, and state whether it is a legal memory address, and if legal, what access is permitted. (Illegal addresses permit no access.)

   a)   0 1 0 1 0 1 0 1 0
   

   That is, page = 0 1 0 and word = 1 0 1 0 1 0
   So, use page table entry 0 1 0: 1 1 0 0 0 1 0 0 1
   This has rights = 1 1 0 and frame = 0 1 0 0 1
   That is, the physical address is 0 1 0 0 1 1 0 1 0 1 0 and this is legal, readable and writable.
   

   b)   1 0 1 0 1 0 1 0 1
   

   Physical address 0 0 1 0 1 0 1 0 1 0 1 and this is illegal, no access allowed.

   c)   0 0 1 1 0 0 1 1 0
   

   Physical address 0 0 0 1 0 1 0 0 1 1 0 and this is legal, read only.

   d)   1 1 0 0 1 1 0 0 1
   

   Physical address 0 1 0 0 1 0 1 1 0 0 1 and this is illegal, no access allowed.

   e)   0 0 0 1 1 1 0 0 0

   Physical address 0 0 0 0 1 1 1 1 0 0 0 and this is legal, readable and executable.

3. Background: Read the man page for the mmap() kernel call in Linux. Consider the following code:

   char * f = mmap(
           NULL,
   	sysconf( _SC_PAGESIZE )*16,
   	PROT_READ, MAP_SHARED,
           open( "~/myfile", O_RDONLY ),
   	0
   );
   

   a) Write a for loop that prints the entire contents of ~/myfile assuming that it has been opened using the above code. (0.6 points)

   int i;
   int size = sysconf( _SC_PAGESIZE )*16;
   for (i = 0; i < size; i++) putchar( f[i] );
   

   b) How many page faults occur, at minimum, during the execution of the code you wrote for part a? (0.2 points)

   In the best case, all pages holding code are already in RAM. When you finish the mmap() call, the pages of the file are still on disk but mapped into the virtual address space, so the only page faults will be one fault each for the pages of the file. The file size is 16 pages according to the second parameter to mmap(), so the answer is:

   16 page faults.

   c) Under what circumstances would more page faults occur than you suggested in part b. (0.2 points)

   First, the code of the for loop might not be in RAM at the time it begins. That would add perhaps one page fault. Second, the page replacement policy was not specified. A bad page replacement policy could evict pages from RAM prematurely, forcing additional page faults. For example, if each page fault bringing a page of the file into RAM also pushed the code of the for loop out, the number of page faults would double.