Instruction replay using a throttling mode

Abstract

Implementations described herein relate to optimized instruction replay using a throttling mode. For example, a disclosed method includes selecting, as an arbitration selection by an execution unit within a processor, a first instruction to be processed by a pipeline of the execution unit. The arbitration selection is between the first instruction, as provided by a replay queue local to the execution unit, and a second instruction provided by an issue queue external to the execution unit. The method further includes determining, based on the selecting of the first instruction provided by the replay queue, that the execution unit is to operate in a replay throttling mode, and directing, based on this determination, the second instruction to be replayed from the issue queue instead of from the replay queue. Corresponding methods, processors, and other implementations are also disclosed.

Description

Atty Docket No. 0120-1142 WO1INSTRUCTION REPLAY USING A THROTTLING MODEBACKGROUND

[0001] Processors such as central processing units (CPUs) include various types of execution units configured to perform different types of instructions found in machine code that the processors are tasked with executing. For example, one type of execution unit is a load / store unit (LSU) that may be tasked with executing load instructions (in which data is obtained from memory) and store instructions (in which data is stored to memory). Other types of execution units include arithmetic logic units (ALUs), floating-point units (FPUs), branch units, and so forth. When an execution unit fails for any reason to execute an assigned instruction on a first attempt, the execution unit may be configured to reattempt executing the instruction until success is achieved. For example, if an LSU attempts a load instruction in which data from a certain memory address is to be obtained, the LSU may receive a cache miss if that data has not been cached. As a result of this failure, the LSU may try again later to perform the load instruction once the data is available in the cache. Reattempting to perform instructions that were not able to be completed earlier in this way is referred to as replaying the instructions.SUMMARY

[0002] Instructions that are to be executed by various execution units of a processor (e.g., a central processing unit (CPU)) may be stored in an issue queue that provides the instructions to the proper execution units as the execution units have availability to take on new instructions for execution. Certain execution units such as a load / store unit (LSU) may also include local replay queues that store instructions to be replayed by the execution unit (e.g., due to a cache miss by the LSU, etc.). Accordingly, when a pipeline of the execution unit becomes available to process a new instruction, an arbitration function is employed to select an instruction for execution from either the issue queue or the replay queue. While it may generally be desirable in this arbitration for the replay queue to be given priority over the issue queue, an undesirable situation (i.e., a vicious cycle or feedback loop referred to herein as a runaway replay scenario) may occur in which several consecutive instructions from the issue queue lose arbitration to instructions from the replay queue, thereby forcing instructionsAtty Docket No. 0120-1142 WO1from the issue queue to have to pass through the replay queue before being selected and executed. To address this situation, methods and apparatuses described herein are configured to detect when a runaway replay scenario occurs, to direct the execution unit to operate in a replay throttling mode that helps break the cycle, and, when appropriate, to return to normal function (ceasing operating in the replay throttling mode).

[0003] In some aspects, the techniques described herein relate to a method including: 1) selecting, as an arbitration selection by an execution unit within a processor, a first instruction to be processed by a pipeline of the execution unit, the arbitration selection being between the first instruction, as provided by a replay queue local to the execution unit, and a second instruction provided by an issue queue external to the execution unit; 2) determining, based on the selecting of the first instruction provided by the replay queue, that the execution unit is to operate in a replay throttling mode; and 3) directing, based on the determining that the execution unit is to operate in the replay throttling mode, the second instruction to be replayed from the issue queue instead of from the replay queue.

[0004] In some aspects, the techniques described herein relate to a processor including: 1) an execution unit having a pipeline configured to process instructions; 2) a replay queue local to the execution unit and providing a first instruction; 3) an issue queue external to the execution unit and providing a second instruction; and 4) an instruction arbiter included within the execution unit and configured to select, as an arbitration selection between the first instruction and the second instruction, the first instruction to be processed by the pipeline of the execution unit; wherein, based on the instruction arbiter selecting the first instruction provided by the replay queue, the execution unit determines to operate in a replay throttling mode that includes directing the second instruction to be replayed from the issue queue instead of from the replay queue.

[0005] Generally, the proposed solution may in particular relate to two types of throttling modes. Based on the determining that the execution unit is to operate in the replay throttling mode, the example implementations above relate to directing the second instruction to be replayed from the issue queue instead of from the replay queue. Additionally or alternatively, the following example implementations relate to directing the issue queue to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode.

[0006] In some aspects, the techniques described herein relate to a method including: 1) selecting, as an arbitration selection by an execution unit within a processor, a first instruction to be processed by a pipeline of the execution unit, the arbitration selection beingAtty Docket No. 0120-1142 WO1between the first instruction, as provided by a replay queue local to the execution unit, and a second instruction provided by an issue queue external to the execution unit; 2) determining, based on the selecting of the first instruction provided by the replay queue, that the execution unit is to operate in a replay throttling mode; and 3) directing, based on the determining that the execution unit is to operate in the replay throttling mode, the issue queue to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode.

[0007] In some aspects, the techniques described herein relate to a processor including: 1) an execution unit having a pipeline configured to process instructions; 2) a replay queue local to the execution unit and providing a first instruction; 3) an issue queue external to the execution unit and providing a second instruction; and 4) an instruction arbiter included within the execution unit and configured to select, as an arbitration selection between the first instruction and the second instruction, the first instruction to be processed by the pipeline of the execution unit; wherein, based on the instruction arbiter selecting the first instruction provided by the replay queue, the execution unit determines to operate in a replay throttling mode that includes directing the issue queue to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode.

[0008] Other implementations may perform similar functions as described above and / or may use other types of hardware to perform the functions. Certain implementations may involve systems, devices, media, and / or combinations of these, that employ processors such as described herein (e.g., processors with issue queues and execution units such as detailed below).

[0009] The details of these and other implementations are set forth in the accompanying drawings and the description below. Other features will also be made apparent from the following description, drawings, and claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 shows certain aspects of an illustrative implementation of optimized instruction replay using a throttling mode in accordance with principles described herein.

[0011] FIG. 2 shows certain aspects of an illustrative processor configured to perform optimized instruction replay using a throttling mode in accordance with principles described herein.

[0012] FIG. 3 shows an illustrative method for optimized instruction replay using aAtty Docket No. 0120-1142 WO1throttling mode in accordance with principles described herein.

[0013] FIGS. 4A-4C show certain aspects of how a runaway replay scenario may be detected to occur while a processor is not operating in a replay throttling mode in accordance with principles described herein.

[0014] FIGS. 5A-5C show certain aspects of how an execution unit may operate in a first type of replay throttling mode in accordance with principles described herein.

[0015] FIGS. 6A-6C show certain aspects of how an execution unit may operate in a second type of replay throttling mode in accordance with principles described herein.

[0016] FIGS. 7A-7C show certain aspects of how a runaway replay scenario may be detected to abate while a processor is operating in a replay throttling mode in accordance with principles described herein.

[0017] FIG. 8 shows an illustrative computing device that may use one or more processors such as those described herein.DETAILED DESCRIPTION

[0018] Methods and apparatuses for optimized instruction replay using a throttling mode are described herein. Instructions introduced into an issue queue wait for an execution unit (e.g., a load-store unit (LSU) in the case of instructions such as load and store instructions) to become available to execute the instruction. Such instructions have typically already been pre-processed for execution by the time they are provided to the execution unit. Additionally, instructions in a replay queue (which may be local to the execution unit) include instructions that have already been attempted by the execution unit. For example, instructions in the replay queue may be those whose execution by the pipeline failed when attempted or that previously lost arbitration (performed by an arbiter) to another instruction and were not able to be processed when previously presented to the execution unit. A runaway replay scenario may be detected within the execution unit (e.g., an LSU) when (first) instructions from the local replay queue are being consistently selected in the arbitration over (second) instructions from an external issue queue, such that the execution unit becomes practically limited to performing only instructions that have passed through the replay queue. When this runaway scenario occurs, every instruction from the issue queue may traverse the replay queue before being executed, thereby significantly diminishing the advantages that the replay queue is intended to provide. Accordingly, as described herein, a runaway replay scenario may be detected, and, in response, a temporary replay throttling mode may be engaged to help break the cycle so that normal operation (in which the replayAtty Docket No. 0120-1142 WO1throttling mode is disengaged) may be resumed without the issues caused by the runaway replay scenario.

[0019] A processor such as a central processing unit (CPU) operates by rapidly performing a large number of instructions. Every instruction would generally need to be performed correctly for the processor to be considered viable, but the speed and efficiency at which the instructions are performed may determine whether the processor is considered to be high performance or more mediocre. Accordingly, various mechanisms throughout the processor may be implemented to help make sure that every instruction is not only performed correctly, but performed as efficiently and quickly (e.g., in as few clock cycles, etc.) as possible. Instruction pipelining, out-of-order execution, and various forms of parallel processing (e.g., on parallel pipelines within an execution unit, on parallel execution units, on parallel cores each with their own set of execution units, etc.) are a few examples of the types of mechanisms used to optimize processor performance.

[0020] Different types of instructions intermingled together in a particular piece of software (e.g., an application, program, subroutine, etc.) may be executed by different types of execution units. For example, arithmetic logic units (ALUs) may be configured to perform integer arithmetic (e.g., addition, subtraction, multiplication, division, etc.), logical operations (e.g., AND, OR, XOR, NOT, etc.), bitwise operations, and the like. Floating-point units (FPUs) may be configured to perform floating-point arithmetic (e.g., addition, subtraction, multiplication, division, square root, etc.). Branch units may be configured to execute branch instructions (e.g., conditional and unconditional jumps in the program). Load / Store Units (LSUs) may be configured to manage data transfers between CPU registers and the memory system (e.g., one or more levels of memory cache that is typically part of the processor or closely associated therewith and main memory that is typically more removed from the processor). For example, LSUs may be configured to perform load instructions (reading from memory, usually by way of one or more caches) and store instructions (writing to memory, usually by way of one or more caches).

[0021] These various types of instructions may be pre-processed in various ways (e.g., fetched from memory, decoded, and otherwise prepared) before being executed by the corresponding type of execution unit. The instructions may then be introduced into an issue queue (also referred to as an instruction queue or reservation station) to wait for the proper type of execution unit to become available to execute the instruction. However, even when the execution unit has availability to take on a new instruction and the issue queue provides one, a technical problem may arise in connection with the execution unit executing theAtty Docket No. 0120-1142 WO1instruction from the issue queue. Specifically, the execution unit may attempt to execute the provided instruction but may fail for some reason.

[0022] A few illustrative reasons for such a failure will be described in connection with an LSU tasked with attempting to execute a load instruction that requires the LSU to obtain data from a particular memory address. It will be understood, however, that other types of execution units may similarly fail and that other reasons for an instruction to fail to complete exist.

[0023] A first example reason for a failed attempt to execute the load instruction by the LSU could be that the data to be accessed has not been cached (e.g., prefetched, cached from a recent use of the data, etc.). In this situation, the LSU may receive a cache miss when attempting to load the data. Rather than stall for the relatively long period that it takes for data to be obtained from main memory (e.g., on the order of hundreds of clock cycles in certain examples), the LSU may consider the attempt to have failed and may be configured to put the instruction aside to try again later (e.g., in several hundred clock cycles after the cache has been able to attain the requested data).

[0024] A second example reason for a failed attempt to execute the load instruction by the LSU could include a miss in another resource such as a translation lookaside buffer (TLB). In this situation, the address translation needed may not be found in the TLB, so the processor may take extra time to look it up in the page tables in main memory.

[0025] A third example reason could be a structural hazard in which a shared hardware resource (e.g., a memory bus, etc.) is being used by another instruction. Still other example reasons could include dependence on other instructions that are not finished, memory access conflicts, hardware errors or issues, and so forth. When any of these types of failures are encountered, another attempt may be made (immediately or at a later time) to successfully execute (process and finish) the instruction. Such additional attempts at execution are referred to herein as instruction replays.

[0026] One way to orchestrate an instruction replay is to send the failed instruction back to the issue queue (from which it was provided) to wait, with the various other instructions for the various execution units, until an opportunity again arises for the instruction to be replayed at the execution unit (e.g., the LSU in this example). This solution, however, may lead to additional technical problems. First, there may be a certain amount of pre-processing work (e.g., address translation, etc.) that is performed between the issue queue dispatching an instruction and the execution unit receiving it. For every time an instruction is sent back to the issue queue without being completed, this pre-processing work is repeated,Atty Docket No. 0120-1142 WO1thereby creating an inefficiency (since it would be more efficient if the results of the preprocessing work, such as a translated address, could be maintained and used without redoing the work). Second, since the issue queue resources are limited and may be shared between many different execution units, storage space in the queue is valuable and limited, and it may be undesirable for the queue to be filled with lots of replay instructions (as opposed to new instructions that have not yet even been attempted).

[0027] At least one technical solution for these technical problems involves implementing a replay queue local to the execution unit (e.g., a local replay queue configured to replay instructions only from the LSU in the example above). Since this storage space is local and specifically configured for replay instructions that have already been attempted (rather than new instructions that have not), provision may be made to preserve preprocessing work that has already been performed (e.g., to store data associated with an address translation, etc.) and the inefficiency of redoing that pre-processing work may be avoided. Moreover, having a dedicated replay queue local to the execution unit may help avoid congesting the external (and shared) issue queue with replay instructions, thereby leaving more room for new instructions provided by upstream processes. Various beneficial technical effects may arise from replay queues including that replay from a local replay queue may be several cycles faster than from an issue queue and may be more likely to go through without further replays (thereby resulting in fewer replays, less power usage associated with the replays, and so forth).

[0028] The introduction of a replay queue means, however, that when an execution pipeline of the execution unit (e.g., a load / store pipeline of the LSU) comes available for processing a new instruction, an arbitration has to be performed to select whether the instruction comes from the issue queue or the replay queue. For example, an instruction arbiter may be included within the execution unit to select from between an instruction provided by the issue queue and an instruction provided by the replay queue when an execution pipeline is ready to accept a new instruction for processing. The instruction arbiter may be implemented by any hardware and / or logic that implements a decision-making function and includes a multiplexor for passing through the selected instruction. The decision-making function built into the instruction arbiter may operate based on a preconfigured algorithm. The decision-making function may be based on static factors and / or dynamic factors during operation, as will be further detailed below.

[0029] While not required, an arbitration algorithm would generally be configured to prioritize the replay queue so as to clear it out and complete earlier instructions to the extentAtty Docket No. 0120-1142 WO1possible before moving on to later instructions. When both the issue queue and replay queue provide a candidate instruction for one available slot in the processing pipeline, however, the instruction that loses the arbitration may itself need to be replayed even though it may not yet even have been properly attempted. For example, if a first instruction provided by the issue queue loses arbitration to a second instruction from the replay queue, the available resources of the execution unit (e.g., a load / store pipeline in the LSU example) may be dedicated to the second instruction while the first instruction is sent to the replay queue to be replayed later.

[0030] Inefficiency associated with this type of arbitration (selecting between an external issue queue and a local replay queue) may serve as a fine performance compromise (given the benefits described above that a dedicated replay queue provides) when an occasional new instruction from the issue queue loses arbitration and is sent to the replay queue. Another technical problem may arise, however, when conditions are such that every or almost every instruction being provided by the issue queue is losing arbitration and having to be rerouted through the replay queue. For example, if an LSU has many instructions in its replay queue that are prioritized over new instructions coming from a shared issue queue, every instruction from the issue queue may end up needing to pass through the replay queue before it can be selected for processing by the arbitration. This scenario is referred to herein as a runaway replay scenario and it may present a technical problem at least because it can cause the replay queue to be overly strained (e.g., possibly leading to a queue overflow) and because every instruction is faced with a longer and less efficient path to get to the execution pipeline. Processor performance may be negatively affected by these and other inefficiencies.

[0031] Along with the technical solutions described above, methods and systems described herein (e.g., processors, execution units, etc.) are configured to provide technical solutions to this technical problem of runaway replay scenarios. Specifically, an execution unit may be configured to identify or detect a runaway replay scenario and, in response, switch into a replay throttling mode that is configured to help break the vicious cycle of the runaway replay scenario. For example, once the runaway replay scenario is determined to be occurring, one type of replay throttling mode may temporarily cause instructions losing arbitration from the issue queue to return to be replayed from the issue queue, rather than being replayed from the replay queue. Another type of replay throttling mode may signal to the issue queue to temporarily cease providing any instructions while the replay queue is emptied out. In either case, the replay queue may receive fewer instructions, such that it becomes easier to clear out the replay queue with the replay throttling mode engaged than in normal operation. The execution unit may further be configured to determine when theAtty Docket No. 0120-1142 WO1negative effects of the runaway replay scenario have been sufficiently mitigated such that the execution unit may cease operating in the replay throttling mode and return to normal operation (with the replay throttling mode disengaged).

[0032] Various beneficial technical effects may arise from the use of technical solutions described herein to the technical problems that have been described. By implementing a replay throttling mode that is only used temporarily to facilitate mitigation of runaway replay scenarios, execution units described herein may receive all the benefits described above of using a replay queue, but without any (or with minimal) negative effects resulting from runaway replay scenarios. In this way, execution units may improve their performance and successfully process and complete more instructions in less time and using fewer limited resources (e.g., buffer space in the queues, etc.). This improved performance and resource efficiency may also be associated with other technical effects such as improved power consumption, improved battery life for the device incorporating the processor, and so forth.

[0033] Various implementations will now be described in more detail with reference to the figures. It will be understood that particular implementations described below are provided as non-limiting examples and may be applied in various situations. Additionally, it will be understood that other implementations not explicitly described herein may also fall within the scope of the claims set forth below. Optimized instruction replay using a throttling mode in the ways described herein may result in any or all of the technical effects mentioned above, as well as various additional and / or alternative beneficial technical effects described and / or made apparent below.

