CN111066006B - Systems, methods and media for facilitating processing within a computing environment - Google Patents

Abstract

A table of contents (TOC) register instruction is set. Instructions are obtained and executed by a processor that provide pointers to reference data structures, such as TOCs. The executing includes determining a value of a pointer to the reference data structure and storing the value in a location (e.g., register) specified by the instruction.

Description

Systems, methods, and media for facilitating processing within a computing environment

Background Art

One or more aspects relate generally to processing within a computing environment, and more particularly to facilitating such processing.

Many computing systems use a global offset table (GOT) or table of contents (TOC) to populate variables within the source code. For example, a compiler generates object code from the source code without knowing the final address or displacement of the code/data. Specifically, the compiler generates object code that references a data structure (e.g., a global offset table or table of contents) for the variable address that accesses the variable value without knowing the final size of the data structure or the offsets/addresses of the various data sections. Placeholders for this information are left in the object code and updated by the linker.

To access the GOT or TOC, pointers are used. Pointers are usually calculated by a sequence of instructions. These instructions usually rely on calculated registers, which are not always easily available in the processor. Therefore, access to variables that depend on the TOC (i.e., variables other than local variables) is delayed.

Summary of the invention

The disadvantages of the prior art are overcome and additional advantages are provided by providing 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 example, an instruction to obtain, by a processor, a pointer to a reference data structure. The instruction is executed, and the execution includes: determining a value of the pointer to the reference data structure, and storing the value in a location specified by the instruction. Using instructions to provide a pointer value facilitates processing and improves performance by limiting delays that may occur waiting for a calculated register value.

In one embodiment, determining the value includes performing a search of a data structure to determine the value. As an example, the data structure includes a reference data structure pointer cache or a table filled with reference data structure pointer values. In addition, in one example, the location includes a register specified by the instruction.

In another embodiment, determining the value includes checking a reference data structure pointer cache for an entry that includes the value, and performing a store based on finding the entry. Additionally, a trap to a handler is triggered by the processor based on the value not being located in the reference data structure cache. The handler obtains the value from a data structure populated with the reference data structure pointer value, and performs a store. In one embodiment, the value is also stored in the reference data structure pointer cache.

In a further embodiment, cache miss processing is performed to determine the value and store the value based on the value not being located in the reference data structure pointer cache.

In yet another embodiment, a trap to a handler is caused by the processor based on obtaining the instruction, and the determination and the storing are performed by the handler.

Computer-implemented methods and systems related to one or more aspects are also described and claimed herein. Additionally, services related to one or more aspects are also described and 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.

BRIEF DESCRIPTION OF THE DRAWINGS

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 will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

FIG1A illustrates an example of a computing environment for incorporating and using one or more aspects of the present invention;

FIG. 1B illustrates further details of the processor of FIG. 1A according to one or more aspects of the present invention;

FIG1C illustrates further details of an example of an instruction execution pipeline used in accordance with one or more aspects of the present invention;

FIG. 1D illustrates further details of an example of the processor of FIG. 1A according to an aspect of the present invention;

FIG. 2 shows an example of a Set TOC Register (STR) instruction according to an aspect of the present invention;

FIG3 illustrates an example of processing associated with a Set TOC Register instruction according to an aspect of the present invention;

FIG. 4 illustrates another example of processing associated with a Set TOC Register instruction according to an aspect of the present invention;

FIG5 illustrates yet another example of processing associated with a Set TOC Register instruction according to an aspect of the present invention;

6A-6B illustrate an embodiment of verifying the setting of a TOC register (also referred to herein as a TOC pointer register) according to an aspect of the present invention;

7A-7B illustrate other embodiments of verifying TOC register settings according to various aspects of the present invention;

FIG8 illustrates one embodiment of determining a TOC pointer value (also referred to herein as a TOC value) according to one aspect of the present invention;

FIG. 9 illustrates an example of processing associated with responding to a subroutine branch prediction TOC value according to an aspect of the present invention;

FIG10 illustrates an example of TOC value check insertion logic according to an aspect of the present invention;

FIG. 11 illustrates another example of processing associated with responding to a subroutine branch prediction TOC value according to an aspect of the present invention;

FIG. 12 illustrates another example of TOC value check insertion logic according to an aspect of the present invention;

FIG. 13 illustrates another example of TOC value check insertion logic according to an aspect of the present invention;

FIG. 14A illustrates an example of a TOC pointer cache (also referred to herein as a TOC cache) in accordance with an aspect of the present invention;

FIG. 14B illustrates an example of a TOC cache insertion process according to an aspect of the present invention;

FIG. 15 illustrates an example of a TOC value assigned to a dynamic shared object according to an aspect of the present invention;

FIG. 16 illustrates another example of a TOC cache according to an aspect of the present invention;

FIG. 17 illustrates another example of a TOC cache insertion process according to an aspect of the present invention;

FIG. 18 illustrates an example of storing TOC values into a TOC tracking structure according to an aspect of the present invention;

FIG. 19 illustrates an example of a TOC referenced by a read-only TOC register according to an aspect of the present invention;

20A-20C illustrate examples of Load TOC-Relative Long instructions according to aspects of the present invention;

FIG. 21 shows an example of a Load Address TOC-Relative Long instruction according to an aspect of the present invention;

FIG. 22 illustrates an example of a TOC add immediate shift instruction according to an aspect of the present invention;

FIG. 23 illustrates an example of an add TOC immediate shifted instruction according to an aspect of the present invention;

FIG. 24 illustrates one embodiment of processing instructions that may include a TOC operand according to an aspect of the present invention;

25-27 illustrate embodiments of obtaining a TOC operand of an instruction according to aspects of the present invention;

FIG. 28 illustrates an example of a compile flow associated with using a Set TOC Register instruction according to an aspect of the present invention;

FIG. 29 illustrates an example of a static linker flow associated with using a Set TOC Register instruction according to an aspect of the present invention;

FIG30 illustrates an example of a compile flow associated with using a TOC read-only register according to an aspect of the present invention;

31A-31B illustrate one embodiment of facilitating processing within a computing environment according to one aspect of the present invention;

FIG32A illustrates another example of a computing environment incorporating and using one or more aspects of the present invention;

Fig. 32B shows further details of the memory of Fig. 32A;

FIG33 illustrates one embodiment of a cloud computing environment; and

FIG. 34 shows an example of abstract model layers.

DETAILED DESCRIPTION

According to one aspect of the present invention, a pointer to a reference data structure is provided, such as a table of contents (TOC) or a global offset table (GOT). In one example, a Set TOC Register (STR) instruction is provided, which loads a value (e.g., a pointer value) for accessing the TOC into a register (or other defined location). Although the TOC is used as an example here, the aspects, features, and techniques described herein are equally applicable to the GOT or other similar types of structures.

TOC pointer value, TOC pointer, TOC value, and pointer to TOC may be used interchangeably herein. The TOC register holds the TOC pointer and may therefore be referred to herein as the TOC pointer register or the TOC register.

In addition, 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. Similarly, reference data structure pointer cache and reference data structure cache are used interchangeably herein. Other examples may also exist.

On the other hand, the instruction sequence that is usually used to set the TOC register is replaced by the set TOC register instruction. As an example, the instruction sequence includes one or more instructions. In addition, the verification operation can be used to verify the TOC register value. The TOC register can be, for example, a hardware register or an architected register, such as a general register (e.g., r2, r12), which is defined by the architecture or specified by the application binary interface (ABI). Other examples are possible.

In yet another aspect, the TOC pointer value is predicted in response to a branch to a subroutine.

In yet another aspect, embodiments of a TOC cache are provided to facilitate processing. A TOC cache (or other reference data structure cache), for example, is a high-speed in-processor cache that includes various TOC pointer values predicted for different locations/modules in a recently used program.

In addition, an aspect is provided to prepare and initialize a TOC tracking structure for TOC pointer value prediction. The TOC tracking structure may be, for example, a TOC cache or an in-memory table populated with TOC pointer values to be predicted for different locations/modules in a program.

On the other hand, a pseudo-register (also referred to herein as a read-only TOC register) is used to provide a pointer value and a TOC register addressing mode. A pseudo-register is not a hardware or architected register, nor does it have storage associated with it; instead, it is a TOC pointer value obtained, for example, from a TOC cache (e.g., a value that has been generated by STR).

Additionally, in another aspect, code is generated and/or compiled using a set TOC register instruction and/or using a read-only TOC register.

Various aspects are described herein. In addition, many variations are possible without departing from the spirit of the various aspects of the present invention. It should be noted that, unless inconsistent, the various aspects and features described herein and variations thereof may be combined with any other aspects or features.

