x86 summary of interrupts and exceptions

< >80386 interrupts and exceptions 8086/8088 interrupts are divided into two categories: internal interrupt and external interrupt. To support functions such as multitasking and virtual memory, 80386 external interrupts are called "interrupts", and internal interrupts are referred to as "exceptions". As with 8086/8088, 80386 typically responds to interrupts or exceptions between two instructions. 80386 handles up to 256 interrupts or exceptions. 1. Interrupts for 80386, interrupts are caused by asynchronous external events. External events and interrupt responses are not related to the instructions being executed. Typically, an interrupt is used to indicate that an I/O device has completed a single operation. As with 8086/8088, 80386 has two pins intr and NMI accept external interrupt request signals. Intr accepts a masked interrupt request. NMI accepts a non-blocking interrupt request. In 80386, the IF flag in the flag register eflags determines whether masking can mask interrupt requests. The external hardware also gives a 8-bit interrupt vector to the processor while the interrupt request signal is sent through the intr. When the processor responds to a masked interrupt request, it reads the interrupt vector number given by the external hardware. The processor does not specify this interrupt vector number. However, in the specific microcomputer system, the system must be set up by software and hardware, so that the interrupt vector number is not only corresponding to the external interrupt source, but also avoids the occurrence of the interrupt vector number using the conflict condition. Programmable Interrupt Controller chip 8259A can work with 80386, can provide the above interrupt vector number to the processor according to the setting, also can handle interrupt request priority. Each 8259A chip can support 8 interrupt request signals, and if 9 8259A chips (one main slice, 8 slave slices) are used, 80386 can receive interrupt request signals of up to 64 interrupt sources on a single pin intr. The processor does not block interrupt requests from NMI. The processor does not receive the interrupt vector number from the external hardware when responding to an NMI interrupt. As with 8086/8088, in 80386, the interrupt vector number corresponding to the non-shielded interrupt is fixed to 2. In order to mask an interrupt's nesting, the processor masks the internal mask once again in response to the NMI when an NMI interrupt is accepted, and the masking process does not end until the execution of the interrupt returns instruction Iret. Therefore, the NMI handler should end with the iret instruction. 2. Abnormal anomalies are caused by 80386 of unusual or illegal conditions detected during the execution of the instruction. The exception is directly related to the command being executed. For example, when you execute a division instruction, the divisor equals 0. Again, when executing the instruction, the privilege level is found to be incorrect. When these conditions occur, the instruction cannot be completed successfully. The soft interrupt instruction "INT n" and "into" are also categorized as exceptions rather than interrupts, because executing these instructions produces an exception event. 80386 identify many different categories of exceptions and give each category a different interrupt vector number. After an exception occurs, the processor handles the exception as if it were a response interrupt. That is, according to the interrupt vector number, the corresponding interrupt handler. It may be more appropriate to refer to this interrupt handler as an exception handler. The exception is further categorized as failure (Fault), Trap, and Abort (abort), depending on whether the program that caused the exception can be recovered and the recovery point is different. We refer to the corresponding exception handlers as fault handlers, trap handlers, and abort handlers, respectively. A fault is an exception that is notified to the system before the instruction that caused the exception. 80386 The fault is considered to be excluded. When control is transferred to the fault handler, the values of the saved Breakpoint CS and Eip point to the instruction that caused the failure. In this way, when the fault handler is troubleshooting, execution Iret returns to the program that caused the failure to continue execution, and the instruction that caused the failure has been re-executed. This re-execution does not require additional involvement of the operating system software. The discovery of a failure may occur before the instruction is executed, or during the execution of the instruction. If a failure is detected during instruction execution, abort the failure instruction and return the operand of the instruction to the value before the instruction begins execution. This ensures that the re-execution of the fault instruction results in the correct result. For example, during the execution of an instruction, if the discovery segment does not exist, then stop the execution of the instruction, and notify the system to produce a segment fault, the corresponding segment fault handler can be loaded by the method of the segment to troubleshoot, then the original instruction can be executed successfully, at least no longer the failure of the segment does not exist. A trap is an exception that is notified to the system after the instruction that caused the exception. When control is transferred to the exception handler, the values of the saved Breakpoint CS and Eip point to the next instruction to be executed for the command that caused the trap. The next instruction to be executed is not necessarily the next one. Therefore, the trap handler does not always determine the instruction that produces the exception based on the saved breakpoint. When the trap handler is transferred, the command that causes the trap should complete normally, and it may change the register or memory unit. Soft interrupt instructions, single-step exceptions are examples of traps. Abort is an exception that notifies the system when a system is in serious condition. The command that caused the abort is not deterministic. When a abort occurs, the executing program cannot be resumed. After the system receives the abort, the handler is re-establishing various system tables and may restart the operating system. Hardware failures and illegal values or inconsistent values in the system tables are examples of aborts. 3. Priority during the execution of an instruction, in which more than one interrupt or exception is detected, the system is notified by the priority level listed in the following table. The highest priority interrupt or exception notification system, other lower-priority exceptions are discarded, and higher-priority interrupts remain suspended.

80386 response Interrupts/exceptions The priority level	Interrupt/Exception type	Priority level
	Debug failure	Highest
	Other faults	↓
	Trap instruction int N and into	↓
	Debugging traps	↓
	NMI Interrupt	↓
	Intr Interrupt	Minimum

< two > Exception types like interrupts are divided into multiple types, and exceptions can be categorized into multiple types. 1.80386 The identified exception 80386 identifies the various categories of exceptions and assigns the corresponding interrupt vector numbers as shown in the following table. Some exceptions also provide some additional information in the form of an error code to the exception handler, and the "none" in the error code column means there is no error code, and "There" indicates an error code.

Vary Often One Overview Table	Vector number	Exception name	Exception type	Error code	Related directives
	0	Division Error	Fault	No	Div,idiv
	1	debugging exceptions	Fault/Trap	No	Any instruction
	3	Single byte INT3	Trap	No	INT 3
	4	Overflow	Trap	No	Into
	5	Boundary check	Fault	No	Bount
	6	Illegal operation code	Fault	No	Illegal instruction code or operand
	7	Device Not available	Fault	No	Floating point instruction or wait
	8	Double fault	Stop	Yes	Any instruction
	9	Coprocessor segment out of bounds	Stop	No	Floating point instructions for accessing memory
	0AH	Invalid TSS anomaly	Fault	Yes	JMP, call, Iret, or interrupts
	0BH	Segment does not exist	Fault	Yes	Instructions for loading segment registers
	0CH	Stack Segment exception	Fault	Yes	Any instruction that loads the SS register, any instruction that is accessed by the SS addressed segment
	0DH	General Protection exceptions	Fault	Yes	Any privileged instruction, any instruction to access the memory
	0EH	Page exception	Fault	Yes	Any instruction to access the memory
	00)	Coprocessor Error	Fault	No	Floating point instruction or wait
	11h-0ffh	Soft interrupt	Trap	No	INT N

