Hybrid atomicity support for binary translation-based microprocessors

Abstract

Hybrid atomicity support for binary translation based microprocessors. A processing device comprising a first shadow register, a second shadow register, and an instruction execution circuit communicatively coupled to the first shadow register and the second shadow register to receive a sequence of instructions comprising a first local commit marker, a first global commit marker, and a first register access instruction referencing an architectural register, speculatively execute the first register access instruction to generate a speculated register state value associated with a physical register, responsive to identifying the first local commit marker, store the speculated register state value in the first shadow register and responsive to identifying the first global commit marker, store the speculated register state value in the second shadow register.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to microprocessors, and more particularly, but not by way of limitation, to hybrid atomicity support for binary translation-based (BT-based) microprocessors. Background Art

[0002] Multi-core processors are found in most computing systems today, including servers, desktop computers, and systems-on-chip (SoCs). Computer systems utilizing these multi-core processors can execute instructions from various types of code. Often, the code is not designed for a specific processor and, therefore, needs to be translated into target code. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be more fully understood from the detailed description given below and from the accompanying drawings of various embodiments of the present disclosure. However, the accompanying drawings should not be considered to limit the present disclosure to the specific embodiments, but are only for explanation and understanding.

[0004] Figure 1 A processing system according to an embodiment of the present disclosure is illustrated.

[0005] Figure 2 A code example including code generated by a binary translator according to an embodiment of the present disclosure is illustrated.

[0006] Figure 3A An example of hybrid atomicity including a global commit mode and a local commit mode according to an embodiment of the present disclosure is illustrated.

[0007] Figure 3B An example of rollback according to an embodiment of the present disclosure is illustrated.

[0008] Figure 4 is a block diagram of a method 400 for executing BT code according to an embodiment of the present disclosure.

[0009] Figure 5A is a block diagram illustrating a microarchitecture for a processor including heterogeneous cores in which one embodiment of the present disclosure may be used.

[0010] Figure 5B is a block diagram illustrating an in-order pipeline and a register renaming stage, an out-of-order issue / execution pipeline implemented according to at least one embodiment of the present disclosure.

[0011] Figure 6 A block diagram of a microarchitecture of a processor including logic according to one embodiment of the present disclosure is illustrated.

[0012] Figure 7 is a block diagram illustrating a system in which embodiments of the present disclosure may be employed.

[0013] Figure 8 is a block diagram of a system in which embodiments of the present disclosure may operate.

[0014] Figure 9 is a block diagram of a system in which embodiments of the present disclosure may operate.

[0015] Figure 10 is a block diagram of a system on a chip (SoC) according to an embodiment of the present disclosure.

[0016] Figure 11 is a block diagram of an embodiment of a SoC design according to the present disclosure.

[0017] Figure 12 A block diagram of one embodiment of a computer system is illustrated. DETAILED DESCRIPTION

[0018] Some multi-core processors may include a binary translator that generates target code that can be executed on a target platform. Certain optimization techniques may be used to optimize the translated code. Optimization may include reordering of instructions. Therefore, the optimized group of instructions should be executed atomically. Atomicity can ensure consistency of results between out-of-order execution (i.e., execution of the reordered group of instructions) and in-order execution (i.e., execution of the original group of instructions). In some computer systems, effective optimization techniques can improve performance and reduce power consumption. During runtime, the binary translator can reorder the placement of instructions in the code. In some systems, memory access instructions (instructions that modify memory locations) or register access instructions (instructions that modify physical registers) can be executed in an order different from the order in which the instructions were fetched and decoded (referred to as out-of-order execution). For example, according to a specific optimization process, the binary translator can reorder the execution of certain memory access instructions. In such systems, these techniques for reordering memory (or register) access instructions are shown to be an effective mechanism for improving the performance of microprocessors that support out-of-order (OoO) instruction execution.

[0019] A microprocessor (referred to herein as a processor) may rely on hardware mechanisms (e.g., hardware transactional memory) to support the atomicity required in OoO execution of instructions. The processor may execute instructions that access data directed to a storage device (e.g., registers or memory). The atomicity of a transaction, which includes the execution of two or more instructions, ensures that the transaction completes or has no effect on the storage device (i.e., an aborted transaction does not change the contents of the storage device). To achieve atomicity in the execution of the set of instructions associated with a transaction, the system may need to create a checkpoint that captures the starting state of the system (including memory state values ​​and register state values). When the state of the microprocessor is once known to be correct (non-speculative), the register and memory state values ​​may define the correct data values ​​for the corresponding registers and memory locations. In response to detecting a rollback event occurring during a transaction, the system may roll back to the checkpoint. Rollback ensures that a failed transaction does not affect the state values ​​of the system. The processor may be configured with a transactional memory to track the internal state of the processor, where the internal state may include memory state values ​​and register state values ​​that can be used for rollback. In some implementations to improve the speed of execution, the processor may implement a hardware transactional memory that includes logic circuitry to track which cache lines are associated with read or write instructions. Hardware transactional memory implemented on a processor, while providing reliable and built-in atomicity that guarantees sequential consistency in the final result, may incur a significant overhead in processor performance, particularly for BT-based processors as explained in the following section.

[0020] Processors designed to execute reordered binary translation (BT) instructions may need to frequently be in atomic transaction mode through back-to-back transactions. These processors are called BT-based processors. BT-based processors perform speculative optimizations for power and performance gains. If the speculative execution of code does not provide the correct result, the BT-based processor rolls back to the correct state. Code may include region boundaries that define points in execution at which the processor state (memory and registers) is correct and can be made visible to the outside world (other processors). The execution of instructions between those boundaries (i.e., speculative execution) should appear atomic to the outside world. Therefore, BT-based processors need to always be in an atomic state. BT-based processors can use existing hardware transactional memory for this purpose, but this incurs high performance overhead that may negate the performance gains achieved through binary translation optimization. For such situations, BT-based processors can adopt lightweight atomic mechanisms (rather than heavyweight hardware transactional memory) to reduce the overhead associated with transactions, where heavyweight means large processor overhead and lightweight means small processor overhead. In some implementations, a BT-based processor may use a buffer that is not part of the data cache but is communicatively coupled to the data cache to temporarily hold memory store instructions prior to an atomic commit to the data cache. Thus, due to the high overhead associated with hardware transactional memory, implementations of BT-based processors typically do not support heavyweight hardware transactional memory. However, hardware transactional memory may be useful for BT-based processors because hardware transactional memory can accommodate a large number of load / store operations and can be used to optimize code execution in certain situations (e.g., loop optimizations using loop invariant code motion (LICM), load hoisting, load elimination, etc.). Additionally, BT-based processors may need to provide backward compatibility to support hardware transactional memory.

[0021] Embodiments of the present disclosure may include a processor architecture that supports two types of commit modes (global commit mode and local commit mode) for speculatively executed instructions, where the instructions can modify at least one of a memory location or a physical register. Code (e.g., code generated by a binary translator) may include a local commit marker that identifies a portion of the code that will be speculatively executed and then committed under the local commit mode supported by the processor architecture, where the local commit marker can be inserted by a code developer or compiler. The code may further include a global commit marker that identifies another portion of the code that will be speculatively executed and then committed under the global commit mode also supported by the processor architecture, where the global commit marker can be inserted by a binary translator. The global commit code region can utilize transactional memory (or cache-based atomicity), while the local commit code region suffers from delayed reclamation of the store / load buffer.

[0022] The processor architecture of the present disclosure can support both local commit mode and global commit mode in code. For instructions that modify memory locations, the processor can support delayed instruction retrieval by storing speculative memory state values ​​in a buffer under local commit mode. This delays instruction retrieval compared to retrieval without atomicity. Storing in the buffer can delay commit to transactional memory until a global commit event occurs. For instructions that reference physical registers, the processor can store speculative register state values ​​in a first set of shadow registers associated with local commit mode and store speculative register state values ​​in a second set of shadow registers associated with global commit mode. In response to a local commit event, the contents of the first shadow register can be copied to an architectural register, while in response to a global commit event, the contents of the second shadow register can be copied to an architectural register (detailed description provided in conjunction with FIG3 ). An architectural register is a logical register designated as an operand of an instruction to store a result value. The processor can implement register renaming to dynamically map logical registers to physical registers in a physical register file using a register alias table (RAT). Therefore, the present disclosure provides a technical solution that supports two types of commit specified in optimized code reordered by a binary translator.

[0023] Figure 1 FIGURE 1 illustrates a processing system 100 according to an embodiment of the present disclosure. Figure 1, a processing system 100 (e.g., a system on a chip (SOC) or a motherboard of a computer system) may include a processor 102 and a memory device 104 communicatively coupled to the processor 102. The processor 102 may be a hardware processing device such as, for example, a central processing unit (CPU) or a graphics processing unit (GPU) that includes one or more processing cores for executing software applications.

[0024] The processor 102 may further include a processing core 106 and a level 2 (L2) cache shared with another processing core similar to the processing core 106. The processing core 106 may, in various implementations, have an in-order core or out-of-order execution capability for instructions. In an illustrative example, the processing core 106 may have a microarchitecture that includes processor logic and circuitry for implementing an instruction set architecture (ISA). Processors 102 having different microarchitectures may share at least a portion of a common instruction set. For example, the same register architecture of the ISA may be implemented differently in different microarchitectures using various techniques, including dedicated physical registers, one or more dynamically allocated physical registers using a register renaming mechanism (e.g., register alias table (RAT), reorder buffer (ROB), and use of a retirement register file), such as in conjunction with Figures 5A-5B As shown in the figure. During the execution of instructions that reference registers, dynamically allocated registers can be used to hold data values. Data values ​​can be overwritten until they are moved to architectural registers (i.e., those registers visible to the programmer. When the code reads the contents of the architectural registers, the contents of the architectural registers need to be correct).

