Multiprocessing on the STM

Homework 4: Multiprocessing on the STM

In this homework, you will convert the STM operating system to support multiple processing with a round-robin scheduler. Call your modified stm program "stm-xxx.c" (replace "xxx" by your own last name).

This involves the following changes and extensions:

Command line

The command line has the following form:

stm-xxx [-q QUANTUM] [-d DEBUGGING-LEVEL] [-m MAX] prog1.stm prog2.stm ...

where

The optional argument "-q QUANTUM" sets the number of instructions in the time quantum. Default value = 5.
The optional argument "-d DEBUG" sets the level of debugging output: Default value = 0.
- If DEBUG == 0, then the only output is that required by the STML code.
- If DEBUG == 1, then
  a) each time a TRP instruction is executed, the program prints out the name and index of the process, the address of the instruction, and the value of the R15 register;
  b) Each time there is a context switch, the program prints out the indices of the old process and the new process.
- If DEBUG == 2, then, additionally,
  a) When the STML modules are loaded, the program displays the physical address and virtual address of each instruction;
  b) Each time any other instruction is executed, the program prints out the name and index of the process, and the address, op-code, and arguments of the instruction.
The optional argument "-m MAX" ensures that your STM interpreter executes at most MAX instructions before quitting. This may be useful for debugging.
The arguments prog1.stm, prog2.stm, etc, are names of files containing the stml code, where each file will be run by a process. The same file may be repeated; in this case, there will be two processes executing the same code, generally on different input data.

Note that the optional argument "-b BASE" from the original SML program is not needed.

Loading

At the beginning of execution, each SML file in the command line gives rise to a process. Each process is given a partition in memory of the size specified at the beginning of the SML file. Partitions are assigned in the order of the command line, starting at physical address 0. The SML code and data from the file is read into the bottom of the corresponding partition.

Process Table

The process table should hold the following information for each process:

The values of the 16 registers.
The values of the base and limit registers.
The name of the process.

You may assume that there are no more than 20 processes and that the name of the process is no more than 32 characters.

Process Queue

You should maintain a FIFO queue of processes. When the running process is preempted, it is placed at the back of the queue. When the running process terminates or aborts, it is removed from the queue. When the queue is empty, the STM simulator halts.

Preemption and context switches

A context switch takes control away from the current process under any one of four circumstances:

The process exhausts its time quantum.
It executes a trap to the kernel.
It deliberately terminates.
It executes an error.

Note that when a process is resumed, it is given exactly the standard time quantum, no more and less. It does not get extra or less time if it failed to use up its previous quantum.

Context switching involves the following:

If the outgoing process is active, then it is placed at the back of the process queue; if not, it is deleted from the process queue.
The process at the head of the queue is chosen to resume.
The values of the registers, other than the base and limit register, must be saved for the outgoing process in the process table.
The values of all the registers, including the base and limit registers, must be loaded for the incoming process from the process table.

Coding

The three functions "phys_address", "get_inst", and "exec_inst" correspond to the supposed hardware of the simulated machine. THESE MAY NOT BE CHANGED. You may change any of the other functions.

HINTS

In order to distinguish Input/Output of different processes, we should print a helpful message identifying the process name, and the action being performed (either input or output).
You will need to maintain several lists, including a list of all the current processes. This is a process table. To do this, it would be helpful to know something about the "struct" data type. If you are not familiar with this concept, please check my webpage on the C language for a brief introduction.
This is not required, but can earn you extra credit points. Modify your solution so that the process table is actually loaded in memory. This is, of course, more realistic. In particular, it would be useful to write write/read functions to store/load string data to/from memory.
This is not required, but a suggestion. To make the OS more realistic, we can have the OS execute an infinite while-loop, waiting to interact with the users. A sequence of jobs can be submitted using the same format as the command line argument that we use above:
E.g.,
% jobs [-q QUANTUM] [-d DEBUGGING-LEVEL] [-m MAX] prog1.stm prog2.stm ...
where "%" is the OS prompt, and "jobs" is a key word. You would need to do some simple synchronization since the screen is also used for I/O from your programs.
You should be able to see the current jobs running by typing
% status

Finally, to exit the OS, you type another key word,
% exit