An embodiment of a computing environment 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 provided by International Business Machines Corporation of Armonk, New York. An embodiment of the z/Architecture is described in IBM Publication No. SA22-7832-10 (March 2015), "z/Architecture Principles of Operation," which is incorporated herein by reference in its entirety. Z/ARCHITECTURE is a registered trademark of International Business Machines Corporation of Armonk, New York, USA.

In another example, the computing environment is based on the Power Architecture provided by International Business Machines Corporation of Armonk, New York. One embodiment of the Power Architecture is described in "Power ISA ^TM Version 2.07B" by International Business Machines Corporation, April 9, 2015, which is incorporated herein by reference in its entirety. POWERARCHITECTURE is a registered trademark of International Business Machines Corporation of Armonk, New York, USA.

The computing environment may also be based on other architectures, including but not limited to the Intel x86 architecture. Other examples also exist.

1A , computing environment 100 includes, for example, computer system 102, which is shown in the form of a general-purpose computing device. Computer system 102 may include, but is not limited to, one or more processors or processing units 104 (e.g., central processing units (CPUs)) coupled to each other via one or more buses and/or other connections 110, memory 106 (referred to as primary storage or storage, for example), and one or more input/output (I/O) interfaces 108.

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, these architectures include Industry Standard Architecture (ISA), Micro Channel Architecture (MCA), Enhanced ISA (EISA), Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI).

The memory 106 may include, for example, a cache 120, such as a shared cache, which may be coupled to a local cache 122 of the processor 104. In addition, the memory 106 may include one or more programs or applications 130, an operating system 132, and one or more computer-readable program instructions 134. The computer-readable program instructions 134 may be configured to perform the functions of embodiments of aspects of the present invention.

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 via, for example, the I/O interface 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 wide area network (WAN), and/or a public network (e.g., the Internet), thereby providing communications with other computing devices or systems.

The 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 perform the functions of embodiments of aspects of the present invention.

The 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 (commonly referred to as a "hard drive"), a disk drive for reading from and writing to a removable, non-volatile disk (e.g., a "floppy disk"), and/or an optical drive for reading from and 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 may be used in conjunction with the 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, among others.

The 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 suitable for use with the computer system 102 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, fat 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 including any of the above systems or devices, etc.

See FIG. 1B for further details of an example of a processor 104. The processor 104 includes a plurality of functional components for executing instructions. These functional components include, for example, an instruction fetch component 150 for fetching instructions to be executed, an instruction decode unit 152 for decoding the fetched instructions and obtaining operands of the decoded instructions, an instruction execution component 154 for executing the decoded instructions, a memory access component 156 for accessing memory for executing instructions as needed, and a write-back component 160 for providing the results of the executed instructions. According to one aspect of the present invention, one or more of these components may be used to execute one or more instructions and/or operations associated with a table of contents (TOC) pointer processing 166.

In one embodiment, the processor 104 also includes one or more registers 168 for use by one or more functional components. The processor 104 may include more, fewer, and/or other components than the examples provided herein.

Further details regarding the execution pipeline of processor 104 will be described with reference to Figure 1C. Although various processing stages of the pipeline are depicted and described herein, it should be understood that additional, fewer and/or other stages may be used without departing from the spirit of aspects of the present invention.

Referring to FIG. 1C , in one embodiment, an instruction is extracted 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 an instruction group 176 to be processed together. The grouped instructions are provided to a mapper 178, which determines any dependencies, assigns resources, and dispatches the instruction/operation group to the appropriate issue queue. There are one or more issue queues for different types of execution units, including, for example, branch, load/store, floating point, fixed point, vector, etc. During the issue stage 180, the instruction/operation is issued to the appropriate execution unit. Any register is read 182 to retrieve its source, and the instruction/operation is executed during the execution stage 184. As noted, as an example, execution may be for a branch, load (LD) or store (ST), fixed point operation (FX), floating point operation (FP), or vector operation (VX). During the write-back stage 186, any results are written to the appropriate register. Subsequently, the instruction is completed 188. If there is an interrupt or flush 190, processing may return to instruction fetch 170.

Additionally, in one example, coupled to the decode unit is a register renaming unit 192, which may be used to save/restore registers.

Additional details about the processor are described with reference to FIG. 1D. In one example, a processor such as processor 104 is a pipeline processor that may include, for example, prediction hardware, registers, caches, decoders, an instruction sequencing unit, and an instruction execution unit. 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 through an instruction fetch address register (IFAR) 107, which has the address of the next instruction to fetch.

The same address is also provided to instruction cache 109, which can fetch multiple instructions referred to as a “fetch group.” Associated with instruction cache 109 is directory 111.

