Abstract: In one embodiment, a computer-implemented method includes requesting, by a first processor thread of a computer processor, access to exception tracking logic. The exception tracking logic is accessible by a plurality of processor threads. The first processor thread receives access to the exception tracking logic. The first processor thread executes a process in slow mode. Based on detecting an exception in slow mode, the first processor thread stores, in the exception tracking logic, exception information about the exception. The exception information is copied from the exception tracking logic to a set of external registers outside the exception tracking logic. The exception tracking logic is released to allow access to the exception tracking logic by other processor threads of the plurality of processor threads.

Abstract: Embodiments relate to load queue entry reuse for operand store compare (OSC) history table update. An aspect includes allocating a load queue entry in a load queue to a load instruction that is issued into an instruction pipeline, the load queue entry comprising a valid tag that is set and a keep tag that is unset. Another aspect includes based on the flushing of the load instruction, unsetting the valid tag and setting the keep tag. Another aspect includes reissuing the load instruction into the instruction pipeline. Another aspect includes based on determining that the allocated load queue entry corresponds to the reissued load instruction, setting the valid tag and leaving the keep tag set. Another aspect includes based on completing the reissued load instruction, and based on the valid tag and the keep tag being set, updating the OSC history table corresponding to the load instruction.

Abstract: Technical solutions are described for dynamically managing an operand-store-compare (OSC) prediction table for load and store operations executed out-of-order. One general aspect includes a method that includes receiving a request to retire a queue entry corresponding to an instruction. The method also includes identifying an OSC prediction for the instruction based on an OSC prediction table entry, where the OSC prediction indicates if the instruction is predicted to hit an OSC hazard. The method also includes determining if the instruction hit the OSC hazard. The method also includes in response to the OSC prediction indicating that the instruction is predicted to hit the OSC hazard and the instruction not hitting the OSC hazard, invalidating the OSC prediction table entry corresponding to the instruction. The present document further describes examples of other aspects such as methods, computer products.

Abstract: A load request is received to retrieve a piece of data from a location in memory and the load request follows one or more store requests in a set of instructions to store a piece of data in the location in memory. One or more possible locations in a cache for a piece of data corresponding to the location in memory is determined. Each possible location of the one or more possible locations in the cache is determined. It is then determined if at least one location of the one or more possible locations contains data to be stored in the location in memory. Data in one location of the at least one location is loaded, the data in the one location is from a store request of the one or more store requests and the store request is closest in the set of instructions to the load request.

Abstract: Technical solutions are described for dynamically managing an operand-store-compare (OSC) prediction table for load and store operations executed out-of-order. One general aspect includes a method that includes receiving a request to retire a queue entry corresponding to an instruction. The method also includes identifying an OSC prediction for the instruction based on an OSC prediction table entry, where the OSC prediction indicates if the instruction is predicted to hit an OSC hazard. The method also includes determining if the instruction hit the OSC hazard. The method also includes in response to the OSC prediction indicating that the instruction is predicted to hit the OSC hazard and the instruction not hitting the OSC hazard, invalidating the OSC prediction table entry corresponding to the instruction. The present document further describes examples of other aspects such as methods, computer products.

Abstract: A load request is received to retrieve a piece of data from a location in memory and the load request follows one or more store requests in a set of instructions to store a piece of data in the location in memory. One or more possible locations in a cache for a piece of data corresponding to the location in memory is determined. Each possible location of the one or more possible locations in the cache is determined. It is then determined if at least one location of the one or more possible locations contains data to be stored in the location in memory. Data in one location of the at least one location is loaded, the data in the one location is from a store request of the one or more store requests and the store request is closest in the set of instructions to the load request.

Abstract: Technical solutions are described for dynamically managing an operand-store-compare (OSC) prediction table for load and store operations executed out-of-order. One general aspect includes a method that includes receiving a request to retire a queue entry corresponding to an instruction. The method also includes identifying an OSC prediction for the instruction based on an OSC prediction table entry, where the OSC prediction indicates if the instruction is predicted to hit an OSC hazard. The method also includes determining if the instruction hit the OSC hazard. The method also includes in response to the OSC prediction indicating that the instruction is predicted to hit the OSC hazard and the instruction not hitting the OSC hazard, invalidating the OSC prediction table entry corresponding to the instruction. The present document further describes examples of other aspects such as methods, computer products.

