Chapter04Rev12 - Chapter 4 (Revision number 12) Interrupts,...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
1 Chapter 4 (Revision number 12) Interrupts, Traps and Exceptions In the previous chapter, we discussed the implementation of the processor. In this chapter, we will discuss how the processor can handle discontinuities in program execution. In a sense, branch instructions and subroutine calls are discontinuities as well. However, the programmer consciously introduced such discontinuities that are part of the program. The discontinuities we will look into in this chapter are those that are potentially unplanned for and often may not even be part of the program that experiences it! Let us look at a simple analogy, a classroom . The professor is giving a lecture on computer architecture. To encourage class participation, he wants students to ask questions. He could do one of two things: (1) periodically, he could stop lecturing and poll the students to see if they have any questions; or (2) he could tell the students whenever they have a question, they should put up their hands to signal that they have a question. Clearly, the first approach takes away the spontaneity of the students. By the time the professor gets around to polling the students, they may have forgotten that they had a question! Worse yet, they had so many questions one after another that they are now completely lost! The second approach will ensure that the students remain engaged and they do not lose their train of thought. However, there is a slight problem. When should the professor take a student’s question? He could take it immediately as soon as someone puts up a hand, but he may be in mid-sentence. Therefore, he should finish his train of thought and then take the question. He has to be careful to remember where he was in his lecture so that after answering the student’s question he can return to where he left off in the lecture. What if another student asks a question while the professor is in the middle of answering the first student’s question? That will soon spiral out of control, so as a first order principle the professor should not take another question until he is finished with answering the first one. So two things to take away from the classroom analogy: remember where to return in the lecture, and disable further questions.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 The processor that we designed executes instructions but unless it can talk to the outside world for I/O it is pretty much useless. Building on the above analogy, we can have the processor poll an input device (such as a keyboard) periodically. On the one hand, polling is error prone since the device could be generating data faster than the polling rate. On the other hand, it is extremely wasteful for the processor to be doing the polling if the device has no data to deliver! Therefore, we can apply the classroom analogy and let the device interrupt the processor to let it know that it has something to say to the processor. As in the classroom analogy, the processor should remember where it is in its current program execution and disable further interruptions until it services the current
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 11/25/2010 for the course CENG 100 taught by Professor Ceng during the Spring '10 term at Universidad Europea de Madrid.

Page1 / 18

Chapter04Rev12 - Chapter 4 (Revision number 12) Interrupts,...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online