The cache and prediction hardware are accessed at approximately the same time and at the same address. If the prediction hardware has prediction information available for the instruction in the fetch group, the prediction is forwarded to the instruction sequencing unit (ISU) 113, which then issues the instruction to the execution unit for execution. The prediction can be used to update the IFAR 107 in conjunction with the branch target calculation 115 and the branch target prediction hardware (e.g., link register prediction stack 117a and 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 the fetch group. The predicted branch is stored in the prediction hardware, such as in the branch information queue (BIQ) 125, and forwarded to the ISU 113.

A branch execution unit (BRU) 121 operates in response to instructions issued thereto by the ISU 113. The BRU 121 has read access to a condition register (CR) file 123. The branch execution unit 121 further accesses information stored by the branch scan logic in a branch information queue 125 to determine the success of a branch prediction, and is operably coupled to an instruction fetch address register (IFAR) 107 corresponding to one or more threads supported by the microprocessor. In accordance with at least one embodiment, a BIQ entry is associated with and identified by an identifier, such as a branch tag BTAG. When a branch associated with a BIQ entry is completed, it is marked as such. The BIQ entries are maintained in a queue, and the oldest queue entries are sequentially de-allocated when the oldest queue entry is marked as containing information associated with a completed branch. The BRU 121 is also operably connected to cause a predictor update when the BRU 121 discovers a branch misprediction.

When executing an instruction, BRU 121 detects whether the prediction is wrong. If so, the prediction is updated. For this purpose, the processor also includes predictor update logic 127. Predictor update logic 127 responds to the update indication from branch execution unit 121 and is configured to update the array entry in one or more of local BHT 105a, global BHT 105b and global selector 105c. Predictor hardware 105a, 105b and 105c may have a write port different from the read port used by instruction fetch and prediction operations, or may share a single read/write port. Predictor update logic 127 may further be operatively coupled to link stack 117a and count register stack 117b.

Referring now to the condition register file (CRF) 123, the CRF 123 is read accessible by the BRU 121 and can be written by execution units, including but not limited to the fixed point unit (FXU) 141, the floating point unit (FPU) 143, and the vector multimedia extension unit (VMXU) 145. The condition register logic execution unit (CRL Execution) 147 (also referred to as the CRU) and the special purpose register (SPR) processing logic 149 have read and write access to the condition register file (CRF) 123. The CRU 147 performs logic operations on the condition registers stored in the CRF file 123. The FXU 141 is capable of performing write updates to the CRF 123.

Processor 104 also includes a load/store unit 151, various multiplexers 153 and buffers 155, and an address translation table 157 and other circuits.

Processor 104 executes a program (also referred to as an application) that includes variables. A variable has an identifier (e.g., a name) and refers to a storage location that includes a value (e.g., information, data). During runtime, the program determines the address of a variable that was not known at compile time by using the TOC.

When a subroutine is called, it builds 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 has to be built. Building such a pointer is expensive.

An example of code for establishing a TOC pointer is shown below, for example with reference to an example ABI, such as the OPENPOWER ELFv2 ABI.

According to one such example embodiment, the caller initializes one or more registers with the address of the called function, such as according to the ABI.

In the following example, two registers, r12 and ctr, are initialized with the address of the called function:

According to the established ABI, the called function initializes the TOC pointer. Various implementations exist. In one embodiment, when an address function is called via a register indirect call, an entry address from one or more registers initialized by the caller is used. For example, according to an example ABI, such as the OPEN POWER ELFv2 ABI, the TOC pointer register r2 may be initialized using the callee's function entry address loaded into r12 by the caller via a function called "foo" as follows:

According to one aspect of the invention, rather than using, for example, the above code to determine the TOC pointer, which is expensive in many microprocessor implementations, a Set TOC Register (STR) instruction is used. The Set TOC Register instruction loads the value of a pointer to the TOC into a register (or other defined location), for example, by performing a lookup in the processor. Since the TOC is shared by all (or a group of) functions of a module, only a small number of TOC register values are to be remembered and associated with an address range. As an example, the Set TOC Register instruction can be implemented as an architected hardware instruction or an internal operation.

An example of a Set TOC Register (STR) instruction is described with reference to Figure 2. In one example, a Set TOC Register instruction 200 includes an operation code (opcode) field 202 containing an operation code indicating a Set TOC Register operation and a Target Register (RT) field 204 specifying a location, such as a register, to receive the value of the TOC pointer.

Although one opcode field is shown in this example, in other embodiments, multiple opcode fields may be present. Other variations are also possible.

As indicated, in one example, target register field 204 identifies the register into which the TOC pointer value is to be loaded. The STR instruction loads the TOC pointer value for the current code sequence into the register specified by field 204, where the code sequence corresponds to the code following the STR instruction address.

There are multiple possible implementations of the processing associated with the STR instruction, including, for example, software implementation, hardware-assisted implementation, and hardware implementation. In the software implementation, based on the execution of the STR instruction, an exception is raised, and the setting of the TOC register is simulated by the management program code (e.g., an operating system or system management program) or by a user mode interrupt handler (e.g., using an event-based branch facility as defined in the Power architecture). In the hardware-assisted implementation, the hardware provides a cache (e.g., a small table or other data structure for storing the most frequently used values) or a predictor for frequent values, and captures it to the software. The management program 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, a lookup table (or other data structure that has been filled with the TOC pointer value in the software) is searched. Further details about the implementation options will be described with reference to Figures 3-5.

One implementation using software (e.g., hypervisor code or a user mode interrupt handler) is described with reference to FIG3 . Referring to FIG3 , in one example, a STR instruction is received by a processor, step 300, and a trap is triggered to a handler routine, such as a hypervisor (e.g., an operating system (OS) or a hypervisor (HV)) or user mode interrupt code, step 310. The handler routine is entered, step 320, and the handler looks up a TOC pointer value for a function corresponding to the address of the STR instruction, such as in a cache or table, step 330. The obtained TOC value is loaded into a target register of the STR instruction, step 340. Thereafter, processing returns to the code following the STR instruction to continue execution using the obtained TOC value, step 350.

Another implementation is described with reference to FIG4 , in which a hardware assisted implementation is described. Referring to FIG4 , a STR instruction is received by a processor, step 400, and a TOC cache lookup is performed to locate a TOC value for the function that includes the STR instruction, step 402. A determination is made as to whether a TOC cache entry for the function is found, query 404. If a TOC cache entry is found, the result from the TOC cache lookup is loaded into the STR target register, step 406. Otherwise, a trap to a handler routine is triggered, step 408, as described above. For example, the handler routine is entered, step 410, and a lookup is performed, such as a lookup in a table for the TOC value of the function that corresponds to the address of the STR instruction, step 412. The TOC value is loaded into the TOC cache, step 414, and the obtained TOC value is loaded into the target register of the STR instruction, step 416. Processing then returns to the instruction following the STR instruction to continue execution using the obtained TOC value, step 418.

Another implementation is described with reference to FIG5 , in which hardware performs the processing. Referring to FIG5 , a STR instruction is received, step 500, and a TOC cache lookup is performed to locate a TOC value for the function that includes the STR instruction, step 502. A determination is made as to whether a TOC cache entry for the function is found, query 504. If a TOC cache entry is found, the result from the TOC cache lookup is loaded into the STR target register, step 506. However, if a TOC cache entry is not found, TOC cache miss handling logic is executed, step 510. This includes, for example, determining a lookup table start, step 512, and looking up a TOC value for the function corresponding to the address of the STR in one or more tables or other data structures, step 514. The found TOC value (e.g., address) is loaded into the TOC cache, step 516, and the obtained TOC value is loaded into the target register of the STR, step 518.

In one or more of the above examples, the TOC cache can be implemented in a variety of ways. For example, it can include a pair (STR address, return value) that associates the address of each STR instruction with the value to be returned, or, because adjacent functions often share a TOC, it can include a range of addresses of STR instructions to return a specified value, such as storing a triple (from_range, to_range, return value) in a table. Further details about the TOC cache are described below.

Although in the above embodiment, STR is used to load a TOC value, STR can also be used to load other values, such as a magic number (e.g., an identifier in the Executable and Linkable Format (ELF)) or other values, such as a value that can be associated with a code region, a specific module, or a specific instruction address of a STR instruction. There are many possibilities.

On the other hand, the code is scanned to find the instruction sequence that sets the TOC register value, and replaces those instruction sequences with the TOC register instruction that sets. On the other hand, a verification instruction is provided to verify the prediction of the value of the TOC register. As an example, the instruction sequence includes one or more instructions.

According to conventional code generation techniques, the TOC value is usually calculated using an instruction sequence, or loaded from a stack.

For example, the TOC value may be calculated using a sequence such as:

In another example, the TOC value is loaded (ld) from memory (e.g. the stack):

ld r2,sp,<stackoffset for //sp is stack pointer (sp is stack

TOC> Stack Pointer)

These sequences typically involve interlocks (e.g., needing to wait for a previous storage instruction for storing a TOC value to complete) before they can complete. This type of interlock typically results in reduced performance. Therefore, according to one aspect of the present invention, a processor instruction decoding unit identifies a TOC setting instruction and/or a TOC setting instruction sequence and replaces them with a STR instruction. Optionally, a verification instruction is also provided. As used herein, a TOC setting instruction and/or a TOC setting instruction sequence includes one or more instructions for setting a TOC register or calculating a TOC pointer value.

For example, in one embodiment, the following instruction sequence is recognized by a processor (e.g., an instruction decode unit of the processor):

addis r2,r12,offset@h

addi r2,r2,offset@I

and the sequence is replaced by the following operation to load the (predicted) TOC value and verify the prediction by comparing it to the sum of register r12 and the offset used in the original code to calculate r2:

STR r2

verify r2,r12,offset

In a further example:

ld r2,sp,<stackoffset for TOC>

is replaced by:

STR r2

load-verify r2,sp,<stackoffset>

Examples of STR instructions are described above, and further details regarding the use of verification operations are described below. For example, further details associated with using STR to verify internal operations (iops), such as verify rx, ry, offset, are described with reference to FIG. 6A.

Referring to FIG6A , a verification technique performed by, for example, a processor is described. Initially, a verification internal operation (e.g., an internal operation verify rx, ry, offset, having two example register operands and one immediate operand—such as the example verify r2, r12, offset in the example code above) is received, step 600. A variable a is calculated by adding the offset of the verification operation to the value of the base register ry (e.g., r12) of the verification internal operation, step 602. A determination is made as to whether the value in the target register rx (e.g., r2) of the verification internal operation is equal to the calculated value a, query 604. If the value of rx is equal to the calculated value a, then verification is complete, step 606, and is successful.

However, if the value of rx is not equal to a, then a is assigned to the target register rx, step 608, and recovery is initiated, step 610. Recovery includes, for example, flushing the incorrect use of rx from the instruction pipeline after the current instruction, or flushing all instructions in the pipeline after the current instruction. Other variations are also possible.

In another embodiment, as shown in Figure 6B, the calculated value (e.g., TOC pointer; also known as TOC pointer address) is loaded into the TOC cache, step 620.

Other examples of verification techniques, such as those performed by a processor, are described with reference to Figures 7A-7B. With reference to Figure 7A, in one example, a load verification internal operation is received, step 700. The value of variable a is calculated. For example, the value at memory address ry (i.e., at the stack pointer) plus the offset is assigned to variable a, step 702. Determine whether the value of base register rx (e.g., r2) is equal to a, query 704. If the value in rx is equal to the calculated value a, then the verification is complete and successful, step 706. However, if the calculated value a is not equal to the value in rx, a is assigned to rx, step 708. In addition, recovery is initiated, step 710. Recovery includes, for example, cleaning incorrect uses of rx or cleaning all instructions in the pipeline after the current instruction. Other variations are possible.

In another embodiment, referring to FIG. 7B , the calculated value (eg, a TOC pointer or address) is loaded into the TOC cache, step 720 .

In another embodiment, different execution paths may be taken depending on whether the TOC value is in the TOC cache. An example of this process is performed by, for example, a processor and described with reference to FIG8 . Initially, it is determined whether there is an opportunity to replace the instruction sequence used to determine the TOC value (e.g., an opportunity to fuse multiple instructions into an iop sequence), query 800. That is, is there an opportunity to replace the instruction sequence with STR and optionally with verification or to perform some other instruction replacement? If not, conventional processing is performed to determine the TOC value (e.g., using the instruction sequence addis/addi or a load instruction), step 802. However, if there is a TOC value replacement opportunity, a lookup is performed in the TOC cache to determine whether there is a value for the routine including STR, step 804. If there is a TOC cache hit, the target register of STR is updated with the TOC value, step 808. In addition, in one example, verification is performed, step 810. However, returning to query 806, if there is no TOC cache hit, the TOC value is generated by, for example, a calculation instruction sequence (e.g., addis, addi) or a load instruction, step 812. The calculated value is loaded into the TOC cache, step 814 , and the target register is updated, step 816 .

Other implementations and variations are possible.

In another aspect, a TOC value is predicted based on entry to a subroutine. For example, when a subroutine call is executed, the TOC value is predicted rather than waiting to find an instruction sequence that is believed to calculate the TOC value. Instead, the TOC value is predicted upon entry to the subroutine, and then when an instruction sequence in the called routine that calculates the TOC value is encountered, it is replaced with a TOC check instruction (i.e., an instruction that checks or verifies the predicted TOC value). If the TOC check instruction fails, or a TOC value is accessed and the prediction is not checked, recovery can be performed.

As an example, the processor predicts the value of the TOC register (e.g., r2) of the subroutine based on the previously observed address. As an example, the predicted TOC value is input into the target address register array together with the predicted target address, or into a separate TOC prediction array.

In certain embodiments, the TOC value may be predicted using, for example, hardware-assisted techniques described with reference to FIG. 4 and/or hardware techniques described with reference to FIG. 5. In another embodiment, the TOC value is obtained by calculating the TOC value using a sequence of instructions in legacy code and initializing a TOC cache. Other possibilities exist as well.

An embodiment of predicting a TOC value based on a subroutine branch is described with reference to FIG. 9 . The process is performed, for example, by a processor. Referring to FIG. 9 , first, determine whether a subroutine call is a candidate for predicting a TOC value, query 900. For example, is the subroutine call a register indirect branch (where the location of the address of the next instruction to be executed is specified in the branch instruction, rather than the address itself)? In other embodiments, branches other than local module functions are considered candidates, or filters or other mechanisms may be provided to determine candidates. If not, conventional processing is performed, step 902. However, if a subroutine call is a candidate for predicting a TOC value, the subroutine call is executed, step 904. In addition to the TOC value, the call may also be combined with predictions of other types of values. In addition, the old TOC value is, for example, saved in a restore location, such as register TOCRECOVER, step 906. In addition, a TOC value is predicted, step 908. As described herein, various techniques may be used to predict a TOC value. Then, the predicted TOC value is loaded into a TOC pointer register (e.g., r2), step 910. As an example, the identification of the TOC register may be hard-coded, or may be configurable. In addition, in one example, a flag or other indicator maintained in the selected location is set (e.g., set to 1) to indicate that a TOC check (e.g., a check of the TOC value) will be performed before the TOC value is used, step 912.

Further details about the TOC check, and in particular the insertion logic for the TOC check, are described with reference to FIG. 10 . In one example, the logic is integrated into a decoding unit. Initially, an instruction is obtained and decoded, step 1000. A determination is made as to whether the TOC check flag is set, query 1002. If not set, the process is complete. However, if the TOC check flag is set (e.g., set to 1), a further determination is made as to whether the current instruction corresponds to a TOC setting instruction (e.g., a sequence of one or more instructions for setting (e.g., loading, storing, providing, inserting, placing) a TOC value in, for example, a TOC register; e.g., a load instruction; or a sequence of instructions for calculating a TOC value), query 1004. If the current instruction corresponds to a TOC setting instruction, a TOC check is inserted into the code, step 1006. For example, an STR verify or STR load verify instruction replaces one or more instructions in the code for calculating a TOC value. For example, based on the example shown above, the parameters of the verification instruction are derived, for example, from the calculation sequence being replaced. Thus, a sequence of instructions based on calculation instructions can be replaced with a verification instruction that calculates an address similar to the calculation instruction(s), e.g., replacing one or more addition instructions with a verification using a corresponding addition calculation instruction; and a load instruction can be replaced with a load-verify instruction that obtains a value to be compared with from the same location from which the replaced load instruction would load the TOC register. Additionally, the TOC check flag is turned off (e.g., set to 0), step 1008.

Returning to inquiry 1004, if the current instruction does not correspond to a TOC setting instruction, it is further determined whether the current instruction corresponds to a TOC use instruction (i.e., one or more instructions that use a TOC value or a TOC register), inquiry 1010. If not, the process is complete. Otherwise, recovery can be performed, step 1012. In one embodiment, this can be achieved by copying the value in TOCRECOVER back into a TOC register (e.g., r2). In another embodiment, register renaming can 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 TOC values based on subroutine branches is described with reference to FIG. 11 . The process is performed, for example, by a processor. Referring to FIG. 11 , first, determine whether a subroutine call is a candidate for predicting a TOC value, query 1100. In one embodiment, register indirect branches are predicted. In other embodiments, module local functions are excluded, and/or filters may further suppress candidate states based on the called address or the caller address, callee address pair. Other possibilities exist. If the subroutine call is not a candidate, then perform conventional processing, step 1102.

Returning to inquiry 1100, if the subroutine call is a candidate for predicting a TOC value, the subroutine call is made, step 1104. Optionally, in addition to the TOC value, other ancillary values may be predicted. Additionally, the old TOC value is saved, for example, in a restore 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 is a TOC cache hit, inquiry 1110. If there is a TOC cache hit, the obtained TOC value is loaded into a TOC pointer register (e.g., r2), step 1112. Additionally, a TOC check flag is set (e.g., to 1), indicating that a TOC value check is to be performed before using the predicted TOC value, and in one embodiment, a TOC capture flag at a selected location is turned off (e.g., to 0), step 1114. Returning to inquiry 1110, if there is a TOC cache miss, the TOC capture flag is set to indicate that a TOC capture is to be performed (eg, set to 1) to obtain a TOC value, and the TOC check flag is turned off (eg, set to 0), step 1116. Other variations are possible.

Details of the check insertion logic for the embodiment of Figure 11 are described with reference to Figure 12. In one embodiment, the logic is integrated into a decoding unit. Initially, an instruction is obtained and decoded, step 1200. Determine whether the current instruction corresponds to a TOC setup instruction, query 1202. If it does not correspond to a TOC setup instruction, determine whether the current instruction corresponds to a TOC use instruction, query 1204. If not, processing is complete. Otherwise, further determine whether the TOC check flag is set, query 1206. If not, processing is completed again. Otherwise, recovery can be performed, step 1208. In one embodiment, recovery includes copying the value in the TOCRECOVER register back into a TOC register (e.g., r2), or using a rename register, as described above. Other variations are possible.

Returning to query 1202, if the current instruction corresponds to a TOC set instruction, a check is inserted into the code, step 1210. For example, an STR verification or an STR load verification is inserted. Then, the TOC check flag is turned off (e.g., set to 0), step 1212.

Another embodiment of TOC check insertion logic is described with reference to FIG. 13 . In one example, the logic is integrated into a decoding unit. Referring to FIG. 13 , an instruction is obtained and decoded, step 1300. Determine whether the current instruction corresponds to a TOC setting instruction, query 1302. If the current instruction does not correspond to a TOC setting instruction, further determine whether the current instruction corresponds to a TOC use instruction, query 1304. If not, processing ends. Otherwise, determine whether the TOC capture flag is set, query 1306. If not, processing is complete. Otherwise, turn off the TOC capture flag (e.g., set to 0), step 1308. In one embodiment, it may be recorded that the function did not load a new TOC value in the TOC cache, or indicate a filter (e.g., a Bloom filter) to suppress TOC predictions for the TOC cache. Other variations are also possible.

Returning to query 1302, if the current instruction does not correspond to a TOC setting instruction, a check is inserted, which in one example includes a verification instruction that triggers a recovery action, 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.

Now, more details about the TOC cache are described with reference to FIG. 14A. In one example, the TOC cache 1400 includes a plurality of columns, including, for example, a TOC setter address column 1402, a TOC value column 1404 including the TOC value of the module of the entry, an optional function initialization TOC column 1406, and an optional use tracking column 1408. The TOC setter address column 1402 includes a TOC setter address, such as the address of an STR, a function start, or a plurality of other values based on a particular use case. In one or more embodiments, a set association table accessed by the TOC setter address is provided. The function initialization TOC column 1406 can be used to capture functions that do not initialize the TOC register. In another embodiment, it is too expensive to use table entries, and a filtering mechanism, such as a Bloom filter or other filtering mechanism, can be used to identify functions whose TOC values should not be predicted. Use tracking provides a way to select an entry to be removed when the table is full and to use another entry. Various tracking schemes can be used, including, for example, the least recently used, the least frequently used, FIFO (first in, first out), the number of times used per time period, etc. In at least one embodiment, column 1408 is adapted to store usage information commensurate with storing appropriate information for an implemented replacement strategy.

One embodiment of inserting an entry into the TOC cache is described with reference to FIG. 14B . Initially, a value pair (e.g., callee, TOC value) to be entered into the TOC cache is received, step 1450. An entry in the cache is selected to store the value pair, step 1452. As an example, an index bit may be used to select the entry, or usage tracking information may be used. Optionally, in one embodiment, if an entry is to be evicted, the evicted entry is saved, for example, to a secondary TOC cache, step 1454. The obtained value pair is stored in the selected entry, step 1456. Other variations are possible.

