Method, computer system and computer program product for transaction start / end instructions

Abstract

A method for executing a machine instruction in a data processing environment, the method comprising: - obtaining, by a processor, a machine instruction for specifying a transaction start operation, the machine instruction being defined for computer execution according to a computer architecture, the machine instruction for specifying a transaction start operation comprising: ◯ an operation code; and ◯ a control field for specifying one or more controls to be used in a transactional execution, comprising at least a base field and a displacement field; and - an execution, by the processor, of the machine instruction, the execution comprising: ◯ determining from a field of the statement whether a transaction to be initiated by the begin transaction statement is a restricted transaction or an unrestricted transaction; ◯ initiating a restricted transaction on the basis that the field is a value, where the restricted transaction has one or more constraints associated with it, where the one or more constraints are not associated with any unrestricted transaction, and setting a condition code to a value indicating successful execution of the machine instruction; and ◯ on the basis that the field is another value, specifying a location for storing diagnostic information in an aborted unconstrained transaction, initiating the unconstrained transaction, and setting a condition code to the value indicating successful execution of the machine instruction, wherein the field indicates an unrestricted transaction, and wherein, based on the base field having a value, contents of a register indicated by the base field are combined with contents of the displacement field to create a first operand address, the first operand address indicating a location of a transaction diagnostic block usable for storing the diagnostic information upon abort.

Description

TECHNICAL FIELD

[0001] One or more aspects relate generally to multiprocessor computing environments and, more particularly, to transactional processing within such computing environments. BACKGROUND

[0002] A constant challenge in multiprocessor programming is updates to the same memory location by multiple central processing units (CPUs). Many instructions that update memory locations, including even simple logical operations such as AND operations, do so with multiple accesses to the memory location. For example, the memory location is first fetched and then the updated result is stored back.

[0003] To allow multiple CPUs to safely update the same memory location, access to the memory location is performed in serial order. One instruction, the TEST AND SET instruction, introduced with the S / 360 architecture previously offered by International Business Machines Corporation, provided an interlocked update of a memory location. A locked update means that the instruction's entire memory access appears to be atomic, as observed by other CPUs and the input / output (I / O) subsystem (e.g., channel subsystem). Later, the S / 370 architecture introduced by International Business Machines Corporation introduced the COMPARE AND SWAP and COMPARE DOUBLE AND SWAP instructions, which provide a more sophisticated means of performing a locked update and enable the implementation of what is commonly known as a lock word (or semaphore).Recently added instructions have provided additional locked update functions, including COMPARE AND SWAP AND PURGE and COMPARE AND SWAP AND STORE. However, all of these instructions provide a lock on only a single memory location.

[0004] More complex programming techniques may require the locked update of multiple memory locations, for example, when adding an element to a doubly linked list. In such an operation, a forward and backward pointer must appear as if they were updated simultaneously, as observed by other CPUs and the I / O subsystem. To accomplish such multiple memory location updates, the program is forced to use a separate single serialization point, such as a lock word. However, lock words can provide a much coarser level of serialization than promised; for example, lock words can serialize an entire queue of millions of elements even if only two elements are updated. The program can structure the data to use more granular serialization (e.g.,a hierarchy of lock points), but this leads to additional problems such as potential deadlock situations if the hierarchy is not respected, and problems with recovery if the program encounters an error while one or more locks are held, or if the lock cannot be acquired.

[0005] In addition to the above, there are numerous scenarios in which a program may execute a sequence of instructions that could result in an exception. If no exception occurs, the program continues; however, if an exception is detected, the program may take corrective action to resolve the exception. For example, Java® may utilize such execution in speculative execution, partial inlining of a function, and / or resequencing of a pointer null check. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and / or its affiliates.

[0006] In classic operating system environments such as IBM z / OS® and its predecessors from International Business Machines Corporation, the program creates a recovery environment to catch any program exception that may occur. If the program does not catch the exception, the operating system typically terminates the program incorrectly for exceptions that the operating system is not prepared to handle. Creating and using such an environment is costly and complex. IBM, z / OS, z / Architecture® (incorporated below), z / VM® (incorporated below), Processor Resource / Systems Manager™ (incorporated below), Power Systems™ (incorporated below), and System x® (incorporated below) are trademarks of International Business Machines Corporation, registered in numerous jurisdictions worldwide.

[0007] Therefore, there is a need in the state of the art to address the above-mentioned problem.

[0008] The document "Early Experience with a Commercial Hardware Transactional Memory Implementation" by D. Dice et al., published in "Sun Microsystems, Inc. Mountain View, CA, USA: Technical Report. 2009 (SMLI TR-2009-180), pp. 1-60", accessed on August 8, 2017, at http: / / dl.acm.orq / citation.cfm?id=1698221, describes hardware transactional memory of a multi-core processor prototype.

[0009] Document US 2012 / 0 084 477 A1 describes mechanisms for executing a transaction in a data processing system. A transaction checkpoint data structure is created in internal registers of a processor. The transaction checkpoint data structure stores transaction checkpoint data representing a state of program registers at a time prior to the execution of a corresponding transaction. The transaction, which includes a first portion of code to be executed by the processor, is executed. During transaction execution, an interrupt of the transaction is received, and as a result, the transaction checkpoint data is stored in a data structure in a memory of the data processing system. A second portion of code is then executed.A state of the program registers is restored using the data structure in the memory of the data processing system in response to an event that causes the processor's execution to transition back to executing the transaction.

[0010] The document “Evaluation of AMD's Advanced Synchronization Facility Within a Complete Transactional Memory Stack” by Dave Christie et al., published in “Proceedings of the 5 th European Conference on Computer Systems. New York, NY, USA : ACM, 2010 (EuroSys '10). pp. 27-40. - ISBN 978-1-60558-577-2", accessed on August 8, 2017, at http: / / doi.acm.orq / 10.1145 / 1755913.1755918 describes AMD's "Advanced Synchronization Facility" (ASF), an x86 instruction set for simplifying and accelerating the synchronization of parallel programs.

[0011] The document “Transactional Memory, 2nd edition” by Tim Harris, James Laurus and Ravi Rajwar, published in “Synthesis Lectures on Computer Architecture, 5, 2010, 1, pp. i-iii, v-vii, x-xi, 19, 41-56, 70-72, 114, 153-164, 168-169, 180,229, 240”, accessed on August 8, 2017 at https: / / doi.org / 10.2200 / 8S00272ED1V01Y201006CAC011 describes transactional memory for coordinating parallel threads.

[0012] The Open Group document “Thread-safety and POSIX.1,” available at http: / / www.unix.org / whitepapers / reentrant.html, accessed on August 9, 2017, and archived on April 8, 2012, at http: / / www.archive.orq, describes features of POSIX.1 and the C programming language for use with parallel threads.

[0013] The paper "Exploiting Dead Value Information" by Milo Martin, Amir Roth, and Charles Fischer, published in "Proceedings of the 30th Annual ACM / IEEE International Symposium on Microarchitecture. Washington, DC, USA: IEEE Computer Society, 1997 (MICRO 30). pp. 125-135. - ISBN 0-8186-7977-8." and accessed on August 30, 2017, at http: / / dl.acm.org / citation.cfm?id=266800.266813, describes "Dead Information Value" (DVI). DVI provides a quantifiable measure for processors to determine whether certain register values ​​are "dead," whereby dead register values ​​are not read before they are overwritten. SUMMARY

[0014] The present subject matter relates to a method, computer system and computer program product for transaction start / end instructions.

[0015] One object underlying the invention can be considered to be providing an improved method, computer system and computer program product for executing a machine instruction in a data processing environment for initiating / terminating transactions.

[0016] The problem is solved by the subject matter of the independent patent claims. Embodiments are given in the dependent claims.

[0017] Deficiencies in the prior art are eliminated and advantages are provided by providing a computer program product for executing a machine instruction, the machine instruction for initiating a transaction, in a data processing environment, wherein stores by other processors in memory locations of the transaction cause the transaction to be aborted, and wherein stores by instructions in the transaction are effectively delayed until a selected transaction is completed. The computer program product includes a computer-readable storage medium readable by a processing circuit and storage instructions for execution by the processing circuit for performing a method. The method includes, for example, obtaining a machine instruction for execution by a processor,wherein the machine instruction is defined for computer execution according to a computer architecture, the machine instruction including, for example, an operation code to specify a transaction start operation; and a control field for specifying one or more controls to be used in transaction execution; and executing the machine instruction by the processor, wherein executing includes: determining from a field of the instruction whether a transaction to be initiated by the transaction start instruction is a restricted transaction or an unrestricted transaction; initiating a restricted transaction based on the field being a value, the restricted transaction having one or more restrictions associated with it, and setting a condition code to a value indicating successful execution of the machine instruction; and basedthat the field is another value, specifying a location to store diagnostic information in an aborted unconstrained transaction, initiating the unconstrained transaction, and setting a condition code to the value indicating successful execution of the machine instruction.

[0018] Methods and systems relating to one or more embodiments are also described and claimed herein. Furthermore, services relating to one or more embodiments are also described and may be claimed herein.

[0019] Viewed from a first aspect, the present invention provides a method for executing a machine instruction in a data processing environment, comprising: acquiring, by a processor, a machine instruction for an operation, the machine instruction being defined for computer execution according to a computer architecture, the machine instruction comprising: an operation code for specifying a begin-transaction operation; and a control field for specifying one or more controls to be used in transactional execution; and executing, by the processor, the machine instruction, wherein the executing comprises: determining from a field of the instruction whether a transaction to be initiated by the begin-transaction instruction is a constrained transaction or an unconstrained transaction;initiating a restricted transaction based on the field being a value, the restricted transaction having one or more constraints associated with it, and setting a condition code to a value indicating successful execution of the machine instruction; and, based on the field being another value, specifying a location for storing diagnostic information in an aborted unconstrained transaction, initiating the unconstrained transaction, and setting a condition code to the value indicating successful execution of the machine instruction.

[0020] Viewed from a further aspect, the present invention provides a computer system for executing a machine instruction, the machine instruction for initiating a transaction, in a data processing environment, wherein stores by other processors in memory locations of the transaction cause the transaction to be aborted, and wherein stores by instructions in the transaction are effectively delayed until a selected transaction is completed, the computer system comprising: a memory;and a processor in communication with the memory, the computer system being configured to execute a method, the method comprising: obtaining a machine instruction for execution by a processor, the machine instruction being defined for computer execution according to a computer architecture, the machine instruction comprising: an operation code for specifying a begin-transaction operation; and a control field for specifying one or more controls to be used in transactional execution; and executing the machine instruction by the processor, the executing comprising: determining from a field of the instruction whether a transaction to be initiated by the begin-transaction instruction is a constrained transaction or an unconstrained transaction;initiating a restricted transaction based on the field being a value, the restricted transaction having one or more constraints associated with it, and setting a condition code to a value indicating successful execution of the machine instruction; and, based on the field being another value, specifying a location for storing diagnostic information in an aborted unconstrained transaction, initiating the unconstrained transaction, and setting a condition code to the value indicating successful execution of the machine instruction.

[0021] Viewed from a further aspect, the present invention provides a computer program product for executing a machine instruction, the machine instruction for initiating a transaction, in a data processing environment, wherein stores by other processors in memory locations of the transaction cause the transaction to be aborted, and wherein stores by instructions in the transaction are effectively delayed until a selected transaction is completed, the computer program product comprising: a computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform a method comprising: acquiring, by a processor, a machine instruction for an operation, the machine instruction being defined for computer execution according to a computer architecture,wherein the machine instruction comprises: an operation code for specifying a transaction start operation; and a control field for specifying one or more controls to be used in transaction-bound execution; and execution of the machine instruction by the processor, wherein the execution comprises: determining from a field of the instruction whether a transaction to be initiated by the transaction start instruction is a constrained transaction or an unrestricted transaction; initiating a constrained transaction based on the field being a value, the constrained transaction having one or more constraints associated with it, and setting a condition code to a value indicating successful execution of the machine instruction; and based on the field being another value,specifying a location to store diagnostic information in an aborted unconstrained transaction, initiating the unconstrained transaction, and setting a condition code to the value indicating successful execution of the machine instruction.

[0022] Viewed from a further aspect, the present invention provides a computer program product for executing a machine instruction in a data processing environment, the computer program product comprising a computer-readable storage medium readable by a processing circuit and storing instructions for performing the steps of the invention by the processing circuit to perform a method.

[0023] Viewed from a further aspect, the present invention provides a computer program stored on a computer-readable medium and loadable into the internal memory of a digital computer, comprising software code portions for carrying out the steps of the invention when the program is executed on a computer.

[0024] Additional features and advantages are realized. Other embodiments and aspects are described in detail herein and are considered part of the claimed invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The present invention will now be described by way of example only with reference to preferred embodiments as illustrated in the following figures: Fig.1 illustrates an embodiment of a data processing environment according to the prior art and in which a preferred embodiment of the present invention may be implemented; Fig. 2A illustrates an example of a transaction begin (TBEGIN) instruction according to a preferred embodiment of the present invention; Fig. Figure 2B illustrates an embodiment of further details of a field of the TBEGIN instruction of Fig. 2A according to a preferred embodiment of the present invention; Fig. 3A illustrates an example of a restricted transaction begin (TBEGINC) instruction according to a preferred embodiment of the present invention; Fig. Figure 3B illustrates an embodiment of further details of a field of the TBEGINC instruction of Fig. 3A according to a preferred embodiment of the present invention; Fig.4 illustrates an example of a transaction end (TEND) instruction according to a preferred embodiment of the present invention; Fig. 5 illustrates an example of a transaction abort (TABORT) instruction according to a preferred embodiment of the present invention; Fig. 6 illustrates an example of nested transactions according to a preferred embodiment of the present invention; Fig. 7 illustrates an example of a NONTRANSACTIONAL STORE (NTSTG) instruction according to a preferred embodiment of the present invention; Fig. 8 illustrates an example of an EXTRACT TRANSACTION NESTING DEPTH (ETND) instruction according to a preferred embodiment of the present invention; Fig. 9 illustrates an example of a transaction diagnostic block according to a preferred embodiment of the present invention; Fig.10 illustrates example abort reasons along with associated abort codes and condition codes according to a preferred embodiment of the present invention; Fig. 11 illustrates one embodiment of the logic associated with creating a constrained or unconstrained transaction in accordance with a preferred embodiment of the present invention; Fig. 12 illustrates an embodiment of the logic associated with executing a transaction in which execution depends on the instruction type, according to a preferred embodiment of the present invention; Fig. 13 illustrates one embodiment of the logic associated with executing a TBEGINC instruction in accordance with a preferred embodiment of the present invention; Fig.14 illustrates one embodiment of the logic associated with ensuring completion of a TBEGINC instruction, in accordance with a preferred embodiment of the present invention; Fig. 15 illustrates one embodiment of the logic associated with executing a TBEGIN instruction in accordance with a preferred embodiment of the present invention; Fig. 16 illustrates one embodiment of the logic associated with executing a TEND instruction in accordance with a preferred embodiment of the present invention; Fig. 17A to 17B illustrate an example of inserting a queue item into a doubly linked list of queue items; Fig. 18 illustrates an embodiment of a computer program product according to the prior art and in which a preferred embodiment of the present invention may be implemented; Fig.19 illustrates an embodiment of a host computer system according to a preferred embodiment of the present invention; Fig. 20 illustrates another example of a computer system according to the prior art and in which a preferred embodiment of the present invention may be implemented; Fig. 21 illustrates another example of a computer system having a computer network according to the prior art and in which a preferred embodiment of the present invention may be implemented; Fig. 22 illustrates an embodiment of various elements of a computer system according to the prior art and in which a preferred embodiment of the present invention may be implemented; Fig. Figure 23A illustrates an embodiment of the execution unit of the computer system of Fig.22 according to a preferred embodiment of the present invention; Fig. Figure 23B illustrates an embodiment of the branching unit of the computer system of Fig. 22 according to a preferred embodiment of the present invention; Fig. Figure 23C illustrates an embodiment of the load / store unit of the computer system of Fig. 22 according to a preferred embodiment of the present invention; and Fig. 24 illustrates an embodiment of an emulated host computer system according to a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0026] According to one aspect, a transactional (TX) execution facility is provided. This facility provides transactional processing for instructions and, in one or more embodiments, offers various execution modes as well as nested levels of transactional processing, as described below.

[0027] The transactional execution facility introduces a CPU state called transactional (TX) execution mode. After a CPU reset, the CPU is not in TX mode. The CPU enters TX mode with a TRANSACTION BEGIN instruction. The CPU exits TX mode either through (a) an outermost TRANSACTION END instruction (more details on inside and outside follow) or (b) an abort of the transaction. In TX mode, memory accesses by the CPU appear to be concurrent for blocks, as observed by other CPUs and the I / O subsystem. The memory accesses are either (a) committed to memory when the outermost transaction ends without aborting (i.e.,updates made to a cache or a buffer local to the CPU are propagated and stored in real memory and become visible to other CPUs) or (b) are discarded when the transaction aborts.

[0028] Transactions can be nested. Thus, the CPU can execute another TRANSACTION BEGIN instruction while in TX mode. The instruction that causes the CPU to enter TX mode is called the outermost TRANSACTION BEGIN instruction; likewise, the program is said to be in the outermost transaction. Subsequent executions of TRANSACTION BEGIN are called inner instructions; and the program executes an inner transaction. The model provides a minimum nesting depth and a model-dependent maximum nesting depth. An EXTRACT TRANSACTION NESTING DEPTH instruction returns the current nesting depth value and, in another embodiment, can return a maximum nesting depth value.This technique uses a model called "flattened nesting" in which an abort condition at any nesting depth causes all levels of transactions to abort and control to return to the statement after the outermost TRANSACTION BEGIN.

[0029] During transaction processing, a transactional access by a CPU is said to conflict with either (a) a transactional access or a non-transactional access made by another CPU, or (b) a non-transactional access made by the I / O subsystem if both accesses are to any memory location within the same cache line and one or both of the accesses is a store. In other words, for transactional execution to be productive, no transactional accesses must be observed before a CPU commit. This programming model can be extremely powerful in certain environments; for example, updating two points in a doubly linked list of one million elements.However, it may be less effective if there is a lot of contention for the memory locations being accessed transactionally.

[0030] In one model of transactional execution (referred to herein as an unconstrained transaction), when a transaction aborts, the program can either attempt to continue executing the transaction in the hope that the termination condition no longer exists, or the program can "fall back" to an equivalent non-transactional path. In another model of transactional execution (referred to herein as a constrained transaction), an aborted transaction is automatically reexecuted by the CPU; if no constraint violations exist, eventual completion of the constrained transaction is ensured.

[0031] When starting a transaction, the program can specify various controls, such as (a) which general-purpose registers are restored to their original contents if the transaction aborts, (b) whether the transaction may modify the floating-point register context, including, for example, floating-point registers and the floating-point control register, (c) whether the transaction may modify access registers (ARs), and (d) whether certain program exceptions must be locked to avoid interruption. When an unconstrained transaction aborts, various diagnostic information can be provided. For example, the outermost TBEGIN instruction that initiates an unconstrained transaction may specify a program-specified transaction diagnostic block (TDB).Furthermore, the TDB in the CPU prefix area or specified by the host state description may also be used when the transaction is aborted due to a program interrupt or a condition that causes interpretive execution to end.

[0032] Various register types are listed above. These are explained in detail below. General purpose registers can be used as accumulators in general purpose arithmetic and logical operations. In one embodiment, each register contains 64 bit positions, and there are 16 general purpose registers. The general purpose registers are identified by the numbers 0 through 15 and are specified by a four-bit R field in an instruction. Some instructions provide addressing for multiple general purpose registers by having multiple R fields. For some instructions, the use of a specific general purpose register is implied rather than explicitly specified by an R field of the instruction.

[0033] In addition to their use as accumulators in general arithmetic and logical operations, 15 of the 16 general purpose registers are also used as base address and index registers in address generation. In these cases, the registers are specified by a four-bit B or X field in an instruction. A value of zero in the B or X field indicates that no base or index needs to be applied, and thus, a general purpose register 0 does not need to be specified to contain a base address or index.

[0034] Floating-point instructions use a group of floating-point registers. In one embodiment, the CPU has 16 floating-point registers. The floating-point registers are identified by the numbers 0 through 15 and specified by a four-bit field R in floating-point instructions. Each floating-point register is 64 bits long and can contain a short (32-bit) or a long (64-bit) floating-point operand.

[0035] A floating-point control (FPC) register is a 32-bit register that contains mask bits, mark bits, a data exception code, and rounding mode bits and is used during processing of floating-point operations.

