Alternate fault handler

Details Alternate fault handler Alternate fault handler

1999-10-29

2002-08-27

Beausoleil, Robert (Department: 2785)

Error detection/correction and fault detection/recovery

Data processing system error or fault handling

Reliability and availability

C714S023000, C712S244000

Reexamination Certificate

active

06442707

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention is related to the field of processors and, more particularly, to exception handling within processors.
2. Description of the Related Art
Microprocessor designers often design their products in accordance with the x86 microprocessor architecture in order to take advantage of its widespread acceptance in the computer industry. Because the x86 microprocessor architecture is pervasive, many computer programs are written in accordance with the architecture. X86 compatible microprocessors may execute these computer programs, thereby becoming more attractive to computer system designers who desire x86-capable computer systems. Such computer systems are often well received within the industry due to the wide range of available computer programs.
The x86 microprocessor architecture specifies a variable length instruction set (i.e. an instruction set in which various instructions employ differing numbers of bytes to specify that instruction). For example, the 80386 and later versions of x86 microprocessors employ between 1 and 15 bytes to specify a particular instruction. Instructions have an opcode, which may be 1-2 bytes, and additional bytes may be added to specify addressing modes, operands, and additional details regarding the instruction to be executed. Certain instructions within the x86 instruction set are quite complex, specifying multiple operations to be performed. For example, the PUSHA instruction specifies that each of the x86 registers be pushed onto a stack defined by the value in the ESP register. The corresponding operations are a store operation for each register, and decrements of the ESP register between each store operation to generate the address for the next store operation.
Often, complex instructions are classified as MROM instructions. MROM instructions are transmitted to a microcode unit within the microprocessor, which decodes the complex MROM instruction and produces two or more simpler microcode instructions for execution by the microprocessor. The simpler microcode instructions corresponding to the MROM instruction are typically stored in a read-only memory (ROM) within the microcode unit. The microcode unit determines an address within the ROM at which the microcode instructions are stored, and transfers the microcode instructions out of the ROM beginning at that address. Multiple clock cycles may be used to transfer the entire set of instructions within the ROM that correspond to the MROM instruction. Different instructions may require differing numbers of microcode instructions to effectuate their corresponding functions. Additionally, the number of microcode instructions corresponding to a particular MROM instruction may vary according to the addressing mode of the instruction, the operand values, and/or the options included with the instruction. The microcode unit issues the microcode instructions into the instruction processing pipeline of the microprocessor. The microcode instructions are thereafter executed in a similar fashion to other instructions. It is noted that the microcode instructions may be instructions defined within the instruction set, or may be custom instructions defined for the particular microprocessor. Of course the use of microcode is not limited to x86 microprocessors. Many different types of microprocessors employ microcode units.
Conversely, less complex instructions are decoded by hardware decode units within the microprocessor, without intervention by the microcode unit. The terms “directly-decoded instruction” and “fastpath instruction” will be used herein to refer to instructions which are decoded and executed by the microprocessor without the aid of a microcode unit. As opposed to MROM instructions which are reduced to simpler instructions which may be handled by the microprocessor, directly-decoded instructions are decoded and executed via hardware decode and functional units included within the microprocessor.
Another use of microcode is in exception handling. An exception may occur in a processor when the processor is unable to complete an instruction. For example, an exception may be generated from a divide instruction when the divisor is zero. Also, an exception may be generated if an invalid opcode is detected by the execution unit. Other type of exceptions may occur from memory operations. The term “memory operation” is an operation which specifies a transfer of data between a processor and memory (although the transfer may be accomplished in cache). Load memory operations specify a transfer of data from memory to the processor, and store memory operations specify a transfer of data from the processor to memory. Load memory operations may be referred to herein more succinctly as “loads”, and similarly store memory operations may be referred to as “stores”. Memory operations may be implicit within an instruction which directly accesses a memory operand to perform its defined function (e.g. arithmetic, logic, etc.), or may be an explicit instruction which performs the data transfer only, depending upon the instruction set employed by the processor. Generally, memory operations specify the affected memory location via an address generated from one or more operands of the memory operation. This address will be referred to herein in as a “data address” generally, or a load address (when the corresponding memory operation is a load) or a store address (when the corresponding memory operation is a store). On the other hand, addresses which locate the instructions themselves within memory are referred to as “instruction addresses”.
Exceptions resulting from memory operations may be referred to as load/store exceptions. An example of such an exception is a page fault which occurs if when translating a linear address to a physical address, the processor determines that the page containing the operand is not present in physical memory. Typically, when an exception occurs, control may be transferred to a microcode routine to handle the exception. For example, for a page fault the exception handling routine may perform certain architecturally required tasks and then pass control to software (e.g., the operating system) to load the missing page into memory. Execution may then return to the instruction from which the page fault occurred.
An exception, such as a load/store exception, may occur during execution of an MROM instruction. For example, during: the execution of the microcode routine that implements an MROM instruction, a page fault may occur. The exception will cause the processor to be redirected to the exception handler (which is typically a microcode routine). Typically, the microcode fault handler must initially perform certain clean-up operations before an exception can be handled. For example, the MROM instruction routine that was interrupted by the exception may have left the processor state in a partially completed state. It may be necessary for the exception handler to “clean up” the processor state before the exception handling can continue. Just what sort of clean up is required depends upon the context in which the exception occurred. Depending on what MROM routine was interrupted or at what point a routine was interrupted, different clean-up may be required. Thus, the exception handler must determine the context in which the exception occurred.
Turning now to
FIG. 1
, a prior art example of how an exception handler may determine the context in which an exception occurred. There exist some number of microcode routines (labeled A through D in the example of FIG.
1
). Each of these routines alter macro-architectural state (visible to the programmer) or micro-architectural state (internal to the processor). Further, each of these routines can be prematurely terminated by an exception or interrupt before they complete. Exceptions/Interrupts transfer control to the microcode's generic exception processing routine (labeled ‘X’). The exception processing microcode implements the architecturally required elements of exception handling (e.g.

Affiliated with

Also associated with

Rating

Alternate fault handler does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Alternate fault handler, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Alternate fault handler will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2897272