Apparatus and method for the analysis and resolution of operand dependencies

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention generally relates to the control of instructions to a pipelined processor of a stored program data processing machine and, more particularly, to an apparatus for controlling the instruction dispatch, issue, execution and pipeline recovery in a microprocessor capable of executing multiple instructions out-of-order every machine clock cycle.

Description of the Prior Art

High performance microprocessors are relying on hardware performed dependency analysis and register renaming to facilitate the out-of-order execution of multiple instructions per machine cycle. Representative prior art in this field is the work by John Cocke et al., as described in U.S. Patent No. 4,992,938, and the work by R. N. Rechtschaffen, as described in U.S. Patent No. 4,574,349. In particular, Cocke et al. disclose a control mechanism for allowing parallelism among floating point operations by overlapping loads and stores with other instructions. The correct sequence of results is maintained by register renaming; that is, by removing the final assignment of architected registers to physical registers. Rechtschaffen discloses a processor complex wherein a greater number of instruction addressable hardware registers are provided in a central processing unit (CPU) than can be identified by register addressing fields of a program instruction. Rechtschaffen provides a pointer assignment mechanism which assigns unique pointer values to hardware registers, although the same general purpose register (GPR) may be identified in address fields of subsequent load instructions.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide an apparatus to perform source operand dependency analysis, perform register renaming and provide rapid pipeline recovery for a microprocessor capable of issuing and executing multiple instructions out-of-order in a single machine cycle.

According to the present invention, the prior art is extended by first providing an enhanced means for rapid pipeline recovery due to a mispredicted branch or other store/load conflict or unsupported store/load forward circumstances, second, providing an improved instruction scheduling means wherein the oldest instructions that have all of their dependencies resolved are executed first, third, providing a means for enabling any execution or memory access instruction to execute out-of-order, and fourth, providing a means for handling precise recovery of interrupts when processing instructions in out-of-order sequence.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which: <ul id="ul0001" list-style="none"><li>Figure 1 is a block diagram of a superscaler microarchitecture that incorporates the unique rename cam as well as other functional units typical of a superscaler processor;</li><li>Figure 2 is a block diagram of a rename unit that is used to perform register renaming, support register dependency analysis, control the execution of instructions and the writeback of the computed results, and facilitate the rapid pipeline recovery from a mispredicted branch instruction stream or a precise interrupt; and</li><li>Figures 3A to 3D, taken together, are a flow chart showing the logic of the process implemented according to the invention.</li></ul>

DETAILED DESCRIPTION OF A PREFERRED

EMBODIMENT OF THE INVENTION

Referring now to the drawings, and more particularly to Figure 1, there is shown a typical superscaler processor that includes a bus interface unit 29 which communicates with a system bus (not shown) to receive and transmit address and control codes and to receive and transmit data and error correcting codes (ECC) or byte parity information. The program instructions are buffered by instruction cache (ICACHE) fill buffer 27 and input to the instruction cache 16. The program data are buffered by data cache (DCACHE) fill buffer 28 and input to the data cache 24. Memory management unit (MMU) 26 controls the writing to and reading out of instructions and data, respectively, for both the instruction cache 16 and the data cache 24.

The superscalar microarchitecture further contains multiple fixed point execution units 21 and 22, a dedicated branch processor 20, a dedicated load/store unit 14, and a floating point unit 23. Instructions are fetched from the instruction cache 16 to the instruction fetch and dispatch unit 15 under the control of the rename unit 12 and dispatched to a central pool of reservation station buffers 19. During the dispatch of instructions from the instruction fetch buffer dispatch window, the destination result field of the instruction is renamed, and the most recent copy of the source operands are either tagged or supplied along with any instruction control bits to the reservation station entry identified by the rename tag. The execution units 14, 20, 21, 22 and 23 are directed by the rename unit 12 to perform the oldest instruction that has each of its operands valid from one of the four reservation read ports P1A, P1B, P1C, or P1D. The four reservation read ports are sourced to the execution units from the central pool of reservation station buffers 19, and the execution units direct the computed results to the completion buffer 18 entry pointed to by the destination tag assigned by the rename unit 12. As reservation station buffers 19 and completion buffer 18 entries are assigned in pairs during the dispatch stage by the rename unit 12, they share the same tag. The writeback unit 13 writes the computed results from the completion buffer 18 back to the architected register or to memory in program order under the direction of the rename unit 12. In the case of the branch execution unit 20, the computed result is written from the completion buffer 18 to the branch target cache 25 which is accessed by the instruction fetch and dispatch unit 15.