[0036] Furthermore, in one embodiment, the CPU has 16 control registers, each having 64 bit positions. The bit positions in the registers are assigned to specific devices in the system, such as a program event record (PER) (discussed below), and are used either to indicate that an operation may occur or to provide specific information requested by the device. In one embodiment, CR0 (bits 8 and 9) and CR2 (bits 61 through 63) are used for the transaction-bound device, as described below.

[0037] For example, the CPU has 16 access registers numbered 0 through 15. An access register consists of 32 bit positions that contain an indirect specification of an address space control element (ASCE). An address space control element is a parameter used by the dynamic address translation (DAT) mechanism to translate references to a corresponding address space. When the CPU is in a mode called access register mode (controlled by bits in the program status word (PSW)), an instruction B field, used to specify a logical address for a memory operand reference, specifies an access register, and the address space control element specified by the access register is used by the DAT for the specified reference. For some instructions, an R field is used instead of a B field.Instructions are provided for loading and storing the contents of the access registers and for moving the contents of one access register to another.

[0038] Each of the access registers 1 through 15 can specify any address space. An access register 0 specifies the primary instruction space. When one of the access registers 1 through 15 is used to specify an address space, the CPU determines which address space is specified by translating the contents of the access register. When access register 0 is used to specify an address space, the CPU treats the access register as specifying the primary instruction space and does not examine the actual contents of the access register. Therefore, the 16 access registers can specify the primary instruction space and a maximum of 15 other spaces at any time.

[0039] In one embodiment, there are several types of address spaces. An address space is a continuous sequence of integers (virtual addresses) along with the specific conversion parameters that allow all numbers to be mapped to a byte location in memory. The sequence starts at zero and continues from left to right.

[0040] For example, in z / Architecture, when a virtual address is used by a CPU to access main memory (also known as main memory), it is first converted to a physical address by dynamic address translation (DAT) and then converted to an absolute address by prepending. The DAT can use one to five levels of tables (page, segment, range third, range second, and range first) as translation parameters. The specification (origin and length) of the parent table for a specific address space is called the address space control element and is found in a control register or as specified by an access register for use by the DAT.Alternatively, the address space control for an address space may be a real space specification that indicates that the DAT should translate the virtual address by simply treating it as a real address and without using any tables.

[0041] The DAT uses the address space control elements in various control registers or as specified by the access registers at different times. The choice is determined by the translation mode specified in the current PSW. Four translation modes are available: primary region mode, secondary region mode, access register mode, and output memory region mode. Different address spaces are addressable depending on the translation mode.

[0042] When the CPU is in primary range mode or secondary range mode, the CPU can translate virtual addresses belonging to two address spaces at any time—the primary address space and the secondary address space. When the CPU is in access register mode, it can translate virtual addresses of up to 16 address spaces at any time—the primary address space and up to 15 address spaces specified by the AR. When the CPU is in output memory range mode, it can translate virtual addresses of the address output memory range at any time.

[0043] The primary address space is identified as such because it consists of primary virtual addresses translated using the primary address space control element (ASCE). Likewise, the secondary address space consists of secondary virtual addresses translated using the secondary ASCE; the address spaces specified by the AR consist of virtual addresses specified by the AR and translated using ASCEs specified by the AR; and the output address space consists of output virtual addresses translated using the output ASCE. The primary and secondary ASCEs are located in control registers 1 and 7, respectively. ASCEs specified by the AR are located in ASN secondary table entries, which are found via a process called access register translation (ART) using control registers 2, 5, and 8. The output ASCE is located in control register 13.

[0044] An embodiment of a data processing environment that incorporates and utilizes one or more aspects of the transactional device described herein is described with reference to Fig. 1 described.

[0045] With reference to Fig. 1, a data processing environment 100 is based in one example on that of International Business Machines (IBM ® ) Corporation, Armonk, New York. The z / Architecture is described in an IBM publication titled "z / Architecture - Principles of Operation," Publication No. SA22-7932-08, 9th Edition, August 2010.

[0046] Other names used herein may be registered trademarks, trademarks, or product names of International Business Machines Corporation or other companies.

[0047] For example, the computing environment 100 includes a central processor complex (CPC) 102 connected to one or more input / output (I / O) units 106 via one or more control units 108. The central processor complex 102 includes, for example, one or more central processors 110, one or more partitions 112 (e.g., logical partitions (LP)), a logical partition hypervisor 114, and an input / output subsystem 115, each of which is described below.

[0048] The central processors 110 are physical processor resources associated with the logical partitions. Specifically, each logical partition 112 has one or more logical processors, each of which represents all or part of a physical processor 110 associated with the partition. The logical processors of a particular partition 112 may either be associated with the partition, so that the underlying processor resource 110 is reserved for that partition, or shared with another partition, so that the underlying processor resource is potentially available to another partition.

[0049] A logical partition functions as a separate system and has one or more applications and, optionally, an operating system resident therein, which may be different for each logical partition. In one embodiment, the operating system is the z / OS operating system, the z / VM operating system, the z / Linux operating system, or the TPF operating system, available from IBM. The logical partitions 112 are managed by a logical partition hypervisor 114, which is implemented by firmware executing on the processors 110. As used herein, firmware includes, for example, the microcode and / or millicode of the processor. It includes, for example, the hardware-level instructions and / or data structures used in an implementation of higher-level machine code.For example, in one embodiment, it includes proprietary code, typically provided as microcode, that contains trusted software or microcode specific to the underlying hardware that controls operating system access to the system hardware.

[0050] The logical partitions and the logical partition hypervisor each contain one or more programs located in respective partitions of the central memory associated with the central processors. An example of the logical partition hypervisor 114 is the Processor Resource / System Manager (PR / SM), offered by International Business Machines Corporation, Armonk, New York.

[0051] The input / output subsystem 115 transfers the flow of information between the input / output units 106 and main memory (also known as main working memory). It is connected to the central processor complex in such a way that it can be part of the central processor complex or separate from it. The I / O subsystem relieves the central processors of the task of directly exchanging data with the input / output units and allows data processing to continue concurrently with input / output processing. To provide data transfers, the I / O subsystem uses I / O data transfer adapters. There are various types of data transfer adapters, including, for example, channels, I / O adapters, PCI cards, Ethernet cards, Small Computer Storage Interface (SCSI) cards, etc.In the specific example described herein, the I / O data transfer adapters are channels, and therefore, the I / O subsystem is referred to herein as a channel subsystem. However, this is only one example. Other types of I / O subsystems may be used.

[0052] The I / O subsystem uses one or more input / output paths as data transfer connections when managing the flow of information to or from the input / output devices 106. In this particular example, these paths are referred to as channel paths because the data transfer adapters are channels.

[0053] The computing environment described above is only one example of a computing environment that may be used. Other environments, including, but not limited to, non-partitioned environments, other partitioned environments, and / or emulated environments, may be used; embodiments are not limited to any one environment.

[0054] In one or more aspects, the transactional execution facility is a CPU extension that provides the means by which the CPU can execute a sequence of instructions—known as a transaction—that may access multiple memory locations, including updating those memory locations. As observed by other CPUs and the I / O subsystem, the transaction either (a) completes in its entirety as a single atomic operation or (b) aborts, potentially leaving no evidence that it was ever executed (except under certain conditions described herein). Thus, a successfully completed transaction may update numerous memory locations without any specific locking required in the classic multiprocessor model.

[0055] The transactional execution facility includes, for example, one or more controls; one or more instructions; transactional processing including constrained and unconstrained execution; and termination processing, each of which is described below.

[0056] In one embodiment, three special-purpose control elements, including a transaction abort program status word (PSW), a transaction diagnostic block (TDB) address, and a transaction nesting depth; five control register bits; and six general-purpose instructions, including TRANSACTION BEGIN (restricted and unrestricted), TRANSACTION END, EXTRACT TRANSACTION NESTING DEPTH, TRANSACTION ABORT, and NONTRANSACTIONAL STORE, are used to control the transactional execution facility. For example, if the facility is installed, it is installed on all CPUs in the configuration. A facility indication, bit 73 in one implementation, when one, indicates that the transactional execution facility is installed.

[0057] When the transactional execution facility is installed, the configuration provides an unrestricted transactional execution facility and, optionally, a restricted transactional execution facility, each of which is described below. For example, if facility specifications 50 and 73 are both one, the restricted transactional execution facility is installed. Both facility specifications are stored in memory at specific locations.

[0058] As used herein, the TRANSACTION BEGIN instruction name refers to the instructions with the mnemonics TBEGIN (transaction begin for an unrestricted transaction) and TBEGINC (transaction begin for a restricted transaction). Discussions related to a specific instruction are indicated by the instruction name followed by the mnemonics enclosed in parentheses or square brackets, or simply by the mnemonics.

[0059] An embodiment with a TRANSACTION BEGIN (TBEGIN) statement format is described in the Fig.2A through 2B. For example, a TBEGIN instruction 200 includes an operation code field 202 containing an operation code indicating an unrestricted begin-of-transaction operation; a base field (B1) 204; a relocation field (D1) 206; and an immediate field (I2) 208. If the B1 field is nonzero, the contents of the general register indicated by B1 204 are added to D1 206 to obtain the first operand address.

[0060] If field B1 is not zero, the following applies: • If the transaction nesting depth is initially zero, the first operand address specifies the location of the 256-byte transaction diagnostic block, known as the TDB specified by TBEGIN (described in more detail below), in which various diagnostic information can be stored if the transaction aborts. If the CPU is in primary region mode or access register mode, the first operand address specifies a location in the primary address space. If the CPU is in secondary region or output memory region mode, the first operand address specifies a location in the secondary or output address space, respectively. If DAT is off, the transaction diagnostic block (TDB) address (TDBA) specifies a location in real memory.

[0061] A memory access possibility through the first operand is determined. If accessible, the logical address of the operand is placed in the transaction diagnostic block address (TDBA), and the TDBA is valid. • If the CPU is already in unrestricted transactional execution mode, the TDBA is not modified and it is unpredictable whether the first operand will be tested for accessibility.

[0062] If field B1 is null, no access exceptions are detected for the first operand, and the TDBA is invalid for the outermost TBEGIN statement.

[0063] The bits of field I2 are defined in an example as follows: General Register Storage Mask (GRSM) 210 ( Fig.2B): Bits 0 through 7 of field I2 contain the general purpose register storage mask (GRSM). Each bit of the GRSM represents an even-odd pair of general purpose registers, where bit 0 represents registers 0 and 1, bit 1 represents registers 2 and 3, and so on. If a bit in the GRSM of the outermost TBEGIN instruction is zero, the corresponding register pair is not stored. If a bit in the GRSM of the outermost TBEGIN instruction is one, the corresponding register pair is stored in a model-dependent memory location that cannot be directly accessed by the program.

[0064] If the transaction is aborted, saved register pairs are restored to their contents at the time the outermost TBEGIN instructions were executed. The contents of all other (unsaved) general purpose registers are not restored when a transaction is aborted.

[0065] The general register storage mask is ignored in all TBEGINs except the outermost one.

[0066] Allow AR Modification (A) 212: The A control, bit 12 of field I2, controls whether the transaction is allowed to modify an access register. The effective control for Allow AR Modification is the logical AND of the A control in the TBEGIN statement for the current nesting level and for all outer levels.

[0067] If the effective A control is zero, the transaction aborts with abort code 11 (restricted instruction) if an attempt is made to modify any access register. If the effective A control is one, the transaction does not abort if an access register is modified (unless any other abort condition exists).

[0068] Allow Floating-Point Operation (F) 214: The F control, bit 13 of field I2, controls whether the transaction may modify specified floating-point instructions. The effective control for Allow Floating-Point Operation is the logical AND of the F control in the TBEGIN statement for the current nesting level and for all outer levels.

[0069] If the effective F-control is zero, (a) the transaction aborts with abort code 11 (restricted instruction) if an attempt is made to execute a floating-point instruction, and (b) the data exception code (DXC) in byte 2 of the floating-point control register (FPCR) is not set by any data exception program exception condition. If the effective F-control is one, (a) the transaction does not abort if an attempt is made to execute a floating-point instruction (if no other abort condition exists), and (b) the DXC in the FPCR may be set by a data exception program exception condition.

[0070] Program Interrupt Filter Control (PIFC) 216: Bits 14 through 15 of field I2 are the program interrupt filter control (PIFC). The PIFC controls whether certain classes of program exceptions (e.g., addressing exception, data exception, operation exception, protection exception, etc.) that occur while the CPU is in transactional execution mode result in an interrupt.

[0071] The effective PIFC is the highest value of the PIFC in the TBEGIN instruction for the current nesting level and for all outer levels. If the effective PIFC is zero, all program exceptions cause an interrupt. If the effective PIFC is one, program exceptions with transactional execution classes of 1 and 2 cause an interrupt. (Each program exception is assigned at least one transactional execution class, which depends on the severity of the exception. The severity is based on the probability of recovery during repeated execution of transactional execution and whether the operating system must recognize the interrupt.) If the effective PIFC is two, program exceptions with transactional execution class 1 cause an interrupt. A PIFC of 3 is reserved.

[0072] Bits 8 to 11 of field I2 (bits 40 to 43 of the instruction) are reserved and should contain zeros; otherwise, the program will not be able to operate compatibly in the future.

[0073] An embodiment of a format of a restricted transaction start instruction (TBEGINC) is described with reference to the Fig.3A through 3B. In one example, TBEGINC 300 includes an opcode field 302 containing an opcode indicating a restricted begin-of-transaction operation; a base field (B1) 304; a relocation field (D1) 306; and an immediate field (I2) 308. The contents of the general purpose register indicated by B1 304 are added to D1 306 to obtain the first operand address. However, for a restricted begin-of-transaction instruction, the first operand address is not used to access memory. Instead, the instruction's B1 field contains zeros; otherwise, a specification exception is detected.

[0074] In one embodiment, field I2 contains various controls, an example of which is shown in Fig. 3B is shown.

[0075] The bits of field I2 are defined in an example as follows: General Register Storage Mask (GRSM) 310: Bits 0 through 7 of field I2 contain the general register storage mask (GRSM). Each bit of the GRSM represents an even-odd pair of general registers, where bit 0 represents registers 0 and 1, bit 1 represents registers 2 and 3, and so on. If a bit in the GRSM is zero, the corresponding register pair is not stored. If a bit in the GRSM is one, the corresponding register pair is stored in a model-dependent memory location that cannot be directly accessed by the program.

[0076] If the transaction is aborted, saved register pairs are restored to their contents at the time of execution of the outermost TRANSACTION BEGIN statement. The contents of all other (unsaved) general purpose registers are not restored when a restricted transaction is aborted.

[0077] When TBEGINC is used to continue execution in the unrestricted transaction execution mode, the general register storage mask is ignored.

[0078] Allow AR Modification (A) 312: The A control, bit 12 of field I2, controls whether the transaction may modify an access register. The effective control for Allow AR Modification is the logical AND of the A control in the TBEGINC instruction for the current nesting level and for all outer TBEGIN or TBEGINC instructions.

[0079] If the effective A control is zero, the transaction aborts with abort code 11 (restricted instruction) if an attempt is made to modify any access register. If the effective A control is one, the transaction does not abort if an access register is modified (unless any other abort condition exists).

[0080] Bits 8 to 11 and 13 to 15 of field I2 (bits 40 to 43 and 45 to 47 of the instruction) are reserved and should contain zeros.

[0081] The end of a transaction start statement is indicated by a TRANSACTION END (TEND) statement, for which a format in Fig. 4. For example, a TEND instruction 400 includes an operation code field 402 that contains an operation code indicating an end-of-transaction operation.

[0082] A number of terms are used in reference to the transactional execution facility, and therefore, for convenience only, a list of terms is provided below in alphabetical order. In one embodiment, these terms have the following definition: Abort: A transaction is aborted if it ends before a TRANSACTION END statement, resulting in a transaction nesting depth of zero. When a transaction is aborted, in one embodiment, the following occurs: • Transactional memory accesses made by any and all levels of the transaction are discarded (i.e., not committed). • Non-transactional memory accesses made by any and all levels of the transaction are committed. • Registers specified by the general-purpose register save mask (GRSM) of the outermost TRANSACTION BEGIN instruction are restored to their contents prior to transactional execution (that is, to their contents at the time of execution of the outermost TRANSACTION BEGIN instruction). General-purpose registers not specified by the general-purpose register save mask of the outermost TRANSACTION BEGIN instruction are not restored. • Access registers, floating-point registers, and floating-point control registers are not restored. Any changes made to these registers during transaction execution are retained if the transaction is aborted.

[0083] A transaction can be aborted for a variety of reasons, including an attempted execution of a restricted statement, an attempted modification of a restricted resource, a transaction-related conflict, an exceedance of various CPU resources, any interpretive execution trap, any interrupt, a TRANSACTION ABORT statement, and more. A transaction abort code provides specific reasons why a transaction may be aborted.

[0084] An example of a TRANSACTION ABORT (TABORT) statement format is shown with reference to Fig.5. For example, a TABORT instruction 500 includes an operation code field 502 containing an operation code specifying a transaction abort operation; a base field (B2) 504; and a displacement field (D2) 506. If the B2 field is nonzero, the contents of the general register specified by B2 504 are added to D2 506 to obtain a second operand address; otherwise, the second operand address is formed from the D2 field alone, and the B2 field is ignored. The second operand address is not used to address data; instead, the address forms the transaction abort code, which is placed in a transaction diagnostic block during abort processing. Address calculation for the second operand address follows address arithmetic rules: in 24-bit addressing mode, bits 0 through 29 are set to zeros; In 31-bit addressing mode, bits 0 to 32 are set to zeros.

[0085] Commit: Upon completion of an outermost TRANSACTION END instruction, the CPU commits the memory accesses made by the transaction (i.e., the outermost transaction and all nested levels) so that they are visible to other CPUs and the I / O subsystem. As observed by other CPUs and the I / O subsystem, all fetch and memory accesses made by all nested levels of the transaction appear to occur as a single concurrent operation when the commit occurs.

[0086] The contents of the general registers, access registers, floating-point registers, and the floating-point control register are not modified by the commit process. Any changes made to these registers during a transaction-bound execution are retained when the transaction's stores are committed.

[0087] Conflict: A transactional access by a CPU conflicts with either (a) a transactional access or a non-transactional access made by another CPU or (b) a non-transactional access made by the I / O subsystem if both accesses are to any memory location within the same cache line and one or more of the accesses is a store.

[0088] A conflict can be detected by a CPU's speculative execution of instructions, even if the conflict is not detected in the conceptual sequence.

[0089] Restricted transaction: A restricted transaction is a transaction that is executed in the restricted transaction-bound execution mode and is subject to the following restrictions: • A subset of general instructions is available. • A limited number of instructions can be executed. • Access can be made to a limited number of memory operand locations. • The transaction is limited to a single nested level.

[0090] If there are no repeated interrupts or conflicts with other CPUs or the I / O subsystem, a restricted transaction will eventually terminate, thus eliminating the need for an abort handler. Restricted transactions are described in detail below.

[0091] If a restricted TRANSACTION BEGIN (TBEGINC) instruction is executed while the CPU is already in unconstrained transaction execution mode, execution continues as a nested unconstrained transaction.

[0092] Restricted transactional execution mode: If the transaction nesting depth is zero and a transaction is initiated by a TBEGINC instruction, the CPU enters restricted transactional execution mode. While the CPU is in restricted transactional execution mode, the transaction nesting depth is one.

[0093] Nested transaction: If the TRANSACTION BEGIN statement is issued while the CPU is in unrestricted transactional execution mode, the transaction is nested.

[0094] The transactional execution facility uses a model called flattened nesting. In flattened nesting mode, stores made by an inner transaction are not observable by other CPUs or the I / O subsystem until the outermost transaction commits its stores. Similarly, when a transaction aborts, all nested transactions are aborted, and all transactional stores of all nested transactions are discarded.

[0095] An example of nested transactions is shown in Fig.6. As shown, TBEGIN 600 starts an outermost transaction 601, TBEGIN 602 starts a first nested transaction, and TBEGIN 604 starts a second nested transaction. In this example, TBEGIN 604 and TEND 606 define an innermost transaction 608. When TEND 610 executes, transaction-bound stores for the outermost transaction and all inner transactions are committed 612.

[0096] Unconstrained transaction: An unconstrained transaction is a transaction executed in the unconstrained transactional execution mode. Although an unconstrained transaction is not constrained in the same way as a constrained transaction, it can still be aborted for a variety of reasons.

[0097] Unrestricted transactional execution mode: When a transaction is initiated by the TBEGIN instruction, the CPU enters unrestricted transactional execution mode. While the CPU is in unrestricted transactional execution mode, the transaction nesting depth can vary from one to the maximum transaction nesting depth.

[0098] Non-transactional access: Non-transactional accesses are memory operand accesses performed by the CPU when it is not in transactional execution mode (i.e., classic memory accesses outside of a transaction). Furthermore, accesses performed by the I / O subsystem are non-transactional accesses. Furthermore, the NONTRANSACTIONAL STORE instruction can be used to cause a non-transactional memory access while the CPU is in unrestricted transactional execution mode.

[0099] An embodiment of a format of a NONTRANSACTIONAL STORE instruction is described with reference to Fig.7. For example, a NONTRANSACTIONAL STORE instruction 700 includes a plurality of operation code fields 702a, 702b specifying an operation code indicating a non-transactional store operation; a register field (R1) 704 specifying a register whose contents are designated as the first operand; an index field (X2) 706; a base field (B2) 708; a first displacement field (DL2) 710; and a second displacement field (DH2) 712. The contents of the general purpose registers specified by the X2 and B2 fields are added to the contents of a concatenation of contents of the DH2 and DL2 fields to form the second operand address. If either or both of the X2 or B2 fields are zero, the corresponding register does not participate in the addition.

[0100] The first 64-bit operand is placed unchanged in the second operand memory location in a non-transactional manner.

[0101] The shift formed by concatenating the DH2 and DL2 fields is treated as a 20-bit signed binary integer.

[0102] The second operand must be aligned on a doubleword boundary; otherwise, a specification exception is detected and the operation is suppressed.

[0103] Outer / Outermost transaction: A transaction with a small transaction nesting depth is an outer transaction. A transaction with a transaction nesting depth value of one is the outermost transaction.

[0104] An outermost TRANSACTION BEGIN statement is one that executes when the transaction nesting depth is initially zero. An outermost TRANSACTION END statement is one that causes the transaction nesting depth to transition from one to zero. A constrained transaction is the outermost transaction in this embodiment.

[0105] Program interrupt filtering: If a transaction is aborted due to certain program exceptions, the program can optionally prevent the interrupt from occurring. This technique is called program interrupt filtering. Program interrupt filtering is subject to the transactional interrupt class, the effective program interrupt filter control from the TRANSACTION BEGIN statement, and an override of the transactional execution program interrupt filtering in control register 0.

[0106] Transaction: A transaction contains the memory operand accesses and selected general-purpose registers modified while the CPU is in transactional execution mode. In an unrestricted transaction, the memory operand accesses can include both transactional and non-transactional accesses. In a restricted transaction, the memory operand accesses are limited to transactional accesses. As observed by other CPUs and by the I / O subsystem, all memory operand accesses made by the CPU while in transactional execution mode appear to occur as a single concurrent operation.When a transaction is aborted, transactional memory accesses are discarded, and all registers specified by the general register memory mask of the outermost TRANSACTION BEGIN instruction are restored to their contents prior to transactional execution.

[0107] Transactional accesses: Transactional accesses are memory operand accesses that occur while the CPU is in transactional execution mode, excluding accesses made by the NONTRANSACTIONAL STORE instruction.

[0108] Transactional execution mode: The term transactional execution mode (also known as transactional execution mode) describes the general operation of both the unconstrained and constrained transactional execution modes. Therefore, when describing the operation, the terms "unconstrained" and "constrained" are used to refer to the transactional execution mode.

[0109] When the transaction nesting depth is zero, the CPU is not in transactional execution mode (also called non-transactional execution mode).

[0110] As observed by the CPU, fetches and stores in transactional execution mode are no different from those made when it is not in transactional execution mode.

[0111] In one embodiment of the z / Architecture, the transactional execution means is under the control of bits 8 through 9 of control register 0, bits 61 through 63 of control register 2, the transaction nesting depth, the transaction diagnostic block address, and the transaction abort program status word (PSW).

[0112] After an initial CPU reset, the contents of bit positions 8 through 9 of control register 0, bit positions 62 through 63 of control register 2, and the transaction nesting depth are set to zero. If the transactional execution control, bit 8 of control register 0, is zero, the CPU cannot enter transactional execution mode.

[0113] Further details regarding the various controls are described below.

[0114] As stated, the transaction-bound execution facility is controlled by two bits in control register 0 and three bits in control register 2. Example: Control Register 0 Bits: In one embodiment, the bit assignment is as follows: Transactional Execution Control (TXC): Bit 8 of control register 0 is the transactional execution control. This bit provides a mechanism by which the control program (e.g., operating system) can indicate whether the transactional execution facility can be used by the program. Bit 8 must be one for successful entry into transactional execution mode.

[0115] If bit 8 of control register 0 is zero, an attempt to execute the EXTRACT TRANSACTION NESTING DEPTH, TRANSACTION BEGIN, and TRANSACTION END instructions results in the execution of a special operation.

[0116] An embodiment of a format of an EXTRACT TRANSACTION NESTING DEPTH statement is described with reference to Fig. 8. For example, an EXTRACT TRANSACTION NESTING DEPTH instruction 800 includes an operation code field 802 specifying an operation code that indicates the operation of extracting the transaction nesting depth; and a register field R1 804 specifying a general register.

[0117] The current transaction nesting depth is placed in bits 48 to 63 of the general register R1. Bits 0 to 31 of the register remain unchanged, and bits 32 to 47 of the register are set to zero.

[0118] In another embodiment, the maximum transaction nesting depth is also placed in the general register R1, such as bits 16 to 31.

[0119] Transactional Execution Program Interrupt Filtering Override (PIFO): Bit 9 of Control Register 0 is the transactional execution program interrupt filtering override. This bit provides a mechanism by which the control program can ensure that any program exception condition that occurs while the CPU is in transactional execution mode results in an interrupt, regardless of the effective program interrupt filtering control specified or implied by the TRANSACTION BEGIN instruction(s).

[0120] Control Register 2 Bits: In one embodiment, the assignments are as follows: Transaction Diagnostic Scope (TDS): Bit 61 of Control Register 2 controls the applicability of the Transaction Diagnostic Control (TDC) element in bits 62 to 63 of the register as follows: TDS Value Meaning 0 The TDC is applied regardless of whether the CPU is in the problem or monitor state. 1 The TDC is only applied when the CPU is in the problem state. When the CPU is in the monitor state, processing occurs as if the TDC contained zero.

[0121] Transaction Diagnostic Control (TDC): Bits 62 through 63 of Control Register 2 are a 2-bit unsigned integer that can be used to cause transactions to be arbitrarily aborted for diagnostic purposes. The TDC encryption, in one embodiment, is as follows: TDC Value Meaning 0 Normal operation, transactions are not aborted as a result of the TDC. 1 Abort any transaction at any instruction, but before the outermost TRANSACTION END instruction is executed. 2 Aborting arbitrary transactions upon arbitrary instruction. 3 Reserved

[0122] If a transaction is aborted due to a non-zero TDC, one of the following cases can occur: • The abort code is set to any of the codes 7 through 11, 13 through 16, or 255, with the code value chosen arbitrarily by the CPU; the condition code is set according to the abort code. Abort codes are described in more detail below. • For an unrestricted transaction, the condition code is set to one. In this case, the abort code is not applicable.

[0123] It depends on the model whether the TDC value 1 is implemented. If it is not implemented, a value of 1 acts as if 2 were specified.

[0124] For a restricted transaction, a TDC value of 1 is treated as if a TDC value of 2 were specified.

[0125] If a TDC value of 3 is specified, the results are unpredictable. Transaction Diagnostic Block Address (TDBA)

[0126] A valid transaction diagnostic block address (TDBA) is set from the first operand address of the outermost TRANSACTION BEGIN (TBEGIN) instruction if the B1 field of the instruction is nonzero. When the CPU is in primary range or access register mode, the TDBA specifies a location in the primary address space. When the CPU is in secondary range or output range mode, the TDBA specifies a location in the secondary or output address space, respectively. If DAT (Dynamic Address Translation) is disabled, the TDBA specifies a location in real memory.

[0127] The TDBA is used by the CPU to locate the transaction diagnostic block—referred to as the TDB specified by TBEGIN—if the transaction is subsequently aborted. The three least significant bits of the TDBA are zero, indicating that the TDB specified by TBEGIN is on a double-word boundary.

[0128] If the B1 field of the outermost TRANSACTION BEGIN (TBEGIN) statement is null, the transaction-bound diagnostic block address is invalid, and no TDB specified by TBEGIN is saved if the transaction is subsequently aborted. Transaction Abort PSW (TAPSW)

[0129] If the nesting depth is initially zero during execution of the TRANSACTION BEGIN (TBEGIN) statement, the transaction abort PSW is set to the contents of the current PSW, and the instruction address of the transaction abort PSW specifies the next instruction (that is, the instruction after the outermost TBEGIN). If the nesting depth is initially zero during execution of the TRANSACTION BEGIN (TBEGIN) statement, the transaction abort PSW is set to the contents of the current PSW, except that the instruction address of the transaction abort PSW specifies the TBEGIN instruction (rather than the next instruction after TBEGIN).

[0130] When a transaction aborts, the condition code in the transaction abort PSW is replaced with a code indicating the severity of the abort condition. If the transaction aborted due to reasons that do not lead to a break, the PSW is subsequently loaded from the transaction abort PSW; if the transaction aborted due to reasons that lead to a break, the transaction abort PSW is stored as the old break PSW.

[0131] The transaction abort PSW is not changed during the execution of each inner TRANSACTION BEGIN statement. Transaction nesting depth (TND)

[0132] For example, the transaction nesting depth is a 16-bit unsigned value that is incremented each time a TRANSACTION BEGIN statement completes with a condition code of 0 and decremented each time a TRANSACTION END statement completes. The transaction nesting depth is reset to zero when a transaction is aborted or the CPU is reset.

[0133] In one embodiment, a maximum TND of 15 is implemented.

[0134] While the CPU is in restricted transactional execution mode, the transaction nesting depth in an implementation is one. Although the maximum TND can be represented as a 4-bit value, the TND is additionally defined as a 16-bit value to facilitate its examination in the transaction diagnostic block. Transaction Diagnostic Block (TDB)

[0135] When a transaction aborts, various state information can be stored in a transaction diagnostic block (TDB) as follows: 1. TDB specified by TBEGIN: For an unrestricted transaction, if the B1 field of the outermost TBEGIN instruction is non-zero, the first operand address of the instruction specifies the TDB specified by TBEGIN. This is a memory location specified by an instruction program that can be examined by the application's abort processing routine. 2. Program Interruption (PI) TDB: When an unconstrained transaction aborts due to an unfiltered program exception, or when a constrained transaction aborts due to any program exception (i.e., any condition that results in a program interrupt that is detected), the PI TDB is stored in memory locations in the prefix area. This is available to the operating system for examination and de-registration in any diagnostic report that may be provided. 3. Intercept TDB: If the transaction is aborted due to any program exception that results in an interrupt (that is, the condition that causes interpretive execution to end and control to return to the host program), a TDB is stored in a memory location specified in the state description block for the guest operating system.

[0136] In one embodiment, the TDB specified by TBEGIN is only saved if the TDB address is valid (that is, if field B1 of the outermost TBEGIN instruction is nonzero).

[0137] For aborts due to unfiltered program exceptions, either only the PI TDB or the interceptor TDB is stored. Thus, zero, one, or two TDBs can be stored for an abort.

[0138] Further details regarding an example of each of the TDBs are described below: TDB specified by TBEGIN: The 256-byte memory location specified by a valid transaction diagnostic block address. If the transaction diagnostic block address is valid, the TDB specified by TBEGIN is stored on a transaction abort. The TDB specified by TBEGIN is subject to any memory protection mechanisms in effect during the execution of the outermost TRANSACTION BEGIN statement. A PER (Program Event Recording) memory change event for each section of the TDB specified by TBEGIN is detected during the execution of the outermost TBEGIN, not during transaction abort processing.

[0139] One purpose of the PER is to aid in debugging programs. It allows the program to warn about the following types of events, such as: • Execution of a successful branch instruction. This option is provided so that an event occurs only if the branch target location is within the specified memory range. • Fetch an instruction from the specified memory area. • Changes to the contents of the specified memory range. This option is provided so that an event only occurs if the memory range is within the specified address space. • Execution of a STORE USING REAL ADDRESS statement. • Execution of the TRANSACTION END statement.

[0140] The program may selectively specify that one or more of the above types of events be detected, except that the STORE USING REAL ADDRESS event may only be specified in conjunction with the memory change event. Information regarding a PER event is provided by the program via a program interrupt, with the cause of the interrupt identified in the interrupt code.

[0141] If the transaction diagnostic block address is not valid, a TDB specified by TBEGIN is not saved.

[0142] Program Interrupt TDB: Real memory locations 6144 to 6399 (1800 to 18FF hex). The program interrupt TDB is stored when a transaction is aborted due to a program interrupt. If a transaction is aborted due to other reasons, the contents of the program interrupt TDB are unpredictable.

[0143] The program interrupt TDB is not subject to any protection mechanisms. PER memory change events are not recognized for the program interrupt TDB if they are saved during a program interrupt.

[0144] Trap TDB: The real 256-byte host memory location specified by locations 488 through 495 of the state description. The trap TDB is stored when an aborted transaction results in a guest interrupt trap (i.e., a trap code 8). If a transaction is aborted for other reasons, the contents of the trap TDB are unpredictable. The trap TDB is not subject to any protection mechanisms.

[0145] As in Fig. 9, the fields of a transaction diagnostic block 900 in one embodiment are as follows: Format 902: Byte 0 contains a validity and format specification as follows: Value Meaning 0 The remaining fields of the TDB are unpredictable. 1 A Format 1 TDB, the remaining fields of which are described below. 2 to 255 Reserved

[0146] A TDB in which the format field is null is called a null TDB

[0147] Markers 904: Byte 1 contains various information as follows: Conflict Token Validity (CTV): When a transaction aborts due to a fetch or store conflict (i.e., abort code 9 or 10, respectively), bit 0 of byte 1 is the conflict token validity indication. If the CTV indication is one, the conflict token 910 in bytes 16 through 23 of the TDB contains the logical address where the conflict was detected. If the CTV indication is zero, bytes 16 through 23 of the TDB are unpredictable.

[0148] If a transaction aborts for any reason other than a fetch or store conflict, bit 0 of byte 1 is stored as zero.

[0149] Constrained Transaction Indication (CTI): If the CPU is in constrained transactional execution mode, bit 1 of byte 1 is set to one. If the CPU is in unconstrained transactional execution mode, bit 1 of byte 1 is set to zero.

[0150] Reserved: Bits 2 to 7 of byte 1 are reserved and stored as zeros.

[0151] Transaction Nesting Depth (TND) 906: Bytes 6 to 7 contain the transaction nesting depth if the transaction was aborted.

[0152] Transaction Abort Code (TAC) 908: Bytes 8 through 15 contain a 64-bit unsigned transaction abort code. Each code point specifies a reason for aborting a transaction.

[0153] It depends on the model whether the transaction abort code is stored in the program interrupt TDB when a transaction is aborted due to conditions other than a program interrupt.

[0154] Conflict Token 910: For transactions aborted due to a fetch or store conflict (i.e., abort codes 9 and 10, respectively), bytes 16 through 23 contain the logical address of the memory location where the conflict was detected. The conflict token is meaningful if the CTV bit, bit 0 of byte 1, is one.

[0155] If the CTV bit is zero, bytes 16 to 23 are unpredictable.

[0156] Because of the speculative execution by the CPU, the conflict token may specify a memory location that would not necessarily be accessed by the transaction's conceptual execution sequence.

[0157] Instruction Address of Aborted Transaction (ATIA) 912: Bytes 24 through 31 contain an instruction address that identifies the instruction that was executing when an abort was detected. If a transaction aborts due to abort codes 2, 5, 6, 11, 13, or 256 or higher, or if a transaction aborts due to abort codes 4 or 13 and the program exception is set to a zero value, the ATIA points directly to the instruction that was executing. If a transaction aborts due to abort codes 4 or 12 and the program exception is not set to a zero value, the ATIA points beyond the instruction that was executing.

[0158] When a transaction aborts due to abort codes 7 to 10, 14 to 16, or 255, the ATIA does not necessarily indicate the exact instruction that caused the abort, but may point to an earlier or later instruction within the transaction.

[0159] If a transaction aborts due to an instruction that is the target of an Execute instruction, the ATIA identifies the Execute instruction by pointing either to the instruction or after it, depending on the abort code, as described above. The ATIA does not specify the target of the Execute instruction.

[0160] The ATIA is subject to the addressing mode when the transaction is aborted. In 24-bit addressing mode, bits 0 through 40 of the field contain zeros. In 31-bit addressing mode, bits 0 through 32 of the field contain zeros.

[0161] It depends on the model whether the instruction address of the aborted transaction is stored in the program interrupt TDB when a transaction is aborted due to conditions other than a program interrupt.

[0162] If a transaction aborts due to abort codes 4 or 12 and the program exception is not set to a zero value, the ATIA does not point to the instruction causing the abort. By subtracting the number of halfwords specified by the interrupt length code (ILC) from the ATIA, the instruction causing the abort can be identified in conditions that suppress or exit, or for non-PER events that exit. If a transaction aborts due to a PER event and no further program exception is present, the ATIA is unpredictable.

[0163] If the transaction diagnostic block address is valid, the ILC can be examined in the program interrupt identifier (PIID) in bytes 36 through 39 of the TDB specified by TBEGIN. If filtering is not applicable, the ILC can be examined in the PIID at locations 140 through 143 in real memory.

[0164] Exception Access Identifier (EAID) 914: For transactions aborted due to certain filtered program exceptions, byte 32 of the TDB specified by TBEGIN contains the exception access identifier. In a z / Architecture example, the format of the EAID and the cases for which it is stored are the same as those described in real storage location 160 when the exception results in an interrupt, as described in the aforementioned "Principles of Operation."

[0165] For transactions aborted for other reasons, including any exceptions that result in a program interrupt, byte 32 is unpredictable. Byte 32 is unpredictable in the program interrupt TDB.

[0166] This field is stored only in the TDB specified by the transaction diagnostic block address; otherwise, the field is reserved. The EAID is stored only for access-list-controlled or DAT protection, type ASCE, page translation, range-first translation, range-second translation, range-third translation, and segment translation program exceptions.

[0167] Data Exception Code (DXC) 916: For transactions aborted due to filtered data exception program exceptions, byte 33 of the TDB specified by TBEGIN contains the data exception code. In a z / Architecture example, the format of the DXC and the cases for which it is stored are the same as those described in real storage location 147 when the exception condition results in an interrupt, as described in the aforementioned "Principles of Operation." In one example, storage location 147 contains the DXC.

[0168] For transactions aborted for other reasons, including any exceptions that result in a program interrupt, byte 33 is unpredictable. Byte 33 is unpredictable in the program interrupt TDB.

[0169] This field is stored only in the TDB specified by the transaction diagnostic block address; otherwise, the field is reserved. The DXC is stored only for data program exceptions.

[0170] Program Interrupt Identifier (PIID) 918: For transactions aborted due to filtered program exceptions, bytes 36 through 39 of the TDB specified by TBEGIN contain the program interrupt identifier. In a z / Architecture example, the format of the PIID is the same as that described in real memory locations 140 through 143 when the condition results in an interrupt (as described in the aforementioned "Principles of Operation"), except that the instruction length code in bits 13 through 14 of the PIID refers to the instruction in which the exception was detected.

[0171] For transactions aborted for other reasons, including exceptions that result in a program interrupt, bytes 36 through 39 are unpredictable. Bytes 36 through 39 are unpredictable in the program interrupt TDB.

[0172] This field is stored only in the TDB specified by the transaction diagnostic block address; otherwise, the field is reserved. The program interrupt identifier is stored only for program exceptions.

[0173] Translation Exception Identifier (TEID) 920: For transactions aborted due to any of the following filtered program exception conditions, bytes 40 through 47 of the TDB specified by TBEGIN contain the translation exception identifier. • Access list controlled or DAT protection • ASCE type • Page implementation • Initial implementation • Secondary implementation • Third-party implementation • Segment implementation exception

[0174] In a z / Architecture example, the format of the TEID is the same as that described in real memory locations 168 through 175 when the condition results in an interrupt, as described in the aforementioned "Principles of Operation."

[0175] For transactions aborted for other reasons, including exceptions that result in a program interrupt, bytes 40 through 47 are unpredictable. Bytes 40 through 47 are unpredictable in the program interrupt TDB.

[0176] This field is stored only in the TDB specified by the transaction diagnostic block address; otherwise, the field is reserved.

[0177] Interrupt Event Address 922: For transactions aborted due to filtered program exceptions, bytes 48 through 55 of the TDB specified by TBEGIN contain the interrupt event address. In a z / Architecture example, the format of the interrupt event address is the same as that described in real memory locations 272 through 279 if the condition results in an interrupt, as described in the aforementioned "Principles of Operation."

