Chapter Seventeen (Part 3)
|Table of Content|
INTERRUPTS TRAPS AND EXEPTIONS (Part 4)
Chaining Interrupt Service Routines
17.6 - Reentrancy Problems
17.7 - The Efficiency of an Interrupt Driven System
17.7.1 - Interrupt Driven I/O vs. Polling
- Interrupt Service Time
17.7.3 - Interrupt Latency
17.7.4 - Prioritized Interrupts
17.8 - Debugging ISRs
|17.5 Chaining Interrupt Service Routines|
Interrupt service routines come in two basic varieties - those that need exclusive access to an interrupt vector and those that must share an interrupt vector with several other ISRs. Those in the first category include error handling ISRs (e.g. divide error or overflow) and certain device drivers. The serial port is a good example of a device that rarely has more than one ISR associated with it at any one given time. The timer real-time clock and keyboard ISRs generally fall into the latter category. It is not at all uncommon to find several ISRs in memory sharing each of these interrupts.
Sharing an interrupt vector is rather easy. All an ISR
needs to do to share an interrupt vector is to save the old interrupt vector when
installing the ISR (something you need to do anyway
so you can restore the interrupt
vector when your code terminates) and then call the original ISR before or after you do
your own ISR processing. If you've saved away the address of the original ISR in the
double word variable
you can call the original ISR with the
; Presumably DS points at DSEG at this point. pushf ;Simulate an INT instruction by pushing call OldIntVect ; the flags and making a far call.
OldIntVect is a dword variable
code generates a far call to the routine whose segmented address appears in the
variable. This code does not jump to the location of the
Many interrupt service routines do not modify the
register to point at a local data segment. In fact
some simple ISRs do not change any of
the segment registers. In such cases it is common to put any necessary variables
(especially the old segment value) directly in the code segment. If you do this
could jump directly to the original ISR rather than calling it. To do so
you would just
use the code:
MyISR proc near . . . jmp cs:OldIntVect MyISR endp OldIntVect dword ?
This code sequence passes along your ISR's flags and return address as the flag and return address values to the original ISR. This is fine when the original ISR executes the iret instruction it will return directly to the interrupted code (assuming it doesn't pass control to some other ISR in the chain).
OldIntVect variable must be in the code
segment if you use this technique to transfer control to the original ISR. After all
you executing the
jmp instruction above
you must have already restored the
state of the CPU
ds register. Therefore
you have no idea what
ds is pointing at
and it probably isn't pointing at your local data
the only segment register whose value is known to you is
so you must keep the vector address in your code segment.
The following simple program demonstrates interrupt
chaining. This short program patches into the
int 1ch vector. The ISR counts
off seconds and notifies the main program as each second passes. The main program prints a
short message every second. When 10 seconds have expired
this program removes the ISR
from the interrupt chain and terminates.
; TIMER.ASM ; This program demonstrates how to patch into the int 1Ch timer interrupt ; vector and create an interrupt chain. .xlist .286 include stdlib.a includelib stdlib.lib .list dseg segment para public 'data' ; The TIMERISR will update the following two variables. ; It will update the MSEC variable every 55 ms. ; It will update the TIMER variable every second. MSEC word 0 TIMER word 0 dseg ends cseg segment para public 'code' assume cs:cseg ds:dseg ; The OldInt1C variable must be in the code segment because of the ; way TimerISR transfers control to the next ISR in the int 1Ch chain. OldInt1C dword ? ; The timer interrupt service routine. ; This guy increment MSEC variable by 55 on every interrupt. ; Since this interrupt gets called every 55 msec (approx) the ; MSEC variable contains the current number of milliseconds. ; When this value exceeds 1000 (one second) the ISR subtracts ; 1000 from the MSEC variable and increments TIMER by one. TimerISR proc near push ds push ax mov ax dseg mov ds ax mov ax MSEC add ax 55 ;Interrupt every 55 msec. cmp ax 1000 jb SetMSEC inc Timer ;A second just passed. sub ax 1000 ;Adjust MSEC value. SetMSEC: mov MSEC ax pop ax pop ds jmp cseg:OldInt1C ;Transfer to original ISR. TimerISR endp Main proc mov ax dseg mov ds ax meminit ; Begin by patching in the address of our ISR into int 1ch's vector. ; Note that we must turn off the interrupts while actually patching ; the interrupt vector and we must ensure that interrupts are turned ; back on afterwards; hence the cli and sti instructions. These are ; required because a timer interrupt could come along between the two ; instructions that write to the int 1Ch interrupt vector. This would ; be a big mess. mov ax 0 mov es ax mov ax es:[1ch*4] mov word ptr OldInt1C ax mov ax es:[1ch*4 + 2] mov word ptr OldInt1C+2 ax cli mov word ptr es:[1Ch*4] offset TimerISR mov es:[1Ch*4 + 2] cs sti ; Okay the ISR updates the TIMER variable every second. ; Continuously print this value until ten seconds have ; elapsed. Then quit. mov Timer 0 TimerLoop: printf byte "Timer = %d\n" 0 dword Timer cmp Timer 10 jbe TimerLoop ; Okay restore the interrupt vector. We need the interrupts off ; here for the same reason as above. mov ax 0 mov es ax cli mov ax word ptr OldInt1C mov es:[1Ch*4] ax mov ax word ptr OldInt1C+2 mov es:[1Ch*4+2] ax sti Quit: ExitPgm ;DOS macro to quit program. Main endp cseg ends sseg segment para stack 'stack' stk db 1024 dup ("stack ") sseg ends zzzzzzseg segment para public 'zzzzzz' LastBytes db 16 dup (?) zzzzzzseg ends end Main
A minor problem develops with developing ISRs what happens if you enable interrupts while in an ISR and a second interrupt from the same device comes along? This would interrupt the ISR and then reenter the ISR from the beginning. Many applications do not behave properly under these conditions. An application that can properly handle this situation is said to be reentrant. Code segments that do not operate properly when reentered are nonreentrant.
Consider the TIMER.ASM program in the previous section. This is an example of a nonreentrant program. Suppose that while executing the ISR it is interrupted at the following point:
TimerISR proc near push ds push ax mov ax dseg mov ds ax mov ax MSEC add ax 55 ;Interrupt every 55 msec. cmp ax 1000 jb SetMSEC ; <<<<< Suppose the interrupt occurs at this point >>>>> inc Timer ;A second just passed. sub ax 1000 ;Adjust MSEC value. SetMSEC: mov MSEC ax pop ax pop ds jmp cseg:OldInt1C ;Transfer to original ISR. TimerISR endp
on the first invocation of the interrupt
MSEC contains 950 and
Timer contains three. If a second interrupt occurs and
the specified point above
ax will contain 1005. So the interrupt suspends the ISR and
reenters it from the beginning. Note that
TimerISR is nice enough to preserve
ax register containing the value 1005. When the second invocation of
it finds that
MSEC still contains 950 because the first invocation
has yet to update
it adds 55 to this value
it exceeds 1000
Timer (it becomes four) and then stores five into
MSEC. Then it returns (by jumping to the next ISR in the
control returns the first invocation of the
routine. At this time (less than 55 msec after updating
Timer by the second
TimerISR code increments the
again and updates
MSEC to five. The problem with this sequence is that it has
Timer variable twice in less than 55 msec.
Now you might argue that hardware interrupts always clear the interrupt disable flag so it would not be possible for this interrupt to be reentered. Furthermore you might argue that this routine is so short it would never take more than 55 msec to get to the noted point in the code above. However you are forgetting something: some other timer ISR could be in the system that calls your code after it is done. That code could take 55 msec and just happen to turn the interrupts back on making it perfectly possible that your code could be reentered.
The code between the
ax instructions above is called a critical region or critical section. A
program must not be reentered while it is executing in a critical region. Note that having
critical regions does not mean that a program is not reentrant. Most programs
that are reentrant
have various critical regions. The key is to prevent an interrupt that
could cause a critical region to be reentered while in that critical region. The easiest
way to prevent such an occurrence is to turn off the interrupts while executing code in a
critical section. We can easily modify the
TimerISR to do this with the
TimerISR proc near push ds push ax mov ax dseg mov ds ax ; Beginning of critical section turn off interrupts. pushf ;Preserve current I flag state. cli ;Make sure interrupts are off. mov ax MSEC add ax 55 ;Interrupt every 55 msec. cmp ax 1000 jb SetMSEC inc Timer ;A second just passed. sub ax 1000 ;Adjust MSEC value. SetMSEC: mov MSEC ax ; End of critical region restore the I flag to its former glory. popf pop ax pop ds jmp cseg:OldInt1C ;Transfer to original ISR. TimerISR endp
We will return to the problem of reentrancy and critical regions in the next two chapters of this text.
Interrupts introduce a considerable amount of complexity to a software system (see "Debugging ISRs"). One might ask if using interrupts is really worth the trouble. The answer of course is yes. Why else would people use interrupts if they were proven not to be worthwhile? However interrupts are like many other nifty things in computer science - they have their place; if you attempt to use interrupts in an inappropriate fashion they will only make things worse for you.
The following sections explore the efficiency aspects of using interrupts. As you will soon discover an interrupt driven system is usually superior despite the complexity. However this is not always the case. For many systems alternative methods provide better performance.
17.7.1 Interrupt Driven I/O vs. Polling
The whole purpose of an interrupt driven system is to allow the CPU to continue processing instructions while some I/O activity occurs. This is in direct contrast to a polling system where the CPU continually tests an I/O device to see if the I/O operation is complete. In an interrupt driven system the CPU goes about its business and the I/O device interrupts it when it needs servicing. This is generally much more efficient than wasting CPU cycles polling a device while it is not ready.
The serial port is a perfect example of a device that works extremely well with interrupt driven I/O. You can start a communication program that begins downloading a file over a modem. Each time a character arrives it generates an interrupt and the communication program starts up buffers the character and then returns from the interrupt. In the meantime another program (like a word processor) can be running with almost no performance degradation since it takes so little time to process the serial port interrupts.
Contrast the above scenario with one where the serial communication program continually polls the serial communication chip to see if a character has arrived. In this case the CPU spends all of its time looking for an input character even though one rarely (in CPU terms) arrives. Therefore no CPU cycles are left over to do other processing like running your word processor.
Suppose interrupts were not available and you wanted to allow background downloads while using your word processing program. Your word processing program would have to test the input data on the serial port once every few milliseconds to keep from losing any data. Can you imagine how difficult such a word processor would be to write? An interrupt system is the clear choice in this case.
If downloading data while word processing seems far fetched consider a more simple case - the PC's keyboard. Whenever a keypress interrupt occurs the keyboard ISR reads the key pressed and saves it in the system type ahead buffer for the moment when the application wants to read the keyboard data. Can you imagine how difficult it would be to write applications if you had to constantly poll the keyboard port yourself to keep from losing characters? Even in the middle of a long calculation? Once again interrupts provide an easy solution.
17.7.2 Interrupt Service Time
Of course the serial communication system just described is an example of a best case scenario. The communication program takes so little time to do its job that most of the time is left over for the word processing program. However were to you run a different interrupt driven I/O system for example copying files from one disk to another the interrupt service routine would have a noticeable impact on the performance of the word processing system.
Two factors control an ISR's impact on a computer system: the frequency of interrupts and the interrupt service time. The frequency is how many times per second (or other time measurement) a particular interrupt occurs. The interrupt service time is how long the ISR takes to service the interrupt.
The nature of the frequency varies according to source of the interrupt. For example the timer chip generates evenly spaced interrupts about 18 times per second likewise a serial port receiving at 9600bps generates better than 100 interrupts per second. On the other hand the keyboard rarely generates more than about 20 interrupts per second and they are not very regular.
The interrupt service time is obviously dependent upon the number of instructions the ISR must execute. The interrupt service time is also dependent upon the particular CPU and clock frequency. The same ISR executing identical instructions on two CPUs will run in less time on a faster machine.
The amount of time an interrupt service routine takes to handle an interrupt multiplied by the frequency of the interrupt determines the impact the interrupt will have on system performance. Remember every CPU cycle spent in an ISR is one less cycle available for your application programs. Consider the timer interrupt. Suppose the timer ISR takes 100 msec to complete its tasks. This means that the timer interrupt consumes 1.8 msec out of every second or about 0.18% of the total computer time. Using a faster CPU will reduce this percentage (by reducing the time spent in the ISR); using a slower CPU will increase the percentage. Nevertheless you can see that a short ISR such as this one will not have a significant effect on overall system performance.
One hundred microseconds is fast for a typical timer ISR especially when your system has several timer ISRs chained together. However even if the timer ISR took ten times as long to execute it would only rob the system of less than 2% of the available CPU cycles. Even if it took 100 times longer (10 msec) there would only be an 18% performance degradation; most people would barely notice such a degradation.
Of course one cannot allow the ISR to take as much time as it wants. Since the timer interrupt occurs every 55 msec the maximum time the ISR can use is just under 55msec. If the ISR requires more time than there is between interrupts the system will eventually lose an interrupt. Furthermore the system will spend all its time servicing the interrupt rather than accomplishing anything else.
For many systems having an ISR that consumes as much as 10% of the overall CPU cycles will not prove to a problem. However before you go off and start designing slow interrupt service routines you should remember that your ISR is probably not the only ISR in the system. While your ISR is consuming 25% of the CPU cycles there may be another ISR that is doing the same thing; and another and another and... Furthermore there may be some ISRs that require fast servicing. For example a serial port ISR may need to read a character from the serial communications chip each millisecond or so. If your timer ISR requires 4 msec to execute and does so with the interrupts turned off the serial port ISR will miss some characters.
Ultimately of course you would like to write ISRs so they are as fast as possible so they have as little impact on system performance as they can. This is one of the main reasons most ISRs for DOS are still written in assembly language. Unless you are designing an embedded system one in which the PC runs only your application you need to realize that your ISRs must coexist with other ISRs and applications; you do not want the performance of your ISR to adversely affect the performance of other code in the system.
17.7.3 Interrupt Latency
Interrupt latency is the time between the point a device signals that it needs service and the point where the ISR provides the needed service. This is not instantaneous! At the very least the 8259 PIC needs to signal the CPU the CPU needs to interrupt the current program push the flags and return address obtain the ISR address and transfer control to the ISR. The ISR may need to push various registers set up certain variables check device status to determine the source of the interrupt and so on. Furthermore there may be other ISRs chained into the interrupt vector before you and they execute to completion before transferring control to your ISR that actually services the device. Eventually the ISR actually does whatever it is that the device needs done. In the best case on the fastest microprocessors with simple ISRs the latency could be under a microsecond. On slower systems with several ISRs in a chain the latency could be as bad as several milliseconds.
For some devices the interrupt latency is more important than the actual interrupt service time. For example an input device may only interrupt the CPU once every 10 seconds. However that device may be incapable of holding the data on its input port for more than a millisecond. In theory any interrupt service time less than 10 seconds is fine; but the CPU must read the data within one millisecond of its arrival or the system will lose the data.
Low interrupt latency (that is responding quickly) is very important in many applications. Indeed in some applications the latency requirements are so strict that you have to use a very fast CPU or you have to abandon interrupts altogether and go back to polling. What a minute! Isn't polling less efficient than an interrupt driven system? How will polling improve things?
An interrupt driven I/O system improves system performance by allowing the CPU to work on other tasks in between I/O operations. In principle servicing interrupts takes very little CPU time compared the arrival of interrupts to the system. By using interrupt driven I/O you can use all those other CPU cycles for some other purpose. However suppose the I/O device is producing service requests at such a rate that there are no free CPU cycles. Interrupt driven I/O will provide few benefits in this case.
For example suppose we have an eight bit I/O device connected to two I/O ports. Suppose bit zero of port 310h contains a one if data is available and a zero otherwise. If data is available the CPU must read the eight bits at port 311h. Reading port 311h clears bit zero of port 310h until the next byte arrives. If you wanted to read 8192 bytes from this port you could do this with the following short segment of code:
mov cx 8192 mov dx 310h lea bx Array ;Point bx at storage buffer DataAvailLp: in al dx ;Read status port. shr al 1 ;Test bit zero. jnc DataAvailLp ;Wait until data is available. inc dx ;Point at data port. in al dx ;Read data. mov [bx] al ;Store data into buffer. inc bx ;Move on to next array element. dec dx ;Point back at status port. loop DataAvailLp ;Repeat 8192 times. . . .
This code uses a classical polling loop (
to wait for each available character. Since there are only three instructions in the
this loop can probably execute in just under a microsecond. So it might take as much as one microsecond to determine
that data is available
in which case the code falls through and by the second instruction
in the sequence we've read the data from the device. Let's be generous and say that takes
another microsecond. Suppose
we use a interrupt service routine. A well-written
ISR combined with a good system hardware design will probably have latencies measured in
To measure the best case latency we could hope to achieve would require some sort of hardware timer than begins counting once an interrupt event occurs. Upon entry into our interrupt service routine we could read this counter to determine how much time has passed between the interrupt and its service. Fortunately just such a device exists on the PC - the 8254 timer chip that provides the source of the 55 msec interrupt.
The 8254 timer chip actually contains three separate timers: timer #0 timer #1 and timer #2. The first timer (timer #0) provides the clock interrupt so it will be the focus of our discussion. The timer contains a 16 bit register that the 8254 decrements at regular intervals (1 193 180 times per second). Once the timer hits zero it generates an interrupt on the 8259 IRQ 0 line and then wraps around to 0FFFFh and continues counting down from that point. Since the counter automatically resets to 0FFFFh after generating each interrupt this means that the 8254 timer generates interrupts every 65 536/1 193 180 seconds or once every 54.9254932198 msec which is 18.2064819336 times per second. We'll just call these once every 55 msec or 18 (or 18.2) times per second respectively. Another way to view this is that the 8254 decrements the counter once every 838 nanoseconds (or 0.838 msec).
The following short assembly language program measures interrupt latency by patching into the int 8 vector. Whenever the timer chip counts down to zero it generates an interrupt that directly calls this program's ISR. The ISR quickly reads the timer chip's counter register negates the value (so 0FFFFh becomes one 0FFFEh becomes two etc.) and then adds it to a running total. The ISR also increments a counter so that it can keep track of the number of times it has added a counter value to the total. Then the ISR jumps to the original int 8 handler. The main program in the mean time simply computes and displays the current average read from the counter. When the user presses any key this program terminates.
; This program measures the latency of an INT 08 ISR. ; It works by reading the timer chip immediately upon entering ; the INT 08 ISR By averaging this value for some number of ; executions we can determine the average latency for this ; code. .xlist .386 option segment:use16 include stdlib.a includelib stdlib.lib .list cseg segment para public 'code' assume cs:cseg ds:nothing ; All the variables are in the code segment in order to reduce ISR ; latency (we don't have to push and set up DS saving a few instructions ; at the beginning of the ISR). OldInt8 dword ? SumLatency dword 0 Executions dword 0 Average dword 0 ; This program reads the 8254 timer chip. This chip counts from ; 0FFFFh down to zero and then generates an interrupt. It wraps ; around from 0 to 0FFFFh and continues counting down once it ; generates the interrupt. ; ; 8254 Timer Chip port addresses: Timer0_8254 equ 40h Cntrl_8254 equ 43h ; The following ISR reads the 8254 timer chip negates the result ; (because the timer counts backwards) adds the result to the ; SumLatency variable and then increments the Executions variable ; that counts the number of times we execute this code. In the ; mean time the main program is busy computing and displaying the ; average latency time for this ISR. ; ; To read the 16 bit 8254 counter value this code needs to ; write a zero to the 8254 control port and then read the ; timer port twice (reads the L.O. then H.O. bytes). There ; needs to be a short delay between reading the two bytes ; from the same port address. TimerISR proc near push ax mov eax 0 ;Ch 0 latch & read data. out Cntrl_8254 al ;Output to 8253 cmd register. in al Timer0_8254 ;Read latch #0 (LSB) & ignore. mov ah al jmp SettleDelay ;Settling delay for 8254 chip. SettleDelay: in al Timer0_8254 ;Read latch #0 (MSB) xchg ah al neg ax ;Fix 'cause timer counts down. add cseg:SumLatency eax inc cseg:Executions pop ax jmp cseg:OldInt8 TimerISR endp Main proc meminit ; Begin by patching in the address of our ISR into int 8's vector. ; Note that we must turn off the interrupts while actually patching ; the interrupt vector and we must ensure that interrupts are turned ; back on afterwards; hence the cli and sti instructions. These are ; required because a timer interrupt could come along between the two ; instructions that write to the int 8 interrupt vector. Since the ; interrupt vector is in an inconsistent state at that point this ; could cause the system to crash. mov ax 0 mov es ax mov ax es:[8*4] mov word ptr OldInt8 ax mov ax es:[8*4 + 2] mov word ptr OldInt8+2 ax cli mov word ptr es:[8*4] offset TimerISR mov es:[8*4 + 2] cs sti ; First wait for the first call to the ISR above. Since we will be dividing ; by the value in the Executions variable we need to make sure that it is ; greater than zero before we do anything. Wait4Non0: cmp cseg:Executions 0 je Wait4Non0 ; Okay start displaying the good values until the user presses a key at ; the keyboard to stop everything: DisplayLp: mov eax SumLatency cdq ;Extends eax->edx. div Executions mov Average eax printf byte "Count: %ld average: %ld\n" 0 dword Executions Average mov ah 1 ;Test for keystroke. int 16h je DisplayLp mov ah 0 ;Read that keystroke. int 16h ; Okay restore the interrupt vector. We need the interrupts off ; here for the same reason as above. mov ax 0 mov es ax cli mov ax word ptr OldInt8 mov es:[8*4] ax mov ax word ptr OldInt8+2 mov es:[8*4+2] ax sti Quit: ExitPgm ;DOS macro to quit program. Main endp cseg ends sseg segment para stack 'stack' stk db 1024 dup ("stack ") sseg ends zzzzzzseg segment para public 'zzzzzz' LastBytes db 16 dup (?) zzzzzzseg ends end Main
On a 66 MHz 80486 DX/2 processor the above code reports an average value of 44 after it has run for about 10 000 iterations. This works out to about 37 msec between the device signalling the interrupt and the ISR being able to process it. The latency of polled I/O would probably be an order of magnitude less than this!
Generally if you have some high speed application like audio or video recording or playback you probably cannot afford the latencies associated with interrupt I/O. On the other hand such applications demand such high performance out of the system that you probably wouldn't have any CPU cycles left over to do other processing while waiting for I/O.
Another issue with respect to ISR latency is latency consistency. That is is there the same amount of latency from interrupt to interrupt? Some ISRs can tolerate considerable latency as long as it is consistent (that is the latency is roughly the same from interrupt to interrupt). For example suppose you want to patch into the timer interrupt so you can read an input port every 55 msec and store this data away. Later when processing the data your code might work under the assumption that the data readings are 55 msec (or 54.9...) apart. This might not be true if there are other ISRs in the timer interrupt chain before your ISR. For example there may be an ISR that counts off 18 interrupts and then executes some code sequence that requires 10 msec. This means that 16 out of every 18 interrupts your data collection routine would collect data at 55 msec intervals right on the nose. But when that 18th interrupt occurs the other timer ISR will delay 10 msec before passing control to your routine. This means that your 17th reading will be 65 msec since the last reading. Don't forget the timer chip is still counting down during all of this that means there are now only 45 msec to the next interrupt. Therefore your 18th reading would occur 45 msec after the 17th. Hardly a consistent pattern. If your ISR needs a consistent latencies you should try to install your ISR as early in the interrupt chain as possible.
17.7.4 Prioritized Interrupts
Suppose you have the interrupts turned off for a brief spell (perhaps you are processing some interrupt) and two interrupt requests come in while the interrupts are off. What happens when you turn the interrupts back on? Which interrupt will the CPU first service? The obvious answer would be "whichever interrupt occurred first." However suppose the both occurred at exactly the same time (or at least within a short enough time frame that we cannot determine which occurred first) or maybe as is really the case the 8259 PIC cannot keep track of which interrupt occurred first? Furthermore what if one interrupt is more important that another? Suppose for example that one interrupt tells that the user has just pressed a key on the keyboard and a second interrupt tells you that your nuclear reactor is about to melt down if you don't do something in the next 100 msec. Would you want to process the keystroke first even if its interrupt came in first? Probably not. Instead you would want to prioritizes the interrupts on the basis of their importance; the nuclear reactor interrupt is probably a little more important than the keystroke interrupt you should probably handle it first.
The 8259 PIC provides several priority schemes but the PC BIOS initializes the 8259 to use fixed priority. When using fixed priorities the device on IRQ 0 (the timer) has the highest priority and the device on IRQ 7 has the lowest priority. Therefore the 8259 in the PC (running DOS) always resolves conflicts in this manner. If you were going to hook that nuclear reactor up to your PC you'd probably want to use the nonmaskable interrupt since it has a higher priority than anything provided by the 8259 (and you can't mask it with a CLI instruction).
Although writing ISRs can simplify the design of many types of programs ISRs are almost always very difficult to debug. There are two main reasons ISRs are more difficult than standard applications to debug. First as mentioned earlier errant ISRs can modify values the main program uses (or worse yet that some other program in memory is using) and it is difficult to pin down the source of the error. Second most debuggers have fits when you attempt to set breakpoints within an ISR.
If your code includes some ISRs and the program seems to be misbehaving and you cannot immediately see the reason you should immediately suspect interference by the ISR. Many programmers have forgotten about ISRs appearing in their code and have spent weeks attempting to locate a bug in their non-ISR code only to discover the problem was with the ISR. Always suspect the ISR first. Generally ISRs are short and you can quickly eliminate the ISR as the cause of your problem before trying to track the bug down elsewhere.
Debuggers often have problems because they are not reentrant or they call BIOS or DOS (that are not reentrant) so if you set a breakpoint in an ISR that has interrupted BIOS or DOS and the debugger calls BIOS or DOS the system may crash because of the reentrancy problems. Fortunately most modern debuggers have a remote debugging mode that lets you connect a terminal or another PC to a serial port and execute the debug commands on that second display and keyboard. Since the debugger talks directly to the serial chip it avoids calling BIOS or DOS and avoids the reentrancy problems. Of course this doesn't help much if you're writing a serial ISR but it works fine with most other programs.
A big problem when debugging interrupt service routines is that the system crashes immediately after you patch the interrupt vector. If you do not have a remote debugging facility the best approach to debug this code is to strip the ISR to its bare essentials. This might be the code that simply passes control on to the next ISR in the interrupt chain (if applicable). Then add one section of code at a time back to your ISR until the ISR fails.
Of course the best debugging strategy is to write code that doesn't have any bugs. While this is not a practical solution one thing you can do is attempt to do as little as possible in the ISR. Simply read or write the device's data and buffer any inputs for the main program to handle later. The smaller your ISR is the less complex it is the higher the probability is that it will not contain any bugs.
Debugging ISRs unfortunately is not easy and it is not something you can learn right out of a book. It takes lots of experience and you will need to make a lot of mistakes. There is unfortunately but there is no substitute for experience when debugging ISRs.
 There is no reason this has to be this way it's just that most people rarely run two programs at the same time which must both be accessing the serial port.
 As a general rule people begin to notice a real difference in performance between 25 and 50%. It isn't instantly obvious until about 50% (i.e. running at one-half the speed).
 On a fast
100 MHz Pentium)
you might expect this loop to execute in much less time than
one microsecond. However
in instruction is probably going to be quite
slow because of the wait states associated with external I/O devices.
 Patching into the int 1Ch interrupt vector produces latencies in the 137 msec range.
Chapter Seventeen: Interrupts
and Exeptions (Part 4)
29 SEP 1996