US20030005271A1 - System and method using a hardware embedded run-time optimizer - Google Patents
System and method using a hardware embedded run-time optimizer Download PDFInfo
- Publication number
- US20030005271A1 US20030005271A1 US10/222,014 US22201402A US2003005271A1 US 20030005271 A1 US20030005271 A1 US 20030005271A1 US 22201402 A US22201402 A US 22201402A US 2003005271 A1 US2003005271 A1 US 2003005271A1
- Authority
- US
- United States
- Prior art keywords
- trace
- instruction
- code
- branch
- program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims description 16
- 238000005457 optimization Methods 0.000 claims abstract description 21
- 238000013507 mapping Methods 0.000 claims abstract description 18
- 230000007246 mechanism Effects 0.000 abstract description 4
- 230000008901 benefit Effects 0.000 description 9
- 238000013519 translation Methods 0.000 description 8
- 230000008569 process Effects 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 230000008030 elimination Effects 0.000 description 2
- 238000003379 elimination reaction Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/3005—Arrangements for executing specific machine instructions to perform operations for flow control
- G06F9/30061—Multi-way branch instructions, e.g. CASE
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3802—Instruction prefetching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3802—Instruction prefetching
- G06F9/3804—Instruction prefetching for branches, e.g. hedging, branch folding
- G06F9/3806—Instruction prefetching for branches, e.g. hedging, branch folding using address prediction, e.g. return stack, branch history buffer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3802—Instruction prefetching
- G06F9/3808—Instruction prefetching for instruction reuse, e.g. trace cache, branch target cache
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/865—Monitoring of software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/88—Monitoring involving counting
Definitions
- This application relates in general to run-time optimizers, and in specific to hardware embedded run-time optimizer.
- a run-time optimizer is an adaptive software system that transparently optimizes applications at run-time.
- the optimizer rewrites the binary code of an application on-the-fly to achieve a higher execution efficiency.
- FIG. 4 depicts prior art run-time optimizer 30 .
- the control loop 31 begins execution of a block of program code via emulation performed by the profiling emulator 32 .
- the profiling aspect of emulator 32 allows the control loop 31 to track the number of times the particular block of code has been executed via emulation.
- a run-time optimization system is different from a run-time binary translation system, in that the latter is for architecture migration while the former is to decrease execution time.
- the run-time optimization system is using the emulator 32 for profiling in order to guide optimizations, i.e. the code is running on its native system.
- the control loop 31 designates the block of code as hot code, and desirable for optimization.
- the control loop 31 then activates trace selector 33 to translate the block of code.
- the trace selector 33 forms a trace of the instructions that comprise the block of code by following the instructions in the block.
- the trace selector makes a prediction as to whether the branch is taken or falls through. If the selector decides the branch is mostly taken, then the trace is formed by extending the code from the branch target block. If the selector decides not to take the branch, then the branch falls through, and the trace continues within the fall through block.
- the trace terminates at a backward branch predicted to be taken or when the trace becomes sufficiently large.
- the code is rewritten with machine dependent and machine independent optimizations.
- the optimized code is then placed into the code cache 34 . The next time the control loop 31 encounters a condition to execute this block of code, then the control loop 31 will execute the code in the code cache 34 and not emulate the code via emulator 32 .
- control is returned to the run-time system RTS 30 and to control loop 31 , which determines if the target resides in the code cache. If the target resides in code cache, then the control loop 31 modifies the target of the branch instruction 41 to be the trace 2 42 in code cache as shown by branch instruction 43 . This modification is called backpatching. Thus, if the exit of the trace is already translated, then the branch is backpatched such that a subsequent execution will directly branch to the new trace without returning to the control loop. Backpatching increases the speed of execution of the code, as returning to the RTS significantly slows down execution time.
- a problem with FIG. 4 is that an emulator is required to perform profiling, i.e. the emulated code is used to determine which code is hot. Emulation is very slow, usually 50-200 times slower than native execution speed. Consequently, there is a large time penalty for determining which code is hot. Moreover, the quality of optimization is often determined by the quality of the selected trace. Poor trace selection can be costly, for example, predicting a branch not to be taken means the remainder of the block code is traced and optimized, and if mispredicted, then that tracing and optimizing of the code subsequent to the branch is wasted. Branch misprediction can be minimized by maintaining a long history of branching outcomes, which is formed by continually emulating the code block. Thus, the prior art RTS either incurs a time penalty from emulation to build a good history or incurs a time penalty from branch misprediction.
- RTS cannot backpatch an indirect branch.
- the RTS cannot backpatch an indirect branch because the target address is unknown.
- the target address is typically in a register or memory location and not written directly in code.
- the RTS will shift control back to the control loop 31 to determine whether the target address has been translated, which is expensive in terms of time.
- the prior art has attempted to minimize this problem by inlining a code sequence to search a smaller lookup table in the optimized traces, however, these mechanism still incur high overhead. Examples of indirect branches are return branches and switch branches.
- a further problem with the prior art RTS is that it attempts to translate any code that is deemed hot based on a small threshold. This problem is referred to as complex and less reliable. There are some traces that are difficult to translate, but, without a translation, the execution of the trace would be performed by software simulation or emulation. Since emulation is slow, all hot code is translated. Some traces are very difficult to translate. For example, it is difficult to translate a trace with branches in the delay slot of another branch. The requirement of translating all hot code increases the translation time and complexity.
- a further problem with the prior art RTS is that it will handle only user code and not operating system (OS) code. This is because the RTS is layered between the user application and the OS, and thus will not handle privileged instructions and addressing modes. In the prior art, the RTS is attached to user processes. Since the prior art RTS cannot be attached to the OS, it does not handle OS code.
- OS operating system
- RTOS run-time optimization system
- the inventive RTOS handles execution profiling and transfers execution to optimized traces automatically. This would allow code to run at faster native speed instead of slower emulation. Since the code is running faster, the threshold for selecting a hot trace could be set much higher than the prior art. This would also avoid generating traces for relatively infrequent code paths. Moreover, a higher threshold would enable the selection of better traces.
- a processor desires to execute a block of instructions, the processor first examines the Icache to determine whether the block is present. If not, the block is moved from memory to Icache. When the code is first moved into Icache, a threshold value is set into a counter associated with the particular instruction or instruction bundle (a group of instructions that can be issued together in the same cycle) of the Icache. Each time the instruction or instruction bundle is executed and retired, the counter is decremented by one. When the counter reaches zero, a trap is generated and the instruction (or instruction bundle) is designated as hot code.
- a trace selector forms a trace of the hot code.
- the trace is followed to determine the location of the target, i.e., the next instruction.
- the Icache maintains branch history information for the instructions in each cache line. This branch history is used to determine whether a branch should be predicted (as thus treated) as taken or to fall through. If the branch is predicted to fall through, then the subsequent instruction bundle is the next instruction. If the branch is predicted to be taken, the target instruction is the next instruction.
- the trace is completed, it is optimized and stored into a trace memory portion of the physical memory. The mapping of the starting address of the original trace to the location of the optimized trace in Trace Memory (TM) is maintained in the IP-to-TM Table.
- the instruction fetch unit consults the IP-to-TM Table to decide whether the execution should continue with an optimized trace in the TM.
- the processor consults the IP-to-TM cache prior to examining the Icache. Therefore, upon subsequent execution of this code, the processor examines the IP-to-TM cache, which then points to the trace memory location. Thus, the code in the trace memory is executed instead of the original binary code. Note that if the code has not been optimized, the processor will execute the original code in the Icache. Note that the instruction from the TM (Trace Memory) will also be moved into the Icache before execution, not just the original code.
- the inventive RTOS uses hardware managed trace address mapping, the complexity of backpatching may be eliminated. This also avoids reserving registers for passing arguments in trampoline code used in backpacking that may introduce a register spilling penalty. Furthermore, the inventive RTOS can significantly reduce the cost of handling indirect branches. Since the non-optimized code runs at native speeds, the indirect branch is allowed to execute which returns control to native code. Note that a hardware (or processor) table lookup is significantly faster than a software (or emulator) table lookup. For example, a search of the IP-to TM cache may require one cycle, whereas a software lookup of a table would require from 10 to 1000 cycles. The software lookup is expensive because the current architecture states must be saved before returning to the software RTS (Run-Time System).
- RTS Un-Time System
- the inventive RTOS uses hardware to directly process non-trace code, which significantly improves the reliability of the dynamic optimizer.
- the dynamic translator can choose not to translate some difficult traces and leave them unchanged in the original code, since this code will be executed at native speeds. Therefore, the time penalty for not optimized code is much lower than compared with the prior art software emulation.
- a decision in the prior art RTOS not to optimize code meant that the code would be executed at emulator speeds. Note that in the prior art, all hot code is optimized.
- the reliability aspects are improved because less code would need to be translated, and thus fewer problems from translation will be introduced into the program application.
- the inventive RTOS is controlled at the processor and at the firmware level, which is below the OS. Therefore, the inventive RTOS can handle OS code.
- RTOS run-time optimization system
- the embedded RTOS does not require software emulation for code profiling to determine hot code.
- the embedded RTOS can substantially reduce the cost of handling indirect branches.
- the embedded RTOS can elect not to translate difficult code, and run such code at native speeds.
- the embedded RTOS can handle OS code in addition to user application codes.
- FIG. 1 depicts the inventive run-time optimization system (RTOS) that has its control loop embedded in hardware;
- RTOS run-time optimization system
- FIG. 2 depicts a version of the inventive RTOS of FIG. 1 configured to run without backpatching
- FIG. 3 depicts a high level block diagram of a computer system adapted to implement the inventive RTOS of FIGS. 1 and 2;
- FIG. 4 depicts a prior art software emulation RTS
- FIG. 5 depicts a prior art backpatching mechanism that is used with the system of FIG. 4.
- FIG. 1 depicts the inventive run-time optimization system (RTOS) 100 that is embedded in hardware.
- RTOS 100 has the control of the optimization in hardware and hardware is used to detect hot code, as well as execute both optimized and non-optimized code. Hardware also notifies the firmware via traps.
- the RTOS 100 uses firmware to handle trace selection, code optimization, and trace memory management, each of which require complex analysis. The balance of work between hardware and firmware is an important aspect of the inventive RTOS.
- the inventive RTOS distributes the different aspects of the RTOS work to the mechanism, i.e. hardware or firmware, best suited to handle the work. Thus, the inventive RTOS has both hardware and firmware aspects.
- the operation of RTOS 100 is transparent to the user, as control moves between hardware and firmware without user involvement. Note that firmware is microcode in ROM.
- the RTOS 100 uses the instruction cache (Icache) 101 of the processor 301 to determine which code is hot code. Associated with the Icache 101 is a counter 102 and a few bits that are used to hold the branch history information associated with each instruction or instruction bundle in the Icache 101 . A preferred embodiment is to have the Icache 101 holds multiple instructions per cache line, thus multiple counters 102 and registers 103 would be associated with each cache line. The number of cache lines is processor dependent, for example a Pentium II has 16K of Icache which is organized into 512 cache lines.
- the RTOS uses the trace memory 105 to hold the traces of the optimized instructions.
- trace memory 105 is a portion of RAM memory 303 .
- RAM 303 also includes IP-to-TM mapping table (TM table) 106 .
- TM table IP-to-TM mapping table
- This table list the mapping of the original IP of a trace to the location in the TM 105 which correspond to the optimized trace.
- the RTOS uses IP-to-TM cache 104 , which is a TLB-like structure in the instruction fetch unit to accelerate mapping table access.
- the IP-to-TM cache 104 holds a smaller portion of the most active entries in the TM mapping table.
- the RTOS uses firmware 108 to perform tasks which require complex analysis.
- Trace selector 109 forms traces of instructions, and includes branch prediction. The operation of this component and its interaction with the other RTOS components is explained in the related, co-pending application entitled, FAST INSTRUCTION PROFILING AND EFFECTIVE TRACE SELECTION, by Hsu et al., Ser. No. 09/252,567, filed Feb. 18, 1999, which is hereby incorporated by reference.
- Optimizer 110 optimizes the trace determined by trace selector 109 .
- the optimized code is then placed into the trace memory 105 , which is managed by trace memory manager 111 .
- Execution pipeline 107 depicts sequence of execution of an instruction by processor 301 .
- the first stage is the instruction pointer generation (IPG) 112 .
- This stage delivers an instruction pointer (IP) to Icache 101 .
- the IP may come from several places, for example, as a corrected target address from a branch misprediction, as a predicted branch addresses, or as a next sequential address.
- IP instruction pointer
- the processor first checks IP-to-TM cache 104 to determine whether the instruction is a starting location of a block which has been optimized and the optimized version resides in trace memory (TM) 105 .
- IP-to-TM cache 104 If it exists in IP-to-TM cache 104 , the processor then retrieves the location of the optimized instruction in trace memory 105 , and executes the optimized instruction. If it does not exist, then the processor examines Icache 101 to determine if the instruction is in Icache. If it exists in Icache 101 , then the processor executes the instruction. If it does not exist, then the processor retrieves the instruction from memory 303 , and places the instruction into Icache 101 . This is performed in fetch stage FET 113 of the pipeline.
- a threshold value is set into counter 102 associated with the particular instruction or instruction bundle in Icache 101 .
- counter 102 is decremented by one and branch history 103 is updated.
- branch history 103 is updated.
- counter 102 reaches zero, a trap is generated and the instruction is designated as hot code.
- the preferred threshold is between approximately 50 to approximately 200.
- the counters can be 8 bits.
- the prior art threshold is as small as 5. Note that in the instruction fetch stage, a fetch address can come from several different sources, e.g.
- Trace selector 109 forms a trace based on the starting instruction bundle and any surmised branch predictions which have been determined from branch history information 103 .
- the termination of a trace will be driven by a set of heuristics including the length of the trace, the number of conditional branches encountered, the probability of accumulated branch predictions and other considerations.
- a trace may terminate at an indirect branch, since the target address is not known. However, the trace selector may decide to grow the trace by predicting its most recent target from some hardware branch predictor such as RTB (Branch Target Buffer).
- the trace selector For a return branch, the trace selector would know the return address if the call instruction is in the trace, if the call instruction is not in the trace, the trace selector can predict the call site using the top address of the RSB (Return Stack Buffer).
- RSB Return Stack Buffer
- traces (as well as any instruction either in the original binary or in the TM) are also brought into Icache 101 before being executed, the profiling and trace selection may end up generating a trace on top of an existing trace. Traces can be identified, since their addresses are preserved memory (e.g. RAM), and are accessible by the RTOS. When trace lines are moved into Icache 101 , their counters do not get initialized, thus they do not participate in profiling. Alternatively, if traces do participate in profiling, trace selector 109 can check whether this trace is considered “good”. For example, if a trace has a frequent early exit, the trace may need to be regenerated.
- trace selector 109 can check whether this trace is considered “good”. For example, if a trace has a frequent early exit, the trace may need to be regenerated.
- optimizer 110 will operate on the trace.
- the optimizer may perform any of the following optimizations: prefetch insertion (both Icache and Dcache), inlining/outlining and calling overhead reduction, instruction polarity padding, bundle compression using compact templates, unnecessary stop bits elimination, converting ST-LD (with same address) to ST-copy, convert LD-LD (with same address) to LD-copy, and constant propagation and assertion propagation. This list is by way of example only. Other optimizations may be performed so long as the processor would deliver an identical architecture state to the original binary application when traps/exceptions are raised.
- Trace memory manager 108 maintains the trace memory 105 .
- the trace memory can be divided into several chunks. Traces are written into the current chunk at the next available address. When a chunk is filled up, the next chunk becomes the current chunk. When there is no chunks available, one of the existing chunks will be evicted. When a chunk is evicted, all the traces in that chunk become invalid. This will in turn trigger the elimination of address mapping entries from TM mapping table 106 and IP-to-TM cache 104 . Also, invalid traces existing in Icache 101 will also be purged. Note that before a chuck is evicted, the trace manager ensures that no threads or processes are executing any of the trace in the evicted chunk.
- trace locality can be implemented by trace memory manager 111 .
- Trace memory manager 111 would track the frequency of usage of traces in the mapping cache, and periodically reorganize the traces in trace memory 105 in such a manner that both sequential and temporal locality can be improved. For example, if trace A branches to trace B more frequently, then trace B will be placed next to trace A in trace memory 105 . Note that if the hardware support PC-relative branches in traces to generate original IP addresses, relocating traces will be much easier.
- next fetch address is a trace address, either a fall through from a trace address or the branch target is a trace
- the fetch unit can bypass the regular instruction translation and retrieve the optimized code from trace memory 105 .
- This operation is explained in the related, co-pending patent application entitled EFFICIENT MAPPING TO OPTIMIZED CODE FOR PROCESSOR EMBEDDED RUN-TIME OPTIMIZERS, by Benitez et al. (HP# 10981004-1), which is hereby incorporated by reference.
- REN stage 115 translates logical (virtual) register into physical registers.
- REG stage 116 accesses the registers and delivers operands to all execution units.
- EXE stage 117 executes the instruction.
- the detection stage or DET 118 is the stage of the pipeline where the processor can check to see whether. an instruction contains a trap or exception. If so, then the processor reports to the operating system, unless the trap or exception is associated with an address in trace memory, then it is reported to firmware.
- the last stage of the pipeline is the write back or WRB 119 .
- executed instructions are retired from the pipeline.
- counter 102 associated with the instruction would be decremented and the associated branch history information 103 would be updated. Updating the branch history allows for an accurate history as a speculative execution is performed. Note that this stage is also referred to as the retirement stage.
- FIG. 2 depicts the inventive run-time optimization system (RTOS) 200 that is embedded in hardware, and is configured to operate without backpatching. Note that Icache 101 and counter 102 are also embedded in hardware.
- the trace-entering IP-address 201 can be used to figure out the original IP address. This simplifies the trace memory management work, as the trace exit branches can be maintained as IP addresses. Thus, transition from trace to original binary is relatively easy. Moreover, when a trace is removed, the trace manager does not need to reinsert trampoline code (unbackpatch) at every incoming branch site.
- Block 201 stores the most recent trace entering IP address.
- the block 201 is a register that holds the most current IP address that enters the TM memory. This IP address is used to calculate the branch address in the trace. Note that most conditional branches are PC relative and not TM relative.
- PC-relative branches in traces may need special treatment since they are now relative to trace memory locations rather than to the original virtual IP address. This treatment may be provided by backpatching.
- backpatching makes trace memory management very difficult. For example, suppose trace A has an exit branch which jumps to trace B. Once this branch is backpatched, trace A and trace B are bound together. If trace B is part of a chunk that is to be evicted from the trace memory, then the respective branch in trace A must be unbackpatched.
- PC-relative branches generate target addresses in the original IP addresses, then backpatching is not needed, and all traces are “relocatable”, i.e. removing one trace would not affect others.
- the target address of PC-relative branches in traces is computed in the context of original IP addresses instead of trace memory addresses. This is achieved by remembering the trace entering IP address in block 201 at EXP stage 114 .
- the branch unit uses this IP address in block 201 as the base address for calculating a PC-relative branch target address for traces (instructions from TM).
- the offset in those PC-relative branch instructions in traces is generated based on the trace entering IP address.
- a branched-to-trace can be entered uniformly from going through the IP-to-TM cache instead of backpatching.
- the manager 111 For a PC-relative branch instruction in a trace, the manager 111 would use the respective entering IP address instead of the current trace address as the current PC location for target address calculation.
- the offset in PC-relative branches needs to be adjusted relative to the entering of IP address. This is done during trace translation/optimization time by the trace selector.
- the following table illustrates the address offset adjustment work. Note that the offsets are adjusted, relative to the entering IP address 1000 . Further note that this table is by way of example only, and other values could be used.
- the left side portion depicts parts of the original binary with the branch offsets listed from the current address and an indication as to whether the branches are likely to be taken or fall through.
- the trace selector builds a trace from these portions, as shown on the right side of the above table.
- the instructions of the trace are predicted to operate sequentially. Thus, TM 1 would fall through to TM 2, and so on. However, if the predicted behavior of the instruction is incorrect, i.e. mispredicted, then the trace will be exited.
- the target of the trace instruction is the opposite of the predicted target of the original binary. For example, TM 2 holds old bundle address 1001 .
- the trace is built with the prediction that the branch will be taken. Hence, TM 3 contains old bundle address 1501 .
- a misprediction indicates that the branch will not be taken, and thus will fall through, i.e. from address 1001 to 1002 .
- the exit branch offset is +2, which when added to the entering IP address of 1000 will yield the correct IP address of 1002 .
- Another example for the table is as follows. TM 5 holds old bundle address 3002 . The trace is built with the prediction that the branch will not be taken, hence TM 6 contains old bundle address 3003 .
- a misprediction indicates that the branch will be taken, and thus will jump from address 3002 to 3102 via the offset of +100.
- the exit branch offset is +2102, which, when added to the entering IP address of 1000 , will yield the correct IP address of 3102 .
- FIG. 3 illustrates computer system 300 adapted to use the present invention.
- Central processing unit (CPU) 301 is coupled to bus 302 .
- Icache 101 , counter 102 , and IP-to-TM cache 104 are parts of processor CPU 301 .
- bus 302 is coupled to random access memory (RAM) 303 , read only memory (ROM) 304 , input/output (I/O) adapter 305 , communications adapter 311 , user interface adapter 308 , and display adapter 309 .
- RAM 303 may be PROM, EPROM, or EEPROM.
- RAM 303 may be SRAM, DRAM, or SDRAM.
- RAM 303 and ROM 304 hold user and system data and programs as is well known in the art.
- I/O adapter 305 connects storage devices 306 , such as a hard drive or a CD ROM drive, to the computer system.
- Communications adaption 311 is adapted to couple the computer system to a local, wide-area, or Internet network 312 .
- User interface adapter 308 couples user input devices, such as keyboard 313 and pointing device 307 , to computer system 300 .
- display adapter 309 is driven by CPU 301 to control the display on display device 310 .
- CPU 301 may be any general purpose CPU, such as an HP PA-8200. However, the present invention is not restricted by the architecture of CPU 301 as long as CPU 301 supports the inventive operations as described herein.
Abstract
The inventive mechanism has a run-time optimization system (RTOS) embedded in hardware. When the code is first moved into Icache, a threshold value is set into a counter associated with the instruction or instruction bundle of the particular cache line of the Icache. Each time the instruction or instruction bundle is executed and retired, the counter is decremented by one. When the counter reaches zero, a trap is generated to inform that the code is hot. A trace selector will form a trace starting from the hot instruction (or instruction bundle) from the Icache line. The Icache maintains branch history information for the instructions in each cache line which is used to determine whether a branch should be predicted as taken or fall through. After the trace is formed, it is optimized and stored into a trace memory portion of the physical memory. The mapping between the original code of the trace and the optimized trace in the trace memory is maintained in a mapping table. The processor consults the mapping table to lead the execution to the optimized code in trace memory. Thus, subsequent execution uses the code in trace memory.
Description
- This is a continuation of copending and commonly assigned U.S. patent application entitled SYSTEM AND METHOD USING A HARDWARE EMBEDDED RUN-TIME OPTIMIZER, Ser. No. 09/252,170, filed Feb. 18, 1999, which is hereby incorporated by reference herein. Reference is made to the following commonly assigned U.S. patent entitled EFFICIENT MAPPING TO OPTIMIZED CODE FOR PROCESSOR EMBEDDED RUN-TIME OPTIMIZER, U.S. Pat. No. 6,185,669, issued Feb. 6, 2001, which is hereby incorporated by reference herein, and copending and commonly assigned U.S. patent application entitled FAST INSTRUCTION PROFILING AND EFFECTIVE TRACE SELECTION, Ser. No. 09/252,567, filed Feb. 18, 1999, which is hereby incorporated by reference herein.
- This application relates in general to run-time optimizers, and in specific to hardware embedded run-time optimizer.
- A run-time optimizer is an adaptive software system that transparently optimizes applications at run-time. The optimizer rewrites the binary code of an application on-the-fly to achieve a higher execution efficiency.
- FIG. 4 depicts prior art run-
time optimizer 30. Thecontrol loop 31 begins execution of a block of program code via emulation performed by theprofiling emulator 32. The profiling aspect ofemulator 32 allows thecontrol loop 31 to track the number of times the particular block of code has been executed via emulation. Note that a run-time optimization system is different from a run-time binary translation system, in that the latter is for architecture migration while the former is to decrease execution time. The run-time optimization system is using theemulator 32 for profiling in order to guide optimizations, i.e. the code is running on its native system. After a predetermined number of executions via emulation, thecontrol loop 31 designates the block of code as hot code, and desirable for optimization. Thecontrol loop 31 then activatestrace selector 33 to translate the block of code. Thetrace selector 33 forms a trace of the instructions that comprise the block of code by following the instructions in the block. When a branch instruction is encountered, the trace selector makes a prediction as to whether the branch is taken or falls through. If the selector decides the branch is mostly taken, then the trace is formed by extending the code from the branch target block. If the selector decides not to take the branch, then the branch falls through, and the trace continues within the fall through block. The trace terminates at a backward branch predicted to be taken or when the trace becomes sufficiently large. After the trace is completed, the code is rewritten with machine dependent and machine independent optimizations. The optimized code is then placed into thecode cache 34. The next time thecontrol loop 31 encounters a condition to execute this block of code, then thecontrol loop 31 will execute the code in thecode cache 34 and not emulate the code viaemulator 32. - As shown in FIG. 5, if the target of a branch which is taken to exit
trace 1, as shown bybranch instruction 41, then control is returned to the run-time system RTS 30 and to controlloop 31, which determines if the target resides in the code cache. If the target resides in code cache, then thecontrol loop 31 modifies the target of thebranch instruction 41 to be thetrace 2 42 in code cache as shown bybranch instruction 43. This modification is called backpatching. Thus, if the exit of the trace is already translated, then the branch is backpatched such that a subsequent execution will directly branch to the new trace without returning to the control loop. Backpatching increases the speed of execution of the code, as returning to the RTS significantly slows down execution time. - A problem with FIG. 4 is that an emulator is required to perform profiling, i.e. the emulated code is used to determine which code is hot. Emulation is very slow, usually 50-200 times slower than native execution speed. Consequently, there is a large time penalty for determining which code is hot. Moreover, the quality of optimization is often determined by the quality of the selected trace. Poor trace selection can be costly, for example, predicting a branch not to be taken means the remainder of the block code is traced and optimized, and if mispredicted, then that tracing and optimizing of the code subsequent to the branch is wasted. Branch misprediction can be minimized by maintaining a long history of branching outcomes, which is formed by continually emulating the code block. Thus, the prior art RTS either incurs a time penalty from emulation to build a good history or incurs a time penalty from branch misprediction.
- Another problem with the prior art RTS is that it cannot backpatch an indirect branch. The RTS cannot backpatch an indirect branch because the target address is unknown. The target address is typically in a register or memory location and not written directly in code. Thus, the RTS will shift control back to the
control loop 31 to determine whether the target address has been translated, which is expensive in terms of time. The prior art has attempted to minimize this problem by inlining a code sequence to search a smaller lookup table in the optimized traces, however, these mechanism still incur high overhead. Examples of indirect branches are return branches and switch branches. - A further problem with the prior art RTS is that it attempts to translate any code that is deemed hot based on a small threshold. This problem is referred to as complex and less reliable. There are some traces that are difficult to translate, but, without a translation, the execution of the trace would be performed by software simulation or emulation. Since emulation is slow, all hot code is translated. Some traces are very difficult to translate. For example, it is difficult to translate a trace with branches in the delay slot of another branch. The requirement of translating all hot code increases the translation time and complexity.
- A further problem with the prior art RTS is that it will handle only user code and not operating system (OS) code. This is because the RTS is layered between the user application and the OS, and thus will not handle privileged instructions and addressing modes. In the prior art, the RTS is attached to user processes. Since the prior art RTS cannot be attached to the OS, it does not handle OS code.
- Therefore, there is a need in the art for a RTS that does not require emulation for profiling, can handle indirect branches without returning control to a control loop, can refuse translation of difficult code and will handle OS code.
- These and other objects, features and technical advantages are achieved by a system and method which embeds the control loop in hardware and, thus, does not require emulation for profiling, can handle indirect branches, will not translate difficult code, and will handle OS code. The inventive run-time optimization system (RTOS) places the control loop in the hardware and the translation/optimization components in the firmware, which are both below the OS level. Hence, the OS code can also be optimization candidates.
- The inventive RTOS handles execution profiling and transfers execution to optimized traces automatically. This would allow code to run at faster native speed instead of slower emulation. Since the code is running faster, the threshold for selecting a hot trace could be set much higher than the prior art. This would also avoid generating traces for relatively infrequent code paths. Moreover, a higher threshold would enable the selection of better traces. Thus, a processor desires to execute a block of instructions, the processor first examines the Icache to determine whether the block is present. If not, the block is moved from memory to Icache. When the code is first moved into Icache, a threshold value is set into a counter associated with the particular instruction or instruction bundle (a group of instructions that can be issued together in the same cycle) of the Icache. Each time the instruction or instruction bundle is executed and retired, the counter is decremented by one. When the counter reaches zero, a trap is generated and the instruction (or instruction bundle) is designated as hot code.
- After the trap is generated to firmware, a trace selector forms a trace of the hot code. The trace is followed to determine the location of the target, i.e., the next instruction. The Icache maintains branch history information for the instructions in each cache line. This branch history is used to determine whether a branch should be predicted (as thus treated) as taken or to fall through. If the branch is predicted to fall through, then the subsequent instruction bundle is the next instruction. If the branch is predicted to be taken, the target instruction is the next instruction. After the trace is completed, it is optimized and stored into a trace memory portion of the physical memory. The mapping of the starting address of the original trace to the location of the optimized trace in Trace Memory (TM) is maintained in the IP-to-TM Table. The instruction fetch unit consults the IP-to-TM Table to decide whether the execution should continue with an optimized trace in the TM. There is an IP-to-TM cache in the instruction fetch unit to speed up the access of the IP-to-TM Table. The processor consults the IP-to-TM cache prior to examining the Icache. Therefore, upon subsequent execution of this code, the processor examines the IP-to-TM cache, which then points to the trace memory location. Thus, the code in the trace memory is executed instead of the original binary code. Note that if the code has not been optimized, the processor will execute the original code in the Icache. Note that the instruction from the TM (Trace Memory) will also be moved into the Icache before execution, not just the original code.
- Since the inventive RTOS uses hardware managed trace address mapping, the complexity of backpatching may be eliminated. This also avoids reserving registers for passing arguments in trampoline code used in backpacking that may introduce a register spilling penalty. Furthermore, the inventive RTOS can significantly reduce the cost of handling indirect branches. Since the non-optimized code runs at native speeds, the indirect branch is allowed to execute which returns control to native code. Note that a hardware (or processor) table lookup is significantly faster than a software (or emulator) table lookup. For example, a search of the IP-to TM cache may require one cycle, whereas a software lookup of a table would require from 10 to 1000 cycles. The software lookup is expensive because the current architecture states must be saved before returning to the software RTS (Run-Time System).
- The inventive RTOS uses hardware to directly process non-trace code, which significantly improves the reliability of the dynamic optimizer. The dynamic translator can choose not to translate some difficult traces and leave them unchanged in the original code, since this code will be executed at native speeds. Therefore, the time penalty for not optimized code is much lower than compared with the prior art software emulation. Specifically, a decision in the prior art RTOS not to optimize code, meant that the code would be executed at emulator speeds. Note that in the prior art, all hot code is optimized. Furthermore, the reliability aspects are improved because less code would need to be translated, and thus fewer problems from translation will be introduced into the program application.
- The inventive RTOS is controlled at the processor and at the firmware level, which is below the OS. Therefore, the inventive RTOS can handle OS code.
- Therefore, it is a technical advantage of the present invention to have the run-time optimization system (RTOS) embedded into the hardware.
- It is another technical advantage of the present invention that the embedded RTOS does not require software emulation for code profiling to determine hot code.
- It is further technical advantage of the present invention that the embedded RTOS can substantially reduce the cost of handling indirect branches.
- It is further technical advantage of the present invention that the embedded RTOS can elect not to translate difficult code, and run such code at native speeds.
- It is further technical advantage of the present invention that the embedded RTOS can handle OS code in addition to user application codes.
- The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and the specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.
- FIG. 1 depicts the inventive run-time optimization system (RTOS) that has its control loop embedded in hardware;
- FIG. 2 depicts a version of the inventive RTOS of FIG. 1 configured to run without backpatching;
- FIG. 3 depicts a high level block diagram of a computer system adapted to implement the inventive RTOS of FIGS. 1 and 2;
- FIG. 4 depicts a prior art software emulation RTS; and
- FIG. 5 depicts a prior art backpatching mechanism that is used with the system of FIG. 4.
- FIG. 1 depicts the inventive run-time optimization system (RTOS)100 that is embedded in hardware.
RTOS 100 has the control of the optimization in hardware and hardware is used to detect hot code, as well as execute both optimized and non-optimized code. Hardware also notifies the firmware via traps. TheRTOS 100 uses firmware to handle trace selection, code optimization, and trace memory management, each of which require complex analysis. The balance of work between hardware and firmware is an important aspect of the inventive RTOS. The inventive RTOS distributes the different aspects of the RTOS work to the mechanism, i.e. hardware or firmware, best suited to handle the work. Thus, the inventive RTOS has both hardware and firmware aspects. The operation ofRTOS 100 is transparent to the user, as control moves between hardware and firmware without user involvement. Note that firmware is microcode in ROM. - The
RTOS 100 uses the instruction cache (Icache) 101 of theprocessor 301 to determine which code is hot code. Associated with theIcache 101 is acounter 102 and a few bits that are used to hold the branch history information associated with each instruction or instruction bundle in theIcache 101. A preferred embodiment is to have theIcache 101 holds multiple instructions per cache line, thusmultiple counters 102 andregisters 103 would be associated with each cache line. The number of cache lines is processor dependent, for example a Pentium II has 16K of Icache which is organized into 512 cache lines. - The RTOS uses the
trace memory 105 to hold the traces of the optimized instructions. Note thattrace memory 105 is a portion ofRAM memory 303.RAM 303 also includes IP-to-TM mapping table (TM table) 106. This table list the mapping of the original IP of a trace to the location in theTM 105 which correspond to the optimized trace. The RTOS uses IP-to-TM cache 104, which is a TLB-like structure in the instruction fetch unit to accelerate mapping table access. The IP-to-TM cache 104 holds a smaller portion of the most active entries in the TM mapping table. - The RTOS uses
firmware 108 to perform tasks which require complex analysis.Trace selector 109 forms traces of instructions, and includes branch prediction. The operation of this component and its interaction with the other RTOS components is explained in the related, co-pending application entitled, FAST INSTRUCTION PROFILING AND EFFECTIVE TRACE SELECTION, by Hsu et al., Ser. No. 09/252,567, filed Feb. 18, 1999, which is hereby incorporated by reference.Optimizer 110 optimizes the trace determined bytrace selector 109. The optimized code is then placed into thetrace memory 105, which is managed bytrace memory manager 111. -
Execution pipeline 107 depicts sequence of execution of an instruction byprocessor 301. The first stage is the instruction pointer generation (IPG) 112. This stage delivers an instruction pointer (IP) toIcache 101. The IP may come from several places, for example, as a corrected target address from a branch misprediction, as a predicted branch addresses, or as a next sequential address. When an instruction pointer (IP) in the user application (not shown) indicates that a particular instruction is to be executed, the processor first checks IP-to-TM cache 104 to determine whether the instruction is a starting location of a block which has been optimized and the optimized version resides in trace memory (TM) 105. - If it exists in IP-to-
TM cache 104, the processor then retrieves the location of the optimized instruction intrace memory 105, and executes the optimized instruction. If it does not exist, then the processor examinesIcache 101 to determine if the instruction is in Icache. If it exists inIcache 101, then the processor executes the instruction. If it does not exist, then the processor retrieves the instruction frommemory 303, and places the instruction intoIcache 101. This is performed in fetchstage FET 113 of the pipeline. - When the instruction is first moved into
Icache 101, a threshold value is set intocounter 102 associated with the particular instruction or instruction bundle inIcache 101. Each time the cache line is retired from theexecution pipeline 107, i.e. execution is complete,counter 102 is decremented by one andbranch history 103 is updated. Whencounter 102 reaches zero, a trap is generated and the instruction is designated as hot code. Note that the preferred threshold is between approximately 50 to approximately 200. Thus, the counters can be 8 bits. For comparison, the prior art threshold is as small as 5. Note that in the instruction fetch stage, a fetch address can come from several different sources, e.g. as calculated from fall through address such as (current-IP+1-line) or (current-TM+1-line), as a predicted taken branch target address in from some branch prediction hardware, or as a target address forwarded from a mispredicted branch detected at the end of execution stage. - The trap invokes
firmware 108.Trace selector 109 forms a trace based on the starting instruction bundle and any surmised branch predictions which have been determined frombranch history information 103. The termination of a trace will be driven by a set of heuristics including the length of the trace, the number of conditional branches encountered, the probability of accumulated branch predictions and other considerations. A trace may terminate at an indirect branch, since the target address is not known. However, the trace selector may decide to grow the trace by predicting its most recent target from some hardware branch predictor such as RTB (Branch Target Buffer). For a return branch, the trace selector would know the return address if the call instruction is in the trace, if the call instruction is not in the trace, the trace selector can predict the call site using the top address of the RSB (Return Stack Buffer). The BTB is described in “Branch Prediction Strategies and Branch Target Buffer Design”, IEEE, Computer, January, 1984, which is hereby incorporated by reference. - Note that since traces (as well as any instruction either in the original binary or in the TM) are also brought into
Icache 101 before being executed, the profiling and trace selection may end up generating a trace on top of an existing trace. Traces can be identified, since their addresses are preserved memory (e.g. RAM), and are accessible by the RTOS. When trace lines are moved intoIcache 101, their counters do not get initialized, thus they do not participate in profiling. Alternatively, if traces do participate in profiling,trace selector 109 can check whether this trace is considered “good”. For example, if a trace has a frequent early exit, the trace may need to be regenerated. - After the trace has been formed,
optimizer 110 will operate on the trace. The optimizer may perform any of the following optimizations: prefetch insertion (both Icache and Dcache), inlining/outlining and calling overhead reduction, instruction polarity padding, bundle compression using compact templates, unnecessary stop bits elimination, converting ST-LD (with same address) to ST-copy, convert LD-LD (with same address) to LD-copy, and constant propagation and assertion propagation. This list is by way of example only. Other optimizations may be performed so long as the processor would deliver an identical architecture state to the original binary application when traps/exceptions are raised. Once the selected trace is optimized, it is written intotrace memory 105. -
Trace memory manager 108 maintains thetrace memory 105. The trace memory can be divided into several chunks. Traces are written into the current chunk at the next available address. When a chunk is filled up, the next chunk becomes the current chunk. When there is no chunks available, one of the existing chunks will be evicted. When a chunk is evicted, all the traces in that chunk become invalid. This will in turn trigger the elimination of address mapping entries from TM mapping table 106 and IP-to-TM cache 104. Also, invalid traces existing inIcache 101 will also be purged. Note that before a chuck is evicted, the trace manager ensures that no threads or processes are executing any of the trace in the evicted chunk. When a processor is interrupted, and the processor is executing in a trace, the processor will go back to its original binary instruction when it resumes. Thus, the trace manager forces each executing thread/process out of the trace memory by sending an interrupt signal to the processor(s). Once the entries in IP-to-TM cache 104 have been purged, no new threads and processes can enter the chunk to be evicted. Thus, the evicted chunk can then be reused. - Note that trace locality can be implemented by
trace memory manager 111.Trace memory manager 111 would track the frequency of usage of traces in the mapping cache, and periodically reorganize the traces intrace memory 105 in such a manner that both sequential and temporal locality can be improved. For example, if trace A branches to trace B more frequently, then trace B will be placed next to trace A intrace memory 105. Note that if the hardware support PC-relative branches in traces to generate original IP addresses, relocating traces will be much easier. - If the next fetch address is a trace address, either a fall through from a trace address or the branch target is a trace, the fetch unit can bypass the regular instruction translation and retrieve the optimized code from
trace memory 105. This operation is explained in the related, co-pending patent application entitled EFFICIENT MAPPING TO OPTIMIZED CODE FOR PROCESSOR EMBEDDED RUN-TIME OPTIMIZERS, by Benitez et al. (HP# 10981004-1), which is hereby incorporated by reference. - In the expansion stage or
EXP stage 114, the instructions are decoded and PC relative branch target addresses are calculated. -
REN stage 115 translates logical (virtual) register into physical registers. -
REG stage 116 accesses the registers and delivers operands to all execution units. -
EXE stage 117 executes the instruction. - The detection stage or
DET 118 is the stage of the pipeline where the processor can check to see whether. an instruction contains a trap or exception. If so, then the processor reports to the operating system, unless the trap or exception is associated with an address in trace memory, then it is reported to firmware. - The last stage of the pipeline is the write back or
WRB 119. In this stage, executed instructions are retired from the pipeline. At thispoint counter 102 associated with the instruction would be decremented and the associatedbranch history information 103 would be updated. Updating the branch history allows for an accurate history as a speculative execution is performed. Note that this stage is also referred to as the retirement stage. - FIG. 2 depicts the inventive run-time optimization system (RTOS)200 that is embedded in hardware, and is configured to operate without backpatching. Note that
Icache 101 and counter 102 are also embedded in hardware. For exception or fault, the trace-entering IP-address 201 can be used to figure out the original IP address. This simplifies the trace memory management work, as the trace exit branches can be maintained as IP addresses. Thus, transition from trace to original binary is relatively easy. Moreover, when a trace is removed, the trace manager does not need to reinsert trampoline code (unbackpatch) at every incoming branch site. Furthermore, access protection for traces can be enforced on the IP-to-TM cache, as the only way to branch to a trace is to go through the IP-to-TM mapping.Block 201 stores the most recent trace entering IP address. Theblock 201 is a register that holds the most current IP address that enters the TM memory. This IP address is used to calculate the branch address in the trace. Note that most conditional branches are PC relative and not TM relative. - Note that PC-relative branches in traces may need special treatment since they are now relative to trace memory locations rather than to the original virtual IP address. This treatment may be provided by backpatching. However, backpatching makes trace memory management very difficult. For example, suppose trace A has an exit branch which jumps to trace B. Once this branch is backpatched, trace A and trace B are bound together. If trace B is part of a chunk that is to be evicted from the trace memory, then the respective branch in trace A must be unbackpatched. However, if PC-relative branches generate target addresses in the original IP addresses, then backpatching is not needed, and all traces are “relocatable”, i.e. removing one trace would not affect others.
- The target address of PC-relative branches in traces is computed in the context of original IP addresses instead of trace memory addresses. This is achieved by remembering the trace entering IP address in
block 201 atEXP stage 114. The branch unit uses this IP address inblock 201 as the base address for calculating a PC-relative branch target address for traces (instructions from TM). The offset in those PC-relative branch instructions in traces is generated based on the trace entering IP address. Thus, a branched-to-trace can be entered uniformly from going through the IP-to-TM cache instead of backpatching. For a PC-relative branch instruction in a trace, themanager 111 would use the respective entering IP address instead of the current trace address as the current PC location for target address calculation. The offset in PC-relative branches needs to be adjusted relative to the entering of IP address. This is done during trace translation/optimization time by the trace selector. The following table illustrates the address offset adjustment work. Note that the offsets are adjusted, relative to the entering IP address 1000. Further note that this table is by way of example only, and other values could be used.Original Binary taken/ Adjusted branch offset in the trace bundle branch not old bundle exit branch address offset taken TM address address offset 1000 br +300 not taken 1 1000 br +300 1001 br +500 taken 2 1001 br +2 1501 br +200 not taken 3 1501 br +701 1502 br +1500 taken 4 1502 br +503 3002 br +100 not taken 5 3002 br +2102 3003 br 2003 taken 6 3003 br +0 - As shown in the above table, the left side portion depicts parts of the original binary with the branch offsets listed from the current address and an indication as to whether the branches are likely to be taken or fall through. The trace selector builds a trace from these portions, as shown on the right side of the above table. The instructions of the trace are predicted to operate sequentially. Thus,
TM 1 would fall through toTM 2, and so on. However, if the predicted behavior of the instruction is incorrect, i.e. mispredicted, then the trace will be exited. The target of the trace instruction is the opposite of the predicted target of the original binary. For example,TM 2 holds old bundle address 1001. The trace is built with the prediction that the branch will be taken. Hence,TM 3 contains old bundle address 1501. A misprediction indicates that the branch will not be taken, and thus will fall through, i.e. from address 1001 to 1002. Thus, the exit branch offset is +2, which when added to the entering IP address of 1000 will yield the correct IP address of 1002. Another example for the table is as follows. TM 5 holds old bundle address 3002. The trace is built with the prediction that the branch will not be taken, hence TM 6 contains old bundle address 3003. A misprediction indicates that the branch will be taken, and thus will jump from address 3002 to 3102 via the offset of +100. Thus, the exit branch offset is +2102, which, when added to the entering IP address of 1000, will yield the correct IP address of 3102. - If all trace exit target addresses are generated from instructions in traces that are in the original IP form, then no backpatch is needed. The fetch address lookup process is also simplified, since only the fall through address calculation may generated a trace address, TAC/RSB and branch misprediction will all generate IP addresses. In this way, all branch target addresses forwarded to the IPG stage are in their original IP addresses. Such addresses will uniformly go through the IP-to-TM cache to transfer to traces if a match is found. This is further discussed in co-pending and commonly assigned U.S. Patent Applications entitled EFFICIENT MAPPING TO OPTIMIZED CODE FOR PROCESSOR EMBEDDED RUN-TIME OPTIMIZER (HP No. 10981004-1), which is hereby incorporated by reference.
- FIG. 3 illustrates
computer system 300 adapted to use the present invention. Central processing unit (CPU) 301 is coupled tobus 302. Note thatIcache 101, counter 102, and IP-to-TM cache 104 are parts ofprocessor CPU 301. In addition,bus 302 is coupled to random access memory (RAM) 303, read only memory (ROM) 304, input/output (I/O)adapter 305,communications adapter 311,user interface adapter 308, anddisplay adapter 309. Note,ROM 304 may be PROM, EPROM, or EEPROM. Also note,RAM 303 may be SRAM, DRAM, or SDRAM. -
RAM 303 andROM 304 hold user and system data and programs as is well known in the art. I/O adapter 305 connectsstorage devices 306, such as a hard drive or a CD ROM drive, to the computer system.Communications adaption 311 is adapted to couple the computer system to a local, wide-area, orInternet network 312.User interface adapter 308 couples user input devices, such askeyboard 313 andpointing device 307, tocomputer system 300. Finally,display adapter 309 is driven byCPU 301 to control the display ondisplay device 310.CPU 301 may be any general purpose CPU, such as an HP PA-8200. However, the present invention is not restricted by the architecture ofCPU 301 as long asCPU 301 supports the inventive operations as described herein. - Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (12)
1. A system for optimizing a portion of a program during run-time of the program, the system comprising:
a hardware portion for detecting which instructions of the program are more frequently executed and maintaining a history of targets chosen by branch instructions of the program;
a software portion for forming an optimized trace of instructions from the most frequently executed instructions and using the history in making branch predictions for branch instructions encountered in forming the trace; and
a trace memory portion that stores the optimized trace.
2. The system of claim 1 , further comprising:
a table memory portion that stores a map of instruction pointers of the program to corresponding addresses in the trace memory.
3. The system of claim 2 , wherein the software portion further comprises:
a trace manager that controls usage of the trace memory.
4. The system of claim 1 , wherein the software portion comprises:
an optimizer which performs at least one predetermined optimization on the trace to form the optimized trace.
5. The system of claim 1 , wherein the hardware portion comprises:
a processor cache for holding a mapping of instruction pointers to addresses of optimized trace instructions.
6. The system of claim 1 , wherein
the hardware portion includes an instruction cache with a first portion that maintains a plurality of values, each indicating a number of executions of a particular instruction of the program, and a second portion that stores information detailing performance of branch instructions of the program; and
the software portion includes a trace selector that forms the trace and is invoked when the one value of the plurality of values reaches a predetermined number, and the trace selector begins the trace with the instruction associated with the one counter and ends the trace with an instruction selected by a predetermined criteria.
7. A method for optimizing a portion of a program during run-time of the program, the method comprising the steps of:
detecting via hardware, which instructions of the program are more frequently executed;
maintaining, via hardware, a history of targets chosen by branch instructions of the program;
forming, via software, an optimized trace of instructions from the most frequently executed instructions, wherein the step of forming includes the step of using the history in making branch predictions for branch instructions encountered in forming the trace; and
storing the optimized trace in a trace memory portion.
8. The method of claim 7 , further comprising the step of:
storing a map of instruction pointers of the program to corresponding addresses in the trace memory in a table memory portion.
9. The method of claim 8 , further comprising the step of:
controlling, via software, usage of the trace memory.
10. The method of claim 7 , further comprising the step of:
performing at least one predetermined optimization on the trace to form the optimized trace.
11. The method of claim 7 , further comprising the step of:
storing, via a processor cache, a mapping of instruction pointers to addresses of optimized trace instructions.
12. The method of claim 7 , wherein the hardware includes an instruction cache with a first portion that maintains a plurality of values, each indicating a number of executions of a particular instruction of the program, and a second portion that stores information detailing performance of branch instructions of the program; and
the software includes a trace selector that forms the trace and is invoked when one value of the plurality of values reaches a predetermined number and the trace selector begins the trace with the instruction associated with the one counter and ends the trace with an instruction selected by a predetermined criteria.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/222,014 US20030005271A1 (en) | 1999-02-18 | 2002-08-15 | System and method using a hardware embedded run-time optimizer |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/252,170 US6453411B1 (en) | 1999-02-18 | 1999-02-18 | System and method using a hardware embedded run-time optimizer |
US10/222,014 US20030005271A1 (en) | 1999-02-18 | 2002-08-15 | System and method using a hardware embedded run-time optimizer |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/252,170 Continuation US6453411B1 (en) | 1999-02-18 | 1999-02-18 | System and method using a hardware embedded run-time optimizer |
Publications (1)
Publication Number | Publication Date |
---|---|
US20030005271A1 true US20030005271A1 (en) | 2003-01-02 |
Family
ID=22954898
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/252,170 Expired - Fee Related US6453411B1 (en) | 1999-02-18 | 1999-02-18 | System and method using a hardware embedded run-time optimizer |
US10/222,014 Abandoned US20030005271A1 (en) | 1999-02-18 | 2002-08-15 | System and method using a hardware embedded run-time optimizer |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/252,170 Expired - Fee Related US6453411B1 (en) | 1999-02-18 | 1999-02-18 | System and method using a hardware embedded run-time optimizer |
Country Status (1)
Country | Link |
---|---|
US (2) | US6453411B1 (en) |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070234016A1 (en) * | 2006-03-28 | 2007-10-04 | Sun Microsystems, Inc. | Method and system for trace generation using memory index hashing |
US7346758B1 (en) * | 2005-05-10 | 2008-03-18 | Advanced Micro Devices, Inc. | System and method for trace messaging |
US7783863B1 (en) * | 2005-09-28 | 2010-08-24 | Oracle America, Inc. | Graceful degradation in a trace-based processor |
US7797517B1 (en) | 2005-11-18 | 2010-09-14 | Oracle America, Inc. | Trace optimization via fusing operations of a target architecture operation set |
US7849292B1 (en) | 2005-09-28 | 2010-12-07 | Oracle America, Inc. | Flag optimization of a trace |
US7870369B1 (en) * | 2005-09-28 | 2011-01-11 | Oracle America, Inc. | Abort prioritization in a trace-based processor |
US7877630B1 (en) | 2005-09-28 | 2011-01-25 | Oracle America, Inc. | Trace based rollback of a speculatively updated cache |
US7937564B1 (en) | 2005-09-28 | 2011-05-03 | Oracle America, Inc. | Emit vector optimization of a trace |
US7941607B1 (en) | 2005-09-28 | 2011-05-10 | Oracle America, Inc. | Method and system for promoting traces in an instruction processing circuit |
US7949854B1 (en) | 2005-09-28 | 2011-05-24 | Oracle America, Inc. | Trace unit with a trace builder |
US7953961B1 (en) | 2005-09-28 | 2011-05-31 | Oracle America, Inc. | Trace unit with an op path from a decoder (bypass mode) and from a basic-block builder |
US7953933B1 (en) | 2005-09-28 | 2011-05-31 | Oracle America, Inc. | Instruction cache, decoder circuit, basic block cache circuit and multi-block cache circuit |
US20110138231A1 (en) * | 2009-12-03 | 2011-06-09 | Infineon Technologies Ag | High compression program flow trace |
US7966479B1 (en) | 2005-09-28 | 2011-06-21 | Oracle America, Inc. | Concurrent vs. low power branch prediction |
US7987342B1 (en) | 2005-09-28 | 2011-07-26 | Oracle America, Inc. | Trace unit with a decoder, a basic-block cache, a multi-block cache, and sequencer |
US8010745B1 (en) | 2006-09-27 | 2011-08-30 | Oracle America, Inc. | Rolling back a speculative update of a non-modifiable cache line |
US8015359B1 (en) | 2005-09-28 | 2011-09-06 | Oracle America, Inc. | Method and system for utilizing a common structure for trace verification and maintaining coherency in an instruction processing circuit |
US8019944B1 (en) | 2005-09-28 | 2011-09-13 | Oracle America, Inc. | Checking for a memory ordering violation after a speculative cache write |
US8024522B1 (en) | 2005-09-28 | 2011-09-20 | Oracle America, Inc. | Memory ordering queue/versioning cache circuit |
US8032710B1 (en) | 2005-09-28 | 2011-10-04 | Oracle America, Inc. | System and method for ensuring coherency in trace execution |
US8037285B1 (en) | 2005-09-28 | 2011-10-11 | Oracle America, Inc. | Trace unit |
US8051247B1 (en) | 2005-09-28 | 2011-11-01 | Oracle America, Inc. | Trace based deallocation of entries in a versioning cache circuit |
US8370609B1 (en) | 2006-09-27 | 2013-02-05 | Oracle America, Inc. | Data cache rollbacks for failed speculative traces with memory operations |
US8370576B1 (en) | 2005-09-28 | 2013-02-05 | Oracle America, Inc. | Cache rollback acceleration via a bank based versioning cache ciruit |
US20130091331A1 (en) * | 2011-10-11 | 2013-04-11 | Iulian Moraru | Methods, apparatus, and articles of manufacture to manage memory |
US8499293B1 (en) | 2005-09-28 | 2013-07-30 | Oracle America, Inc. | Symbolic renaming optimization of a trace |
US20140282451A1 (en) * | 2013-03-15 | 2014-09-18 | Alejandro M. Vicente | Identification and management of unsafe optimizations |
US20140337604A1 (en) * | 2013-05-09 | 2014-11-13 | Beeman C. Strong | Minimizing bandwidth to track return targets by an instruction tracing system |
CN104407968A (en) * | 2014-10-30 | 2015-03-11 | 北京控制工程研究所 | Method for measuring and calculating longest operation time of code instructions through static analysis |
US20150113251A1 (en) * | 2013-10-18 | 2015-04-23 | Marvell World Trade Ltd. | Systems and Methods for Register Allocation |
US20160357658A1 (en) * | 2015-06-05 | 2016-12-08 | Intel Corporation | Implementation Of Processor Trace In A Processor That Supports Binary Translation |
US20170024266A1 (en) * | 2015-07-20 | 2017-01-26 | Kabushiki Kaisha Toshiba | Memory system, information processing system, and host device |
Families Citing this family (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6418530B2 (en) | 1999-02-18 | 2002-07-09 | Hewlett-Packard Company | Hardware/software system for instruction profiling and trace selection using branch history information for branch predictions |
US6725335B2 (en) * | 2000-02-09 | 2004-04-20 | Hewlett-Packard Development Company, L.P. | Method and system for fast unlinking of a linked branch in a caching dynamic translator |
US6785801B2 (en) * | 2000-02-09 | 2004-08-31 | Hewlett-Packard Development Company, L.P. | Secondary trace build from a cache of translations in a caching dynamic translator |
US7260684B2 (en) * | 2001-01-16 | 2007-08-21 | Intel Corporation | Trace cache filtering |
US6950924B2 (en) * | 2002-01-02 | 2005-09-27 | Intel Corporation | Passing decoded instructions to both trace cache building engine and allocation module operating in trace cache or decoder reading state |
US20030191893A1 (en) * | 2002-04-09 | 2003-10-09 | Miller John Alan | Method, system, and apparatus for efficient trace cache |
US6961874B2 (en) * | 2002-05-20 | 2005-11-01 | Sun Microsystems, Inc. | Software hardening utilizing recoverable, correctable, and unrecoverable fault protocols |
US7603704B2 (en) | 2002-12-19 | 2009-10-13 | Massachusetts Institute Of Technology | Secure execution of a computer program using a code cache |
US7594111B2 (en) * | 2002-12-19 | 2009-09-22 | Massachusetts Institute Of Technology | Secure execution of a computer program |
US7228534B2 (en) * | 2003-06-14 | 2007-06-05 | Intel Corporation | Optimizing performance of a program or a computer system |
US7236107B2 (en) * | 2004-09-20 | 2007-06-26 | Fujitsu Limited | System and method for identifying optimal encoding for a given trace |
US7463593B2 (en) | 2005-01-13 | 2008-12-09 | International Business Machines Corporation | Network host isolation tool |
US7735136B2 (en) * | 2005-04-18 | 2010-06-08 | Vmware, Inc. | 0-touch and 1-touch techniques for improving the availability of computer programs under protection without compromising security |
EP1891520B1 (en) * | 2005-06-07 | 2017-09-13 | VMware, Inc. | Constraint injection system for immunizing software programs against vulnerabilities and attacks |
US20080077778A1 (en) * | 2006-09-25 | 2008-03-27 | Davis Gordon T | Method and Apparatus for Register Renaming in a Microprocessor |
US20080215804A1 (en) * | 2006-09-25 | 2008-09-04 | Davis Gordon T | Structure for register renaming in a microprocessor |
US8386712B2 (en) * | 2006-10-04 | 2013-02-26 | International Business Machines Corporation | Structure for supporting simultaneous storage of trace and standard cache lines |
US7644233B2 (en) * | 2006-10-04 | 2010-01-05 | International Business Machines Corporation | Apparatus and method for supporting simultaneous storage of trace and standard cache lines |
US7610449B2 (en) * | 2006-10-04 | 2009-10-27 | International Business Machines Corporation | Apparatus and method for saving power in a trace cache |
US7934081B2 (en) * | 2006-10-05 | 2011-04-26 | International Business Machines Corporation | Apparatus and method for using branch prediction heuristics for determination of trace formation readiness |
US20080250206A1 (en) * | 2006-10-05 | 2008-10-09 | Davis Gordon T | Structure for using branch prediction heuristics for determination of trace formation readiness |
US20080250207A1 (en) * | 2006-11-14 | 2008-10-09 | Davis Gordon T | Design structure for cache maintenance |
US20080114964A1 (en) * | 2006-11-14 | 2008-05-15 | Davis Gordon T | Apparatus and Method for Cache Maintenance |
US20080120468A1 (en) * | 2006-11-21 | 2008-05-22 | Davis Gordon T | Instruction Cache Trace Formation |
US20080235500A1 (en) * | 2006-11-21 | 2008-09-25 | Davis Gordon T | Structure for instruction cache trace formation |
US8180964B1 (en) * | 2007-09-28 | 2012-05-15 | The Mathworks, Inc. | Optimization of cache configuration for application design |
US8308185B2 (en) * | 2009-01-30 | 2012-11-13 | Weaver Danny C | Pin-engaging drawbar and lock plate assembly |
US8356165B2 (en) * | 2009-09-14 | 2013-01-15 | Advanced Micro Devices, Inc. | Selecting regions of hot code in a dynamic binary rewriter |
US8516230B2 (en) | 2009-12-29 | 2013-08-20 | International Business Machines Corporation | SPE software instruction cache |
US8631225B2 (en) | 2010-06-25 | 2014-01-14 | International Business Machines Corporation | Dynamically rewriting branch instructions to directly target an instruction cache location |
US9459851B2 (en) | 2010-06-25 | 2016-10-04 | International Business Machines Corporation | Arranging binary code based on call graph partitioning |
US8522225B2 (en) | 2010-06-25 | 2013-08-27 | International Business Machines Corporation | Rewriting branch instructions using branch stubs |
US20110320786A1 (en) | 2010-06-25 | 2011-12-29 | International Business Machines Corporation | Dynamically Rewriting Branch Instructions in Response to Cache Line Eviction |
US9626279B2 (en) | 2013-07-01 | 2017-04-18 | Nxp Usa, Inc. | Debug method and device for providing indexed trace messages |
US9626280B2 (en) * | 2013-07-01 | 2017-04-18 | Nxp Usa, Inc. | Debug method and device for handling exceptions and interrupts |
US10402200B2 (en) | 2015-06-26 | 2019-09-03 | Samsung Electronics Co., Ltd. | High performance zero bubble conditional branch prediction using micro branch target buffer |
Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4370711A (en) * | 1980-10-21 | 1983-01-25 | Control Data Corporation | Branch predictor using random access memory |
US4611281A (en) * | 1983-05-24 | 1986-09-09 | Iwatsu Electric Co., Ltd. | Apparatus for analyzing microprocessor operation |
US4704679A (en) * | 1985-06-11 | 1987-11-03 | Burroughs Corporation | Addressing environment storage for accessing a stack-oriented memory |
US5146586A (en) * | 1989-02-17 | 1992-09-08 | Nec Corporation | Arrangement for storing an execution history in an information processing unit |
US5446876A (en) * | 1994-04-15 | 1995-08-29 | International Business Machines Corporation | Hardware mechanism for instruction/data address tracing |
US5557786A (en) * | 1994-01-24 | 1996-09-17 | Advanced Computer Applications, Inc. | Threaded, height-balanced binary tree data structure |
US5668969A (en) * | 1993-09-20 | 1997-09-16 | Apple Computer, Inc. | Address selective emulation routine pointer address mapping system |
US5721893A (en) * | 1996-05-14 | 1998-02-24 | Hewlett-Packard Company | Exploiting untagged branch prediction cache by relocating branches |
US5901318A (en) * | 1996-05-06 | 1999-05-04 | Hewlett-Packard Company | Method and system for optimizing code |
US5909578A (en) * | 1996-09-30 | 1999-06-01 | Hewlett-Packard Company | Use of dynamic translation to burst profile computer applications |
US5950009A (en) * | 1997-03-10 | 1999-09-07 | International Business Machines Coporation | Method and apparatus for profile-based reordering of program portions in a computer program |
US6006033A (en) * | 1994-08-15 | 1999-12-21 | International Business Machines Corporation | Method and system for reordering the instructions of a computer program to optimize its execution |
US6009270A (en) * | 1997-04-08 | 1999-12-28 | Advanced Micro Devices, Inc. | Trace synchronization in a processor |
US6029004A (en) * | 1997-03-17 | 2000-02-22 | International Business Machines Corporation | Method and apparatus for modular reordering of portions of a computer program based on profile data |
US6031992A (en) * | 1996-07-05 | 2000-02-29 | Transmeta Corporation | Combining hardware and software to provide an improved microprocessor |
US6061776A (en) * | 1997-06-27 | 2000-05-09 | Wisconsin Alumni Research Foundation | Multiple processor, distributed memory computer with out-of-order processing |
US6085186A (en) * | 1996-09-20 | 2000-07-04 | Netbot, Inc. | Method and system using information written in a wrapper description language to execute query on a network |
US6092180A (en) * | 1997-11-26 | 2000-07-18 | Digital Equipment Corporation | Method for measuring latencies by randomly selected sampling of the instructions while the instruction are executed |
US6115809A (en) * | 1998-04-30 | 2000-09-05 | Hewlett-Packard Company | Compiling strong and weak branching behavior instruction blocks to separate caches for dynamic and static prediction |
US6205545B1 (en) * | 1998-04-30 | 2001-03-20 | Hewlett-Packard Company | Method and apparatus for using static branch predictions hints with dynamically translated code traces to improve performance |
US6233678B1 (en) * | 1998-11-05 | 2001-05-15 | Hewlett-Packard Company | Method and apparatus for profiling of non-instrumented programs and dynamic processing of profile data |
US6351844B1 (en) * | 1998-11-05 | 2002-02-26 | Hewlett-Packard Company | Method for selecting active code traces for translation in a caching dynamic translator |
-
1999
- 1999-02-18 US US09/252,170 patent/US6453411B1/en not_active Expired - Fee Related
-
2002
- 2002-08-15 US US10/222,014 patent/US20030005271A1/en not_active Abandoned
Patent Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4370711A (en) * | 1980-10-21 | 1983-01-25 | Control Data Corporation | Branch predictor using random access memory |
US4611281A (en) * | 1983-05-24 | 1986-09-09 | Iwatsu Electric Co., Ltd. | Apparatus for analyzing microprocessor operation |
US4704679A (en) * | 1985-06-11 | 1987-11-03 | Burroughs Corporation | Addressing environment storage for accessing a stack-oriented memory |
US5146586A (en) * | 1989-02-17 | 1992-09-08 | Nec Corporation | Arrangement for storing an execution history in an information processing unit |
US5668969A (en) * | 1993-09-20 | 1997-09-16 | Apple Computer, Inc. | Address selective emulation routine pointer address mapping system |
US5557786A (en) * | 1994-01-24 | 1996-09-17 | Advanced Computer Applications, Inc. | Threaded, height-balanced binary tree data structure |
US5446876A (en) * | 1994-04-15 | 1995-08-29 | International Business Machines Corporation | Hardware mechanism for instruction/data address tracing |
US6006033A (en) * | 1994-08-15 | 1999-12-21 | International Business Machines Corporation | Method and system for reordering the instructions of a computer program to optimize its execution |
US5901318A (en) * | 1996-05-06 | 1999-05-04 | Hewlett-Packard Company | Method and system for optimizing code |
US5721893A (en) * | 1996-05-14 | 1998-02-24 | Hewlett-Packard Company | Exploiting untagged branch prediction cache by relocating branches |
US6031992A (en) * | 1996-07-05 | 2000-02-29 | Transmeta Corporation | Combining hardware and software to provide an improved microprocessor |
US6085186A (en) * | 1996-09-20 | 2000-07-04 | Netbot, Inc. | Method and system using information written in a wrapper description language to execute query on a network |
US5909578A (en) * | 1996-09-30 | 1999-06-01 | Hewlett-Packard Company | Use of dynamic translation to burst profile computer applications |
US5950009A (en) * | 1997-03-10 | 1999-09-07 | International Business Machines Coporation | Method and apparatus for profile-based reordering of program portions in a computer program |
US6029004A (en) * | 1997-03-17 | 2000-02-22 | International Business Machines Corporation | Method and apparatus for modular reordering of portions of a computer program based on profile data |
US6009270A (en) * | 1997-04-08 | 1999-12-28 | Advanced Micro Devices, Inc. | Trace synchronization in a processor |
US6061776A (en) * | 1997-06-27 | 2000-05-09 | Wisconsin Alumni Research Foundation | Multiple processor, distributed memory computer with out-of-order processing |
US6092180A (en) * | 1997-11-26 | 2000-07-18 | Digital Equipment Corporation | Method for measuring latencies by randomly selected sampling of the instructions while the instruction are executed |
US6115809A (en) * | 1998-04-30 | 2000-09-05 | Hewlett-Packard Company | Compiling strong and weak branching behavior instruction blocks to separate caches for dynamic and static prediction |
US6205545B1 (en) * | 1998-04-30 | 2001-03-20 | Hewlett-Packard Company | Method and apparatus for using static branch predictions hints with dynamically translated code traces to improve performance |
US6233678B1 (en) * | 1998-11-05 | 2001-05-15 | Hewlett-Packard Company | Method and apparatus for profiling of non-instrumented programs and dynamic processing of profile data |
US6351844B1 (en) * | 1998-11-05 | 2002-02-26 | Hewlett-Packard Company | Method for selecting active code traces for translation in a caching dynamic translator |
Cited By (40)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7346758B1 (en) * | 2005-05-10 | 2008-03-18 | Advanced Micro Devices, Inc. | System and method for trace messaging |
US8032710B1 (en) | 2005-09-28 | 2011-10-04 | Oracle America, Inc. | System and method for ensuring coherency in trace execution |
US7953933B1 (en) | 2005-09-28 | 2011-05-31 | Oracle America, Inc. | Instruction cache, decoder circuit, basic block cache circuit and multi-block cache circuit |
US7783863B1 (en) * | 2005-09-28 | 2010-08-24 | Oracle America, Inc. | Graceful degradation in a trace-based processor |
US8051247B1 (en) | 2005-09-28 | 2011-11-01 | Oracle America, Inc. | Trace based deallocation of entries in a versioning cache circuit |
US7849292B1 (en) | 2005-09-28 | 2010-12-07 | Oracle America, Inc. | Flag optimization of a trace |
US7870369B1 (en) * | 2005-09-28 | 2011-01-11 | Oracle America, Inc. | Abort prioritization in a trace-based processor |
US7877630B1 (en) | 2005-09-28 | 2011-01-25 | Oracle America, Inc. | Trace based rollback of a speculatively updated cache |
US7937564B1 (en) | 2005-09-28 | 2011-05-03 | Oracle America, Inc. | Emit vector optimization of a trace |
US7941607B1 (en) | 2005-09-28 | 2011-05-10 | Oracle America, Inc. | Method and system for promoting traces in an instruction processing circuit |
US7949854B1 (en) | 2005-09-28 | 2011-05-24 | Oracle America, Inc. | Trace unit with a trace builder |
US7953961B1 (en) | 2005-09-28 | 2011-05-31 | Oracle America, Inc. | Trace unit with an op path from a decoder (bypass mode) and from a basic-block builder |
US8370576B1 (en) | 2005-09-28 | 2013-02-05 | Oracle America, Inc. | Cache rollback acceleration via a bank based versioning cache ciruit |
US7966479B1 (en) | 2005-09-28 | 2011-06-21 | Oracle America, Inc. | Concurrent vs. low power branch prediction |
US8037285B1 (en) | 2005-09-28 | 2011-10-11 | Oracle America, Inc. | Trace unit |
US7987342B1 (en) | 2005-09-28 | 2011-07-26 | Oracle America, Inc. | Trace unit with a decoder, a basic-block cache, a multi-block cache, and sequencer |
US8499293B1 (en) | 2005-09-28 | 2013-07-30 | Oracle America, Inc. | Symbolic renaming optimization of a trace |
US8015359B1 (en) | 2005-09-28 | 2011-09-06 | Oracle America, Inc. | Method and system for utilizing a common structure for trace verification and maintaining coherency in an instruction processing circuit |
US8019944B1 (en) | 2005-09-28 | 2011-09-13 | Oracle America, Inc. | Checking for a memory ordering violation after a speculative cache write |
US8024522B1 (en) | 2005-09-28 | 2011-09-20 | Oracle America, Inc. | Memory ordering queue/versioning cache circuit |
US7797517B1 (en) | 2005-11-18 | 2010-09-14 | Oracle America, Inc. | Trace optimization via fusing operations of a target architecture operation set |
US7444499B2 (en) * | 2006-03-28 | 2008-10-28 | Sun Microsystems, Inc. | Method and system for trace generation using memory index hashing |
US20070234016A1 (en) * | 2006-03-28 | 2007-10-04 | Sun Microsystems, Inc. | Method and system for trace generation using memory index hashing |
US8010745B1 (en) | 2006-09-27 | 2011-08-30 | Oracle America, Inc. | Rolling back a speculative update of a non-modifiable cache line |
US8370609B1 (en) | 2006-09-27 | 2013-02-05 | Oracle America, Inc. | Data cache rollbacks for failed speculative traces with memory operations |
US8484517B2 (en) * | 2009-12-03 | 2013-07-09 | Infineon Technologies Ag | High compression program flow trace |
US20110138231A1 (en) * | 2009-12-03 | 2011-06-09 | Infineon Technologies Ag | High compression program flow trace |
US20130091331A1 (en) * | 2011-10-11 | 2013-04-11 | Iulian Moraru | Methods, apparatus, and articles of manufacture to manage memory |
US9043773B2 (en) * | 2013-03-15 | 2015-05-26 | Intel Corporation | Identification and management of unsafe optimizations |
US20140282451A1 (en) * | 2013-03-15 | 2014-09-18 | Alejandro M. Vicente | Identification and management of unsafe optimizations |
US9442729B2 (en) * | 2013-05-09 | 2016-09-13 | Intel Corporation | Minimizing bandwidth to track return targets by an instruction tracing system |
US20140337604A1 (en) * | 2013-05-09 | 2014-11-13 | Beeman C. Strong | Minimizing bandwidth to track return targets by an instruction tracing system |
US20150113251A1 (en) * | 2013-10-18 | 2015-04-23 | Marvell World Trade Ltd. | Systems and Methods for Register Allocation |
WO2015056098A3 (en) * | 2013-10-18 | 2015-08-13 | Marvell World Trade Ltd. | Systems and methods for register allocation |
US9690584B2 (en) * | 2013-10-18 | 2017-06-27 | Marvell World Trade Ltd. | Systems and methods for register allocation |
CN104407968A (en) * | 2014-10-30 | 2015-03-11 | 北京控制工程研究所 | Method for measuring and calculating longest operation time of code instructions through static analysis |
US20160357658A1 (en) * | 2015-06-05 | 2016-12-08 | Intel Corporation | Implementation Of Processor Trace In A Processor That Supports Binary Translation |
US9934124B2 (en) * | 2015-06-05 | 2018-04-03 | Intel Corporation | Implementation of processor trace in a processor that supports binary translation |
US20170024266A1 (en) * | 2015-07-20 | 2017-01-26 | Kabushiki Kaisha Toshiba | Memory system, information processing system, and host device |
US10089212B2 (en) * | 2015-07-20 | 2018-10-02 | Toshiba Memory Corporation | Memory system, information processing system, and host device outputting debugging information through a host interface |
Also Published As
Publication number | Publication date |
---|---|
US6453411B1 (en) | 2002-09-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6453411B1 (en) | System and method using a hardware embedded run-time optimizer | |
US6647491B2 (en) | Hardware/software system for profiling instructions and selecting a trace using branch history information for branch predictions | |
US6233678B1 (en) | Method and apparatus for profiling of non-instrumented programs and dynamic processing of profile data | |
US5530964A (en) | Optimizing assembled code for execution using execution statistics collection, without inserting instructions in the code and reorganizing the code based on the statistics collected | |
Gal et al. | HotpathVM: An effective JIT compiler for resource-constrained devices | |
JP3808755B2 (en) | Virtual machine with JIT compiler | |
KR100578583B1 (en) | Method of changing modes of code generation | |
Bala et al. | Transparent dynamic optimization: The design and implementation of Dynamo | |
US20020066081A1 (en) | Speculative caching scheme for fast emulation through statically predicted execution traces in a caching dynamic translator | |
US6470492B2 (en) | Low overhead speculative selection of hot traces in a caching dynamic translator | |
US5966537A (en) | Method and apparatus for dynamically optimizing an executable computer program using input data | |
US6351844B1 (en) | Method for selecting active code traces for translation in a caching dynamic translator | |
US6295644B1 (en) | Method and apparatus for patching program text to improve performance of applications | |
US6122638A (en) | Object-oriented processor and method for caching intermediate data in an object-oriented processor | |
US20050154867A1 (en) | Autonomic method and apparatus for counting branch instructions to improve branch predictions | |
US7725885B1 (en) | Method and apparatus for trace based adaptive run time compiler | |
Zhang et al. | An event-driven multithreaded dynamic optimization framework | |
US6430675B1 (en) | Hardware system for fetching mapped branch target instructions of optimized code placed into a trace memory | |
JP2000040007A (en) | Code generation for bytecode compiler | |
US6785801B2 (en) | Secondary trace build from a cache of translations in a caching dynamic translator | |
US6314431B1 (en) | Method, system, and apparatus to improve instruction pre-fetching on computer systems | |
US20030084271A1 (en) | Speculative execution for java hardware accelerator | |
US7739672B2 (en) | Information processor, information processing method, and programs therefor | |
KR20120064446A (en) | Appratus and method for processing branch of bytecode on computing system | |
WO2001013223A1 (en) | Method and apparatus for operating virtual computer |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., COLORAD Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928 Effective date: 20030131 Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.,COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928 Effective date: 20030131 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |