KR19990064093A - Integrated function scheduler for irregular execution in superscalar processors - Google Patents

Abstract

The superscalar processor 200 includes a scheduler 280 that selects an operation for irregular execution, the scheduler 280 includes control logic and storage that is divided into entries 540 corresponding to the operation, and executes the execution. Use an entry to generate an operation to execution units 251 to 257 for parallel pipelined execution to provide an operand as a recorder buffer that is required for the purpose and maintains the result of the operation until the result is performed. To 257, provides a wide parallel path that minimizes pipeline bottlenecks and keeps in and out of execution units 251 to 257, and enters entries to determine when all operands required for the execution of the operation are valid. Monitors and provides the requested operands to execution units 251 through 257, the operands being in register file 290, scheduler en Li, or execution units can be obtained, the scan chain (530,532,534,536,538) from (251 to 257) is characterized in that the link with the entry identifies the operation and the operand for execution.

Description

Integrated multifunction computation scheduler for irregular execution on superscalar processors

A typical computer program is a list of instructions that produce a sequence of machine instructions or operations that the processor executes when compiled or assembled. The operations have a program order defined by the logic of the computer program, and generally try to execute them in program order. The scalar processor executes the operations in program order, which limits the scalar processor to complete one operation before completing the next operation. The superscalar processor includes a number of execution units that operate simultaneously for execution and complete multiple operations at the same time. Thus, a superscalar processor can be faster than a scalar processor operating at the same clock speed, since the scalar processor can ideally complete multiple operations per clock cycle while the processor completes one operation per cycle.

In general, a superscalar processor schedules the execution of an operation so that the operation can be executed concurrently and completes it outside of normal program order. Problems arise in irregular execution because one operation may depend on another operation in which the logic of the computer program requires that the first operation in the program be executed before the second operation. For example, an operation sometimes needs to be executed dependent on the result of a branch operation. The processor often predicts the result of the branch operation before executing the branch operation and continues execution of the operation based on the prediction. Branch predictions may not be accurate, so execution should be contemplated because wrong operations are performed. In addition, many computers require that the state of the system be known before or after the operation generates an error, interrupt, or trap; However, if the operation is performed irregularly, the operation due to an error in the program may have been completed before the error occurred. Thus, the processor must be able to avoid operations that should not be executed and be able to configure the state of the system in response to errors.

Superscalar structures attempt to achieve some conflicting goals in order to schedule operations. One purpose is to efficiently schedule to maximize the concurrent execution of the operations actually required to complete the program. Another goal is that the schedule circuit should not be complicated because it increases the difficulty and provides circuit size and cost in providing a well-defined, error-free design. Another goal is to quickly schedule the processor to run at high clock rates. There is a need for a scheduling circuit that realizes this purpose.

TECHNICAL FIELD The present invention relates to digital processor systems, and more particularly, to a method and circuit for controlling execution order of operations for maximizing processor performance.

1 is a block diagram of a computer system including a processor in accordance with one embodiment of the present invention;

2 is a processor in accordance with one embodiment of the present invention;

3 is an explanatory diagram of a format example for RISC instructions executed by an engine other than an order according to an embodiment of the present invention;

4A-4D are pipelines for four types of RISC operation in one embodiment of the present invention;

5 is a scheduler according to an embodiment of the present invention;

6 is a circuit diagram of a portion of a scheduler storage device in accordance with one embodiment of the present invention;

7 is an explanatory diagram of an example of a format for an operation and an field for an op quad stored in the scheduler according to FIG. 5;

8A and 8B are explanatory views of a scan chain using a look-ahead for quick selection;

9A-9C are explanatory diagrams of scan chains using look-threads for quick selection of operations for a second execution unit;

10 is a block diagram of an interface between an execution unit and the scheduler of FIG. 5; And

11-11C are block diagrams of processing systems of the present invention.

The same reference numbers have been used for different figures representing similar or identical terms.

In accordance with the present invention, an irregular execution engine includes a set of execution units that can operate simultaneously and a scheduler that dispatches operations to execution units. The scheduler includes an entry corresponding to the operation to be executed. Each entry includes the execution of the associated operation and the storage of the information required for the logic to pass the information to the correct execution unit if required. The operations are first dispatched according to the type and the validity of the execution unit for the operation type, and secondly in the successive program order. Thus, various types of operations are often executed outside of the normal program order. Operations of the same type can also be executed irregularly because more than one execution unit can be valid in one operation type, and remain in one execution pipeline while another execution unit completes the next operation of the same type. Can be. In addition, operations that block the execution pipeline may be pushed out of the preceding stage of the pipeline, such that one execution unit operation may be executed out of program order.

Entries in the scheduler are not limited by operation type, and the execution unit does not define a station or queue that can be blocked if the execution unit is stalled. After execution of the negligible operation, the result of the operation is retained in the associated scheduler entry and / or storage queue. The scheduler maintains the results until the compute execution unit associated with the scheduler determines that there are no faults and a branch that has not been mispredicted proceeds with the associated operation. If the computing execution unit determines that the oldest operation executed is created by sequential program execution, the result is permanent by writing to a register file, status register, or memory, and the operation ends and is removed from the scheduler. If the operation execution unit determines that it is not created by sequential program execution, the operation ends without permanent change.

In addition to the scheduling function, the scheduler also specifies the function of the reorder buffer in forced register rename. Since the physical location of the entry in the scheduler represents the program order, a tag indicating the program order of the operation is not required, and the result stored in the entry provides registers and status values at corresponding points in the program order. This eliminates the complexity required to maintain and transmit tag information between several separate executing base stations. The actual register rename during execution of the operation is not required because the scan chain directed in the appropriate physical direction in the scheduler places the preceding operation that affects the register operands required for subsequent operations.

In one embodiment of the invention, the scheduler includes a column of entries associated with pending operations. Each entry corresponds to a single operation, and each column in the entry corresponds to multiple operations, such as four operations. Organizing the scheduler into columns simplifies the scheduler structure, but the scheduling and execution of operations is independent of grouping operations into columns. In some methods, the scheduler acts as a shift register when information associated with a new group of operations is loaded into the top row of the scheduler and shifts as a group towards the bottom row of the scheduler when the older operation ends. Thus, the position of the operation in the scheduler indicates its age. Newer operations (ie, later in program order) are at the top of the scheduler, and older operations (ie, earlier in program order) are at the bottom of the scheduler.

Most operations are loaded into the top row of the scheduler, but if they can be issued to the execution unit from any point in the scheduler, they are immediately ready for execution. The status field in the entry for the operation indicates whether the operation has been issued, at a special stage in the execution pipeline, or completed. The state of an operation is independent of the position of the operation in the scheduler, but the longer the operation is in the scheduler, the greater the chance of issue and completion. In-row operations are completed at the same time so that multiple operations can be completed in each clock cycle. Thus, multiple operations can be loaded into the scheduler, and multiple operations can be removed from the scheduler at each clock cycle.

Some operations, such as conditional branch calculations and register operations that depend on state flags, are executed when the operation reaches a particular column of the scheduler. This simplifies, reduces costs, and speeds up the hardware in the scheduler by eliminating general-purpose hardware to help perform these operations in other columns. Scheduling delays are minimized by selecting columns for the execution of those operations where the operands needed to execute are likely to be valid. For example, a state flag dependent operation is processed lower at one point in the scheduler if an older operation is likely to complete the modification of the state flag value required to complete the state flag dependent operation. Additional circuitry that allows the execution of state flag dependent operations higher in the scheduler provides a minimal improvement in terms of execution rate since the required state flag will be valid if the state flag dependent operation is in the higher row of the scheduler.

The scheduler is tightly coupled to the execution unit and maintains information related to operations in the multiple execution pipeline. The scheduler issues the operation, provides the operation information to the operation unit at the requested time, maintains the result from the completed operation until the result is performed or abandoned, and sends the same result as required for the execution of other operations. . Remarkably, each scheduler entry maintains a register and state resulting from the associated operation. Thus, the scheduler implicitly implements register renaming without explicit renaming, or implements the mapping of logical registers into physical registers. Thus, the scheduler provides a single, unified structure for scheduling the execution of operations, provides the operand values required during execution, and acts as a recorder buffer in enforced register renames.

Model for Implementation and Industrial Application of the Invention

The invention is schematically described in the following order.

I. summary

II. Scheduler

A. Scheduler Loading

Static Entry Field

2. Dynamic Entry Field

Op quad field

B. Load / hift control

III. Action execution

A. Issue Stage

1.Issue Selection Phase

a. Issue Selection Scan Chains

b. Issue Selection Scan Chains For RUY

B. Operand Forward Stage

1.Operand Selection Phase

2. Operand Transfer Phase

3. Displacement Forwarding

4. Medium Value Forwarding

C. Data Operand Withdrawal

D. Register Operation Bumping

E. Load / Save Orders

F. Suspension Processing

Ⅳ. Wide Area Control Logic

A. Scheduler Information Used by External Logic

B. Wide area control function

Ⅴ. Status flags

A. Status Flag Fetch

B. Status Flag Forwarding to cc-Dep RegOps

C. Resolving Branch Expectations

Ⅵ. Synchronization of non-stoppable actions

Iii. Self-modifying code processing

Iii. Action Disposal Unit

A. Disposal

1. Disposition of register

2. Disposition of State Flags

3. Memory Record Disposition

B. Op Quad Retirement

C. Fault Handling

1. Handling of load failure

2. FAULT and LDDHA / LDAHA Op Treatment

3. Handling of Target Limit Violations

4. Invalid expected branch handling

D. A break cycle occurs

Iii. Processing system

Iii. conclusion

Attachments A: RISC86 ^TM Syntax

Appendix B: Pseudo-RTL Description

I. summary

The processor according to the embodiment of the present invention can be applied to various applications including a personal computer. 1 shows a block diagram of a computer motherboard 100 incorporating a processor 200 in accordance with one embodiment of the present invention. The processor 200 is a monolithic integrated circuit capable of executing complex instruction sets and can be fabricated using conventional integrated circuit processing such as five metal layer CMOS processing with a 0.35 μm design rule. The chipset connected to the processor 200 includes a memory controller 121 that provides an interface with the internal level-2 cache 125 main memory 122 and a local bus such as the PCI bus 155 and the ISA bus 165. Bus controllers 150 and 160 that provide an interface are included.

2 is a block diagram of an embodiment of a processor 200. Processor 200 has a system interface 122 that provides access to the address space of a computer system including main memory 122 and devices on local buses 151 and 161. In one embodiment, system interface 205 includes a 64-bit system bus with multiprocessor cache coherency that provides modified, exclusive, shared, and invalid (MESI) status and configurable bus scaling. have.

The integrated level-2 cache control logic 210 provides an interface with a private bus to external SRAM forming the level 2 cache 125. Providing a level-2 cache interface separate from system interface 210 releases the level-2 cache from the system bus / chipset, allows for faster caches, and reduces the use of system buses and cache buses. Allow for an increase in bandwidth on each bus. Level-2 cache control logic 210 further provides a configurable cache size of data and tag storage up to 2MB on multiple clock scaling and off-the-shelf burst pipeline synchronous SRAM. The level-2 cache uses a reply 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 may be, for example, pin-for-pin applicable to chipsets for processors such as Pentium.

Level-1 instruction cache 230 and level-1 data cache 220 are internal to processor 200 and are coupled to the level-2 cache and system bus through level-1 cache control logic 215. In one embodiment, the instruction cache 230 is a two-way set-associated cache that includes storage for 16 KB of instructions and additional predecode information. Data cache 220 is a two-way set-associative cache that includes storage for 32 KB of data. To provide faster operation and avoid access urges, data cache 220 uses a pipelined bank of dual-port memory that allows one write and one read per cycle.

Instructions from main memory 122 are loaded into instruction cache 230. According to one embodiment, the instructions in main memory 122 are CISC instructions from a complex instruction set, such as the standard x86 instruction set of the PC industry. The RISC command may also be referred to herein as a macro command. Up to 16 bytes of the CISC instruction are fetched per cycle. While instruction cache 230 is loaded, instruction bytes are predecoded for quick identification of macroinstruction boundaries. Predecoding adds a code bit to each byte to indicate an offset from the bike to the start of the instruction following the instruction where the instruction byte is assumed to be the first byte in the instruction.

The instruction decoder 240 executes an unconditional branch instruction, performs branch prediction for the conditional branch instruction, and converts the RISC instruction fetched from the instruction cache 230 into an operation for the execution engine 250. Execution engine 250 executes a superscalar, non-order, and reduced instruction set calculation (RISC) architecture. A single CISC instruction from the instruction cache 230 is decoded into zero, one, or several operations for execution engine 250. Multiple CISC instructions may be decoded each cycle to produce a set of RISC instructions indicating that the operation is executed by execution engine 250. The instruction decoder 240 includes a hardware decoder (MacDec) 242 for the most common RISC instructions and a vector decoder 244 for non-common and more complex CISC instructions. The vector decoder 244 includes a ROM 246, referred to herein as an Emcode ROM 246 containing a RISC instruction sequence, sometimes referred to as an MPEG. The vector decoder 244 selects an address in the encode ROM 246 according to the CISC to be decoded, and replaces or replaces a portion of the RISC instruction read from the encode ROM 246 required to convert the CISC instruction corresponding to the RISC instruction. Correct it.

3 and Appendix A illustrate an example format of a RISC instruction optimized for execution of an x86 CISC instruction and is referred to as a RISC86 instruction set. Each RISC86 instruction is one of a register operation (RegOp), a load-store operation (LdStOp), or a special operation (SpecOp). RegOp is sometimes designed as a ".cc" RegOp indicating that the RegOp modifies a status code or a "cc-dep" Reg or a "cc-dep" Reg indicating that the RegOp depends on a status code. LdStOp is further classified into a load operation LdOp or a storage operation StOp. Load medium value operation (LIMMOp) is a type of LdOp that has a different format than other LdOp and sometimes supplies a large intermediate value following LdStOp or RegOp. SpecOp includes branch operations (BrOp) and floating point operations (FpOp) with different formats. 3 and Appendix A illustrate only BrOp as an example of SpecOp. Conditional branching operation BRCOND is a type of BrOp that depends on the status code (field cc in FIG. 3).

In one embodiment of the invention, the instruction decoder 240 converts the x86 macro instruction into a RISC86 instruction (or operation). MacDec 242 translates common macro instructions into short sequences of RISC86 operations. For example, the x86 macro commands INC reg, PUSH reg, and Jcc tgt_addr are decoded into RegOp, StOp and BRCOND, respectively; ADD reg, mem macro instructions are decoded into LdOp and RegOp in a sequence; ADD mem, reg macro instructions are decoded into LdOp, RegOp and StOp in the sequence; The LEAVE macro command is then decoded into RegOp, LdOp and RegOp in the sequence.

In one embodiment, instruction decoder 240 decodes up to two x86 macroinstructions per cycle to create a set of four RISC86 operations that can be loaded into execution engine 250 in one cycle. If four sets of operations need to be completed, no-op operations will be used. If two consecutive instructions can be identified as each decoded instruction in two or less operations, they are decoded during the cycle. In an optional embodiment, up to three (or more) macro instructions may be decoded in each cycle to form a set of four (or more) operations. The vector decoder 244 is used to decode long sequences of uncommon macro instructions and RISC86 operations. Such a sequence may be longer than four operations and may require more than one clock cycle to be loaded into execution engine 250.

For an unconditional branch macro instruction, instruction decoder 240 determines the next macro instruction that is fetched for decoding and no action occurs. For a conditional branch macro instruction, decoder 240 includes branch prediction logic 248 that expects a program counter following the conditional branch instruction and generates a BRCOND that is evaluated later to determine whether the prediction is correct. Conditional branches BRCONDs may be generated even within the RISC command sequence from the MPEG ROM 246 when the macro instruction to be encoded is not a conditional branch. The MPEG ROM 246 includes predictions for respective BRCONDs used by the vector decoder 244 when generating the decoded RISC instruction sequence for the macro instruction. The expectation for BRCOND from the MPEG ROM 244 is evaluated in a similar manner to BRCOND generated directly from the conditional branch macro instruction.

The execution engine 250 includes seven execution units "251" to "257" that can operate in parallel, a scheduler 280 for issuing an operation for execution, and the scheduler 280 for disposing operation results. A combined operational disposal unit (OCU) 260 is included. Each execution unit has a corresponding action that can be executed. The load unit 251 and the storage unit 252 execute LdOps and StOps, respectively. The storage queue 270 temporarily stores data from the speculative execution of StOps by the storage unit 252. Data from the storage queue 270 is written to the data cache 220 when the StOp result is disposed as described below. Register units 253 and 254, also referred to herein as RUX and RUY, execute RegOps that normally access register file 290. Floating point unit 255 and multimedia unit 256 are optional units that perform floating point operations (FpOps) and operations for multimedia applications, respectively. In one embodiment, the floating point unit 255 and the multimedia unit 256 are omitted.

The scheduler 280 issues an operation to execution units 251 to 257, retrieves information required by various executions during execution, and deletes operation information such as a retired operation. The scheduler 280 is divided into entries containing storage and logic associated with each operation. The information in the storage of the entry describes the operation to be executed, executed or performed. In one embodiment, four sets of entries are organized into groups, which are referred to herein as rows, although the entries are not physically arranged in rows. Information related to the four operations in the row is referred to as an Op quad. The row contains a storage field and logic associated with the Op quad as a group added to the information and logic associated with each operation.

The scheduler 280 acts like a shift register in many respects. In one embodiment, scheduler 280 is six deep rows. Decoder 240 may load a new Op quad into the top row of scheduler 280 in each clock cycle. The Op quad shifts down from the top row to the bottom row where the Op quad retires. The position of the Op quad in the scheduler 280 indicates the age or place in the program order for the Op quad; However, for most of the operation, the location in the scheduler 280 is independent of the execution phase.

4A-4D show multi-stage pipelines associated with RegOps, LdOps, StOps and BrOps. Each stage in the pipeline usually requires one processor clock cycle unless the operation is maintained in one of the stages that prevents the operation in the earlier stages. The two preliminary steps 410 and 420 are common to all execution pipelines. During step 410, up to 16 bytes of the CISC instruction are fetched into the instruction cache 230 and pre-decoded to identify the instruction boundary and reduce the subsequent decoding time. During step 420, the instruction decoder 240 decodes up to three CISC instructions from the instruction cache 230 and forms an Op quad loaded into the top row of the scheduler 280.

The scheduler 280 then controls the issue step 430 and operand forward step 440 related to operations other than BrOps. While the publishing step 430 is in progress, the scheduler 280 scans its entries and issues up to six operations to the corresponding execution units 251 to 256. The scheduler 280 may also select a newer operation for publication before the older operation so that the execution is out of order and speculative. Operand dependencies are not taken into account while the issue selection is in progress. The scheduler 280 transmits the operands to the execution units 251 to 256 during the operand forwarding step 440 for the previously issued operation while the issue selection step 430 is in progress. During step 440, some operands issued to register unit 253 or 254 collide outside the pipeline to avoid long clogging of the pipeline if the required operand becomes unavailable in several clock cycles.

As shown in FIG. 4A, execution of RegOps is completed within one clock cycle, which is execution step 450. Execution step 450 of RegOps includes an ALU step 451 in which an arithmetic logic unit (ALU) in register unit 253 or 254 is executed, and a source operand of RegOp according to the type of RegOps being executed, and the result is a result. The status values from the transfer step 452 and the register unit 253 or 254 are stored back into the entry corresponding to RegOp. The result and status flags stored in the entry are subsequently disposed of in the register file 290 and the structural status flag register is disposed when it is safe or secure. After or shortly after the operation is completed, the result of the operation may be discarded and the operation may be retired by shifting the Op quad which includes the operation outside the scheduler 280. Between completion and disposal, the result and status flags from the operation are available in scheduler 280 for execution of other instructions.

4B and 4C show LdOps and StOps requiring two execution steps 450 and 460. Execution steps 450 and 460 include address calculation steps 453 for determining virtual addresses for data access, DTLB mapping steps 455 for mapping addresses for accessing data caches, and gears in entries corresponding to operations. A result transfer step is included to send the results back. As soon as the operation is completed, the scheduler 280 receives the inferential result and the result that is disposed only when it is stable or stable.

4D illustrates BrOps processing. When the instruction decoder 240 decodes the CISC branch instruction and generates BrOps, the decoder 240 determines a new program counter for the next CISC instruction to be decoded. For an unconditional branch, there is no uncertainty in the new program counter, and decoder 240 completes the unconditional branch by changing the program counter. The instruction decoder 240 includes a parallel adder for quick addition of offsets and an old program counter value for calculating the new program counter value. Instruction decoder 240 also includes a 16-entry feedback address stack on the instruction address where subsequent subroutine calls are pushed for later prediction of the instruction address after the instruction is returned.

For conditional branching, decoder 240 expects a program counter value following the conditional branch and inserts BRCOND in the Op quad into scheduler 280. In one embodiment, the branch prediction is a branch correlation process, often referred to in the art as a two-level branch prediction. An example of branch correlation processing, which is also used, is described in US Patent Application No. 5,454,117, "Configurable Branch Prediction for a Processor Performing Speculative Execution." The branch correlation expects the address of the instruction executed after the branch instruction.

Branch prediction logic 248 in instruction decoder 240 uses an 8,912-entry branch history table (BHT), with each BHT entry containing two standard history bits that indicate whether a branch is taken or not taken. The entry is indexed using a combination of four bits from the program counter (PC) and nine bits of the wide branch history, which is taken by the program execution reaching the branch as well as from the address of the branch whether or not the branch is taken. Expected from the path. This provides improved branch prediction that reduces the change to the flush scheduler 280 described below.

If the expected or modified program counter is hit in the 16-entry branch target cache of decoder 240, the next CISC instruction will be ready for decoding at the end of x86 instruction decoding step 420. Otherwise, clock cycle 424 will be required to calculate the address and to fetch the next CISC instruction for decoding.

As with all other operations, the conditional branch operation BRCOND loaded into the scheduler 280 is shifted toward the bottom of the scheduler 280 as if the old operation retired, but no issue select scan is used for BRCOND. BRCOND enters branch state evaluation step 464 when the BRCOND reaches row 4 of scheduler 280. The branch evaluation unit 257 can evaluate one BRCOND per cycle supplying that the status code cc requiring each BRCOND is valid. These required status codes will be valid when the BRCOND reaches row 4 because older operations (operations in row 4 and row 5) are likely to have been completed. If the requested status code is not yet valid, the BRCOND is congested by preventing the Op quad from shifting out of row 4. If BRCOND is congested, the Op quads on row 4 are not shifted unless one or more of the 0 to 3 rows are empty (ie not valid) Op quads. If each of the rows 0 through 3 contains a valid op quad, the instruction decoder 240 cannot load a new op quad into the scheduler 280 while the BRCOND is congested. If the shift in row 3 is stagnant because the shift in rows 4 and 5 requires an empty Op quad, the shift in rows 4 and 5 is also stagnant, in this embodiment of the scheduler 280 Only empty Op-Quads within the top row can be created.

