the operating system and the central processing unit 4 although cs420 is not a hardware course, the...
TRANSCRIPT
The Operating System and the Central Processing Unit
4
Although CS420 is not a hardware course, the OS and the CPU are highly interdependent and indeed must be designed with one another in mind, so you
need to know a little bit about the CPU and interrupts (but only a very little bit, trust me ;-) to help make sense
of much of the OS, which is the actual point of CS420
• The next few slides provide an overview of the operation of a typical (but real) CPU that we’ll cover in detail in CEC470
• For CS420, the purpose of these first few charts is merely:
1. To provide the technical context to allow us to precisely define some vocabulary we’ll need
2. To lay the groundwork for some of the issues that will occupy us later in the course
3. To describe how the operating system software itself actually gets run (not why – what the OS actually does and how – that’s the whole rest of the semester ;-)
• The hardware details here are not germane enough to the theory of operating systems that I’d consider them testable – not for CS420, they sure are for CEC470, though ;-)
• This PowerPoint file is meant to be viewed in slide show mode
• If you’re reading this note, you’re not in slideshow mode ;-)
• Hit function key F5 to change to slide show mode
Overview
• The Interrupt Vector Table (IVT) – where the CPU and the OS meet
• An OS-centric view of life on a CPU, including how it both supports and controls the CPU
• Summary
MSJ-2
• The hardware architecture and instruction execution
• Interrupts and the System Status Register (SSR)
• A complete biography of the CPU in one page of pseudo-code
• A CPU-centric view of life and how it both supports and controls the OS, including deciding when it gets to run
• A CPU-centric view of life and how it both supports and controls the OS, including deciding when it gets to run
the CPU
the OS
IVT
functionalunit
CPU Legend:
special purpose register
data control C
MSJ-3
Architecture of a Simple CPU
ALU
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
generalpurposeregisters add
signextend
IR
B
NPC
A
ALUoutputPC
Imm
cond
datamemory
LMD
ROM
RAM
instruct.memory
4
Functional units are smart little thingies that manipulate data
Memory is not conceptually part of the CPU but you can’t understand the CPU without some understanding how the memory interacts with it
The split of data and instructions into separate (cache) memories as shown here is irrelevant to CS420 but is a common architecture discussed extensively in CS470 – and these slides were originally developed for CS470
Execution of an instruction may require up to five separate steps, each step typically taking a single clock cycle:
1. Instruction fetch2. Instruction decode and register fetch3. Execution or address calculation4. Memory access5. Write back
A functional unit requires control bits to tell it what to do
• The special purpose registers are dumb little store-and-forward thingies that simply mediate the data flow among functional units
• They’re called “special purpose” since, unlike the general purpose registers, software (machine language) cannot manipulate them directly – i.e., software controls how general purpose registers are used to shift, add, subtract, multiply, divide, etc; special purpose registers can’t be used that way
ALU
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
generalpurposeregisters add
signextend
IR
B
NPC
A
ALUoutputPC
Imm
cond
datamemory
LMD
ROM
RAM
instruct.memory
4
Cycle 1: Instruction Fetch
instruction fetch
MSJ-4
+4
c
The CPU hardware “issues” the instruction by sending its address (the contents of the PC) to the instruction memory…
The other stuff that happens during this cycle is irrelevant to CS420
At the start of the instruction fetch cycle, the Program Counter (PC) contains the memory address of the next instruction we want to execute
… which causes the instruction memory to send the contents of that location to the CPU’s Instruction Register (IR), sometimes known as the Instruction Decode Register (IDR)
ALU
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
generalpurposeregisters add
signextend
IR
B
NPC
A
ALUoutputPC
Imm
cond
datamemory
LMD
ROM
RAM
instruct.memory
4
instruction fetch
Cycle 2: Instruction Decode and Register Fetch
instruction fetch
+4
MSJ-5
ccc c cc
instruction decode & register fetch
Lots of other interesting things happen after that; but they’re irrelevant to us here in CS420
At the start of this cycle, the various bit fields of the instruction are extracted, decoded, and sent to the CPU’s functional units to control the rest of the execution of this instruction − e.g., some of the bits of the instruction contain the operations code (opcode), which tells the ALU whether it is to do an addition, subtraction, multiplication, division, left shift, right shift, etc, etc
ALU
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
generalpurposeregisters add
signextend
IR
B
NPC
A
ALUoutputPC
Imm
cond
datamemory
LMD
ROM
RAM
instruct.memory
4
MSJ-6
instruction fetch
Cycle 3: Execution or Address Calculation
c
execution or address calculation
Instruction decode/ register fetch
+4
c
c
c
c
c
• The Arithmetic Logic Unit (ALU) manipulates data − e.g., multiplies or divides − as specified by the opcode bits extracted from the IR
• The ALU does not work directly with data in memory; it only manipulates data from the A and B registers, the
Imm, or the NPC, and its output goes to the ALUoutput register
ALU
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
generalpurposeregisters add
signextend
IR
B
NPC
A
ALUoutputPC
Imm
cond
datamemory
LMD
ROM
RAM
instruct.memory
4
MSJ-7
instruction fetch
Cycle 4: Memory Access
instruction decode & register fetch
execution or address calculation
execution or address calculation memory access
+4
c
c
c
c
Data memory is where all the data used by your program is stored – i.e., all those integers, floating points, characters, etc.
c
ALU
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
MUX
p1
p2
generalpurposeregisters add
signextend
IR
B
NPC
A
ALUoutputPC
Imm
cond
datamemory
LMD
ROM
RAM
instruct.memory
4
Cycle 5: Write Back
instruction decode & register fetch
execution or address calculation
execution or address calculation
memory access
c
c
write back
write back
instruction fetch
+4
c
MSJ-8
c
write back
After its write back, the execution of the current instruction is complete and the PC contains the address of the next instruction we want to execute
During write back, the results of the current instruction’s calculations are written into the appropriate registers:
• The address of the next instruction we want to execute is always written into the PC
• Results from the current instruction can be (and usually are) stored into some general purpose register so that they are available for future instructions to use
• Most of the time, a CPU just executes the instructions from some program one instruction after another
• Sometimes, however, we need to interrupt a program to handle something else right away − e.g., even though some student program is contentedly grinding away in an infinite loop, happily consuming 100% of the CPU time for the next trillion years, we really need to shutdown the nuclear reactor in the next few milliseconds or Los Angeles may disappear
• Interrupts will lead to all sorts of interesting issues for us later in CS420
• To handle them, the OS will need some help from the System Status Register (SSR), part of the CPU’s hardware
So Where and How Do Interrupts Fit Into This Picture?
MSJ-9
• The SSR is just an aggregate name for a miscellaneous bunch of mostly unrelated bits somewhere in the CPU
• The SSR bits provide the OS and the CPU control over certain aspects of each other’s behavior and status data to help them figure out what to do and when to do it
• Some of the bits can be set and cleared by software but not hardware, or hardware but not software, or set by one but cleared by the other, etc; we’ll see examples of these various possibilities here and on the next slide
printer
disk controller
nuclear reactor
interruptRequest
MSJ-10
Overview of a Simplified System Status Register (SSR)
interruptNumber
•••
interruptsEnabled
privilegedMode
powerReady
The powerReady status bit is completely controlled by the power supply Other SSR bits are not
particularly important to us for CS420
••••••
countdownTimer
Often, whatever sets an IRQ must also supply an interruptNumber to identify the specific interrupt so the OS knows exactly what it is being requested to do – like shutdown the reactor, as opposed to telling the operator the printer is out of paper
• An enabled IRQ is what causes the CPU to start the OS running; we’ll see how in a few slides
• In addition to external devices, both user software and the computer’s own internal hardware can also set an IRQ if and when they need to get the attention of the OS
help me
user software
• To do something that it is not allowed to do on its own, unprivileged, or user mode, software simply executes a system service call (SSC)
• An SSC is an unprivileged instruction which merely sets an IRQ to get the attention of the OS, which is privileged code
• Some instructions, e.g, stopCPU, are potentially so disruptive to the efficient operation of the computer system that they are only legal for privileged software (i.e., the OS itself) so the SSR has a privilegedMode bit that lets the CPU know when privileged code is being executed
• If an instruction decoded by the CPU is a privileged instruction but the privilegedMode bit is not set, the CPU will declare an error (which the OS will have to handle)
• Only the CPU hardware itself can turn the privilegedMode bit on (why?) and, as we’ll see on a later slide, it only does so just before it starts the OS running
The interruptsEnabled bit is used by the OS to control the CPU hardware
• Privileged software can set a countdown timer to generate an interrupt
• The countdown timer gets decremented periodically by the CPU hardware
• When the timer reaches 0, an interrupt is generated
• This is how the OS sets a reminder for itself to do something in the future
Depending on the CPU hardware, multiple external devices may be able to set the same IRQ
The setting of an interruptRequest bit (IRQ) is what signals the actual presence of an interrupt request − but unless the interruptsEnabled bit has been previously set by the OS, the CPU ignores the IRQ
• The CPU and other computer hardware (e.g., memory or an I/O controller) can set an IRQ bit, too, as, for example, when the CPU detects an attempt to execute an illegal instruction or do a division by 0, and needs the OS to figure out what to do about the problem
• Note that the use of the term “interrupt” is not totally standard in these cases
• Sometimes “external interrupt” or just “interrupt” is used to refer only to an IRQ being set by external hardware; in which case the term “internal interrupt”, “software interrupt”, or “trap” may be used to refer to something like an SSC or the ALU setting an IRQ
• The end result is the same, however
MSJ-11
while ( ! powerReady );PC = startAddressOfBootProgram;clearInterruptsEnabledBit; setPrivilegedModeBit;while (powerReady) /* Execute an instruction */ if ( ! (IRQ && interruptsEnabled) ) { /* Issue an instruction normally */ instructionFetch(PC); instructionDecodeAndRegisterFetch(); executionOrAddressCalculation(); memoryAccess(); writeBack(); } else /* Prepare for interrupt processing first */ clearInterruptsEnabledBit; setPrivilegedModeBit; interruptedPC = PC; PC = interruptVectorTable[interruptNumber]; }
• Before we do anything else we better save the address of the instruction we were just about to execute before we got interrupted
• Exactly where it’s saved is hardware dependent; but it has to be saved somewhere so the operating system can get to it later to restore control to the program that just got interrupted and let it resume its execution as if nothing had happened
A Complete Biography of the CPU in One Page of Pseudo-code, Including Interrupts
Nothing can happen until the power supply reports that the power is stable by setting the powerReady bit in the SSR
• Although the IRQ bit can be set by external hardware at any time, the CPU hardware itself only checks for interrupts just before it issues a new instruction to start its execution
• But even if the IRQ is set, the interrupt will not be serviced unless the interruptsEnabled bit is also set
• Otherwise, the IRQ will be ignored and the next instruction of the current program will be issued and executed normally (no interrupt)
• So what instruction should the CPU execute next? Why, the first instruction in the appropriate ISR, of course, so the CPU will get the correct ISR’s start address from an OS data structure called the Interrupt Vector Table (IVT) and put it (the ISR’s start address) in the PC, which means it will be the next instruction issued
• We’ll look at this step and the IVT in more detail on the next slide
• Let’s look at the more or less complete (more or less non-fiction ;-) life story of a CPU from power up/reset to power off, handling interrupts along the way
• Although we’ll describe the CPU’s logic here in pseudo-code, since that’s easier to understand than logic diagrams, it is not software
• It is either literally hardwired circuitry or, in some types of CPU implementations, microcode – but that’s not a CS420 concern
• We don’t want to be interrupted before completing most of the boot program
• The boot program itself will eventually figure out when it’s safe to enable interrupts and use a software instruction to do so
Instruction execution itself must be atomic: Once an instruction has been issued to the CPU at the start of the instructionFetch cycle, all 5 cycles must complete without any sort of interruption or there has been an a error or failure of some sort
Once the control and status bits and the PC have been initialized, the entire life of the CPU, from then until the power goes off, consists of looping gazillions of times through the 5 cycles of instruction execution which we saw animated earlier; even the boot program itself is just a perfectly ordinary set of instructions as far as the CPU is concerned
Once the preparation for interrupt processing is complete, the CPU continues on with its boring instruction execution loop, having just set the PC so that the next instruction issued for execution will be the start of the correct ISR
• The boot program is OS code and hence needs to execute in privileged mode
• Only the CPU hardware can set this bit so it must do so here, before it issues the first instruction of the boot program
• The PC is the Program Counter in the CPU that we saw in the earlier animations of instruction execution
• The CPU here is initializing the PC to the start address of the boot program, which is the first set of instructions we want to execute after power-up
• We’ll take a quick look at the boot program on a later slide
• The ISR about to run is OS software so the CPU must turn on the privlegedMode bit for it
• The ISR itself will turn this bit off later
If there is an enabled IRQ present just before the CPU issues an instruction, the CPU won’t issue that instruction but will instead reconfigure a couple of bits in the CPU before issuing the first instruction of the appropriate interrupt service routine (ISR), an OS function whose job is to respond to (service) some particular interrupt, e.g., shut down the reactor
• We don’t want to get interrupted by a second interrupt right at the start of servicing a prior one
• When do interrupts get re-enabled? Why, that’s up to the ISR software, of course, whenever the ISR’s programmer decided it was safe – and we’ll have lots to think about here later in CS420
Roadmap
• A CPU-centric view of life and how it supports the OS
• The Interrupt Vector Table (IVT),where the CPU and the OS meet
• An OS-centric view of life on a CPU, including a clever analogy about how an OS is like Sleeping Beauty and the CPU is Prince Charming
•Summary
MSJ-12
the CPU
the OS
IVT
Let’s take a more detailed look at the last step of the CPU’s interrupt preparation from the last slide:
address of ISR0
address of ISR1
address of ISR2
address of ISR3
address of ISR4
address of ISR5
address of ISR7
address of ISR6
IVT
MSJ-13
The Interrupt Vector Table (IVT)How the CPU Launches an ISR for the Operating System
PC = interruptVectorTable[SSR.interruptNumber];
interruptNumber
• In summary, the IVT is a perfectly ordinary array whose contents are maintained by the OS and used by the CPU hardware to find the address of the correct ISR to start whenever the CPU detects an enabled IRQ
• The IVT is thus at the very heart of the integration of the OS with the CPU
• The OS, like any other piece of software, consists of algorithms and data structures; and you’ve just met its first important data structure
• Note that since the CPU hardware starts an ISR executing in privileged mode, it is important that the IVT be protected from unauthorized modification
• If you could place the address of one of your functions in the IVT, your code, running in privileged mode, could then circumvent or modify the OS itself
• So the OS must store the IVT in memory that user mode programs can’t modify – still usually in RAM, not ROM, however (we’ll discuss that further in a minute)
• Managing memory to provide that protection not only impacts the hardware design but will also lead to major requirements on the OS, which we’ll cover in some detail later in CS420
• The IVT is just a 1-dimensional array whose base address in memory is known to the CPU hardware; perhaps it [the IVT base address] is stored someplace like the SSR by the OS at bootup, perhaps it’s hardwired, but that’s a CPU design issue, not a CS420 one − the important point here is that the hardware must know where the IVT is
• Each entry in the IVT is a pointer to a function*, one for each different interrupt – e.g., one ISR for the printer, one for the nuclear reactor, etc
* Pointers are just addresses, remember; and although you may or may not have covered them in CS125, pointers to functions are legitimate data types in C, so an array of pointers to functions is a perfectly ordinary data structure in C, the language most OS’s are written in. The next slide contains a very short demo program that you can download, compile, and execute, if you like; although we won’t be doing any programming of this sort this semester
• The CPU uses the interrupt number from the SSR as the index (offset) into the IVT, so in this last step of preparing to service an interrupt, the CPU is setting its Program Counter so that the next instruction to be issued will be the start of the correct ISR
• If the interrupt number were 6, for example, the CPU would go to the 6th entry in the IVT to find the starting address for ISR6, perhaps the one that shuts down the nuclear reactor rather than the one to tell the operator the printer is out of paper
#include<stdio.h>void ISR0(void) { printf("\n Hello from ISR0, called as (*IVT[0])() \n"); }
void ISR1(void) { printf("\n Hello from ISR1, called as (*IVT[1])() \n"); }
void ISR2(void) { printf("\n Hello from ISR2, called as (*IVT[2])() \n"); }
main() { void (*IVT[3])(void)= { ISR0, ISR1, ISR2 };
int functionNumber;
for (functionNumber = 0; functionNumber < 3; functionNumber++) (*IVT[functionNumber])();
}
/* Simulated ISR (it needn’t be named ‘ISR’ of course); it’s address in memory will be the entry for IVT[0] in ‘main’ */
/* This one’s address in memory will be the entry for IVT[1] in ‘main’ */
/* This one’s address in memory will be the entry for IVT[2] in ‘main’ */
/* The line, below, declares and initializes what could be a real IVT (it doesn’t have to be named ‘IVT’, of course); it may look strange, but it's legal C and if you think hard about it, its syntax ultimately makes sense */
/* We'll use this integer as the counter in the 'for' loop, below, to call each of the functions defined above */
/* The 'for' loop, below, just demonstrates dereferencing of function pointers in C; although that’s not how the CPU hardware calls an ISR, of course. To actually service an interrupt, the CPU hardware just takes the contents of an IVT entry and stores it in the PC so it is the next instruction issued. As we saw in the hardware pseudocode on the previous two slides, no software is involved in setting the PC that way, the CPU does it “by itself”. The code, below just demonstrates that C code can in fact call a function by dereferencing a (function) pointer to it . */
/* This line picks an array element and dereferences it. Since the compiler knows that the pointer being dereferenced is a function pointer (as opposed to, say, an integer pointer), the compiled code then transfers control to that address, thus calling that function */
Demo Program for Function Pointers
MSJ-14
• A real ISR would never be called like this; it’s started by the CPU hardware, not by other software, as we are doing in this demo program
• But the purpose of this little demo program is just to show you that C really does support function pointers, arrays of function pointers, etc; so here we are calling our functions not by name but by dereferencing pointers to them, each pointer being an element in an array
• Download, compile, and run this program to see that it all works as expected; this loop calls our 3 demo ISR functions one after the other, and they each printout a single line uniquely identifying themselves
• Here we’re declaring an array of 3 function pointers; the name of the array has no particular significance, of course, but since we were talking about the interrupt vector table, lets call this demo array ‘IVT’
• The syntax looks odd, but after a while one gets used to it
• In C, one can’t declare an array containing variables of different types, so all the addresses in an array of function pointers must point to functions that have the same signature – i.e., the same type of returned value, and the same number, type, and order of parameters
• Since an IVT is an array of ISR addresses, this demo array will contain only addresses of functions that have no parameters and return no values; other arrays of function pointers could have other signatures
• An ISR typically doesn’t return a value; there’s no one to return it to, since an ISR isn’t called by another function, which is the normal way a function in a program consisting of multiple functions gets started
• Instead, an ISR is started “automatically” by the CPU hardware to get an enabled interrupt serviced by the OS
• Here we’re initializing our array with the addresses of our 3 demo ISR functions
• Just as an array name [with no square brackets after it] is an address constant equal to the base address of the array, so too just the name of a function (no argument list in parentheses after it) is an address constant for the first instruction of the function, which is exactly what we would want in a real IVT
• I don’t want to spend overly much time on this code in lecture, although we’ll go over it briefly; but you won’t be writing code like this in CS420; I’ve included it just to demonstrate that C does support function pointers and they’re just addresses
• All pointer values in C are just addresses, of course; it’s what they point to (their type, in other words) that tells the compiler how to handle them: de-referencing an integer pointer to the right of an assignment operator (=) produces an integer value; dereferencing a function pointer anywhere produces a transfer of control to some function – which then may or may not eventually return a value, depending on the function
• If you like, you can download this code from the Blackboard site for CS420, and then compile it and run it just for fun; each of the three trivial ISR functions will run and print out its “Hello from ISRi …” message
• Note the difference between the expressions ISR1 and ISR1()
• ISR1 is an address constant
• ISR1() is the value (if any) returned by calling the function at address ISR1 with the arguments (if any) inside the parentheses
• If, for example, for some odd reason, you wanted to see exactly where in memory some function were stored, something like printf(“%d”, ISR1) would do the trick; a function name like ISR1 just being a constant like any other constant
Similarly, an ISR typically doesn’t have parameters. Who would supply the arguments?
• A constant theme for CS420 is going to be that there’s no magic
• With only one exception, below, OS functions these days are usually coded in perfectly ordinary C, although their comprehensibility is clearly affected by
1. The comprehensibility of C syntax itself (not very good, actually)
2. The skill of their programmers
3. The extent to which those programmers considered comprehensibility to be a virtue (or a requirement)
But that’s true of any C code, OS functions are not unique in this regard
• Anyway, the only other “trick” you probably haven’t seen yet in your experience with C is how to insert assembly language code – like, for example, a single instruction such as an SSC – into the middle of a C function; but for CS420, we won’t be doing anything like that; CS420 is an OS theory course, not a C or assembly language programming course; the only reason I put this stuff in here at all is just to buttress my point that there’s no magic; but you won’t be doing any coding like this (i.e., assembly language or arrays of function pointers) in CS420 and none of this code or anything like it will be on any exam
Roadmap
• A CPU-centric view of life, and the hardware it devotes to supporting the OS
•The Interrupt Vector Table – where the CPU and the OS meet
•An OS-centric view of life on a CPU or How the Operating System is like Sleeping Beauty to the CPU’s Prince Charming
MSJ-15
• A one page biography of the life of the OS• The boot program and subsequent initializations• Interrupt servicing• Other important stuff to do after an interrupt
(like all the rest of CS420, in other words)
•Summary
• At this level of abstraction (one page), the OS’s life story looks even simpler than the earlier, one page, pseudo-code description of the CPU’s logic
• Here’s an abridged version of the entire life story of the OS:
1. Boot-up – load the OS into memory
2. Go to sleep and wait for an interrupt to wake up (like Sleeping Beauty waiting for a kiss)
A. Service the interrupt
B. After servicing the interrupt but before returning the CPU to the interrupted code, look around for other interesting things to do
A One Page Biography of the OS
MSJ-16
boot disk
Boot-Up
MSJ-17
• The ROM portion of the boot program is fairly simple-minded; all it does is go out to a predetermined place (the boot sector) on a predetermined disk (the boot disk) and load a predetermined amount of code from there into a predetermined location in RAM
• The newly loaded OS software now in RAM then does the more complicated job of finding the rest of the necessary OS functions on the disk, loading them into memory, and initializing any data structures (like the IVT, for example) that require dynamic initialization
ROM
RAM
instr.memory
datamemory
IVT
• The boot program may seem more complicated than it really is merely because it is often quite time-consuming
• Boot times can be long because, among other reasons, it can take the OS some time to discover what devices are actually connected so it knows what ISR’s to load and have their addresses inserted into the IVT (“Helllloooo, printer, are you there? Say something. I’m waaiiiiting.”)
?
• As we saw during the earlier instruction animation, instructions to be executed must be fetched from memory
• Since high speed RAM is volatile, the contents of RAM are undefined right after power-up; so no portion of the OS can be in RAM until something loads it there from a disk or other non-volatile device
• That “something” is the boot program and at least the first part of it must therefore be stored in some non-volatile (ROM) portion of the instruction memory
• There’s also an optional, not particularly standard, but also not particularly interesting, initialization phase that some OS’s may sometimes allow called sysgen (system generation);
• There are a lot of parameters that a knowledgeable sysadmin can fiddle with to control the behavior of an OS – e.g., maximum number of users allowed to log in concurrently – some of these parameters can be adjusted at any time, others only during boot-up
• Sysgen essentially just involves giving a sysadmin an opportunity to fiddle with any key OS parameters that can’t be adjusted during normal operations but only early during OS boot-up − e.g., for Windows, holding down the F8 key during bootup tells the OS that you want to do some sysgen-like thing before finishing the boot process
Sidebar: Origin of the Phrase “Booting”
• Since the ROM code that starts the load of the (rest of) the OS from disk is itself part of the OS, it apparently seemed to the founding fathers of OS theory that, in its loading of itself, the OS was “lifting itself up by its own bootstraps”
MSJ-18
• That’s not really technically correct, of course; but that little piece of the OS in ROM needs to be called something and “boot program” is both semi-apt and picturesque; it obviously caught on and is hence here to stay, accurate or not
Another Sidebar: The OS and ROM• Why not just put all the OS in ROM and simplify the startup
process? (Be better for security, too; wouldn’t it?)
• So why do you even need to ask that question? Either:
1. You haven’t noticed Microsoft issuing “critical security updates” to Windows about once a week or so for the last 10 years, or
2. You have happily been prying the OS ROMs out of their sockets on your mother board once a week and running down to your local Microsoft dealership for replacements
• Electrically erasable, programmable, read-only memory (EEPROM) solves this problem, but it’s too slow for use as the instruction memory for a high performance OS for general purpose computer systems, although it’s obviously good enough for cell phones and the like
MSJ-19
Anyway, Moving On: Sleeping Beauty and the Life of the OS After the Boot
MSJ-20
OS not running,(user code running) boot ISR
interestingand important
OS stuff
Eventually, there will be an interrupt and Prince Charming (the CPU) will dispatch some ISR, thus awakening the OS to service the interrupt
Sleeping Beauty
• After the boot program finishes loading and initializing all the necessary pieces, the OS becomes a Sleeping Beauty waiting for an interrupt to wake it up, meanwhile letting the CPU be used to run user code
• If there is no “real” user code to run, there is usually a built-in system idle program of some sort – but it presumably runs in user mode, so whether or not it is really part of the OS is probably a pointless question, the sort of thing that theologians or philosophers debate during their idle times
After it’s all done servicing its interrupt, just before it completely terminates, an ISR will often call other OS functions to look around and see if there’s other important OS stuff to do (like everything else this semester in CS420 ;-)
When the important stuff is all done, control returns to the ISR so that it can restore the CPU to the interrupted code
• A modern, general purpose OS is thus often described as being “interrupt driven”
• Even though the really interesting and important stuff we’ll be studying the rest of this semester has nothing to do with servicing interrupts, (which is actually only a small, though important, part of the OS’s job), it nonetheless is just code and it only actually runs after an interrupt
• The OS just takes advantage of the fact that it’s already running to see if there’s other, more important stuff it really ought to do
• An OS runs once at boot-up and then only after an interrupt; that’s it
The very last thing an ISR does is to reset the PC to the address of the instruction that was just about to be issued just prior to the interrupt, thus resuming execution of the interrupted program, which is also known as “restoring” or “returning” the CPU to the interrupted program
But the Sleeping Beauty Metaphor Aside, Interrupt Driven Does Not Mean That the
OS is Purely Passive
MSJ-21
• One of the “interesting and important” things the OS can do is to use a privileged mode instruction to set a countdown timer in the SSR (or someplace equivalent) to generate a future interrupt
• The point being that even though the post-boot OS is interrupt driven, it would be misleading to think of it as merely a slave to the external world
• It can schedule interrupts of its own to ensure that it also runs at times of its own choosing, as well as in response to truly random external events
Roadmap
• A CPU-centric view of life and how it supports the OS
• The Interrupt Vector Table (IVT) – where the CPU and the OS meet
• An OS-centric view of life on a CPU, including a clever analogy about how an OS is like Sleeping Beauty and the CPU is Prince Charming
• Summary
MSJ-22
Summary: The OS and the CPU Are Highly Interdependent
• The CPU is what starts the OS running and sets up SSR bits so that the OS starts properly – e.g., in privileged mode
• The OS sets bits in the SSR that control how the CPU works (e.g., will it accept interrupts) and sets up the IVT so that the CPU starts the right ISR whenever an interrupt needs to be serviced
• The OS can use a countdown timer in the CPU to schedule itself for whenever it calculates it needs to run, as well as running whenever something else needs it to run
• Other than after power-up, the CPU only runs the OS in response to interrupts/traps, which can be generated:
1. By hardware events both internal and external to the CPU
2. By user mode software whenever it needs OS services
MSJ-23
Summary (cont’d)
MSJ-24
Often, most of the OS processing that actually takes place after an interrupt really has nothing to do with servicing the interrupt; the OS just uses the fact that it’s already running to look around and see if there’s something else important it ought to do, like all the stuff we’ll be discussing for the rest of a semester of CS420