Compacting the Retirement Queue

Abstract

A system, apparatus, and method for compressing multiple instruction operations together into a single retire queue entry are disclosed. The processor includes at least a scheduler, a retire queue, one or more execution units, and control logic. When the control logic detects that a given instruction operation is to be dispatched by the scheduler to an execution unit, the control logic determines whether the given instruction operation satisfies one or more conditions for being compressed into a single retire queue entry with one or more other instruction operations. If the one or more conditions are met, the two or more instruction operations are stored together in a single retire queue entry. By compressing multiple instruction operations together into separate retire queue entries, the retire queue can be used more efficiently, allowing the processor to speculatively execute more instructions without the retire queue exhausting its supply of available entries.

Description

[Background technology]

[0001] A processor pipeline includes many different units that operate on the instructions being executed. These units include a decode unit, a scheduler unit, a picker, and an execution unit. The decode unit decodes fetched instructions into instruction operations. An instruction operation is also referred to herein as an "operation" or "op." Generally, an op is an operation that can be performed by hardware included in an execution unit. In various embodiments, each instruction, when executed, is translated into one or more operations that perform the actions defined for that instruction according to the instruction set architecture.

[0002] An out-of-order processor requires an in-order queue of dispatched operations to update the architectural state in order when the operation is retired. This in-order queue is referred to herein as a "retire queue." The term "retire" is also defined herein as updating the processor's architectural state with the operation's results while freeing the temporary storage location allocated for that operation. In some processors, complex instructions are decomposed into one or more operations when dispatched to an execution unit to limit the complexity of the scheduler, arithmetic logic unit, and address generation unit. For example, in the x86 instruction set architecture (ISA), many instructions support a load-ex-store format. The load-ex-store format involves loading a value from memory, performing an operation on that value, and then writing the result back to memory. This can be dispatched to the scheduling unit as up to three operations, such as a load, an arithmetic operation, and a store. Typically, each dispatched operation consumes a retire queue entry. As a result, a single instruction may consume multiple retire queue entries, which means that the supply of entries available in the retire queue may quickly be exhausted. When this occurs, the processor stalls until more retire queue entries become available. The availability of entries in the retire queue imposes limits on the range of speculations the processor can operate on, which impacts the performance of the processor (e.g., instructions per cycle (IPC)).

[0003] The advantages of the methods and mechanisms described herein may be better understood by referring to the following description in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram of one embodiment of a computing system. [Figure 2] FIG. 2 is a block diagram of one embodiment of a processor pipeline. [Figure 3] FIG. 10 illustrates a table used to determine whether an op can be compressed into a retire queue entry, according to one embodiment. [Figure 4] FIG. 10 illustrates another example of a table used to track compressibility of ops into retire queue entries, according to one embodiment. [Figure 5] FIG. 2 is a block diagram of an embodiment of a reservation station. [Figure 6] FIG. 1 is a generalized flow diagram illustrating one embodiment of a method for compacting instruction operations into retire queue entries. [Figure 7] FIG. 1 is a generalized flow diagram illustrating one embodiment of a method for storing intermediate data in a reservation station. [Figure 8] FIG. 1 is a generalized flow diagram illustrating one embodiment of a method for sharing a reservation station entry among multiple instruction operations. [Figure 9] FIG. 1 is a generalized flow diagram illustrating one embodiment of a method for reducing the number of physical registers used by instruction operations to increase the compressibility of retirement queue entries. [Figure 10] FIG. 1 is a generalized flow diagram illustrating one embodiment of a method for broadcasting result data from execution units. DETAILED DESCRIPTION OF THE INVENTION

[0005] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, those skilled in the art will recognize that various embodiments may be practiced without the use of such specific details. In some instances, well-known structures, components, signals, computer program instructions, and techniques have not been shown in detail so as not to obscure the approaches described herein. It should be understood that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements.