The pipelined stages for each of the major type of machine instructions is illustrated in Figure 1. For example, the data store operation consists of six stages: instruction fetch, instruction dispatch, address generation (i.e., execution stage), memory translation lookaside buffer (TLB) and cache hit/miss search, completion (i.e., write cache and TLB results to completion buffer), and finally writeback to cache. <tables id="tabl0001" num="0001"><table frame="all"><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><i>Data Store Instruction</i></entry><entry namest="col2" nameend="col2" align="left"><i>Data Load Instruction</i></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>P0 ·</b> Instruction Fetch</entry><entry namest="col2" nameend="col2" align="left"><b>PO ·</b> Instruction Fetch</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P1 ·</b> Dispatch</entry><entry namest="col2" nameend="col2" align="left"><b>P1 ·</b> Dispatch</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P2 ·</b> Address Generation</entry><entry namest="col2" nameend="col2" align="left"><b>P2 ·</b> Address Generation</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P3 ·</b> Memory Table Search</entry><entry namest="col2" nameend="col2" align="left"><b>P3 ·</b> Memory Read</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P4 ·</b> Complete</entry><entry namest="col2" nameend="col2" align="left"><b>P4 ·</b> Complete</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left"><b>P5 ·</b> Writeback (to DCACHE)</entry><entry namest="col2" nameend="col2" align="left"><b>P5 ·</b> Writeback (RF)</entry></row></tbody></tgroup></table></tables><tables id="tabl0002" num="0002"><table frame="all"><tgroup cols="2" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="78.75mm" /><colspec colnum="2" colname="col2" colwidth="78.75mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><i>Fixed Point Instruction</i></entry><entry namest="col2" nameend="col2" align="left"><i>Floating Point Instruction</i></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>P0 ·</b> Instruction Fetch</entry><entry namest="col2" nameend="col2" align="left"><b>P0 ·</b> Instruction Fetch</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P1 ·</b> Dispatch</entry><entry namest="col2" nameend="col2" align="left"><b>P1 ·</b> Dispatch</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P2 ·</b> Execute</entry><entry namest="col2" nameend="col2" align="left"><b>P2 ·</b> Execute 1</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P3 ·</b> Complete</entry><entry namest="col2" nameend="col2" align="left"><b>P3 ·</b> Execute 2</entry></row><row><entry namest="col1" nameend="col1" align="left"><b>P4 ·</b> Writeback</entry><entry namest="col2" nameend="col2" align="left"><b>P4 ·</b> Execute 3</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left"><b>P5 ·</b> Complete</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left"><b>P6 ·</b> Writeback</entry></row></tbody></tgroup></table></tables>

In the foregoing table, the numbers with the prefix "P" designate stages in the pipeline. Thus, the P0 pipeline stage is the instruction fetch stage, the P1 pipeline stage is the dispatch stage, and so forth.

The store barrier cache 11, works in conjunction with instruction fetch and dispatch unit 15, the rename unit 12, the load/store and load special function unit 14 and the writeback unit 13 to obtain a significant performance advantage over prior art by permitting speculative execution of load and store instructions. The store barrier cache 11 is accessed in parallel with the instruction cache 16 and contains history bits that are used to predict the condition wherein a load instruction has executed ahead of a store instruction in program order and that the load and store instruction have the same real address. If the store barrier cache 11 predicts a store load conflict, this information is used during the dispatch of the store instruction to mark a barrier bit within the rename unit 12 so that no loads in program order are permitted to execute ahead of the store that is predicted to be violated. In this fashion, aggressive out-of-order instruction execution is enabled with the accompanying performance advantages.

