COMPUTER PROGRAM PRODUCT, COMPUTER SYSTEM AND METHOD FOR SIMULTANEOUSLY PREDICTING BRANCH ADDRESSES AND UPDATING REGISTER CONTENT

Abstract

A computer program product designed to simplify processing in a data processing environment, wherein the computer program product features: a computer-readable storage medium that is readable by a processing circuit and stores instructions for carrying out a procedure which includes: Predictions, using a processor of the data processing environment, of a predicted value to be used in a register-indirect branch, wherein the predicted value has a target address to which a register-indirect branch is to point according to the prediction; Storing the predicted value at a selected memory location accessible to one or more instructions of the data processing environment, wherein the storage is performed concurrently with the processing of the register-indirect branch, where, within the limits of a single architecture-defined instruction, the predicted destination address is stored at the selected memory location and in a program counter to redirect the instruction call to the predicted destination address; and Using the predicted value in speculative processing that includes register-indirect branching, wherein at least some of the one or more instructions are instructions of a code to which the register-indirect branch is supposed to refer according to the prediction, and wherein the use includes accessing the predicted value from the selected memory location by the at least some of the one or more instructions as part of the speculative processing.

Description

BACKGROUND

[0001] One or more aspects generally relate to a computer program product, a computer system, and a method for simultaneously predicting branch addresses and updating register contents, and more particularly to simplifying processing in a data processing environment.

[0002] Many data processing systems use register-indirect branching, where the location of the address of the next instruction to be executed is specified not in the address itself, but in a branch instruction. For example, the location of a register containing the address is specified.

[0003] Furthermore, according to commonly used application binary interfaces (ABIs), a branch address is first loaded into a general-purpose register (GPR) and then transferred to a special-purpose control register (SPR) before a register-indirect branch is performed. For example, in the Power Instruction Set Architecture (ISA) offered by International Business Machines Corporation, Armonk, New York, a branch instruction branches to a counter (CTR) special-purpose register. However, the special-purpose register is not loaded directly, but rather via a general-purpose register.

[0004] Reading the counter register is usually expensive. Therefore, at least one ABI specifies that the value of the CTR should be stored in another register, such as R12, when a branch is made to a subroutine (BCTR), so that the other register can be used as a base register by the called function. However, when a branch prediction is made, the branch address may be predicted before the R12 value has been loaded, causing the called subroutine to block in response to a data access, limiting performance.

[0005] The publication "Modeling Value Speculation" refers to speculative execution based on values ​​and, in particular, to a model for a methodical description of dynamically scheduled microarchitectures that use value speculation. The model isolates the parts of a microarchitecture that can be influenced by value speculation with respect to various variables and latency events. This provides systematic means for describing, evaluating, and comparing the performance of value-speculative microarchitectures (Sazeides, Y.: Modeling Value Speculation. In: Proceedings Eighth International Symposium on High Performance Computer Architecture, August 7, 2022, pp. 211–222. - ISSN 1530-0897. https: / / doi.org / 10.1109 / HPCA.2002.995711).

[0006] The paper "Perais, Arthur and Seznec, André: Practical data value speculation for future high-end processors. In: 2014 IEEE 20th International Symposium on High Performance" refers to a reconsideration of the concept of value prediction in a contemporary context and demonstrates its potential as a direction for improving current single-threaded performance. First, it was shown that any value predictor can achieve very high prediction accuracy using very simple hardware. This paves the way for an implementation of value prediction without a complex selective reissue mechanism to absorb mispredictions. Prediction is performed in the front-end of the in-order pipeline and validation in the back-end of the in-order pipeline, while the out-of-order engine is only slightly modified.Second, when predicting consecutive occurrences of the same instruction, previous context-based value predictors, which rely on the local value history, exhibit a complex critical loop that should ideally be implemented in a single cycle. To circumvent this requirement, a new value predictor, TAGE (VTAGE), is introduced that leverages the global branch history. VTAGE can seamlessly predict consecutive occurrences, allowing predictions to span multiple cycles (Perais, Arthur and Seznec, André: Practical data value speculation for future high-end processors. In: 2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA), June 19, 2014, pp. 428–439. - ISSN 2378-203X. https: / / doi.org / 10.1109 / HPCA.2014.6835952). SUMMARY

[0007] The invention is based on the object of creating an improved computer program product, an improved computer system, and an improved method for simultaneously predicting branch addresses and updating register contents. This object is achieved by the subject matter of the independent patent claims.

[0008] By providing a computer program product to simplify processing in a computing environment, deficiencies in the prior art are overcome and additional advantages are provided. The computer program product comprises a storage medium readable by processing circuitry and storing instructions for performing a method. The method includes, for example, predicting, using a processor of the computing environment, a predicted value to be used in a register-indirect branch. The predicted value is stored in a selected memory location accessible by one or more instructions of the computing environment, and the storing is performed concurrently with processing a register-indirect branch.The selected memory location is used, in addition to another memory location, to store an instruction address. The predicted value is used in speculative processing that includes the register-indirect branch.

[0009] By processing a register-indirect branch and simultaneously storing a predicted value resulting from this processing in a memory location (in addition to a program counter) that can be accessed by other instructions, processing is simplified and performance may be improved, especially if the predicted value is correct.

[0010] As one or more examples, the predicted value includes a target address to be used by an instruction fetch, and the selected memory location includes a hardware register. Further, in one example, using includes redirecting the instruction fetch to the target address.

[0011] In a further aspect, it is determined whether the predicted value is accurate. Based on the determination that the predicted value is inaccurate, a recovery is performed.

[0012] For example, recovery includes deleting one or more instructions executing subsequent to the use and replacing the predicted value with an unpredicted value. In one example, replacing includes using one or more rename registers to provide the unpredicted value.

[0013] In a single embodiment, storing comprises allocating a register to hold the predicted value and copying the predicted value into the register allocated to hold the predicted value.

[0014] As an example, the register is a rename register allocated for a logical register that is assigned to hold the predicted value. Furthermore, in a single embodiment, the rename register is marked as available.

[0015] Computer-implemented methods and systems relating to one or more aspects are also described and claimed herein. Furthermore, services relating to one or more aspects are also described and, where appropriate, claimed herein.

[0016] According to one aspect, a computer program product is provided to simplify processing in a data processing environment, the computer program product comprising: a computer-readable storage medium readable by processing circuitry and storing instructions for performing a method comprising: predicting, using a processor of the data processing environment, a predicted value to be used in a register-indirect branch; storing the predicted value in a selected memory location accessible by one or more instructions of the data processing environment, wherein the storing is performed concurrently with processing a register-indirect branch, and the selected memory location is used in addition to another memory location to store an instruction address;and using the predicted value in speculative processing that includes the register-indirect branch.;

[0017] According to another aspect, a computer system is provided to simplify processing in a data processing environment, the computer system comprising: a main memory; and a processor that communicates with the main memory, the computer system being configured to perform a method, the method comprising: predicting a predicted value to be used in a register-indirect branch; storing the predicted value in a selected memory location accessible by one or more instructions of the data processing environment, wherein the storing is performed concurrently with processing a register-indirect branch, and the selected memory location is used in addition to another memory location to store an instruction address;and using the predicted value in speculative processing that includes the register-indirect branch.;

[0018] According to another aspect, a computer-executed method is provided to facilitate processing in a computing environment, the computer-executed method comprising: predicting, using a processor of the computing environment, a predicted value to be used in a register-indirect branch; storing the predicted value in a selected memory location accessible by one or more instructions of the computing environment, wherein the storing is performed concurrently with processing a register-indirect branch, and the selected memory location is used in addition to another memory location to store an instruction address; and using the predicted value in speculative processing that includes the register-indirect branch.

[0019] Additional features and advantages are realized by the techniques described herein. Further embodiments and aspects are described in detail herein and are considered part of the claimed aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] One or more aspects are particularly pointed out and separately claimed as examples in the claims at the end of the description. The foregoing, as well as features and advantages of one or more aspects, will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, in which: Fig. 1A shows an example of a computing environment for incorporating and using one or more aspects of the present invention; Fig. 1B further details of a processor from Fig. 1A according to one or more aspects of the present invention; Fig. 1C shows further details of an example instruction execution pipeline used in accordance with one or more aspects of the present invention; Fig. 1D further details of an example of a processor of Fig. 1A according to one aspect of the present invention; Fig. 2 shows an example of processing associated with a prediction for a register-indirect branch according to one aspect of the present invention; Fig. 3 shows an example of checking prediction accuracy according to one aspect of the present invention; Fig. 4 shows another example of checking prediction accuracy according to an aspect of the present invention; Fig. 5 shows an example of processing associated with a prediction for a register-indirect branch and an associated register according to one aspect of the present invention; Fig. 6 shows another example of checking prediction accuracy according to an aspect of the present invention; Fig. 7 shows an example of checking the prediction accuracy for associated registers according to one aspect of the present invention; Fig. 8 shows an example of processing associated with an externally indicated affiliated register prediction (EIARP) according to one aspect of the present invention; Fig. 9 shows an example of processing associated with a context switch and prediction of an externally specified associated register according to one aspect of the present invention; Fig. 10 shows an example of processing associated with entering hardware exception / interrupt processing according to one aspect of the present invention; Fig. 11 shows an example of processing associated with terminating hardware exception / interrupt processing according to one aspect of the present invention; Fig. 12 shows an example of processing associated with a register-indirect branch prediction and the use of an externally specified associated register prediction in accordance with one aspect of the present invention; Fig. 13 shows an example of processing associated with a prediction for a register-indirect branch and for a prediction of whether an associated register can be predicted, according to an aspect of the present invention; Fig. 14 shows another example of checking prediction accuracy according to an aspect of the present invention; Fig. 15 shows another example of checking prediction accuracy for associated registers according to an aspect of the present invention; Fig. 16 shows yet another example of checking prediction accuracy for associated registers according to an aspect of the present invention; Fig. 17 shows an example of processing associated with register-indirect branch prediction and for dynamically selecting an associated register that can be predicted, in accordance with one aspect of the present invention; Fig. 18 shows an example of checking prediction accuracy for associated registers and updating a predictor according to one aspect of the present invention; Fig. 19 shows an example of processing associated with detecting a fusion sequence according to one aspect of the present invention; Fig. 20 shows an example of processing associated with a prediction of an externally specified associated register and a fusion-based membership sequence according to an aspect of the present invention; Fig. 21 shows an example of processing associated with performing branch prediction with a fusion-based associated sequence according to one aspect of the present invention; Fig. 22 shows an example of processing associated with determining whether an instruction is creating or deleting an association, in accordance with one aspect of the present invention; Fig. 23 shows an example of processing associated with predicting associated derived registers according to one aspect of the present invention; Fig. 24 shows an example of checking prediction accuracy for associated derived registers according to one aspect of the present invention; Fig. 25 shows an example of processing associated with branch prediction and fusion-based associated derived sequences according to one aspect of the present invention; the Fig. 26A to 26B illustrate a single embodiment for simplifying processing in a data processing environment according to one aspect of the present invention; Fig. 27A shows another example of a computing environment for incorporating and using one or more aspects of the present invention; Fig. 27B further details of the main memory of Fig. 27A shows; Fig. 28 shows a single embodiment of a cloud computing environment; and Fig. 29 shows an example of abstraction model layers. DETAILED DESCRIPTION

