Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 (Review of Prerequisite Material). Processes are an abstraction of the operation of computers. So, to understand operating systems, one must have a.

Similar presentations


Presentation on theme: "1 (Review of Prerequisite Material). Processes are an abstraction of the operation of computers. So, to understand operating systems, one must have a."— Presentation transcript:

1 1 (Review of Prerequisite Material)

2 Processes are an abstraction of the operation of computers. So, to understand operating systems, one must have a basic knowledge about how computer hardware is organized. The von Neumann architecture forms the basis for most contemporary computer systems. 2

3  Babbage designed Difference Engine ( ), later called Analytical Engine, using notion of stored program computer (but with mechanical, not electronic, parts)  Used idea from Jacquard loom to store computational patterns  Ideas he developed were reinvented, extended, and implemented by Zuse (1936), Atanasoff (1940), Bell labs (1945), Aiken and Hopper (1946), and others in 1930’s and 1940’s 3

4 4 Fixed Electronic Device Pattern Variable Program Stored Program Device Jacquard Loom

5  First true computer which used the concept of stored program was EDVAC (Electronic Digital Variable Automatic Computer), designed in 1945 (but not completed until 1951)  While the concept of the stored program computer is often attributed to von Neumann (this architecture is known as the von Neumann architecture), it was not totally due to him – his support did increase government and academic support 5

6 6 Control Unit (CU) Central Processing Unit (CPU) Address Bus Data Bus Arithmetical Logical Unit (ALU) Primary Memory Unit (Executable Memory) Device Device Controller and Device Device Controller and Device

7 7 - The crucial difference between computers and other electronic devices is the variable program

8  Datapath  ALU – Arithmetic/Logic Unit  Registers  General-purpose registers  Control registers  Communication paths between them  Control  Controls the data flow and operations of ALU 8

9 9 R1 R2 Rn... Status Registers Functional Unit Left Operand Right Operand Result To/from Primary Memory load R3,b load R4,c add R3,R4 store R3,a

10 10 int a, b, c, d;... a = b + c; d = a - 100; Source ; Code for a = b + c load R3,b load R4,c add R3,R4 store R3,a Assembly Language ; Code for d = a load R4,=100 subtract R3,R4 store R3,d

11 11 ; Code for a = b + c load R3,b load R4,c add R3,R4 store R3,a ; Code for d = a load R4,=100 subtract R3,R4 store R3,d Assembly Language … … … … … … …1 Machine Language

12 Primary Memory Fetch Unit Decode Unit Execute Unit PC IR Control Unit load R3,b load R4,c add R3,R4 store R3,a … … … …1 load R4, c 3050

13 13 PC = ; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; // fetch phase }; Fetch phase: Instruction retrieved from memory Execute phase: ALU op, memory data reference, I/O, etc.

14 Control unitControl unit IR S1 bus S2 bus R0, r1,... (registers) ia(PC) psw... MAR MDR A B C Dest bus Memory ALU MAR memory address register MDR memory data register IR instruction register

15 15 MAR MDR Command n Read Op: Load MAR with address read 2. Load Command with “read” Data will then appear in the MDR

16  Instruction fetch (IF) MAR  PC; IR  M[MAR]  Instruction Decode (ID) A  Rs1; B  Rs2; PC  PC + 4  Execution (EXE)  Depends on the instruction  Memory Access (MEM)  Depends on the instruction  Write-back (WB) 16

17  r3  r1 + r2  IF: MAR  PC; IR  M[MAR]  ID: A  r1; B  r2; PC  PC + 4  EXE: ALUoutput  A + B  MEM:  WB: r3  ALUoutput 17

18  load 30(r1), r2  IF: MAR  PC; IR  M[MAR]  ID: A  r1; PC  PC + 4  EXE: MAR  A + #30  MEM: MDR  M[MAR]  WB: r2  MDR 18

19  bnez r1, -16  IF: MAR  PC; IR  M[MAR]  ID: A  r1; PC  PC + 4  EXE: ALUoutput  PC + #-16; cond  (A op 0)  MEM: if (cond) PC  ALUoutput  WB: 19 r1 = 100 r4 = 0 r3 = 1 L1: r4 = r4 + r3 r3 = r3 + 2 r1 = r1-1 if (r1!=0) goto L1 // Outside loop // r4 ?

20  I/O devices are used to place data into primary memory and to store its contents on a more permanent medium  Logic to control detailed operation  Physical device itself  Each device uses a device controller to connect it to the computer’s address and data bus  Many types of I/O devices 20

21 21 Application Program Device Controller Device Software in the CPU Abstract I/O Machine Device manager Program to manage device controller Supervisor mode software

22  Block or character oriented  Depends on number of bytes transferred in one operation  Input or Output (or both)  Storage or communication  Handled by device controller 22

23  A hardware component to control the detailed operations of a device  Interface between controllers and devices  Interface between software and the controller  Through controller’s registers 23

24 24 Command Status Data 0 Data 1 Data n-1 Logic busydoneError code... busy done 0 0 idle 0 1 finished 1 0 working 1 1 (undefined)

25 25 Primary Memory CPU Controller Device Primary Memory CPU Controller Device Conventional devices DMA controllers

26  Instructions to access device controller’s registers  Special I/O instructions  Memory-mapped I/O 26

27 27 Primary Memory Device 0 Device 1 Device n-1 Primary Memory Device 0 Device 1 Device n-1 Device Addresses Memory Addresses

28  Through busy-done flag  Called polling  A busy-waiting implementation  Not effective 28

29 29 … // Start the device … While(busy == 1) wait(); // Device I/O complete … done = 0; … while((busy == 0) && (done == 1)) wait(); // Do the I/O operation busy = 1; … busydone Software Hardware

