Patent application number | Description | Published |
20080244544 | Using hardware checkpoints to support software based speculation - Hardware checkpoints may be used to mark software-based speculation regions. An instruction may be provided at the beginning of a speculation region and at the end of the speculation region. If an exception occurs during the speculation region, a hardware rollback may be occurred. The hardware rollback rolls back to the instruction at the beginning of the speculation region. The hardware may take a checkpoint by taking a register snapshot and treating future memory updates as tentative. When the instruction marking the end of the speculation is reached, all the tentative memory updates are committed and the previously taken register snapshot is discarded. | 10-02-2008 |
20090063773 | Technique to enable store forwarding during long latency instruction execution - A technique to allow independent loads to be satisfied during high-latency instruction processing. Embodiments of the invention relate to a technique in which a storage structure is used to hold store operations in program order while independent load instructions are satisfied during a time in which a high-latency instruction is being processed. After the high-latency instruction is processed, the store operations can be restored in program order without searching the storage structure. | 03-05-2009 |
20090119459 | LATE LOCK ACQUIRE MECHANISM FOR HARDWARE LOCK ELISION (HLE) - A method and apparatus for a late lock acquire mechanism is herein described. In response to detecting a late-lock acquire event, such as expiration of a timer, a full cachet set, and an irrevocable event, a late-lock acquire may be initiated. Consecutive critical sections are stalled until a late-lock acquire is completed utilizing fields of access buffer entries associated with consecutive critical section operations. | 05-07-2009 |
20100332801 | Adaptively Handling Remote Atomic Execution - In one embodiment, a method includes receiving an instruction for decoding in a processor core and dynamically handling the instruction with one of multiple behaviors based on whether contention is predicted. If no contention is predicted, the instruction is executed in the core, and if contention is predicted data associated with the instruction is marshaled and sent to a selected remote agent for execution. Other embodiments are described and claimed. | 12-30-2010 |
20110153960 | TRANSACTIONAL MEMORY IN OUT-OF-ORDER PROCESSORS WITH XABORT HAVING IMMEDIATE ARGUMENT - Methods, systems, and apparatuses to provide an XABORT in a transactional memory access system are described. In one embodiment, the stored value is a context value indicating the context in which a transactional memory execution was aborted. A fallback handler may use the context value to perform a series of operations particular to the context in which the abort occurred. | 06-23-2011 |
20110153989 | SYNCHRONIZING SIMD VECTORS - A vector compare-and-exchange operation is performed by: decoding by a decoder in a processing device, a single instruction specifying a vector compare-and-exchange operation for a plurality of data elements between a first storage location, a second storage location, and a third storage location; issuing the single instruction for execution by an execution unit in the processing device; and responsive to the execution of the single instruction, comparing data elements from the first storage location to corresponding data elements in the second storage location; and responsive to determining a match exists, replacing the data elements from the first storage location with corresponding data elements from the third storage location. | 06-23-2011 |
20110153992 | METHODS AND APPARATUS TO MANAGE OBJECT LOCKS - Example methods and apparatus to manage object locks are disclosed. A disclosed example method includes receiving an object lock request from a processor, the lock request associated with object lock code to lock an object, and generating object lock-bypass code based on a type of the processor, the object lock-bypass code to execute in a managed runtime in response to receiving the object lock request. The example method also includes identifying a type of instruction set architecture (ISA) associated with the processor, invoking a checkpoint instruction for the processor based on the identified ISA, suspending the object lock code from executing and executing target code when the object is uncontended, and allowing the object lock code to execute when the object is contended. | 06-23-2011 |
20110197182 | DEBUGGING PARALLEL SOFTWARE USING SPECULATIVELY EXECUTED CODE SEQUENCES IN A MULTIPLE CORE ENVIRONMENT - Methods and apparatus relating to debugging parallel software using speculatively executed code sequences in a multiple core environment are described. In an embodiment, occurrence of a speculative code debug event is detected and a speculative code execution debug module is executed in response to occurrence of the event. Other embodiments are also disclosed and claimed. | 08-11-2011 |
20120030518 | LAST BRANCH RECORD INDICATORS FOR TRANSACTIONAL MEMORY - In one embodiment, a processor includes an execution unit and at least one last branch record (LBR) register to store address information of a branch taken during program execution. This register may further store a transaction indicator to indicate whether the branch was taken during a transactional memory (TM) transaction. This register may further store an abort indicator to indicate whether the branch was caused by a transaction abort. Other embodiments are described and claimed. | 02-02-2012 |
20120079159 | Throttling Integrated Link - Methods and apparatus for throttling an interface that is integrated on the same die as a processor are described. In one embodiment, a signal from an Integrated Input/Output hub (e.g., integrated on the same die as a processor) causes throttling of a link coupled between the IIO and an Input/Output (IO) device. Other embodiments are also disclosed. | 03-29-2012 |
20120117333 | CRITICAL SECTION DETECTION AND PREDICTION MECHANISM FOR HARDWARE LOCK ELISION - A method and apparatus for detecting lock instructions and lock release instruction, as well as predicting critical sections is herein described. A lock instruction is detected with detection logic, which potentially resides in decode logic. A lock instruction entry associated with the lock instruction is stored/created. Address locations and values to be written to those address location of subsequent potential lock release instruction are compared to the address loaded from by the lock instruction and the value load by the lock instruction. If the addresses and values match, it is determined that the lock release instruction matches the lock instruction. A prediction entry stores a reference to the lock instruction, such as a last instruction pointer (LIP), and an associated value to represent the lock instruction is to be elided upon subsequent detection, if it is determined that the lock release instruction matches the lock instruction. | 05-10-2012 |
20120227045 | METHOD, APPARATUS, AND SYSTEM FOR SPECULATIVE EXECUTION EVENT COUNTER CHECKPOINTING AND RESTORING - An apparatus, method, and system are described herein for providing programmable control of performance/event counters. An event counter is programmable to track different events, as well as to be checkpointed when speculative code regions are encountered. So when a speculative code region is aborted, the event counter is able to be restored to it pre-speculation value. Moreover, the difference between a cumulative event count of committed and uncommitted execution and the committed execution, represents an event count/contribution for uncommitted execution. From information on the uncommitted execution, hardware/software may be tuned to enhance future execution to avoid wasted execution cycles. | 09-06-2012 |
20130179668 | LAST BRANCH RECORD INDICATORS FOR TRANSACTIONAL MEMORY - In one embodiment, a processor includes an execution unit and at least one last branch record (LBR) register to store address information of a branch taken during program execution. This register may further store a transaction indicator to indicate whether the branch was taken during a transactional memory (TM) transaction. This register may further store an abort indicator to indicate whether the branch was caused by a transaction abort. Other embodiments are described and claimed. | 07-11-2013 |
20130205119 | INSTRUCTION AND LOGIC TO TEST TRANSACTIONAL EXECUTION STATUS - Novel instructions, logic, methods and apparatus are disclosed to test transactional execution status. Embodiments include decoding a first instruction to start a transactional region. Responsive to the first instruction, a checkpoint for a set of architecture state registers is generated and memory accesses from a processing element in the transactional region associated with the first instruction are tracked. A second instruction to detect transactional execution of the transactional region is then decoded. An operation is executed, responsive to decoding the second instruction, to determine if an execution context of the second instruction is within the transactional region. Then responsive to the second instruction, a first flag is updated. In some embodiments, a register may optionally be updated and/or a second flag may optionally be updated responsive to the second instruction. | 08-08-2013 |
20140006698 | Hybrid Cache State And Filter Tracking Of Memory Operations During A Transaction | 01-02-2014 |
20140059333 | METHOD, APPARATUS, AND SYSTEM FOR SPECULATIVE ABORT CONTROL MECHANISMS - An apparatus and method is described herein for providing robust speculative code section abort control mechanisms. Hardware is able to track speculative code region abort events, conditions, and/or scenarios, such as an explicit abort instruction, a data conflict, a speculative timer expiration, a disallowed instruction attribute or type, etc. And hardware, firmware, software, or a combination thereof makes an abort determination based on the tracked abort events. As an example, hardware may make an initial abort determination based on one or more predefined events or choose to pass the event information up to a firmware or software handler to make such an abort determination. Upon determining an abort of a speculative code region is to be performed, hardware, firmware, software, or a combination thereof performs the abort, which may include following a fallback path specified by hardware or software. And to enable testing of such a fallback path, in one implementation, hardware provides software a mechanism to always abort speculative code regions. | 02-27-2014 |
20140156933 | System, Method, and Apparatus for Improving Throughput of Consecutive Transactional Memory Regions - Systems, apparatuses, and methods for improving TM throughput using a TM region indicator (or color) are described. Through the use of TM region indicators younger TM regions can have their instructions retired while waiting for older TM regions to commit. | 06-05-2014 |
20140189241 | Method and Apparatus to Write Modified Cache Data To A Backing Store While Retaining Write Permissions - A method is described that includes performing the following for a transactional operation in response to a request from a processing unit that is directed to a cache identifying a cache line. Reading the cache line, and, if the cache line is in a Modified cache coherency protocol state, forwarding the cache line to circuitry that will cause the cache line to be written to deeper storage, and, changing another instance of the cache line that is available to the processing unit for the transactional operation to an Exclusive cache coherency state | 07-03-2014 |
20140189315 | Copy-On-Write Buffer For Restoring Program Code From A Speculative Region To A Non-Speculative Region - An apparatus is described having an out-of-order instruction execution pipeline. The out-of-order execution pipeline has a first circuit and a second circuit. The first circuit is to hold a pointer to physical storage space where information is kept that cannot yet be confirmed as being free of potential dependencies on the information. The second circuit is to hold the pointer if the pointer existed in the first circuit when a non speculative region of program code ended and upon retirement of a following speculative overwriter instruction originally coded to overwrite the information. | 07-03-2014 |
20140258695 | Last Branch Record Indicators For Transactional Memory - In one embodiment, a processor includes an execution unit and at least one last branch record (LBR) register to store address information of a branch taken during program execution. This register may further store a transaction indicator to indicate whether the branch was taken during a transactional memory (TM) transaction. This register may further store an abort indicator to indicate whether the branch was caused by a transaction abort. Other embodiments are described and claimed. | 09-11-2014 |
20140379996 | METHOD, APPARATUS, AND SYSTEM FOR TRANSACTIONAL SPECULATION CONTROL INSTRUCTIONS - An apparatus and method is described herein for providing speculative escape instructions. Specifically, an explicit non-transactional load operation is described herein. During execution of a speculative code region (e.g. a transaction or critical section) loads are normally tracked in a read set. However, a programmer or compiler may utilize the explicit non-transactional read to load from a memory address into a destination register, while not adding the read/load to the transactional read set. Similarly, a non-transactional store is also provided. Here, a transactional store is performed and not added to a write set during speculative code execution. And the store may be immediately globally visible and/or persistent (even after an abort of the speculative code region). In other words, speculative escape operations are provided to ‘escape’ a speculative code region to perform non-transactional memory accesses without causing the speculative code region to abort or fail. | 12-25-2014 |
20150032998 | METHOD, APPARATUS, AND SYSTEM FOR TRANSACTIONAL SPECULATION CONTROL INSTRUCTIONS - An apparatus and method is described herein for providing speculation control instructions. An xAcquire and xRelease instruction are provided to define a critical section. In one embodiment, the xAcquire instruction includes a lock instruction with an elision prefix and the xRelease instruction includes a lock release instruction with an elision prefix. As a result, a processor is able to elide locks and transactionally execute a critical section defined in software by xAcquire and xRelease. But by adding only prefix hints, legacy processor are able to execute the same code by just ignoring the hints and executing the critical section traditionally with locks to guarantee mutual exclusion. Moreover, xBegin and xEnd are similarly provided for in an Instruction Set Architecture (ISA) to define a transactional code region. In addition, other control speculation instructions, such as xAbort to enable explicit abort of a critical or transactional code section and xTest to test a state of speculative execution is also provided in the ISA. | 01-29-2015 |
20150089286 | EVENT COUNTER CHECKPOINTING AND RESTORING - Event counter checkpointing and restoring is disclosed. In one implementation, a processor includes a first event counter to count events that occur during execution within the processor, event counter checkpoint logic, communicably coupled with the first event counter, to store, prior to a transactional execution of the processor, a value of the first event counter, a second event counter to count events prior to and during the transactional execution, wherein the second event counter is to increment without resetting after the transactional execution is aborted, event count restore logic to restore the first event counter to the stored value after the transactional execution is aborted, and tuning logic to determine, in response to aborting of the transactional execution, a number of the events that occurred during the transactional execution based on the stored value of the first event counter and a value of the second event counter. | 03-26-2015 |
Patent application number | Description | Published |
20100287340 | Concurrent Execution of Critical Sections by Eliding Ownership of Locks - One embodiment of the present invention provides a system that facilitates avoiding locks by speculatively executing critical sections of code. During operation, the system allows a process to speculatively execute a critical section of code within a program without first acquiring a lock associated with the critical section. If the process subsequently completes the critical section without encountering an interfering data access from another process, the system commits changes made during the speculative execution, and resumes normal non-speculative execution of the program past the critical section. Otherwise, if an interfering data access from another process is encountered during execution of the critical section, the system discards changes made during the speculative execution, and attempts to re-execute the critical section. | 11-11-2010 |
20110225375 | Concurrent Execution of Critical Sections by Eliding Ownership of Locks - One embodiment of the present invention provides a system that facilitates avoiding locks by speculatively executing critical sections of code. During operation, the system allows a process to speculatively execute a critical section of code within a program without first acquiring a lock associated with the critical section. If the process subsequently completes the critical section without encountering an interfering data access from another process, the system commits changes made during the speculative execution, and resumes normal non-speculative execution of the program past the critical section. Otherwise, if an interfering data access from another process is encountered during execution of the critical section, the system discards changes made during the speculative execution, and attempts to re-execute the critical section. | 09-15-2011 |
20130097391 | Concurrent Execution of Critical Sections by Eliding Ownership of Locks - Critical sections of multi-threaded programs, normally protected by locks providing access by only one thread, are speculatively executed concurrently by multiple threads with elision of the lock acquisition and release. Upon a completion of the speculative execution without actual conflict as may be identified using standard cache protocols, the speculative execution is committed, otherwise the speculative execution is squashed. Speculative execution with elision of the lock acquisition, allows a greater degree of parallel execution in multi-threaded programs with aggressive lock usage. | 04-18-2013 |
20140019692 | CONCURRENT EXECUTION OF CRITICAL SECTIONS BY ELIDING OWNERSHIP OF LOCKS - Critical sections of multi-threaded programs, normally protected by locks providing access by only one thread, are speculatively executed concurrently by multiple threads with elision of the lock acquisition and release. Upon a completion of the speculative execution without actual conflict as may be identified using standard cache protocols, the speculative execution is committed, otherwise the speculative execution is squashed. Speculative execution with elision of the lock acquisition, allows a greater degree of parallel execution in multi-threaded programs with aggressive lock usage. | 01-16-2014 |
20140297970 | Concurrent Execution of Critical Sections by Eliding Ownership of Locks - Critical sections of multi-threaded programs, normally protected by locks providing access by only one thread, are speculatively executed concurrently by multiple threads with elision of the lock acquisition and release. Upon a completion of the speculative execution without actual conflict as may be identified using standard cache protocols, the speculative execution is committed, otherwise the speculative execution is squashed. Speculative execution with elision of the lock acquisition, allows a greater degree of parallel execution in multi-threaded programs with aggressive lock usage. | 10-02-2014 |