If the branch is expected correctly, the fetch, decrypt, and execute operations will continue without interruption. If the branch was not expected correctly, the decoder 240 goes up after the BRCOND so that the decoder 240 starts to fetch and decode the correction command while later operation results are discarded and decommissioned from the scheduler 280 than the incorrectly expected branch. The decoder 240 is restarted at the other command address. Loading a new instruction into the scheduler 280 is suspended until the misexpected BRCOND is retired and the scheduler 280 is flushed. If the misexpected branch is decommissioned, execution unit 250 is flushed by invalidating all operations within scheduler 280 and execution units 251 through 257. A new instruction that is completed before all of the misexpected branches and retired before the misexpected branch is shifted out of the bottom of the scheduler row 280 and loaded into the scheduler 280 before the misexpected branch is retired All operations can be invalid because The invalidity of all actions does not require identification of the actions that must be retired, which simplifies the process. Delaying the loading of a new instruction is generally two clock cycles in an amount approximately equal to the time required for the decoder 240 to shift the misexpected branch to the bottom row and to enable and withdraw the new first instruction. There is a minimum effect on performance as it is decommissioned next time.

Execution engine 250 executes a non-stoppable operation. Non-interruptible operations cannot be performed speculatively, only when the results are safely disposed of. After the abortable operation reaches the final stage of the pipeline and is completed, all the results of the execution are stored in the scheduler 280 until the action disposal unit 260 determines to dispose of the safety of the result. In each cycle, one Op quad (up to four operations) may be disposed of and retired from scheduler 280.

II. Scheduler

5 shows one embodiment of a scheduler 280 that includes 24 entries related up to 24 operations. Each entry includes a storage element (usually flip-flop) in the scheduling store 540 and portions of logic 530, 532, 534, 536 and 538 associated with the entry. The storage element stores information relating to a running or completed operation Op waiting for execution. The operation decoder 540 receives four RISC86 operations from the command decoder 240 and loads or uses the new Op quads in the top row of the scheduler store 540. The fields in the storage 540 are shown in FIG. 7, which are related to, but not identical to, the fields related to the RISC86 instruction shown in FIG. 3. Some fields maintain the same values as the overall execution of the related operation, hereinafter referred to as "status fields". The other fields are loaded or changed later, such as when the action completes execution, and are later referred to as "dynamic fields."

The storage elements in the scheduling store 540 may look like shift registers that are six rows deep. Each line contains four entries, each associated with a RISC86 instruction. Each clock cycle is shifted down to the next row if the op quad does not stagnate in the row at if the next row is an empty row or contains an op quad shifting down. The Op quad in the bottom row (row 5) will shift out of scheduler 280 if all operations associated with the bottom row have been disposed.

6 shows one embodiment of a portion of the scheduling store 540. The portion of the scheduler store 540 shown in FIG. 6 includes a storage element for the dynamic field in the row 3 of the scheduler 280 (edge trigger flip-flop 623) and memory for the status field in the same row. Device elements (edge trigger flip-flop 643) are included. Row 3 contains similar storage elements for each bit in the dynamic field and status field shown in FIG. 6 and described below. The other rows in the scheduling store 540 are similar or identical to row 3 and are connected in series with row 3.

In Fig. 6, flip-flops 642, 643, 644 store the same status field bits in each of rows 2, 3, and 4; Stores the bit values associated with the op quad shift from flip-flop 642 to flip-flop 643, as does the op quad shift from row 2 to row 4. The wide area control logic 520 generates one signal LdEntry [i] for each row (i = 0 to 5), the shift controlling whether that row occurs. The row is overwritten on the rising edge of the clock signal CLK. For example, signal LdEntry 3 enables flip-flop 643 to either enable or disable, and signal LdEntry 4 enables or disables flip-flop 644. It makes one state. Also, if the op quad is stuck in row 4, signal LdEntry 4 is not asserted so that flip-flop 644 retains its value. The independence of the signal LdEntry [i] allows the submission of an empty Op quad entry that may be more than the congestion of the Op quad. For example, if the Op quad is stuck in row 4, signal LdEntry 3 may be asserted from row 2 such that the value OpField2 is shifted to row 3 at the rising edge of clock signal CLK (empty). A row may occur, for example, if the instruction decoder 240 cannot supply an Op quad in every cycle due to a branch target cache miss). Table B.1 in Appendix B describes the operation of the circuitry that performs the status field.

Since new data outside the scheduling store 540 is inserted into the dynamic field during the shift of the old data, the dynamic field is more complex than the state field, and the new data may or may not shift to the next row. Stay together. The signals OpFieldValue2 and OpFieldValue3 represent information associated with each of the first and second op quads in rows 2 and 3 respectively. Circuitry outside the scheduler store 540 generates signals NewValue2 and NewValue3 to change the information associated with the first and second Op quads, respectively. The multiplexer 632 changes the first Op quad by selecting whether the new information signal OpNewField2 changes to the new value NewValue2 or remains at the same value as the old value OpFieldValue2. The multiplexer 633 selects whether the new information signal New information signal OpNewField3 changes to the new value NewValue3 or remains at the same value as the old value OpFieldValue3.

Whether the dynamic field value associated with the first op quad is changed or not, the value NewOpField2 may be written to row 2 or row 3 at the rising edge of the clock signal CLK. To shift the first op quad to row 3, signal LdEntry3 causes multiplexer 613 to select signal NewOpField2 as the signal NextOpField3 that is written to flip-flop 623 at the rising edge of signal CLK. To prevent the first Op quad from shifting into row 3, signal LdEntry3 causes multiplexer 613 to select signal NewOpField3 that is written to flip-flop 23. Signal LdEntry4 and multiplexer 614 similarly select to allow the second op quad to be shifted from row 3 to row 4. Table B.2 in Appendix B describes the operation of the circuit for performing the dynamic fields.

II. A scheduler loading

The instruction decoder 240 decodes the macro instruction and sends four to the scheduler 280 each time the row (0) (top) of the scheduler 280 is empty or contains an op quad shifting to row (1). Form a set of RISC86 instructions. Emcode ROM 246 can format an Op quad, which has no operation inside it that is the actual part of the execution of the x86 instruction. This can occur because various x86 instructions have different entry points in the same code in the encode ROM 246 and the operation inside the encode ROM 246 moves the branch into the middle of the Op quad. Instructions that do not require the x86 instruction to be decoded are nulled (changed to NO-OPs). The decryption command also contains a replaceable environment for the action field. For variable replacement, the emulation environment maintains a variable environment that includes, for example, the default address and data size for the current code segment and the number of registers and the x86 instructions to be decrypted. The variable environment replaces the placeholder value in operation from the MPEG ROM 246. Environment variable substitution increases the flexibility of the MPEG ROM 246 because several environment variables change one MPEG section to perform multiple x86 instructions. The instruction decoder 240 and / or the operation decoder 510 performs variable substitution if necessary.

Within the scheduler 280, the operation decoder 510 receives the Op quad from the instruction decoder 240 and fills the storage field in the top row of the scheduling store 540. If no op quads are available in the instruction decoder 240, the operation decoder 510 creates an empty op quad when the op quad in the top row is shifted down.

7 illustrates an example of a static entry field 541, a dynamic field 542 and an op quad field 549 in the scheduler store 540. The initial values of the entry fields 541, 542 depend on the corresponding RISC86 instruction. The operation decoder 540 modifies some fields from RISC86 instructions based on other fields, derives new fields from the current fields, replaces some fields physically with other fields, and passes through unchanged minority fields. The Op Quad field is generated from information corresponding to the Op Quad entirely.

II. A.1 Static Entry Fields

In one embodiment, each entry includes a static field 541, defined as follows, with all signals acting high.

Field Type [2: 0] specifies the type of action associated with the entry. Possible types include: SpecOp referencing memory or generating a faultable address; LdOp; StOp; RegOp executable only by the register unit 253; And RegOp executable by either register unit "253" or "254". The multimedia unit 256 executes the selected type of RegOp for the multimedia application. Floating point operation (FpOps) is a type of SpecOp that is executed by floating point unit 255. Table B.3 in Appendix B describes the circuitry in the operation decoder 510 that generates the values for the filter type.

The field LD_Imm indicates whether the operation requires an intermediate value from the preceding LIMMOp. The intermediate value is large displacement if the operation is LdStOp using large displacement versus small (8-bit) displacement maintained inside the field DestVal of the entry cold. For RegOp, the intermediate value is the second operand Src2. Table B.4 in Appendix B describes the circuitry in the operation decoder 510 for generating values for the field Ld_Imm.

Fields SrclReg [4: 0], Src2Reg [4: 0], and SrcStReg [4: 0] identify the registers holding the first source operand Src1, the second source operand Src2, and the stored data operand of the operation, respectively. Has a register number. Tables B.5, B.6, and B.7 in Appendix B describe the circuitry in the operation decoder 510 that generates values for SrclReg, Src2Reg, Src3Reg, and SrcStReg.

Fields DestReg [4: 0] contain a register number that identifies the destination register of the operation. Table B.8 in Appendix B describes the circuitry in the operation decoder 510 for generating values for the field DestReg.

Fields SrclBM [1: 0], Src2BM [1: 0] and Src2BM [2] indicate that operands Src1 and Src2 should be valid for the execution of the operation. By definition, SrclBM [2] and Src2BM [2] are the same as Srcl2BM [2]. Bits 2, 1 and 0 of SrclBM [1: 0] and Src2BM [1: 0] represent bits [31:16], [15: 8] and [7: 0], respectively. Table B.9 of Appendix B describes the circuitry in the operation decoder 510 that generates values for the fields SrclBM [1: 0], Src2BM [1: 0], and Srcl2BM [2].

Field SrcStBM [2: 0] indicates whether bytes of the stored data operand are required for the performance of StOp. The bit equivalent is equal to SrclBM or Src2BM. Table B.10 in Appendix B describes the circuitry in the operation decoder 510 for generating values for the field SrcStBM.

Field OpInfo [12: 0] has additional information for an operation disposal unit (OCU) that depends on the execution unit or whether the operation is executable. The field OpInfo has three possible field definitions, depending on whether the operation is RegOp, LdStOp or SpecOp. For RegOp, field OpInFo contains: 4 bits from the RISC86 type field; 2 bits from the RISC86 ISF field; 4 bits from RISC86 Seg field; Two bits representing an effective data size DataSz for operation; And a concatenation of bits AddrSz representing the effective address size (32/16 bits) for address computation. For SpedOp, the field OpInfo contains a concatenation of 4 bits from the RISC86 type field and 5 bits from the RISC86 cc field. Table B.11 in Annex B describes the circuitry in the operation decoder 510 for generating values for the field OpInfo.

II. A.2 Dynamic Entry Field

The dynamic entry field 542 is initialized by the operation decoder 510 but can be changed while the operation is being executed. In general, each entry contains logic for changing the required dynamic fields. An entry dynamic field 542 of one embodiment is described below.

Field State [3: 0] represents the execution state of the operation for the pipeline of FIGS. 4A-4D. (S3, S2, S1 are alternative signal names for State [3: 0]). Field State decodes five possible states by shifting one field that passes four bits. The value b0000 indicates a "not issued" state; b0001, b0011 and b0111 represent operations in operand forward step, execution step 1 and execution step 2; And b1111 indicates that the operation is completed. Most of the operation enters the scheduler 280 with the field State set to "unissued" with b0000, which is changed after the operation is issued to the execution pipeline. The field State is updated (effectively shifted) when an action is issued or goes to the pipeline stage. Immediately after completion of the pipeline, the field State is set to b1111 while the operation is retiring and waiting for disposal. The field State of all entries is set to b1111 during the abort cycle. Some operations (eg, load schedule operation LDK) have an initial state field value of 1111 and have already been completed when loaded into the scheduler 280. Table B.12 of Appendix B describes the circuitry in the operation decoder 510 that initializes the field state and circuitry in the scheduler 280 that modifies the field state during execution of the associated operation.

A field Exec1 indicating a register unit 253 (not 254) is set when executing the operation and when the operation successfully issues the execution unit 253. Table B.13 shows the logic for setting and changing field Exec1.

Field DestBM [2: 0] holds a byte mask indicating that the byte in the register indicated by field RestReg is an operation modification. DestBM [2], DestBM [0] and DestBM [0] correspond to [31:16], [15: 8] and [7: 0], respectively. The field DestBM is initialized by the operation decoder 510 and may be cleared during the abort cycle. The logic related to DestBM is described in Table B.14 in Appendix B.

Fields DestVal [31: 0] hold the result of the action being executed and the result that will be disposed of in DestReg. DestBM indicates whether the byte is valid after executing the operation. The field DestVal is loaded when the operation has completed execution phase 1 or 2 (depending on the type of operation); For unexecuted operations (eg LDK), DestVal is initialized with the appropriate result. The field DestVal can be used as temporary storage before the result is saved when the operation is complete. In one embodiment, the field DestVal initially holds the median and displacement values for RegOp and LdStOp respectively, and has an optional (continuous or object) branch program counter value for BRCOND. The logic related to the field DestVal is described in Table B.15 in Appendix B.

Field StatMod [3: 0] holds a state group mark indicating that the state group flags an action modification. The 3,2,1,0 bits correspond to the flag bit groups {EZF, ECF}, OF, {SF, ZF, AF, PF} and CF, respectively, where the flag bits EZF, ECF, OF, SF, AF, PF and CF are also modified by RegOps. The field StatMod is all zeros for non-RegOps and is cleared during the abort cycle. The logic related to the field DestVal is described in Table B.16 in Appendix B.

The fields StatVal [7: 0] hold the status result value of the operation to be disposed in the status register EFlags. StatMod indicates that the flag group was affected after execution. StatVal is important only for RegOps; This is the effect of StatVal. StatVal is loaded when RegOp completes execution step 1. The logic associated with the field StatVal is described in Table B.17 dp of Appendix B.

Field OprndMatch_XXsrcY where "XX" is LU, SU, RUX or RUY and "Y" is 1 or 2-additional memory for transmission information passing between two pipeline stages in contrast to greater global importance Device element. Table B.18 in Appendix B describes the logic that controls the field OprndMatch_XXsrcY.

Field DBN [3: 0] holds four data brutepoint status bits Bn (n = 0 to 3) for LdStOp. This field is initially all zeros and a breakpoint from the appropriate unit is recorded for the next trapping when the next associated LdStOp is executed. The logic associated with fields DBN [3: 0] is described in Table B.19 of Appendix B.

II. A.3 Op Quad Field

Each row in the scheduler 280 includes four entries plus an Op quad field 549 associated with the Op quad as a whole. Listed below is a further Op quad field 549 shown in FIG. The operation decoder 510 initializes the Op quad field. Most Op quad fields are static. Some Op quad fields are dynamic, and the logic in each row in scheduler 280 changes the Op quad fields as needed.

Field Emcode indicates whether the Op Quad is from MacDec 242 or Vector Decoder 244 (i.e., ROM ROM 246), and Table B.20 describes the setting of Field Emcode.

Field Eret indicates whether it is an MPEG op and marked as the last op quad in a series of op quads representing a complex macro instruction. Table B.12 describes the logic for setting the field Eret.

Field FaultPC [3: 0] holds the logical macrocommand fault program counter value associated with the first operation in the row. The action disposal unit 260 uses the field FaultPC when processing the fault execution. Table B.22 describes the logic that configures the field FaultPC.

Fields BPTInfo [14: 0] hold branch prediction table-related information when an op quad occurs. The field BPTInfo is defined only with MacDec-generated Op quads containing BRCOND. Table B.23 describes the logic for setting this field BPTInfo.

Fields RASPtr [2: 0] hold the pointer to the top of the feedback address stack when the op quad occurred. The field RASPtr is defined only with MacDec-generated Op quads containing BRCOND. Table B.24 describes the logic for setting the field RASPtr.

The field LimViol indicates that the Op quad is a decoding of a transmission control command detected on the target address where a code segment restriction violation is detected. For most rows, the field LimViol is static. The field LimViol is loaded within row (1) and summarized in Table B.25 of Appendix B.

Field OpQv indicates that the row contains valid Op quads, and indicates that wide area logic 520 uses the field OpQv when controlling the shift of the Op quad. Invalid op quads may be overwritten if the op quad under scheduler 280 is congested. Fields in a row containing an "invalid" Op quad have the same value as the interrupted Op quad, which may be invalid as a result of the abort. Table B.26 in Appendix B describes the logic that controls the field OpQv.

Fields Op1I, Op2I and Op3I hold counts (1, 2 or 3) of the number of macro instructions represented by the Op quad and are used as count retirement instructions.

Fields Ilen0 and Ilen1 hold the length in bytes of the first and second (if present) macroinstructions represented by the Op quad and are used to determine the instruction address at which the fault occurs.

The fields Smc1stAddr, Smc1stPg, and Smc2ndPg hold the first and second (if more than one page instruction is in the Op quad) addresses covered by the operation in the Op quad and are used to detect self-modifying codes.

II. B load / shift control

As described above, the scheduler 280 manages 24 entries in a shift register (or FIFO buffer) containing six rows. The scheduler 280 is not as robust as the shift register where each row has independent shift control (actually a load control signal LdEntry [i]). The op quad can shift down to the next row as long as the next row is empty or empty (and the preceding op quad can shift down from this to this row). The Op quad always shifts down to the higher numbered row if space is available. Ideally, each Op quad will shift down one row at each clock cycle at the clock cycle boundary.

For most of the operation, the location in the scheduler 280 is independent of the pipeline stage for the operation. In addition, most operations shift down into the scheduler 280 even if there is congestion in the execution pipeline. Two exceptions are status flags in the bottom row of the scheduler 280 and actions that depend on which action. An operation that depends on the status flag has a step in which the operation must be executed in a particular row of scheduler 280 so that it does not shift until the step is completed. Operation in row 5 prohibits the shift or retirement of Op quads from row 5 until all operations in row 5 are completed and disposed.

Table B.27 of Annex B shows the wide ranges of generating signals SchedFull and SchedFull indicating whether LsEntry5 and scheduler 280 can adopt a new op quad at the end of the current cycle from the signals LdEntry0 controlling the shift in scheduler 280. The circuitry within the control logic 520 is described.

III. Action execution

Physically, the scheduler store 540 is a storage structure that holds state values for operation. In addition to the storage, the scheduler 280 includes logic that operates at the state value while the operation is executing. In terms of control, scheduler 280 is a pipelined data path that generates control information for the execution of an operation through the processing pipeline and handles the execution results. The scheduler storage and state changes are synchronized to the system clock, i.e., all state changes in the scheduler 280 are edge-triggered as described in relation to (at least logically) all storage elements in the scheduler 280 (at least logically). Is on the rising edge of the system clock to become a flip-flop. From a logical point of view, every state sequence inside scheduler 280 is essentially a single cycle. State change decisions are made in each cycle based on machine state during the cycle.

The structure of the scheduler 280 reflects the pipelined nature of the operation execution. The logic in the scheduler 280 (and each corresponding entry) can be divided into several, mostly independent chunks of logic, each directly associated with a particular processing step of the type of a given operation or execution pipeline. . From the point of view of a particular processing pipeline, the chunk of scheduler logic associated with each step provides key control information for determining the processing performed within that step and when the step completes successfully. In terms of observing a given step through all processing pipelines (at least the first combination of steps), very similar chunks of logic perform the same function for each pipeline or for each action source operand in each pipeline.

4A-4D show pipeline timing for four operation types. For this type, the operation is loaded into the scheduler 280 after the instruction decoding step 420. BrOp is completed in a separate evaluation step 490 that occurs when BrOp reaches row 4 in scheduler 280. RegOps, StOps and LdOps pass through three or four stage pipelines and change correspondingly between the four or five states. Fields State [3: 0] within a scheduler entry track or represent the state of the action associated with that entry.

Op issuance step 430 and operand forward step 440 of FIGS. 4A and 4C are common to all RegOps, LdOps, and StOps described below.

Operand forward step 430 is followed by the execution step. RegOps has only one execution step 450 because register units 253 and 254 perform all RegOps in a single cycle. Moreover, once RegOp enters execution step 450, it always completes successfully and exits step 450 at the end of its clock cycle. LdOps and StOps have two execution steps (450,460), which include address computation (453), segment and page translation (and protection checks) and data cache mapping (455), and result transfer (462). Occurs during. Unlike RegOp, LdOps and StOps may be congested for any period within one of steps 450 or 460. Most congestion of LdOps (most significant data cache and data transformation look-aside buffer (DTLB) miss and fault) is applied to the last step 460. Congestion in step 450 results from misaligned memory references and occupying step 460 and is blocked by operation prior to completion.

The scheduler 280 controls pipelines created by execution engines such as the load unit 251, the storage unit 252, the register units 253 and 254, the floating point unit 255, and the multimedia unit 256. One embodiment of the present invention includes register units 253 and 254, a load unit 251 and a storage unit 252. It is an apparatus according to the disclosure herein to apply one aspect of the present invention to a processor with more or fewer execution units. For example, in one embodiment including the multimedia unit 256, the multimedia unit 256 is issued with an operation for the multimedia unit 256, an operand forwarded, and the result used for the register unit 253. It may logically be considered part of the first register unit 253 to be transmitted using a circuit.

In one embodiment, floating point unit (FPU) 255 has its own independent register file and disposal unit; The scheduler 280 includes a scan chain that selects FpOps for publication to the FPU 255. The scheduler 280 issues an FpOp and forwards the operand to the FPU 255. Execution of the FpOp affects only the registers in the register file associated with the FPU 255 so that the scheduler 280 does not require a result from the FPU 255. The FPU 255 may be a signal where FpOp is completed immediately, long before FPU 255 actually completes or disposes of the FpOp. OCU 260 discards and retires the FpOp from scheduler 280 without changing anything.

Each of the register units 253 and 254 provides a pipeline referred to as an RU pipeline or a RUX or RUY pipeline to distinguish between the register unit 253 and the register unit 254. Each RU pipeline has three stages, referred to as issuance stage 430, operand forward stage 440, and execution stage 450. The load unit 251 and the storage unit 252 each provide LU and SU pipelines with the following four stages: issue stage 430, operator forward stage 440 and execute stage 450,460. As described above, the State field represents the five stages of the operation using " one shifting / increment field " decoding to indicate the current pipeline stage of the associated operation and the operation whose pipeline is completed.

The scheduler 280 has main control of the issue step 430 and the operand forward step 440. The processing inside the issue and overland forward phases 430 and 440 is divided into two phases per phase, which typically occurs during the first and second half of the system clock cycle. The issue step 430 includes a issue select step 441 and a broadcast step 432. Operand forward step 440 includes an operand selection step 441 and an operand sending step 442.