[0025] refer to Figure 1 The processing core 106 may further include an instruction cache 108, a front-end circuit 110, an execution circuit 112, an instruction retirement circuit 114, a register file 116, an instruction delay eviction circuit 118 (including a load / store buffer 120), a level 1 (L1) data cache 124, a first shadow register set 126, and a second shadow register set 128. The processing core 106 may optionally include a binary translator 140 for reordering instructions into target code that can be speculatively executed in an OoO manner. In one embodiment, the binary translator 140 may be implemented in logic circuitry as a hardware component of the processing core 106. In another embodiment, the binary translator 140 may be implemented as a software application running on the processing core 106.

[0026] The instruction cache circuit 108 can be coupled to an instruction fetch circuit (not shown). The instruction cache circuit 108 can receive and store instructions retrieved by the instruction fetch circuit. In one embodiment, a binary translator 140 can receive a sequence of instructions from the instruction cache circuit 108 and perform code optimization to generate a target code by reordering the instructions in the code. After the code optimization of the binary translator 140, the target code can include a local commit tag that identifies the portion of the code to be executed under the local commit mode and a global commit tag that identifies the portion of the code to be executed under the global commit mode. The local commit tag can be inserted by the binary translator 140. Alternatively, the global commit tag can be inserted by the application developer.

[0027] Figure 2 A code example 200 including code 204 generated by a binary translator according to an embodiment of the present disclosure is illustrated. Original code 202 (e.g., x86 instruction code) may include a ring 206 that includes a number of instructions. Binary translator 140 may generate target code 204 based on code 202. In target code 204, binary translator 140 may use a local commit marker (e.g., CMIT.LOCAL) to specify portions of the code that are in local commit mode, and a global commit marker (e.g., CMIT.GLOBAL) to specify portions of the code that are in global commit mode. For example, code 204 may run in local commit mode within ring 206 and in global commit mode outside ring 206.

[0028] refer to Figure 1 , the front-end circuit 110 may receive the target code 204 generated by the binary translator 140 to perform pre-processing before execution. In one embodiment, the front-end circuit 110 may include an instruction decoder circuit that may translate an instruction into an address in the micro memory where the micro code for the instruction begins. The front-end circuit 110 may feed the instruction to the instruction execution circuit 112 for speculative execution.

[0029] Processing core 106 may include logic circuitry to support both local commit mode and global commit mode specified in the target code. Processing core 106 may provide different hardware components to handle instructions that reference memory locations in memory 104 (referred to as memory access instructions) and instructions that reference physical registers of register file 116 (referred to as register access instructions).

[0030] In this regard, the processing core 106 may include a register file 116 that may include physical registers that may be referenced by register access instructions. Prior to a commit event, these physical registers may be renamed and / or overwritten. The processing core 112 may further include shadow register sets 126, 128 coupled to the register file 116 to maintain copies of the contents of the register file 116. In some implementations, the shadow register sets may maintain both speculative and non-speculative copies of each physical register in the register file 116. Subsequent execution of register access instructions may cause the contents of the physical registers to be rewritten, causing the speculative copies in the corresponding shadow registers to be updated. A commit event (e.g., identification of a "COMMIT.GLOBAL" flag or a "COMMIT.LOCAL" flag by the instruction execution circuitry 112) may trigger the conversion of all speculative copies in the register file 116 to non-speculative copies.

[0031] In one embodiment, to improve efficiency, the shadow register sets 126 and 128 may be implemented as a copy-on-write (CoW) structure that maintains a first-in, first-out (FIFO) mapping between physical registers and architectural registers. Physical registers referenced by register access instructions during execution are referred to as "live" physical registers. In response to a first rewrite of a "live" physical register, the shadow register sets 126 and 128 may maintain a shadow copy. However, this rewrite does not cause the instruction retirement circuitry 114 to reclaim the physical register for use in other register access instructions. The shadow register sets 126 and 128 do not maintain the contents of the live physical registers for subsequent rewrites because they do not represent rollback state values ​​for atomic transactions. In response to retirement of a global or local commit event (e.g., by identifying a subsequent global or local commit marker), the live physical registers are reclaimed and their contents become non-speculative. Thus, the CoW shadow register sets 126 and 128 may eliminate the need for multiple copy operations from physical registers to the shadow register sets 126 and 128 in response to frequent rewrites.

[0032] In one embodiment, shadow register set 126 is associated with a local commit mode, and shadow register set 128 is associated with a global commit mode. Shadow register set 126 can maintain the original contents of the real physical registers in the local commit mode, and shadow register set 128 can maintain the original contents of the real physical registers in the global commit mode. In response to a local commit event, instruction retirement circuitry 114 can reclaim the real physical registers in the local commit mode. In response to a global commit event, instruction retirement circuitry 114 can reclaim the real physical registers in the global commit mode.

[0033] The processing core 106 may further include a level 1 (L1) data cache 124, which may include an implementation of a transactional memory 132. As discussed above, the transactional memory 132 may provide atomicity for memory transactions via memory access instructions that reference memory locations. The transactional memory 132 may include logic for tracking memory state values ​​that may be used for rollback. In one embodiment, the transactional memory may track read or write instructions associated with a cache line. The transactional memory 132 may include a cache line for storing a copy of the contents associated with a memory location. The copy is referred to as the memory state value at the memory location. In one embodiment, the cache line may further include a state flag for indicating whether the cache is speculative. For example, the state flag may be set (to "1") to indicate a speculative state and cleared (to "0") to indicate a non-speculative state. In one embodiment, the speculative state is indicated using a read (RD) bit and / or a write (WR) bit of the cache line. When set, the RD bit may indicate that the cache line is associated with a read instruction, and when set, the WR bit may indicate that the cache line is associated with a write instruction.

[0034] In one embodiment, under global commit mode, speculative memory state values ​​associated with memory locations are maintained in cache lines.In response to a commit event, all speculative cache lines are set to non-speculative (e.g., by clearing the speculative state bit).

[0035] To improve performance in partial commit mode, processing core 106 may include delayed eviction circuitry 118 to temporarily hold memory state values ​​that may later be copied to transactional memory 132. In one embodiment, delayed eviction circuitry 118 may include a load / store buffer 120. In response to identifying a local commit marker (e.g., COMMIT.LOCAL), instruction execution circuitry 112 may first create a local checkpoint captured in response to identifying the local commit marker. Furthermore, instruction execution circuitry 112 may speculatively execute memory access instructions that modify memory locations. In partial commit mode, instruction execution circuitry 112 may store speculative memory state values ​​in load / store buffer 120 in response to speculatively executing memory access instructions. In response to execution of another memory access instruction that modifies a memory location, instruction execution circuitry 112 may modify the speculative memory state values ​​stored in load / store buffer 120 to new values. In response to a commit event (e.g., identification of a second partial commit marker), instruction execution circuitry 112 may move the speculative memory state values ​​from load / store buffer 120 to transactional memory 130 as a cache line. Here, a commit event (eg, identifying a local commit marker) serves as a conclusion of a previous local commit mode and the beginning of a new local commit mode.The speculative state of a cache line may be set to a speculative state (set to "1").

[0036] In the following, hybrid atomicity support is discussed in terms of global commit mode and local commit mode.

[0037] Embodiments of the present disclosure may provide different components and methods for processing speculatively executed memory access instructions and speculatively executed register access instructions under global commit mode. The instruction execution circuit 112 may receive a global commit flag (e.g., as in Figure 2 COMMIT.GLOBAL) shown in . The sequence of instructions may have been generated by the binary translator 140 with code optimization. Therefore, the execution of the sequence of instructions may include OoO speculative execution. In response to identifying the global commit marker, the instruction execution circuit 112 may first create a global checkpoint (a reference to a memory location storing retained memory state values ​​and register state values) to which the processing core 106 may roll back in the event of a global rollback event. A global rollback event occurs when a processor failure causes the processor to roll back to the state value referenced by the global checkpoint. For the sake of simplicity of discussion, Figures 3A-3B Creation of global checkpoints and detection of global rollback events are provided. In addition, in response to identifying the global commit marker, the instruction execution circuitry 112 may begin speculatively executing instructions under a global commit mode.

[0038] In the global commit mode, the instruction execution circuitry 112 may identify a memory access instruction (e.g., an instruction that modifies a memory location) and speculatively execute the memory access instruction. Execution of the memory access instruction may cause the cache controller to generate a cache line entry in the transactional memory 132 of the data cache 124 and store a copy of the memory state value in the cache line. In one embodiment, the instruction execution circuitry 112 may also set a speculation bit to a "speculative" state, wherein the speculation bit may be an RD / WT bit indicating that the cache line has been accessed by the memory access instruction.

[0039] The instruction execution circuitry 112 may further identify register access instructions (e.g., instructions that modify physical registers) and speculatively execute the register access instructions. During execution of the instructions, the instruction execution circuitry 112 may store the speculative register values ​​in the global shadow registers 128, where the global shadow registers are implemented as a CoW structure. In response to a global commit event, the speculative register values ​​in the global shadow registers 128 are copied to the physical registers.

[0040] In response to a global commit event (e.g., identifying the second global commit flag), the instruction execution circuitry 112 may cause the cache controller to clear the speculative bits in the cache line of the transactional memory 132. The instruction execution circuitry 112 may copy the speculative register value from the global shadow register 128 to an architectural register operand (indicating a physical register) of the register access instruction.

[0041] Embodiments of the present disclosure may provide different components and methods for processing speculatively executed memory access instructions and speculatively executed register access instructions under local commit mode. The instruction execution circuit 112 may receive a local commit flag (e.g., as in Figure 2 The sequence of COMMIT.LOCAL) instructions shown in .

[0042] Figure 2A code example 200 including code 204 generated by a binary translator according to an embodiment of the present disclosure is illustrated. Original code 202 (e.g., x86 instruction code) may include a ring 206 that includes a number of instructions. Binary translator 140 may generate target code 204 based on code 202. In target code 204, binary translator 140 may use a local commit marker (e.g., CMIT.LOCAL) to specify portions of the code that are in local commit mode, and a global commit marker (e.g., CMIT.GLOBAL) to specify portions of the code that are in global commit mode. For example, code 204 may run in local commit mode within ring 206 and in global commit mode outside ring 206.

