EmuOS Phase 3 Design Brendon Drew Will Mosley Anna Clayton November 10, 2011

Overview EmuOS – An emulated operating system with the following features: Multiprogramming Primary and Secondary Memory Virtual Memory IO Spooling Paging Swapping Interrupts

Basic Operation Input file → Processing → Output file Input file contains Control Cards, Instruction Cards, and Data Cards Output file contains Header Lines and Output Lines Program order not maintained.

Basic Operation Each user program has: 3 Control Cards $AMJ contains program id, max time, max lines $DTA defines boundary between instruction cards and data cards $EOJ marks the end of a user program 1 or more Instruction Cards 0 or more Data Cards

Basic Operation User programs may use seven operations LR (Load register): Load memory location to R register. SR (Store register): Store R register to memory location. CR (Compare register): Compare target address with register R and place results in register C. BT (Branch on true): If the toggle C contains true from the most recent CR instruction to be executed, then control of the program will branch to the address indicated. GD (Get data): Read a page of data from the input file. PD (Put Data): Writes a page of data to the output file. H (Halt): Stops the user program.

Requirements Implement a virtual machine for: Virtual Memory Process Management Memory Management Implement emulated hardware to perform: Spooling and buffering Process execution Interrupt handling

Kernel Flow Transition between slave mode Master mode Interrupt Handling (No longer using Java Exceptions to model interrupts) Start channels for spooling/buffering Hardware simulation

CPU An emulated CPU processes the instructions for EmuOS Fetch Increment Execute Registers: IC, R, C, PTR, PTL

Hardware Simulation Increment total time count Raise time interrupt (TI = 2) Increment time slice count Raise time interrupt (TI = 1) Channels 1 - 3 Increment channel counter Raise IOI interrupt

Interrupts Service Interrupt Program Interrupt Time Interrupt Handle system service requests Program Interrupt Handle program errors and page faults Time Interrupt Enforces time slices and process total time limit Input Output Interrupt Services tasks dispatched to and returned from channels

System interrupt handler Check for … Time interrupt Program interrupt Service interrupt IO Interrupt Call handlers for raised interrupts If there are no interrupts, nothing is done.

Service interrupt handler Services the GD PD and H halt instructions PCB status updated PCB moved to IO queue for GD and PD PCB moved to terminate queue for H

Program interrupt handler Operand error Invalid address Operand not a number Operation error Invalid instruction Page fault Validate page fault Swapping

Time interrupt handler Total time limit expired PCB moved to terminate queue Termination status set Time slice expired PCB moved to end of ready queue Context switch

IO interrupt handler Channel evaluation order is 2,3,1 Channel 2 handler Manage empty buffer queue and output-full buffer queue Channel 3 handler Task evaluation order is output spooling, GD and PD, swapping and Input spooling Channel 1 handler Manage empty buffer queue and input-full buffer queue

Processes EmuOS allocates one process per user program submitted to the system. Each process is represented in EmuOS by a Process Control Block (PCB). PCB encapsulates all data relevant to running a process Max lines, max time Current lines, current time Register contents Location of data on drum

Memory EmuOS maintains 4 types of memory OS Memory (buffers) Virtual Memory (what the user programs are aware of): 10 40-byte pages. 100 addressable 4- byte words, 00 through 99 Real Memory: 30 40-byte frames. Pure demand paging. Secondary Memory (drum): 100 40-byte tracks. Used for spooling/buffering.

Memory EmuOS handles the mapping of virtual memory to real memory by implementing pure demand paging. A page table is allocated for each running process in which each page of currently in-use virtual memory is mapped to the frame that that particular page is loaded in. The page table location (frame number) is stored in the CPU in the PTR register. The length of the page table is stored in the CPU in the PTL register. When a process has finished spooling, a page table is created for it but no instruction cards are loaded in memory. Execution begins at this point, and the first action is to load the first instruction card in to memory. When the next instruction card is referenced, it will generate a page fault and at that point the page will be loaded in real memory.

Memory Each page table entry contains 4 bytes: Dirty bit: 1st byte is 1 if the page has been modified since being loaded in to real memory. 0 if the page in real memory matches the version in secondary memory. Swap bit: 2nd byte is 1 if the page has been loaded in to real memory but is currently swapped out to secondary memory. Frame/Track Number: 3rd and 4th bytes contain the frame number where the page is mapped if the page is in real memory. These bytes contain the track number where the page is swapped if the page has been swapped to secondary memory. These bytes contain spaces if the page has not yet been loaded to real memory.

Page table lookup, no faults Memory Page table lookup, no faults

Page table lookup resulting in page fault Memory Page table lookup resulting in page fault