During the issue selection step 441, the scheduler 280 selects the next operation entering each of the pipelines. In one embodiment, four operation choices occur immediately, for example for the LU, SU, RUX, and RUY pipelines. During the broadcast step 432, information about the operands of each selected operation is broadcast to all scheduler entries and external logic.

During operand selection step 441, scheduler 280 uses the information from broadcast step 432 to locate the operand (up to 2 * "number of execution units" operand). The source of the operand may be a register file 290, scheduler store 540 or result bus 561, 562, 563 or 564 of execution units 251, 252, 253 or 254. Scheduling store 540 includes information about fields for intermediate values, undisclosed results, and operations that are earlier but not completed within the program order. The resulting bus of the execution unit becomes the source of the operand if the execution unit completes an operation that affects the required operand. The scheduler 280 also determines the status of each operand value, i.e. determines whether a valid value is actually available from the desired source. Based on this information, the scheduler 280 determines whether the progress of operation within the operand forward step 440 is the execution step 450. Progress is independent of each pipeline. Only explicit operand dependencies force the order on which the action is executed. Except for such dependencies, various operation types are processed through each pipeline in any order for other types of operations.

During the operand forward step 442, the scheduler 280 sends the operand value on the operand bus 554 from the desired source to the execution units 251 through 254. As shown in FIG. 5, there are nine operand buses 554 in the embodiment, eight of which provide operand values for operation within the operand forward step. Embodiments with more enforcement units, such as those with floating point unit 255, may have more operand buses. Operand transfer occurs regardless of whether the operand value is valid or not. If the operand value is valid, the associated action does not precede execution step 450 such that the execution unit does not use an invalid operand.

During operand transfer step 442 of LdOps and StOps, displacement forwarding 443 transfers the displacement operands to load unit 251 and storage unit 252 (one in each unit) via displacement bus 555. The displacement operand is a 32-bit value from the scheduler entry. Selection of the source entry for the displacement occurs during operand selection step 441.

Once LdOp or StOp enters execution step 450, load and storage units 251, 252 latch on the associated displacement and operand values and retain them while operation is maintained within step 450. Scheduler 280 has limited control of the pipeline execution steps 450 and 460. In steps 450 and 460, the scheduler 280 keeps track of the status of the operation and captures the result register and status values. Address calculation 453 in execution step 450 calculates the address accessed by LdStOp. If the address and data size for the LdStOp allow data access to cross the boundary between entries in the data cache, the LdStOp will be referred to herein as misaligned. The misaligned LdStOp is divided into two data accesses: the second access stagnates at execution step 450 while the first access precedes execution step 460. The status field of the scheduler entry associated with the misaligned LdStOp indicates the execution phase of the second access.