In one embodiment, a single TOC pointer value corresponds to the entire module, i.e., all functions in the module have the same TOC pointer value. Therefore, according to one aspect of the present invention, the processor stores TOC values for a certain range of addresses in the TOC cache. As an example, the address range corresponding to the same TOC pointer value is dynamically determined, for example, by coalescing a newly discovered TOC value with a pre-existing range. In another embodiment, the size of the range is provided by a dynamic loader, and the predicted TOC value is associated with the value of the range. Other examples are also possible.

As another example, the TOC may cover a portion of a module, and the address range would be that of that portion.Other variations exist as well.

As described above, a TOC cache may be used, but in this regard, the TOC cache has a different format than in Figure 14A and therefore has different management. This enables a more compact and efficient representation of the TOC cache, which exploits the TOC value attribute.

As shown in Figure 15, in one example, application 1500 may include multiple modules, including main program 1502 and one or more dynamic shared objects (DSO) 1504, such as shared libraries. Each module is associated with a TOC value 1506, which corresponds to the code in the address range of the module loaded by the dynamic loader, for example. Since each module may have its own TOC value associated with it, a TOC cache can be implemented to indicate this. For example, as shown in Figure 16, TOC cache 1600 includes, for example, a TOC range address_from column 1602 and a TOC range address_to column 1604. TOC range address_from column 1602 shows the beginning of a specific module of the TOC value, and TOC range address_to column 1604 shows the end of the specific module of the TOC value. For this module, the TOC value is included in the TOC value column 1606. In addition, the TOC cache may include a usage tracking column 1608. Other and/or different columns are also possible.

Reference Figure 17 describes an embodiment of inserting an entry in such a TOC cache. The logic is executed, for example, by a processor. A value pair (e.g., callee, TOC value) to be inserted into the cache is received, step 1700. An attempt is made to select an entry for storing the TOC value based on the indicated TOC value, step 1702. Determine whether an entry for the TOC value is found in the TOC cache, query 1704. If no entry is found, an entry within the TOC cache is selected for storing the TOC value, step 1706. The entry can be an empty entry, or it can be an entry with other information. If there is already a value in the entry to be used, the information can be saved, for example, in a secondary TOC cache, step 1708. The received value is then stored in the selected entry, step 1710. In addition, the address_from and address_to columns are set to the callee address.

Returning to inquiry 1704, if an entry is found, determine 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, update the address_from column of the selected entry to the callee address, step 1722. Otherwise, update the address_to column of the selected entry to the callee address, step 1724.

The above flow assumes that there is one entry per TOC value, so that multiple entries are not found. However, if multiple entries can be found for a particular module, they will be checked.

In another embodiment, candidate selection for TOC prediction may use a TOC table with a scope to determine whether to perform a call to the same module to suppress TOC prediction. Other variations are possible.

On the other hand, a TOC tracking structure is prepared and initialized for TOC prediction. As an example, a linker links programs, and the linker determines a TOC value, which is an absolute value of a module or a relative offset, for example, relative to a module load address. A dynamic loader loads the module and calculates a final TOC value. The dynamic loader then loads the TOC value into the TOC tracking structure for use in conjunction with, for example, a set TOC register instruction or another prediction instruction.

As an example, the TOC tracking structure can be the TOC cache itself, or it can be a representation of an in-memory table. Other examples are possible. In addition, details associated with storing TOC values into the tracking structure are described with reference to FIG. 18. This process is performed, for example, by a loader.

18 , the loader receives a request to load a module, step 1800, and computes at least one TOC pointer for the loaded module, step 1802. The TOC value is stored in a TOC tracking structure, e.g., along with the address range into which the module has been loaded, step 1804. The stored value may then be returned for a particular function, or stored in a TOC cache for later retrieval, etc.

In one embodiment, when the tracking structure is, for example, an in-memory structure, and the TOC value is not found in the TOC cache, control is transferred to software using, for example, an interrupt or a branch based on a user mode event. The software handler then reloads the value, for example, by accessing an in-memory structure that stores the address range and TOC value corresponding to each module. In another embodiment, the in-memory TOC structure is architecturally defined, and the hardware handler reloads the TOC cache directly from the in-memory structure. In one embodiment, the software handler reloads the TOC cache and the in-memory structure when the module is loaded. Other variations are possible.

According to another aspect of the present invention, a read-only TOC register and a TOC addressing mode are included in an instruction set architecture (ISA). The read-only TOC register is, for example, a pseudo or virtual register that provides a TOC value for a given module (e.g., by accessing a TOC cache or a table in memory). That is, it is not a hardware or architected register and does not have a storage device to back it up, but provides a TOC value to be used, for example, when referencing a selected register number. The TOC value is initialized, for example, from a value stored in a TOC base table, which can be loaded in conjunction with module initialization. The TOC base table can correspond to one or more of the TOC cache or memory structures of Figures 14 and 16. In conjunction with one or more aspects of the present invention, other formats can also be used to store and provide a TOC base value at a given instruction address.

An example of using a read-only TOC register is described with reference to FIG. 19 . As shown, a read-only TOC register 1900 (referred to herein as TOCbase) is a pointer to a location in a TOC 1902. The TOC 1902 includes one or more variable addresses 1904 indicating the location of a corresponding variable that holds a variable value 1906. The read-only TOC register TOCbase is referenced by the addressing mode, either implicitly in the instruction or as a prefix. The processor performs a TOC value lookup in response to TOCbase being designated as an addressing mode or register of an addressing mode, and the TOC value obtained is used to replace the value provided by the general register designated as the base register.

In one embodiment, when n bits are provided to encode ²ⁿ registers in an instruction set, one of the ²ⁿ register numbers is defined as a value that references a TOC pointer, and when the register is specified, the value of the TOC pointer is used as the value of the register.

In another aspect, various instructions that can use read-only registers are provided. For example, various load TOC relatively long instructions are provided, as described with reference to Figures 20A-20C, and one or more load address TOC relatively long instructions can be provided, an example of which is described with reference to Figure 21. Other examples are also possible.

As shown in Figure 20A, the load TOC relatively long instruction 2000 includes: multiple operation code (opcode) fields 2002a, 2002b, which include an operation code specifying a load TOC relatively long (LTL) operation; a first operand field ( _R1 ) 2004, which is used to indicate the location of the first operand (e.g., a register); and a second operand field ( _RI2 ) 2008, which is an immediate field, whose content is used as a signed binary integer specifying one of the bytes, half-words, words, double words, etc., which are added to the value of the TOC pointer at the current instruction address to form the address of the second operand in the memory (the TOC is defined by an external device - for example, using a program loader, a STR instruction, a TOC table, a TOC cache, etc.).

Other embodiments of the load TOC relatively long instruction are also provided, as shown in Figures 20B-20C. Each load TOC relatively long instruction (LGTL) 2010 (Figure 20B) and LGFTL 2020 (Figure 20C) includes an opcode field 2012a, 2012b; 2022a, 2022b; a first operand field ( _R1 ) 2014, 2024, which is used to indicate the location of the first operand (e.g., a register); and a second operand field ( _R2 ) 2018, 2028, which is an immediate field, the content of which is used as a signed binary integer specifying one of the bytes, halfwords, words, doublewords, etc., which are added to the value of the TOC pointer at the current instruction address to form the address of the second operand in memory (the TOC is defined by external means - for example, using a program loader, STR instruction, TOC table, TOC cache, etc.).

The second operand is placed in the first operand position unchanged, except that for load TOC relative long (LGFTL), it is sign extended.

For load TOC relatively long (LTL), the operand is, for example, 32 bits, while for load TOC relatively long (LGTL), the operand is 64 bits. For load TOC relatively long (LGFTL), the second operand is treated as a 32-bit signed binary integer, while 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 shall be aligned on a word boundary, and for load TOC relative long (LGTL), the second operand shall be aligned on a doubleword boundary; otherwise, a specification exception may be recognized.

An example of a load address TOC relatively long instruction is described with reference to Figure 21. As depicted, the load address TOC relatively long instruction 2100 includes a plurality of opcode fields 2102a, 2102b, the opcode fields including an opcode indicating a load address TOC relatively long operation; a first operand field ( _R1 ) 2104 indicating the location (e.g., register) of a first operand; and a second operand field ( _R2 ) 2108, which is an immediate field, the contents of which are a signed binary integer specifying a number of one of bytes, halfwords, words, doublewords, etc., which is added to the value of the TOC pointer at the current address to generate the calculated address.

The address specified using the RI ₂ field is placed in general register R _1. The address is obtained by adding the RI ₂ field to the TOC value of the current address.

