Nachos 2013

From ACM Class Wiki
Jump to: navigation, search



  • (Oct 13) Setup web page.


The project for this course is to build an operating system from scratch. We believe that the best way for you to understand operating systems concepts is to build a real operating system and then to experiment with it. To help you get started, we have built a very simple, but functional, operating system called Nachos. Over the course of the semester, your job will be to improve the functionality and performance of Nachos; we expect that you will eventually modify or replace much of what we have written.

The project has several phases, corresponding to the major pieces of a modern operating system: thread management, multiprogramming, virtual memory, file system, etc. Some phases build on previous phases; for example, all parts of the project use thread management routines. As far as possible, we have structured the assignments so that you will be able to finish the project even if all of the pieces are not working, but you will get more out of the project if you use your own software. Part of the charm of building operating systems is that you get to "use what you build": if you do a good job in designing and implementing the early phases of the project, that will simplify your task in building later phases.

The end result of the project is to build the infrastructure for running multiple user-defined programs. Part of the code we provide is a software emulation of a MIPS-like workstation. For instance, our code emulates turning on and off interrupts, taking exceptions and page faults, as well as the actions of physical devices (e.g. a disk, a console, etc.).

It is important to realize that while we run Nachos on top of this emulation as a Java program, the code you write and most of the code we provide are exactly the same as if Nachos were running on bare hardware. We run Nachos as a Java program for convenience: it is very portable and easier to debug. These same reasons apply in industry; it is usually a good idea to test out system code in a simulated environment before running it on potentially flaky hardware.

In order to port Nachos to real hardware, we would have to replace our emulation code with a little bit of machine-dependent code and some physical machines. For example, in phase 1, we provide routines to enable and disable interrupts; on real hardware, the CPU provides these functions.

Unless you work for a really smart company, when you develop operating system software you usually cannot change the hardware to make your life easier. Thus, you are not permitted to change any of our emulation code, although you are permitted to change most of the Nachos code that runs on top of the emulation.

Finally, some suggestions for doing well in this course:

  • Read the code that is handed out with the assignment first, until you pretty much understand it. Start with the interface documentation.
  • Don't code until you understand what you are doing. Design, design, and design first.
  • If you get stuck, talk to as many other people as possible.


Grading Policy

For each phase, we will use a set of test cases to see if your implementation achieves the expected behavior within a limited time (varied for each case). You will be graded according to the number of test cases passed. The percentage for each phase is:

  • Phase 1: 30%
  • Phase 2: 20%
  • Phase 3: 30%
  • Phase 5: 20%

You can submit your work no later than one week past the deadline, and you can submit for multiple times. The penalty for the delayed submissions and re-submissions is calculated as follows:

           / D(D+1)            \
Penalty = ( ------- + (R-1) x 5 ) %
           \   2               /

where D is the number of days past the deadline and R is the number of the submitted versions. Your final grade will be the maximum of the grades of all the submissions you make. However, we may choose not to grade your submission if the maximum potential grade of that submission cannot surpass the current one.

The result for each phase will be published one week after the deadline. To help with your debugging, the full test cases used for grading will be published at the 3rd day past the deadline.

Warning: Any cheating submission will receive a score of zero.

Submission Guideline


  1. Create a Bitbucket account and a private git repository nachos2013
  2. Add username xjia to your repository with read permission
  3. Get the Nachos framework from

Refer to Bitbucket 101 on how to install git and how to create accounts and repos, etc.

Warning: You must create a private repository so others cannot access your code. If you share code with others, you will get a score of zero for this course.

Repository Layout

If your project is located at e.g. /home/yourname/nachos2013 (or C:\Users\yourname\nachos2013), the layout of this directory should be as follows.

|-- nachos-sjtu
|   |-- conf
|   |-- doc
|   |-- src
|   |   |-- nachos
|   |       |-- ag
|   |       |-- filesys
|   |       |-- machine
|   |       |-- network
|   |       |-- security
|   |       |-- threads
|   |       |-- userprog
|   |       \-- vm
|   |
|   |-- README
|   \-- .gitignore
\-- test

You must put your Java source code files in the src directory. It is recommended to create the .gitignore file with the following content.



This course project is divided into four phases, and you are required to submit by creating a tag for each of the phases.

By typing the following commands, you can submit the second version (v2) of your code for an imaginary phase 0 (p0).

git tag p0v2
git push --tags

For the real phases 1, 2, 3 and 5, use p1, p2, p3 and p5 instead of p0. Start versioning your submission from v1.



JIA Xiao xjia [at]
LIU Jingcheng liuexp [at]
XIAO Changcheng xchangcheng [at]
ZHANG Xinjian zhangxinjian1015 [at]
Personal tools