In addition to the four step process for obtaining the source operand to start execution, the scheduler 280 performs a similar four step process for obtaining the data operand for StOp; However, the data operand is obtained for the StOp in SU step 460. The process for supplying the stored data is synchronized with the steps 450 and 460 of the StOp and the operation selection step 456 to identify the StOp in the execution step 450, the broadcast step of transmitting information describing the source of the data operand ( 457, a data operand selection step 461 and a data operand transmission step 456. Essentially, the stored data operands are fetched in parallel with the StOp execution; The actual data value is obtained and sent to the storage queue 270 when the StOp is complete. Completion and exit step 460 corresponds to creation of storage, which is the physical address from the queue entry and address calculation 453 for the StOp and DTLB mapping 455 based on the data selected in step 461. If a valid data operand or physical address is not yet available, the StOp remains at step 460.

While a chunk of scheduler logic 530, 532 is involved in issuing operations and operator forwarding, an entry contains a chunk of logic 534 that is involved in order load and store operations. Only in some executions an order must be maintained between operations due to register dependencies, and a limited execution order is also maintained between LdOps and StOps due to memory dependencies (eg, LdOps cannot be freely executed before older StOps). Load-storage orders are authorized by StOp, such as the Check Instruction Address (CIA) and Check Data Address (CDA) operations, which reference the StOp and memory that access the memory and / or generate a faultable address, but the LEA (Load Effect Address) It is not applied as an operation. Since all LdOps reference memory, no LdOps are excluded from the load-storage order.

The load-storage order is placed in step 460 of two execution pipelines where LdOp or StOp in step 460 is maintained until the operation is safe. Until step 460, no order is maintained between the LU and SU pipelines. Moreover, LdStOp can also do anything other than order when memory independence becomes "proofed" by comparing the partial address with the older LdStOp. The storage queue 270 performs address comparisons related to dependency checking but does not require a scheduler to support determining the relative age of LdOp and StOp in the LU and SU execution pipes. Only appropriate address comparisons are considered in determining whether a given LdOp or StOp is complete.

The load-store order logic 534 includes logic related to the LU pipeline and logic related to the SU pipeline. Logic associated with the LU pipeline determines the age of any LdOp in the LU stage 460 with respect to any StOp in the SU stage 450 or 460 and the other StOp. Logic 534 generates three signals, SC_SU2OLDER, SC_SU1OLDER, and SC_SU0OLDER, on bus 556 to determine whether the StOp in SU stage 460, 450 or elsewhere is older than the LdOp in LU stage 460. Indicates. The logic associated with the SU pipeline determines the age of any StOp in the SU step 460 with respect to which LdOps and other LdOps in the LU step 460 and generates two signals, SC_LU2OLDER and SC_LU1OLDER, such that any LdOps is in step 460. It is older than the StOp.

Scheduler 280 further includes status flag processing logic 538 associated with obtaining and using a flag or status code (cc) value. Three relatively independent areas of functionality are included: fetching status flag values for state-independent RegOp executed by register unit 253, fetching status flag values for resolution of BRCOND by branch evaluation unit 257, and Uninterruptable RegOp synchronization prior to BRCOND.

The RUX execution unit executes a state-independent (“cc-dep”) RegOp and requires a state operand value at the same time as the register operand value, ie at the end of operand forward step 440. CC-dep RegOp cannot precede execution step 450 until it reaches row 3 and remains in row 3 until a valid status code is reached. Unlike retrieving a register value, state retrieval processing is not pipelined and occurs during one cycle, i.e., the entire RUX operand forward step 440. Moreover, the same logic 538 fetches the status flag values so far for both cc-dep RegOp and BRCOND. For cc-dep RegOp, the status code passes to execution unit 253 while the status value that RegOp needed was validated. If a valid value for all required status flags is not yet available, RegOp is stagnated in operand forward step 440 (same as if the register operand value is not yet available).

BRCOND does not require any actual execution. Instead, while BRCOND is outstanding (and before reaching the bottom of scheduler 280), BRCOND is resolved to be correctly expected or not. BRCOND is solved on demand at rates up to one BRCOND per cycle. When BRCOND reaches row 4, status flag processing logic 538 uses either the valid status flag for evaluation of the BRCOND is valid from register file 290 or if the operation is older than the BRCOND. Check to determine if it is possible. Flag processing logic 538 may, if necessary, determine whether an older operation of supplying a status flag requiring evaluation of the BRCOND has been completed. If the value for the requested state flag is not yet available, the solution of BRCOND is stagnated by prohibiting the shift of the Op quad containing the BRCOND. When the status flag value requesting the next outstanding BRCOND becomes available, status flag processing logic 538 evaluates the branch flag value to determine whether the status code specified inside the BRCOND was correctly expected. Pass through unit (257). If BRCOND is incorrectly expected, a restart signal is asserted to begin fetching the instruction and to begin decoding the portion of instruction decoder 240 (FIG. 2) at the modified branch address. If the action is expected correctly, nothing happens.

The resolution of BRCOND is important for the execution of a nonstoppable RegOp. Execution of an uninterruptable RegOp results in a change that cannot be interrupted or cannot be made. In addition, RegOp that is not interruptable until RegOp is safe is prohibited from entering execution step 450. This requires that all preceding BRCONDs be resolved and determines whether the non-interruptable RegOp was correctly expected before it could precede execution step 450. Subsequently, while it is found that any preceding BRCOND remains unresolved or incorrectly expected, the non-stoppable RegOp stagnates within operand forward step 440. If the preceding BRCOND is expected correctly, the delay is temporary; If the preceding BRCOND is incorrectly expected, the RegOp will stall until the last interrupt cycle flushes the scheduler 280.

Vector decoder 244 generates a non-stoppable RegOp from MPEG ROM 246. In the ROM ROM 246, there is no operation allowed within the Op quad immediately prior to the Op quad containing the non-stoppable RegOp among the dependent operations given as a result of the non-stoppable RegOp. Further, when the non-stoppable RegOp is executed in row 4, there is no operation in row 5 that has a dependency granted on the non-stoppable RegOp, and that is granted on the non-breakable RegOp. All older operations with dependencies are retired so that when the non-interruptable RegOp is executed in row 4, all older operations that had a given dependency on the non-interruptable RegOp are retired and the non-interruptable RegOp Is completed before is executed in row (4).

III. A Issuance Step

The scheduler 280 performs the issue selection and broadcast steps 431, 432 in parallel for each execution pipeline requiring an issue scan and an operand. In one embodiment, the issue step operation is performed in parallel for the load unit 251, the storage unit 252, the register unit 253 and the register unit 254.

III. A.1 Issuance Selection Steps

In each cycle, scheduler 280 attempts to select an operation for publication to each unit capable of parallel execution. In one embodiment, scheduler 280 chooses to issue LdOp, StOp and two RegOp to LU, SU, RUX and RUY pipelines. For issue selection step 431, scheduler 280 scans all entries in scheduling store 540 with an "order" from the oldest operation to the newest operation and for publication based on the field State and Type of the entry. Select an action. The issue selection 431 does not take into account register states or memory dependencies that are placed on each other. This simplifies the issue selection step and allows the issue selection step 431 to complete quickly for the relatively large store 540.

Issuance options are independent of each other and simultaneously in the four processing pipelines. For each pipeline LU, SU, and RUX, the next issued action (indicated by the State field) that the pipeline can execute (indicated by the Field Type) is selected. In other words, the next issued LdOp is selected for the load unit 251, the next issued StOp is selected for the storage unit 252, and the RegOp not issued next is selected for the register unit 253. do. For register unit 254, RegOp following the RegOp selected for pipeline RUX is selected. Conceptually, the issue choice for pipeline RUY depends on the issue choice for RUX; Physically, however, the issue selection for RUY is performed in parallel with the issue selection for RUY.

For the scan, each scheduler entry issues a 4-bit IssuableToxx (ie one bit in each pipeline) indicating whether the associated operation is suitable for the current publication selection with pipeline xx where xx is LU, SU, RUX or RUY. do. The issue selection process for pipeline xx scans from the oldest scheduler entry to the newest scheduler entry to find the entry with the set of bits IssuableToxx. For pipeline LUs, SUs and RUXs, the first action in which the desired set of bits IssuableToLU, IssuableToSU or IssuableToRU is found is selected one for publication to pipeline LUs, SUs or RUXs. The issue selection for pipeline RUY selects the first action with IssuableToRUY following the action selected for pipeline RUX.

Actions suitable for issue selection are immediately loaded into the scheduler 280, ie, actions may be issued during the first cycle in the scheduler 280. In this case, only the Type bit and bit S0 need to be valid at the beginning of the cycle. All other fields in the entry may occur as late as the end of the issue selection step 431 (ie, half a cycle later) and need only be valid inside the scheduler entry for the broadcast step 432.

If the operation selected for publication does not precede operand forward step 440, the operation remains unissued and during the next clock cycle, the operation will probably compete for publication and be reselected.

III. A.1.a Issuance Scan Chain

In one embodiment of the invention, the scheduler 280 scans the operation using a scan chain formed from the logic block associated with the entry. Each scan chain is similar to carrying a chain as used in some adders. In the issue select scan chain for the load unit, the storage unit or the register unit, the "scan" bit Cin entered as the oldest entry clears the scan chain until a logic block within one of the entries removes the scan bit. Is propagated logically. If the entry relates to the desired type of operation (ie IssuableToxx is declared), the entry removes the scan bit. In order to scan the operation to be issued to the register unit 254, a scan bit is logically generated by an entry associated with the operation to be issued to the register unit 253, the scan bit being issueable to the register unit 254. It is propagated until removed by the entry associated with the operation. The entry for removing the scan bit asserts itself as an entry associated with the operation to be issued to execution unit xx by asserting signal IssueOpToxx. Thus, the selected entry can take appropriate action requiring broadcast step 431. If the scan bits for execution unit xx are propagated through all entries that are not removed, then there is no entry in scheduler 280 related to operations that can be issued to unit xx, and no operations are selected for publication.

While scan chains in which scan bit signals propagate in series through every single entry in scheduler 280 are relatively simple, faster performance may be required. Look-ahead techniques similar to those used in traditional Generate-Propagate-Kill transport chains can be applied. One look-ahead technique combines entries into groups, each group generating, propagating or removing scan bits. The look ahead is faster because the group occurrence, propagation and removal terms are determined in parallel from a single entry term and whether a scan through the group can be determined without propagating the signal through every entry in the group. By combining successive combinations of group terms, no scan bit signal propagation actually occurs because the entire scheduler store forms a single group.

For the LU, SU, and RUX scan chains, the single-entry that removes the term K is the signal IssuableTcXX. The occurrence terms G are all zero, and the propagation term P is the whole of the related K terms. Table B.28 shows the single-entry terms for the LU, SU, and RUX scan chains. Table B.29 in Appendix B describes the group terms Pgrp and Kgrp used in the Issue Selection Scan Chain for Pipeline LU, SU, and RUX.

8A and 8B show logic 800 performing part of a RUX scan chain using a look-ahead group of six entries. More or fewer groups of entries may be used, but 6 entries per group divides 24 entries into four quadrants and reduces the number of wires used to process the group term. As shown in Fig. 8A, each quadrant has an associated NOR gate 810,812 and a NAND gate 814 that operate together like a six-input OR gate and the group removal signal Kgrp3, for quadrant 3,2,1 or 0, Issue Kgrp2, Kgrp1 or Kgrp0. The input for NOR gates 810, 812 is the signal IssuableToRUX, which is the single-entry that removes the term for pipeline RUX. The scan chains for pipeline LUs and SUs are the same except that the respective signals IssuableToLU and IssuableToSU are input in place of IssuableToRUX.

The issue selection scan is made according to the physical order of entries in the scheduler 280, from the oldest entry to the newest entry. Quadrant 3 contains the oldest entry. If signal Kgrp3 is asserted, one of the above operations in quadrant 3 will remove the scan bit and an operation from quadrant 3 will be issued. Buffer 823 selects quadrant 3 by asserting delayed signal IssueQuadrant [3]. If the signal Kgrp3 is not asserted, the scan bits can be propagated through the group 3, but the operation in quadrant 2, 1 or 0 is also selected. If signal Kgrp2 is asserted and signal Kgrp3 is not asserted, NAND gate 822 asserts signal IssueQuadrant [2]. Similarly, if the scan bit can propagate to quadrant 1 or 0 and the group remove signal Kgrp1 or Kgrp0 is asserted (ie, the group removes the scan bit), then the NAND gates 821,820 are signal IssueQuadrant [1] and IssueQuadrant. Each [0] is declared. If there is no group removal signal Kgrp [3: 0] declared, then no action is selected for publication.

8B shows logic 850 to select an operation from quadrant 0 when the signal IssueQuadrant [0] is asserted. Four circuits are similar to logic 850, one for each quadrant operating in parallel. Since entry 5 is the oldest entry in quadrant 0, entry 5 is selected and quadrant 0 is selected for publication if it is possible to issue to pipeline RUX. If IssueQuadrant [0] is declared and IssuableToRUX [5] is asserted, AND gate 865 asserts signal IssueOpRUX [5] to indicate entry 5 containing the selected operation. AND gates 860 to 864 correspond to entries 0 to 4 and assert each bit in signal IssueOpToRUX [0: 4] to enable the selected action to be issued to RUX and the old action in quadrant 0 to RUX. Identifies when there is nothing. NOR gates 870 through 873 assert a signal to each NAND gate 860 through 863 to indicate that there is no such old entry that can be issued to RUX.

As an alternative to the circuit 800, 850, logic to perform the equation of Table B.29 in Appendix B may be used.

Logic 800 of FIG. 8A generates the next signal IssueQuadrant [3: 0] after three gate delays from the input of signal IssuableToRUX [23: 0] even if the selected entry is in quadrant 0 and the last quadrant is searched for. do. Without the look-ahead technique, scan bits must propagate throughout the scheduler when no action is selected. In one embodiment this is about 24 or more gate delays. Also, look-ahead scan chains are usually faster than serial scan chains as scan bits pass through every entry.

III. A.1.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 similar to conventional occurrence, propagation and elimination terms. The O term ensures that only one action is selected. The single-entry that generates the term G for entry i is the signal IssuableToRUX [i] and the term O is equal to the term G. The single-entry that removes the term K for entry i is the signal IssuableToRUY [i] and the P term is the total amount of the related K term.

Look-ahead techniques may be used within the issue selection for pipeline RUY. Conceptually, for the RUY scan chain, the scan bit is issued by the entry containing the operation selected for publication to RUX and eliminated by the next new operation that can be issued to pipeline RUY. If an entry in the group generates a scan bit and the entry for removing the scan does not appear in the group, the group generates an output scan bit. If each entry in the group propagates the scan bit, the group generates a scan bit. Once the generated O term suppresses the newer entry from the generation of a new scan bit, the group O term is generated if any entry in the group generates a single-entry O term. The equations in Table B.30 of Appendix B summarize the logic of generating group terms from single-entry terms in the RUY scan chain.

9A-9C illustrate an issue select scan chain for pipeline RUY that divides scheduler 280 into eight three-entry groups for the first time. In FIG. 9A, the generation group term Ggrp [7: 1], Pgrp from the logic block 910 and the single-entry signals G [23: 3] and O [23: 3] that implement the logic shown in Table B.30. [7: 1] and Ogrp [7: 1]. The newest group, the group term for entries 0 through 2, is not necessary for the reasons described below. The group terms are combined in three steps to form the terms for the larger group. Circuit 900 occurs for groups containing the oldest three, six, nine, twelve, fifteen, eighteen and twenty one entries group terms such as G_7, G_67, G_567, G_4567, G_34567, G_234567, and G_1234567. Occurs.

The first step in circuit 900, including logic block 920, combines group terms from adjacent groups of three entries to generate group terms for a group of six entries. The second step involving logic block 930 combines the group terms from adjacent groups of entries, one of six or three, to generate group terms for a group of nine or twelve entries. The third step involving logic block 940 combines the group terms from adjacent groups of twelve, six or three entries to generate group terms for groups of eleven, eighteen and fifteen entries.

Logic blocks 920, 930 and 940 have group terms GY, PY, OY for the next new group Y for group X and combine group terms GX, PX, OX to group X Generate terms (GXY, PXY, OXY) for the group (XY) that is the connection of, Y. In one embodiment of the invention, each block 920, 930, 940 follows the equation:

GXY = GX, PY +-OX, GY

PXY = PXPY

OXY = OX + OY

The circuit shown in FIG. 9B shows an example of the execution of blocks 920, 930 and 940. In FIG. 9B, the input signal is for group 1, 2 and the output signal is for association of group 1, 2; The desired inconsistent group can replace group (1, 2). Optionally, other equivalent logic may be used, or block 920, 930 or 930, 940, which is a selection step, may be transitioned to inverse logic. Additionally, as discussed below, the last step, propagation term from block 940, is not necessary, and block 940 can be simplified by not implementing the propagation equation (ie, removing AND gate 922). .

Desired output signals from circuit 900 are the G and O terms. The output signals G_7, G_67, G_567, G_4567, G_34567, G_234567 and G_1234567 respectively indicate that the previously generated scan bits reach groups 6,5,4,3,2,1 and 0, and in this specification the signal CinGrp [6 Also referred to as: 0]. Signals O_7, O_67, O_567, O_4567, O_34567, O_234567 and O_1234567 are prior to each of the groups 6,5,4,3,2,1, and 0, regardless of whether the scan bits are removed before reaching each group. Is generated. The signals O_7, O_67, O_567, O_4567, O_34567, O_234567 and O_1234567 are also referred to herein as signals OinGrp [6: 0].

The multi-bit signal IssueOpRUY [23: 0] can be generated from the group signals CinGrp [6: 0] and OinGrp [6: 0] and the single-entry signals P, K, G and O. 9C shows logic to select an entry for issue to a RUY execution unit. The logic that generates the signal IssueOpToRUY [23:21] entries (23 to 21) is different from the logic for other groups because there is no group propagation to the oldest group, group (7). The logic shown to generate IssueOpToRUY [20:18] for group 6 is repeated for each group (5 to 0). As can be seen in Table B.31 of Annex B, the group propagation term from the final group (0) does not require the selection of an action for publication.

III. A.2 Operand Information Broadcast Stage

During the broadcast phase of the issue phase of the processing pipeline, information about the operands to be issued to the execution unit is broadcast to all scheduler entries and external logic. This information describes two source operands for each action selected for publication. The entry for the selected action also transmits information about the selected action to external logic and associated execution units.

Operand information bus 552 (FIG. 5) passes through scheduler 280. The number of operand information buses 552 matches the maximum number of operands required for the execution unit. The entry related to the selected operation drives two operand buses 522 associated with the execution unit for which the association is issued. Each operand information bus 552 is 8 bits wide and has a 5-bit register number Src1Reg [4: 0] or SrcReg [4: 0] and a 3-bit byte mark Src1BM [2: 0] or Src2BM [for the source operand. 2: 0]. Table B.31 describes the entry logic for driving operand information bus 552.

The comparison logic inside each entry compares the broadcast operand information with similar information about the destination register for operation in the entry making the comparison. The comparison logic checks whether the register number is correct and the byte mark is correct (ie, some or all of the bytes requiring an operand will be modified or modified by the operation). The result of the multiple comparisons ("# of the operand information bus" * "# of entries") is a signal that controls the activity that occurs during the next processing step, operand selection step 441. Table B.32 describes the logic for performing the comparison. The following formula summarizes a general comparison:

OprndMatch_XXsrcY = (busReg [4: 0] = = DestReg [4: 0])

&& (busBM [1] DestBM [1] + busBM [0] DestBM [0])

Here, "XXsrcY" is one of LUsrc2, LUsrc2, SUsrc1, SUsrc2, RUXsrc1, RUXsrc2, RUYsrc1 and RUYsrc2, and "bus" refers to the single signal OprndInfo_XXsrcY, which is one of operand information buses 552.

The comparison result "Match" signal OprndMatch_XXsrcY is the product of the broadcast step and is used in the operand selection. This occurs together within each entry and every entry, ie inside each entry, and eight match signals are piped to the entry selection logic 532 of the entry. All of the match signals are held locally at each entry and latched into registers for use in subsequent pipeline stages. Essentially, inside each entry, eight operand information bus comparators feed eight "control" signals to eight chunks of operand selection logic 532. The match signal inside each entry in the bottom row is gated or masked by additional signals related to the disposition of the register of this operation, resulting in an architectural register file 290. See the description of the action disposal unit 260 below.

Each entry does not actually control the loading of the match bus into the operand match register within that entry. Wide area logic 520 generates signals LUAdv0, SUAdv0, RUXAdv0, and RUYAdv0 indicating whether the issued operation precedes operand forward step 440, and the match signal is latched and used when the operation actually precedes operand forward step 440. Just become.

Four operation information buses 551 correspond to a load unit 251, a storage unit 252, a register unit 253 and a register unit 254 which provide additional information describing the issued operation. The additional information is primarily an OpInfo field, which is read by the scheduler 280 during the broadcast phase and latched into an external pipeline register if the operation actually precedes the operand forward phase. Table B.33 describes the logic that generates the motion information signal.

The Src1 / 2Reg and Src1 / 2BM fields provided during the broadcast phase are used for the desired number during the next two phases (ie operand forward phase). The OpInfo field is simply passed down to the corresponding execution unit (via the second set of pipeline registers controlled by the corresponding signal XX Adv1). For RUX and RUY operation, the relevant byte mark Src1 / 2BM is also passed "down" into the corresponding register unit.

III. B. Operand Forward Steps

The operand forward step consists of an operand selection step and an operand transmission step.

III. B.1 Operand Selection Steps

In each cycle in the operand forward step, the scheduler 280 selects an entry that supplies a value for the operand to be "fetched" using the batch bits generated by the issue status logic 530 and stored in the operand match register. The scheduler 280 may determine for each operand whether the value of the operand is from a scheduler entry or from a register file 290. Register file 290 defaults to no matching entry. During the operand forward step, the selected entry and / or register file 290 drives the operand value on the operand bus 544 to send the operand value to the associated execution unit.

In the issue selection process at the issue stage, operand selection occurs independently and simultaneously. Thus, the operand selection logic 532 includes eight scan chains for selecting entries for providing operands. Each entry has an operand match register for each operand bus and associated scan chain. Each scan chain finds the oldest and newest matching entry than the entry containing the action with the fetched operand. Logically, the scan starts a scan from an entry that has an operand to be fetched and includes an operation that proceeds to an older entry direction (the scan bit occurs). If an entry is found that sets the match bit, the entry supplies the operand requested by the driving of the associated operand bus 554 during the next step. If no "matching" entry is found, a scan bit is output in the scan chain to cause register file 290 to supply the operand value.

If the operation with the fetched operand does not precede the operand forward step, the operand selection process is performed again in the next cycle. The operation is not advanced if, for example, an entry with a set of match bits does not modify (and thus cannot supply) all the bytes that require the operand. Since the physical state of the operation in the field state and scheduling store 540 may change in each cycle, the output of the new selection may be different from the output of the current cycle. Naturally, during each cycle, the selection process determines what needs to be done to forward the operand value during that cycle.

The scan to find the appropriate source for the operand value can be performed in the same way as the issue selection scan described above. However, the scan is in the direction of an older operation opposite to the direction of the issue selection step. Moreover, for operand selection, the scan chain is not a "propagation-removal" chain. Operand selection scan chains are similar to conventional conveying or "generating-propagating-removing" chains. The initial scan bit Cin into the scan chain is zero, and the entry corresponding to the operation with the fetched operand generates the scan bit. Scan elimination occurs at the first entry that follows the operand match bit set, and scan propagation occurs at the interleaving entry.

The global control logic 520 uses the last output scan bit Cout from the last / oldest entry to determine which entry is selected and which register file 290 should be selected to provide the operand. If Cout is asserted, global control logic 520 selects register file 290. The selected source drives the operand during the operand transfer phase which is later in the operand forward phase. During the operand selection step, the source register in the register file 290 that normally holds the desired operand value is read when the register file 290 is selected to drive the operand bus.

In the issue select scan chain, the look-ahead execution is speeded up. Table B.34 in Appendix B provides an example of an operand selection scan chain with a look-ahead equation similar to the conventional Generate-Propagate-Kill equation.

III. B.2 Operand Transfer Step

During operand transfer step 442 of operand forward step 440, the values for each of the eight source operands are retrieved and transferred via operand bus 554 to the input register of the associated execution unit. The operand value is a 32-bit quantity, but some bytes are not defined. While the modify operation is in progress, the execution unit does not use undefined operand bytes. Some entries or register files 290 may drive each operand bus 554, and each entry in the scheduling store 540 may drive some and / or all buses.

In one embodiment, 192 operand select signals and 8 scan chain signals Cout are generated during the operation selection step. Based on this signal, the logic in each selected entry makes available the appropriate bus driver in that entry. If no entry is selected for the operand, register file 290 makes the driver available for that operand. Table B.35 in Appendix B describes the logic that enables the driver for operand bus 554.

Operand registers in execution units 251 through 254 capture the operand value from the operand bus for use in subsequent pipeline stages. Global control logic 520 controls the loading of the operand register by generating one control signal per processing pipeline. If the operation of the operand forward step can precede execution step 450, a new operand value is loaded into the execution unit. Similarly, signals SUAdv1, RUXAdv1, and RUYAdv1 control SU, RUX, and RUY loading of the operand registers, respectively.

During the operand transfer step 442 of the operand forward step 440 of the four processing pipelines, information about each of the selected operations to provide operand values is also read outside the scheduler 280. Each operand bus 554 has an associated offland status bus 553 that carries the operand status signal OprndStat describing the " origin " of the operand being fetched. The operand status signal from the entry is a concatenation of the fields State, DestBM, Type and Execl of the entry providing the operand value. External logic uses this information during the operand transfer step to determine the source and availability of valid operand values.

Register file 290 also has a set of drivers for operand status bus 553 that ensure operand status bus 553 carries a defined value, the result of which is properly operated by logic using the information. Bring it. Table B.36 in Appendix B describes the operand status signals and their occurrence.

Each source operand carried in an execution unit comes from one of three possible sources: a scheduler entry, a register file 290, or a result bus of this execution unit or another execution unit. Operand transfer step 442 covers the transport from the entry. In particular, the register number for the desired operand is broadcast from the operation during the broadcast phase and passed to the appropriate read port of the register file 290. For each operand to be provided, the scheduler 280 determines whether the scheduler entry or register file 290 drives the operand bus 554 corresponding to the operand; As a result, the operand is transmitted to the execution unit via the operand bus 554 during the operand transmission step.

As shown in FIG. 10, operand bus 554 couples with operand input registers 1021 through 1024 and 1031 through 1034 in execution units 251 through 254 via mulplexplexer 1010. Result buses 561 to 564 from execution units 251 to 254 are also coupled to multiplexer 1010. Thus, five "operland" buses go to each operand input of each execution unit, mainly one of the operand buses 554 from the scheduler 280 or register 290 plus four from the execution units 251 to 254. Dedicated to the result bus inputs. During the operand transfer phase, the scheduler 280 generates a select signal for the 5: 1 multiplexer 1010 in each operand input register. The operand status signal indicates whether the desired operand value may or may not be available in the execution unit; If so, the result bus and the value Result_XX from execution units 251 to 254 are selected. Otherwise, operand bus 554 is selected. The validity of the operand is an independent issue that only affects whether the associated action in operand forward step 440 actually enters the execution unit prior to execution step 450.

III. B.3 Displacement Forwarding

In addition to the register operand, the scheduler 280 fetches the displacement operand and forwards it to the LU and SU processing pipeline during the operand transfer step 442. The load unit 251 and the storage unit 252 each have three input operand buses (two register buses 554 and one displacement bus 555). The displacement operand is a 32-bit quantity, but some bytes of the displacement operand are not defined and are not used during the modify operation of execution units 251 and 252.

The scheduler 280 processes the displacement in a manner similar to the operation register result. The displacement is initially stored and used inside the 32-bit DestVal field of the entry and then driven on the displacement bus 555 if necessary during the operand transfer step 442. The displacement is always an intermediate value of RISC86 operation, so that no forwarding displacement value from register file 290 occurs. The field DestVal is also used for result values from LdOps and some StOps, but the two uses of the field DestVal do not load the result value into the scheduler entry until after the displacement forwards out of the entry, i.e. before operand forward step 440. Because it does not crash.

Small (8-bit) displacements specified inside the equivalent are treated differently than large (16 / 32-bit) displacements. The motion decoder 510 sine expands the small displacement into the DestVal field of the entry that holds the associated LdStOp before the small displacement is loaded. Large displacements are believed to be stored in the DestVal field of the entry for LIMMOp immediately preceding LdStOp using the displacement. In general, the preceding entry maintains a " LIMM t0, [disp] " operation that can be loaded into the scheduler 280 with the LIMMOp being completed or not executed.

Select the DestVal field to drive the displacement bus 555 while each cycle does not require scanning of the scheduler entry. Instead, each entry determines from its State and Type fields whether it can cause its driver or a preceding driver to assert the DestVal field value onto the appropriate displacement bus 555. Table B.37 in Appendix B summarizes the logic that enables the displacement bus driver inside each entry.

III. B.4 Median Forwarding

In the example of the format of the RISC86 operation, the intermediate value is the operand src2 of RegOps. Scheduler 280 deals with median values and displacement similarities. The Shak RISC86 instruction set uses only a small (8-bit) intermediate value in RegOps and the operation decoder 510 stores the intermediate value in the field DestVal of the entry holding RegOp. Thus, the intermediate value is stored in the DestVal field of the entry, equal to the displacement, but equal to the register operand forwarded to the register operand bus 554 (especially the RUXsrc2 and RUYsrc2 operand buses). The intermediate value for the Src2 operand is forwarded to each register execution unit during operand transfer step 442 of operand forward step 440 instead of the register value. The selection of a register value source (ie scheduler entry or register file 290) is prohibited and the entry in the query drives its DestVal field directly into the appropriate operand bus 554.

The prohibition of RUX / RUY src2 operand selection is performed during operand selection step 441 by masking a single-entry occurrence term that the entry holding RegOp normally asserts in the operand selection scan chain. This is done separately and independently for RUXsrc2 and RUYsrc2 and prohibits the selection of any entry by the RUX / Ysrc2 scan chain. The entry containing the intermediate value also prevents selecting register file 290 as the default operand source. The single entry term for the RUX and RUY operand selection scan chains described in Table B.34 shows this prohibition.

The selection of small "middle" DestVal values for driving into the RUXsrc2 and RUYsrc2 operand busses during each cycle does not require scanning of the scheduler entries. Instead, each entry allows the driver of its DestVal field to simply be available to the appropriate operand bus 554 based on the entry's State field and associated bits. The same driver can be used for register operand value forwarding and median operand forwarding. Table B.38 in Appendix B describes the circuit for driving the intermediate value on operand bus 554. When an entry drives an intermediate value on operand bus 554, the associated operand status bus 553 also drives. It is shown in Table B.38 that the same bus driver and driver input values for the register operands are used without additional terms for intermediate values.

III. C data operand fetch

StOp has three register source operands and no destination register. On the other hand, the other operation must be up to two source operands and one purpose. The third source operand for StOp provides stored data, referred to herein as a data operand. The data operand does not need to start running StOp but needs to complete StOp. The withdrawal of the data operands is performed in a similar manner to the withdrawal of other source operands, but the "normal" operand withdrawal processing occurs during the issue phase 430 and the operand forward phase 440, and the data operand index is the SU execution phase ( 450,460). Scheduler 280 checks the availability of the data operands during SU execution step 460 and maintains the associated StOp in step 460 if the data operands are not available.

The data operand withdrawal process has two different principles and is very similar to the publish and operand forward steps described above. First, the operation selection step 456 does not require a scan of the scheduler operand to select between the various candidates that occur during the issue selection step 431. Instead, an entry associated with the StOp in SU step 450 identifies the State and Type fields and themselves and provides the data operands to storage unit 252 as needed. The second difference is that the OpInfo field of the StOp does not need to be read (again) into the storage unit 252 during the broadcast step 457 for the data operand. Instead, storage unit 252 maintains and uses the OpInfo value from when the StOp is issued. The OpInfo value read during the SU issue step 430 is passed down through the operand forward step and the first and second execution steps of the SU pipeline.

Table B.39 in Appendix B describes the signals generated for data operand selection and forwarding.

III. D register operation conflict

Scheduler 280 manages the execution pipeline based on order issuance selection and processing for each operation type. The "normal" operation is issued to the execution unit proceeding to the pipeline of the order in which the operation was issued. If an operation is left within the operand forward phases of the SU and LU pipelines, then the actions currently being selected for publication to that pipe, for example, are stagnant because the operations are not passed by each other within the processing pipeline. However, if RegOp stalls within an operand forward step of either register unit 253 or register unit 254 due to one or more unusable operand values, RegOp may crash outside the processing pipe and the unissued It will go back to the previous state. The conflict sets the RegOp's State field back to b0000. If RegOp collides outside operand forward step 440, then another RegOp selected for publication to that register precedes operand forward step 440 and immediately replaces the conflicting RegOp. At the same time, the conflicting RegOp is entitled to be reissued to a register unit, but does not require the same register unit.

Conflicts are applicable to all RegOps for the following purposes: First, RUX-only RegOp (in the RUX operand forward phase) does not crash if RUX-only RegOp is selected for publication to RUX because the current conflict violates the restriction that RUX-only RegOp is executed on demand against each other. Secondly, RegOp only collides when RegOp stalls in more than one cycle, otherwise leaving the RegOp in operand forward step 440 results in more efficient use of execution unit resources. Table B.12 describes the circuit that changes the State field of an entry to perform a RegOp conflict. The wide area control logic 520 issues the wide area collision signals BumpRUX and BumpRUY forcing assertion of the signals RUXAdv0 and RUYAdv0 so that the properly issued RegOp precedes the operand forward step 440. The description of global control logic 520 below further illustrates the state under the collision of RegOp.

III. E Load / Save Order

Scheduler 280 supplies the necessary order maintenance between LdOps and StOps. In particular, load-store order logic 534 stores the memory independence of the load and stores it by indicating the relative ages of the selected LdOps and StOps. If the LdOp or StOp is likely to access an address such as an older StOp or LdOp that has not yet completed, maintaining operation within the execution stage 460 of the LU and SU execution pipeline will maintain appropriate load-storage orders. It becomes.

The load and storage units 251 and 252 include an address comparator, and the ordering logic 534 in the scheduler 280 allows only an appropriate address comparison on the bus 556 to perform LdOp or StOp in the second execution step 460. Provides information indicating the relative age of the LdStOp to be taken into consideration when determining whether to keep. The relative age determination process is similar to the issue selection / operland information broadcast process. During the first step 463 of execution step 460 for LdOp and StOp, order logic 534 performs five "propagation-removal" scans that scan all scheduler entries from the oldest to the newest. Two scans compare LdOp and StOp in SU stage 460, and three scans compare StOp and LdOp in LU stage 460. During the second step 464, the entry for LdOp and / or StOp in the execution step 460 samples the widespread signal SC_SU2OLDER, which samples the relevant two or three scan chain results and directly represents the desired relative age information on the bus 556. , SC_SU1OLDER, SC_SU0OLDER Drives SC_LU2OLDER and SC_LU1OLDER.

Execution of the second half of LdOp and misaligned load in execution step 460 or 450 requires three scan chains to determine the relative age of the three categories of LdOp of StOp. Each scan chain scans for the oldest StOp in the category. One scan chain detects StOp in step 460 or 450 and performs the second half of misaligned storage. The other scan chain detects StOp in step 450, and the three scan chains detect StOp not yet the oldest in step 450. The state of the scan bit at any point in the scan chain affects whether an old StOp of a given type has not yet been found. Thus, the entry for LdOp determines the age of LdOp for any StOp in a given category from the input scan bits. If the input scan bit Cin is "1", the scan signal is not yet "removed" and there is no older StOp in a given category. Load-store order logic 534 determines the association of the signal from the address comparator, if necessary.

StOp, which performs the second half of misaligned storage at stage 460 or stage 450, requires two scan chains to determine its downtime with respect to the two categories of LdOp. One scan chain detects any StOp that performs a second half of misaligned storage in stage 460 or stage 450. The second scan chain detects any LdOps that have not yet been detected at stage 460. Based on the input scan bit Cin into the entry that holds StOp in the query, the order logic 534 determines whether the signals from the address comparator are related.

Each scan chain is a propagation- kill chain from the oldest to the most recent scheduler entry. The load-storing sequence is described in Table B.40 of Appendix B and US Patent Application No. 08 / 592,209.

F. Suspension Processing

When the abandon cycle occurs, the scheduler 280 is activated. All Op quads become invalid by clearing all Op quad fields OpQV, and the fields of the entry are also set to harmless values. The field in the entry must be cleared because the field OpQV only affects the control of the Op Quad loading and shifting, other operations in the scheduler 280 ignore the field OpQV, and assume the entry is valid. Operations in scheduler 280 that are not logically valid are changed to valid but harmless operations. To do this, the State field of the operation is set to complete so that the operation will not be issued or executed. The DestBM and StatMod fields are set to indicate that the operation does not modify any register byte or status flag. In such circumstances, all other fields may have some value that does not cause any damage . Such an operation is an effective no-op operation.

The new Op quad can be loaded into the scheduler 280 as soon as the scheduler 280 is activated. The new op quad is not associated with any op quad that does not need to be activated. Instead, it becomes a logically new first op quad after giving up. This occurs after abandoned or mispredicted BRCOND. After the abandon cycle, the new first op quad is delayed due to the exclusion condition.

Effectively, the following sequence of events occurs at the end of the abandon cycle. Note that the storage elements in scheduler 280 are globally synchronized with the system clock signal and do not change state in response to input until the next cycle boundary. First, changes in the fields OpQV, State, DestBM, and StatMod occur as described above. The new Op quad is then loaded with the best scheduler entry position, with all or some of the Op quads shifting to one position or nothing shifting to one position. In the exclusion-related waiver, the new op quad is also invalidated, and any shifting that occurs because all scheduler op quads are active is generally ignored. In the BRCOND related disclaimer, the new Op quad is valid or empty.

Abandonment signal appears in two variations, early and rate . Early deformation is called SC_EAbort, and rate deformation is called SC_Abort. The early abandon signal is sent to a section of the scheduler 280 that requires immediate abandon confirmation. Rate variation is the same as early, but one cycle delay in flip-flops and is transmitted more widely.

Ⅳ. Wide Area Control Logic

In addition to the logic associated with each entry, the scheduler 280 includes logic that controls the scheduler 280 as a whole.

A. Scheduler Information Used by External Logic

External logic, such as global control logic 520 and execution units 251, 254, uses a number of information provided by scheduler 280 during the broadcast and operand transmission phase of extracting operand values. For most operand types, the broadcast and operand transfer stages will be during the issue and operand transfer stages of the execution pipeline. During the broadcast phase, information about the operation from which the operand is extracted is read on the appropriate OpInfo bus 551; The two source registers (Src1, Src2) and byte representation (Src1BM, Src2BM) fields of the operation are read on two related OprndInfo buses 552. In the data operand of StOps, the broadcast phase and the operand transmission phase are at the SU stages 450,460. The information of the StOp's data operands is driven onto the associated OprndInfo bus 552, but there is no associated OpInfo. The storage unit 252 persists the operation information when StOp is issued. Broadcast operand information is used during the next two steps. Operation information simply passes down the pipeline in the execution unit. In the case of register units 253 and 254, the two source byte mark Src1BM and Src2BM bits from OprndInfo bus 552 also pass down the pipeline. During the operand transfer phase, information about each operation that is the source of the operand value is read on the OprndStat bus 553 associated with each operand bus 554. Information describing the state of the source operation is used directly (only) during this step. Table B.41 summarizes the information read from scheduler 280 at various times.

B. Wide area control function

The logic, storage elements, and buses having the core of the scheduler 280 are described above. Scheduler 280 also includes global control logic 520 that coordinates shifting within scheduler 280 and coordinates the operation and supply of operands to execution units 251-254. The following describes the piece of global control logic 520 in step 4 of the operand extraction process.

During the issue selection phase, the external concern is only whether an operation has been selected for the issue into each processing pipeline. In each issue selection that did not find a suitable operation, no scheduler entry drives the corresponding OpInfo and OprndInfo buses 551,552. The next three stages during this processing pipeline and the values on these buses are not taken into account. The only requirement is that the operation valid bit (OpV) for the operand transfer stage 440 of the execution pipeline is zero to indicate that the operand transfer stage 440 is empty in this pipeline stage.

The operand transfer step operation valid (OpV) bit indicates whether a valid operation is issued to the operation unit. The output scan bit Cout of each issue select scan chain generates an OpV bit for operation in the issue stage. Table B.42 describes the operation valid bits or the OpV bits. The global signal XXAdv0 controls loading the OpV bit into the pipeline register to follow the progress of an empty operation. During the abandon cycle, all pipeline registers are unconditionally cleared to activate the execution unit.

The broadcast phase does not require any significant global control logic other than to control the pipeline registers latching the information read from the scheduler 280 (ie, OprndInfo and OpInfo values).

During the swing select phase, two external activities occur. First, the source register number (ie, the SrcYReg field of the latched OprndInfo value) read during the preceding phase is used to access the register file 290. This is done in parallel with the swing select scan in scheduler 280. Up to 9 source operands can be sent in each cycle. Thus, register file 290 has nine corresponding read ports, each associated with any one of operand bus 554. The register fields that appear in these ports are XXsrcY and SUsrcSt, where XX = {LU, SU, RUX, RUY} and Y = {1,2}.

During the operand selection phase, a second external activity is selected for each operand bus 554 and operand information bus 552, where the scheduler 280 or register file 290 will provide values for the next phase. Each scheduler entry directly determines whether or not it must drive the bus, so that global control logic 550 only determines if register file 290 is possible. Enabling the register file 290 is based on an output scan bit Cout indicating which entry was selected during the operand select phase. If the last scan signal Cout during the operand select scan chain indicates that there is no entry for the associated operand bus 554, the global control logic causes the register file 290 to drive the associated operand bus 554 and operand information bus 552. do. Equations representing signals on operand bus 554 are described in Table B. 35 and Table B.36 of Appendix B.

During the operand transfer phase, the global control logic 520 includes: RegOp "bumping", all execution unit input multiplexers 1010 of the execution unit, validity determination for each operand value to be fetched, and the global pipeline register control signal (XXAdvO). Controls the generation of the signal HoldXXO, which is a generation factor.

Execution of one RegOp bump separates the logic in each scheduler entry that changes the state field of the entry, and the global control logic 520, which generates the global bump signal BumpRUX and BumpRUY signals and forces confirmation of the signals RUXAdvl and RUYAdvl signals. to be. The generation of the BumpRUX / Y signal is the OprndStat value read from each register unit source operand (ie, OprndStat_RUXsrcY and OprndStat_RUYsrcY, where srcY = {src1, src2}) scheduler 280 during the operand transfer phase. In particular, the field state and type for each operand source is tested to determine if the sourcing operation is at least two cycles away from providing a valid operand value. If the sourcing operation is at least two cycles away from providing a valid operand value, the subordinate RegOp is bumped from the operand forward step. If RegOp has not reached the operand forward step, RegOp is at least two cycles away from providing the operand. If LdOp has not been reached by the first execution step, LdOp is at least two cycles away from the provision of the operand.

Table B.43 summarizes the generation of the signal BumpRUX / Y, which includes additional timeout periods that can result in deadlock situations. The 3-bit counter associated with the RUX and RUY operand forward stages generates a signal RUX / Y timeout after the operation is held above the timeout period during the operand forward stage. Taking RUX as an example, each time the RUX operand forward stage is loaded (whether it is a valid or invalid operation), the associated counter is reset to the starting value. During all other cycles, the counter is decremented. When the counter reaches 000, the RUX timeout is checked to indicate that the operation has been held for too long.

The RUX / Y timeout signal causes the corresponding operation signal OpV to be set for the operand forward stage of the register units 253 and 254. For example, the signal RUX timeout immediately causes the signal OpV_RUX_0 to be zero, and then causes the assertion of the pipeline control signal RUXAdv0 to reload the RUX operand forward stage. Signal OpV_RUX_0 ensures that RUX execution stage 450 does not encounter a conflicting RegOp if signal RUXAdv1 is also asserted.

The second global control function that occurs during the operand transfer page is the generation of a control signal for each source operand input multiplexer 1010 coupled to execution units 251-254. As described above, each 5: 1 multiplexer 1010 selects an operand from one of the associated operand bus 554 or operand buses 561-564 to select one of the associated operand registers 1021-1024 or 1031-1034. Load into either. During operand transfer phase 442, control logic 520 uses operand status signal OprndStat from bus 553 to generate a control signal for each multiplexer 1010 and select operands OprndStat_SUsrcSt and OprndStat_XXsrcY, where XX = {LU , ST, RUX, RUY} and Y = {1,2} are loaded into the operand register. In particular, the global control logic 520 examines the field state and type for each operand source to determine which sourcing operation completes execution and if not, which execution unit executes the sourcing operation. Operand bus 554 is selected if the source is a register file 290, a completed operation, or an operation that provides itself with a src2 contiguous value. Otherwise, the bus is selected from the execution unit corresponding to the type of sourcing operation. Operands from the bus will not be valid unless the sourcing operation completes in that cycle.

The third global control function that occurs during the operand transfer phase is the determination of the validity of each of the nine operand values appearing in the execution unit source operand register. A signal is generated for each source operand to indicate whether the source operand value is valid. By controlling the associated execution unit input multiplexer 1010, the operand feasibility determination is based on the shape of the OprndStat from the bus 533 and the field state value. The sourcing operation must have either a completed execution or a currently completed execution for the operand to be valid. Also, the DestBM field of the OprndStat value is compared to Src1BM or Src2BM of the latched OprndInfo value for the operand to be fetched. For the operand to be valid, the byte mark of the sourcing operation must be a superset of the required byte mark Src1BM or Src2BM. The adjacent value of src2 is always valid. The signal OprndInvld_XXsrcY appears to indicate that the operand srcY for execution unit XX is valid. Table B.45 summarizes the logic for generating the signal OprndInvld_XXsrcY.

The fourth global control function that occurs during the operand transfer phase is the generation of a pipeline control signal that holds up an operation in the pipeline stage when the operand required for progress is invalid. If the source operand is not possible, the signal SC_HoldXX0 holds the operation in operand forward stage 440, while the time signal SC_HoldSU2 holds the StOp in the second execution stage 460 when the data operand is not valid at that time. The cc-dep RegOps is held up in operand forward stage 440 if the required condition code is invalid. Table B.46 summarizes the logic for generating the signals SC_HoldXX0 and SC_HoldSU2.

Ⅴ. Status Flags

The status flag logic 538 for x86 architectural flags and micro-architecture flags has three functional areas: retrieval of status flag operand values for cc-dep RegOps, retrieval of status flag values for resolution of BRCOND, and non-stop RegOps. Has synchronization with the preceding BRCOND. Unlike operand selection logic 532 and LdOp-StOp order logic 534, status flag handling logic 538 is not written to all scheduler entries. Status flag handling for related operations is only performed while detecting that the status flag is within a particular column in the scheduler 280. The cc-dep RegOps must be in column 3 during the cycle when the status operand fetch is executed (ie, during the RUX operand forward stage). BRCOND and non-stop RegOps should be in column 4 during decomposition by branch evaluation unit 257 and RUX operand forward stage. Thus, the cc-dep and non-stop RegOps are held up in the RUX operand forward stage until they shift down to columns 3 and 4, and the shifting of the op quads in columns 3 and 4 results in Cc-dep and non- Abort RegOps is suppressed until proceeding into the RUX run stage. BRCON remains in column 4 while the evaluation requires a status flag to be valid.

Suppression of evaluation and execution of cc-dep RegOps, non-stop RegOps, and BRCOND when the operation is in a particular column of scheduler 280 simplifies status flag handling logic 538. For example, status flag handling logic 538 is only needed within the bottom three scheduler columns and the bottom two columns used to determine the appropriate status flag value. In addition, the same status flag value may be shared by both cc-dep regOp in column 3 and BRCOND in column 4. Synchronization between non-stop RegOp and BRCON is simplified because the location of BRCOND is fixed when evaluated.

The multiple restrictions imposed upon positioning each other within the op quads of cc-dep RegOp, BRCOND, and non-interrupted RegOp further simplify the logic. This restriction is generally translated into coding rules for encoding, but in some cases also suppresses the MacDec 242 decoding of multiple macroinstructions within the cycle. This limitation requires the Op quad to include:

1) no change in cc of RegOp after BRCOND;

