HK1193890A - Method, apparatus and computer system for facilitating communication in a communication environment - Google Patents

Description

Facilitating communication between isolated memory spaces of a communication environment

Background

One aspect of the present invention relates generally to communications in a communication environment, and more particularly to facilitating data transfer between isolated memory spaces of the communication environment.

To transfer data between isolated memory spaces, networking technologies and protocols are typically used. For example, data may be sent from one isolated memory space to another isolated memory space over an Ethernet link using TCP/IP protocols. Current networking technologies enable data to be sent synchronously or asynchronously. This is an exclusive choice in terms of the sender.

When data is transmitted synchronously, the transmitter is suspended until the data transmission is completed. On the other hand, if the data is sent asynchronously, the sender may continue to operate.

Disclosure of Invention

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a computer program product for facilitating communications in a communications environment. The computer program product comprises a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method comprises the following steps: obtaining, for example by a processor of the communication environment, a pre-authorization from a sender of the communication environment to convert from synchronous data transfer to asynchronous data transfer; obtaining, by the processor, a request from the transmitter to transmit data to a receiver of the communication environment; initiating, by the processor, sending the data to the receiver, wherein the initiating employs the synchronous data transmission; determining, by the processor, that the synchronous data transmission is to be converted to an asynchronous data transmission; and automatically converting, by the processor, the synchronous data transfer to the asynchronous data transfer to complete sending the data to the receiver in response to the determination, wherein the automatic conversion is independent of operations performed by the sender other than the pre-authorization.

Methods and systems relating to one or more aspects of the present invention are also described and claimed herein. Services relating to one or more aspects of the present invention are also described and claimed herein.

Additional features and advantages are realized through the techniques of one or more aspects of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

Drawings

One or more aspects of the present invention are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The above and other objects, features and advantages of one or more aspects of the present invention will become apparent from the following detailed description when taken in conjunction with the accompanying drawings in which:

FIG. 1 illustrates one example of a communication environment incorporating and/or using one or more aspects of the present invention;

FIG. 2 illustrates an example of storage space associated with the logical partitions of FIG. 1, in accordance with an aspect of the present invention;

FIG. 3 illustrates one example of a synchronized outbound data transmission used in accordance with an aspect of the present invention;

FIG. 4 illustrates an example of a control structure for automatically transitioning from synchronous to asynchronous data transfers in accordance with an aspect of the present invention;

FIG. 5A depicts one embodiment of the logic used to automatically convert an isochronous data transfer to an asynchronous data transfer, in accordance with an aspect of the present invention;

FIG. 5B graphically illustrates one example of successful completion of asynchronous data transfer in accordance with an aspect of the present invention;

FIG. 6 depicts one embodiment of a computer program product incorporating one or more aspects of the present invention;

FIG. 7 depicts one embodiment of a host computer system to incorporate and use one or more aspects of the present invention;

FIG. 8 illustrates a further example of a computer system for incorporating and using one or more aspects of the present invention;

FIG. 9 illustrates another example of a computer system including a computer network for incorporating and using one or more aspects of the present invention;

FIG. 10 depicts one embodiment of various elements of a computer system to incorporate and use one or more aspects of the present invention;

FIG. 11A depicts one embodiment of an execution unit of the computer system of FIG. 10 for incorporating and using one or more aspects of the present invention;

FIG. 11B depicts one embodiment of a branching unit for the computer system of FIG. 10 to incorporate and use one or more aspects of the present invention;

FIG. 11C depicts one embodiment of a load/store unit of the computer system of FIG. 10 for incorporating and using one or more aspects of the present invention; and

FIG. 12 illustrates one embodiment of an emulated host computer system incorporating and using one or more aspects of the present invention.

Detailed Description

According to one aspect of the present invention, a capability is provided for automatically converting synchronous data transfers to asynchronous data transfers. For example, in response to determining that there is a delay in completing the data transfer (e.g., the data receiver is unable to receive the data while transferring), the synchronous data transfer is automatically converted to an asynchronous data transfer. The transition from synchronous to asynchronous data transfer is performed automatically because it is not upon request of the sender (or receiver) and the sender (or receiver) is not aware of the transition when it is initiated. Further, at the time of conversion, the transmitter (or receiver) does not need to take any action or intervene in the conversion.

One embodiment of a communication environment to incorporate and/or use one or more aspects of the present invention is described with reference to fig. 1. In one example, the communication environment 100 includes a Central Processor Complex (CPC) 102, which is based on International Business machines corporation (C: (C))) Provided withUnder the heading "z/Architecture Principles of Operation" (IBM publication No. SA22-7832-08, 8.2010, incorporated herein by reference in its entirety)In publicationsDescribeIn the following description. One system that may include the central processor complex 102 is the zEnterprise 196 (z 196) system offered by International Business machines corporation, Armonk, N.Y..Andare registered trademarks of international business machines corporation, armonk, new york, usa, and zEnterprise 196 and z196 are trademarks thereof. Other names used herein may be registered trademarks, trademarks or product names of International Business machines corporation or other companies.

The central processor complex 102 includes, for example, one or more partitions 104, a hypervisor 106, one or more central processors 108, and one or more components of an input/output subsystem 110. In this example, one or more partitions 104 are logical partitions (also known as LPARs) that include a set of system hardware resources that are virtualized as a single system.

Each logical partition 104 can function as a separate system. That is, each logical partition may be reset independently, initially loaded with operating system 120 (if needed) and run with different programs. An operating system or application running in a logical partition appears to have access to the entire system, but in practice, only a portion of the system is available. The combination of hardware and Licensed Internal Code (LIC), referred to as firmware, prevents programs in one logical partition from interfering with programs in a different logical partition. This allows multiple different logical partitions to run on a single or multiple physical processors in a time-sliced manner. In this example, multiple logical partitions have a resident operating system 120, and the resident operating system 120 may be different for one or more logical partitions. In one embodiment, operating system 120 is provided by International Business machines corporation, Armonk, N.Y.And (4) operating the system.

As used herein, firmware includes, for example, microcode, millicode, and/or macrocode of a processor. It includes, for example, hardware-level instructions and/or data structures for implementing higher-level machine code. In one embodiment, it comprises, for example, specialized code typically provided as microcode, which includes trusted software or microcode specific to the underlying hardware and which controls operating system access to the system hardware.

Logical partitions 104 are managed by a hypervisor 106, and hypervisor 106 is implemented by firmware running on central processor 108. An example of hypervisor 106 is Processor Resource/SystemManager (PR/SM) provided by International Business machines corporation, Armonk, N.Y.^TM）。

Central processors 108 are physical processor resources allocated to logical partitions. For example, a logical partition 104 includes one or more logical processors, each of which represents all or a portion of the physical processor resources 108 allocated to the partition. The logical processors of a particular partition 104 may be dedicated to the partition in order to reserve the underlying processor resources for that partition; or shared with another partition so that the underlying processor resources may be used for another partition.

Logical partition 104 and hypervisor 106 each comprise one or more programs that reside in respective portions of main memory 150 associated with the central processors. In one example, a portion of main memory, referred to as storage space, is allocated for each logical partition, as described in further detail with reference to FIG. 2.