[0043] The sequence of instructions may have been generated using code optimization by binary translator 140. Therefore, execution of the sequence of instructions may include OoO speculative execution. In response to identifying the local commit marker, instruction execution circuitry 112 may first create a local checkpoint to which processing core 106 may roll back in the event of a local rollback event. Furthermore, in response to identifying the local commit marker, instruction execution circuitry 112 may begin speculatively executing instructions in a local commit mode.

[0044] In partial commit mode, instruction execution circuitry 112 may identify memory access instructions (e.g., instructions that modify memory locations) and speculatively execute the memory access instructions. Execution of the memory access instructions may cause instruction execution circuitry 112 to store a copy of the memory state value in load / store buffer 120.

[0045] The instruction execution circuitry 112 may further identify register access instructions (e.g., instructions that modify physical registers) and speculatively execute the register access instructions. During execution of the register access instructions, the instruction execution circuitry 112 may store the speculative register values ​​in the local shadow registers 126, which may be implemented as a CoW structure. Subsequent execution of the register access instructions may modify the physical registers while the local shadow registers 126 retain the rollback register state values.

[0046] In response to a local commit event (e.g., a second local commit marker), the instruction execution circuitry 112 may move the contents of the load / store buffer 120 to one or more cache lines of the transactional memory 132. If the local commit event is in an overarching global commit code region, the instruction execution circuitry 112 may set the speculation bit of the cache line to a speculative state. The instruction execution circuitry 112 may copy the speculative register value from the physical register to the architectural register referenced by the register access instruction.

[0047] Figure 3A An example of hybrid atomicity including a global commit mode and a local commit mode is illustrated in accordance with embodiments of the present disclosure. In this example, a portion of code executed in association with the local commit mode is located in a portion of code associated with the global commit mode. In other examples, a portion of code associated with the global commit mode can be located in a portion of code associated with the local commit mode. In such cases, a global commit event can force the local commit mode to be split into sub-portions. Reference is made to Figure 3A , the instruction execution circuit 112 can receive instructions to be executed in accordance with the sequence 300. Execution of these instructions can include OoO speculative execution of instructions that can require transactional atomicity. The sequence of instructions can have been generated by a binary translator using code optimization. The instructions can include global commit markers (e.g., COMMIT.GLOBAL), local commit markers (e.g., COMMIT.LOCAL), memory access instructions, and register access instructions as discussed above in connection with Figure 1

[0048] At 302, the instruction execution circuit 112 can identify a first global commit marker in the code. In response to identifying the first global commit marker, the instruction execution circuit 112 can create a first global checkpoint 310 by converting all speculative memory state values and speculative register state values to non-speculative as in the example below. For example, the instruction execution circuit 112 can clear the speculative bit of the cache line in the transactional memory 132 to convert the speculative memory state values to non-speculative and move the speculative register values stored in the physical registers to the target architectural registers. The first global checkpoint 310 can be used as a reference to a rollback from a later global rollback event to the state values reserved by the first global checkpoint 310. After creating the first global checkpoint 310, the instruction execution circuit 112 can begin executing instructions 312 under the global commit mode. The execution can include speculative execution of memory access instructions and register access instructions.

[0049] ​At 304, the instruction execution circuitry 112 may further identify a first local commit marker in the code. In response to identifying the first local commit marker, the instruction execution circuitry 112 may create a first local checkpoint 314 by converting the speculative memory state values ​​and speculative register state values ​​associated with the local commit mode to non-speculative values, as in the following example. For example, the instruction execution circuitry 112 may move the speculative memory state values ​​in the load / store buffer 120 to the transactional memory 132 (rather than directly to the transactional memory 132 as in the global commit mode) and move the physical registers in which the speculative register values ​​are stored to the target architectural registers. The speculative memory state values ​​may be stored in a cache line with the speculation bit set to the speculative state. The first local checkpoint 134 may serve as a rollback point for subsequent global rollback events. After creating the first local checkpoint 314, the instruction execution circuitry 112 may begin executing instructions 316 in the local commit mode. The execution may include speculative execution of memory access instructions and register access instructions.

[0050] Similarly, at 306, the instruction execution circuitry 112 may identify a second local commit marker and create a second local checkpoint 318. The second local checkpoint 318 may replace the first local checkpoint 314 as the rollback point for a local rollback event. The instruction execution circuitry 112 may then begin executing instructions 320 in the local commit mode.

[0051] At 308, the instruction execution circuitry 112 may further identify a second global commit marker and create a second global checkpoint 322. In one embodiment, the creation of the second global checkpoint 322 may include first copying speculative register state values ​​from the shadow register set 216 to corresponding architectural registers, and moving speculative memory state values ​​from the load / store buffer 120 to the transactional memory 132. The conversion of speculative state values ​​to non-speculative in the local commit mode is because speculative optimizations are not allowed across transactional memory boundaries.

[0052] Instruction execution circuit 112 can encounter global / local rollback events that can force the transaction to abort and roll back the state values of processing core 106 to the corresponding global / local checkpoints. Global rollback events can be global commit faults, including such as, for example, x86 level exceptions, interrupts, XABORTS, external cache snoop, Write-set cache line eviction, etc. When these global rollback events occur within the global commit code region, they cause global abort and global rollback. Local rollback events can be micro-architecture and BT specific events that cause local aborts (not x86 global level aborts). These local aborts are not visible at the x86 architecture level. Local rollback events can include such as, for example, BT specific memory speculation failures, BT specific interrupts / exceptions, etc. Depending on the type of fault that occurred, the hybrid atomicity enable rollback and recovery to precise local or global checkpoints as described in this disclosure. This capability helps further improve the performance of processing core 107 by reducing the overhead associated with enforcing transaction atomicity.

[0053] Figure 3B An example of rollback is illustrated in accordance with an embodiment of the present disclosure. Referring to Figure 3B , instruction execution circuit 112 can have created global checkpoints and local checkpoints as illustrated in Figure 3A . A local rollback event 324 can occur. In response to detecting local rollback event 324, instruction execution circuit 112 can roll back the state values of processing core 106 to the first local checkpoint. Because of the hybrid atomicity (two levels), instruction execution circuit 112 does not need to roll back the speculative memory state values in LI data cache 124 and the speculative register state values in global shadow register set 128 to the first global checkpoint 310, thus reducing the overhead associated with enforcing transaction atomicity. Local rollback event 324 can include retrieving the saved register state values from local shadow registers 126 and retrieving the memory state values from the locations referenced by the local checkpoint.

[0054] Similarly, a global rollback event 326 can occur. In response to detecting global rollback event 326, instruction execution circuit 112 can roll back the speculative register state values stored in global shadow registers 128 and the speculative memory state values stored in LI data cache 124 to the first global checkpoint.

[0055] Figure 4is a block diagram of a method 400 for executing BT code according to embodiments of the present disclosure. The method 400 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device, general purpose computer system, or a special purpose machine) firmware, or a combination thereof. In one embodiment, the method 400 can be partially performed by the processor 102 and the processing core 106, as shown in Figure 1

[0056] For simplicity of explanation, the method 400 is depicted and described as a series of acts. However, acts in accordance with this disclosure can occur in various orders and / or concurrently, and with other acts not presented and described herein. Furthermore, not all illustrated acts can be employed to implement the method 400 in accordance with the disclosed subject matter. In addition, those skilled in the art will understand and appreciate that the method 400 could alternatively be represented as a series of interrelated states via a state diagram or events.

[0057] Referring to Figure 4 At 402, the processing device can receive a sequence of instructions including a first local commit marker, a first global commit marker, a first memory access instruction associated with a memory location, and a first register access instruction referencing an architectural register.

[0058] At 404, the processing device can speculatively execute the first memory access instruction to generate a speculative memory state value associated with the memory location and speculatively execute the first register access instruction to generate a speculative register state value associated with the physical register.

[0059] At 406, the processing device can identify a transaction mode that can be determined based on active commit markers. The transaction mode can be "not in a transaction region" (i.e., not in a global commit code region nor in a local commit code region) or "in a global transaction region but not in a local transaction region" (i.e., in a global commit code region but not in a local commit code region) or "in a local transaction region" (i.e., not in a global commit code region but in a local commit code region) or "in both a global transaction region and a local transaction region" (i.e., in a local commit code region, which is within a global commit code region).

[0060] In response to identifying the local commit marker in the global transaction region and the local transaction region, at 408, the processing device can store the speculative memory state value in a buffer coupled to a data cache, and at 410, the processing device can store the speculative register state value in a first shadow register.

[0061] ​In response to identifying the global commit markers in the global transaction region and the local transaction region, the processing device may store speculative memory state values ​​in the transaction memory of the data cache at 412 and store speculative register state values ​​in the second shadow register at 414 .

[0062] Figure 5A 1 is a block diagram illustrating the microarchitecture of a processor 500 for implementing a processing device including heterogeneous cores according to one embodiment of the present disclosure. Specifically, the processor 500 depicts an in-order architecture core and register renaming logic and out-of-order issue / execution logic to be included in the processor according to at least one embodiment of the present disclosure.

[0063] The processor 500 includes a front end unit 530 coupled to an execution engine unit 550, and both are coupled to a memory unit 570. The processor 500 may include a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the processor 500 may include a specialized core, such as, for example, a network or communication core, a compression engine, a graphics core, or the like. In one embodiment, the processor 500 may be a multi-core processor or may be part of a multi-processor system.

[0064] The front end unit 530 includes a branch prediction unit 532 coupled to an instruction cache unit 534, which is coupled to an instruction translation lookaside buffer (TLB) 536. The instruction translation lookaside buffer (TLB) 536 is coupled to an instruction fetch unit 538, which is coupled to a decode unit 540. The decode unit 540 (also referred to as a decoder) can decode instructions and generate as output one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals that are decoded from the original instruction or otherwise reflect or are derived from the original instruction. The decoder 540 can be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read-only memories (ROM), and the like. The instruction cache unit 534 is further coupled to a memory unit 570. Decode unit 540 is coupled to rename / allocator unit 552 in execution engine unit 550 .

