An exemplary fault-tolerant computing system comprises a secondary processor configured to execute in delayed lock step with a primary processor from a common program store, comparators in the store data and writeback paths to detect a fault based on comparing primary and secondary processor states, and a writeback path delay permitting aborting execution when a fault is detected, before writeback of invalid data. The secondary processor execution and the primary processor store data and writeback may be delayed a predetermined number of cycles, permitting fault detection before writing invalid data. Store data and writeback paths may include triple module redundancy configured to pass only majority data through the store data and writeback path delay stages. Some implementations may forward data from the store data path delay stages to the writeback stage or memory if the load data address matches the address of data in a store data path delay stage.

A deferral instruction associated with a transaction is executed in a transaction execution computing environment with transactional memory. Based on executing the deferral instruction, a processor sets a defer-state indicating that pending disruptive events such as interrupts or conflicting memory accesses are to be deferred. A pending disruptive event is deferred based on the set defer-state, and the transaction is completed based on the disruptive event being deferred. The progress of the transaction may be monitored during a deferral period. The length of such deferral period may be specified by the deferral instruction. Whether the deferral period has expired may be determined based on the monitored progress of the transaction. If the deferral period has expired, the transaction may be aborted and the disruptive event may be processed.

Livelock recovery circuits configured to detect livelock in a processor, and cause the processor to transition to a known safe state when livelock is detected. The livelock recovery circuits include detection logic configured to detect that the processor is in livelock when the processor has illegally repeated an instruction; and transition logic configured to cause the processor to transition to a safe state when livelock has been detected by the detection logic.

Systems, methods, and apparatuses relating to circuitry to precisely monitor memory store accesses are described. In one embodiment, a system includes a memory, a hardware processor core comprising a decoder to decode an instruction into a decoded instruction, an execution circuit to execute the decoded instruction to produce a resultant, a store buffer, and a retirement circuit to retire the instruction when a store request for the resultant from the execution circuit is queued into the store buffer for storage into the memory, and a performance monitoring circuit to mark the retired instruction for monitoring of post-retirement performance information between being queued in the store buffer and being stored in the memory, enable a store fence after the retired instruction to be inserted that causes previous store requests to complete within the memory, and on detection of completion of the store request for the instruction in the memory, store the post-retirement performance information in storage of the performance monitoring circuit.

A processor includes: memory; an execution pipeline having a plurality of pipeline stages configured to process data provided to the execution pipeline and to store a result of the processing into the memory; a receive pipeline having a plurality of pipeline stages configured to handle incoming data to the processor and storing the incoming data into memory; context status storage configured to hold an exception indicator of an exception encountered by the execution pipeline while the execution pipeline processes data; wherein the receive pipeline is configured to determine that an exception has been committed to the context status storage by the execution pipeline, to suppress a write to memory of any incoming data to be handled by the receive pipeline and to commit a corresponding exception indicator to the context status storage at a final one of its pipeline stages.

A method of processing exceptions in an exception-driven computing-based system that operates in either initialisation mode or exception-driven mode. The method includes, upon detecting an exception has occurred, causing the processor to execute exception handling instructions. When the system is operating in initialisation mode the exception handling instructions invoke a first exception handler that causes a main register set to be saved before processing the exception and restored after processing the exception, and when the system is operating in exception-driven mode the exception handling instructions invoke a second exception handler that does not cause the main register set to be saved and restored. In some examples, the exception handling instructions are initially configured to invoke the first exception handler and are dynamically updated when the system switches from initialisation mode to exception-driven mode to invoke the second exception handler.

A hardware execution unit within a processor core executes a second instruction, which is part of a software thread, and which is executed out of order within the software thread. A sticky bit flip detection hardware device detects a change to a sticky bit in a floating-point status and control register (FPSCR) within the processor core. An instruction issue hardware unit identifies a first instruction that is in the software thread that is capable of reading or clearing the sticky bit. A flushing execution unit flushes all results of instructions from an instruction completion table (ICT) that include and are after the first instruction in the software thread. A hardware dispatch device dispatches all instructions that include and are after the first instruction in the software thread for execution by one or more hardware execution units within the processor core in a next-to-complete (NTC) sequential order.

Embodiments related to managing potentially invalid results generated/obtained by a microprocessor during runahead are provided. In one example, a method for operating a microprocessor includes causing the microprocessor to enter runahead upon detection of a runahead event. The example method also includes, during runahead, determining that an operation associated with an instruction referencing a storage location would produce a potentially invalid result based on a value of an architectural poison bit associated with the storage location and performing a different operation in response.

An update system may be used to update referenced data objects that are used by multiple applications. In some cases incorrect data may be entered and later corrected. Data consistency techniques are described herein to help avoid use of incorrect data before the data is corrected. A communication from the update system may include updated master data objects and an indication that there are further updates queued. A flag may be set for each of the updated master data objects as they are stored in a database. Then when a request to access those objects is received, the request may be denied when the flag set, thereby preventing access to potentially incorrect or outdated data.

Techniques for improving performance of accelerated processing devices (“APDs”) when exceptions occur are provided. In APDs, the very large number of parallel processing execution units, and the complexity of the hardware used to execute a large number of work-items in parallel, means that APDs typically stall when an exception occurs (unlike in central processing units (“CPUs”), which are able to execute speculatively and out-of-order). However, the techniques provided herein allow at least some execution to occur past exceptions. Execution past an exception generating instruction occurs by executing instructions that would not lead to a corruption while skipping those that would lead to a corruption. After the exception has been satisfied, execution occurs in a replay mode in which the potentially exception-generating instruction is executed and in which instructions that did not execute in the exception-wait mode are executed. A mask and counter are used to control execution in replay mode.