[0021] In one or more aspects, based on the prediction of a value of the contents of a register (e.g., a target address of a target address register) to be used for register-indirect branches, the predicted value is stored in the register (e.g., the target address register, also referred to herein as the predicted register). The register is then available for future use. For example, the contents of a target address register are updated and made available in connection with a prediction instruction fetch. When a target address is predicted, it is simultaneously made available both for an instruction fetch and for storage in a register or other selected memory location accessible by others (e.g., other instructions or operations). This allows others to use the predicted value.

[0022] As an example, the predicted register or memory location is a register or memory location other than a program counter that is automatically updated based on a prediction. For example, it is a register or memory location in addition to the program counter, such as a counter (CTR) register or another selected register / memory location. The target address, if predicted, is simultaneously made available to the predicted register because only one facility handles the register-indirect branch and stores the predicted target address. For example, it is within the bounds of a single architected instruction (e.g., at the hardware / software interface). No further architected instruction is required to copy or move the value to the predicted register / memory location.

[0023] In another aspect, in addition to predicting the value of the contents of a register and storing the predicted value in the predicted register, the predicted value is also stored in another memory location, such as another register used to facilitate processing. This other memory location or register is referred to herein as an associated memory location or register that stores the predicted value used by other instructions. The associated register is a register that is associated with the predicted register. For example, an associated register has a known relationship to another register (e.g., the predicted register), which is known, for example, to be a copy of the other register. In a particular case, both registers may be referenced with an instruction.For example, the MTCTR-R12 instruction moves the contents of R12 into the CTR register. Thus, R12 is associated with CTR. There are other such examples.

[0024] In yet another aspect, a control is provided to indicate whether an associated register should be used in the prediction. If an associated register is to be predicted, the control also provides an indication of the associated register (e.g., a register number). This control is, for example, code-specific and can be enabled / disabled for each unit of code, such as an application, process, function, module, or dynamically shared object (e.g., a library), as examples.

[0025] In yet another aspect, the predicted value can be used to predict a value to be stored in an associated derived register (or other memory location) to further simplify processing. An associated derived register is a register whose contents are derived from the contents of an associated register. For example, the contents of R12, along with an offset, can be used to obtain a value to be stored in a selected register, such as R2. Thus, in this example, R2 is an associated derived register. Other examples exist as well.

[0026] Furthermore, in one or more aspects, a particular sequence of instructions used in register-indirect branching that specifies one or more registers that can be predicted may be identified, and based thereon, a sequence of operations that perform operations of the particular sequence of instructions is combined by fusion to simplify processing. That is, a fusion process is performed to combine one or more instructions into a single composite process of operations. That is, the sequence of instructions is to be treated as a whole.

[0027] Various aspects are described herein. Furthermore, many variations are possible without departing from the spirit of aspects of the present invention. It should be noted that various aspects and features are described herein, and each aspect or feature may be combined with any other aspect or feature, subject to incompatibility.

[0028] A single embodiment of a data processing environment for incorporating and using one or more aspects of the present invention is described with reference to Fig. 1A. In one example, the computing environment is based on the z / Architecture offered by International Business Machines Corporation, Armonk, New York. A single embodiment of the z / Architecture is described in "z / Architecture Principles of Operation," IBM Publication No. SA22-7832-10, March 2015, which is hereby incorporated by reference in its entirety. Z / ARCHITECTURE is a registered trademark of International Business Machines Corporation, Armonk, New York, USA.

[0029] In another example, the computing environment is based on the Power Architecture offered by International Business Machines Corporation, Armonk, New York. A single embodiment of the Power Architecture is described in "Power ISA™ Version 2.07B," International Business Machines Corporation, April 9, 2015, which is hereby incorporated by reference in its entirety. POWER ARCHITECTURE is a registered trademark of International Business Machines Corporation, Armonk, New York, USA.

[0030] The computing environment can also be based on other architectures, including but not limited to Intel's x86 architectures. Other examples exist as well.

[0031] As in Fig. 1A, a computing environment 100 includes a computer system 102, shown, for example, in the form of a general-purpose computing device. The computer system 102 may include, but is not limited to, one or more processors or processing units 104 (e.g., central processing units (CPUs)), a memory 106 (referred to as main memory or random access memory, as examples), and one or more input / output (I / O) interfaces 108 interconnected via one or more buses and / or other connections 110.

[0032] Bus 110 represents one or more of any of several types of bus structures, including a main memory bus or a main memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. Examples of such architectures include, but are not limited to, the Industry Standard Architecture (ISA) local bus, the Micro Channel Architecture (MCA) local bus, the Enhanced ISA (EISA) local bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) local bus.

[0033] For example, main memory 106 may include a cache 120, such as a shared cache, that may be coupled to the local caches 122 of processors 104. Main memory 106 may further include one or more programs or applications 130, an operating system 132, and one or more computer-readable program instructions 134. Computer-readable program instructions 134 may be configured to perform functions of embodiments of aspects of the invention.

[0034] The computer system 102 may also communicate with one or more external devices 140, one or more network interfaces 142, and / or one or more data storage devices 144, for example, via I / O interfaces 108. Example external devices include a user terminal, a tape drive, a pointing device, a display, etc. The network interface 142 enables the computer system 102 to communicate with one or more networks, such as a local area network (LAN), a general purpose wide area network (WAN), and / or a public network (e.g., the Internet), that provide communication with other data processing devices or systems.

[0035] The data storage unit 144 may store one or more programs 146, one or more computer-readable program instructions 148, and / or data, etc. The computer-readable program instructions may be configured to perform functions of embodiments of aspects of the invention.

[0036] Computer system 102 may include and / or be connected to removable / non-removable, volatile / non-volatile storage media of a computer system. For example, it may include and / or be connected to a non-removable, non-volatile magnetic storage medium (commonly referred to as a "hard disk drive"), a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and / or an optical disk drive for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. It should be understood that other hardware and / or software components could be used in connection with computer system 102.Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems, etc.

[0037] Computer system 102 may operate with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system 102 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, portable or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments that include any of the foregoing systems or devices, and the like.

[0038] Further details regarding an example of the processor 104 are provided with reference to Fig. 1B. The processor 104 includes a variety of functional components used to execute instructions. These functional components include, for example, an instruction fetch component 150 to fetch instructions to be executed; an instruction decode unit 152 to decode the fetched instructions and obtain operands of the decoded instructions; instruction execution components 154 to execute the decoded instructions; a main memory access component 156 to access main memory for instruction execution when necessary; and a write-back component 160 to provide the results of the executed instructions.One or more of these components may be used to execute one or more instructions and / or operations in connection with prediction instruction fetch and / or prediction instruction processing 166, in accordance with one or more aspects of the present invention.

[0039] In a single embodiment, processor 104 also includes one or more registers 168 to be used by one or more of the functional components. Processor 104 may include additional, fewer, and / or different components than the examples provided herein.

[0040] Further details regarding an execution pipeline of the processor 104 are described with reference to Fig. 1C. While various processing stages of the pipeline are depicted and described herein, it is understood that additional, fewer, and / or different stages may be used without departing from the spirit of aspects of the invention.

[0041] With reference to Fig. 1C, in a single embodiment, an instruction is fetched 170 from an instruction queue, and branch prediction 172 and / or decoding 174 of the instruction may be performed. The decoded instruction may be added to a group of instructions 176 to be processed together. The grouped instructions are provided to a mapper 178, which determines any dependencies, allocates resources, and dispatches the group of instructions / operations to the appropriate dispatch queues. There are one or more dispatch queues for the various types of execution units, including, as examples, branch, load / store, floating-point, fixed-point, vector, etc. During a dispatch stage 180, an instruction / operation is dispatched to the appropriate execution unit.Any registers are read 182 to retrieve their sources, and the instruction / operation is executed during an execution stage 184. As indicated, execution may be for a branch, load (LD), or store (ST) operation, a fixed-point (FX), a floating-point (FP), or a vector (VX) operation, as examples. Any results are written to the appropriate register(s) during a write-back stage 186. Afterward, the instruction completes 188. If an interrupt or flush occurs 190, processing may return to instruction fetch 170.

[0042] In one example, a register renaming unit 192 is further coupled to the decode unit, which may be used in saving / restoring registers.

[0043] Additional details relating to a processor are provided with reference to Fig. 1D. In one example, a processor such as processor 104 is a pipelined processor, which may include prediction hardware, registers, caches, decoders, an instruction scheduling unit, and instruction execution units, as examples. The prediction hardware includes, for example, a local branch history table (BHT) 105a, a global branch history table (BHT) 105b, and a global selector 105c. The prediction hardware is accessed by an instruction fetch address register (IFAR) 107, which has the address for the next instruction fetch.

[0044] The same address is also provided to an instruction cache 109, which can fetch a plurality of instructions, referred to as a "fetch group." The instruction cache 109 includes a directory 111.

[0045] The cache and prediction hardware are accessed at approximately the same time using the same address. If the prediction hardware has prediction information for an instruction in the fetch group, this prediction is passed to an instruction sequencing unit (ISU) 113, which in turn dispatches instructions to execution units for execution. The prediction can be used to update the IFAR 107 in conjunction with a branch target calculation 115 and branch target prediction hardware (such as a link register prediction stack 117a and a count register stack 117b). If no prediction information is present, but one or more instruction decoders 119 find a branch instruction in the fetch group, a prediction is created for that fetch group.Predicted branches are stored in the prediction hardware, such as a branch information queue (BIQ) 125, and forwarded to the ISU 113.

[0046] A branch execution unit (BRU) 121 operates in response to instructions dispatched to it by the ISU 113. The BRU 121 has read access to a condition register (CR) file 123. The branch execution unit 121 also has access to information stored by the branch check logic in the branch information queue 125 to determine the success of a branch prediction and is operatively connected to the instruction fetch address register(s) (IFAR) 107 corresponding to the one or more threads supported by the microprocessor. According to at least one embodiment, BIQ entries belong to and are identified by an identifier, e.g., a branch tag (BTAG). When a branch belonging to a BIQ entry is completed, it is marked as such.BIQ entries are maintained in a queue, and the oldest queue entries are sequentially released when they are identified as containing information related to a completed branch. The BRU 121 is further operatively connected to initiate a predictor update when the BRU 121 detects a branch misprediction.

[0047] When the instruction executes, the BRU 121 detects whether the prediction is incorrect. If so, the prediction must be updated. For this purpose, the processor also includes predictor update logic 127. The predictor update logic 127 responds to an update indication from the branch execution unit 121 and is configured to update array entries in one or more of the local BHT 105a, the global BHT 105b, and the global selector 105c. The prediction hardware 105a, 105b, and 105c may have write ports that are different from the read ports used by the instruction fetch and prediction operations, or a single write / read port may be shared. The predictor update logic 127 may be further operatively connected to a connection stack 117a and a count register stack 117b.

[0048] Referring now to the condition register file (CRF) 123, the BRU 121 has read access to the CRF 123 and execution units can write to it, including, but not limited to, a fixed point unit (FXU) 141, a floating point unit (FPU) 143, and a vector multimedia extension unit (VMXU) 145. A condition register logic (CRL) execution unit 147 (also referred to as the CRU) and special purpose register (SPR) handler logic 149 have read and write access to the condition register file (CRF) 123. The CRU 147 performs logical operations on the condition registers stored in the CRF file 123. The FXU 141 is capable of performing write update operations on the CRF 123.

