Patent Application
20080046692
In some embodiments, a delay determination unit 16 included in or associated with the main processor 12, the coprocessor 14 or a different coprocessor (not shown) the delay determination unit 16 accounts for the speculative nature of a particular set of one or more instructions to be executed by the coprocessor 14. The delay determination unit 16 accounts for the speculative nature of instructions by altering the instruction execution delay associated with the coprocessor 14 accordingly. Some instructions may be more or less speculative than others, i.e., they are more or less likely to commit, allowing them to update the architected state in the main processor 12 or coprocessor 14. The architected state includes any state visible to the programmer by means of the processor's instruction set. For example, the instruction execution result may be stored in a register file 18 included in or associated with the main processor 12, or in a register file 19 included in or associated with coprocessor 14. As such, each instruction or set of instructions offloaded to the coprocessor 14 may incur an execution delay based on their speculative nature. For example, highly speculative instructions may incur a greater execution delay while less speculative instructions may incur a lesser delay.
In other embodiments, the delay determination unit 16 accounts for the extent of processing resources available to an application to be executed by the processing system 10. That is, the delay determination unit 16 alters the dynamic delay based on processing resources such as processing speed, memory bandwidth, cache size, display capability, battery mode, battery life, power savings mode, and the like. As such, the delay-determination unit 16 enables the processing system 10 to trade-off between system performance and power consumption by altering the execution delay associated with the coprocessor 14 accordingly. For example, if battery life is a concern, the delay determination unit 16 may alter the delay of the coprocessor 14 so that instructions are not executed until first committed by the main processor 12, thus reducing power consumption.
Regardless of the condition that triggers adjustment of the instruction execution delay, the delay may be dynamically altered on a per-instruction, multiple instruction, or application basis. The ability to alter instruction execution delay does not prevent instruction pipeline flushes; rather, it allows delay-based speculative-execution control. The benefit to the user is dynamic power and performance balancing and optimization of the processing system 10.
In more detail, the main processor 12 is communicatively coupled to includes the coprocessor 14. The main processor 12 includes an instruction unit 20, one or more execution units 22, and the register file 18. The instruction unit 20 provides centralized control of instruction flow to the execution units 22 and to the coprocessor 14. The execution units 22, which may include one or more load/store units (not shown), floating point units (not shown), and integer units (not shown) execute instructions dispatched by the instruction unit 20. The register file 18 comprises an array of registers that stage data between memory (not shown) and the functional units of the main processor 12, e.g., the execution units 22. Likewise, the coprocessor's register file 19 comprises an array of registers that stage data between memory (not shown) and the functional units of the coprocessor 14, e.g., execution units 26. The register file 18 may store temporary results before the corresponding instructions are committed by the main processor 12. In such an arrangement, the register file 18 may implement register renaming which enables dynamic mapping of physical register file entries to architected register names. As such, register entries holding temporary results may be renamed when the instructions are committed. Likewise, the coprocessor 14 may store temporary results generated by it until the producing instructions are committed, at which time the register file 19 is updated.
The coprocessor 14 receives instructions offloaded by the instruction unit 20. In some embodiments, the coprocessor 14 is capable of executing coprocessor functions only and cannot fetch instructions from memory (not shown), execute program flow control instructions, perform input/output operations, manage memory, and the like. As such, the main processor 12 fetches instructions for the coprocessor 14 and handles other operations aside from coprocessing functions. In other embodiments, the coprocessor 14 functions more along the lines of a general-purpose processor, carrying out a limited range of additional functions under control of the main processor 12.
Regardless, instructions offloaded to the coprocessor 14 may be buffered in an instruction queue 24 for subsequent dispatch to a coprocessor execution unit 26 or may be provided directly to the coprocessor execution unit 26. The coprocessor's instruction queue 24 may reside in the main processor 12 or other places outside of the coprocessor 14. The coprocessor execution unit 26 may comprise a plurality of stages 28 for executing instructions, e.g., decode, register access, execute, and writeback stages. Regardless of the pipelined nature of the coprocessor execution unit 26, each instruction is executed by the coprocessor 14 based on the dynamic delay stored in a register 30. Further, each instruction or set of instructions provided to the coprocessor 14 is associated with its corresponding delay. This association enables the register 30 to be dynamically reprogrammed without losing the delay value(s) assigned to instruction(s) not yet fully executed. As a result, delays associated with instructions moving through the instruction queue 24 and the various execution stages 28 are accessible for subsequent use. In one embodiment, each set of one or more instructions processed by the coprocessor 14 is tagged with its assigned delay as shown in
The dynamic instruction execution delay value may be expressed in various forms. These various forms of dynamic instruction execution delay value may be utilized separately or in combination. In one embodiment, the dynamic instruction execution delay corresponds to a speculative instruction execution flag 40 in the register 30, as illustrated in
In yet another embodiment, the dynamic instruction execution delay corresponds to a processor cycle count field 44 in the register 30, as illustrated in
Returning to
In some embodiments, the delay determination unit 16 determines the dynamic instruction execution delay based on the application to be executed by the processing system 10. That is, the application indicates the appropriate execution delay, or the appropriate delay can be determined by or for the application. In one embodiment, the application determines the dynamic delay based on the processing resources available to the application, e.g., processing speed, memory bandwidth, cache size, display capability, battery mode, battery life, power savings mode, and the like.
In another embodiment, the application determines the dynamic delay based on the instruction execution delay that can be tolerated by the application. For example, some applications can tolerate a high instruction execution delay without adversely impacting system performance, e.g., applications that perform high-cycle count batch processing where the results are consumed significantly after the calculations are performed. Conversely, other applications cannot tolerate a high instruction execution delay, e.g., applications that have short instruction sets or that need results immediately.
System performance may be optimized by tailoring instruction execution delay to individual applications. Each application executed by the processing system 10 may adjust instruction execution delay accordingly, e.g., on a per-instruction, multiple instruction, or application basis. An application may determine the dynamic delay during compile time, e.g., using a Java™ just-in-time compiler, during application load time or during application execute time, also referred to as run time. Regardless, the delay determination unit 16 provides an instruction to the main processor 12 that indicates the desired instruction execution delay. In response to the instruction, the main processor 12 may directly write the dynamic delay value to the coprocessor register 30. Alternatively, the main processor 12 passes the instruction to the coprocessor 14 where the coprocessor 14 decodes the instruction and updates the register 30 accordingly.
In other embodiments, the delay determination unit 16 determines the dynamic instruction execution delay based on branch history data. In one embodiment, the delay determination unit 16 maintains a table 50 of branch history data, e.g., data that indicates branch prediction accuracy. In one embodiment, the branch history data corresponds to the frequency of execution pipeline flushes. In that context, the delay determination unit 16 tracks each time the coprocessor 14 flushes instructions from its instruction queue 24 or execution unit 26 and associates these occurrences with the corresponding instruction that caused each flush to occur. This data provides an indication as to how speculative certain instructions are. The more speculative an instruction, the greater the delay that may be assigned to the instruction and vice-versa.
In another embodiment, the branch history data corresponds to data maintained by a branch processing unit (not shown) included in the main processor 12, e.g., data maintained in a branch history table (not shown). When an instruction or set of instructions are offloaded to the coprocessor 14, the delay determination unit 16 accesses the history table 50 to determine whether the instruction(s) are more or less likely to be committed by the main processor 12. The more speculative the instruction(s), the greater the delay assigned to the instruction(s). The converse holds true for less speculative instructions.
In yet other embodiments, the delay determination unit 16 employs a hybrid approach for determining the dynamic instruction execution delay. According to the hybrid approach, an application to be executed by the processing system 10 uses the history data maintained by the delay determination unit 16 to determine dynamic delay values. That is, the application probes the history table 50 to determine the execution delay to be assigned to the instructions constituting the application. The hybrid approach allows programs to access historical data to determine the instruction execution delays best suited for individual applications. This may occur during compile time, load time, or run time.
Irrespective of how the dynamic delay is determined, the delay determination unit 16 may be included in the main processor 12 as mentioned previously.
The delay determination unit 16 may access the BHT 68 to determine dynamic delay values assigned to instructions having a history tracked by the BHT 68. In one embodiment, the delay determination unit 16 supplements its history table 50 with that of the BHT 68. The delay determination unit 16 uses information stored in the BHT 68 to determine dynamic instruction execution delay values, e.g., by determining delay values based on the strength or weakness of previously taken/not taken branch histories. The resulting dynamic delay values are provided to the coprocessor 14 for delaying execution of offloaded instructions as previously described.
Alternatively,
While the various dynamic delay determination embodiments previously disclosed herein have been described in large part with respect to coprocessors, they are equally applicable to the execution units 22 included in the main processor 12. That is, one or more of the main processor execution units 22 may use dynamic delay values determined by the delay determination unit 16 to control internal instruction execution timing. In that context,
The execution units 22 may comprise a plurality of stages 82 for executing instructions, e.g., decode, register access, execute and writeback stages. Instructions to be executed internally by the main processor 12 may be buffered in an instruction queue 80 for subsequent execution or may be provided directly to a first one of the execution stages 82. Regardless of the pipelined and queuing nature of the execution units 22, instruction execution is based on the dynamic instruction execution delay stored in one or more registers 30. To enable dynamic alteration of the instruction execution delay, each set of one or more instructions provided to the execution units 22 is associated with its corresponding delay. As such, the registers 30 may be dynamically reprogrammed without losing the delay values assigned to previous instructions not yet executed. Dynamic delay values may be determined in accordance with any of the embodiments previously disclosed herein. Also, the delay determination unit 16 may determine a different dynamic delay for each execution unit 18 included in the main processor 12, thus enabling instruction execution timing control on a per-execution unit basis.
At least some instructions executed in a processing system 10 incur a pre-execution delay based on a dynamically alterable delay value. In some embodiments, the dynamic delay is determined by an application to be executed by the processing system 10. Application-based execution delay adjustment can be done at compile-time, load-time, or run-time. In other embodiments, the dynamic delay is determined by analyzing the history of previously executed instructions. In yet other embodiments, the dynamic delay is determined by assessing the processing resources available to a given application. Regardless, dynamic instruction execution delays may be determined by a main processor 12 or a coprocessor 14. The dynamic delays may be zero-delay, cycle based, or stage and event based. Stage and event based delays result in instructions being held in a specified stage, including the instruction queue, until a specified event occurs (e.g., commit is received). The delay may be dynamically altered on a per-instruction, multiple instruction, or application basis.
With the above range of variations and applications in mind, it should be understood that the present invention is not limited by the foregoing description, nor is it limited by the accompanying drawings. Instead, the present invention is limited only by the following claims and their legal equivalents.