[0065] The execution engine unit 550 includes a rename / allocator unit 552 coupled to a retirement unit 554 and a set of one or more scheduler units 556. The scheduler unit(s) 556 represent any number of different schedulers, including reservation stations (RSs), a central instruction window, and the like. The scheduler unit(s) 556 are coupled to physical register file(s) 558. Each of the physical register file(s) 558 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating point, packed integer, packed floating point, vector integer, vector floating point, and the like, state (e.g., an instruction pointer, which is the address of the next instruction to be executed), and the like. The physical register file(s) 558 are overlaid by the retirement unit 554 to illustrate various ways in which register renaming and out-of-order execution can be implemented (e.g., using reorder buffer(s) and retirement register file(s); using future file(s), history file(s), and retirement register file(s); using a register map and a pool of registers; and the like).

[0066] In one implementation, the processor 500 may communicate with Figure 1 In particular, the processor 500 may include the processor 102 described in Figure 1 Processing core 106 is shown in FIG.

[0067] Typically, architectural registers are visible from outside the processor or from a programmer's perspective. Registers are not limited to any known specific type of circuit. Various different types of registers are suitable, as long as they are capable of storing and providing data as described herein. Examples of suitable registers include, but are not limited to, dedicated physical registers, dynamically allocated physical registers using register renaming, a combination of dedicated physical registers and dynamically allocated physical registers, and the like. The retirement unit 554 and the physical register file(s) 558 are coupled to the execution cluster(s) 560. The execution cluster(s) 560 include a set of one or more execution units 562 and a set of one or more memory access units 564. The execution units 562 can perform various operations (e.g., shifts, additions, subtractions, multiplications) and operate on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point).

[0068] While some embodiments may include multiple execution units dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. Scheduler unit(s) 556, physical register file(s) 558, and execution cluster(s) 560 are shown as potentially multiple because some embodiments create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipelines, and / or memory access pipelines each with their own scheduler unit(s), physical register file(s), and / or execution cluster(s), and in the case of separate memory access pipelines, some embodiments are implemented where only the execution cluster of that pipeline has memory access unit(s) 564. It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution and the rest in-order issue / execution.

[0069] Coupled to the memory unit 570 is a set of memory access units 564, which may include, to name a few, a data prefetcher 580, a data TLB unit 572, a data cache unit (DCU) 574, and a level 2 (L2) cache unit 576. In some embodiments, the DCU 574 is also referred to as a first-level data cache (L1 cache). The DCU 574 can handle multiple outstanding cache misses and continue to service incoming stores and loads. It also supports maintaining cache coherency. The data TLB unit 572 is a cache used to improve virtual address translation speed by mapping virtual and physical address spaces. In an exemplary embodiment, the memory access unit 564 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 572 in the memory unit 570. The L2 cache 576 may be coupled to one or more other levels of cache and ultimately to main memory.

[0070] In one embodiment, data prefetcher 580 speculatively loads / prefetches data to DCU 574 by automatically predicting that a program is about to consume that data. Prefetching can refer to transferring data stored in one memory location (e.g., a lower level cache or memory) of a memory hierarchy to a higher level memory location closer to (e.g., resulting in lower access latency for) a processor before the processor actually needs the data. More specifically, prefetching can refer to the early retrieval of data from one of the lower level caches / memory to the data cache and / or prefetch buffers before the processor issues a demand for the particular data being returned.

[0071] Processor 500 can support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technology, Inc. of Sunnyvale, CA; the ARM instruction set (with optional additional extensions such as NEON) of ARM Holdings of Sunnyvale, CA).

[0072] It should be understood that a core can support multiple threads (two or more parallel sets of execution operations or threads), and can do so in any of a variety of ways including time-sliced multithreading, simultaneous multithreading (where a single physical core provides logical cores for each of the multithreaded threads to use at a time), or a combination thereof (such as simultaneous multithreading with some time-sliced multithreading). time-sliced fetch and decode in a hyperthreaded technology, and simultaneous multithreading thereafter).

[0073] While register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in in-order architectures. While the illustrated embodiment of the processor also includes separate instruction and data cache units and a shared L2 cache unit, alternative embodiments can have a single internal cache for both instructions and data, such as for example, a level 1 (Ll) internal cache or multiple levels of internal caches. In some embodiments, a system can include a combination of internal caches and external caches that are external to the cores and / or processors. Alternatively, all caches can be external to the cores and / or processors.

[0074] Figure 5B is a block diagram of a sequential pipeline and register renaming stage of a processor 500 implemented by Figure 5A of FIG. 1, in accordance with some embodiments of the present disclosure. Figure 5B The solid line block diagram in FIG. 1 illustrates a sequential pipeline, while the dashed line block diagram illustrates a register renaming, out-of-order issue / execution pipeline. In Figure 5B5. In the embodiment of the present invention, the processor 500 as a pipeline includes a fetch stage 502, a length decode stage 504, a decode stage 506, an allocation stage 508, a rename stage 510, a schedule (also called dispatch or issue) stage 512, a register read / memory read stage 514, an execute stage 516, a write back / memory write stage 518, an exception handling stage 522, and a commit stage 524. In some embodiments, the ordering of the stages 502-524 may be different than shown and is not limited to the order shown in FIG. Figure 5B The specific ordering shown in .

[0075] Figure 6 A block diagram of a microarchitecture for a processor 600 including a hybrid core according to one embodiment of the present disclosure is illustrated. In some embodiments, instructions according to one embodiment can be implemented to operate on data elements having sizes of bytes, words, double words, quad words, etc., and data types such as single-precision and double-precision integers and floating-point data types. In one embodiment, a sequential front end 601 is the portion of the processor 600 that fetches instructions to be executed and prepares them for later use in the processor pipeline.

[0076] The front end 601 may include several units. In one embodiment, an instruction prefetcher 626 fetches instructions from memory and feeds them to an instruction decoder 628, which in turn decodes or interprets them. For example, in one embodiment, the decoder decodes the received instruction into one or more operations, which are referred to as "microinstructions" or "micro-operations" (also referred to as micro-ops or uops) that the machine can execute. In other embodiments, the decoder parses the instruction into an opcode and corresponding data and control fields used by the microarchitecture to perform operations according to one embodiment. In one embodiment, a trace cache 630 takes the decoded uops and assembles them into a program-ordered sequence or trace in a uop queue 634 for execution. When the trace cache 630 encounters a complex instruction, the microcode ROM 632 provides the uops required to complete the operation.

[0077] Some instructions are converted to a single micro-op, while others require several micro-ops to complete the entire operation. In one embodiment, if more than four micro-ops are required to complete the instruction, then the decoder 628 accesses the microcode ROM 632 for the instruction. For one embodiment, the instruction can be decoded into a small number of micro-ops for processing at the instruction decoder 628. In another embodiment, if multiple micro-ops are required to implement the operation, then the instruction can be stored in the microcode ROM 632. The trace cache 630 refers to the entry point programmable logic array (PLA) to determine the correct microinstruction pointer for the read microcode sequence to complete one or more instructions according to one embodiment from the microcode ROM 632. After the microcode ROM 632 completes the micro-op sorting for the instruction, the front end 601 of the machine continues to fetch micro-ops from the trace cache 630.

[0078] The out-of-order execution engine 603 is where instructions are prepared for execution. The out-of-order execution logic has multiple buffers to smooth out the flow of instructions and reorder the flow of instructions to optimize performance as they go down the pipeline and are scheduled for execution. The dispatcher logic allocates the machine buffers and resources each uop needs to execute. The register renaming logic renames logical registers into entries in the register file. The dispatcher also allocates an entry for each uop in one of the two uop queues, one for memory operations and one for non-memory operations, before the instruction scheduler: the memory scheduler, the fast scheduler 602, the slow / general floating-point scheduler 604, and the simple floating-point scheduler 606. The uop schedulers 602, 604, 606 determine when a uop is ready to execute based on the readiness of their dependent input register operand sources and the availability of the execution resources the uop needs to complete its operation. The fast scheduler 602 of one embodiment can schedule on each half of the main clock cycle, while the other schedulers can only schedule once per main processor clock cycle. The scheduler arbitrates for the dispatch ports to schedule uops for execution.

[0079] Register files 608, 610 are located between the dispatch units 602, 604, 606 and execution units 612, 614, 616, 618, 620, 622, 624 in execution block 611. Separate register files 608, 610 exist for integer and floating point operations. Each register file 608, 610 of one embodiment also includes a bypass network that can bypass or forward the results of an instruction that has just finished to a new dependent uop that has not yet been written into the register file. The integer register file 608 and the floating point register file 610 are also capable of transferring data to each other. For one embodiment, the integer register file 608 is split into two separate register files, one for the lower order 32 bits of data and a second for the upper order 32 bits of data. The floating point register file 610 of one embodiment has 128 bit wide entries since floating point instructions generally have 64 to 128 bits wide of operands.

[0080] Execution block 611 includes execution units 612, 614, 616, 618, 620, 622, 624 in which the instructions are actually processed. This portion of the processor 600 includes register files 608, 610 that store the integer and floating point data operand values that are used by the micro-instructions for execution. The processor 600 of one embodiment is comprised of multiple execution units: address generation units (AGUs) 612, 614, fast ALUs 616, 618, slow ALU 620, floating point ALU 622, floating point move unit 624. For one embodiment, the floating point execution block 622, 624 performs floating point, MMX, SIMD, and SSE or other operations. The floating point ALU 622 of one embodiment includes a 64 bit by 64 bit floating point divider to execute divide, square root, and remainder micro-ops. For embodiments of the disclosure, instructions involving a floating point value can be handled with the floating point hardware.

[0081] In one embodiment, ALU operations are directed to the high-speed ALU execution units 616, 618. The fast ALUs 616, 618 of one embodiment can execute fast operations with an effective latency of half a clock cycle. For one embodiment, most complex integer operations are directed to the slow ALU 620 because the slow ALU 620 includes integer execution hardware for long-latency operations, such as multipliers, shifts, flag logic, and branch processing. Memory load / store operations are performed by the AGUs 612, 614. For one embodiment, the integer ALUs 616, 618, 620 are described in the context of performing integer operations on 64-bit data operands. In alternative embodiments, the ALUs 616, 618, 620 can be implemented to support a variety of data bits, including 16, 32, 128, 256, etc. Similarly, the floating-point units 622, 624 can be implemented to support a range of operands with bits of varying widths. For one embodiment, the floating point units 622, 624 may operate on 128-bit wide packed data operands in conjunction with SIMD and multimedia instructions.

[0082] In one embodiment, the uop scheduler 602, 604, 606 dispatches dependent operations before the parent load has completed execution. Because uops are speculatively scheduled and executed in processor 600, processor 600 also includes logic for handling memory misses. If data will miss a load in the data cache, there may be dependent operations in flight in the pipeline that leave the scheduler with temporarily incorrect data. A replay mechanism tracks and re-executes instructions that use the incorrect data. Only dependent operations need to be replayed and independent operations are allowed to complete. The scheduler and replay mechanism of one embodiment of the processor are also designed to catch instruction sequences for text string comparison operations.

[0083] Processor 600 also includes logic for implementing memory address prediction for memory disambiguation according to embodiments of the present disclosure. In one embodiment, execution block 611 of processor 600 may include a memory address predictor (not shown) for implementing memory address prediction for memory disambiguation.

[0084] The term "register" may refer to an on-board processor storage location that is used as a portion of an instruction for identifying an operand. In other words, a register may be one that is usable from the outside of the processor (from a programmer's perspective). However, the register of an embodiment should not be limited to a particular type of circuit in meaning. Rather, the register of an embodiment can store and provide data and perform the functions described herein. The registers described herein may be implemented using any number of different technologies by a circuit within the processor, such as dedicated physical registers, dynamically allocated physical registers using register renaming, a combination of dedicated physical registers and dynamically allocated physical registers, etc. In one embodiment, integer registers store thirty-two bit integer data. The register file of an embodiment also includes eight multimedia SIMD registers for packed data.

[0085] For the following discussion, registers are understood to be data registers designed to hold packed data, such as 64-bit wide MMX™ registers (also referred to as 'mm' registers in some instances) in microprocessors enabled by the MMX technology of Intel Corporation of Santa Clara, California. These MMX registers, available in both integer and floating-point form, can operate together with the packed data elements of accompanying SIMD and SSE instructions. Similarly, 128-bit wide XMM registers related to SSE2, SSE3, SSE4 or later (generally referred to as "SSEx") technology can also be used to hold such packed data operands. In one embodiment, in storing packed data and integer data, registers do not need to distinguish between the two data types. In one embodiment, integer and floating point are included in the same register file or in different register files. In addition, in one embodiment, floating point and integer data can be stored in different registers or in the same register.

[0086] Now refer to Figure 7 , a block diagram illustrating a system 700 in which embodiments of the present disclosure may be used is shown. Figure 7 As shown in FIG, multiprocessor system 700 is a point-to-point interconnect system and includes a first processor 770 and a second processor 780 coupled via a point-to-point interconnect 750. Although shown with only two processors 770, 780, it will be understood that the scope of the embodiments of the present disclosure is not limited in this regard. In other embodiments, one or more additional processors may be present in a given processor. In one embodiment, multiprocessor system 700 may implement a hybrid core as described herein.

[0087] Processors 770 and 780 are shown including integrated memory controller units 772 and 782, respectively. Processor 770 also includes point-to-point (PP) interfaces 776 and 778 as part of its bus controller unit; similarly, second processor 780 includes PP interfaces 786 and 788. Processors 770, 780 can exchange information via point-to-point (PP) interface 750 using PP interface circuits 778, 788. As shown in FIG. Figure 7 As shown in FIG, IMCs 772 and 782 couple the processors to respective memories, namely, memory 732 and memory 734, which may be portions of main memory locally attached to the respective processors.

[0088] Processors 770, 780 may each exchange information with chipset 790 via respective PP interfaces 752, 754 using point-to-point interface circuits 776, 794, 786, 798. Chipset 790 may also exchange information with high-performance graphics circuitry 738 via high-performance graphics interface 739.

[0089] A shared cache (not shown) may be included in either processor or external to both processors, still connected to the processors via the PP interconnect, such that if the processors are placed in a low power mode, local cache information for either or both processors may be stored in the shared cache.

[0090] Chipset 790 may be coupled to first bus 716 via interface 796. In one embodiment, first bus 716 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I / O interconnect bus, although the scope of the present disclosure is not limited in this respect.

[0091] As in Figure 7 As shown in FIG, various I / O devices 714 may be coupled to first bus 716, along with a bus bridge 718 that couples first bus 716 to a second bus 720. In one embodiment, second bus 720 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to second bus 720, including, for example, a keyboard and / or mouse 722, communication devices 727, and a storage unit 728 such as a disk drive or other mass storage device which may include instructions / code and data 730. Additionally, an audio I / O 724 may be coupled to second bus 720. Note that other architectures are possible. For example, instead of Figure 7 Instead of a point-to-point architecture, the system can implement a multi-drop bus or other such architecture.

[0092] Now refer to Figure 8 , shows a block diagram of a system 800 in which one embodiment of the present disclosure may operate. The system 800 may include one or more processors 810, 815 coupled to a graphics memory controller hub (GMCH) 820. Figure 8 The optional nature of the additional processor 815 is indicated by dashed lines. In one embodiment, the processors 810, 815 implement a hybrid core according to an embodiment of the present disclosure.

[0093] Each processor 810 , 815 may be some version of a circuit, integrated circuit, processor, and / or silicon integrated circuit as described above. However, it should be noted that it is unlikely that integrated graphics logic and integrated memory control units will be present in the processors 810 , 815 . Figure 8 The GMCH 820 is shown to be coupled to a memory 840, which may be, for example, dynamic random access memory (DRAM). For at least one embodiment, the DRAM may be associated with a non-volatile cache.

[0094] The GMCH 820 may be a chipset or part of a chipset. The GMCH 820 may communicate with the processor(s) 810, 815 and control the interaction between the processor(s) 810, 815 and the memory 840. The GMCH 820 may also serve as an accelerated bus interface between the processor(s) 810, 815 and other elements of the system 800. For at least one embodiment, the GMCH 820 communicates with the processor(s) 810, 815 via a multi-drop bus such as a front-side bus 895.

[0095] In addition, the GMCH 820 is coupled to a display 845 (such as a flat panel or touch screen display). The GMCH 820 may include an integrated graphics accelerator. The GMCH 820 is further coupled to an input / output (I / O) controller hub (ICH) 850, which may be used to couple various peripheral devices to the system 800. For example, in Figure 8 In the embodiment shown, an external graphics device 860, which may be a discrete graphics device, is coupled to the ICH 850, along with another peripheral device 870.

[0096] Alternatively, additional or different processors may also be present in the system 800. For example, the additional processor(s) 815 may include additional processor(s) identical to the processor 810, additional processor(s) that are heterogeneous or asymmetric to the processor 810, an accelerator (such as, for example, a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array, or any other processor. There may be a variety of differences between the processor(s) 810, 815 in terms of a spectrum of metrics of merit, including architectural, microarchitectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetry and heterogeneity among the processors 810, 815. For at least one embodiment, the various processors 810, 815 may reside in the same die package.

[0097] Now refer to Figure 9 , showing a block diagram of a system 900 in which embodiments of the present disclosure may operate. Figure 9 Processors 970 and 980 are illustrated. In one embodiment, processors 970 and 980 may implement the hybrid core described above. Processors 970 and 980 may include integrated memory and I / O control logic ("CL") 972 and 982, respectively, and may communicate with each other via a point-to-point interconnect 950 between point-to-point (PP) interfaces 978 and 988, respectively. Each of processors 970 and 980 communicates with chipset 990 via point-to-point interconnects 952 and 954, as shown, through respective PP interfaces 976 to 994 and 986 to 998. For at least one embodiment, CL 972 and 982 may include an integrated memory controller unit. CL 972 and 982 may include I / O control logic. As depicted, memories 932 and 934 are coupled to CL 972 and 982, and I / O devices 914 are also coupled to control logic 972 and 982. Legacy I / O device 915 is coupled to chipset 990 via interface 996 .

[0098] Embodiments may be implemented in many different system types. Figure 10 is a block diagram of a SoC 1000 according to an embodiment of the present disclosure. The dashed boxes are optional features on more advanced SoCs. In some implementations, such as in Figure 10 The SoC 1000 shown in FIG. 1 includes the following components: Figure 1 Features of SoC 100 are shown in FIG. Figure 101006; a system agent unit 1010; a bus controller unit 1016; an integrated memory controller unit 1014; a set or one or more media processors 1018, which may include integrated graphics logic 1008, an image processor 1024 for providing still camera and / or video camera functionality, an audio processor 1026 for providing hardware audio acceleration, and a video processor 1028 for providing video encoding / decoding acceleration; a static random access memory (SRAM) unit 1030; a direct memory access (DMA) unit 1032; and a display unit 1040 for coupling to one or more external displays. In one embodiment, a memory module may be included in the integrated memory controller unit 1014. In another embodiment, a memory module may be included in one or more other components of the SoC 1000 that can be used to access and / or control memory. The application processor 1020 may include a memory address predictor for implementing a hybrid core as described in embodiments herein.

[0099] The memory hierarchy includes one or more levels of cache within the core, a set, or one or more shared cache units 1006 and external memory (not shown) coupled to a set of integrated memory controller units 1014. The set of shared cache units 1006 may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and / or combinations thereof.

[0100] In some embodiments, one or more of the cores 1002A-N may be multi-threaded. System agent 1010 includes components that coordinate and operate cores 1002A-N. System agent unit 1010 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or include logic and components necessary to regulate the power state of cores 1002A-N and integrated graphics logic 1008. The display unit is used to drive one or more externally connected displays.

[0101] Cores 1002A-N may be homogeneous or heterogeneous in terms of architecture and / or instruction set. For example, some of cores 1002A-N may be sequential while others may be out-of-order. As another example, two or more of cores 1002A-N may be capable of executing the same instruction set, while others may be capable of executing only a subset of that instruction set or a different instruction set.

[0102] Application processor 1020 may be a general purpose processor, such as an Intel processor from Santa Clara, Calif. TM Core available to companies TM i3, i5, i7, 2Duo and Quad, Xeon TM , Itanium TM 、Atom TM or Quark TM Alternatively, the application processor 1020 may come from another company, such as ARM Holdings TM Co., Ltd., MIPS TM Etc. Application processor 1020 may be a specialized processor, such as, for example, a network or communications processor, a compression engine, a graphics processor, a coprocessor, an embedded processor, or the like. Application processor 1020 may be implemented on one or more chips. Application processor 1020 may be part of and / or implemented on one or more substrates using any of a plurality of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.

[0103] Figure 11 1 is a block diagram of an embodiment of a system-on-chip (SoC) design according to the present disclosure. As a specific illustrative example, SoC 1100 is included in a user equipment (UE). In one embodiment, a UE refers to any device that will be used by an end user to communicate, such as a handheld phone, smartphone, tablet computer, ultra-thin notebook computer, laptop computer with broadband adapter, or any other similar communication device. A UE is often connected to a base station or node, which potentially corresponds in nature to a mobile station (MS) in a GSM network.

[0104] Here, SOC 1100 includes two cores - 1106 and 1107. Cores 1106 and 1107 may conform to an instruction set architecture, such as an ISA based on Architecture Core TM1100 . The processors of the present invention are processors of the present invention, ...

[0105] The interconnect 1110 provides a communication channel to other components, such as a subscriber identity module (SIM) 1130 for interfacing with a SIM card, a boot ROM 1135 for storing boot code for execution by cores 1106 and 1107 to initialize and boot the SoC 1100, an SDRAM controller 1140 for interfacing with external memory (e.g., DRAM 1160), a flash controller 1145 for interfacing with non-volatile memory (e.g., flash memory 1165), a peripheral control 1150 (e.g., a serial peripheral interface) for interfacing with peripheral devices, a video codec 1120 and a video interface 1125 for displaying and receiving input (e.g., touch-enabled input), a GPU 1115 for performing graphics-related calculations, etc. Any of these interfaces can incorporate aspects of the present disclosure described herein. In addition, the system 1100 illustrates peripheral devices for communication, such as a Bluetooth module 1170, a 3G modem 1175, a GPS 1180, and a Wi-Fi 1185.

[0106] Figure 12A graphical representation of a machine in the example form of a computer system 1200 is illustrated in which a set of instructions can be executed to cause the machine to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine can be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine can operate in the capacity of a server or client device in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a web device, a server, a network router, a switch, or a bridge, or any machine capable of executing a set (sequential or other) of instructions specifying the actions to be taken by the machine. In addition, although only a single machine is illustrated, the term "machine" should also be interpreted to include any set of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0107] The computer system 1200 includes a processing device 1202, a main memory 1204 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (such as synchronous DRAM (SDRAM) or DRAM (RDRAM)), etc.), a static memory 1206 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1218, which communicate with each other via a bus 1230.

