Introduction | Mechanics | Getting Started | CHIP | HOCA
The project consists of designing and implementing the HOCA (Turkish for good teacher) operating system. The project is structured in three phases:
Project teams The project is to be done in teams of four or five. The assignments will be the same for either size team. Groups of five will have less coding to do per person but will also have to manage the interactions between more people. We will not allow teams of less than four. If for any reason you need to switch groups, you need to get explicit from the TA and instructor. In general, switching teams will only be approved effective after the current assignment is completed.
Improving your engineering skills requires learning
from your mistakes -- asking after each bug you find, ``how could I
have found this bug earlier or with less effort?'' To encourage you to
do this, every member of each group is to keep a journal of your
activities in completing each assignment. The journal should contain
which areas of the project you worked on, how you attacked each
problem, and what bugs you found after you had gotten it to
compile. The journals will be graded.
Also, in order to encourage every member of the team to contribute equally, every team member is required to individually email your TA with a quantitative assessment of the relative contributions of each of your teammates, excluding yourself. This should be turned in as part of your journal. If you have N people in your group, you have (N-1)*20 points to allocate among your teammates, proportional to how much they contributed to just this assignment.
It is our experience that for most groups, all of your teammates will pull their weight, and so you'll be able to simly give 20 points to each member. But if you have as teammates Sam Slacker, Annie Average, Hugh Helpful, and Connie Conscientious, for example, then you might allocate your 80 points as follows:
Grading policy The grading for the project will be as follows: 40% design, 30% comments and programming style, and 30% implementation. We have structured the grading in this way to encourage you to think through your solution before you start coding. If all you do is to work out a detailed design for what you would do to address the assignment (and if the design would work!), but you write no code, you will still get substantial credit. The implementation and code documentation portion of the grade considers whether you implemented your design, and provided documentation that the reader could understand. Part of being a good engineer is coming up with simple designs and easy to understand code; a solution which works isn't necessarily the best that you can do. Thus, part of the design and implementation grade will be based on whether your solution is elegant, simple, and easy to understand.
The intent of the grading for the project is not to differentiate among those students who do a careful design and implementation of the assignments -- in other words, don't implement some complex feature just because someone else in the class is implementing it. My expectation is that most of you will get close to full credit on each assignment. Rather, the grading is to help me identify those students who (i) don't do the assignments or (ii) don't think carefully about the design, and therefore end up with a messy and over-complicated solution. You cannot pass this course without at least making a serious attempt at each of the assignments. Further, the grading is skewed so that you will get substantial credit, even if your implementation doesn't completely work, provided your design is logical and easy to understand. (In other words, don't pull an all-nighter just to fix the last remaining bug in your solution.)
Grading: Design To be successful on this project without spending an indordinant amount of time on it, it is essential that you spend time designing a solution that will work before you start coding. To encourage this approach, half of the project grade will be based on your design of the system. The project design grade have four parts worth a total of 50 points per project.
Design proposal 5% Design Review 15% README and
15% Journal 5%
Grading: Implementation Half of the project grade will be for your implementation. Each assignment will indicate how implementation points will be divided across different subcomponents of the project. The TA will compile and run your program and test cases. The TA may also run additional test cases that we devise! The TA will also evaluate your code's simplicity and elegance, as well as your coding style.
Grading: Teamwork For each project, your ``Teamwork'' score will be out of a possible 20 points. We will base this number on the average score given by your teammates, but the TA or instructor may adjust that number based on our interactions with you at the design review and at office hours or based on your journal. At the end of the semester, we will adjust your overall project grade based on your average ``teamwork'' grade on the projects as follows:
Note that our goal is not to encourage anyone to take on huge amounts of extra work to gain extra credit at the expense of the rest of the team. And, as we indicated above, we expect the vast majority of students to do their fair share of work and get scores around 20 points.
> 22 +1% to +5% of project grade 17-22 no change 15-17 -10% of project grade 13-15 -20% of project grade 10-13 -30% of project grade 7-10 -40% of project grade 5-7 -50% of project grade 3-5 -75% of project grade 0-3 -90% of project grade 0 -100% of project grade
Late policy We will use flexible slip dates for the assignments. Each team is given an automatic extension of 3 calendar days, which you can use on any assignment during the semester, in any increment, as long as the total amount of lateness did not add up to more than 4 days. For instance, you can hand in one assignment 4 days late, or each of four assignments 1 day late. This should let you schedule due dates around the due dates for other courses. When you hand in an assignment, you must identify at the top of the assignment, (i) how late this assignment is, and (ii) how much of the total slip time you have left. If you wish, you may calculate your remaining slip time to the nanosecond. After you have used up your slip time, any assignment handed in late will be marked off 10% per day or part thereof. There will be no extensions granted.
The project assignments will be done using public SPARC 5s. You can get a list of the machine names by typing cshosts pubss5. All upper-division CS students (which, I think, includes all students in the class) should already have accounts on these machines. If not, contact me.
In order to access the course software you should add the following to the PATH and MANPATH environment variables of your UNIX account:
This document describes the architecture on top of which the kernel will be implemented.
This document describes CHIP's graphical interface and contains a tutorial describing how the interface is used to debug and execute programs written for CHIP.
This document contains the configuration of several of CHIP's hardware parameters.