[0178] For transactions aborted for other reasons, including exceptions that result in a program interrupt, bytes 48 through 55 are unpredictable. Bytes 48 through 55 are unpredictable in the program interrupt TDB.

[0179] This field is stored only in the TDB specified by the transaction diagnostic block address; otherwise, the field is reserved.

[0180] Further details regarding interrupt events are described below.

[0181] When the PER-3 facility is installed in an embodiment of the z / Architecture, it provides the program with the address of the last instruction to cause an interrupt in subsequent CPU execution. A record of the interrupt event address can be used as a debugging aid for detecting a bad branch. This facility, for example, provides a 64-bit register in the CPU called the interrupt event address register. Whenever an instruction other than TRANSACTION ABORT causes an interrupt in subsequent instruction execution (i.e., the instruction address in the PSW is replaced rather than incremented by the length of the instruction), the address of that instruction is placed in the interrupt event address register.Whenever a program interrupt occurs, regardless of whether the PER is specified, the current contents of the interrupt event address register are placed in the real memory locations 272 to 279.

[0182] If the instruction causing the interrupt event is the target of an execute type instruction (EXECUTE or EXECUTE RELATIVE LONG), the instruction address used to fetch the execute type instruction is placed in the interrupt event address register.

[0183] In one embodiment of z / Architecture, a break event is considered to occur whenever any of the following instructions causes a branch: BRANCH AND LINK (BAL, BALR); BRANCH AND SAVE (BAS, BASR); BRANCH AND SAVE AND SET MODE (BASSM); BRANCH AND SET MODE (BSM); BRANCH AND STACK (BAKR); BRANCH ON CONDITION (BC, BCR); BRANCH ON COUNT (BCT, BCTR, BCTG, BCTGR); BRANCH ON INDEX HIGH (BXH, BXHG); BRANCH ON INDEX LOW OR EQUAL (BXLE, BXLEG); BRANCH RELATIVE ON CONDITION (BRC); BRANCH RELATIVE ON CONDITION LONG (BRCL); BRANCH RELATIVE ON COUNT (BRCT, BRCTG); BRANCH RELATIVE ON INDEX HIGH (BRXH, BRXHG); BRANCH RELATIVE ON INDEX LOW OR EQUAL (BRXLE, BRXLG); COMPARE AND BRANCH (CRB, CGRB); COMPARE AND BRANCH RELATIVE (CRJ, CGRJ); COMPARE IMMEDIATE AND BRANCH (CIB, CGIB); COMPARE IMMEDIATE AND BRANCH RELATIVE (CIJ, CGIJ); COMPARE LOGICAL AND BRANCH (CLRB, CLGRB); COMPARE LOGICAL AND BRANCH RELATIVE (CLRJ, CLGRJ);COMPARE LOGICAL IMMEDIATE AND BRANCH (CLIB, CLGIB); and COMPARE LOGICAL IMMEDIATE AND BRANCH RELATIVE (CLIJ, CLGIJ).;

[0184] An interrupt event is also assumed to occur upon completion of any of the following statements: BRANCH AND SET AUTHORITY (BSA); BRANCH IN SUBSPACE GROUP (BSG); BRANCH RELATIVE AND SAVE (BRAS); BRANCH RELATIVE AND SAVE LONG (BRASL); LOAD PSW (LPSW); LOAD PSW EXTENDED (LPSWE); PROGRAM CALL (PC); PROGRAM RETURN (PR); PROGRAM TRANSFER (PT); PROGRAM TRANSFER WITH INSTANCE (PTI); RESUME PROGRAM (RP); and TRAP (TRAP2, TRAP4).

[0185] An interrupt event is not expected to occur as a result of a transaction being aborted (either implicitly or as a result of the TRANSACTION ABORT statement).

[0186] Model-dependent diagnostic information 924: Bytes 112 to 127 contain model-dependent diagnostic information.

[0187] For all abort codes except 12 (filtered program interrupt), the model-dependent diagnostic information is stored in each stored TDB.

[0188] In one embodiment, the model-dependent diagnostic information includes the following: • Bytes 112 through 119 contain a 64-bit vector called transactional execution branch information (TXBI). Each of the first 63 bits of the vector specifies the results of executing a branch instruction when the CPU was in transactional execution mode, as follows: Value Meaning 0 The statement ended without branching. 1 The statement ended with branching.

[0189] Bit 0 represents the result of the first such branch instruction, bit 1 represents the result of the second such instruction, and so on.

[0190] If fewer than 63 branch instructions were executed while the CPU was in transactional execution mode, the least significant bits that do not correspond to branch instructions are set to zeros (including bit 63). If more than 63 branch instructions were executed, bit 63 of the TXBI is set to one.

[0191] Bits in the TXBI are set by instructions capable of causing an interrupt event as listed above, except for the following: - Not every restricted instruction causes a bit to be set in the TXBI. - For z / Architecture instructions, for example, it is model-dependent whether instruction execution causes a bit to be set in the TXBI if the M1 field of the BRANCH ON CONDITION, BRANCH RELATIVE ON CONDITION, or BRANCH RELATIVE ON CONDITION LONG instruction is zero, or if the R2 field of the following instructions is zero. • BRANCH AND LINK (BALR); BRANCH AND SAVE (BASR); BRANCH AND SAVE AND SET MODE (BASSM); BRANCH AND SET MODE (BSM); BRANCH ON CONDITION (BCR); and BRANCH ON COUNT (BCTR, BCTGR). • For termination conditions caused by a host access exception, bit position 0 of byte 127 is set to one. For all other termination conditions, bit position 0 of byte 127 is set to zero. • For abort conditions detected by the load / store unit (LSU), the five least significant bits of byte 127 contain an indication of the cause. For abort conditions not detected by the LSU, byte 127 is reserved.

[0192] General Register 930: Bytes 128 to 255 contain the contents of general registers 0 to 15 at the time the transaction was aborted. The registers are stored in ascending order, starting with general register 0 in bytes 128 to 135, general register 1 in bytes 126 to 143, and so on.

[0193] Reserved: All other fields are reserved. Unless otherwise specified, the contents of reserved fields are unpredictable.

[0194] As observed by other CPUs and the I / O subsystem, a save to the TDB(s) during a transaction abort is a multiple access reference that occurs after any non-transactional save.

[0195] A transaction may be aborted due to causes outside the scope of the immediate configuration in which it is executing. For example, volatile events detected by a hypervisor (such as LPAR or zNM) may cause a transaction to abort.

[0196] The information provided in the transaction diagnostic block is intended for diagnostic purposes and is substantially correct. However, because an abort may be caused by an event outside the scope of the immediate configuration, information such as the abort code or program interrupt identifier may not accurately reflect conditions within the configuration and thus should not be used to determine program action.

[0197] If a transaction aborts due to any data exception program exception condition, and both the AFP register control element, bit 45 of control register 0, and the effective floating-point operation control element (F) are one, in addition to the diagnostic information stored in the TDB, the data exception code (DXC) is placed in byte 2 of the floating-point control register (FPCR), regardless of whether filtering applies to the program exception condition. If a transaction aborts and either the AFP register control element and / or the effective floating-point operation control element are zero, the DXC is not placed in the FPCR.

[0198] As stated herein, in one embodiment, the following general instructions are provided when the transactional execution facility is installed. • EXTRACT TRANSACTION NESTING DEPTH • NON-TRANSACTIONAL STORE • TRANSACTION ABORT • TRANSACTION BEGIN • TRANSACTION END

[0199] When the CPU is in transactional execution mode, attempted execution of certain instructions is restricted and causes the transaction to abort.

[0200] If an attempted execution of restricted instructions is issued in the restricted transactional execution mode, it may also result in a transaction-related program interrupt or may cause execution to continue as if the transaction were unrestricted.

[0201] For example, in a z / Architecture example, restricted instructions include the following nonprivileged instructions: COMPARE AND SWAP AND STORE; MODIFY RUNTIME INSTRUMENTATION CONTROLS; PERFORM LOCKED OPERATION; PREFETCH DATA (RELATIVE LONG) if the code in field M1 is 6 or 7; STORE CHARACTERS UNDER MASK HIGH if field M3 is zero and the code in field R1 is 6 or 7; STORE FACILITY LIST EXTENDED; STORE RUNTIME INSTRUMENTATION CONTROLS; SUPERVISOR CALL; and TEST RUNTIME INSTRUMENTATION CONTROLS.

[0202] In the above list, COMPARE AND SWAP AND STORE and PERFORM LOCKED OPERATION are complex instructions that can be implemented more effectively using basic TX-mode instructions. The cases for PREFETCH DATA and PREFETCH DATA RELATIVE LONG are restricted because codes 6 and 7 free a cache row, potentially requiring the data to be committed before a transaction completes. SUPERVISOR CALL is restricted because it causes an interrupt (causing a transaction to abort).

[0203] The following instructions are restricted under the conditions listed below: • BRANCH AND LINK (BALR), BRANCH AND SAVE (BASR), and BRANCH AND SAVE AND SET MODE, if the R2 field of the statement is nonzero and branch tracing is enabled. • BRANCH AND SAVE AND SET MODE and BRANCH AND SET MODE if the R2 field is non-zero and mode tracking is enabled; SET ADDRESSING MODE if mode tracking is enabled. • MONITOR CALL when a monitoring event condition is detected.

[0204] The above list contains instructions that can create trace entries. If these instructions were allowed to execute transactionally and create trace entries, and the transaction were subsequently aborted, the trace table pointer would advance in control register 12, but the trace table stores would be discarded. This would leave an inconsistent gap in the trace table; therefore, the instructions are restricted in the cases where they would create trace entries.

[0205] When the CPU is in transactional execution mode, the following instructions are restricted depending on the model: CIPHER MESSAGE; CIPHER MESSAGE WITH CFB; CIPHER MESSAGE WITH CHAINING; CIPHER MESSAGE WITH COUNTER; CIPHER MESSAGE WITH OFB; COMPRESSION CALL; COMPUTE INTERMEDIATE MESSAGE DIGEST; COMPUTE LAST MESSAGE DIGEST; COMPUTE MESSAGE AUTHENTICATION CODE; CONVERT UNICODE-16 TO UNICODE-32; CONVERT UNICODE-16 TO UNICODE-8; CONVERT UNICODE-32 TO UNICODE-16; CONVERT UNICODE-32 TO UNICODE-8; CONVERT UNICODE-8 TO UNICODE-16; CONVERT UNICODE-8 TO UNICODE-32; PERFORM CRYPTOGRAPHIC COMPUTATION; RUNTIME INSTRUMENTATION OFF; and RUNTIME INSTRUMENTATION ON.

[0206] Each of the above instructions is implemented, either currently or in earlier machines, by the hardware coprocessor and is thus considered restricted.

[0207] If the effective control for AR modification (A) is zero, the following statements are restricted: COPY ACCESS; LOAD ACCESS MULTIPLE; LOAD ADDRESS EXTENDED; and SET ACCESS.

[0208] Each of the above statements causes the contents of an access register to be modified. If the A control in the TRANSACTION BEGIN statement is zero, the program has explicitly stated that access register modification is not allowed.

[0209] If the effective control for allowing floating-point operations (F) is zero, floating-point instructions are restricted.

[0210] Under certain circumstances, the following instructions may be restricted: EXTRACT CPU TIME; EXTRACT PSW; STORE CLOCK; STORE CLOCK EXTENDED; and STORE CLOCK FAST.

[0211] Each of the aforementioned instructions is subject to an interception control in the interpretive execution state description. If the hypervisor has set the interception control for these instructions, their execution may be prolonged due to the hypervisor's implementation; therefore, they are considered restricted when an interception occurs.

[0212] When an unrestricted transaction aborts due to an attempted execution of a restricted instruction, the transaction abort code in the transaction diagnostic block is set to 11 (restricted instruction), and the condition code is set to 3, except as follows: when an unrestricted transaction aborts due to an attempted execution of an instruction that would otherwise result in a privileged operation exception, it is unpredictable whether the abort code is set to 11 (restricted instruction) or 4 (unfiltered program interrupt resulting from detecting the program interrupt of the privileged operation).If an unrestricted transaction aborts due to an attempted execution of PREFETCH DATA (RELATIVE LONG) when the code in field M1 is 6 or 7, or of STORE CHARACTERS UNDER MASK HIGH when field M3 is zero and the code in field R1 is 6 or 7, it is unpredictable whether the abort code will be set to 11 (restricted instruction) or 16 (other cache). If an unrestricted transaction aborts due to an attempted execution of MONITOR CALL, and both a monitor event condition and a specification exception condition exist, it is unpredictable whether the abort code will be set to 11 or 4, or to 12 if the program interrupt is filtered.

[0213] Additional instructions may be constrained in a constrained transaction. Although these instructions are not currently defined to be constrained in an unconstrained transaction, they may be constrained in an unconstrained transaction in future processors under certain circumstances.

[0214] Certain restricted instructions may be permitted in transactional execution mode in future processors. Therefore, the program should not rely on the transaction being aborted due to the attempted execution of a restricted instruction. The TRANSACTION ABORT instruction should be used to reliably cause a transaction to be aborted.

[0215] In a non-restricted transaction, the program should provide an alternative non-transactional code path to accommodate a transaction that aborts due to a restricted statement.

[0216] In operation, if the transaction nesting depth is zero, execution of the TRANSACTION BEGIN (TBEGIN) instruction that results in a zero condition code causes the CPU to enter unrestricted transactional execution mode. If the transaction nesting depth is zero, execution of the restricted TRANSACTION BEGIN (TBEGINC) instruction that results in a zero condition code causes the CPU to enter restricted transactional execution mode.

[0217] All rules that apply to non-transactional execution also apply to transactional execution, unless explicitly stated otherwise. The following are additional processing characteristics while the CPU is in transactional execution mode.

[0218] If the CPU is in the unrestricted transactional execution mode, the execution of the TRANSACTION BEGIN instruction that results in a zero condition code causes the CPU to remain in the unrestricted transactional execution mode.

[0219] As observed by the CPU, fetches and stores made in transactional execution mode are no different from those made in non-transactional execution mode. As observed by other CPUs and by the I / O subsystem, all memory operand accesses made while a CPU is in transactional execution mode appear to be concurrent single-block accesses. Thus, accesses to all bytes within a halfword, word, doubleword, or quadword are specified to appear to occur concurrently for one block, as observed by other CPUs and I / O (i.e., channel) programs. The halfword, word, doubleword, or quadword is referred to as a block throughout this section.If a fetch-type reference is specified so that it appears to be concurrent within a block, no memory access to the block by any other CPU and / or I / O program is permitted while bytes contained in the block are being fetched. If a fetch-type reference is specified so that it appears to be concurrent within a block, no access to the block, either fetching or storing, is permitted by any other CPU and / or I / O program while bytes contained in the block are being stored.

[0220] Memory accesses for instruction and DAT and ART (Access Register Table) table fetches follow non-transactional rules.

[0221] The CPU typically exits transactional execution mode using a TRANSACTION END instruction, which causes the transaction nesting depth to change to zero, in which case the transaction terminates.

[0222] When the CPU exits transactional execution mode by executing a TRANSACTION END instruction, all stores made during transactional execution mode are committed; thus, the stores appear to occur as a single concurrent block operation, as observed by other CPUs and by the I / O subsystem.

[0223] A transaction can be aborted implicitly for a variety of reasons, or it can be aborted explicitly using the TRANSACTION ABORT statement. Possible example causes for a transaction abort, the corresponding abort code, and the condition code placed in the transaction abort PSW are described below.

[0224] External interrupt: The transaction abort code is set to 2, and the condition code in the transaction abort PSW is set to 2. The transaction abort PSW is saved as the external old PSW as part of external interrupt processing.

[0225] Program Break (Unfiltered): A program break condition that results in a break (i.e., an unfiltered condition) causes the transaction to abort with code 4. The condition code in the transaction abort PSW is specifically set to the program break code. The transaction abort PSW is stored as the old program PSW as part of program break processing.

[0226] A statement that would otherwise result in a transaction being aborted due to an operation error may produce alternative results: for an unrestricted transaction, the transaction may instead be aborted with abort code 11 (restricted statement); for a restricted transaction, a transaction-specific interrupt may be detected instead of the operation error.

[0227] If a PER (Program Event Recording) is detected in conjunction with another unfiltered program exception, the condition code is set to 3.

[0228] Machine Check Interrupt: The transaction abort code is set to 5, and the condition code in the transaction abort PSW is set to 2. The transaction abort PSW is saved as the old machine check PSW as part of machine check interrupt processing.

[0229] I / O interrupt: The transaction abort code is set to 6, and the condition code in the transaction abort PSW is set to 2. The transaction abort PSW is saved as the old I / O PSW as part of I / O interrupt processing.

[0230] Fetch overflow: A fetch overflow condition is detected when the transaction attempts to fetch more memory locations than the CPU supports. The transaction abort code is set to 7, and the condition code is set to either 2 or 3.

[0231] Memory overflow: A memory overflow condition is detected when the transaction attempts to store more memory locations than the CPU supports. The transaction abort code is set to 8, and the condition code is set to either 2 or 3.

[0232] If the condition code in response to a fetch or memory overflow abort can be either 2 or 3, the CPU may indicate repeatable situations (e.g., condition code 2 indicates that reexecution of the transaction may be productive; in contrast, condition code 3 does not recommend reexecution).

[0233] Fetch conflict: A fetch conflict condition is detected when another CPU or the I / O subsystem attempts to store into a memory location that was fetched transactionally by this CPU. The transaction abort code is set to 9, and the condition code is set to 2.

[0234] Memory conflict: A memory conflict condition is detected when another CPU or the I / O subsystem attempts to access a memory location saved by this CPU during transactional execution. The transaction abort code is set to 10, and the condition code is set to 2.

[0235] Restricted instruction: When the CPU is in transactional execution mode, an attempted execution of a restricted instruction causes the transaction to abort. The transaction abort code is set to 11, and the condition code is set to 3.

[0236] When the CPU is in restricted transactional execution mode, it is unpredictable whether an attempted execution of a restricted instruction will result in a transaction-related interrupt or a restricted instruction abort. The transaction will still abort, but the abort code can indicate either cause.

[0237] Program exception (filtered): A program exception that does not result in an interrupt (i.e., a filtered condition) causes the transaction to abort with a transaction abort code of 12. The condition code is set to 3.

[0238] Nesting depth exceeded: A nesting depth exceeded condition is detected when the transaction nesting depth is at the maximum allowed for the configuration and a TRANSACTION BEGIN statement is executed. The transaction is aborted with a transaction abort code of 13, and the condition code is set to 3.

[0239] Cache fetch-related condition: A condition related to memory locations fetched by the transaction is detected by the CPU's cache circuitry. The transaction is aborted with a transaction abort code of 14, and the condition code is set to 2 or 3.

[0240] Cache-related condition: A condition related to memory locations saved by the transaction is detected by the CPU's cache circuitry. The transaction is aborted with a transaction abort code of 15, and the condition code is set to 2 or 3.

[0241] Other cache condition: A other cache condition is detected by the CPU's cache circuitry. The transaction is aborted with a transaction abort code of 16, and the condition code is set to 2 or 3.

[0242] If the CPU accesses instructions or memory operands using different logical addresses that map to the same absolute address during transactional execution, the transaction aborts depending on the model. If the transaction aborts due to accesses using different logical addresses that map to the same absolute address, abort code 14, 15, or 16 is set, depending on the condition.

[0243] Miscellaneous condition: A miscellaneous condition is any other condition detected by the CPU that causes a transaction to abort. The transaction abort code is set to 255, and the condition code is set to either 2 or 3.

[0244] When multiple configurations are running on the same machine (for example, logical partitions or virtual machines), a transaction may be aborted due to an external machine check or an I / O interrupt that occurred in another configuration.

[0245] Although examples are provided above, other causes of transaction aborts may be provided with corresponding abort codes and condition codes. For example, a cause may be a restart interrupt, in which the transaction abort code is set to 1, and the condition code in the transaction abort PSW is set to 2. The transaction abort PSW is saved as the old restart PSW as part of restart processing. As another example, a cause may be a supervisor call condition, in which the abort code is set to 3, and the condition code in the transaction abort PSW is set to 3. Other or different examples are also possible. Notes: 1. The other condition may result from any of the following: • Instructions such as COMPARE AND REPLACE DAT TABLE ENTRY, COMPARE AND SWAP AND PURGE, INVALIDATE DAT TABLE ENTRY, INVALIDATE PAGE TABLE ENTRY, PERFORM FRAME MANAGEMENT FUNCTION in z / Architecture, in which the NQ control is zero and the SK control is one, SET STORAGE KEY EXTENDED, in which the NQ control is zero, executed by a different CPU in the configuration; the condition code is set to 2. • An operator function such as reset, restart or stop or the equivalent SIGNAL PROCESSOR instruction is executed on the CPU. • Any other condition not listed above; the condition code is set to 2. 2. The memory location where fetch and store conflicts are detected can be anywhere within the same cache line. 3. Under certain conditions, the CPU may not be able to distinguish between similar termination conditions. For example, a fetch or memory overflow may be indistinguishable from a corresponding fetch or memory conflict. 4. Speculative execution of multiple instruction paths by the CPU may cause a transaction to abort due to conflict or overflow conditions, even if such conditions do not occur in the conceptual sequence. When the CPU is in the restricted transactional execution mode, the CPU may temporarily block speculative execution, allowing the transaction to speculatively attempt completion without detecting such conflicts or overflows.