[0108] The processing device 1202 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computer (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets or a processor that implements a combination of instruction sets. The processing device 1202 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. In one embodiment, the processing device 1202 may include one or more processing cores. The processing device 1202 is configured to execute processing logic 1226 for performing the operations and steps discussed herein. For example, the processing logic 1226 may execute as described in Figure 4 In one embodiment, the processing device 1202 is associated with the processor 1202 as described herein with respect to the embodiments of the present disclosure. Figure 1 The processor architecture 102 described is the same.

[0109] The computer system 1200 may further include a network interface device 1208 communicatively coupled to a network 1220. The computer system 1200 may also include a video display unit 1210 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 1212 (e.g., a keyboard), a cursor control device 1214 (e.g., a mouse), and a signal generating device 1216 (e.g., a speaker). In addition, the computer system 1200 may include a graphics processing unit 1222, a video processing unit 1228, and an audio processing unit 1232.

[0110] The data storage device 1218 may include a machine-accessible storage medium 1224 on which is stored software implementing any one or more of the methods of functionality described herein, such as implementing storage address prediction for memory disambiguation as described above. The software may also reside, completely or at least partially, in the main memory 1204 as instructions and / or in the processing device 1202 as processing logic 1226 during execution thereof by the computer system 1200; the main memory 1204 and the processing device 1202 also constituting machine-accessible storage media.

[0111] The machine-readable storage medium 1224 may also be used to store instructions that implement storage address prediction for a hybrid core such as described in accordance with embodiments of the present disclosure. Although the machine-accessible storage medium 1128 is shown as a single medium in the example embodiments, the term "machine-accessible storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store one or more sets of instructions. The term "machine-accessible storage medium" should also be understood to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by a machine, as well as causing the machine to perform any one or more of the methods of the present disclosure. The term "machine-accessible storage medium" should therefore be understood to include, but is not limited to, solid-state memory and optical and magnetic media.

[0112] The following examples relate to further embodiments. Example 1 is a processor comprising an instruction retirement circuit, a data cache comprising a transactional memory, a first shadow register set and a second shadow register set, and an instruction execution circuit to receive a sequence of instructions comprising a first local commit marker, a first global commit marker, a first memory access instruction associated with a memory location and a first register access instruction referencing an architectural register, speculatively execute the first memory access instruction to generate a speculative memory state value associated with the memory location and speculatively execute the first register access instruction to generate a speculative register state value associated with a physical register, in response to identifying the first local commit marker, store the speculative memory state value in a buffer associated with the instruction retirement circuit and store the speculative register state value in the first shadow register, and in response to identifying the first global commit marker, store the speculative memory state value in the transactional memory of the data cache and store the speculative register state value in the second shadow register.

[0113] In Example 2, the subject matter of Example 1 can further provide that the processing core comprises a binary translator to generate the sequence of instructions based on input instructions, and wherein the local commit mode is associated with a first portion of code executed and the global commit mode is associated with a second portion of code containing the first portion of code.

[0114] In Example 3, the subject matter of Example 1 can further provide that the instruction execution circuit is further to identify a second local commit marker, in response to identifying the second commit marker, copy the speculative memory state value from the buffer to a cache line in the transactional memory and set a speculation flag to a speculative state, copy the speculative register state value from the physical register to the architectural register, and generate a local checkpoint referencing the cache line and the architectural register.

[0115] In Example 4, the subject matter of any of Examples 1 and 3 can further provide that the instruction execution circuit is further to speculatively execute a second register access instruction to generate a second speculative register state value, store the second speculative register value in the first shadow register, identify a local rollback event, and roll back the processing device to the speculative memory state value stored in the cache line referenced by the local checkpoint and to the second speculative register state value stored in the first shadow register.

[0116] In Example 5, the subject matter of Example 1 may further provide that the instruction execution circuitry is further to identify a second global commit marker, and in response to identifying the second global commit marker, clear a speculation flag associated with a speculative memory state value in the transactional memory, copy the speculative register state value from the physical register to the architectural register, and generate a global checkpoint referencing the cache line and the architectural register.

[0117] In Example 6, the subject matter of any of Examples 1 and 5 may further provide that the instruction execution circuitry is further to speculatively execute a second register access instruction to generate a second speculative register state value, store the second speculative register value in a second shadow register, identify a global rollback event, and roll back the processing device to the speculative memory state value stored in the cache line referenced by the global checkpoint and to the second speculative register state value stored in the second shadow register.

[0118] In Example 7, the subject matter of Example 1 may further provide that at least one of the first shadow register or the second shadow register is implemented using a copy-on-write (CoW) structure.

[0119] In Example 8, the subject matter of Example 1 may further provide for storing a speculative memory state value in a transactional memory of a data cache, the instruction execution circuit being operable to store the speculative memory state value in a cache line in the transactional memory and to set a speculation flag in the cache line to a speculative state.

[0120] In Example 9, the subject matter of Example 1 may further provide that the transactional memory includes a cache line for storing speculative memory values, and wherein the cache line includes a speculation flag for storing a state of the speculation, and wherein the speculation flag is a read / write state flag of the cache line.

[0121] Example 10 is a system comprising a memory and a processor communicatively coupled to the memory, including instruction retirement circuitry, a data cache including transactional memory, and instruction execution circuitry to receive a sequence of instructions, the sequence of instructions including a first local commit marker, a first global commit marker, and a first memory access instruction associated with a memory location, speculatively execute the first memory access instruction to generate a speculative memory state value referenced by the memory location, store the speculative memory state value in a buffer associated with the instruction retirement circuitry in response to identifying the first local commit marker, and store the speculative memory state value in the transactional memory of the data cache in response to identifying the first global commit marker.

[0122] In Example 11, the subject matter of Example 10 can further provide that the instruction execution circuitry is further to identify a second local commit marker, and in response to identifying the second commit marker, copy the speculative memory state value from the buffer to the cache line in the transactional memory and set a speculation flag to a speculative state, and generate a local checkpoint referencing the cache line and the physical register, identify a local rollback event, and roll back the processing device to the state value stored in the cache line referenced by the local checkpoint.

[0123] In Example 12, the subject matter of Example 10 can further provide that the instruction execution circuitry is further to identify a second global commit marker, and in response to identifying the second global commit marker, clear the speculation flag associated with the speculative memory state value in the transactional memory, and generate a global checkpoint referencing the cache line, identify a global rollback event, and roll back the processing device to the state value stored in the cache line referenced by the global checkpoint.

[0124] In Example 13, the subject matter of Example 10 can further provide that to store a speculative memory state value in a transactional memory of a data cache, the instruction execution circuitry is to store the speculative memory state value in a cache line in the transactional memory and set a speculation flag in the cache line to a speculative state.

[0125] Example 14 is a processing device comprising a first shadow register, a second shadow register, and an instruction execution circuit communicatively coupled to the first shadow register and the second shadow register to receive a sequence of instructions, the sequence of instructions comprising a first local commit marker, a first global commit marker, and a first register access instruction referencing an architectural register, to speculatively execute the first register access instruction to generate a speculative register state value associated with a physical register, to store the speculative register state value in the first shadow register in response to identifying the first local commit marker, and to store the speculative register state value in the second shadow register in response to identifying the first global commit marker.

[0126] In Example 15, the subject matter of Example 14 can further provide that the instruction execution circuitry is further to identify a second local commit marker, and in response to identifying the second commit marker, copy the speculative register state value from the physical register to the architectural register, and generate a local checkpoint referencing the architectural register, speculatively execute a second register access instruction to generate a second speculative register state value, store the second speculative register value in the first shadow register, identify a local rollback event, and roll back the processing device to the speculative memory state value stored in the cache line referenced by the local checkpoint and to the second speculative register state value stored in the first shadow register.

[0127] In Example 16, the subject matter of Example 14 may further provide that the instruction execution circuitry is further to identify a second global commit marker, and in response to identifying the second global commit marker, copy the speculative register state value from the physical register to the architectural register and generate a global checkpoint referencing the cache line and the architectural register, speculatively execute a second register access instruction to generate a second speculative register state value, store the second speculative register value in a second shadow register, identify a global rollback event, and roll back the processing device to the speculative memory state value stored in the cache line referenced by the global checkpoint and to the second speculative register state value stored in the second shadow register.

[0128] In Example 17, the subject matter of Example 14 may further provide that at least one of the first shadow register or the second shadow register is implemented using a copy-on-write (CoW) structure.

[0129] Example 18 is a method comprising receiving, by a processor, a sequence of instructions comprising a first local commit marker, a first global commit marker, a first memory access instruction associated with a memory location, and a first register access instruction that references an architectural register, speculatively executing the first memory access instruction to generate a speculative memory state value associated with the memory location and speculatively executing the first register access instruction to generate a speculative register state value associated with a physical register, storing the speculative memory state value in a buffer coupled to a data cache and storing the speculative register state value in a first shadow register in response to identifying the first local commit marker, and storing the speculative memory state value in a transactional memory of the data cache and storing the speculative register state value in a second shadow register in response to identifying the first global commit marker.

[0130] In Example 19, the subject matter of Example 18 may further include identifying a second local commit marker, and in response to identifying the second local commit marker, copying the speculative memory state value from the buffer to the cache line in the transactional memory and setting the speculation flag to a speculative state, copying the speculative register state value from the physical register to the architectural register, and generating a local checkpoint referencing the cache line and the architectural register.

[0131] In Example 20, the subject matter of Example 18 may further include identifying a second global commit marker, and in response to identifying the second global commit marker, clearing a speculation flag associated with the speculative memory state value in the transactional memory, copying the speculative register state value from the physical register to the architectural register, and generating a global checkpoint referencing the cache line and the architectural register.

[0132] Example 21 is an apparatus comprising: an apparatus for performing the method of any of Examples 18 to 20.

[0133] Example 22 is a machine-readable non-transitory medium having program code stored thereon that, when executed, performs operations comprising: receiving, by a processor, a sequence of instructions comprising a first local commit marker, a first global commit marker, a first memory access instruction associated with a memory location, and a first register access instruction referencing an architectural register, speculatively executing the first memory access instruction to generate a speculative memory state value associated with the memory location and speculatively executing the first register access instruction to generate a speculative register state value associated with a physical register, in response to identifying the first local commit marker, storing the speculative memory state value in a buffer coupled to a data cache and storing the speculative register state value in a first shadow register, and in response to identifying the first global commit marker, storing the speculative memory state value in a transactional memory of the data cache and storing the speculative register state value in a second shadow register.

[0134] In Example 23, the subject matter of Example 22 may further provide that the operations further include identifying a second local commit marker, and in response to identifying the second local commit marker, copying the speculative memory state value from the buffer to a cache line in the transactional memory and setting the speculation flag to a speculative state, copying the speculative register state value from the physical register to the architectural register, and generating a local checkpoint referencing the cache line and the architectural register.

[0135] In Example 24, the subject matter of Example 22 may further provide that the operations further include identifying a second global commit marker, and in response to identifying the second global commit marker, clearing a speculation flag associated with the speculative memory state value in the transactional memory, copying the speculative register state value from the physical register to the architectural register, and generating a global checkpoint referencing the cache line and the architectural register.

[0136] A design can go through various stages, from creation to simulation to manufacturing. Data representing a design can represent the design in a variety of ways. First, as is useful in simulation, the hardware can be represented using a hardware description language or another functional description language. Furthermore, at some stage in the design process, a circuit-level model with logic and / or transistor gates can be generated. Furthermore, most designs, at some stage, reach the level of data representing the physical placement of various devices in the hardware model. In the case of conventional semiconductor manufacturing techniques, the data representing the hardware model may be data specifying the presence or absence of various features on different mask layers used to produce the integrated circuit. In any representation of the design, the data can be stored in any form of machine-readable medium. A memory device such as a disk or a magnetic or optical storage device can be a machine-readable medium for storing such information transmitted via light or electrical waves modulated or otherwise generated to transmit information. When an electrical carrier wave indicating or carrying a code or design is transmitted, a new copy is made, in the sense that the electrical signal is copied, buffered, or retransmitted. Thus, a communications provider or network provider can at least temporarily store an article, such as information encoded into a carrier wave, on a tangible, machine-readable medium to implement the techniques of embodiments of the present disclosure.

[0137] As used herein, a module refers to any combination of hardware, software, and / or firmware. As an example, a module includes hardware, such as a microcontroller associated with a non-transient medium to store code suitable for execution by the microcontroller. Thus, in one embodiment, reference to a module refers to hardware that is specifically configured to recognize and / or execute code that will be maintained on a non-transient medium. Furthermore, in another embodiment, the use of a module refers to a non-transient medium comprising code that is specifically suitable for execution by a microcontroller to perform predetermined operations. And as can be inferred, in yet another embodiment, the term module (in this example) may refer to a combination of a microcontroller and a non-transient medium. Module boundaries that are often illustrated as separate typically vary and may overlap. For example, a first and a second module may share hardware, software, firmware, or a combination thereof, while potentially retaining some independent hardware, software, or firmware. In one embodiment, the use of the term logic includes hardware, such as transistors, registers, or other hardware, such as programmable logic devices.

[0138] In one embodiment, the use of the phrase 'configured to' refers to arranging, putting together, manufacturing, offering for sale, importing, and / or designing a device, hardware, logic, or element to perform a specified or determined task. In this example, a device or element that is not operating is still "configured to" perform a specified task if it is designed, coupled, and / or interconnected to perform the specified task. As a purely illustrative example, during operation, a logic gate can provide a 0 or a 1. However, a logic gate that is 'configured to' provide an enable signal to a clock does not include every possible logic gate that can provide a 1 or a 0. Instead, the logic gate is a logic gate that is coupled in some manner such that, during operation, a 1 or 0 output will enable the clock. Note again that the use of the term 'configured to' does not require operation, but instead focuses on a potential state of the device, hardware, and / or element, where in the potential state, the device, hardware, and / or element is designed to perform a specific task when the device, hardware, and / or element is operating.

[0139] Additionally, in one embodiment, the use of the phrases 'to,' 'able to / with,' and / or 'operable to' refers to some device, logic, hardware, and / or element being designed in such a manner as to enable use of the device, logic, hardware, and / or element in a specified manner. As noted above, in one embodiment, the use of 'to,' 'able to / with,' and / or 'operable to' refers to a potential state of a device, logic, hardware, and / or element wherein the device, logic, hardware, and / or element is not operating but is designed in such a manner as to enable use of the device in a specified manner.

[0140] As used herein, a value includes any known representation of a number, state, logical state, or binary logical state. Typically, the use of logic levels, logical values, or logical values ​​is also referred to as 1 and 0, which simply represent binary logical states. For example, 1 refers to a high logic level and 0 refers to a low logic level. In one embodiment, a memory cell such as a transistor or a flash memory cell may be able to hold a single logical value or multiple logical values. However, other representations of values ​​in computer systems have been used. For example, the decimal number ten can also be represented as the binary value 910 and the hexadecimal letter A. Therefore, a value includes any representation of information that can be held in a computer system.

[0141] Furthermore, a state may be represented by a value or portion of a value. As an example, a first value such as a logical one may represent a default or initial state, while a second value such as a logical zero may represent a non-default state. Additionally, in one embodiment, the terms reset and set refer to default and updated values ​​or states, respectively. For example, a default value potentially includes a high logical value, i.e., reset, while an updated value potentially includes a low logical value, i.e., set. Note that any combination of values ​​may be utilized to represent any number of states.

[0142] Embodiments of the methods, hardware, software, firmware, or code described above may be implemented via instructions or code stored on a machine-accessible, machine-readable, computer-accessible, or computer-readable medium, which instructions or code may be executed by a processing element. Non-transitory machine-accessible / readable media include any mechanism that provides (i.e., stores and / or transmits) information in a form readable by a machine such as a computer or electronic system. For example, non-transitory machine-accessible media include random access memory (RAM) such as static RAM (SRAM) or dynamic RAM (DRAM); ROM; magnetic or optical storage media; flash memory devices; electrical storage devices; optical storage devices; acoustic storage devices; other forms of storage devices for holding information received from transient (propagating) signals (e.g., carrier waves, infrared signals, digital signals), etc., which are to be distinguished from non-transitory media from which information may be received.

[0143] The instructions for executing the program logic of the embodiments of the present disclosure can be stored in a memory in the system, such as DRAM, cache, flash memory or other storage devices. In addition, instructions can be distributed via a network or by other computer-readable media. Therefore, a machine-readable medium may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, but is not limited to a floppy disk, an optical disk, a compressed disk, a read-only memory (CD-ROM) and a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic card or an optical card, a flash memory or a tangible machine-readable storage device used in the transmission of information via an electrical, optical, acoustic or other form of propagation signal (e.g., carrier wave, infrared signal, digital signal, etc.) through the Internet. Therefore, a computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., computer).