2) no cc change of RegOp prior to cc-dep RegOp;

3) none with non-stop RegOp and BRCOND;

4) only one cc-dep RegOp;

5) only one BRCOND; And

6) Only one non-stop RegOp.

By way of limitation, the correct status flag for cc-dep RegOp in column 3 is also correct for BRCOND in column 4, and the same status flag circuit serves two purposes.

V.A. Status flag withdrawal

Status flag handling logic 538 draws four independent groups of status flags corresponding to four bits of the field StatMod. Table B.47 in Attachment B shows the four flag groups and their corresponding field StatMod. Whether each group is valid for an operation is determined independently, depending on whether the old operation that can modify the group is complete.

Sending the status flag value directly to register unit 253 or cc-dep ReOp entering unit register from unit 254 is not supported by the embodiment. Thus, the status flag validates the cycle following completion of the condition code that changes RegOp. This minimizes the delay between the execution of RegOp, which modifies a particular group of status flags, and subsequent execution of the cc-dep RegOp using this group. The impact of statistical execution of this delay is minimal because cc-dep RegOp is relatively rare when decoding typical x86 code. In addition, the impact of delay can be eliminated by instructing RISC86 to avoid cc-dep RegOp in the Op quad immediately following RegOp changing the condition code needed for the indication decoder 240 for cc-dep RegOp.

During each cycle, the setting of effective status flag values at the boundary between scheduler rows 3 and 4 is calculated. The calculated status flag includes the executed status flag and a change in the status flag caused by the operation in columns 4 and 5. As explained above, only RegOp modifies the status flag. Since each RegOp can modify only one, two, three, or all four groups, the status flag calculation is performed independently for each of the four groups. The result of the calculation for each group is the state information from the latest RegOp with a set of flag values and StatMod bits corresponding to the group set. The State field for RegOp indicates whether RegOp has completed and provided a valid flag value.

The status flag logic 538 includes eight status flag bits STATUS and Table B. Generates four valid bit STATUSVs associated with the status flag group in 4 shown in 47. These 12 bits are sent via bus 557 to branch evaluation unit 257 which evaluates the logic in register unit 253 that handles BRCOND and cc-dep RegOp. The register unit 253 and the branch evaluation unit 257 determine whether the required status flags from the valid bit STATUSV are valid, and if they are valid, execute the cc-dep RegOp in duf 3 using the status bit STATUS and in column 4 Evaluate BRCOND. The global control logic 520 generates a shift control signal depending on whether the required status flag is reasonable.

The same process as the register operand value retrieval process fetches each stater flag group to obtain a suitable flag value for the final operation in column 3 in the scheduler 280. In the following, the indication " OpX " indicates an entry of X in the scheduler 280, where X = 0 and X = 23 indicate operations in the latest and oldest scheduler, respectively. For example, column 4 includes Op16, Op17, Op18 and Op19. For each flag group, the prop-kill-style scan from Op16 to Op23 causes the first operation to be done with the StatMod bit for these flag group sets, and the completed state bit of the entry (ie S3) and the set of appropriate flag values are read. do. The StatusV bits of these groups are state bits S3 from the found entry. If no such operation is found, the required flag value is read from the architectural status flag register and the signal STATUSV is set to indicate that the group is valid. Table B.48 shows the status flag retrieval logic for each flag group.

Ⅴ.B Status Forwarding to cc-Dep RegOps

During each cycle, global control logic 520 examines four operations in column 3 to determine if any of them are cc-dep RegOp. If so, the RegOp is decoded to determine which status flag groups are needed, and the StatusV bit is checked to determine if these groups are all valid. At the same time, status [7: 0] is sent blindly to the RUX execution unit. If any of the required flag groups are not currently valid, the cc-dep RegOp is held up in RUX to proceed to the run phase and the shifting of the Op quads from column 3 is prohibited. If all required flag groups are currently valid, cc-dep RegOp is allowed to proceed to the RUX execution phase, at least as long as the status operand fetch is involved. cc-dep RegOp is still prohibited because no operand is possible. If cc-dep RegOp does not proceed to execution step 460, shifting in row 3 is prohibited.

If the unexecuted cc-dep RegOp is not in columns 3 to 5, but the cc-dep RegOp is in the RUX operand forward phase, RegOp is unconditionally held up in the operand forward stage. If cc-dep RegOp in column 3 has not been executed, but cc-dep RegOp is not in the RUX operand forward stage, shifting in column 3 is prohibited. Table B.49 shows the logic that controls the shifting and operation progress.

Ⅴ. Branch prediction analysis

During each cycle, if BRCOND is found in column 4, the condition code (cc) field of this BRCOND is decoded to determine the predicted condition value. The predicted condition value is compared to a selected one of the 32 condition values derived from the status flag from status flag handling logic 538 if the associated valid bit indicates that the selected condition is valid. If the selected condition is not yet valid, shifting of the Op quad in column 4 is inhibited and evaluation of BRCOND is attempted again in the next clock cycle. If the selected condition is valid, the comparison of the predicted condition and the selected condition indicate whether the prediction is correct.

If a BRCOND is found to be incorrectly predicted (and thus requires a pipeline restart), a restart signal will be issued depending on whether BROCOND is from MacDec 242 or an encoding operation from internal or encoded. In addition, the appropriate x86 macroinstruction or encode vector address and associated return address stack TOS value are generated and returned to instruction decoder 240 to restart decoding.

For the benefit of the synchronization handling logic between the non-interrupted RegOp and the preceding BRCOND described later, a record of the incorrectly predicted BRCOND is maintained while it is noticeable (ie, until an abort cycle is executed). In addition, a noticeable mispredicted BRCOND holds up the loading of the "new" Opquad until the abort cycle is executed.

If BRCOND is correctly predicted, the only action to be taken is to set the BRCOND state bit S3 to indicate that BRCOND is complete. Table B. 50 represents the logic for handling BRCOND evaluation.

Ⅵ. Synchronization of non-stop operations

During each cycle, if a non-interrupting RegOp is found in column 4, the scheduler 280 checks for a previous mispredicted BRCOND. Since encode coding is suppressed, the preceding BRCOND must be in the lower row and therefore analyzed. In addition, the BRCOND (in column 4) being analyzed is after the non-stop RegOp and is therefore not valid.

If there is no mispredicted BRCOND, the non-stop RegOp is allowed to proceed to the RUX execution phase even if RegOp does not proceed because the required operand is still invalid. If RegOp does not immediately proceed to RUX execution, RegOp is allowed to shift in column 4.

If column 4 or 5 does not contain a non-executed non-stop RegOp but the non-stop RegOp is in the RUX operand forward step, the non-stop RegOp is unconditionally in the operand forward step until the non-stop RegOp reaches column 4. It is held up. If the non-stop RegOp in column 4 has not yet been executed, but the non-stop RegOp is not in the RUX operand forward step or the non-executed non-stop RgeOp is in column 5, shifting in columns 4 and 5 is prohibited. Table B. 51 represents the handling logic of a non-stop RegOp.

Iii. Self-modifying code handling

Store queue 270 provides several bits of physical and linear addresses for the data to be processed. If the store address matches any of the indication addresses of the Op quad, writing to the indication may modify the indication and the operation currently appearing (decoded) in the scheduler 280 may not be correct. Invalid operations must be corrected before the results from the operations are given.

In an embodiment of the invention, the self-modifying code support logic 536 compares the address bits from the store queue 270 to the instruction address of each Opquad (or if the instruction in the Op quad is from a different page). . If the comparison removes 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 given instruction. Logically, within the scheduler 280, the detection of the self-modifying code is treated as a kind of factor and trap into the signal indicating "trap pending". Table B. 52 shows self-modifying code handling logic 536.

Iii. Operation commit unit

Operation Commit Unit (OCU) 260 generally operates on an operation within the last row (column 4 or 5) or the last column of scheduler 280. The main functions of the OCU 260 are to give the result of the operation (or to make it permanent) and to withdraw the Op quad from the scheduler 280.

Many types of results or state changes can come from the execution of an operation. The main forms of change are breakable: register defense, status flag change; And memory writes. In the RISC86 instruction set, register changes come from all RegOp, LdOp, LIMMOp, LDK operations, and STUPD StOp. Status flag changes come from ".cc" RegOp and memory records come from STxx StOp. The scheduler 280 and store queue 270 temporarily store registers and statuses that are entries in the scheduler 280 and temporarily store memory records that are entries in the store queue 270 until an associated operation is given and withdrawn. Support for interruptible state changes by saving to. Operation commitments make state changes permanent. While new status values remain in scheduler 280 and store queue 270, the status values proceed to a dependent operation as needed.

All other state changes are non-interruptible and are obtained from non-interrupted RegOp execution. Non-interruptible state changes include changes to standard x86 registers, such as segment registers and non-status EFlag bits, and to micro-architecture registers for RISC operations. Non-interruptible state changes can occur immediately during non-interruptible RegOp execution, and decoder 240 and scheduler 280 are responsible for sufficiently synchronizing non-interruptible operations to surrounding operations.

Ⅷ.A commitment

During each cycle, the OCU 260 examines operations in rows 4 and / or 5 in the scheduler 280 and attempts to give as many results as possible. State changes in the op quads can be given in one cycle or more. If all operations of the Op quad of the lower row are given or are being given enough, the Op quad is withdrawn from the scheduler 280 at the end of the current cycle by causing the Op quad from column 4 to shift to column 5 and overwrite. Otherwise, as many changes as possible are given and shifting to row 5 is prohibited. The commitment process is repeated until all operations in column 5 are given and the Op quads in column 4 are shifted down to column 5.

The register result, status result, and memory write commit are executed independently. For operations with multiple results (eg RegOp with register and status results, or STUPD operation with register results and memory writes), the various results do not need to be given simultaneously. A commitment of one type of state change may generally precede or follow a commitment of another type of state change. The overall commitment of the operation is executed when the OCU 260 is given the last result from the operation.

The result of the operation is: until the operation execution status indicates completion of the operation; It is not given until the leading LdStOp completes, which means that the preceding foulable operation, BRCOND, was correctly predicted. The FAULT operation is not considered because decoder 240 does not need to complete each operation in the same column as a FAULE operation by placing each FAULT operation within the Op quad as the first "valid" operation. For StOp to generate memory writes, an additional restriction is that only one write per cycle from store queue 270 to data cache 220 can be given.

The OCU 260 can give four registers and four status results and one memory write per cycle, typically giving and withdrawing an Op quad from the scheduler 280 every cycle. The op quad remains in the bottom row of the scheduler 280 and is not withdrawn for more than one cycle if the op quad contains multiple memory write StOp or some operations in the op quad have not yet completed.

If an operation in a lower column needs to be fouled, for example, if the operation is a FAULT operation or a foul occurs during the execution of the operation, then the commitment of subsequent operations is prohibited. If all old operations within the op quad being fouled are being given or are being given enough, the OCU 260 withdraws the op quad and starts the chase cycle. The escape cycle flushes the scheduler 280 and execution units of all current operations.

At the same time as the escape cycle, the OCU 260 also sends the indication decoder 240 to one of the two possible encode "entry point" addresses, the "depost" pole handler address (which is initialized by reset encoding), Or "alternative" handler address (specified by macroinstruction or exception processing encode). LDDHA and LDAHA operations are loaded in the scheduler 280 as completed and recognized by the OCU 260 when they reach the bottom of the scheduler 280 and are " executed " and support the foul depot and alternate handler addresses. do.

Only certain types of operations are to be fouled, that is, LdOp, StoOp (except LEA operations), and FAULT operations. For LdOp or StOp, the foul is recognized by the second execution stage 460 of the LU or SU execution pipeline; If a foul is detected, LdStOp is held up in the second execution phase until an associated or unrelated escape cycle flushes LdStOp from scheduler 280 and execution unit 251 or unit 252. This result in the completed LdStOp guarantees foul-free. The OCU 260 distinguishes between the fouling LdStOP and the LdStOp not yet completed, because the signals from the execution units 251, 252 indicating the fouling operation are in their respective second execution phases. When the OCU 260 attempts to give the next incomplete LdStOp and associated execution unit 252 or 251 a foul signal for the operation held in the second execution step, the operation that the OCU 260 tries to grant is performed with the fouler. It must be an operation that has been met. If the associated execution unit 251 or 252 does not exhibit a foul signal, nothing can be determined that can be determined for an incomplete LdStOp and the OCU 260 waits until the LdStOp completes.

The FAULT operation is loaded into the completed state and always into the scheduler 280. The OCU 260 handles the commitment of the foul operation and the escape of the surrounding operation in the same manner as the LdStOp to foul.

In addition, to foul on a particular operation, the OCU 260 also recognizes various debug trap exceptions that are accumulated and stored until the end of the encode sequence indicated by ERET. If the "ERET" Op quad is withdrawn and the trap exception is pending, the OCU 260 starts a foul-style escape cycle once the foul has been recognized at the fifth and final operation in the Op quad.

The OCU 260 recognizes the "branch target restriction violation" condition, which is tagged with the Op quad while certain operations in the Op quad are involved. This unconditionally initiates an escape cycle if the foul is recognized on the first operation in the Op quad.

OCU 260 also handles BRCOND, while OCU 260 is primarily concerned with operations that produce an escapeable state change. BRCOND is determined when in column 4. If a false prediction is detected, macroinstruction fetch logic and instruction decoder 240 immediately resets and restarts from the appropriate macroinstruction address. If an incorrectly predicted BRCOND reaches column 5, operations that are newer than the incorrectly predicted BRCOND are forbidden, and the escape cycle starts later when all operations preceding the incorrectly predicted BRCOND are committed or committed. The escape cycle also enables the loading of "new" operations to cause immediate issue from decoder 240 to scheduler 280 into execution units 251-256. Mispredicted BRCOND and operation foul escape differ from no betting to take and encode a mispredicted BRCOND. Nothing needs to be done to commit the correctly predicted BRCOND reaching the bottom of the scheduler 280.

OCU 260 exits or commits each BRCOND. OCU 260 selects an action according to the BRCOND scheduler entry state field. When BRCOND is resolved, the scheduler entry state field changes to complete if correctly predicted and remains unissued if incorrectly predicted. Thus, whether BRCOND was completed in column 4 directly indicates whether BRCOND was incorrectly predicted.

The actual timing of the operation result commitment is relatively simple and can be thought of as occurring during the second half of the commit cycle. Typically, the Op quad is committed during the same cycle, falling to the bottom of the scheduler 280, and withdrawn from the scheduler 280 at the end of the cycle. During the cycle, the operand value proceeds to all dependent operations from scheduler 280 rather than register file 290 while the result is written to register file 290.

Committing memory writes are a two-step process executed in the form of a two-phase write commit pipeline. The first write commit pipeline stage corresponds to the commit cycle of the OCU 260 for StOp of the OCU 260 as long as the OCU 260 is considered, and StOp is committed when entering two stages of this pipeline. The timing-wise of StOp must enter the second write commit phase at the same time or prior to the withdrawal of the associated Op quad from scheduler 280. If StOp cannot enter this second phase, StOp is not considered committable and the revocation of the Op quad is held up.

When the OCU 260 starts an escape cycle because of an operation foul, the escape signal and the associated encode vector address are asserted during the commit / retract cycle of the op quad containing the foul operation. During the next cycle, the scheduler 280 It is flushed and the target encode Op quad is fetched. For internal encoding, the scheduler 280 will be empty for this one cycle.

The escape signal of the wrongly predicted BRCOND is also asserted during the commit / retract cycle of the associated Op quad. Because the instruction fetch and decode starts early, the scheduler 280 is reloaded into the new Op quad as soon as the next cycle. In other words, the scheduler 280 does not remain empty for one cycle.

When the OCU 260 recognizes multiple operations in the Op quad that are required by the escape cycle, it selects the first operation and starts the appropriate escape operation for the operation at the appropriate time of that operation.

Iii. A.1 Register Commitment

OCU 260 manages and controls the committing of register results to register file 290. During each cycle, the register result of each completed operation in one of the lower two rows of scheduler 280 may be written to register file 290 (via the four independent writers, during the second half of the cycle). Each write is performed according to the byte mark from the associated scheduler entry, shield DestBM [2: 0].

If the operation has not yet completed and is not committable, the associated register file is prohibited during this cycle. If the operation is of a type that conceptually does not produce a register result, the byte mark may all be cleared and the register number may not be determined. This result, not bytes, is modified during register file writing. Similarly, register t0 (the register always being zero) is specified in the direction of the operation, and the bike mark is cleared again. In these cases, the operation decoder 210 sets the byte mark to b000 during loading.

In general, there is a possibility of controversy, that is, multiple simultaneous writes to the same register. The required result comes from the latest operation, and old records are prohibited and effectively ignored. The register file 290 handles these functions based on the possible records associated with the register numbers indicated separately from the control of the register commitment process of the OCU 260.

In addition, since a competing record is an old record that modifies a register byte that is not modified by the latest record, an effective register file recording is a combination of bytes from a competing operation. For example, the first (oldest) operation modifies {3,2,1,0} bytes, the second operation modifies {1,0} bytes, and the third (latest) operation is {1 } Modify the byte, and the actual register file write takes {3,2} bytes from the first operation, {0} bytes from the second operation, and {1} bytes from the third operation. In other cases, part of the register file is not modified at all. Control logic in register file 290 handles this additional function. In practice, contention decision logic in register file 290 operates based on individual bytes instead of 32-bit words.