[0049] The processor 104 further includes a load / store unit 151 and various multiplexers 153 and buffer memories 155 as well as address translation tables 157 and other circuitry.

[0050] Processor 104 executes programs (also referred to as applications) that use hardware registers to store information. Programs that call routines, such as functions, subroutines, or other types of routines, are responsible for saving registers used by the caller (i.e., the programs calling the routines) and restoring those registers upon return from the callee (the called routine). Likewise, the callee is responsible for saving / restoring registers it uses, as shown in the code examples provided below.

[0051] Furthermore, many data processing systems use base registers to address data and / or code. For example, the System / 360 (System z) offered by International Business Machines Corporation uses a branch and link register (BALR) instruction and a USING instruction to create an index for addressing data and code. As another example, Power Systems uses a branch and link (BL) instruction with an offset (e.g., BL+4) to create a program counter (PC) address in a register for use in addressing data in position independent code (PIC). Other systems also use base registers to address data and code.

[0052] As indicated, various sequences have been used to achieve addressability. For example, sequences have been used where the program counter (PC) value is loaded into the callee's function, or where the call address of the provided function is used. This offers the possibility of providing a known value represented by the current instruction address, but potentially uses a complex sequence. Conversely, using the specified function entry address results in a simpler sequence but depends on a potentially long dependency chain to determine the entry point address. The following examples describe sequences used so far to achieve addressability.

[0053] An example of code for System / 360 (System z) is shown below: The following System / 360 assembly code shows the structure of subroutine calls commonly used to call a subroutine in mainframe systems based on the System / 360 architecture:

[0054] The following System / 360 (System z) assembly code shows the structure of called subroutine calls in mainframe systems based on the System / 360 architecture:

[0055] Furthermore, an example of code for a system based on the Power Architecture is shown below. The following Power Architecture assembly code shows the structure of subroutine calls commonly used to call a subroutine in Power systems based on the Power Architecture:

[0056] The following Power Architecture assembly code shows the structure of called subroutine calls in Power systems based on the Power Architecture:

[0057] Loading the program counter as a base, as in the previous examples, involves additional overhead. For example, the System / 360 code contains an extra instruction balr r12, 0, and on Power Systems, there is an extra set of instructions, including mflr / bl.+4 / mflr / mtlr. Thus, in a single code implementation, the function entry point is also used as a base, as shown below.

[0058] An example of System / 360 code that includes the function entry point as a base is as follows:

[0059] An example of code based on the Power Architecture is as follows:

[0060] While in the above implementation, the target address may be available for branch execution to enter the subroutine, during speculative execution after a branch prediction, the address may not be available until the target address becomes available for validation of the prediction. For example, at the time of prediction, the address may not be available in a register or other selected memory location (different from the program counter) accessible by other instructions or operations. According to one aspect of the present invention, based on a branch predictor predicting a register-indirect branch address, the predicted value is thus also provided as a speculative value, for example, in an architected register. If the prediction is correct, execution then proceeds faster.If the prediction is incorrect, recovery is performed as it would have been based on the incorrect prediction.

[0061] Further details regarding a register-indirect branch prediction technique are given with reference to Fig. 2. In one example, a processor performs this processing. First, the target address for a register-indirect branch is predicted, STEP 200, and the instruction fetch is redirected to the predicted target address (also referred to herein as a predicted address), STEP 202. Further, in one example, a new rename register is allocated for the logical register containing the target address, STEP 204. That is, in a single embodiment, register renaming is used for recovery. In register renaming, a new rename register is allocated upon a branch, and the new rename register is loaded with the predicted value. The prediction is checked, and if the prediction is false, recovery is performed by returning to the previously named register.

[0062] As indicated, the predicted address is copied into the associated rename register, STEP 206. The rename register containing the destination address is marked available, STEP 208. Further, a prediction check is performed to determine whether the prediction is correct, STEP 210. There are several ways to cause a prediction check to occur, including starting a state machine that performs the check when the destination register value provided to the branch instruction becomes available; inserting an internal operation (iop) to check; or causing a branch operation to be dispatched to a check pipeline, etc.

[0063] In case of misprediction, a recovery is performed. There are several recovery execution options that can be used, including copying the correct value from the old register to the new register; or using a rename execution, where the newly mapped rename register is discarded and the rename map points to a previous physical register containing the correctly loaded value. Further details regarding example recovery executions performed by a processor, for example, are described with reference to the Fig. 3 to 4 described.

[0064] First, with reference to Fig. 3, in a single embodiment, a branch prediction check is performed, STEP 300. This involves using the predicted address and comparing that address to a current address computed as input to the branch instruction when it becomes available. If the prediction is correct, QUERY 301, the prediction check is complete, STEP 302, and recovery is not required.

[0065] However, if the prediction is incorrect, QUERY 301, instructions past the mispredicted branch are discarded, STEP 304. Further, the instruction fetch is redirected to the computed address, STEP 306. Further, the correct non-speculative value is written to the register containing the destination address, STEP 308. There can be several ways to accomplish this, including, in a no-rename design, writing to an active register; further, in a rename design, writing to an existing rename register; or allocating a new rename register. The register containing the destination address is marked available, STEP 310. This concludes an example of prediction checking.

[0066] In a further embodiment, with reference to Fig. 4, a prediction-checking technique for a register-indirect branch is provided that explicitly uses register renaming. In this example, a check is performed on the correctness of a branch prediction, STEP 400. If the prediction is correct, QUERY 401, the check is complete, STEP 402, and recovery is not performed. However, if the prediction is incorrect, QUERY 401, the instructions after the mispredicted branch are flushed, STEP 404, and the rename register allocated during the prediction is deallocated, revealing the previous rename register with the non-speculative target address, STEP 406. The instruction fetch is then redirected to the computed address, STEP 408. This concludes an example of prediction checking.

[0067] Advantageously, the technology of Fig. 4 of branch processing, as currently performed in many out-of-order processors, in which registers allocated after a branch instruction are automatically deallocated, provided that the register allocated in connection with the processing of the branch instruction is treated as a register allocated after the execution of the branch instruction. In an embodiment in which the target register allocated in connection with the branch instruction is not treated as allocated after the branch instruction and is not deallocated, an execution according to Fig. 3 be adjusted so that the rename register allocated to hold the speculative value is updated with a correct, non-speculative value.

[0068] In another embodiment, non-renaming annotations may be used, where, for example, two copies of the base are provided. Then, upon a prediction, a switch is made to the second, or new, copy. The prediction copies the predicted value to the new copy, and future instructions use the newly activated copy. The prediction is checked, and if a misprediction occurs, the old copy is used. In such an implementation, misprediction recovery is performed by updating the active copy of the destination register, i.e., pointing to the old (unpredictable) copy and activating the second copy as the next new base value on the next prediction. Other implementations are also possible.

[0069] As described herein, based on the prediction of contents (e.g., a value; a target address) of a register to be used for a register-indirect branch, the predicted contents used for the prediction are also stored (e.g., simultaneously) in the register to be used for the register-indirect branch so that it can be used by other instructions. This simplifies processing.

[0070] In another aspect, the predicted value written to the destination address register (and, for example, the program counter) is also written to an associated register. For example, if the predicted value is to be written to a counter register, CTR, which is the destination address register, it is also written to another selected register, such as R12, R15, or another register associated with the CTR register.

[0071] For specific processing, such as with frequently used ABIs, a branch address must first be loaded into a general-purpose register (GPR) and then transferred to a special-purpose control register (SPR) before a register-indirect branch is performed. According to one such example of a branching architecture, the Power ISA branches to a special-purpose counter (CTR) register. However, the special-purpose register (e.g., the counter register, CTR) is not loaded directly, but rather via a general-purpose register.

[0072] Because reading the counter register can be expensive, an example ABI further specifies that the value of the CTR should be stored in a selected register, e.g., R12, R15, or another register, when a branch to a subroutine (BCTR) is made. This allows the selected register to be used as a base register by the called function. However, when a branch prediction is made, the branch address may be predicted before the value of the selected register has been loaded, causing the called subroutine to block in response to a data access.

[0073] Previously, to provide the value in the selected register, such as R12 in this example, a shift operation was performed from CTR (MFCTR) to R12, which reads the CTR register and writes the result to R12. However, according to one definition of an ABI, such as the Power ELF v2 ABI, if a value is provided in CTR, that value is also made available in R12. Thus, the shift operation from CTR to R12 is not required because software already indicates that whatever is in the CTR register should also be written to R12, eliminating the copy. However, according to one aspect of the present invention, when a register is predicted, the predicted value for that register is provided in that register. Thus, if the predicted register is CTR, CTR is updated simultaneously.However, the application wants to read R12, which hasn't been updated, and since there's no copy, there's no software path to fetch the predicted value located in the CTR into R12. R12 is a dedicated register; it has a connection, but it's not a copy that's necessarily visible in the code. Therefore, according to one aspect of the present invention, the same value predicted for CTR and written to the CTR is also written to R12 (or another selected register or memory location).

[0074] Thus, according to one aspect of the present invention, an associated register is predicted in conjunction with a branch prediction of one or more types of subroutine branches. This is described in more detail below.

[0075] An example of a prediction technique for a register-indirect branch that also predicts an associated register is described with reference to Fig. 5. In one example, a processor performs this processing. First, the target address for a register-indirect branch is predicted, STEP 500, and the instruction fetch is redirected to the predicted target address, STEP 502. Further, in one example, a new rename register is allocated for the logical register containing the target address, STEP 504, and the predicted address is copied into the allocated rename register, STEP 506. The rename register containing the target address is marked available, STEP 508.

[0076] Further, according to one aspect of the present invention, a new rename register is also allocated for the associated register, STEP 510. The predicted address is copied into the rename register allocated for the associated register, STEP 512, and the rename register for the associated register is marked as available, STEP 514.

[0077] A prediction check is performed to determine whether the branch prediction is correct, STEP 516, an example of which is described herein. A prediction check is also performed for the associated register, STEP 518. This check includes, for example, comparing a value of the architected value before processing the existing instruction, and in response predicting the associated register to the value predicted by that existing instruction. The check may be initiated by starting a state machine, inserting an IOP for the check, or causing a branch operation to be dispatched to a check pipeline with a hint to check the associated value. Many variations are possible.

[0078] Further details related to branch prediction checking are described with reference to Fig. 6 and further details of a prediction test to check the prediction of the associated register are described with reference to Fig. 7. These examples use register renaming. However, other implementations are possible without using register renaming. In one example, a processor performs this processing.

[0079] First, with reference to Fig. 6, in one example, a check is performed to determine the correctness of the branch prediction, STEP 600. If the branch prediction is correct, QUERY 601, the check is completed, STEP 602, and recovery is not performed. However, if the branch prediction is incorrect, QUERY 601, recovery is performed. For example, the instructions after the incorrectly predicted branch are deleted, STEP 604. This may include checking the associated register. Furthermore, the rename registers allocated during the prediction (e.g., the target address register and an associated register) are deallocated, revealing the previous rename registers with the non-speculative target address and the original value in the associated register, STEP 606. The instruction fetch is then redirected to the computed address, STEP 608.This completes a single execution of the branch prediction check.

