The Project 
 
Introduction | Mechanics | Getting Started | CHIP | HOCA 






Introduction



The project consists of  designing and implementing the HOCA (Turkish
for good teacher) operating system. The project is structured
in three phases:  

    

  1.  The first phase involves implementing two modules that are later
used in the nucleus to implement the process queue and the semaphore
abstractions. 

  2.  The second phase involves building the nucleus --- the routines
that implement the notion of asynchronous sequential processes, a
pseudo-clock and the synchronization primitives. 

  3.  The third phase involves implementing another software level
(the  support level) that creates an environment with virtual
memory, input/output devices and virtual synchronization operations
that is suitable for the execution of user programs. 



Mechanics



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.



Journals
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:



If on the next assignment, Sam starts pulling his weight, you should
reflect his new performance (and not his past record) in the
assessment for that assignment. We will use this information in
determining final grades. By the way, many engineering companies use
peer review to determine annual raises, so making your peers think you
are useful is a good skill to have.




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 
 Code documentation 		
 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:









 > 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 











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. 


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.





Getting Started



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:



You should also add the following to your .login file:





The CHIP Computer
System
 



The Hoca Operating System