[0144] Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0145] In the foregoing description, specific embodiments have been given with reference to specific exemplary embodiments. However, it will be clear that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the appended claims. Therefore, the description and drawings are to be regarded in an illustrative rather than a restrictive sense. Furthermore, the foregoing use of embodiments and other exemplary language does not necessarily refer to the same embodiment or the same example, but may refer to different and distinct embodiments as well as potentially the same embodiment.

Claims

1. A processing device comprising: First shadow register; Second shadow register; a register file comprising physical registers, the register file coupled to a first shadow register and a second shadow register; as well as Instruction execution circuitry is communicatively coupled to the first shadow register, the second shadow register, and the register file, the instruction execution circuitry being configured to: receiving code comprising a first local commit marker associated with a first portion of the code, a first global commit marker associated with a second portion of the code including the first portion of the code, and a first register access instruction referencing an architectural register; speculatively executing a first register access instruction to generate a speculative register state value stored in a physical register; In response to identifying the first partial commit marker, storing a speculative register state value in a first shadow register; In response to identifying the first global commit marker, storing a speculative register state value in a second shadow register; and In response to identifying a second local commit marker, copying speculative register state values ​​from physical registers to architectural registers; and Generates a local checkpoint of the referenced architectural registers.

2. The processing device of claim 1 , wherein the instruction execution circuit is further configured to: identifying a second global commit tag; and In response to identifying a second global commit marker, copying speculative register state values ​​from physical registers to architectural registers; and Generates a global checkpoint of the reference architecture registers; speculatively executing a second register access instruction to generate a second speculative register state value; storing a second speculative register value in a second shadow register; Identifies a global rollback event; and The processing device is rolled back to a speculative register state value stored in an architectural register referenced by the global checkpoint and to a second speculative register state value stored in a second shadow register. 3 . The processing device of claim 1 , wherein at least one of the first shadow register or the second shadow register is implemented using a copy-on-write (CoW) structure.