In 24-bit addressing mode, the address is placed in bit positions 40-63, bits 32-39 are set to zero, and bits 0-31 remain unchanged. In 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 64-bit addressing mode, the address is placed in bit positions 0-63.

No store reference of the operand occurs, and no access exception is checked for the address.

In another aspect, a TOC addition immediate shift (tocaddis) instruction is provided (e.g., for RISC-type architectures). As shown in FIG. 22 , in one example, a TOC addition immediate shift instruction 2200 includes an opcode field 2202, which includes an opcode specifying a TOC addition immediate shift operation; a target return (RT) field 2204 indicating a target return value; and a shift immediate (SI) field 2206 specifying a shift amount to be applied to the TOC value.

As an example, the following defines tocaddis:

tocaddis RT,SI

RT<=(TOC)+EXTS(SI││ ¹⁶ 0)

The sum TOC+(SI││0×0000) is placed in register RT. EXTS refers to the extended sign, and ││ refers to concatenation.

On the other hand, a TOC indication prefix instruction may be provided. For example, an addition TOC immediate shift instruction addtocis+ is provided, which is a prefix instruction that provides information for the next instruction. Referring to Figure 23, in one example, for example, an addition TOC immediate shift instruction 2300 includes an opcode field 2302 having an opcode specifying an addition TOC immediate shift operation; a target register (RT) field 2304 for storing the result; an operand field (RA) 2306; and a shift immediate (SI) field 2308.

As an example,

addtocis+RT,RA,SI

if RA＝0then RT←(TOC)+EXTS(SI││ ¹⁶ 0)else RT←(RA)+

EXTS(SI││ ¹⁶ 0)

The sum (RA│TOC)+(SI││0×0000) is provided as a reference source for register RT for the next sequential instruction only. addtocis+ is an instruction prefix, and when RT is specified, subsequent instructions are modified to use the value calculated for RT as input. This 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 before the next sequential instruction, the state will be updated in a manner that allows execution to be resumed with the next instruction and produce the correct result (i.e., RT will be written, or another implementation-defined method for maintaining the effect of modifying the RT source of the next sequential instruction will be used). Note that if RA=0, addtocis+ uses the value of TOCbase, rather than the contents of GPR0.

This prefix instruction may have other options, such as a displacement designator field, to indicate whether to use an extra immediate bit. In addition, it may include one or more additional immediate fields that include a value to be used (e.g., add, or operate, etc.) with the operand of a subsequent instruction.

Other prefix options may be used, including a TOC prefix and/or a TOC prefix with an option for covering an optional operand in an operand. For example, a prefix instruction may be provided that indicates that a TOC value should be used instead of one of the operands of a subsequent instruction. In one example, the operand is selectable.

In addition, aspects of prefix instructions (e.g., addtocis) and subsequent instructions may be fused for ease of processing. For example, if a prefix instruction with a displacement is specified, and the subsequent instruction also includes a displacement, the displacement may correspond to an immediate shift and an immediate displacement. There are other possibilities.