The register file 17 is in general partitioned into an integer register file and a floating-point register file. As shown in Figure 1, the register file 17 is a unified register file, this being done to simplify the discussion. It is an obvious extension to consider multiple register files. For that matter, the same is true for the completion buffer 18 and reservation station files 19. That is, although the completion buffer and reservation station files are shown in Figure 1 as unified files, they could be partitioned about each function unit according to integer or floating point data. These extensions are immediately obvious to those skilled in the art of superscalar processor design. The register file 17 of Figure 1 has six read ports designated as RA1, RB1, RC1, RA2, RB2, and RC2. The read ports RA1, RB1 and RC1 correspond to the first instruction within the instruction dispatch window, while the ports RA2, RB2, and RC2 correspond to the second instruction in the dispatch window. The three write ports to the register file are sourced from the completion buffer 18 with one or more of them being active at any given clock cycle according to the number of result operands that are being written back to the register file 17 during the last stage of an instruction pipeline stage. For the single cycle fixed point instructions, this is during the P4 pipeline stage. For the multiple cycle floating point instructions, this is during the P6 pipeline stage. And for the data load type instructions, this is during the P5 pipeline stage.

Figure 1 illustrates the major data paths for a representative microarchitecture. The reservation station, completion buffer and register file read and write port addresses and control are not shown in Figure 1. However, it is obvious that for each read and write port of the reservation station, completion buffer and register file, there corresponds port address and control. This port address and control for each file is generated by the rename unit 12 with the algorithm specified in the pseudocode below. The pseudocode describes the rename unit role in generating port address and control as an instruction progresses through each of its major pipeline states as described in Table 1 below.

The rename unit 12 is used to control the dispatch of instructions from the instruction fetch buffer 15, the issue of instructions to one of the functional units 14, 20, 21, 22, and 23, and the writeback of instructions from the completion buffer 18 back to either the architected registers or memory. The rename unit apparatus shown in Figure 2 operates as a rotating stack structure that consists of multiple registers 30 through 37 and multiple logic blocks 40 through 47 and by design maintains a record of program order with the least recently used (LRU) or oldest instruction at the top and the most recently used (MRU) or newest instruction at the bottom of the stack. Each of the logic blocks 40 through 47 contain priority encoder logic, execution state scoreboard logic and rename tags.

Figure 2 illustrates the rename unit structure with a total of eight rename register entries, although greater or fewer entries are obvious extensions of the basic concept. Rename tags are allocated from the free list of rename tags in circular order, and the rename unit rotates according to the number of rename tags that are assigned. The rename unit simply produces the register file, reservation station and completion buffer read and write port address tags corresponding to each of the execution unit pipeline stages as an instruction progresses from dispatch, to issue, through execution and is finally written back. Dispatch tags are generated that correspond to both the local and global source operand dependency analysis and are grouped in register 58 in Figure 2. Similarly, instruction issue tags are set in latches 59, and writeback tags are set in latches 61. Instruction execution unit result tags as well as any status and or exception condition information is written to the rename unit as the instructions complete. These are temporarily stored in register 60 in Figure 2.

