One such routine is reschedule. This routine should behave like the reschedule I described in class. When called, it should save the state of the current process and pick a new process to execute. In this system, the mechanism for selecting a new process is specified. The process selected must have a priority value greater or equal to any other ready process' priority.
I mention reschedule in particular, because if you look at the KMOS code you will notice that Milenkovic uses a routine named dispatch rather than reschedule. His routine behaves significantly differently from reschedule. In particular, calls to dispatch never return. You should use a primitive similar to reschedule in your system.
Other useful routines to have might be a procedure to insert a process on or delete a process from the ready list (or a queue in general). I do not want to spell out your entire design by identifying all such procedures, but I want to remind you to take the time to carefully consider how to structure the routines that manipulate processes.
In several of the kernel routines you will need to disable and enable interrupts. In class I indicated that in a real system, all kernel calls would be performed by causing traps, thereby saving the processor status register and loading a new processor priority. In your kernel it will be simpler to simply call kernel routines. If this is done, however, you will need some other way to save the processor priority before you disable interrupts. To make this possible, I have added a "Store Processor Status Register" instruction (STPS) to the WC34020.