Referring to FIG. 2, in one embodiment, main memory 150 includes a plurality of memory spaces, each memory space including a series of addresses in the main memory. Memory space may be allocated to an entity, such as a logical partition or other entity. In the example shown in FIG. 2, there are two memory spaces allocated to two logical partitions, respectively. One memory space is referred to herein as the memory space 202 of the sender and the other memory space is referred to herein as the memory space 204 of the receiver, since the communication between the sender and the receiver is described further below. The memory space 202 of the transmitter includes, for example, one or more input queues 210, one or more output queues 212, and one or more buffers 214. Likewise, the receiver's storage space 204 includes one or more input queues 220, one or more output queues 222, and one or more buffers 224. The use of queues and buffers is described further below.

The individual memory spaces are isolated from each other because data cannot be written directly from one memory space to another without firmware control. In one example, data is transferred from one storage space to another using networked transfer over an Ethernet link, for example using TCP/IP. In one particular example, a so-called Hipersockets, available from International Business machines corporation, is used^TMThe technique of (1) performs the transmission.

HiperSockets^TMHigh speed TCP/IP connectivity is provided in a central processor complex. It does not require any physical wiring or external networking connections between servers running in different logical partitions. Instead, communication is through the system memory of the processor. Hipersockets^TMThe OSA-Express based queued direct I/O (QDIO) protocol is implemented. The firmware emulates the link control layer of the OSA-Express QDIO interface.

Data transfer from one memory space to another using networking technology is, for example, synchronous, wherein after initiating the data transfer, the sender is suspended until the transfer is complete. An example of a synchronized data transfer from one memory space to another is described with reference to fig. 3.

Referring to fig. 3, a sender 300 (e.g., a TCP/IP stack or program running in the memory space of the sender) initiates a request to send data to a receiverA processor 310 (e.g., another TCP/IP stack or program in the memory space of the receiver). Since the memory space of the receiver is isolated from the memory space of the sender, in this example, a network communication protocol is used to perform isochronous data transfer for data sent from the sender to the receiver. Using isochronous data transfer, a very fast, low latency direct communication path is provided between a sender and a receiver by performing memory transfers from one location to another under the control of firmware. In one example, by Hipersockets^TMA memory-to-memory data transfer is performed. This transmission mechanism is very efficient as long as the receiver receives data at a rate equal to or faster than the rate at which the transmitter transmits data.

To transmit data, the sender obtains the data contained in the selected data buffer 320 and places it on the sender's output queue 330. For example, pointer 332 of the selected data buffer is placed on the output queue. The transmitter 300 then signals 340 a processor to perform the data transmission to the receiver 310. In one example, the firmware 350 of the processor is signaled, and the firmware 350 will perform the transfer; however, in other examples, rather than firmware, other code and/or hardware of the processor.

In response to receiving a signal requesting a data transfer from the sender to the receiver, the firmware copies the data in the sender's output queue and places it on the receiver's input queue 360. For example, data is copied to the empty buffer 370 and a pointer 372 to the data is placed in the input queue 360. After the data transfer is complete, the firmware returns a signal to the transmitter that the transfer is complete. Until the transmitter receives the completion signal, the transmitter is suspended and cannot perform any other operations.

As a specific example, to signal the processor, the sender issues a Signaladapter (SIGA) instruction that specifies a write function (SIGA-w) that signals the processor that one or more output queues have data to transmit to the receiver. The write function is specified as a function code provided in a first general purpose register used by the instruction, and a network connection address (e.g., a subsystem identification word) of the write function is indicated in a second general purpose register used by the instruction. Further, the output queue is also specified in a third general register used by the instruction.

In this particular example, the queues are implemented as queued direct I/O (QDIO) queues, and each queue has associated therewith a plurality of buffers and various control information. In one embodiment, the QDIO queue includes a data structure describing the queue, and a buffer memory block for data transfer. As an example, a plurality of storage data structures (referred to as queue components) that collectively describe characteristics of a queue and provide control to allow data exchange include, for example:

a Queue Information Block (QIB) that includes information about the set of QDIO input and output queues.

The QIBs include the Storage List Information Block (SLIB) address of the input queue and the SLIB address of the output queue.

There is one SLIB per queue, and each SLIB provides information about the queue and each queue buffer of the queue. Each SLIB has a header and one or more entries, called Storage List Information Block Entries (SLIBEs), that contain information about each buffer of each queue. In one example, each memory list information block includes an address of a next memory list information block, an address of a memory list (SL), and an address of a memory list status block (SLSB).

One storage list is defined for each queue and SL comprises for example 128 entries, one for each buffer of the queue. The storage list provides information about the location of the I/O buffer in main memory. Each entry includes an absolute address of a Storage Block Address List (SBAL). Each storage block address list includes a list of absolute addresses of storage blocks that collectively make up one of the data buffers associated with each queue.

A storage block list entry (SBALE) is provided as part of each SBAL. Each SBALE includes an absolute memory address of the memory block. In general, the storage blocks addressed by all entries of a single SBAL constitute one of many possible QDIO buffers of a QDIO queue. In one example, a QDIO queue may have 128 QDIO buffers associated with it.

The SLSB includes status indicators that provide status information about the buffers that make up the queue.

Further details regarding SIGA, QDIO queues, and associated control structures are described in: baskey et al, U.S. Pat. No. 5, 6,332,171, 1 entitled "Self-Contained queue with associated Control Information For Reception And Transfer Of incorporated And outputting Data Using A Queued Direct Input-Output Device", published on 12/18/2001; U.S. Pat. No. 8, 6,345,241, 1 entitled "method and Apparatus For Simulation Of Data In a Virtual environmental use ordered Input-Output Device" by Brice et al, published on 2.5.2002; markos et al, entitled "Method And Apparatus For providing configuration Information Using A Queued Direct Input-Output Device, US patent 6,519,645B2, published on 11/2/2003; and Easton et al, U.S. Pat. No. 7,941,799B2 entitled "suppressing I/O Operation Requests From Pageable Guests without host interaction", published 5/10/2011.

In the above process, when the receiver cannot provide an empty buffer at the same speed as the transmitter transmits data, increased delay and CPU overhead are introduced on the transmitter side due to the synchronous nature of the protocol. When no empty buffer is provided on the receiver, the transmitter has two options. It may incur the overhead of queuing failed operations and then retransmitting the data to the same receiver, or dropping the data to allow higher level communication protocols (such as TCP/IP) to redrive the operation. A drawback of queuing and retransmitting data is that it not only requires additional CPU cycles for recovery, but can potentially prevent or delay other transmissions by the sender to other destinations (which may be able to accept incoming data).

A virtualized environment that allows multiple servers (e.g., senders, receivers) to share CPU resources is more likely to result in the following: where the receiver may not be able to keep up with the various transmitters to which data is being transmitted. This is typically the case: when a hypervisor (e.g., PR/SM) controls the dispatch of servers on the various available shared processors. The problem is compounded when there are multiple levels of hypervisor between the transmitter and the shared CPU resource. This is for example the following case: when the transmitter is atWhen the virtual machine under the control runs in the virtual machine,also running in logical partitions. Here, both hypervisors dispatch servers to allow them to replenish empty buffers in time.

