Introduction

An operating system is just a program that manages your hardware, dividing up the resources of your computer fairly and reasonably among the multiple programs that you want to run. We will be building a simulator of an operating system $$ a program that does most of what an operating system does but running in the JVM instead of directly on the hardware.

The problem that we are trying to solve is that we have more than one program that we want to run, but only one CPU. We want all programs to make some forward progress over some reasonable period of time; we don$$t want one single program to run, and no others get any run time. We want some level of fairness. To get that fairness, each program will get some amount of run time $($called a quantum$).$ After that run time is over, another program will get a turn.

Refresher on hardware

A CPU fetches instructions from memory, decodes them $($including getting data from registers$),$ executes the instructions, then stores the results back to registers in an $($almost$)$ infinite loop. What stops the loop? Interrupts. An interrupt is a signal, generated by an instruction $($a soft interrupt$)$ or by outside hardware $($a hard interrupt$).$

CPUs have two $($or more$)$ modes $$ normal mode and privileged mode. Every program runs in normal mode except the operating system. The operating system runs in $$privileged$$ or $$ring $0.$ This mode allows the operating system to bypass all of the security features of the CPU and access anything that it wants. In normal mode, the CPU cannot access devices or memory unless privileged mode has previously granted access to them.

The switching of modes happens by interrupts. When an interrupt $($hard or soft$)$ occurs, the CPU stops the fetch$-$decode$-$execute$-$store cycle and transitions to privileged mode where it restarts the cycle, but with the program counter pointing to a piece of code called an interrupt handler. Typically, when the interrupt is handled $($and that varies depending on the kind of interrupt$),$ the interrupt handler code switches the CPU back to normal mode.

One final piece of hardware is the hardware timer. This is a separate chip $($usually$)$ that can be given a duration. When that duration has elapsed, it signals the CPU with a hard interrupt.

Task Switching

When the computer boots, there is no concept of task$-$switching; that is an operating system idea. The computer starts and reads the operating system from disk. The operating system does some hardware configuration $($things like finding out what disks exist, how much memory do you have$).$ It then picks the first program to run, sets the hardware timer to expire in a time period $($called a quantum$),$ then switches to user mode and the userland program runs.

Eventually the quantum elapses, the timer causes an interrupt and the processor switches to privilege mode. The timer interrupt handler calls the operating system$$s task switch which determines the next program to run. It then resets the hardware timer and starts the program running.

Cooperative Multitasking

Java doesn$$t really expect people to start and stop threads like operating systems do$.$ Most people start a thread and let it run, because they have work that they want done and the thread does the work. We won$$t be implementing pre$-$emptive multitasking. We will be implementing cooperative multitasking. The difference? Each user land program runs until it calls a function $$cooperate$()$ that gives the operating system a chance to switch the thread out for something else. This is not ideal, but some operating systems in the past did use this $($original MacOS, for example$).$

Calling the Operating System

When a user program needs to call the operating system $($which$,$ of course, needs to run in privilege mode$),$ it can$$t just call it like it would a function; that wouldn$$t switch processor modes. That transition happens though a soft interrupt. Remember that this is just an instruction $($like LOAD, STORE or ADD$)$ except that it causes the CPU to switch to privilege mode. Typically, the user program will store an id in a pre$-$defined register and then use the INTERRUPT instruction. The interrupt handler will look at that register and call some operating system function. Other registers will hold parameters to the OS function.

Our Software Architecture

We will have two different areas $$ I call them $$kerneland$$ and $$userland$.$ Kerneland is the privileged area and userland is where our traditional programs are run. There is a bridge between them. Every publicly accessible function in kerneland a bridge function in a class called $$OS$.$

In terms of organizing our code, we will have an OS class and a Kernel class. The OS class, for our simulator, will call the Kernel class. Our userland programs may not call the Kernel class or any other class that resides in kerneland except by calling a function in OS that does the work for them; this simulates the soft interrupt approach that happens in CPUs. The Kernel class, for some of the simple example