A specific optimization example using addtocis is shown below. In this example, n (e.g., 3) instruction candidate sequences include, for example: addtocis+r4,toc,upper; addi r4,r4,lower; and lvx*vr2,r0,r4. This sequence can 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 (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 TOC instead of the constant 0 when the RA field has the value 0. In one example, lvx* is a form of an instruction that defines a base register (e.g., 4 in this example) to have an unspecified value after the instruction is executed. In one example, lvx* is a form of an lvx (load vector indexed) instruction that indicates the last use of at least one register (e.g., defined here as the register represented as <r1> in the template). lvd is a load vector operation with an implementation-defined displacement. The toc_or_gpr function handles the special case of an extended TOC, as lvd otherwise treats the RA operand similar to all other RA operands, as a 0 value representing 0, and other register values representing logical registers.

There may be further opportunities to reduce complex instruction sequences that include TOC instructions or TOC usage instructions to simpler instruction sequences.

One embodiment of an execution flow for managing TOC operands is described with reference to Figure 24. In one example, a processor is executing the logic.

24, in one example, an instruction is received, step 2400. Based on the non-TOC operand definition, any non-TOC operands of the instruction are obtained, step 2402. For example, if the instruction operand specifies a general register, data is obtained from that register, and so on.

A determination is made as to whether a TOC operand is present in the instruction, query 2404. That is, is there an 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, the TOC operand is obtained from an in-memory TOC structure, as described with reference to Figure 25. The address of the in-memory TOC tracking structure is obtained, step 2500, and the TOC value for the module including the instruction is obtained from the in-memory TOC structure, step 2502. The TOC value is then provided for use by the instruction, step 2504.

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 FIG26. In this example, the TOC cache is accessed, step 2600, and a determination is made as to whether there is a TOC cache hit, query 2602. That is, is there an entry in the cache for the module that includes the instruction? If there is no TOC cache hit, the TOC cache is reloaded from the in-memory TOC cache structure, step 2604. Thereafter, or if there is a TOC cache hit, the TOC value for the module that includes the instruction is obtained from the TOC cache and provided for use by the instruction, step 2606.

Another example of obtaining a TOC operand from a TOC cache supported by an in-memory structure is described with reference to FIG27. In this example, the TOC cache is accessed, step 2700, and a determination is made as to whether there is a TOC cache hit, query 2702. If there is a TOC cache hit, the TOC value is retrieved from the entry in the TOC cache corresponding to the module that includes the instruction, and the TOC value is provided for use by the instruction, step 2704. However, if there is no TOC cache hit, control is transferred to a software handler, step 2706. The software handler uses a software determined TOC value (e.g., obtains it from an in-memory tracking structure), step 2710, and loads the determined TOC value into the TOC cache, step 2712. The software handler ends, and the instruction is restarted, step 2714.

To load the TOC cache from software, a load TOC cache (LTC) instruction may be used. For example, LTCRfrom, Rto, RTOC may be used to load an entry of <MODULE.Rfrom, MODULE.Rto, MODULE.TOC>. For example, an entry is included in the cache, 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, the entry is selected according to the replacement strategy of the particular implementation.

In another embodiment, the table entries are loaded by loading a plurality of control registers.

The following describes an example usage:

According to the definition of C programming language, function foo returns the character from array bar, where the character position is indicated to function foo by the argument idx.

According to one aspect of the present invention, the compiler translates the program into the following sequence of machine instructions:

According to one or more aspects of the present invention, the Set TOC Register instruction efficiently initializes the register to be loaded with the TOC value. In addition, according to one aspect of the present invention, since the Set TOC Register instruction is effective, the TOC register value is not saved and restored in the compiled code. Instead, when the subroutine is called, the TOC register value is abandoned. When the called function returns, the TOC value is not loaded. Instead, a new Set TOC Register instruction is generated to load the TOC register.

An example of compiler generated code to obtain the correct value of the TOC pointer based on the STR (Set TOC Register) instruction corresponding to the C programming language function foo above is as follows:

One embodiment of initializing registers with a TOC pointer as performed by a compiler is described with reference to FIG. 28 . Initially, a determination is made as to whether the function accesses the TOC, query 2800 . If not, then processing is complete. However, if the function accesses the TOC, then prior to first use, the registers are initialized with the TOC pointer using, for example, a STR instruction, step 2802 . For example, a STR instruction is added to the compiled code and used to initialize the TOC registers. Other variations are possible.

In another example, the static linker can initialize the TOC, as described with reference to FIG. 29. In this example, a determination is made as to whether the subroutine is parsed as a function that can modify a register with a TOC value, query 2900. If not, the process is complete. Otherwise, the register holding the TOC pointer is reinitialized, for example, with a STR instruction, step 2902. For example, a STR instruction is added to the compiled code and used to initialize the TOC register. Other variations are possible.

An example use case is as follows. According to one aspect of the invention, this more efficient code is generated:

In addition to generating code using TOC setting instructions, code can also be generated using the TOC read-only register. This further avoids the need to load the TOC into the GPR and thereby reduces register pressure and the overhead of loading registers or reloading registers after function calls.

An example of compiler-generated code using the TOC read-only register is as follows:

char bar[MAX];

char foo(int idx)

{

return bar[idx];

}

According to the definition of C programming language, function foo returns the character from array bar, where the character position is indicated to function foo by the argument idx.

According to one aspect of the present invention, the compiler translates the program into the following sequence of machine instructions.

An example of a compilation flow using a TOC read-only register to reference the TOC is described with reference to FIG. 30 . In this example, a determination is made as to whether a reference to the TOC is requested, query 3000 . If not, the process is complete. Otherwise, the TOC is referenced using the TOC read-only register, step 3002 . For example, an operation (e.g., an internal operation, an instruction, etc.) is included in the code being compiled and is used to determine a pointer to the TOC. Other variations are possible.

An example use case is as follows. According to one aspect of the invention, this more efficient code is generated:

One or more aspects of the present invention are inseparable from computer technology and facilitate processing within a computer, thereby improving its performance. Further details of an embodiment of facilitating processing within a computing environment related to one or more aspects of the present invention are described with reference to Figures 31A-31B.

31A , in one embodiment, an instruction providing a pointer to a reference data structure is obtained by a processor (3100). The instruction is executed (3102), and the execution includes, for example, determining the value of the pointer to the reference data structure (3104), and storing the value in a location (e.g., a register) specified by the instruction (3106).

In one example, determining the value includes performing a lookup of a data structure (eg, a reference data structure pointer cache or a table populated with reference data structure pointer values) to determine the value (3108).

As a specific example, determining the value includes, for example, checking a reference data structure pointer cache for an entry that includes the value (3110), and performing a store based on finding the entry (3112). Further, in one example, referring to FIG. 31B , determining includes initiating, by the processor, a trap to a handler based on the value not being located in the reference data structure pointer cache (3120), obtaining, by the handler, the value from a data structure populated with the reference data structure pointer value (3122), and performing a store by the handler (3124). Additionally, the value is stored in the reference data structure pointer cache (3126).

In another example, determining further includes performing cache miss processing to determine the value and storing the value based on the value not being located in the reference data structure pointer cache (3130).

In one embodiment, based on obtaining the instruction, a trap is caused by the processor to a handler (3132), and the determination and storage (3134) are performed by the handler.

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 simulation environments, examples of which are described with reference to FIG. 32A. In this example, the computing environment 20 includes, for example, a local central processing unit (CPU) 22, a memory 24, and one or more input/output devices and/or interfaces 26 coupled to each other via, for example, one or more buses 28 and/or other connections. As an example, the computing environment 20 may include a PowerPC processor or pSeries server provided by International Business Machines Corporation of Armonk, New York, and/or other machines based on architectures provided by International Business Machines Corporation, Intel, or other companies.

The local central processing unit 22 includes one or more local 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 representative of the state of the environment at any particular point in time.

In addition, the native central processing unit 22 executes instructions and codes stored in the memory 24. In a specific example, the central processing unit executes emulator code 32 stored in the memory 24. The code enables a computing environment configured in one architecture to emulate another architecture. For example, the emulator code 32 allows a machine based on an architecture other than the z/architecture (such as a PowerPC processor, a pSeries server, or other server or processor) to emulate the z/architecture and execute software and instructions developed based on the z/architecture.

Further details related to the emulator code 32 are described with reference to FIG. 32B. The guest instructions 40 stored in the memory 24 include software instructions (e.g., related to machine instructions) that are developed to be executed in an architecture different from the architecture of the native CPU 22. For example, the guest instructions 40 may have been designed to be executed on a z/architecture processor, but on the contrary, they are simulated on a native CPU 22, which may be, for example, an Intel processor. In one example, the emulator code 32 includes an instruction fetch routine 42 to obtain one or more guest instructions 40 from the memory 24, and optionally provide a local buffer for the obtained instructions. It also includes an instruction conversion routine 44 to determine the type of the obtained guest instruction and convert the guest instruction into one or more corresponding native instructions 46. The conversion includes, for example, identifying the function to be performed by the guest instruction and selecting the native instruction to perform the function.

In addition, the emulator code 32 includes an emulation control routine 48 to cause native instructions to be executed. The emulation control routine 48 may cause the native CPU 22 to execute a routine of native instructions that emulates one or more previously acquired guest instructions, and at the end of such execution, returns control to the instruction fetch routine to emulate the acquisition of the next guest instruction or guest instruction group. The execution of the native instructions 46 may include: loading data from the memory 24 into a register; storing data from a register back to the memory; or performing some type of arithmetic or logic operation as determined by the conversion routine.

Each routine is implemented, for example, in software that is stored in memory and executed by the native central processing unit 22. In other examples, one or more routines or operations are implemented in firmware, hardware, software, or some combination thereof. The registers of the emulated processor may be emulated using the registers 30 of the native CPU or by using locations in the memory 24. In an embodiment, the guest instructions 40, the native instructions 46, and the emulator code 32 may reside in the same memory or may be allocated in different memory devices.

As used herein, firmware includes, for example, microcode or millicode of a processor. For example, it includes hardware-level instructions and/or data structures for implementing higher-level machine code. In one embodiment, firmware may include, for example, proprietary code that is typically transmitted as microcode, including trusted software or microcode specific to the underlying hardware, and controls operating system access to system hardware.

The guest instructions 40 that are obtained, translated, and executed are, for example, one or more of the instructions described herein. Instructions of one architecture (e.g., z/architecture) are fetched from memory, translated, and represented as a series of native instructions 46 of another architecture (e.g., PowerPC, pSeries, Intel, etc.). These native instructions can then be executed.

One or more aspects may relate to cloud computing.

First, it should be understood that although the present disclosure includes a detailed description about cloud computing, the implementation of the technical solutions recorded therein is not limited to a cloud computing environment, but can be implemented in combination with any other type of computing environment now known or later developed.

Cloud computing is a service delivery model for convenient, on-demand network access to a shared pool of configurable computing resources. Configurable computing resources are resources that can be quickly deployed and released with minimal management cost or interaction with the service provider, such as networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

Features include:

On-demand self-service: Cloud consumers can unilaterally and automatically deploy computing capabilities such as server time and network storage on demand without human interaction with the service provider.

Broad network access: Computing power can be accessed over the network through standard mechanisms that facilitate the use of the cloud through different types of thin-client or thick-client platforms (e.g., mobile phones, laptops, personal digital assistants (PDAs)).

Resource pool: The computing resources of the provider are grouped into resource pools and serve multiple consumers through a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated on demand. Generally, consumers cannot control or even know the exact location of the provided resources, but can specify the location (such as country, state or data center) at a higher level of abstraction, so it is location-independent.

Rapid elasticity: The ability to quickly and elastically (sometimes automatically) deploy computing power to scale up quickly, and quickly release it to scale down quickly. To consumers, the computing power available for deployment often appears to be unlimited, and any amount of computing power can be accessed at any time.

Measurable services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a 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 to both service providers and consumers.

The service model is as follows:

Software as a Service (SaaS): The capability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). Aside from limited user-specific application configuration settings, consumers neither manage nor control the underlying cloud infrastructure including networks, servers, operating systems, storage, or even individual application capabilities.

Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired by consumers on the cloud infrastructure, which are created using programming languages and tools supported by the provider. Consumers neither manage nor control the underlying cloud infrastructure including networks, servers, operating systems or storage, but have control over the applications they deploy and may also have control over the configuration of the application hosting environment.

Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, network, and other basic computing resources on which consumers can deploy and run arbitrary software including operating systems and applications. Consumers neither manage nor control the underlying cloud infrastructure, but have control over the operating system, storage, and applications they deploy, and may have limited control over selected network components (such as host firewalls).

The deployment model is as follows:

Private cloud: The cloud infrastructure is run solely for an organization. The cloud infrastructure can be managed by the organization or a third party and can exist inside or outside the organization.

Community Cloud: A cloud infrastructure is shared by several organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). A community cloud can be managed by multiple organizations within the community or by a third party and can exist inside or outside the community.

Public cloud: Cloud infrastructure is provided to the public or to large industry groups and is owned by an organization that sells cloud services.

Hybrid cloud: A cloud infrastructure consisting of two or more clouds (private, community or public) in a deployment model that remain distinct entities but are bound together by standardized or proprietary technologies (such as cloud burst sharing for load balancing between clouds) that enable data and application portability.

The cloud computing environment is service-oriented, with characteristics centered on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that includes a network of interconnected nodes.

Referring now to FIG. 33 , an illustrative cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more computing nodes 10 with which a cloud consumer can communicate using a local computing device, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and/or an automotive computer system 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or a combination thereof, as described above. In this way, cloud consumers can allow the cloud computing environment 50 to provide infrastructure as a service, platform as a service, and/or software as a service without maintaining resources on local computing devices. It should be understood that the types of computing devices 54A-N shown in FIG. 33 are merely illustrative, and the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computing device (e.g., using a web browser) through any type of network and/or network addressable connection.

Referring now to FIG. 34 , a set of functional abstraction layers provided by the cloud computing environment 50 ( FIG. 33 ) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 34 are merely illustrative, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

The hardware and software layer 60 includes hardware and software components. Examples of hardware components include host 61; server 62 based on RISC (Reduced Instruction Set Computer) architecture; server 63; blade server 64; storage device 65; network and network 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, the management layer 80 may provide the functionality described below. Resource provisioning functionality 81 provides dynamic acquisition of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing functionality 82 tracks the cost of resource usage within a cloud computing environment and provides bills or invoices for consuming these resources. In one example, these resources may include application software licenses. Security functionality provides identity authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal functionality 83 provides access to the cloud computing environment for consumers and system administrators. Service level management functionality 84 provides allocation and management of cloud computing resources to meet required service levels. Service level agreement (SLA) planning and fulfillment functionality 85 provides pre-scheduling and provisioning for future demand for cloud computing resources based on SLA forecasts.