An execution unit state scoreboard, Table 1, is maintained for each entry within the rename unit and is used to identify each state of instruction execution as the instruction progresses from dispatch through writeback. The one hot encoding of the execution state scoreboard as indicated in Table 1 is not necessary but is an effective means to speed up the priority encode operations dictated by source operand dependency analysis and instruction issue and writeback. Rename unit sources are read during the phase 0 of the master clock. The source tags are sampled by the latch 48 on phase 0. Result tags and state information are gated by the latch 49 on phase 1 of the master clock and the result data the tag data update the rename unit during phase 1 with the rotation performed on the next master clock rising edge. The operation in Figure 2 is shown as a combination of phase 0, phase 1 and edge triggered operation; however, other equivalent clocking strategies are obvious to those skilled in the art. For example, one such strategy is a self-timed clocking approach. <tables id="tabl0003" num="0003"><table frame="all"><title>TABLE 1,</title><tgroup cols="6" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="26.25mm" /><colspec colnum="2" colname="col2" colwidth="26.25mm" /><colspec colnum="3" colname="col3" colwidth="26.25mm" /><colspec colnum="4" colname="col4" colwidth="26.25mm" /><colspec colnum="5" colname="col5" colwidth="26.25mm" /><colspec colnum="6" colname="col6" colwidth="26.25mm" /><thead valign="top"><row><entry namest="col1" nameend="col6" align="center">EXECUTION UNIT STATE SCOREBOARD</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">executionunit state scoreboard</entry><entry namest="col2" nameend="col2" align="center">s4</entry><entry namest="col3" nameend="col3" align="center">s3</entry><entry namest="col4" nameend="col4" align="center">s2</entry><entry namest="col5" nameend="col5" align="center">s1</entry><entry namest="col6" nameend="col6" align="center">s0</entry></row><row><entry namest="col1" nameend="col1" align="left">completed and available for rename</entry><entry namest="col2" nameend="col2" align="center">0</entry><entry namest="col3" nameend="col3" align="center">0</entry><entry namest="col4" nameend="col4" align="center">0</entry><entry namest="col5" nameend="col5" align="center">0</entry><entry namest="col6" nameend="col6" align="center">1</entry></row><row><entry namest="col1" nameend="col1" align="left">renamed but not available for issue</entry><entry namest="col2" nameend="col2" align="center">0</entry><entry namest="col3" nameend="col3" align="center">0</entry><entry namest="col4" nameend="col4" align="center">0</entry><entry namest="col5" nameend="col5" align="center">1</entry><entry namest="col6" nameend="col6" align="center">0</entry></row><row><entry namest="col1" nameend="col1" align="left">fully available for issue</entry><entry namest="col2" nameend="col2" align="center">0</entry><entry namest="col3" nameend="col3" align="center">0</entry><entry namest="col4" nameend="col4" align="center">1</entry><entry namest="col5" nameend="col5" align="center">0</entry><entry namest="col6" nameend="col6" align="center">0</entry></row><row><entry namest="col1" nameend="col1" align="left">issued but not completed</entry><entry namest="col2" nameend="col2" align="center">0</entry><entry namest="col3" nameend="col3" align="center">1</entry><entry namest="col4" nameend="col4" align="center">0</entry><entry namest="col5" nameend="col5" align="center">0</entry><entry namest="col6" nameend="col6" align="center">0</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">completed and available for writeback</entry><entry namest="col2" nameend="col2" align="center">1</entry><entry namest="col3" nameend="col3" align="center">0</entry><entry namest="col4" nameend="col4" align="center">0</entry><entry namest="col5" nameend="col5" align="center">0</entry><entry namest="col6" nameend="col6" align="center">0</entry></row></tbody></tgroup></table></tables>

Dispatch priority encoders are used to provide the most recent rename tag for the architected source register dependency analysis. Instruction issue priority encoders are also used to identify the reservation station entry that contains the oldest instruction that has all of its source dependencies resolved and is to be launched next. One issue priority encoder is used for each of the four function unit ports P1A to P1D shown in Figure 1. Lastly, writeback priority encoders are used to identify the completion buffer entry that contains the next completed instruction that is to be written back. Again, one writeback priority encoder is applied for writeback unit port and write back of completed instructions is performed in program order. Each of the priority encoders are fixed with respect to the LRU to MRU stack position and are furthermore set up to provide either least recent rename tag or most recent rename tag entry as required by their specific application. The execution state scoreboard is updated as a conventional state machine according to a prescribed set of conditions based upon previous state and new events. However, unlike a conventional state machine, its state varies according to the rotation of the rename unit. Update of the execution unit state scoreboard is accomplished by matching the result rename tag against the same tag within the rename unit and updating the execution unit scoreboard accordingly.

The rename unit 12 maintains a record of program order although instructions issue and execute out-of-order. As mentioned above, the micro architecture is capable of speculatively executing multiple instructions including load and store instructions out-of-order. In order to realize the significant performance advantage of this aggressive execution model, it is necessary to be able to recover from a mispredicted branch or other store load conflict condition rapidly without loss of any valid completed instructions. The key to rapid recovery is the rename unit's program order stack structure which permits an instantaneous partial flush of the invalid rename tags and dispatch along the correct instruction stream.

