1. OPERATING SYSTEMS Goals of the course Definitions of operating systems Operating system goals What is not an operating system Computer architecture O/S services Goals of the course Definitions of operating systems Operating system goals What is not an operating system Computer architecture O/S services This lecture will cover:

2. This Lecture will also cover: O/S resource management O/S achievement history Hardware architecture Processes Interrupts O/S resource management O/S achievement history Hardware architecture Processes Interrupts

3. Goals of the Course This course is to provide a combined applied/ theoretical background in Operating Systems and Systems Programming to improve students’ understanding: 1. Systems software design 2. Systems programming 3. Performance analysis 4. Performance tuning This course is to provide a combined applied/ theoretical background in Operating Systems and Systems Programming to improve students’ understanding: 1. Systems software design 2. Systems programming 3. Performance analysis 4. Performance tuning

4. Some Prerequisites The Study of Operating Systems Relies on Many Areas: 1.Mathematics (a) Discrete Mathematics (b) Basic Calculus (c)Probability (Exponential Distribution, Poisson Processes) The Study of Operating Systems Relies on Many Areas: 1.Mathematics (a) Discrete Mathematics (b) Basic Calculus (c)Probability (Exponential Distribution, Poisson Processes)

5. 2. Computer Science (a) Computer Architecture (b)Programming Language Design (c)Software Design (d)Data Structures/ Algorithms Don’t Panic if you are not familiar with all the topics, but it is best to be exposed to most of them. 2. Computer Science (a) Computer Architecture (b)Programming Language Design (c)Software Design (d)Data Structures/ Algorithms Don’t Panic if you are not familiar with all the topics, but it is best to be exposed to most of them. Other Prerequisites

6. Operating System Definitions Operating System - a program that acts as an intermediary between a user of a computer and the computer hardware. Resource Allocator - manages and allocates resources. Control Program - controls the execution of user programs and operation of I/O devices. Kernel - the one program running at all times (all else being application programs). Operating System - a program that acts as an intermediary between a user of a computer and the computer hardware. Resource Allocator - manages and allocates resources. Control Program - controls the execution of user programs and operation of I/O devices. Kernel - the one program running at all times (all else being application programs).

7. O/S Design Goals An Operating System (O/S for short) provides the following: 1. A run time programming interface for applications. 2. Resource management. An Operating System (O/S for short) provides the following: 1. A run time programming interface for applications. 2. Resource management.

8. O/S Design goals include: 1. Convenience - Reduce Complexity for programmers/ users. 2. Efficiency - Allow “efficient” access to system resources. 3. Flexibility - Adding new features should be easy. O/S Design goals include: 1. Convenience - Reduce Complexity for programmers/ users. 2. Efficiency - Allow “efficient” access to system resources. 3. Flexibility - Adding new features should be easy.

9. What is not an O/S 1. Programming Language Compilers - Translators 2. Interpreter - Shell/ User Interface 3. Library - A set of commands/ utilities These features are typically provided as part of the O/S but are strictly speaking not the O/S. 1. Programming Language Compilers - Translators 2. Interpreter - Shell/ User Interface 3. Library - A set of commands/ utilities These features are typically provided as part of the O/S but are strictly speaking not the O/S.

10. Computer Architecture The following layers of abstraction are used (from highest to lowest): 1. Applications Software - Custom programs to support users. 2. Systems Software - Controls the hardware. 3. Hardware - The physical control of the system (signals). The following layers of abstraction are used (from highest to lowest): 1. Applications Software - Custom programs to support users. 2. Systems Software - Controls the hardware. 3. Hardware - The physical control of the system (signals).

11. Application Software Systems Software Hardware Figure 1: Computer Systems Architecture

12. O/S Services Some O/S services for users are: 1. Program execution - Read program into memory/ run it return control when done. 2. Peripheral Access - I/O device driver interface. 3. Persistent Object Management- File system structure. 4. Security - File System, Network. Some O/S services for users are: 1. Program execution - Read program into memory/ run it return control when done. 2. Peripheral Access - I/O device driver interface. 3. Persistent Object Management- File system structure. 4. Security - File System, Network.

13. 5. Error Detection/ Handling - Hardware failure, program errors. 6. Program Creation Tools - Debugging/ text editing etc. 7. Accounting - Billing for computer access 5. Error Detection/ Handling - Hardware failure, program errors. 6. Program Creation Tools - Debugging/ text editing etc. 7. Accounting - Billing for computer access Other O/S Services

14. O/S Resource Management O/S controls are intrusive because they both consume the resources which they seek to control and mediate conflicting requests.

15. Resource Attributes Resources have properties governing their use including: 1. Preemption - How expensive is it for the device/ resource? 2. Renewability - Does the resource get replenished? 3. Scheduling - Does order of allocation matter? 4. Persistence - Does it’s lifetime extend beyond that of the process which creates it? 5. Sharing - Is it suited to be accessed by many users? Resources have properties governing their use including: 1. Preemption - How expensive is it for the device/ resource? 2. Renewability - Does the resource get replenished? 3. Scheduling - Does order of allocation matter? 4. Persistence - Does it’s lifetime extend beyond that of the process which creates it? 5. Sharing - Is it suited to be accessed by many users?

16. Scheduling/ Allocation Policy The scheduled allocation of resources reflects policies including: 1. Fairness 2. Starvation Freedom 3. Maximum Throughput 4. Maximum Utilization 5. Minimize Response time. The scheduled allocation of resources reflects policies including: 1. Fairness 2. Starvation Freedom 3. Maximum Throughput 4. Maximum Utilization 5. Minimize Response time.

17. O/S Achievements Denning's list of conceptual breakthroughs (1980): Processes --- A program in execution Memory Management Information protection and security Scheduling and resource management System Structure Denning's list of conceptual breakthroughs (1980): Processes --- A program in execution Memory Management Information protection and security Scheduling and resource management System Structure

18. A Traditional Hardware Architecture The traditional von Neumann structure consists of: 1) Processor - Also called the CPU (Central Processing Unit) our example has the registers: PC --- Program Counter IR --- Instruction Register MAR --- Memory Address Register MBR --- Memory Buffer Register I/O AR --- I/O Address Register I/O BR --- I/O Buffer Register The traditional von Neumann structure consists of: 1) Processor - Also called the CPU (Central Processing Unit) our example has the registers: PC --- Program Counter IR --- Instruction Register MAR --- Memory Address Register MBR --- Memory Buffer Register I/O AR --- I/O Address Register I/O BR --- I/O Buffer Register

19. 2) Memory --- (Volatile) 3) Peripherals --- I/O Devices 4) Systems Interconnection --- Links the Other Components (Bus) 2) Memory --- (Volatile) 3) Peripherals --- I/O Devices 4) Systems Interconnection --- Links the Other Components (Bus) A Traditional Hardware Architecture (Continued)

20. Figure 2: von Neumann Architecture Figure 2: von Neumann Architecture

21. The register structure comes from Stallings; the names mean: 1) PC --- Program Counter --- Address of next instruction 2) IR --- Instruction Register --- Current OpCode to execute 3) MAR --- Memory Address Register --- Memory Pointer 4) MBR --- Memory Buffer Register --- Buffer for memory access 5) I/O AR --- I/O Address Register --- I/O Pointer 6) I/O BR --- I/O Buffer Register --- Buffer for I/O access User registers are not shown here. The register structure comes from Stallings; the names mean: 1) PC --- Program Counter --- Address of next instruction 2) IR --- Instruction Register --- Current OpCode to execute 3) MAR --- Memory Address Register --- Memory Pointer 4) MBR --- Memory Buffer Register --- Buffer for memory access 5) I/O AR --- I/O Address Register --- I/O Pointer 6) I/O BR --- I/O Buffer Register --- Buffer for I/O access User registers are not shown here.

22. Process Context The context of a process consists of: 1) The Current Instruction Pointer (the IP) 2) Register Contents 3) Memory used by that process This is the machine's current state used to determine the machines next state when running a particular program. The context of a process consists of: 1) The Current Instruction Pointer (the IP) 2) Register Contents 3) Memory used by that process This is the machine's current state used to determine the machines next state when running a particular program.

23. The Model of Execution Traditionally called the fetch/ execute cycle, in its simplest form: (figure 3)

24. Time- Sharing Systems- Interactive Computing The CPU is multiplexed among several jobs that are kept in memory and on disk (the CPU is allocated to a job only if the job is in memory). A job is swapped in and out of memory to the disk. On-line communication between the user and the system is provided; when the operating system finishes the execution of one command, it seeks the next “control statement” not from a card reader, but rather from the user’s keyboard. On line file system must be available for users to access data and code. Time- Sharing Systems- Interactive Computing The CPU is multiplexed among several jobs that are kept in memory and on disk (the CPU is allocated to a job only if the job is in memory). A job is swapped in and out of memory to the disk. On-line communication between the user and the system is provided; when the operating system finishes the execution of one command, it seeks the next “control statement” not from a card reader, but rather from the user’s keyboard. On line file system must be available for users to access data and code.

25. Motivation for Interrupts An interrupt is an external asynchronous event changing the flow of control of a process (my definition). It is also refers to triggering such an event. 14.1 - The Problem Peripherals tend to have slow response time (especially if waiting on human supplied input). Motivation for Interrupts An interrupt is an external asynchronous event changing the flow of control of a process (my definition). It is also refers to triggering such an event. 14.1 - The Problem Peripherals tend to have slow response time (especially if waiting on human supplied input).

26. The Solution To improve CPU utilization we want to allow the CPU to continue to execute while awaiting I/O as seen in Figure. When an interrupt is detected an interrupt handling routine is typically invoked. There are times (such as interrupt processing) where it may be desirable to disallow further interrupts. The Solution To improve CPU utilization we want to allow the CPU to continue to execute while awaiting I/O as seen in Figure. When an interrupt is detected an interrupt handling routine is typically invoked. There are times (such as interrupt processing) where it may be desirable to disallow further interrupts.

27. Interrupting the Fetch/Execute Cycle The fetch/ execute cycle is adjusted to support interrupts. (figure 4) The fetch/ execute cycle is adjusted to support interrupts. (figure 4)

28. Interrupt Processing Processing an interrupt on most architectures involves the following steps: 1. Finish the current instruction 2. Push the IP on the stack 3. Set the IP to the interrupt handler's address. 4. Preserve the process context (i.e. push registers). 5. Executing the interrupt handling routine. 6. Restore the process context (i.e. pop registers). 7. Pop the IP from the stack Interrupt Processing Processing an interrupt on most architectures involves the following steps: 1. Finish the current instruction 2. Push the IP on the stack 3. Set the IP to the interrupt handler's address. 4. Preserve the process context (i.e. push registers). 5. Executing the interrupt handling routine. 6. Restore the process context (i.e. pop registers). 7. Pop the IP from the stack