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

2. 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 executionThe hardware architecture and instruction execution Interrupts and the System Status Register (SSR)Interrupts and the System Status Register (SSR) A complete biography of the CPU in one page of pseudo-codeA 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 runA 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

3. functional unit CPU Legend: datacontrol C MSJ-3 Architecture of a Simple CPUArchitecture of a Simple CPU ALU MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 general purpose registers add sign extend data memory 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 fetch 2.Instruction decode and register fetch 3.Execution or address calculation 4.Memory access 5.Write back Execution of an instruction may require up to five separate steps, each step typically taking a single clock cycle: 1.Instruction fetch 2.Instruction decode and register fetch 3.Execution or address calculation 4.Memory access 5.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 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

4. ALU MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 general purpose registers add sign extend data memory 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)

5. ALU MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 general purpose registers add sign extend data memory ROM RAM instruct. memory 4 instruction fetch Cycle 2: Instruction Decode and Register Fetch instruction fetch +4 MSJ-5 cccccc 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

6. ALU MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 general purpose registers add sign extend data memory ROM RAM instruct. memory 4 MSJ-6 instruction fetch Cycle 3: Execution or Address Calculationc 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 general purpose registers, the I mm, or the NPC 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 general purpose registers, the I mm, or the NPC

7. ALU MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 general purpose registers add sign extend data memory ROM RAM instruct. memory 4 MSJ-7 instruction fetch Cycle 4: Memory Access instruction decode & register fetch 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

8. ALU MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 MUXMUX p1 p2 general purpose registers add sign extend data memory ROM RAM instruct. memory 4 Cycle 5: Write Back instruction decode & register fetch execution or address calculation memory access c c 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 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

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

10. 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 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 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 it Note that the use of the term “interrupt” is not totally standard in these cases Sometimes “interrupt” or “external 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 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 it Note that the use of the term “interrupt” is not totally standard in these cases Sometimes “interrupt” or “external 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 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 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 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 The setting of an interruptRequest bit (IRQ) is what signals the actual presence of an interrupt request − but the CPU ignores the IRQ unless the interruptsEnabled bit has been previously set by the OS 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 the CPU ignores the IRQ unless the interruptsEnabled bit has been previously set by the OS Depending on the CPU hardware, multiple external devices may be able to set the same IRQ 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 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

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

12. Roadmap A CPU-centric view of life and how it supports the OS The Interrupt Vector Table (IVT) – where the CPU and the OS meetThe 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

13. Let’s take a more detailed look at the last step of the CPU’s interrupt preparation from the last slide: address of ISR 0 address of ISR 1 address of ISR 2 address of ISR 3 address of ISR 4 address of ISR 5 address of ISR 7 address of ISR 6 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 an 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 In summary, the IVT is an 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 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’s 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) 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 6 th entry in the IVT to find the starting address for ISR 6, perhaps the one that shuts down the nuclear reactor rather than the one to tell the operator the printer is out of paper 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 6 th entry in the IVT to find the starting address for ISR 6, perhaps the one that shuts down the nuclear reactor rather than the one to tell the operator the printer is out of paper

14. #include 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 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 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 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 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 ISR i …” message 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 ISR i …” 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 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 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

15. 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 CharmingAn 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 OSA one page biography of the life of the OS The boot program and subsequent initializationsThe boot program and subsequent initializations Interrupt servicingInterrupt servicing Other important stuff to do after an interrupt (like all the rest of CS420, in other words)Other important stuff to do after an interrupt (like all the rest of CS420, in other words) Summary

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

17. 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 data memory 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.”) 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 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

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

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

20. Anyway, Moving On: Sleeping Beauty and the Life of the OS After the Boot MSJ-20 OS not running, (user code running) boot ISR interesting and 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 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

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

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

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

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