560 likes | 588 Views
Computer Organization. (Review of Prerequisite Material). Computer Architecture. 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.
E N D
Computer Organization (Review of Prerequisite Material)
Computer Architecture 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.
Historical Perspective • Babbage designed Difference Engine (1822-1857), 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
Pattern Jacquard Loom Variable Program Stored Program Device Stored Program Computers and Electronic Devices Fixed Electronic Device
Historical Perspective – cont • 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
Central Processing Unit (CPU) Arithmetical Logical Unit (ALU) Control Unit (CU) Address Bus Data Bus Device Controller and Device Primary Memory Unit (Executable Memory) Device Device von Neumann Architecture
von Neumann Architecture – cont. • The crucial difference between computers and other • electronic devices is the variable program
Central Processing Unit • Datapath • ALU – Arithmetic/Logic Unit • Registers • General-purpose registers • Control registers • Communication paths between them • Control • Controls the data flow and operations of ALU
The ALU load R3,b load R4,c add R3,R4 store R3,a Right Operand Left Operand R1 R2 . . . Rn Functional Unit Status Registers Result To/from Primary Memory
Assembly Language ; Code for a = b + c load R3,b load R4,c add R3,R4 store R3,a ; Code for d = a - 100 load R4,=100 subtract R3,R4 store R3,d Program Specification Source int a, b, c, d; . . . a = b + c; d = a - 100;
Machine Language 10111001001100…1 10111001010000…0 10100111001100…0 10111010001100…1 10111001010000…0 10100110001100…0 10111001101100…1 Machine Language Assembly Language ; Code for a = b + c load R3,b load R4,c add R3,R4 store R3,a ; Code for d = a - 100 load R4,=100 subtract R3,R4 store R3,d
load R3,b load R4,c add R3,R4 store R3,a Fetch Unit 3046 3050 3054 3058 10111001001100…1 10111001010000…0 10100111001100…0 10111010001100…1 3050 PC Decode Unit IR load R4, c Execute Unit Primary Memory Control Unit Control Unit
Control Unit Operation • Fetch phase: Instruction retrieved from memory • Execute phase: ALU op, memory data reference, I/O, etc. PC = <machine start address>; IR = memory[PC]; haltFlag = CLEAR; while(haltFlag not SET) { execute(IR); PC = PC + sizeof(INSTRUCT); IR = memory[PC]; // fetch phase };
S1 bus Dest bus S2 bus Control unit ALU A R0, r1,... (registers) C B ia(PC) psw... MAR MDR IR MAR memory address register MDR memory data register IR instruction register Memory
1234 98765 read 1. Load MAR with address 2. Load Command with “read” 3. Data will then appear in the MDR Primary Memory Unit 0 MAR 1 2 MDR Command 1234 98765 Read Op: n-1
Instruction Execution • 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)
Arithmetic Instruction Example • 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
Memory Instruction Example • 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
Branch/jump Instruction Example • 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: r1 = 100 r4 = 0 r3 = 1 L1: r4 = r4 + r3 r3 = r3 + 2 r1 = r1-1 if (r1!=0) goto L1 // Outside loop // r4 ?
Devices • 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
Device manager • Program to manage device controller • Supervisor mode software Application Program Software in the CPU Abstract I/O Machine Device Controller Device Device Organization
Device Characteristics • 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
Device Controllers • 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
busy done 0 0 idle 0 1 finished 1 0 working 1 1 (undefined) Device Controller Interface . . . busy done Error code . . . Command Status Data 0 Data 1 Logic Data n-1
Direct Memory Access Conventional devices DMA controllers Primary Memory Primary Memory CPU CPU Controller Controller Device Device
Addressing Devices • Instructions to access device controller’s registers • Special I/O instructions • Memory-mapped I/O
Addressing Devices Primary Memory Primary Memory Memory Addresses Device 0 Device 0 Memory Addresses Device 1 Device 1 Device Addresses Device n-1 Device n-1
Communication Between CPU and Devices • Through busy-done flag • Called polling • A busy-waiting implementation • Not effective
… // Start the device … While(busy == 1) wait(); // Device I/O complete … done = 0; Software busy done Hardware … while((busy == 0) && (done == 1)) wait(); // Do the I/O operation busy = 1; … Polling I/O
Polling I/O – cont. while(deviceNo.busy || deviceNo.done) <waiting>; deviceNo.data[0] = <value to write> deviceNo.command = WRITE; while(deviceNo.busy) <waiting>; deviceNo.done = TRUE; • 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
A More Efficient Approach • 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
… … … Ready Processes Ready Processes Ready Processes CPU CPU CPU Device Device Device I/O Operation Uses CPU Better Utilization of CPU
Determining When I/O is Complete CPU Interrupt Pending Device Device Device • 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
Interrupts • 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
Interrupts – cont. • 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
program Interrupt handler interrupt Interrupts – cont.
Synchronous vs. Asynchronous • 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
Interrupt Handling • 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
memory[1] contains the address of the interrupt handler Control Unit with Interrupt (Hardware) PC = <machine start address>; 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] };
Interrupt Handler (Software) interruptHandler() { saveProcessorState(); for(i=0; i<NumberOfDevices; i++) if(device[i].done) goto deviceHandler(i); /* something wrong if we get to here … */ deviceHandler(int i) { finishOperation(); returnToScheduler(); } saveProcessorState() { for(i=0; i<NumberOfRegisters; i++) memory[K+i] = R[i]; for(i=0; i<NumberOfStatusRegisters; i++) memory[K+NumberOfRegisters+i] = StatusRegister[i]; }
Interrupt Handling – cont. • 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
Fetch/Execute Cycle w/Interrupts PC = <machine start address>; 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] };
Revisiting the trap Instruction (Hardware) 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”
Branch Table 1 2 3 The Trap Instruction Operation Mode S trap Trusted Code User Supervisor
RAM Boot Prog ROM Loader Power Up Boot Device POST OS BIOS … CMOS Hardware Process Data Flow Intel System Initialization
0x0000100 BIOS loader Fetch Unit 0000100 PC Decode Unit IR … Execute Unit Bootstrapping Bootstrap loader (“boot sector”) 1 0x0001000 Primary Memory
Fetch Unit 0001000 PC Decode Unit IR … Execute Unit Bootstrapping Bootstrap loader (“boot sector”) 1 0x0000100 2 BIOS loader 0x0001000 0x0008000 Loader Primary Memory
Fetch Unit 0008000 PC Decode Unit IR … Execute Unit Bootstrapping Bootstrap loader (“boot sector”) 1 0x0000100 2 BIOS loader 0x0001000 0x0008000 Loader 3 0x000A000 OS Primary Memory
Bootstrapping Bootstrap loader (“boot sector”) 1 0x0000100 2 BIOS loader 0x0001000 0x0008000 Fetch Unit Loader 3 000A000 PC 0x000A000 Decode Unit OS IR … Primary Memory Execute Unit 4. Initialize hardware 5. Create user environment 6. …
A Bootstrap Loader Program FIXED_LOC: // Bootstrap loader entry point load R1, =0 load R2, =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 read BOOT_DISK, BUFFER_ADDRESS loop: load R3, [BUFFER_ADDRESS, R1] store R3, [FIXED_DEST, R1] incr R1 bleq R1, R2, loop br FIXED_DEST