November 11's class will be spent discussing this project. Each one of you will be responsible for leading the discussion on one of the three items of the project (you decide among yourselves who is assigned what item). Your preparedness for your part of the discussion will be factored into your project grade. Don't forget that you have me and each other as resources in preparing for this discussion. My expectation will be that you have completed the design phase of the project and are working on the implementation.
The second phase of Nachos is to support multiprogramming. As in the first assignment, we give you some of the code you need; your job is to complete the system and enhance it.
The first step is to read and understand the part of the system we have written for you. Our code can run a single user-level `C' program at a time. As a test case, we've provided you with a trivial user program, `halt'; all halt does is to turn around and ask the operating system to shut the machine down. Run the program `nachos -x ../test/halt'. As before, trace what happens as the user program gets loaded, runs, and invokes a system call.
The files for this assignment are:
You'll be working in the userprog directory for this project. This project builds on what you did in the first project --- making use of the synchronization routines you wrote. You may discover design flaws that were not brought out in the testing of the first project.
So far, all the code you have written for Nachos has been part of the operating system kernel. In a real operating system, the kernel not only uses its procedures internally, but allows user-level programs to access some of its routines them via ``system calls''.
In this assignment we are giving you a simulated CPU that models a real CPU. In fact, the simulated CPU is the same as the real CPU (a MIPS chip), but we cannot just run user programs as regular UNIX processes, because we want complete control over how many instructions are executed at a time, how the address spaces work, and how interrupts and exceptions (including system calls) are handled.
Our simulator can run normal programs compiled from C --- see the Makefile in the `test' subdirectory for an example. The compiled programs must be linked with some special flags, then converted into Nachos format, using the program ``coff2noff'' (which we supply). The only caveat is that floating point operations are not supported.
Note that you will need to ``bullet-proof'' the Nachos kernel from user program errors --- there should be nothing a user program can do to crash the operating system (with the exception of explicitly asking the system to halt). Also, to support the system calls that access the console device, you will probably find it helpful to implement a ``SynchConsole'' class, that provides the abstraction of synchronous access to the console. ``progtest.cc'' has the beginnings of a SynchConsole implementation; look ahead to the file system assignment for the similar example for the SynchDisk class.
Instrument the operating system to keep track of average response time for executing user programs. Write a test case (a set of user programs to run) that performs well using your policy for scheduling the CPU among user programs, and a test case that performs poorly (has very long average response time). Run the test cases and explain the measured performance. What would you need to do in order to fix this?
(10% extra credit) Implement multithreaded user programs. Implement the thread fork and yield system calls, to allow a user program to fork a thread to call a routine in the same address space, and then ping pong between the threads.