[0080] In one example, the prediction of the associated register may be checked separately from the branch prediction check. Consequently, further details regarding the check, by, for example, a processor, of the prediction of the associated register are described with reference to Fig. 7. In one example, the correctness of the associated register prediction is checked, STEP 700. If the associated register prediction is correct, QUERY 701, the check is completed, STEP 702, and no recovery is performed. However, if the associated register prediction is incorrect, QUERY 701, recovery is performed. For example, the instructions after the mispredicted associated register (or the first user of the mispredicted associated register) are flushed, STEP 704, and the rename register allocated for the associated register during the prediction is freed, revealing the previous rename register containing the unpredicted, correct associated value, STEP 706. Execution then restarts at the flush point, STEP 708. This concludes one example of checking the associated register prediction.

[0081] In one aspect of checking a prediction, the check compares the predicted value of the associated register with the most recent value of the associated register calculated before the instruction that triggers the prediction of the associated register. In at least one embodiment, this value is stored in a rename register.

[0082] In another embodiment, recovery from a misprediction is performed by copying a value of the associated register into the rename register, which is allocated to hold the predicted value of the associated register, prior to the instruction that triggers the prediction of the associated register. In at least one embodiment, restore by restoring a value is used when freeing a rename register is more expensive than copying the correct value into the allocated rename register.

[0083] As described herein, based on the prediction of contents (e.g., a value; a target address) of a register to be used for a register-indirect branch, the predicted contents used for the prediction are also stored (e.g., simultaneously) in the register to be used for the register-indirect branch (in addition to the program counter) and in an associated register so that the value can be used by other instructions. This simplifies processing.

[0084] In another aspect, a control is provided to indicate whether an associated register should be used in the prediction. If it is indicated that the associated register should be used, the control may further include an indication of the associated register to be used (e.g., a register number). This control is, for example, code-specific and may be enabled / disabled for each unit of code, such as an application, a process, a module, a function, or a dynamically shared object (e.g., a library), as examples.

[0085] In one aspect, one or more associated register prediction controls are provided, where a first set of code units benefits from predicting associated register values ​​and a second set of code units does not. Many variations are possible.

[0086] As one example, control is provided in a machine state register (MSR). The operating system sets MSR control for one code unit and disables MSR control for another code unit. In another embodiment, page table entry (PTE) control may be provided. For example, a bit in the PTE controls the prediction or non-prediction of an associated register for branches on the page on which the branch resides, where the page corresponds to a page whose address is translated by the PTE. In another embodiment, a bit in the PTE controls the prediction or non-prediction of an associated register for branches based on the setting of the page of the branch target address bit, where the address of the branch target is translated by the PTE.In still other embodiments, hybrid forms are supported, where, for example, the MSR bit allows consideration of a bit set in the PTE. Many other examples are possible.

[0087] In one example of PTE control, a bit in the PTE is set by the dynamic loader based on an indication of a module or page level of a program module, which describes, for example, the characteristics of the module, such as the ABI level used for a particular code segment.

[0088] In at least one embodiment, a static linker links modules to group functions into common pages when they share a common ABI level, and separates them into separate pages when they do not share a common ABI level.

[0089] In another embodiment, a module uses the ABI level pro rata, meaning that the code in a single module conforms to the same ABI level, and the level and implicit setting for this control are provided, for example, by a module header such as the ELF (Executable Linkable Format) signature. Many examples and variations are possible. The example controls described herein are merely examples.

[0090] The use of a controller to indicate whether to use an associated register prediction for a code unit is referred to herein as an externally indicated affiliated register prediction (EIARP). A single embodiment for using an externally indicated affiliated register prediction for a code unit is described with reference to Fig. 8. In one example, this processing is performed by an operating system executing on a processor of a computing environment.

[0091] With reference to Fig. 8, the operating system first loads a unit of code, such as an application, process, module, function, or dynamically shared object, etc., STEP 800. It is determined whether the unit of code (referred to herein as loaded code or as code) is eligible for a code-specific prediction of an externally specified associated register, STEP 802. This may be determined, for example, by examining the ABI version or an EIARP indicator of the code, provided in a header or a signature of the code, as examples.

[0092] If the code is not a candidate for a prediction of an externally specified associated register, INQUIRY 804, processing is complete, STEP 810. Otherwise, an indication of the associated register (e.g., a register number) is loaded into a control register, STEP 806. Example control registers include a machine state register (MSR), a program status word (PSW), a special purpose register (SPR), a page-based page table entry (PTE), or a segment table entry (STE), as just a few examples.

[0093] Further, a control (e.g., a flag or other indicator) may be set that enables an EIARP for the loaded code, STEP 808. In one example, the flag or other indicator is set in a control register or other control field, such as an MSR, PSW, SPR, PTE, or STE, as examples. This reduces the risk of excessive mispredictions and recovery delays.

[0094] In another embodiment, a control is set to indicate that a code unit is not subject to EIARP if INQUIRY 804 determines that the code is not eligible for prediction of an associated register based on code characteristics (e.g., ABI level).

[0095] In further embodiments, the code is loaded by a program loader, a dynamic program loader, a shared library loader, a dynamic library loader, or another system component configured to load code.

[0096] In a single embodiment, upon a context switch of the operating system, the configuration including the code-specific EIARP is updated (e.g., by the operating system). Updating the code-specific EIARP due to a context switch is performed, for example, when control is in a register that is not explicitly bound to the code unit, such as in an MSR, SPR, or PSW. Because the PTE is bound to the code, the EIARP configuration does not need to be updated in one example. A single embodiment of context-switch logic in conjunction with the code-specific EIARP is described with reference to Fig. 9.

[0097] With reference to Fig. 9, based on a context switch, a value is obtained from the control register of the context being switched from, STEP 900, and stored in a context switch structure, STEP 902. Other processing may be performed, STEP 904. Further, a new value of the context being switched to is obtained, STEP 906, and stored in a control register of the context being switched to, STEP 908.

[0098] In further embodiments, the value for the tax register is stored in the context structure of a requester when the value is initially set, e.g., in connection with processing the technique of Fig. 8, and STEPS 900 and 902 are omitted during the context switch operation to preserve the code settings. Other variations are also possible.

[0099] During processing, a program may use a hardware exception (e.g., page fault, floating-point exception, etc.) and transition to the operating system via interrupt processing. In a single embodiment, the configuration settings may be disabled upon transition to the operating system (e.g., by the operating system), as described with reference to Fig. 10.

[0100] In one example, the value of the control register of the context being switched from is obtained, STEP 1000, and stored in an exception context, STEP 1002. Example exception contexts include, for example, small capacity memory for System z or selected registers for Power Systems, such as SRR0 / SRR1... or HSRR0 / HSRR1... as examples. The exception context may include the code-specific EIARP and / or other configuration information. Other processing may be performed, STEP 1004. Further, optionally, a supervisor initialization value may be stored in a control register, such as an MSR, SPR, etc., STEP 1006. Additional and / or other processing may also be performed.

[0101] After handling the exception, the hardware exception / interrupt processing is terminated. An example of this processing performed, e.g., by a processor, is described with reference to Fig. 11. In one example, the code-specific EIARP and / or other configuration information to be recovered is obtained from the exception context, STEP 1100, and stored in a selected control register (e.g., MSR, SPR, PSW, etc.), STEP 1102.

[0102] Further details of using a code-specific EIARP with branch prediction are described with reference to Fig. 12. In one example, a processor performs this processing. In a single embodiment, the target address for a register-indirect branch is predicted, STEP 1200, and the instruction fetch is redirected to the predicted target address, STEP 1202. Further, in one example, a new rename register is allocated for the logical register containing the target address, STEP 1204. The predicted address is copied into the allocated rename register, STEP 1206, and the rename register containing the target address is marked available, STEP 1208.

[0103] Further, in accordance with one aspect of the present invention, it is determined whether EIARP is enabled for the code, QUERY 1210. This is determined, for example, by checking a control indicating whether an associated register should be predicted for the code. If EIARP is not enabled for the code, processing continues by causing a branch prediction check to take place, STEP 1220. Otherwise, a new rename register is also allocated for the associated register, STEP 1212. The register number of the associated register is determined, for example, using EIARP configuration information. Further, the predicted address is copied into the rename register allocated for the associated register, STEP 1214, and the rename register for the associated register is marked available, STEP 1216.

[0104] A check of the prediction of the associated register is performed to determine whether the prediction of the associated register is correct, STEP 1218. This includes, for example, comparing a value of the architected value before the existing instruction is processed, and in response predicting the associated register with the value predicted by that existing instruction.

[0105] Further, a branch prediction check is performed, STEP 1220. Examples of logic for checking the correctness of a prediction are described herein. Examples are also described below with reference to Fig. 14 to 15. Other examples are also possible.

[0106] In yet another aspect, a prediction is made as to whether a corresponding register can be predicted. This prediction is based, for example, on a dynamic prediction determination of the membership status for a candidate corresponding register (e.g., branch instruction). In one example, a processor dynamically determines the extent of a corresponding register for each candidate branch subroutine instruction that may have a corresponding register. The branch instructions, the particular candidate corresponding registers, and the activation of the dynamic membership determination may be controlled by a plurality of control registers, including an MSR bit, a PTE bit, other control registers, or a combination thereof. This may further include a control register indicating a candidate membership or a bit mask determining multiple candidate memberships.

[0107] According to one or more aspects, a candidate is predicted to be associated, and a prediction is made based on a predictor. A check of the prediction is performed in the processor. If the prediction was incorrect because the associated register is not associated, a dynamic predictor is updated to suppress a future associated prediction.

[0108] There are a variety of techniques that can be used to discover new dynamic membership relationships. One such technique, for example, involves randomly assuming membership whenever a predictor indicates non-membership (at a sufficiently low rate) to detect either genuinely changed behavior or changed behavior due to aliasing, where a different branch becomes dominant. Another technique, for example, involves training periods during which the operating system determines to force the prediction of new memberships, either at a fixed interval or in response to provided changes, such as those detected using a variety of dynamic runtime monitoring and fingerprinting techniques. Other techniques are also possible.

[0109] In one aspect, a prediction is made as to whether a defined register (either statically defined or defined in an EIARP configuration, as examples) is associated with a particular instance (e.g., a particular branch). In this aspect, a code unit (e.g., a branch instruction) is loaded, and a number of a defined register (e.g., R12) is hard-wired in hardware or loaded into a configuration or control register (e.g., MSR, PSW, SPR, PTE, STE, etc.). Optionally, a flag is also set to enable prediction for the code unit.

[0110] If the register number is loaded into a configuration or control register and not hard-wired, processing is performed based on a context switch, since each code unit may have different configuration information. An example of this processing is described with reference to Fig. 9.

[0111] Likewise, if a hardware exception is used and the register number is not hard-wired, exception processing may be performed as described in a single embodiment with reference to the Fig. 10 and Fig. 11 is described.

[0112] An example of a prediction technique for a register-indirect branch, which also predicts whether a defined register is associated, is presented with reference to Fig. 13. In one example, a processor performs this processing. In one example, the target address for a register-indirect branch is first predicted, STEP 1300, and the instruction fetch is redirected to the predicted target address, STEP 1302. Further, in one example, a new rename register is allocated for the logical register containing the target address, STEP 1304. The predicted address is copied into the allocated rename register, STEP 1306, and the rename register containing the target address is marked available, STEP 1308.