[0034] FIG. 1 shows certain aspects of an illustrative implementation 100 of optimized instruction replay using a throttling mode in accordance with principles described herein. As shown, implementation 100 involves an execution unit 102 that incorporates within it a pipeline 104 (also referred to as an execution pipeline), a replay queue 106, and an instruction arbiter 108. External to execution unit 102, implementation 100 is also shown to involve an issue queue 110. Also drawn within the box associated with execution unit 102 is a switch 112 labeled “Replay Throttling Mode.” Unlike the other elements shown in execution unit 102, switch 112 will be understood to represent not necessarily a physical component, but a mode of operation (a replay throttling mode) in which execution unit 102 may operate. More particularly, when the switch is set to “OFF” (as shown in FIG. 1), execution unit 102 may be configured to be in a normal operating mode (i.e., the replay throttling mode is disengaged). When the switch is set to “ON,” however (as indicated by aAtty Docket No. 0120-1142 WO1toggle 114 that shows the switch flipping to the other side), the replay throttling mode may be engaged and execution unit 102 may be configured to operate in the replay throttling mode. While not explicitly shown in FIG. 1, it will be understood that the illustrated components of implementation 100 (as well as various additional components) may all be included in a processor such as a CPU. An example processor including implementations of these components will be described and illustrated below.

[0035] As outlined above, an issue queue such as issue queue 110 may store zero or more instructions 116 that may be in various stages of readiness to be processed by execution unit 102. For example, certain instructions 116 may be ready for execution as soon as execution unit 102 is prepared to take them or as soon as other instructions before them in the issue queue have been processed. Other instructions 116 may be less prepared for execution and may be, for instance, in a sleep state in which the instruction is waiting for one or more events to occur such as for a certain time period to pass, for certain data to be obtained (e.g., from memory to a cache), for another instruction to complete, or the like.

[0036] Similar to issue queue 110, replay queue 106 also includes zero or more instructions 116 that also may be in various states or stages of readiness. As described above, however, there may be certain differences between the instructions 116 in issue queue 110 and the instructions 116 in replay queue 106. First, as mentioned above and as will be illustrated in more detail below, the instructions 116 in issue queue 110 may represent a variety of different types of instructions targeting not only the illustrated execution unit 102 but, possibly, also targeting one or more additional execution units of different types. For instance, if execution unit 102 is assumed to be a load / store unit (LSU) that is configured to process load instructions and store instructions, the instructions 116 in issue queue 110 may include load and store instructions for the LSU along with other types of instructions intended for other types of execution units (e.g., add instructions intended for an ALU, multiplication instructions intended for an FPU, branch instructions intended for a branch unit, etc.).Additionally, while the instructions 116 in issue queue 110 could be instructions that are awaiting replay, it is generally desirable for most or all of the instructions 116 in issue queue 110 to be new instructions that are received from upstream processing stages (not shown) rather than replay instructions that have been previously dispatched to corresponding execution units.

[0037] In contrast, the instructions 116 of replay queue 106 may include only instructions of the type that execution unit 102 is configured to execute (e.g., load instructions and / or store instructions for the example where execution unit 102 is an LSU).Atty Docket No. 0120-1142 WO1Additionally, all of the instructions 116 in replay queue 106 may be replay instructions either because their execution by pipeline 104 failed when it was attempted or because they lost arbitration to another instruction and were not able to be processed when they were presented to execution unit 102 previously. Because replay queue 106 is more limited in the types of instructions it stores, it will be understood that replay queue 106 may be smaller than issue queue 110 (not explicitly shown), though each of these buffers may be any suitable size as may serve a particular implementation.

[0038] Various arrows are depicted in FIG. 1 to show different data paths whereby data, and particularly instructions 116, may move from component to component when execution unit 102 is in operation. For example, a data path 118 may be used to provide instructions 116 from the external issue queue 110 to execution unit 102 (and to instruction arbiter 108, more particularly). A data path 120 may then be used to similarly provide instructions 116 from the replay queue 106 (local to execution unit 102) to instruction arbiter 108. When candidate instructions 116 are provided by both data path 118 and data path 120 and pipeline 104 has one availability to process a candidate instruction, instruction arbiter 108 may be configured to select one of the instructions to be provided to pipeline 104 on a data path 122, while the other (unselected) candidate instruction is slated for replay and provided to replay queue 106 by way of a data path 124.

[0039] Additionally, if pipeline 104 attempts and fails (for any of the reasons mentioned above) to execute the instruction received by way of data path 122, pipeline 104 may similarly send that failed instruction, via a data path 126, to be replayed from replay queue 106 at a later time. For example, pipeline 104 may be configured to process a particular instruction 116 based on instruction arbiter 108 selecting that instruction from one of the queues 106 or 110. Execution unit 102 may then determine that the processing of the first instruction is unsuccessful, or in other words, that the execution of the selected instruction is not able to be completed. For example, as mentioned above, the determining that the processing of the instruction is unsuccessful could include determining a cache miss associated with the processing of the instruction, determining that a processing resource is currently unavailable for use in the processing of the instruction (e.g., a structural hazard, etc.), or determining that another obstacle is keeping pipeline 104 from successfully completing the instruction. Based on the determining that the processing of the instruction is unsuccessful, execution unit 102 may then direct the instruction to be replayed from replay queue 106 (via data path 126).

[0040] As detailed below, it will be understood that the replay throttling modeAtty Docket No. 0120-1142 WO1represented by switch 112 may be kept disengaged (OFF) under most circumstances so that data flows in accordance with the description above. However, when a number of instructions 116 accumulate in replay queue 106, a runaway replay scenario may be detected in which instruction arbiter 108 is repeatedly selecting instructions from replay queue 106 (data path 120) rather than from issue queue 110 (data path 118), such that virtually every new instruction is needing to flow from issue queue 110 to instruction arbiter 108 (data path 118) just to lose arbitration and be queued for replay (data path 124) before finally being presented to instruction arbiter 108 (data path 120) in a circumstance where it can be selected in the arbitration and be processed by pipeline 104 (data path 122). This runaway replay scenario may cause processor performance to be diminished. Accordingly, when it is detected, execution unit 102 may be configured to temporarily engage the replay throttling mode (toggle 114 of switch 112) until the runaway replay scenario is detected to abate or become less consequential. Differences in the operation of the execution unit 102 when operating in the replay throttling mode will be described in more detail below.

[0041] FIG. 2 shows certain aspects of an illustrative processor 200 configured to perform optimized instruction replay using a throttling mode in accordance with principles described herein. As shown, illustrative processor 200 includes implementations of various elements described in relation to implementation 100 above, as well as certain additional elements that will now be described. The elements of illustrative processor 200 shown in FIG. 2 are limited to those elements relevant to implementing optimized instruction replay using a throttling mode in accordance with principles described herein. As such, it will be understood that illustrative processor 200 may further include a variety of additional functional elements that are not shown in FIG. 2 and are beyond the scope of this description.

[0042] As shown in FIG. 2, processor 200 may include a plurality of execution units 102 (i.e., an execution unit 102-1, an execution unit 102-2, and execution unit 102-3, and other execution units represented by an ellipsis in certain examples). As described above, each of these execution units 102 may represent different types of execution units such as an LSU, an ALU, an FPU, a branch unit, and so forth. Within execution unit 102-1, certain internal elements are depicted. For example, execution unit 102-1 is shown to include a plurality of pipelines 104-1, 104-2, and 104-3 (as well as additional execution pipelines represented by an ellipsis) each configured to process instructions; a replay queue 106 local to the execution unit 102-1; and an instruction arbiter 108 that may be configured to make arbitration selections for all of the plurality of pipelines. For purposes of illustration, execution unit 102-1 will be assumed, like execution unit 102 described above, to beAtty Docket No. 0120-1142 WO1implemented as an LSU of processor 200. As such, each pipeline 104-1 to 104-3 may be configured to perform both load instructions (in which data is obtained from memory) and store instructions (in which data is stored in memory). To this end, execution unit 102-1 is shown to connect to a cache / memory 202 that represents one or more levels of data caching and a main memory from which the LSU may obtain requested data and to which the LSU may write data. While internal elements of execution units 102-2 and 102-3 are not shown in FIG. 2, it will be understood that these units could include similar or different elements as described above for execution unit 102-1.

[0043] Also included in processor 200 along with the various execution units 102 is an issue queue 110 external to the execution units 102, as well as pre-processing 204 that represents certain hardware configured to perform one or more pre-processing operations on instructions provided to the execution units by the issue queue 110. As mentioned above and as illustrated in processor 200, the issue queue 110 may be shared by not only execution unit 102-1 (i.e., the LSU that includes the pipelines 104 configured to perform the load and store instructions in this example), but also by one or more additional execution units (e.g., execution unit 102-2, execution unit 102-3, etc.) configured to process other types of instructions besides the load and store instructions. Accordingly, as mentioned above, the issue queue will be understood to store and provide instructions for both the LSU and the additional execution units.

[0044] The pre-processing operation performed at pre-processing 204 may take at least one clock cycle between the instruction being dispatched by issue queue 110 and the instruction being received by an instruction arbiter of the target execution unit (e.g., instruction arbiter 108 of the LSU execution unit 102-1 in the example of a load or store instruction). For example, pre-processing 204 may represent address translation processing for the instruction dispatched by issue queue 110 for the execution unit or other such processing that may be performed prior to processing by the target execution unit. Due at least in part to this pre-processing work (and the at least one clock cycle that it takes), it will be understood that it may be faster and more efficient to replay instructions from the local replay queue 106 of the execution unit 102-1 than to replay instruction from the shared, external issue queue 110. Along with the pre-processing operation, issue queue 110 may also be physically farther from the execution pipelines of the execution unit (i.e., pipelines 104-1 through 104-3), which may also contribute to the inefficiency of replaying instructions from the issue queue 110.