[0246] Execution of a TRANSACTION ABORT instruction causes the transaction to be aborted. The transaction abort code is set by the second operand address. The condition code is set to either 2 or 3, depending on whether bit 63 of the second operand address is zero or one.

[0247] Fig. Figure 10 summarizes sample abort codes stored in a transaction diagnostic block and the corresponding condition code (CC). The description in Fig. Figure 10 illustrates a specific implementation. Other implementations and value encryptions are possible.

[0248] In one embodiment, and as previously mentioned, the transaction-based facility considers both constrained transactions and non-constrained transactions, as well as the associated processing. Constrained transactions will be discussed first, followed by non-constrained transactions.

[0249] A constrained transaction executes in transactional mode without a rollback path. It is a processing mode useful for compact functions. If there are no repeated interrupts or conflicts with other CPUs or the I / O subsystem (i.e., caused by conditions that do not allow the transaction to complete successfully), a constrained transaction will eventually terminate; thus, an abort handler is not required and is not specified. For example, the transaction will eventually terminate if there is no violation of an unaddressable condition (e.g., divide by 0); no condition that does not allow the transaction to complete (e.g., a timer interrupt that does not allow an instruction to be executed; an unexpected I / O, etc.); or no violation of a constraint or constraint associated with a constrained transaction.

[0250] A restricted transaction is initiated by a restricted TRANSACTION BEGIN (TBEGINC) statement when the transaction nesting depth is initially zero. In one embodiment, a restricted transaction is subject to the following requirements: 1. The transaction executes no more than 32 statements, excluding the restricted TRANSACTION BEGIN (TBEGINC) statement and the TRANSACTION END statement. 2. All statements in the transaction must be within 256 contiguous bytes of memory, including the restricted TRANSACTION BEGIN (TBEGINC) statement and each TRANSACTION END statement. 3. In addition to the restricted instructions, the following restrictions apply to a restricted transaction. a. Instructions are limited to those designated as general instructions, including, for example, adding, subtracting, multiplying, dividing, shifting, rotating, etc. b. Branch instructions are limited to the following (the listed instructions are part of the z / Architecture in one embodiment): • BRANCH RELATIVE ON CONDITION, where field M1 is non-zero and field RI2 contains a positive value. • BRANCH RELATIVE ON CONDITION LONG, where field M1 is non-zero and field RI2 contains a positive value that does not cause a cyclic sequence of addresses. • COMPARE AND BRANCH RELATIVE, COMPARE IMMEDIATE AND BRANCH RELATIVE, COMPARE LOGICAL AND BRANCH RELATIVE, and COMPARE LOGICAL IMMEDIATE AND BRANCH RELATIVE, where field M3 is nonzero and field RI4 contains a positive value. (Thus, only forward branches with branch masks nonzero.) c. Except for TRANSACTION END and statements that cause specified operand serialization, statements that cause a serialization function are restricted. d. Instructions of memory-to-memory (SS) operations and memory-to-memory operations with an extended operation code (SSE) are restricted. e. Alle der folgenden allgemeinen Anweisungen (die in diesem Beispiel zur z / Architecture gehören), sind eingeschränkt. CHECKSUM; CIPHER MESSAGE; CIPHER MESSAGE WITH CFB; CIPHER MESSAGE WITH CHAINING; CIPHER MESSAGE WITH COUNTER; CIPHER MESSAGE WITH OFB; COMPARE AND FORM CODEWORD; COMPARE LOGICAL LONG; COMPARE LOGICAL LONG EXTENDED; COMPARE LOGICAL LONG UNICODE; COMPARE LOGICAL STRING; COMPARE UNTIL SUBSTRING EQUAL; COMPRESSION CALL; COMPUTE INTERMEDIATE MESSAGE DIGEST; COMPUTE LAST MESSAGE DIGEST; COMPUTE MESSAGE AUTHENTICATION CODE; CONVERT TO BINARY; CONVERT TO DECIMAL; CONVERT UNICODE-16 TO UNICODE-32; CONVERT UNICODE-16 TO UNICODE-8; CONVERT UNICODE-32 TO UNICODE-16; CONVERT UNICODE-32 TO UNICODE-8; CONVERT UNICODE-8 TO UNICODE-16; CONVERT UNICODE-8 TO UNICODE-32; DIVIDE; DIVIDE LOGICAL; DIVIDE SINGLE; EXECUTE; EXECUTE RELATIVE LONG; EXTRACT CACHE ATTRIBUTE; EXTRACT CPU TIME; EXTRACT PSW; EXTRACT TRANSACTION NESTING DEPTH; LOAD AND ADD; LOAD AND ADD LOGICAL; LOAD AND AND;LOAD AND EXCLUSIVE OR; LOAD AND OR; LOAD PAIR DISJOINT; LOAD PAIR FROM QUADWORD; MONITOR CALL; MOVE LONG; MOVE LONG EXTENDED; MOVE LONG UNICODE; MOVE STRING; NON-TRANSACTIONAL STORE; PERFORM CRYPTOGRAPHIC COMPUTATION; PREFETCH DATA; PREFETCH DATA RELATIVE LONG; RUNTIME INSTRUMENTATION EMIT; RUNTIME INSTRUMENTATION NEXT; RUNTIME INSTRUMENTATION OFF; RUNTIME INSTRUMENTATION ON; SEARCH STRING; SEARCH; STRING UNICODE; SET ADDRESSING MODE; STORE CHARACTERS UNDER MASK HIGH, wenn das Feld M3 null ist und der Code im Feld R1 6 oder 7 ist; STORE CLOCK; STORE CLOCK EXTENDED; STORE CLOCK FAST; STORE FACILITY LIST EXTENDED; STORE PAIR TO QUADWORD; TEST ADDRESSING MODE; TRANSACTION ABORT; TRANSACTION BEGIN (sowohl TBEGIN als auch TBEGINC); TRANSLATE AND TEST EXTENDED; TRANSLATE AND TEST REVERSE EXTENDED; TRANSLATE EXTENDED; TRANSLATE ONE TO ONE; TRANSLATE ONE TO TWO TRANSLATE TWO TO ONE; und TRANSLATE TWO TO TWO.; 4. The transaction's memory operands access no more than four octal words. Note: LOAD ON CONDITION and STORE ON CONDITION are considered memory references, regardless of the condition code. For example, an octal word is a group of 32 consecutive bytes on a 32-byte boundary. 5. The transaction executing on this CPU or stores by other CPUs or the I / O subsystem do not access memory operands in any 4-KB blocks containing the 256 bytes of memory that begin with the restricted TRANSACTION BEGIN (TBEGINC) instruction. 6. The transaction does not access instructions or memory operands using different logical addresses mapped to the same absolute address. 7. Operand references made by the transaction must be within a single double word, except that for LOAD ACCESS MULTIPLE, LOAD MULTIPLE, LOAD MULTIPLE HIGH, STORE ACCESS MULTIPLE, STORE MULTIPLE, and STORE MULTIPLE HIGH, operand references must be within a single eight-word.

[0251] If a constrained transaction violates any of the constraints 1 through 7 listed above, either (a) a transaction constraint interrupt is detected or (b) execution continues as if the transaction were unrestricted, except that further constraint violations may still result in a transaction template interrupt. The action taken is unpredictable, and the action taken may vary depending on which constraint has been violated.

[0252] If there are no constraint violations, repeated interrupts, or conflicts with other CPUs or the I / O subsystem, a restricted transaction will eventually terminate as described above. 1. The chance of successfully completing a restricted transaction improves if the transaction meets the following criteria: a. The number of instructions issued is less than the maximum of 32. b. The number of memory operand references is less than the maximum of 4 octal words. c. The memory operand references are located on the same cache line. d. Memory operand references to the same memory locations occur in the same order in all transactions. 2. A constrained transaction is not necessarily guaranteed to complete successfully the first time it is executed. However, if a constrained transaction that does not violate any of the listed constraints is aborted, the CPU uses circuitry to ensure that subsequent re-executions of the transaction will succeed. 3. In a restricted transaction, TRANSACTION BEGIN is a restricted statement, so a restricted transaction cannot be nested. 4. Violation of any of the above requirements 1 to 7 by a restricted transaction may result in a program loop. 5. The limitations of a constrained transaction are similar to those of a compare and swap loop. Because of the potential interference from other CPUs and the I / O subsystem, there is no architectural guarantee that a COMPARE AND SWAP instruction will ever exit with a condition code of 0. A constrained transaction can suffer from similar interference in the form of aborts due to fetch or store conflicts or unexpected interrupts.

[0253] The CPU uses balancing algorithms to ensure that a constrained transaction eventually completes if no constraint violations occur. 6. To determine the number of repeated iterations required to complete a restricted transaction, the program can use a counter in a general-purpose register that is not subject to the general-purpose register storage mask. An example is shown below: LH1 15,0 Zero retry counter Ribbon TBEGINC 0(0),X 'FE00' Maintain GRs 0 to 13 AHI 15,1 Increase counter ... ... Restricted transaction-related Execution code ... TEND End of transaction • R15 now includes the number of repeated transaction-related attempts.

[0254] Note that both registers 14 and 15 are not restored in this example. Also note that in some models, the count in general register 15 may be low if the CPU detects the abort condition after the TBEGINC instruction completes but before the AHI instruction completes.

[0255] As observed by the CPU, fetches and stores made in transactional execution mode are no different from those made in non-transactional execution mode.

[0256] In one embodiment, the user (i.e., the person creating the transaction) chooses whether to restrict a transaction. One embodiment of the logic used to make such a determination is described with reference to Fig.11. First, the user determines whether the transaction needs to be constrained, STEP 1100. For example, the user decides whether the restrictions associated with constrained transactions are acceptable. If so, QUERY 1102, a constrained transaction is created, STEP 1104. This involves using the TBEGINC statement to begin the constrained transaction, including one or more statements after TBEGINC, and ending the transaction with TEND. Otherwise, if no constrained transaction is to be created, in one embodiment, an unconstrained transaction is created, STEP 1106. This involves using TBEGIN to start an unconstrained transaction, including one or more statements, and ending with TEND.

[0257] In another embodiment, a processor makes a recommendation to the user regarding whether to use a constrained transaction. The recommendation is based on stored default rules (e.g., the constraints) accessible by the processor. For example, the processor accesses the rules and determines whether all of the constraints are acceptable. If so, the processor recommends a constrained transaction; otherwise, an unrestricted transaction is recommended.

[0258] An overview of transaction-related cancellation processing is provided with reference to Fig.12. First, a processor obtains (e.g., fetches, receives) a transaction (e.g., TBEGIN or TBEGINC), STEP 1200, and a selected field (e.g., the operation code or a field other than the operation code) is checked for the transaction type, STEP 1201. If the field indicates that the transaction is restricted, INQUIRY 1202, the transaction is processed as a restricted transaction, STEP 1204. For a restricted transaction, the transaction abort PSW is set to point to the TBEGINC instruction that started the transaction. When an abort condition is reached, INQUIRY 1206, control is transferred to that PSW, which points to the TBEGINC instruction, and the condition code is set to indicate whether the condition is expected to be recoverable.For a constrained transaction, no termination handler is invoked (other than a return to TBEGINC); instead, processing continues with a re-execution of the TBEGINC statement. If no termination condition is met, in one embodiment, the transaction is terminated with a TRANSACTION END statement.

[0259] However, if the transaction is unrestricted, QUERY 1202, the transaction is processed as an unrestricted transaction, STEP 1208. For an unrestricted transaction, the transaction abort PSW is set to point to the statement following the TBEGIN statement. The expected use for an unrestricted transaction is that the statement following the TBEGIN statement will be a branch statement, transferring control to an abort processing routine if the condition code is nonzero. Therefore, if an abort condition is reached, QUERY 1210, processing for an unrestricted transaction continues with the statement following the TRANSACTION BEGIN statement, STEP 1212. Otherwise, processing completes with a TRANSACTION END statement.

[0260] In another embodiment, additional checks are performed to determine whether the transaction should be processed as a restricted transaction. For example, if the operation code indicates that it is a restricted transaction, but it is a nested transaction, in one embodiment, the transaction is executed as an unrestricted transaction. Additional checks may also be performed.

[0261] Further details regarding the processing of restricted transactions and in particular the processing associated with the TBEGINC instruction are provided with reference to Fig. 13. Execution of the TBEGINC instruction causes the CPU to either enter the restricted transactional execution mode or remain in the unrestricted execution mode. The CPU (i.e., the processor) executing TBEGINC executes the logic of Fig.13 out.

[0262] With reference to Fig. 13, based on execution of a TBEGINC instruction, a serialization function is executed, STEP 1300. A serialization function or operation involves terminating all conceptually previous memory accesses (and, for z / Architecture, for example, associated reference bit and change bit settings) by the CPU, as observed by other CPUs and by the I / O subsystem, before the conceptually subsequent memory accesses (and associated reference bit and change bit settings) occur. Serialization affects the sequence of all CPU accesses to memory and to memory keys, except those associated with a fetch from an ART table entry and a DAT table entry.

[0263] As observed by a CPU in transactional execution mode, a serialization operation proceeds normally (as described above). As observed by other CPUs and by the I / O subsystem, a serialization operation performed while a CPU is in transactional execution mode occurs when the CPU exits transactional execution mode, either as a result of a TRANSACTION END instruction that reduces the transaction nesting depth to zero (normal termination) or as a result of the transaction being aborted.

[0264] Following an execution of a serialization, a determination is made as to whether an exception was detected, QUERY 1302. If so, the exception is handled, STEP 1304. For example, a special operation exception is detected and the operation is suppressed if the transactional execution control, bit 8 of control register 0, is 0. As another example, a specification exception is detected and the operation is suppressed if field B1, bits 16 through 19 of the instruction, is nonzero; an execution exception is detected and the operation is suppressed if the TBEGINC is the target of an Execute instruction; and an operation exception is detected and the operation is suppressed if the transactional execution facility is not installed in the configuration.If the CPU is already in restricted transaction execution mode, a program exception due to a transaction-specific exception is detected, and the operation is suppressed. Furthermore, if the transaction nesting depth, increasing by 1, would exceed a model-dependent maximum transaction nesting depth, the transaction is aborted with abort code 13. Additional or other exceptions may be detected and handled.

[0265] However, if no exception exists, a determination is made as to whether the transaction nesting depth is zero, QUERY 1306. If the transaction nesting depth is zero, the transaction diagnostic block address is considered invalid, STEP 1308; the transaction abort PSW is set from the contents of the current PSW, except that the instruction address of the transaction abort PSW specifies the TBEGINC instruction rather than the next consecutive instruction, STEP 1310; and the contents of the general register pairs, as specified by the general register storage mask, are stored in a model-dependent memory location that cannot be directly accessed by the program, STEP 1312. Furthermore, the nesting depth is set to 1, STEP 1314. In addition, the effective value of the floating-point operation permit (F) and program interrupt filter (PIFC) controls is set to zero, STEP 1316.Further, the effective value of the Allow AR Modification (A) control, bit 12 of field I2 of the instruction, is determined, STEP 1318. For example, the effective A control is the logical AND of the A control in the TBEGINC instruction for the current level and for all outer TBEGIN instructions.

[0266] Returning again to QUERY 1306, if the transaction nesting depth is greater than zero, the nesting depth is incremented by 1, STEP 1320. Further, the effective value for Allow Floating Point Operation (F) is set to zero, and the effective value of the Filter Program Interrupt Control (PIFC) remains unchanged, STEP 1322. Processing then continues with STEP 1318. In one embodiment, successful initiation of the transaction results in a condition code of 0. This terminates one embodiment of the logic associated with executing a TBEGINC instruction.

[0267] In one embodiment, the exception checking specified above may occur in a different order. A specific order for exception checking is as follows: Exceptions with the same priority as the priority of program break conditions for the general case. Specification exceptions due to field B1 containing a non-zero value. Abort due to exceeding a transaction nesting depth. Condition code 0 due to normal termination.

[0268] In addition, the following applies in one or more embodiments: 1. Registers specified by the general register save mask to be saved are only restored if the transaction is aborted, but not if the transaction is terminated normally using TRANSACTION END. Only the registers specified by the GRSM of the outermost TRANSACTION BEGIN instruction are restored upon abort.

[0269] The I2 field should specify all register pairs that provide input values ​​that are modified by a restricted transaction. Therefore, if the transaction is aborted, the input register values ​​are restored to their original contents when the restricted transaction is executed again. 2. For most models, improved execution can be achieved for both TRANSACTION BEGIN and transaction abort by specifying in the general register save mask the minimum number of required registers to be saved and restored. 3. The following illustrates the results of the TRANSACTION BEGIN instruction (both TBEGIN and TBEGINC) based on the current transaction nesting depth (TND) and, if the TND is non-zero, whether the CPU is in unrestricted or restricted transactional execution mode. Instruction TND = 0 TBEGIN Enter unrestricted transactional execution mode TBEGINC Enter restricted transactional execution mode Instruction TND > 0 TBEGIN NTX mode CTX mode In the unrestricted transaction-based Transaction-related exception Continue execution mode TBEGINC Continue in unrestricted transactional execution mode Transaction-related exception Explanation CTX CPU is in restricted transactional execution mode NTX CPU is in unrestricted transactional execution mode TND Transaction nesting depth at the beginning of the statement.

[0270] As described herein, in one aspect, completion of a constrained transaction is ensured provided it does not contain a condition that makes completion impossible. To ensure completion, the processor (e.g., CPU) executing the transaction may take certain actions. For example, if a constrained transaction has a termination condition, the CPU may temporarily: (a) block out-of-order execution; (b) block other CPUs from accessing the conflicting memory locations; (c) cause arbitrary delays in any termination processing; and / or (d) call for other measures to facilitate successful completion.

[0271] Further details regarding processing associated with taking steps to facilitate the termination of a restricted transaction are provided with reference to Fig. 14 described.

[0272] First, the processor executes a restricted transaction started by the TBEGINC instruction, STEP 1400. If an abort condition is encountered that does not result in an interrupt, INQUIRY 1402, the processor optionally (e.g., depending on the number of aborts) takes one or more actions as described herein to ensure completion, STEP 1404. Further, the processor executes the TBEGINC instruction again, STEP 1406, and processing continues with STEP 1400.

[0273] If no termination condition exists, or if a termination condition exists that results in an interrupt, return to QUERY 1402, processing continues until a transaction termination (e.g., TEND) or an interrupt occurs, QUERY 1408. In the event of an interrupt, the CPU loads the PSW associated with the interrupt type. The transaction ends based on the termination or interrupt; otherwise, processing continues.

[0274] In one embodiment, the decision whether to perform an action when a transaction is aborted and / or the selection of the action to be performed is based on the value of an abort counter that provides a counter value of how many times the transaction has been aborted.

[0275] The counter increments the counter value each time the transaction is aborted, and is reset to zero upon successful transaction completion or an interrupt that results in no further re-executions of the transaction. When the counter value reaches a threshold (e.g., 63 counters), an interrupt is indicated, the transaction execution is unsuccessful, and the counter is reset. However, before the counter value reaches the threshold, a number of actions can be taken to increase the chances of successful transaction execution. These actions include actions that must be executed on the processor executing the transaction and / or actions that must be executed against conflicting processors (CPUs).

[0276] Within the same processor, depending on the abort counter value and a selection criterion for actions with the same or overlapping abort counter values, one or more of the following actions can be taken: re-execution of the transaction (counter values ​​1 to 3); disabling branch prediction, e.g., via a switch (counter values ​​8 to 20); disabling speculative instruction fetching beyond the cache line boundary of the current instruction, which in one embodiment is achieved by only allowing a cache boundary crossing during instruction fetching if the backend of the pipeline is empty (counter values ​​8 to 20); disabling superscalar forwarding, e.g., via a switch (counter values ​​8 to 20); disabling out-of-order execution, e.g.,via a switch (counters 8 to 20); exclusively fetching all cache misses, even for fetch-only requests (counters 8 to 20); executing a single instruction at a time throughout the pipeline (counters 21 to 23); disabling superscalar forwarding (counters 24 to 28); and executing a single instruction at a time throughout the pipeline and exclusively fetching all cache misses (counters 32 to 63). By employing some of these measures, the speculative aggressiveness of a processor pipeline is gradually limited during repeated transaction aborts. Full speculative aggressiveness of a processor pipeline is restored based on a successful transaction completion or an interrupt that results in no further transaction retries.