[0113] It is further determined whether the associated value can be predicted, QUERY 1310. For example, can the associated register be predicted? If not, processing continues by causing a branch prediction check to take place, STEP 1320. Otherwise, in one embodiment, a new rename register is allocated for the associated register being predicted, STEP 1312. The register number of the associated register may be hard-wired or determined using EIARP configuration information, as examples.

[0114] The predicted address is copied into the associated rename register for the corresponding register, STEP 1314, and the rename register for the corresponding register is marked available, STEP 1316.

[0115] A prediction check of the associated register is performed to determine if the prediction is correct, STEP 1318, as well as a branch prediction check, STEP 1320, as described herein. In case of a misprediction, recovery is performed as described with reference to the Fig. 14 to 15. In one example, a processor performs this processing.

[0116] In one or more embodiments, QUERY 1310 may be subject to a control override to detect new associated registers. In a single embodiment, QUERY 1310 is forced to specify an associated register during a training phase. A training phase may, for example, correspond to a fixed or configurable number of cycles after an application is loaded. In another example, a training phase may, for example, correspond to a fixed or configurable number of cycles after an indication to start a training phase. In one example, a training start indication may correspond to a randomly generated signal with a fixed or configurable probability. In another example, a training start indication may correspond to the elapse of a specified interval since the last training phase, e.g.,a fixed or configurable number of cycles, or a fixed or configurable number of nanoseconds, microseconds, or other time unit. In another embodiment, QUERY 1310 indicates the presence of an associated register for a first number of executions of a branch; where the first number is fixed or configurable. Still other embodiments may utilize other known or future techniques to train an associated register predictor.

[0117] With reference to Fig. 14 In the case of a branch misprediction in this example, by definition, the prediction of the associated value or the prediction with respect to the associated value is also mispredicted. The check includes, for example, determining the correctness of the branch prediction, STEP 1400. If the branch prediction is correct, INQUIRY 1401, the check is complete, STEP 1402, and recovery is not performed. However, if the branch prediction is incorrect, INQUIRY 1401, recovery is performed. For example, the instructions after the mispredicted branch are deleted, STEP 1404. This may include clearing the check of the associated register. Furthermore, the rename registers allocated during the prediction are freed, making the previous rename registers visible, STEP 1406.This may include freeing the destination address register and the associated register if EIARP is enabled, revealing the previous rename registers with the non-speculative destination address and the original value in the associated register. The instruction fetch is then redirected to the calculated address, STEP 1408. This completes a single execution of the prediction check.

[0118] Furthermore, in a single embodiment, when EIARP is enabled, a prediction correctness check of the associated register may be invoked, as described with reference to Fig. 15. In a single embodiment, a check is performed on the correctness of the prediction of an associated register, STEP 1500. If the prediction of the associated register is correct, QUERY 1501, the check is completed, STEP 1502, and recovery is not performed. However, if the prediction of the associated register is incorrect, QUERY 1501, recovery is performed. For example, the instructions after the mispredicted associated register are flushed, STEP 1504. In another example, the first user of the mispredicted associated register is flushed in STEP 1504. Further, the rename register allocated for the associated register during a prediction is deallocated, revealing the previous rename register containing the unpredicted correct associated value, STEP 1506. Execution then restarts at the flush point, STEP 1508.This concludes an example of testing the prediction of the associated register.

[0119] In yet another embodiment, when a predictor is used to predict whether an associated value (e.g., an associated register) can be predicted, an update of the predictor associated with this prediction may also be performed, as described with reference to Fig. 16. In one example, a processor performs this processing.

[0120] With reference to Fig. 16, in a single embodiment, a check is performed on the correctness of the prediction of a related register, STEP 1600. If the prediction of whether the related register can be predicted is correct, QUERY 1601, the membership predictor may be updated to indicate a correct prediction, STEP 1602, and recovery is not performed. In another example, no update needs to be performed.

[0121] However, if the prediction of whether the associated register can be predicted is incorrect, QUERY 1601, recovery is performed. For example, the instructions after the mispredicted associated register are deleted, STEP 1604. In another embodiment, the first user of a mispredicted associated register is deleted in STEP 1604. Further, the rename register allocated for the associated register during a prediction is deallocated, revealing the previous rename register containing the unpredicted correct associated value, STEP 1606. Further, in one example, the membership predictor is updated to indicate an incorrect prediction, STEP 1608. Execution is then restarted at the deletion point, STEP 1610. This completes a single execution of the prediction check.

[0122] In an alternative embodiment, the value stored in the mispredicted associated register is copied to the rename register instead of releasing the rename register. Further variations are possible.

[0123] In another aspect, a prediction is made as to whether a register is associated with a particular instance, and a further prediction is made regarding the register number and a further identifier. An example of this processing is described with reference to Fig. 17. In one example, a processor performs this processing.

[0124] With reference to Fig. 17, the target address for a register-indirect branch is first predicted, STEP 1700, and the instruction fetch is redirected to the predicted target address, STEP 1702. Further, in one example, a new rename register is allocated for the logical register containing the target address, STEP 1704. The predicted address is copied into the allocated rename register, STEP 1706, and the rename register containing the target address is marked available, STEP 1708.

[0125] Further, according to one aspect, it is determined whether the associated value can be predicted, INQUIRY 1710. If not, processing continues by causing a branch prediction check to take place, STEP 1726. Otherwise, it is determined whether a new register identifier (e.g., a number) should be selected as the predicted associated register, INQUIRY 1712. If not, an indication of a predicted associated register, e.g., made by a predictor, is selected as the associated register, STEP 1714; otherwise, a different register (e.g., a different register number) is selected, STEP 1716. A new rename register is then allocated for the selected associated register (e.g., having the selected register number), STEP 1718.

[0126] The predicted address is copied into the associated rename register for the associated register, STEP 1720, and the rename register for the associated register is marked available, STEP 1722.

[0127] A prediction check of the associated register is performed to determine whether the prediction associated with the associated register is correct, STEP 1724, as well as a branch prediction check, STEP 1726, as described herein.

[0128] In at least one embodiment, QUERY 1712 corresponds to a test of whether a prediction confidence exceeds a threshold. For example, the prediction confidence may correspond to a known confidence value of 1 or more bits. The threshold may be fixed or software-configured.

[0129] A prediction check can also be performed to determine whether the selected associated register is correct, as described with reference to Fig. 18. In one example, a processor performs this processing. In a single embodiment, a check is performed on the correctness of the prediction of a corresponding register, STEP 1800. If the prediction of the selected corresponding register is correct, QUERY 1801, the membership predictor may be updated to indicate a correct prediction of the register used as the corresponding register, STEP 1802, and no recovery is performed. In another embodiment, the predictor is not updated.

[0130] However, if the prediction of the selected associated register is incorrect, INQUIRY 1801, recovery is performed. For example, the instructions following the mispredicted associated register are deleted, STEP 1804. In another embodiment, the first user of the mispredicted associated register is deleted in STEP 1804. Further, the rename register allocated for the associated register during a prediction is deallocated, revealing the previous rename register containing the unpredicted correct associated value, STEP 1806. Further, in one example, the membership predictor is updated to indicate a misprediction of the particular register to be used as the associated register, STEP 1808. Execution is then restarted at the deletion point, STEP 1810.This completes an execution of the prediction check of the associated register.

[0131] According to another aspect, related registers are identified by identifying a sequence of instructions. In one example, the sequence includes a first instruction configured to create a related relationship and a second instruction configured to perform a subroutine branch. In one example, the sequence includes:

[0132] This sequence is recognized as a sequence that performs both the membership-creating move operation and the subroutine call. In a single embodiment, the membership-creating sequence is converted into a fusion sequence of operations that performs the move operation and creates a branch with a membership prediction.

[0133] Based on the recognition of the above sequence (or a similar sequence), a fusion sequence of operations is generated that performs the shift operation and takes the branch. As examples, a simplified sequence can be generated, e.g., hard-wired with R12 or with EIARP; or an extended fusion sequence can be generated that includes a check of the predicted branch address, thus avoiding the cost of the MTCTR instruction altogether. An example of an extended sequence is described with reference to Fig. 19. In a single embodiment, this processing is performed by a decoder.

[0134] First, it determines whether a fusion sequence possibility has been detected, QUERY 1900. Did the decoder detect, for example, MTCTR followed by BCTRL? If no fusion sequence possibility was detected, fusion generation processing is complete. Otherwise, fusion generation processing continues. A branch target address is predicted, STEP 1902. The target address is loaded into a program counter (PC) so that processing can begin execution at the target address, STEP 1904. Furthermore, the predicted target address is loaded into both the CTR register, STEP 1906, and an associated register (e.g., R12), STEP 1908. Since this is a subroutine call, a return address is loaded into a link register (LR), STEP 1910. Furthermore, a check of the predicted target address is performed, STEP 1912.In one example, this check is performed with respect to the source of MTCTR, which is the value of R12.

[0135] In one example, the number (e.g., R12) of the associated register is hard-wired as the associated register. In another example, the associated register is specified in a controller, such as a selected control register. In yet another example, it is determined dynamically based on the sequence of instructions (e.g., the register number specified after MTCTR). Other examples are also possible. In the above sequence, MTCTR does not need to be executed because the prediction overwrites the value, and the associated register and the predicted destination address are checked simultaneously in one example. Other variations are possible.

[0136] In a single exemplary embodiment, the operations of the technique of Fig. 19 can be expressed by generating an example iop sequence, such as: mtctr R12 old ctr=ctr update_Ir from_instruction_address+ predict_indirect_ctr+ update_pc_from_prediction+ update_ctr_from_prediction+ update_affiliated_reg_from_prediction (R12) check_target_address (old_ctr)

[0137] In another embodiment, the copy of R12 is suppressed and a simplified iop sequence is generated: old_affiliated=R12+ update_Ir from_instruction_address+ predict_indirect_ctr+ update_pc_from_prediction+ update_ctr_from_prediction+ update_affiliated_reg_from_prediction (R12) check_target_address (old_affiliated)

[0138] In a variety of embodiments, the prediction iop generates a single prediction that can be used to update the program counter (i.e., PC—the address from which instructions are fetched), the branch target register (ctr in this example), and an associated register (R12 in this example). In this particular embodiment, the prediction iop is also configured to capture the PC before updating with the prediction in order to capture a subroutine return address, e.g., in the link register (LR). In another embodiment, capturing the PC in the link register (LR) can be performed by a separate iop.

[0139] In these examples, the + symbol is used to indicate the performance of multiple operations within a single iop, with the descriptive components connected by the + sign. For example, update_pc_from_prediction updates the program counter (PC) with the address predicted by the predictor.

[0140] In a single embodiment with an externally specified associated register, the detection of a fusion sequence is based on the detection of a sequence that includes a register specified in a configuration register. Before detecting a fusion-based associated sequence, an associated register is specified using a control register for an external indication of the associated register sequence to be detected. An example of this processing being performed, e.g., by a processor, is described with reference to Fig. 20. In another embodiment, the sequence that defines the relationship of the associated register and contains the number of the associated register is fixed (or “hard-wired”) in the processor logic, and the technique of Fig. 20 is not carried out in such an embodiment.