[0045] Consequently, it would generally be more efficient to replay instructions fromAtty Docket No. 0120-1142 WO1replay queue 106 and, if instructions are being provided by both issue queue 110 and replay queue 106 at a given time (e.g., for a given arbitration selection that is to be made by instruction arbiter 108), the instruction from replay queue 106 may generally be prioritized. For example, in operation, replay queue 106 may be configured to provide a first instruction to instruction arbiter 108, issue queue 110 may be configured to provide a second instruction to instruction arbiter 108, and instruction arbiter 108 may be configured to select, as an arbitration selection between the first instruction and the second instruction, the first instruction to be processed by a particular pipeline of execution unit 102-1 (e.g., one of pipelines 104-1 through 104-3 that has availability to process a new instruction). In this example, based on instruction arbiter 108 selecting the first instruction (provided by replay queue 106), execution unit 102-1 may determine to operate in a replay throttling mode that includes directing the second instruction to be replayed from the issue queue instead of from the replay queue. As will be described in more detail below, this may help break the cycle of a runaway replay scenario that is detected based on instruction arbiter 108 selecting the first instruction provided by replay queue 106. Alternatively, execution unit 102-1 may determine to operate in the replay throttling mode by directing issue queue 110 to cease providing instructions to execution unit 102-1 until the replay throttling mode is disengaged (e.g., when replay queue 106 can be at least somewhat cleared out).

[0046] Additional details of this optimized instruction replay using a throttling mode will now be described in relation to FIG. 3 (the overarching method), FIGS. 4A-4C (detecting the runaway replay scenario and when to enter the replay throttling mode), FIGS. 5A-5C (operating in a first type of replay throttling mode), FIGS. 6A-6C (operating in a second type of replay throttling mode), and FIGS. 7A-7C (detecting when to exit the replay throttling mode).

[0047] FIG. 3 shows an illustrative method 300 for optimized instruction replay using a throttling mode in accordance with principles described herein. Method 300 may be performed by a processor (e.g., an implementation of processor 200) or, more particularly, by certain components thereof (e.g., an execution unit such as an LSU coupled with an issue queue, etc.). While FIG. 3 shows illustrative operations according to a specific implementation, it will be understood that other implementations of this method may omit, add to, reorder, and / or modify any of the operations that are explicitly represented in FIG. 3. Additionally, while the operations of method 300 are illustrated with arrows suggestive of a sequential order of operation, it will be understood that one or more of the operations of method 300 may be performed concurrently (e.g., in parallel) with one another.Atty Docket No. 0120-1142 WO1

[0048] At operation 302, an execution unit (e.g., one of execution units 102 described above, such as an LSU represented by execution unit 102-1) may make an arbitration selection between a first instruction and a second instruction. The first instruction may be provided by a replay queue local to the execution unit, while the second instruction may be provided by an issue queue external to the execution unit. In the arbitration selection of operation 302, the execution unit may select the first instruction to be the one processed next by a pipeline of the execution unit. Indeed, as mentioned above, an instruction arbiter responsible for the arbitration selection may be configured to prioritize the replay queue when selecting between candidate instructions provided by the replay queue and the issue queue. Replay instructions tend to be earlier in the program execution than non-replay (i.e., new) instructions that are being arbitrated or processed by the execution unit for the first time. As such, this prioritization may help finalize execution for earlier instructions as soon as possible since these are more likely to cause stalls or other inefficiencies (as later instructions depend from them, etc.).

[0049] At operation 304, the execution unit may determine that the execution unit is to operate in a replay throttling mode. This determination may be made, for example, based on the selecting of the first instruction (provided by the replay queue) at operation 302 and based on any suitable rule or algorithm associated with a pattern of selections made by the instruction arbiter that signals a runaway replay scenario. For instance, one example rule or algorithm may identify a runaway replay scenario when a predetermined threshold number of arbitration selections (e.g., 4 arbitration selections, 8 arbitration selections, 12 arbitration selections, etc.) are made consecutively in favor of the replay queue. In one scenario, for instance, the selection of the first instruction at operation 302 could be the final arbitration selection from the replay queue that completes the threshold number of such selections (e.g., the 5th consecutive arbitration selection from the replay queue in an implementation where the predetermined threshold is 5). In other words, in this scenario, the determining that the execution unit is to operate in a replay throttling mode may: 1) be performed when the execution unit is not already operating in the replay throttling mode; 2) include a determination that the execution unit is to enter the replay throttling mode (i.e., that the replay throttling mode is to be engaged or toggled from off to on); and 3) be based on the arbitration selection completing the threshold number of consecutive arbitration selections of instructions provided by the replay queue instead of instructions provided by the issue queue.

[0050] In contrast, in a different scenario in which the replay throttling mode is already engaged, the selecting of the first instruction from the replay queue at operation 302Atty Docket No. 0120-1142 WO1may form a basis for operation 304 to determine that the execution unit is to continue operating in the replay throttling mode (rather than entering the replay throttling mode such as described for the other scenario). For example, if a rule or algorithm requires at least a predetermined threshold of consecutive selections from the replay queue while operating in the replay throttling mode to exit the mode (i.e., a different threshold than mentioned above for entering the replay throttling mode), the determination at operation 304 to operate in the replay throttling mode may be a determination to continue in the replay throttling mode due to the threshold not yet being satisfied. For instance, the selection at operation 302 could be only the 3rd arbitration selection from the replay queue since the replay throttling mode became engaged and the rule could require that there be five such selections before the mode is disengaged. As another example, the replay throttling mode may be configured to exit (i.e., be disengaged or toggled from on to off) if an instruction from the replay queue loses arbitration to an instruction from the issue queue. Accordingly, if this is the rule, the selection of the instruction from the replay queue at operation 302 would indicate that the replay queue did not lose arbitration to the issue queue on this particular arbitration selection, and thus the replay throttling mode should remain engaged for the time being.

[0051] Before continuing to describe the operations of method 300, FIGS. 4A-4C show certain aspects of how a runaway replay scenario may be detected to occur while a processor is not operating in a replay throttling mode in accordance with principles described herein. In other words, FIGS. 4A-4C show how the determination at operation 304 may be made, based on the selection of operation 302, for the earlier scenario in which the replay throttling mode is first entered or initially engaged. In FIGS. 4A-4C (as well as in FIGS. 5A-5C, FIGS. 6A-6C, and FIGS. 7A-7C, described in more detail below), various snapshots of the elements that have already been described (e.g., in relation to FIGS. 1-2, etc.) are illustrated as operations are ongoing and notable events are occurring. The elements that have already been described will hence not be described again in relation to the following figures, except to the extent that additional context is needed to explain the aspects being illustrated in these figures.

[0052] In FIG. 4A, a snapshot 400-A illustrates a moment where the replay throttling mode is disengaged (i.e., switch 112 is set to OFF, indicating that the processor is in the normal operating mode) and both issue queue 110 and replay queue 106 are providing respective instructions to instruction arbiter 108 for an arbitration selection to be made. More particularly, replay queue 106 is shown to be providing a first instruction 116-1 (via data path 120) while execution unit 102 is shown to be providing a second instruction 116-2 (via dataAtty Docket No. 0120-1142 WO1path 118). As shown, each of the instructions 116-1 and 116-2 are shaded with different fill patterns to differentiate them from one another and from other instructions that may still be in the queues. The fill patterns also illustrate that the instructions may retain their spot in their queue until they are successfully executed or at least selected for arbitration. As such, it will be understood that when an instruction is described as losing arbitration and being sent back to the queue that provided it, the return may involve data movement (e.g., an instruction being transmitted from the arbiter to the queue) or, more efficiently, may involve simply not releasing the slot of the queue so that it is retained until the instruction is actually selected and executed.

[0053] In FIG. 4B, a snapshot 400-B will be understood to follow after snapshot 400-A when instruction arbiter 108 has completed the arbitration selection and chosen first instruction 116-1 to be processed by pipeline 104. A shown, second instruction 116-2, which lost the arbitration, is sent (via data path 124) to replay queue 106 to be replayed at a later time. First instruction 116-1 is then provided (via data path 122) to pipeline 104 for processing. The slot associated with first instruction 116-1 in replay queue 106 may be maintained until first instruction 116-1 is known to have executed successfully or the slot may be released (not shown) and a new slot allocated in the event that first instruction 116-1 fails to be completed and is sent back (via data path 126) to be replayed again.

[0054] If replay queue 106 has several instructions waiting for replay and these are prioritized over instructions from issue queue 110 (as they generally would be), the events depicted by snapshots 400-A and 400-B may tend to recur again and again. As has been described, this is referred to herein as a runaway replay scenario and, when it can be identified by the execution unit 102, the replay throttling mode may be engaged to help break out of the vicious cycle it causes. It will be understood that the events of snapshots 400-A and 400-B are proper and not themselves indicative of a runaway replay scenario (e.g., if they only occurred once). It is when these events are being observed several times in sequence (e.g., close together in time, consecutively, etc.) that a runaway replay scenario may be identified. For example, one rule or algorithm could define a runaway replay scenario as occurring when the instruction arbiter 108 selects the replay queue instruction over the issue queue instruction five times in a row (or another suitable threshold number or pattern), thereby sending five consecutive instructions from the issue queue through the replay queue rather than directly to the pipeline.