[0277] For example, in one embodiment, all actions for a given counter value are executed simultaneously. In another embodiment, if an overlap exists, one action is selected over another, for example, based on selecting from a list order, randomly selecting based on a selection function, or other techniques.

[0278] Further, when proceeding to the next level of abort counter values, in one example, the selected actions replace the previous actions. For example, anything previously disabled is enabled, and the new actions are taken. However, in another embodiment, the new actions are taken in addition to the previous actions. Thus, as used herein, another action replaces a previous action, is in addition to a previous action, or any combination thereof. Further, it may be the same or a different action than the previous action.

[0279] For example, the action is performed by a firmware setting of a hardware bit that enables special processing mode (e.g., disabling branch prediction, etc.). The hardware automatically resets this bit under the same conditions as those under which the counter is reset.

[0280] If the transaction continues to abort after performing one or more of the aforementioned actions and the counter value reaches a selected value or level, action can be taken against conflicting processors. For example, for aborts 4 to 15, arbitrary delays (i.e., re-execution of the transaction is delayed for a specific amount of time or a specific number of machine cycles, etc.) can be executed, and for aborts 16 to 23, a semaphore can be acquired for the other processors of the partition (e.g., LPAR area) in which this processor is executing, thus suspending operations on the other processors. Likewise, for counter values ​​24 to 63, a semaphore can be acquired for the entire system, requiring all processors in the system to suspend operations until the semaphore is removed.In this processing mode, based on the fact that the selected level at which a semaphore must be requested has been reached, a firmware routine is called to request the semaphore, for example, using a compare-and-swap mechanism. When the semaphore is obtained, an interrupt is signaled to the appropriate processors (e.g., the processors within the same partition, all processors in the system, or any subset). Afterward, the processor exits the firmware routine and re-executes the transaction one or more times until successful completion or an interrupt occurs. The semaphore is reset when the transaction has completed successfully or is no longer being retried.

[0281] Although in the aforementioned embodiment, action is taken based on an abort counter value, in another embodiment, action is taken based on reasons for the abort and / or based on the counter value. Thus, action is determined to be taken based on an abort condition, where the condition is the counter value, the abort reason, or a combination of the counter value and the abort reason. For example, a processor could detect that the abort occurred due to another CPU and then request the semaphore. This can also be combined with a count, e.g., "if abort > 16 and the abort occurred due to a conflict with another CPU → request semaphore." There are many variations and possibilities.

[0282] In one embodiment, using the aforementioned techniques for constrained transactions ensures successful completion of the transaction, provided such completion is possible (e.g., there is no violation of a constraint-based restriction or any other violation).

[0283] In summary, the processing of a restricted transaction is as follows: • If restricted TX mode already exists, a transaction policy exception is detected. • If the current TND (Transaction Nesting Depth) is > 0, execution continues as if it were an unrestricted transaction ◯ Effective F-control element is set to zero ◯ Effective PIFC remains unchanged ◯ Allows an outer unrestricted TX to call a service function that a restricted TX can use. • If the current TND = 0: ◯ Transaction diagnostic block address is invalid - No TDB specified by a statement saved on abort ◯ Transaction abort PSW is set to address of TBEGINC - Not the next continuous instruction ◯ General purpose register pairs specified by the GRSM are stored in a model-dependent memory location that cannot be accessed by a program ◯ Optionally formed transaction token (from the D2 operand). The transaction token is an identifier for the transaction. It can correspond to the memory operand address or another value. • Effective A = TBEGINC A and each outer A • TND increased ◯ When the TND transitions from 0 to 1, the CPU enters restricted TX mode ◯ Otherwise, the CPU remains in unrestricted TX mode • The instruction ends with CC0 • Exceptions: ◯ Specification exception (PIC (Program Interruption Code) 0006) if field B1 is not zero ◯ Special operation exception (PIC 0013 hex) if the transaction execution control (CR0.8) is zero ◯ Transaction policy exception (PIC 0018 hex) when issued in restricted TX mode ◯ Operation exception (PIC 0001) if the restricted transaction-based execution facility is not installed ◯ Execution exception (PIC 0003) if the instruction is the target of an Execute instruction ◯ Abort code 13 if the nesting depth is exceeded • Termination conditions in a restricted transaction: ◯ Abort PSW points to instruction TBEGINC - Not the following instruction - Abort condition causes the entire TX to be re-executed * No error path ◯ The CPU takes special measures to ensure successful completion of further execution ◯ Provided there is no permanent conflict, interruption or violation of terms, eventual completion of the transaction is ensured. • Violation of specifications: ◯ PIC 0018 hex - indicates a violation of a transaction specification ◯ Otherwise, the transaction is executed as if it were not restricted

[0284] As described above, in addition to the processing of constrained transactions, which is optional, the transaction-bound facility also provides, in one embodiment, the processing of non-constrained transactions. Further details regarding the processing of non-constrained transactions, and in particular the processing associated with the TBEGIN instruction, are described with reference to Fig. 15. The execution of the TBEGIN instruction causes the CPU to either enter or remain in the unrestricted transactional execution mode. The CPU (i.e., the processor) executing TBEGIN executes the logic of Fig. 15 out.

[0285] With reference to Fig.15, based on execution of the TBEGIN instruction, a serialization function (described above) is executed, STEP 1500. Following execution of serialization, a determination is made as to whether an exception has been detected, INQUIRY 1502. If so, the exception is handled, STEP 1504. For example, a special operation exception is detected and the operation suppressed if the transactional execution control, bit 8 of control register 0, is zero. Further, a specification exception is detected and the operation suppressed if the program interrupt filter control, bits 14 through 15 of field I2 of the instruction, contains the value 3; or the first operand address does not specify a doubleword boundary.An operation exception is detected and the operation is suppressed if the transactional execution facility is not installed in the configuration; and an execution exception is detected and the operation is suppressed if TBEGIN is the target of an Execute instruction. If the CPU is in restricted transactional execution mode, a program exception due to a transaction-specific exception is also detected and the operation is suppressed. Furthermore, if the transaction nesting depth, if incremented by 1, would exceed a model-dependent maximum transaction nesting depth, the transaction is aborted with abort code 13.

[0286] Furthermore, if the B1 field of the instruction is non-zero and the CPU is not in transactional execution mode, i.e., the transaction nesting depth is zero, memory accessibility is determined for the first operand. If the first operand cannot be accessed for memory purposes, an access exception is detected, and the operation is either set to a null value, suppressed, or terminated, depending on the specific access exception condition. In addition, any PER memory change event for the first operand is detected. If the B1 field is non-zero and the CPU is already in transactional execution mode, it is unpredictable whether memory accessibility will be determined for the first operand, and PER memory change events are detected for the first operand. If the B1 field is zero, the first operand is not accessed.

[0287] In addition to exception checking, a determination is made as to whether the CPU is in transactional execution mode (i.e., the transaction nesting depth is zero), QUERY 1506. If the CPU is not in transactional execution mode, the contents of the selected general register pairs are saved, STEP 1508. Specifically, the contents of the general register pairs specified by the general register save mask are saved in a model-dependent memory location that is not directly accessible by the program.

[0288] A determination is also made as to whether the B1 field of the instruction is zero, QUERY 1510. If the B1 field is not zero, the first operand address is placed into the transaction diagnostic block address, STEP 1514, and the transaction diagnostic block address is valid. The transaction abort PSW is also set from the contents of the current PSW, STEP 1516. The instruction address of the transaction abort PSW specifies the next instruction (that is, the instruction following the outermost TBEGIN).

[0289] Furthermore, a determination of the effective value of the Allow AR Modification (A) control, bit 12 of field I2 of the instruction, is made, STEP 1518. The effective A control is the logical AND of the A control in the TBEGIN instruction for the current level and for all outer levels. Additionally, an effective value of the Allow Floating-Point Operation (F) control, bit 13 of field I2 of the instruction, is determined, STEP 1520. The effective F control is the logical AND of the F control in the TBEGIN instruction for the current level and for all outer levels. Further, an effective value of the program interrupt filter control (PIFC), bits 14 through 15 of field I2 of the instruction, is determined, STEP 1522. The effective PIFC value is the highest value in the TBEGIN instruction for the current level and for all outer levels.

[0290] Additionally, a value of one is added to the transaction nesting depth, STEP 1524, and the instruction terminates with a condition code of 0, STEP 1526. If the transaction nesting depth transitions from zero to one, the CPU enters unconstrained transactional execution mode; otherwise, the CPU remains in unconstrained transactional execution mode.

[0291] If B1 is zero upon returning to QUERY 1510, the transaction diagnostic block address is invalid, STEP 1511, and processing continues with STEP 1518. If the CPU is in transactional execution mode, QUERY 1506, processing also continues with STEP 1518.

[0292] A resulting condition code for executing TBEGIN includes, for example: 0 Transaction initiation successful 1 - 2 - 3 -

[0293] Program exceptions include, for example: • Access (store, first operand) • Operation (transactional execution facility not installed) • Special operation • Specification • Transaction default (due to a restricted instruction)

[0294] In one embodiment, the exception checking specified above may occur in a different order. A specific order for exception checking is as follows: • Exceptions with the same priority as the priority of program break conditions for the general case. • Specification exception due to a reserved PIFC value. • Specification exception due to the first operand address not being on a double word boundary. • Access exception (if field B1 is not zero). *Aborted due to exceeding the maximum transaction nesting depth. • Condition code 0 due to normal termination. Notes: 1. If field B1 is not zero, the following applies: • An accessible transaction diagnostic block (TDB) must be provided when an outermost transaction is initiated - even if the transaction is never aborted. • Since it is unpredictable whether access to the TDB for nested transactions will be checked, an accessible TDB must be provided for each nested TBEGIN statement. • The execution of any TBEGIN in which the B1 field is non-zero and the execution of any abort processing that occurs for a transaction initiated by an outermost TBEGIN in which the B1 field is non-zero may be slower than when the B1 field is zero. 2. Registers specified by the general register save mask to be saved are, in one embodiment, only restored if the transaction is aborted, but not if the transaction is terminated normally using TRANSACTION END. Only the registers specified by the GRSM of the outermost TRANSACTION BEGIN instruction are restored upon abort.

[0295] The I2 field should specify all register pairs that provide input values ​​that will be modified by the transaction. Therefore, if the transaction is aborted, the input register values ​​are restored to their original contents upon entry into the abort handler. 3. The TRANSACTION BEGIN (TBEGIN) statement is expected to be followed by a conditional branch statement that determines whether the transaction was initiated successfully. 4. If a transaction aborts due to conditions that do not result in an interrupt, the statement specified by the transaction abort PSW receives control (that is, the statement following the outermost TRANSACTION BEGIN (TBEGIN) statement). In addition to the condition code set by the TRANSACTION BEGIN (TBEGIN) statement, condition codes 1 through 3 are also set when a transaction aborts.

[0296] Therefore, the statement sequence following the outermost TRANSACTION BEGIN (TBEGIN) statement should be able to accommodate all four condition codes, even though the TBEGIN statement in this example only sets the code 0. 5. For most models, improved execution can be achieved for both TRANSACTION BEGIN and transaction abort by specifying in the general register save mask the minimum number of registers required to be saved and restored. 6. While in unrestricted transactional execution mode, a program may call a utility function that can modify access registers or floating-point registers (including the floating-point control register). Although such a utility routine may save the modified registers upon invocation and restore them upon exit, the transaction may be aborted before the routine exits normally. If the calling program does not provide for preserving these registers while the CPU is in unrestricted transactional execution mode, it may not be able to allow the utility function to modify the registers.

[0297] To prevent inadvertent modification of access registers, the program can set the AR modification control, bit 12 of field I2 of the TRANSACTION BEGIN instruction, to zero while in unrestricted transactional execution mode. Similarly, to prevent inadvertent modification of floating-point registers, the program can set the floating-point operation control, bit 13 of field I2 of the TBEGIN instruction, to zero. 7. Program execution conditions detected during execution of the TRANSACTION BEGIN (TBEGIN) statement are subject to the effective program interrupt filter control set by all outermost TBEGIN statements. Program execution conditions detected during execution of the outermost TBEGIN statement are not subject to filtering. 8. To update multiple memory locations in serial order, conventional code sequences can use a lock word (semaphore). If (a) transactional execution is used to implement updates from multiple memory locations, (b) the program also provides a fallback path to be invoked if the transaction aborts, and (c) the fallback path uses a lock word, the transactional execution path should also check for lock availability and, if the lock is not available, terminate the transaction using the TRANSACTION END statement and branch to the fallback path. This ensures consistent access to the resources specified in serial order, regardless of whether they are being updated transactionally.

[0298] Alternatively, the program could abort if the lock is not available, but the abort processing can be significantly slower than simply ending the transaction using TEND. 9. If the effective program interrupt filter control (PIFC) is greater than zero, the CPU filters most data exception program interrupts. If the floating-point operation permit control (F) is zero, the data exception code (DXC) resulting from an abort due to a data exception program exception condition is not set in the floating-point control register. In this scenario (filtering is applied and the effective F control is zero), the only location where the DXC is examined is in the TDB specified by TBEGIN. If the program's abort handler is to examine the DXC in such a situation, general register B1 should be non-zero, so that a valid transaction diagnostic block address (TDBA) is set. 10. If a PER memory change or null address detection condition exists for the TDB specified by TBEGIN of the outermost TBEGIN instruction, and PER event suppression does not apply, the PER event will be detected during instruction execution, causing the transaction to abort immediately, regardless of whether any other abort condition exists.

[0299] In one embodiment, the TBEGIN instruction implicitly sets the transaction abort address to the next instruction after TBEGIN. This address is intended as a conditional branch instruction that determines whether a branch is executed depending on the condition code (CC). A successful TBEGIN sets CC0, whereas an aborted transaction sets CC1, CC2, or CC3.

[0300] In one embodiment, the TBEGIN instruction provides an optional memory operand that specifies the address of a transaction diagnostic block (TDB) in which information is stored if the transaction aborts.

[0301] It also provides an immediate operand that contains: a general purpose register storage mask (GRSM) that specifies which pairs of general purpose registers should be stored at the beginning of a transaction-bound execution and restored when the transaction aborts; a bit (A) that allows the transaction to be aborted if the transaction modifies access registers; a bit (F) that allows the transaction to be aborted if the transaction attempts to execute floating-point instructions; and a program break filter control (PIFC) that allows individual transaction levels to bypass the actual presence of a program break when a transaction aborts.

[0302] The A, F, and PIFC controls can be different at different nesting levels and can be saved back to the previous level when the inner transaction levels are completed.

[0303] Furthermore, the TBEGIN (or TBEGINC in another embodiment) is used to form a transaction token. Optionally, the token can be matched with a token formed by the TEND instruction. For example, for each TBEGIN (or TBEGINC) instruction, a token is formed from the first operand address. This token can be formed regardless of whether the base register is zero (unlike a TDB address setting, which only occurs when the base register is non-zero). For each TRANSACTION END instruction executed with a non-zero base register, a similar token is formed from its memory operand. If the tokens do not match, a program exception can be detected, warning the program about a standalone instruction.

[0304] Token matching provides a mechanism intended to improve software reliability by ensuring that a TEND instruction is correctly paired with a TBEGIN (or TBEGINC). When a TBEGIN instruction executes at a particular nesting level, a token is formed from the memory operand address that identifies that instance of a transaction. When a corresponding TEND instruction executes, a token is formed from the instruction's memory operand address, and the CPU compares the beginning token for the nesting level with the ending token. If the tokens do not match, an exception is raised. A model can implement token matching only for a certain number of nesting levels (or for no nesting levels).The token may not include all bits of the memory operand address, or the bits may be combined using hashing or other methods. A token can be formed by the TBEGIN instruction even if its memory operand is not accessed.

[0305] In summary, processing of an unrestricted transaction occurs as follows: • If TND = 0: ◯ If B1 ≠ 0, the transaction diagnostic block address is set from the first operand address. ◯ Transaction abort PSW is set to the next instruction address. ◯ General register pairs specified by the I2 field are stored in a model-dependent memory location. - This cannot be accessed directly by the program • Effective PIFC, A and F controls are calculated ◯ Effective A = TBEGIN A and each outer A ◯ Effective F = TBEGIN F and each outer F ◯ Effective PIFC = max (TBEGIN PIFC, each outer PIFC) • Transaction nesting depth (TND) is increased • When the TND transitions from 0 to 1, the CPU enters transactional execution mode • Condition code is set to zero ◯ If a statement following TBEGIN receives a control: - TBEGIN success is indicated by CC0 - Aborted transaction is indicated by CC not equal to zero • Exceptions: ◯ Abort code 13 if the nesting depth is exceeded ◯ Access exception (one of various PICs) when field B1 is non-zero and the memory operand cannot be accessed for a memory operation ◯ Execution exception (PIC 0003) if the TBEGIN instruction is the target of an Execute instruction ◯ Operation exception (PIC 0001) if the transaction-based execution facility is not installed ◯ PIC 0006, if - PIFC is invalid (value of 3) - Second operand address not aligned to double word boundary ◯ PIC 0013 hex if transaction-bound execution control (CR0.8) is zero ◯ PIC 0018 hex when output in restricted TX mode

[0306] As stated above, a transaction, whether constrained or unrestricted, can be terminated by a TRANSACTION END (TEND) statement. Further details regarding the processing of a transaction end (TEND) statement are described in Fig. 16. The CPU (ie the processor) that executes TEND executes the logic of Fig. 16 out.

[0307] With reference to Fig.16, based on the processor receiving the TEND instruction (e.g., fetching, receiving, etc.), various exception checks are first performed, and if an exception is present, QUERY 1600, the exception is handled, STEP 1602. For example, if the TRANSACTION END is the target of an Execute type instruction, the operation is suppressed, and an execution exception is detected, and a special operation exception is detected, and the operation is suppressed if the transactional exception control, bit 8 of CR0, is zero. Furthermore, an operation exception is detected, and the operation is suppressed if the transactional execution facility is not installed in the configuration.

[0308] If no execution is detected, returning to QUERY 1600, the transaction nesting depth is decreased (e.g., by one), STEP 1604. A determination is made as to whether the transaction nesting depth is zero after the decrease, QUERY 1606. If the transaction nesting depth is zero, all memory accesses made by the transaction are committed, STEP 1608. Further, the CPU exits transactional execution mode, STEP 1610, and the instruction exits, STEP 1612.

[0309] If, returning to QUERY 1606, the transaction nesting depth is not zero, the TRANSACTION END statement simply terminates.

[0310] If the CPU is in transaction execution mode at the beginning of the operation, the condition code is set to 0; otherwise, the condition code is set to 2.

[0311] Note that the effective floating-point operation control (F), the AR modification control (A), and the program interrupt filter control (PIFC) are reset to their respective values ​​prior to the TRANSACTION BEGIN statement that initiated the just-ended level. Furthermore, a serialization function is executed upon completion of the operation.

[0312] The PER statement fetch and transaction end events detected at the completion of the outermost TRANSACTION END statement do not cause the transaction to abort.

[0313] In one example, the TEND instruction also contains a base field B2 and a displacement field D2, which are combined (e.g., added) to create a second operand address. In this example, a token match can be performed. For example, if B2 is nonzero, selected bits of the second operand address are matched against a transaction token formed by the corresponding TBEGIN. If there is no match, an exception is raised (e.g., PIC 0006).

[0314] The above provides an effective means for updating multiple non-contiguous objects in memory without classical (coarse-grained) serialization, such as blocking, which offers the potential for significant multiprocessor performance improvements. Thus, multiple non-contiguous objects are updated without the enforcement of further coarse-grained memory access ordering provided by classical techniques such as locking and semaphores. Speculative processing is provided without cumbersome recovery facilities, and constrained transactions are offered for simple updates with low memory footprint.

[0315] Transactional execution can be used in a variety of scenarios, including, but not limited to, partial embedding, speculative processing, and lock ejection. With partial embedding, the subset to be included in the execution path is enclosed in TBEGIN / TEND. TABORT can be included to roll back state upon premature exit. For speculation, such as in Java, null checks of dereferenced pointers can be deferred until the loop edge using a transaction. If the pointer is null, the transaction can be safely aborted using TABORT, which is included in TBEGIN / TEND.

[0316] With regard to a lock omission, an example of its use is given with reference to Fig. 17A to 17B and the code fragment provided below.