[0006] Disclosed herein are various systems, apparatuses, and methods for compressing retire queue entries. The systems include one or more processors coupled to one or more memories. Each processor includes at least a scheduler, a retire queue, one or more execution units, and control logic. Because reducing the number of retire queue entries consumed by instructions is deemed beneficial to processor performance, the control logic attempts to compress multiple instruction operations into a single retire queue entry. Thus, in one embodiment, when the control logic detects that a given instruction operation is to be dispatched to an execution unit by the scheduler, the control logic determines whether the first instruction operation meets one or more conditions for being compressed into a single retire queue entry with one or more other instruction operations. The one or more conditions for compressing the instruction operations may include the instruction operations being dispatched together, the instruction operations not exceeding the available fields in a single retire queue entry, the instruction operations being able to be retired together, no redirection operations being possible in the middle of the instruction operations, and / or other conditions. If these conditions are met, the two or more instruction operations are stored together in a single retire queue entry. By packing multiple instruction operations together into separate retire queue entries, the retire queue can be used more efficiently, allowing the processor to speculatively execute more instructions without the retire queue exhausting its supply of available entries.

[0007] 1, a block diagram of one embodiment of computing system 100 is shown. In one embodiment, computing system 100 includes at least processors 105A-105N, input / output (I / O) interface 120, bus 125, memory controller(s) 130, network interface 135, and memory device(s) 140. In other embodiments, computing system 100 includes other components and / or is configured differently. Processors 105A-105N represent any number of processors included in system 100.