Timely dispatch of receivers is not an issue when sufficient CPU resources are provided. Isochronous data transfers are only interrupted when CPU resources become limited in the short or long term. Thus, in accordance with one aspect of the present invention, a transmitter is able to utilize synchronous low latency data transfers in an unconstrained CPU environment, while eliminating the associated drawbacks and overhead when CPU resources become constrained. This is achieved by: when the receiver cannot keep up with the transmitter, the communication protocol is converted from synchronous to asynchronous. In one embodiment, the synchronous to asynchronous protocol conversion is performed automatically without any push back to the sender (i.e., the sender does not need to perform any operations at the time of conversion). This eliminates the need for the sender to perform any type of recovery process, or to block or suspend data transmissions to other receivers, when CPU resources become limited for a particular receiver. Furthermore, it allows synchronous communication to automatically continue to a previously restricted receiver.

According to one aspect of the invention, a capability is provided for a sender to queue data in its memory until a receiver provides an empty buffer where data can be received. To facilitate this process, one or more control structures are used, as described with reference to fig. 4. For example, the transmitter allocates an empty block of memory 400 in the transmitter memory for each pending asynchronous transmission. In one example, there may be X such blocks at any time, where X is model dependent and configurable. X denotes the number of concurrent asynchronous requests allowed by the sender. This memory block, referred to as the QDIO (queued direct input/output) asynchronous operations block (QAOB), is used to track asynchronous data transfers until the firmware completes the operation. In this example, QAOB contains only control information and not the data itself. The sender provides the block when a request to the sender that will allow optionally asynchronous execution initiates a data transfer; otherwise, it does not need to provide a control block. This enables the sender to control the maximum number of outstanding asynchronous requests. When QAOB determines that data transmission is to be performed asynchronously, QAOB itself is used only and initialized by firmware. In the case where data transfers are to be performed asynchronously, the transmitter does not have to perform any operations on the data transfer other than providing memory for QAOB. In a particular example, the QAOB is included in the SIGA instruction providing the request. The sender issues a SIGAwrite with QAOB (SIGA-wq) instruction that specifies a selected function code in a first general purpose register that indicates a writewith QAOB function. The QAOB address is specified in a fourth general register used by the instruction. The general register has 0 (when QAOB is not specified) or an absolute address of QAOB (for example, 256-byte QAOB). In response to setting the write with QAOB function code, the firmware determines whether QAOB available for asynchronous data transfer is specified in the fourth general register.

When the firmware changes the data transmission to an asynchronous protocol, it uses QAOB to track the data residing in the memory of the transmitter associated with the outbound data transmission. In which Hipersockets are used^TMIn the example of a transmission, the QAOB keeps track of the transmitter being in a memory blockAddresses and controls associated with data transfers specified in an address list (SBAL). Examples of fields extracted from the SBAL and placed in the QAOB include, for example:

● all significant SBALEs from the SBAL (e.g., the first SBALE to the SBALE with the last entry bit set). This includes the absolute buffer address and byte count of the data;

● SBAL output queue number;

● buffer numbers (e.g., 1-27) of the SBAL that initiated the request;

● meaningful SBALE entry number; and

● are used to access the memory key of the memory block specified by each meaningful SBALE.

In addition to QAOB, another control structure is used, referred to as a Completion Queue (CQ) 410. That is, in one example, when a communication queue is established, in addition to providing a QAOB, the transmitter allocates a new queue type, i.e., a completion queue, in its memory. In Hipersockets^TMThis is the new type of QDIO input queue that has SBAL but no buffer associated with SBALE. Not using this new input queue to transmit data; instead, the firmware uses it to issue a completion event to signal the transmitter that the asynchronous data transfer is complete. When the queue entry becomes "inbound ready," information about the completion event is located in the SBALE itself, which is included on the completion queue. The firmware publishes the address of the QAOB associated with the completed asynchronous data transfer in the CQ and generates an interrupt (if necessary) to signal the transmitter of the completed data transfer. At this point, the transmitter may reuse the memory associated with the completed operation for other purposes. (in one embodiment, a single completion event is issued using the SBALE. since the SBAL includes, for example, 16 SBALEs, the firmware may issue up to 16 completion events (QAOB) in a single SBAL.)

Further, in one embodiment, the firmware has another queue TPQ420 for each intended recipient that keeps track of it having outstanding data transfer requests.

Further details regarding the conversion from synchronous to asynchronous data transfers are described with reference to fig. 5A-5B. FIG. 5A illustrates one embodiment of logic used by firmware to perform translation, and FIG. 5B graphically illustrates one example of translation. Reference is made to both figures in the following discussion.

Referring to fig. 5A-5B, initially, firmware 350 receives an indication of QAOB (e.g., an address of a memory block that may be used for asynchronous data transfer) (step 500). Thus, it is known that it can perform requested data transfers asynchronously, if needed (or required). In one embodiment, the firmware may receive multiple QAOBs indicating that it may perform at most this number of data transfers asynchronously. The sender provides QAOB as a pre-authorization for the firmware-the firmware can asynchronously perform data transfer if it so chooses.

In one particular example, the QAOB is included as part of a data transmission request received by firmware from transmitter 300 (step 502). In response to receiving the data transfer request, the firmware attempts to send the data to the receiver (step 504). If the receiver is able to receive data (e.g., has an empty buffer at the receiver) (inquiry 506), the data is transmitted asynchronously (step 508) and the data transmission is complete. Thereafter, the sender may perform another data transfer, and if the sender allows asynchronous processing, the sender may include QAOB in the new request.

However, if the receiver is currently unable to receive data (e.g., the buffer status determines that there is no empty buffer at the receiver and thus the receiver is delayed in receiving data), the firmware automatically converts the data transmission from a synchronous request to an asynchronous request (assuming QAOB is provided in the request). The request is saved in a QAOB (step 510) and the QAOB is queued at a predetermined destination in the TPQ420 (step 512), for example, by placing a pointer to the QAOB on the TPQ. The QAOB now includes the content of the SBAL, so the SBAL can be used for other processing.

In one embodiment, if QAOB is not specified, the request fails or waits until the request can be sent synchronously.

In one example, the sending server is provided control in response to queuing a QAOB and has an indication to asynchronously perform the data transfer using the specified QAOB. The sending server can then immediately set up for its next data transmission and optionally allocate another QAOB if required for the subsequent data transmission.

Next, a determination is made as to whether the receiver is capable of receiving data (INQUIRY 514). For example, it is determined whether the firmware receives a signal from the receiver that it is now able to accept data (e.g., now providing an empty buffer) or whether the firmware determines that a buffer is available by checking the buffer status. In one particular example, the receiver signals the firmware using the SIGA instruction that it placed an empty buffer on its input queue. The SIGA read (SIGA-r) function code is specified in a first general register. The SIGA read function causes the firmware to transfer any pending packets from the TPQ of the receiver to the input buffer of the target.

If the receiver cannot accept the data, the firmware waits. Otherwise, if the receiver is able to receive data (e.g., has at least one empty buffer), the firmware determines if it has a pointer to QAOB on the receiver TPQ (query 518). If not, the process is complete. Otherwise, the firmware performs the data transfer using QAOB. Specifically, it forwards the data pointed to by QAOB to the receiver, placing the data in an empty buffer, and a pointer to the now filled buffer on the input queue of the receiver.

Thereafter, the firmware indicates to the transmitter that the data transfer is complete (step 520). In one example, the indication includes issuing a QAOB address associated with the completed asynchronous data transfer in the sender's completion queue 410 (fig. 5B) and generating an interrupt 550 (if necessary) to signal the sender of the completed data transfer. At this point, the transmitter may reuse the memory associated with the completed operation for other purposes. The QAOB published on the CQ includes information about asynchronous processing, including, for example, status information, completion codes, error codes, and the like.