[0055] To illustrate, FIG. 4C shows a snapshot 400-C in which a route 402 from issue queue 110 to pipeline 104 is shown to pass through not only the instruction arbiter 108 butAtty Docket No. 0120-1142 WO1also the replay queue 106. When virtually every instruction (e.g., a threshold number of consecutive instructions) from issue queue 110 is having to take route 402, rather than a more direct route in which the instruction is selected in the arbitration and goes straight to the pipeline without waiting again in the replay queue 106, execution unit 102 may determine that a runaway replay scenario is ongoing and, in response, may be configured to engage the replay throttling mode. To illustrate, snapshot 400-C shows a toggle 404 of switch 112 to represent the replay throttling mode being engaged when the Nth instruction from issue queue 110 has been observed to take route 402 to be executed by execution unit 102 (where N is a predetermined threshold defined by an algorithm or rule to be appropriate for a particular implementation).

[0056] Returning to FIG. 3, at operation 306-1, the execution unit may direct the second instruction to be replayed from the issue queue instead of from the replay queue. This direction may be based on the determining, at operation 304, that the execution unit is to operate in the replay throttling mode. For example, as described above, the determination at operation 304 may indicate that the execution unit is to enter the replay throttling mode (if the entrance threshold is satisfied and the mode is not yet engaged) or is to remain in the replay throttling mode (if the mode was engaged previously and the exit threshold is not satisfied). Based on this determination, operation 306-1 represents a first option (“Option 1”) for how the replay throttling mode may be implemented to help break out of the runaway replay scenario that has been detected.

[0057] To illustrate this first option, FIGS. 5A-5C show certain aspects of how execution unit 102 may operate in this first type of replay throttling mode in accordance with principles described herein. First, a snapshot 500-A in FIG. 5A illustrates an identical situation as described above in relation to snapshot 400- A in FIG. 4 A, except that switch 112 shows that the replay throttling mode is now engaged (i.e., set to ON). More particularly, as shown in snapshot 500-A, first instruction 116-1 is provided (via data path 120) to instruction arbiter 108 by replay queue 106 while second instruction 116-2 is provided to instruction arbiter 108 (via data path 118) by issue queue 110.

[0058] As with the situation in snapshot 400-A when the replay throttling mode was not engaged, the instruction 116-1 from the replay queue 106 is likely to receive priority and be selected from the two candidate instructions presented. However, based on the engagement of the replay throttling mode (i.e., the first type of replay throttling mode represented by operation 306-1) in this scenario, a snapshot 500-B of FIG. 5B shows a different outcome than was illustrated by snapshot 400-B when the replay throttling modeAtty Docket No. 0120-1142 WO1was still off. Specifically, snapshot 500-B again shows first instruction 116-1 being selected by instruction arbiter 108 and provided for processing (via data path 122) to pipeline 104. However, instead of sending second instruction 116-2 to be replayed from replay queue 106 (as was done when the replay throttling mode was disengaged in FIG. 4B), snapshot 500-B shows second instruction 116-2 being sent back (via a data path 502) to be replayed from issue queue 110. In this way, the stream of instructions flowing along route 402 into replay queue 106 is throttled (i.e., slowed, reduced, etc.) and it becomes easier for execution unit 102 to empty out replay queue 106 so that it can better focus on its primary purpose of replaying instructions that arrived via data path 126 (after actually encountering execution issues) rather than those that arrived via data path 124 (after losing arbitration and without processing yet having even been attempted).

[0059] A snapshot 500-C in FIG. 5C is shown to include a route 504 that instructions 116 from issue queue 110 may take to pipeline 104 while the replay throttling mode is engaged (i.e., while switch 112 is ON, such as in the events depicted in snapshots 500-A and 500-B). As shown by route 504, the instructions may be provided to instruction arbiter 108 and, when losing arbitration, may return to wait in issue queue 110 until they are put up for arbitration again at a later time (at which point they eventually are provided to pipeline 104 for processing, as shown). As described above, this route 504 is similar to the route that would be used if no replay queue 106 were to be implemented at all. As such, by temporarily imposing the conventional inefficiencies and drawbacks of replaying from the issue queue 110, execution unit 102 may be able to process more of the instructions from the replay queue 106 and thereby mitigate the runaway replay scenario so that the replay throttling mode can soon be disengaged so that the benefits of the replay queue can again be enjoyed.

[0060] Returning to FIG. 3, at operation 306-2, the execution unit may direct the issue queue to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode. This direction, as with the alternative direction of operation 306-1, may also be based on the determining, at operation 304, that the execution unit is to operate in the replay throttling mode. For example, as described above, the determination at operation 304 may indicate that the execution unit is to enter the replay throttling mode (if the entrance threshold is satisfied and the mode is not yet engaged) or is to remain in the replay throttling mode (if the mode was engaged previously and the exit threshold is not satisfied). Based on this determination, operation 306-2 then represents a second option (“Option 2”) for how the replay throttling mode may be implemented to help break out of the runaway replay scenario that is ongoing.Atty Docket No. 0120-1142 WO1

[0061] To illustrate this second option, FIGS. 6A-6C show certain aspects of how execution unit 102 may operate in this second type of replay throttling mode in accordance with principles described herein. First, a snapshot 600-A in FIG. 6A illustrates a similar situation as described above in relation to snapshot 500-A in FIG. 5A (including that switch 112 shows that the replay throttling mode is engaged or set to ON), except that instruction arbiter 108 has now communicated to issue queue 110 (via a data path 602) that the issue queue is to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode. In response to this communication, snapshot 600-A illustrates a data path 604 that, rather than extending to instruction arbiter 108 as with data path 118 above, is halted (by a stop sign symbol) to indicate that instructions 116 from issue queue 110 are not being provided to instruction arbiter 108.

[0062] Consequently, as shown in a snapshot 600-B in FIG. 6B, no arbitration selection is necessary while this type of replay throttling mode is engaged since only the replay queue 106 is even presenting instructions 116 to instruction arbiter 108. First instruction 116-1 from replay queue 106 is shown in snapshot 600-B to be provided to pipeline 104 since it is the only selection instruction arbiter 108 can make while issue queue 110 is abstaining from providing further instructions 116 (data path 604). Similar to the first type of replay throttling mode illustrated in FIG. 5B, this replay throttling functions to cut off or otherwise throttle the stream of instructions flowing along route 402 into replay queue 106, thereby making it easier for execution unit 102 to empty out replay queue 106 so that it can better focus on its primary purpose of replaying instructions that arrived via data path 126 rather than via data path 124.

[0063] A snapshot 600-C in FIG. 6C is shown to include a route 606 that instructions 116 from issue queue 110 may take to pipeline 104 when this second type of replay throttling mode is used. As shown by route 606, once the instructions are provided to instruction arbiter 108, they may be selected straightaway to be presented to pipeline 104 for processing.However, while the replay throttling mode is actually engaged, they may wait longer in issue queue 110 (as represented by the stop sign symbol on route 606). As such, by temporarily stalling instructions 116 from issue queue 110, execution unit 102 may be able to process more of the instructions from the replay queue 106 and thereby mitigate the runaway replay scenario so that the replay throttling mode can soon be disengaged and the benefits of the replay queue can again be enjoyed.

[0064] It is noted, that certain inefficiencies may arise in this second type of replay throttling mode that would not necessarily manifest with the first type of replay throttlingAtty Docket No. 0120-1142 WO1mode illustrated in FIGS. 5A-5C. For example, there could be certain arbitration selections (i.e., clock cycles in which a new instruction can be selected for processing) in which replay queue 106 does not have any instructions that are awake and ready to be processed.Accordingly, if issue queue 110 had provided a candidate instruction for consideration by instruction arbiter 108 in this scenario, the candidate instruction from issue queue 110 may well have been selected and processed. Since issue queue 110 abstains in this mode from even providing candidate instructions for consideration, however, these opportunities to pass instructions from issue queue 110 to pipeline 104 while the replay throttling mode is engaged would not be taken advantage of. In other words, this second replay throttling mode of FIGS.6A-6C, in which issue queue 110 abstains from providing instructions, may be more conservative and less efficient than the first replay throttling mode of FIGS. 5A-5C, in which instructions from issue queue 110 are provided just in case there is a chance of them being selected.

[0065] Returning to FIG. 3, operation 302, operation 304, and both options represented by operations 306-1 and 306-2 relate to determining when to engage the replay throttling mode and how to operate within the replay throttling mode to weaken and diminish a runaway replay scenario that has been identified. Operation 308, operation 310, and both options represented by operations 312-1 and 312-2 (corresponding respectively to the options of operations 306-1 and 306-2 above) relate to determining when the runaway replay scenario has sufficiently abated that the replay throttling mode may be disengaged and the normal operating mode may be resumed.

[0066] More specifically, at operation 308, an additional arbitration selection between a third instruction and a fourth instruction may be made (e.g., by the instruction arbiter 108) and the third instruction may be selected (instead of the fourth instruction) to be processed by the pipeline of the execution unit. This additional arbitration selection may be made while the execution unit operates in the replay throttling mode, as described above. For example, this additional arbitration selection may be similar to either of those whose setup is shown by snapshots 500-A or 600-A and whose outcome is shown by snapshots 500-B or 600-B.