[0008] In one embodiment, processor 105A is a general-purpose processor such as a central processing unit (CPU). In one embodiment, processor 105N is a data-parallel processor having a highly parallel architecture. Data-parallel processors include graphics processing units (GPUs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc. In some embodiments, processors 105A-105N include multiple data-parallel processors.

[0009] Memory controller(s) 130 represent any number and type of memory controller accessible by processors 105A-105N and I / O devices (not shown) coupled to I / O interface 120. Memory controller(s) 130 are coupled to any number and type of memory device(s) 140. Memory device(s) 140 represent any number and type of memory devices. For example, the type of memory in memory device(s) 140 may include dynamic random access memory (DRAM), static random access memory (SRAM), NAND flash memory, NOR flash memory, ferroelectric random access memory (FeRAM), or other memory.

[0010] I / O interface 120 represents any number and type of I / O interface (e.g., Peripheral Component Interconnect (PCI) bus, PCI Extended (PCI-X), PCI Express (PCIE) bus, Gigabit Ethernet (GBE) bus, Universal Serial Bus (USB)). Various peripheral devices (not shown) are coupled to I / O interface 120. Such peripheral devices include, but are not limited to, a display, a keyboard, a mouse, a printer, a scanner, a joystick or other type of game controller, a media recording device, an external storage device, a network interface card, etc. Network interface 135 is used to send and receive network messages over a network.

[0011] In various embodiments, computing system 100 may be a computer, a laptop, a mobile device, a game console, a server, a streaming device, a wearable device, or any of a variety of other types of computing systems or devices. Note that the number of components of computing system 100 may vary depending on the embodiment. For example, in other embodiments, more or fewer components may be present than those shown in FIG. 1. Note also that in other embodiments, computing system 100 may include other components not shown in FIG. 1. Also, in other embodiments, computing system 100 may be configured in a manner other than that shown in FIG. 1.

[0012] Referring to FIG. 2, a block diagram of one embodiment of a processor pipeline 200 is shown. In various embodiments, processors 105A-105N (of FIG. 1) include one or more instances of processor pipeline 200. In one embodiment, processor pipeline 200 includes at least fetch unit 210, decode unit 215, dispatch unit 220, reservation station 225, execution units 235A-235N, and retire unit 240. It should be understood that processor pipeline 200 also includes other components (e.g., branch prediction unit, instruction cache) that are not shown in the figure so as not to obscure the diagram. In other embodiments, processor pipeline 200 is configured in other suitable manners.

[0013] In one embodiment, fetch unit 210 fetches instructions of the program stream from memory and / or an instruction cache, and fetch unit 210 communicates the fetched instructions to instruction decode unit 215. Instruction decode unit 215 decodes each instruction into one or more instruction operations (or ops for short). Note that ops are also referred to as micro-ops or uops. In general, instruction operations are operations that can be performed by hardware included in execution units 230A-230N. In various embodiments, each instruction is translated into one or more ops that, when executed, perform the operations defined for that instruction according to the instruction set architecture. Any type of instruction set architecture may be used by processor pipeline 200.

[0014] Ops from instruction decode unit 215 are provided to dispatch unit 220, which assigns ops to queues 230A-230N. Note that queues 230A-230N are sometimes referred to as reservation stations 225, and each queue is referred to as a reservation station. Note that reservation stations 225 are also sometimes referred to as a "scheduler" or "scheduler unit." As shown in processor pipeline 200, each queue 230A-230N is coupled to a corresponding execution unit 235A-235N. However, in other embodiments, one or more queues 230A-230N may be coupled to multiple execution units 235A-235N.

[0015] In one embodiment, dispatch unit 220 includes a register rename unit 222 for mapping architectural register specifiers to physical register specifiers that reference actual physical registers in physical register file (PRF) 255. In other embodiments, register rename unit 222 is a separate structure from dispatch unit 220. Out-of-order microprocessors use register renaming to extract parallelism and improve performance. When the hardware allocates all available physical register numbers (PRNs) corresponding to locations in PRF 255, the instruction decode pipeline stalls until physical registers in PRF 255 become available again. In one embodiment, to help avoid instruction decode pipeline stalls, intermediate data generated during a sequence of ops is stored directly in reservation stations of dependent ops, without using PRF 255. In many cases, this intermediate data is needed by only one dependent op. More efficient use of the PRF 255 improves processor performance by allowing the out-of-order window to span more instructions before running out of physical registers, thereby increasing the chances of compressing multiple ops into a single entry in the retirement queue 250, as described in more detail below.

[0016] For example, when an x86 instruction having a load-execute format is executed, the first operand is obtained from a register before the arithmetic and logic unit (ALU) can execute the instruction, but the second operand must first be loaded from memory. In this case, the instruction is decomposed into two operations: a load address generation (AGEN) operation and an ALU operation. In one embodiment, a single reservation station entry is allocated for the instruction, and the entry contains the ALU register operand and the AGEN operation. In this embodiment, both operations are issued from the same reservation station entry. After the AGEN operation is issued, the AGEN operation is overwritten with the load data, so that the reservation station entry contains the ALU register operand and the ALU operand loaded from memory. The physical register number (PRN) broadcast for this load data does not address a PRF entry, but instead uses a special tag to directly address the appropriate reservation station entry. The ALU op is then issued without any intermediate load data being written back to the PRF 255. Storing intermediate data to the reservation station 225 can apply to a sequence of micro-ops derived from a single instruction or multiple instructions fused together to take advantage of this mechanism.

[0017] Once dependencies are resolved and the op is ready to execute, a picker (not shown) selects the op from queues 230A-230N for execution by execution units 235A-235N. Execution units 235A-235N represent any number and type of execution units. For example, execution units 235A-235N may include any of a variety of types, including, but not limited to, integer execution units, floating-point execution units, load / store units, arithmetic logic units, and address generation units. Furthermore, execution units 235A-235N may include two or more units of a particular type. For example, in one embodiment, execution units 235A-235N include two integer execution units.

[0018] During dispatch, an entry in retire queue 250 is allocated and the op is written into the entry. Some of the fields in the retire queue entry may be written based on the execution result after execution of the op by execution units 235A-235N. The entry is held in retire queue 250 until the corresponding op is no longer speculative, at which point the op is retired in-order. Dispatch unit 220 includes control logic 223 that determines whether two or more ops can be compressed into a single entry in retire queue 250. In one embodiment, two or more ops are compressed into a single entry in retire queue 250 if the two or more ops satisfy one or more conditions. Depending on the embodiment, the conditions may include: the two or more ops are dispatched together; the two or more ops are architecturally retireable together; all completions of the two or more ops can be tracked in a single retire queue entry; all architectural state updated by the two or more ops can be tracked in a single retire queue entry; and no program redirection is possible between the two or more ops. If two or more ops do not meet the required conditions, each op is stored in a separate entry in the retirement queue 250.

[0019] When the op's result is no longer speculative, the processor's architectural state is updated using the op's result, and the op is retired from retire queue 250. When two or more ops are compressed together into a given entry in retire queue 250 and two or more ops are ready for retirement, the processor's architectural state is updated simultaneously with the results of the two or more ops. In some cases, the processor needs to restore the architectural state after the first compressed op but before the second compressed op in a given entry. For example, an exception may cause the processor to stop retiring according to the corresponding instruction. In one embodiment, to address this scenario, the processor flushes all younger in-flight ops and replays the instruction without compressing the op into retire queue 250.

[0020] 3, a table 300 is shown that is used to determine whether an op can be compressed into a retire queue entry, according to one embodiment. Table 300 includes sample instructions that may be encountered in an exemplary program sequence in one particular embodiment. In one embodiment, control logic generates table 300 (or some other similar structure) that helps determine whether a group of ops can be compressed together into a single retire queue entry. Alternatively, rather than generating table 300 or a similar structure, the control logic includes circuitry that performs decision-making based on the values ​​indicated by the various fields 335-355 of table 300.

[0021] The first entry in table 300 is for the "Add [RAX+RBX],RCX" instruction. This instruction is translated into two ops: the first op, "Ld Temp,[RAX+RBX]," is a load operation, and the second op, "Add [RAX+RBX],Temp," is an add operation. In one embodiment, the "Temp" identifier (ID) does not identify a physical register number. Rather, the "Temp" location specifies a particular reservation station entry. Using the "Temp" ID to specify a reservation station entry rather than a physical register number helps reduce physical register usage. Using the "Temp" ID to specify a reservation station entry increases the chances of compressing ops together into a single retire queue entry.

[0022] Fields 335-350 of table 300 are used to indicate which portion of the architectural state is updated by each op. Each portion of the architectural state corresponds to a different field of the retire queue entry occupied by the op. An example of fields 305-330 of a retire queue entry according to one embodiment is shown at the top of the figure. For example, in one embodiment, the fields of a retire queue entry include a destination architectural register number (Arn) field 305, a destination physical register number (Prn) field 310, a destination flags field 315, a destination free flag register number (Frn) field 320, an arithmetic logic unit (ALU) completion field 325, and a load / store completion field 330. In other embodiments, a retire queue entry may have other types of fields. For example, in some embodiments, a retire queue entry may include one or more optional fields 332 that allow for the compression of more ops into a single retire queue entry.

[0023] The arithmetic logic unit (ALU) completion (comp) field 345 for the table 300 entry for the first instruction, op#0, is set, indicating that op#0 should use the ALU completion field 325 of the retire queue entry. The other fields of retire queue entry #0 are unused by op#0. The destination Arn / Prn field 335 for the table 300 entry for the first instruction, op#1, is set, indicating that the destination Arn field 305 and the destination Prn field 310 of the retire queue entry are used. Also, the destination flags / Frn field 340 is set, indicating that the destination flags field 315 and the destination Frn field 320 of the retire queue entry are used. Because there is no overlap in fields 335-350 of table 300 entries op#0 and #1, these two operations can share a single retire queue entry (entry #0). This is indicated in the first entry of table 300 by a "Yes" entered in the retire queue compressibility "RetQ Compression?" field 355. Generally, consecutive operations can be compressed into a single retire queue entry if there are no overlaps in the retire queue entry fields occupied by those operations. However, other factors may prevent two consecutive operations with no overlaps from being compressed into a single retire queue entry. An example of another factor that may prevent the compression of consecutive ops is shown using the following instruction:

[0024] The next instruction shown in table 300 is instruction "JNZ 0x04." This instruction is labeled instruction #1, and the op is labeled op#2. Instruction "JNZ 0x04" maps to only a single operation. This operation cannot be compressed with subsequent operations into the next retire queue entry because this would violate the rule that a branch must be the last operation in a retire queue entry. Therefore, because operation "JNZ 0x04" is not compressed with other operations, operation "JNZ 0x04" has its own retire queue entry (entry #1), as shown in field 360.

[0025] The next instruction, labeled instruction #2, is the instruction "MOV R08,[R04]." This instruction is mapped to a single op, labeled op#3. The destination Arn / Prn field 335 is set in the corresponding entry in table 300 for this op, and the load / store completion field 350 is also set for this op. The subsequent instruction, labeled instruction #4, is the instruction "CMP RAX,RBX." This instruction decodes to a single op, labeled op#4. The destination flag / Frn field 340 is set in the corresponding entry in table 300 for this op, and the ALU completion field 345 is also set for this op. Because there is no overlap between the table 300 entries for op#3 and op#4, and op#3 and op#4 meet the other criteria for being compressed into a single retire queue entry, the retire queue compressibility field 355 is set in the table 300 entry for op#3. Therefore, op#3 and op#4 are compressed together into retire queue entry #2, as shown in field 355. Note that ops derived from other instructions can be analyzed in a similar manner using the fields of table 300 to determine whether adjacent ops can be compressed together into a single retire queue entry.

[0026] Referring to FIG. 4, another example of a table 400 used to track the compressibility of ops into retire queue entries is shown, according to one embodiment. The example table 400 is intended to illustrate one embodiment that attempts to compress integer and / or floating-point ops into a single, combined retire queue entry. The first instruction #0 listed in table 400 is the instruction "MOV [RBX],RCX" with a single op#0. The load / store completion field 460 is set for op#0, and the retire queue compressibility field 470 is set to "No," indicating that op#0 is not compressible with other operations. Therefore, op#0 is stored alone in retire queue entry #0, as shown in field 475.

[0027] The next instruction #1 listed in table 400 is the instruction "VMOVAPD YMM0,[RAX]," which maps to a single op#1. The floating-point destination Arn / Prn field 445 is set for op#1, as are the load / store completion field 460 and the floating-point completion field 465. The retire queue compressibility field 470 is set to "Yes" for op#1, indicating that op#1 can be compressed into the same retire queue entry (entry #1) with op#2. The next instruction #2 listed in table 400 is the "JNZ 0x04" instruction. The only field set for op#2 in the corresponding entry in table 400 is the ALU completion field 455. Although op#2 is a branch operation, op#2 can be compressed with op#1 because op#2 will be the last operation stored in the retire queue entry (entry #1).

[0028] The next instruction, "MOV R08,[R04]," maps to a single op#3. The entry for op#3 has integer destination Arn / Prn field 435 and load / store completion field 460 set. Field 470 of the entry for op#3 indicates that op#3 can be compressed with op#4 into a single retire queue entry (entry #2). op#4 is derived from instruction #4, which is the "ADDPD XMM0,XMM1" instruction shown in the last entry of table 400. op#4 has floating-point destination Arn / Prn field 445 set, floating-point destination flag / Frn field 450 set, and floating-point completion field 465 set.

[0029] An example of a retire queue entry is shown at the top of Figure 4, along with fields 402-422. In this example, integer destination architectural register number (Arn) field 402 and integer destination physical register number (Prn) field 404 correspond to field 435 of table 400. Similarly, integer destination flags field 406 and integer destination Frn field 408 of the entry correspond to field 440 of table 400, floating-point destination Arn field 410 and floating-point destination Prn field 412 of the entry correspond to field 445 of table 400, floating-point destination flags field 414 and floating-point destination Frn field 416 of the entry correspond to field 450 of table 400, and ALU completion field 418, load / store completion field 420, and floating-point completion field 422 correspond to fields 455, 460, and 465, respectively, of table 400. In other embodiments, the retire queue entries may have other numbers and / or types of fields, and in these embodiments, table 400 has additional fields corresponding to these other types of fields.

[0030] Referring to FIG. 5, a block diagram of one embodiment of a reservation station 505 is shown. In one embodiment, reservation station 505 includes a queue 510 and control logic 515. Queue 510 includes storage for any number of entries for ops dispatched from a dispatch unit (not shown), with storage capacity varying depending on the embodiment. An example of an entry 520 according to one embodiment is shown. In other embodiments, queue 510 may support other types of entries with other types of fields.

[0031] As shown in queue 510, entry 520 includes opcode field(s) 520A, tag field(s) 520B, first operand field 520C, second operand field 520D, third operand field 520E, intermediate indicator field 520F, and any number of other fields. In one embodiment, entry 520 can store the opcodes and tags of multiple ops issued by the dispatch unit. For example, for a load-execute style instruction, two ops share a single entry 520, and both ops are issued from this single entry 520. In this example, the single entry 520 is assigned an ALU register operand stored in field 520C and address generation (AGEN) operands stored in fields 520D and 520E. After the AGEN op is issued, the AGEN operand in field 520D is overwritten with the ALU operand loaded from memory. The physical register number (PRN) broadcast for this load data uses a special tag to directly address the reservation station 505 that will buffer the load data, rather than a PRF entry. In one embodiment, control logic 515 detects this special tag on the result bus, retrieves the load data, and overwrites field 520D. Thus, after the AGEN op is issued, entry 520 contains the ALU register operand stored in field 520C and the ALU operand loaded from memory stored in field 520D. Additionally, in one embodiment, after the AGEN op is issued, intermediate indicator field 520F is set. In this embodiment, when intermediate indicator field 520F is set, this indicates that a second op sharing this entry is ready to be issued.

[0032] In other embodiments, other combinations of ops can share a single entry 520 in reservation stations 505. For example, in another embodiment, two or more ops from different instructions can share a single entry in reservation stations 505. These two or more ops would also issue from the same entry. By sharing entries in reservation stations 505 and storing intermediate data in these shared entries, the number of physical registers used is reduced. This allows more instructions to be speculatively executed without exhausting the supply of available physical registers. Reducing physical register usage also provides additional opportunities for packing multiple ops together into a retire queue entry.

[0033] Referring to Figure 6, one embodiment of a method 600 for compacting instruction operations into retire queue entries is shown. For purposes of explanation, the steps of this embodiment and the steps of Figures 7-10 are shown sequentially. However, it should be noted that in various embodiments of the described method, one or more of the described elements may be performed simultaneously, in a different order than shown, or omitted entirely. Other additional elements may also be performed as needed. Any of the various systems or devices described herein may be configured to perform method 600.

[0034] The control logic receives a first instruction operation and a second instruction operation to be stored in a retire queue (block 605). In one embodiment, the first instruction operation and the second instruction operation are derived from a single instruction. In another embodiment, the first instruction operation and the second instruction operation are derived from separate instructions. The control logic determines whether the first instruction operation and the second instruction operation meet one or more conditions for being compressed into a single retire queue entry (block 610). Depending on the embodiment, the one or more conditions may include: the first and second instruction operations being dispatched together; the first and second instruction operations being architecturally retireable together; all completions of the first and second instruction operations being tracked in a single retire queue entry; all architectural state updated by the first and second instruction operations being tracked in a single retire queue entry; and no program redirection occurring midway between the first and second instruction operations. In other embodiments, other conditions may be checked at block 610. In some cases, the control logic determines in block 610 whether three or more instruction operations can be compressed together into a single retire queue entry.

[0035] If the first and second instruction operations satisfy one or more conditions (conditional block 615: "Yes"), fields corresponding to the first and second instruction operations are modified as necessary to appropriately compress the first and second instruction operations (optional block 620). The first and second instruction operations are then compressed together into a single retire queue entry (block 625). Alternatively, if the first and second instruction operations do not satisfy one or more conditions (conditional block 615: "no"), the first and second instruction operations are stored in separate retire queue entries (block 630). After blocks 625 and 630, method 600 ends. Note that in other embodiments, method 600 can be used to compress three or more different instruction operations into a single retire queue entry.

[0036] Referring to FIG. 7, one embodiment of a method 700 for storing intermediate data in a reservation station is illustrated. A given instruction is decoded into multiple instruction operations (block 705). The remainder of the description of method 700 will assume that the given instruction is divided into two instruction operations. In this description, these two instruction operations will be referred to as a first instruction operation and a second instruction operation. However, it should be understood that this is merely illustrative of one embodiment. In other embodiments, the given instruction may be divided into more than two instruction operations. The first instruction operation is then assigned to a first reservation station entry, and the second instruction operation is assigned to a second reservation station entry (block 710). Also, for purposes of this description, it is assumed that the first instruction operation generates an intermediate result that is operated on by the second instruction operation. In other embodiments, the first and second instruction operations are stored in a single reservation station entry.

[0037] When a first instruction operation is executed, intermediate results of the first instruction operation are temporarily stored in a second reservation station entry rather than being stored in a physical register (block 715). A second instruction operation is then executed by manipulating the intermediate results stored in the second reservation station entry (block 720). Execution of the second instruction operation may also manipulate one or more other operands. After block 720, method 700 ends. Storing intermediate results in a second reservation station entry rather than using a physical register allows the physical register to be used in another instruction operation. This also helps prevent a situation in which the processor pipeline has allocated all available physical register numbers. If the processor pipeline runs out of physical register resources, the processor pipeline stalls until more physical registers become available. Method 700 helps prevent this from occurring. Note that in other embodiments, more than one intermediate result can be stored in a reservation station entry. Also, in other embodiments, a single intermediate result may be written to multiple reservation station entries if there are multiple dependent instruction operations that use the intermediate result.

[0038] Referring to FIG. 8, one embodiment of a method 800 for sharing a reservation station entry among multiple instruction operations is shown. An instruction is decoded into two instruction operations (block 805). In other embodiments, the instruction is decoded into three or more instruction operations. A dispatch unit dispatches the two instruction operations to be stored in a single reservation station entry (block 810). Multiple operands are stored in a reservation station entry shared by the two instruction operations (block 815). After a first instruction operation is issued to an execution unit, one or more operands in the shared reservation station entry are overwritten with first result data from the first instruction operation (block 820). Then, a second instruction operation is issued to the execution unit and operates on the first result data stored in the shared reservation entry (block 825). After the second instruction operation is executed, second result data from the second instruction operation is written to one or more physical registers (block 830). After block 830, method 800 ends. Note that in other embodiments, other numbers of instruction operations can share a single reservation station entry. Furthermore, these instruction operations can, in some embodiments, result from different instructions.

[0039] Referring to FIG. 9 , one embodiment of a method 900 for reducing the number of physical registers used by an instruction operation to increase the compressibility of a retire queue entry is illustrated. An instruction operation is dispatched to a reservation station by a dispatch unit (block 905). Next, control logic of the reservation station determines whether the instruction operation can be compressed into a retire queue entry with one or more other instruction operations if the instruction operation's intermediate result data is stored in the reservation station entry rather than in a physical register (block 910). Note that the ability to compress an instruction operation into a retire queue entry is not a prerequisite for using a reservation station for intermediate results. While block 910 describes the determination of whether to store intermediate result data in a reservation station entry as depending on whether the instruction operation can be compressed into a retire queue entry with other instruction operations, it should be understood that this merely illustrates one embodiment. In other embodiments, the determination of whether to store intermediate result data in a reservation station entry is made independently of the compression of the instruction operation into a retire queue entry. In some cases, even if an instruction operation is not compressible into a retire queue entry, it may still be advantageous to use a reservation station to store intermediate data. Thus, while method 900 describes the decisions to store intermediate result data in a reservation station entry and to compress a retire queue entry as being linked together, this is shown by way of example. In other embodiments, the decision whether to store intermediate result data in a reservation station entry may be separated from the decision whether to compress a retire queue entry.

[0040] If the control logic determines that the instruction operation can be compressed into a retire queue entry (condition block 915: “Yes”), the intermediate result data of the instruction operation is stored in an appropriate reservation station entry (block 920). In one embodiment, a requirement for storing intermediate result data in a reservation station entry is that the result of the instruction operation is always sourced by only one other instruction operation, and any architectural state updated by the instruction operation is overwritten by the other instruction operation. Storing the intermediate result data of the instruction operation in a reservation station entry allows the physical register to be used by another instruction operation, reduces the number of fields used in the retire queue entry by the instruction operation, and increases the probability that the instruction operation can be compressed with other instruction operations. In one embodiment, the appropriate reservation station entry is an entry corresponding to a dependent instruction operation that will manipulate the intermediate result data. Otherwise, if the control logic determines that the instruction operation is not compressible into a retire queue entry (condition block 915: “no”), the intermediate result data of the instruction operation is stored in a physical register (block 925). After blocks 920 and 925, the method 900 ends.

[0041] Referring to FIG. 10, one embodiment of a method 1000 for broadcasting result data from an execution unit is shown. A reservation station issues an instruction operation to an execution unit, and the reservation station communicates a flag to the execution unit indicating where the result data is to be written (block 1005). The execution unit then executes the instruction operation and generates result data for the instruction operation (block 1010). If the flag is set (conditional block 1015: "yes"), the execution unit broadcasts a special tag along with the result data onto the result bus (block 1020). In response to detecting the special tag, control logic coupled to the result bus forwards the result data to the appropriate reservation station (block 1025). The reservation station then writes the result data to the appropriate reservation station entry (block 1030). After block 1030, method 1000 ends.

[0042] If the flag is not set (conditional block 1015: "no"), the execution unit broadcasts a normal tag along with the result data onto the result bus (block 1035). In one embodiment, the normal tag includes a physical register number (PRN) that identifies the physical register to which the result data is to be written. Then, in response to detecting the normal tag, control logic coupled to the result bus writes the result data to the appropriate physical register (block 1040). After block 1040, method 1000 ends.

[0043] In various embodiments, program instructions of a software application are used to implement the methods and / or mechanisms described herein. For example, program instructions executable by a general-purpose or special-purpose processor are contemplated. In various embodiments, such program instructions are expressed in a high-level programming language. In other embodiments, the program instructions are compiled from a high-level programming language into binary, intermediate, or other form. Alternatively, the program instructions are written to describe the operation or design of hardware. Such program instructions are expressed in a high-level programming language such as C. Alternatively, a hardware design language (HDL) such as Verilog is used. In various embodiments, the program instructions are stored on any of a variety of non-transitory computer-readable storage media. The storage medium is accessible by a computing system during use to provide the program instructions to the computing system for program execution. Typically, such a computing system includes at least one or more memories and one or more processors configured to execute the program instructions.

[0044] It should be emphasized that the above-described embodiments are merely non-limiting examples of embodiments. Many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1. a retire queue configured to store entries corresponding to unretired instruction operations; control logic; The control logic receiving a first instruction operation corresponding to a first decoded instruction and a second instruction operation corresponding to a second decoded instruction different from the first decoded instruction, the first instruction operation being stored in the retire queue; compressing the first instruction operation and the second instruction operation together into a single retire queue entry in response to determining that the first instruction operation and the second instruction operation satisfy one or more conditions for being compressed together into a single retire queue entry; configured to: Processor.

2. The one or more conditions are: a first condition that the first instruction operation and the second instruction operation are architecturally retireable together; a second condition that all updates to the processor's architectural state caused by the first instruction operation and the second instruction operation can be tracked in a single retire queue entry; The processor of claim 1 .

3. the one or more conditions further include a third condition that the first instruction operation and the second instruction operation are dispatched together. The processor of claim 2 .

4. the one or more conditions further include a fourth condition that the first instruction operation is older than the second instruction operation. The processor of claim 3.

5. the one or more conditions further include a fifth condition that no operation that prevents the first instruction operation and the second instruction operation from being retired together may occur between the first instruction operation and the second instruction operation. The processor of claim 4.

6. the control logic is further configured to, in response to determining that three or more instruction operations satisfy the one or more conditions, store the three or more instruction operations in a single retire queue entry. The processor of claim 1 .

7. the processor is further configured to store an intermediate output of the first instruction operation in a reservation station entry rather than in a physical register. The processor of claim 1 .

8. receiving a first instruction operation corresponding to a first decoded instruction and a second instruction operation corresponding to a second decoded instruction different from the first decoded instruction, the first instruction operation being stored in a retire queue; and compressing the first instruction operation and the second instruction operation together into a single retire queue entry in response to determining that the first instruction operation and the second instruction operation meet one or more conditions for being compressed together into a single retire queue entry. method.

9. The one or more conditions are: a first condition that the first instruction operation and the second instruction operation are architecturally retireable together; a second condition that all updates to the processor's architectural state caused by the first instruction operation and the second instruction operation can be tracked in a single retire queue entry; 9. The method of claim 8.

10. the one or more conditions further include a third condition that the first instruction operation and the second instruction operation are dispatched together.

10. The method of claim 9.

11. the one or more conditions further include a fourth condition that the first instruction operation is older than the second instruction operation. The method of claim 10.

12. the one or more conditions further include a fifth condition that no operation that prevents the first instruction operation and the second instruction operation from being retired together may occur between the first instruction operation and the second instruction operation. The method of claim 11.

13. and, in response to determining that three or more instruction operations satisfy the one or more conditions, storing the three or more instruction operations in a single retire queue entry.

9. The method of claim 8.

14. storing an intermediate output of the first instruction operation in a reservation station entry rather than in a physical register; 9. The method of claim 8.

15. Memory and and a processor according to any one of claims 1 to 7. system.

Images