|Publication number||US7660971 B2|
|Application number||US 11/669,999|
|Publication date||Feb 9, 2010|
|Filing date||Feb 1, 2007|
|Priority date||Feb 1, 2007|
|Also published as||US20080189535|
|Publication number||11669999, 669999, US 7660971 B2, US 7660971B2, US-B2-7660971, US7660971 B2, US7660971B2|
|Inventors||Vikas Agarwal, William E. Burky, Krishnan Kailas, Balaram Sinharoy|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Non-Patent Citations (1), Referenced by (2), Classifications (6), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention was made with Government support under DARPA, NBCH3039004. THE GOVERNMENT HAS CERTAIN RIGHTS IN THIS INVENTION.
1. Technical Field
The present invention relates in general to data processing systems and in particular to microprocessors. Still more particularly, the present invention relates to an improved method and system for dependency tracking and flush recovery for an out-of-order microprocessor.
2. Description of the Related Art
Early microprocessors executed only one instruction at a time and executed instructions in an order determined by the compiled machine-language program running on the microprocessor. Such microprocessors are known as “sequential” microprocessors. Various techniques, such as pipelining, superscaling, and speculative instruction execution, are utilized to improve the performance of sequential microprocessors. Pipelining breaks the execution of instructions into multiple stages, in which each stage corresponds to a particular execution step. Pipelined designs enable new instructions to begin executing before previous instructions are finished, thereby increasing the rate at which instructions can be executed.
“Superscalar” microprocessors typically include multiple pipelines and can process instructions in parallel using two or more instruction execution pipelines in order to execute multiple instructions per microprocessor clock cycle. Parallel processing requires that instructions be dispatched for execution at a sufficient rate. However, the execution rate of microprocessors has typically outpaced the ability of memory devices and data busses to supply instructions to the microprocessors. Therefore conventional microprocessors utilize one or more levels of on-chip cache memory to increase memory access rates.
Cache memory includes one or more levels of dedicated high-speed memory for storing recently accessed instructions and data. Cache memory technology is based on the premise that microprocessors frequently re-execute the same instructions and/or execute different instructions using recently accessed data. When data is read from main memory, the cache memory saves a copy of the data and an index corresponding to the location in main memory. The cache system monitors subsequent requests for data to see if any requested information is already stored in the cache. If the cache system finds that requested data is stored in the cache, often referred to as a cache “hit”, the data is delivered immediately to the microprocessor from the cache. If requested data is not currently stored in the cache, often referred to a cache “miss”, the requested data is fetched directly from main memory and saved in the cache for future use.
Superscalar microprocessors can process instructions simultaneously only when no data dependencies exist between the instructions in each of the pipelines. An instruction that depends on one or more preceding instructions to load required data into working operand registers cannot execute until all of the required data have been retrieved from cache or main memory. Furthermore, execution units can not predict how long it may take to load data into the working operand registers. Older microprocessors handled this uncertainty by delaying execution until the required data is fetched (i.e., by “stalling” the execution pipeline). This stalling was inconsistent with high-speed processing requirements.
Conventional microprocessors utilize speculative instruction execution to addresses pipeline stalls by enabling a second instruction that is data dependent on a first instruction to enter an execution pipeline before the first instruction has passed completely through the execution pipeline. Thus, in speculative execution microprocessors, the data dependent second instruction, which is often referred to as a consumer instruction, depends on the first instruction, which is referred to as a producer instruction.
In microprocessors that utilize speculative instruction execution, there is a delay between the decision to issue an instruction and the actual execution of the instruction. Thus, in the case of load instructions, there may be a significant delay between the issue of a load instruction and the corresponding data fetch from cache memory. A consumer load instruction, dependent on a delayed producer instruction, may be issued before confirmation by the cache system that the required load data required is available in the cache. When the required data is not found in the cache, dependent consumer load instructions can execute and access incorrect data.
In order to maintain correctness, microprocessors flush incorrectly executed speculative instructions and their results. Conventional microprocessors detect and correct such misspeculation by tracking instruction dependencies using large physical register mappers. The register mappers enable dependency chains to be established based on physical register names. However these register mappers are complex and typically rely on content-addressable memory (CAM) functions to concurrently evaluate large numbers of physical registers. To enable recovery from cache flushes, microprocessors also save a previous physical register state for each instruction group and for each physical register type, thus requiring a large amount of memory area and slowing the process of register state recovery. Consequently, an improved method for dependency tracking and flush recovery for an out-of-order microprocessor is needed.
A method and system for dependency tracking and flush recovery for an out-of-order processor are disclosed. According to one embodiment of the method, an identifier of a first instruction in an instruction sequence is recorded in a last definition (DEF) data structure as the most recent instruction in the instruction sequence that defines contents of the particular logical register. The identifier of the first instruction is also recorded in a next DEF data structure in association with an identifier of a previous second instruction also indicating an update to the particular logical register. In addition, a recovery array is updated to indicate which of the instructions in the instruction sequence updates each of the plurality of logical registers. In response to misspeculation during execution of the instruction sequence, the processor performs a recovery operation to place the identifier of the second instruction in the last DEF data structure by reference to the next DEF data structure and the recovery array.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.
The invention itself, as well as a preferred mode of use, further objects, and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
With reference now to
Instructions are fetched and ordered for processing by instruction sequencing logic 13 within processor 10. In the depicted embodiment, instruction sequencing logic 13 includes an instruction fetch address register (IFAR) 30 that contains an effective address (EA) indicating a cache line of instructions to be fetched from L1 I-cache 18 for processing. During each cycle, a new instruction fetch address may be loaded into IFAR 30 from one of at least three sources: branch prediction unit (BPU) 36, which provides speculative target path addresses resulting from the prediction of conditional branch instructions, global completion table (GCT) 38, which provides sequential path addresses, and branch execution unit (BEU) 92, which provides non-speculative addresses resulting from the resolution of predicted conditional branch instructions. The effective address loaded into IFAR 30 is selected from among the addresses provided by the multiple sources according to a prioritization scheme, which may take into account, for example, the relative priorities of the sources presenting addresses for selection in a given cycle and the age of any outstanding unresolved conditional branch instructions.
If hit/miss logic 22 determines, after translation of the EA contained in IFAR 30 by effective-to-real address translation (ERAT) 32 and lookup of the real address (RA) in I-cache directory 34, that the cache line of instructions corresponding to the EA in IFAR 30 does not reside in L1 I-cache 18, then hit/miss logic 22 provides the RA to L2 cache 16 as a request address via I-cache request bus 24. Such request addresses may also be generated by prefetch logic within L2 cache 16 or elsewhere within processor 10 based upon recent access patterns. In response to a request address, L2 cache 16 outputs a cache line of instructions, which are loaded into prefetch buffer (PB) 28 and L1 I-cache 18 via I-cache reload bus 26, possibly after passing through predecode logic (not illustrated).
Once the cache line specified by the EA in IFAR 30 resides in L1 cache 18, L1 I-cache 18 outputs the cache line to both branch prediction unit (BPU) 36 and to instruction fetch buffer (IFB) 40. BPU 36 scans the cache line of instructions for branch instructions and predicts the outcome of conditional branch instructions, if any. Following a branch prediction, BPU 36 furnishes a speculative instruction fetch address to IFAR 30, as discussed above, and passes the prediction to branch instruction queue 64 so that the accuracy of the prediction can be determined when the conditional branch instruction is subsequently resolved by branch execution unit 92.
IFB 40 temporarily buffers the cache line of instructions received from L1 I-cache 18 until the cache line of instructions can be translated by instruction translation unit (ITU) 42. In the illustrated embodiment of processor 10, ITU 42 translates instructions from user instruction set architecture (UISA) instructions (e.g., PowerPC® instructions) into a possibly different number of internal ISA (IISA) instructions that are directly executable by the execution units of processor 10. Such translation may be performed, for example, by reference to microcode stored in a read-only memory (ROM) template. In at least some embodiments, the UISA-to-IISA translation results in a different number of IISA instructions than UISA instructions and/or IISA instructions of different lengths than corresponding UISA instructions. The resultant IISA instructions are then assigned by global completion table 38 to an instruction group, the members of which are permitted to be executed out-of-order with respect to one another. Global completion table 38 tracks each instruction group for which execution has yet to be completed by at least one associated EA, which is preferably the EA of the oldest instruction in the instruction group.
Following UISA-to-IISA instruction translation, instructions are dispatched in-order to one of latches 44, 46, 48, 50, and 51 according to instruction type. That is, branch instructions and other condition register (CR) modifying instructions are dispatched to latch 44, fixed-point and load-store instructions are dispatched to either of latches 46 and 48, floating-point instructions are dispatched to latch 50, and vector instructions are dispatched to latch 57. Each instruction requiring a rename register for temporarily storing execution results is then assigned one or more registers within a register file by the appropriate one of CR mapper 53, link and count register (LCR) mapper 55, exception register (XER) mapper 57, general-purpose register (GPR) mapper 59, floating-point register (FPR) mapper 61, and vector register (VR) mapper 65. According to the illustrative embodiment, register mapping may be performed by a simplified register file mapper, a reorder buffer (ROB), or other similar devices known to those skilled in the art. Register file mapping can thus be performed at instruction issue time or close to result write-back time, thereby reducing the lifetimes of allocated renames and increasing the efficiency of rename usage.
Instruction sequencing logic 13 tracks the allocation of register resource to each instruction using the appropriate one of CR last definition (DEF) table 52, LCR last DEF table 54, XER last DEF table 56, GPR last DEF table 58, FPR last DEF table 60, and VR last DEF table 63. An exemplary last DEF table is illustrated in
Data processing system 8 also includes flush recovery array 43, which is coupled to next DEF tables 41. Flush recovery array 43 enables instruction sequencing logic 13 to utilize next DEF tables 41 to track instruction data dependencies and perform flush recovery operations, as illustrated in
After latches 44, 46, 48, 50, and 51, the dispatched instructions are temporarily placed in an appropriate one of CR issue queue (CRIQ) 62, branch issue queue (BIQ) 64, fixed-point issue queues (FXIQs) 66 and 68, floating-point issue queues (FPIQs) 70 and 72, and VR issue queue (VRIQ) 73. From issue queues 62, 64, 66, 68, 70, 72, and 73, instructions can be issued opportunistically (i.e., possibly out-of-order) to the execution units of processor 10 for execution. In some embodiments, the instructions are also maintained in issue queues 62-73 until execution of the instructions is complete and the result data, if any, are written back, in case any of the instructions needs to be reissued.
As illustrated, the execution units of processor 10 include a CR unit (CRU) 90 for executing CR-modifying instructions, a branch execution unit (BEU) 92 for executing branch instructions, two fixed-point units (FXUs) 94 and 100 for executing fixed-point instructions, two load-store units (LSUs) 96 and 98 for executing load and store instructions, two floating-point units (FPUs) 102 and 104 for executing floating-point instructions, and vector execution unit (VEU) 105 for executing vector instructions. Each of execution units 90-105 is preferably implemented as an execution pipeline having a number of pipeline stages.
During execution within one of execution units 90-105, an instruction receives operands, if any, from one or more architected and/or rename registers within a register file coupled to the execution unit. When executing CR-modifying or CR-dependent instructions, CRU 90 and BEU 92 access the CR register file 80, which in a preferred embodiment contains a CR and a number of CR rename registers that each comprise a number of distinct fields formed of one or more bits. Among these fields are LT, GT, and EQ fields that respectively indicate if a value (typically the result or operand of an instruction) is less than zero, greater than zero, or equal to zero. Link and count register (LCR) register file 82 contains a count register (CTR), a link register (LR) and rename registers of each, by which BEU 92 may also resolve conditional branches to obtain a path address. Similarly, when executing vector instructions, VRU 105 accesses the VR register file 89, which in a preferred embodiment contains multiple VRs and a number of VR rename registers. General-purpose register files (GPRs) 84 and 86, which are synchronized, duplicate register files, store fixed-point and integer values accessed and produced by FXUs 94 and 100 and LSUs 96 and 98. Floating-point register file (FPR) 88, which like GPRs 84 and 86 may also be implemented as duplicate sets of synchronized registers, contains floating-point values that result from the execution of floating-point instructions by FPUs 102 and 104 and floating-point load instructions by LSUs 96 and 98.
After an execution unit finishes execution of an instruction, the execution notifies GCT 38, which schedules completion of instructions in program order. To complete an instruction executed by one of CRU 90, FXUs 94 and 100, FPUs 102 and 104, or VEU 105, GCT 38 signals the appropriate last DEF table. The instruction is then removed from the issue queue, and once all instructions within its instruction group have completed, is removed from GCT 38. Other types of instructions, however, are completed differently.
When BEU 92 resolves a conditional branch instruction and determines the path address of the execution path that should be taken, the path address is compared against the speculative path address predicted by BPU 36. If the path addresses match, BPU 36 updates its prediction facilities, if necessary. If, however, the calculated path address does not match the predicted path address, BEU 92 supplies the correct path address to IFAR 30, and BPU 36 updates its prediction facilities, as described further below. In either event, the branch instruction can then be removed from BIQ 64, and when all other instructions within the same instruction group have completed, from GCT 38.
Following execution of a load instruction (including a load-reserve instruction), the effective address computed by executing the load instruction is translated to a real address by a data ERAT (not illustrated) and then provided to L1 D-cache 20 as a request address. At this point, the load operation is removed from FXIQ 66 or 68 and placed in load data queue (LDQ) 114 until the indicated load is performed. If the request address misses in L1 D-cache 20, the request address is placed in load miss queue (LMQ) 116, from which the requested data is retrieved from L2 cache 16, and failing that, from another processor 10 or from system memory 12.
Store instructions (including store-conditional instructions) are similarly completed utilizing a store queue (STQ) 110 into which effective addresses for stores are loaded following execution of the store instructions. From STQ 110, data can be stored into either or both of L1 D-cache 20 and L2 cache 16, following effective-to-real translation of the target address.
With reference now to
In one embodiment, last DEF table 200 includes multiple columns 205, each of which corresponds to a particular logical register (LREG) that may be referenced by an instruction. Each column 205 further includes at least two fields, including at least a last DEF instruction tag (ITAG) field 210 and valid field 215. According to the illustrative embodiment, an associated register file such as one of GPR files 84, 86, FPR file 88, or VR file 89 includes 120 physical registers to which 32 LREGs can be physically mapped by a register file mapper or ROB device. Utilizing LREGS instead of physical registers as index values into last DEF table 200 enables last DEF table 200 to occupy less space and have more rapid access than mappers tracking register use by physical register number. Although the depicted embodiment has 32 columns corresponding to 32 LREGs in an associated register file, it should be appreciated that different ones of last DEF tables 52, 54, 56, 58, 60, and 63 may have different sizes, depending upon the desired number of architected registers.
In one embodiment, last DEF table 200 utilizes one write port per instruction, and write port orthogonality is ensured via intra-group write after write (WAW) predecodes. Similarly, the read outputs of last DEF table 200 can be bypassed via intra-group read after write (RAW) predecodes. Instruction sequencing logic 13 can thus utilize multiple last DEF tables 200 and instruction dispatch groups to process multiple simultaneous instructions, to prioritize instructions, and/or to identify duplicate instructions. Since the instruction tags recorded within last DEF table 200 are read addresses, content-addressable memory (CAM) functions are not required for instruction source lookup.
When instruction sequencing logic 13 issues a new instruction, the last DEF ITAG field 210 corresponding to the logical register(s) written/defined by the instruction are updated with the ITAG of the instruction. Thus, last DEF table 200 always reflects the identities of the “youngest” instructions that define the LREGs in the associated register file. As utilized herein, the “youngest” ITAG refers to a unique instruction identifier that corresponds to the most recent instruction that writes or overwrites a particular LREG. When a last DEF ITAG field 210 is updated, the associated valid field 215 is also updated to a valid state. The contents of fields 210 and 215 are utilized during the processes of dependency tracking and flush recovery, which are illustrated in
With reference now to
With reference now to
According to the illustrative embodiment, data processing system 8 employs orthogonal register sets, meaning that at most one register set is accessed by each instruction. Consequently, each ITAG can be associated with an update to, at most, a single register type (e.g., GPR, FPR, or VR). The specific register file to which the LREG identifier maps is indicated by encoded bits within destination type column 250. Instruction sequencing logic 13 writes flush recovery array 43 at the time instructions are dispatched. In the depicted embodiment, flush recovery array 43 has 4 write ports 240 including decoders in order to support concurrent dispatch by instruction sequencing logic 13 of 4 instructions.
When recovery is required, flush recovery array 43 outputs encoded values that represent which ITAGs should be indicated by as the new “youngest” instructions in last DEF table 200 (from
With reference now to
In the exemplary processing scenario, processor 10 executes the following sequence of instructions:
In this instruction sequence, the initial numeral (e.g., 0, 1, 2, . . . , 7) represents the ITAG assigned to the instruction by instruction sequencing logic 13, the next field is a mnemonic representing the operation code of the instruction (e.g., add or conditional branch), the third field designates the target logical register, if any, written by the instruction, and the final two fields designate the logical registers holding the input operands.
As instruction sequencing logic 13 sequentially issues the instructions in the instruction sequence, instruction sequencing logic 13 first assigns an ITAG of “0” to last DEF ITAG field 210 for LREG 2 in GPR last DEF table 58 as shown at reference number 300, since the fixed-point instruction for ITAG 0 (i.e., add r2, r9, r3) updates LREG 2. Instruction sequencing logic 13 also sets the associated valid field 215, as indicated in
When instruction sequencing logic 13 issues the instruction assigned ITAG 1, instruction sequencing logic 13 overwrites the last DEF ITAG field 210 for LREG 2 in GPR last DEF table 58 with “1” (i.e., ITAG 1) since ITAG 1 also updates GPR LREG 2. In order to track the previous value (i.e., ITAG 0), instruction sequencing logic 13 sets the next DEF ITAG field 230 within next DEF table 41 corresponding to ITAG 0 to “1” to indicate ITAG 1 has overwritten ITAG 0 and sets the associated next DEF valid field 225. Instruction sequencing logic 13 also sets the cell corresponding to ITAG 1 and LREG 2 (i.e., row 2, column 3) within flush recovery array 43 to indicate the instruction corresponding to ITAG 1 has written LREG 2.
When instruction sequencing logic 13 issues the instruction assigned ITAG 2, instruction sequencing logic 13 assigns “2” (i.e., ITAG 2) to the last DEF ITAG field 210 for LREG 3 in GPR last DEF table 58 as shown at reference numeral 305, since ITAG 2 updates GPR LREG 3. Instruction sequencing logic 13 also sets the associated valid field 215, as indicated in
When instruction sequencing logic 13 issues the instruction assigned ITAG 4, instruction sequencing logic 13 overwrites the last DEF ITAG field 210 for LREG 2 in GPR last DEF table 58 with “4” (i.e., ITAG 4) since ITAG 4 also updates GPR LREG 2. In order to track the previous value (i.e., ITAG 1), instruction sequencing logic 13 sets the next DEF ITAG field 230 within next DEF table 41 corresponding to ITAG 1 to “4” to indicate ITAG 4 has overwritten ITAG 1 and sets the associated next DEF valid field 225. Instruction sequencing logic 13 also sets the cell corresponding to ITAG 4 and LREG 2 (i.e., row 5, column 3) within flush recovery array 43 to indicate the instruction corresponding to ITAG 4 updates LREG 2.
When instruction sequencing logic 13 issues the instruction assigned ITAG 5, instruction sequencing logic 13 assigns “5” (i.e., ITAG 5) to the last DEF ITAG field 210 for LREG 4 in GPR last DEF table 58 as indicated at reference numeral 310, since ITAG 5 updates GPR LREG 4. Instruction sequencing logic 13 also sets the associated valid field 215, as indicated in
When instruction sequencing logic 13 issues the instruction assigned ITAG 6, instruction sequencing logic 13 overwrites the last DEF ITAG field 210 for LREG 2 in GPR last DEF table 58 with “6” (i.e., ITAG 6) since ITAG 6 also updates GPR LREG 2. In order to track the previous value (i.e., ITAG 4), instruction sequencing logic 13 sets the next DEF ITAG field 230 within next DEF table 41 corresponding to ITAG 4 to “6” to indicate ITAG 6 has overwritten ITAG 4 and sets the associated next DEF valid field 225. Instruction sequencing logic 13 also sets the cell corresponding to ITAG 6 and LREG 2 (i.e., row 7, column 3) within flush recovery array 43 to indicate the instruction corresponding to ITAG 6 writes LREG 2.
Finally, when instruction sequencing logic 13 issues the instruction assigned ITAG 7, instruction sequencing logic 13 overwrites the last DEF ITAG field 210 for LREG 3 in GPR last DEF table 58 with “7” (i.e., ITAG 7) since ITAG 7 also updates GPR LREG 3. In order to track the previous value (i.e., ITAG 2), instruction sequencing logic 13 sets the next DEF ITAG field 230 within next DEF table 41 corresponding to ITAG 2 to “7” to indicate ITAG 7 has overwritten ITAG 2 and sets the associated next DEF valid field 225. Instruction sequencing logic 13 also sets the cell corresponding to ITAG 7 and LREG 3 (i.e., row 8, column 4) within flush recovery array 43 to indicate the instruction corresponding to ITAG 7 updates LREG 3.
When instruction sequencing logic 13 thereafter detects a mispredicted instruction, instruction sequencing logic 13 initiates a flush recovery operation, as illustrated in
Tuning now to
At block 417, a determination is made for each row within next DEF table 41 (i.e., for each ITAG 220) whether the row is being flushed. For each row within next DEF table 41 that is being flushed, instruction sequencing logic 13 takes no further action for that row, and processing of that row terminates, as depicted in block 435. For each row within next DEF table 41 that is not being flushed, the process proceeds to block 420.
At block 420, a determination is made whether the magnitude of the values within next DEF ITAG field 230 are greater than or equal to the magnitude of flush ITAG vector 325, and whether the valid fields 235 corresponding to the values within next DEF ITAG field 230 are set. For each ITAG within next DEF table 41 that has a magnitude of the next DEF ITAG field 230 that is less than the magnitude of flush ITAG vector 325 or has a valid field 235 that is not set, instruction sequencing logic 13 takes no further action, and processing of such ITAGs terminates, as shown in block 435.
For each ITAG within next DEF table 41 for which the magnitude of the next DEF ITAG field 230 is greater than or equal to the magnitude of flush ITAG vector 325 and a set valid field 235 (i.e., for each valid next DEF ITAG field 230 that was dispatch subsequent to the mispredicted branch instruction), instruction sequencing logic 13 writes the ITAG 220 to the appropriate field 210 in last DEF table 200 by utilizing flush recovery array 43, as depicted in block 430. Instruction sequencing logic 13 accesses each row within flush recovery array 43 that corresponds to the each valid ITAG row 220 for which next DEF ITAG field 230 is greater than or equal to the magnitude of flush ITAG vector 325, and utilizes destination type field 250 to determine which last DEF ITAG field 210 (i.e., LREG) within each last DEF table 200 to update. For example, if the next DEF ITAG field 230 of ITAG 1 in next DEF table 41 contains a flushed ITAG, instruction sequencing logic 13 accesses the row corresponding to ITAG 1 (i.e., the second row) of flush recovery array 43 and locates a “1” in a particular decode column 245 (i.e., the column of the corresponding LREG). Instruction sequencing logic 13 utilizes destination type field 250 to determine which last DEF table 200 ITAG 1 corresponds to and overwrites last DEF ITAG field 210 in the appropriate column (i.e., LREG) with the value in next DEF ITAG field 230. Instruction sequencing logic 13 thus utilizes flush recovery array 43 to quickly update GPR last DEF table 58, FPR last DEF table 60, and VR last DEF table 63 in parallel with the appropriate encoded ITAGs that wrote LREGs. The flush recovery process then terminates at block 435.
The present invention thus enables data processing system 8 to utilize multiple small last DEF tables 200 indexed by logical register (instead of physical register like conventional mappers), to track instruction dependencies during speculative instruction execution. Furthermore, the present invention enables data processing system 8 to utilize flush recovery array 43 to quickly restore instruction dependencies during out-of-order execution. The encoded parallel output of flush recovery array 43 eliminates the need for complicated register mappers and CAM functions, thereby reducing the area required for instruction dependency tracking logic and increasing the speed of flush recovery operations through the use of a custom register file based approach.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. Although the illustrative embodiment utilizes last DEF tables 200 and next DEF table 41, in other embodiments various alternative data structures may be utilized.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5758112 *||Feb 7, 1997||May 26, 1998||Silicon Graphics, Inc.||Pipeline processor with enhanced method and apparatus for restoring register-renaming information in the event of a branch misprediction|
|US5974524 *||Oct 28, 1997||Oct 26, 1999||International Business Machines Corporation||Method and apparatus for reducing the number of rename registers in a processor supporting out-of-order execution|
|US6098167 *||Mar 31, 1997||Aug 1, 2000||International Business Machines Corporation||Apparatus and method for fast unified interrupt recovery and branch recovery in processors supporting out-of-order execution|
|US6751749 *||Feb 22, 2001||Jun 15, 2004||International Business Machines Corporation||Method and apparatus for computer system reliability|
|US7370178 *||Jul 14, 2006||May 6, 2008||Mips Technologies, Inc.||Method for latest producer tracking in an out-of-order processor, and applications thereof|
|1||*||Moudgill, Mayan, Pingali, Keshav, Vassiliadis, Stamatis. "Register renaming and dynamic speculation: an alternative approach" Sep. 1993.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8037366 *||Mar 24, 2009||Oct 11, 2011||International Business Machines Corporation||Issuing instructions in-order in an out-of-order processor using false dependencies|
|US20100251016 *||Sep 30, 2010||International Business Machines Corporation||Issuing Instructions In-Order in an Out-of-Order Processor Using False Dependencies|
|Cooperative Classification||G06F9/3863, G06F9/3842|
|European Classification||G06F9/38E2, G06F9/38H2|
|Feb 1, 2007||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AGARWAL, VIKAS;BURKY, WILLIAM E.;KAILAS, KRISHNAM;AND OTHERS;REEL/FRAME:018836/0432;SIGNING DATES FROM 20070118 TO 20070131
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION,NEW YO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:AGARWAL, VIKAS;BURKY, WILLIAM E.;KAILAS, KRISHNAM;AND OTHERS;SIGNING DATES FROM 20070118 TO 20070131;REEL/FRAME:018836/0432
|Sep 20, 2013||REMI||Maintenance fee reminder mailed|
|Jan 30, 2014||FPAY||Fee payment|
Year of fee payment: 4
|Jan 30, 2014||SULP||Surcharge for late payment|