[0317] Fig. 17A illustrates a doubly linked list 1700 of a plurality of queue elements 1702a to 1702d. A new queue element 1702e is to be inserted into the doubly linked list of queue elements 1700. Each queue element 1702a to 1702e contains a forward pointer 1704a to 1704e and a backward pointer 1706a to 1706e. As shown in Fig. 17B, ​​to add queue element 1702e between queue elements 1702b and 1702c, (1) back pointer 1706e is set to point to queue element 1702b, (2) forward pointer 1704e is set to point to queue element 1702c, (3) back pointer 1706c is set to point to queue element 1702e, and (4) forward pointer 1704b is set to point to queue element 1702e.

[0318] An example of a code fragment that Fig.17A to 17B is shown below: * R1 - Address of the new queue element to be inserted. * R2 - address of the insertion point; the new element is inserted before the element pointed to by R2. NEW USE OFUSE OFLHI QEL, R1 CURRENT QEL, R1 R15,10 Number of reloads RIBBON TBEGIN TDB,X'C000' Start transaction (save GRs 0 to 3) JNZ BROKEN CC nonzero means aborted. LG R3,CURR.BWD Point to previous element. Make addressable. Update previous forward pointer. Update current back pointer. Update new forward pointer. Update new back pointer. PREVIOUS USE OFSTG QEL, R3R1,PREV.FWD STG R1,CURR.BWD STG R2,NEW.FWD STG R3,NEW.BWD TEND TransactionEndCC3: Non-repeatable abort. ABORTED ... NO_RETRY JCT R15, LOOP Repeat transaction several times J NO_RETRY No success after 10 attempts; do it the hard way.

[0319] In one example, if the transaction is used for lock omission, but the fallback path uses a lock, the transaction must at least fetch the lock word to determine that it is available. The processor ensures that the transaction aborts if another CPU accesses the lock non-transactionally.

[0320] As used herein, storage, central storage, main memory, memory, and main working memory are used interchangeably unless otherwise implicitly by use or explicitly stated. Furthermore, in one embodiment, effectively deferring a transaction includes delaying committing transactional stores to main working memory until a selected transaction completes; in another embodiment, effectively deferring a transaction includes allowing transactional updates to working memory but retaining the old values ​​and restoring the working memory to the old values ​​upon termination.

[0321] As will be appreciated by one of ordinary skill in the art, one or more aspects may be embodied as a system, method, or computer program product. Accordingly, one or more aspects may take the form of a fully hardware embodiment, a fully software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to herein as a "circuit," "module," or "system." Further, one or more embodiments may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied therein.

[0322] Any combination of one or more computer-readable media may be used. The computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or unit, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program that can be used by or in connection with an instruction-executing system, apparatus, or device.

[0323] With reference to Fig. 18, in one example, a computer program product 1800 includes, for example, one or more non-transitory computer-readable storage media 1802 for storing thereon computer-readable program code means or logic 1804 to provide and facilitate one or more embodiments.

[0324] Program code embodied in a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wired, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0325] Computer program code for performing operations for one or more embodiments may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like, and conventional procedural programming languages ​​such as the "C" programming language, assembly language, or similar programming languages. The program code may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter scenario, the remote computer may be connected to the user's computer over any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, over the Internet using an Internet service provider).

[0326] One or more embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may be implemented by computer program instructions.These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other devices that process programmable data to produce a machine such that the instructions, executing via the processor of the computer or other devices that process programmable data, create means for implementing the functions / acts specified in the flowchart and / or the block or blocks of the block diagram.

[0327] These computer program instructions may also be stored in a computer-readable medium that can direct a computer, other device that processes programmable data, or other devices to function in a particular manner such that the instructions stored in the computer-readable medium produce an article of manufacture, including instructions that implement the function / act specified in the flowchart and / or the block or blocks of the block diagram.

[0328] The computer program instructions may also be loaded onto a computer, other device that processes programmable data, or other devices to cause the execution of a series of operations on the computer, other device that executes programmable data, or other devices to produce a computer-implemented process, such that the instructions executing on the computer or other programmable device provide processes for implementing the functions / acts specified in the flowchart and / or the block or blocks of the block diagram.

[0329] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code comprising one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions specified in the block may occur in a different order than indicated in the figures. For example, two blocks shown consecutively may actually execute substantially in parallel, or the blocks may sometimes execute in the reverse order, depending on the functionality involved.It is also noted that each block in the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0330] In addition to the foregoing, one or more aspects may be provided, offered, deployed, managed, maintained, etc., by a service provider that provides management of customer environments. For example, the service provider may create, maintain, support, etc., computer code and / or computer infrastructure that performs one or more aspects for one or more customers. In return, the service provider may, for example, receive payment from the customer under a subscription and / or fee agreement. Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third-party providers.

[0331] In one aspect, an application may be used to perform one or more embodiments. For example, using an application comprises providing a computing infrastructure capable of performing one or more embodiments.

[0332] As a further aspect, a computing infrastructure may be used that comprises integrating computer-readable code into a computing system, in which the code in combination with the computing system is capable of performing one or more embodiments.

[0333] As yet another aspect, a process for integrating a computing infrastructure may be provided, comprising integrating computer-readable code into a computer system. The computer system comprises a computer-readable medium, the computer medium comprising one or more embodiments. The code, in combination with the computer system, is capable of executing one or more embodiments.

[0334] Although various embodiments are described above, these are only examples. For example, computing environments of other architectures may be used to incorporate and utilize one or more embodiments. Furthermore, different instructions, instruction formats, instruction fields, and / or instruction values ​​may be used. Furthermore, various, further, and / or additional constraints / defaults may be provided / used. Many variations are possible.

[0335] Furthermore, other types of computing environments may benefit from and be used. For example, a computing system suitable for storing and / or executing program code may be used, including at least two processors connected directly or indirectly to memory elements via a system bus. The memory elements include, for example, local memory used during actual execution of the program code, mass storage, and cache memory that provides temporary storage of at least some program code to reduce the number of times code must be retrieved from mass storage during execution.

[0336] Input / output or I / O devices (including, but not limited to, keyboards, displays, pointing devices, DASD, tape, CDs, DVDs, thumb drives, and other storage devices, etc.) can be connected to the system either directly or through intermediate I / O controllers. Network adapters can also be connected to the system to enable the computing system to connect to other computing systems or remotely located printers or storage devices via intervening private or public networks. Modems, cable modems, or Ethernet cards are just a few of the available types of network adapters.

[0337] With reference to Fig.19, representative components of a host computer system 5000 for implementing one or more embodiments are illustrated. The representative host computer 5000 includes one or more CPUs 5001 in communication with a computer memory (i.e., central storage) 5002, as well as I / O interfaces to storage media devices 5011 and networks 5010 for exchanging data with other computers or SANs or the like. The CPU 5001 is compatible with an architecture having an architected instruction set and architecture-bound functionality. The CPU 5001 may have an access register translation (ART) 5012 including an ART translation buffer (ALB) 5013 for selecting an address space to be used by a dynamic address translation (DAT) 5003 for translating program addresses (virtual addresses) to real memory addresses.A DAT typically includes a translation buffer (TLB) 5007 for caching translations so that later accesses to the block of computer memory 5002 do not require the delay of an address translation. Typically, a cache 5009 is used between computer memory 5002 and processor 5001. Cache 5009 may be hierarchical, with a large cache available to more than one CPU and smaller, faster (lower-level) caches between the large cache and each CPU. In some implementations, the lower-level caches are split to provide separate lower-level caches for instruction fetch and data access.In one embodiment, a transaction diagnostic block (TDB) 5100 and one or more buffers 5101 for the TX facility may be stored in one or more of cache 5009 and memory 5002. In one example, in TX mode, data is initially stored in a TX buffer, and when TX mode ends (e.g., outermost TEND), the data in the buffer is stored (committed) in memory, or the data in the buffer is discarded in the event of an abort.

[0338] In one embodiment, an instruction is fetched from memory 5002 by an instruction fetch unit 5004 via a buffer 5009. The instruction is decrypted in an instruction decryption unit 5006 and forwarded (in some embodiments along with other instructions) to an instruction execution unit or units 5008. Typically, multiple execution units 5008 are used, for example, an arithmetic execution unit, a floating-point execution unit, and a branch instruction execution unit. Further, in one embodiment of the TX facility, various TX control elements 5110 may be used. The instruction is executed by the execution unit, which accesses operands from instruction-specified registers or memory as needed.When an operand is to be accessed (loaded or stored) from memory 5002, a load / store unit 5005 typically handles the access under the control of the instruction being executed. Instructions can be executed in hardware circuitry or in internal microcode (firmware), or by a combination of both.

[0339] According to one aspect of the TX facility, the processor 5001 also includes a PSW 5102 (e.g., TX and / or abort PSW), a nesting depth 5104, a TDBA 5106, and one or more control registers 5108.

[0340] As noted, a computer system contains information in local (or main) memory, as well as addressing, protection, and reference and change records. Some aspects of addressing include the format of addresses, the concept of address spaces, the different types of addresses, and how one address type translates into another. Some main memory contains permanently assigned memory locations. Main memory provides the system with directly addressable, fast-access data storage. Both data and programs must be loaded into main memory (by input devices) before they can be processed.

[0341] Main memory may contain one or more smaller, fast-access buffers, sometimes called caches. A cache is usually physically associated with a CPU or I / O processor. Except for performance, the effects of physical design and the use of different storage media are generally not observable by the program.

[0342] Separate caches can be maintained for instructions and for data operands. Information in a cache is maintained in contiguous bytes on an integral boundary called a cache block or cache line (or line for short). A model may provide an EXTRACT CACHE ATTRIBUTE instruction that returns the size of a cache line in bytes. A model may also provide PREFETCH DATA and PREFETCH DATA RELATIVE LONG instructions, which affect the prefetching of memory in the data or instruction cache or the release of data from the cache.

[0343] Memory is viewed as a long horizontal sequence of bits. For most operations, memory accesses occur in a left-to-right sequence. The sequence of bits is divided into units of eight bits. An eight-bit unit is called a byte, which is the basic building block of all information formats. Each byte location in memory is identified by a unique non-negative integer, which is the address of that byte location, or simply the byte address. Adjacent byte locations have consecutive addresses, starting with 0 on the left and continuing in a left-to-right sequence. Addresses are unsigned binary integers and are 24, 31, or 64 bits.

[0344] Information is transferred between memory and a CPU or channel subsystem one byte or group of bytes at a time. Unless otherwise specified, for example, in z / Architecture, a group of bytes in memory is addressed by the most significant byte of the group. The number of bytes in the group is specified either implicitly or explicitly by the operation to be performed. When a group of bytes is used in a CPU operation, it is called an array. Within each group of bytes, for example, in z / Architecture, bits are numbered in a sequence from left to right. In z / Architecture, the most significant bits are sometimes referred to as the "high-order bits" and the least significant bits as the "low-order bits." However, bit numbers are not memory addresses. Only bytes can be addressed. To manipulate individual bits of a byte in memory, the entire byte is accessed.The bits in a byte are numbered 0 to 7 from left to right (e.g., in the z / Architecture). The bits in an address can be numbered 8 to 31 or 40 to 63 for 24-bit addresses, or 1 to 31 or 33 to 63 for 31-bit addresses; they are numbered 0 to 63 for 64-bit addresses. In one example, bits 8 to 31 and 1 to 31 apply to addresses residing in a memory location (e.g., a register) that is 32 bits wide, whereas bits 40 to 63 and 33 to 63 apply to addresses residing in a 64-bit memory location. In any other fixed-length multi-byte format, the bits that comprise the format are numbered sequentially from 0. For the purpose of error detection and preferably for correction, one or more check bits may be transmitted with each byte or with a group of bytes.Such check bits are automatically generated by the machine and cannot be directly controlled by the program. Memory capacities are expressed as a number of bytes. If the length of a memory operand field is implied by an instruction's operation code, the field is of fixed length, which can be one, two, four, eight, or 16 bytes. Larger fields may be implied for some instructions. If the length of a memory operand field is not implied but is explicitly stated, the field is of variable length. Variable-length operands can vary in length by increments of one byte each (or, for some instructions, in multiples of two bytes or other multiples).When information is placed into memory, only the contents of those byte locations contained in the specified field are replaced, even if the width of the physical path to memory is greater than the length of the field being stored.

[0345] Certain units of information must be located on an integral boundary in memory. A boundary is said to be integral for a unit of information if its memory address is a multiple of the unit's length in bytes. Fields of 2, 4, 8, 16, and 32 bytes on an integral boundary are referred to by a special name. A halfword is a group of two consecutive bytes on a two-byte boundary and is the basic building block of instructions. A word is a group of four consecutive bytes on a four-byte boundary. A doubleword is a group of eight consecutive bytes on an eight-byte boundary. A quadword is a group of 16 consecutive bytes on a 16-byte boundary. An octetword is a group of 32 consecutive bytes on a 32-byte boundary.When memory addresses specify halfwords, words, doublewords, quadwords, and octwords, the binary representation of the address contains one, two, three, four, or five least significant zero bits, respectively. Instructions must be located on integral two-byte boundaries. There is no boundary alignment requirement for the memory operands of most instructions.

[0346] For units that implement separate instruction and data operand caches, a significant delay may be noticed if the program stores to a cache line from which instructions are subsequently fetched, without considering whether the store changes the instructions that are subsequently fetched.

[0347] In one example, the embodiment may be implemented by software (sometimes referred to as licensed internal code, firmware, microcode, picocode, and the like, all of which would be consistent with one or more embodiments). Referring to Fig.19, software program code embodying one or more aspects may be accessed by processor 5001 of host system 5000 from long-term storage media devices 5011, such as a CD-ROM drive, a tape drive, or a hard disk drive. The software program code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard disk drive, or a CD-ROM. The code may be distributed on such media or may be distributed to users from computer memory 5002 or from a memory of a computer system over a network 5010 to other computer systems for use by users of such other systems.

[0348] The software program code includes an operating system that controls the function and interaction of the various computer components and one or more application programs. Program code is typically migrated from storage media device 5011 to computer memory 5002 at a relatively higher speed, where it is available for processing by processor 5001. The techniques and methods for embodying software program code in memory, on physical media, and / or distributing software code over networks are known and will not be discussed further herein. Program code created and stored on a tangible medium (including, but not limited to, electronic memory (RAM) modules, flash memory, CDs, DVDs, magnetic tape, and the like) is often referred to as a "computer program product."The computer program product medium is typically readable by processing circuitry for execution by the processing circuitry, which is preferably located in a computer system.

[0349] Fig. Figure 20 illustrates a representative workstation or server hardware system in which one or more embodiments may be implemented. The system 5020 of Fig.20 shows a representative basic computer system 5021, such as a PC, workstation, or server, including optional peripherals. The basic computer system 5021 includes one or more processors 5026 and a bus used to connect and facilitate data transfer between the processor(s) 5026 and the other components of the system 5021, according to known techniques. The bus connects the processor 5026 to a memory 5025 and a long-term storage 5027, which may include a hard disk drive (including any magnetic media, CD, DVD, and flash memory) or, for example, a tape drive.The system 5021 may also include a user interface adapter that connects the microprocessor 5026 via the bus to one or more interface devices such as a keyboard 5024, a mouse 5023, a printer / scanner 5030, and / or other interface devices, which may be any user interface device such as a touch screen, a digital input pad, etc. The bus also connects a display device 5022 such as an LCD screen or monitor to the microprocessor 5026 via a display adapter.

[0350] System 5021 may communicate with other computers or networks of computers via a network adapter 5028 capable of communicating with a network 5029. Exemplary network adapters include data links, Token Ring, Ethernet, or modems. Alternatively, system 5021 may communicate using a wireless interface, such as a CDPD (Cellular Digital Packet Data) card. System 5021 may be associated with other such computers in a local area network (LAN) or a wide area network (WAN), or system 5021 may be a client in a client / server arrangement with another computer, etc. All of these configurations, as well as the corresponding communication hardware and software, are well known in the art.

[0351] Fig.Figure 21 illustrates a computing network 5040 in which one or more embodiments may be implemented. Computing network 5040 may include a plurality of individual networks, such as a wireless network and a wired network, each of which may include a plurality of individual workstations 5041, 5042, 5043, 5044. As will be appreciated by one of ordinary skill in the art, one or more LANs may additionally be included, where a LAN may include a plurality of intelligent workstations connected to a host processor.

[0352] With further reference to Fig.21, the networks may also include mainframe computers or servers, such as gateway computers (client server 5046) or application servers (remotely located server 5048 that can access a data repository and that can also be accessed directly from a workstation 5045). A gateway computer 5046 serves as the entry point into each network. A gateway is required when connecting one network protocol to another. The gateway 5046 may preferably be connected to another network (for example, the Internet 5047) using a data link. The gateway 5046 may also be connected directly to one or more workstations 5041, 5042, 5043, 5044 using a data link. The gateway computer may be implemented using an IBM eServer System z server, available from International Business Machines Corporation.

[0353] With simultaneous reference to Fig. 20 and Fig. 21, software program code 5031, which may embody one or more aspects, may be accessed by processor 5026 of system 5020 from long-term storage media 5027, such as a CD-ROM drive or a hard disk drive. The software program code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard disk drive, or a CD-ROM. The code may be distributed on such media or may be distributed to users 5050, 5051 from the memory or storage of one computer system over a network to other computer systems for use by users of such other systems.

[0354] Alternatively, the program code may be embodied in memory 5025 and accessed by processor 5026 using the processor bus. Such program code includes an operating system that controls the function and interaction of the various computer components and one or more application programs 5032. Program code is typically migrated from storage media 5027 to high-speed memory 5025, where it is available for processing by processor 5026. The techniques and methods for embodying software program code in memory, on physical media, and / or distributing software code over networks are well known and will not be discussed further herein.Program code created and stored on a tangible medium (including, but not limited to, electronic memory (RAM), flash memory, CDs, DVDs, magnetic tape, and the like) is often referred to as a "computer program product." The computer program product medium is typically readable by processing circuitry for execution by the processing circuitry, preferably located in a computer system.

[0355] The cache most readily available to the processor (usually faster and smaller than other processor caches) is the lowest-level (L1 or level one) cache, and the main memory (main working memory) is the highest-level cache (L3 if there are three levels). The lowest-level cache is often divided into an instruction cache (I-cache), which contains machine instructions to be executed, and a data cache (D-cache), which contains data operands.

[0356] With reference to Fig.Figure 22 illustrates an exemplary processor embodiment for processor 5026. Typically, one or more levels of cache 5053 are used to buffer blocks of memory to improve processor performance. Cache 5053 is a high-speed buffer that contains cache lines of memory data that are likely to be used. Typical cache lines are 64, 128, or 256 bytes of memory data. Separate caches are more often used to cache instructions than to cache data. Cache coherence (synchronization of copies of lines in memory and the caches) is often provided by various "snoop" algorithms known in the art. The main memory 5025 of a processor system is often referred to as the cache.In a processor system with four levels of cache 5053, main memory 5025 is sometimes referred to as the Level 5 (L5) cache because it is typically faster and contains only a portion of the non-volatile storage (DASD, tape, etc.) available to a computer system. Main memory 5025 acts as a "cache" for pages of data that are swapped into and out of main memory 5025 by the operating system.

[0357] A 5061 program counter (instruction counter) tracks the address of the current instruction to be executed. A program counter in a z / Architecture processor is 64 bits and can be truncated to 31 or 24 bits to support previous addressing boundaries. A program counter is typically embodied in a computer's PSW (Program Status Word) so that it persists through a context switch. Therefore, a running program that has a program counter value can be interrupted, for example, by the operating system (context switch from the program environment to the operating system environment). The program's PSW maintains the program counter value while the program is inactive, and the operating system's program counter (in the PSW) is used while the operating system is executing. Normally, the program counter is incremented by an amount equal to the number of bytes in the current instruction.RISC (Reduced Instruction Set Computing) instructions are typically fixed-length, whereas CISC (Complex Instruction Set Computing) instructions are typically variable-length. IBM z / Architecture instructions are CISC instructions and are 2, 4, or 6 bytes long. The program counter 5061 is modified either by a context switch operation or, for example, an affected branch operation of a branch instruction. In a context switch operation, the current program counter value is stored in the program status word along with other state information about the executing program (such as condition codes), and a new program counter value is loaded that points to an instruction of a new program module to be executed.An affected branch operation is performed to allow the program to make decisions or to loop within the program by loading the result of the branch instruction into the program counter 5061.

[0358] Typically, an instruction fetch unit 5055 is used to fetch instructions for processor 5026. The fetch unit fetches either "next following instructions," target instructions of affected branch instructions, or the first instructions of a program after a context switch. Modern instruction fetch units use prefetch techniques to speculatively prefetch instructions based on the likelihood that the prefetched instructions could be used. For example, a fetch unit may fetch 16 bytes of an instruction containing the next following instruction and additional bytes of other following instructions.

