Assigned: January 22, 2003 Due: February 22, 2003 11:59:59 PMPhase 1: Understand the CodePhase 2: Design ConsiderationsPhase 3: [75%] Exceptions and IO System CallsPhase 4: [10%] Implement a new system callPhase 5: [15%] DocumentationDeliverables and gradingWhen you complete your project, remove all executables and object files. If you want me to read a message with your code, create a README.NOW file and place it in the nachos code directory. Tar and compress the code, and submit the file using the online submission system. It is important that you follow the design guidelines presented for the system calls. I will be running my own shells and test programs against your code to determine how accurately you designed your lab, and how robust your answers are. Grading for the implementation portion will depend on how robust and how accurate your solution is. Remember, the user should not be able to do anything to corrupt the system, and system calls should trap as many error conditions as possible.Project #1 – Exceptions and Simple System CallsIntroduction to Operating Systems CSE421Assigned: January 22, 2003 Due: February 22, 2003 11:59:59 PMThe first project is designed to further your understanding of the relationship between the operatingsystem and user programs. In this assignment, you will implement simple system call traps. In Nachos,an exception handler handles all system calls. You are to handle user program run time exceptions aswell as system calls for IO processing. We give you some of the code you need; your job is to completethe system and enhance it.Phase 1: Understand the CodeThe first step is to read and understand the part of the system we have written for you. Our code can runa 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 theprogram ‘nachos –rs 1023 -x ../test/halt’. As before, trace what happens as the user program getsloaded, runs, and invokes a system call.The files for this assignment are:progtest.cc test routines for running user programs.syscall.h the system call interface: kernel procedures that user programs can invoke.exception.cc the handler for system calls and other user-level exceptions, such as page faults. In the code we supply, only the ‘halt’ system call is supported.bitmap.* routines for manipulating bitmaps (this might be useful for keeping track of physical page frames)filesys.hopenfile.h (found in the filesys directory) a stub defining the Nachos file system routines.For this assignment, we have implemented the Nachos file system by directly making the corresponding calls to the UNIX file system; this is so that you need to debug only one thing at a time. In assignment four, we'll implement the Nachos file system for real on a simulated disk.translate.* translation table routines. In the code we supply, we assume that every virtualaddress is the same as its physical address -- this restricts us to running one user program at a time. You will generalize this to allow multiple user programs to be run concurrently in a later lab. machine.* emulates the part of the machine that executes user programs: main memory, processor registers, etc.mipssim.cc emulates the integer instruction set of a MIPS R2/3000 processor.console.* emulates a terminal device using UNIX files. A terminal is (i) byte oriented, (ii) incoming bytes can be read and written at the same time, and (iii) bytes arrive asynchronously (as a result of user keystrokes), without being explicitlyrequested.synchconsole.* routine to synchronize lines of I/O in Nachos. Use the synchconsole class to ensure that your lines of text from your programs are not intermixed.../test/* C programs that will be cross-compiled to MIPS and run in Nachos1Phase 2: Design ConsiderationsIn order to fully realize how an operating system works, it is important to understand the distinctionbetween kernel (system space) and user space. If we remember from class, each process in a system hasits own local information, including program counters, registers, stack pointers, and file system handles.Although the user program has access to many of the local pieces of information, the operating systemcontrols the access. The operating system is responsible for ensuring that any user program request tothe kernel does not cause the operating system to crash. The transfer of control from the user levelprogram to the system call occurs through the use of a “system call” or “software interrupt/trap”. Beforeinvoking the transfer from the user to the kernel, any information that needs to be transferred from theuser program to the system call must be loaded into the registers of the CPU. For pass by value items,this process merely involves placing the value into the register. For pass by reference items, the valueplaced into the register is known as a “user space pointer”. Since the user space pointer has no meaningto the kernel, we will have to translate the contents of the user space into the kernel such that we canmanipulate the information. When returning information from a system call to the user space,information must be placed in the CPU registers to indicate either the success of the system call or theappropriate return value.In this assignment we are giving you a simulated CPU that models a real CPU. In fact, the simulatedCPU is the same as the real CPU (a MIPS chip), but we cannot just run user programs as regular UNIXprocesses, because we want complete control over how many instructions are executed at a time, howthe 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’ subdirectoryfor an example. The compiled programs must be linked with some special flags, then converted intoNachos format, using the program “coff2noff” (which we supply). The only caveat is that floating-pointoperations are not supported. NOTE : You should -NOT alter the code within the machine directory, only the code within theuserprog directory. 2Phase 3: [75%] Exceptions and IO System CallsImplement exception handling and handle the basic system calls for file IO. (All system calls are listedin syscall.h) We have provided you an assembly-language
View Full Document
Unlocking...