[0067] At operation 310, the execution unit may determine that it is to cease operating in the replay throttling mode. For example, this determination may be made while the execution unit operates in the replay throttling mode. In some cases, the determination to cease operating in the replay throttling mode may be based on the selection of the third instruction at operation 308, while in other cases the determination may be made based on other criteria.Atty Docket No. 0120-1142 WO1

[0068] To illustrate some examples of criteria that may lead to the determination at operation 310 to cease operating in the replay throttling mode, FIGS. 7A-7C show certain aspects of various ways a runaway replay scenario may be detected to abate while a processor is operating in a replay throttling mode in accordance with principles described herein.

[0069] In FIG. 7A, a snapshot 700-A is shown to represent a scenario, similar to snapshot 500-B, where an instruction 116-3 from replay queue 106 is selected and sent to pipeline 104 for processing while an instruction 116-4 from issue queue 110 loses the arbitration. In this implementation of the additional arbitration selection between the third instruction 116-3 and the fourth instruction 116-4, FIG. 7 A shows that the third instruction 116-3 is provided by replay queue 106 while the fourth instruction 116-4 is provided by issue queue 110. The determining that execution unit 102 is to cease operating in the replay throttling mode may be based on a determination that the selecting of the third instruction completes a threshold number of selections, in consecutive arbitration selections, of instructions provided by replay queue 106 instead of instructions provided by issue queue 110. More particularly, for example, a counter 702-A may be implemented to keep a count of consecutive arbitration selections in which the replay queue instruction (i.e., third instruction 116-3 in this example) is observed to be selected over the issue queue instruction (i.e., fourth instruction 116-4 in this example). When a predetermined exit threshold (“Threshold”) of such selections has been counted by counter 702-A, a toggling 704 of the replay throttling mode may be made to disengage the replay throttling mode (i.e., toggle switch 112 to OFF). It will be understood that the exit threshold used for this purpose may be the same or different from an entrance threshold mentioned above to be used to determine when the replay throttling mode is to be entered.

[0070] In FIG. 7B, a snapshot 700-B is again (like snapshot 700-A) shown to represent a scenario where the instruction from replay queue 106 is selected and sent to pipeline 104 for processing while the instruction from issue queue 110 loses the arbitration. In this implementation of the additional arbitration selection between the third instruction and the fourth instruction, FIG. 7B shows again that the third instruction 116-3 is provided by replay queue 106 while the fourth instruction 116-4 is provided by issue queue 110.However, in this example (in contrast to the example of snapshot 700-A), the determining that execution unit 102 is to cease operating in the replay throttling mode may be based on a determination that execution unit 102 has operated in the replay throttling mode for a threshold number of consecutive clock cycles. More particularly, for example, a counter 702-B may be implemented to keep a count of clock cycles that pass while execution unit 102Atty Docket No. 0120-1142 WO1operates in the replay throttling mode, regardless of which instruction is selected in one or more arbitration selections during that period. When a predetermined exit threshold (“Threshold”) of such clock cycles has been counted by counter 702-B (i.e., after a predetermined amount of time has passed), the same toggling 704 of the replay throttling mode may be made to disengage the replay throttling mode (i.e., toggle switch 112 to OFF). Here again, it will be understood that the exit threshold used for this purpose may be the same or different from other entrance and exit thresholds described herein.

[0071] In FIG. 7C, a snapshot 700-C is shown to represent a scenario where the instruction 116-3 that is selected by instruction arbiter 108 and provided for processing to pipeline 104 is not from replay queue 106 (as was the case in FIGS. 7A and 7B) but from issue queue 110 (as illustrated by the fill shading of the instruction). For example, this scenario could occur if replay queue 106 was completely emptied out in the replay throttling mode, such that there are no instructions 116 left in the replay queue and instruction arbiter 108 passes through the only candidate it receives. As another possibility, this scenario could occur if the instructions in replay queue 106 are all detected to be in states (e.g., sleep states) where they are known to not be ready for processing. For example, there could be an instruction 116 in replay queue 106 that is waiting for data to come back from memory and will remain in a sleep state until such time that the requested data is obtained. As yet another possibility, this scenario could occur if replay queue 106 possesses an instruction 116-4 (not shown in FIG. 7C) that is awake and presented to instruction arbiter 108, but for some other reason, the rule or algorithm happens to select the third instruction 116-3 from issue queue 110. In any of these cases, the third instruction selected by instruction arbiter 108 is shown to be provided by issue queue 110, while any fourth instruction (not selected) is provided by replay queue 106. The determining that the execution unit is to cease operating in the replay throttling mode is thus in response to the selecting of this third instruction provided by issue queue 110. This is illustrated in FIG. 7C by a dotted arrow extending from the selected third instruction 116-3 to the toggling 704 of the replay throttling mode at switch 112 (toggling the switch to OFF) that is made to disengage the replay throttling mode.

[0072] For any of the described manners of determining when the execution unit is to cease operating in the replay throttling mode (i.e., any of the concepts illustrated by FIGS. 7A-7C), it will be understood that the determining that the execution unit is to cease operating in the replay throttling mode may further be based on dynamic factors such as a quantity of instructions in the replay queue. For example, the exit thresholds described above may be dynamically determined based on how many instructions 116 are present in replayAtty Docket No. 0120-1142 WO1queue 106 at a given time (e.g., such that the exit threshold of instructions is no greater than the quantity of instruction in the queue, such that the exit threshold of clock cycles is dependent on the number of instructions left to empty out of the queue, etc.).

[0073] Returning to FIG. 3, operations 312-1 and 312-2 show alternative options (“Option 1” and “Option 2,” respectively) for how to disengage the replay throttling mode based on the determination of operation 310 in any of the ways illustrated in FIGS. 7A-7C. Operation 312-1 will be understood to correspond to operation 306-1, while operation 312-2 will be understood to correspond to operation 306-2.

[0074] At operation 312-1, the execution unit may direct, based on the determining at operation 310 that the execution unit is to cease operating in the replay throttling mode and based on the additional arbitration selection, the fourth instruction to be replayed from the replay queue instead of from the issue queue. In other words, as shown in FIGS. 7A and 7B, as the replay throttling mode is disengaged and the normal mode resumed, the fourth instruction (i.e., fourth instruction 116-4 in these examples) and subsequent non-selected instructions may again be sent to replay queue 106 to be replayed from there (similarly as described in relation to FIGS. 4A-4C before the replay throttling mode was engaged).

[0075] At operation 312-2, the execution unit may direct the issue queue to resume providing instructions to the execution unit. As with operation 312-1, this may be based on the determining at operation 310 that the execution unit is to cease operating in the replay throttling mode and based on the additional arbitration selection. In other words, the direction from operation 306-2 for the issue queue to abstain from providing further instructions to the execution unit may be reversed or withdrawn such that the issue queue may resume providing candidate instructions for arbitration.

[0076] As has been mentioned, various methods and processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices. In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer-readable medium (e.g., a memory, etc.), and executes those instructions, thereby performing one or more operations such as the operations described herein. Such instructions may be stored and / or transmitted using any of a variety of known computer-readable media.

[0077] A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including, but not limited to, non-volatile media, and / orAtty Docket No. 0120-1142 WO1volatile media. Non-volatile media may include, for example, optical or magnetic disks and other persistent memory. Volatile media may include, for example, dynamic random-access memory (DRAM), which typically constitutes a main memory.

[0078] FIG. 8 shows an illustrative computing device 800 that may use or implement one or more processors (e.g., CPUs, etc.) such as those described herein. As shown in FIG. 8, computing device 800 may include a communication interface 802, a processor 804 (which may represent an implementation of processor 200 with various execution units such as execution units 102 in connection with a shared issue queue such as issue queue 110), a storage device 806, and an input / output (VO) module 808 communicatively connected via a communication infrastructure 810. While an illustrative computing device 800 is shown in FIG. 8, the components illustrated in FIG. 8 are not intended to be limiting. Additional or alternative components may be used in other embodiments. Components of computing device 800 shown in FIG. 8 will now be described in additional detail.

[0079] Communication interface 802 may be configured to communicate with one or more computing devices. Examples of communication interface 802 include, without limitation, a wired network interface (such as a network interface card), a wireless network interface (such as a wireless network interface card), a modem, an audio / video connection, and any other suitable interface.

[0080] Processor 804 generally represents any type or form of processing unit capable of processing data or interpreting, executing, and / or directing execution of one or more of the instructions, processes, and / or operations described herein. Processor 804 may direct execution of operations in accordance with one or more applications 812 or other computerexecutable instructions such as may be stored in storage device 806 or another computer-readable medium.

[0081] Storage device 806 may include one or more data storage media, devices, or configurations and may employ any type, form, and combination of data storage media and / or device. For example, storage device 806 may include, but is not limited to, a hard drive, network drive, flash drive, magnetic disc, optical disc, RAM, dynamic RAM, other non-volatile and / or volatile data storage units, or a combination or sub-combination thereof. Electronic data, including data described herein, may be temporarily and / or permanently stored in storage device 806. For example, data representative of one or more executable applications 812 configured to direct processor 804 to perform any of the operations described herein may be stored within storage device 806. In some examples, data may be arranged in one or more databases residing within storage device 806.Atty Docket No. 0120-1142 WO1

