Module R3 Process Scheduling

Module R3 involves the creation of a simple “Round Robin” dispatcher. The successful completion of this module will require that you read and understand chapters I2, I3, and R3 from your project manual. Successful completion of this module requires that you understand: Interrupt handlers, context switching, and the role of the system stack and registers. (I2)

Components of R3  Add 1 temporary command to your command handler:  This command exists to allow the testing of your “dispatcher” and “system call handler”.  This operation will be responsible for creating and initializing 5 PCB’s to represent 5 processes which will be dispatched.

 You will implement 2 internal functions the “dispatcher” and the “system call handler”  The “dispatcher” is responsible for locating the next ready process and performing a context switch to begin executing that process  The “system call handler” will be responsible for handling “system” calls issued by the running processes. These system calls will trigger an interrupt that will result in either the current process leaving the running state, and another being dispatched, or the current process being terminated  Both of these functions will be structured as interrupt handlers.

Addresses, the stack, and registers  The 8086 processor uses an addressing scheme called “segmented addressing”  A pair of 16 bit values is needed to create an address: A segment number and an offset.  A segment # represents the startling location of a 64k byte region called a segment  The offset represents a relative address within that segment  Addresses are typically represented as XXXX:YYYY where XXXX is the segment #, and YYYY the offset, both values are assumed to be in hexadecimal

 To facilitate addressing (so every instruction needn’t supply 2 separate 16-bit address components) bit segment registers (containing segment #’s) are maintained:  Data Segment: contains the static (persistent) data variables used by a program. This is stored in the DS register. This value is automatically used for memory references that fetch and store data.  Code Segment: Contains the instructions of the program being executed. This is stored in the CS register. This value is automatically used when instructions are being fetched. A 16-bit register called the IP (instruction pointer) is used for determining the address of the next instruction to be executed.

 Stack Segment: the storage area for the “current stack”. This is stored in the SS register. The stack is used for temporarily storing addresses and data, both explicitly via push and pop instructions, and implicitly during subroutine calls and interrupts. (like local variables.. Etc)  Extra Segment: this is a spare segment, whose location is stored in the ES register.

The Stack  The stack is a data buffer. At any time a set of data items occupies a contiguous region with in the buffer.  One end called the bottom is fixed, the other end called the top is movable.  Generally data is added and removed only at the top of the stack. A push adds a data item, a pop removes a data item.  A pointer (called the stack pointer) must be maintained POINTING to the top of the stack.

 In the 8086, stacks are designed to grow from higher addresses to lower addresses  Each push operation will:  Decrement the stack pointer by 2  Store a data word at the new address given by the stack pointer  Each Pop operation will:  Fetch a data word from the address given by the stack pointer  Increment the stack pointer by 2  One important usage of the stack is that in C, function parameters are frequently pushed onto the stack before calling a function. Data 10A bottom top

Addressing registers:  Additionally, there are 4 registers that can be used for offset calculation:  SP: The stack pointer is used in pushing values and addresses on the stack, and for popping these from the stack.  BP: the “base pointer” can be used to compute offsets for both the stack segment and the data segment. In turbo C it is often used as a temporary register for saving the value of the stack pointer.  SI and DI: Source and destination indexes. These are used to compute the offset of data

Data Registers  The 8086 also has 4 16-bit data registers (aka. General registers or arithmetic registers) AX, BX, CX, & DX  These registers can also be treated as 8 8bit registers: AH, AL, BH, BL, CH, CL, DH, DL (H refers to the high order byte, and L the low order)  A,B,C & D stands for accumulator, base, count, and data.  When saving and restoring the context of processes we must ensure that values for these registers are not corrupted.

Program status word  One last register to concern ourselves with: is the program status word  This register contains condition codes, and bits that determine whether or not certain interrupts can be generated.  For R3, we will be interested in the 9 th bit or the IF (interrupt enable flag).  During interrupt processing we will disable interrupts by setting this bit to 0. We must later restore it.

Dispatcher Initialization  This involves adding a new command to your COMHAN called “dispatch”.  This will invoke a function which will perform the following:  Allocate and initialize 5 PCB:  These will be linked to 5 test procedures provided in “PROCS_R3.C” on the MPX support web pages.  These procedures will be statically compiled and linked to your MPX executable, by adding them to your project.  We need to store the starting address of each function in its associated PCB.  Values for initialization are described in chapter R3 of your project manual

 Insert all 5 PCB’s on the ready queue. We will only need to use the FIFO insertion method.  Link the int 60h interrupt to your system call handler. (accomplished via a call to a new support routine sys_set_vec )  Call your dispatcher to begin execution:

How the processes execute  The names of the test procedures are: test1-R3 through test5-R3.  Each process is designed as a simple loop that prints out a message a set number of times. Test1-R3 prints out the message once… and so forth  Processes once dispatched are not preempted, nor are they subject to timeout.  Each process will voluntarily give up control of the CPU using a call to “sys_req” which will generate a system call interrupt. Processes call “sys_req” with two possible op_code values:  IDLE: which will return the process to the ready queue  EXIT: which is a request to terminate the process, and free the PCB.

Processing system call interrupts  You will need to write an interrupt handler called “sys_call” whose purpose is to catch and process system call interrupts generated by executing processes.  In the declaration of the prototype of this function we will use the TURBO C keyword “interrupt” void interrupt sys_call(void);  The interrupt keyword generates executable assembler language statements which automatically save the registers: AX, BX, CX, DX, ES, DS, SI, DI, & BP On the stack automatically. (in this order). Similarly code is added at the end of the procedure to automatically restore these registers.

 “sys_call” Notes:  Sys_req prepares for the system call interrupt by placing the parameters it was called with onto the “current” stack. It then generates interrupt 60, using the int 60h machine instruction.  When “sys_call” is invoked it is responsible for retrieving these values and interpreting what type of action has been requested.  Additionally, the interrupt hardware pushed the flag register, CS and IP onto the stack.  So when “sys_call” is invoked the status of the stack is:

(previous stack contents) Buffer length pointer parameter (*count) Buffer address parameter (*buffer) Device_id parameter Op_code parameter FlagCSIPAXBXCXDXESDSSIDIBP We will need to retrieve the contents of the 1 st four parameters to identify the type of request made by the calling process. (pseudo code can be found on page 11)

 Depending on the type of request made:  Switch to a temporary stack to avoid stack overflow.  If a request to IDLE has been issued: The current processes status is switched to “ready” and the process is placed back on the ready queue.  If a request to EXIT has been issued: The process is deleted using your function from R2.  A call to your “dispatcher” is issued to begin execution of the next process.  (Note) the dispatcher will not return to this function!

The dispatcher  The dispatcher “dispatch” will be structured as an interrupt handler, but will be invoked via a regular function call.  It is responsible for:  Remove the PCB at the front of the ready queue  Change the process status to running, and set a pointer to this PCB identifying it as the running process.  COPY the stack pointer (_SS and _SP) from the processes PCB to the actual stack pointer, to prepare for context restoration.  When this function “ends” execution will resume in the newly restored process!!!! It will never return to the interrupt handler!

Notes of concern  We do need to save the initial state of the MPX the first time that the dispatcher is called.  There fore we need to declare global variables to store the SS and SP of the MPX. These will be restored when there are no more processes in the ready queue. Restoration of these variables will return control to the COMHAN and we will be able to terminate execution of MPX.

Complete outline for the dispatcher: if sp_save is null, ss_save = _SS sp_save = _SP remove the PCB at the head of the ready queue if a PCB was found set cop to this PCB set _SS and _SP to the PCB's stack pointer else set cop to NULL set _SS to ss_save set _SP to sp_save end if "return from interrupt"