Memory When a user program references a page in virtual memory and that page is found to not have a frame backing it, then a page fault has occurred. A page fault can be valid or invalid. Any command that references memory can result in a page fault if the address referenced is not in real memory.

Memory GD: A page fault encountered on a GD instruction is always valid. PD: A page fault encountered on a PD instruction is valid if either the page is in real memory or the swap bit for that page is on. SR: A page fault encountered on an SR instruction is always valid. LR: A page fault encountered on an LR instruction is valid if either the page is in real memory or the swap bit for that page is on. BT: A page fault encountered on a BT instruction is valid if the address it references points to an instruction page (even if that instruction card has not yet been loaded in memory) but is invalid if the address it references points to a data page. The number of instruction cards is stored in the PCB so if the page number portion of the target address is greater than the number of pages of instructions in the program then the page fault is invalid. CR: A page fault encountered on a CR instruction is valid if the target page is in real memory or the swap bit for that page is on. H: This instruction does not reference a memory address and cannot result in a page fault.

Memory If a valid page fault occurs: If a valid page fault occurs, then a frame is obtained to store the referenced page of virtual memory. EmuOS requests that a free frame be allocated, clears the frame of any residual data from a previous process, and enters the frame number in the page table. When EmuOS is done processing the page fault it decrements the IC counter which causes the instruction that caused the page fault to be restarted. A page fault takes only one cycle. If an invalid page fault occurs: Program is abended and terminated.

Memory Page replacement/swapping EmuOS allocates up to four frames per process 1 for page table At least 1 for instructions If a page fault occurs and all four frames are allocated, swapping occurs LRU (least recently used) algorithm is used PCB maintains LRU frame list

Spooling Spooling is performed by passing buffers between different Channels. Input Spooling Channel1: empty buffer → read data from card reader → input-full buffer Channel3: input-full buffer → write to drum → empty buffer Output Spooling Channel3: empty buffer → read from memory → output-full buffer Channel2: output-full buffer → write buffer to printer → empty buffer

Channel and Buffers EmuOS implements IO spooling using 3 channel types: Channel 1 - The interface between the input file (card reader) and OS memory (buffers). Channel 2 -Channel 2 is the interface between OS memory and the output file (printer). Channel 3 - Channel 3 is the interface between physical memory and secondary memory (drum). Used in: Input/Output Spooling GD and PD instructions Swapping

Buffer Implementation When EmuOS is initialized, a List containing all empty buffers will be created. Buffer references will pe passed between the different channels, changing the state as we go. Single data structure to contain and access all buffers. Example: the first empty buffer in this structure is said to be at the “head” of the empty buffer queue

Channel Architecture

Channel Implementation Each channel implementation will inherit from an abstract Channel class which contains the following methods: isBusy() - Check for busy channel. increment() - Increments the channel time clock. start(ChannelTask task) – starts the channel And requires the following methods to be implemented: run() - Runs the specific channel operation when it is time. ChannelTask “helper class” will encapsulate all information specific to the current task assigned to the channel.

Channel Implementation A constructor that requires a BufferedReader A private method called read() to read a block from the input file into the given buffer. Returns input-full buffer to the ifq. Channel2 A private method called write() to write the contents of the given buffer to the output file. Returns empty buffer to the ebq. Channel 3 A constructor that requires a Drum, RAM and ChannelTask reference. Private methods to perform each task

Multiprogramming EmuOS implements multiprogramming in phase 3. It does this by maintaining queues of PCBs to keep track of which state each process is in and when it should be allowed to run on the CPU.

Multiprogramming Process can be in one of seven states: New Ready Executing Swap IO Memory Terminated Process can be on one of five queues: Ready IO Swap Memory Terminate

Multiprogramming The process at the head of the ready queue is allowed to execute until it has reached its time quantum. The time quantum for EmuOS is ten cycles. If the currently running process reaches ten cycles without being moved to the swap, memory, IO, or terminate queue, then a TI=2 interrupt is raised When TI=2 interrupt is handled the process is moved from the head of the ready queue to the tail of the ready queue. EmuOS implements round-robin scheduling. No processes have priority over other processes.

Java implementation highlights Hardware is represented by "plain old" Java objects As programs are executed we manipulate the state of these simple data structures. Allows new features to be added easily. Enum types used for interrupt modeling. BufferedReader and BufferedWriter objects emulate I/O.

Java Class Diagram

Multiprogramming When the process at the head of the ready queue moves to another queue, a context switch must occur. When a context switch occurs, all information needed to resume execution of the process at a later cycle is stored in the PCB. This information, which is stored in the CPU registers, is copied to the PCB. The second step of context switch is to copy the same information from the PCB that is next on the ready queue to the CPU registers so that the next process can begin (or resume) execution. Context switch does not consume any CPU cycles.