[0141] With reference to Fig. 20, the code (such as code containing one or more fused sequences that specify a relationship of an associated register) is first loaded, STEP 2000. Further, a register number corresponding to a register that may occur in an association-generating sequence to be recognized is loaded, STEP 2010. Further, optionally, a flag is set to enable EIARP, STEP 2020. Since only sequences that are recognized as sequences specifying relationships of associated registers are implemented, there is no risk of excessive mispredictions and therefore a means to enable or disable the prediction of associated registers may not be present in one or more embodiments. In further embodiments, a flag to enable or disable the prediction of the value of an associated register may be provided as a security feature, e.g.in the event of incorrect execution of the logic for predicting the corresponding register. Other variants are also possible. Other variants are also possible.

[0142] If the register to be used as a related register is not hard-wired but instead is specified in a controller, the configuration information, including an indication of the related register, is stored for later retrieval based on a context switch. A single embodiment of this processing is described above with reference to Fig. 9. Similarly, when using a hardware exception, processing is carried out as described with reference to the Fig. 10 to 11. However, if the register number is hard-wired, this processing is optional.

[0143] A single embodiment of branch prediction with a fusion-based associated sequence is described with reference to Fig. 21. In one example, a processor performs this processing.

[0144] With reference to Fig. 21, a step that detects a merge possibility is performed, STEP 2100. For example, a check is made by the decoder for a sequence of MTCTR Rx / BCTRL, where Rx corresponds to a register for which a membership relationship with the branch target address can be detected. In an exemplary sequence, register Rx may correspond to register R12. Based on the performance of a detect step for a membership-creating sequence that can be merged, it is determined whether such a merge sequence possibility is detected, INQUIRY 2102. That is, is a sequence of MTCTR Rx and BCTRL present in the code stream and does Rx of MTCTR match an expected register number, such as a number of a hard-wired associated register, or one stored in a controller, e.g.the EIARP controller, provided number, as examples? If no merge sequence possibility is detected, conventional processing is performed, STEP 2104. Otherwise, processing continues by predicting the target address for a register-indirect branch, STEP 2106, and redirecting the instruction fetch to the predicted target address, STEP 2108. Further, in one example, a new rename register for the logical register containing the target address is allocated, STEP 2110. The predicted address is copied into the allocated rename register, STEP 2112, and the rename register containing the target address is marked available, STEP 2114.

[0145] Furthermore, a new rename register is allocated for the associated register (e.g., the Rx register specified in the merge sequence establishing an association), STEP 2116. The predicted address is copied into the rename register allocated for the associated register, STEP 2118, and the rename register for the associated register is marked available, STEP 2120.

[0146] A check of the prediction of the predicted address is performed to determine if the prediction is correct, STEP 2122. This includes, for example, comparing the target address with a value of the associated register (Rx) before the merge sequence (e.g., using its previous rename register). If the prediction is incorrect, recovery is performed as described herein. An example of such recovery is described with reference to Fig. 14.

[0147] In further embodiments, the number of the associated register is not hard-wired or provided by a controller (i.e., EIARP), but is determined by the sequence itself (e.g., a register number specified after MTCTR). In one such exemplary embodiment, INQUIRY 2102 checks whether a sequence of MTCTR, RX, and BCTRL is present in the code stream. If the sequence is present, the particular register RX specified in the sequence is used as the associated register. In one such embodiment, the code loading technique and the EIARP configuration technique, such as that of Fig. 8 or Fig. 20, is not required, and the prediction of an associated register may operate in conjunction with conventional code loading techniques. Furthermore, saving information of an associated register via a context switch and / or performing hardware exception processing is not required, and the prediction of an associated register may operate in conjunction with conventional context switch sequences and conventional hardware exception processing in at least one embodiment.

[0148] In the above example of a sequence of instructions, the MTCTR and BCTRL instructions are in sequence. However, according to another aspect, membership is predicted even if the instructions are not in sequence. For example, consider the following code:

[0149] The above code is recognized as code that performs both the move operation that creates an ownership and the subroutine call. Thus, based on the detection of an instruction that creates an ownership (e.g., MTCTR), an indicator is set. The indicator may further specify the number (or some other specification) of the associated register. If an operation is detected that clears the ownership (e.g., changes either the contents of the CTR or the register that was the source of MTCTR), the indicator is then reset. When a BCTRL is encountered, it is indicated as a branch with an associated register if an ownership specification is active, optionally further specifying the number of the register to which an ownership exists.

[0150] A single embodiment of processing related to the determination of an affiliation based on a dynamic control analysis at runtime is described with reference to Fig. 22. In one example, a processor performs this processing. The technique of Fig. 22 is performed on each instruction of the instruction stream sequence to determine the association of a register with a branch target register of a branch, branches for which an associated register is to be predicted, and the register number of the associated register. Detected association relationships are used by the execution of the technique of Fig. 22 for an instruction to execute this technique is passed on to the next instruction until an association is either canceled or a register-indirect branch is detected, in connection with which the prediction of the value of an associated register is to be performed. This processing is performed in one example by the instruction decoder.

[0151] With reference to Fig. 22, in a single embodiment, an instruction is received, STEP 2200, and decoded, STEP 2202. A determination is made as to whether the instruction is an affiliation-creating instruction, such as an MTCTR, INQUIRY 2204. If it is an affiliation-creating instruction, any previous affiliation is canceled and the new affiliation is recorded (e.g., an indicator is set), STEP 2206. However, if the instruction is not an affiliation-creating instruction, a further determination is made as to whether the instruction is an affiliation-deleting instruction (e.g., an instruction that overwrites either the source or destination of the affiliation relationship, e.g., either the source register of MTCTR that specified the affiliation or the count register, CTR), INQUIRY 2208.If it is a delete membership instruction, the membership is canceled (e.g., the indicator is reset), STEP 2210.

[0152] If the instruction is not a create-affiliation or delete-affiliation instruction, this processing continues with INQUIRY 2212, which checks whether the existing instruction is a register-indirect branch instruction and an affiliation is currently active. If INQUIRY 2212 is positive, a register-indirect branch instruction with an associated register was detected, and control transfers to STEP 2214. Otherwise, the technique ends for the existing instruction.

[0153] In STEP 2214, a register-indirect branch instruction was detected when a membership relationship between a register-indirect branch destination register (such as the counter register, ctr) and another register is active. To simplify the prediction of the value of the detected associated register, the presence of an associated register is indicated in conjunction with the branch instruction, and the register number of the associated register is recorded to simplify the prediction of the value of the associated register in conjunction with branch processing for the existing branch. The technique of Fig. 22 ends for the existing instruction.

[0154] If the technology of Fig. 22 for an instruction being processed for a processor (e.g., after STEPS 2206, 2210, 2212, or 2214, respectively), processing is performed on the next fetched instruction. The recorded membership information is obtained from an implementation of the technique of Fig. 22 passed on to the next execution for the next instruction in the instruction stream.

[0155] Based on the determination of the sequence of a membership-creating shift operation and a subsequent branch according to STEP 2214, although they may be separated by one or more other instructions, a fusion sequence is generated based on the membership-creating shift operation and the branch, as described above. As an example, the processing of Fig. 19 and the Fig. 20 to 21 in addition to the restoration as described with reference to Fig. 14. Other processing described with fusion and / or predictive branching may also be performed in one or more embodiments.

[0156] As described herein, in a single embodiment, to avoid the cost of performing a shift operation from a counter instruction, MFCTR (which moves the value from the CTR to a selected register (e.g., R12)) when the CTR value is predicted, an ABI may indicate the presence of the value of the CTR in a general register (e.g., register R12 according to the known ELFv2 ABI of the Power Architecture), and the predicted value is written by a processor to the CTR and the selected register (e.g., R12) when a sequence corresponding to the ABI function call sequence that uses an associated register (such as R12) to transfer the address of the called function to the called function is detected, in accordance with an aspect of the present invention.

[0157] This selected register is referred to herein as a corresponding register. In one example, the value of the selected register is used to determine another value, such as a pointer to a table of contents (TOC) or a global offset table (GOT), according to well-known ABI specifications, such as the Power Architecture's ELF v2 ABI. This other value is stored in another selected register, such as R2. The value of the other selected register, R2, is obtained, for example, by adding an offset to the value in the selected register (e.g., R12). The value of the other selected register (e.g., R2) is then used, for example, as a pointer to the TOC or GOT, which provides access to variables.Specifically, a compiler generates object code from source code without knowing the final address or offset of the code / data. Specifically, the compiler generates object code that accesses a variable address reference data structure (e.g., a global offset table or a table of contents (TOC)) for variable values ​​without knowing the final size of the data structure or the offsets / addresses of various data sections. Placeholders for this information remain in the object code and are updated by a linker.

[0158] Since the value of the associated register (e.g., R12) is predicted and the offset is known or determinable, the value of the other selected register is predicted as an associated derived value according to one aspect.

[0159] In one embodiment, the configuration and processing of the associated derived value is similar to the configuration and processing of the associated value. An indication of the associated derived value (e.g., the register number such as R2) may, for example, be hard-wired or stored in a control register or other control field such as an MSR, SPR, PSW, PTE, STE, etc. Furthermore, if the code is eligible for EIARP, the register number of the associated derived register may be loaded (e.g., STEP 806 of Fig. 8). As further examples, the value can be saved and restored upon a context switch, as in an example with reference to Fig. 9, and it can be included in a processing of exception conditions, as in an example with reference to the Fig. 10 to 11. It may also be incorporated into another associated register and / or register-indirect branch prediction processing described herein.

[0160] An example of a prediction technique for a register-indirect branch that also predicts an associated derived register is described with reference to Fig. 23. In one example, a processor performs this processing. First, processing associated with a register-indirect branch and a prediction of an associated value is performed, STEP 2300.This may include several operations, including, for example: predicting the target address for a register-indirect branch; redirecting the instruction fetch to the predicted target address; allocating a new rename register for the logical register containing the target address; copying the predicted address into the associated rename register; marking the rename register containing the target address as available; allocating a new rename register for the associated register; copying the predicted address into the rename register associated with the associated register; marking the rename register for the associated register as available; and performing one or more prediction checks, as in an example with reference to . Fig. 5.

[0161] In addition to the above processing, which performs one or more of the above operations, it is determined whether the predictor predicts an associated derived register, QUERY 2302. In one example, this is based on detecting a sequence of instructions that represents the use of a GOT. In another example, one or more controls in a control register may be used to predict whether to predict the value of a derived associated register. Other examples are also possible.

[0162] If the predictor does not predict a corresponding derived register, this processing is complete. In one example, when the code branches to a sequence that computes a derived value, dynamic idiom detection is performed during execution. A sequence that computes a derived value is detected, e.g., dynamically during code execution, and a predictor is updated to indicate this.

[0163] Otherwise, if the predictor actually predicts an associated derived value, in one example, an offset for the derived value is obtained, STEP 2304. This offset may be obtained using a variety of techniques, including using a lookup table, accessing the instruction stream, or using a predictor, as examples. Many techniques are possible. Further, a value for the associated derived register is calculated, for example, by adding the offset to a predicted value of the associated register obtained in STEP 2300, STEP 2306.

[0164] A new rename register is allocated for the associated derived register, STEP 2308. The calculated value is copied to the allocated rename register for the associated derived register, STEP 2310, and the rename register for the associated derived register is marked as available, STEP 2312.

[0165] A check of the prediction of the associated derived register may be performed to determine whether the prediction is correct, STEP 2314. Further details in connection with a prediction check, which includes checking the prediction of the associated derived register, are described with reference to Fig. 24. This may be performed in addition to the branch prediction check and / or the associated register prediction checks, as examples. In one example, a processor performs this processing.