In one particular example, when a QAOB address is published in a completion queue entry (i.e., the QAOB address is included in an SBALE located in the completion queue entry), the firmware returns the following information, for example, to a program in the QAOB:

● reflect the cause code of the results of the asynchronous I/O operation; and

● buffer status of asynchronous data transfer: "queue status-buffer N (SQBN)". This is the same value that is placed in the SLSB for the isochronous data transmission. The SQBN contains a value indicating the current state of QAOB. The state value for example comprises two parts: indicating whether the program firmware owns the first portion of the buffer; and a second portion indicating the current process state of QAOB.

Although a particular request is executed asynchronously, other requests from the sender to other receivers may be executed synchronously unless the particular receiver is delayed, for example, in receiving data. Further, other requests from the sender to the receiver are automatically restored to synchronization unless it is again determined that the receiver is delayed in receiving data. For example, the firmware attempts to send data to the receiver (as described above), and if the receiver is able to receive the data, then the data is sent synchronously. In one embodiment, even if the transfer is switched between synchronous and asynchronous, the data still takes the same FIFO order as the transfer. The firmware will transmit all queued QAOB on receiver TPQ420 before receiving any future synchronization requests from that transmitter or any other transmitter. If another isochronous data transfer is made to the receiver that already has a QAOB on its TPQ420, the firmware automatically converts the isochronous data transfer to an asynchronous request (if authorized by the sender) or the isochronous data transfer fails because there is no buffer response available. Maintaining this order avoids costly reordering processes, thereby improving the performance of the TCP/IP stack and overall CPU utilization of the receiver.

The foregoing describes in detail a capability to automatically convert an isochronous data transfer to an asynchronous data transfer in response to a processor (e.g., firmware) determining that such conversion is to occur. For example, the conversion is performed in response to the receiver being delayed in being able to receive the data (e.g., no buffer is available, slow response, etc.). Furthermore, the capability allows for automatic synchronization of other transmissions to the same receiver.

One or more aspects of this support provide this capability to adjust to transient or longer term data transfers without having to make costly retransmissions to the target destination and with minimal or no impact to other operational destinations in the network. In one aspect, a capability is provided to toggle between synchronous and asynchronous data transfers without having to push back to the sender program. In one particular example using Hipersockets Completion Queues (CQ), the device driver does not pause I/O operations (SIGA does not prevent this process). Using CQs, the write process is ignored for the moment and the sender is allowed to continue issuing other writes (SIGA (s)) to the same target or to other targets, where some writes may complete synchronously while others complete asynchronously. This non-blocking aspect makes the CQ asynchronous.

According to one aspect of the invention, data is copied from the sender to the receiver only once (without internal buffers), regardless of whether the transmission is synchronous or asynchronous.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Thus, various aspects of the invention may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system. Furthermore, various aspects of the invention may also be embodied in the form of a computer program product in one or more computer-readable media having computer-readable program code embodied in the medium.

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

Referring now to FIG. 6, in one example, a computer program product 600 includes, for instance, one or more non-transitory computer-readable storage media 602 having computer-readable program code means or logic 604 stored thereon to provide and facilitate one or more aspects of the present invention.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language, assembly language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

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

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition to the foregoing, one or more aspects of the present invention may be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of a user's environment. For example, a service provider can create, maintain, support, etc., computer code and/or computer infrastructure that performs one or more aspects of the present invention for one or more users. The service provider, in turn, may accept payment from the user, for example, according to 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 of the invention, an application may be deployed to perform one or more aspects of the invention. As one example, deploying an application comprises providing a computer infrastructure operable to perform one or more aspects of the present invention.

As yet another aspect of the present invention, a computing infrastructure may be deployed comprising integrating computer-readable code into a computer system, wherein the code in combination with the computing system is capable of performing one or more aspects of the present invention.

As yet another aspect of the present invention, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system includes a computer-readable medium, wherein the computer medium includes one or more aspects of the present invention. The code in combination with the computer system is capable of performing one or more aspects of the present invention.

While various embodiments are described above, these are only examples. For example, computing environments of other architectures may incorporate and use one or more aspects of the present invention. For example, servers other than a zEnterprise server may include, use, and/or benefit from one or more aspects of the present invention. Further, the transition from synchronous to asynchronous may be in response to considerations other than whether a buffer is available. Still further, one or more aspects of the present invention may be used to isolate any memory-to-memory transfers between memory spaces. Many other variations are possible.

Moreover, other types of computing environments may benefit from one or more aspects of the present invention. By way of example, a data processing system suitable for storing and/or executing program code will be used that includes at least two processors coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, DASD, magnetic tape, CDs, DVDs, thumb drives, and other storage media) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the available types of network adapters.

Referring to FIG. 7, representative components of a host computer system 5000 to implement one or more aspects of the present invention are depicted. The representative host computer 5000 includes one or more CPUs 5001 in communication with computer memory (i.e., central storage) 5002, and I/O interfaces to storage media devices 5011 and networks 5010 for communicating with other computers or SANs and the like. The CPU5001 conforms to an architecture having an architectural instruction set and architectural functions. The CPU5001 may have Dynamic Address Translation (DAT) 5003 for translating program addresses (virtual addresses) to real addresses of memory. A DAT typically includes a Translation Lookaside Buffer (TLB) 5007 for caching translations so that later accesses to a block of computer memory 5002 do not require the delay of address translation. Typically, a cache 5009 is used between the computer memory 5002 and the processor 5001. The cache 5009 may be hierarchical, having a large cache available to more than one CPU, and smaller, faster (lower level) caches between the large cache and each CPU. In some embodiments, the lower level cache is split to provide separate lower level caches for instruction fetching and data accesses. In one embodiment, instructions are fetched from memory 5002 by instruction fetch unit 5004 via cache 5009. The instructions are decoded in the instruction decode unit 5006 and (in some embodiments, with other instructions) sent to the one or more instruction execution units 5008. Typically, several execution units 5008 are used, such as an arithmetic execution unit, a floating point execution unit, and a branch instruction execution unit. The instruction is executed by the execution unit, accessing operands from registers or memory specified by the instruction, as needed. If an operand is to be accessed (loaded or stored) from memory 5002, load/store unit 5005 typically handles the access under the control of the instruction being executed. The instructions may be executed in hardware circuitry, or in internal microcode (firmware), or in a combination thereof.

Note that the computer system includes information in local (or main) memory, as well as addressing, protection, and reference and change records. Some aspects of addressing include address format, concept of address space, various types of addresses, and the manner in which one type of address is translated to another type of address. Some main memories include permanently allocated memory locations. The main memory provides the system with fast-access data storage that is directly addressable. Both data and programs will be loaded into main memory (from the input device) before they can be processed.

The main memory may include one or more smaller, faster-access cache memories, sometimes referred to as caches. The cache is typically physically associated with the CPU or I/O processor. The effects of the physical structure and use of different storage media are not typically observed by a program except in terms of performance.

Separate caches for instruction and data operands may be maintained. Information in a cache may be maintained as contiguous bytes on integer boundaries called cache blocks or cache lines (or simply lines). The model may provide an EXTRACT CACHE ATTRIBUTE instruction that returns the byte size of the CACHE line. The model may also provide PREFETCH DATA (prefetch data) and PREFETCH DATA relative issue (prefetch longer data) instructions that enable prefetching for storage into a data or instruction cache, or release of data from the cache.

