Patent Grant
11010164
One or more aspects relate, in general, to processing within a computing environment, and in particular, to facilitating such processing.
Many computing systems use a Global Offset Table (GOT) or a Table of Contents (TOC) to populate variables within source code. For instance, a compiler generates object code from source code, without knowing the final address or displacement of the code/data. Specifically, the compiler generates object code that will access a variable address reference data structure (e.g., a Global Offset Table or a Table of Contents) for variable values without knowing the final size of the data structure or offsets/addresses of various data sections. Placeholders for this information are left in the object code and updated by a linker.
To access the GOT or TOC, a pointer is used. The pointer is typically computed by a sequence of instructions. These instructions often depend on computed registers which are not always readily available in a processor. Consequently, accesses to variables that depend on the TOC (i.e., variables other than local variables) may be delayed.
Shortcomings of the prior art are overcome and additional advantages are provided through the provision of a computer program product for facilitating processing within a computing environment. The computer program product includes a computer readable storage medium readable by a processing circuit and storing instructions for performing a method. The method includes, for instance, calling a subroutine from a calling module executing on a processor. Based on calling the subroutine, a value of a pointer to a reference data structure is predicted. The predicting is performed prior to executing a sequence of one or more instructions in the subroutine to compute the value. The value that is predicted is used to access the reference data structure to obtain a variable value for a variable of the subroutine. By predicting the value of the pointer, based on calling the subroutine, performance is improved.
In a further aspect, a current value of the pointer is obtained prior to the predicting, and the current value is stored in a recovery location. This is to facilitate recovery in the event of a misprediction. A determination is made, in one embodiment, that the value predicted for the pointer is incorrect. Based on determining the value predicted for the pointer is incorrect, the current value is recovered from the recovery location.
In yet a further aspect, the value predicted for the pointer is loaded in a defined location. This facilitates processing.
Yet further, in one aspect, a determination is made as to whether a current instruction in the subroutine corresponds to the sequence of one or more instructions to compute the value. Based on determining the current instruction corresponds to the sequence of one or more instructions to compute the value, a check instruction is inserted in the code to check the prediction of the value. The inserting replaces the sequence of one or more instructions.
In a further embodiment, a determination is made as to whether a check indicator is set. Based on determining the check indicator is set, a determination is made as to whether the current instruction corresponds to the sequence of one or more instructions to compute the value.
As one example, based on determining the current instruction does not correspond to the sequence of one or more instructions to compute the value, a determination is made as to whether the current instruction corresponds to a sequence of one or more instructions to use the value. Based at least on determining that the current instruction corresponds to the sequence of one or more instructions to use the value, recovery is performed.
In one example, the sequence of one or more instructions includes a load instruction. In another example, the predicting includes using a reference data structure pointer cache to obtain the value.
Further, in one embodiment, a current value of the pointer is obtained prior to the predicting, and the current value is stored in a rename register for use in recovery.
Computer-implemented methods and systems relating to one or more aspects are also described and claimed herein. Further, services relating to one or more aspects are also described and may be claimed herein.
Additional features and advantages are realized through the techniques described herein. Other embodiments and aspects are described in detail herein and are considered a part of the claimed aspects.
One or more aspects are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and objects, features, and advantages of one or more aspects are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
In accordance with an aspect of the present invention, the providing of a pointer to a reference data structure, such as a Table of Contents (TOC) or a Global Offset Table (GOT), is facilitated. In one example, a Set TOC Register (STR) instruction is provided that loads a register (or other defined location) with a value used to access the TOC (e.g., a pointer value). Although a TOC is referred to herein as an example, the aspects, features and techniques described herein are equally applicable to a GOT or other similar type structures.
TOC pointer value, TOC pointer, TOC value, and pointer to the TOC, as examples, are used interchangeably herein. The TOC register holds a TOC pointer, and therefore, may be referred to herein as a TOC pointer register or a TOC register.
Further, TOC pointer cache, TOC pointer tracking structure, TOC pointer table, etc. are also referred to herein as TOC cache, TOC tracking structure, TOC table, etc., respectively. Similarly, reference data structure pointer cache and reference data structure cache are used interchangeably herein. Others examples may also exist.
In a further aspect, sequences of instructions typically used to set a TOC register are replaced by a Set TOC Register instruction. As an example, a sequence of instructions includes one or more instructions. Further, a verify operation may be used to verify the TOC register value. A TOC register may be, for instance, a hardware register, or an architected register, such as a general purpose register (e.g., r2, r12), defined by an architecture or specified by an Application Binary Interface (ABI). Other examples are possible.
In yet a further aspect, the TOC pointer value is predicted responsive to branching to a subroutine.
In still a further aspect, embodiments of a TOC cache are provided to facilitate processing. A TOC cache (or other reference data structure cache) is, for instance, a high-speed in-processor cache that includes various TOC pointer values to be predicted for different locations/modules in the program that have recently been used.
Yet further, an aspect is provided to prepare and initialize a TOC tracking structure for TOC pointer value prediction. A TOC tracking structure may be, for instance, a TOC cache or an in-memory table populated with TOC pointer values to be predicted for different location/modules in the program.
In a further aspect, a pseudo-register (also referred to herein as a read-only TOC register) is used to provide the pointer value, along with TOC register addressing modes. The pseudo-register is not a hardware or architected register, nor does it have storage associated therewith; instead, it is a TOC pointer value obtained, e.g., from a TOC cache (e.g., the value that would have been produced by STR).
Moreover, in a further aspect, code is generated and/or compiled with a Set TOC Register instruction and/or to use read-only TOC registers.
Various aspects are described herein. Further, many variations are possible without departing from a spirit of aspects of the present invention. It should be noted that, unless otherwise inconsistent, each aspect or feature described herein and variants thereof may be combinable with any other aspect or feature.
One embodiment of a computing environment to incorporate and use one or more aspects of the present invention is described with reference to
In another example, the computing environment is based on the Power Architecture, offered by International Business Machines Corporation, Armonk, N.Y. One embodiment of the Power Architecture is described in “Power ISA™ Version 2.07B,” International Business Machines Corporation, Apr. 9, 2015, which is hereby incorporated herein by reference in its entirety. POWER ARCHITECTURE is a registered trademark of International Business Machines Corporation, Armonk, N.Y., USA.
The computing environment may also be based on other architectures, including, but not limited to, the Intel x86 architectures. Other examples also exist.
As shown in
Bus 110 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include the Industry Standard Architecture (ISA), the Micro Channel Architecture (MCA), the Enhanced ISA (EISA), the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI).
Memory 106 may include, for instance, a cache 120, such as a shared cache, which may be coupled to local caches 122 of processors 104. Further, memory 106 may 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 carry out functions of embodiments of aspects of the invention.
Computer system 102 may also communicate via, e.g., I/O interfaces 108 with one or more external devices 140, one or more network interfaces 142, and/or one or more data storage devices 144. Example external devices include a user terminal, a tape drive, a pointing device, a display, etc. Network interface 142 enables computer system 102 to communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet), providing communication with other computing devices or systems.
Data storage device 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 carry out functions of embodiments of aspects of the invention.
Computer system 102 may include and/or be coupled to removable/non-removable, volatile/non-volatile computer system storage media. For example, it may include and/or be coupled to a non-removable, non-volatile magnetic media (typically called a “hard 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 conjunction 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 archival storage systems, etc.
Computer system 102 may be operational 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, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.
Further details regarding one example of processor 104 are described with reference to
Processor 104 also includes, in one embodiment, one or more registers 168 to be used by one or more of the functional components. Processor 104 may include additional, fewer and/or other components than the examples provided herein.
Further details regarding an execution pipeline of processor 104 are described with reference to
Referring to
Further, in one example, coupled to the decode unit is a register renaming unit 192, which may be used in the saving/restoring of registers.
Additional details regarding a processor are described with reference to
The same address is also provided to an instruction cache 109, which may fetch a plurality of instructions referred to as a “fetch group”. Associated with instruction cache 109 is a directory 111.
The cache and prediction hardware are accessed at approximately the same time with the same address. If the prediction hardware has prediction information available for an instruction in the fetch group, that prediction is forwarded to an instruction sequencing unit (ISU) 113, which, in turn, issues instructions to execution units for execution. The prediction may be used to update IFAR 107 in conjunction with 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 available, 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 in a branch information queue (BIQ) 125, and forwarded to ISU 113.
A branch execution unit (BRU) 121 operates in response to instructions issued to it by ISU 113. BRU 121 has read access to a condition register (CR) file 123. Branch execution unit 121 further has access to information stored by the branch scan logic in branch information queue 125 to determine the success of a branch prediction, and is operatively coupled to instruction fetch address register(s) (IFAR) 107 corresponding to the one or more threads supported by the microprocessor. In accordance with at least one embodiment, BIQ entries are associated with, and identified by an identifier, e.g., by a branch tag, BTAG. When a branch associated with a BIQ entry is completed, it is so marked. BIQ entries are maintained in a queue, and the oldest queue entries are de-allocated sequentially when they are marked as containing information associated with a completed branch. BRU 121 is further operatively coupled to cause a predictor update when BRU 121 discovers a branch misprediction.
When the instruction is executed, BRU 121 detects if the prediction is wrong. If so, the prediction is to be updated. For this purpose, the processor also includes predictor update logic 127. Predictor update logic 127 is responsive to an update indication from branch execution unit 121 and configured to update array entries in one or more of the local BHT 105a, global BHT 105b, and global selector 105c. The predictor hardware 105a, 105b, and 105c may have write ports distinct from the read ports used by the instruction fetch and prediction operation, or a single read/write port may be shared. Predictor update logic 127 may further be operatively coupled to link stack 117a and count register stack 117b.
Referring now to condition register file (CRF) 123, CRF 123 is read-accessible by BRU 121 and can be written to by the execution units, 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 execution unit (CRL execution) 147 (also referred to as the CRU), and special purpose register (SPR) handling logic 149 have read and write access to condition register file (CRF) 123. CRU 147 performs logical operations on the condition registers stored in CRF file 123. FXU 141 is able to perform write updates to CRF 123.
Processor 104 further includes, a load/store unit 151, and various multiplexors 153 and buffers 155, as well as address translation tables 157, and other circuitry.
Processor 104 executes programs (also referred to as applications) that include variables. A variable has an identifier (e.g., name) and refers to a storage location that includes a value (e.g., information, data). During runtime, a program determines addresses of the variables, which were not known at compile time, by using the TOC.
When a subroutine is called, the subroutine establishes its own TOC because if it is in a different module than the function that called it, it will have its own data dictionary (i.e., TOC) and a pointer to that dictionary is to be established. Establishing such a pointer is expensive.
One example of code used to establish a TOC pointer is shown below, e.g., with reference to an example ABI, such as the Open POWER ELFv2 ABI.
In accordance with one such example embodiment, the caller initializes one or more registers with the address of the called function, e.g., in accordance with an ABI.
In the following example, two registers, r12 and ctr, are initialized with the address of the called function:
In accordance with an established ABI, the called function initializes a TOC pointer. A variety of implementations exist. In one embodiment, the entry address from the one or more registers initialized by the caller is used, when the address function is called via a register-indirect call. For example, in accordance with an example ABI, such as the Open POWER ELFv2 ABI, the TOC pointer register, r2, may be initialized as follows using the callee's function entry address loaded into r12 by the caller by the function called “foo”:
In accordance with an aspect of the present invention, instead of determining the TOC pointer using, for instance, the code above, which is expensive in many microprocessor implementations, a Set TOC Register (STR) instruction is used. The Set TOC Register instruction loads a register (or other defined location) with a value of a pointer to the TOC, e.g., by performing a look-up in the processor. Since the TOC is shared by all (or a set) of functions of a module, only a small number of TOC register values are to be remembered and associated with a range of addresses. As examples, the Set TOC Register instruction may be implemented as an architected hardware instruction or an internal operation.
One example of a Set TOC Register (STR) instruction is described with reference to
Although, in this example, one opcode field is shown, in other embodiments, there may be a plurality of opcode fields. Other variations are also possible.
As indicated, in one example, target register field 204 identifies a register to be loaded with a TOC pointer value. The STR instruction loads the register specified by field 204 with the value of the TOC pointer for a present code sequence, in which the code sequence corresponds to code following the address of the STR instruction.
There are a variety of possible implementations of processing associated with the STR instruction including, for instance, a software implementation, a hardware-assisted implementation, and a hardware implementation. In the software implementation, based on executing the STR instruction, an exception is raised and the setting of the TOC register is emulated by supervisor code (e.g., the operating system or hypervisor) or by a user-mode interrupt handler (e.g., using an event-based branch facility in accordance with a definition of the Power Architecture). In the hardware-assisted implementation, the hardware provides a cache (e.g., a small table or other data structure to store most frequently used values) or predictor for frequent values and traps to the software. The supervisor code or user-mode interrupt handler then processes the instruction, as described above. In the hardware implementation, the hardware provides a cache or predictor for frequent values, and based on a miss in the cache, looks up a table (or other data structure that has been populated in software with the TOC pointer values). Further details regarding the implementation choices are described with reference to
One implementation that uses software, e.g., supervisor code or user-mode interrupt handler, is described with reference to
Another implementation is described with reference to
A further implementation is described with reference to
In one or more of the above examples, the TOC cache may be implemented in a number of ways. For instance, it may include a pair (STR address, returned value) associating a value to return for the address of each STR instruction, or it may include a range of addresses of STR instructions for which to return a specified value, since adjacent functions typically share a TOC, e.g., storing a triple (from_range, to_range, returned value) in a table. Further details regarding TOC caches are described below.
Although in the above-described embodiments, the STR is used to load a TOC value, the STR may also be used to load other values, such as a magic number (e.g., identifier in, e.g., the Executable and Linkable Format (ELF)), or other values, e.g., those which may be associated with a region of code, specific modules, or particular instruction addresses of an STR instruction. Many possibilities exist.
In a further aspect, code is scanned looking for instruction sequences that set the value of a TOC register and those instruction sequences are replaced with a Set TOC Register instruction. In yet a further aspect, a verification instruction is provided to verify prediction of the value of the TOC register. As examples, an instruction sequence includes one or more instructions.
In accordance with conventional code generation techniques, TOC values are often computed using a sequence of instructions, or loaded from the stack.
For instance, a TOC value may be computed using a sequence such as:
In another example, a TOC value is loaded (ld) from memory (e.g., a stack):
These sequences commonly involve interlocks (e.g., need to wait on a previous store instruction directed at storing the TOC value to complete), before they may complete. This type of interlock commonly results in performance degradation. Thus, in accordance with an aspect of the present invention, a processor instruction decode unit recognizes TOC-setting instructions and/or TOC-setting instruction sequences and replaces them with an STR instruction. Optionally, a verification instruction is also provided. As used herein, a TOC-setting instruction and/or TOC-setting instruction sequence includes one or more instructions used to set a TOC register or compute a TOC pointer value.
For example, in one embodiment, the following instruction sequence is recognized by the processor (e.g., the instruction decode unit of the processor):
and the sequence is replaced with the following operations to load a (predicted) TOC value and verify the prediction by comparing it to the sum of the register r12 and offset used in the original code to compute r2:
In a further example:
is replaced with:
Examples of the STR instruction are described above, and further details regarding using the verify operations are described below. For instance, further details associated with using an STR verify internal operation (iop), e.g., verify rx, ry, offset, are described with reference to
Referring to
However, if the value of rx is unequal to a, then a is assigned to the target register rx, STEP 608, and recovery is initiated, STEP 610. Recovery includes, for instance, flushing incorrect uses of rx from the instruction pipeline after the present instruction or flushing all instructions in the pipeline after the present instruction. Other variations are also possible.
In a further embodiment, as shown in
Other examples of verification techniques performed, e.g., by a processor, are described with reference to
In another embodiment, with reference to
In a further embodiment, different execution paths may be taken depending on whether the TOC value is in the TOC cache. One example of this processing is performed by e.g., a processor, and is described with reference to
Other implementations and variations are also possible.
In a further aspect, the TOC value is predicted based on entering a subroutine. For instance, when a subroutine call is performed, the TOC value is predicted, rather than waiting to find a sequence of instructions that is believed to compute the TOC value. Instead, the TOC value is predicted upon entering the subroutine, and then, when the sequence of instructions in the called routine that computes the TOC value is encountered, it is replaced by a TOC checking instruction (i.e., an instruction that checks or verifies the predicted TOC value). If the TOC checking instruction fails, or a TOC value is accessed without the prediction having been checked, recovery may be performed.
As one example, the processor predicts the value of the TOC register (e.g., r2) for a subroutine based on previously observed addresses. The predicted TOC value is entered into a target address register array in conjunction with a predicted target address or in a separate TOC prediction array, as examples.
In particular embodiments, the TOC value may be predicted using, for instance, the hardware-assisted technique described with reference to
One embodiment of predicting the TOC value based on a subroutine branch is described with reference to
Further details regarding a TOC check, and in particular, insertion logic for the TOC check, are described with reference to
Returning to INQUIRY 1004, if the current instruction does not correspond to a TOC setting instruction, then a further determination is made as to whether the current instruction corresponds to a TOC use instruction (i.e., one or more of instructions to use the TOC value or TOC register), INQUIRY 1010. If not, then processing is complete. Otherwise, recovery may be performed, STEP 1012. In one embodiment, this can be accomplished by copying the value in TOCRECOVER back into the TOC register (e.g., r2). In another embodiment, register renaming may be used. In this embodiment, the predicted TOC value is stored in a new rename register, and during recovery, the new rename register is invalidated or the old TOC value is copied from another rename register to the new rename register. Other implementations and/or embodiments are also possible.
Another embodiment of predicting a TOC value based on a subroutine branch is described with reference to
Returning to INQUIRY 1100, if the subroutine call is a candidate for predicting the TOC value, then the subroutine call is made, STEP 1104. Optionally, other affiliated values may be predicted, in addition to the TOC value. Further, the old TOC value is saved in, for instance, a recovery register, TOCRECOVER, STEP 1106. Then, an attempt is made to predict the TOC value using the TOC cache, STEP 1108. A determination is made as to whether there was a TOC cache hit, INQUIRY 1110. If there was a TOC cache hit, then the obtained TOC value is loaded into the TOC pointer register (e.g., r2), STEP 1112. Further, a TOC check flag is set (e.g., to 1) indicating a TOC value check is to be performed prior to use of the predicted TOC value, and in one embodiment, a TOC capture flag located in a select location is turned off (e.g., set to 0), STEP 1114. Returning to INQUIRY 1110, if there is a TOC cache miss, then the TOC capture flag is set to indicate a TOC capture (e.g., set to 1) is to be performed to obtain the TOC value, and the TOC check flag is turned off (e.g., set to 0), STEP 1116. Other variations are also possible.
Details regarding check insertion logic for the embodiment of
Returning to INQUIRY 1202, if the current instruction corresponds to a TOC setting instruction, then the check is inserted into the code, STEP 1210. For instance, an STR verify or an STR load-verify is inserted. The TOC check flag is then turned off (e.g., set to 0), STEP 1212.
A further embodiment of TOC check insertion logic is described with reference to
Returning to INQUIRY 1302, if the current instruction does not correspond to a TOC setting instruction, then the check is inserted, which in one example includes a verify instruction that triggers recovery actions, STEP 1310, and the TOC capture flag is reset (e.g., set to 0), STEP 1312.
In one embodiment, the processing associated with the TOC check flag and the TOC capture flag may be performed, and in one example, they may be performed in parallel.
Further details regarding a TOC cache are now described with reference to
One embodiment of inserting an entry into the TOC cache is described with reference to
In one embodiment, a single TOC pointer value corresponds to an entire module, i.e., all functions in a module have the same TOC pointer value. Therefore, in accordance with an aspect of the present invention, the processor stores a TOC value in a TOC cache for a range of addresses. As an example, the range of addresses corresponding to the same TOC pointer value is dynamically determined, e.g., by coalescing newly discovered values of the TOC with pre-existing ranges. In a further embodiment, the extent of the ranges is provided by the dynamic loader, and a predicted TOC value is associated with the value of the range. Other examples are also possible.
As a further example, the TOC may cover a portion of a module, and then, the range of addresses would be the range of that portion. Other variations also exist.
The TOC cache may be used, as described above, but in this aspect, the TOC cache has a different format than in
As shown in
One embodiment of inserting an entry in such a TOC cache is described with reference to
Returning to INQUIRY 1704, if an entry is found, then a determination is made as to whether the callee address is less than the address in the address_from column, INQUIRY 1720. If the callee address is less than the address_from column, then the address_from column of the selected entry is updated to the callee address, STEP 1722. Otherwise, the address_to column of the selected entry is updated to the callee address, STEP 1724.
The above flow assumes one entry per TOC value such that there are not multiple entries found. However, if multiple entries could be found for a particular module, then a check for such would be made.
In a further embodiment, candidate selection for TOC prediction may use the TOC table with ranges to determine whether a call to the same module is performed to suppress TOC prediction. Other variations are possible.
In a further aspect, a TOC tracking structure is prepared and initialized for TOC prediction. As one example, a linker links a program and the linker determines a TOC value, either an absolute value for a module or a relative offset, e.g., relative to a module load address. The dynamic loader loads the module and computes the final TOC value. The dynamic loader then loads the TOC value into a TOC tracking structure to be used in connection with, for instance, the Set TOC Register instruction or another predictive instruction.
As examples, the TOC tracking structure may be the TOC cache itself or it may be an in-memory table representation. Other examples are also possible. Further, details associated with storing TOC values into the tracking structure are described with reference to
Referring to
In one embodiment, when the tracking structure is, e.g., an in-memory structure, and a TOC value is not found in the TOC cache, control is transferred to software using, e.g., an interrupt, or user-mode event based branch. The software handler then reloads the value, e.g., by accessing the in-memory structure storing the address range and TOC value corresponding to each module. In another embodiment, the in-memory TOC structure is architecturally defined and a hardware handler reloads the TOC cache directly from the in-memory structure. In one embodiment, the software handler reloads both the TOC cache and the in-memory structure when loading a module. Other variations are possible.
In accordance with a further aspect of the present invention, a read-only TOC register and TOC addressing modes are included in an instruction set architecture (ISA). The read-only TOC register is, for instance, a pseudo or virtual register that provides a TOC value for a given module (e.g., by accessing a TOC cache or an in-memory table). That is, it is not a hardware or architected register and does not have storage backing it, but, instead provides a TOC value to be used when, e.g., a selected register number is referenced. The TOC value is initialized from, for example, a value stored in a TOC base table that may be loaded in conjunction with module initialization. A TOC base table can correspond to one or more of a TOC cache of
One example of using a read-only TOC register is described with reference to
In one embodiment, when there are provided n bits to encode 2n registers in an instruction set, one of the 2n register numbers is defined to refer to the value of the TOC pointer, and when that register is specified, the value of the TOC pointer is used as a value for the register.
In further aspects, various instructions are provided that may use a read-only register. For instance, various load TOC-Relative Long instructions are provided, as described with reference to
As shown in
Other embodiments of Load TOC-Relative Long instructions are also provided, as depicted in
The second operand is placed unchanged at the first operand location, except that, for Load TOC Relative Long (LGFTL), it is sign extended.
For Load TOC-Relative Long (LTL), the operands are, e.g., 32 bits, and for Load TOC-Relative Long (LGTL), the operands are 64 bits. For Load TOC-Relative Long (LGFTL), the second operand is treated as a 32-bit signed binary integer and the first operand is treated as a 64-bit signed binary integer.
When DAT is on, the second operand is accessed using the same addressing-space mode as that used to access the instruction. When DAT is off, the second operand is accessed using a real address.
For Load TOC-Relative Long (LTL, LGFTL), the second operand is to be aligned on a word boundary, and for Load TOC-Relative Long (LGTL), the second operand is aligned on a doubleword boundary; otherwise, a specification exception may be recognized.
One example of a Load Address TOC-Relative Long instruction is described with reference to
The address specified using the RI2 field is placed in general register R1. The address is obtained by adding the RI2 field to the value of the TOC at the current address.
In the 24-bit addressing mode, the address is placed in bit positions 40-63, bits 32-39 are set to zeros, and bits 0-31 remain unchanged. In the 31-bit addressing mode, the address is placed in bit positions 33-63, bit 32 is set to zero, and bits 0-31 remain unchanged. In the 64-bit addressing mode, the address is placed in bit positions 0-63.
No storage references for operands take place, and the address is not inspected for access exceptions.
In a further aspect, a TOC add immediate shifted (tocaddis) instruction is provided (for, e.g., a RISC-style architecture). As depicted in
As one example, the following defines tocaddis:
tocaddis RT,SI
RT<=(TOC)+EXTS (SI∥160)
The sum TOC+(SI∥0x0000) is placed into register RT. EXTS refers to extended sign and ∥ refers to concatenation.
In a further aspect, TOC-indicating prefix instructions may be provided. For instance, an add TOC immediate shifted instruction, addtocis+, is provided, which is a prefix instruction providing information for a next instruction. Referring to
As an example,
addtocis+RT,RA,SI
if RA=0 then RT←(TOC)+EXTS (SI∥160) else RT←(RA)+EXTS (SI∥160)
The sum (RA|TOC)+(SI∥0x0000) is provided as a source for references to register RT for the next sequential instruction only. addtocis+ is an instruction prefix, and modifies the following instruction to use the value computed for RT as input when RT is specified. The instruction indicates that RT becomes unused after the next sequential instruction is executed and its value will be undefined. If execution is interrupted after the addtocis+ instruction and prior to the next sequential instruction, the state will be updated in a manner to allow execution to resume with the next instruction and produce a correct result (i.e., RT will be written, or another implementation-defined method for retaining the effect of modifying the next sequential instruction's RT source will be used). It is noted that addTOCis+ uses the value of TOCbase, not the contents of GPRO, if RA=0.
The prefix instruction may have further options, such as a displacement specifier field that indicates whether additional immediate bits are to be used. Additionally, it may include one or more additional immediate fields that include values to be employed with (e.g., added to, OR'd with, etc.) operands of the successor instruction.
Other prefix options may be used including a TOC prefix and/or a TOC prefix with an option to override a selectable one of the operands. For instance, a prefix instruction may be provided that indicates that a TOC value should be used instead of one of the operands of a successor instruction. In one example, the operand is selectable.
Additionally, aspects of a prefix instruction (e.g., addtocis) and a subsequent instruction may be fused to facilitate processing. For instance, if a prefix instruction with a displacement is specified and the subsequent instruction also includes a displacement, then the displacement may correspond to an immediate shifted and an immediate displacement. Other possibilities exist.
A particular optimization example using addtocis is shown below. In this example, an n (e.g., 3) instruction candidate sequence includes, for instance: addtocis+r4, toc, upper; addi r4, r4, lower; and lvx*vr2, r0, r4. This sequence may be represented in the following template:
i1=addtocis+<r1>, <r2>, <upper>
i2=addi<r1>, <r1>, <lower>
i3=lvx*<vrt>, r0, <r1>
=> and optimized to the following internal operation:
lvd<vrt>, toc_or_gpr(<r2>), combined (<upper>, <lower>)
The addtocis instruction is similar to addis, but introduces the value of the TOC, rather than the constant 0, when the RA field has a value 0. In one example, lvx* is an instruction form that defines the base register (e.g., 4 in this example) as having an unspecified value after execution of the instruction. In one example, lvx* is a form of the lvx (load vector indexed) instruction indicating a last use of at least one register (e.g., defined herein to be the register indicated as <r1> in the template). Lvd is a load vector operation with an implemented defined displacement. The toc_or_gpr function handles expanding the TOC special case, since the lvd would otherwise handle the RA operand similar to all other RA operands as a 0 value representing 0, and the other register values representing the logical register.
Further opportunities may exist to reduce a complex sequence of instructions that includes a TOC instruction or a TOC-using instruction into a simpler sequence of instructions.
One embodiment of an execution flow used to manage TOC operands is described with reference to
Referring to
A determination is made as to whether a TOC operand is present in the instruction, INQUIRY 2404. That is, is there a operand in the instruction that explicitly or implicitly uses a TOC pointer? If a TOC operand is present, then the TOC operand is obtained, as described below, STEP 2406. Thereafter, or if a TOC operand is not present, any obtained operand values are used in accordance with the instruction definition, STEP 2408. Optionally, one or more output operands are written, STEP 2410.
In one example, a TOC operand is obtained from an in-memory TOC structure, as described with reference to
In another example, the TOC operand is obtained from a TOC cache, which is backed by an in-memory structure, as described with reference to
A further example of obtaining the TOC operand from a TOC cache backed by an in-memory structure is described with reference to
To load the TOC cache from software, a Load TOC Cache (LTC) instruction may be used. For instance, LTC Rfrom, Rto, RTOC may be used to load an entry for <MODULE.Rfrom, MODULE.Rto, MODULE.TOC>. For instance, an entry is included in the cache and the address_from column is populated using Rfrom; the address_to column is populated using Rto; and the TOC value is populated using RTOC. In one embodiment, an entry is selected in accordance with a replacement policy of a particular implementation.
In another embodiment, a table entry is loaded by loading a plurality of control registers.
One example of a use case is described below:
In accordance with the definition of the C programming language, the function foo returns a character from an array bar, in which the character position is indicated by the argument idx to function foo.
In accordance with one aspect of the present invention, a compiler translates this program to the following machine instruction sequence:
In accordance with one or more aspects of the present invention, a Set TOC Register instruction efficiently initializes a register to be loaded with the TOC value. Further, in accordance with an aspect of the present invention, since a Set TOC Register instruction is efficient, a TOC register value is not saved and restored in compiled code. Rather, when a subroutine is called, the TOC register value is abandoned. When a called function returns, the TOC value is not loaded. Rather, a new Set TOC Register instruction is generated to load the TOC register.
One example of compiler generated code to obtain the correct value of the TOC pointer based on an STR (Set TOC Register) instruction corresponding to the C program language function foo above is as follows:
foo:
One embodiment of initializing a register with the TOC pointer, as performed by the compiler, is described with reference to
In a further example, a static linker can initialize the TOC, as described with reference to
An example use case is as follows. This more efficient code is generated in accordance with an aspect of the present invention:
In addition to generating code with a TOC setting instruction, code may be generated using TOC read-only registers. This further obviates a need to load a GPR with the TOC, and thereby, reduces register pressure and overhead of loading the register, or of reloading it after a function call.
One example of compiler generated code to use a TOC read-only register is as follows:
In accordance with the definition of the C programming language, the function foo returns a character from an array bar, in which the character position is indicated by the argument idx to function foo.
In accordance with one aspect of the present invention, a compiler translates this program to the following machine instruction sequence.
One example of a compilation flow to use a TOC read-only register to reference the TOC is described with reference to
An example use case is as follows. This more efficient code is generated in accordance with an aspect of the present invention:
One or more aspects of the present invention are inextricably tied to computer technology and facilitate processing within a computer, improving performance thereof. Further details of one embodiment of facilitating processing within a computing environment, as it relates to one or more aspects of the present invention, are described with reference to
Referring to
In a further aspect, a current value of the pointer is obtained prior to the predicting (3108), and the current value is stored in a recovery location (3110). A determination is made, in one embodiment, that the value predicted for the pointer is incorrect (3112). Based on determining the value predicted for the pointer is incorrect, the current value is obtained from the recovery location (3114).
As one example, the value predicted for the pointer is loaded in a defined location (3116). Further, in one example, the predicting includes using a reference data structure pointer cache to obtain the value (3118).
In a further aspect, with reference to
In a further embodiment, a determination is made as to whether a check indicator is set (3126). Based on determining the check indicator is set, a determination is made as to whether the current instruction corresponds to the sequence of one or more instructions to compute the value (3128). Further, in one embodiment, based on determining the current instruction does not correspond to the sequence of one or more instructions to compute the value, a determination is made as to whether the current instruction corresponds to a sequence of one or more instructions to use the value (3130). Based at least on determining that the current instruction corresponds to the sequence of one or more instructions to use the value, recovery is performed (3132).
As an example, the sequence of one or more instructions includes a load instruction (3134). Further in one embodiment, a current value of the pointer prior to the predicting is obtained (3136), and the current value is stored in a rename register for use in recovery (3138).
Other variations and embodiments are possible.
Other types of computing environments may also incorporate and use one or more aspects of the present invention, including, but not limited to, emulation environments, an example of which is described with reference to
Native central processing unit 22 includes 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 include information that represents the state of the environment at any particular point in time.
Moreover, native central processing unit 22 executes instructions and code that are stored in memory 24. In one particular example, the central processing unit executes emulator code 32 stored in memory 24. This code enables the computing environment configured in one architecture to emulate another architecture. For instance, emulator code 32 allows machines 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 to execute software and instructions developed based on the z/Architecture.
Further details relating to emulator code 32 are described with reference to
Further, 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 obtained guest instructions and, at the conclusion of such execution, return control to the instruction fetch routine to emulate the obtaining of the next guest instruction or a group of guest instructions. Execution of native instructions 46 may include loading data into a register from memory 24; storing data back to memory from a register; or performing some type of arithmetic or logic operation, as determined by the translation routine.
Each routine is, for instance, implemented in software, which is stored in memory and executed by native central processing unit 22. In other examples, one or more of the routines or operations are implemented in firmware, hardware, software or some combination thereof. The registers of the emulated processor may be emulated using registers 30 of the native CPU or by using locations in memory 24. In embodiments, guest instructions 40, native instructions 46 and emulator code 32 may reside in the same memory or may be disbursed among different memory devices.
As used herein, firmware includes, e.g., the microcode or Millicode of the processor. It includes, for instance, the hardware-level instructions and/or data structures used in implementation of higher level machine code. In one embodiment, it includes, for instance, proprietary code that is typically delivered as microcode that includes trusted software or microcode specific to the underlying hardware and controls operating system access to the system hardware.
A guest instruction 40 that is obtained, translated and executed may be, for instance, one of the instructions described herein. The instruction, which is of one architecture (e.g., the z/Architecture), is fetched from 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.
One or more aspects may relate to cloud computing.
It is understood in advance that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.
Cloud computing is a model of service delivery for enabling convenient, 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 provider of the service. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.
Characteristics are as follows:
On-demand self-service: a cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with the service's provider.
Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).
Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).
Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.
Service Models are as follows:
Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer 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 application hosting environment configurations.
Infrastructure as a Service (IaaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).
Deployment Models are as follows:
Private cloud: the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on-premises or off-premises.
Community cloud: the cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on-premises or off-premises.
Public cloud: the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.
Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for loadbalancing between clouds).
A cloud computing environment is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes.
Referring now to
Referring now to
Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61; RISC (Reduced Instruction Set Computer) architecture based servers 62; servers 63; blade servers 64; storage devices 65; and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.
Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.
In one example, management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing 82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources may comprise application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.
Workloads layer 90 provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from 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 table of contents pointer processing 96.
The present invention may be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is 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 of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device 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 device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language 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, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer 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, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in 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 therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
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 operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
In addition to the above, one or more aspects may be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of customer environments. For instance, the service provider can create, maintain, support, etc. computer code and/or a computer infrastructure that performs one or more aspects for one or more customers. In return, the service provider may receive payment from the customer under a subscription and/or fee agreement, as examples. Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.
In one aspect, an application may be deployed for performing one or more embodiments. As one example, the deploying of an application comprises providing computer infrastructure operable to perform one or more embodiments.
As a further aspect, a computing infrastructure may be deployed comprising integrating computer readable code into a computing system, in which the code in combination with the computing system is capable of performing one or more embodiments.
As yet a further aspect, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system comprises a computer readable medium, in which the computer medium comprises one or more embodiments. The code in combination with the computer system is capable of performing one or more embodiments.
Although various embodiments are described above, these are only examples. For example, computing environments of other architectures can be used to incorporate and use one or more embodiments. Further, different instructions or operations may be used. Additionally, different registers may be used and/or other types of indications (other than register numbers) may be specified. Many variations are possible.
Further, other types of computing environments can benefit and be used. As an example, a data processing system suitable for storing and/or executing program code is usable that includes at least two processors coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memory which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/Output or I/O devices (including, but not limited to, keyboards, displays, pointing devices, DASD, tape, CDs, DVDs, thumb drives and other memory media, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing 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.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising”, when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain various aspects and the practical application, and to enable others of ordinary skill in the art to understand various embodiments with various modifications as are suited to the particular use contemplated.
This application is a continuation of co-pending U.S. patent application Ser. No. 15/708,223, filed Sep. 19, 2017, entitled “PREDICTING A TABLE OF CONTENTS POINTER VALUE RESPONSIVE TO BRANCHING TO A SUBROUTINE,” which is hereby incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5241679 | Nakagawa et al. | Aug 1993 | A |
| 5313634 | Eickemeyer | May 1994 | A |
| 5459682 | Sato | Oct 1995 | A |
| 5526499 | Bernstein | Jun 1996 | A |
| 5581760 | Atkinson | Dec 1996 | A |
| 5590329 | Goodnow | Dec 1996 | A |
| 5604877 | Hoyt et al. | Feb 1997 | A |
| 5737590 | Hara | Apr 1998 | A |
| 5774722 | Gheith | Jun 1998 | A |
| 5797014 | Gheith | Aug 1998 | A |
| 5815700 | Poplingher et al. | Sep 1998 | A |
| 5815719 | Goebel | Sep 1998 | A |
| 5822787 | Zucker | Oct 1998 | A |
| 5835743 | Zucker | Nov 1998 | A |
| 5850543 | Shiell et al. | Dec 1998 | A |
| 5892936 | Tran et al. | Apr 1999 | A |
| 5896528 | Katsuno et al. | Apr 1999 | A |
| 5898864 | Golla et al. | Apr 1999 | A |
| 5898885 | Dickol et al. | Apr 1999 | A |
| 5923882 | Ho | Jul 1999 | A |
| 5961636 | Brooks | Oct 1999 | A |
| 5968169 | Pickett | Oct 1999 | A |
| 5991871 | Zucker | Nov 1999 | A |
| 6047362 | Zucker | Apr 2000 | A |
| 6157999 | Rossbach | Dec 2000 | A |
| 6195734 | Porterfield | Feb 2001 | B1 |
| 6308322 | Serocki et al. | Oct 2001 | B1 |
| 6314561 | Funk | Nov 2001 | B1 |
| 6393549 | Tran | May 2002 | B1 |
| 6401181 | Franaszek et al. | Jun 2002 | B1 |
| 6442707 | McGrath et al. | Aug 2002 | B1 |
| 6591359 | Hass | Jul 2003 | B1 |
| 6625660 | Guthrie et al. | Sep 2003 | B1 |
| 6691220 | Guthrie et al. | Feb 2004 | B1 |
| 6715064 | D'Sa et al. | Mar 2004 | B1 |
| 6766442 | Kahle et al. | Jul 2004 | B1 |
| 6772323 | Krishnan et al. | Aug 2004 | B2 |
| 6826747 | Augsburg et al. | Nov 2004 | B1 |
| 6845442 | Lepak et al. | Jan 2005 | B1 |
| 6880073 | Arimilli et al. | Apr 2005 | B2 |
| 6965983 | Lin | Nov 2005 | B2 |
| 6973563 | Sander | Dec 2005 | B1 |
| 7000094 | Nevill | Feb 2006 | B2 |
| 7017028 | Ben-David | Mar 2006 | B2 |
| 7024537 | Pickett et al. | Apr 2006 | B2 |
| 7028166 | Pickett | Apr 2006 | B2 |
| 7069415 | Chauvel | Jun 2006 | B2 |
| 7089400 | Pickett | Aug 2006 | B1 |
| 7263600 | Sander et al. | Aug 2007 | B2 |
| 7296136 | Collard | Nov 2007 | B1 |
| 7310799 | Eisenberg et al. | Dec 2007 | B2 |
| 7366887 | Waltermann et al. | Apr 2008 | B2 |
| 7464254 | Sharangpani | Dec 2008 | B2 |
| 7539695 | Nishiyama | May 2009 | B2 |
| 7571288 | Pudipeddi et al. | Aug 2009 | B2 |
| 7688686 | Polson et al. | Mar 2010 | B2 |
| 7802080 | Butcher | Sep 2010 | B2 |
| 7809933 | Levitan et al. | Oct 2010 | B2 |
| 7890941 | Garud | Feb 2011 | B1 |
| 8397014 | Khmelnitsky | Mar 2013 | B2 |
| 8601001 | Bremer et al. | Dec 2013 | B2 |
| 8607211 | Blainey et al. | Dec 2013 | B2 |
| 8639913 | Codrescu | Jan 2014 | B2 |
| 8769539 | Hopper et al. | Jul 2014 | B2 |
| 8930657 | Balasubramanian | Jan 2015 | B2 |
| 8997066 | Levanoni | Mar 2015 | B2 |
| 9021512 | Gschwind | Apr 2015 | B1 |
| 9075636 | Gschwind | Jul 2015 | B2 |
| 9110675 | Gschwind et al. | Aug 2015 | B1 |
| 9146715 | Gschwind | Sep 2015 | B1 |
| 9189234 | Inoue | Nov 2015 | B2 |
| 9218170 | Gschwind | Dec 2015 | B1 |
| 9244663 | Gschwind et al. | Jan 2016 | B1 |
| 9244854 | Gschwind | Jan 2016 | B2 |
| 9250875 | Gschwind et al. | Feb 2016 | B1 |
| 9250881 | Gschwind | Feb 2016 | B1 |
| 9298467 | Jackson | Mar 2016 | B2 |
| 9311093 | Gschwind et al. | Apr 2016 | B2 |
| 9329850 | Gschwind et al. | May 2016 | B2 |
| 9348616 | Gschwind et al. | May 2016 | B2 |
| 9367319 | Wang et al. | Jun 2016 | B2 |
| 9384130 | Gschwind et al. | Jul 2016 | B2 |
| 9424295 | Wright et al. | Aug 2016 | B2 |
| 9471514 | Badishi | Oct 2016 | B1 |
| 9513828 | Bertolli et al. | Dec 2016 | B2 |
| 9639913 | Satoh | May 2017 | B2 |
| 9760496 | Satoh | May 2017 | B2 |
| 9952844 | Gschwind | Apr 2018 | B1 |
| 9996294 | Koester et al. | Jun 2018 | B2 |
| 10209972 | Gschwind | Feb 2019 | B2 |
| 10620955 | Gschwind | Apr 2020 | B2 |
| 10656946 | Gschwind | May 2020 | B2 |
| 10691600 | Gschwind | Jun 2020 | B2 |
| 10705973 | Gschwind | Jul 2020 | B2 |
| 10713050 | Gschwind | Jul 2020 | B2 |
| 10713051 | Gschwind | Jul 2020 | B2 |
| 10725918 | Gschwind | Jul 2020 | B2 |
| 20020011943 | Deeley | Jan 2002 | A1 |
| 20020032718 | Yates | Mar 2002 | A1 |
| 20030028754 | Sugimoto | Feb 2003 | A1 |
| 20030041318 | Klarer | Feb 2003 | A1 |
| 20030172255 | Dundas | Sep 2003 | A1 |
| 20040173524 | Hoogerbrugge | Sep 2004 | A1 |
| 20040174803 | Carson | Sep 2004 | A1 |
| 20050132175 | Henry | Jun 2005 | A1 |
| 20060112374 | Oliva | May 2006 | A1 |
| 20060155703 | Dejean et al. | Jul 2006 | A1 |
| 20070067364 | Barbian | Mar 2007 | A1 |
| 20070088937 | Archambault et al. | Apr 2007 | A1 |
| 20070127321 | Verbakel et al. | Jun 2007 | A1 |
| 20070276794 | Nishiyama | Nov 2007 | A1 |
| 20080109614 | Begon et al. | May 2008 | A1 |
| 20080126770 | Morrow | May 2008 | A1 |
| 20080148033 | Sumner et al. | Jun 2008 | A1 |
| 20080229067 | Froemming | Sep 2008 | A1 |
| 20080244114 | Schluessler | Oct 2008 | A1 |
| 20080270736 | Nishida | Oct 2008 | A1 |
| 20080276069 | Blaner | Nov 2008 | A1 |
| 20080301420 | Inoue | Dec 2008 | A1 |
| 20090172814 | Khosravi | Jul 2009 | A1 |
| 20090210661 | Alexander | Aug 2009 | A1 |
| 20090271597 | Kuesel et al. | Oct 2009 | A1 |
| 20110196875 | Vadlamani et al. | Aug 2011 | A1 |
| 20110289303 | Silvera | Nov 2011 | A1 |
| 20120030660 | McGrath | Feb 2012 | A1 |
| 20120131309 | Johnson | May 2012 | A1 |
| 20120151182 | Madajczak | Jun 2012 | A1 |
| 20120297165 | Kruger | Nov 2012 | A1 |
| 20130212316 | Nassie | Aug 2013 | A1 |
| 20130262783 | Okada | Oct 2013 | A1 |
| 20130263153 | Gschwind | Oct 2013 | A1 |
| 20130275734 | Toll et al. | Oct 2013 | A1 |
| 20140047419 | Gaster | Feb 2014 | A1 |
| 20140095833 | Gschwind | Apr 2014 | A1 |
| 20150033214 | Qi et al. | Jan 2015 | A1 |
| 20150046691 | Heil et al. | Feb 2015 | A1 |
| 20150067300 | Inoue | Mar 2015 | A1 |
| 20150106588 | Godard | Apr 2015 | A1 |
| 20150205612 | Jackson | Jul 2015 | A1 |
| 20150261510 | Gschwind | Sep 2015 | A1 |
| 20150301841 | Mackintosh | Oct 2015 | A1 |
| 20150309812 | Gschwind et al. | Oct 2015 | A1 |
| 20150310644 | Zhou | Oct 2015 | A1 |
| 20160055003 | Clancy et al. | Feb 2016 | A1 |
| 20160062655 | Landau | Mar 2016 | A1 |
| 20160070548 | Gschwind et al. | Mar 2016 | A1 |
| 20160117155 | Salmon-Legagneur et al. | Apr 2016 | A1 |
| 20160117201 | Gschwind | Apr 2016 | A1 |
| 20160124733 | Gschwind | May 2016 | A1 |
| 20160124850 | Gschwind | May 2016 | A1 |
| 20160179546 | Yamada | Jun 2016 | A1 |
| 20160180079 | Sahita et al. | Jun 2016 | A1 |
| 20160202980 | Henry et al. | Jul 2016 | A1 |
| 20160263153 | O'Hara | Sep 2016 | A1 |
| 20170003941 | Gschwind | Jan 2017 | A1 |
| 20170031685 | Craske | Feb 2017 | A1 |
| 20170031783 | Kedem et al. | Feb 2017 | A1 |
| 20170147161 | White | May 2017 | A1 |
| 20170193401 | Grehant | Jul 2017 | A1 |
| 20170220353 | Jackson | Aug 2017 | A1 |
| 20170262387 | Sell | Sep 2017 | A1 |
| 20180113685 | Gschwind | Apr 2018 | A1 |
| 20180113688 | Gschwind | Apr 2018 | A1 |
| 20180113689 | Gschwind | Apr 2018 | A1 |
| 20180113692 | Gschwind | Apr 2018 | A1 |
| 20180113693 | Gschwind | Apr 2018 | A1 |
| 20180113697 | Gschwind | Apr 2018 | A1 |
| 20180113723 | Gschwind | Apr 2018 | A1 |
| 20180113725 | Gschwind | Apr 2018 | A1 |
| 20180113726 | Gschwind | Apr 2018 | A1 |
| 20180196746 | Craske | Jul 2018 | A1 |
| 20180219962 | Lahman | Aug 2018 | A1 |
| 20180225120 | Barnes | Aug 2018 | A1 |
| 20180246813 | Goldsack | Aug 2018 | A1 |
| 20190004980 | Maor | Jan 2019 | A1 |
| 20190087098 | Gschwind | Mar 2019 | A1 |
| 20190087099 | Gschwind | Mar 2019 | A1 |
| 20190087162 | Gschwind | Mar 2019 | A1 |
| 20190087163 | Gschwind | Mar 2019 | A1 |
| 20190087187 | Gschwind | Mar 2019 | A1 |
| 20190087189 | Gschwind | Mar 2019 | A1 |
| 20190087190 | Gschwind | Mar 2019 | A1 |
| 20190087191 | Gschwind | Mar 2019 | A1 |
| 20190087334 | Gschwind | Mar 2019 | A1 |
| 20190087335 | Gschwind | Mar 2019 | A1 |
| 20190087336 | Gschwind | Mar 2019 | A1 |
| 20190087337 | Gschwind | Mar 2019 | A1 |
| 20190087346 | Gschwind | Mar 2019 | A1 |
| 20190087347 | Gschwind | Mar 2019 | A1 |
| 20200042462 | Gschwind | Feb 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2510966 | Mar 2015 | GB |
| WO201524452 | Feb 2015 | WO |
| Entry |
|---|
| IBM, “z/Architecture—Principles of Operation,” IBM Publication No. SA22-7832-10, Eleventh Edition, Mar. 2015, pp. 1-1732. |
| IBM, “Power ISA—V2.07B,” Apr. 2015, pp. 1-1527. |
| Mel, Peter and Tim Grance, “The NIST Definition of Cloud Computing,” National Institute of Standards and Technology, Information Technology Laboratory, Special Publication 800-145, Sep. 2011, pp. 1-7. |
| “64-Bit ELF V2 ABI Specification: Power Architecture,” https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture, downloaded from internet Aug. 7, 2017, p. 1. |
| Kaiser, Scott et al., “A Method for Predicting Support Escalations with Machine Learning,” IP.com No. IPCOM000236818D, May 16, 2014, pp. 1-8 (+ cover). |
| Poblocki, Andrzej, “Predicting the Length of Translated Text Using Statistics,” IP.com No. IPCOM000230931D, Sep. 18, 2013, pp. 1-3 (+ cover). |
| Anonymous, “Storing Profiling Information for Use in Future Virtual Machine Invokations for Optimization Decisions,” IP.com No. IPCOM000216308D, Mar. 29, 2012, pp. 1-5 (+ cover). |
| Hu, Shiliang et al., “Using Dynamic Binary Translation to Fuse Dependent Instructions,” Proceedings of the International Symposium on Code Generation and Optimization, Sep. 2004, pp. 1-12. |
| Waterman, Andrew, “Design of the RISC-V Instruction Set Architecture,” Electrical Engineering and Computer Sciences—University of California at Berkeley, Technical Report No. UCB/EECS-2016-1, Jan. 2016, pp. 1-117. |
| IBM, “Configurable Microprocessor Branch Prediction for Performance and Power Savings,” IP.com No. IPCOM000028112D, Apr. 2004, pp. 1-4 (+ cover). |
| Das, Moumita et al., “Attacks on Branch Predictors: Am Empirical Exploration,” ICISS 2015, Dec. 2015, pp. 511-520. |
| Boogerd, Cathal et al., “On the Use of Data Flow Analysis in Static Profiling,” Eighth IEEE International Working Conference on Source Code Analysis and Manipulation, Jul. 2008, pp. 79-88. |
| Pophale, Swaroop et al., “Evaluating OpenMP Affinity on the POWER8 Architecture,” IWOMP 2016, Oct. 2016, pp. 35-46. |
| Sinharoy, B. et al., “IBM POWER8 Processor Core Microarchitecture,” IBM Journal of Research and Development, vol. 59, No. 1, Paper 3, Jan./Feb. 2015, pp. 2:1-2:21. |
| Abalenkovs, M. et al., “Parallel Programming Models for Dense Linear Algebra on Heterogeneous Systems,” Supercomputing Frontiers and Innovations, 2015, vol. 2, No. 4, Mar. 2015, pp. 67-86. |
| Anonymous, “Method and System for Improved Branch Predictions,” IP.com No. IPCOM000214467D, Jan. 2012, pp. 1-2 (+ cover). |
| Anonymous, “Address Mode Aware Branch Prediction with Shutdown Capability,” IP.com No. IPCOM000235852D, Mar. 2014, pp. 1-5. |
| Anonymous, “A Unified Scalar and SIMD Instruction Set Architecture: Repurposing a Scalar Instruction Set for SIMD Instruction via Mode-Sensitive Semantics,” IP.com No. IPCOM000241485D, May 5, 2015, pp. 1-3 (+ cover). |
| IBM, “A Technique for Adding Additional Registers to an Instruction Set Architecture,” IP.com No. IPCOM000188078D, Sep. 2009, pp. 1-5 (+ cover). |
| Collins, Jamison et al., “Pointer Cache Assisted Prefetching,” Nov. 2002, Proceedings of the 35th Annual International Symposium on Microarchitecture, pp. 1-12. |
| Gschwind, Michael et al., “Table of Contents Cache Entry Having a Pointer for a Range of Addresses,” U.S. Appl. No. 16/515,697, filed Jul. 18, 2019, pp. 1-91. |
| Gschwind, Michael et al., “Table of Contents Cache Entry Having a Pointer for a Range of Addresses,” U.S. Appl. No. 16/515,739, filed Jul. 18, 2019, pp. 1-88. |
| Gschwind, Michael K. et al., “Set Table of Contents (TOC) Register Instruction,” U.S. Appl. No. 16/542,830, filed Aug. 16, 2019, pp. 1-90. |
| List of IBM Patents and/or Patent Applications Treated as Related, dated Oct. 15, 2019, pp. 1-2. |
| Gschwind, Michael et al., “Initializing a Data Structure for Use in Predicting Table of Contents Pointer Values,” U.S. Appl. No. 16/599,355, filed Oct. 11, 2019, pp. 1-90. |
| List of IBM Patents and/or Patent Applications Treated as Related, dated Jan. 8, 2020, pp. 1-2. |
| Chen, S., “Defeating memory corruption attacks via pointer taintedness detection,” 2005 International Conference on Dependable Systems and Networks (DSN'05), Yokohama, Japan, Mar. 2005, pp. 378-387. |
| Tuck, B. et al., “Hardware and Binary Modification Support for Code Pointer Protection From Buffer Overflow,” 37th International Symposium on Microarchitecttire (MIOCRO-37'04, Portland, OR, USA, Jan. 2004, pp. 209-220. |
| Park, J., et al., “Data Reorganization and Prefetching of Pointer-Based Data Structures,” IEEE Design & Test of Computers, vol. 28, No. 4, Jul.-Aug. 2011, pp. 38-47. |
| Number | Date | Country | |
|---|---|---|---|
| 20200034147 A1 | Jan 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15708223 | Sep 2017 | US |
| Child | 16590439 | US |