[0166] With reference to Fig. 24, in one example, a check is performed on the correctness of the associated derived prediction, STEP 2400. If the prediction is correct, QUERY 2401, the check is completed, STEP 2402, and recovery is not performed. However, if the prediction is incorrect, QUERY 2401, recovery is performed. For example, the instructions are flushed after function entry, STEP 2404. Further, the rename registers allocated during the prediction are freed, including the rename register for the associated derived value, STEP 2406. Further, the instruction fetch is then redirected to re-execute the calculations of the associated derived register (e.g., R2) and subsequent instructions, STEP 2408. This completes a single execution of the prediction check.

[0167] In other embodiments, the indication of the associated derived register (e.g., the register number) may be predicted. Thus, processing is performed on the associated register as described herein to predict the indication, use the prediction, check for correctness, e.g., by comparing the predicted value of the associated derived register with the value calculated by the instruction sequence that unpredictably calculates the value in the instruction stream, and / or perform recovery therefrom. Many variations are possible.

[0168] In another aspect, the presence of an associated derived register and the particular register number of the register may be determined in response to detecting one or more sequences of instructions. For example, the decode logic detects the following code sequence:

[0169] In the above code, "addis" stands for "add immediate shift," e.g., according to the Power Architecture definition in an exemplary embodiment; "addi" stands for "add immediate," e.g., according to the Power Architecture definition in an exemplary embodiment; Rx is the associated register (e.g., R12); and Ry is the associated derived register (e.g., R2).

[0170] Based on the detection of the above sequence (or a similar sequence; various sequences are possible, and a hardware implementation may detect one or more of the possible sequences according to a variety of example embodiments), a fusion sequence is generated that performs the shift operation, the branch, and the calculation of the derived value. As examples, a simplified fusion sequence may be generated, e.g., where the associated register (e.g., R12) and the associated derived register (e.g., R2) are hard-wired or specified in a control register; or an extended fusion sequence may be generated that includes a check of the predicted branch address with respect to the original associated register, avoiding the MTCTR overhead altogether.In a single embodiment, this processing is performed by a decoder and includes, for example: predict target address PC <= predicted target address CTR <= predicted target address Rx <= predicted target address Ry <= predicted target address + offset return address check predicted target address against Rx.

[0171] In one example, the associated register number (e.g., R12) and / or the associated derived register number (e.g., R2) are hard-wired as the associated register and the associated derived register, respectively. In another example, the associated register number and / or the associated derived register number are specified in a control, such as in a selected control register. In yet another example, they are determined dynamically based on the sequence of instructions (e.g., the register number specified after MTCTR or the register number provided in addis or addi). Other examples are also possible.

[0172] Further details regarding a prediction technique for a register-indirect branch with a fusion-based associated derived sequence are given with reference to Fig. 25. In one example, a processor performs this processing. In a single embodiment, a step that detects a fusion possibility is performed, STEP 2500. For example, a check is performed by the decoder for a sequence of MTCTR Rx / BCTRL / ADDIS / ADDI. Based on the performance of the detect step, it is determined whether such a fusion sequence possibility is detected, QUERY 2502. That is, is a sequence of MTCTR, BCTRL, ADDIS, and ADDI present in the code stream, and does Rx of MTCTR match an expected register number, such as a hard-wired number of an associated register or a number provided in a controller, as examples? If no fusion sequence possibility is detected, conventional processing is performed, STEP 2504.Otherwise, in one example, processing continues with predicting the target address for a register-indirect branch, STEP 2506, and redirecting the instruction fetch to the predicted target address, STEP 2508. Further, in one example, a new rename register is allocated for the logical register containing the target address, STEP 2510. The predicted address is copied into the allocated rename register, STEP 2512, and the rename register containing the target address is marked available, STEP 2514.

[0173] Furthermore, a new rename register is also allocated for the associated register (e.g., Rx, such as R12), STEP 2516. The predicted address is copied into the rename register allocated for the associated register, STEP 2518, and the rename register for the associated register is marked as available, STEP 2520.

[0174] Furthermore, a new rename register is also allocated for the associated derived register (e.g., Ry, such as R2), STEP 2522. An offset is added to the predicted address, and the result is stored in the rename register allocated for the associated derived register, STEP 2524. The rename register for the associated derived register is marked available, STEP 2526.

[0175] A check of the prediction of the predicted address is performed to determine if the prediction is correct, STEP 2528. This includes, for example, comparing the target address with a value of the associated register (Rx) before the merge sequence (e.g., using its previous rename register). If the prediction is incorrect, in one example, recovery is performed as described herein. This concludes one embodiment of this processing.

[0176] In further embodiments, other predictive tests may also be performed as described herein.

[0177] One or more aspects of the present invention are inextricably linked to computer technology and simplify processing in a computer, improving its performance. Further details of a single embodiment for simplifying processing in a data processing environment as it relates to one or more aspects of the present invention are described with reference to Fig. 26A to 26B.

[0178] With reference to Fig. 26A, in a single embodiment, a predicted value to be used in a register-indirect branch is predicted (2600) using a processor of the computing environment. The predicted value is stored in a selected memory location (e.g., a hardware register) accessible by one or more instructions of the computing environment (2602). The storing is performed concurrently with the processing of a register-indirect branch (2604). Further, the selected memory location, in addition to another memory location (e.g., PC), is used to store an instruction address (2605). The predicted value is used in speculative processing that includes the register-indirect branch (2606).As an example, the predicted value includes a target address to be used by an instruction fetch (2608), and wherein using comprises redirecting the instruction fetch to the target address (2610).

[0179] In another aspect, it is determined whether the predicted value is accurate (2612). Based on the determination that the predicted value is inaccurate, recovery is performed (2614). Recovery may be performed in several ways. In one example, recovery includes, for example, deleting one or more instructions executed subsequent to using (2616) and replacing the predicted value with an unpredicted value (2618). As one example, replacing includes using one or more rename registers to provide the unpredicted value (2620).

[0180] Furthermore, in one example, storing includes referring to Fig. 26B allocating a register to hold the predicted value (2622) and copying the predicted value into the register allocated to hold the predicted value (2624).

[0181] In one example, the register is a rename register allocated for a logical register that is allocated to hold the predicted value (2626). Further, in one example, the rename register is marked as available (2628).

[0182] One or more aspects of the present invention are advantageously used to accelerate instruction sequences. According to a single embodiment for the Power Architecture, the sequence provided below can be efficiently executed, in which the counter register is used to initialize a GOT base when entering the function via a counter-indirect branch.

[0183] Thus, a caller can call a subroutine as shown below if it makes a register-indirect or a module-external call and if the counter (CRT) register has been initialized with the destination register of the function to be called: bctrl

[0184] According to a single embodiment, an ABI defines a function to have two entry points, one for count register (crt) indirect calls from module-external callers and register-indirect calls when a GOT pointer is to be initialized, and from a local caller when a GOT pointer is to be uninitialized: callee_ctr_indirect_entry: mfctr r12 ! obtain CTR value addis r2, r12, (.TOC.-callee_ctr_indirec_entry)@ha addi r2.r2, (.TOC.-callee_ctr_indirect_entry)@1 calle_direct_local_entry: ... ! subroutine body blr ! return to caller

[0185] Advantageously, the MFCTR instruction that loads the value of the count register can immediately provide the predicted speculative value of the CTR, allowing the subsequent sequence of addis and addi to compute the GOT pointer as a register for accessing global variables, and allowing continuation of accesses to global variables that would otherwise delay the processing of the subroutine body.

[0186] In another embodiment, e.g., according to the System / 360 instruction set, subroutine calls may be made using a register-indirect call, and only a single entry point may be present.

[0187] Other types of computing environments may also incorporate and utilize one or more aspects of the present invention, including, but not limited to, emulation environments, an example of which is described with reference to Fig. 27A. In this example, a computing environment 20 includes, for example, a native central processing unit (CPU) 22, main memory 24, and one or more input / output devices and / or interfaces 26 interconnected, for example, via one or more buses 28 and / or other connections. As examples, the computing environment 20 may include a PowerPC processor or a Power server offered by International Business Machines Corporation, Armonk, New York; and / or other computers based on architectures offered by International Business Machines Corporation, Intel, or other companies.

[0188] The native central processing unit 22 contains one or more native registers 30, such as one or more general-purpose registers and / or one or more special-purpose registers used during processing within the environment. These registers contain information representing the state of the environment at any given time.

[0189] In addition, the native central processing unit 22 executes instructions and code stored in main memory 24. In one particular example, the central processing unit executes emulator code 32 stored in main memory 24. This code enables the computing environment configured in one architecture to emulate another architecture. For example, the emulator code 32 enables computers based on architectures other than the z / Architecture, such as PowerPC processors, pSeries servers, or other servers or processors, to emulate the z / Architecture and execute software and instructions developed based on the z / Architecture.

[0190] Further details regarding the emulator code 32 are given with reference to Fig. 27B. Guest instructions 40 stored in main memory 24 include software instructions (e.g., correlating with machine instructions) designed for execution on a different architecture than that of the native CPU 22. For example, guest instructions 40 may have been designed for execution on a z / Architecture processor, but are instead emulated on the native CPU 22, which may be, for example, an Intel processor. In one example, emulator code 32 includes an instruction fetch routine 42 to obtain one or more guest instructions 40 from main memory 24 and, optionally, to provide local buffering for the obtained instructions. It also includes an instruction translation routine 44 to determine the type of guest instruction received and to translate the guest instruction into one or more corresponding native instructions 46.This implementation includes, for example, determining the function to be performed by the guest instruction and selecting the native instruction(s) to perform that function.

[0191] Additionally, emulator code 32 includes an emulation control routine 48 to cause the native instructions to be executed. Emulation control routine 48 may cause native CPU 22 to execute a routine of native instructions that emulate one or more previously received guest instructions and, at the end of that execution, return control to the instruction fetch routine to emulate receiving the next guest instruction or group of guest instructions. Execution of native instructions 46 may include loading data from main memory 24 into a register; storing data from a register back into main memory; or performing a particular type of arithmetic or logical operation determined by the translation routine.

[0192] For example, each routine is embodied in software stored in main memory and executed by the native central processing unit 22. In further examples, one or more of the routines or operations are executed in firmware, hardware, software, or a combination thereof. The registers of the emulated processor may be emulated using the registers 30 of the native CPU or by using memory locations in main memory 24. In embodiments, the guest instructions 40, the native instructions 46, and the emulator code 32 may be located in the same main memory or distributed among different memory units.

[0193] As used herein, firmware includes, for example, the microcode or millicode of the processor. It includes, for example, the hardware-level instructions and / or data structures used in the execution of higher-level machine code. In one embodiment, it includes, for example, proprietary code, typically delivered as microcode, which includes trusted software or microcode specific to the underlying hardware and controls operating system access to the system hardware.

[0194] A guest instruction 40 that is received, translated, and executed may, for example, be one of the instructions described herein. The instruction, which is an instruction from one architecture (e.g., the z / Architecture), is fetched from main memory, translated, and represented as a sequence of native instructions 46 of another architecture (e.g., PowerPC, pSeries, Intel, etc.). These native instructions are then executed.

[0195] One or more aspects may relate to cloud computing.

[0196] It should be understood at the outset that, although this disclosure contains a detailed description of cloud computing, the implementation of the teachings herein is not limited to a cloud computing environment. Rather, embodiments of the present invention may be practiced in conjunction with any other type of computing environment now known or later invented.