The memory is considered to be a long horizontal string of bits. For most operations, accesses to memory are made in left-to-right order. The bit string is subdivided into units of eight bits. The eight-bit unit is called a byte, which is the basic building block for all information formats. Each byte location in memory is identified by a unique non-negative integer, which is the address of the byte location, or simply, the byte address. Adjacent byte positions have consecutive addresses, starting at 0 on the left and proceeding in left to right order. The address is an unsigned binary integer and is 24, 31 or 64 bits.

Information is transferred between the memory and the CPU or channel subsystem one byte or a group of bytes at a time. Unless otherwise specified, e.g. inA group of bytes in memory is addressed by the leftmost byte of the group. The number of bytes in a group may be implied or explicitly specified by the operation to be performed. When used in CPU operations, a group of bytes is called a field. Within each group of bytes, e.g. inIn which bits are numbered in left-to-right order. In thatIn (d), the leftmost bit is sometimes referred to as the "high order" bit and the rightmost bit is referred to as the "low order" bit. However, the number of bits is not a memory address. Only bytes can be addressed. To operate on a single bit of a byte in memory, the entire byte is accessed. The bits on a byte are numbered 0 to 7 from left to right (e.g., inIn (1). The bits in the address are numbered 8-31 or 40-63 for a 24-bit address, 1-31 or 33-63 for a 31-bit address, and 0-63 for a 64-bit address. In any other fixed length format of a plurality of bytes, the bits that make up the format are numbered consecutively starting from 0. For error detection, and preferably for correction, one or more check bits may be passed with each byte or group of bytes. Such check bits are automatically generated by the machine and cannot be directly controlled by the program. The storage capacity is expressed in number of bytes. When the memory operandWhen the length of a field is implied by the opcode of an instruction, the field is said to have a fixed length, which may be one, two, four, eight, or sixteen bytes. Larger fields may be implied for some instructions. When the length of the memory operand field is not implied but explicitly indicated, the field is said to have a variable length. Variable length operands may be variable in length in increments of one byte (or for some instructions, in multiples of two bytes or other multiples). When information is placed in memory, only the contents of those byte locations included in the specified field are replaced, even though the width of the physical path to memory may be greater than the length of the field being stored.

Some units of information are located on integer limits in memory. For a unit of information, a bound is said to be an integer when its memory address is a multiple of the length of the unit in bytes. Special names are given to fields of 2, 4,8 and 16 bytes on the integer limit. A halfword is a set of two consecutive bytes on a two-byte boundary and is the basic building block of instructions. A word is a set of four consecutive bytes on a four-byte boundary. A doubleword is a set of eight consecutive bytes on an eight-byte boundary. A quad word (quadword) is a set of 16 contiguous bytes on a 16-byte boundary. When a memory address specifies a halfword, a word, a doubleword, and a quadword, the binary representation of the address includes one, two, three, or four rightmost zero bits, respectively. The instruction will be on a two-byte integer boundary. Most instructions have memory operands that do not have boundary alignment requirements.

On devices that implement separate caches for instructions and data operands, significant delays may be experienced if a program stores in a cache line and an instruction is subsequently fetched from the cache line, regardless of whether the store alters the subsequently fetched instruction.

In one embodiment, the invention may be implemented by software (sometimes referred to as licensed internal code, firmware, microcode, millicode, picocode, etc., any of which would be consistent with the invention). Referring to fig. 7, software program code embodying the present invention is typically accessed by the processor 5001 of the host system 5000 from a long-term storage media device 5011, such as a CD-ROM drive, tape drive or hard drive. The software program code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard drive, or a CD-ROM. The code may be distributed on such media, or may be distributed to users of other computer systems from the computer memory 5002 or storage devices of one computer system over the network 5010 for use by users of such other systems.

The software program code includes an operating system which controls the function and interaction of the various computer components and one or more application programs. The program code is typically paged from the storage media device 5011 to the relatively higher speed computer memory 5002 where it is available to the processor 5001. Techniques and methods for embodying software program code in memory, on physical media, and/or distributing software code via networks are well known and will not be discussed further herein. When the program code is created and stored on a tangible medium, including but not limited to an electronic memory module (RAM), flash memory, Compact Discs (CDs), DVDs, tapes, etc., it is often referred to as a "computer program product". The computer program product medium is typically readable by processing circuitry preferably located in a computer system for execution by the processing circuitry.

FIG. 8 illustrates a representative workstation or server hardware system in which the present invention may be implemented. The system 5020 of fig. 8 includes a representative base computer system (base computer system) 5021, such as a personal computer, workstation or server, including optional peripherals. A basic computer system 5021 comprises one or more processors 5026 and a bus used to connect and enable communication between the processors 5026 and other components of the system 5021, in accordance with known techniques. The bus connects the processor 5026 to memory 5025 and long-term storage 5027 which may comprise a hard disk drive (including any of magnetic media, CD, DVD, and flash memory, for example) or a tape drive, for example. The system 5021 can also include a user interface adapter that connects the microprocessor 5026 via the bus to one or more interface devices, such as a keyboard 5024, a mouse 5023, a printer/scanner 5030, and/or other interface devices, which can be any user interface device, such as a touch-sensitive screen, a digital input pad (digitized entry pad), etc. The bus may also connect a display device 5022, such as an LCD screen or monitor, to the microprocessor 5026 via a display adapter.

The system 5021 may communicate with other computers or networks of computers via a network adapter capable of communicating 5028 with a network 5029. Exemplary network adapters are communications channels, token ring, Ethernet or modems. Alternatively, the system 5021 may communicate using a wireless interface, such as a CDPD (cellular digital packet data) card. The system 5021 can be associated with such other computers in a Local Area Network (LAN) or a Wide Area Network (WAN), or the system 5021 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as suitable communication hardware and software, are known in the art.

Fig. 9 illustrates a data processing network 5040 in which one or more aspects of the present invention may be implemented. The data processing network 5040 may include a plurality of separate networks, such as wireless and wired networks, each of which may include a plurality of separate workstations 5041, 5042, 5043, 5044. Further, those skilled in the art will appreciate that one or more LANs may be included, wherein a LAN may include a plurality of intelligent workstations coupled to a host processor.

Still referring to FIG. 9, the network may also include mainframe computers or servers, such as a gateway computer (client server 5046) or application server (remote server 5048, which may access a data repository and may also be accessed directly from a workstation 5045). The gateway computer 5046 serves as a point of entry into each individual network. When connecting one networking protocol to another, a gateway is required. The gateway 5046 may preferably be coupled to another network (e.g., the internet 5047) by a communications link. Gateway 504 may also be coupled using a communication link6 are directly coupled to one or more workstations 5041, 5042, 5043, 5044. IBM eServer, available from International Business machines corporation, may be utilized^TMSystemThe server implements a gateway computer.

Referring concurrently to fig. 8 and 9, software programming code which may embody one or more aspects of the present invention may be accessed by the processor 5026 of the system 5020 from long-term storage media 5027, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard drive, or a CD-ROM. The code may be distributed on such media, or from the memory or storage of one computer system over a network to users 5050, 5051 of other computer systems for use by users of such other systems.

Alternatively, the programming code may be embodied in the memory 5025 and accessed by the processor 5026 using a processor bus. Such programming code includes an operating system which controls the function and interaction of the various computer components and one or more application programs 5032. Program code is typically paged from the storage medium 5027 to high-speed memory 5025 where it is available for processing by the processor 5026. Techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be discussed further herein. Program code, when created and stored on tangible media, including but not limited to electronic memory modules (RAM), flash memory, Compact Discs (CDs), DVDs, tapes, etc., is commonly referred to as a "computer program product". The computer program product medium is typically readable by a processing circuit, preferably located in a computer system, for execution by the processing circuit.

The cache most readily used by the processor (which is typically faster and smaller than the other caches of the processor) is the lowest level (L1 or level 1) cache, and main storage (main memory) is the highest level cache (L3 if there are three levels). The lowest level cache is often divided into an instruction cache (I-cache) that holds the machine instructions to be executed, and a data cache (D-cache) that holds the data operands.

Referring to FIG. 10, an exemplary processor embodiment is shown for the processor 5026. Typically, one or more levels of cache 5053 are used to buffer memory blocks in order to improve processor performance. The cache 5053 is a cache buffer that holds cache lines of memory data that are likely to be used. Typical cache lines are 64, 128 or 256 bytes of memory data. A separate cache is typically used for caching instructions rather than data. Cache coherency (synchronization of copies of lines in memory and cache) is typically provided by various "snoop" algorithms well known in the art. The main memory 5025 of the processor system is commonly referred to as a cache. In a processor system having 4 levels of cache 5053, main memory 5025 is sometimes referred to as a level 5 (L5) cache, because it is typically faster and maintains only a portion of the non-volatile storage (DASD, tape, etc.) that is available to the computer system. Main memory 5025 may "cache" pages of data paged in and out of main memory 5025 by the operating system.

Program counter (instruction counter) 5061 keeps track of the address of the current instruction to be executed.The program counter in the processor is 64 bits and may be truncated to 31 or 24 bits to support the previous addressing limits. The program counter is typically embodied in the computer's PSW (program status word) so that it persists during context transitions. Thus, an in-progress program having a program counter value may be interrupted by, for example, an operating system (context switch from a program environment to an operating system environment). The PSW of a program maintains a program counter value when the program is inactive, and while the operating system is executing,the program counter (in the PSW) of the operating system is used. Typically, the program counter is incremented by an amount equal to the number of bytes of the current instruction. RISC (reduced instruction set computing) instructions are typically of fixed length, while CISC (Complex instruction set computing) instructions are typically of variable length.Is a CISC instruction having a length of 2, 4 or 6 bytes. Program counter 5061 is modified by, for example, a context switch operation or a branch taken operation of a branch instruction. In a context switch operation, the current program counter value is saved in a program status word along with other status information about the program being executed (such as condition codes), and a new program counter value is loaded and points to the instruction of the new program module to be executed. A branch taken operation is performed to allow the program to make a decision or loop within the program by loading the result of the branch instruction into the program counter 5061.

Typically, instructions are fetched on behalf of the processor 5026 using an instruction fetch unit 5055. The fetch unit may fetch a "next sequence of instructions," a target instruction of a branch taken instruction, or a first instruction of a context-switched program. Present instruction fetch units typically use prefetch techniques to speculatively prefetch instructions based on the likelihood that the prefetched instructions will be used. For example, the fetch unit may fetch 16 bytes of instructions, including the next sequential instruction and additional bytes of further sequential instructions.

The fetched instructions are then executed by the processor 5026. In one embodiment, the fetched instructions are passed to the dispatch unit 5056 of the fetch unit. The dispatch unit decodes the instructions and forwards information about the decoded instructions to the appropriate units 5057, 5058, 5060. The execution unit 5057 will typically receive information from the instruction fetch unit 5055 regarding decoded arithmetic instructions, and will perform arithmetic operations on operands according to the opcode of the instruction. Operands are preferably provided to the execution unit 5057 from storage 5025, architectural registers 5059, or from an immediate field (immediate field) of the instruction being executed. The results of the execution, when stored, are stored in storage 5025, registers 5059, or other machine hardware (such as control registers, PSW registers, etc.).

The processor 5026 typically has one or more units 5057, 5058, 5060 for performing the function of instructions. Referring to fig. 11A, an execution unit 5057 may communicate with architected general registers 5059, decode/dispatch unit 5056, load store unit 5060, and other 5065 processor units via interface logic 5071. The execution unit 5057 may use several register circuits 5067, 5068, 5069 to hold information that the Arithmetic Logic Unit (ALU) 5066 is to operate on. The ALU performs arithmetic operations such as add, subtract, multiply, divide, and logical operations such as AND, OR, and exclusive OR (XOR), rotate, and shift. Preferably, the ALU supports specialized operations that are design dependent. Other circuitry may provide other architectural tools 5072, including condition codes and recovery support logic, for example. Typically, the results of the ALU operations are held in output register circuitry 5070, which may forward the results to a variety of other processing functions. There are many processor unit arrangements and this description is intended only to provide a representative understanding of one embodiment.

For example, ADD instructions will be executed in an execution unit 5057 having arithmetic and logical functionality, while floating point instructions will be executed in floating point execution with dedicated floating point capabilities, for example. Preferably, the execution unit operates on the operands identified by the instruction by executing the function defined by the opcode on the operands. For example, an ADD instruction may be executed by the execution unit 5057 on operands found in two registers 5059 identified by register fields of the instruction.

The execution unit 5057 performs arithmetic addition on two operands and stores the result in a third operand, which may be a third register or one of the two source registers. The execution unit preferably utilizes an Arithmetic Logic Unit (ALU) 5066, which can perform a variety of logical functions, such as shifting, rotating, and, OR, XOR, and any of a variety of algebraic functions, including addition, subtraction, multiplication, and division. Some ALUs 5066 are designedFor scalar operations, some are for floating point. Depending on the architecture, the data may be big endien (where the least significant byte is at the most significant byte address) or little endien (where the least significant byte is at the least significant byte address). IBMIs the large end. Depending on the architecture, the signed field may be sign and magnitude, 1's complement, or 2's complement. A 2's complement number is advantageous in that the ALU does not need to design subtraction capability because only addition in the ALU is required, whether negative or positive in the 2's complement. The numbers are typically described in shorthand, where a 12-bit field defines the address of a block of 4096 bytes, and are typically described as a 4Kbyte block, for example.

Referring to FIG. 11B, branch instruction information for executing a branch instruction is typically sent to a branch unit 5058, which often predicts branch outcome before other conditional operations are completed, using a branch prediction algorithm such as a branch history table 5082. Before the conditional operation completes, the target of the current branch instruction will be fetched and speculatively executed. When the conditional operation completes, the speculatively executed branch instruction is either completed or discarded based on the condition of the conditional operation and the speculative result. Typical branch instructions may test the condition code and branch to a target address if the condition code satisfies the branch requirement of the branch instruction, the branch address may be calculated based on a number including, for example, a number found in a register field or an immediate field of the instruction. The branch unit 5058 may utilize an ALU5074 having a plurality of input register circuits 5075, 5076, 5077 and an output register circuit 5080. The branch unit 5058 may communicate with, for example, general registers 5059, decode dispatch unit 5056, or other circuitry 5073.

Execution of a set of instructions may be interrupted for a number of reasons including, for example, a context switch initiated by the operating system, a program exception or error causing a context switch, an I/O interrupt signal causing a context switch, or multi-threaded activity of multiple programs (in a multi-threaded environment). Preferably, the context switch action saves state information about the currently executing program and then loads state information about another program being invoked. The state information may be stored, for example, in hardware registers or memory. The state information preferably includes a program counter value pointing to the next instruction to be executed, condition codes, memory translation information and architectural register contents. The context translation activities may be implemented by hardware circuitry, application programs, operating system programs, or firmware code (microcode, pico code, or Licensed Internal Code (LIC)), alone or in combination.

The processor accesses operands according to the instruction defined method. An instruction may provide an immediate operand using the value of a portion of the instruction, may provide one or more register fields that explicitly point to general purpose registers or special purpose registers (e.g., floating point registers). The instruction may utilize the implied register determined by the opcode field as an operand. The instruction may utilize memory locations for operands. The memory location of the operand may be provided by a register, an immediate field, or a combination of a register and an immediate field, such asIllustrated by the long displacement facility (facility), where the instruction defines a base register, an index register, and an immediate field (displacement field) that are added together to provide, for example, the address of an operand in memory. Unless otherwise indicated, a location herein typically means a location in main memory (main storage).

Referring to fig. 11C, a processor accesses a memory using a load/store unit 5060. The load/store unit 5060 may perform a load operation by obtaining the address of a target operand in memory 5053 and loading the operand into a register 5059 or other memory 5053 location, or may perform a store operation by obtaining the address of a target operand in memory 5053 and storing data obtained from a register 5059 or another memory 5053 location in the target operand location in memory 5053. The load/store unit 5060 may be speculative and may access memory in an out-of-order relative to instruction order, but the load/store unit 5060 will maintain the appearance to a program that instructions are executed in order. The load/store unit 5060 may communicate with general registers 5059, decryption/dispatch unit 5056, cache/memory interface 5053 or other elements 5083, and includes various register circuits, ALUs 5085 and control logic 5090 to calculate memory addresses and provide pipeline order to keep operations in order. Some operations may be out of order, but the load/store unit provides functionality such that operations that are performed out of order appear to the program as if they were performed in order, as is well known in the art.

Preferably, the addresses that are "seen" by the application are commonly referred to as virtual addresses. Virtual addresses are sometimes referred to as "logical addresses" and "effective addresses". These virtual addresses are virtual in that they are redirected to a physical memory location by one of a variety of Dynamic Address Translation (DAT) techniques including, but not limited to, simply prefixing the virtual address with an offset value, translating the virtual address via one or more translation tables, preferably including at least one segment table and a page table (alone or in combination), preferably the segment table having an entry pointing to the page table. In thatA translation hierarchy is provided that includes a region first table, a region second table, a region third table, a segment table, and an optional page table. The performance of address translation is typically improved by utilizing a Translation Lookaside Buffer (TLB) that includes entries that map virtual addresses to associated physical memory locations. When a DAT translates a virtual address using a translation table, an entry is created. Subsequent use of the virtual address may then utilize the entry of the fast TLB, rather than the slow sequential translation table access. TLB content may be managed by a plurality of replacement algorithms including LRU (least recently used).

Where the processors are processors of a multi-processor system, each processor has the responsibility of maintaining shared resources, such as I/O, caches, TLBs, and memory, which are interlocked to achieve coherency. Typically, "snooping" techniques will be used to maintain cache coherency. In a snooping environment, each cache line may be marked as being in one of a shared state, an exclusive state, a changed state, an invalid state, etc., to facilitate sharing.

The I/O unit 5054 (fig. 10) provides the processor with means for attaching to peripheral devices including, for example, tapes, disks, printers, displays, and networks. The I/O cells are typically presented to the computer program by a software driver. In a location such as fromSystem ofThe channel adapter and the open system adapter are I/O units of the mainframe computer that provide communication between the operating system and peripheral devices.

Moreover, other types of computing environments may benefit from one or more aspects of the present invention. By way of example, an environment may include an emulator (e.g., software or other emulation mechanisms), in which a particular architecture (including, for example, instruction execution, architectural functions such as address translation, and architectural registers) or a subset thereof is emulated (e.g., in a native computer system having a processor and memory). In such an environment, one or more emulation functions of the emulator can implement one or more aspects of the present invention, even though the computer executing the emulator may have a different architecture than the capabilities being emulated. As one example, in emulation mode, a particular instruction or operation being emulated is decoded, and the appropriate emulation function is established to implement the single instruction or operation.

In an emulation environment, a host computer includes, for example, memory to store instructions and data; an instruction fetch unit to fetch instructions from memory and, optionally, to provide local buffering of fetched instructions; an instruction decode unit to receive the fetched instruction and determine a type of instruction that has been fetched; and an instruction execution unit to execute the instruction. Execution may include loading data from memory to a register; storing data from the register back to the memory; or perform some type of arithmetic or logical operation as determined by the decode unit. In one example, each unit is implemented in software. For example, the operations performed by the units are implemented as one or more subroutines in emulator software.

More specifically, in a mainframe computer, programmers (typically today's "C" programmers) typically use architected machine instructions through compiler applications. The instructions stored in the storage medium may be inEither locally in a server or in a machine executing other architectures. They may be present and futureMainframe computer server andother machines (e.g., Power Systems servers and Systems)Server) is simulated. They can be used byAMD^TMEtc. are executed in machines running Linux on various machines of manufactured hardware. Except that atExecuting on this hardware, Linux can also be used for machines using the programs described by TurboHercules (www.trubohercules.com /), Hercules (www.hercules-390. org /), UMX orSimulations provided by FSI (Fundamental Software, Inc), where the general execution is in simulation mode. In emulation mode, emulation software is executed by the native processor to emulate the architecture of the emulated processor.

The native processor typically executes emulation software, which includes firmware or a native operating system, to execute an emulation program of the emulated processor. The emulation software is responsible for fetching and executing instructions of the emulated processor architecture. The emulation software maintains an emulated program counter to keep track of instruction boundaries. The emulation software can fetch one or more emulated machine instructions at a time and convert the one or more emulated machine instructions into a corresponding set of native machine instructions for execution by the native processor. These translated instructions may be cached so that faster translations may be accomplished. The emulation software will maintain the architectural rules of the emulated processor architecture to ensure that the operating system and applications written for the emulated processor operate correctly. Furthermore, the emulation software will provide resources determined by the emulated processor architecture, including but not limited to control registers, general purpose registers, floating point registers, dynamic address translation functions including, for example, segment and page tables, interrupt mechanisms, context translation mechanisms, time of day (TOD) clocks, and architectural interfaces to the I/O subsystem, such that operating systems or applications designed to run on the emulated processor may run on the native processor with the emulation software.

The particular instruction being emulated is decoded and a subroutine is called to perform the function of that single instruction. The emulation software functions that emulate the functions of an emulated processor are implemented, for example, in a "C" subroutine or driver, or by other methods that provide drivers for specific hardware, as will be understood by those skilled in the art after understanding the description of the preferred embodiments. Including, but not limited to, U.S. patent No. 5,551,013 entitled "Multiprocessor for Hardware Emulation" to beaussoleil et al; and U.S. patent certificate number 6,009,261 entitled "Preprocessing of Stored Target Instructions for simulating an incorporated instruction on a Target Processor" to Scalazi et al; and U.S. patent document No. 5,574,873 entitled "Decoding Guest Instructions to direct Access orientations angles of the Guest Instructions" to Davidian et al; and U.S. patent certificate No. 6,308,255 entitled "symmetric Multiprocessing Bus and chip Used for multiprocessor support Non-Native Code to Run in a System" to Gorishek et al; and U.S. patent document No. 6,463,582 entitled "Dynamic Optimizing Object code translator for Architecture implementation and Dynamic Optimizing Object code Translation Method" by Lethin et al; and U.S. patent certificate No. 5,790,825 entitled "Method for simulating Guest instruments" by Eric Traut for Host computer through Dynamic reconfiguration of Host instruments "; as well as numerous other patents, show various known ways to implement emulation of instruction formats architected for different machines for a target machine available to those skilled in the art.

In fig. 12, an example of an emulated host computer system 5092 is provided that emulates a host computer system 5000' of a host architecture. In the emulated host computer system 5092, the host processor (CPU) 5091 is an emulated host processor (or virtual host processor) and includes an emulated processor 5093 having a different native instruction set architecture than the processor 5091 of the host computer 5000'. The emulation host computer system 5092 has a memory 5094 accessible by an emulation processor 5093. In the exemplary embodiment, memory 5094 is partitioned into a host computer memory 5096 portion and an emulation routines 5097 portion. Host computer memory 5096 is available to programs emulating host computer 5092, according to the host computer architecture. The emulation processor 5093 executes native instructions of an architected instruction set of a different architecture than the emulated processor 5091 (i.e., native instructions from the emulated program processor 5097), and may access host instructions for execution from programs in the host computer memory 5096 by using one or more instructions obtained from a sequence and access/decode routine that may decode the accessed host instructions to determine a native instruction execution routine for emulating the function of the accessed host instructions. Other tools defined for the host computer system 5000' architecture may be emulated by the architecture tool routines, including such tools as general purpose registers, control registers, dynamic address translation and I/O subsystem support and processor caches. The emulation routine may also take advantage of functions available in the emulation processor 5093, such as dynamic translation of general purpose registers and virtual addresses, to improve the performance of the emulation routine. Specialized hardware and offload engines may also be provided to assist the processor 5093 in emulating the functionality of the host computer 5000'.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the 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 the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (20)

1. A computer program product for facilitating communication in a communication environment, the computer program product comprising:

a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method comprising:

obtaining, by a processor of the communication environment, a pre-authorization from a sender of the communication environment to convert from synchronous data transfer to asynchronous data transfer;

obtaining, by the processor, a request from the transmitter to transmit data to a receiver of the communication environment;

initiating, by the processor, sending the data to the receiver, wherein the initiating employs the synchronous data transmission;

determining, by the processor, that the synchronous data transmission is to be converted to an asynchronous data transmission; and

responsive to the determination, automatically converting, by the processor, the synchronous data transfer to the asynchronous data transfer to complete sending the data to the receiver, wherein the automatic conversion is independent of operations performed by the sender other than the pre-authorization.

2. The computer program product of claim 1, wherein the determining comprises determining that the receiver is delayed in being able to receive the data while the data is being transmitted, and in response thereto, automatically converting the synchronous data transfer to the asynchronous data transfer to complete the transmission of the data while the receiver is able to receive the data.

3. The computer program product of claim 2, wherein the pre-authorization comprises obtaining an indication of a memory block to track the asynchronous data transfer.

4. The computer program product of claim 3, wherein the automatic conversion comprises:

storing the request in the memory block;

queuing the memory block to a queue of the receiver;

determining that the receiver is capable of receiving the data; and

transmitting the data to the receiver using the memory block.

5. The computer program product of claim 4, wherein determining that the receiver is capable of receiving the data comprises determining that the receiver has an empty buffer for receiving the data.

6. The computer program product of claim 4, wherein the method further comprises indicating completion of transmission to the sender.

7. The computer program product of claim 6, wherein the indicating completion comprises posting an address of the memory block on a completion queue in memory accessible to the sender.

8. The computer program product of claim 7, wherein the method further comprises generating an interrupt to the sender in response to posting the address on the completion queue.

9. The computer program product of claim 2, wherein determining that the receiver is delayed comprises determining that a receiver buffer is not available to receive the data.

10. The computer program product of claim 1, wherein the method further comprises obtaining another request from the sender to be synchronously sent to another receiver before completing the asynchronous sending of the request to the receiver.

11. The computer program product of claim 1, wherein the method further comprises receiving one or more other requests from the sender prior to completing the asynchronous sending of the data to the receiver, wherein the data of the one or more other requests may be sent to one or more receivers synchronously or asynchronously.

12. The computer program product of claim 1, wherein the method further comprises maintaining a data arrival order at the receiver in response to transitioning from the synchronous data transfer to the asynchronous data transfer.

13. A computer system for facilitating communications in a communications 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 a processor of the communication environment, a pre-authorization from a sender of the communication environment to convert from synchronous data transfer to asynchronous data transfer;

obtaining, by the processor, a request from the transmitter to transmit data to a receiver of the communication environment;

initiating, by the processor, sending the data to the receiver, wherein the initiating employs the synchronous data transmission;

determining, by the processor, that the synchronous data transmission is to be converted to an asynchronous data transmission; and

responsive to the determination, automatically converting, by the processor, the synchronous data transfer to the asynchronous data transfer to complete sending the data to the receiver, wherein the automatic conversion is independent of operations performed by the sender other than the pre-authorization.

14. The computer system of claim 13, wherein the determining comprises determining that the receiver is delayed in being able to receive the data while the data is being sent, and in response thereto, automatically converting the synchronous data transfer to the asynchronous data transfer to complete the sending of the data while the receiver is able to receive the data.

15. The computer system of claim 14, wherein the pre-authorization comprises obtaining an indication of a memory block to track the asynchronous data transfer.

16. The computer system of claim 15, wherein the automatic conversion comprises:

storing the request in the memory block;

queuing the memory block to a queue of the receiver;

determining that the receiver is capable of receiving the data; and

transmitting the data to the receiver using the memory block.

17. The computer system of claim 16, wherein determining that the receiver is capable of receiving the data comprises determining that the receiver has an empty buffer for receiving the data.

18. The computer system of claim 16, wherein the method further comprises indicating completion of the transmission to the sender, wherein the indicating completion comprises posting an address of the memory block on a completion queue in memory accessible to the sender, and wherein the method further comprises generating an interrupt to the sender in response to posting the address on the completion queue, wherein determining that the receiver is delayed comprises determining that a receiver buffer is unavailable to receive the data.

19. A method of facilitating communication in a communication environment, the method comprising:

obtaining, by a processor of the communication environment, a pre-authorization from a sender of the communication environment to convert from synchronous data transfer to asynchronous data transfer;

obtaining, by the processor, a request from the transmitter to transmit data to a receiver of the communication environment;

initiating, by the processor, sending the data to the receiver, wherein the initiating employs the synchronous data transmission;

determining, by the processor, that the synchronous data transmission is to be converted to an asynchronous data transmission; and

responsive to the determination, automatically converting, by the processor, the synchronous data transfer to the asynchronous data transfer to complete sending the data to the receiver, wherein the automatic conversion is independent of operations performed by the sender other than the pre-authorization.

20. The method of claim 19, wherein said determining comprises determining that the receiver is delayed in being able to receive the data while the data is being transmitted, and in response thereto, automatically converting the synchronous data transfer to the asynchronous data transfer to complete the transmission of the data while the receiver is able to receive the data.