Question 1: 5 points

"Of course it's safe. I thoroughly searched the source code for safety and determined that:
• When you compile to object code, the only file it opens for writing is the object code file.
• When you link to create an executable, the only file it opens for writing is the executable.
• It never opens sockets, pipes, or other non-file objects.
• It never calls gets() or makes any non-safe read() call.
• It never calls fork(), execve(), thread calls, longjmp(), or any other weird control construct.

Therefore, you can be assured of its integrity. I'll be applying for a raise later this afternoon!"

Although Freddy's answer seems reasonable, you think about it a little more, and decide to visit your boss to explain just how unsafe Freddy's software purchase could be. What will you say to your boss?

Question 2: 16 points

int palcount(char *s, int len)
{
  char *e;
  int c;

  e = s+len-1;
  c = 0;
  while (s <= e) {
    if (*e == *s) c++;
    e--;
    s++;
  }
  return c;
}

The following is what happens when palcount is compiled into assembly code. (I'm using the generic jassem assembly code from CS360. If you don't know anything about jassem, just mentally map it to your favorite assmebly code. R0 and r1 are general purpose registers, fp is the frame pointer, g1 is a register whose value is always one, and gm1 is a register whose value is always minus one.

           palcount:        // s will be at fp+12, len will be at fp+16
L01:          push #8       // e will be at fp-4,  c will be at fp

L02:          ld [fp+12] -> %r0     // e = s + len-1
L03:          ld [fp+16] -> %r1
L04:          add %r0,%r1 -> %r0
L05:          add %r0,%gm1 -> %r0
L06:          st %r0 -> [fp-4]

L07:          st %g0 -> [fp]       // c = 0

           l1:
L08:          ld [fp+12] -> %r0   // while (s <= e) 
L09:          ld [fp-4] -> %r1
L10:          cmp %r0, %r1
L11:          bgt l0

L12:          ld [fp+12] -> %r0   // if (*e == *s)
L13:          ld [r0] -> %r0
L14:          ld [fp-4] -> %r1
L15:          ld [r1] -> %r1
L16:          cmp %r0 %r1
L17:          bne l2
          
L18:          ld [fp] -> %r0      // c++
L19:          add %r0, %g1 -> %r0
L20:          st %r0 -> [fp]

           l2:
L21:          ld [fp-4] -> %r0      // e--
L22:          add %r0, %gm1 -> %r0
L23:          st %r0 -> [fp-4]
              
L24:          ld [fp+12] -> %r0     // s++
L25:          add %r0, %g1 -> %r0
L26:          st %r0 -> [fp+12]
          
L27:          b l1

           l0:
L28:          ld [fp] -> %r0     // Return c
L29:          ret

Suppose instructions are 4 bytes long, integers and pointers are 4 bytes long, and pages are 1K bytes. Also suppose there is no cache or TLB to get in the way of our calculations.

• Part 1: Suppose that len = x. What are the maximum and minimum number of pages that may be touched when palcount() is executed?
• Part 2: Define a working set with a window size of delta.
• Part 3: Suppose len is some number greater than 10000. Suppose delta is equal to 21504 (21K). What are the maximum and minimum sizes of the working set for this procedure at iteration 3000 of the loop?
• Part 4: Suppose we execute palcount(0x5000, 0x100025), and when we start running it, fp = 0x7ffffff80, and palcount = 0x400. Moreover, the pages containing fp and palcount are already loaded into memory, but all of the other pages are not resident. How many page faults will occur if a LRU replacement algorithm is used, and our page pool is composed of six pages?
• Part 5: How many page faults will occur if a strict FIFO replacement algorithm is used, and our page pool is composed of six pages?
• Part 6: Suppose our hardware does not include a valid bit. Moreover, suppose we only want to allocate six pages to our palcount() process. How can we augment the FIFO algorithm to perform on par with the LRU algorithm? Give details on why the performance is similar.

Question 3: 11 points

Jimus' computer has the following features:

• Although pointers are four bytes, valid virtual addresses are between 0x00000000 and 0x00ffffff.
• Pages are 256 bytes.
• Page-table entries are four bytes each, composed of a pointer to the physical page frame, and a "valid" bit.

• The first page is NULL access.
• The next two pages contain code.
• The next page is NULL access.
• The next three pages contain the globals and the heap.
• The stack is composed of four pages, and the last legal stack address is 0x00fffeff.
• All other pages are NULL access.

Answer the following questions:

• Part 1: What are the addresses of the code segment?
• Part 2: What are the addresses of the globals/heap segment?
• Part 3: What are the addresses of the stack segment?
• Part 4: How many pages of page table entries does RedHat use for this process?
• Part 5: Draw me a picture of the page table(s) for part 4.
• Part 6: How many pages of page table entries does Jimux use for this process?
• Part 7: Draw me a picture of the page table(s) for part 6.

Question 4: 6 points