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 The next few slides provide an overview of the operation of a typical (but real) CPU that well 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 well 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 – thats the whole rest of the semester ;-) The hardware details here are not germane enough to the theory of operating systems that Id consider them testable – not for CS420, they sure are for CEC470, though ;-) The next few slides provide an overview of the operation of a typical (but real) CPU that well 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 well 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 – thats the whole rest of the semester ;-) The hardware details here are not germane enough to the theory of operating systems that Id 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 youre reading this note, youre 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 cant 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 Theyre 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 cant be used that way The special purpose registers are dumb little store-and-forward thingies that simply mediate the data flow among functional units Theyre 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 cant 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 CPUs 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 theyre 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 CPUs 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 A and B registers, the I mm, or the NPC, and its output goes to the ALU output register 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 I mm, or the NPC, and its output goes to the ALU output register

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 instructions 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 instructions 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 CPUs 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 others 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; well 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; well see how in a few slides In addition to external devices, both user software and the computers 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; well see how in a few slides In addition to external devices, both user software and the computers 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 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 well 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 well 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 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 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

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 its 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 its 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 ISRs start address from an OS data structure called the Interrupt Vector Table (IVT) and put it (the ISRs start address) in the PC, which means it will be the next instruction issued Well 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 ISRs start address from an OS data structure called the Interrupt Vector Table (IVT) and put it (the ISRs start address) in the PC, which means it will be the next instruction issued Well look at this step and the IVT in more detail on the next slide Lets 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 well describe the CPUs logic here in pseudo-code, since thats 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 thats not a CS420 concern Lets 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 well describe the CPUs logic here in pseudo-code, since thats 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 thats not a CS420 concern We dont want to be interrupted before completing most of the boot program The boot program itself will eventually figure out when its safe to enable interrupts and use a software instruction to do so We dont want to be interrupted before completing most of the boot program The boot program itself will eventually figure out when its 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 Well 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 Well 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 wont 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 dont want to get interrupted by a second interrupt right at the start of servicing a prior one When do interrupts get re-enabled? Why, thats up to the ISR software, of course, whenever the ISRs programmer decided it was safe – and well have lots to think about here later in CS420 We dont want to get interrupted by a second interrupt right at the start of servicing a prior one When do interrupts get re-enabled? Why, thats up to the ISR software, of course, whenever the ISRs programmer decided it was safe – and well 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 the CPU the OS IVT

13. Lets take a more detailed look at the last step of the CPUs 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 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 youve just met its first important data structure 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 youve 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 cant modify – still usually in RAM, not ROM, however (well 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 well 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 cant modify – still usually in RAM, not ROM, however (well 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 well 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 its hardwired, but thats 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 OSs are written in. The next slide contains a very short demo program that you can download, compile, and execute, if you like; although we wont 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 neednt be named ISR of course); its address in memory will be the entry for IVT[0] in main */ /* This ones address in memory will be the entry for IVT[1] in main */ /* This ones 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 doesnt 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 thats 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; its 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; its 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 were 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 cant 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 were 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 cant 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 doesnt return a value; theres no one to return it to, since an ISR isnt 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 doesnt return a value; theres no one to return it to, since an ISR isnt 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 were 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 were 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 dont want to spend overly much time on this code in lecture, although well go over it briefly; but you wont be writing code like this in CS420; Ive included it just to demonstrate that C does support function pointers and theyre just addresses All pointer values in C are just addresses, of course; its 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 dont want to spend overly much time on this code in lecture, although well go over it briefly; but you wont be writing code like this in CS420; Ive included it just to demonstrate that C does support function pointers and theyre just addresses All pointer values in C are just addresses, of course; its 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 doesnt have parameters. Who would supply the arguments? A constant theme for CS420 is going to be that theres 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 thats true of any C code, OS functions are not unique in this regard Anyway, the only other trick you probably havent 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 wont 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 theres no magic; but you wont 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 theres 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 thats true of any C code, OS functions are not unique in this regard Anyway, the only other trick you probably havent 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 wont 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 theres no magic; but you wont 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 CPUs Prince CharmingAn OS-centric view of life on a CPU or How the Operating System is like Sleeping Beauty to the CPUs 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 OSs life story looks even simpler than the earlier, one page, pseudo-code description of the CPUs logic Heres 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 ISRs to load and have their addresses inserted into the IVT (Helllloooo, printer, are you there? Say something. Im 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 ISRs to load and have their addresses inserted into the IVT (Helllloooo, printer, are you there? Say something. Im 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 Theres also an optional, not particularly standard, but also not particularly interesting, initialization phase that some OSs 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 cant 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 Theres also an optional, not particularly standard, but also not particularly interesting, initialization phase that some OSs 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 cant 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 Thats 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; wouldnt it?) So why do you even need to ask that question? Either: 1.You havent 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 its too slow for use as the instruction memory for a high performance OS for general purpose computer systems, although its 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, the sort of thing that theologians or philosophers debate during their idle times After its all done servicing its interrupt, just before it completely terminates, an ISR will often call other OS functions to look around and see if theres 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 well 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 OSs job), it nonetheless is just code and it only actually runs after an interrupt The OS just takes advantage of the fact that its already running to see if theres other, more important stuff it really ought to do An OS runs once at boot-up and then only after an interrupt; thats 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 (contd) 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 its already running to look around and see if theres something else important it ought to do, like all the stuff well be discussing for the rest of a semester of CS420