As can be seen from the above table, the allocation of some interrupt vector numbers in protected mode conflicts with the interrupt vector number of real mode. The assignment of interrupt vector number in real mode is based on the 8086/8088 CPU of PC microcomputer system, and the allocation of interrupt vector number in the above table is 80386. In fact, when Intel announces 8086/8088, it retains these conflicting interrupt vector numbers. Despite this conflict, a 80386 CPU-based microcomputer system can still be compatible with a 8086/8088 CPU-based microcomputer system, because in the real mode of 80386, there are almost no exceptions to the interrupt vector number that is provided when the interrupt vector number and external hardware interrupt request occur.It is important to note that the 8259A interrupt controller must be reset in protected mode to produce a hardware interrupt vector that does not conflict with the exception. 2. Fault class exception When a failure occurs, the control moves to the fault handler, and the values of the saved Breakpoint CS and Eip point to the instruction that caused the failure, so that the execution resumes after the troubleshooting. (1) Division error Fault (exception 0) Division error is a fault. This failure occurs when a div instruction or idiv instruction is executed, if the divisor equals 0 or the quotient is too large to hold the operator's operand. Division error failure does not provide an error code. (2) Boundary Check Fault (exception 5) If the bound instruction finds that the value being tested exceeds the range given in the instruction, a boundary check failure occurs. The boundary check fault does not provide an error code. (3) Illegal Operation code failure (Exception 6) if the CS and Eip point to the storage unit of the bit pattern is recognized as part of an instruction, then an illegal operation code failure occurs. Such a failure occurs when: (1) The contents of the opcode field are not a valid 80386 instruction code, (2) where the memory operand is required, the register operand is used, and (3) the lock prefix is used before the command that cannot be locked. Operation code is not provided for illegal opcode failure. (4) The device is not available fault (exception 7) device is not available fault support 80387 digital coprocessor. In systems that do not have 80387 coprocessor hardware, the exception handler can be used in place of the coprocessor's software emulator. When a task switch occurs, a 80387 register state switch is made only when a new task uses a floating point instruction. Device unavailable failure does not provide an error code. The fault occurs in the following cases: (1) when the floating point instruction is executed, the EM bit or TS bit in the control register CR0 is 1, and (2) when the wait instruction is executed, the TS bit and the EM bit are 1 in the control register CR0.It should be noted that the handler for this exception must be a process and not a task, or 80386 will set the TS bit when the handler publishes a iret instruction. The coprocessor then executes the failed instruction again and finds that the TS is set, so the exception 7 occurs again, and the result is an endless loop. Handlers can be called through trap gates because interrupts can be allowed during execution. (5) Invalid TSS failure (Exception 0AH) when the TSS is loaded from the task status segment, if a segment exception occurs except for a segment that does not exist, an invalid TSS failure occurs. When entering the fault handler, the saved CS and Eip point to the failed instruction, or to the first instruction of the task when it occurs as part of the task switch. An invalid TSS failure provides an error code, as shown in the format of the error code. The selected sub-section is a selector pointing to the TSS that caused the failure. The main component of the 16-bit error code is the selector, which points to the selection of the TSS that caused the failure. The high 13 bits are the index portion of the selector, and the TI bit is the descriptor indicator bit.

Format of the error code
Bit15-bit3	BIT2	BIT1	BIT0
Select the index portion of the child	TI	IDT	EXT