[0082] I / O module 808 may include one or more I / O modules configured to receive user input and provide user output. One or more I / O modules may be used to receive input for a single virtual experience. I / O module 808 may include any hardware, firmware, software, or combination thereof supportive of input and output capabilities. For example, I / O module 808 may include hardware and / or software for capturing user input, including, but not limited to, a keyboard or keypad, a touchscreen component (e.g., touchscreen display), a receiver (e.g., an RF or infrared receiver), motion sensors, and / or one or more input buttons.

[0083] I / O module 808 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In certain embodiments, I / O module 808 is configured to provide graphical data to a display for presentation to a user. The graphical data may be representative of one or more graphical user interfaces and / or any other graphical content as may serve a particular implementation.

[0084] The following clauses describe implementations of optimized instruction replay using a throttling mode in accordance with principles described herein.

[0085] Clause 1. A method comprising: selecting, as an arbitration selection by an instruction arbiter of an execution unit within a processor, a first instruction to be processed by a pipeline of the execution unit, the arbitration selection being between the first instruction, as provided by a replay queue local to the execution unit, and a second instruction provided by an issue queue external to the execution unit; determining, based on the selecting of the first instruction provided by the replay queue, that the execution unit is to operate in a replay throttling mode; and directing, based on the determining that the execution unit is to operate in the replay throttling mode, the second instruction to be replayed from the issue queue instead of from the replay queue.

[0086] Clause 2. The method of clause 1, further comprising: selecting, as an additional arbitration selection while the execution unit operates in the replay throttling mode, a third instruction to be processed by the pipeline of the execution unit, the additional arbitration selection being between the third instruction and a fourth instruction; determining, while the execution unit operates in the replay throttling mode, that the execution unit is to cease operating in the replay throttling mode; and directing, based on the determining that the execution unit is to cease operating in the replay throttling mode and based on the additional arbitration selection, the fourth instruction to be replayed from the replay queue instead of from the issue queue.Atty Docket No. 0120-1142 WO1

[0087] Clause 3. The method of clause 2, wherein, for the additional arbitration selection between the third instruction and the fourth instruction, the third instruction is provided by the replay queue and the fourth instruction is provided by the issue queue.

[0088] Clause 4. The method of clause 3, wherein the determining that the execution unit is to cease operating in the replay throttling mode is based on a determination that the selecting of the third instruction completes a threshold number of selections, in consecutive arbitration selections, of instructions provided by the replay queue instead of instructions provided by the issue queue.

[0089] Clause 5. The method of clause 2, wherein the determining that the execution unit is to cease operating in the replay throttling mode is based on a determination that the execution unit has operated in the replay throttling mode for a threshold number of consecutive clock cycles.

[0090] Clause 6. The method of clause 2, wherein: for the additional arbitration selection between the third instruction and the fourth instruction, the third instruction is provided by the issue queue and the fourth instruction is provided by the replay queue; and the determining that the execution unit is to cease operating in the replay throttling mode is in response to the selecting of the third instruction provided by the issue queue.

[0091] Clause 7. The method of any of clauses 2 to 6, wherein the determining that the execution unit is to cease operating in the replay throttling mode is further based on a quantity of instructions in the replay queue.

[0092] Clause 8. The method of any of clauses 1 to 7, wherein the determining that the execution unit is to operate in a replay throttling mode is: performed when the execution unit is not operating in the replay throttling mode; includes a determination that the execution unit is to enter the replay throttling mode; and based on the arbitration selection completing a threshold number of consecutive arbitration selections of instructions provided by the replay queue instead of instructions provided by the issue queue.

[0093] Clause 9. The method of any of clauses 1 to 8, further comprising: processing, by the pipeline of the execution unit and based on the selecting of the first instruction, the first instruction; determining that the processing of the first instruction is unsuccessful; and based on the determining that the processing of the first instruction is unsuccessful, directing the first instruction to be replayed from the replay queue.

[0094] Clause 10. The method of clause 9, wherein the determining that the processing of the first instruction is unsuccessful includes determining a cache miss associated with the processing of the first instruction.Atty Docket No. 0120-1142 WO1

[0095] Clause 11. The method of clause 9, wherein the determining that the processing of the first instruction is unsuccessful includes determining that a processing resource is currently unavailable for in the processing of the first instruction.

[0096] Clause 12. The method of any of clauses 1 to 11, wherein: the execution unit is a load / store unit (LSU) of the processor; and the pipeline of the execution unit is configured to perform both load instructions in which data is obtained from memory and store instructions in which data is stored in memory.

[0097] Clause 13. The method of any of clauses 1 to 12, wherein a pre-processing operation is performed on the second instruction provided by the issue queue for at least one clock cycle between the second instruction being dispatched by the issue queue and the second instruction being received by an instruction arbiter of the execution unit.

[0098] Clause 14. A processor comprising: an execution unit having a pipeline configured to process instructions; a replay queue local to the execution unit and providing a first instruction; an issue queue external to the execution unit and providing a second instruction; and an instruction arbiter included within the execution unit and configured to select, as an arbitration selection between the first instruction and the second instruction, the first instruction to be processed by the pipeline of the execution unit; wherein, based on the instruction arbiter selecting the first instruction provided by the replay queue, the execution unit determines to operate in a replay throttling mode that includes directing the second instruction to be replayed from the issue queue instead of from the replay queue.

[0099] Clause 15. The processor of clause 14, wherein: the execution unit includes a plurality of pipelines configured to process instructions, the pipeline included among the plurality of pipelines; and the instruction arbiter is configured to make arbitration selections for all the plurality of pipelines.

[0100] Clause 16. The processor of any of clauses 14 to 15, wherein: the execution unit is a load / store unit (LSU); the pipeline of the execution unit is configured to perform both load instructions in which data is obtained from memory and store instructions in which data is stored in memory; the processor further includes an additional execution unit configured to process other types of instructions besides the load instructions and the store instructions; and the issue queue is configured to store and provide instructions for both the LSU and the additional execution unit.

[0101] Clause 17. The processor of any of clauses 14 to 16, wherein: the instruction arbiter is further configured to select, as an additional arbitration selection while the execution unit operates in the replay throttling mode, a third instruction to be processed byAtty Docket No. 0120-1142 WO1the pipeline of the execution unit, the additional arbitration selection being between the third instruction and a fourth instruction; and while the execution unit is operating in the replay throttling mode, the execution unit determines that the execution unit is to cease operating in the replay throttling mode and, based on the additional arbitration selection, to direct the fourth instruction to be replayed from the replay queue instead of from the issue queue.

[0102] Clause 18. The processor of any of clauses 14 to 17, wherein: the pipeline of the execution unit is configured, based on the selecting of the first instruction, to process the first instruction and determine that the processing of the first instruction is unsuccessful; and based on the determining that the processing of the first instruction is unsuccessful, the execution unit directs the first instruction to be replayed from the replay queue.

[0103] Clause 19. A method comprising: selecting, as an arbitration selection by an instruction arbiter of an execution unit within a processor, a first instruction to be processed by a pipeline of the execution unit, the arbitration selection being between the first instruction, as provided by a replay queue local to the execution unit, and a second instruction provided by an issue queue external to the execution unit; determining, based on the selecting of the first instruction provided by the replay queue, that the execution unit is to operate in a replay throttling mode; and directing, based on the determining that the execution unit is to operate in the replay throttling mode, the issue queue to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode.

[0104] Clause 20. The method of clause 19, further comprising: selecting, as an additional arbitration selection while the execution unit operates in the replay throttling mode, a third instruction to be processed by the pipeline of the execution unit, the additional arbitration selection being between the third instruction and a fourth instruction; determining, while the execution unit operates in the replay throttling mode, that the execution unit is to cease operating in the replay throttling mode; and directing, based on the determining that the execution unit is to cease operating in the replay throttling mode and based on the additional arbitration selection, the issue queue to resume providing instructions to the execution unit.

[0105] Clause 21. A processor comprising: an execution unit having a pipeline configured to process instructions; a replay queue local to the execution unit and providing a first instruction; an issue queue external to the execution unit and providing a second instruction; and an instruction arbiter included within the execution unit and configured to select, as an arbitration selection between the first instruction and the second instruction, the first instruction to be processed by the pipeline of the execution unit; wherein, based on the instruction arbiter selecting the first instruction provided by the replay queue, the executionAtty Docket No. 0120-1142 WO1unit determines to operate in a replay throttling mode that includes directing the issue queue to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode.

[0106] Various implementations of the systems and techniques described herein can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0107] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the description and claims. In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems.Accordingly, other implementations are within the scope of the following claims.

[0108] Specific structural and functional details disclosed herein are merely representative for purposes of describing example implementations. Example implementations, however, may be embodied in many alternate forms and should not be construed as limited to only the implementations set forth herein.

[0109] It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. A first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the implementations of the disclosure. As used herein, the term and / or includes any and all combinations of one or more of the associated listed items.