Possible records for all four operations are generated in parallel. Possible related writes are asserted in register file 290 for each completed operation if all the preceding / old LdStOp in the Op quad are completed and the preceding / old BRCOND is incorrectly predicted. When the result of the operation is written to register file 290, the associated DestBM bit is cleared to indicate that the scheduler entry no longer provides a register value for the dependent operation. Clearing of the DestBM field is also performed for partial register writes. If a dependent operation cannot obtain all the bytes required from one operation, the dependent operation is held up in the operand forward step until all bytes are obtained from the register file 290.

In addition, the nine signals OprndMatch_XXsrcY associated with the scheduler entry (see description above) are marked when the DestBM bit in that entry is about to be cleared (i.e., indicating no match). This is due to the pipeline nature of the register operand fetch process in scheduler 280. In particular, the DestBM bit of the entry must be used at both stages of this process and must match across both cycles.

To increase register commitment throughput, operation register writes are executed from column 4 when the register commitments of all operations in column 5 complete. This is done by generalizing the RegOp writeable logic to account for four operations in column 5 or four operations in column 4. The operation of the selected column is named "OpA" to "OpD" in place of Op20 from Op23 or Op16 from Op19. Table B.53 shows the logic for selecting the results for commitment to register file 290.

A.A.2 Status flag commitment

The OCU 260 also controls and manages the commitment of the status flag result generated by the ".cc" RegOp to the architectural EFlag register. Unlike the commitment of the register result, none of the status flag results of the operation from column 5 (up to four) are written to the EFlag until the Op quad in column 5 is withdrawn or tries to escape. Normally, if all operations in an Op quad are fully committed or fully committed, the executed overall result of cumulative or status results within all fours is recorded at the end of the cycle with EFlag when the Op quad is withdrawn from scheduler 280 do. For an op quad containing a fouling operation or an incorrectly predicted BRCOND, only the status result from the fouling instruction or the operation before BRCOND is committed and the cumulative result is recorded during the cycle escape or at the end of the cycle escape.

This process applies to the micro-architecture status flags (EZF and ECF) as well as the x86 architectural status flags. In particular, the architectural EFlag register is extended to 34 bits to make room for the two extra status flags. RDFGLG and WRFLG RegOp refer to the standard 32-bit portion of this extended EFlag register.

The generation of the cumulative status result is based on a status bit mark (StatMod [3: 0]) from each of the four entries in the lower column. The eight status flags are separated into four groups for the modification process instead of having eight individual bitmarks. By updating a general register in a register file, there is a possibility of contention, that is, multiple modifications to the same group of status flags. The required result is the latest revision of each group of status flags.

The generation of cumulative status results is also based on each completed status State [3] of four operations. For an escaped quad, the field state indicates which status result should be committed and which should not be committed. For commitments, all preceding operations must be completed and there are no fouls and mispredictions. Table B. 54 summarizes the logic of accumulating status flag changes.

No external control or restriction on operation commitment and withdrawal is required as long as the status flag results are considered. Because the status flag change comes from RegOp and every RegOp produces a register state change (even up to t0), the Op quad cannot be withdrawn until all RegOp in the Op quad is completed and thus has a valid status result. If the status flag value is advanced (with BRCOND and "cc-dependent" RegOp), there is no need to delete the StatMod field of the operation in the lower column.

A.A.3 Memory Write Commitment

The third function of the OCU 260 is to control the commitment of the memory write data values to " memory " (data cache and / or main memory). This differs in many ways from the commitment and status results of a register: the memory write commitment includes the associated steer queue entry (in most cases); One memory write per cycle is committed; The commitment process has a two-phase commit pipeline. OCU 260 scans the bottom two rows to find the StOp for memory write to commit.

Memory writes are all related to StOp (except for LEA, CIA, and CDA operations that do not actually reference memory). When StOp completes execution, the associated memory address and store data enters store queue 270. Later, when StOp's memory write is committed, this entry is read into cache memory and withdrawn from store queue 270. StOp is executed and committed to allow store queue 270 to act as a simple FIFO, and the matching of store queue entries associated with the scheduler StOp is automatic.

The actual commitment process is more complex and will be described below. In general, a two-step process is needed where the last / oldest store queue is read first and the address is looked up in the data cache 220; Based on the status of the lookup, store data is written into the data cache 220 and / or from memory. In the latter case, data and addresses are typically simply loaded into a write buffer and later written out of memory.

In a two-phase write commit pipeline, the first stage (ie, data cache tag lookup) corresponds to the commit cycle and status result of the register, i.e. the inclusion of the Op quad can be withdrawn at the end of the cycle of the stage. From the standpoint of the OCU 260, the commit process can be thought of as a single cycle / single step operation that succeeds or is delayed. The commitment of the memory write can be held up for the same reason as the change of the register state, and also held up if the write commit cannot enter step 2 of the commit pipe. When a write enters commit phase 2, the associated StOp can be withdrawn from scheduler 280, and the remaining commit processes are asynchronous to OCU 260 and scheduler 280.

During the first commit phase, no control decision is made. The data cache tag lookup is executed and the accessed tag data is latched for inspection during the second commit phase.

The write commit pipeline is a single pipeline and therefore supports the commitment of one memory write per cycle. For an Op quad containing one memory-write StOp, this allows for the withdrawal and commitment of the possible Op quads of each cycle (receiving the same kind as the same warning coming from the commitment of the register state change). For Op quads that contain two, three, or four StOp, it is necessary to commit the Op quads so that the corresponding minimum number of cycles remain at the bottom of the scheduler 280 for at least that number of cycles. do. The committing of the memory writes associated with the StOp in column 5 or column 4 reduces the holdup caused by multiple StOp in the Op quad. If the memory writes are committed in order, the OCU 260 can get a “head start” on the multi-write op quad when the bottom op quad is held up, otherwise the space of the uncommitted memory write or the bottom op quad Does not just contain StOp. This helps to better match one write commitment capacity of the OCU per cycle with the average number of writes per op quad less than one per op quad.

During each cycle, the OCU's memory write commit logic finds the oldest uncommitted memory-write StOp (ie, related to the next StOp and the write to be committed). The selected operation creates the current lower / oldest store queue entry. At the same time, by selecting the operation, the address of the oldest store queue entry is given to the data cache and the tag lookup begins. Note that this is done "blind", ie regardless of whether the associated StOp actually appears commitable.

If the selected StOp is commitable and the write commit can proceed to the second write commit step, the OCU 260 thinks that StOp should be committed. In the next cycle, the OCU 260 finds the next memory-write StOp. The criterion of the StOp commitment is the same as the register result commitment: the selected StOp must be completed, the LdStOp in all preceding / old Op quads (and the preceding Op quad if this StOp is in the last column) must also be completed, and the preceding / old wrong prediction There should be no BRCOND. Write commit can proceed when commit phase 2 has been emptied or has fully completed the commitment of recording.

If the selected StOp is not commitable because it is not completed, the OCU 260 checks the signal from the second SU execution step, indicating whether the StOP has "stuck" into the foul condition detected in that step. If there is such an operation, it is the same StOp that the OCU 260 attempts to commit, and therefore must be escaped by the OCU 260. The proper escape cycle does not start until StOp is in the bottom row, all preceding operations in the Op quad are committed, and the preceding BRCOND is not predicted incorrectly. This is essentially a committable extension of StOp. OCU 260, on the other hand, remains in this state for a preceding operation until the escape cycle begins.

OCU 260 is primarily related to memory-input StOps, but the operation is not related to handle CIA and CDA operations since OCU 260 generates a faultable memory address that must be detected and committed. In a typical case, such as an operation that executes fault-free, the OCU 260 moves to commit the next StOp in the next cycle and consumes a little cycle by the execution of the operation. Because a store queue entry occurs while the operation is running, the entry is not suspended from the store queue. If the fault is cleared while the CIA and CDA operations are being executed, the operation is "stuck" at the second SU execution stage and the OCU 260 stops exactly in the same form as other StOps.

A second special situation of OCU 260 occurs when StOp's memory reference is separated by storage unit 252 into two memory inputs that cross an alignment boundary (currently 8 bytes) and have two associated storage order entries. . In this situation, the OCU 260 takes two cycles to abort two storage queue entries without apparently committing StOp until the second cycle. If StOp has a fault, it stops without interrupting any stored queue entries.

The exemplary embodiment of the OCU 260 uses a mask bit (CmtMask [7: 0]) indicating the OCU progression of the committing memory-input StOp in the last two columns. Each of the eight mask bits CmtMask [7: 0] corresponds to eight entries in the last two columns. The first set of bits (starting at bit 0) correctly instructs the OCU 260 to commit StOps to the entry corresponding to the last clear bit and retrieve the corresponding entry. The entry corresponding to the last clear bit contains the next StOp that is committed. The entries corresponding to the set mask bits are retrieved for commitable StOp. OCU 260 persists the bits (UncmtStOp [7: 0]) indicating entries in the last two columns that contain uncommitted memory-input StOps.

During each cycle, the OCU 260 selects a StOp that was not next scheduled and generates a new set of mask bits based on the entry containing the StOp. Unmasked entries are checked to determine if the selected StOp is currently commitable or a pause cycle needs to be started. If the selected StOp is commitable and the stage 2 of the commit pipeline is available to accept new input commits at the end of the cycle. The UncmtStOp bit is updated / shifted to match the shift of the last two columns. Table B.55 in Appendix B describes the logic.

Ⅷ.B. Op Quad Exit

When a stopable state change of all operations has occurred or is occurring continuously in the bottom row of scheduler 280, DCU 260 terminates the Op quad from scheduler 280 at the end of the cycle. This causes the next Op quad to shift to the bottom row of the scheduler 280. Op quads are not terminated within a cycle in which not all the computational results occur, and are maintained for execution processing or invalidated to stop the cycle. If invalid, the stop cycle is subject to an error that is recognized by one of the operations in column 5.

In particular, the termination of the Op quad terminates all register results, status results, and executed memory inputs, and there are no mispredicted BRCOND or FAULT operations in the Op quad. If the Op quad is marked as invalid, the termination of the Op quad also occurs immediately. The scheduler's shift control logic handles this automatically. Status results are all performed in relation to the termination (or stop) of the op quad. Table B.56 shows the circuitry in the OCU 260 for the termination of the op quad.

Ⅷ.C. Fault adjustment

Ⅷ.C.1. Load calculation fault adjustment

LdOps does not require any special adjustments by the OCU 260 because LdOps are generally due to register state changes only. Like most StOps, LdOps may encounter errors while running. Special logic in the OCU 260 recognizes and handles LdOps faults in the same way as LdOps faults. To determine if a faulting LdOp exists in the bottom column of the scheduler 280, the OCU 260 retrieves the column 5 for the operation that is the LdOp with the previous / old operation completed and executed, and the preceding mispredicted BRCOND. Is not. The OCU 260 checks the signal from the load unit 251 indicating whether the LdOp with the detected fault condition is a "stuck" of the second execution stage of the LU pipeline.

If the LdOp in column (5) proceeds without completion by executing and completing signals and operations from the inserted LU stage, the OCU 260 recognizes the faulting LdOp and immediately takes the appropriate stop cycle to stop the next operation and LdOp. To start. Table B.57 shows the LdOp fault adjustment logic of the OCU.

C.C.2. Tuning FAULT and LDDHA / LDAHA Operations

Some special operations, FAULT, LDDHA and LDAHA operations require additional and special execution tuning. None of these operations are executed or issued by the execution unit. FAULT, LDDHA, and LDAHA operations are important only for the OCU 260 without having to perform execution dependent on other operations.

OCU 260 coordinates FAULT operations such as faulting LdStOp. The stop cycle begins by leading to the currently coded OCU fault handler. Unlike Fault LdStOp, there is no issue to recognize when there is a fault and when the pause cycle begins. To simplify the logic of the OCU for coordinating FAULT operations, the following constraints are applied on decoders 240 and 510: 1) The FAULT operation must be at the first operation position of the op quad, and 2) the next operation in the op quad. Must be "NO-OPs" (ie LDK t0, xx) and 3), and 3) the next Op quad must not contain memory-input StOps. Forbidden memory-input StOps from the next op quad ensures other OCU execution logic that can operate on the "FAULT" op quad without any special consideration.

The status of the FAULT operation begins with 'b0000' when loaded into the scheduler 280. When the FAULT operation reaches column 5, the incomplete state of the FAULT operation clears the OCU's op quad termination logic by stopping the op quad. Prohibit, OCU 260 FAULT operation execution logic starts a stop cycle The characteristics of the stop cycle are the same as the fault on LdStOps The difference is only the occurrence of a unique fault ID Table B.58 shows the stop for FAULT operations Represents the logic that generates the signal.

The LDDHA / LDAHA operation enables encoding to change and set the address of the encode ROM 246, which is an OCU-aware exception that leads the course. OCU 260 holds two vector address registers, one for having a "default" handler address and the other for having a "alternative" handler address. The first vector address register acts for fault encoding (macro instruction and exception processing encoding), and reset encoder via LDDHA operation (processor 200 executes a reset encoding for initialization after reset). Set only once by The second vector address register is set via an LDAHA operation.

For the encoding order from the vector decoder 244 (defined from the entry point via ERET) that does not include the LDAHA operation, the fault recognized by the OCU 260 on the operations in the sequence is the vector to the address of the fault handler address register. Due to being. For an encoding sequence that includes an LDAHA operation, the operational fault in the Op quad prior to including the LDAHA operation is vectored to the default address: however, the fault on the Op quad operation includes the LDAHA operation or the next Op quad. It is due to being vectored to the address of the second vector address register, including the last quad of the encoding order. Termination of the "ERET" Op quad until the next occurrence of the LDAHA operation effectively reactivates the default handler address register for the next operation. The occurrence of a pause cycle also reactivates the default handler address register.

To simplify the problem for the OCU 260, the LDDHA / LDHAH operation is forced to be at the oldest operation position of the Op quad. "Valid" operations are allowed at the next operation position of the op quad. Table B.59 shows the LDDHA / LDAHA operation handling logic of the OCU.

C.C.3. Target Limit Violation Handling

In addition to the execution of state changes associated with each operation in the op quad, the OCU 260 also recognizes the special state indicated for the op quad as a whole. When the MacDec 260 decodes a potential control command, and when a code segment limit violation is detected on the target address (after MacDec generates an Op quad and the Op quad is placed into the scheduler 280), the Op quad. Is marked to indicate something like a violation detected with respect to the op quad.

When the op quad reaches the OCU 260 and is executed, the set tag bit is recognized and the stop cycle begins without executing any state change from the operation in the op quad. Effectively, the entire op quad is faulted. If the FAULT operation is on the op quad, the effect is similar. Table B.60 shows the logic for handling branch target limit violations.

C.C.4. Mispredicted Branch Handling

In addition to the handling of various special cases and the execution of a stopable state change, the OCU 260 coordinates the occurrence of stop cycles for mispredicted BRCONDs. As discussed above, restarting of the command patch and decoder region occurs before BRCOND reaches the bottom of the scheduler 280. The scheduler 280 results in a stop as a result, and only the preceding operation to be executed is guaranteed. Because of the occurrence of a stop cycle for an operation fault, the stop does not start until all preceding operations have been executed. Table B.61 shows the logic for generating a break for a mispredicted branch.

Ⅷ.D. Stop cycle occurs

The OCU 260 generates stop cycles in two situations: recognition of an Op fault (on LdStOp or FAULT) and recognition of an incorrectly predicted BRCOND. The preceding section and Tables B.55, B.57, B.58, and B.61 span the generation range of signals that initiate a pause cycle (eg, signals StAbort, LdAbort, FltAbort, LimAbort, and BrAbort). This section describes relevant information and the generation of generic Abort signals.

The Abort signal is a combination of individual stop signals associated with the execution of a particular type of operation or state change. The associated encode vector address, which is defined only by the fault related stop and not by the BRCOND related stop, is FltVecAddr as described above. The stop signal flushes the scheduler 280 and all execution units 251 to 257 of all special operations and reinitializes these areas in preparation for detecting new operations from the instruction decoder 240. This is sufficient because the branch evaluation unit 257 restarts the instruction decoder 240 and x86 macro instruction patches and encodes in advance for the BRCOND related stops.

For an exception related stop, the instruction decoder 240 also needs to be restarted at the fault handler address. When an instruction patch / decode is restarted at the same time for an incorrectly predicted BRCOND and operation exception, the operation exception is given a large precedence. The generation of the appropriate restart signal and the vector address for the restart occur appropriately. When a fault related stop occurs, the OCU 260 also obtains information about the fault, that is, the x86 macro instruction program obtains the logical address of the x86 instructions that are effectively faulted into register SR4. Table B.62 shows the logic for generating OCU stop cycles.

Iii. Processing system

Embodiments of the present invention include a wide variety of processing systems, including substantially standalone and networked personal computer systems, workstation systems, multimedia systems, network server systems, multiprocessor systems, embedded systems, integrated telephone technology systems. And video conferencing systems. 11A-11C depict a schematic set of processing systems incorporating a superscalar processor 200 in accordance with the present invention having a bus configuration, memory hierarchy and cache configuration, I / O interfaces, controllers, devices and peripheral elements. . 11A through 11A illustrate a set of processing systems. Suitable forms for systems incorporating superscalar processor 200 include the following elements, cards, interfaces, and devices:

1. Image display device, monitor, flat display and touch screen;

2. pointing device and keyboard;

3. inter-processors, floating point processors, graphics processors, I / O controllers and UARTs;

4. secondary and tertiary storage, controllers and interfaces, cache, RAM, ROM, flash memory, static RAM, dynamic RMA;

5. CD-ROM, fixed disk, removable media storage device, floppy disk, WORMs, IDE controller, speed-IDE controller, SCSI device, scanner and juke box;

6. PCMCIA interfaces and devices, ISA buses and devices, EISA buses and devices, PCI local buses and devices, VESA local buses and devices, micro channel architecture buses and devices;

7. Network interfaces, cards and adapters for things like Ethernet, token rings, 10 base-T, twisted pairs, untwisted pairs, ATM networks, frame relays, ISDN, etc .;

8. Video cards and devices, 2-D and 3-D graphics cards, frame buffers, MPEG / JPEG compressed / uncompressed logic and devices, video conferencing cards and devices, and video cameras and frame capture devices;

9. Computers incorporating fax cards and devices, modem cards and devices, telephone technology cards and devices;

10. sound cards and devices, audio and video input devices, microphones, and speakers;

11. Data acquisition and control cards and interfaces, compressed and uncompressed logic and devices, encryption and decryption logic and devices; And

12. Redundant / default allowable elements and devices such as tape backup units, RAID, and ECC memory.

There are too many suitable combinations of the elements, cards, interfaces and devices (including comparable elements, cards, interfaces and devices listed above).

Networked personal computer 100 incorporating superscalar processor 200 is shown in FIG. 11A. Superscalar processor 200 is coupled to memory subsystem 120. Although memory subsystem 120 is shown as RAM, an alternative embodiment includes one cache or caches inserted between RAM and superscalar processor 200. The superscalar processor 200 and the memory subsystem 120 are included as part of the motherboard 101 of the computer 100. A series of adapters, interfaces, and controllers connect the processor 200 to the device and peripheral elements. The adapter, interface, and controller are typically coupled to the processor 200 as a card on the backplane bus of the motherboard 101. However, alternative embodiments may integrate individual adapters, interfaces, and controllers into the motherboard 101. The parallel interface 109 and the serial interface 108 are each a parallel port device (e.g., a printer such as the parallel printer 102, a tape backup unit, etc.) and a serial device (e.g., a modem 103, a pointing device). And a parallel port and a serial port for sending an interface signal to a printer). The hard disk / floppy disk controller 130 controls access to the hard disk 132 and the floppy disk 131. The LAN adapter 107 provides a computer 100 having a network that is interfaced to a twisted pair with a token ring network, local area networks such as 10 Base-T and 802.3 Ethernet. As with other adapters and interfaces, the LAN adapter 107 is coupled to the processor 200 as a card on the backplane bus of the motherboard 101.

In a network server configuration as shown in FIG. 11B when shown coupled to the level (2) cache 125 and the processor bus 123, the superscalar processor 200 may be a processor or a processor. Of particular interest. Each superscalar processor 200 is coupled to the system controller 150 and the memory controller 121 via the processor bus 123. The memory controller 121 provides a 64-bit interface to the memory 122 including an 8-bit parity interface for supporting error correction code (ECC). ECC memory is preferred but not optional. System controller 150 provides an interface (or bridge) between 64-bit processor bus 123 and 32-bit local bus 151. The local bus 151 is a high speed I / O bus, for example a VESA local bus (VL bus) or a peripheral element interconnect (PCI) bus. System controller 150 provides buffering to support the potential heterogeneous clock rates of processor bus 123 and local bus 151. System controller 150 may arbitrate for the use of two buses 123 and 151, and in some forms may support burst data transactions that intersect the two buses. The local bus 151 is connected to various local bus devices and elements (actually SCSI) adapters 170, IDE controllers 180, LANs (adapters 157 and bridges and peripheral controllers 160). The display adapter 112 is shown coupled to the low bandwidth ISA bus 161 because the necessity typically requires less repair in a network server architecture than a personal computer or workstation architecture.

The IDE controller 180 includes various controller forms (including IDE, enhanced IDE, ATA, and enhanced small device interface (ESDI) controller forms) for interfacing storage devices such as disks, tape drivers, and CD-ROMs. Indicates. The IDE controller 180 is connected to the tape backup unit 183 and two disks (hard disk 181 and floppy disk 182). An alternative architecture may interface the IDE / enhanced IDE CD-ROM via IDE controller 180, while CD-ROM 172 and CD juke box 173 may be a small computer system interface (see FIG. 11B). Interface is connected via SCSI).

SCSI adapter 180 provides a spare chain of various SCSI devices (scanner 174, CD juke box 173, scanner 2016, CD-ROM 172, and inexpensive disk (RAID) 171 in a good chain structure). Row) and the local bus 151. For practical purposes, a good chain of SCSI devices is shown as a bus in FIG. 11B. The LAN adapter 157 is an IEEE 802.x standard (e.g. 802.3 baseband ethernet on coaxial media, twisted and untwisted media pairs, 10 base-T, 802.3 wide area network, 802.4 token passing network, 802.5 token ring network). And other suitable network adapters such as those based on the Optical Fiber Distribution Data Interface (FDDI) standard. The ISA bus 161 is connected to the local bus 151 via a bridge with the peripheral controller 160 and, like the super I / O 135, has a multifunction I / O card, telephony technology card 136, display adapter ( It provides modular connections and 16-bit I / O buses for various peripheral elements, including 112). Super I / O 135 provides support for disk 131, parallel port 139, serial port 138, and pointing device 137.

