DOC PREVIEW
Lecture

This preview shows page 1-2-3-4 out of 13 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CMU 18-447S’09 L14-1© 2009J. C. Hoe18-447 Lecture 14:Exceptions and InterruptsJames C. HoeDept of ECE, CMUMarch 16, 2009Announcements: Spring break is over . . .HW 3 is due now Project 2 due this weekMidterm 2 on 3/30 in class (last lecture to be included)Handouts: CMU 18-447S’09 L14-2© 2009J. C. HoeExceptions and Interrupts A systematic way to handle exceptional conditions that are relatively rare, but must be detected and acted upon quickly instructions may fail and cannot complete external I/O devices may need servicing quantum expiration in a time-shared system Option 1: write every program with continuous checks (a.k.a. polling) for every possible contingencyacceptable for simple embedded systems (toaster) Option 2: write “normal” programs for the best-case scenario where nothing unusual happens detect exceptional conditions in HW “transparently” transfer control to an exception handler that knows how to resolve the condition and then back to your programCMU 18-447S’09 L14-3© 2009J. C. HoeTypes of Interrupts Synchronous Interrupts (a.k.a. exceptions) exceptional conditions tied to a particular instruction e.g. illegal opcode, illegal operand, virtual memory management faults  the faulting instruction cannot be finishedno forward progress unless handled immediately Asynchronous Interrupts (a.k.a. interrupts) external events not tied to a particular instruction I/O events, timer events some flexibility on when to handle itcannot postpone forever or things start to “fall on the floor” System Call/Trap Instruction an instruction whose only purpose is to raise an exception whatever for?CMU 18-447S’09 L14-4© 2009J. C. HoeInterrupt SourcesinterruptcontrollogicIRQ lines from external devices(I/O, DMA, timers, etc.)CPUdatapath- failed instructions- system call instructionsExceptions, a.k.a. synchronous interruptsInterrupts, a.k.a. asynchronous interruptsexternal interruptsCMU 18-447S’09 L14-5© 2009J. C. HoeInterrupt Control Transfer An interrupt is an “unplanned”function call to a system routine (aka, the interrupt handler)  Unlike a normal function call, the interrupted thread cannot anticipate the control transfer or prepare for it in any way Control is later returned to the main thread at the interrupted instructionThe control transfer to the interrupt handler and back must be 100% transparent to the interrupted thread!!!i1i2i3H1H2Hn….interruptrestartCMU 18-447S’09 L14-6© 2009J. C. HoeVirtualization and Protection Modern OS supports time-shared multiprocessing but each “user-level” process still thinks it is alone each process sees a private set of user-level architectural states that can be modified by the user-level instruction set each process cannot see or manipulate (directly) state and devices outside of this abstraction  OS implements and manages a critical set of functionality  keep low-level details out of the user-level process protect the user-level process from each other and itself Do you want to access/manage harddisk directly? Do you trust your buddy or yourself to access the harddisk directly?CMU 18-447S’09 L14-7© 2009J. C. HoePrivilege Levels The OS must somehow be more powerful to create and maintain such an abstraction, hence a separate privileged (aka protected or kernel) mode additional architectural states and instructions, in particular those controlling virtualization/ protection/isolation the kernel code running in the privileged mode has access to the complete “bare” hardware systemuser-level levelstate and instructionsprivileged level“hypervisor” level forvirtualizing multiple OSsCMU 18-447S’09 L14-8© 2009J. C. HoeControl and Privilege Transfer User-level code never runs in the privileged mode Processor enters the privileged mode only on interrupts---user code surrenders control to a handler in the OS kernel The handler restores privilege level back to user mode before returning control to the user codei1i2i3H1H2Hn….interruptrestartuser->privilegedprivileged->userCMU 18-447S’09 L14-9© 2009J. C. HoeImplementing InterruptsCMU 18-447S’09 L14-10© 2009J. C. HoePrecise Interrupt/ExceptionSequential Code Semantics Overlapped ExecutionA precise interrupt appears (to the interrupt handler) to take place exactly between two instructions• older instructions finished completely• younger instructions as if never happened• on synchronous interrupts, execution stops just before the faulting instructioni1i2i3i1:i2:i3:CMU 18-447S’09 L14-11© 2009J. C. HoeStopping and Restarting a PipelineI0I0I1I0I1I2I0I1I2I3bubbubbubbubIhbubbubbubIhIh+1bubbubIhIh+1Ih+2bubIhIh+1Ih+2Ih+3I0I1I2I3I4I1I2bubbubbubI2bubbubbubbubWBMEMEXIDIFt10t9t8t7t6t5t4t3t2t1t0What if I0, I1, I2, I3and I4 all generate exceptions in t4?How would things look different for asynchronous interrupts?CMU 18-447S’09 L14-12© 2009J. C. HoeException Sources in Different Stages IF instruction memory address/protection fault ID illegal opcode trap to SW emulation of unimplemented instructions system call instruction (a SW requested exception) EX invalid results: overflow, divide by zero, etc MEM data memory address/protection fault WB nothing can stop an instruction now… We can associate async interrupts (I/O) with any instruction/stage we likeCMU 18-447S’09 L14-13© 2009J. C. HoePipeline Flush for ExceptionsPCInstruction memory4RegistersSign extendM u xM u xM u xControlALUEXMWBMWBWBID/EXEX/MEMMEM/WBM u xData memoryM u xHazard detection unitForwarding unitIF.FlushIF/ID=Except PC400000400M u x0M u x0M u xID.FlushEX.FlushCauseShift left 2Figure from [P&H CO&D, COPYRIGHT 2004 Elsevier. ALL RIGHTS RESERVED.]- carry PC in the pipeline with each inst.- new pipeline flush pointsCMU 18-447S’09 L14-14© 2009J. C. HoeMIPS Interrupt ArchitectureCMU 18-447S’09 L14-15© 2009J. C. HoeMIPS Interrupt Architecture Privileged system control registers Exception Program Counter (EPC, CR14): which instruction did we stop on Interrupt Cause Register (CR 13): what caused the interrupt Interrupt Status Register (CR 12): enable and disable interrupts, set privilege modes  Loaded automatically on interrupt transfer events  Also accessed by the “move from/to co-processor-0” instruction: “mfc0 Ry, CRx” and “mtc0 Ry, CRx”Figures from [P&H CO&D, COPYRIGHT 2004 Elsevier. ALL RIGHTS RESERVED.]CMU


Lecture

Download Lecture
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?