The error code format shown is the general format of the error code when the exception occurs. Visible error code does not contain the RPL of the selector, but is replaced by the IDT bit and ext bit. When an exception or an external interrupt is handled, an exception occurs, and the ext position is 1. When a table entry is read from the interrupt descriptor sheet IDT and an exception is generated, IDT position 1, which occurs only during the processing of interrupts or exceptions. When no selection is made, the value of the selection sub-component of the error code is 0. Some of the causes of invalid TSS failures are as follows: The length limit in the TSS descriptor is less than 103, the invalid LDT descriptor, or the LDT does not appear, the stack segment is not a writable segment, and the descriptor for the stack segment selection sub-index is beyond the descriptor list bounds; The stack segment DPL does not match the new Cpl The RPL of the stack segment selector is not equal to CPL, the descriptor of the code snippet Selection sub-index is beyond the descriptor descriptor, the code snippet selector does not point to the code snippet, the DPL of the non-Uniform code fragment is not the new CPL, the DPL of the Uniform Code fragment is greater than the new Cpl; The FS or GS selector points to an unreadable segment (such as a system segment), and the descriptor for the selected sub-index of the DS, ES, FS, or GS exceeds the bounds of the descriptor descriptor. (6) There is no fault (exception 0BH) processor when the descriptor is loaded into the non-SS segment of the cache, if the descriptor is found to be valid other aspects, and the P-bit is 0 (indicating that the corresponding segment does not exist), then in reference to this descriptor there is no fault in the segment. The case of the SS segment is included in the stack segment failure. When entering the fault handler, the saved CS and EIP execute the failed instruction, or the fault occurs as part of the task switch, pointing to the first instruction of the task. Segment not present a failure provides an error code that contains the segment selector that caused the failure. The format of the error code is as shown. Select the sub-index section to index the segment descriptor selector that causes the segment to fail. (7) Stack segment failure (Exception 0CH) a stack segment failure occurs when the processor detects some problem with the segment addressed by the SS register. When entering the fault handler, the saved CS and Eip point to the failed instruction, or to the first instruction of the task when it occurs as part of the task switch. The stack segment fault provides an error code, and the format of the error code is the same. Specifically, a stack segment failure occurs when the following three cases occur: (1) When the stack operation, the offset exceeds the range specified by the segment bounds. The error code in this case is 0. For example, when the push operation, the stack overflows. (2) When an internal stack operation is caused by a privilege-level transformation, the offset exceeds the range specified by the segment bounds. The error code in this case contains a selector with an inner stack. (3) The presence bit in the descriptor that is loaded into the SS register (high-speed buffer register) is 0. The error code in this case contains the corresponding selector. The first of these cases is easily identifiable. The second and third cases are identified by judging the error code that contains the selection sub-The presence bit in the descriptor of the indicator. If there is a bit of 1, then the second case, otherwise it is the third case. (8) General Protection Fault (exception 0DH) in addition to the explicitly listed segment anomalies, other segment anomalies are considered general protection failures. When entering the fault handler, the saved CS and Eip point to the failed instruction, or to the first instruction of the task when it occurs as part of the task switch. The General Protection fault provides an error code, and the format of the error code is as shown. According to the possible response of the handler, the general protection fault can be divided into the following two categories: (1) Violation of the protection method, but the program does not need to abort the exception. This type of failure provides an error code of 0. This exception occurs when an application performs privileged instructions or I/O access, a system that supports a virtual 8086 program, or a system that supports virtual I/O access needs to emulate these instructions and re-execute the interrupted program after the simulation has completed the failed instruction. (2) An exception that violates the protection method and causes the program to terminate. This type of failure may provide an error code of 0, or it may not be 0 (determines the selection). Some of the reasons for this type of failure are: write to a read-only data segment or code snippet, read from a code snippet that can only be executed, load a system segment descriptor into the data segment register DS, ES, FS, GS, or SS, transfer control to a non-executable segment, and pass the segment register CS, DS, ES, When FS or GS accesses memory, the offset exceeds the bounds of the segment, and when a descriptor is accessed, the limit of the descriptor block is exceeded, and the control information with a PG bit of 1 but PE bit 0 is loaded into the CR0 register; switch to a busy task. The identification of the above two types of general protection faults can be carried out by checking the instruction and error code that caused the failure. If the error code is not 0, then it must be the second type of general protection failure. If the error code is 0, you need to further examine the instruction that caused the failure to determine whether it is a system-supported, simulated instruction. (9) Page fault (exception 0EH) for a detailed description of the page failure, see the following article. (10) Coprocessor error (Exception 10H) coprocessor failure indicates that the coprocessor has an unshielded digital error, such as overflow or underflow. The next floating-point instruction or wait instruction after the failed floating-point instruction causes the coprocessor error to be notified to the system as a fault. No error code is provided for coprocessor error failure. 3. Trap class Exception (1) Debug Trap (Exception 1) Debug exception has fault type, also has trap type. The debugger can access the debug register DR6 to determine the cause and type of the debug exception. Debug exceptions do not provide an error code. (2) Single byte INT3 (Exception 3) INT3 is a special single-byte "INT n" directive. The debugger can take advantage of this directive to support program breakpoints. The INT3 directive is seen as a trap, not an interruption. When the INT3 instruction is executed to enter the exception 3 handler, the saved CS and Eip point to the instruction immediately following the INT3, i.e.The bytes behind the INT3. The INT3 trap does not provide an error code. (3) Overflow (exception 4) into instruction provides conditional traps. If the of flag is 1, then the into command generates a trap, otherwise it does not generate a trap and proceeds to the instruction following into. When entering the overflow handler, the saved CS and Eip point to the next instruction in the into instruction. Overflow traps do not provide an error code. 4. Abort class exception (1) Double fault exception (exception 8) When an exception is being handled by the system, if an exception is detected, the processor attempts to notify the system of a double failure instead of notifying the second exception. A double fault is an abort class exception, so the saved CS and EIP may not point to the instruction that caused the double failure, and the restart of the instruction does not support a double fault when it is transferred to the dual fault handler. The error code provided by the double fault is 0. When a segment fault exception is being processed, a page failure may occur. In this case, the notification to the system is a page fault exception rather than a double-fault exception. However, if a segment failure or page failure is being handled, another segment failure is detected, or if a page failure is being processed, another page failure is detected, causing a double failure. When a double fault is being processed and another segment or page fault is detected, the processor pauses the instruction and enters the shutdown mode. The shutdown mode is similar to the state of the processor instruction after a HLT instruction: The processor is idling and is maintained until the processor receives an NMI interrupt request or is restarted. In shutdown mode, the processor does not respond to INTR interrupt requests. A double fault usually indicates a serious problem with the system table, such as a Segment Descriptor table, a page table, or an interrupt descriptor list. The dual-fault handler may have to restart the operating system after rebuilding the system tables. (2) coprocessor segment out of bounds (Exception 9) coprocessor segment out-of-bounds exception belongs to abort class exception, because the instruction that caused the exception cannot be restarted. The abort exception is generated when the floating-point instruction operand exceeds the bounds of the segment. The coprocessor segment out-of-bounds exception does not provide an error code. CS and Eip saved in the exception handler entry point to the aborted instruction. This stop is not a system abort, but a program that only affects the instructions that are executing when the exception is detected. < three > Interrupt and Exception Transfer method 80386 the interrupt and exception transfer method in real mode is the same as 8086. The interrupt and exception transfer methods described here refer to the transfer method used when 80386 responds to interrupts and handles exceptions in protected mode. 1. Interrupt descriptor descriptor for IDT, like 8086/8088, when responding to an interrupt or handling an exception, 80386 goes to the corresponding handler based on the interrupt vector number. However, in protected mode, 80386 does not use the interrupt vector table in real mode, but instead uses the interrupt descriptor sheet IDT. In protected mode, the 80386 interrupt vector number is used as the index of the descriptor in the interrupt descriptorThe index of the interrupt vector in the interrupt vector table. Like the Global Descriptor Descriptor (GDT), in the entire system, the interrupt Descriptor list IDT has only one. The Interrupt Descriptor Descriptor Register IDTR indicates the location of IDT in memory. Since 80,386 recognizes only 256 interrupt vector numbers, the IDT maximum length is 2K. Interrupt Descriptor Descriptor IDT contains descriptors that can only be interrupt gates, trap doors, and task gates. In other words, in protected mode, 80,386 can only be transferred to the corresponding interrupt or exception handler by means of an interrupt gate, trap Gate, or task gate. The format of the gate descriptor given in the previous article is visible, and the door descriptor contains a 48-bit full pointer consisting of a selector and an offset. In addition, the double-word count field is meaningless for interrupt gate, Trap Gate and task gate. 2. Steps for interrupt response and exception handling the interrupt response and exception handling that are automatically implemented by the hardware are as follows: first, determine whether the gate descriptor to be indexed by the interrupt vector number is outside of IDT's bounds. If the limit is exceeded, the general protection fault is caused, and the error code is the interrupt vector number multiplied by 8 plus 2. Secondly, the corresponding gate descriptor is obtained from IDT, and the selection sub-, offset and descriptor attribute types are decomposed and checked. Descriptors can only be task Gate, 286 interrupt gate, 286 trap Gate, 386 interrupt gate or 386 trap gate, otherwise it will cause general protection fault, error code is interrupt vector number multiplied by 8 plus 2. If the transfer is caused by an int n instruction or into instruction, also check if the DPL in the interrupt gate, Trap Gate, or task Gate descriptor satisfies CPL&LT;=DPL (for other exceptions or interrupts, the DPL in the door is ignored). This check avoids the use of interrupt vector numbers assigned to various devices when an application executes an int n instruction. If the check does not pass, it causes the general protection fault, the error code is the interrupt vector number multiplied by 8 plus 2. The P-bit in the gate descriptor must be 1, which means that the gate descriptor is a valid entry, otherwise it causes no fault in the segment, and the error code is the interrupt vector number multiplied by 8 plus 2. Finally, depending on the type of the gate descriptor, the interrupt or exception handler is transferred in a split case. For exception handling, the return point is determined based on the exception type before starting the above steps, and if there is an error code, the error codes are formed in the format of the error code and the error code is pressed onto the stack before the exception handler is actually executed. To ensure the double-word boundary alignment of the stack, the 16-bit error code is pressed with a 32-bit value, where the high 16-bit value is undefined, as is the case for 16-bit segments. 3. By interrupting the gate or the trap gate if the interrupt vector number indicates that the gate descriptor is 386 interrupt gate or 386 trap gate, then control shifts to a handler procedure for the current task and can transform the privilege level. As with other call commands that invoke the gate, get a 48-bit full pointer to the handler from the interrupt gate and trap gate. Where the 16-bit selector is the selector for the corresponding handler or code snippet, which indicates the description of the code snippet in the Global Descriptor List GDT or the local descriptor descriptor in the LDTThe 32-bit offset indicates the offset of the handler entry point within the code snippet. The transfer process by interrupting the gate or trap gate is shown below, the process is automated by hardware 。 (1) If the selection of the null, the general protection failure occurs, (2) The corresponding descriptor, (3) is not a storage segment descriptor, resulting in a general protection failure, (4) not a consistent code snippet and DPL (5) Adjust rpl=0; (6) load the descriptor into CS; (7) A general protection failure occurs if the ingress offset crosses ; (8) The eflags is pressed into the stack, (9) The CS is pressed into the stack; (11) The EIP is pressed into the stack; (12) If the gate is interrupted, the if=0 is made; (13) If there is an error code, the error code is pressed into the stack; (14) transferred to the processing program. As is visible from the above transfer process, the selector that indicates the handler in the interrupt gate or trap Gate must point to a descriptor that describes an executable code snippet. If the selected sub is empty, it causes a general protection failure, and the error code is 0. If the descriptor is not a code snippet descriptor, it causes a general protection failure, and the error code contains the selector. Interrupts or exceptions can be transferred to the same privilege level or an inner level privilege level. The type and the DPL field in the descriptor of the specified handler code snippet above determine whether the transfer within this same task will occur with a privilege level transformation. If it is a non-uniform code snippet, and dplcpl generates a generic protection exception. The sixth step in the transfer process, that is, "loading the descriptor CS" refers to the description of the specified handler segment is loaded into the high-speed buffer Register of CS, in this step to the descriptor is similar through the call gate for the transfer of other checks, including whether the code snippet descriptor and the code snippet descriptor exists, etc. Therefore, the exception may occur again. When the descriptor is checked, the rpl=0 of the selected child in the gate (adjusted internally within the processor without affecting the RPL field of the selector in memory) is implemented to consider only the code snippet of DPL, regardless of the rpl of the selector in the gate. After the descriptor is loaded into CS, the gate descriptor is also checked to indicate whether the offset of the handler code snippet entry is out of bounds, that is, whether the segment bounds are exceeded. If it is out of bounds, it causes a general protection failure of error code 0. As you can see from the transfer process, the procedure and order of pressing the flag register and the breakpoint into the stack is the same as the real mode, but each time the stack operation is a double word, CS is expanded to 32 bits. This is also true in the 16-bit segment. The TF is set to 0, which means that the handler is not allowed to step into execution. The NT is set to 0, indicating that the handler returns to the same task instead of a nested task when it returns using the interrupt return instruction Iret. It is important to note that any privileged-level program can change the NT bit so that the interrupt or trap handler can be used to complete the task switch. The difference between the transfer of the interrupt gate and the transfer through the trap gate is only the handling of the IF flag. For an interrupt gate, the if is set to 0 during the transfer so that the INTR interrupt is masked during the execution of the handler (of course, an if flag can be opened in the interrupt handler to allow the response to be enabled during the execution of the handlershielded interrupt); for trap doors, keep the if bit constant during the transfer, i.e. if the IF bit turns out to be 1, the intr interrupt is allowed after the trap gate is transferred to the handler. Therefore, the interrupt gate is best suited for processing interrupts, while trap doors are suitable for handling exceptions. In the case of an error code, the error code is pressed into the stack before being transferred to the handler. Only exception handling can have error codes. The stack condition is given when the gate or trap gate is transferred through an interrupt. (a) There is no change of privilege level and no error code, (b) There is no change of privilege level with error code, (c) is the case of transforming the privilege level and the inner stack without error codes. (d) is an inner stack case that transforms the privileged level and has an error code. Note that each item in the figure is a double word. 4. Transfer of mission Gate if the interrupt vector number is simply the gate descriptor of the task Gate descriptor, then the control is transferred to a handler that appears as a separate task mode. The selector in the task gate is the selector for the TSS segment that describes the corresponding handler task, that is, the selector indicates an available 286TSS or 386TSS. The transfer of a task gate to a usable 386TSS segment via the mission door is similar to the shift of the call to the switch, the main difference being that for exception handling that provides the error code, after the task switch is completed, the error code is pressed into the stack of the new task (when the task gate is transferred, Returns the address and the stack that the outer stack pointer does not press into the new task). With the transfer of the task gate, when entering an interrupt or exception handler, the NT bit in the flag register EFlags is set to 1, which indicates that the task is nested, and the iret instruction returns to the last suspended task along the Link field in the TSS. Use the task gate to provide an automatic dispatch of a handler task when responding to an outage or handling an exception. This task scheduler is executed directly by the hardware and crosses the software task switch contained in the operating system, which provides a quick task switch for the handler. 5. Comparison of the transfer methods to interrupt response and exception handling, 80386 allows processing by using an interrupt gate or trap door implementation by a process within the current task, or by another task by using the task Gate implementation. The handlers within the current task are simpler and can be quickly transferred to the handler, but the handlers are responsible for saving and recovering the processor's registers and so on. Handlers that go to different tasks take a long time to save and restore the contents of the processor register as part of the task switch. Using the methods of handlers in the current task, the State of the executing task is accessed directly when the response is interrupted or handled, but this requires that a handler be included within each task. With the processing of independent tasks, the handlers are better isolated, but access to the original task state becomes more complex when the response is interrupted or the exception is handled. It is important to note that some exceptions must be handled by an interrupt gate or trap gate, as mentioned above with exception 7. Invalid TSS anomalies must be handled using a task gate to ensure that the handler has an effective task environment. Other anomalies are usually handled within the task environment. Within the task, the exception is detected and the interrupt does not have to be masked, so the trap door is used. The exception handler indicated by the trap gate is a process shared by all tasks, so the handler is best placed within the global address space. If each task requires a different handler, the global exception handler can hold an Entry table for each handler and invoke the appropriate handler for the task that caused the exception. Interrupts are usually not related to the task being performed and may benefit from using the isolation provided by the task gate. Interrupts that require a faster response can beTo a better deal. Because interrupts can occur at any time, the interrupt handler that is accessed through the interrupt gate must be placed in the global address space so that all tasks are valid. It is also important to emphasize that the 80386 program must not invoke a low-privileged procedure, which enforces the same rules when the processor invokes an interrupt or exception handler, so that such a procedure has at least the same privileged level as the procedure called in its task context that is the highest privilege level performed by the task. Therefore, when using an interrupt gate, the interrupt handler must usually be scheduled at privileged level 0, or if an interrupt occurs while the privilege level 0 is executing, it cannot enter the interrupt handler, which can cause a general protection failure (except when the interrupt handler uses the task Gate). Because task switching can switch from any privileged level to any privileged level of the target task. 6. Return interrupt after interrupt or exception handling return instruction Iret used to return from an interrupt or exception handler. The execution of this instruction is based on the task nesting flag whether the NT bit is 1 in two cases. The NT bit is 1, which indicates the return of the nested task. The link field in the current TSS holds the TSS selector for the previous task, and the selection is removed for task switching to complete the return. This situation occurs when the interrupt or exception handler that is transferred through the task gate returns, because the NT bit is cleared 0 when the interrupt gate or trap gate is transferred to the handler. The NT bit is 0, which indicates the return within the current task. This situation occurs when the interrupt or exception handler that is transferred through the interrupt gate or trap gate is returned. Specific actions include: Eject the pointer from the top of the stack, EIP and CS, and then pop the eflags value. The RPL field that pops up the CS selector determines the privileged level after the return. If the RPL of the returned selector is the same as the CPL, no privilege level changes are made. If the RPL specifies an outer privilege level, then a privilege level change is required, and the value of ESP and SS is popped out of the stack of layers from the inner stack. These practices are similar to RET directives. For example, using CS to select the RPL of a child instead of a DPL by selecting the segment of the sub-identity, is to return to a consistent code snippet that is not at the given privileged level in DPL. If the RPL of the selected CS of the pop-up specifies an inner privilege level, a general protection failure is generated. Note that for the Iret directive, the Select subfield of the return address saved in the current stack must point to the snippet descriptor. It cannot be a system segment or a door descriptor. Failure to do so will cause general protection failures. For an exception handler that provides an error code, the error code must be manually popped out of the stack before the iret instruction is executed, and the error code is not automatically ejected or canceled by the processor. The interrupt return instruction Iret can be used not only for the return of nested tasks caused by interrupts/exceptions, but also for the return of nested tasks caused by the invocation of a command call through a task gate, as described earlier, when invoking a command call between segments that perform a task switch through a task gate, the flag ParkThe NT bit in the device is set to 1, which indicates that the task is nested. The RET directive does not implement this function.

X86 summary of interrupts and exceptions