OUT-OF-ORDER PROCESSING WITH OPERATION BUMPING TO REDUCE PIPELINE DELAY

Abstract: A superscalar microprocessor (200) includes a scheduler (280) which stores information related to operations and issues operations for out-of-order execution by execution units (251 to 257). Operations are issued without regard for the availability of operands required for execution. After the issue stage, an operand forward stage identifies operand sources which may be a register file (290) or an operation in the scheduler (280). The scheduler (280) forwards a value and state information for the operand. The state information indicates whether an operation providing the operand was or is being completed so that execution can continue. The state information can also indicate a wait until a source operation is completed. If the wait is too long, the issued operation is bumped so that another operation can be issued and executed. This reduces hold ups and increases utilization of execution units (251 to 257).

Description: OUT-OF-ORDER PROCESSING WITH OPERATION BUMPING TO REDUCE PIPELINE DELAY TECHNICAL FIELD This invention relates to digital processor systems and to methods for managing instruction execution in an execution pipeline in a superscalar processor. BACKGROUND ART A typical computer program is a list of instructions which when compiled or assembled generates a sequence of machine instructions or operations which a processor executes. The operations have a program order defined by the logic of the computer program and are generally intended for sequential execution in the program order. Scalar processors execute the operations in the program order which limits a scalar processor to completing one operation before completing the next operation. To improve processor performance, superscalar processors have been developed which contain a vanety of execution units which are capable of operatmg m parallel so that operations can be executed and completed in parallel or out of the program order. Superscalar processors can complete more than one operation at a time and therefore can be computationally faster than scalar processors operating at the same clock speed. A scheduler in a superscalar processor may schedule execution of operations so that operations are executed out of the normal program order. Difficulties in out-of-order execution arise because one operation may depend on another in that the logic of a computer program requires that the first operation in the program be executed before the second operation Whether an operation should be executed at all often depends on the result of a branch operation If an operation that follows a conditional branch operation is executed before the branch, the execution must be speculative because the branch may skip over the instruction Additionally, many computers require that a system's state be known just before or after an operation generates an error, interrupt, or trap; but when operations are executed out of order, an operation which follows an error in a program may have been executed before the error occurred. Thus, the processor must be able to undo operations which should not have been executed and must be able to construct the system's state following an error Two somewhat conflicting goals of superscalar architecture are quick scheduling so that a processor can operate at a high clock rate and efficient scheduling to maximize parallel execution of operation which are actually required for completion of the program. Schedulers which accomplish these goals are desired. DISCLOSURE OF THE INVENTION In accordance with the invention, an out-of-order execution engine includes a set of execution units capable of operating in parallel and a scheduler which dispatches operations to the execution units. The scheduler contains entries associated with operations to be executed. An operation can either be an abortable operation, which can be executed speculatively, or a non-abortable operation which cannot be executed speculatively. Each entry includes storage for information required for execution of an associated operation and logic for directing the information to the correct execution unit when required. Operations are dispatched first according to type and availability of the required execution unit and second according to the sequential program order. However, operations which would block an execution pipeline can be bumped from early stages of the pipeline so that even instructions of the same type can be executed out of the program order. The entries in the scheduler are not specialized according to instruction type, and the execution units do not have specialized queues which can be blocked if an execution unit is stalled. After execution of an abortable operation, the results of the operation is kept in the associated entry and/or in a store queue. The scheduler keeps a result until an operation commit unit coupled to the scheduler determines that no fault or mispredicted branch precedes the associated operation. If the operation commit unit determines that the results of the oldest executed operations would be generated by sequential execution of a program, the results are made permanent by writing to a register file, a status register, or memory, and the operation is retired and removed from the scheduler. If the operation commit unit determines that a result would not be generated by sequential execution of the program, the operation is retired without making permanent changes. In one embodiment of the invention, the scheduler includes rows of entries associated with pending operations. Each entry corresponds to a single operation, and each row of entries corresponds to multiple operations, for example four operations. The scheduler in some ways operates as a shift register where information associated with a new group of operations is loaded into a top row of the scheduler and shifts down as a group toward the bottom row of the scheduler as older operations are retired. Tags indicating the age of an operation are not required because position of an operation in the scheduler indicates its age. Most operations are immediately eligible for execution when loaded into the top row of the scheduler but may be issued to execution units from any point in the scheduler. A state field in an entry for an operation indicates whether the operation has been issued, is in an execution stage of a pipeline, or has been complete. The state of the operation is independent of the operation's position in the scheduler, but the longer an operation is in the scheduler, the greater the chance that the operation will be issued and completed. Operations in a row are retired simultaneously so mat multiple operations can be completed each clock cycle. Some operations such as evaluations of conditional branches and register operations which depend on status flags are executed when the operations reach a paπicular row of the scheduler where older operations are likely complete. Accordingly, operations which depend on status flags are handled in a row where older operations have likely completed modification of the status flag values. This minimizes pipeline hold ups caused by waits for valid status flag values. The scheduler is tightly coupled to the execution units and the operation commit unit and maintains information concerning operations for multiple execution pipelines. The scheduler issues operations, provides the operation information to the execution units at times required, and holds the results from complete operations for forwarding as required for executing other operations before the results have been committed. Accordingly, the scheduler provides a single unified structure which schedules execution of operations, provides operand values required during execution, and acts as a reorder buffer. In one embodiment of the invention, out-of-order execution of operations, proceeds by: selecting a first operation from a list for issue to an execution unit, wherein the first operation is first in program order of all operations which are in the list and issuable to the execution unit during a first clock cycle; advancing the first operation to an operand forward stage duπng which operands required for execution of the first operation are to be forwarded to the execution unit, wherein advancing the first operation to the operand forward stage makes the first operation not issuable to the execution unit during a second clock cycle; selecting a second operation from the list for issue to the execution unit, wherein the second operation is first in program order of all operations which in the list which and are issuable to the execution unit during the second clock cycle; determining whether the first operation would be held up in the operand forwarding stage for more than a threshold time; removing the first operation from operand forwarding stage if the first operation would be held up in the operand forwarding stage for more than the threshold time, wherein removing the first operation from the operand forward stage makes the first operation issuable duπng a third clock cycle; and advancing the second operation to the operand forward stage in response to the first operation being removed. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows a block diagram of a computer system including a processor in accordance with an embodiment of the invention. Fig. 2 shows a processor in accordance with an embodiment of the invention. Fig. 3 illustrates an example format for RISC instructions executed by an out-of-order engine in accordance with an embodiment of the invention. Figs. 4A, 4B, 4C, and 4D show pipelines for four types of RISC operations in an embodiment of the invention. Fig. 5 shows a scheduler in accordance with an embodiment of the invention. Fig. 6 shows a circuit diagram of a poπion of a scheduler reservoir in accordance with an embodiment of the invention. Fig. 7 illustrates an example format for fields for operations and Op Quads stored in a scheduler in accordance with Fig. 5. Figs. 8A and 8B illustrate a scan chain using look-ahead for rapid selection. Figs. 9 A, 9B, and 9C illustrate a scan chain using look-ahead for rapid selection of an operation for a second execution unit. Fig. 10 is a block diagram of the interface between execution units and the scheduler of Fig. 5. Figs. 11 A, 1 IB, and 1 IC are block diagrams of processing system embodiments of the invention. Use of the same reference symbols in different figures indicates similar or identical items. MODES FOR CARRYING OUT THE INVENTION AND INDUSTRIAL APPLICABILITY The invention described in connection with the following outline: I. Overview II. Scheduler A. Scheduler Loading 1. Static Entry Fields 2. Dynamic Entry Fields 3. Op Quad Fields B. Load/Shift Control III. Operation Execution A. Issue Stage 1. Issue Selection Phase a. Issue Selection Scan Chains b. Issue Selection Scan Chains for RUY 2. Operand Information Broadcast Phase B. Operand Forward Stage 1. Operand Selection Phase 2. Operand Transfer Phase 3. Displacement Forwarding 4. Immediate Value Forwarding C. Data Operand Fetching D. Register Operation Bumping E. Load/Store Ordering F. Aboπ Handling IV. Global Control Logic A. Scheduler Information Used by Extemal Logic B. Global Control Functions V. Status Flags A. Status Flag Fetch B. Status Flag Forwarding to cc-Dep RegOps C. Branch Prediction Resolution VI. Synchronization of Non-Aboπable Operations VII. Self-Modifying Code Handling VIII. Operation Commit Unit A. Commitment 1. Register Commitment 2. Status Flag Commitment 3. Memory Write Commitment B. Op Quad Retirement C. Fault Handling 1. Load Operation Fault Handling 2. FAULT and LDDHA/LDAHA Op Handling 3. Target Limit Violation Handling 4. Mispredicted Branch Handling D. Aboπ Cycle Generation IX. Processing Systems X. Conclusion Appendix A: RISC86™ Syntax Appendix B: Pseudo-RTL Descπptions I Overview A processor in accordance with an embodiment of the invention may be applied in a vanety of applications including in a personal computer. Fig. 1 shows a block diagram of a computer motherboard 100 containing a processor 200 in accordance with an embodiment of the invention. Processor 200 is a monolithic integrated circuit capable of executing a complex instruction set and may be manufactured using conventional integrated circuit processes, such as a 5 metal layer CMOS process having 0.35 μm design rules. A chipset connected to processor 200 includes an external level- 2 cache 125, a memory controller 121 which provides an interface to a main memory 122, and bus controllers 150 and 160 which provide interfaces to local busses such as a PCI bus 155 and an ISA bus 165. Fig. 2 shows a block diagram of an embodiment of processor 200. Processor 200 has a system interface 205 which provides access to the address space of a computer system including main memory 122 and devices on local busses 151 and 161. In an exemplary embodiment, system interface 205 has a 64-bit system bus with multiprocessor cache coherency suppoπ for modified, exclusive, shared, and invalid (MESI) states and configurable bus scaling. Integrated level-2 cache control logic 210 provides an interface with a pnvate bus to an external SRAM which forms level 2 cache 125. Providing level-2 cache interface separate from system interface 210 uncouples the speed of the level-2 cache from the system bus/chipset, allowing for a faster cache, and decreases utilization of the system bus and cache bus, allowing greater bandwidth on each bus. Level-2 cache control logic 210 fuπher provides for multiple clock scaling and configurable cache sizes for up to 2 MB of data and tag storage on off-the-shelf burst pipelined synchronous SRAMs The level-2 cache uses a writeback policy and a 32 byte line size As an alternative to the configuration shown in Fig 1 , processor 200 has a single bus for system and cache access. The bus, for example, may be ptn-for-pin compatible with chipsets for processors such as the Pentium A level- 1 instruction cache 230 and a level- 1 data cache 220 are intemal to processor 200 and are connected through level- 1 cache control logic 215 to the level 2 cache and to the system bus In the exemplary embodiment, instruction cache 230 is a two-way set-associative cache containing storage for 16 KB of instructions and additional predecode information Data cache 220 is a two-way set- associative cache containing storage for 32 KB of data. To provide faster operation and avoid access conflicts, data cache 220 uses pipelined banks of dual-poπed memory which allows one read and one wnte per cycle. Instructions from ma memory 122 are loaded into instruction cache 230 In accordance with the exemplary embodiment, the instructions in main memory 122 are CISC instructions from a complex instruction set such as the PC industry standard x86 instruction set The CISC instructions are sometimes referred to herein as macroinstmctions Up to 16 bytes of CISC instmctions are fetched per cycle While loading instmcuon cache 230, instmction bytes are predecoded for rapid identification of macroinstmction boundanes Predecodmg appends code bits to each byte to indicate an offset from the byte to the staπ of the following instmction assuming that the instmction bvte is the first byte in an instmction An instmction decoder 240 executes unconditional branch instmctions, performs branch prediction for conditional branch instmctions, and conveπs the CISC instmctions fetched from instmction cache 230 into operations for an execution engine 250 Execution engine 250 implements a superscalar, out-of-order, reduced mstmction set computing (RISC) architecture A single CISC mstmction from instmction cache 230 decodes into zero (for unconditional branch instmctions), one, or several operations for execution engine 250 Multiple CISC instmctions can be decoded each cycle to create a set of RISC mstmctions which indicates the operations executed by execution engine 250. Instmction decoder 240 includes a hardware decoder (MacDec) 242 for the most common CISC instmctions and a vector decoder 244 for uncommon and more complex CISC instmctions. Vector decoder 244 contains a ROM 246 sometimes refened to herein as emcode ROM 246 which contains RISC instmction sequences, sometimes refened to herein as emcode. Vector decoder 244 selects an address in emcode ROM 246 according to a CISC instmction being decoded and replaces or modifies poπions of the RISC instmctions read from emcode ROM 246 as required to conveπ the CISC instmction to coπesponding RISC instmctions. Fig. 3 and Appendix A illustrate an example format of RISC instmctions that is optimized for execution of x86 CISC instmctions and is sometimes referred to the RISC86* instmction set. Each RISC86* instmction is either a register operation (RegOp), a load-store operation (LdStOp), or a special operation (SpecOp). RegOps are sometimes designated as a ".cc" RegOp to indicate the RegOp modifies condition codes or a "cc-dep" Reg to indicate the RegOp depends on condition codes. LdStOps are fuπher classified as either a load operation (LdOp) or a store operation (StOp). A load immediate value operation (LIMMOp) is a type of LdOp which has a different format from other LdOps and sometimes provides a large immediate value for a following LdStOp or RegOp. SpecOps include branch operations (BrOps) and floating point operation (FpOp) which have different formats Fig. 3 and Appendix A descnbe only BrOps as an example of a SpecOp A conditional branch operation (BRCOND) is a type of BrOp which depends on a condition code (field cc in Fig. 3) In the exemplary embodiment of the invention, instmction decoder 240 conveπs x86 macroinstmctions into RISC86 β instmctions (or operations) MacDec 242 conveπs common macroinstmctions into shoπ sequences of RISC86* operations For example, x86 macroinstmctions INC reg, PUSH reg, and Jcc tgt addr are decoded into a RegOp, a StOp, and a BRCOND respectively; an ADD reg, mem macroinstmctions is decoded as a LdOp and a RegOp in sequence, an ADD mem.reg macroinstmctions is decoded as a LdOp, a RegOp, and a StOp in sequence, and a LEAVE macroinstmction is decode as a RegOp, a LdOp, and a RegOp in sequence In one embodiment, instmction decoder 240 decodes up to two x86 macroinstmctions per cycle to create a set of four RISC86* operations which can be loaded into execution engine 250 in one cycle. No-op operations are used if necessary to complete a set of four operations. Two operations are decoded duπng a cycle if the two consecutive mstmctions can be identified as being instmctions which each decode to two or fewer operations. In an alternative embodiment, up to three (or more) macroinstmctions can be decoded each cycle to form a set of four (or more) operations Vector decoder 244 is used to decode macroinstmctions which are uncommon or decode to long sequences of RISC86* operations. Such sequences may be longer than four operations and may require more than one clock cycle for loading into execution engine 250. For unconditional branch macroinstmctions, instmction decoder 240 determines the next macroinstmction fetched for decoding and generates no operations. For a conditional branch macroinstmction, decoder 240 contains branch prediction logic 248 which predicts the program counter following a conditional branch instmction and generates a BRCOND which is later evaluated to determine whether the prediction was correct. Conditional branches (BRCONDs) can also occur m RISC instmction sequences from emcode ROM 246 when the macroinstmction being decode is not a conditional branch. Emcode ROM 246 includes a prediction for each such BRCOND which vector decoder 244 uses when generating a RISC instmction sequence for a decoded macroinstmction. The prediction for a BRCOND from the emcode ROM 246 are evaluated in a manner similar to BRCOND generated directly from conditional branch macroinstmction. Execution engine 250 contains seven execution units 251 to 257 which are generally capable of operating in parallel, a scheduler 280 which issues operations for execution, and an operation commit unit (OCU) 260 coupled to scheduler 280 for committing the results of operations. Each execution unit has corresponding operations which it can execute. A load unit 251 and a store unit 252 execute L Ops and StOps respectively. A store queue 270 temporanly stores data from speculative execution of StOps by store unit 252. Data from store queue 270 is wπtten to data cache 220 when the results of a StOp are committed as described below. Register units 253 and 254, also referred to herein as RUX and RUY, execute RegOps which nominally access a register file 290. A floating point unit 255 and a multimedia unit 256 are optional units which respectively execute floating point operations (FpOps) and operations for multimedia applications. In the exemplary embodiment, floating point unit 255 and multimedia unit 256 are omitted. Scheduler 280 issues operations to execution units 251 to 257, dispatches information required by the vanous execution units dunng execution, and deletes operation information as operations are retired. Scheduler 280 is paπitioned into entries where each entry contains storage and logic associated with an operation. Information in the storage of an entry descπbes an operation which is to be executed, is being executed, or has been executed. In the exemplary embodiment, sets of four entnes are organized into groups, refened to herein as rows even though entries may not be physically positioned as a row. The information associated with four operations in a row is refened to herein as an Op quad. Rows contain storage fields and logic associated with an Op quad as a group in addition to the information and logic associated with individual operations. Scheduler 280 operates in many ways like a shift register. In an exemplary embodiment, scheduler 280 is six rows deep Decoder 240 can load a new Op quad into the top row of scheduler 280 each clock cycle. The Op quad shifts down from the top row towards a bottom row from which the Op quad is retired. The position of an Op quad in scheduler 280 indicates the age or place in the program order for the Op quad; but for most operations, the position in scheduler 280 is independent of the stage of execution. Fig. 4A to 4D show multi-stage pipelines associated with RegOps, LdOps, StOps, and BrOps. Each stage in the pipelines nominally requires one processor clock cycle unless an operation is held up in one of the stages preventing operations at earlier stages from advancing. Two preliminary stages 410 and 420 are common to all the execution pipelines. During stage 410, up to 16 bytes of CISC instmctions are fetched into instmction cache 230 and predecoded to identify instmction boundaries and reduce subsequent decode time. During stage 420, instmction decoder 240 decodes up to three CISC instmctions from instmction cache 230 and forms an Op quad which is loaded into the top row of scheduler 280. Scheduler 280 then controls an issue stage 430 and an operand forward stage 440 associated with operations other than BrOps Dunng an issue stage 430, scheduler 280 scans its entnes and issues up to six operations to conesponding execution units 251 to 256 Scheduler 280 may select newer operations for issue before an older operation so that execution is out-of-order and speculative Operand dependencies are not consider dunng issue selection Scheduler 280 transmits operands to execution units 251 to 256 during operand forwarding stage 440 for the operations previously issued duπng issue selection stage 430 Duπng stage 440, some operations issued to register unit 253 or 254 may be bumped out of a pipeline to avoid long blockage of the pipeline if needed operands will not be available for several clock cycles As shown in Fig 4A, execution of RegOps is completed in the one clock cycle which is execution stage 450 Execution stage 450 of a RegOp includes an ALU phase 451 in which an aπthmetic logic unit (ALU) in register unit 253 or 254 processes the source operands of the RegOp according to the type of RegOp being executed, and a result transfer phase 452 in which a result and status values from register unit 253 or 254 are stored back in the entrv conesponding to the RegOp Results and status flags stored in the entry are subsequently committed to register file 290 and the architectural status flag register if and when it is safe to do so After or just as an operation completes, the operation's results can be committed and the operation can be retired by shifting the Op quad containing the operation out of scheduler 280 Between completion and commitment, the results and sums flags from an operation are available in scheduler 280 for execution of other instmctions Figs 4B and 4C show that LdOps and StOps require two execution stages 450 and 460 Executions stages 450 and 460 include an address calculation phase 453 which determines a viπual address for a data access, a DTLB mapping phase 455 which maps addresses for accessing data cache, and a result transfer phase which returns the result of the operation for storage in the entry corresponding to the operation Upon completion of an operation scheduler 280 receives results which are speculative and are only committed if and when it is safe to do so Fig 4D illustrates handling of BrOps When instmction decoder 240 decodes a CISC branch stmction and generates a BrOp, decoder 240 determines a new program counter for the next CISC instmction to be decoded For unconditional branches, there is no unceπainty in the new program counter, and decoder 240 completes the unconditional branch by changing the program counter Instmction decoder 240 mcludes parallel adders for fast addition of an offset and the old program counter value to calculate the new program counter value Instmction decoder 240 also includes a 16-entry retum address stack onto which stmction addresses following subroutine calls are pushed for later prediction of mstmction addresses after retum mstmctions For conditional branches, decoder 240 predicts the program counter value following a conditional branch, and inseπs a BRCOND in an Op quad loaded into scheduler 280 In the exemplary embodiment, the branch prediction is a branch correlation process which sometimes refened to in the an as two-level branch prediction. U S. pat No 5,454, 1 17, entitled "Configurable Branch Prediction for a Processor Performing Speculative Execution, " describes an example branch conelation process which may be used. The branch conelation predicts the address of the instmction executed after a branch instmction. Branch prediction logic 248 in instmction decoder 240 uses a 8, 192 -entry branch history table (BHT) where each BHT entry contains the standard two history bits indicating tendency for the branch to be taken or not taken. The entries are indexed using a combination of four bits from the program counter (PC) and nine bits of global branch history so that whether a branch is taken or not is predicted not only from the address of the branch but also from the path which program execution took in reaching the branch. This provides a better branch prediction which reduces the chance of having to flush scheduler 280 as described below. If the predicted or changed program counter hits in a 16-entry branch target cache of decoder 240, the next CISC instmction is ready for decoding by the end of x86 instmction decode stage 420. Otherwise, a clock cycle 424 is required to calculate an address and fetch the next CISC instmction for decoding. Like all other operations, conditional branch operations (BRCONDs) loaded into scheduler 280 shift toward the bottom of scheduler 280 as older operation are retired, but no issue selection scan is used for BRCONDs. A BRCOND enters a branch condition evaluation stage 464 when the BRCOND reaches row 4 of scheduler 280. Branch evaluation unit 257 can evaluate one BRCOND per cycle provided that the condition codes (cc) required for each BRCOND are valid. Branch evaluation unit 257 determines the conect program counter following the BRCOND and whether the BRCOND was correctly predicted. The required condition codes are likely to be valid when the BRCOND reaches row 4 because older operations (those in rows 4 and 5) are likely to have been completed. If the required condition codes are not yet valid, the BRCOND is held up by preventing the Op quad from shifting out of row 4. When a BRCOND is held up. Op quads above row 4 are prevented from shifting unless one or more of rows 0 to 3 is an empty (i.e. invalid) Op quad. If each of rows 0 to 3 contains valid Op quads, instmction decoder 240 cannot load a new Op quad into scheduler 280 while the BRCOND is held up. Shifting of rows 4 and 5 is also held up if shifting of row 3 is held up because shifting row 4 or 5 would require creating an empty Op quad and the exemplary embodiment can only create an empty Op-quad in the top row of scheduler 280. If a branch was correctly predicted, fetching, decoding, and executing operations continue without interruption. If the branch was inconectly predicted, scheduler 280 restaπs decoder 240 at the correct instmction address following the BRCOND so that decoder 240 staπs fetching and decoding the right instmctions while results from operations older than the mispredicted branch are committed and retired from scheduler 280. Loading of new instmctions into scheduler 280 is inhibited until the mispredicted BRCOND is retired and scheduler 280 is flushed. When the mispredicted branch is retired, execution unit 250 is flushed by invalidating every operation in scheduler 280 and in execution units 251 to 257. All operations can be invalidated because all operations preceding the mispredicted branch must have been completed and retired before the mispredicted branch shifts out of the bottom row of scheduler 280 and no new instmction are loaded into scheduler 280 before the mispredicted branch is retired. Invalidating all operations simplifies the process because no identification of operations which must be retained is required. Delaying loading of new instmctions has a minimal effect on performance because typically the mispredicted branch shifts down to the bottom row and is retired after two clock cycles which is about the same amount of time required for decoder 240 to fetch and have available the first new mstmctions. Execution engine 250 executes aboπable and non-aboπable operations. Non-aboπable operations cannot be speculatively executed and are only executed when the results can be safely committed. Aboπable operations are speculatively executed After an aboπable operation reaches the final stage of its pipeline and is completed, any result from the execution is stored in scheduler 280 until operation commit unit 260 determines that committing the results is safe. Each cycle, one Op quad (up to four operations) can be committed and retired from scheduler 280 II. Scheduler Fig. 5 shows the exemplary embodiment where scheduler 280 contains 24 entnes associated with up to 24 operations Each entry includes storage elements (nominally flip-flops) in a scheduling reservoir 540 and poπions of logic 530, 532, 534, 536, and 538 associated with the entry The storage elements store information regarding an operation (Op) which is awaiting execution, being executed, or completed An operation decoder 510 receives four RISC86 ® operations from instmction decoder 240 and loads or initializes a new Op quad in the top row of scheduler reservoir 540 The fields in reservoir 540 are shown in Fig. 7 and are related to but not identical to die fields of the associated RISC86* instmctions shown in Fig. 3 Some fields retain the same value throughout execution of the associated operation and are refened to herein as "static fields " Other fields are loaded or changed later such as when the operation completes execution and arc refened to as "dynamic fields. " The storage elements in scheduling reservoir 540 can be loosely viewed as a shift register that is six rows deep. Each row contains four entnes, each entry associated with a RISC86 ® instmction Each clock cycle, an Op quad that is not held up in a row shifts down to the next row if the next row is empty or contains an Op quad that is also shifting downward The Op quad in the bottom row (row 5) shifts out of scheduler 280 if all operations associated with the bottom row have been committed. Fig. 6 shows an embodiment of a poπion of scheduling reservoir 540. The poπion of scheduling reservoir 540 shown in Fig. 6 includes a storage element (edge triggered flip-flop 623) for a dynamic field in row 3 of scheduler 280 and a storage element (edge tπggered flip-flop 643) for a static field in the same row. Row 3 contams similar storage elements for each bit in the dynamic and static fields as shown in Fig. 6 and described below. The other rows in scheduling reservoir 540 are similar or identical to row 3 and are connected in senes with row 3. In Fig. 6, flip-flops 642, 643, and 644 store a bit of the same static field in respective rows 2, 3, and 4; and a bit value associated with an Op quad shifts from flip-flop 642 to flip-flop 644 as the Op quad shifts from row 2 to row 4. Global control logic 520 generates signals LdEntry[i], one for each row (i = 0 to 5), which control whether shifts to the conesponding rows occur. The rows are overwritten at the rising edge of clock signal CLK. For example, a signal LdEntry3 either enables or disables flip-flop 643, and a signal LdEntry4 either enables or disables flip-flop 644. Accordingly, when an Op quad is held up in row 4, signal LdEntry4 is deasseπed so that flip-flop 644 retains a value. The independence of signals LdEntry[i] allows filling of empty Op quads entries which may be above a held up Op quad. For example, if an Op quad is held up in row 4, signal LdEntry3 can be asseπed so that a value OpField2 from row 2 shifts into row 3 at the rising edge of clock signal CLK. (Empty rows may result if, for example, instmction decoder 240 is unable to provide an Op quad every cycle because of a branch target cache miss.) Table B.1 in Appendix B describes operation of circuitry implementing static fields. Dynamic fields are more complicated than static fields because new data from outside scheduling reservoir 540 may be inseπed into a dynamic field while shifting old data, and the new data must stay with the conect Op quad which may or may not shift to the next row. Signals OpFieldValue2 and OpFieldValue3 represent information associated with respective first and second Op quads in rows 2 and 3. Circuitry outside scheduler reservoir 540 generates signals NewValue2 and NewValue3 to change the information associated with the first and second Op quads respectively. Multiplexer 632 selects whether a new information signal NewOpField2 changes to new value NewValue2 to change the first Op quad or stays equal to old value OpFieldValue2. Multiplexer 633 selects whether a new information signal NewOpField3 changes to new value NewValue3 or stays equal to old value OpFieldValue3. Whether dynamic field values associated with the first Op quad changes or not, value NewOpField2 can be written into row 2 or written into row 3 at the rising edge of clock signal CLK. For the first Op quad to shift into row 3, signal LdEntry3 causes a multiplexer 613 to select signal NewOpField2 as signal NextOpField3 which is written to flip-flop 623 at a rising edge of signal CLK. To prevent the first Op quad from shifting into row 3, signal LdEntry3 causes multiplexer 613 to select signal NewOpFiekD which is written in flip-flop 23. Signal LdEntry4 and multiplexer 614 similarly select whether the second Op quad is allowed to shift from row 3 into row 4. Table B.2 in Appendix B describes operation of circuitry implementing dynamic fields. ILA Scheduler Loading Instmction decoder 240 decodes macroinstmctions and forms sets of four RISC86 instmctions which are transmitted to scheduler 280 whenever row 0 (the top) of scheduler 280 is empty or contains an Op quad that is shifting to row 1. Emcode ROM 246 can contain an Op quad where not all of the operations in the Op quad are actually pan of implementation of an x86 instmctions. This may occur because different x86 mstmctions have different entry pomts in the same code in emcode ROM 246 or because an operation within emcode ROM 246 causes a branch into the middle of an Op quad. Instmctions not required for the x86 instmction being decoded are nulled (changed to NO-OPs). Instmction decoding also includes environment vanable substitution for fields of operations. For variable substitution, an emulation environment maintains environmental vaπables which include, for example, default address and data sizes and register numbers for the cunent code segment and x86 mstmction being decoded The environmental variables replace placeholder values in operations from emcode ROM 246. Environment vanable substitution increases flexibility of emcode ROM 246 because different environmental variables conveπ one emcode section to implement different x86 instmctions. Instmction decoder 240 and/or operation decoder 10 perform environmental vanable substitution as required. In scheduler 280, operation decoder 510 receives an Op quad from instmction decoder 240 and fills storage fields in the top row of scheduling reservoir 540 If no Op quad is available from instmction decoder 240, operation decoder 510 creates an empty Op-quad when the Op quad in the top row shifts down. Fig. 7 illustrates an example of static entry fields 541 , dynamic entry fields 542, and Op quad fields 549 in scheduler reservoir 540. The initial values of entry fields 541 and 542 depend on a conesponding RISC86 stmction Operation decoder 510 modifies some fields from the RISC86 instmctions based on other fields, deπves new fields from existing ones, replaces some fields with physically different fields, and passes a few fields through unchanged Op quad fields are generated from information conesponding to the Op quad as a whole. II. A 1 Static Entry Fields In the exemplary embodiment, each entry contains static fields 5 1 which are defined as follows, where all signals are active high. Field Type[2.0] specifies the type of operation associated with the entry Possible types include: SpecOp; LdOp; StOp; StOp which references memory or generates a faultable address; RegOp executable only by register unit 253, and RegOp executable by either register unit 253 or 254. Multimedia unit 256 executes selected types of RegOps which are related to multimedia applications. Floatmg point operations (FpOps) are a type of SpecOp executed by floating point unit 255. Table B.3 in Appendix B describes circuitry in operation decoder 510 which generates a value for field Type. Field LD Imm indicates whether the operation requires an immediate value from a preceding LIMMOp. The immediate value is a large displacement if the operation is a LdStOp that uses a large displacement versus a small (8-bit) displacement held within field DestVal of the entry. For a RegOp, the immediate value is the second operand Src2. Table B.4 in Appendix B descnbes circuitry in operation decoder 510 which generates a value for field Ld lmm. Fields SrclReg[4:0], Src2Reg[4:0], and SrcStReg[4:0] hold register numbers identifying registers which respectively hold the first source operand Srcl, the second source operand Src2, and the store data operand of the operation. Tables B.5, B.6, and B.7 in Appendix B descnbe circuitry in operation decoder 510 which generates values for fields SrclReg, Src2Reg, and SrcStReg. Field DestReg[4:0] holds a register number identifying the destination register of the operation. Table B.8 in Appendix B describes circuitry in operation decoder 510 which generates a value for field Des t Reg. Fields SrclBM[l :0], Src2BM[l :0], and Srcl2BM[2] indicate which bytes of operands Srcl and Src2 must be valid for execution of the operation. By definition, SrclBM[2] and Src2BM[2] are equal to Srcl2BM[2]. Bits 2, 1 , and 0 of SrclBM[ l :0] and Src2BM[ l :0], indicate bus [31 : 16], [15:8], and [7:0], respectively. Table B.9 in Appendix B descπbes circuitry in operation decoder 510 which generates values for fields SrclBM[l :0], Src2BM[l :0], and Srcl2BM[2]. Field SrcStBM[2.0] indicates which bytes of the store data operand are required for completion of a StOp. The bit conespondence is the same as for SrclBM or Src2BM. Table B.10 in Appendix B describes circuitry in operation decoder 510 which generates a value for field SrcStBM Field Oplnfo[12:0] holds additional information for the execution units or the operation commit unit (OCU) depending on whether the operation is executable. Field Opinfo has three possible field definitions, depending on whether the operation is a RegOp, a LdStOp, or a SpecOp For a RegOp, field Opinfo contains a concatenation of: six bus from the RISC86 Type field; four bits from the RISC86 Ext field; the RISC86 Rl field; and two bits indicating an effective data size DataSz for the operation. For a LdStOp. field Opinfo contains a concatenation of: four bits from the RISC86 Type field; two bits from the RISC86 ISF field; four bus from the RISC86 Seg field; two bits indicating the effective data size DataSz for the operation: and a bit AddrSz indicating the effective address size for the address calculation (32/16 bits). For a SpecOp. field Opinfo contains a concatenation of four bits from the RISC86 Type field and five bits from the RISC86 cc field. Table B. l l in Appendix B describes circuitry in operation decoder 510 which generates a value for field Opinfo. II .A.2 Dynamic Entry Fields Dynamic entry fields 542 are initialized by operation decoder 510 but can change during execution of operations. Typically, each entry contains logic for changing dynamic fields as required. The dynamic fields 542 for an entry in the exemplary embodiment are defined as follows. Field State[3:0] indicates an operation's execution state with respect to the pipelines of Fig. 4A to 4D. (S3,S2,S1,S0 are alternate signal names for State[3:0].) Field State encodes five possible states by shifting a field of ones across four bits. Value bOOOO indicates an "Unissued" state; bOOOl, bOOl l , and bOl 1 1 indicate an operation at operand forward stage, execution stage 1 , and execution stage 2; and bl 1 11 indicates an operation is completed. Most operations enter scheduler 280 with field State set to bOOOO, "unissued", and field State changes after the operation issues to an execution pipeline. Field State is updated (effectively shifted) when the operation issues or advances out a pipeline stage. Upon completion of the pipeline, field State is set to bi l l 1 while the operation awaits being committed and retired. Field State of every entry is set to bl 111 during aboπ cycles. Some operations (e.g. load constant operation LDK) have an initial state field value of 1111 and thus are already completed when loaded into scheduler 280. Table B.12 in Appendix B describes circuitry in operation decoder 510 which initializes field State and circuits in the entries of scheduler 280 which modify field State during execution of the associated operation. Field Execl indicates register unit 253 (not 254) is executing the operation and is set when the operation has successfully been issued execution unit 253. Table B.13 shows the logic which sets and changes field Execl . Field DestBM[2:0] holds byte marks indicating which bytes of the register indicated by field DestReg the operation modifies. DestBM[2], DestBM[ l], and DestBM[0) conespond to bits [31 : 16], [ 15:8], and [7:0] respectively. Field DestBM is initialized by operation decoder 510 and may be cleared during an aboπ cycle. Logic associated with field DestBM is described in Table B. 14 of Appendix B. Field DestVal[31 :0] holds results from execution of the operation, to be committed to DestReg. DestBM indicates which bytes are valid after operation execution. Field DestVal is loaded when the operation completes execution stage 1 or 2 (depending on the type of operation); for non-executed operations (e.g. LDK), DestVal is initialized with the appropriate result value. Field DestVal can be used for temporary storage before results are stored when an operation is completed. ln the exemplary embodiment, field DestVal initially holds immediate and displacement values for RegOps and LdStOps respectively, and the alternate (sequential or target) branch program counter value for a BRCOND. Logic associated with field DestVal is described in Table B.15 of Appendix B. Field StatMod[3:0] holds status group marks indicating which groups of status flags an operation modifies. Bits 3, 2, 1 , 0 respectively conespond to flag bit groups {EZF.ECF}, OF, {SF.ZF.AF.PF}, and CF where flags bits EZF, ECF, OF, SF, AF, PF, and CF may be modified by RegOps. Field StatMod is all zeroes for non-RegOps and is cleared during aboπ cycles. Logic associated with field DestVal is described in Table B.16 of Appendix B. Field StatVal[7:0] holds the operation's status result value which is to be committed to status register EFlags. StatMod indicates which flag groups are affected after execution. StatVal is significant only for RegOps; this is reflected by StatMod. StatVal is loaded when the RegOp completes execution stage 1. Logic associated with field StatVal is described in Table B.17 in Appendix B. Fields OprndMatch_XXsrcY, where "XX * is LU, SU, RUX, or RUY and "Y" is 1 or 2, are additional storage elements for transient information that is passed between two pipeline stages in contrast to information of more global significance. Table B.18 in Appendix B describes logic which controls fields OpmdMatch XXsrcY. Field DBN[3:0] holds four data breakpoint status bits Bn (n=0 to 3) for a LdStOp. This field is initially all zeroes, then, when the associated LdStOp executes, breakpoint bits from the appropriate unit are recorded for later trapping. Table B.19 in Appendix B describes logic associated with field DBN[3:0]. II .A.3 OP Quad Fields Each row in scheduler 280 contains four entries plus Op quad fields 549 associated with the Op quad as a whole. The following enumerates the additional Op quad fields 549 shown in Fig. 7. Operation decoder 510 initializes Op quad fields. Most Op quad fields are static. Some Op quad fields are dynamic, and logic in each row of scheduler 280 changes the dynamic Op quad field as required. Field Emcode indicates whether the Op quad is from MacDec 242 or vector decoder 244 (i.e. emcode ROM 246) Table B.20 describes setting of field Emcode. Field Eret indicates whether this is an emcode Op quad and that is marked as the last Op quad in a series of Op quads representing a complex macroinstmction. Table B.21 describes logic which sets field Eret. Field FaultPC[31 :0] holds the logical macroinstmction fault program counter value associated with the first operations in the row. Operation commit unit 260 uses field FaultPC when handling fault exceptions. Table B.22 describes logic which sets field FaultPC. Field BPTInfo[ 14:0] holds branch prediction table-related information from when the Op quad was generated. Field BPTInfo is defined only for MacDec-generated Op quads which contain a BRCOND. Table B.23 describes logic which sets field BPTInfo. Field RASPtr[2:0] holds a pointer to the top of the retum address stack as of when the Op quad was generated. Field RASPtr is defined only for MacDec-generated Op quads which contain a BRCOND. Table B.24 describes logic which sets field RASPtr. Field LimViol indicates that the Op quad is the decode of a transfer control instmction for which a code segment limit violation was detected on the target address. For most rows, field LimViol is static. Field LimViol is loaded in row 1 as summarized in Table B.25 in Appendix B. Field OpQV indicates whether the row contains a valid Op quad and global logic 520 use field OpQV when controlling the shifting of Op quads. Invalid Op quads may be overwritten if an Op quad lower in scheduler 280 is held up. Fields in a row containing an "invalid" Op quad have the same values as an aboπed Op quad, and an Op quad can become invalid as a result of an aboπ. Table B.26 of Appendix B describes logic controlling field OpQV. Fields OplI, Op2I, and Op3I hold a count (1 , 2, or 3) of the number of macroinstmctions represented by an Op quad and are used to count retired instmctions. Fields IlenO and Ilenl hold lengths in bytes of the first and (if present) second macroinstmctions represented by the Op quad and are used to determine the instmction address at which a fault occuned. Fields SmclstAddr, SmclstPg, Smc2ndAddr, and Smc2ndPg hold the first and (if instmctions from more than one page are in the Op quad) second addresses covered by operations in the Op quad and are used to detect self-modifying code. II .B Load/Shift Control As described earlier, scheduler 280 manages 24 entnes as a shift register (or FIFO buffer) containing six rows. Scheduler 280 is not as rigid as a shift register in that each row has an independent shift control (actually a load control signal LdEntry[ι|). An Op quad can shift down to the next row (and die preceding Op quad can shift down into this row from above) as long as the next row is empty or being emptied. Op quads always shift down into higher numbered rows when space is available. Ideally each Op quad shifts down one row each clock cycle, at a clock cycle boundary. For most operations, position in scheduler 280 is independent of pipeline stage for the operation. Accordingly, most operations shift down in scheduler 280 even if held up in an execution pipeline. Two exceptions are operations that depend on status flags and any operation in the bottom row of scheduler 280. Operations which depend on status flags have a stage which must be executed when the operation is in a paπicular row of scheduler 280 and thus inhibit shifting until the stage is completed. Operations in row 5 inhibit shifting or retirement of an Op quad from row 5 until all operations in row 5 are completed and committed. Table B.27 in Appendix B describes circuitry in global control logic 520 which generates signals LdEntryO to LdEntry5 that control shifting in scheduler 280 and signals SchedFull and SchedEmpty which indicate whether scheduler 280 can accept a new Op quad at the end of the cunent cycle. HI. Operation Execution Physically, scheduling reservoir 540 is a storage stmcture which holds state values for operations. In addition to reservoir 540, scheduler 280 includes logic which operates on the state values during operation execution. From a control perspective, scheduler 280 is a pipelined data path which generates control information for execution of operations through the processing pipelines and handles execution results. Scheduler storage and state changes are synchronous with the system clock, i.e. all state changes in scheduler 280 are on the rising edge of the system clock so that all storage elements in scheduler 280 (at least logically) are edge-triggered flip-flops such as described in regard to Fig. 6. From a logical perspective, all state sequencing within scheduler 280 is single cycle in nature. State transition decisions are made each cycle based on the machine state during the cycle. The stmcture of scheduler 280 reflects the pipelined nature of operation execution Logic in scheduler 280 (and correspondingly each entry) can be divided into many distinct, largely independent chunks of logic, each of which is directly associated with a specific processing stage of a given type of operation or execution pipeline. From the perspective of a paπicular processing pipeline, a chunk of scheduler logic associated with each stage provides key control information for the processing done in that stage and/or for determining when that stage can successfully complete. From the perspective of a given stage as viewed across all processing pipelines (at least for the first couple of stages), very similar chunks of logic perform the same function for each pipeline or for each operation source operand of each pipeline. Figs. 4A to 4D show pipeline timing for four types of operations For these types, an operation is loaded into scheduler 280 after instmction decode stage 420 A BrOp is completed in branch evaluation stage 490 which occurs when the BrOp reaches row 4 of scheduler 280 RegOps, StOps, and LdOps go through a three or four stage pipeline, and conespondingly transition between four or five states Field State[3 0] within a scheduler entry tracks or represents the stage of the operation associated with the entry Op issue stage 430 and operand forward stage 440 of Fig 4A and 4C are common to all RegOps, LdOps, and StOps and are descnbed below Following operand forward stage 430 are the execution stages RegOps have just one execution stage 450 because register units 253 and 254 execute all RegOps in a single cycle Further, once a RegOp enters execution stage 450. it always successfully completes and exits stage 450 at the end of that clock cycle. LdOps and StOps have two execution stages 450 and 460, dunng which address calculation 453, segment and page translation (and protection checking) and data cache mapping 455, and results transfer 462 take place. Unlike RegOps. LdOps and StOps can be held for arbitrary penods in either stage 450 or 460 Most hold-ups of LdOps (most notably data cache and data translation lookaside buffer (DTLB) misses and faults) apply to the last stage 460 Hold ups in stage 450 stem from misaligned memory references and from stage 460 being occupied and blocked by an operation not advancing to completion Scheduler 280 controls pipelines created by the execution engines such as load unit 251 , store unit 252, register units 253 and 254, floating point unit 255, and multimedia unit 256 The exemplary embodiment of the invention includes register units 253 and 254, load unit 251, and store unit 252 Application of aspects of the invention to processors having more or fewer execution units will be apparent in view of this disclosure. For example, in an embodiment containing multimedia unit 256, multimedia unit 256 can be logically considered as pan of the first register unit 253 so that operations for multimedia umt 256 are issued, operands are forwarded, and results are transfened using circuitry used for register unit 253. In one embodiment, floating point unit (FPU) 255 has its own independent register file and commit unit; and scheduler 280 contains a scan chain selecting FpOps for issue to FPU 255. Scheduler 280 issues an FpOp and forwards operands to FPU 255. Execution of the FpOp affects only registers in the register file associated with FPU 255 so that scheduler 280 does not require results from FPU 255. FPU 255 can signal that a FpOp is complete immediately, long before FPU 255 actually completes or commits the FpOp. OCU 260 commits and retires the FpOp from scheduler 280 without changing anything. Each of register units 253 and 254 provides a pipeline refened to as an RU pipeline or as RUX or RUY pipeline to distinguish register unit 253 from register unit 254. Each RU pipeline has three stages refened to as issue stage 430, operand forward stage 440, and execution stage 450. Load unit 251 and store unit 252 respectively provide LU and SU pipelines which have four stages: issue stage 430, operand forward stage 440, and execution stages 450 and 460. As descnbed above, the State field represents five states of an operation using "shifting/increasing field of ones" encoding to indicate the cunent pipeline stage of the associated operation or indicate that the operation has completed us pipeline. Scheduler 280 has pnmary control of issue stages 430 and operand forward stages 440 Processing within issue and operand forward stages 430 and 440 is broken down into two phases per stage, the phases nominally occumng during the first and second halves of the system clock cycle. Issue stage 430 includes an issue selection phase 431 and a broadcast phase 432. Operand forward stage 440 includes an operand selection phase 441 and an operand transfer phase 442. Dunng issue selection phase 431 , scheduler 280 selects the next operations to enter each of the pipelines. In the exemplary embodiment, for example, four operation selections occur at once for the LU, SU, RUX, and RUY pipelines. Dunng broadcast phase 432. information about the operands of each selected operation is broadcast to all scheduler entnes and to extemal logic. Dunng operand selection phase 441. scheduler 280 uses the information from broadcast phase 432 to locate operands (up to 2*"ιhe number of execution units" operands). The sources of an operand may be register file 290, scheduling reservoir 540, or a result bus 561 , 562, 563. or 564 of an execution unit 251, 252, 253, or 254. Scheduling reservoir 540 contams fields for immediate values, results which have not been committed, and information concerning operations preceding in program order but not completed. The result bus of an execution unit is the source of an operand if the execution unit is completing an operation which affects the required operand. Scheduler 280 also determines the status of each operand value, i.e. whether a valid value is in fact available from the designated source. Based on this information, scheduler 280 determines in operand forward stage 440 which of the operations advance into execution stage 450. Advancement is independent for each pipeline. Only explicit operand dependencies constrain the order with which operations are executed. Except for such dependencies, different types of operations are processed through their respective pipelines in arbitrary order with respect to other types of operations. During operand transfer phase 442, scheduler 280 transfers operand values from the designated sources over operand busses 554 to execution units 251 to 254. As shown in Fig. 5, the exemplary embodiment has nine operand busses 554, eight of which provide operand values for operations in operand forward stage. Embodiments having more execution units, such as embodiments having a floating point unit 255, may have more operand busses. Operand transfer occurs regardless of whether operand values are valid. If an operand value is invalid, the associated operation does not advance to execution stage 450 so that the execution unit doesn't use the invalid operand. Duπng operand transfer phase 442 of LdOps and StOps, displacement forwarding 443 transfers displacement operands via displacement busses 555, to load unit 251 and store unit 252 (one to each unit). The displacement operands are 32-bit values from scheduler entnes. Selection of source entnes for displacements occurs dunng operand selection phase 441 When a LdOp or a StOp enters execution stage 450, load and store units 251 and 252 latch associated displacement and operand values and holds them as long as the operation remains in stage 450. Scheduler 280 has limned control of the pipeline execution stages 450 and 460. In stages 450 and 460, scheduler 280 keeps track of operations' states and captures resultant register and status values. Address calculation 453 in execution stage 450 determines an address accessed by the LdStOp If the address and data size for a LdStOp causes a data access which extends across a boundary between entnes in the data cache the LdStOp is refened to herein as being misaligned. Misaligned LdStOp are split into two data accesses; a first access advances to execution stage 460 while the second access is held up in execution stage 450. The state field of the scheduler entry associated with the misaligned LdStOp indicates the execution stage of the second access In addition to the four phase process for obtaining the source operands for staπing execution, scheduler 280 performs a similar four phase process for obtaining the data operand for a StOp, but the data operand is obtained for the StOp in SU stage 460 The process for providing the store data is synchronized with stages 450 and 460 of the StOp and includes an operation selection phase 456 identifying the StOp in execution stage 450. a broadcast phase 457 transmitting information descnbing the source of a data operand, a data operand selection phase 461. and data operand transfer phase 462 In essence, a store data operand is fetched in parallel with StOp execution, and the actual data value is obtained and transfened to store queue 270 upon completion of the StOp Completion and exiting stage 460 corresponds to the creation of a store queue entry for the StOp, based on the data selected in phase 461 and the physical address from address calculation 453 and DTLB mapping 455. If a valid data operand or physical address is not yet available, the StOp is held in stage 460. Besides the chunks of scheduler logic 530 and 532 associated with operation issue and operand forwarding, entnes include chunks of logic 534 associated with ordenng load and store operations. Just as some execution ordenng must be maintained between operations due to register dependencies, a limited execution ordenng is also maintained between LdOps and StOps due to memory dependencies (e.g. LdOps cannot freely execute ahead of older StOps). Load-store ordenng applies to StOps which access memory and to StOps such as CIA (check instmction address) and CDA (check data address) operations which reference memory and/or generate faultable addresses but not to LEA (load effective address) operations. No LdOps are excluded from load-store ordering since all LdOps reference memory. The load-store ordering is enforced at stage 460 of the two execution pipelines where a LdOp or a StOp in stage 460 is held until completing the operation is safe. Up until stage 460, no ordering is maintained between the LU and SU pipelines. Fuπher, LdStOps can generally complete out-of-order when memory independence is "proved" by paπial address comparisons with older LdStOps. Store queue 270 performs address comparisons associated with dependency checking but requires scheduler suppoπ in determining the relative ages of LdOps and StOps in the LU and SU execution pipes. Only the appropnate address compansons (a LdOp to older StOps and a StOp to older LdOps) are considered in determining whether a given LdOp or StOp is allowed to complete. Load-store ordering logic 534 includes logic associated with the LU pipeline and logic associated with the SU pipeline. The logic associated with the LU pipeline determines the age of any LdOp in LU stage 460 relative to any StOps in SU stages 450 or 460. and any other StOps. Logic 534 generates three signals SC SU20LDER, SC SU IOLDER, and SC SU0OLDER on a bus 556 io indicate whether a StOP in SU stage 460, stage 450, or elsewhere is older than the LdOp in LU stage 460. The logic associated with the SU pipeline determines the age of any StOp in SU stage 460 relative to any LdOps in LU stage 460 and any other LdOps and generates two signals SC LU20LDER and SC LU 1 OLDER to indicate whether any LdOps are older than the StOp in stage 460. Scheduler 280 fuπher includes status flag handling logic 538 associated with acquinng and using status flag or condition code (cc) values. Three relatively independent areas of functionality are involved: fetching status flag values for status-dependent RegOps executed by register unit 253, fetching su s flag values for resolution of BRCONDs by branch evaluation unit 257, and synchronizing non-aboπable RegOps with preceding BRCONDs The RUX execution unit executes status-dependent ("cc-dep" ) RegOps and requires a status operand value at the same time as the register operand values, i.e by the end of operand forward stage 440. CC-dep RegOps are not allowed to advance to execution stage 450 until reaching row 3 and are kept in row 3 until they receive valid condition codes. Unlike the fetching of register values, the status fetch process is not pipelined and occurs in one cycle, i.e. entirely duπng RUX operand forward stage 440. Further, the same logic 538 fetches up-to-date status flag values for both cc-dep RegOps and BRCONDs. For cc-dep RegOps, condition codes are passed to execution unit 253 while validity of the status values needed by the RegOp is checked. If valid values for all required status flags are not yet available, the RegOp is held up in operand forward stage 440 (the same as for register operand values not yet available). BRCONDs do not require any actual execution processing. Instead, while a BRCOND is outstanding (and before it reaches the bottom of scheduler 280), the BRCOND is resolved as correctly predicted or not. BRCONDs are resolved in order, at a rate of up to one BRCOND per cycle. When a BRCOND reaches row 4, status flag handling logic 538 checks to determine whether valid status flags for evaluation of the BRCOND are available either from register file 290 or an operation older than the BRCOND. Flag handling logic 538 also determines whether the older operations, if any, that provide the sutus flags required for evaluation of the BRCOND are completed If values for the required status flags are not yet available, resolution of the BRCOND is held up by inhibiting shifting of the Op quad containing the BRCOND When the stams flag values required for the next unresolved BRCOND are available, status flag handling logic 538 passes the status flag values to branch evaluation unit 257 which determines whether the condition code specified within the BRCOND was conectly predicted. If the BRCOND was inconectly predicted, restaπ signals are asseπed to staπ the mstmction fetch and decode poπions of mstmction decoder 240 (Fig 2) at the conect branch address If the operation was conectly predicted, nothing happens The resolution of BRCONDs is significant to the execution of non-aboπable RegOps Execution of non-abonable RegOp results in changes that cannot be aboπed or undone Accordingly, non-aboπable RegOps are prevented from enteπng execution stage 450 until execution of the RegOp is safe This requires all preceding BRCONDs be resolved and determined to have been conectly predicted before the non-aboπable RegOp can advance to execution stage 450 Consequently, while any preceding BRCOND remains unresolved or has been found to have been mispredicted, the non- aboπable RegOp is held in operand forward stage 440 If preceding BRCONDs were conectly predicted, the delay is temporary, but if a preceding BRCOND was inconectly predicted, the RegOp is held up until an eventual aboπ cycle flushes scheduler 280 Vector decoder 244 generates non-aboπable RegOps from emcode ROM 246 In emcode ROM 246, no operations which have an implied dependence on the results of a non-aboπable RegOp are allowed in the Op quad immediately preceding the Op quad containing the non-aboπable RegOp Accordingly, when the non-aboπable RegOp is executed in row 4. no operation in row 5 has implied dependence on the non-aboπable RegOp, and all older which may have had an implied dependence on the non-aboπable RegOp are retired and therefore completed before the non-aboπable RegOp is executed in row 4 III A Issue Stage Scheduler 280 performs issue selection and broadcast phases 431 and 432 in parallel for each execution pipeline requinng an issue scan and operands. In the exemplary embodiment, issue stage operations are performed m parallel for load unit 251, store unit 252, register unit 253, and register HI. A 1 Issue Selection Phase Each cycle, scheduler 280 attempts to select an operation for issue to each unit capable of parallel execution. In the exemplary embodiment, scheduler 280 selects a LdOp, a StOp, and two RegOps to be issued to LU, SU, RUX, and RUY pipelines. For issue selection phase 431 , scheduler 280 scans all entries in scheduling reservoir 540 "in order" from oldest to newest operations and selects operations for issue based on fields State and Type of the entries. Issue selection 431 does not consider register sutus or memory dependencies that operations may have on each other. This simplifies the issue selection process and allows issue selection phase 431 to be quickly completed for a relatively large reservoir 540. Issue selection is simultaneous and independent for each of the four processing pipelines. For each pipeline LU, SU, and RUX, the next unissued operation (as indicated by its State field) which the pipeline can execute (as indicated by field Type) is selected. In other words, the next unissued LdOp is selected for load unit 251, the next unissued StOp is selected for store unit 252, and the next unissued RegOp is selected for register unit 253. For register unit 254, a RegOp following the RegOp selected for pipeline RUX is selected. Conceptually, the issue selection for pipeline RUY depends on issue selection for RUX; but physically, issue selection for RUY is performed in parallel with issue selection for RUX. For the scans, each scheduler entry generates four bits (i.e. one bit for each pipeline) IssuableToxx which indicate whether the associated operation is cunently eligible for issue selection to pipeline xx where xx is LU, SU, RUX, or RUY. The issue selection process for pipeline xx scans from the oldest scheduler entry to the newest scheduler entry searching for entries with bit IssuableToxx set. For pipelines LU, SU, and RUX, the first operation found with the desired bit IssuableToLU, IssuableToSU, or IssuableToRU set is the one selected for issue to pipeline LU, SU, or RUX. Issue selection for pipeline RUY selects the first operation with IssuableToRUY set following the operation selected for pipeline RUX. Operations are eligible for issue selection immediately upon being loaded into scheduler 280, i.e. an operation can be issued during its first cycle in scheduler 280. In such cases, only the Type bits and bit SO need to be valid at the beginning of the cycle. All other fields in an entry can be generated as late as the end of issue selection phase 431 (i.e. up to one half cycle later) and only need to be valid within a scheduler entry for broadcast phase 432. If an operation selected for issue does not advance into operand forward stage 440, the operation remains unissued, and during the next clock cycle, that operation competes for issue and will probably be selected again. HLA. I.a Issue Selection Scan Chains In one embodiment of the invention, scheduler 280 scans the operations using scan chain circuits formed from logic blocks associated with the entries. Each scan chain is similar to a carry chain such as used in some adders. In an issue selection scan chain for the load unit, the store unit, or register unit X, a "scan" bit Cin input to the oldest entry logically propagates through the scan chain until a logic block in one of the entries kills the scan bit. An entry kills the scan bit if the entry is associated with an operation of the desired type (i.e. IssuableToxx is asseπed) To scan for an operation to be issued to register unit 254, a scan bit is logically generated by an entry associated with the operation to be issued to register unit 253, and that scan bit propagates until killed by an entry associated with an operation issuable to register unit 254 The entry which kills the scan bit asseπs a signal IssueOpToxx to identify itself as the entry associated with the operation to be issued to execution unit xx. The selected entry can thus take appropriate action as required for broadcast phase 431 If a scan bit for execution unit xx propagates through all of the entnes without being killed, no entry in scheduler 280 is associated with an operation that is issuable to unit xx, and no operation is selected for issue While a scan chain where a scan bit signal propagates seπally through every single entry in scheduler 280 is relatively simple, a faster implementation mav be necessary Look-ahead techniques analogous to those used in traditional Generate-Propagate-Kill cany chams can be applied One look¬ ahead technique combines entnes into groups, and each group generates, propagates, or kills a scan bit Look ahead is faster because group generate, propagate, and kill terms are determined in parallel from single-entry terms and whether a scan passes through a group can be determined without a signal propagating through every entry in the group By successive combination of group terms, no scan bit signal propagation actually occurs because the entire scheduler reservoir forms a single group For the LU, SU, and RUX scan chains, the smgle-entrv kill terms K are signals IssuableToXX The generate terms G are all zero, and the propagate terms P are the complement of the associated K terms Table B 28 indicates the single-entry terms for LU, SU, and RUX scan chams Table B 29 in Appendix B descπbes group terms Pgrp and Kgrp used in issue selection scan chains for pipelines LU, SU, and RUX Figs. 8A and 8B show logic 800 which implements a poπion of an RUX scan chain using look-ahead groups of six entnes Groups of more or fewer entnes can be used, but six entries per group panuions 24 entnes into four quadrants and reduces the number of wires used in processing the group terms As shown Fig 8A, each quadrant has associated NOR gates 810 and 812 and a NAND gate 814 which together act as a six-input OR gate and generate a group kill signal Kgrp3, Kgrp2, Kgrpl , or KgrpO for quadrant 3, 2, 1 , or 0 The inputs for NOR gates 810 and 812 are signals IssuableToRUX which are the single-entry kill terms for pipeline RUX Scan chains for the pipelines LU and SU are identical, except that respective signals IssuableToLU and IssuableToSU are input in place of IssuableToRUX. Issue selection scans are from the oldest to newest entnes according to the physical order of entnes in scheduler 280. Quadrant 3 contains the oldest entnes If signal Kgrp3 is asseπed, one of the operations in quadrant 3 would kill a scan bit and an operation from quadrant 3 should be issued A buffer 823 asseπs a delayed signal IssueQuadrant[3] to select quadrant 3. If signal Kgrp3 is not asseπed, a scan bit can propagate through group 3, but an operation in quadrant 2, 1, or 0 may be selected. NAND gate 822 asseπs signal IssueQuadrant[2] if signal Kgrp2 is assened and signal Kgrp3 is not. Similarly, NAND gates 821 and 820 asseπ signals IssueQuadrant[l] and IssueQuadrant[0] respectively if the scan bit could propagate to quadrant 1 or 0 and the group kill signal Kgrpl or KgrpO is asseπed (i.e. the group would kill the scan bit). If none of the group kill signals Kgrp[3:0] are asseπed, no operation is selected for issue. Fig. 8B shows logic 850 which selects an operation from quadrant 0 if signal IssueQuadrant[0] is asseπed. Four circuits similar to logic 850, one for each quadrant, operate in parallel. Since entry 5 is the oldest entry in quadrant 0, entry 5 is selected if it issuable to pipeline RUX and quadrant 0 is selected for issue. AND gate 865 asseπs signal IssueOpToRUX[5] to indicate entry 5 contains the selected operation, if IssueQuadrant[0] is asseπed and IssuableToRUX[5] is asseπed. AND gates 860 to 864 conespond to entries 0 to 4 and asseπ a respective bit in signal IssueOpToRUX[0:4] to identify the selected operation when that operation is issuable to RUX and no older operation in quadrant 0 is issuable to RUX. NOR gates 870 to 873 asseπ signals to respective NAND gates 860 to 863 to indicate none of the older entries are issuable to RUX. As an alternative to circuits 800 and 850, any logic which implements the equations of Table B.29 in Appendix B can be employed. Logic 800 of Fig. 8 A generates signal IssueQuadrant[3:0] after three gate delays from input of signal IssuableToRUX [23:0] even if the selected entry is in quadrant 0, the last quadrant searched. Logic 850 of Fig. 8B generates signal IssueOpToRUX after about two more gate delays. Without using look-ahead techniques, a scan bit must propagate through the entire scheduler when no operation is selected. This is about 24 or more gates delays for the exemplary embodiment. Accordingly, look¬ ahead scan chains are typically much faster than seπal scan chains when a scan bit propagates through every entry. III.A. l .b Issue Selection Scan Chain for RUY The RUY scan chain is more complex and uses four terms G. P, K. and O. The terms G, P, and K are analogous to the conventional generate, propagate, and kill terms. The O term ensures that only one operation is selected. Single-entry generate term G for entry i is signal IssuableToRUX[i], and the term O is equal to the term G. Single-entry kill term K for entry 1 is signal IssuableToRU Y[i], and the P terms are the complements of the associated K terms. Look-ahead techniques can also be employed in issue selection for pipeline RUY. Conceptually, for the RUY scan chain, a scan bit is generated by the entry containing an operation selected for issue to RUX and is killed by the next newer operation that is issuable to pipeline RUY. A group generates an output scan bit if an entry in the group generates the scan bit and no following entry in the group kills the scan. A group propagates a scan bit if each entry in the group propagates the scan bit. An O term once generated prevents newer entries from generating a new scan bit, and a group O term is generated if any entry in the group generates a single-entry O term. Equations in Table B.30 of Appendix B summarize the logic which generates group terms from single-entry terms in an RUY scan chain. Figs. 9A, 9B, and 9C illustrate an issue selection scan chain for pipeline RUY which initially partitions scheduler 280 into eight 3-entry groups. In Fig. 9A, logic blocks 910 implementing the logic shown in Table B.30 and generate group terms Ggrp[7: l], Pgrp[7:l], and Ogrp[7:l] from single- entry signals G[23:3] and 0[23:3]. Group terms for the newest group, entries 0 to 2, are not required for reasons described below. The group terms are combined in three stages to form terms for larger groups. Circuitry 900 generates group terms such as generate terms G_7, G 67, G 567, G 4567, G 34567, G 234567, and G_1234567 for groups which contain the oldest three, six, nine, twelve, fifteen, eighteen, and twenty one entries. The first stage of circuity 900, containing logic blocks 920, combines group terms from adjacent groups of three entries to generate group terms for groups of six entries. The second stage, containing logic blocks 930, combines group terms from adjacent groups of either six or three entries to generate group terms for a group of nine or twelve entnes. The third stage, containing logic blocks 940, combines group terms from adjacent groups of twelve, six, or three entnes to generate group terms for groups of twenty one, eighteen, and fifteen entries. Logic blocks 920, 930, and 940 combine group terms GX, PX, and OX for a group X with group terms GY, PY, and OY for the next newer group Y to generate terms GXY, PXY, and OXY for a group XY that is the concatenation of groups X and Y. In one embodiment of the invention, each of blocks 920, 930, and 940 implements following equations. GXY = GX-PY + -OX-GY PXY = PX-PY OXY = OX + OY The circuit shown in Fig. 9B shows an exemplary implementation of blocks 920, 930, and 940. In Fig. 9B. input signals are for groups I and 2 and output signals are for the union of group 1 and 2; but any desired consecutive groups can replace groups 1 and 2. Altematively, other equivalent logic may be employed or alternate stages, blocks 920 and 930 or blocks 930 and 940, can be implemented with inveπiπg logic. Additionally, as described below, propagate terms from the last stage, blocks 940, are not required, and block 940 can be simplified by not implementing the propagate equations (i.e. eliminating AND gate 922). The desired output signals from circuit 900 are G terms and O terms. Output signals G_7, G 67, G 567, G 4567, G 34567, G 234567, and G 1234567 indicate whether a prior generated scan bit reaches group 6, 5, 4, 3, 2, 1, and 0 respectively and are also refened to herein as signals CinGrp[6:0]. Signals 0_7, 0_67, 0_567, 0_4567, 0_34567, 0 234567, and O 234567 indicate whether a scan bit was generated prior to group 6, 5, 4, 3, 2, 1, and 0, respectively, regardless of whether the scan bit is killed before reaching the respective group. Signals 0 7, 0 67, 0 567, 0 4567, 0 34567, 0 234567, and 0 1234567 are also referred to herein as signals OinGrp[6:0]. A multi-bit signal IssueOpToRUY[23:0] can be generated from group signals CinGrp[6:0] and OinGrp[6:0] and single-entry signals P, K, G, and O. Fig. 9C shows logic which select entries for issue to the RUY execution unit. Logic which generates signals IssueOpToRUY[23:21] entries 23 to 21 , differs from logic for the other groups because there is no group propagation into group 7, the oldest group. Logic shown generating IssueOpToRUY[20: 18] for group 6 is repeated for each group 5 to 0. As in Table B.31 of Appendix B, group propagate terms from the final group 0 are not required for selection of an operation for issue. Ill .A.2 Operand Information Broadcast Phase During the broadcast phase of the issue stage of the processing pipelines, information about operands for operations to be issued to the execution units is broadcast to all scheduler entries and to extemal logic. This information describes two source operands for each operation selected for issue. The entry for the selected operations also transmits information about the selected operations to extemal logic and the associated execution unit. Operand information busses 552 (Fig. 5) mn through scheduler 280. The number of operand information busses 552 matches the maximum number of operands which may be required by the execution units. An entry associated with a selected operation dπves two operand information busses 552 which are associated with the execution unit to which the associated will issue. Each operand information bus 552 is eight bits wide and carnes a 5-bit register number SrclReg[4:0] or Src2Reg[4:0] and a 3-bit byte mark SrclBM[2:0] or Src2BM[2:0] for a source operand. Table B.31 describes the entry logic drives operand information busses 552. Companson logic within each entry compares broadcast operand information to similar information concerning a destination register for the operation in the entry making the compaπson. The compaπson logic checks for matching register numbers and for overlapping byte marks (i.e. some or al! of the bytes required for an operand are or will be modified by the operation). The results of multiple ("ff of operand information busses" * "ff of entries") compansons are signals that control actions occumng duπng the next processing phase, operand selection phase 441. Table B.32 descπbes logic which performs the compansons. The following equation summanzes a generic companson: OpmdMatch XXsrcY = (busReg[4:0] = = DestReg[4:0]) && (busBM[l] DestBM[l] + busBM[0] DestBM [0]) where "XXsrcY" is one of LUsrcl , LUsrc2, SUsrcl , SUsrc2, RUXsrcl , RUXsrc2, RUYsrcl , and RUYsrc2 and "bus" refers to signal Oprndlnfo XXsrcY which is on one of operand information busses 552. "Match" signals OpmdMatch XXsrcY that result from the comparisons are the product of the broadcast phase and are used in the operand selection. This is done concurrently within each and every entry, i.e. within each entry, eight match signals are piped to the entry's operand selection logic 532. All the match signals remain local to each entry and are latched into registers for use in the following pipeline stage. In essence, within each entry, eight operand information bus comparators feed eight "control" signals to eight chunks of operand selection logic 532. The match signals within each entry within the bottom row are gated or masked by additional signals associated with the committing of these operations' register results to the architectural register file 290. See the description of operation commit unit 260 below. Each entry does not actually control loading of match bits into operand match registers within the entry. Global logic 520 generates signal LUAdvO, SUAdvO, RUXAdvO, and RUYAdvO which indicate whether an issued operation will advance into operand forward stage 440, and match signals are only latched and used if an operation will actually advance into operand forward stage 440. Four operation information busses 551 conesponding to load unit 251 , store unit 252, register unit 253, and register unit 254 provide additional information describing an operation issued. The additional information, namely the Opinfo field, is read out of scheduler 280 during the broadcast phase and latched into extemal pipeline registers if the operation will actually advance to operand forward stage. Table B.33 describes logic which generates the operation information signals. The Srcl/2Reg and Srcl/2BM fields provided during broadcast phase are used for a number of purposes during the next two phases (i.e. during operand forward stage). The Opinfo fields are simply passed "down the pipe" to the conesponding execution units (via a second set of pipeline registers controlled by corresponding signal XXAdv l ). For RUX and RUY operations, the associated byte marks Srcl/2BM are also passed "down the pipe" to the conesponding register unit. III.B. Operand Forward Stage The operand forward stage consists of an operand selection phase and an operand transfer phase. III.B.1 Operand Selection Phase Each cycle, in the operand forward stage, scheduler 280 uses match bits, which were generated by issue stage logic 530 and stored in operand match registers, to select entries which supply values for operands being "fetched". Scheduler 280 also determines for each operand whether the operand's value comes from a scheduler entry or register file 290. Register file 290 is the default if there was no matching entry. During the operand transfer phase, the selected entries and/or register file 290 drive operand values onto operand busses 554 and thus transfer operand values to the associated execution units. As with the issue selection process in the issue stages, operand selections are independent and simultaneous. Thus, operand selection logic 532 contains eight scan chains for selecting entries to provide operands. Each entry has an operand match register bit for each operand bus and associated scan chain. Each scan chain searches for the newest entry with a match that is older than the entry contai ng the operation whose operand is being fetched. Logically, the scan starts (a scan bit is generated) from the entry containing the operation whose operand is being fetched and proceeds in the direction of older entnes to the first entry with an operand match bit set. If an entry having a set match bit is found, that entry supplies the required operand by driving of the associated operand bus 554 during the next phase. If no "matching" entry is found, a scan bit output from the scan chain causes register file 290 to supply the operand value. If an operation whose operands are being fetched does not advance out of operand forward suge, then the operand selection process is performed again in the next cycle. An operation will not advance if, for example, an entry with match bit set does not modify (and therefore cannot supply) all bytes required for the operand. Since field State and the physical location of operations with scheduling reservoir 540 can change each cycle, the outcome of the new selection may be different from the cunent cycle's outcome. In essence, during each cycle, the selection process determines what needs to be done to forward appropriate operand values duπng that cycle. The scan to find the appropnate source for an operand value can be performed in the same manner as the issue selection scans described above. However, the scan is in the direction of older operations which is opposite from the direction of the issue selection scans. Further, for operand selection, the scan chains are not "propagate-kill" chams Operand selection scan chain are analogous to a traditional carry or "generate-propagate-kill" cham. The initial scan bit Cm into the scan chain is zero, and the entry corresponding to the operation whose operand is being fetched generates the scan bit. A scan kill occurs at the first following entry with operand match bit set, and scan propagates occur at intervening entnes Global control logic 520 uses the final output scan bit Cout trom the last/oldest entry to determine whether any entry was selected and thus whether register file 290 should instead be selected to provide the operand. If Cout is asseπed, global control logic 520 selects register file 290. The selected source drives the conesponding operand bus duπng operand transfer phase which is the latter pan of the operand forward stage. Dunng the operand selection phase, the source register in register file 290 which nominally holds the desired operand value is read in case register file 290 is selected to dnve the operand bus. As with the issue selection scan chains, a look-ahead implementation improves speed. Table B.34 of Appendix B provides an example of an operand selection scan chain in terms of look-ahead equations similar to the traditional Generate-Propagate-Kill equations. III.B .2 Operand Transfer phase During operand transfer phase 442 of operand forward stage 440, values for each of the eight source operands are fetched and transmitted over operand busses 554 to input registers of the associated execution units. Operand values are 32-bit quantities, but some bytes may be undefined. During correct operation, an execution unit does not use undefined operand bytes. Any entry or register file 290 can drive each operand bus 554, and each entry of scheduling reservoir 540 can drive any and/or all of the busses. In the exemplary embodiment, 192 operand selection signals and 8 scan chain signals Cout are generated during the operand selection phase. Based on these signals, logic in each selected entry enables the appropriate bus drivers in the entry. If none of the entries is selected for an operand, register file 290 enables drivers for that operand. Table B.35 in Appendix B describes logic for enabling driver for operand busses 554. Operand registers in execution units 251 to 254 capture the operand values from operand busses 554 for use in subsequent pipeline stages. Global control logic 520 generates control signals, one per processing pipeline, to control the loading of the operand registers. New operand values are loaded into an execution unit if an operation in operand forward stage can advance into execution stage 450. Global signal LUAdvl controls the LU stage 1 source operand registers. Similarly, signals SUAdvl , RUXAdvl , and RUYAdvl respectively control the SU, RUX, and RUY loading of the operand registers. During operand transfer phase 442 of operand forward stage 440 of the four processing pipelines, information about each of the operations selected to provide an operand value is also read out of scheduler 280. Each operand bus 554 has an associated operand status bus 553 that carries an operand stams signal OpmdStat describing the "origin" of the operand being fetched. The operand status signal from an entry is a concatenation of fields State, DestBM, Type, and Execl of the entry providing the operand value. Extemal logic uses this information during the operand transfer phase to determine the source and availability of a valid operand value. Register file 290 also has a set of drivers for operand status busses 553 to ensure that operand status busses 553 carry defined values and that the values result in appropriate behavior by logic using the information. Table B.36 of Appendix B describes the operand status signal and its generation. Each source operand delivered to an execution unit comes from one of three possible sources: a scheduler entry, register file 290, or a result bus of this or another execution unit. Operand transfer phase 442 covers delivery from an entry. Register file 290 is accessed during the Operand Selection phase in parallel with scheduler activity. In paπicular, the register number for the desired operand is broadcast from the operations entry during the broadcast phase and passed to the appropriate read pon of register file 290. For each operand to be provided, scheduler 280 determines whether a scheduler entry or register file 290 drives the operand bus 554 which corresponds to the operand; and the resultant operand is transfened to the execution unit, during the operand transfer phase, via the operand bus 554. As shown in Fig. 10, operand busses 554 couple to operand input registers 1021 to 1024 and 1031 to 1034 in execution units 251 to 254 through multiplexers 1010. Result busses 561 to 564 from execution units 251 to 254 are also connected to multiplexers 1010. Thus, five "operand" busses run to each operand input of each execution unit, namely one of operand bus 554 dedicated to input that operand from scheduler 280 or register file 290 plus four result busses from execution units 251 to 254. During the operand transfer phase, scheduler 280 generates select signals for 5: 1 multiplexers 1010 at each operand input register. The operand stams signal indicates whether the desired operand value is or may be just becoming available from an execution unit; and if so, the appropriate result bus and value Result XX from an execution unit 251 to 254 is selected. Otherwise, operand bus 554 is selected. The validity of the operand is an independent issue that only affects whether the associated operation in operand forward stage 440 advances into execution stage 450 and thus actually enters an execution unit. III.B.3 Displacement Forwarding In addition to register operands, scheduler 280 fetches and forwards displacement operands to the LU and SU processing pipelines during operand transfer phase 442. Load unit 251 and store unit 252 each have three input operand busses (two register operand busses 554 and one displacement bus 555). Displacement operands are 32-bit quantities, but some bytes in a displacement operand may be undefined and therefore not used during conect operation of execution units 251 and 252. Scheduler 280 handles displacements in a manner similar to operation register result values. Displacements are initially stored within the 32-bit DestVal fields of entries until used and are driven onto displacement busses 555 as required during the operand transfer phase 442. Displacements are always immediate values for RISC86 operations, so that forwarding displacement values from register file 290 does not occur. Field DestVal is also used for result values from LdOps and some StOps, but the two uses of field DestVal do not conflict since a result value is not loaded into a scheduler entry until after the displacement is forwarded out of the entry, i.e. not until after operand forward stage 440. Small (8-bit) displacements, which are specified within operations, are handled differently from large (16/32-bit) displacements. Operation decoder 510 sign extends a small displacement before loading the small displacements into the DestVal field of the entry holding the associated LdStOp. Large displacements are presumed to be stored in the DestVal field of the entry for a LIMMOp immediately preceding the LdStOp using the displacement. Generally, the preceding entry holds a "LIMM t0,[disp]" operation which can be loaded into scheduler 280 in a completed state so that the LIMMOp is not issued or executed. The selection of DestVal fields to drive displacement busses 555 during each cycle does not require scanning of scheduler entries. Instead, each entry determines from its State and Type fields whether to enable its drivers or drivers in a preceding entry to asseπ a DestVal field value onto the appropriate displacement bus 555. Table B.37 in Appendix B summarizes logic for enabling the displacement bus drivers within each entry. III.B.4 Immediate Value Forwarding In the exemplary format of RISC86 operations, immediate values are operands src2 of RegOps. Scheduler 280 handles immediate values and displacements similarly. The RISC86 instmction set uses only small (8-bit) immediate values in RegOps, and operation decoder 510 stores the immediate values in field DestVal of the entry holding the RegOp. Thus, immediate values are like displacements tn that they are stored in the DestVal fields of entries, but are like register operands, in that they are forwarded over register operand busses 554 (specifically the RUXsrc2 and RUYsrc2 operand busses). Immediate values for Src2 operands are forwarded to respective register execution units duπng operand transfer phase 442 of operand forward stage 440 in place of a register value. The selection of a register value source (i.e. a scheduler entry or register file 290) is inhibited, and the entry in question directly dπves us DestVal field onto the appropriate operand bus 554 The inhibition of RUX/RUY src2 operand selection is performed during operand selection phase 441 by masking the single-entry generate term that an entry holding the RegOp would normally asseπ to in operand selection scan chain. This is done separately and independently for RUXsrc2 and RUYsrc2 and prevents selection of any entry by the RUX/Ysrc2 scan chain. Entnes containing immediate values also inhibit selection of register file 290 as the default operand source. The single entry terms for RUX and RUY operand selection scan chains descnbed in Table B.34 exhibit the inhibition. The selection of small "immediate" DestVal values to drive onto the RUXsrc2 and RUYsrc2 operand busses dunng each cycle does not require scanning of scheduler entnes. Instead, each entry enables the dnvers of s DestVal field onto the appropnate operand bus 554 simply based on the entry's State field and related b s. The same dnvers can be used for register operand value forwarding and immediate value operant forwarding Table B.38 in Appendix B descπbes circuitry for dnving immediate values on operand busses 554 When an entry dnves an immediate value onto an operand bus 554, the entry also drives the associated operand status bus 553. The same bus drivers and dnver input values as for register operands are used for immediate values but with an additional term as shown in Table B.38. III.C Data Operand Fetching StOps have three register source operands and no destination register. In contrast, other operations have to up to two source operands and one destination. The third source operand for a StOp provides the data to be stored and is sometimes refened to herein as a data operand. The data operand is not needed to staπ execution of a StOp but is needed for completion of the StOp. Fetching of data operands is performed in a manner similar to fetching of other source operands, but where the "normal" operand fetch process occurs during issue stage 430 and operand forward stage 440, the data operand fetch process occurs during SU execution stages 450 and 460. Scheduler 280 checks data operand availability during SU execution stage 460 and holds the associated StOp in stage 460 if the data operand is not available. The data operand fetch process is largely the same as issue and operand forward stages described above with two principal differences. First, operation selection phase 456 does not require a scan across scheduler entnes to choose between multiple candidates such as occurs during issue selection phase 431. Instead, the entry associated with the StOp at SU stage 450 identifies itself from State and Type fields and provides the data operand to store unit 252 when required. The second difference is that the Opinfo field of the StOp does not need to be read out (again) to store unit 252 during broadcast phase 457 for the data operand. Instead, store unit 252 retains and uses the Opinfo value from when the StOp was issued. The Opinfo value read out duπng the SU issue stage 430 is passed down through operand forward stage and the first and second execution stages of the SU pipeline. Table B.39 in Appendix B describe signals generated for data operand selection and forwarding. III.D Register Operation Bumping Scheduler 280 generally manages the execution pipelines based on in-order issue selection and processing for each type of operation. "Normally", operations issued to an execution unit progress down the pipeline in the order in which the operations were issued When an operation is held up in operand forward stage of the SU or LU pipeline, for example, the operation cunently being selected for issue to that pipe is also held up because operations do not pass by each other within a processing pipeline. However, when a RegOp is held up in operand forward stage of either register unit 253 or 254 due to one or more unavailable operand values, the RegOp may be bumped out of the processing pipe and back to the unissued state. Bumping sets the RegOp's State field back to bOOOO. When a RegOp is bumped out of operand forward stage 440. another RegOp selected for issue to that register unit advances to operand forward stage 440. immediately taking the place of the bumped RegOp. Simultaneously, the bumped RegOp is immediately eligible for reissue to a register unit, not necessanly the same register unit. Bumping is applicable to all RegOps, subject to the following constraints. First, an RUX -only RegOp (in RUX operand forward stage) is not bumped if an RUX-only RegOp is cunently being selected for issue to RUX because bumping would violate a restriction that RUX-only RegOps be executed in order with respect to each other. Secondly, a RegOp should only be bumped if the RegOp will be stalled for more than one cycle, otherwise leaving the RegOp in operand forward stage 440 more efficiently utilizes execution unit resources. Table B.12 describes circuitry which changes the State field of entries to implement RegOp bumping. Global control logic 520 generates global bump signals BumpRUX and BumpRUY which force asseπion of signals RUXAdvO and RUYAdvO, respectively so that the appropriate issued RegOps advance to operand forward stage 440. A descπption below of global control logic 520 further mdicates the conditions under which a RegOp is bumped. III.E Load/Store Ordenng Scheduler 280 supports maintaining the required ordenng between LdOps and StOps. In particular, load-store ordenng logic 534 supports checking memory dependency of loads and stores by indicating the relative ages of selected LdOps and StOps. If a LdOp or StOp possibly accesses the same address as an older StOp or LdOp which is not yet completed, holding operations in execution stage 460 of the LU and SU execution pipelines maintains proper load-store ordenng Load and store units 251 and 252 contain address comparators, and ordenng logic 534 in scheduler 280 provides on bus 556 information indicating the relative age of the LdStOps so that only the appropnate address compansons are considered when determining whether to hold LdOp or StOp in the second execution stage 460 The relative age determination process is similar to the issue selection/operand information broadcast process Duπng a first phase 463 of execution stage 460 for LdOp and StOp pipelines, ordenng logic 534 performs five "propagate-kill" scans across all scheduler entnes from oldest to newest. Two scans compare LdOps to the StOp in SU stage 460, and three scans compare StOps to the LdOp in LU stage 460. Dunng a second phase 464, the entry for the LdOp and/or StOp in execution stage 460 samples the results from the associated two or three scan chains and dnves on bus 556 global signals SC SU20LDER. SC SUIOLDER SC SU0OLDER, SC LU20LDER, and SC LUIOLDER which directly indicate the desired relative age information A LdOp in execution stage 460 or in stage 450 and performing the second half of a misaligned load requires three scan chains to determine the LdOp's age relative to three categones of StOps Each scan chain scans for oldest StOp in a category One scan chain detects a StOp in stage 460 or in stage 450 and performing the second half of a misaligned store Another scan chain detects a StOp in stage 450. and a third scan chain detects an oldest StOp not yet in stage 450 The state of the scan bit at any point in the scan chain reflects whether an older StOp of a given type has been found yet Thus, the entry for a LdOp can determine from the input scan bus the LdOp's age relative to any StOp in a given category If the input scan bit C is 1, the scan signal has not been "killed" yet, and no older StOp of the given category exists. Load-store ordenng logic 534 determines which, if any, signals from the address comparators are relevant. A StOp in stage 460 or in stage 450 and performing the second half of a misaligned store requires two scan chams to determine its age relative to two categones of LdOp One scan chain detects any LdOp in stage 460 or stage 450 and performing the second half of a misaligned load The second scan chain detects any LdOps not yet in stage 460. Based on the input scan b s Cm to the entry holding the StOp in question, ordenng logic 534 determines which signals from the address comparators are relevant. Each scan chain is a "propagate-kill" chain from oldest scheduler entry to newest. Table B.40 in Appendix B descnbes load-store ordenng III.F Aboπ Handling When an abort cycle occurs, scheduler 280 is flushed. All Op quads are invalidated by cleanng all Op quad fields OpQV, and fields of the entnes are also set to innocuous values. Fields in the entnes must be cleared because field OpQV only affects the control of Op Quad loading and shifting and other operations within scheduler 280 ignore field OpQV and assume that the entnes are valid. A logically invalid operation withm scheduler 280 is changed to a valid but innocuous operation. To do this, the State field of the operation is set to completed so that the operation will not be issued or executed. DestBM and StatMod fields are set to indicate that the operation does not modify any register bytes or status flags. In these circumstances, all other fields can have any values without causing any "harm". Such an operation is effectively a No-op operation A new Op quad may be loaded into scheduler 280 as soon as scheduler 280 is flushed The new Op quad is not associated with any of the outstanding Op quads that need to be flushed, instead, it is logically the first new Op quad "after" the aboπ. This would occur after an aboπed or mispredicted BRCOND. The first new Op quad after aboπ cycles are delayed due to exception conditions In effect, the following sequence of events occurs at the end of the aboπ cycle Note that the storage elements within scheduler 280 are fully synchronous with the system clock signal and don't change sute in response to inputs until the next cycle boundary First, changes in fields OpQV, State, DestBM, and StatMod occur as described above. Then all, some, or none of the Op quads shift down one position, and a new Op quad is loaded into the top scheduler entry For exception-related aborts. the new Op quad is also invalidated and whatever shifting that occurs is generally a don't care since all scheduler Op quads are being flushed For BRCOND-related aboπs. the new Op quad is valid or empty The Abort signal comes in two vaπeties, "early" and "late" The early version is called SC EAboπ, and the late vanety is called SC Aboπ The early aboπ signal is transmuted to sections of scheduler 280 which require immediate notification of an aboπ. The late vanety is the same as the early, but delayed by one cycle with a flip-flop and is more widely transmitted. IV. Global Control Logic In addition to logic associated with mdividual entnes, scheduler 280 contains logic which controls scheduler 280 globally. IV.A Scheduler Information Used bv Extemal Logic Extemal logic such as global control logic 520 and execution units 251 to 254 uses a vanety of information provided by scheduler 280 dunng the broadcast and the operand transfer phases of fetchmg operand values For most types of operands, the broadcast and operand transfer phases are dunng the issue and operand forward stages of the execution pipelines. Dunng the broadcast phase, information about the operation whose operands are being fetched is read out on the appropnate Opinfo bus 551; and the operation's two source register (Srcl and Src2) and byte mark (SrclBM and Src2BM) fields are read out onto the two associated Opmdlnfo busses 552. For the data operand of StOps, the broadcast phase and operand transfer phase are duπng SU stages 450 and 460 Information for the data operand for a StOp is dnven on an associated Opmdlnfo bus 552, but there is no associated Opinfo Store unit 252 retains operation information from when the StOp was issued Broadcast operand information is used dunng the next couple of phases Operation information is simply passed down the pipeline in the execution units In the case of register units 253 and 254, the two source byte mark SrclBM and Src2BM bus from the Opmdlnfo busses 552 are also passed down the pipeline Duπng the operand transfer phase, information about each of the operations that is the source of an operand value is read out onto OpmdStat bus 553 associated with each operand bus 554 The information descπbing the status of the sourcmg operation is directly used (and only used) during this phase. Table B 41 summanzes the information read out of scheduler 280 at various times IV B Global Control Functions The preceding descnbes the logic, storage elements, and busses compnsing the core of scheduler 280 Scheduler 280 also includes global control logic 520 that coordinates shifting in scheduler 280 and "feeding" of operations and operands to execution units 251 to 254 The following descnbes pieces of global control logic 520 for the four phases of the operand fetch process Dunng the issue selection phase, the only extemal concern is whether an operation was selected for issue to each processing pipeline. For each issue selection that did not find an eligible operation, no scheduler entry dnves the conesponding Opinfo and Opmdlnfo busses 551 and 552 The values on these busses and the following three phases for this processing pipeline are don't care The only requirement is that an operation valid bit (OpV) for operand forward stage 440 of an execution pipeline is zero to indicate operand forward stage 440 in this pipeline stage is empty Operand forward stage operation valid (OpV) bus indicated whether valid operations are issued to the execution units. The output scan bit Cout of each issue selection scan chain generates an OpV bit for operations in the issue stage. Table B 42 descnbes the operation valid or OpV bits. Global signals XXAdvO control loading of OpV bits mto pipeline registers to follow progress of the empty operation. Dunng aboπ cycles, all pipeline registers are unconditionally cleared to flush the execution units. The broadcast phase requires no significant global control logic other than to control the pipeline registers which latch information (namely the Opmdlnfo and Opinfo values) read from scheduler 280. During the operand selection phase, two extemal activities take place. First, the source register numbers (i.e. the SrcYReg fields of the latched Opmdlnfo values) read during the preceding phase are used to access register file 290. This is done in parallel with operand selection scans within scheduler 280. Up to nine source operands can be fetched each cycle. Accordingly, register file 290 has nine conesponding read poπs, each associated with one of operand busses 554. The register fields presented to these poπs are XXsrcY and SUsrcSt, where XX = {LU,SU,RUX,RUY} and Y= { 1 ,2}. A second extemal activity during the operand selection phase is determining, for each operand bus 554 and operand information bus 552, whether scheduler 280 or register file 290 will provide a value during the next phase. Each scheduler entry directly determines for itself whether it should drive the busses or not, so the only concern for global control logic 520 is whether register file 290 should be enabled. Enabling register file 290 is based on output scan bits Cout which indicate whether any entry was selected during the operand selection phase. If the final scan signal Cout of an operand selection scan chain indicates no entry was selected for the associated operand bus 554, global control logic enables register file 290 to drive the associated operand bus 554 and operand information bus 552. Equations describing signals on operand busses 554 are in Tables B.35 and B.36 of Appendix B. During the operand transfer phase, global control logic 520 controls: RegOp "bumping", all execution unit input multiplexers 1010 of the execution units, validity determination for each operand value being fetched, and generation of signals HoldXXO which factor into the generation of the global pipeline register control signals XXAdvO. One implementation of RegOp bumping is split between logic within each scheduler entry that changes the State field of the entry, and global control logic 520 which generates global bump signals BumpRUX and BumpRUY and forces asseπion of signals RUXAdv l and RUYAdv l . Generation of the BumpRUX/Y signals is based on the OpmdStat values that are read out of scheduler 280, duπng operand transfer phase, for each of the register unit source operands i i.e. OprndStat RUXsrcY and OpmdStat RUYsrcY where srcY = {src l . src2}). In paπicular. fields State and Type for each operand source are examined to determine whether the sourcmg operation is at least two cycles away from providing a valid operand value. If either sourcing operation is at least two cycles away from providing a valid operand value, the dependent RegOp is bumped out of operand forward stage. A RegOp is at least two cycles from providing an operand if the RegOp has not yet advanced, to operand forwarding stage. A LdOp is at least two cycles from providing an operand if the LdOp has not yet advanced to the first execution stage. Table B.43 summarizes generation of the signals BumpRUX/Y and include an additional timeout term to handle what could otherwise be deadlock situations. 3-bit counters associated with RUX and RUY operand forward stage's generate signals RUX/Ytimeout after an operation has been held in operand forward stage for more than a time out period. Taking RUX as example, whenever RUX operand forward stage is loaded (inespective of whether with a valid or invalid operation), the associated counter is reset to a staπ value. During all other cycles, the counter is decremented. If the counter reaches 000, then RUXtimeout is asserted to indicate that the operation has been held up too long. RUX/Ytimeout signals cause setting of conesponding operation valid signals OpV for operand forward stage of register units 253 and 254. For example, signal RUXtimeout immediately forces signal OpV RUX O equal to 0, which then causes assertion of pipeline control signal RUXAdvO to reload RUX operand forward stage. Signal OpV RUX O ensures that the RUX execution stage 450 does not see the bumped RegOp if signal RUXAdvl is also asseπed. A second global control function occurring dunng operand transfer phase 442 is generation of the control signals for each source operand input multiplexer 1010 coupled to execution units 251 to 254. As described above, each 5: 1 multiplexer 1010 selects an operand from an associated operand bus 554 or one of result busses 561 to 564 to load into an associated one of operand register 1021 to 1024 or 1031 to 1034. During operand transfer phase 442, control logic 520 uses operand status signals OpmdStat from busses 553 to generate control signals for each of multiplexers 1010 and select operands OpmdStat_SUsrcSt and OprndStat XXsrcY, where XX = {LU,SU,RUX,RUY} and Y = { 1,2}, to be loaded into the operand registers. In particular, global control logic 520 examines fields State and Type for each operand source to determine whether the sourcmg operation has completed execution and, if not completed, which execution unit is executing the sourcmg operation. The operand bus 554 is selected if the sources is register file 290, a completed operation, or an operation providing a src2 immediate value to itself. Otherwise, the result bus from the execution unit corresponding to the type of the sourcmg operation is selected. An operand from a result bus will not be valid unless the sourcmg operation is completing in that cycle. Table B.44 in Appendix B summanzes generation of select signals for each operand. A third global control function occumng duπng the operand transfer phase is determination of the validity of each of the nine operand values being presented to execution unu source operand registers. A signal is generated for each source operand to indicate whether the source operand value is valid. As with the control of the associated execution unit input multiplexers 1010, operand validity determination is based on fields State and Type of the OpmdStat values from busses 553. A sourcmg operation must either have completed execution or cunently be completing execution for an operand to be valid. In addition, the DestBM field of the OpmdStat value is compared with field SrclBM or Src2BM of the latched Opmdlnfo value for the operand being fetched. For the operand to be valid, the sourcing operation's byte marks must be a superset of the required byte marks SrclBM or Src2BM. A src2 immediate value is always valid. A signal OpmdInvld_XXsrcY is asserted to indicate operand srcY for execution unit XX is invalid. Table B.45 summanzes logic which generates signals OprndInvld_XXsrcY. A fourth global control function occurring during the operand transfer phase is generation of pipeline control signals which hold operation up in a pipeline stage when required operands for advancement are not valid. Signals SC HoldXXO hold operations operand forward stage 440 of execution unit XX if source operands are not available. StOps can advance out of operand forward stage 440 even if the data operand is not available, but signal SC_HoldSU2 holds the StOp in the second execution stage 460 if the data operand is then invalid, cc-dep RegOps are held up in operand forward stage 440 if required condition codes are invalid. Table B.46 summarizes logic which generates signals SC HoldXXO and SC_HoldSU2. V. Sutus Flags Stams flag logic 538 for both x86 architectural flags and micro-architectural flags involve three areas of functionality: fetching status flag operand values for cc-dep RegOps, fetching status flag values for resolution of BRCONDs, and synchronizing non-aboπable RegOps with preceding BRCONDs. Unlike operand selection logic 532 and LdOp-StOp ordenng logic 534, status flag handling logic 538 is not spread across all scheduler entnes. Status flag handling for related operations only occurs while operations that access status flags are withm ceπain rows in scheduler 280. Cc-dep RegOps must be in row 3 during the cycle when status operand fetching occurs (i.e. during RUX operand forward stage). BRCONDs and non-aboπable RegOps must be in row 4 duπng resolution by branch evaluation unit 257 and RUX operand forward stage, respectively. Accordingly, cc-dep and non-aboπable RegOps are held up in RUX operand forward stage until they shift down to rows 3 and 4 respectively, and shifting of the Op quads in rows 3 and 4 is inhibited until Cc-dep and non-aboπable RegOps in those rows can advance into RUX execution stage. BRCOND remain in row 4 until the stams flags required for evaluation are valid. Restπcting execution or evaluation of cc-dep RegOps, non-aboπable RegOps, and BRCOND to when the operations are in particular rows of scheduler 280 simplify status flag handling logic 538 For example, sutus flag handling logic 538 is only required in the bottom three scheduler rows and only the bottom two rows are used for determining appropnate status flag values. Additionally, the same status flag values can be shared by both a cc-dep RegOp in row 3 and a BRCOND in row 4 Synchronization between non-aboπable RegOps and BRCONDs is simplified because the position of BRCONDs when evaluated is fixed. A number of restrictions placed on positioning cc-dep RegOps, BRCOND, and non-aboπable RegOps relative to each other within Op quads fuπher simplifies logic. The restπctions generally translate into coding mles for emcode, but in some cases also constrain MacDec 242 decoding of multiple macroinstmctions in a cycle. The restrictions require that an Op quad contain: 1) No cc altering RegOps after a BRCOND; 2) No cc altering RegOps before a cc-dep RegOp; 3) No non-aboπable RegOps and a BRCOND together; 4) Only one cc-dep RegOp; 5) Only one BRCOND; an 6) Only one non-aboπable RegOp. With these rest net ions, status flags are which are conect for a cc-dep RegOp in row 3 are also correct for a BRCOND in row 4, and the same stams flag circuitry serves two purposes V.A Stams Flag Fetch Status flag handling logic 538 fetches four independent groups of status flags conesponding to the four bus of field StatMod Table B.47 in Appendix B identifies the four flag groups and their conespondence to field StatMod Whether each group is valid for an operation is independently determined depending on whether older operations which could modify the group have completed Passing status flag values directly from either register unit 253 or 254 to a cc-dep RegOp entenng register unit 253 is not suppoπed in the exemplary embodiment. Accordingly, status flags are valid the cycle following completion of a condition code alteπng RegOp This creates a minimum latency of one cycle between a RegOp which modifies a paπicular group of status flags and execution of a following cc-dep RegOp which uses the group. The statistical performance impact of this latency is minimal because cc-dep RegOps are relatively rare when decoding typical x86 code. Fuπher, any impact of the latency can be eliminated if mstmction decoder 240 orders RISC86 operations to avoid a cc-dep RegOp in an Op quad immediately following a RegOp that alters the condition codes required for the cc-dep RegOp Dunng each cycle, the effective set of status flag values at the boundary between scheduler rows 3 and 4 is computed The computed status flags include the committed status flag and all changes to the status flags caused by operations in rows 4 and 5 As noted above, only RegOps modify the status flags Since each RegOp can modify only one. two, three, or all four of the groups of sutus flags, status flag computation is performed independently for each of the four groups The result of the computation, for each group, is a set of flag values and state information from the newest RegOp with a StatMod bu corresponding to the group set. The State field for the RegOp indicates whether the RegOp has completed and provided valid flag values Status flag logic 538 generates eight status flag bus STATUS and four validity bus STATUSV associated with the four groups of status flags as shown in Table B 47 These 12 bus are passed via bus 557 to branch evaluation unit 257 which evaluates BRCONDs and logic in register unit 253 which handles cc-dep RegOps. Register unit 253 and branch evaluation unit 257 determine from validity bus STATUSV whether the required status flags are valid and if they are valid, uses status bits STATUS to execute the cc-dep RegOp (if any) in row 3 and evaluate the BRCOND (if any) in row 4. Global control logic 520 generates shift control signals based on whether the required stams flags are valid. A process similar to that for fetching register operand values fetches each stams flag group to obtain the appropnate flag values for the last operation in row 3 of scheduler 280. In the following the notation OpX refers to entry X in scheduler 280 where X=0 and X=23 respectively identify the newest and oldest operations in scheduler 280. Row 4, for example, contains Opl6, Opl7, Opl8, and Opl9. For each flag group, a propagate-kill-style scan from Opl6 to Op23 locates the first operation with StatMod bit for this flag group set, and that entry ' s completed state bit (i.e. S3) and the appropnate set of flag values are read out. The Stams V bit for this group is simply state bit S3 from the entry found. If no such operation is found, the desired flag values are read from the architectural status flags register and signal STATUSV is set to indicate the group is valid Table B 48 descnbes the stams flag fetch logic for each flag group V B Status Forwarding to cc-Dep RegOps Dunng each cycle, global control logic 520 examines the four operations within row 3 to determine whether any of them is a cc-dep RegOp. If one is, then that RegOp is decoded to determine which groups of status flags are needed, and the StatusV bus are checked to determine whether all of those groups are valid Concunently, Status[7 0] is blindly passed to the RUX execution unit If any of the required flag groups are not cunently valid, the cc-dep RegOp is held up from advancing into the RUX execution stage and shifting of the Op quad out of rows 3 is inhibited If all of the required flag groups are cunently valid, the cc-dep RegOp is allowed to advance into the RUX execution stage at least insofar as the status operand fetch is concemed The cc-dep RegOp may still be prevented from advancing because an operand is not available If the cc-dep RegOp does not advance into execution stage 460, shifting of row 3 is inhibited If there is no unexecuted cc-dep RegOp in rows 3 to 5, but there is a cc-dep RegOp in RUX operand forward stage, then the RegOp is unconditionally held up in operand forward stage If a cc-dep RegOp in row 3 has not yet executed, but there is no cc-dep RegOp in RUX operand forward stage, shifting of rows 3 is inhibited Table B 49 descπbes logic which controls shifting and operation advancement. V Branch Prediction Resolution Duπng each cycle, if a BRCOND is found in row 4, the condition code (cc) field of that BRCOND is decoded to determine a predicted condition value The predicted condition value is compared to a selected one of 32 condition values denved from status flags from sutus flag handling logic 538 if associated validity bus indicates the selected condition is valid If the selected condition is not yet valid, shifting of the Op quad in row 4 is inhibited and evaluation of the BRCOND is attempted again in the next clock cycle If the selected condition is valid, a compaπson of the predicted condition and the selected condition indicates whether the prediction was conect. If a BRCOND is found to be mispredicted (and thus a pipeline restart is required), the restart signal is asserted based on whether the BRCOND is from MacDec 242 or is an emcode operation from internal or extemal emcode. In addition, an appropnate x86 macroinstmction or emcode vector address and an associated retum address stack TOS value are generated and returned to instmction decoder 240 to restart decoding For the benefit of the logic handling synchronization between non-abortable RegOps and preceding BRCONDs (described in the next section), a record is maintained of a mispredicted BRCOND while it remains outstanding (i.e. until an abort cycle occurs). Further, an outstanding mispredicted BRCOND holds up loading of "new" Op quads until the abort cycle occurs. If a BRCOND was conectly predicted, the only action taken is to set the BRCOND's State bit S3 to indicate the BRCOND is completed. Table B.50 describes logic which handles BRCOND evaluation. VI. Synchronization of Non- Abortable Operations During each cycle, if a non-abortable RegOp is found in row 4, then scheduler 280 checks for any preceding mispredicted BRCONDs. Due to emcode coding constraints, any preceding BRCONDs must be in a lower row and thus must have all been resolved. Further, any BRCOND cunently being resolved (in row 4) is after the non-abortable RegOp and thus is inelevant. If there is no mispredicted BRCOND, the non-abortable RegOp is allowed to advance into RUX execution stage, although the RegOp does not advance if required operands are not yet available. If the RegOp does not immediately advance into RUX execution stage, the RegOp is still allowed to shifted out of row 4. If rows 4 or 5 contain no unexecuted non-abortable RegOp but there is a non-abortable RegOp in RUX operand forward stage, the non-abortable RegOp is unconditionally held up in operand forward stage until the non-abortable Reg-Op reaches row 4. If a non-abortable RegOp in row 4 has not yet executed, but no non-abortable RegOp is in RUX operand forward stage or an unexecuted non-abortable RegOp is in row 5. shifting of rows 4 and 5 is inhibited. Table B.51 describes logic for handling non-abortable RegOps. VII. Self-Modifying Code Handling Store queue 270 provides several bits of the linear and physical addresses for data to be committed. If the store addresses match any instmction address for an Op quad, a write to an instmction may have modified an instmction and an operation now present (decoded) in scheduler 280 may be incorrect. The inconect operation must be conected before results from the operation are committed. In the exemplary embodiment of the invention, self-modifying code support logic 536 compares address bits from store queue 270 to the instmction address (or addresses, if the instmctions in an Op quad are from different pages) of each Op quad. If a comparison eliminates the possibility of code modification, logic 536 does nothing. If the possibility is not eliminated, logic 536 flushes scheduler 280 and restarts the fetch/decode process from the address of the last committed instmction. Logically, in scheduler 280, detection of self-modifying code is treated as a kind of trap and factors into a signal indicating a "trap pending". Table B.52 descnbes an example portion of self-modifymg code handling logic 536. VIII. Operation Commit Unit OCU (Operation Commit Unit) 260 generally operates on the operations within the last or second to last row (row 4 or 5) of scheduler 280 The pnncipal function of OCU 260 is to commit (or make permanent) the results of operations and then retire Op quads from scheduler 280 OCU 260 also initiates abort cycles Many types of results or state changes can stem from execution of an operation. The pπncipal types of changes are abortable and encompass' register changes; stams flag changes, and memory wntes In the RISC86 instmction set, register changes result from all RegOps, LdOps, LIMMOps, LDK operations, and STUPD StOps. Stams flag changes result from ".cc" RegOps, and memory wntes result from STxx StOps Scheduler 280 and store queue 270 suppoπ aboπable state changes by temporanly storing register and status results in entries of scheduler 280 and memory wnte data in entnes of store queue 270. until the associated operations are committed and retired Operation commitment makes state changes permanent While new state values reside in scheduler 280 and store queue 270, the state values are forwarded to dependent operations as necessary All other state changes are noπ-aboπable and result from non-aboπable RegOp execution The non-aboπable state changes include changes to standard x86 registers such as segment registers and non-status EFlags bus and changes to micro-architectural registers for execution of RISC operations. Non-aboπable state changes can occur immediately dunng non-abortable RegOp execution, and decoder 240 and scheduler 280 are responsible for ensunng sufficient synchronization of the non- abortable operations with the sunounding operations VIII A Commitment Dunng each cycle, OCU 260 examines operations within rows 4 and/or 5 of scheduler 280 and tπes to commit the results of as many of the operations as possible The state changes in an Op quad may be committed in one cycle or over many cycles. If all of the operations of an Op quad in the bottom row have been commuted or are being successfully comm ted, the Op quad is retired from scheduler 280 at the end of the current cycle by allowing an Op quad from row 4 to shift into and overwπte row 5. Otherwise, as many changes as possible are committed and shifting into row 5 is inhibited. The commitment process is repeated each cycle until all operations in row 5 have been committed and the Op quad from row 4 is allowed to shift down to row 5 Commitments of register results, stams results, and memory wntes are performed independently. For operations which have multiple results (e.g. a RegOp with register and status results, or a STUPD operation with a register result and a memory wnte), the vanous results are not necessaniy committed simultaneously. The commitment of one type of state change can generally be ahead or behind the commitment of another type of state change. The overall commitment of an operation occurs when OCU 260 commits the last result from the operation. An operation's results are not committed until: the operation's execution state indicates the operation is completed; any preceding faultable operations, namely any preceding LdStOps, are completed, which implies that the operations are fault-free; and any preceding BRCONDs are completed, which implies that the BRCONDs were conectly predicted. FAULT operations are not a concern since decoder 240 places each FAULT operation as the first "valid" operation in an Op quad so that no operations in the same row as a FAULT operation need to be completed. For StOps which generated a memory write, an additional constraint is that only one write can be committed per cycle from store queue 270 into data cache 220. OCU 260 can commit up to four register and four status results and one memory write per cycle and typically commits and retires an Op quad from scheduler 280 every cycle. An Op quad remains in the bottom row of scheduler 280 and unretired for more than one cycle only if the Op quad contains multiple memory write StOps or if some of the operations in the Op quad have not yet completed. If an operation in the bottom row needs to be faulted, for example, if the operation is a FAULT operation or a fault occuned during execution of the operation, commitment of the following operations is inhibited. Once all older operations within the Op quad being faulted have been committed or are being successfully committed, OCU 260 retires the Op quad and initiates an aboπ cycle. The aboπ cycle flushes scheduler 280 and all execution units of all outstanding operations. Concurrent with the aboπ cycle, OCU 260 also vectors instmction decoder 240 to one of two possible emcode "entry point" addresses, either the "default" fault handler address (as initialized by reset emcode), or an "alternate" handler address (as specified by a macroinstmction or exception processing emcode). LDDHA and LDAHA operations, which are loaded into scheduler 280 in a completed state and are recognized and "executed" by OCU 260 when they reach the bottom of scheduler 280, suppoπ setting of the fault default and alternate handler addresses. Only ceπain types of operations can be faulted, namely LdOps, StOps (except for LEA operations), and FAULT operations. For a LdOp or StOp, faults are identified by the second execution stage 460 of the LU or SU execution pipeline; and if a fault is detected, the LdStOp is held up in the second execution stage until the associated or an unrelated abon cycle flushes the LdStOp from scheduler 280 and execution unit 251 or 252. This results in completed LdStOps being guaranteed fault-free. OCU 260 differentiates between a faulting LdStOp and a LdStOp that has not yet completed, by signals from execution units 251 and 252 indicating a faulting operation is stuck in their respective second execution stage. When OCU 260 tries to commit the next uncompleted LdStOp and the associated execution unit 251 or 252 signals a fault for an operation held in the second execution stage, the operation that OCU 260 is trying to commit must be the operation that has encountered a fault. If the associated execution unit 251 or 252 does not assen a fault signal, then nothing definite can be determined about an uncompleted LdStOp; and OCU 260 waits for the LdStOp to complete. FAULT operations are loaded into scheduler 280 in a completed state and always fault. OCU 260 handles commitment of FAULT operations and the resulting aboπion of sunounding operations in the same manner as LdStOps which fault. In addition to faults on specific operations, OCU 260 also recognizes vanous debug trap exceptions which are accumulated and remembered up until the end of an emcode sequence as indicated by an ERET. If an "ERET" Op quad is retired and trap exceptions are pending, OCU 260 initiates a fault-style aboπ cycle as if a fault was recogmzed on a fifth and last operation within the Op quad. OCU 260 recognizes a "branch target limit violation" condition which, while associated with just ceπain operations within an Op quad, is tagged with the Op quad as a whole. This unconditionally initiates an aboπ cycle as if a fault was recognized on the first operation within the Op quad. While OCU 260 is pπmanly concemed with operations that generate abortable state changes, OCU 260 also handles BRCONDs. BRCONDs are resolved when in row 4. If a misprediction is detected, logic for fetching macroinstmctions and instmction decoder 240 are immediately reset and restarted from the proper macroinstmction address. When the mispredicted BRCOND reaches row 5, commitment of operations newer than the mispredicted BRCOND is inhibited, and an aboπ cycle is initiated after all operations preceding the mispredicted BRCOND have been committed or are being successfully committed. The aboπ cycle flushes scheduler 280 and all execution units of all operations. The aboπ cycle also enables loading "new" operations from decoder 240 into scheduler 280 for immediate issue to execution units 251 to 256. Mispredicted BRCONDs and operation fault aborts differ in that no vectoπng to emcode is initiated for mispredicted BRCONDs. No action is necessary to commit a conectly predicted BRCOND that reaches the bottom of scheduler 280. OCU 260 either commits or aboπs each BRCOND. OCU 260 chooses the action based on the BRCOND's scheduler entry State field. When a BRCOND is resolved, its scheduler entry State field is either changed to completed if conectly predicted, or is left unissued if mispredicted. Thus, whether a BRCOND is completed in row 4 directly indicates whether the BRCOND was mispredicted. The actual timing of operation result commitments is relatively simple and can be viewed as happening during the latter part of the commit cycle. Typically, an Op quad is committed during the same cycle that it falls into the bottom of scheduler 280, and is retired from scheduler 280 at the end of the cycle. During this cycle, while results are being wπtten to register file 290, operand values continue to be forwarded to all dependent operations from scheduler 280, not from register file 290. Committing memory writes is a two stage process implemented in the form of a two stage write commit pipeline. The first stage of the write commit pipeline conesponds to OCU 260's commit cycle for a StOp and, as far as OCU 260 is concemed, the StOp has been committed when it enters the second stage of this pipeline. Timing- wise the StOp must enter the second write commit stage before or concurrent with retirement of the associated Op quad from scheduler 280. If a StOp cannot enter this second stage, the StOp is viewed as not yet being committable and retirement of the Op quad is held up. When OCU 260 initiates an aboπ cycle due to an operation fault, an abon signal and an associated emcode vector address are asseπed dunng the commit/retire cycle of the Op quad containing the faulting operation Dunng the next cycle, scheduler 280 will have been flushed, and the target emcode Op quad is being fetched For internal emcode, scheduler 280 will be empty for exactly this one cycle. The Aboπ signal for a mispredicted BRCOND is also asseπed dunng the commit/retire cycle of the associated Op quad. Since mstmction fetch and decode was restaned earlier, scheduler 280 can be reloaded with a new Op quad as early as the very next cycle, I e scheduler 280 does not sit empty for even one cycle. When OCU 260 recognizes multiple operations within an Op quad as requinng an aboπ cycle, it chooses the first such operation and initiates appropnate aboπ actions with respect to that operation at the appropnate time for that operation VIII A 1 Register Commitment OCU 260 manages and controls committing of register result values to register file 290 Dunng each cycle, the register result of each completed operation within one of the bottom two rows of scheduler 280 can be wntten into register file 290 (dunng the latter pan of the cycle, via four independent wnte poπs). Each wnte is performed according to byte marks, field DestBM[2 0], from the associated scheduler entry This process applies to the x86 architectural registers and the temporary/micro-architectural registers If an operation is not yet completed and committable, the associated register file wnte is inhibited for this cycle If an operation is of a type which conceptually does not generate a register result, then the byte marks are all clear and the register number is possibly undefined This results in no bytes being modified duπng the register file wnte Similarly, if register tO (an always zero register) is specified as the destination for an operation, the byte marks are again all cleared In both of these cases, operation decoder 210 forced the byte marks to bOOO dunng loading In general, the possibility of contention exists, i.e. of multiple simultaneous wntes to the same register. The desired result is from the newest operation, and the other, older wntes are inhibited and effectively ignored. Register file 290 handles this function separate from OCU 260's control of the register commitment process based simply on the presented register numbers and associated wnte enables. Further, if the contending wntes are such that the older wntes modify register bytes which are not modified by the newest wnte, then the effective register file wnte is a combination of bytes from the contending operations. For example, if a first (oldest) operation modifies bytes {3,2,1,0}, a second operation modifies bytes {1,0}, and a third (newest) operation modifies byte {1}, the acmal register file wnte takes bytes {3,2} from the first operation, byte {0} from the second operation, and byte {1} from the third operation. In other cases, some of the register file bytes are not modified at all Control logic in register file 290 handles this further functionality. In essence, contention resolution logic mside register file 290 operates on the basis of individual bytes instead of 32-bit words. The wnte enables for all four operations are generated in parallel. An associated wnte enable is asseπed to register file 290 for each completed operation if all preceding/older LdStOps within the Op quad are completed and no preceding/older BRCOND is mispredicted. When results of an operation are wπtten to register file 290, the associated DestBM bus are cleared to indicate that the scheduler entry no longer provides a register value to dependent operations Clearing of the DestBM field is also done for partial register wntes. If a dependent operation cannot obtain all required bytes from one operation, the dependent operation is held up in an operand forward stage until it can obtain all of the bytes from register file 290. In addition, nine signals OpmdMatch XXsrcY associated with a scheduler entry (see descnption above) are masked (i.e. forced to indicate no match) when the DestBM bus withm that entry are about to be cleared. This is due to the pipelined nature of the register operand fetch process with scheduler 280. Specifically, the DestBM bus of an entry are used in both stages of this process and must be consistent across both cycles. To increase register commitment throughput, operation register wntes may take place from row 4 when register commitment for all operations in row 5 have completed This is accomplished by generalizing the RegOp wnte enable logic to consider either the four operations row 5 or four operations in row 4. The operations of the selected row are renamed "OpA" through "OpD" in place of p23 through Op20 or Opl9 through Opl6. Table B.53 descπbes logic which selects results for commitment to register file 290. VIII.A.2 Stams Flag Commitment OCU 260 also manages and controls the commitment to the architectural EFlags register of status flag results generated by ".cc" RegOps. Unlike the commitment of register results, none of the (up to four) stams flag results of operations from row 5 are wπtten into EFlags until the Op quad in row 5 is about to be either retired or aborted. In the normal case, when all operations within the Op quad have been fully committed or are being successfully committed, the cumulative or overall result of all four status results is written into EFlags at the end of the cycle when the Op quad is retired from scheduler 280. For an Op quad containing a faulting operation or a mispredicted BRCOND, only the stams results from the operations before the faulting instmction or BRCOND are committed and the cumulative result is written during or at the end of the abon cycle. This process applies to the micro-architectural sutus flags (EZF and ECF) as well as to the x86 architecmrai sums flags. In essence, the architecmrai EFlags register is extended to 34 bits to make room for the extra two sutus flags. The RDFLG and WRFLG RegOps only reference the standard 32-bit portion of this extended EFlags register Generation of the cumulative status result is based on the status bit marks (StatMod[3 0]) from each of the four entnes with the bottom row The eight status flags are divided into four groups for modification marking purposes instead of having eight individual bu marks As with updates to a general register withm the register file, the possibility of contention exists, I e of multiple modifications to the same group of status flags The desired result is the newest modification values for each group of sutus flags The generation of the cumulative stams result is also based on the completed status (State[3]) of each of the four operations For an Op quad being aboπed, field State identifies which status results should be committed and which should not be committed For commitment, all preceding operations must be completed and thus free of fault and misprediction Table B 54 summanzes logic which accumulates the status flag changes No explicit control or constraint on operation commitment and retirement is required insofar as status flag results are concemed Since status flag state changes only result from RegOps and since all RegOps generate register state changes (even if just to tO), an Op quad cannot be retired until all RegOps within the Op quad are completed and thus have valid status result values There is also no need, given how status flag values are forwarded (to BRCONDs and "cc-dependent" RegOps), for any cleanng of StatMod fields for the operations of the bottom row VIII. A 3 Memorv Wnte Commitment A third function of OCU 260 is controlling the commitment of memory wnte data values to "memory' (the data cache and/or to mam memory) This differs from the commitment of register and status results in a number of ways memory wnte commitment involves an associated store queue entry (in most cases), at most one memory wnte can be committed per cycle, the commitment process has a two stage commit pipeline OCU 260 scans the bottom two rows to find StOps for memory wntes to commit The possibility of faults on the associated StOps exists Memory wntes are all associated with StOps (except for LEA, CIA, and CDA operations, which don't actually reference memory) When a StOp completes execution, the associated memory address and store data is entered into store queue 270 Later, when the memory wnte of a StOp is committed, this entry is read out to cache memory and retired from store queue 270 StOps are executed and committed in order relative to each other which allows store queue 270 to operate as a simple FIFO, and matching of store queue entnes with associated scheduler StOps is automatic. The actual commitment process, though, is more complicated and descnbed below Generally, a two stage process is required in which the last/oldest store queue entry is first read and the address looked up in data cache 220, then, based on the status of the lookup, the store data is written into dau cache 220 and/or out to memory. In the latter case, the data and address is typically simply loaded into the Write Buffer and, later, written out to memory. In the two stage write commit pipeline, the first stage (i.e. the data cache tag lookup) conesponds to the commit cycle of register and stams results, i.e. the containing Op quad could be retired at the end of this stage's cycle. From OCU 260's perspective, the commit process is largely viewed as a single cycle/single stage action that either succeeds or is delayed. The commitment of a memory write can be held up for similar reasons as for a register state change, and also held up if the write commit is not able to enter stage 2 of the commit pipe When a write enters commit stage 2, the associated StOp can be retired from scheduler 280, and the remainder of the commit process is asynchronous to OCU 260 and scheduler 280. During the first commit stage, no control decisions are made The data cache tag lookup is performed, and the accessed tag data is simply latched for examination duπng the second commit stage. The wnte commit pipeline is only a single pipeline and thus only suppoπs commitment of one memory wnte per cycle. For Op quads containing at most one memory-wπting StOp, this allows the possible commitment and retirement of an Op quad each cycle (subject to the same son of caveats as stem from the commitment of register state changes). For Op quads containing two, three, or four StOps, a conesponding minimum number of cycles is required to commit the Op quad which causes the Op quad to remain at the bottom of scheduler 280 for at least that many cycles. Committing a memory write associated with a StOp in row 4 or row 5 reduces hold-ups caused by multiple StOps in an Op quad. Given that memory wntes are committed in order. OCU 260 can get a "head staπ" on multiple wnte Op quads when the bottom Op quad is held up but otherwise empty of uncommitted memory wntes or the bottom Op quad simply does not contain any SiOps This helps to better match the OCU's one wnte per cycle commitment capability to the average number of wntes per Op quad which is less than one per Op quad. Dunng each cycle, the OCU's memory wnte commit logic searches the bottom two rows for the oldest uncommitted memory-wπting StOp (i.e. for the next StOp and associated write to try to commit). The selected operation generated the cunent bottom/oldest store queue entry. Concunently with operation selection, the address of the oldest store queue entry is presented to the Data cache and a ug lookup initiated. Note that this is done "blindly", i.e. without consideration of whether the associated StOp is in fact presently committable. If the selected StOp is committable and the write commit is able to advance into the second write commit stage, OCU 260 considers the StOp to be committed. In the next cycle, OCU 260 searches for the next memory-writing StOp. The criterion for StOp commitment are the same as for register result commitment: the selected StOp must be completed, all preceding/older LdStOps within the Op quad (and possibly the preceding Op quad if this StOp is in the last row) must also be completed, and there must not be a preceding/older mispredicted BRCOND. A write commit is able to advance into commit stage 2 when that stage is either empty or is successfully completing commitment of a write. If the selected StOp is not committable only because it is not completed, OCU 260 examines the signal from the second SU execution stage which mdicates whether a StOp is "stuck" in that stage with a detected fault condition. If there is any such operation, it is the same StOp that OCU 260 is trying (unsuccessfully) to commit, and thus must be aboπed by OCU 260. An appropnate abort cycle is not initiated until the StOp is in the bottom row, all preceding operations within the Op quad have been committed, and no preceding BRCOND was mispredicted. This is essentially an extension of the condition for StOp being committable. In the mean time, OCU 260 remains in this state until an abort cycle is initiated for a preceding operation. OCU 260 is pnmarily concemed with memory-writing StOps but also handles CIA and CDA operations because these operations generate faultable memory addresses which OCU 260 must examine and commit. In the normal case of such an operation executing fault-free, OCU 260 trivially spends a cycle on commuting the operation and simply moves on to commuting the next StOp in the next cycle. Since no store queue entry was created dunng execution of the operation, no entry is retired from the store queue. If a fault was detected dunng execution of the CIA or CDA operation, the operation is "stuck" in the second SU execution stage, and OCU 260 aboπs in exactly the same fashion as for other StOps. A second special situation for OCU 260 anses when a StOp's memory reference crosses an alignment boundary (cunently 8 bytes) and is split by store unit 252 into two memory wntes having two associated store queue entnes In such situations. OCU 260 take two cycles to retire the two store queue entnes and does not officially commit the StOp until the second cycle. If the StOp has a fault, it is aborted without retirement of any store queue entnes. The exemplary embodiment of OCU 260 uses a set of mask bus (CmtMask[7:0]) which represent the OCU's progress in commuting memory-wπting StOps within the last two rows. Each of the eight mask bits CmtMask[7:0] conesponds to the eight entnes in the last two rows. A first set of b s (staπing from bit 0) are clear to indicate that OCU 260 has searched the conesponding entries and committed any StOps up to the entry conesponding to the last clear bit. The entry conesponding to the last clear bit contains the next StOp to be committed. Entries conesponding to the set mask bits have yet to be examined for committable StOps. OCU 260 also maintains a set of bits (UncmtStOp[7:0]) indicating which entnes in the last two rows contain uncommitted memory-writing StOps. During each cycle, OCU 260 selects the next uncommitted StOp and generates a new set of mask bits based on the entry containing this StOp. The unmasked entries are examined to determine whether the selected StOp is presently commituble or an abort cycle needs to be initiated. If the selected StOp is committable and if suge 2 of the commit pipeline is able to accept a new wnte commit at the end of the cycle, the StOp is committed and the UncmtStOp bus are updated with new values. The UncmtStOp bits are also updated/shifted to match any shifting of the last two rows. Table B.55 in Appendix B describes this logic. VIII.B Op Quad Retirement When all aboπable state changes of the operations within the bottom row of scheduler 280 have been committed or are being successfully committed, OCU 260 retires the Op quad from scheduler 280 at the end of the cycle. This allows the next Op quad to shift into the bottom row of scheduler 280. During cycles in which not all such operation results have been committed, the Op quad is not retired and is either retained for fuπher commitment processing or invalidated due to an aboπ cycle. If invalidated, the aboπ cycle would be in response to some fault having been recognized on one of the operations within row 5. More specifically, the retirement of an Op quad requires that all register results, stams results, and memory writes are committed, and that there is no FAULT operation or mispredicted BRCOND in the Op quad. Retirement of an Op quad also occurs immediately if the Op quad is marked as invalid. The scheduler's shift control logic automatically takes care of this. Status results are all committed together in conjunction with retirement (or aboπion) of the Op quad. Register results are committed or cunently committing if the associated operations are completed. Table B.56 summarizes circuitry in OCU 260 for retirement of Op quads. VIII.C Fault Handling VIIl.C. l Load Operation Fault Handling LdOps normally do not require any special handling by OCU 260 since LdOps only result in general register state changes. Like most StOps, though. LdOps can also encounter faults during execution. Special logic in OCU 260 recognizes and handles LdOp faults in the same manner as StOp faults. To determine whether a faulting LdOp exists in bottom row of scheduler 280, OCU 260 searches row 5 for an operation which is a LdOp with all preceding/older operations completed and committed and no preceding mispredicted BRCOND. OCU 260 also examines a signal from load unit 251 indicating whether a LdOp with a detected fault condition is "stuck" in the second execution stage of the LU pipeline. If a LdOp in row 5 is uncompleted and preceded only by completed and committed operations and the signal from LU stage 2 is asserted, OCU 260 recognizes a faulting LdOp and initiates an appropriate abort cycle immediately to abort the LdOp and all following operations. Table B.57 summarizes the OCU's LdOp fault handling logic. VIII.C.2 FAULT and LDDHA/LDAHA Operation Handling A few special operations, FAULT, LDDHA, and LDAHA operations, require additional, special commitment handling. None of these operations are issued to or executed by an execution unit. The FAULT, LDDHA, and LDAHA operations have no execution dependencies with other operations and are significant only to OCU 260. OCU 260 handles the FAULT operation much like a faulting LdStOp. An abort cycle is initiated along with vectoring to the cunent emcode OCU fault handler. Unlike faulting LdStOps, there is no issue of whether there is a fault to recognize and of when to initiate the abort cycle. To simplify the OCU's logic for handling FAULT operations, the following constraints are placed upon decoders 240 and 510: 1) FAULT operations must be in the first operation position of an Op quad, 2) all following operations in the Op quad must be "NO-OPs" (e.g. LDK tO.xx), and 3) the following Op quad must not contain any memory-writing StOps. Prohibiting memory-writing StOps from the next Op quad ensures that all other OCU commitment logic can operate blindly on "FAULT" Op quads without any special consideration. The State of a FAULT operation is initialized to 'bOOOO when loaded into scheduler 280. When the FAULT operation reaches row 5, the uncompleted state of the Fault operation inhibits the OCU's Op quad retirement logic from retiring the Op quad, and FAULT operation commit logic in OCU 260 immediately initiates an abort cycle. The specifics of the abort cycle are the same as for faults on LdStOps. The only difference is the generation of a unique fault ID. Table B.58 describes logic which generates an aboπ signal for a FAULT operation. The LDDHA/LDAHA operations enable emcode to set and change the address in emcode ROM 246 to which OCU-recognized exceptions are vectored. OCU 260 maintains two vector address registers, one to hold a "default" handler address and another to hold an "alternate" handler address. The first vector address register is active for most emcode (both macroinstmction and exception processing emcode) by default and is set just once by the reset emcode via an LDDHA operation. (Processor 200 executes reset emcode for initialization after a reset.) The second vector address register is set via an LDAHA operation. For emcode sequences from vector decoder 244 (defined to be from an entry point through to an ERET) which do not contain an LDAHA operation, any faults recognized by OCU 260 on operations within the sequence result in vectoring to the address in the default handler address register. For emcode sequences which contain an LDAHA operation, faults on operations in Op quads before the one containing the LDAHA operation result in vectoring to the default address; but faults on operations in the Op quad containing the LDAHA operation or in any following Op quads up to and including the last quad of the emcode sequence, result in vectoring to the address in the second vector address register. The retirement of the "ERET" Op quad effectively reactivates the default handler address register for all following operations until the next occunence of an LDAHA operation. The occunence of an abort cycle also reactivates the default handler address register. To simplify matters for OCU 260, LDDHA/LDAHA operations are constrained to be located in the oldest operation position of an Op quad. "Valid" operations are allowed in the following operation positions of the Op quad. Table B.59 summanzes the OCU's LDDHA/LDAHA operation handling logic. VIII.C.3 Target Limit Violation Handling In addition to the commitment of state changes associated with each operation within an Op quad, OCU 260 also recognizes a special condition gged for an Op quad as a whole. Whenever MacDec 260 decodes a transfer control instmction and a code segment limit violation is detected on the target address (after the MacDec has generated an Op quad and the Op quad has been loaded into scheduler 280), the Op quad is marked to indicate that such a v iolation was detected in association with the Op quad. When the Op quad reaches OCU 260 and is to be committed, the set tag bit is recognized and an aboπ cycle is initiated without commitment of any state changes from the operations within the Op quad. Effectively the entire Op quad is faulted. The effect is similar to as if there was a FAULT operation in the Op quad. Table B 60 descπbes logic for handling branch target limit violations. VIII.C 4 Mispredicted Branch Handling Besides commitment of aboπable state changes and handling of various special cases, OCU 260 handles generation of aboπ cycles for mispredicted BRCONDs As mentioned earlier, the restaπ of the mstmction fetch and decode areas occurs before the BRCOND reaches the bottom of scheduler 280. Scheduler 280 subsequently generates an aboπ and ensures that only preceding operations are committed As with the generation of aboπ cycles for operation faults, the aboπ is not initiated until all preceding operations have been committed. Table B 61 summanzes logic which generates an aboπ for a mispredicted branch. VIII D Aboπ Cvcle Generation OCU 260 generates aboπ cycles in two situations: recognition of an Op fault (on a LdStOp or a FAULT operation), and recognition of a mispredicted BRCOND Preceding sections and Tables B.55, B.57 B.58, and B.61 covered generation of signals initiating an aboπ cycle (i.e. signals StAboπ, LdAboπ, Fit Abort, LimAboπ, and BrAboπ). This section descπbes the generation of the general Abort signal and related information. The Abort signal is a combination of all individual abort signals associated with commitment of specific types of state changes or operations. The associated emcode vector address, which is defined only for fault-related aborts and not BRCOND-related aboπs, is FltVecAddr as descnbed above. The Abort signal flushes scheduler 280 and all execution units 251 to 257 of all outstanding operations and re-initializes these areas in preparation for receiving new operations from mstmction decoder 240. For BRCOND-related aborts, this is sufficient because branch evaluation unit 257 previously restarted the emcode and x86 macroinstmction fetch and instmction decoder 240. For exception-related aborts, instmction decoder 240 also needs to be restarted at the fault handler address. When mstmction fetch/decode restaπs are signaled simultaneously for both a mispredicted BRCOND and an operation exception, the operation exception is given higher priority The vector address for the restart and the generation of the appropriate restart signals are generated accordingly When a fault-related abort occurs, OCU 260 also latches information about the fault, namely the x86 macroinstmction program counter (the logical address of the associated x86 instmction effectively being faulted) into a register SR4 Table B 62 summarizes the OCU's abort cycle generation logic IX Processing Systems Embodiments of the invention include a wide vaπetv of processing systems, illustratively including standalone and networked personal computer systems, workstation systems, multimedia systems, network server systems, multiprocessor systems, embedded svstems, integrated telephony systems, and video conferencing systems Figs 1 1 A to 1 IC depict an illustrative set of processing systems that combine a superscalar processor 200 in accordance with the invention with suitable, bus configurations, memory hierarchies and cache configurations, I/O interfaces, controllers, devices, and penpheral components The set of processing systems depicted in Figs 1 1 A to 1 IC is merely illustrative Suitable configurations for a system incoφorating superscalar processor 200 include combinations of components, cards, interfaces, and devices such as 1 video display devices, monitors, flat-panel displays, and touch screens, 2 pointing devices and keyboards, 3 co-processors, floating point processors, graphics processors, I/O controllers, and UARTs, 4 secondary and ternary storage devices, controllers, and interfaces, caches. RAM, ROM. flash memory, static RAM, dynamic RAM 5 CD-ROMs, fixed disks, removable media storage devices, floppy disks, WORMs, IDE controllers, enhanced-IDE controllers, SCSI devices, scanners and jukeboxes, 6 PCMCIA interfaces and devices, ISA busses and devices, EISA busses and devices, PCI local busses and devices, VESA local busses and devices. Micro Channel Architecture busses and devices, 7 network interfaces, adapters and cards such as for ethernet, token ring, lOBase-T, twisted pairs, untwisted pairs, ATM networks, frame-relay, ISDN, etc, 8. video cards and devices, 2-D and 3-D graphics cards, frame buffers, MPEG/JPEG compression/ decompression logic and devices, videoconferencing cards and devices, and video cameras and frame capture devices; 9 computer integrated telephony cards and devices, modem cards and devices, fax cards and devices; 10 sound cards and devices, audio and video input devices, microphones, and speakers, 11. dau acquisition and control cards and interfaces, compression decompression logic and devices, encryption/ decryption logic and devices; and 12. tape backup units, redundant/fault tolerant components and devices such as RAID and ECC memory. Suiuble combinations of such components, cards, interfaces, and devices (including those enumerated above as well as comparable components, cards, interfaces, and devices) are too numerous to list. A networked personal computer 100 incoφorating superscalar processor 200 is shown in Fig. 11 A. Superscalar processor 200 is coupled to memory subsystem 120. Memory subsystem 120 is shown as RAM, although altemative embodiments include a cache or caches inteφosed between the RAM and superscalar processor 200. Superscalar processor 200 and memory subsystem 120 are included as parts of a motherboard 101 of computer 100. A series of adapters, interfaces, and controllers couple processor 200 to devices and peripheral components. These adapters, interfaces, and controllers are typically be coupled to processor 200 as cards in a backplane bus of motherboard 101. However, altemative embodiments may incoφorate individual adapters, interfaces and controllers into motherboard 101. A graphics adapter 1 10 is coupled to superscalar processor 200 and drives signals to control display 1 1 1 in accordance with screen updates supplied by superscalar processor 200. A parallel interface 109 and a serial interface 108 provide parallel port and serial port signaling interfaces for respectively interfacing to parallel port devices (e.g. , printers such as parallel printer 102, tape backup units, etc.) and to serial devices (e.g. , modem 103, pointing devices, and printers). A hard disk/ floppy disk controller 130 controls access to a hard disk 132 and a floppy disk 131. A LAN adapter 107 provides computer 100 with a network interface to local area networks such as 802.3 ethernet, lObase-T. twisted pair, and token ring networks. As with the other adapters and interfaces, LAN adapter 107 is typically coupled to processor 200 as a card in the backplane bus of motherboard 101. Superscalar processor 200 is paπicularly attractive as the processor, or a one of multiple processors, in a network server configuration such as than shown in Fig. 1 IB where multiple instances of superscalar processor 200 are shown coupled to a level 2 cache 125 and to a processor bus 123. Each superscalar processor 200 couples to a memory controller 121 and a system controller 150 via a processor bus 123. Memory controller 121 provides a 64-bit interface to memory 122 including an 8- bit parity interface to support Enor Conecting Codes (ECC). ECC memory is desirable, but optional. System controller 150 provides the interface (or bridge) between the 64-bit processor bus 123 and the 32-bit local bus 151. Local bus 151 is any high-speed I/O bus, for example, a VESA Local bus (VL bus) or Peripheral Component Interconnect (PCI) bus. System controller 150 provides buffering to support the potentially disparate clock rates of processor bus 123 and local bus 151. System controller 150 arbitrates for use of the two busses (123 and 151) and may, in certain configurations, support burst data transactions across the two busses. Local bus 151 couples to multiple local bus devices and components (illustratively, to SCSI Adapter 170, IDE controller 180, LAN Adapter 157, and bridge and peripheral controller 160). Because display device requirements are typically less demanding in network server configurations than in personal computer or workstation configurations, display adapter 112 is shown coupled to the lower bandwidth ISA bus 161. IDE controller 180 is representative of a variety of controller designs (including IDE, enhanced IDE, ATA, and Enhanced Small Device Interface (ESDI) controller designs) for interfacing storage devices such as disks, tape drives, and CD-ROMs. IDE controller 180 is coupled to two disks (hard disk 181 and floppy disk 182) and to a tape backup unit 183. Altemative configurations may interface an IDE/enhanced IDE CD-ROM via IDE controller 180, although a both a CD-ROM 172 and a CD jukebox 173 are interfaced via a Small Computer System Interface (SCSI) adapter 170 in the embodiment of Fig. 11 B. SCSI adapter 180 is coupled to local bus 151 and to multiple SCSI devices (illustratively, to a Redundant Anay of Inexpensive Disks (RAID) 171 , CD-ROM 172, scanner 2016, CD jukebox 173, and a scanner 174) in a daisy chain configuration. For illustrative puφoses, the daisy chain of SCSI devices is shown as a bus in Fig. 1 I B. LAN adapter 157 is representative of suitable network adapters such as those based on IEEE 802.x standards (e.g., 802.3 baseband ethernet on coaxial media, twisted and untwisted pair media, and lObase-T, 802.3 broadband networks, 802.4 token passing networks, 802.5 token ring networks, etc.), and those based on Fiber Distributed Data Interface (FDDI) standards. ISA bus 161 is coupled to local bus 151 via bridge and peripheral controller 160 and provides a 16-bit I/O bus and modular connections for a vanety of penpheral components including display adapter 1 12, telephony card 136, and a multifunction I/O card such as super I/O 135. Super I/O 135 provides suppoπ for a pointing device 137, a serial pon 138, a parallel port 139. and a disk 131. A multimedia workstation configuration for superscalar processor 200 shown in Fig. 1 IC. As with the server configuration of Fig. 1 I B, the multimedia workstation configuration includes a hierarchy of busses with varying performance charactenstics each matched to the devices and components coupled thereto. Those skilled in the an will recognize a vanety of suiuble variations on the bus hierarchy of Fig. 1 IC. Memory bus 126 couples superscalar processor 200, cache 127, memory 128, and bridge 129. As with the network server configuration of Fig. 1 IB. a variety of cache configurations are suitable for a multimedia workstation. Local bus 151 is preferably a high speed I/O bus such as a VL bus or PCI bus. SCSI adapter 170, LAN adapter 157, a graphics adapter 114, sound adapter 190, and motion video adapter 195 are coupled to each other and to superscalar processor 200 via I/O bus 151. SCSI adapter 170, LAN adapter 157, and an expansion bus bridge 160, together with the components and devices coupled to each are comparable to conesponding adapters, components, and devices discussed above with reference to Fig. HB. In particular, SCSI adapter 170 is coupled to multiple SCSI devices (illustratively, disk 175, tape backup unit 176, and CD-ROM 172) in a daisy chain configuration. In accordance with an embodiment of superscalar processor 200, superscalar processor 200 may contain a multimedia unit 256 for executing multimedia extensions to the x86 instmction set. Referring again to Fig. HC, multimedia adapters, such as sound adapter 190, motion video adapter 195, and graphics adapter 114, are each coupled to superscalar processor 200 via busses 151 and 126 to provide for high-bandwidth transfers of multimedia data between the multimedia adapters, memory 128, and secondary storage devices (e.g., disk 175). Sound adapter 190 provides digital-to-analog (D/A) and analog-to-digital (A/D) interfaces for respectively synthesizing and sampling audio signals. The A/D and D/A interfaces of sound adapter 190 are respectively coupled to a microphone 191 and a speaker 192. Suitable designs for sound cards are well known in the art and sound adapter 190 is of any such suitable design. Motion video adapter 195 provides suppoπ for capture and compression of video signals, for example, from video camera 196. In addition, motion video adapter 195 supplies a display device 198 such as a television, high-definition television, or a high resolution computer monitor with display signals via a frame buffer 197. Altemative embodiments of motion video adapter 195 may eliminate frame buffer 197 and directly drive a raster display. Furthermore, altemative embodiments of motion video adapter 195 may decouple the video input and video output functionality of motion video adapter 195, and instead provide separate video input and video output components. Because video information requires large amounts of storage space, it is generally compressed. Accordingly, to display compressed video information, for example from data represented on a compact disk in CD-ROM 172. the compressed video information must be decompressed. High bandwidth burst mode data transfers are suppoπed by I/O bus 151 , which is preferably a local bus such as PCI with suppoπ for arbitrary length burst data transfers. Video compression and decompression can be performed by superscalar processor 200 (executing multimedia instmctions in a multimedia unit) and/or by motion video adapter 195. Thus, memory bus 126 and bridge 129 preferably suppoπ burst data transfers across bridge 129 between memory bus 126 and I/O bus 151. X. Conclusion Although the present invention has been described with reference to paπicular embodiments, the description is only an example of the invention's application and should not be taken as a limitation. Various adaptations and combinations of feamres of the embodiments disclosed are within the scope of the present invention. Appendix A: RISC86™ Syntax This appendix describes op-codes according to the RISC86™ syntax illustrated in Fig.3. RegQp DEFINITIONS Bits 36 and 37 of an Op-code are 00 to identify a RegOp. Bits 10 and 11 are unused and should be 00. A.1 RegOp Type Field Encoding Type DSz≠lb DSz = lb cc-dep RUX-onlv ALU OOOOOx ADD/INC ADD/INC Ops OOOOlx MOV/OR OR OOOlOx ADC ADC ♦ ♦ OOOllx SBB SBB ♦ ♦ 001000 AND/EAND AND 001001 BAND OOlOlx SUB/ESUB ooπox EXOR/XOR OOlllx CMP CMP Shift 010000 SLL SLL Ops 010001 BLL SLL OlOOlx SRL SRL OlOlOx SLC/RLC ♦ ♦ OlOllx SRC/RRC ♦ ♦ OHOOx SLA SLA OHOlx SRA SRA oπiox SLD/RLD RLS 0111 lx SRD/RRD RRS Move lOOOOx RDFLG and 100010 SEXT Other 100011 ZEXT Ops 100100 RDFLGS DAA ♦ ♦ 100101 RDFLGS DAS ♦ ♦ 1001 lx MOVcc ♦ ♦ 101000 MUL1S 101001 MLU1U 101010 MULEH 101011 MULEL 101100 DIV1 101101 DIV2 101110 DIVER 101111 DIVEO Spec. llOOOx RDxxx Reg. HOOlx Ops HOlxx ♦ ♦ 111000 WRDR 111001 WRDL llIOlx WRxxx 111100 CHKS 111101 WRDH lllllx WRIP Mnemonics separated by a "/" have identical Type fields and are treated identically by register units 253 and 254. These RegOps differ in stams modifications indicated by fields Ext and SS and committed by OCU 260. The Type field is inteφreted differently based on field DSz. As illustrated above, execution units perform one operation for a byte-size RegOp and another operation for a 16/32-bit size RegOp. All byte-size RegOps and all RegOps having type field of the form xlxxxx, lxlxxx, or xxOlxx are RUX-only operations. Hardware treats all RegOps with Type field values of the form xxOlxx as "cc-dependent" and thus synchronizes execution of the operation with status operand forwarding. A.2 RegQp Extension Field Extf3:01 For MOVcc Op's, {Type[0],Ext[3:0]} specifies a 5-bit condition code. For RDxxx/WRxxx Op's, {Type[0],Ext[3:0]} specifies a 5-bit special register number. For WRFLG(.cc) the spec register number encoding matches the StatMod value desired if ".cc" is specified. For RDSEG Ops, Ext[3:0] specifies a 4-bit segment (selector) register. The set of segment registers include x86 architecmrai registers and additional special segment registers. Reg, ff Name Use 0000 ES x86 Architectural 0001 CS x86 Architectural 0010 SS x86 Architectural 001 1 DS x86 Architectural 0100 FS x86 Architecmrai 0101 GS x86 Architectural 01 10 HS Temporary 01 1 1 lOOx TS Descriptor table "seg. reg. " (GDT or LDT) 1010 LS Linear "seg. reg. " ("null * segmentation) 1011 MS Emulation memory seg. reg. l lxx OS Effective (arch.) data seg. reg. The OS segment register is replaced at Op decode time by the cunent 3-bit register number from the emulation environment. For other operations with field SS= 1 , {Type[0],Ext[3:0]} specifies four Status Modification bits (as stored in scheduler 280). A.3 RegQp Operation/Data Size Field DSzf2:01 Field Dsz indicates a data size for the operation. DSzf2:01 Operation/Data Size 0 0 0 1 byte 0 0 1 2 bytes 0 1 0 4 bytes 0 1 1 DSize 1 0 0 ASize 1 0 1 SSize Sizes DSize, ASize, and SSize are placeholders which are replaced with conesponding environmental variables during environmental substitution. A.4 RegQp RUX-onlv Field Rl Rl is set to indicate the RegOp is issuable only to register unit 251. A.5 RegQp Destination Field Dest|4:01 Field Des t [4:0] holds a 5-bit general register number identifying a destination register for the operation. A.6 RegQp First Source Field Scrl 14:01 Field Scrl [4:0] holds a 5-bit general register number identifying a first source register for the operation. A.6 RegQp Set Status Field SS Field SS is set to indicate the operation modifies the status flags indicated by field Ext. A.6 RegQp Field I Field I indicates whether field Imm8/Src2 contains an immediate value or a register number. A.6 RegQp Field Imm8/Src2[7:01 Field Imm8/Src2 holds an immediate value or a register number for a second source operand. If I = 0, Imm8/Src2[4:0] contains a 5-bit register number. If 1 = 1 , Imm8/Src2[7:0] specifies an 8-bit signed immediate value which is sign extended to a size indicated by field DSz. LdStOp DEFINITIONS Bits 37 and 36 of an Op-code are 0 and 1 to indicate a LdStOp. A.7 LdStOp Type Field Type! 3 01 Tvpel3:01 Mnemonic Operation oooo LD Load integer (int.) data 0001 LDF Load floating point (f p.) data. 0010 LDST Load int. data with store check 0 00011 11 L LDDMM Load multimedia (m.m.) data 0100 CDAF CDA plus flush cache line(s) 0101 - 01 10 LDSTL Load int. w/ store check, locked 01 11 LDMSTL Load m.m. w/ store check, locked 1 1000000 S STT Store int. data 1001 STF Store f.p. data 1010 STUPD Store int. w/ base register update 101 1 STM Store m.m. data 1100 CDA Check data effective address 1 1110011 C CIIAA Check instmction effective address 1110 TIA TLB Invalidate Address l l l l LEA Load effective address A.8 LdStOp Address Calculation Size Field ASzfLOI Before emcode environmental substimtion, field ASz[l :0] indicates the address calculation size as follows. ASzfLOl Size 00 ASize 01 SSize 10 4 bytes 11 DSize Emcode environmental substitution changes ASize, SSize, or DSize to the appropriate fixed size. A.9 LdStOp Data Size Field DSzf Ol For LDF, STF, LDM, STM For Other Ops DSz Before After (LDF. STF onlv) Before After 00 FpDSize (LDF, STF only) 1 byte 1 byte 01 2 bytes 2 bytes 2 bytes 2 bytes 10 4 bytes 4 bytes 4 bytes 4 bytes 11 8 bytes 8 bytes DSize A.10 LdStOp Data Field Dataf4:01 Field Data indicates a 5-bit general register number for the store source or load destination register. A.10 LdStOp Segment Field Seg[3:01 Field Seg[3:0] identifies a segment register. A.1 1 LdStOp Base Operand Field Base[3:01 Field Base contains a 4-bit register number indicating a general register in the lower half of the register file. The value from the register is the base for the address calculation. A.12 LdStQp Index Field Indeχ[3:01 Field Base contains a 4-bit register number indicating a general register in the lower half of the register file. The value from the register is use as an address index which is scaled and added to the base during an address calculation. A.13 LdStQp Index Scale Factor Field ISFf LOl Field ISF indicates the index should be scaled by a factor of 1 , 2. 4, or 8. A. 14 LdStQp Large Displacement Field LD Field LD indicates whether the operation uses a large (32-biι) displacement from a preceding LIMMOp or small (8-bit) displacement from field Dispδ. A.15 LdStQp Small Displacement Field Disp8f7:01 Field Disp8[7:0] contains an 8-bit displacement which is sign extended to a size indicated by field ASz. LIMMOp DEFINITIONS Bits 37 and 36 of an Op-code are 11 to indicate a LIMMOp. A.16 LIMMOP Immediate Fields ImmHi and ImmLo Fields ImmHi[14:0] and ImmLo[16:0] respectively contain the most significant 15 bits and the least significant 17 bits of a 32-bit immediate value. A.17 LIMMOP Destination Field Dest[3:01 Field Dest[3:0] stores a 4-bit register number indicating a destination for the immediate value. Note: the standard NO-OP is "LIMM tO, < undefined > " which is loaded into scheduler in a completed state and is committed by writing an immediate value < undefined > to a register tO which is not changed by writing. SoecQp DEFINITIONS Bits 37 and 36 of an Op-code are 10 to indicate a SpecOp. Bit 35 is set for the SpecOps described in this appendix but cleared for FpOps. A.18 SpecOp Type Field Tvpef3:01 Type Mnemonic Operation OOxx BRCOND Branch condition OlOx LDDHA Set default fault handler address 1 Ol lx LDAHA Set alternate fault handler address lOOx LDK Load constant lOlx LDKD Load constant, data l lxx FAULT Unconditional fault A. 19 SpecOp Condition Code Field ccf4:01 Field cc[4:0] contains a 5-bit condition code for BRCOND operations. Bits cc[4: l] specify the condition to be tested as follows. ccl " 4: 11 Mnemonic Condition 0000 Tme 1 0001 ECF ECF 0010 EZF EZF 0011 SZnZF - ( - EZF ZF) 0100 MSTRZ - EZF- - IP - ( DTF + SSTF) 0101 STRZ - EZF - IP - ( DTF + SSTF) 0110 MSTRC - ECF- - IP - (DTF + SSTF) 0111 STRZnZF - EZF- - IP - ( DTF + SSTF) ZF 1000 OF OF 1001 CF CF 1010 ZF ZF 1011 CvZF CF + ZF 1100 SF SF 1101 PF PF 1110 SxOF SF Λ OF l l l l SxOvzF SF Λ OF + ZF Bit cc[0] specifies whether the condition or its compliment is evaluated for tmth. In the above definitions, " - ", "•", " + ", and " Λ " indicate logical NOT, AND, OR, and XOR operations, respectively. OF, SF, ZF, AF, PF, and CF are standard x86 status bits. EZF and ECF are an emulation zero flag and an emulation carry flag that emcode uses in sequences implementing x86 instmctions when architectural zero flag ZF and carry flag CF are not changed. IP, DTF, and SSTF are signals indicating an interrupt pending, a de-bug trap flag, and single step trap flag respectively. Branch conditions STRZ and MSTRC are logically identical and are used in implementing x86 instmctions such as a move string instmction MOVS. For such x86 instmctions, emcode stores an index in a register and creates a loop that ends with a BRCOND. Each iteration of the loop moves a chunk of data and decrements the index. Branch prediction initially predicts that the BRCOND branches to the beginning of the loop. Condition MSTRC indicates that branch evaluation logic 257 is to signal instmction decoder 240 when the index reaches a predefined point near completion of the x86 instmction. Decoder 240 then changes the branch prediction for the BRCOND being loaded into scheduler 280. Accordingly, a mispredicted branch and associated aboπ can be avoided when loopmg is complete. The improves processor efficiency A.20 SpecOp Data Size Field DSzf Ol Field DSz[l :0] indicates a data size 1 byte, 4 bytes, or DSize for load constant operations LDK and LDKD. A.21 SpecOp Destination Field Dest[4:01 Field Dest holds a 5-bit register number which is the destination of operation LDK and LDKD. A.21 SpecOp Immediate Field Imml7π6:01 Field Imml7[16:0] contains a 17-bit constant, a 17-bit signed immediate, or 14-bit Op address. GENERAL REGISTER DEFINITIONS There are 24 integer general registers. The first eight registers conespond to the x86 general registers AX to DI. The remaining sixteen registers serve as temporary or scratch registers used within multiple operation sequences implementing CISC instmctions. The operations which use 5-bit register numbers can access 32 registers, and remaining register numbers not used for integer registers can be multimedia registers or placeholders for environmental vanable substitution. The x86 integer register set suppoπs addressing, for byte operations of either of the lower two bytes of half of the registers (AX, CX, DX, and BX). Based on register size specification, the 3-bιt register numbers within x86 instmctions are inteφreted as either hi/lo byte registers or as word/dword registers. From an operation perspective, this size is specified by either the ASz or DSz field of the operation. (ASz for Base and Index registers in LdStOps; and generally DSz for Data/Dest, Srcl, and Src2 registers). The scratch integer register set suppoπs similar addressing of the lower two bytes of again half of registers (tl-t4 and t8-tl 1). The following table maps register numbers 1 to 24 to named register. Register Name Register Name Reg. Num. Size≠ l bvte Size= l bvte 00000 AX AL 00001 CX CL 00010 DX DL 00011 BX BL 00100 SP AH 00101 BP CH 00110 SI DH 00111 DI BH 01000 tl tlL 01001 t2 t2L 01010 t3 t3L 01011 t4 t4L 01100 t5 tlH 01101 t6 t2H oi πo t7 t3H 01111 t0/_ t4H 10000 t8 t8L 10001 t9 t9L 10010 no tlOL 1001 1 ti l tl lL 10100 tl2 t8H 10101 tl3 t9H 10110 tl4 tlOH 101 1 1 tl5 tl lH Mnemonics "tO" and "_" are synonyms for a register that can be written to but always retums a value zero when read. "_" is typically used in a context where an operand or result value is a don't care. As indicated above register tO cannot be referenced in byte mode. Appendix B: Pseudo-RTL Descriptions Tables in this appendix describe logic which generates signals used throughout the exemplary embodiment of processor 200. Each table may use signals descnbed in other tables without further explanation or reference to the other tables. Signals described in this appendix are asseπed or active high unless expressly indicated otherwise. The followmg notations are used. " - " indicates the complement or inverse of a signal such as would be provided by an inveπer. Signals connected via a " • ", " ", and "&" are combined as a logical AND such as could be implemented by an AND gate. Signals connected via a " + " are combined as a logical OR such as could be implemented by an OR gate. Signals connected via a " Λ " are combined as a logical exclusive OR such as could be implemented by an XOR gate. The notation "if (a) x=b else x=c" or alternatively "if (a) x = b • c" indicates a multiplexer with an output signal x equal to signal b if signal a is assert and signal x equal to c otherwise. If "else x=c" is omitted, signal x is low if signal a is low. Another notation which represents a multiplexer is "x = switch (A) case Al : xl case A2: x2 ... case An. xn" where output signal x has values xl or x2 or ... xn depending on the value of a multibit select signal A. Where cases are omitted as in "x = switch (A) xl :x2. ... xn", output values xl to xn conespond to sequential values of signal A. Most signals descnbed change each clock cycle. Notation ©(clock) indicates a signal is latched into a register at an edge of signal clock for use in a subsequent clock cycle. As will be understood by those skilled in the an, the logic descnbed below can be implemented in a vanety of ways. Table B 1 Static Field Storage Element Operation always ©(posedge CLK) if (LdEntry[iJ) // Shift control from global control OpFιeld[ι] = OpFιeld[ι- l] // load preceding Op value Table B.2 Dynamic Field Storage Element Operation if (LoadNewValue[ι]) // if logic loads a new value NewOpField[i] = NewValuefi]; // load a new value else NewOpField[i] = OpField[i]; if (LdEntry[i]) // if logic shifts value NextOpField[i] = NewOpField[i-l]; // advance FIFO else NextOpField[i] = NewOpField[i]; always @(posedge CLK) OpField[i] = NextOpField[i]; Global control logic 520 for scheduler 280 generates mdependent signals LdEntry[ι] which select a signal loaded into a respective flip-flop. The notation xxOp.yyy refers to an input signal to operation decoder 510 indicating a value from a field yyy defined for a RISC86 instmction of type xxOp For example, RegOp Srcl refers to bits in an instmction at the same position as the Srcl field of a RegOp Fig 3 and Appendix A define an exemplary field definition for a RegOp, a LdStOp, a LIMMOp, and a SpecOp. Table B 3 Field Type Type[2.0] swιtch(θpld) { case RegOp. Type[2, l] = 'bl l , Type[0] = - (RegOp.Rl + RUYD) case LdStOp- Type[2] = LdStOp Type[3], Type[l] = - LdStOp.Type[3], Type[0] = LdStOp Type[3] • -(LdStOp Type[2) LdStOp Type[l]) default. Type[2:0] = 'bOOO } "RUYD" is a special register that disables the second register unit RUY for debugging Table B 4 Field LD Irr-m LDJmm = (OpId = RegOp) "> RegOp I LdStOp. LD //don't care if not RegOp or LdStOp Table B 5 Field Src l Reg if (OpId = RegOp) Srcl Reg = RegOp. Src l ; Src lReg[2) --. = - (LdStOp DSz = lB) else SrclReg = { l 'bO. LdStOp Base} //don't care if not RegOp or LdStOp Table B 6 Field Src2Reg if (OpId= RegOp) Src2Reg = RegOp. Src2; Src2Reg[2] &= - (LdStOp DSz= lB) else Src2Reg = { l 'bO, LdStOp. Index} //don't care if not RegOp or LdStOp Table B 7 Field SrcStReg SrcStReg = LdStOp. Data SrcStReg[2] = SrcStReg[2]--(LdStOp.DSz= lB • LdStOp DataReg=t0) //don't care if not StOp Table B.8 Field DestReg if (OpId= LIMMOp) DestReg = {l'bO.LIMMOp.Dest} elseif ((Opld = LdStOp) -(LdStOp .Type = STUPD)) DestReg = {l'bO.LdStOp.Base} else { DestReg = LdStOp.Data DestReg[2] = DestReg[2]-~(LdStOp.DSz = lB) } //don't care if non-STUPD StOp Table B.9 Fields SrclBM. Src2BM. and Srcl2BM if (Opld = RegOp) { SrclBM[0] = ~(RegOp.DSz = lB) + -RegOp. Srcl [2] SrclBM[l] = -(RegOp.DSz=lB) + RegOp.Srcl[2] Src2BM[0] = -( RegOp. DSz = IB) + - RegOp. Src2[2] + RegOp.I Src2BM[l] = - (RegOp. DSz = IB) + RegOp. Src2[2] -RegOp.I if(RegOp.Type=10001x) Src2BM[l] = SrclBM[l] = l'bO //if ZEXT.SEXT Srcl2BM[2] = (RegOp. DSz=4B) if (RegOp.Type = (10001x + 111x00)) Srcl 2BM[2]= l'bO //if ZEXT.SEXT.CHKS } else { //else LdStOp or don't care SrclBM[l:0] = Src2BM[l:0] = 2'bll Srcl2BM[2] = (LdStOp. ASz =4B) } // don't-care if LIMM Table B IO Field SrcStBM if (LdStOp.Type=x0xx) { //STxx Ops SrcStBMJO] = -(LdStOp. DSz= IB) + - LdStOp. Dau[2] SrcStBM[l] = - (LdStOp. DSz = IB) + LdStOp. Data[2] SrcStBM[2] = (LdStOp.DSz=4B) } else SrcStBM[2:0] = 'bOOO //CDA,CIA,LEA Ops //don't care if not a StOp Table B.11 Field Opinfo OpInfo[12] = Op[35] //Prevents LIMM from looking like various exception Ops Oplnfo[ll:8] = (Opld = LIMMOp) ? ' ill : Op[34:31] Oplnfo[7:0] = Op[30:25], Op[23:22] Table B.I2 State Field Operation decoder 510 initializes field State[3:0] either as bOOOO (unissued) or bl 111 (completed) according to the Opld field of the conesponding RISC86 instmction. State = (-OpQV + Opld = SpecOp -SpecOp. Type = (LDKxx + LDxHA) + Opld = LIMMOp) ? ' ill : 'bOOOO Field State (signals SO, Sl, S2, and S3) change during operation execution as follows. if(S0Enbl)S0 = -BumpEntry + SC_Aboπ if (SlEnbl) Sl = (SO- -BumpEntry) + SC_Aboπ if (S2Enbl) S2 = Sl + SC Aboπ if (S3Enbl) S3 = S2 + Sl-RU + SC Aboπ BumpEntry = RU--Sl-S0-(ExeclBumpRUX + -Execl-BumpRUY) SOEnbl =IssueOpToLU[i]CHP_LUAdvO + IssueOpToSU[i]CHP_SUAdvO + IssueOpToRUX[i]CHP_RUXAdvO + IssueOpToRUY[i]CHP_RUYAdvO + SC Aboπ + BumpEntry SlEnbl = LUCHP LUAdvO + SUCHP SUAdvO + RU<ExeclCHP_RUXAdvO + - Execl CHP_RUYAdvO) + SC Aboπ S2Enbl = LUCHP LUAdvl + SUCHP SUAdvl + RU + SC Aboπ S3Enbl = LUCHP_LUAdv2 + SUCHP_SUAdv2 + RU + SC_Aboπ Signal SC Aboπ is asseπed to aboπ execution of operations cunently in scheduler 280. Signals IssueOpToLU[i], IssueOpToSU[i], IssueOpToRUX[i], and IssueOpToRUY[i]. Table B.13 Field Execl Operation decoder 510 initializes field Execl to low. Execl = X Subsequently, field Execl changes as follows. if (SOEnbl) Execl = IssueOpToRUX Signal IssueOpToRUX is generated within the entry during the issue selection scan chain for register unit 253. Table B.14 Field DestBM Operation decoder 520 initializes field DestBM according to the operation to indicate which bytes of the destination register will be modified, if (Opld = LIMMOp) { if (LIMMOp.DestReg=t0) DestBM = 'bOOO else DestBM = 'bill } elseif (OpId=LdStOp-LdStOp.Type=STUPD) { DestBM[l:0] = 2'bll DestBM[2] = (LdSt0p.ASz=4B) } else { DestBMfO] = ~(LdStOp.DSz= lB) + - LdStOp. Data[2] DestBM[l] = - (LdStOp. DSz = IB) + LdStOp. Dau[2] DestBM[2] = (LdStOp. DSz =4B) } if ( -OpQV + DestReg = * b0111 1 + (Opld = LdStOp -LdStOp. Type =ST/STF)) DestBM = 3'bO // if invalid or dest is tO, store no dest reg Field DestBM is cleared as follows: if (SC_Abort) DestBM = 3'bO Table B.15 Field DestVal Operation decoder 510 generates field DestVal from the associated RISC86 instmction using the following logic. DestVal = switch(θρld) { case RegOp: sext(RegOp.Imm8) case LdStOp: sext(LdStOp.Dispδ) case LIMMOp: {LIMMOp. ImmHi. LIMMOp. ImmLo} case SpecOp: if (SpecOp.Type = BRCOND - DEC OpQSel E) DEC AltNextlPC else sext(SpecOp.Imml7) } Follow execution of the operation field DestVal changes as follows. if (( - S2 + LU)- - S3 S1 ) DestVal = switch (Type) case LU: DC DestRes case SU: SU l DestRes case (RU -Exec l ): RUX DestRes case (RU- - Execl ): RUY DestRes where signals DC DestRes. SU l DestRes, RUX DestRes, and RUY DestRes are from the execution unit that executed the operation. Table B.16 Field StatMod Operation decoder 510 sets field StatMod according to the associated operation. StatMod = (OpQV OpId= RegOp) RegOp.SS) ? RegOp.Ext : 4'bO //OpQV:see below Logic in scheduler 280 clears field StatMod during an abort, if (Execl -- S3 -Sl -RUX NoStatMod + SC Abort) StatMod = 4'bO Table B.17 Field StatVal Generation Logic Field StatVal is initially zero. StatVal = 8'bX and changes when a RegOp is completed, if ( -S3-S1) StatVal = (Execl) ? RUX_StatRes : RUY StatRes Table B.18 Fields QpmdMatch XXsrcY Fields OprndMatch_XXsrcY pass information from the issue stage to operand forward stage of each processing pipeline (or, in one case, from stage 1 to stage 2 of SU), values are controlled by global signals XXAdvY (more specifically XXAdvO or SUAdv2) if (LUAdvO) { OpmdMatch LUsrcl = .. OpmdMatch_LUsrc2 = .. } if (SUAdvO) { OpmdMatch SUsrcl = ... OprndMatch_SUsrc2 = . . } if (SUAdv2) { OpmdMatch SUsrcSt = . } if (RUXAdvO) { OprndMatch RUXsrcl = OprndMatch_RUXsrc2 = ... } if (RUYAdvO) { OpmdMatch RUYsrcl = . . OpmdMatch_RUYsrc2 = . } Table B 19 Field DBN Field DBN is initially zero. DBN = 4'bO and changes dunng execution as follows. ιf ((AdvLU2 + AdvSU2)- - S3 -S2) DBN[3:0) = (DBN_LU[3 0] LU ) + (DBN_SU[3 0] SU) Table B 20 Op Quad Field Emcode Emcode = DEC OpQSel E + DEC_Vec2Emc //treat vectoring Op quad as pan of emcode Table B.21 Op Quad Field Eret Eret = DEC OpQSel E-EDR Eret Table B.22 Op Quad Field FaultPC FaultPC = DEC PC The logical PC for the first decoded x86 instmction in Op quad. Table B.23 OP Quad Field BPTInfo BPTInfo = DEC BPTInfo Information from the current BPT access. Table B.24 Op Quad Field RASPtr RASPtr = DEC_RASPtr The cunent retum address stack. Table B.25 OP Quad Field OpQV Operation decoder 510 initially sets field 00^ to indicate whether the Op quad loaded into the top of scheduler 280 is valid. OpQV = ((DEC OpQSel E) ? EDR_OpQV : DEC_OpQV ) • - ExcpAboπ - (SC_MιsPred- - BrAboπ) This multiplexer is not unique; all new Op quad fields come from similar (but 3: 1) multiplexers see OCU descnption for descnption of ExcpAbort. Field OpQv can later be cleared after an abort to invalidate an Op quad and prevent execution or commitment. if (SC_Abort) OpQV = 'bO Table B.26 Op Quad Field LimViol LimViol = 'bO Field LimViol is actually loaded one cycle later than all of the other fields above (i.e dunng the first cycle that the new Op quad is resident and valid withm the scheduler. This is reflected in the descnption above of this Op quad field. @clk: LdLV = LdEntryO- - DEC_OpQSel_E //a simple flip-flop if (LdLV) LimViol = DEC LimViol //see below for LdEntryO Table B 27 Shift Control Logic Signals LdEntryO to LdEntry5 control loading of row 0 (with a new Op quad) to loading row 5 (with an Op quad from row 4) as described m regard to Fig. 6. In this table, input signal OpQRetire, from OCU 260, indicates when a valid Op quad in the bottom row of scheduler 280 can be retired and input signals HoldOpQ3, HoldOpQ4A, and HoldOpQ4B indicate whether condition code evaluation has held up an operation in row 3 or 4. HoldOpQ45 = (HoldOpQ3 + HoldOpQ4A + HoldOpQ4B)- -(SC MisPred + Q4PendLdStAboπ + "trap pending") LdEntry5 = (OpQRetire + -OpQV_5) -HoldOpQ45 LdEntry4 = (OpQRetire + -OpQV_5 + - OpQV_4)— HoldOpQ45 LdEntry3 = LdEntιy4 + -OpQV 3 LdEntry2 = LdEntry4 + -OpQV_3 + - OpQV_2 LdEntryl = LdEntry4 + ~OpQV_3 + -OpQV_2 + -OpQV l LdEntryO = LdEntry4 + -OpQV_3 + -OpQV_2 + -OpQV l + -OpQV O + BrAboπ SchedFull = - LdEntryO + SC MisPred-- BrAboπ SchedEmpty = -(OpQV O + OpQV l + OpQV_2 + OpQV_3 + OpQV_4 + OpQV_5) B.28 Single-Entry Issue Scan Terms Single-entry terms are: LU: - Pi = Ki = IssuableToLU[i] = LUi- - S0i SU: - Pi = Ki = IssuableToSU[i] = SUi-- S0i RUX: - Pi = Ki = IssuableToRUX [i] = RUi- - S0i RUY: - Pi = Ki = IssuableToRUY[ι] = RUYi-- S0ι Oi = Gi = IssuableToRUX[ι] = RUi-- S0i IssuableToxx = " State = Unissued" • "Executable by xx" where "State = Unissued" is - SO and "Executable by xx" is equal to LU/SU/RU/RUY for execution pipelines LU/SU/RUX/RUY respectively. Type bus LUi, SUi, RUi, RUXi as used here are: LU = 1 for LdOps; SU = 1 for StOps (including operations such as LEA); RU = 1 for all RegOps; and RUY = 1 for RegOps executable by RUY. Table B 29 LU. SU, and RUX Look-ahead Scan Chains Six single-entry signals to form four group propagate signals XXPgφ[3:0] and group kill signals XXKgφ[3:0] for scan chain XX where XX is LU, SU. or RUX. Each group signal corresponds to a quadrant of scheduler 280. The following are group signals for the first quadrant (quadrant 0) which includes entnes 0 to 5 for one of the scan chains. XXPgrpO = P0-P1 -P2 -P3 P4 -P5 = - (K0 + K 1 + K2 -r-K3 -f-K4 + K5) XXKgrpO = K0 + Kl -r-K2 + K3 + K4 + K5 = - (P0-P1 -P2 -P3 -P4-P5) where PO to P5 and K0 to K5 are the single-entry terms for six consecutive entries and pipeline XX A group contains the selected instmction if s group kill signal XXKgφ is asseπed and no older group kills the scan bit. A bit from XXIssueQuadrant[0:3] is asseπed to identify the group containing the operation selected for issue to pipeline XX. Signals XXIssueQuadrant[0:3] are generated as follows. XXIssueQuadrant3 = XXKgφ3 XXIssueQuadrant2 = XXKgφ2 - - XXKgφ3 XXIssueQuadrant 1 = XXKgφ 1 - - XXKgφ2 - - XXKgφ3 XXIssueQuadrantO = XXKgrpO - - XXKgφ 1 - - XXKgφ2 - - XXKgφ3 XXNonelssued = - XXKgφO - - XXKgφ 1 - - XXKgφ2 - - XXKgφ3 Signals IssueToXX[i] to indicate the operation issued, if any, issued to pipeline XX and is generated from signals IssueQuadrant and single-entry kill terms IssuableToXX as follows. IssueOpToXX[5] = XXIssueQuadrant[0]-IssuableToXX[5] lssueOpToXX[4] = XXIssueQuadrant[0]- - IssuableToXX[5] -IssuableToXX[4) IssueOpToXX[3] = XXIssueQuadrant[0] - - IssuableToXX[5] - - IssuableToXX[4] • IssuableToXX[3] IssueOpToXX[2] = XXIssueQuadrant[0] • - IssuableToXX[5]-- IssuableToXX[4]- - IssuableToXX[3] -IssuabIeToXX[2] IssueOpToXX[l] = XXIssueQuadrant(0] • - IssuableToXX[5]-- IssuableToXX[4]- - IssuableToXX[3] - - IssuableToXX[2] - - IssuableToXX[0] • IssuableToXX[ 1] IssueOpToXX[0] = XXIssueQuadrant[0] • - IssuableToXX[5]-- IssuableToXX[4]- - IssuableToXX [3] - - IssuableToXX[2] ■ - IssuableToXXfO] - - IssuableToXX[ 1 ] • IssuableToXX[0] Table B 30 RUY Scan Chain (3-bit groups) Single-entry P, K, O, and G are combined to produce group terms Ggφ[7:0], Pgφ[7:0], and Ogφ[7:0] for eight groups of three entries. For group 0, the group terms are- Ggφfi] = Gx-Py-Pz + -Ox-Gy-Pz + -Ox -Oy-Gz = Gx--Ky-Kz + Gy-Kz + Gz Pgφ[ι] = Px-Py-Pz = -Kx--Ky-Kz Kgφ[ι] = - Pgφ[ι] = Kx + Ky + Kz Ogφ[ι] = Ox + Oy + Oz = Gx + Gy + Gz where x, y, and z respectively identify oldest, middle and newest entnes in group I. Single-entry G terms are bus of signal IssuableToRUX[23.0], and single-entry K terms are bus of IssuableToRU Y[23:0]. Group terms are combined in stages to form group terms for yet larger groups The following equations descnbe logic which combines group terms GX, OX. PX. GY. OY. and PY to form group terms for a group XY which is the union of groups X and Y. GXY = GX-PY + -OX-GY PXY = PX-PY OXY = OX + OY Signals CιnGφ[6:0] and OinGφ[6:0] are output from the combinations. Signals CinGφ[6:0] are signals G_7, G_67, G_567, G_4567, G 34567, G 234567, and G 1234567 Output signal OinGφ[6:0] are signals 0_7, 0_67, 0_567, 0_4567, 0_34567, 0_234567, and O 234567. One bit of signal IssueOpToRUY[23:0] is asserted to identify the selected entry. The following equations descnbe logic which generates signal IssueOpToRUY. IssueOpToRUY[23] = 0 IssueOpToRUY[22] = G[23]-K[22] IssueOpToRUY[21] = G[23]-P[22]-K[21] + ~023-G[22]-K[21] For group i where i is equal to 6 to 0: IssueOpToRUY[3*i+2] = K[3*i+2]CinGφ[i] IssueOpToRUY[3*i + l] = K[3*i + l]-(CinGφ[i] -P[3*i - -2] + ~OinGφ[i] -G[3*i+2]) IssueOpToRUY[3*i] = K[3*i] -(CinGφ[i]-P[3*i-r-2] -P[3*i-r- l] + -OinGφ[i] G[3*i+2] -P[3*i + l] + -0[3*i +2] -G[3*i + l]) Table B.31 Operand Information Broadcast Each entry generates signals Srcllnfo and Src21nfo which describe source operands for the operation contained in the entry. Srcllnfo[7:0] = {SrclBM[2:0],SrclReg[4:0]} Src2Info[7:0] = {Src2BM[2:0],Src2Reg[4:0]} If the operation is selected for issue, the entry drives signals Srcllnfo and Src2Info on operand information busses associated with the execution unit to which the operation will issue. Signals Opmdlnfo XXsrcY are the signals actually earned by the operand information bus associated with source operand Y for execution unit XX and are generated as follows. Opmdlnfo LUsrc l = IssueOpToLU ? Srcllnfo : 8'bZ OpmdInfo_LUsrc2 = IssueOpToLU ? Src21nfo : 8'bZ Opmdlnfo SUsrcl = IssueOpToSU ? Srcllnfo : 8'bZ OpmdInfo_SUsrc2 = IssueOpToSU ? Src2Info : 8'bZ Opmdlnfo RUXsrcl = IssueOpToRUX ? Srcllnfo : 8'bZ OpmdInfo_RUXsrc2 = IssueOpToRUX ? Src2Info : 8'bZ Opmdlnfo RUYsrcl = IssueOpToRUY ? Srcllnfo : 8'bZ OpmdInfo_RUYsrc2 = IssueOpToRUY ? Src2Info : 8'bZ B.32 Operand Information Match Compansons The following equation summanzes a genenc comparison: OpmdMatch_XXsrcY = (busReg[4:0] = = DestReg[4:0])- (busBM[ l] DestBM[l] + busBM[0] -DesιBM[ l ]) where "XXsrcY" is one of LUsrcl , LUsrc2, SUsrcl , SUsrc2, RUXsrcl , RUXsrc2, RUYsrcl , and RUYsrc2 and "bus" refers to signal Opmdlnfo XXsrcY which is on one of the operand information busses 552. The byte mark checking does not include BM[2] as a simplification and trade-off. BM[2] = 1 implies (BM[1] BM[0]) = 1 and thus, if busBM[2] = 1 , a match is signaled regardless of DestBM[2]. Table B.33 Operation Information Broadcast The following equations summarize readout of Opinfo fields from entries contain an operation that is issued. Accordingly to the following equations, each entry may generate a signal OpInfo LU, OpInfo SU, OpInfo RUX, or OpInfo RUY on an operation information busses corresponding to LU, SU, RUX, or RUY pipeline. OpInfo LU = IssueOpToLU ? Opinfo: 13'bZ OpInfo SU = IssueOpToSU ? Opinfo: 13'bZ OpInfo RUX = IssueOpToRUX ? Opinfo: 13'bZ OpInfo_RUY = IssueOpToRUY ? Opinfo: 13'bZ Only an entry which contains an issued operation drive a signal on a bus 551. Signals XXAdvO control these external pipeline registers in the same way as they control the intemal registers. Table B.34 Operand Selection Scan Chain Single-entry terms are for the eight scan chains LUsrcl, LUsrc2, SUsrcl, SUsrc2, RUXsrcl, RUXsrc2, RUYsrcl, and RUYsrc2. LUsrcl: -P=K = OpmdMatch LUsrcl G = LU--S1-S0 LUsrc2: -P=K = OprndMatch_LUsrc2 G = LU -S1S0 SUsrcl: -P=K = OpmdMatch SUsrcl G = SU--S1-S0 SUsrc2: -P=K = OpmdMatch_SUsrc2 G = SU -S1S0 RUXsrcl: -P«K - OpmdMatch_RUXsrcl G » RUExecl -SlSO RUXsrc2: -P=K = OpmdMatch_RUXsrc2 G = RU-Execl--Sl-SO--lmm RUYsrcl: -P=K = OprndMatch RUYsrcl G = RU -Execl -SlSO RUYsrc2: -P=K = OpmdMatch_RUYsrc2 G = RU-~Execl--Sl-SO-~Imm Group terms for 4-bit groups are formed as follows. Pgφ = P0P1P2P3 Ggφ = GO-PI P2P3 + G1-P2-P3 + G2-P3 + G3 ClnO = CIn CInl = Cln-PO + GO Cln2 = Cln-POPl + GO-PI + Gl CIn3 = CIn-P0-Pl-P2 + GO-PI P2 + G1-P2 + G2 COut = CIn-PO-Pl-P2-P3 + GO-PI -P2-P3 + G1P2P3 + G2-P3 + G3 Altematively, 3-bit or 6-bit groups could be employed. Each entry contains a logic signals which generates signals Supply ValueToXXsrcY which indicate whether the entry supplies operand srcY to execution pipeline XX. Supply ValueToLUsrcl = LUsrclchain.CIN LUsrclchain.K Supply ValueToLUsrc2 = LUsrc2cham.CIN LUsrc2chaιn.K Supply ValueToSUsrcl = SUsrclchain.CIN-SUsrclchain.K Supply ValueToSUsrc2 = SUsrc2chaιn.CIN-SUsrc2chaιn.K Supply ValueToRUXsrcl = RUXsrclchain.CIN-RUXsrclchain K Supply ValueToRUXsrc2 = RUXsrc2chaιn.CIN-RUXsrc2chaιn.K Supply ValueToRUYsrcl = RUYsrclchain.CIN-RUYsrclcha .K Supply ValueToRUYsrc2 = RUYsrc2chain CIN-RUYsrc2chaιn.K XXsrcYchain.CIN and XXsrcYchain.K are the input scan bit signal and kill term in an entry in the scan chain conesponding to operand srcY of pipeline XX Table B 35 Enable Logic for Operand Transfer Each entry has eight drivers conesponding to eight operand signals Oprnd XXsrcY to be transfened. An entry enables its drivers to supply an operation result values if signal SupplyValueToXXSrcY is asserted duπng operand selection phase. Opmd LUsrcl = Supply ValueToLUsrc l ? DestVal . 32'bZ Opmd_LUsrc2 = Supply ValueToLUsrc2 ? DestVal . 32 'bZ Oprnd_SUsrc l = Supply ValueToSUsrc l ? DestVal . 32'bZ Opmd_SUsrc2 = SupplyValueToSUsrc2 ? DestVal : 32'bZ Opmd_RUXsrcl = Supply ValueToRUXsrcl ? DestVal : 32'bZ Opmd_RUXsrc2 = SupplyValueToRUXsrc2 ? DestVal : 32'bZ Opmd RUYsrcl = SupplyValueToRUYsrcl ° DestVal . 32'bZ Opmd_RUYsrc2 = SupplyValueToRUYsrc2 * > DestVal : 32'bZ Register filed 290 enables its dnves to supply signals Opmd_XXsrcY if a scan bit output from a scan chain is set. Opmd_LUsrcl = LUsrclcham COUT ? LUsrclRegVal : 32'bZ Oprnd_LUsrc2 = LUsrc2chaιn.COUT ? LUsrc2RegVal : 32'bZ Oprnd SUsrcl = SUsrclchain.COUT ? SUsrclRegVal : 32'bZ Oprnd_SUsrc2 = SUsrc2chaιn.COUT ? SUsrc2RegVal : 32'bZ Opmd_RUXsrcl = RUXsrcl chain. COUT ? RUXsrcl Reg Val : 32'bZ Opmd_RUXsrc2 = RUXsrc2chaιn.COUT ? RUXsrc2RegVal : 32'bZ Opmd RUYsrcl = RUYsrcl chain. COUT ? RUYsrclRegVal : 32'bZ Oprnd_RUYsrc2 = RUYsrc2chaιn.COUT ? RUYsrc2RegVal : 32 'bZ Table B.36 Operand Information Signal An entry providing an operand also provides an operand status signal as follows. OpmdStat[9:0] = {State[3:0],DestBM[2:0],Type[2: l], Execl} Enable signals for operand drivers enable drivers for the operand status signal as follows. OpmdStatJLUsrcl = Supply ValueToLUsrcl ? OpmdStat : 10'bZ OprndSut_LUsrc2 = SupplyValueToLUsrc2 ? OpmdStat : 10'bZ OpmdStat SUsrcl = Supply ValueToSUsrcl ? OpmdStat : 10'bZ OpmdStat_SUsrc2 = SupplyValueToSUsrc2 ? OpmdStat : 10'bZ OpmdStat RUXsrcl = Supply ValueToRUXsrcl ? OpmdStat : 10 'bZ OprndStat_RUXsrc2 = Supply ValueToRUXsrc2 ? OpmdStat : 10'bZ OpmdStat RUYsrcl = Supply ValueToRUYsrcl ? OpmdStat : 10'bZ OprndStat_RUYsrc2 = SupplyValueToRUYsrc2 ? OpmdStat : 10'bZ Register file 290 drives an operand status bus 553 is none of the entries is selected to provide the operand conesponding to the operand status bus. The operand status signal from register file 290 are of the following form. OpmdSut[9:0] = {4'bl l l l ,3'bl l l,2'bXX, rbX} Logic which enables register file 290 to drive the operand status busses 553 is summarized as follows. OpmdStat LUsrcl = LUsrclchain.COUT ? OpmdStat : 10'bZ OpmdStat_LUsrc2 = LUsrc2chain.COUT ? OpmdStat : 10'bZ OpmdStat SUsrcl = SUsrclchain.COUT ? OpmdStat : 10'bZ OpmdStat_SUsrc2 = SUsrc2chain.COUT ? OpmdStat : 10'bZ OpmdStat RUXsrcl = RUXsrcl chain.COUT ? OpmdStat : 10'bZ OpmdStat_RUXsrc2 = RUXsrc2chain.COUT ? OpmdStat : 10'bZ OpmdSut_RUYsrcl = RUYsrclchain.COUT ? OpmdStat : 10'bZ OpmdStat_RUYsrc2 = RUYsrc2chain.COUT ? OpmdStat : 10'bZ Table B.37 Displacement Forwarding During operand forwarding stage, displacement forwarding from an entry is enabled either by the entry or by the preceding entry in scheduler 280. The following summarizes forwarding of signals Disp LU and Disp_SU to load unit 251 and store unit 252. Disp_LU = (thisOp(LU— Sl -SO -LD) + nextOp(LU--Sl -SO-LD)) ? DestVal : 32 'bZ Disp_SU = (thisOp(SU — Sl -SO -LD) + nextOp(SU - Sl -SO-LD)) ? DestVal : 32'bZ Values "thisOp" and "nextOp" identify the physical entry from which come the following signals LU, Sl, SO, and LD. Also, in the case of the first/newest entry in scheduler 280, the NextOp term is zero. Table B.38 Immediate Value Forwarding Drivers provide immediate values to register units 253 and 254 as follows. 0prnd_RUXsrc2 = (RU-Execl - - Sl -SO-Imm) ? DestVal : 32'bZ Oprnd_RUYsrc2 = (RU-- Execl - -Sl -SO-Imm) ? DestVal : 32'bZ The following equations summarizes enabling separate bus for operand stams signals. OprndSut_RUXsrc2 = (RU-Execl -- Sl -SO-Imm) ? OpmdStat : 10'bZ OprndStat_RUYsrc2 = (RU-- Execl - - Sl SO-Imm) ? OpmdStat : 10'bZ Table B.39 Data Operand Selection and Forwarding During operation selection phase 456, each entry determines whether it is in execution stage 450. "Select for data operand fetch" = SU- - S2 S1 During data operand broadcast stage, the entry containing the operation determined to be in execution stage 450 generates a data operand information signal as follows. SrcSUnfo[7:0] = {SrcStBM[2:0] .SrcStReg[4:0]} Oprndlnfo_SUsrcSt = SU- -S2 S1 ? SrcStlnfo : 8 * bZ Each entry determines from the data operand information signal whether the entry contains an operation that affects the source register of the data operand. A data operand match register in each entry latches a value OpmdMatch SUsrcSt indicating whether the entry affects the source of the data operand. OpmdMatch SUsrcSt = (busReg[4:0] = = DestReg[4:0])- (busBM[l] -DestBM[l] + busBM[0] -DestBM[ l]) where "bus" refers to Opmdlnfo SUsrcSt. Duπng operand selection phase 461. a scan chain staπing from the selected entry selects a source of the data operand. The source is the newest preceding entry which affects the source of the data operand or register file 290 if no preceding entry affects data operand. The scan chain has single- entry scan terms: - P=K = OpmdMatch SUsrcSt G = SU -- S3-S2 Group-level scan equations are the same as for other operand selection scan chains such as in Table B.34, and each entry determines from an input scan bit and a kill term for the entry whether the entry is selected. Supply ValueToSUsrcSt = SUsrcStchain.CIN-SUsrcStchain.K During data operand transfer phase 462, drivers within each scheduler entry are enabled as follows. Opmd SUsrcSt = SupplyValueToSUsrcSt ? DestVal : 32'bZ OpmdStat_SUsrcSt = SupplyValueToSUsrcSt ? OpmdStat : 10'bZ If none of the entries' drivers are enabled, drivers at output of register file are enabled as follows. Opmd SUsrcSt = SUsrcStchain.COUT ? SUsrcStRegVal : 32'bZ OpmdStat_SUsrcSt = SUsrcStchain.COUT ? : 10'bZ The data operand Opmd SUsrcSt transfened over bus 554 is captured in a register 1052 in store unit 252. During data operand transfer phase 462, control logic 520 uses the operand sutus value read. Table B.40 Load-Store Ordering Scan Chains Load-store ordering scan chains has single-entry propagate/kill (P/K) terms based on State and Type fields of each entry. For the three LdOp scan chains, the ST Type bit is used instead of the SU bit. This distinguishes the StOps which actually reference memory from LEA operations which only generate logical addresses. LUst2/LUstl/LUstO and SUld2/SUldl denote the respective scan chains for load unit 251 and store unit 252. The single-entry terms for the scan chains are: LUst2 -P=K = ST— S3<S2 + Sl-SU2_FirstAddrV) LUstl -P=K = ST--S2 LUstO -P=K = ST— Sl SUld2 ~P = K = LU— S3-(S2 + Sl-LU2_FirstAddrV) SUldl -P=K = LU -S2 The group look-ahead terms (based on groups of four) are: Pgφ = P0-P1-P2-P3 CInO = CIn CInl = CIn-PO CIn2 = Cln-P0-Pl CIn3 = CIn-P0Pl-P2 The scan bit input signals for Op quads are: CinGφ5 = 1 CinGφ4 = Pgφ5 CinGφ3 = Pgφ5-Pgφ4 CinGφ2 = Pgφ5-Pgrp4-Pgφ3 CinGφl = Pgφ5-Pgφ4-Pgφ3-Pgφ2 CinGφO = Pgφ5-Pgφ4-Pgφ3-Pgφ2-Pgφl During the second phase 462 of execution stage 460 for a LdStOp, the two/three scan bits Cin's to the entry holding the LdStOp are combined with a 24:1 multiplexer as follows: LUAges[2:0] = 3'bO SUAges[l:0] = 2 * bO for (all Ops){ LUAges[2:0] | = (LU— S3 S2 + Sl-LU2_FirstAddrV)) ? {-LUst2chain.CIN,-LUstlchain.CIN,-LUst0chain.CIN} : 3'bO SUAges[l:0] | = (SU — S3<S2 + Sl-SU2_FirstAddrV)) ? {-SUld2chain.CIN,-SUldlchain.CIN} : 2'bO }} The scan bits Cin are inverted when driven onto the global signals with the result that if a global signal is one, then the associated stage contains an older operation. Table B.41 Information from Scheduler to Extemal Logic The following summarizes the information that is read out of scheduler 280, at various times, for extemal use: During Operand Information Broadcast phase: OpmdInfo_XXsrcY[7:0], OpmdInfo_SUsrcSt[7:0], SrcYReg[4:0], SrcYBM[2:0], and OpInfo_XX[12:0] During Operand Transfer phase: OprndStat_XXsrcY[9:0], OprndStat_SUsrcSt[9:0], State[3:0], DestBM[2:0], Type[2: l], and Execl Note: XX = {LU.SU.RUX.RUY}; Y = { 1,2} Table B.42 Operation Valid Bits The following summarizes the OpV bits for issue stage of the four execution pipelines. OpV LU ss = - LUchain.COUT OpV SU Iss = - SUcham.COUT OpV RUX ss = - RUXchain.COUT OpV RUYJss = - RUYchain.COUT Table B.43 RegQp Bumping Global control logic 520 includes logic which generates signals BumpRUX/Y as follows. Included below are terms which handle what could otherwise be deadlock situations. Signal InhBumpRUX inhibits RegOp bumping if the operand forward stage is an RUX-only operation and a RegOp to be issued is also an RUX-only operation. InhBumpRUX = OpInfo_RUX(RegOp).Rl OpV_RUX_Iss pInfo_RUX_0(RegOp).Rl Signal BumpRUX is asseπed to bump a RegOp out of operand forward stage of execution unit 253 if not inhibited and one of the source operation is unissued or a LdOp in operand forward stage or a timeout signal is assert in response to the RegOp in operand forwarding stage being held up for more than a timeout count. BumpRUX = -InhBumpRUX • ( -OprndSut_RUXsrcl.State[0] + (~OprndSut_RUXsrcl .State[l] — OpmdSut_RUXsrcl.Type[l]) + ~OprndStat_RUXsrc2.Sute[0] + (~OprndStat_RUXsrc2.State[l] — OprndStat_RUXsrc2.Type[l]) + RUXTimeout) Signal BumpRUY to bump a RegOp out of the second register unit 254 cannot be inhibited but otherwise is asserted for the same reasons as signal BumpRUX. BumpRUY = -OpmdStat_RUYsrcl .State[0] + ( - OpmdSut_RUYsrcl .State[l] -OpmdStat_RUYsrcl .Type[l]) + ~ OprndSut_RUYsrc2.Sta.e[0] + ( -OpmdStat_RUYsrc2.State[l] -OpmdStat_RUYsrc2.Type[l]) + RUYTimeout Table B.44 Operand Transfer Multiplexer Control The following equations summanze the five mput select signals for each operand multiplexer. Global control logic 520 uses the operand status signal on busses 553 to select either an operand bus 554 or one of result busses 561 to 564 to provide an operand. For most operands, operand bus 554 is selected if the source operation is completed. SelOpmdBus XXsrcY = State[3] + State[2] Type[ l] For the second operand of RegOps, the operand bus is selected if the source operation is completed or the operand is an immediate value. SelOpmdBus_RUXsrc2 = State[3] + State[2] ype[ l ] + RUXsrc2Imm SelOprndBus_RUYsrc2 = State[3] + State[2] Type[ 1 ] + RUYsrc2Imm where signals RUXsrc2Imm and RUYsrc2Imm indicate the src2 operand is an immediate value. RUXsrc2Imm = (Type[l :0] = 'bl l )— Sl -SO-Execl RUYsrc2Imm = (Type[l :0] = 'bl l )-- Sl -SO- - Execl The result bus from the one of execution units 251 to 254 which would execute the source operation is selected if operand bus 554 is not selected. SelLUDestRes_XXsrcY = ~ SelOpmdBus_XXsrcY— Type[ l] SelSUDestRes_XXsrcY = - SelOpmdBus_XXsrc Y Type[ 1 ] — Type[0] SelRUXDestRes_XXsrcY = - SelOpmdBus_XXsrcY Type[ l ] Type[0| Execl SelRUYDestRes_XXsrcY = - SelOpmdBus_XXsrcY Type[ l | Type[0] — Exec l The selected operand may be invalid. An execution unit is prevented from using the invalid operand by preventing the associated operation from advancing from operand forward stage 440 to execution stage 450. Table B.45 Identification of Invalid Operands Global control logic 520 uses operand status signals from bus 553 to generate signals Opmdlnvld XXsrcY that indicate whether an operand srcY (Y = {1,2}) for an execution unit XX (XX = {LU,SU,RUX,RUY}). OprndInvld_XXsrcY = -State[l] + ~Type[l] - Sute[2] + ~State[3] -~ CHP_LUAdv2) + SrcYBM[2] — DestBM[2] + SrcYBM[l] - - DestBM[l] + SrcYBMJO] — DestBM [0] Table B.46 Hold Signal Logic Hold signals SC HoIdXXO are generated to prevent an operation from advancing to execution stage 450 if the required operands are not available. StOps are allowed to advance to execution stage 450 even if the data operand is not yet available because the data operand is not required until the second execution stage 460. However, signal SC_HoIdSU2 holds the operation in execution stage 460 if the data operand is still invalid. SC_HoldLU0 = OprndInvId_LUsrcl + OpmdInvld_LUsrc2 SC_HoldSU0 = OprndInvld_SUsrcl + OprndInvld_SUsrc2 SC_HoldRUXO = Oprndlnvld RUXsrcl + OprndInvld_RUXsrc2 - - RUXsrc2Imm + StatusInvld RUX + NonAbsync SC_HoldRUYO = Oprndlnvld RUYsrcl + OpmdInvld_RUYsrc2 — RUYsrc2Imm SC_HoldSU2 = Opmdlnvld SUsrcSt— SU2_FirstAddrV Table B.47 Status Flag Groups Standard x86 status flag bits OF, SF, ZF, PF, CF, EZF, and ECF are paπitioned into four groups which conespond to bits of signal STATUSV and field StatMod as follows. STATUSV[3] and StatMod[3] - > OF STATUSV[2] and StatMod[2] - > SF, ZF, AF, PF STATUSV[1] and StatMod[ l] - > CF STATUSVfO] and StatMod[0] - > EZF, ECF Table B.48 Status Flag Fetching Each of entries 16 to 23 generates signals Statlnfo l , StatInfo_2, SutInfo_3, and StatInfo_4 conesponding to the four flag groups and indicating the status flags and a validity bit for the four flag groups. Any one or more of signals Statlnfo l . StatInfo_2, StatInfo_3. and StatInfo_4 is used to generate signals STATUS and STATUSV if the entry is selected by a scan chain for a conesponding group, ln the following, the prefix "OPj:" indicates a field or signal form entry j. for 0 = 16:23) { OPj:StatInfo_3[ l :0] = { OPj:StatVal[7], OPj :S3 } //OF OPj:StatInfo_2[4:0] = { OPj:StatVal[6:3], OPj:S3 } //SF.ZF.AF.PF OPj:StatInfo_l[l :0] = { OPj:StatVal[2], OPj:S3 } //CF OPj:StatInfo_0[2:0] = { OPj:StatVal[ l:0], OPj:S3 } //EZF.ECF } The architecmrai status flag register generates signals FlgSutlnfo l, FlgStatInfo_2, FlgStatInfo_3, and FlgStatInfo_4, any of which are used to generate signals STATUS and STATUSV if no entry is selected by a scan chain for a corresponding group. FlgStatInfo_3[l :0] = { StatFlags[7], * bl } //OF FlgStatInfo_2[4:0] = { StatFlags[6:3], 'bl } //SF,ZF,AF,PF FlgStatInfo_l [l:0] = { StatFlags[2], 'bl } //CF FlgStatlnfo )[2:0] = { StatFlags[l :0], 'bl } //EZF,ECF The following logic represent four scan chain without look-ahead for locating an entry to provide a flag group, for (i =0,1, 2,3) { Ih indexes flag group conesponding to StatModfi] StatSellό i = OP16:StatMod[i] StatSell7_i = -OP16:StatMod[i]OP17:StatMod[i] StatSellβ i = -OP16:StatMod[i] — OP17:SutMod[i]OP18:StatMod[i] StatSell9_i = -OP16:StatMod[i]-... -OP18:StatMod[i]-OP19:StatMod[i] StatSel20_i = -OP16:StatMod[i]-... -OP19:StatMod[i]-OP20:StatMod[i] StatSel21_i = -OP16:StatMod[i]-... -OP20:StatMod[i]OP21:StatMod[i] StatSel22_i = -OP16:StatMod[i]-... -OP21:StatMod[i]OP22:StatMod[i] StatSel23_i = -OP16:StatMod[i]-... -OP22:StatMod[i] P23:StatMod[i] StatSelFlg_i= -OP16:StatMod[i]-... -OP22:StatMod[i] — OP23:StatMod[i] } The output status flag information signals are: Sutlnfo_3[l:0] = {StatSell6_3}*2 OP16:SutInfo_3[l:0] + {StatSell7_3}*2 OP17:StatInfo_3[l:0] + {StatSell8_3}*2 OP18:StatInfo_3[l:0] + {StatSell9_3}*2 OP19:StatInfo_3[l:0] + {SutSel20_3}*2 OP20:SutInfo_3[l:0] + {StatSel21_3}*2OP21:StatInfo_3[l:0] + {StatSel22_3}*2 OP22:StatInfo_3[l:0] + {StatSel23_3}*2 OP23:StatInfo_3[l:0] + {StatSelFlg_3}*2 FlgStatInfo_3[l:0] Statlnfo_2[4:0] = {StatSell6_2}*5 OP16:StatInfo_2[4:0] + {StatSell7_2}*5 OP17:StatInfo_2[4:0] + {StatSell8_2}*5 OP18:StatInfo_2[4:0] + {StatSell9_2}*5 OP19:StatInfo_2[4:0] + {StatSel20_2}*5 OP20:StatInfo_2[4:0] + {StatSel21_2}*5 OP21:StatInfo_2[4:0] + {SutSel22_2}*5 OP22:SutInfo_2[4:0] + {SutSel23_2}*5 OP23:Statlnfo_2[4:0] + {StatSelFlg_2}*5 FlgSutInfo_2[4:0] Sutlnfo_l[l:0] = {StaiSel 16 1 }-2 OP16:StatInfo_l[l:0] + {StatSell7_l}*2 OP17:StatInfo_l[l:0] + {StatSell8_l}*2 OP18:StatInfo_l[l:0] + {StatSell9_l}*2 OP19:StatInfo_l[l:0] + {StatSel20_l}*2 OP20:StatInfo_l[l:0] + {StatSel21_l}*2 OP21:StatInfo_l[l:0] + {StatSel22_l}*2 OP22:StatInfo_l[l:0] + {StatSel23_l}*2OP23:StatInfo_l[l:0] + {StatSelFlg_l}*2 FlgStatInfo_l[l:0] Statlnfo_0[2:0] = {StatSell6_0}*3 OP16:StatInfo_0[2:0] + {StatSell7_0}*3 OP17:StatInfo_0[2:0] + {StatSell8_0}*3 OP18:StatInfo_0[2:0] + {StatSell9_0}*3 OPI9:StatInfo_0[2:0] + {SutSel20_0}*3 OP20:StatInfo_0[2:0] + {StatSel21_0}*3OP21:StatInfo_0[2:0] + {StatSel22_0}*3 OP22:StatInfo_0[2:0] + (StatSel23_0}*3 OP23:SutInfo_0[2:0] + {StatSelFlg_0}*3 FlgSutInfo_0[2:0] Status[7:0] = //OF; SF,ZF,AF,PF; CF; EZF.ECF {StatInfo_3[l],StatInfo_2[4:l],StatInfo_l[l],StatInfo_0[2:l] } StatusV[3:0] = {StatInfo_3[0],StatInfo_2[0],StatInfo_l[0],StatInfo_0[0] } Table B.49 cc-RegQp Handling A signal CCDepInRUX O indicates whether a cc-dep RegOp is in operand forward stage of register unit RUX and is generated from pipeline registers containing operation information and validity bits for the operation in operand forwarding stage. CCDepInRUXJ) = (OpInfo_RUX_0(RegOp).Type[3:2] = 'b01)OpV_RUX_0 A signal UnexecCCDepInQ3 indicates whether an unexecuted cc-dep RegOp is in row 3 and is generate from type and state bits in the entries of row 3. UnexecCCDepInQ3 = OP12:(RU OpInfo(RegOp).Type[3:2] = 'b01 -Sl) + OP13:(RU OpInfo(RegOp).Type[3:2] = 'b01 -Sl) + OP14:(RU OpInfo(RegOp).Type[3:2] = 'b01 - Sl) + OP15:(RU OpInfo(RegOp).Type[3:2] = 'b01 -Sl) The following logic determines generates a signal StatV which indicates whether the status bit group required for the RegOp in operand forward stage is valid. if ( ~OpInfo_RUX_0(RegOp).Type[5]) StatV = StatusV[l] //need CF for ADC.SBB.RLCRRC Ops elseif (OpInfo_RUX_0(RegOp).Type[ 1 :0] = 'blO) StatV = StatusV[0] //need EZF, ECF for MOVcc Op else //need OF CF for MOVcc.RDFLG.DAA.DAS Ops StatV = Status V[3] Status V[2] StatusV[l] Signal StπExecCCDep keeps track of when an unexecuted cc-dep RegOp is in row 3. StπExecCCDep = CCDepInRUX O SC AdvRUXO — BumpRUX Signal UnexecCCDepInQ4 keep track of when an unexecuted cc-dep RegOp is in row 4. ®clk: if (LdEntry4 + StrtExecCCDep + SC_EAboπ) UnexecCCDepInQ4 = LdEntry4-UnexecCCDepInQ3 — StπExecCCDep— SC EAboπ Signal SC HoldStatus holds a copy of the status flag values at input to register unit RUX. SC HoldSutus = UnexecCCDepInQ4 Signal StatusInvld RUX holds RegOp execution. StatusInvld RUX = (CCDepInRUXJ)— UnexecCCDepInQ4)- - (UnexecCCDepInQ3 StatV - - NoStatMod) Signal HoldOpQ3 holds an Op quad from shifting out of scheduler row 3. HoldOpQ3 = UnexecCCDepInQ3- -(CCDepInRUXJ) StatV— NoStatMod) + UnexecCCDepInQ4 Signal RUX_NoStatMod, from the RUX unit, indicates that the operation being executed does not modify status flags. A cycle-delayed version, called NoStatMod. Table B.50 BRCOND Handling The following equations describe BRCOND handling. Reference is made below to signals DTF and SSTF which are signals indicating breakpoint and single-step traps, respectively. A signal MDD, for "multiple decode disable" can be used for debugging to prevent more than one macroinstmction at a time being inseπed into scheduler 280. BRCOND handling first determines whether a BRCOND is in row 4. Signal BRCONDj indicates whether OPj is an unevaluated BRCOND. BRCONDj = (Type=SpecOpMOpInfo(SpecOp).Type=BRCOND)— S3) where j is the entry number and Type, Opinfo, and S3 are fields of entry j. Signal BRCONDInQ4 indicates whether row 4 contains a BRCOND. BRCONDInQ4 = (BRCOND16 + BRCOND17 + BRCOND 18 + BRCOND19)-OPQ4:OpQV If a BRCOND is in row 4, the predicted condition code is (SpecOp. cc) from field Opinfo of the entry containing the BRCOND. CondCode[4:0] = {BRCOND16}*5 OP16:OpInfo(SpecOp).CC[4 0] + {BRCOND17}*5 OP17:OpInfo(SpecOp).CC[4:0] + {BRCOND18}*5 OP18:OpInfo(SpecOp).CC[4:0] + {BRCOND19}*5 OP19:OpInfo(SpecOp).CC[4:0] Values of signal CondCode[4: l] are defined as follows. (Bu CondCode[0] flips the sense.) Tme 4'bOOOO ECF 4'b0001 EZF 4'b0010 SZnZF 4'b0011 MSTRZ 4'bOlOO STRZ 4'b0101 MSTRC 4'b0110 STRZnZF 4'bθl l l OF 4'blOOO CF 4'bl001 ZF 4'blOlO CvZF 4'blθl l SF 4'bl lOO PF 4'bl lθl SxOF 4'bl l lO SxOvZF 4'bl l l l Signal CondV indicates whether status bus required for evaluation of the BRCOND are valid. CondV = switch (CondCode[4: l ]) { case 0000: 'bl case 0001 : StatusV[0] case 0010: StatusV[0] case 001 1 : Status V[0] Status V[2] case 0100: StatusV[0] case 0101 : StatusV[0] case 0110: Stams V[0] case 0111 : Stams V[0] -StatusV[2] case 1000: StatusV[3] case 1001 : SutusV[l] case 1010: StatusV[2] case 1011 : Sutus V [2] -Status V[l] case 1100: Status V[2] case 1101: SumsV[2] case 1110: StatusV[3] -SutusV[2] case 1111 : StatusV[3] -Status V[2] } Signal HoldOpQ4A is for inhibiting shifting of the Op quad in row 4 if a BRCOND is in row 4 and the condition necessary for evaluation is invalid. HoldOpQ4A = BRCONDInQ4 — CondV Signal CondVal indicates the predicted value CondCode[0] was mispredicted. CondVal = switch (CondCode[4: l]) { case 0000: CondCode[0] Λ 'bl case 0001 : CondCode[0] Λ Status[0] case 0010: CondCode[0] Λ Stams[l] case 0011 : Sutus[l] + (CondCode[0] " - Sutus[5]) case 0100: CondCode[0] Λ ( -Sums[ l] - IP - (DTF + SSTF + MDD)) case 0101: CondCode[0] Λ ( -Sutus[l] - IP -(DTF + SSTF+MDD)) case 0110: CondCode[0] A ( -Stams[0] - IP -(DTF+SSTF + MDD)) case 0111: -Status[l] - IP -(DTF+SSTF + MDD)-(CondCode[0] " Status[5]) case 1000: CondCode[0] " Status[7] case 1001: CondCode[0] * Status[2] case 1010: CondCode[0] Λ Status[5] case 1011: CondCode[0] Λ (Sutus[5] + Status[2]) case 1100: CondCode[0] Λ Sutus[6] case 1101 : CondCode[0] Λ Sums[3] case 1110: CondCode[0] * (Status[7] Λ Status[6]) case l l l l : CondCode[0] ~ ((Sutus[7] ~ Sιams[6]) + Status[5]) } where signal IP is defined as IP = SI NMIP + SI INTRP and indicates whether there are any active h/w interrupt requests. Signal SC_Resolve indicates a resolve conditional branch. SC_Resolve = BRCONDInQ4 CondV- -SC MisPred— NoStatMod— OPQ4: Emcode A register records Signal Resolved indicating resolution of a BRCOND in quad 4. @clk: Resolved = -LdEntry4-(SC_Resolve + Resolved) x86 MOVS (move string) instmctions are decoded into an emcode loop of operations. To improve the speed at which MOVS instmctions are performed, full 32-bit transfers are performed until a byte count for the loop is less than 4. A conditional BRCOND is used in the check of the count for the MOVS. Signal TermMOVS terminates the emcode loop if the move string is almost done. TermMOVS = BRC0NDInQ4 CondV— NoStatMod— SC MisPred • ((CondCode[4: l] = 'bOHO)-(OP19:DestVal[15:0] = 16 , h5) OP19:DestVal[31 : 16] = 16'hO + RUX_D) + (CondCode[4: l] = 'b0100)-(OP23:DestVal[15:0] = 16'h6)- (OP23:DestVal[31 : 16] = 16'bO + RUX_D)) //CondCode= MSTRC ... + CondCode = MSTRZ ... @clk: TeπnedMOVS = - LdEntry4 (TermMOVS + TeπnedMOVS) SC TermMOVS = TermMOVS + TermedMOVS Signal BrVecAddr from field DestVal for a BRCOND indicates the emcode or instmction vector address to be used if the branch was mispredicted. BrVecAddr[31 :0] = {BRCOND16}*32OP16:DestVal[31 :0] + {BRCOND17}*32OP17:DestVal[31 :0] + {BRCOND18}*32OP18:DestVal[31 :0] + {BRCOND19}*32-OP19:DestVal[31 :0] Signals SC OldRASPtr. SC OldBPTInfo. and SC RestaπAddr are transmitted to restaπ instmction decoder 240. A restaπ can be generated in response to a mispredicted branch or a fault. Signal SC OldRASPtr from field RASPtr of a mispredicted or faulting entry is for restoring the RAS TOS pointer. Signal SC OldBPTInfo indicates conect branch prediction table information for conecting the branch prediction table. Signal SC RestaπAddr indicates the program counter following the restaπ. SC_OldRASPtr[2:0] = OPQ4:RASPtr[2:0] SC_OldBPTInfo[14:0] = OPQ4:BPTInfo[ 14:0] SC_RestaπAddr[31 :0] = Excp Abort ? OPQ5: FaultPC : ((OPQ4: Emcode) ? OPQ4:FaultPC[31 :0] : BrVecAddr[31 :0|) Signals BrVec2Emc and BrVec2Dec indicate a restaπ is required because of a mispredicted BRCOND for the case of a BRCOND from emcode or MacDec 252. BrVec2Emc = SC Resolve — CondVal -OPQ4 : Emcode BrVec2Dec = SC Resolve— CondVal PQ4: - Emcode A register records misprediction: @clk: if (SC Resolve + SC Aboπ) SC MisPred = - SC Aboπ ( - CondVal + SC MisPred) If a BRCOND was conectly predicted, the BRCOND is marked as completed as follows. @clk: if (SC Resolve CondVal BRCOND 16) OP16:S3 = 'bl @clk: if (SC_ResolveCondVal-BRCOND17) OP17:S3 = 'bl @clk: if (SC Resolve CondVal BRCOND 18) OP18:S3 = 'bl @clk: if (SC Resolve CondVal -BRCOND 19) OP19:S3 = 'bl A BRCOND being successfully resolved may sit m row 4 for more than one cycle due to row 5 not being able to shift and thus preventing row 4 from shifting down Duπng this time, signal SC Resolve is asseπed, and one of signals BrVec2XX on bus 558 remains asseπed for the entire time (versus for just the first cycle) Instmction decoder 240 keeps restarting each cycle until signal BrVec2XX deasseπs All other associated signals such as the vector address maintain proper values throughout this time. Table B 51 Non-aboπable RegQp Handling Signal NonAblnRUX O is asseπed to indicate a non-aboπable RegOp is in RUX operand forward stage NonAblnRUX O = (OpInfo_RUX_0(RegOp) Type[5 2] = 'bl l lO) OpV RUX O Signal UnexecNonAbInQ4 is asseπed to indicate a non-aboπable RegOp is in row 4 of scheduler 280 and is generated from fields Type, Opinfo, and State of entries 16 to 19 UnexecNonAbInQ4 = OP16(RU-OpInfo(RegOp).Type[5.2] = 'bl l l0 — Sl ) + OP17(RUOpInfo(RegOp) Type[5 2] = 'bl l l0 — Sl) + OP18(RUOpInfo(RegOp) Type[5 2] = 'bl l l0 - Sl) + OP19(RUOpInfo(RegOp) Type[5 2] = 'bl l l0— Sl) Signal NonAbSync is used to hold up advancement from RUX operand forward stage if a non- aboπable RegOp is in RUX operand forward stage and not in row 4 or a preceding BRCOND was mispredicted or a trap is pending NonAbSync = NonAblnRUX O- ( - UnexecN ' onAbInQ4 + SC MisPred + "trap pending") The non-aboπable RegOp is prevented from shifting out of row 4 until it advances to RUX execution stage HoldOpQ4B = UnexecNonAbInQ4 Table B 52 Self-Modifving Code Handling Logic Self-Modifying code handling logic makes the following compansons to eliminate the possibility that code has been modified for (ι=0; l < 5, + +ι) { uit Match 1st = (STQ_LιnAddr(l l,5) = OpQι:SmclstAddr) • (STQ_PhysAddr(19, 12) = OpQι:SmclstPg); uit Match2nd = (STQ_LιnAddr(l l,5) = OpQι:Smc2ndAddr) • (STQ_PhysAddr(19,12) = OpQι:Smc2ndPg); MatchSMCfi] = (Matchlst + Match2nd) • OpQι:OpQV; } SmcHit = "STQ store is not a special memory access" • ("self-modifying code detected by DEC (fetch/decode) unit" + MatchSMQO] + MatchSMC[l] + MatchSMC[2] + MatchSMC[3] + MatchSMC[4]); Table B.53 Commitment to the Register File The following equations summarizes the register file write enable and the DestBM field and signal OpmdMatch XXsrcY modifications for each operation of an Op quad. Operation results selected to be committed are from row 4 or 5 by signal RegCmtSel. RegCmtSel = 0P23:S3 P22:S3 P21 :S3OP20:S3 - (OP23 DestBM = 0)<OP22: DestBM = 0)- (OP21 :DestBM = 0)-(OP20: DestBM = 0) OPA = RegCmtSel ? OP 19 : OP23 OPB = RegCmtSel ? OP 18 : OP22 OPC = RegCmtSel ? OP 17 : OP21 OPD = RegCmtSel ? OP 16 : OP20 Signal Cmtlnh inhibits commitment if a limit violation occurs for an operation in row 5 or if a trap is pending. Signal RegCmtlnh inhibits register commitment Cmtlnh = OPQ5:LιmVιol + "trap pending" RegCmtlnh = Cmtlnh + RegCmtSel - (OPQ4:LιmVιol + - StCmtSel[2] + SetTrapPend) Signals WrEnbli enable commitment to register file 290 if there is no limit violation in the Op quad being committed and older operations in the row are older and therefore also being committed WrEnblO = - (RegCmtSel OPQ4.LιmVιol : OPQ5 LimViol) OPA S3 WrEnbl i = - (RegCmtSel ? OPQ4:LιmVιol OPQ5 LimViol) OPA S3-OPB.S3 WrEnbl2 = - (RegCmtSel ? OPQ4:LιmVιol : OPQ5.LιmVιol) OPA S3 OPB.S3-0PC:S3 WrEnbl3 = - (RegCmtSel ? OPQ4:LιmVιol : OPQ5:LιmVιol) OPA S30PB S30PC.S3 PD:S3 Byte mark DestBM are clear the cycle in which results are committed to register file 290. @clk: if (WrEnblO) OP23:DestBM = 3'bO @clk: if (WrEnbl i ) OP22:DestBM = 3'bO @clk: if (WrEnbl2) OP21 :DestBM = 3'bO @clk: if (WrEnbB) OP20:DesιBM = 3'bO @clk: if (WrEnblO -RegCmtSel) OP19:DestBM = 3'bO @clk: if (WrEnbli -RegCmtSel) OP18:DestBM = 3'bO @clk: if (WrEnbl2 -RegCmtSel) OP17:DestBM = 3'bO @clk: if (WrEnbB -RegCmtSel) OP16:DestBM = 3'bO Signals OpmdMatch_XXsrcY are effectively masked so that register file 290 provides operands. OP23: "effective match with operand XXsrcY" = OP23:OpmdMatch_XXsrcY— WrEnblO OP22: "effective match with operand XXsrcY" = OP22:OpmdMatch_XXsrcY— WrEnbli OP21 : "effective match with operand XXsrcY" = OP21 :OprndMatch_XXsrcY— WrEnbl2 OP20: "effective match with operand XXsrcY" = OP20:OprndMatch_XXsrcY— WrEnbB OP19: "effective match with operand XXsrcY" = OP19:OpmdMatch_XXsrcY- -(WrEnblO RegCmtSel) OP18: "effective match with operand XXsrcY" = OP18:OprndMatch_XXsrc Y- - (WrEnbl 1 RegCmtSel) OP17: "effective match with operand XXsrcY" = OP17:OpmdMatch_XXsrcY— (WrEnbl2 RegCmtSel) OP16: "effective match with operand XXsrcY" = OP16:OprndMatch_XXsrcY — (WrEnbB RegCmtSel) Table B.54 Status Flag Commitment The following equation summarizes the cumulative result generation or the selection process for a status group. Similar processes are applied independently for each status group. NextStatFlags[xl :x2] = if (OP20:StatMod[x] -OP23:S3 -OP22:S3 P21 :S3) OP20:StatVal[xl :x2] elseif (OP21 :StatMod[x] OP23:S30P22:S3) OP21 :StatVal[xl :x2] elseif (OP22:SutMod[x] -OP23:S3) OP22:StatVal[xl :x2] elseif(OP23:SutMod[x]) OP23:StatVal[xl :x2] else SutFlags[xl :x2] Table B.55 StOp Commitment Signal StCmtSel indicates which of entries 23 to 16 contains the StOp selected for commitment. The oldest entry containing an uncommitted StOp is selected. StCmtSel[3:0] = priority_encode( (OPQ5:OpQV-UncmιStOp[0]) (OPQ5:OpQV-UncmtStOp[3]). (OPQ4:OpQV-UncmtStOp[4]) (OPQ4:OpQV UncmιStOp[7])) StCmtSel equals bOOOO to bOl 1 1 if entry 23 to 16 is selected. StCmtSel equals bl 1 1 1 if no entry is selected. Signal CmtMask has eight bits conesponding to the eight entnes in the last two rows of scheduler 280. Bits conesponding to the oldest entry up to the selected entry are zero, and the remaining bits are one. CmtMask[7:0] = {(StCmtSel[2:0] < 'bi l l) (StCmtSel[2:0] < 'bOOO)} Signal CmtCiaCda indicates the selected StOp is a CIA or CDA instmction. CmtCiaCda = ( ~CmtMask[7] P16:Type[2]) + ( -CmtMask[6] mtMask[7]OP17:Type[2]) + ( ~CmtMask[5] CmtMask[6] OP18:Type[2]) + ( ~ CmtMask[4] CmtMask[5]-OP19:Type[2]) + ( ~CmtMask[3] CmtMask[4] OP20:Type[2]) + ( ~CmtMask[2] CmtMask[3]OP21 :Type[2]) + ( ~Cm-Mask[l] mtMask[2] OP22:Type[2]) + ( -CmtMask[0] CmtMask[l] P23:Type[2]) Signal StCmtlnh inhibits commitment of a StOp if all commitment is inhibited, StCmtlnh = Cmtlnh + StCmtSel[2]-(OPQ4: LimViol + SmcHit — CmtCiaCda + "trap pending") Signals StCmtV and Q5StCmtV respectively indicate whether a StOp and a StOp in row 5 is ready for commitment this cycle. There is no commitment of a StOp if no StOp was selected, StOp commitment is inhibited, the selected StOp has not completed, or older StOps have not completed. StCmtV = -StCmtSel[3] — StCmtlnh CmtMask[7] + OP16:S3)- (CmtMask[6] + OP17:S3 + OP17:RU)- (CmtMask[5] + OP18:S3 + OP18:RU)- (CmtMask[4] + OP19:S3 + OP19:RU)- (CmtMask[3] + OP20:S3 + OP20:RU)- (CmtMask[2] + OP2LS3 + OP21 :RU)- (CmtMask[ l] + OP22:S3 + OP22:RU) Q5StCmtV = - StCmtSel[2] — Cmtlnh- (CmtMask[3] + OP20:S3)- (CmtMask[2] + OP2LS3 + OP21 :RU)-(CmtMask[l] + OP22:S3 + OP22:RU)- (CmtMask[0] + OP23:S3 + OP23:RU) Signal StAdv indicates whether a StOp can advance to stage 2 of the store commitment pipeline. StAdv = - STQ_FirstAddr- - DC_HoldSCl HP_AdvSC2 + CmtCiaCda Signals StRetire and Q5StRetιre indicate whether any of a row-5 StOp is commuted this cycle. StRetire = StCmtV StAdv Q5StRetire = Q5StCmtV StAdv Signal NewUncmtStOp identifies all StOps in the bottom two rows which have not been and are not being committed. NewUncmtStOp[7:0] = { (CmtMask[7] OP16:Type = ST) (CmtMask[0] OP23:Type = ST) } If a StOp is committed UncmtStOp bits are updated as follows. NextUncmtStOp[7:0] = (StRetire) ? NewUncmtStOp[7:0] : UncmtStOp[7:0] NextUncmtStOp[ 1 1 :8] = { OP12:Type=ST. OP13:Type = ST. OPI4:Type = ST. OP15:Type =ST } <g>clk: UncmtStOp[7:4] = (LdEntry4) "> NextUncmtStOp[ l l :8] : NextUncmtStOp[7:4] UncmtStOp[3:0] = (LdEntry5) ? NextUncmtStOp[7:4] : NextUncmtStOp[3:0] Signal AllStCmt indicates whether all memory-wnting StOps in row 5 have been committed or are being successfully committed. AllStCmt = StCmtSel[2] + Q5SιRetire— NewUncmtStOp[3] -... ~ NewUncmtStOp[0] Signal SC HoldSC 1 indicates whether OCU 260 believes store commitment is ready to advance to suge 2. SC_HoldSCl = -StCmtV + CmtCiaCda Store unit 252 generates a signal SUViol indicated a fault for a StOp smck in the second execution suge. An abort will be generated if the selected StOp is stuck in the second execution stage and therefore caused the fault. StAbort = - StCmtSel[2] -SU Viol • ((StCmtSel [ 1 :0] = = 00) — OP23:S3 + (StCmtSel[l :0] = = 01) — OP22:S30P23:S3 + (StCmtSel[l:0] = = 10)— 0P21 :S3-0P22:S3OP23:S3 + (StCmtSel[l :0] = = 11)— OP20:S3 P21 :S3 P22:S3 P23:S3) Table B.56 Op Quad Retirement The following equation summarizes the OCU's Op quad retirement control logic. OpQRetire = OP20:S3 P21 :S3 OP22:S3-OP23:S3-AllStCmt Signal OpQRetire may be asserted for multiple cycles for the same Op quad. This will occur when shifting of the bottom Op quad is being temporarily inhibited. When the Op quad is retired or aborted, accumulated status flags are committed. @clk: if ((OpQRetire + SC_ Abort)— OPQ5: LimViol) SutFlags[7:0] = NewStatFlags[7:0] Table B.57 LdOp Abort OCU 260 generates an abort signal Ld Abort for a LdOp in row 5 if it has not completed and all older operations have completed and been committed. LdAbort = LU2 LU Viol <OP23: (Type =LU — S3) + OP22:(Type=LU— S3)OP23:S3— CmtMask[ l] + OP21 :(Type=LU — S3) P23:S30P22:S3 — CmtMask[2] + OP20:(Type = LU — S3)OP23:S30P22:S30P21 :S3- ~CmtMask[3] ) Table B.58 FAULT OP Aboπs The following equation summarizes the OCU's FAULT operation handling logic. FltAboπ = OPQ5:OpQV-OP23:(Type=SpecOp-OpInfo(SpecOp).Type = FAULT) Table B.59 LDDHA/LDAHA Handling Logic OCU handles LDDHA and LDAHA operations when they reach entry 23 by loading the DestVal into the appropriate default handler address register. @clk: if ( OPQ5:OpQV- OP23:(Type=SpecOpOpInfo(SpecOp).Type = LDDHA) ) DefFltVecAddr[13:0] = OP23:DestVal[13:0] LdAltAddr = OPQ5:OpQV- OP23:(Type=SpecOpOplnfo(SpecOp).Type=LDAHA) @clk: if (LdAltAddr) AltFltVecAddr[13:0] = OP23:DestVal[13:0] Signal EffAltFltVecAddr provides the new altemate handler address for faults on Ops within the same Op quad as an LDAHA operation. EffAltFltVecAddr! 13:0] = (LdAltAddr) ? OP23:DestVal[13:0] : AltFltVecAddr[13:0] O 97/13199 PCΪ7US96/15741 Changing and switching between handler addresses is synchronized with the recognition of faults on sunounding operations. @clk: if (NextOPQ5:Eret-NextOPQ5:OpQV— BrAbort + LdAltAddr + ExcpAbort) FItVecMode = - ExcpAbort- - ( NextOPQ5:Eret-NextOPQ5:OpQV— BrAbort)- LdAltAddr CurFltVecAddr[14:0] = (FItVecMode + LdAltAddr) ? EffAltFltVecAddr[] : DefFltVecAddr[] OPQ refers to an Op quad field. Table B.60 Branch Target Limit Violations Handling If a valid Op quad which is tagged as having a branch target limit violation reaches row 5, OCU 260 generates an abort signal LimAbort. LimAbort = OPQ5:(OpQV-LimViol) Table B.61 Aboπ for Mispredicted BRCOND OCU 260 generates an aboπ signal BrAboπ for a mispredicted BRCOND when all operations preceding an uncompleted BRCOND in row 5 are completed. BrAboπ = OP23 : (Type = SpecOp— S3) + OP22:(Type = SpecOp- - S3)OP23:S3 — CmtMask[ l ] + OP21 : (Type = SpecOp— S3)OP23:S3 P22:S3 — CmtMask[2] + OP20:(Type = SpecOp— S3)OP23:S3 -OP22:S30P21 :S3 — CmtMask[3] The commitment of following operations is inhibited by the State of the BRCOND being not completed (i.e. - S3). Also, BrAboπ is asseπed when FltAboπ is asseπed, but this is harmless. Table B.62 Aboπ Cvcle Logic Signal ExcpAboπ indicates an aboπ when any abort condition requiring a vector address for restart. ExcpAbort = LdAbort + StAbort + FltAbort + LimAbort + TrapAbort + SCReset Signal SC EAbort also includes aborts for mispredicted BRCOND. SC EAbort = ExcpAbort + BrAbort The abort is initiated by signal SC Aboπ at a clock edge. @clk: SC_ Abort = SC EAbort Information required for the different causes of the abort are provided as follows. if (TrapAbort) { Faultld[2:0] = (DTF + SSTF) ? Oxl : 0x0 } else if (LimAbort) { Faultld[2:0] = 0x2 } else { Faultld[2:0] = LdAbort ? LU2_ViolType : SU2_ ViolType } Latch into SR4: @clk: if (ExcpAbort) { SC_FID[2:0] = Faultld[2:0] SC_SR4[31 :0] = OPQ5:FaultPC[31 :0] } Select emcode vector address: if (SCReset) { SC_VecAddr[13:0] = 0x2200 ExtEmcVecAddr = SCExtReset } else { SC_VecAddr[13:0] =(ExcpAboπ) ? CurFltVecAddr[ 13:0] : BrVecAddr[ 13:0) ExtEmcVecAddr = (ExcpAboπ) ? CurFltVecAddr[ 14] : BrVecAddr[ 14] } SC_Vec2ROM = (ExcpAboπ + BrVec2Emc) - ExtEmcVecAddr SC_Vec2RAM = (ExcpAboπ + BrVec2Emc) ExtEmcVecAddr SC_Vec2Dec = - ExcpAboπ BrVec2Dec

Claims: We claim: 1. A method for out-of-order execution of operations, comprising: selecting a first operation from a list for issue to an execution unit, wherein the first operation is first in program order of all operations which are in the list and issuable to the execution unit during a first clock cycle; advancing the first operation to an operand forward stage during which operands required for execution of the first operation are to be forwarded to the execution unit, wherein advancing the first operation to the operand forward stage makes the first operation not issuable to the execution unit during a second clock cycle; selecting a second operation from the list for issue to the execution unit, wherein the second operation is first in program order of all operations which in the list which and are issuable to the execution unit during the second clock cycle; determining whether the first operation would be held up in the operand forwarding stage for more than a threshold time; removing the first operation from operand forwarding stage if the first operation would be held up in the operand forwarding stage for more than the threshold time, wherein removing the first operation from the operand forward stage makes the first operation issuable during a third clock cycle: and advancing the second operation to the operand forward stage in response to the first operation being removed. 2. The method of claim 1 , wherein the threshold time is one clock cycle. 3. The method of claim 1 , wherein the first operation precedes the second operation in program order and the method fuπher comprises executing the second operation before executing the first operation. 4. The method of claim 1 , wherein the list comprises a sequence of entries in a scheduler, wherein each entry contains memory fields which store information conceming an associated operation. 5. The method of claim 4, wherein determining whether the first operation would be held up in the operand forwarding stage for more than a threshold time, comprises: broadcasting from a first entry, associated with the first operation, a signal identifying a source of an operand which is required for execution of the first operation; forwarding from a second entry, which associated with a third operation that alters the operand and precedes the first operation in the program order, a state signal indicating an execution stage for the third operation; determining from the state signal a mmimum time until execution of the third operation complete thereby making the operand available; and companng the minimum time to the threshold time. 6. The method of claim 5, wherein broadcasting occurs dunng the first clock cycle. 7. The method of claim 6, wherein the forwarding, determining, and companng steps occur dunng the second clock cycle. 8. The method of claim 1 , wherein the second clock cycle immediately follows the first clock cycle, and the third clock cycle immediately follows the second clock cycle 9. The method of claim 1 , fuπher comprising executing the first operation with a second execution unit 10. The method of claim 9, wherein the first operation precedes the second operation in program order and the method further compnses holdmg up until completion of the second operation if results from the first operation are required for completion of the second. 1 1. A processing system compnsing: a scheduling reservoir containing information associated with operations, an execution unu implementing a pipeline for execution of operations, and issue selection logic coupled to the scheduling reservoir and associated with the execution unit, wherein each clock cycle, the issue selection logic selects from the scheduling reservoir an entry associated with an operation which is first in program order of all operations associated with entnes in the scheduling reservoir that are issuable to the execution unit dunng the clock cycle, charactenzed by: logic for setting state fields of the entnes in the scheduling reservoir, wherein in response an entry being selected by the issue logic, the logic changes a value in a state field of the selected entry from "unissued" to "issued" thereby making the associated operation not issuable to the execution unit, and in response to determining that operands required for the operation to advance in the execution unit's pipeline will be unavailable for more than a threshold time, changes the state field from indicating the "issued" state back to indicating the "umssued" state thereby making the operation issuable to the execution unu and allowing another operation to enter the "issued" state. 12. The processing system of claim 11 , further comprising a memory subsystem which stores data and instmctions for the processing system. 13. The processing system of claim 12, wherein the processing system constimtes components of a motherboard. 14. The processing system of claim 13, wherein the motherboard further comprises a backplane bus and one or more devices on cards connected to the motherboard via the backplane bus. 15. The processing system of claim 12, 13, or 14, fuπher comprising a parallel device interface. 16. The processing system of claim 15, further comprising a pπnter connected to the processing system via the parallel interface. 17. The processing system of claim 12, 13, 14, 15, or 16, further comprising a serial device interface. 18. The processing system of claim 17, further comprising a modem connected to the processing system via the serial interface. 19. The processing system of any of claims 12 to 18. further compnsing a graphics adapter for connection of a video display to the processing system. 20. The processing system of any of claims 12 to 19. fuπher compnsing a local area network adapter for connection of a network of devices to the processing system. 21. The processing system of claim 12, fuπher comprising a disk controller for connection of a disk drive to the processing system. 22. The processing system of claim 11 , wherein the processing system constitutes a ponion of a single chip processor.

Inventors: BEN-MEIR AMOS, FAVOR JOHN G, BEN-MEIR, AMOS, FAVOR, JOHN, G.
Applicants: ADVANCED MICRO DEVICES INC, ADVANCED MICRO DEVICES, INC.
Application year: 1996
Main classification: G06F9
IPC codes: G06F9