The workload layer 90 provides examples of functions that can take advantage of a cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom instructional provision 93; data analysis processing 94; transaction processing 95; and content table pointer processing 96.

The present invention may be a system, method and/or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions thereon for causing a processor to perform various aspects of the present invention.

A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A 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 of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, 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 disc (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage medium used herein should not be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., a light pulse transmitted through a fiber optic cable), or an electrical signal transmitted through a wire.

The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing/processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and/or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and/or edge servers. The network adapter card or network interface in each computing/processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing/processing device.

The computer-readable program instructions for performing the operation of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, and procedural programming languages such as "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., using an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may be personalized electronic circuits using the state information of computer-readable program instructions, and the electronic circuits execute computer-readable program instructions to perform various aspects of the present invention.

Various aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present invention. It will be understood that each block in the flowchart illustrations and/or block diagrams and combinations of blocks in the flowchart illustrations and/or block diagrams can be implemented by computer-readable program instructions.

These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions/actions specified in the flowchart and/or one or more block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can cause a computer, a programmable data processing device, and/or other equipment to work in a specific manner, so that the computer-readable storage medium with instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions/actions specified in the flowchart and/or one or more block diagram blocks.

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 executed on the computer, other programmable apparatus, or other device implement the functions/actions specified in the flowchart and/or a block diagram block or multiple block diagram blocks.

The flow charts and block diagrams in the accompanying drawings illustrate the system, method and computer program product according to various embodiments of the present invention. The architecture, function and operation of possible implementation methods. In this regard, each box in the flow chart or block diagram can represent a part of a module, a program segment or an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions marked in the box may not occur in the order shown in the figure. For example, the two boxes shown in succession can actually be executed substantially in parallel, or these boxes can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each box in the block diagram and/or flow chart illustration and the combination of boxes in the block diagram and/or flow chart illustration can be implemented by a dedicated hardware-based system that performs a specific function or action, or performs a combination of dedicated hardware and computer instructions.

In addition to the above, one or more aspects may be provided, delivered, deployed, managed, serviced by a service provider that provides customer environment management. For example, a service provider may create, maintain, support computer code and/or computer infrastructure that performs one or more aspects for one or more customers. In return, the service provider may receive payment from the customer, for example, under a subscription and/or fee agreement. Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.

In one aspect, an application may be deployed to perform one or more embodiments. As an example, deployment of an application includes providing a computer infrastructure operable to perform one or more embodiments.

As another aspect, a computing infrastructure may be deployed including integrating computer readable code into a computing system, wherein the code in combination with the computing system is capable of performing one or more embodiments.

As another aspect, a process for integrating computing infrastructure may be provided, comprising integrating computer readable code into a computer system. The computer system comprises a computer readable medium, wherein the computer medium comprises one or more embodiments. The code combined with the computer system is capable of executing one or more embodiments.

Although various embodiments are described above, these are merely examples. For example, computing environments with other architectures may be used to incorporate and use one or more embodiments. In addition, different instructions or operations may be used. In addition, different registers may be used and/or other types of indications (other than register numbers) may be specified. Multiple variations are possible.

In addition, 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 available, which includes at least two processors that are directly or indirectly coupled to a memory element through a system bus. The memory element includes a local memory, a large storage and a cache memory that are used during the actual execution of the program code, and the cache memory provides temporary storage of at least some program codes, so as to reduce the number of times that code must be retrieved from the large storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, DASD, tapes, CDs, DVDs, thumb drives and other storage media, etc.) can be coupled to the system directly or through intervening I/O controllers. Network adapters can also be coupled to the system to enable the data processing system to be 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 terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the present invention. 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 when used in this specification, the terms "include" and/or "comprise" specify the presence of the features, integers, steps, operations, elements and/or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or combinations thereof.

The corresponding structures, materials, actions, and equivalents (if any) of all means or step plus function elements in the following claims are intended to include any structure, material, or action for performing a function in combination with other claimed elements as specifically claimed. The description of one or more embodiments has been given for the purpose of illustration and description, but is not intended to be exhaustive or limited to the disclosed forms. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments are selected and described in order to best explain various aspects and practical applications, and to enable those of ordinary skill in the art to understand that various embodiments with various modifications are suitable for the intended specific use.

Claims (20)

1. A computer-readable storage medium for facilitating processing within a computing environment, readable by a processing circuit and storing instructions for performing a method comprising:

obtaining, by a processor, instructions to be executed, the instructions providing pointers to reference data structures used to populate variables included in program code; and

executing the instructions, the executing comprising:

determining a value of the pointer to the reference data structure, the value of the pointer being used to access the reference data structure for populating variables included in program code; and

the value is stored in a location specified by the instruction, wherein the determining and the storing are performed as part of executing the instruction.

2. The computer-readable storage medium of claim 1, wherein determining the value comprises performing a lookup of a data structure to determine the value.

3. The computer readable storage medium of claim 2, wherein the data structure comprises a reference data structure pointer cache.

4. The computer-readable storage medium of claim 2, wherein the data structure comprises a table populated with reference data structure pointer values.

5. The computer-readable storage medium of claim 1, wherein the location comprises a register specified by the instruction.

6. The computer-readable storage medium of claim 1, wherein determining the value comprises:

checking a reference data structure pointer cache for an entry comprising the value; and

based on finding the entry, the storing is performed.

7. The computer-readable storage medium of claim 6, wherein determining the value further comprises:

causing, by the processor, a trap to a handler based on the value not being located in the reference data structure pointer cache;

obtaining, by the handler, the value from a data structure populated with reference data structure pointer values; and

the storing is performed by the processing program.

8. The computer-readable storage medium of claim 7, wherein the method further comprises storing the value in the reference data structure pointer cache.

9. The computer-readable storage medium of claim 6, wherein determining the value further comprises performing a cache miss process to determine the value and store the value based on the value not being in the reference data structure pointer cache.

10. The computer-readable storage medium of claim 1, wherein the method further comprises:

causing, by the processor, a trap to a handler based on obtaining the instruction; and

the determining and the storing are performed by the processing program.

11. A computer system for facilitating processing within a computing environment, the computer system comprising:

a memory; and

a processor in communication with the memory, wherein the computer system is configured to perform a method comprising:

obtaining, by the processor, instructions to be executed, the instructions providing pointers to reference data structures used to populate variables included within program code; and

executing the instructions, the executing comprising:

determining a value of the pointer to the reference data structure, the value of the pointer being used to access the reference data structure for populating variables included in program code; and

the value is stored in a location specified by the instruction, wherein the determining and the storing are performed as part of executing the instruction.

12. The computer system of claim 11, wherein the location comprises a register specified by the instruction.

13. The computer system of claim 11, wherein determining the value comprises:

checking a reference data structure pointer cache for an entry comprising the value; and

based on finding the entry, the storing is performed.

14. The computer system of claim 13, wherein determining the value further comprises:

causing, by the processor, a trap to a handler based on the value not being located in the reference data structure pointer cache;

obtaining, by the handler, the value from a data structure populated with reference data structure pointer values; and

the storing is performed by the processing program.

15. The computer system of claim 11, wherein the method further comprises:

causing, by the processor, a trap to a handler based on obtaining the instruction; and

the determining and the storing are performed by the processing program.

16. A computer-implemented method for facilitating processing within a computing environment, the method comprising:

obtaining, by a processor, instructions to be executed, the instructions providing pointers to reference data structures used to populate variables included in program code; and

Executing the instructions, the executing comprising:

determining a value of the pointer to the reference data structure, the value of the pointer being used to access the reference data structure for populating variables included in program code; and

the value is stored in a location specified by the instruction, wherein the determining and the storing are performed as part of executing the instruction.

17. The computer-implemented method of claim 16, wherein the location comprises a register specified by the instruction.

18. The computer-implemented method of claim 16, wherein determining the value comprises:

checking a reference data structure pointer cache for an entry comprising the value; and

based on finding the entry, the storing is performed.

19. The computer-implemented method of claim 18, wherein determining the value further comprises:

causing, by the processor, a trap to a handler based on the value not being located in the reference data structure pointer cache;

obtaining, by the handler, the value from a data structure populated with reference data structure pointer values; and

the storing is performed by the processing program.

20. The computer-implemented method of claim 16, further comprising:

causing, by the processor, a trap to a handler based on obtaining the instruction; and

the determining and the storing are performed by the processing program.