The multimedia workstation architecture for the superscalar processor 200 is shown in FIG. 11C. Like the server architecture of FIG. 11B, the multimedia workstation architecture includes an organization of buses with various execution characteristics that each match a device and its associated elements. Those skilled in the art can make various changes in the bus organization of FIG. 11C. The memory bus 126 connects the bridge 129, the memory 128, the cache 127, and the superscalar processor 200. As with the network server architecture of FIG. 11B, various cache structures are suitable for multimedia workstations. The local bus 151 is preferably a high speed I / O bus, such as a VL bus or a PCI bus. The SCSI adapter 170, the LAN adapter 157, the graphics adapter 114, the sound adapter 190, and the motion video adapter 195 communicate with the superscalar processor 200 via the I / O bus 151. Is connected about. SCSI adapter 170, LAN adapter 157, and expansion bus bridge 160, along with components and devices, are comparable to the devices, components, and adapters described above with reference to FIG. 11B, respectively. In particular, SCSI adapter 170 is connected to various SCSI devices (actually disk 175, tape backup unit 176 and CD-ROM 172) in a good chain structure.

According to an embodiment of the superscalar processor 200, the superscalar processor 200 may include a multimedia unit 256 for executing multimedia extensions in the x86 instruction set. Referring back to FIG. 11C, a multimedia adapter, such as a sound adapter 190, a motion video adapter 195, and a graphics adapter 114 are connected to the superscalar processor 200 via buses 151 and 126, respectively. Provides high-bandwidth transmission for multimedia data between secondary storage devices (e.g., disk 175, memory 128, and multimedia adapters). Sound adapter 190 provides for sampling and synthesizing audio signals, respectively. Provide analog-to-digital (A / D) and digital-to-analog (D / A) interfaces The A / D and D / A interfaces of the sound adapter 190 are connected to the speaker 192 and the microphone 191, respectively. Suitable designs for sound cards are known to those skilled in the art and the sound adapter 190 is of such suitable design.

Motion video adapter 195 provides support for capturing and compressing video signals, such as, for example, video camera 196. In addition, the motion video adapter 195 provides a display device 198 such as a high resolution computer monitor, a high resolution television or a television with a display signal via the frame buffer 197. An alternative embodiment of the motion video adapter 195 may remove the frame buffer 197 and drive the raster display directly. Moreover, alternative embodiments of motion video adapter 195 separate the video input and video output functions of the motion video adapter and instead provide separate video input and video output configurations.

Video information is generally compressed because it requires a large amount of storage space. Thus, to display the compressed video information from the data appearing on the compact disc of the CD-ROM 172. Compressed video information should be decompressed. Highband burst mode data transmission is supported by I / O bus 151, which is preferably a local bus such as PCI that supports for any length of burst data transmission. Video compression and decompression may be performed by the scheduler processor 200 (executing multimedia functions in the multimedia unit) and / or by the motion video adapter 195. Thus, memory bus 126 and bridge 129 preferably support burst data transfer across bridge 129 between memory bus 126 and I / O bus 151.

Iii. conclusion

Although the present invention has been described above with reference to specific embodiments, the detailed description is only an embodiment by the applicant of the present invention and is not intended to be limiting. Various applications and combinations of embodiments are known within the scope of the present invention.

Appendix A: RISC86 ^TM construction

This appendix describes Opcodes according to the RISC86 ^™ syntax described in FIG.

Definition of RegOp

Bits 36 and 37 of the opcode go to 00 to identify RegOp. Bits 10 and 11 are not used and should be 00.

A.1 RegOp type field encoding

Mnemonics separated by "/" have the same type field and are treated identically by register units 253 and 254. These RegOps are represented by fields (Ext, SS) and differ in the state modifications performed by OCU 260.

The type field is interrupted differently based on the field DSz. As mentioned above, the execution unit executes one operation for the byte size RegOp and another operation for the 16/32 bit size RegOp.

All byte sizes RegOps and all RegOps with type fields of the form x1xxxx, 1x1xxx, or xx01xx are RUX only operations.

The hardware treats all RegOps with type fields of the form xx01xx as being "cc dependent", thus synchronizing to the state operands that carry the execution of the operation.

A.2 RegOp Extended Field Ext [3: 0]

In MOVcc Op's, {Type [0], Ext [3: 0]} specifies a 5-bit status code.

In RDxxx / WRxxx Op's, {Type [0], Ext [3: 0]} specifies a 5-bit special register number. In WRFLG (.cc), if ".cc" is specified, the encoded spec register number matches the required StatMod value. In RDSEG Ops, Ext [3: 0] specifies a 4-bit segment (selector) register. The set of segment registers includes x86 structure registers and additional special segment registers.

The OS segment register is replaced at Op decode time by the current 3-bit register number from the copy environment.

In another operation with field (SS = 1), {Type [0], Ext [3: 0]} specifies four state modification bits (as stored in scheduler 280).

A.3 RegOp Operation / Data Size Field DSz [2: 0]

Field Dsz represents the data size for the operation.

The size (DSize, ASize, SSize) becomes a placeholder that is replaced by the corresponding environment variable during environment substitution.

A.4 RegOp RUX-only field R1

R1 is set to indicate that RegOp can only occur with the register unit 251.

A.5 RegOp Destination Field Dest [4: 0]

Fields Dest [4: 0] have a 5-bit general register number that identifies the destination register for the operation.

A.6 RegOp First Source Field Scrl [4: 0]

Field Scrl [4: 0] has a 5-bit general register number that identifies the first source register for the operation.

A.6 RegOp Set Status Field SS

Field SS is set to indicate that the operation modifies the status flag indicated by field Ext.

A.6 RegOp Field I

Field I indicates whether field Imm8 / Src2 contains an instant value or register number.

A.6 RegOp Field Imm8 / Src2 [7: 0]

Field Imm8 / Src2 has a temporary value or register number of the second source operand. If I = 0, Imm8 / Src2 [4: 0] contains a 5-bit register number. If I = 1, Imm8 / Src2 [7: 0] specifies an 8-bit sine instantaneous value that becomes a sine extended to the size indicated by field DSz.

LdStOp Definition

Bits 37 and 36 of the opcode are 0 and 1 to indicate LdStOp.

A.7 LdStOp Type Field Type [3: 0]

A.8 LdStOp address calculation size field ASz [1: 0]

Before encoding the environment substitution, the fields ASz [1: 0] represent the following address calculation sizes.

Encode environment substitutions change ASize, SSize, or DSize to an appropriate fixed size.

A.9 LdStOp Data Size Field DSz [1: 0]

A.10 LdStOp Data Field Data [4: 0]

Field Data represents the 5-bit general register number of the storage source or load destination register.

A.10 LdStOp Segment Field Seg [3: 0]

Fields Seg [3: 0] identify the segment register.

A.11 LdStOp Base Operand Field Base [3: 0]

The field Base contains a 4-bit register number representing the general register in the lower half of the register file. The value from the register becomes the base for address calculation.

A.12 LdStOp Index Field Index [3: 0]

The field Base contains a 4-bit register number representing the general register in the lower half of the register file. The value from the register is added to the base during address calculation and used as the scaled address index.

A.13 LdStOp index scale factor field ISF [1: 0]

Field ISF indicates that the index should be scaled by the factors 1,2,4, or 8.

A.14 LdStOp Large Displacement Field LD

Field LD indicates whether the operation uses a large (32-bit) displacement from LIMMOp or a small (8-bit) displacement from field Disp8.

A.15 LdStOp Small Displacement Field Disp8 [7: 0]

Field Disp8 [7: 0] contains an 8-bit displacement that becomes a sine extended to the size indicated by field ASz.

LIMMOp definitions

Bits 37 and 36 of the opcode are 11 to indicate LIMMOp.

A.16 LIMMOp Immediate Fields ImmHi and ImmLo

Fields ImmHi [14: 0] and ImmLo [16: 0] contain the most significant 15 bits and the least significant 17 bits of the 32 bit immediate value, respectively.

A.17 LIMMOp Destination Field Dest [3: 0]

Fields Dest [3: 0] store a 4-bit register number indicating the destination for an immediate value.

Note: The standard NO-OP is "LIMM t0, <undefined>", which is loaded into the scheduler on completion and is written using the immediate value <undefined> to a register (t0) that does not change by writing.

SpecOp definition

Bits 37 and 36 of the Opcode are 10 to indicate SpecOp. Bit 35 is defined in this appendix but is set for explicit SpecOps in FpOps.

A.18 SpecOp Type Field Type [3: 0]

A.19 SpecOp Status Code Field cc [4: 0]

Fields cc [4: 0] contain a 5-bit status code for the BRCOND operation. Bits cc [4: 1] specify the state to be tested as follows.

Bits cc [4: 0] specify whether the state or its components are computed.

In the above definitions, "to", "˙", "+", and "^" represent logical NOT, AND, OR, and XOR, respectively. OF, SF, ZF, AF, PF, and CF are standard x86 status bits. EZF and ECF are mimic zero flags and mimic rounding flags that the encoder uses as a sequence to implement the x86 instruction when the structural zero flag ZF and the rounding flag CF do not change. IP, DTF, and SSTF are signals representing interrupt pending, debug trap flags, and single step trap flags, respectively.

Branch states STRZ and MSTRC are logically identical and are used to implement x86 instructions, such as the move string instruction MOVS. In such x86 instructions, the MPEG stores the index in a register and creates a loop that ends with BRCOND. Each loop iteration shifts the chunk of data and reduces the index. Branch prophecy initially predicts that BRCOND will branch to the beginning of the loop. State MSTRC indicates that branch calculation logic 257 signals instruction decoder 240 when the index reaches a predefined point near the completion of the x86 instruction. Decoder 240 then changes the branch prediction of BRCOND that is loaded into scheduler 280. Thus, mispredicted branching and related abandonment can be avoided when the looping is complete. This improves processor validity.

A.20 SpecOp Data Size Field DSz [1: 0]

The fields DSz [1: 0] indicate one byte, four bytes, or DSize, which are data sizes of the load constant operations LDK and LDKD.

A.21 SpecOp Destination Field Dest [4: 0]

The field Dest has a 5-bit register number that is the destination of the operations LDK and LDKD.

A.21 SpecOp Immediate Value Field Imm17 [16: 0]

Field Imm17 [16: 0] contains a 17-bit constant and contains an immediately signed 17-bit or 14-bit op address.

General register definition

There are 24 integer general registers. The first eight registers correspond to x86 general purpose registers (AX to DI). The remaining 16 registers serve as temporary or scratch registers used in multiple operation sequences that implement CISC instructions. Operations using 5-bit register numbers can access 32 registers, and the remaining register numbers not used in integer registers can be multimedia registers or placeholders for environment variable substitution.

The x86 integer register set aids addressing for one of the two lower half bytes of the register (AX, CX, DC, BX). Based on the register size description, the 3-bit register number in the x86 instruction is translated as a hi / lo byte register or a word / dword register. In prospective operations, this size is specified by the ASz or DSz fields of the operation (base and index registers of ASz or LkStOps; and generally DSz, Srcl, and Src2 registers of Data / Dest). The scratch integer register set again helps with similar low-byte addressing of half of the registers (t1-t4 and t8-t11).

The following table maps register numbers from 1 to 24 into named registers.

The mnemonics "t0" and "_" can be written on top of it, but they become synergy in registers that always return zero when read. "_" Is generally used in situations where an operand or a result is ignored. As indicated above, register t0 cannot be referenced in byte mode.

Appendix B: Pseudo-RTL Description

The tables in this appendix describe the logic for generating signals used through embodiments of the processor 200. Each table may use the signals described in the other table with or without further description of the other table. The signals described in this appendix are assumed to be highly active unless otherwise indicated.

The following notation is used. "-" Represents the complement or inverse of the signal as provided by the inverter. Signals connected via "˙", "", and "&" are combined as a logical AND, as may be implemented by an AND gate. Signals connected via "+" are combined as logical OR gates, as may be implemented by OR gates. Signals connected via "^" are combined as logically exclusive OR, as may be implemented by an XOR gate. The notation "if (a) x = b else x = c" or "if (a) x = b: c" indicates that if signal a is assumed output signal x is equal to signal b and signal b is c Represent the same multiplexer as If " else x = c " is omitted, the signal x becomes low if the signal a is low. Another notation is that if the output signal x has a value x1 or x2 or ... xn dependent on the value of the multi-bit select signal A, then the multiplexer will return "x = switch (A) case A1: x1 case A2: x2 ... case An: xn ". When the case is omitted such as "x = switch (A) x1: x2: ... xn", the output values of x1 to xn correspond to the ordered signal values. Most of the signals described change each clock cycle. The notation @ (clock) indicates that the signal is latched into a register at the edge of the signal clock for use in subsequent clock cycles.

As will be appreciated by one of ordinary skill in the art, the logic described below may be implemented in a number of ways.

Table B.1 Static Field Memory Operation

Table B.2 Dynamic Field Memory Operation

The global control logic 520 of the scheduler 280 generates an independent signal LdEntry [i] that selects the signal loaded into each flip-flop.

The notation xxOp.yyy refers to the input signal to the operation decoder 510 representing the value from the field yyy defined in the xxOp type RISC86 instruction. For example, RegOp.Srcl refers to the bits in the instruction at the same location as the Srcl field of RegOp. In FIG. 3, and Appendix A defines example field definitions for RegOp, LdStOp, LIMMOp, and SpecOp.

Table B.3 Field Types

"RUYD" is a special register that disables the second register unit RUY for debugging.

Table B.4 Field LD_Imm

Table B.5 Field SrclReg

Table B.6 Field Src2Reg

Table B.7 Fields SrcStReg

Table B.8 Fields DestReg

Table B.9 Fields SrclBM, Src2BM, and Srcl2BM

Table B.10 Fields SrcStBM

Table B.11 Field OpInfo

The operation decoder 510 initializes field State [3: 0] as b0000 (not generated) or b1111 (not completed) according to the OpId field of the corresponding RISC86 instruction.

Table B.12 Status Fields

Table B.13 Field Execl

The operation decoder 510 initializes the field Execl low.

Execl = X

Subsequently, the field Execl is changed as follows.

if (S0Enbl) Execl = IssueOpToRUX

Signal IssueOpToRUX is generated in the entry during the issue selection scan chain for register unit 253.

Table B.14 Fields DestBM

The operation decoder 520 initializes the field DestBM in accordance with an operation indicating that the byte of the destination register will be modified.

The field DestBM becomes clear as follows:

if (SC_Abort) DestBM = 3'b0

Table B.15 Fields DestVal

Arithmetic decoder 510 generates field DestVal from the associated RISC86 instruction using the following logic.

Subsequent execution of the operation field DestVal changes as follows.

At this time, the signals DC_DestRes, SU1_DestRes, RUX_DestRes, and RUY_DestRes are generated from the execution unit that performed the operation.

Table B.16 Field StatMod

The operation decoder 510 sets the field StatMod in accordance with the associated operation.

Table B.17 Field StatVal Generation Logic

The field StatVal is initially zero.

StatVal = 8'bX

It is changed when RegOp completes.

if (~ S3 · S1) StatVal = (Execl)? RUX_StatRes: RUY_StatRes

Table B.18 Fields OprndMatch_XXsrcY

The field OprndMatch_XXsrcY passes information from the issue stage to the operand transfer stage of each processing pipeline (or from stage 1 to stage 2 of SU in one case) and the values are controlled by the global signal XXAdvY (especially XXAdv0 or SUAdv2). .

Table B.19 Field DBNs

The field DBN has an initial value of zero.

DBN = 4'b0

And during execution it changes to

if ((AdvLU2 + AdvSU2) ... S3S2) DBN [3: 0] = (DBN_LU [3: 0] LU) + (DBN_SU [3: 0] SU)

Table B.20 Op Quad Field Emcodes

Table B.21 Op Quad Field Eret

Table B.22 Op Quad Field FaultPC

Logical PC on x86 first decoded on op quad

Table B.23 Op Quad Fields BPTInfo

Information from Current BPT Access

Table B.24 Op Quad Field RASPtr

Current return address stack

Table B.25 Op Quad Field OpQV

The operation decoder 510 initially sets the field OpQV to indicate whether the op quad loaded into the top of the scheduler 280 is valid.

This multiplexer is not the only one; All new Op quad fields from similar (but 3: 1) multiplexers refer to the OCU description for an explanation of ExcpAbort.

The field OpQV can be clarified after giving up to invalidate the op quad and prevent execution.

Table B.26 Op Quad Field LimViol

LimViol = 'b0

Field LimViol is actually loaded one cycle after all the other fields described above (i.e. during the first valid cycle, a new Op quad is present in the scheduler). This is reflected in the above description of this Op quad.

Table B.27 Shift Control Logic

As described with reference to FIG. 6, control loading column 0 (with the new op quad) into loading column 5 (with the op quad from column 4). In this table, the input signal OpQRetire from the OCU 260 indicates when a valid op quad in the lowest column of the scheduler 280 can be terminated, and the input signals HoldOpQ3, HoldOpQ4A, and HoldOpQ4B show the status code calculation in column 3 or column. Indicates whether the operation was postponed at 4.

Table B.28 Single-Entry Issue Scan Terms

Single-entry terms are:

Here, "State = Unissued" is -S0, and "Executable by xx" is the same as the execution pipeline LU / SU / RUX / RUY, respectively. The same type bits LUi, SUi, RUi, RUXi as used are: LU = 1 in LdOps; SU = 1 in StOps (including operations like LEA); RU = 1 in all RegOps; And RUY = 1 in RegOps executable by RUY.

Table B.29 LU, SU, and RUX Look Ahead Scan Chains

The six single-entry signal forms the four group propagation signal XXPgrp [3: 0] and the group kill signal XXKgrp [3: 0] for scan chain XX when XX is LU, SU, or RUX. Each group signal corresponds to a quadrant section of the scheduler 280. The following is a group signal of a first quadrant interval (quadrant interval 0) containing entries 0-5 for one of the scan chains.

Where P0 to P5 and K0 to K5 are the single-entry terms of 6 consecutive entries and pipeline XX.

The group contains the selected instruction if the group kill signal XXKgrp is assumed, and older groups clear the scan bit. Bits from XXIssueQuadrant [0: 3] are assumed to identify the group containing the operation selected for the issue into pipeline XX. The signal XXIssueQuadrant [0: 3] is generated as follows.

The signal IssueToXX [i], if present, represents the operation issued to the pipeline XX and is generated from the signal IssueQuadrant and the single-entry kill term IssuableToXX as follows.

Table B.30 RUY Scan Chains (3-bit Group)

Single-entries P, K, O, and G are combined to yield group terms Ggrp [7: 0], Pgrp [7: 0], and Ogrp [7: 0] for 8 groups of 3 entries. In group 0, the group term is:

Where x, y, and z identify the oldest, middle, and most recent entries in group i, respectively. The single entry G term is a bit of the signal IssuableToRUX [23: 0], and the single-entry K term is a bit of IssuableToRUY [23: 0].

Group terms are combined at the stage to form a larger group of group terms. The following operation describes the logic to combine group terms GX, OX, PX, GY, OY and PY to form a group term of group XY, which is a combination of group X and group Y.

GXY = GX, PY +-OX, GY

PXY = PXPY

OXY = OX + OY

The signals CinGrp [6: 0] and OinGrp [6: 0] are the output from the combination. Signals CinGrp [6: 0] become signals G_7, G_67, G_567, G_4567, G_34567, G_234567, and G_1234567, and output signal OinGrp [6: 0] is signals O_7, O_67, O_567, O_4567, O_34567, O_234567, and O_1234567 Becomes

One bit of the signal IssueOpToRUY [23: 0] is assumed to identify the selected entry. The following equation describes the logic for generating the signal IssueOpToRUY.

Table B.31 Operand Information Broadcast

Each entry produces signals Src1Info and Src2Info that describe the source operands of the operations contained in the entry.

Src1Info [7: 0] = {Src1BM [2: 0], Src1Reg [4: 0]}

Src2Info [7: 0] = {Src2BM [2: 0], Src2Reg [4: 0]}

If the operation is selected to issue, the entry drives signals Src1Info and Src2Info on the operand information bus associated with the execution unit in which the operation is to take place. The signal OprndInfo_XXsrcY is a signal actually transmitted by the operand information bus associated with the source operand Y of the execution unit XX, and is generated as follows.

Table B.32 Operand Information Match Comparison

The following equation summarizes the mixed comparison:

Where "XXsrcY" is one of LUsrc1, LUsrc2, SUsrc1, SUsrc2, RUXsrc1, RUXsrc2, RUYsrc1, and RUYsrc2, and "bus" refers to the signal OprndInfo_XXsrcY on one bus of operand information bus 552. Byte notation checking does not include BM [2] as a simplification and exchange. BM [2] = 1 means (BM [1] BM [0]) = 0, so if busBM [2] = 1, the match is signaled without considering DestBM [2].

Table B.33 Operand Information Broadcast

The following equation summarizes the readout of the OpInfo field from the entry containing the generated operation. According to the following equation, each entry produces a signal OpInfo_LU, OpInfo_SU, OpInfo_RUX, or OpInfo_RUY on an operation information bus corresponding to the LU, SU, RUX, or RUY pipeline.

Only the entry containing the generated operation drives a signal on bus 551.

The signal XXAdv0 controls these external pipeline registers in the same way that they control internal registers.

Table B.34 Operand Selection Scan Chain

The single-entry term is for 8 scan chains LUsrc1, LUsrc2, SUsrc1, SUsrc2, RUXsrc1, RUXsrc2, RUYsrc1, and RUYsrc2.

The group term of the 4-bit group is formed as follows.

Instead, 3 or 6 bit groups can be used.

Each entry contains a logic signal that generates a signal SupplyValueToXXsrcY indicating whether the entry provides operand srcY to execution pipeline XX.

XXsrcYchain.CIN and XXsrcYchain.K are the kill terms in the entry in the scan chain that correspond to the input scan bit signal and the operand srcY of pipeline XX.

Table B.35 Actionable Logic for Operand Transfer

Each entry has 8 drivers corresponding to 8 operand signals Oprnd_XXsrcY to be transmitted. The entry allows the driver to supply the result of the operation if the signal SupplyValueToXXSrcY is assumed during the operand selection phase.

The register file 290 allows the driver to supply the signal Oprnd_XXsrcY if the scan bit output from the scan chain is set.

Table B.36 Operand Information Signals

The entry providing the operand also provides the operand status signal as follows.

The executable signal for the operand driver makes the driver executable on the operand status signal as follows.

Register file 290 drives operand status bus 553 that is not among the entries selected to provide an operand corresponding to the operand status bus. The operand status signal from the register file 290 has the following form.

The logic that enables the register file 290 to drive the operand status bus 553 is summarized as follows.

Table B.37 Potential Transmission

During the operand transfer stage, the potential transfer from the entry is made possible by the previous entry in the scheduler 280 or by the entry. Next, the transmission of the signals Disp_LU and Disp_SU to the load unit 251 and the storage unit 252 is summarized.