[0197] Cloud computing is a service delivery model for enabling seamless, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four implementation models. The properties are as follows:

[0198] On-demand self-service: A cloud user can unilaterally and automatically provision data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider.

[0199] Broad Network Access: Functions are available over a network and accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0200] Resource pooling: The provider's computing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control or knowledge over the exact location of the provided resources, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0201] Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling out, in some cases automatically, and released quickly for rapid scale-in. To the user, the features available for deployment often appear unlimited, and they can be purchased in any quantity at any time.

[0202] Measured Service: Cloud systems automatically control and optimize resource usage by leveraging a metering function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource consumption can be monitored, controlled, and reported, creating transparency for both the provider and the user of the service. The service models are as follows:

[0203] Software as a Service (SaaS): The functionality provided to the user is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices via a thin client interface such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0204] Platform as a Service (PaaS): The functionality provided to the user is to deploy applications created or obtained by the user, using programming languages ​​and tools supported by the provider, into the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly over configurations of the application hosting environment.

[0205] Infrastructure as a Service (IaaS): The functionality provided to the user consists of providing processing, storage, networking, and other basic computing resources, allowing the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls). The deployment models are as follows:

[0206] Private Cloud: The cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can be located on its own premises or on a third-party site.

[0207] Community Cloud: The cloud infrastructure is shared by multiple organizations and supports a specific user community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organizations or a third party and can be located on their own premises or on someone else's premises.

[0208] Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0209] Hybrid Cloud: Cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain separate entities but are interconnected by a standardized or proprietary technology that enables data and application portability (e.g., cloud targeting for load balancing between clouds).

[0210] A cloud computing environment is service-oriented, focusing on state independence, low coupling, modularity, and semantic interoperability. At the heart of cloud computing lies an infrastructure consisting of a network of interconnected nodes.

[0211] With reference to Fig. 28, an illustrative cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices employed by cloud users, such as the personal digital assistant (PDA) or cellular phone 54A, the desktop computer 54B, the laptop computer 54C, and / or the automotive computer system 54N, can communicate. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or a combination thereof.This enables the cloud computing environment 50 to offer infrastructure, platforms, and / or software as a service, for which a cloud user does not need to maintain resources on a local computing device. It should be noted that the types of services described in . Fig. 28 are intended to be merely illustrative and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computer-based device via any type of network and / or via any type of network-accessible connection (e.g., using a web browser).

[0212] With reference to Fig. 29 shows a set of functional abstraction layers used by the cloud computing environment 50 ( Fig. 28). It should be clear from the outset that the Fig.The components, layers, and functions shown in Figure 29 are intended to be illustrative only, and embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided: A hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe computers 61; servers based on the RISC (Reduced Instruction Set Computer) architecture 62; servers 63; blade servers 64; storage units 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0213] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be deployed: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0214] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 provides for the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when using resources within the cloud computing environment, as well as billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 83 provides users and system administrators with access to the cloud computing environment.Service level management 84 provides the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment 85 provides the pre-arranging and procurement of cloud computing resources for which future requirements are anticipated, in accordance with an SLA.

[0215] A workload layer 90 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and registry processing 96.

[0216] The present invention may be a system, a method, and / or a computer program product at any possible level of integration of technical details. The computer program product may comprise computer-readable storage medium(s) having computer-readable program instructions stored thereon for causing a processor to perform aspects of the present invention.

[0217] The computer-readable storage medium may be any physical device capable of retaining and storing instructions for use by an instruction-executing system. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM).Flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as containing transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., pulses of light carried through a fiber optic cable), or electrical signals carried through a wire.

[0218] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.

[0219] Computer-readable program instructions for performing operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, integrated circuit configuration data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and procedural programming languages ​​such as the C programming language or similar programming languages.The computer-readable program instructions 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 case, the remote computer may be connected to the user's computer through 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).In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention.

[0220] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer-readable program instructions.

[0221] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine such that the instructions, executed by the processor of the computer or other programmable data processing device, produce a means for implementing the functions / steps defined in the flowchart block(s) and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored thereon comprises an article of manufacture, including instructions that implement aspects of the function / step specified in the flowchart block(s) and / or block diagrams.

[0222] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of process steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-executable process such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / steps defined in the block(s) of flowcharts and / or block diagrams.

[0223] The flowcharts 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 of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for performing the particular logical function(s). In some alternative implementations, the functions indicated in the block may occur in a different order than shown in the figures. For example, two blocks shown in succession may actually execute substantially concurrently, or the blocks may sometimes execute in reverse order depending on the corresponding functionality.It is further understood that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or steps, or by combinations of special purpose hardware and computer instructions.

[0224] In addition to the foregoing, one or more aspects may be provided, offered, deployed, managed, maintained, etc., by a service provider that offers management of customer environments. For example, the service provider may create, maintain, support, etc., computer code and / or computer infrastructure that executes one or more aspects for one or more customers. The service provider, in turn, may receive payments from the customer under a subscription and / or fee-based agreement, as examples. Additionally or alternatively, the service provider may receive payments from the sale of advertising content to one or more third parties.

[0225] In one aspect, an application may be deployed to perform one or more embodiments. As an example, deploying an application includes providing computing infrastructure configured to perform one or more embodiments.

[0226] As another aspect, a computing infrastructure may be employed comprising embedding computer-readable code into a computing system, wherein the code, in conjunction with the computing system, is capable of performing one or more embodiments.

[0227] 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 includes a computer-readable medium, wherein the computer medium includes one or more embodiments. The code in conjunction with the computer system is capable of executing one or more embodiments.

[0228] While various embodiments have been described above, these are merely examples. For example, computing environments of other architectures may be used to incorporate and utilize one or more embodiments. Furthermore, different instructions or operations may be used. Furthermore, different registers may be used and / or other types of information (other than register numbers) may be provided. Many variations are possible.

[0229] Furthermore, other types of computing environments may benefit and be used. As an example, a computing system capable of storing and / or executing program code may be used, including at least two processors connected directly or indirectly to storage elements via a system bus. The storage elements include, for example, local memory used during actual execution of the program code, mass storage, and cache memory that allows temporary storage of at least a portion of the program code to reduce the frequency with which code must be retrieved from mass storage during execution.

[0230] Input / output (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 intervening I / O controllers. Network adapters can also be connected to the system to enable the computing system to connect to other computing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.

Claims

[1] A computer program product for simplifying processing 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 a method comprising: predicting, using a processor of the computing environment, a predicted value to be used in a register-indirect branch, the predicted value comprising a target address to which a register-indirect branch is to be pointed according to the prediction; Storing the predicted value at a selected memory location accessible by one or more instructions of the computing environment, wherein the storing is performed concurrently with processing the register-indirect branch, in which, within the bounds of a single architected instruction, the predicted target address is stored at the selected memory location and in a program counter to redirect the instruction fetch to the predicted target address; and Using the predicted value in speculative processing that includes the register-indirect branch, wherein at least some of the one or more instructions are instructions of code that the register-indirect branch is predicted to reference, and wherein the using comprises accessing the predicted value from the selected memory location by the at least some of the one or more instructions as part of the speculative processing. [2] The computer program product of claim 1, wherein the using further comprises redirecting the instruction fetch to the predicted target address. [3] The computer program product of claim 1, wherein the selected memory location comprises a hardware register. [4] The computer program product of claim 1, wherein the method further comprises: Determine whether the predicted value is accurate; and Performing a recovery based on the determination that the predicted value is inaccurate. [5] The computer program product of claim 4, wherein the recovery comprises: Deleting one or more instructions that are executed subsequent to the use; and Replacing the predicted value with an unpredicted value. [6] The computer program product of claim 5, wherein replacing comprises using one or more rename registers to provide the unpredicted value. [7] The computer program product of claim 1, wherein storing comprises: Assigning a register to hold the predicted value; and Copy the predicted value into the register allocated to hold the predicted value. [8] The computer program product of claim 7, wherein the register is a rename register allocated for a logical register that is assigned to hold the predicted value. [9] The computer program product of claim 8, wherein the method further comprises marking the rename register as available. [10] A computer system for facilitating processing in a data processing environment, the computer system (102) comprising: a main memory (106); and a processor (104) communicating with the main memory, the computer system (102) being configured to perform a method, the method comprising: Predicting a predicted value to be used in a register-indirect branch, the predicted value having a target address to which a register-indirect branch is predicted to point; Storing the predicted value at a selected memory location accessible by one or more instructions of the computing environment, wherein the storing is performed concurrently with the processing of the register-indirect branch, in which, within the bounds of a single architected instruction, the predicted target address is stored at the selected memory location and in a program counter to redirect the instruction fetch to the predicted target address; and Using the predicted value in speculative processing that includes the register-indirect branch, wherein at least some of the one or more instructions are instructions of code that the register-indirect branch is predicted to reference, and wherein the using comprises accessing the predicted value from the selected memory location by the at least some of the one or more instructions as part of the speculative processing. [11] The computer system of claim 10, wherein the selected memory location comprises a hardware register. [12] The computer system of claim 10, wherein the method further comprises: Determine whether the predicted value is accurate; and Performing a recovery based on the determination that the predicted value is inaccurate. [13] The computer system of claim 10, wherein storing comprises: Assigning a register to hold the predicted value; and Copy the predicted value into the register allocated to hold the predicted value. [14] A computer-implemented method for facilitating processing in a data processing environment, the computer-implemented method comprising: Predicting, using a processor of the computing environment, a predicted value to be used in a register-indirect branch, the predicted value having a target address to which a register-indirect branch is predicted to point (200, 500, 1200, 1300, 1700, 2506); Storing the predicted value at a selected memory location accessible by one or more instructions of the computing environment, wherein the storing is performed concurrently with processing the register-indirect branch in which, within the bounds of a single architected instruction, the predicted target address is supplied at the selected memory location and in a program counter to redirect the instruction fetch to the predicted target address; and Using the predicted value in speculative processing that includes the register-indirect branch, wherein at least some of the one or more instructions are instructions of code that the register-indirect branch is predicted to reference, and wherein the using comprises accessing the predicted value from the selected memory location by the at least some of the one or more instructions as part of the speculative processing. [15] The computer-implemented method of claim 14, wherein said using further comprises redirecting said instruction fetch to said predicted target address (202,502,1202,1302,1702,2508). [16] The computer-implemented method of claim 14, wherein the selected memory location comprises a hardware register. [17] A computer-implemented method according to claim 14, further comprising: Determine whether the predicted value is accurate; and Performing a recovery based on the determination that the predicted value is inaccurate. [18] A computer-implemented method according to claim 17, wherein the recovery comprises: Deleting one or more instructions that are executed after use (304,404,604,704,1404,1604,1704); and Replacing the predicted value with an unpredicted value. [19] The computer-implemented method of claim 18, wherein replacing comprises using one or more rename registers to provide the unpredicted value. [20] A computer-implemented method according to claim 14, wherein storing comprises: Assigning a register to hold the predicted value; and Copy the predicted value into the register allocated to hold the predicted value. [21] A computer-implemented method according to claim 20, wherein the register is a rename register allocated for a logical register that is allocated to hold the predicted value. [22] The computer-implemented method of claim 21, further comprising marking the rename register as available.

Images