Electrical computers and digital processing systems: processing – Dynamic instruction dependency checking – monitoring or... – Commitment control or register bypass
Reexamination Certificate
1998-12-23
2001-08-28
Treat, William M. (Department: 2183)
Electrical computers and digital processing systems: processing
Dynamic instruction dependency checking, monitoring or...
Commitment control or register bypass
C712S244000
Reexamination Certificate
active
06282636
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of microprocessors, and in particular, to systems and methods for processing exceptions.
2. Background Art
A pipelined processor is organized as a series of cascaded stages of hardware. Instruction processing is divided into a sequence of operations, and each operation is performed by resources in a corresponding pipeline stage (“pipe stage”). Independent operations from several instructions may be processed simultaneously by different pipe stages, increasing the instruction throughput of the pipeline. By including multiple execution resources in each pipe stage, the pipelined processor can execute multiple instructions per clock cycle. Instructions that step through the processor pipeline in parallel form an issue group.
One final operation performed for each issue group is a check that determines which instructions of the issue group should update the architectural state with their results. An instruction that updates the architectural state is “committed” or “retired”. An instruction may not be retired if it or an instruction that precedes it in the issue group triggers a condition or event that must be addressed by the processor outside of the scheduled flow of instructions. These conditions/events include architectural faults, architectural traps, micro-architectural faults, and micro-architectural traps, and are referred to collectively as “interruptions” or “exceptions”. In the following discussion, “interruptions” and “exceptions” are used interchangeably.
When such an event/condition occurs, an “exception” is raised to signal the event to the processor. For example, an architectural exception is raised when an instruction tries to access an address that is not present in memory or the processor attempts to execute an undefined opcode. For these architectural exceptions, the processor intervenes and transfers control to a handler that addresses the triggering event. For micro-architectural exceptions, the processor may only need to flush the pipeline and reexecute the affected instructions.
Exceptions originate in the resources that are used to implement a given instruction. These resources may be referred to collectively as an execution port. For example, each instruction in an issue group is associated with a different execution port. The resources of an execution port typically include logic that is specific to the type of instructions it processes, such as branch units, floating point register files, load/store units. They also include shared resources that provide services to multiple execution ports, such as caches, translation buffers, and tables. Any of these resources may generate a warning signal (an “exception”) if the instruction being processed triggers an exception.
More than one instruction in an issue group may trigger an exception, and a single instruction may generate more than one exception. Accordingly, exception signals must be collected from the different processor resources, prioritized, and analyzed to determine a highest priority exception for each issue group. The processor's response depends on the nature of the highest priority exception. When an exception occurs, the processor must determine which instruction(s) in the issue group, if any, can be retired. Retirement depends on the instruction's execution order relative to the instruction(s) of the issue group that generates the exception. The first instruction in execution order that raises an exception takes priority in the exception handling process. If this instruction raises multiple exceptions, the highest priority exception is addressed first.
Conventional processors employ a centralized exception/commit unit to process exception signals and generate commit signals to the execution ports. Centralized exception/commit units provide clean logic boundaries. However, given the relatively large number of execution resources in modern processors, the exception unit must receive and process a large number of exception signals. This can lead to signal routing problems, since all the exception signals must be provided to the centralized unit, and all the commit signals must be routed from the central unit to the various execution ports. In addition, the number of execution resources makes modern processors relatively large. This can create timing problems, especially for exceptions generated in the later pipe stages. In these cases, the exception signal must be routed to the central exception/commit unit, processed, and returned before the commit stage of the pipeline is reached.
The present invention addresses these and other problems related to exception/commit processing.
SUMMARY OF THE INVENTION
The present invention provides a distributed exception/commit system that allows exception signals to be processed by exception units that are local to the resources that generate them. The resulting local exception signals arc combined to provide global exception/commit signals. The distributed nature of the system reduces routing congestion and timing constraints on the processed signals.
In accordance with the present invention, an exception/commit system includes multiple exception units. Each exception unit receives exception signals from resources that are local to it and generates one or more local commit signals. The local commit signals from the exception units are combined to provide a global commit signal for each execution port.
For one embodiment of the invention, local exception signals are prioritized, encoded, and forwarded to a selected exception unit. The selected exception unit determines a global exception from the encoded signals and resteers instruction processing based on the global exception.
REFERENCES:
patent: 5625789 (1997-04-01), Hesson et al.
patent: 5682492 (1997-10-01), MacFarland et al.
patent: 5748936 (1998-05-01), Karp et al.
patent: 5884062 (1999-03-01), Wichman et al.
patent: 5974524 (1999-10-01), Cheong et al.
patent: 6021486 (2000-02-01), Morrison
patent: 6049868 (2000-04-01), Panwar
patent: 6205542 (2001-03-01), Grochowski et al.
Mathews Gregory
Tu Steven
Yeh Tse-Yu
Intel Corporation
Novakoski Leo V.
Treat William M.
LandOfFree
Decentralized exception processing system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Decentralized exception processing system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Decentralized exception processing system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2528002