The values "thisOp" and "nextOp" identify the physical entries from the following signals LU, S1, S0, and LD. Also, for the first / last entry in the scheduler 280, the NextOp term is zero.

Table B.38 Immediate Value Transfer

The driver provides the immediate value to the register units 253 and 254 as follows.

The following equation summarizes the enabling of separate buses for operand status signals.

Table B.39 Selecting and Sending Data Operands

During the operation selection step 456, each entry determines whether it is in the execution stage 450.

"Select for data operand fetch" = SU-S2S1

During the data operand broadcast stage, an entry containing an operation determined to be in execution stage 450 generates data operand information as follows.

Each entry determines from the data operand information signal whether the entry includes an operation that affects the source register of the data operand. The data operand match register in each entry latches the value OprndMatch_SUsrcSt indicating whether the entry affects the data operand source.

Where "bus" quotes OprndInfo_SUsrcSt.

During operand selection step 461, the scan chain starting from the selected entry selects the source of the data operand. The source is the newest advanced entry affecting the source or register file 290 of the data operand if there is no previous entry affecting the data operand. The scan chain has a single-entry scan term:

P = K = OprndMatch_SUsrcSt

G = SU-S3S2

The group level scan equation is the same for other operand selection scan chains as in Table B.34, where each entry determines whether an entry is selected from an input scan bit and a kill term for the entry.

During the data operand transfer step 462, the driver in each scheduler entry is enabled as follows.

If no driver in the entry is executable, the driver in the output of the register file becomes executable as follows.

The data operand Oprnd_SUsrcSt sent over bus 554 is obtained in register 1052 in storage unit 252. During the data operand transfer step 462, the control logic 520 uses the read operand status value.

Table B.40 Load-Store Ordering Scan Chains

The load-store ordering scan chain has a single-entry propagation / kill (P / K) term based on the State and Type fields of each entry. In a 3 LdOp scan chain, the ST Type bit is used instead of the SU bit. This distinguishes StOps, which actually quotes memory from a LEA operation that only generates logical addresses. LUst2 / LUst1 / LUst0 and SUld2 / SUld1 represent the respective scan chains for load unit 251 and storage unit 252.

Single-entry terms for the scan chain are:

The group look-ahead term (based on four groups) is:

The scan bit input signal for the op quad is:

During the second stage 462 of the execution stage 460 of LdStOp, 2/3 scan bits Cin's into the entry holding LdStOp are combined with a 24: 1 multiplexer as follows.

The scan bit Cin is translated if the global signal is one if the associated stage is driven with the global signal resulting in an older operation.

Table B.41 Information from the Scheduler to External Logic

The following summarizes the information for reading the scheduler 280 at various times for external use.

During the operand information broadcast phase:

During the operand transfer phase:

Attention: XX = {LU, SU, RUX, RUY}; Y = {1,2}

Table B.42 Operation Valid Bits

The following summarizes the OpV bits in the issue stage of the four execution pipeline.

Table B.43 RegOp Bumping

Global control logic 520 includes logic to generate signal BumpRUX / Y as follows. Below is a section dealing with what could otherwise be a deadlock situation.

The signal InhBumpRUX inhibits RegOp bumping if the operand transfer stage becomes a RUX-only operation and the RegOp to be generated is also a RUX-only operation.

InhBumpRUX = OpInfo_RUX (RegOp). R1OpV_RUX_IssOpInfo_RUX_0 (RegOp) .R1

The signal BumpRUX is assumed to bump RegOp outside the operand transfer stage of the execution unit 253 if not prohibited, and either one of the source operations is not generated or the LdOp or timeout signal in the operand transfer stage is held for longer than the timeout count. It is assumed in response to RegOp in the operand transfer stage.

The signal BumpRUY bumping RegOp out of the second register unit 254 cannot be inhibited, otherwise it is assumed for the same reason as the signal BumpRUX.

Table B.44 Operand Transport Multiplexer Control

The following equation summarizes the five input selection signals for each operand multiplexer. Global control logic 520 uses operand status signals on bus 553 to select either operand bus 554 or result buses 561-564 to provide operands. In most operands, operand bus 554 is selected if the source operation is complete.

SelOprndBus_XXsrcY = State [3] + State [2] · Type [1]

In the second operand of RegOps, the operand bus is selected if the source operation is complete or if the operand is an immediate value.

Where signals RUXsrc2Imm and RUYsrc2Imm indicate that the src2 operand is an immediate value.

The resulting bus from one of the execution units 251-254 executing the source operation is selected if the operand bus 554 is not selected.

The selected operand may not be valid. The execution unit prevents the use of invalid operands by preventing the associated operation from proceeding from the execution stage 450.

Table B.45 Identification of Invalid Operands

Global control logic 520 is generated from bus 553 to generate signal OprndInvld_XXsrcY indicating whether operand srcY (Y = {1,2}) for execution unit XX (XX = {LU, SU, RUX, RUY}). Use the operand status signal of.

OprndInvld_XXsrcY = -State [1] + -Type [1]-(-State [2] + -State [3]-CHP_LUAdv2) + SrcYBM [2]-DestBM [2] + SrcYBM [1]-DestBM [ 1] + SrcYBM [0] · DestBM [0]

Table B.46 Hold Signal Logic

Hold signal SC_HoldXX0 is generated to prevent the operation from proceeding to execution stage 450 if the requested operand is invalid. StOps is allowed to proceed to the execution stage even though the data operand is not yet valid because no data operand is required until the second execution stage 460. If the data operand is still not valid, the signal SC_HoldSU2 holds the operation at execution stage 460.

Table B.47 Status Flag Groups

The standard x86 status flag bits OF, SF, ZF, PF, CF, EZF, and ECF are divided into four groups corresponding to the bits of the signal STATUSV and field StatMod as follows.

Table B.48 Status Flag Extraction

Each entry 16 to 23 generates signals StatInfo_1, StatInfo_2, StatInfo_3, and StatInfo_4 corresponding to four flag groups and representing the status flags and validity bits of the four flag groups. One or more of the signals StatInfo_1, StatInfo_2, StatInfo_3, and StatInfo_4 are used to generate signals STATUS and STATUSV if the entry is selected by the scan chain of the corresponding group. In the following, the prefix "OPj:" denotes a field or signal type entry j.

The structural status flag register generates the signals FlgStatInfo_1 and FlgStatInfo_2.

The following logic represents a 4 scan chain without lookahead for locating entries to provide a flag group.

The output status flag information signal is:

Table B.49 cc-RegOp Processing

The signal CCDepInRUX_0 indicates whether cc-dep RegOp is in the operand transfer stage of the register unit RUX and is generated from a pipeline register containing operation information and valid bits for the operation at the operand transfer stage.

CCDepInRUX_0 = (OpInfo_RUX_0 (RegOp) l.Type [3: 2] = 'b01) · OpV_RUX_0

The signal UnexecCCDepInQ3 indicates whether an unexecuted cc-dep RegOp is in column 3, and is generated from the type and status bits in the entry of column 3.

The following logic determines to generate a signal StatV indicating whether the group of status bits required for RegOp is valid at the operand transfer stage.

The signal StrtExecCCDep keeps track of when an unexecuted cc-dep RegOp is in column 3.

The signal UnexecCCDepInQ4 keeps track of when the unexecuted cc-dep RegOp is in column 4.

From the RUX unit, the signal RUX_NoStatMod indicates that the operation to be executed does not modify the status flag. The cycle delay version is called NoStatMod.

Table B.50 BRCOND Processing

The following equation describes BRCOND processing. Reference is made under the signals DTF and SSTF, which are signals representing breakpoints and single-step traps, respectively. A signal MDD of "no multiple decode" can be used to debug to prevent one or more macro instructions from being inserted into the scheduler 280 at a time.

The BRCOND process first determines whether BRCOND is in column 4. The signal BRCONDj indicates whether OPj is a BRCOND not calculated.

Where j is an entry number and Type, OpInfo, and S3 are fields of entry j. Signal BRCONDInQ4 indicates whether column 4 contains BRCOND.

If BRCOND is in column 4, the predicted condition code is (SpecOp.cc) from the field OpInfo of the entry containing BRCOND.

The value of the signal CondCode [4: 1] is defined as follows (bit CondCode [0] responds to the senses):

The signal CondV indicates whether the status bit required for the calculation of BRCOND is valid.

The signal HoldOpQ4A prohibits the shift of the op quad in column 4 if BRCOND is in column 4 and the conditions required for the calculation are not valid.

Here, the signal IP is defined as IP = SI_NMIP + SI_INTRP, and indicates whether there are any active h / w interrupt requests.

The signal SC_Resolve indicates a solving condition branch.

The register writes a Signal Resolved that represents the resolution of BRCOND in quad 4.

The x86 MOVS (move string) instruction is decoded into the encode loop of the operation. To improve the speed at which MOVS instructions are performed, a full 32-bit transfer is performed until the byte count of the loop is less than or equal to four. The condition BRCOND is used in the check of counts for MOVS. The signal TermMOVS ends the encode loop if the moving string is nearly performed.

The signal BrVecAddrssm from the field DestVal for BRCOND indicates the MPEG or instruction vector address to be used if the branch is mispredicted.

The signals SC_OldRASPtr, SC_OldBPTInfo, and SC_RestartAddr are sent to restart the instruction decoder 240. Restarts may be generated in response to mispredicted branches or faults. The signal SC_OldRASPtr from the field RASPtr of the entry that is mispredicted or faulted is for restoring the RASTOS pointer. Signal SC_OldBPTInfo represents clear branch prediction table information for correcting branch prediction table. The signal SC_RestartAddr indicates a program counter according to restart.

The signals BrVec2Emc and BrVec2Dec indicate that a restart is required because of the mispredicted BRCOND in the case of an encoder or BRCOND from MacDec 252.

The register records false prophecies:

If BRCOND was not predicted correctly, BRCOND is marked complete as follows.

Successfully resolved BRCOND can settle in column 4 for more than one cycle because column 5 can shift, preventing column 4 from shifting. During this time, the signal SC_Resolve is assumed, and one of the signals BrVec2XX is assumed for the entire time (for five cycles) and remains on the bus 558. The instruction decoder 240 continues to restart each cycle until the signal BrVec2XX is indeterminate. All other related signals, such as vector addresses, maintain their proper values through this time.

Table B.51 Non-Givable RegOp Processing

The signal NonAbInRUX_0 is assumed to indicate that RegOp that is not abandonable is in the RUX operand transfer stage.

The signal UnexecNonAbInQ4 indicates that a non-abandonable RegOp is in column 4 of the scheduler 280 and is generated from the field Type, OpInfo, and State of entries 16-19.

The signal NonAbSync is used to suspend progress from the RUX operand transport stage if a non-abandonable RegOp is in the RUX operand transport stage and not in column 4, or if the preceding BRCOND is mispredicted or the trap is delayed.

RegOp, which is not abandonable, blocks the shift of column 4 until it proceeds to the RUX run stage.

HoldOpQ4B = UnexecNonAbInQ4

Table B.52 Self-Modifying Code Processing Logic

The self-modifying code processing logic compares to remove the possibility of code being modified.

Table B.53 Execution with Register Files

The following equation summarizes the DestBM field and signal OprndMatch_XXsrcY modifications for each operation of the writable register file and the op quad. The result of the operation selected to be executed is from column 4 or column 5 by the signal RegCmtSel.

The signal CmtInh prohibits execution if a limiting disturbance occurs in the column 5 or if the trap is delayed. The signal RegCmtInh prohibits register execution.

The signal WrEnbli is free from restrictions on the Op quads that are executed, and allows execution into the register file 290 if the older operation in the column is older.

The byte representation DestBM is clear in the cycle in which the result is executed into register file 290.

The signal OprndMatch_XXsrcY is effectively indicated so that register file 290 provides the operand.

Table B.54 Status Flags Execution

The following equation summarizes the cumulative result generation or selection process for a state group.

Table B.55 StOp Execution

Signal StCmtSel indicates to include the StOp selected for execution among entries 23-16. The oldest entry containing the StOp that was not executed is selected.

StCmtSel [3: 0] = priority_encode ((OPQ5: OpQVUncmtStOp [0]), ..., (OPQ5: OpQVUncmtStOp [3]), (OPQ5: OpQVUncmtStOp [4]), ..., (OPQ5: OpQV ・ UncmtStOp [7]))

StCmtSel is equal to b0000 to b0111 if entries 23 to 16 are selected. StCmtSel is the same as b1111 if no entry is selected.

The signal CmtMask has 8 bits corresponding to 8 entries in the last two columns of the scheduler 280. The bit corresponding to the oldest entry up to the selected entry is zero, and the remaining bits are one.

The signal CmtCiaCda indicates that the selected StOp is a CIA or CDA command.

The signal StCmtInh prohibits the execution of StOp if all executions are prohibited.

The signals StCmtV and Q5StCmtV indicate whether StOp and StOp in column 5 are ready to execute this cycle, respectively. If no StOp is selected, StOp execution is forbidden, the selected StOp has not completed, or older StOp has not completed, there is no StOp execution.

The signal StAdv indicates whether StOp can proceed to stage 2 of the storage execution pipeline.

The signals StRetire and Q5StRetire indicate which of the column-5 StOp executes this cycle.

The signal NewUncmtStOp identifies all StOps in the bottom two columns that are neither running nor running.

If StOp is executed, the UncmtStOp bit is updated as follows.

The signal Al1StCmt indicates whether all memory write StOps in column 5 have been executed or have been executed successfully.

The signal SC_HoldSC1 indicates whether the OCU 260 is sure that the store run is ready to proceed to stage 2.

SC_HoldSC1 =-StCmtV + CmtCiaCda

The storage unit 252 generates a signal SUViol indicating a fault in StOp that occurred at the second execution stage. It will be created if the selected StOp is deleted at the second execution stage causing a fault.

Table B.56 Op quad count

The following equation summarizes the op quad retrieval control logic of the OCU.

OpQRetire = OP20: S3, OP21: S3, OP22: S3, OP23: S3, AllStCmt

The signal OpQRetire can be assumed for multiple cycles for the same Op quad. This occurs when the shift of the lowest Op quad is temporarily prohibited.

When the op quad is reclaimed or abandoned, the accumulated status flag is executed.

Table B.57 LdOp Abandonment

OCU 260 generates abandon signal LdAbort for LdOp in column 5 if it is not completed and all older operations are completed and executed.

Table B.58 FAULT OP Waiver

The following equation summarizes the FAULT operation processing logic of the OCU.

Table B.59 LDDHA / LDAHA Processing Logic

The OCU handles LDDHA and LDAHA operations when they arrive at entry 23 by loading DestVal into the appropriate default handler address register.

The signal EffAltFltVecAddr provides a new alternate processor address for faults on Ops in the same Op quad as the LDAHA operation.

Exchanges and switches between processor addresses are synchronized with fault recognition on surrounding operations.

OPQ quotes the Op quad field.

Table B.60 Quarterly Target Limit Interference Handling

OCU 260 generates abandon signal LimAbort if a valid valid quad tagged with a branch target limit disturb reaches column 5.

LimAbort = OPQ5: (OpQVLimViol)

Table B.61 Abandonment in Mispredicted BRCOND

OCU 260 generates abandonment signal BrAbort for the mispredicted BRCOND when all operations preceding BRCOND that have not been completed in column 5 are completed.

Execution of the next operation is prohibited by the state of BRCOND (that is, S3) that is not completed. Further, BrAbort is assumed when FltAbort is assumed, but this is not harmful.

Table B.62 Abandon Cycle Logic

The signal ExcpAbort indicates abandonment in any abandonment condition that requires a vector address for restart.

ExcpAbort = LdAbort + StAbort + FltAbort + TrapAbort + SCReset

The signal SC_EAbort also includes abandonment in the mispredicted BRCOND.

SC_EAbort = ExcpAbort + BrAbort

Abandonment is initiated by the signal SC_Abort at the clock edge.

@clk: SC_Abort = SC_EAbort

The information required for the differences issued by the waiver is provided as follows:

Select MPEG Vector Address:

Claims (27)

Multiple execution units; And a scheduler associated with the execution unit, The scheduler A plurality of entries, each entry including a memory field for storing information describing an operation associated with the entry; Logic to scan the entry to select an operation to occur in the execution unit for execution; Logic for providing information to an execution unit for execution of the generated operation; And logic to store the result from the execution of the previously generated operation in the entry associated with the previously generated operation. The method of claim 1, A calculation execution unit connected to the scheduler, The operation execution unit finishes and removes operations from the scheduler so that new operations can be associated with entries in the scheduler, And wherein the operation performing unit replaces the result if the result is stored in an entry and is required by a program executed by the processing system. The method of claim 2, And a register file, wherein the operation performing unit offsets the result by transferring the result from an entry in the scheduler to a register file. The method of claim 3, wherein And a status register, wherein the operation performing unit offsets the result by transferring the status flag value indicated by the result from the entry to the status flag register. The method according to any one of claims 1 to 4, The entries in the scheduler are grouped into a sequence of columns starting at the top row and ending at the bottom row, each column containing a number of entries, the memory field of each entry except the bottom row being concatenated with the memory field of the entry in the next column of the sequence, , The scheduler has global control logic to generate a control signal for each column except the lowest column, wherein each control signal shifts the information stored in the memory field of the column to the memory field in the next column of the sequence. The method of claim 5, And the control logic generates a signal that causes the operation performing unit to shift the information in the scheduler's column to the lowest column in the scheduler in response to completing all operations associated with the entry in the lowest column of the scheduler. The method according to claim 5 or 6, And an instruction decoder for generating an operation set from instructions constituting a program to be executed by the processing system, wherein the instruction decoder is coupled to load information associated with the operation set into the topmost entry of the scheduler. The method of claim 7, wherein The global control logic generates a signal with a command decoder that prohibits loading a set of operations into the top row of the scheduler if the last loaded information in the top row of the scheduler does not shift or is currently shifting to the next row in the scheduler. system. The method according to claim 7 or 8, If the instruction decoder encounters a conditional branch instruction in the program to be executed, the instruction decoder: Determine that the predicted instruction address follows a conditional branch instruction; And Processing information that, when executed, loads information related to the operation that generates whether the prediction was correct into the entry in the top row of the scheduler. The method according to any one of claims 5 to 9, The scheduler Status register; And Generate a status flag bit from the value stored in the status register, cause it to be stored in a field of the scheduler, and generate a validity bit indicating whether the status flag bit is valid for operation at the boundary of the selected row of the scheduler associated with the status flag logic. Processing system, characterized in that. The method of claim 10, In a first operation that requires a state flag bit for completion of a particular execution stage of the first operation, the state flag logic continues to operate until the information associated with the first operation shifts to the boundary of the selected column associated with the state flag logic. And a signal generation to prevent entry into the execution stage. The method of claim 11, The global control logic generates a signal that prevents the first operation from shifting to the first operation away from the boundary until the status flag bit is valid in an operation provided to the execution stage that requires the status bit after reaching the boundary of the selected column. Processing system, characterized in that. The method according to claim 11 or 12, The status flag logic may simultaneously provide status flag bits for execution of the first operation type if the first operation type is in a column above the selected boundary, and the second operation type if the second operation type is in a column below the selected boundary. And may simultaneously provide a status flag bit for execution of the. The method of claim 13, And the second type of operation is a conditional branch calculation. The method according to any one of claims 1 to 14, The processing system comprises part of a single chip processor. The method according to any one of claims 1 to 14, And a memory subsystem for storing data and instructions. The method of claim 16, The processing system comprises a portion of the components of the computer motherboard. The method of claim 17, The motherboard includes a backplane bus operatively coupled to the processor, and the processing system includes one or more devices on a card connected with the motherboard via the backplane bus. The method according to any one of claims 1 to 14 or 16, The processing system comprises part of a network server. The method according to any one of claims 1 to 14 or 16, The processing system forms part of the multimedia computer system, The multimedia computer system includes: a multimedia performance device; A multimedia adapter coupled with the multimedia performance device, coupled with the multimedia signal acquisition device, and including a signal conversion interface for synthesizing and sampling the multimedia signal; And an input / output bus connected to the multimedia adapter for communicating the transmission of the multimedia data. The processing system is connected to an input / output bus that processes the multimedia data and controls the communication of the multimedia data between the processing system and the multimedia adapter. A plurality of entries for maintaining operations whose program order matches the physical order of entries; First issue selection circuitry for searching a plurality of entries according to a physical order of operations to be executed by the first execution unit; Operand transmission circuitry for transmitting the operand value from the scheduler to the first execution unit; And And a result transfer circuit for storing the result of the operation executed by the first execution in the entry corresponding to the executed operation if the result is valid for transfer by the operand transfer circuit. The method of claim 21, A second issue selection circuit for searching a plurality of entries according to the physical order of the operations to be executed by the second execution unit, the operand transmission circuit transferring the operand value from the scheduler to the second execution unit, and the result transmission circuit executing And a result of the operation executed by the second execution in the entry corresponding to the calculated operation. The method of claim 22, And wherein the first execution unit is capable of executing an operation that is not designed for execution by the second execution unit. In a program that executes decoded irregular operations, Loading a set of operations into entries in the top column of the scheduler if the top column of the scheduler is empty or shifts to the next lower column; Shifting the operation of each column of the scheduler to the next lower column if the next lower column is empty or the next lower intra column operation shifts; Scanning the scheduler in the direction of the lowest column to the highest column to select an operation for execution unit generation; Temporarily storing a result from the execution of an operation in the entry of the scheduler corresponding to the operation; Performing results from the lowest column of the scheduler into a register file; And Shifting the information to the lowest column if a result from the execution of all operations related to the current lowest column information is performed or not required. The method of claim 24, Performing any operation preceding the abandon operation; And abandoning all operations in the scheduler when the abandon operation reaches the lowest column of the scheduler. Giving up the operation to indicate that execution of the operation is not required. The method of claim 24 or 25, Performing any operation preceding the first operation generated in the first execution unit; While the first operation is at the bottom row, determining whether the first execution unit has completed execution of the first operation; And If at the bottom row, signaling all operations in the scheduler to be abandoned in response to an incomplete first operation and excluding the first execution unit, Abandoning an operation comprises setting the operation to a state that indicates that the operation is not required. The method of claim 24, Executing a conditional branch operation to determine whether the instruction decoder incorrectly predicted the conditional branch operation; Restarting the instruction decoder when determining whether the conditional branch operation has been mispredicted; Inhibiting loading the operation into the scheduler until the conditional branch reaches the bottom row; Performing any operation preceding a conditional branch; And Abandoning all operations in the scheduler if the conditional branch is at the bottom of the scheduler, The step of executing the conditional branch operation occurs when the conditional branch operation is in a column between the top and bottom columns of the scheduler, and the step of abandoning the operation sets the operation to a state indicating that the execution of the operation is not required. How to.