At the core of the SYS/BIOS hardware interrupt is an essential piece of technology called the interrupt dispatcher. The dispatcher makes it possible for hardware interrupts to be run properly with other BIOS threads in the system and provides other benefits, such as optimization and ease of use. When a Hwi is created in a system, the location of the dispatcher is what is patched into the interrupt vector table, while the address of the interrupt service routine, the interrupt mask, and other Hwi parameters are stored in the dispatch table data structure. If any interrupts preempt one another, an interrupt stack is used to save the context.  There are a number of benefits to using the interrupt dispatcher. Because the dispatcher is a piece of code common to all of the interrupt handling, it can help reduce the code size footprint of the system. If task threads, each with their own stack, are being used, then the fact that the dispatcher is using a separate stack for interrupts means that each of the task stacks can be smaller. One critical reason for using the interrupt dispatcher is that it is knowledgeable about the SYS/BIOS scheduler; this means other lower priority threads will be properly disabled while the high priority interrupt service routines are executing. If any threads (such as Tasks or Swi’s) are made ready to run by the ISR and are a higher priority than the thread that the Hwi preempted, then those high priority threads will properly preempt the lower priority thread. In addition, the interrupt dispatcher allows the user to enable some instrumentation that will track when interrupts occur. Note that use of the dispatcher is not mandatory – particularly if no SYS/BIOS APIs are called from within the ISR. Although the dispatcher is implemented by SYS/BIOS, there is good value in seeing what actually goes on inside, so this module will now spend a few minutes walking through the dispatcher execution. The first thing that the dispatch does after it is vectored to is disable the Task scheduler. The reason for this is that it is undesirable for any Tasks that are made ready to run to preempt the hardware interrupt processing, since Hwi’s by definition are treated as an implicitly higher priority thread. Additionally, if the Task module is not enabled, Task_disable() is optimized out of the dispatcher in order to make the execution of the dispatcher as efficient as possible. It was mentioned before that one benefit of the dispatcher is that it maintains a separate stack for interrupt processing. If the stack pointer is currently pointing to a Task stack, this is the time it switches to the interrupts stack. The dispatcher also stores away the interrupt return pointer in case the user needs to retrieve it using the getIrp API call. This is another step that can be optimized out if there is no need to ever take that API call. Like the Task scheduler, the Swi scheduler is also disabled so that any software interrupts that are made ready to run will be deferred. Similar to Tasks, if Swi’s are disabled, this call to Swi_disable will be optimized out if the Swi module is not enabled. Developers have the option of attaching “hook functions” to the Hwi for instrumentation or other purposes. At this point in the process, the Hwi Hook begin function is called. Another hook function is potentially called at this point if one was configured to run.Then at this point, the Swi scheduler is run to allow execution of any higher priority software interrupts that are ready to run. If Tasking is enabled, the stack pointer is then switched back from the interrupt stack to the Task stack. Finally the Task scheduler is run. One final note: when developers are writing a generic ISR, they use the compiler interrupt keyword so that context is saved properly to the stack. However, when using a SYS/BIOS Hwi, the dispatcher is already taking care of saving the thread context, so if the interrupt keyword is used in a Hwi, it will cause a catastrophic runtime failure in the code.