[0359] The fetched instructions are then executed by processor 5026. In one embodiment, the fetched instruction(s) are passed to a forwarding unit 5056 of the fetch unit. The forwarding unit decrypts the instruction(s) and forwards information about the encrypted instruction(s) to corresponding units 5057, 5058, 5060. An execution unit 5057 typically receives information about decrypted arithmetic instructions from the instruction fetch unit 5055 and performs arithmetic operations on operands according to the instruction's operation code. Operands are preferably provided to the execution unit 5057 either from memory 5025, from architectural registers 5059, or from an immediate field of the instruction being executed.When results of execution are stored, they are stored either in memory 5025, in registers 5059, or in other machine hardware (such as control registers, PSW registers, and the like).

[0360] Virtual addresses are converted to real addresses using a dynamic address translation 5062 and optionally using the access register translation 5063.

[0361] A processor 5026 typically has one or more units 5057, 5058, 5060 to perform the function of the instruction. With reference to Fig.23A, an execution unit 5057 may communicate 5071 with architecturally bound general purpose registers 5059, a decryption / forwarding unit 5056, a load / store unit 5060, and other processor units 5065 via interface logic 5071. An execution unit 5057 may use multiple register circuits 5067, 5068, 5059 to manage information upon which the arithmetic logic unit (ALU) 5066 executes. The ALU performs arithmetic operations such as adding, subtracting, multiplying, and dividing, as well as logical functions such as AND, OR, and exclusive OR (XOR), rotating, and shifting. Preferably, the ALU supports specialized operations that are design-dependent. Additional circuitry may provide additional architectural features 5072, including, for example, condition codes and recovery support logic.Typically, the result of an ALU operation is managed in an output register circuit 5070, which can forward the result to a variety of further processing functions. There are many arrangements of processor units; the present description is intended only to provide a representative understanding of one embodiment.

[0362] For example, an ADD instruction would be executed in an execution unit 5057 with arithmetic and logic functionality, whereas a floating-point instruction, for example, would be executed in a floating-point execution with a dedicated floating-point function. Preferably, an execution unit operates on operands identified by an instruction by performing a function defined by an operation code on the operands. For example, an ADD instruction may be executed by an execution unit 5057 on operands found in two registers 5059 identified by register fields of the instruction.

[0363] Execution unit 5057 performs arithmetic addition on two operands and stores the result in a third operand, where the third operand can be a third register or one of the two source registers. The execution unit preferably uses an arithmetic logic unit (ALU) 5066, which can perform a variety of logical functions such as shift, rotate, AND, OR, and XOR, as well as a variety of algebraic functions, including add, subtract, multiply, and divide. Some ALUs 5066 are designed for scalar operations and some for floating-point operations. Depending on the architecture, data can be big-endian (with the least significant byte at the highest byte address) or little-endian (with the least significant byte at the lowest byte address). The IBM z / Architecture is big endian.Signed fields can be sign and magnitude, one's complement, or two's complement, depending on the architecture. A two's complement number has the advantage that the ALU does not need to develop a subtraction function, since either a negative or a positive value in two's complement requires only one addition within the ALU. Numbers are generally described in shorthand, with a 12-bit field defining the address of a 4,096-byte block and is generally described as a 4-KB (kilobyte) block.

[0364] With reference to Fig.23B, branch instruction information for executing a branch instruction is typically sent to a branch unit 5058, which often uses a branch prediction algorithm, such as a branch history table 5082, to predict the result of the branch before further conditional operations complete. The target of the current branch instruction is retrieved and speculatively executed before the conditional operations complete. When the conditional operations complete, the speculatively executed branch instructions are either completed or discarded based on the conditions of the conditional operation and the presumed result.A typical branch instruction may check condition codes and branch to a target address if the condition codes match the branch instruction's branch request. A target address may be calculated based on multiple numbers, including those found, for example, in register fields or an immediate field of the instruction. Branch unit 5058 may use an ALU 5074, which has a plurality of input register circuits 5075, 5076, 5077 and an output register circuit 5080. Branch unit 5085 may, for example, exchange data 5081 with general purpose registers 5059, decryption / forwarding unit 5056, or other circuits 5073.

[0365] The execution of a group of instructions may be aborted for a variety of reasons, including, for example, a context switch initiated by an operating system, a program exception or error causing a context switch, an I / O interrupt signal causing a context switch, or multithreading activity of a plurality of programs (in a multithreaded environment). Preferably, a context switch action stores state information about a currently executing program and then loads state information about another program that is called. State information may be stored, for example, in hardware registers or in memory. State information preferably includes a program counter value pointing to a next instruction to be executed, condition codes, translation information, and architectural register contents.A context switch activity can be performed by hardware circuitry, application programs, operating system programs, or firmware code (microcode, picocode, or licensed internal code (LIC)) alone or in combination.

[0366] A processor accesses operands according to instruction-defined procedures. The instruction may provide an immediate operand using the value of a portion of the instruction, may provide one or more register fields that explicitly point to either general-purpose registers or special-purpose registers (for example, floating-point registers). The instruction may use implicit registers identified as operands by an operation code field. The instruction may use memory locations for operands.A memory location of an operand can be provided by a register, an immediate field, or a combination of registers and an immediate field, as exemplified by the z / Architecture long shifter, where the instruction defines, for example, a base register, an index register, and an immediate field (shift field), which are added together to provide the operand's address in memory. A memory location herein typically implies a memory location in main memory (main storage) unless otherwise specified.

[0367] With reference to Fig.23C, a processor accesses memory using a load / store unit 5060. The load / store unit 5060 may perform a load operation by obtaining the address of the destination operand in memory 5053 and loading the operand into a register 5059 or other memory location 5053, or it may perform a store operation by obtaining the address of the destination operand in memory 5053 and storing data obtained from a register 5059 or another memory location 5053 into the destination operand location in memory 5053. The load / store unit 5060 may be speculative and access memory in a sequence that is out of order with respect to the instruction sequence, but the load / store unit 5060 must maintain the appearance to programs that the instructions were executed in order.A load / store unit 5060 can communicate 5084 with general purpose registers 5059, a decryption / forwarding unit 5056, a cache / memory interface 5053, and other elements 5083, and includes various register circuits 5086, 5087, 5088, and 5089, ALUs 5085, and control logic 5090 to calculate memory addresses and provide pipeline sequencing to keep operations in order. Some operations may be out of order, but the load / store unit provides functionality that makes out-of-order operations appear to the program as if they were executed in order, as is known in the art.

[0368] Preferably, addresses that an application program "sees" are often referred to as virtual addresses. Virtual addresses are sometimes referred to as "logical addresses" and "effective addresses." These virtual addresses are virtual in that they are mapped to a physical memory location by one of a variety of dynamic address translation (DAT) technologies, including, but not limited to, simply prepending an offset value to a virtual address, translating the virtual address through one or more translation tables, the translation tables preferably comprising at least a segment table and a page table alone or in combination, the segment table having an entry pointing to the page table.In the z / Architecture, a translation structure is provided that includes a first-order table, a second-order table, a third-order table, a segment table, and an optional page table. Address translation performance is often improved by using a translation buffer (TLB), which has entries that map a virtual address to a corresponding physical memory location. The entries are created when the DAT translates a virtual address using the translation tables. Subsequent use of the virtual address can then use the fast TLB entry instead of the slow sequential accesses of a translation table. TLB contents can be managed using a variety of replacement algorithms, including LRU (Least Recently Used).

[0369] In the case of a processor in a multiprocessor system, each processor is responsible for keeping shared resources such as I / O, cache, TLBs, and memory interlocked for coherence. Typically, "snoop" technologies are used to manage cache coherence. In a snoop environment, each cache line can be marked as having any of a shared state, an exclusive state, a modified state, an invalid state, and the like to facilitate sharing.

[0370] The I / O units 5054 ( Fig. 22) provide the processor with a means of connecting to peripheral devices, including tape, floppy disk, printers, displays, and networks. I / O devices are often represented to the computer program as software drivers. In mainframes such as IBM's System z ®Channel adapters and open system adapters are mainframe I / O units that provide data transfer between the operating system and peripheral devices.

[0371] Furthermore, other types of computing environments may benefit from one or more aspects. As an example, an environment may include an emulator (e.g., software or other emulation mechanisms) by which a particular architecture (e.g., including instruction execution, architecturally arranged functions such as address translation, and architecturally arranged registers) or a subset thereof is emulated (e.g., on a native computer system having a processor and memory). In such an environment, one or more emulation functions of the emulator may implement one or more embodiments, even though a computer executing the emulator may have a different architecture than the emulated functions.For example, in emulation mode, the specific emulated instruction or operation is decoded, and a corresponding emulation function is created to implement the individual instruction or operation.

[0372] For example, in an emulation environment, a host computer includes memory for storing instructions and data; an instruction fetch unit for fetching instructions from memory and optionally providing local buffering for the fetched instruction; an instruction decryption unit for receiving the fetched instructions and determining the type of instructions that were fetched; and an instruction execution unit for executing the instructions. Execution may include loading data from memory into a register; storing the data from the register back into memory; or performing an arithmetic or logical operation type as determined by the decryption unit. In one example, each unit is implemented in software. For example, the operations performed by the units are implemented as one or more subroutines in the emulator software.

[0373] In particular, in a mainframe, architecture-specific machine instructions are used by programmers, today usually "C" programmers, often through a compiler application. These instructions, stored in the storage medium, can be executed natively in a z / Architecture IBM server or, alternatively, in machines running other architectures. They can be used in existing and future IBM mainframe servers and on other IBM machines. ® emulated (e.g. IBM Power Systems™ servers and IBM System x® servers). They can be run on machines running Linux using hardware developed by IBM ® , Intel ®, AMD, and others, can run on a wide variety of machines. In addition to running on this hardware under a z / Architecture, Linux® can also be used on machines that use emulation by Hercules, UMX, or FSI (Fundamental Software, Inc.), generally running in an emulation mode. In emulation mode, emulation software is executed by a native processor to emulate the architecture of an emulated processor. Intel is a trademark or registered trademark of Intel Corporation or its subsidiaries in the U.S. and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

[0374] The native processor typically runs emulation software, which includes either firmware or a native operating system to perform an emulation of the emulated processor. The emulation software is responsible for fetching and executing instructions of the emulated processor architecture. The emulation software maintains an emulated program counter to track instruction boundaries. The emulation software can simultaneously fetch one or more emulated machine instructions and convert the one or more emulated machine instructions into a corresponding set of native machine instructions for execution by the native processor. These converted instructions can be cached, allowing for faster conversion.However, the emulation software must maintain the architectural rules of the emulated processor architecture to ensure that operating systems and applications written for the emulated processor function correctly. Furthermore, the emulation software must provide resources identified by the emulated processor architecture, including, but not limited to, control registers, general-purpose registers, floating-point registers, dynamic address translation functionality including, for example, segment tables and page tables, interrupt mechanisms, context-switching mechanisms, time-of-day (TOD) timers, and architectural interfaces to I / O subsystems, so that an operating system or application program designed to run on the emulated processor can run on the native processor with the emulation software.

[0375] A specific emulated instruction is decoded, and a subroutine is called to perform the function of the particular instruction. An emulation software function that emulates a function of an emulated processor is implemented, for example, in a "C" subroutine or a driver or some other method of providing a driver for the specific hardware, as will be practical for one of ordinary skill in the art after understanding the description of the preferred embodiment. Various software and hardware emulation patents, including, but not limited to, U.S. Patent No. 5,551,013, entitled "Multiprocessor for Hardware Emulation" by Beausoleil et al.; and U.S. Patent No. 6,009,261, entitled "Preprocessing of Stored Target Routines for Emulating Incompatible Instructions on a Target Processor" by Scalzi et al.; and U.S. Patent No.5,574,873 entitled “Decoding Guest Instructions to Directly Access Emulation Routines that Emulate the Guest Instructions” by Davidian et al; and U.S. Patent No. 6,308,255 entitled “Symmetrical Multiprocessing Bus and Chipset Used for Coprocessor Support Allowing Non-Native Code to Run in a System” by Gorishek et al; and US Letters Patent No. 6,463,582 entitled “Dynamic Optimizing Object Code Translator for Architecture Emulation and Dynamic Optimizing Object Code Translation Method” to Lethin et al; and U.S. Patent No. 5,790,825 entitled “Method for Emulating Guest Instructions on a Host Computer Through Dynamic Recompilation of Host Instructions” by Eric Traut; and many others illustrate a variety of known ways of achieving emulation of an instruction format architecturally bound to another machine for a target machine, which is available to one skilled in the art.

[0376] In Fig.24, an example of an emulated host computer system 5092 is provided that emulates a host computer system 5000' of a host architecture. In the emulated host computer system 5092, the host processor (CPU) 5091 is an emulated host processor (or virtual host processor) and includes an emulation processor 5093 that has a different native instruction set architecture than that of the processor 5091 of the host computer 5000'. The emulated host computer system 5092 has a memory 5094 accessible by the emulation processor 5093. In the example embodiment, the memory 5094 is partitioned into a portion of host computer memory 5096 and a portion of emulation routines 5097. The host computer memory 5096 is available for programs of the emulated host computer 5092 according to the host computer architecture.The emulation processor 5093 executes native instructions of an architectural instruction set of a different architecture than that of the emulated processor 5091, the native instructions being obtained from the emulation routines' memory 5097, and can access a host instruction for execution from a program in the host computer memory 5096 by using one or more instructions obtained in a follow-up and access / decrypt routine that can decrypt the accessed host instruction(s) to determine a native instruction execution routine for emulating the function of the accessed host instruction.Additional features defined for the architecture of the host computer system 5000' may be emulated by architecture-specific feature routines, including, for example, features such as general purpose registers, control registers, dynamic address translation, I / O subsystem support, and processor cache. The emulation routines may also utilize features available in the emulation processor 5093 (e.g., general purpose registers and dynamic virtual address translation) to enhance the performance of the emulation routines. Specialized hardware and swap engines may also be provided to assist the processor 5093 in emulating the functionality of the host computer 5000'.

[0377] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It is further understood that the terms "comprises" and / or "comprising," when used in this specification, indicate the presence of specified features, integers, steps, acts, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, acts, elements, components, and / or groups thereof.

[0378] The corresponding structures, materials, acts, and equivalents of all means or step-plus-function elements in the following claims are intended to include, if any, all structures, materials, or acts for performing the function in combination with other claimed elements as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description, but is by no means intended to be exhaustive or limited to the form disclosed.

Claims

[1] A method for executing a machine instruction in a data processing environment, the method comprising: - obtaining, by a processor, a machine instruction for specifying a transaction start operation, the machine instruction being defined for computer execution according to a computer architecture, the machine instruction for specifying a transaction start operation comprising: ◯ an operation code; and ◯ a control field for specifying one or more controls to be used in a transactional execution, comprising at least a base field and a move field; and - an execution, by the processor, of the machine instruction, the execution comprising: ◯ determining from a field of the statement whether a transaction to be initiated by the begin transaction statement is a restricted transaction or an unrestricted transaction; ◯ initiating a restricted transaction on the basis that the field is a value, where the restricted transaction has one or more constraints associated with it, where the one or more constraints are not associated with any unrestricted transaction, and setting a condition code to a value indicating successful execution of the machine instruction; and ◯ on the basis that the field is another value, specifying a location for storing diagnostic information in an aborted unconstrained transaction, initiating the unconstrained transaction, and setting a condition code to the value indicating successful execution of the machine instruction, wherein the field indicates an unrestricted transaction, and wherein, based on the base field having a value, contents of a register indicated by the base field are combined with contents of the displacement field to create a first operand address, the first operand address indicating a location of a transaction diagnostic block usable for storing the diagnostic information upon abort. [2] The method of claim 1, wherein the field comprises the operation code. [3] A method according to any one of the preceding claims, wherein the control element field comprises one or more of the following: a general register storage mask for specifying one or more pairs of registers to be stored at the beginning of the transaction and restored upon abort; and Allow an access register modification field to control whether the transaction is authorized to modify an access register. [4] The method of claim 3, wherein the field indicates an unrestricted transaction, and wherein the control field further comprises: a floating-point operation field to control whether the transaction is authorized to execute specified floating-point instructions; and a program break filter control field to control whether certain classes of program break conditions lead to an interrupt. [5] A method according to any one of the preceding claims, wherein the one or more restrictions comprise: a limited number of instructions in the transaction; Statements in the transaction must be within a predefined memory range; certain pre-specified instructions may be included in the transaction, while others will be restricted; an access restriction by memory operand of the transaction; the transaction does not access memory operands in memory blocks that contain the predefined memory range; the transaction does not access instructions or memory operands using different logical addresses mapped to the same absolute address; and Operand references by transactions must be within a specified size. [6] A method according to any one of the preceding claims, wherein the method further comprises: executing a further machine instruction to terminate the transaction initiated by the transaction begin instruction, the further machine instruction comprising an end transaction instruction, the end transaction instruction comprising an operation code to specify the end transaction instruction. [7] The method of claim 6, wherein executing the further machine instruction comprises: a gradual reduction of transaction-related nesting depth; determining whether the incrementally reduced transaction-based nesting depth is zero; and a commit of memory accesses made by the transaction on the basis that the incrementally reduced transaction nesting depth is zero. [8] A computer system for executing a machine instruction, the machine instruction for initiating a transaction, in a data processing environment, wherein stores by other processors in memory locations of the transaction cause the transaction to be aborted, and wherein stores by instructions in the transaction are effectively delayed until a selected transaction is completed, the computer system comprising: a RAM; and a processor in communication with the memory, the computer system being configured to execute a method, the method comprising: obtaining a machine instruction for execution by a processor, the machine instruction being defined for computer execution according to a computer architecture, the machine instruction comprising: an operation code for specifying a transaction start operation; and a control field for specifying one or more controls to be used in a transactional execution; and an execution, by the processor, of the machine instruction, the execution comprising: determining from a field of the instruction whether a transaction to be initiated by the begin transaction instruction is a restricted transaction or an unrestricted transaction; initiating a restricted transaction based on the field being a value, and setting a condition code to a value indicating successful execution of the machine instruction, wherein the restricted transaction has one or more constraints associated with it, and wherein the one or more constraints comprise: at least a subset of general instructions is available, a limited number of instructions can be executed, access can be made to a limited number of memory operand locations, or the transaction is limited to a single nested level; and on the basis that the field is another value, specifying a location for storing diagnostic information in an aborted unconstrained transaction, initiating the unconstrained transaction, and setting a condition code to the value indicating successful execution of the machine instruction, wherein the field indicates an unrestricted transaction, and wherein the machine instruction further comprises a base field to be used in executing the transaction, and wherein, based on the base field having a value, contents of a register indicated by the base field are combined with contents of a displacement field to create a first operand address, the first operand address indicating a location of a transaction diagnostic block usable for storing the diagnostic information upon abort. [9] The computer system of claim 8, wherein the field further comprises one of: the operation code or a field of the instruction separate from the operation code. [10] A computer system according to any one of claims 8 or 9, wherein the control field comprises one or more of the following: a general register storage mask for specifying one or more pairs of registers to be stored at the beginning of the transaction and restored upon abort; and Allow an access register modification field to control whether the transaction is authorized to modify an access register. [11] The computer system of claim 10, wherein the field indicates an unrestricted transaction, and wherein the control field further comprises: a floating-point operation field to control whether the transaction is authorized to execute specified floating-point instructions; and a program break filter control field to control whether certain classes of program break conditions lead to an interrupt. [12] A computer system according to any one of claims 8 to 11, wherein the method further comprises: executing another machine instruction to terminate the transaction initiated by the transaction start instruction, wherein the further machine instruction comprises an end-of-transaction instruction, the end-of-transaction instruction comprising an operation code for specifying the end-of-transaction instruction. [13] The computer system of claim 12, wherein executing the further machine instruction comprises: a gradual reduction of transaction-related nesting depth; determining whether the incrementally reduced transaction-based nesting depth is zero; and a commit of memory accesses made by the transaction on the basis that the incrementally reduced transaction nesting depth is zero. [14] A computer system according to any one of claims 8 to 13, wherein the one or more constraints comprise: a limited number of instructions in the transaction; Statements in the transaction must be within a predefined memory range; certain pre-specified instructions may be included in the transaction, while others will be restricted; an access restriction by memory operand of the transaction; the transaction does not access memory operands in memory blocks that contain the predefined memory range; the transaction does not access instructions or memory operands using different logical addresses mapped to the same absolute address; and Operand references by transactions must be within a specified size. [15] A computer program product for executing a machine instruction in a data processing environment, the machine instruction for initiating a transaction, wherein stores by other processors in memory locations of the transaction cause the transaction to be aborted, and wherein stores by instructions in the transaction are effectively delayed until a selected transaction is completed, the computer program product comprising: a non-transitory computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform a method according to any one of claims 1 to 7.

Images