Abstract: Execution of threads in a processor core is controlled. The processor core supports simultaneous multi-threading (SMT) such that there can be effectively multiple logical central processing units (CPUs) operating simultaneously on the same physical processor hardware. Each of these logical CPUs is considered a thread. In such a multi-threading environment, it may be desirous for one thread to stop other threads on the processor core from executing. This may be in response to running a critical sequence or other sequence that needs the processor core resources or is manipulating processor core resources in a way that other threads would interfere with its execution.

Abstract: Execution of threads in a processor core is controlled. The processor core supports simultaneous multi-threading (SMT) such that there can be effectively multiple logical central processing units (CPUs) operating simultaneously on the same physical processor hardware. Each of these logical CPUs is considered a thread. In such a multi-threading environment, it may be desirous for one thread to stop other threads on the processor core from executing. This may be in response to running a critical sequence or other sequence that needs the processor core resources or is manipulating processor core resources in a way that other threads would interfere with its execution.

Abstract: Embodiments relate to a method, system and computer program product for storing a system-absolute address (SAA) in a first level look-aside buffer (TLB). In one embodiment, the system includes a central processor including the TLB and general purpose registers (GPRS). The TLB is configured for storing the SAA. The central processor is configured for issuing a load system-absolute address (LSAA) instruction. The system includes a translation unit that is in communication with the TLB of the central processor. The system is configured to perform a method including determining, based on the LSAA instruction being issued, whether the SAA is stored in the TLB. The method includes sending a translation request to the translation unit from the central processor based on the SAA not being stored in the TLB. The method includes determining the SAA by the translation unit based on receiving the translation request.

Abstract: Embodiments relate to load queue entry reuse for operand store compare (OSC) history table update. An aspect includes allocating a load queue entry in a load queue to a load instruction that is issued into an instruction pipeline, the load queue entry comprising a valid tag that is set and a keep tag that is unset. Another aspect includes based on the flushing of the load instruction, unsetting the valid tag and setting the keep tag. Another aspect includes reissuing the load instruction into the instruction pipeline. Another aspect includes based on determining that the allocated load queue entry corresponds to the reissued load instruction, setting the valid tag and leaving the keep tag set. Another aspect includes based on completing the reissued load instruction, and based on the valid tag and the keep tag being set, updating the OSC history table corresponding to the load instruction.

Abstract: Embodiments relate to a method, system and computer program product for storing a system-absolute address (SAA) in a first level look-aside buffer (TLB). In one embodiment, the system includes a central processor including the TLB and general purpose registers (GPRS). The TLB is configured for storing the SAA. The central processor is configured for issuing a load system-absolute address (LSAA) instruction. The system includes a translation unit that is in communication with the TLB of the central processor. The system is configured to perform a method including determining, based on the LSAA instruction being issued, whether the SAA is stored in the TLB. The method includes sending a translation request to the translation unit from the central processor based on the SAA not being stored in the TLB. The method includes determining the SAA by the translation unit based on receiving the translation request.

Abstract: A load request is received to retrieve a piece of data from a location in memory and the load request follows one or more store requests in a set of instructions to store a piece of data in the location in memory. One or more possible locations in a cache for a piece of data corresponding to the location in memory is determined. Each possible location of the one or more possible locations in the cache is determined. It is then determined if at least one location of the one or more possible locations contains data to be stored in the location in memory. Data in one location of the at least one location is loaded, the data in the one location is from a store request of the one or more store requests and the store request is closest in the set of instructions to the load request.

