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

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

3. 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.

4. 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

5. 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.

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

7. 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

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

9. 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

10. 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

11. 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.

12. 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

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

14. 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

15. 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

16. 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

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

18. 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.

19. 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.

20. Page table lookup, no faults
Memory
Page table lookup, no faults

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

22. 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.

23. 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.

24. 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.

25. 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

26. 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

27. 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

28. 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

29. Channel Architecture

30. 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.

31. 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

32. 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.

33. 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

34. 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.

35. 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.

36. Java Class Diagram

37. 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.