[0110] The terminology used herein is for the purpose of describing particular implementations only and is not intended to be limiting of the implementations. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used in thisAtty Docket No. 0120-1142 WO1specification, specify the presence of the stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0111] It will be understood that when an element is referred to as being “coupled,” “connected,” or “responsive” to, or “on,” another element, it can be directly coupled, connected, or responsive to, or on, the other element, or intervening elements may also be present. In contrast, when an element is referred to as being “directly coupled,” “directly connected,” or “directly responsive” to, or “directly on,” another element, there are no intervening elements present. As used herein the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0112] Spatially relative terms, such as “beneath,” “below,” “lower,” “above,” “upper,” and the like, may be used herein for ease of description to describe one element or feature in relationship to another element(s) or feature(s) as illustrated in the figures. It will be understood that the spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation depicted in the figures. For example, if the device in the figures is turned over, elements described as “below” or “beneath” other elements or features would then be oriented “above” the other elements or features. Thus, the term “below” can encompass both an orientation of above and below. The device may be otherwise oriented (rotated 130 degrees or at other orientations) and the spatially relative descriptors used herein may be interpreted accordingly.

[0113] Unless otherwise defined, the terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which these concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and / or the present specification and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0114] Further to the descriptions above, a user may be provided with controls allowing the user to make an election as to both if and when systems, programs, or features described herein may enable collection of user information (e.g., information about a user's social network, social actions, or activities, profession, a user's preferences, or a user's current location), and if the user is sent content or communications from a server. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be treated so that noAtty Docket No. 0120-1142 WO1personally identifiable information can be determined for the user, or a user's geographic location may be generalized, or location information may be obtained (such as to a city, zip code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over what information is collected about the user, how that information is used, and what information is provided to the user.

[0115] While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes, and equivalents may occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover such modifications and changes as fall within the scope of the implementations. It will be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Any portion of the apparatus and / or methods described herein may be combined in any combination, except mutually exclusive combinations. The implementations described herein can include various combinations and / or sub-combinations of the functions, components, and / or features of the different implementations described. As such, the scope of the present disclosure is not limited to the particular combinations hereafter claimed, but instead extends to encompass any combination of features or example implementations described herein irrespective of whether or not that particular combination has been specifically enumerated in the accompanying claims at this time.

Claims

Atty Docket No. 0120-1142 WO1WHAT IS CLAIMED IS:

1. A method comprising:selecting, as an arbitration selection by an instruction arbiter of an execution unit within a processor, a first instruction to be processed by a pipeline of the execution unit, the arbitration selection being between the first instruction, as provided by a replay queue local to the execution unit, and a second instruction provided by an issue queue external to the execution unit;determining, based on the selecting of the first instruction provided by the replay queue, that the execution unit is to operate in a replay throttling mode; anddirecting, based on the determining that the execution unit is to operate in the replay throttling mode, the second instruction to be replayed from the issue queue instead of from the replay queue.

2. The method of claim 1, further comprising:selecting, as an additional arbitration selection while the execution unit operates in the replay throttling mode, a third instruction to be processed by the pipeline of the execution unit, the additional arbitration selection being between the third instruction and a fourth instruction;determining, while the execution unit operates in the replay throttling mode, that the execution unit is to cease operating in the replay throttling mode; anddirecting, based on the determining that the execution unit is to cease operating in the replay throttling mode and based on the additional arbitration selection, the fourth instruction to be replayed from the replay queue instead of from the issue queue.

3. The method of claim 2, wherein, for the additional arbitration selection between the third instruction and the fourth instruction, the third instruction is provided by the replay queue and the fourth instruction is provided by the issue queue.

4. The method of claim 3, wherein the determining that the execution unit is to cease operating in the replay throttling mode is based on a determination that the selecting of the third instruction completes a threshold number of selections, in consecutive arbitration selections, of instructions provided by the replay queue instead of instructions provided by the issue queue.Atty Docket No. 0120-1142 WO15. The method of claim 2, wherein the determining that the execution unit is to cease operating in the replay throttling mode is based on a determination that the execution unit has operated in the replay throttling mode for a threshold number of consecutive clock cycles.

6. The method of claim 2, wherein:for the additional arbitration selection between the third instruction and the fourth instruction, the third instruction is provided by the issue queue and the fourth instruction is provided by the replay queue; andthe determining that the execution unit is to cease operating in the replay throttling mode is in response to the selecting of the third instruction provided by the issue queue.

7. The method of any of claims 2 to 6, wherein the determining that the execution unit is to cease operating in the replay throttling mode is further based on a quantity of instructions in the replay queue.

8. The method of any of claims 1 to 7, wherein the determining that the execution unit is to operate in the replay throttling mode is:performed when the execution unit is not operating in the replay throttling mode; includes a determination that the execution unit is to enter the replay throttling mode; andbased on the arbitration selection completing a threshold number of consecutive arbitration selections of instructions provided by the replay queue instead of instructions provided by the issue queue.

9. The method of any of claims 1 to 8, further comprising:processing, by the pipeline of the execution unit and based on the selecting of the first instruction, the first instruction;determining that the processing of the first instruction is unsuccessful; and based on the determining that the processing of the first instruction is unsuccessful, directing the first instruction to be replayed from the replay queue.Atty Docket No. 0120-1142 WO110. The method of claim 9, wherein the determining that the processing of the first instruction is unsuccessful includes determining a cache miss associated with the processing of the first instruction.

11. The method of claim 9, wherein the determining that the processing of the first instruction is unsuccessful includes determining that a processing resource is currently unavailable for in the processing of the first instruction.

12. The method of any of claims 1 to 11, wherein:the execution unit is a load / store unit (LSU) of the processor; andthe pipeline of the execution unit is configured to perform both load instructions in which data is obtained from memory and store instructions in which data is stored in memory.

13. The method of any of claims 1 to 12, wherein a pre-processing operation is performed on the second instruction provided by the issue queue for at least one clock cycle between the second instruction being dispatched by the issue queue and the second instruction being received by the instruction arbiter of the execution unit.

14. A processor comprising:an execution unit having a pipeline configured to process instructions;a replay queue local to the execution unit and providing a first instruction;an issue queue external to the execution unit and providing a second instruction; and an instruction arbiter included within the execution unit and configured to select, as an arbitration selection between the first instruction and the second instruction, the first instruction to be processed by the pipeline of the execution unit;wherein, based on the instruction arbiter selecting the first instruction provided by the replay queue, the execution unit determines to operate in a replay throttling mode that includes directing the second instruction to be replayed from the issue queue instead of from the replay queue.

15. The processor of claim 14, wherein:the execution unit includes a plurality of pipelines configured to process instructions, the pipeline included among the plurality of pipelines; andAtty Docket No. 0120-1142 WO1the instruction arbiter is configured to make arbitration selections for all the plurality of pipelines.

16. The processor of any of claims 14 to 15, wherein:the execution unit is a load / store unit (LSU);the pipeline of the execution unit is configured to perform both load instructions in which data is obtained from memory and store instructions in which data is stored in memory;the processor further includes an additional execution unit configured to process other types of instructions besides the load instructions and the store instructions; andthe issue queue is configured to store and provide instructions for both the LSU and the additional execution unit.

17. The processor of any of claims 14 to 16, wherein:the instruction arbiter is further configured to select, as an additional arbitration selection while the execution unit operates in the replay throttling mode, a third instruction to be processed by the pipeline of the execution unit, the additional arbitration selection being between the third instruction and a fourth instruction; andwhile the execution unit is operating in the replay throttling mode, the execution unit determines that the execution unit is to cease operating in the replay throttling mode and, based on the additional arbitration selection, to direct the fourth instruction to be replayed from the replay queue instead of from the issue queue.

18. The processor of any of claims 14 to 17, wherein:the pipeline of the execution unit is configured, based on the selecting of the first instruction, to process the first instruction and determine that the processing of the first instruction is unsuccessful; andbased on the determining that the processing of the first instruction is unsuccessful, the execution unit directs the first instruction to be replayed from the replay queue.

19. A method comprising:selecting, as an arbitration selection by an instruction arbiter of an execution unit within a processor, a first instruction to be processed by a pipeline of the execution unit, the arbitration selection being between the first instruction, as provided by a replay queue local toAtty Docket No. 0120-1142 WO1the execution unit, and a second instruction provided by an issue queue external to the execution unit;determining, based on the selecting of the first instruction provided by the replay queue, that the execution unit is to operate in a replay throttling mode; anddirecting, based on the determining that the execution unit is to operate in the replay throttling mode, the issue queue to abstain from providing further instructions to the execution unit while the execution unit operates in the replay throttling mode.

20. The method of claim 19, further comprising:selecting, as an additional arbitration selection while the execution unit operates in the replay throttling mode, a third instruction to be processed by the pipeline of the execution unit, the additional arbitration selection being between the third instruction and a fourth instruction;determining, while the execution unit operates in the replay throttling mode, that the execution unit is to cease operating in the replay throttling mode; anddirecting, based on the determining that the execution unit is to cease operating in the replay throttling mode and based on the additional arbitration selection, the issue queue to resume providing instructions to the execution unit.

21. A processor comprising:an execution unit having a pipeline configured to process instructions;a replay queue local to the execution unit and providing a first instruction;an issue queue external to the execution unit and providing a second instruction; and an instruction arbiter included within the execution unit and configured to select, as an arbitration selection between the first instruction and the second instruction, the first instruction to be processed by the pipeline of the execution unit;wherein, based on the instruction arbiter selecting the first instruction provided by the replay queue, the execution unit determines to operate in a replay throttling mode that includes directing the issue queue to abstain from providing further instructions to the execution unit while the execution operates in the replay throttling mode.

Images