Abstract: In one embodiment, a computer-implemented method includes requesting, by a first processor thread of a computer processor, access to exception tracking logic. The exception tracking logic is accessible by a plurality of processor threads. The first processor thread receives access to the exception tracking logic. The first processor thread executes a process in slow mode. Based on detecting an exception in slow mode, the first processor thread stores, in the exception tracking logic, exception information about the exception. The exception information is copied from the exception tracking logic to a set of external registers outside the exception tracking logic. The exception tracking logic is released to allow access to the exception tracking logic by other processor threads of the plurality of processor threads.

Abstract: Technical solutions are described for dynamically managing an operand-store-compare (OSC) prediction table for load and store operations executed out-of-order. One general aspect includes a method that includes receiving a request to retire a queue entry corresponding to an instruction. The method also includes identifying an OSC prediction for the instruction based on an OSC prediction table entry, where the OSC prediction indicates if the instruction is predicted to hit an OSC hazard. The method also includes determining if the instruction hit the OSC hazard. The method also includes in response to the OSC prediction indicating that the instruction is predicted to hit the OSC hazard and the instruction not hitting the OSC hazard, invalidating the OSC prediction table entry corresponding to the instruction. The present document further describes examples of other aspects such as methods, computer products.

Abstract: Embodiments relate to load queue entry reuse for operand store compare (OSC) history table update. An aspect includes allocating a load queue entry in a load queue to a load instruction that is issued into an instruction pipeline, the load queue entry comprising a valid tag that is set and a keep tag that is unset. Another aspect includes based on the flushing of the load instruction, unsetting the valid tag and setting the keep tag. Another aspect includes reissuing the load instruction into the instruction pipeline. Another aspect includes based on determining that the allocated load queue entry corresponds to the reissued load instruction, setting the valid tag and leaving the keep tag set. Another aspect includes based on completing the reissued load instruction, and based on the valid tag and the keep tag being set, updating the OSC history table corresponding to the load instruction.

Abstract: A load request is received to retrieve a piece of data from a location in memory and the load request follows one or more store requests in a set of instructions to store a piece of data in the location in memory. One or more possible locations in a cache for a piece of data corresponding to the location in memory is determined. Each possible location of the one or more possible locations in the cache is determined. It is then determined if at least one location of the one or more possible locations contains data to be stored in the location in memory. Data in one location of the at least one location is loaded, the data in the one location is from a store request of the one or more store requests and the store request is closest in the set of instructions to the load request.

Abstract: A load request is received to retrieve a piece of data from a location in memory and the load request follows one or more store requests in a set of instructions to store a piece of data in the location in memory. One or more possible locations in a cache for a piece of data corresponding to the location in memory is determined. Each possible location of the one or more possible locations in the cache is determined. It is then determined if at least one location of the one or more possible locations contains data to be stored in the location in memory. Data in one location of the at least one location is loaded, the data in the one location is from a store request of the one or more store requests and the store request is closest in the set of instructions to the load request.

Abstract: Embodiments relate to a method, system and computer program product for storing a system-absolute address (SAA) in a first level look-aside buffer (TLB). In one embodiment, the system includes a central processor including the TLB and general purpose registers (GPRS). The TLB is configured for storing the SAA. The central processor is configured for issuing a load system-absolute address (LSAA) instruction. The system includes a translation unit that is in communication with the TLB of the central processor. The system is configured to perform a method including determining, based on the LSAA instruction being issued, whether the SAA is stored in the TLB. The method includes sending a translation request to the translation unit from the central processor based on the SAA not being stored in the TLB. The method includes determining the SAA by the translation unit based on receiving the translation request.

Abstract: Processing of transactions within a computing environment is facilitated by taking actions to increase the chances of successfully executing a transaction. A counter is maintained that provides a count of how often a transaction has aborted. The counter increments the count each time the transaction is aborted, and it is reset to zero upon successful completion of the transaction or an interruption leading to no more re-executions of the transaction. If the count reaches a threshold value, then an interrupt is presented and transaction execution is unsuccessful. However, before the count reaches the threshold, a number of actions may be taken to increase the chances of successfully executing the transaction. These actions include actions to be performed within the processor executing the transaction, and/or actions to be performed against conflicting processors.