Download Nachos Project 2: Multi Programming | CMSC 321 and more Study Guides, Projects, Research Operating Systems in PDF only on Docsity!
CMSC 321 — Operating Systems Nachos Project 2: Multiprogramming, Part 1 of 2 (Modified copy of Nachos Assignment #2 by Tom Anderson) Due Date: Wednesday, March 4, 2009, 11:59pm
The second phase of Nachos is to support user‐level multiprogramming. This project will be split into two separate parts—this document describes the first of those two. As in the first assignment, you are
given some of the code you need; your job is to complete the system and enhance it.
In order to get the files for this assignment, do the following:
- In your Nachos working directory, save a copy of your Project 1 directory. For example, use cp –r nachos1/ nachos2/ to make a copy of the directory to use for Project 2. (The ‐r flag to cp denotes a recursive copy— it will copy the directory and all its contents, including other subdirectories and their contents.)
- Download nachos2.tgz from the course assignments web page and save to the directory where your nachos2/ directory was created, unpack and then delete the tarball. (NOTE: nachos2.tgz packed the nachos2 directory; for this to work as it should, you have to unpack in the directory that contains your new nachos2 directory! Try tar tzf nachos2.tgz to see what I mean.)
This procedure will overwrite everything in the nachos2/ directory except the threads subdirectory, which will be preserved as you submitted it for Project 1. Some new files will also be placed into the
directory.
Now when you invoke make in your new Nachos top‐level directory, a nachos executable will be created in the userprog subdirectory. This executable will use source files from the threads
directory, including your implementation of locks and condition variables from Project 1.
The first step is to read and understand the part of the system that has been written for you. The code
can run a single user‐level C program at a time. As a test case, you are provided with a trivial user
program (in the test directory) named halt; all halt does is ask the operating system to shut the machine down.
To run the user program in Nachos, execute nachos -x ../test/halt. As before, trace what happens as the user program gets loaded, runs, and invokes a system call. Trace the code down to the
details.
Following are the files for this assignment. Be sure to read each of them carefully. To better understand
what is going on, you may want to read Thomas Narten’s A Road Map Through Nachos , available via link from the course web page.
- progtest.cc — test routines for running user programs.
- addrspace.h, addrspace.cc — create an address space in which to run a user program and load the program from disk.
- syscall.h — the system call interface: kernel procedures that user programs can invoke. Implementation of these system calls is the bulk of the programming in this project.
- exception.cc — the handler for system calls and other user‐level exceptions, such as page faults. In the code supplied, only the Halt() system call is supported. Until you implement the code for the other system calls, a system call will result in an ASSERT() violation and a core dump.
- bitmap.h, bitmap.cc — routines for manipulating bitmaps (this might be useful for keeping track of physical page frames).
- filesys.h, openfile.h (in the filesys directory)—a stub defining the Nachos file system routines. For this assignment, the Nachos file system is implemented by directly making the corresponding calls to the Unix file system.
- translate.h, translate.cc (in the machine directory) — translation table routines. In the code supplied, every virtual address is assumed to be the same as its physical address — this restricts you to running one user program at a time. You will generalize this to allow multiple user programs to be executed concurrently. You will not be asked to implement virtual memory support until the next project; for now, every page of a running program must be in physical memory. All address translation will be handled via page tables — do not use the TLB of the simulated MIPS processor yet. (In translate.cc, you will find ReadMem() and WriteMem(), which will prove useful.)
- machine.h, machine.s (in the machine directory) — emulates the part of the machine that executes user programs: main memory, processor registers, etc.
- mipssim.cc (in the machine directory) — emulates the integer instruction set of a MIPS R2/3000 processor.
- console.h, console.cc (in the machine directory) — emulates a terminal device using UNIX files. A terminal is (i) byte oriented, (ii) allows incoming bytes to be read and written at the same time, and (iii) allows bytes to arrive asynchronously (as a result of user keystrokes) without being explicitly requested.
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 also allows user‐level programs
to access some of its routines via system calls.
In this assignment, you are given a simulated CPU. The user programs are run on this simulated CPU
which acts the same as a real MIPS CPU. You cannot just run user programs as regular UNIX processes because you 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.
c) Use timer interrupts to force threads to yield after a certain number of ticks. Note that the source code in scheduler.cc already saves and restores user machine state on context switches.
A few brief words on compiling user programs: First, note that all user programs in the test directory
include only syscall.h. This is really the only library header file you can include, since these system calls are the only ones Nachos supports. Second, consider how a Nachos user program is compiled. The
Makefile in the test directory contains instructions for compiling the sample programs in that
directory. For example, the Makefile contains these lines to compile and link shell.c:
shell.o: shell.c $(CC) $(CFLAGS) -c shell.c shell: shell.o start.o $(LD) $(LDFLAGS) start.o shell.o -o shell.coff ../bin/coff2noff shell.coff shell
These lines expand to
/usr/local/gnu/decstation-ultrix/bin/gcc -G 0 -c -I../userprog -I../threads -c shell.c /usr/local/gnu/decstation-ultrix/bin/ld -T script -n start.o shell.o -o shell.coff ../bin/coff2noff shell.coff shell
The gcc and ld in the directory above are the MIPS C cross compiler and linker — they generate MIPS machine language code. Look at the man pages for gcc and ld to explore what all the options do. The
first line compiles a C program into an object file, but does not link it. The second line links the object file with the object file start.o. Notice that every Nachos user program must be linked with start.o. As
mentioned above, it contains the code necessary for a C user program to make a Nachos system call by name. The third line converts a Unix format executable (coff format) to a simpler Nachos format
executable (noff format). The resulting executable shell can be executed by the simulated MIPS processor.
