We will be using a virtual platform (VP), which is the combination of a virtual machine (VM) (which is really a simulated, simple CPU architecture) and a kernel that controls that machine.
The current virtual platform is capable of booting the kernel, which in turn loads a single executable image, executing that one process, and then halting. While there is a good deal of machinery involved in this simple platform, it does not do as much as we would like.
Most specifically, we would like the kernel to be able to load and interleave the execution of multiple processes. That is, when the virtual platform is started, two or more programs can be specified (some programs perhaps more than once).
First, follow the steps outlined on the Getting Started with The VP page. It will provide instructions on how to download, compile, and run the VP. You may also wish to examine the assembler documentation to see how you can write new programs that will run on the VP.
Notice that the virtual platform, as provided, is a uniprogrammed system that will execute a single program and then halt. The following steps indicate the elements of the kernel that you must modify or expand:
The kernel does not handle clock interrupts, invalid instruction interrupts, or invalid memory access interrupts. You must modify the kernel to handle each of those.
The CPU (a.k.a. the VM) must have its clock interrupt period set, or else it will not cause the periodic trap. You must set the interrupt period. (I recommend a small value -- just a few cycles -- for debugging purposes.)
The kernel and (the bootstrapping portion of) the VM must be modified to load multiple executable images and create processes for each. Note that there are currently no data structures to keep track of processes in the kernel -- you must add that capability!
In its current form, the virtual machine supports protection on address ranges (with base and limit registers) so that the kernel can keep processes from accessing one another's memory. You must, in creating and loading each process, allocate memory space and enforce the use of its own memory range.
The clock interrupt handler should implement a scheduler, thus bringing about pre-emptive multitasking.
Processes should be able to perform a FORK system call. Create this system call within your kernel, such that a process that forks has all of its resources (read: address space) duplicated as a copy. Note that there is an enumeration of the system calls in systemCall_t, near the front of kernel.cc. The FORK call should be assigned the constant 0x11111110. The FORK call should return (via register %s0):
Note that we will not worry about an EXEC facility just now -- these will be two copies of the same process, running happily along to completion.
It is important to note that no changes to the virtual machine are needed (other than the passing of multiple executables during bootstrapping). There may be bugs in the virtual machine, but if there are, you should contact me! I will compile your kernel along with my virtual machine when evaluating your work, and they should work together!
When you've completed the project, submit the files as project-1 using cs39-submit.