Rapid pipeline recover via a partial flush of the contents of the rename unit is achieved by forcing a rename unit entry to state 0, completed and available for rename. This can be necessitated as a result of a mispredicted branch or a store-load conflict. Depending on a particular implementation, external interrupts may also force a partial flush if it is desired to have the shortest possible interrupt latency at the expense of wiping out valid results which in all likelihood will have to be reproduced after the interrupt service routine has completed.

The logic necessary to implement the pseudocode describing the preferred method in Table 2 can take the form of a programmable logic array (PLA) whose execution unit state scoreboard is rotated by the multiplexers 50 through 57 of Figure 2 according to the number of instructions that are dispatched in a given cycle. Table 2 describes in detail the requirements for execution unit state scoreboard state transitions in terms of "IF THEN ELSE" rules which by themselves are sufficient to drive a logic synthesis tool.

The priority encoder logic is used to provide the oldest or newest tag result from the rename unit according to the direction of the priority search. Priority encoder logic and also the construction of the PLA is well known to those skilled in the art, and for this reason it is not described in detail.

Table 2 summarizes the pseudo code for instruction dispatch, instruction issue and instruction writeback. <tables id="tabl0004" num="0004"><img file="EP0709769A2_D0001.tif" /></tables>

The Current Dispatch Window is defined as the two oldest instructions in the instruction fetch and dispatch buffer 15 (Figure 1). I0 is the oldest instruction and I1 is the next instruction in program order newer than I0. I0 produces a result which is written to rd0 and has source operands a0, b0 and c0. Similarly, the I1 instruction produces a result which is written to the register file location specified by rdl and operates on the source operands specified by the register identification fields a1, b1 and c1. <ul id="ul0002" list-style="none" compact="compact"><li>I0: opcode d0, a0, b0, c0</li><li>I1: opcode d1, a1, b1, c1</li></ul>

The dependency analysis performed on the current dispatch window is defined as the local source operand dependency analysis. The dependency analysis performed, in which the source operands arise from instructions previously dispatched, is referred to as global source operand dependency analysis.

In the following description, the pseudocode for the rename unit 12 is illustrated in the flow diagram shown in Figures 3A to 3D. The flow diagram uses the convention of diamond shaped boxes to indicate a decision (or test) operation, corresponding to an IF statement in the pseudocode, and rectangular shaped boxes to indicate a function (or action) operation, corresponding to the THEN and ELSE statements in the pseudocode. The pseudocode is itself annotated with comments between */ /* delimiters. These comments are for the most part the reference characters in the boxes of the drawing figures. The connections between figures are indicated by alpha characters in circles, as is conventional in flow diagrams.

The Local Source Operand Dependency Analysis is illustrated at 100 in the flow diagram of Figure 3A. The pseudocode, with references to the flow diagram, is as follows:<img file="EP0709769A2_D0002.tif" /><img file="EP0709769A2_D0003.tif" />

The Global Source Operand Dependency Analysis is illustrated at 120 in the flow diagram of Figure 3A. The pseudocode, with references to the flow diagram, is as follows:<img file="EP0709769A2_D0004.tif" /><img file="EP0709769A2_D0005.tif" />

The Rename Destination Result is illustrated at 140 in the flow diagram of Figure 3B. The pseudocode, with references to the flow diagram, is as follows: <img file="EP0709769A2_D0006.tif" />

The issue instruction to functional unit from ports 0-3 is illustrated at 150 in the flow diagrams of Figure 3B and 3C. The pseudocode, with references to the flow diagram, as follows:<img file="EP0709769A2_D0007.tif" /><img file="EP0709769A2_D0008.tif" />

The writeback completed instruction to and from writeback ports wbk0-wbk2 is illustrated at 170 in the flow diagram of Figure 3C and at 190 and 210 in the flow diagram of Figure 3D. The pseudocode, with references to the flow diagram, is as follows:<img file="EP0709769A2_D0009.tif" /><img file="EP0709769A2_D0010.tif" /><img file="EP0709769A2_D0011.tif" />