Babylon: Rephrasing CS162 and providing a common infrastructure for CS61C, CS152 and CS164

Marcelino Enriquez mars@cs, Brian Gaeke brg@cs, Galen Hancock galen@csua,
Gagan Prakash gagpcool@hkn, Paolo Soto paolo@csua, Nicholas Weaver nweaver@cs

Babylon@CSUA.Berkeley.EDU
[status reports] [meeting minutes]

The Motivation:

Nachos in its current form is a not as an effective teaching tool as it used to be. At the start, nachos was written in C++ but used only select C++ features in order to implement more complex data structures. Over the course of time, too many C++ features have been added into the current version of nachos - resulting in forcing the 162 student to spend time learning about the intricacies of C++, taking time away from learning the concepts of Operating Systems.

Nachos itself has several key issues. As a simulator, it does not truly simulate the environment of a production operating system running under hardware. Curently the user programs run on the simulated processor of the virtual machine, while the kernel runs on the real processor. Nachos (except for the java implementation, which we address below) is not truly pre-emptive. Java Nachos is preemptive, but nondeterministic with respect to concurrency errors, and is too load intensive for the current instructional infrastructure to support.

Our Proposal

We wish to develop a self contained system in which students can easily read, learn, and understand operating system concepts in a portable framework. Our proposed system consists of a small, multithreaded, mach-style microkernel written in ANSI C, with an emphasis on compactness, readability, and extensibility. The kernel will include basic support for task switching, scheduling, protection, and I/O, with several projects for the class already designed-into the framework.

The kernel will be completely new, in order to keep the design as elegant and readable as possible. Both the kernel and user programs will be compiled using gcc, linked with the GNU binutils, and will run on a MIPS architecture simulator which supports scripted events and signals, GDB support, and suitably realistic I/O devices.

By running both the user and kernel on the simulator, this enables preemptive multitasking while retaining determinism, allows a very high degree of portability as it eliminates all architecture-dependent code, makes the design much more Arealistic, and supports debugging of both user and kernel programs through a common interface.

Figure 1

Extensions Into Other Courses

This framework is designed to be easily usable by other courses as well as CS162. CS152 stulents could implement in silicon the module to handle output of the binsutils. CS61c students could learn about linkers/loaders by writing/code-studying the assembler and linker for this system. CS164 material can easily be added by having the backends of either the cool or the java compiler output mips assembly. We will designed the system to be easily integrable into other courses and their respective material.

61c students will have access to a compiler, linker, and loader as well as a MIPS simulator with better debugging support, while providing familiarity with a set of tools which they may encounter again in later courses.

Implementation Summary

For the implementation we can use gcc or lcc as the compiler. For the simulator we could use spim or vmips (fully spec compilant virtual mips machine created by Brian Gaeke).
If we select vmips, this offers an already existing compiler, libc, linker, loader, and GDB interface.

Staffing Requirements

A simple budget to support 3 programmers for about 3-4 months worth of programming work would be sufficient, with an additional month of debugging. This can be done through funding by EECS Instructional, since 2 of the proposal writers are undergraduates currently working for EECS Instructional and would be interested in working on the project over the summer, as we would have more time to dedicate to this project during the summer break.

Timeline/Milestones

  • Simulator - done (vmips)
  • LibC - partly done
  • Simulator Documentation
  • multithreaded mach-style kernel
  • kernel Documentation
  • Block, Network, and Serial devices.
  • Skeletal 152 processor
  • Skeletal 164 compiler back end

    Future Directions

    Our simulator would be designed for future extensiblity as well. Future work could consist a multiprocessor simulator, and a programmed IO disk model, for more advanced features.

    Conclusion

    We believe that our courseware will be a much better platform for the concepts of CS162. We believe that our revisions will provide a reusable and extensible framework for CS[162, 152, 164, 61C].