4. A processing device comprising: First shadow register; Second shadow register; a physical register coupled to the first shadow register and the second shadow register; as well as Instruction execution circuitry is communicatively coupled to the first shadow register, the second shadow register, and the physical register, the instruction execution circuitry being configured to: receiving a sequence of instructions, the sequence of instructions comprising a first local commit marker, a first global commit marker, and a first register access instruction referencing an architectural register; speculatively executing a first register access instruction to generate a speculative register state value associated with a physical register; In response to identifying the first partial commit marker, storing a speculative register state value in a first shadow register; In response to identifying the first global commit marker, storing a speculative register state value in a second shadow register; The instruction execution circuit is further configured to: Identifying a second partial commit marker; and In response to identifying a second commit marker, copying speculative register state values ​​from physical registers to architectural registers; and Generates a local checkpoint of the reference architectural registers; speculatively executing a second register access instruction to generate a second speculative register state value; storing a second speculative register value in the first shadow register; Identify a partial rollback event; and The processing device is rolled back to a speculative memory state value stored in an architectural register referenced by the local checkpoint and to a second speculative register state value stored in the first shadow register.

5. A system comprising: Main memory; as well as a processor, communicatively coupled to the main memory, comprising: an instruction retirement circuit coupled to the buffer; a data cache including a transactional memory, wherein the transactional memory is also coupled to the buffer; and An instruction execution circuit is coupled to the buffer and the transaction memory, and the instruction execution circuit is configured to: receiving code comprising a first local commit marker associated with a first portion of the code, a first global commit marker associated with a second portion of the code including the first portion of the code, and a first memory access instruction associated with a memory location of the main memory; speculatively executing a first memory access instruction to generate a speculative memory state value associated with a memory location; responsive to identifying a first partial commit marker, storing a speculative memory state value in the buffer; In response to identifying the first global commit marker, storing speculative memory state values ​​in transactional memory; and In response to identifying a second local commit marker, copying the speculative memory state value from the buffer to a cache line in the transactional memory; setting a speculation flag associated with the cache line to a speculative state; and Generates a local checkpoint of the referenced cache line.

6. The system of claim 5 , wherein the instruction execution circuit is further configured to: Identify a partial rollback event; and The state of the processor is rolled back to the speculative memory state value stored in the cache line referenced by the local checkpoint.

7. The system of claim 5 , wherein the instruction execution circuit is further configured to: identifying a second global commit tag; and In response to identifying the second global commit marker, clearing a speculation flag associated with a speculative memory state value in the transactional memory; and Generate a global checkpoint of the referenced cache line; Identifies a global rollback event; and The state of the processor is rolled back to the speculative memory state value stored in the cache line referenced by the global checkpoint.

8. A processing device comprising: an instruction retirement circuit coupled to the buffer; a data cache including a transactional memory, wherein the transactional memory is also coupled to the buffer; a first shadow register and a second shadow register; as well as a register file comprising physical registers, the register file coupled to a first shadow register and a second shadow register; as well as An instruction execution circuit is coupled to the data cache, the register file, the first shadow register, and the second shadow register, the instruction execution circuit being configured to: receiving code comprising a first local commit marker associated with a first portion of the code, a first global commit marker associated with a second portion of the code including the first portion of the code, a first memory access instruction referencing a memory location, and a first register access instruction referencing an architectural register; speculatively executing a first memory access instruction to generate a speculative memory state value associated with a memory location and speculatively executing a first register access instruction to generate a speculative register state value stored in a physical register; In response to identifying a first local commit marker, storing the speculative memory state value in a buffer; and storing a speculative register state value from the physical register in a first shadow register; and In response to identifying a first global commit marker, storing the speculative memory state value in a transactional memory of the data cache; and A speculative register state value from the physical register is stored in the second shadow register.

9. The processing device of claim 8, further comprising a binary translator to generate the code based on input instructions.

10. The processing device of claim 8, wherein the instruction execution circuit is further configured to: Identifying a second partial commit marker; and In response to identifying a second commit marker, copying a speculative memory state value from the buffer to a cache line in transactional memory and setting a speculation flag to a speculative state; copying speculative register state values ​​from physical registers to architectural registers; and Generates local checkpoints that reference cache lines and architectural registers.

11. The processing device of any one of claims 8 and 10, wherein the instruction execution circuit is further configured to: speculatively executing a second register access instruction to generate a second speculative register state value; storing a second speculative register value in the first shadow register; Identify a partial rollback event; and The processing device is rolled back to a speculative memory state value stored in a cache line referenced by the local checkpoint and to a second speculative register state value stored in the first shadow register.

12. The processing device of claim 8, wherein the instruction execution circuit is further configured to: identifying a second global commit tag; and In response to identifying a second global commit marker, clearing a speculation flag associated with a speculative memory state value in the transactional memory; copying speculative register state values ​​from physical registers to architectural registers; and Generates a global checkpoint that references cache lines and architectural registers.

13. The processing device of any one of claims 8 and 12, wherein the instruction execution circuit is further configured to: speculatively executing a second register access instruction to generate a second speculative register state value; storing a second speculative register value in a second shadow register; Identifies a global rollback event; and The processing device is rolled back to a speculative memory state value stored in a cache line referenced by the global checkpoint and to a second speculative register state value stored in a second shadow register.

14. The processing device of claim 8, wherein at least one of the first shadow register or the second shadow register is implemented using a copy-on-write (CoW) structure.

15. The processing device of claim 8 , wherein for storing speculative memory state values ​​in the transactional memory of the data cache, the instruction execution circuit is to: storing the speculative memory state value in a cache line in the transactional memory; and Sets the speculation flag in the cache line to the speculative state.

16. The processing device of claim 8, wherein the transactional memory comprises a cache line for storing speculative memory values, and wherein the cache line comprises a speculation flag for storing a state of speculation, and wherein the speculation flag is a read / write state flag of the cache line.

17. A method comprising: receiving, by a processor, code comprising a first local commit marker associated with a first portion of the code, a first global commit marker associated with a second portion of the code including the first portion of the code, a first memory access instruction associated with a memory location, and a first register access instruction referencing an architectural register; speculatively executing a first memory access instruction to generate a speculative memory state value associated with a memory location and speculatively executing a first register access instruction to generate a speculative register state value stored in a physical register; In response to identifying a first local commit marker, storing speculative memory state values ​​in a buffer coupled to the transactional memory; and storing a speculative register state value from the physical register in a first shadow register; and In response to identifying a first global commit marker, storing the speculative memory state value in transactional memory; and A speculative register state value from the physical register is stored in the second shadow register.

18. The method of claim 17, further comprising: Identify the second local commit marker; and In response to identifying a second local commit marker, copying a speculative memory state value from the buffer to a cache line in transactional memory and setting a speculation flag to a speculative state; copying speculative register state values ​​from physical registers to architectural registers; and Generates local checkpoints that reference cache lines and architectural registers.

19. The method of claim 17, further comprising: Identify a second global commit tag; and In response to identifying a second global commit marker, clearing a speculation flag associated with a speculative memory state value in the transactional memory; copying speculative register state values ​​from physical registers to architectural registers; and Generates a global checkpoint that references cache lines and architectural registers.

20. A device comprising: means for receiving, by a processor, code comprising a first local commit marker associated with a first portion of code, a first global commit marker associated with a second portion of code including the first portion of code, a first memory access instruction associated with a memory location, and a first register access instruction referencing an architectural register; means for speculatively executing a first memory access instruction to generate a speculative memory state value associated with a memory location and speculatively executing a first register access instruction to generate a speculative register state value stored in a physical register; means for, in response to identifying a first partial submission marker, storing speculative memory state values ​​in a buffer coupled to the transactional memory; and storing a speculative register state value from the physical register in a first shadow register; and means for, in response to identifying a first global commit marker, storing the speculative memory state value in transactional memory; and A speculative register state value from the physical register is stored in the second shadow register.

21. The apparatus of claim 20, further comprising: means for identifying a second partial submission mark; as well as means for, in response to identifying a second partial submission marker, copying a speculative memory state value from the buffer to a cache line in transactional memory and setting a speculation flag to a speculative state; copying speculative register state values ​​from physical registers to architectural registers; and Generates local checkpoints that reference cache lines and architectural registers.

22. The apparatus of claim 20, further comprising: means for identifying a second global commit marker; as well as means for, in response to identifying a second global commit marker, clearing a speculation flag associated with a speculative memory state value in the transactional memory; copying speculative register state values ​​from physical registers to architectural registers; and Generates a global checkpoint that references cache lines and architectural registers.

23. A computer-readable medium having stored thereon instructions that, when executed, cause a computing device to perform the method of any one of claims 17-19.

Images