30  It introduces busy-waiting  The CPU is busy, but is effectively waiting  Devices are much slower than CPU  CPU waits while device operates  Would like to multiplex CPU to a different process while I/O is in process 30 while(deviceNo.busy || deviceNo.done) ; deviceNo.data[0] = deviceNo.command = WRITE; while(deviceNo.busy) ; deviceNo.done = TRUE;

31  When a process is waiting for its I/O to be completed, it would be more effective if we can let another process to run to fully utilize the CPU  It requires a way for the device to inform the CPU when it has just completed I/O 31

32 32 CPU Device … Ready Processes CPU Device … Ready Processes I/O Operation CPU Device … Ready Processes Uses CPU

33 33 CPU Device Interrupt Pending CPU incorporates an “interrupt pending” flag When device.busy  FALSE, interrupt pending flag is set Hardware “tells” OS that the interrupt occurred Interrupt handler part of the OS makes process ready to run

34  An interrupt is an immediate (asynchronous) transfer of control caused by an event in the system to handle real-time events and running- time errors  Interrupt can be either software or hardware  I/O device request (Hardware)  System call (software)  Signal (software)  Page fault (software)  Arithmetic overflow  Memory-protection violation  Power failure 34

35  Causes of interrupts:  System call (syscall instruction)  Timer expires (value of timer register reaches 0)  I/O completed  Program performed an illegal operation:  Divide by zero  Address out of bounds while in user mode  Segmentation fault 35

36 36 program interrupt Interrupt handler

37  Synchronous  Events occur at the same place every time the program is executed with the same data and memory  Can be predicted  Asynchronous  Caused by devices external to the processor or memory 37

38  When an interrupt occurs, the following steps are taken  Save current program state  Context switch to save all the general and status registers of the interrupted process  Find out the interrupt source  Go to the interrupt handler 38

39 39 PC = ; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; if(InterruptRequest) { memory[0] = PC; PC = memory[1] }; memory[1] contains the address of the interrupt handler

40 40 interruptHandler() { saveProcessorState(); for(i=0; i

41  Problem when two or more devices finish during the same instruction cycle  Race condition between interrupts  The interrupt handler gets interrupted  To avoid race conditions implement InterruptEnable flag  If FALSE, no interrupts allowed  Reset to TRUE when handler exits “critical code” section 41

42 42 PC = ; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; if(InterruptRequest && InterruptEnabled) { disableInterrupts(); memory[0] = PC; PC = memory[1] };

43 43 executeTrap(argument) { setMode(supervisor); switch(argument) { case 1: PC = memory[1001]; // Trap handler 1 case 2: PC = memory[1002]; // Trap handler 2... case n: PC = memory[1000+n];// Trap handler n }; The trap instruction dispatches a trap handler routine atomically Trap handler performs desired processing “A trap is a software interrupt”

44 44 S Mode Trusted Code trap UserSupervisor Branch Table 2 31

45 45 ROM CMOS RAM Boot Device POST BIOS Boot Prog Loader OS … Hardware Process Data Flow Power Up

46 46 Bootstrap loader (“boot sector”) Primary Memory 1 0x Fetch Unit Decode Unit Execute Unit … … PC IR BIOS loader 0x

47 47 Bootstrapping Bootstrap loader (“boot sector”) Primary Memory Loader 1 2 Fetch Unit Decode Unit Execute Unit … … PC IR BIOS loader 0x x x

48 48 Bootstrapping Bootstrap loader (“boot sector”) Primary Memory Loader OS Fetch Unit Decode Unit Execute Unit … … PC IR BIOS loader 0x x x x000A000

49 49 Bootstrap loader (“boot sector”) Primary Memory Loader OS Initialize hardware 5. Create user environment 6. … Fetch Unit Decode Unit Execute Unit 000A000 … … PC IR BIOS loader 0x x x x000A000

50 50 FIXED_LOC: // Bootstrap loader entry point loadR1, =0 loadR2, =LENGTH_OF_TARGET // The next instruction is really more like // a procedure call than a machine instruction // It copies a block from FIXED_DISK_ADDRESS // to BUFFER_ADDRESS readBOOT_DISK, BUFFER_ADDRESS loop:loadR3, [BUFFER_ADDRESS, R1] storeR3, [FIXED_DEST, R1] incrR1 bleqR1, R2, loop brFIXED_DEST

51  Use von Neumann architecture, BUT  Physically very small and light weight  Severe restraints on power consumption  Limited memory size  May use removable devices for storage, networking, etc.  System-on-a-chip (SOC)  Most components are integrated into same chip as the CPU  Power management is critical issue 51

52  How can we make computers faster while using the same clock speed  Break computer into multiple units – each working on a different part of same problem  Divide CPU into functional units => pipelining  Use multiple ALUs => SIMD machines  Single instruction-multiple data  Use multiprocessors => parallel computers 52

53 53 Function Unit Operand 1 Operand 2 Result Operand 1 Operand 2 Result (a) Monolithic Unit (b) Pipelined Unit

54 54 ALU Control Unit (a) Conventional Architecture ALU Control Unit ALU … (b) SIMD Architecture

55  Shared memory multiprocessors  Distributed memory multiprocessors 55

56  The von Neumann architecture is used in most computers  To manage I/O devices or effectively, interrupts are used  Interrupt handling involves hardware and software support  There are also machines which use a different architecture  Array processors; multiprocessors 56


Download ppt "1 (Review of Prerequisite Material). Processes are an abstraction of the operation of computers. So, to understand operating systems, one must have a."

Similar presentations


Ads by Google