General processor instructions for performing compression / decompression operations

Abstract

The DEFLATE conversion invokes a general-purpose processor instruction. The instruction is obtained by a general-purpose processor of a computing environment. The instruction is a single architected instruction of an instruction set architecture that conforms to compression industry standards. Executing the instruction includes: based on whether the function to be performed by the instruction is a compression function or a decompression function, transforming the state of the input data between the uncompressed form of the input data and the compressed form of the input data to provide a transformed data state. Providing the transformed data state as an output for performing a task.

Description

BACKGROUND OF THE INVENTION

[0001] One or more aspects generally relate to facilitating processing within a computing environment, and more particularly to facilitating processing of compression and decompression operations.

[0002] In one or more computing environments, information is maintained in a compressed form on a storage device rather than in its original uncompressed form. The compressed form occupies fewer bytes than the original form. Thus, transmitting and maintaining the compressed form of the information requires less time and space, respectively, than performing the same function with the information in its original form.

[0003] In such an environment, an operating system (OS) provides mechanisms for performing compression and decompression operations. In one example, to provide these operations, the operating system includes a zlib open source software library that adheres to the DEFLATE standard compression technique specified in the "IETF (Internet Engineering Task Force) RFC (Request for Comments) 1951 specification". The mechanism can include a software implementation in which a user executes a number of instructions on a general-purpose processor to perform compression or decompression, or it can use a dedicated hardware implementation connected to an input / output (I / O) port of the system, where the I / O device performs the operations. SUMMARY OF THE INVENTION

[0004] The disadvantages of the prior art are overcome and additional advantages are provided by a computer program product for facilitating processing in 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 obtaining, by a general-purpose processor of the computing environment, instructions to perform one of a plurality of functions supported by the instructions. The instructions are a single architected machine instruction of an instruction set architecture compliant with compression industry standards. Executing the instructions includes: transforming a state of input data between an uncompressed form of the input data and a compressed form of the input data based on whether the function is a compression function or a decompression function to provide a transformed data state. Providing the transformed data state as an output for performing a task.

[0005] By performing compression and / or decompression functions (also known as operations) using a single architected instruction dispatched on a general-purpose processor, a substantial subset of primitive software instructions used to perform those functions is replaced by a single architected instruction. Replacing those primitive instructions with a single architected instruction reduces program complexity and eliminates the need for code that includes optimizing the primitive instructions. Overall performance is improved. In addition, by not dispatching these operations to an input / output device, the operating system avoids task switching while waiting for the input / output device to perform the operation.

[0006] For example, transforming the state of input data uses an industry-standard compression format. Compression formats include, for example, the DEFLATE compression format.

[0007] In one embodiment, the tasks are selected from a group of tasks consisting of: performing one or more operations using an output, the output including compressed data; sending the output; performing one or more operations using an output, the output including uncompressed data.

[0008] In one embodiment, the instruction includes an opcode field and a plurality of register fields, where the opcode field includes an operation code specifying an operation, and the plurality of register fields specify a plurality of registers to be used by the instruction. The plurality of registers includes one register for identifying the output operand location to be used as an output by the instruction and another register for identifying the input operand location to be used as an input by the instruction, the input depending on the function to be performed.

[0009] For example, based on the function being a compression function, the input includes data to be encoded from the input operand location to provide compressed data symbols stored to the output operand location, and based on the function being a decompression function, the input includes compressed data symbols to be decoded from the input operand location to provide uncompressed data stored to the output operand location.

[0010] When performing the compression function, the compressed form of the information is maintained on the storage device instead of the original form of the information. The compressed form of the information occupies fewer bytes than the original form. Therefore, sending and maintaining the compressed form of the information requires less time and space, respectively, compared to performing the same function in the original form of the information.

[0011] In one embodiment, the instruction also uses a selected register to indicate the function among a plurality of functions to be performed by the instruction. The plurality of functions includes a query function, a compression function, a dynamic-Huffman table generation function, and a decompression function.

[0012] In one embodiment, the instruction also uses another selected register to provide the address of a parameter block used by the instruction for one or more of the plurality of functions.

[0013] In a further aspect, the function to be performed is to generate a dynamic-Huffman table function, the execution including: based on the function being to generate a dynamic-Huffman table function, generating—a compressed representation of the dynamic-Huffman table to be used when the function to be performed at another execution of the instruction is a compression function or a decompression function.

[0014] Computer-implemented methods and systems related to one or more aspects are also described and claimed herein. Further, services related to one or more aspects are also described and may be claimed herein.

[0015] Additional features and advantages are realized through the techniques described herein. Other embodiments and aspects are described in detail herein and are considered to be part of the claimed aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] One or more aspects are specifically pointed out and clearly claimed in the claims at the end of the specification. The above and other objects, features, and advantages of one or more aspects are apparent from the following detailed description in conjunction with the accompanying drawings, in which:

[0017] Figure 1A An example of a computing environment including and using one or more aspects of the present invention is shown;

[0018] Figure 1B An example of a Figure 1A processor according to one or more aspects of the present invention is shown;

[0019] Figure 2 Another example of a computing environment including and using one or more aspects of the present invention is shown;

[0020] Figure 3A A format of a DEFLATE transform call (DFLTCC) instruction according to one aspect of the present invention is shown;

[0021] Figure 3B An example of a field of an implicit register (general-purpose register 0) used by a DEFLATE transform call instruction according to one aspect of the present invention is shown;

[0022] Figure 3C An example of a function code for a DEFLATE transform call instruction according to one aspect of the present invention is shown;

[0023] Figure 3D An example of a field of an implicit register (general-purpose register 1) used by a DEFLATE transform call instruction according to one aspect of the present invention is shown;

[0024] Figure 3E Shows an example of the content of register R1 specified by the DEFLATE transform call instruction according to one aspect of the present invention;

[0025] Figure 3F Shows an example of the content of register R1+1 used by the DEFLATE transform call instruction according to one aspect of the present invention;

[0026] Figure 3G Shows an example of the content of register R2 specified by the DEFLATE transform call instruction according to one aspect of the present invention;

[0027] Figure 3H Shows an example of the content of register R2+1 used by the DEFLATE transform call instruction according to one aspect of the present invention;

[0028] Figure 3I Shows an example of the content of register R3 specified by the DEFLATE transform call instruction according to one aspect of the present invention;

[0029] Figure 3J Shows an example of the content of the parameter block used by the DFLTCC-QAF (Query Available Function) function of the DEFLATE transform call instruction according to one aspect of the present invention;

[0030] Figure 3K Shows an example of the content of the parameter block used by the DFLTCC-GDHT (Generate Dynamic-Huffman Table) function of the DEFLATE transform call instruction according to one aspect of the present invention;

[0031] Figure 3L Shows an example of the content of the parameter block used by the DFLTCC-CMPR (Compress) and DFLTCC-XPND (Expand) functions of the DEFLATE transform call instruction according to one aspect of the present invention;

[0032] Figure 4 Shows an example of a sub-byte boundary according to one or more aspects of the present invention;

[0033] Figures 5A - 5C Shows an example demonstrating how the sub-byte boundary applies to the DFTLCC-CMPR function according to one aspect of the present invention;

[0034] Figure 6 Shows an example of an uncompressed data block according to one aspect of the present invention;

[0035] Figure 7Shows an example of a block with compressed data using a fixed - Huffman table (FHT) according to one aspect of the present invention;

[0036] Figure 8 Shows an example of a block with compressed data using a dynamic - Huffman table (DHT) according to one aspect of the present invention;

[0037] Figure 9 Shows an example of a compressed data set in a memory according to one aspect of the present invention;

[0038] Figure 10 Shows an example of a sample program for compressing data into three blocks of a compressed data set according to one aspect of the present invention;

[0039] Figure 11 Shows an example of the parameter block content of the DFLTCC - CMPR function acting on the first compressed data block of a data set according to one aspect of the present invention;

[0040] Figure 12 Shows an example of the parameter block content of the DFLTCC - CMPR function acting on the second compressed data block of a data set according to one aspect of the present invention;

[0041] Figure 13 Shows an example of a sample program for decompressing data in a compressed data set according to one aspect of the present invention;

[0042] Figures 14A - 14C Shows an example of an in - line history buffer before and after multiple executions of DFLTCC - CMPR according to one aspect of the present invention;

[0043] Figures 15A - 15E Shows an example of a circular history buffer before and after multiple executions of DFLTCC according to one aspect of the present invention;

[0044] Figures 16A - 16C Shows an example of an in - line history buffer before and after multiple executions of DFLTCC - XPND according to one aspect of the present invention;

[0045] Figure 17 Shows an example of using a DEFLATE transform call instruction according to one aspect of the present invention;

[0046] Figure 18 Shows an example of using a circular history buffer according to one aspect of the present invention;

[0047] Figures 19A - 19B Shows an example of facilitating processing within a computing environment according to one aspect of the present invention;

[0048] Figure 20A Another example of a computing environment that includes and uses one or more aspects of the present invention is shown;

[0049] Figure 20B is shown Figure 20A further details of the memory of;

[0050] Figure 21 An embodiment of a cloud computing environment is shown; and

[0051] Figure 22 An example of an abstract model layer is shown. Detailed Description

[0052] In accordance with one aspect of the present invention, an ability to facilitate processing in a computing environment is provided. As an example, a single instruction (e.g., a single architected hardware machine instruction at a hardware / software interface) is provided to perform a function (also referred to as an operation) such as a compression or decompression function to compress and / or decompress (also referred to as deflate) data. The instruction is part of a general-purpose processor instruction set architecture (ISA) dispatched by a program (e.g., an operating system or a user program) on a general-purpose processor. By using ISA instructions for compression / decompression, the operating system does not have to perform a task switch for executing the compression / decompression operation, thereby saving execution cycles. Further, by using a single instruction to compress and / or decompress data, the execution time within a processor (such as a general-purpose processor) is reduced.

[0053] In one example, the instruction performs compression and decompression operations that conform to an industry standard (referred to as the DEFLATE standard), and the instruction is referred to as a DEFLATE Conversion Call instruction. The DEFLATE standard includes a description of compressed data symbols for duplicate strings in the original form of the data (the uncompressed form of the data). Such symbols include pointers and lengths of duplicate strings that describe the position and length of a previously processed duplicate string relative to the current position of the data being processed. The previously processed data in uncompressed form is referred to as history. In one example, the history is a continuous number of bytes in memory, and the number of bytes can be as large as, for example, 32K bytes.

[0054] Refer to Figure 1ADescribes an embodiment of a computing environment that includes and uses one or more aspects of the present invention. Computing environment 100 includes, for example, a processor 102 (e.g., a central processing unit), a memory 104 (e.g., main memory; also referred to as system memory, main storage device, central storage device, storage), and one or more input / output (I / O) devices and / or interfaces 106 coupled to each other via, for example, one or more buses 108 and / or other connections.

[0055] In one example, processor 102 is based on the hardware architecture provided by International Business Machines Corporation of Armonk, New York, USA, and is part of a server, such as part of a server that is also provided by International Business Machines Corporation and implements the z / Architecture hardware architecture. An embodiment of the z / Architecture hardware architecture is described in a publication entitled "z / Architecture Principles of Operation" (IBM Publication No. SA22-7832-11, 12 th edition, September 2017), which is hereby incorporated by reference in its entirety. However, the z / Architecture hardware architecture is just an exemplary architecture; other architectures and / or other types of computing environments may include and / or use one or more aspects of the present invention. In one example, the processor executes an operating system, such as an operating system also provided by International Business Machines Corporation.

[0056] Processor 102 includes a plurality of functional components for executing instructions. As Figure 1B shown, these functional components include, for example, an instruction fetch component 120 for fetching instructions to be executed; an instruction decode unit 122 for decoding the fetched instructions to obtain the operands of the decoded instructions; an instruction execution component 124 for executing the decoded instructions; a memory access component 126 for accessing memory for instruction execution when necessary; and a write-back component 130 for providing the results of the executed instructions. According to one or more aspects of the present invention, one or more of these components may include at least a portion of one or more other components for compression / decompression processing (or other processing that may use one or more of the more aspects of the present invention), or have access to one or more other components for compression / decompression processing (or other processing that may use one or more of the more aspects of the present invention) as described herein. The one or more other components include, for example, a compression / decompression component (or other component) 136.

[0057] Reference Figure 2 Describes another example of a computing environment that includes and uses one or more aspects of the present invention. In one example, the computing environment is based on the z / Architecture hardware architecture; however, the computing environment can be based on other architectures provided by International Business Machines Corporation or other companies.

[0058] Refer to Figure 2 , in one example, the computing environment includes a Central Electronic Complex (CEC) 200. The CEC 200 includes a plurality of components, such as a memory 202 (also referred to as system memory, main memory, central storage device, storage device) coupled to one or more processors (also referred to as Central Processing Units (CPUs)) 204 and an input / output subsystem 206.

[0059] The memory 202 includes, for example, one or more logical partitions 208, a hypervisor 210 that manages the logical partitions, and processor firmware 212. An example of the hypervisor 210 is the Processor Resource / System Manager (PR / SM TM ) hypervisor provided by International Business Machines Corporation of Armonk, New York, USA. As used herein, firmware includes, for example, the microcode of the processor. It includes, for example, hardware-level instructions and / or data structures used in the implementation of higher-level machine code. In one embodiment, it includes, for example, proprietary code typically delivered in microcode form, the microcode including trusted software or microcode specific to the underlying hardware, controlling the operating system's access to the system hardware.

[0060] Each logical partition 208 can act as a separate system. That is, each logical partition can be independently reset, run a guest operating system 220 such as the z / OS operating system or another operating system, and operate with different programs 222. The operating system or application running in the logical partition may appear to have access to the entire system, but in fact, only a portion of the system is available.

[0061] The memory 202 is coupled to a processor (e.g., CPU) 204, which is a physical processor resource that can be assigned to a logical partition. For example, the logical partition 208 includes one or more logical processors, each logical processor representing all or a portion of the physical processor resource 204 that can be dynamically assigned to the logical partition.

[0062] In addition, memory 202 is coupled to I / O subsystem 206. I / O subsystem 206 may be part of or separate from the central electronic complex. It directs the flow of information between main memory 202 and input / output control unit 230 and input / output (I / O) devices 240 coupled to the central electronic complex.

[0063] Many types of I / O devices may be used. One particular type is data storage device 250. Data storage device 250 may store one or more programs 252, one or more computer-readable program instructions 254, and / or data, etc. The computer-readable program instructions may be configured to perform the functions of embodiments of aspects of the present invention.

[0064] As an example, each processor 204 includes at least one cache 260 (e.g., local cache) in a cache hierarchy that includes multiple levels of caches, including one or more local caches and / or one or more shared caches. Further, in one embodiment, the local cache and memory 202 are coupled to a compression / decompression component (or other component) 262 that is operative to perform one or more of compression and / or decompression of data (and / or other operations of one or more aspects of the present invention). In different instances, there may be one or more components that perform these tasks. Many variations are possible.

[0065] In one embodiment, a processor (e.g., processor 204) obtains an instruction (e.g., a DEFLATE transform call instruction), decodes the instruction, performs setup for the instruction, including translating the address to be used by the instruction, and then sends the command of the instruction to a component coupled to the processor, such as component 262, to perform the function specified by the instruction. Component 262 may access the cache hierarchy and memory such that, when performing the specified function, component 262 reads data, processes the data, and stores the processed data back. As an example, component 262 is a hardware component.

[0066] In a further embodiment, at least a portion of component 262 is included as part of the processor. Many variations are possible.

[0067] The central electronic complex 200 may include and / or be coupled to removable / non-removable, volatile / non-volatile computer system storage media. For example, the central electronic complex 200 may include and / or be coupled to non-removable non-volatile magnetic media (commonly referred to as "hard disk drives"); disk drives for reading from and writing to removable non-volatile disks (e.g., "floppy disks"), and / or optical disk drives for reading from or writing to removable non-volatile optical disks such as CD-ROMs, DVD-ROMs, or other optical media. It should be understood that other hardware and / or software components may be used in conjunction with the central electronic complex 200. Examples include but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0068] Furthermore, the central electronic complex 200 may operate with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be applicable to the central electronic complex 200 include but are not limited to: personal computer (PC) systems, server computer systems, thin clients, thick clients, hand-held 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, and so on.

[0069] Although different examples of computing environments are described herein, one or more aspects of the present invention may be used with many types of environments. The computing environments provided herein are merely examples.

[0070] According to one aspect of the present invention, a computing environment such as computing environment 100 or central electronic complex 200 employs a conversion facility that provides mechanisms for compressing and decompressing data. In one example, the conversion facility is a DEFLATE conversion facility that provides mechanisms for compressing and decompressing data using the DEFLATE compressed data format. In one example, the conversion facility is installed in the system when a facility indicator is set to, for example, 1. As a particular instance of the z / Architecture hardware architecture, when the conversion facility is installed in the z / Architecture architecture mode, the facility bit 151 is set to, for example, 1. The facility includes, for example, DEFLATE conversion call instructions, embodiments of which are described below.

[0071] In one example, the DEFLATE transform call instruction performs a function related to the state of converting data between its original (uncompressed) form and a compressed representation of the data as specified by a selected standard, such as the "IETF (Internet Engineering Task Force) RFC (Request for Comments) 1951 specification", the description of which is as follows: DEFLATE Compressed Data Format Specification version 1.3 Internet Engineering Task Force, Request for Comments 1951, May 1996.

[0072] In one example, the uncompressed data is a sequence of bytes, and the compressed representation of the data includes symbols. A symbol represents either a single byte of the uncompressed data - called a literal byte, or a sequence of bytes that repeat in the uncompressed data - called a duplicate string. As an example, a Huffman table specifies the encoding and decoding between compressed data symbols and uncompressed data. There are two types of Huffman tables: a fixed-Huffman table (FHT), which is a predefined specification that includes, for example, all possible codings; and a dynamic-Huffman table (DHT), which is a set of codings created specifically for the data to be compressed, and which can be a subset of all possible codings. The compressed representation of data generated with a DHT is typically smaller than the compressed representation of the same data generated with an FHT. A portion of the most recently processed uncompressed data (called history) is maintained for encoding and decoding compressed data symbols that represent duplicate strings. The history is the reference source for the duplicate strings. During operation, the history is updated as the data is processed.

[0073] As described above, in one example, the DEFLATE transform call instruction uses the DEFLATE compressed data format described in "RCF 1951, DEFLATE Compressed Data Format Specification version 1.3". Attributes of the DEFLATE standard applicable to the DEFLATE transform call instruction include, for example:

[0074] · The compressed data set includes a series of blocks. There are three types of blocks. One type includes a 3-bit header, followed by length information and uncompressed data; two types of blocks include a 3-bit header, followed by compressed data elements.

[0075] · The compressed data elements may include a compressed representation of a dynamic-Huffman table, compressed data symbols, and an end-of-block (EOB) symbol.

[0076] · The compressed data elements have different bit lengths.

[0077] · The compressed data elements may start or end between byte boundaries in a storage device.

[0078] · The compressed data elements are loaded into bytes in order, for example, from the rightmost bit position to the leftmost bit position.

[0079] When a compressed data element occupies only a portion rather than the entire byte in a storage device, the entire byte in the storage device is accessed. Storage operand lengths specify the number of addressable bytes, which may specify more bits than those occupied by the compressed data.

[0080] Other details regarding compressed data blocks are described further below.

[0081] See Figures 3A - 3L , which describes an embodiment of the DEFLATE transform call (DFLTCC) instruction. In one example, a general-purpose processor (e.g., processor 102 or 204) is used to execute the instruction. In the description herein, specific locations, specific fields, and / or specific sizes of fields (e.g., specific bytes and / or bits) are indicated. However, other locations, fields, and / or sizes may be provided. Further, although it is specified that bits are set to specific values, such as 1 or 0, this is merely an example. In other instances, bits may be set to different values, such as opposite values or another value. Many variations are possible.

[0082] In one embodiment, a program (e.g., an operating system or a user program) may execute the DEFLATE transform call instruction multiple times to compress or decompress a single data stream. For example, when an application compresses or decompresses a large data stream (e.g., greater than 1M bytes), the operation may include multiple calls to compress or decompress a buffered portion of the data stream. According to one aspect of the present invention, the program declares a history buffer (e.g., a 32K-byte buffer) for accumulating uncompressed data processed during the operation of executing the DEFLATE transform call instruction multiple times. This buffer is referred to as a circular history buffer and is defined using the DEFLATE transform call instruction as described herein.

[0083] See Figure 3A, in one example, the format of the DEFLATE Transform Call (DFLTCC) instruction 300 is an RRF format that represents a register and a register operation with an extended opcode (OPCODE) field and additional register fields. As an example, the instruction includes: an opcode field 302 (e.g., bits 0 - 15) that has an opcode indicating a DEFLATE transform call operation; a first register field (R1) 304 (e.g., bits 24 - 27) that specifies a first pair of general-purpose registers; a second register field (R2) 306 (e.g., bits 28 - 31) that specifies a second pair of general-purpose registers; and a third register field (R3) 308 (e.g., bits 16 - 19) that specifies a third general-purpose register. The content of the register specified by the R1 field 304 specifies the location of the first operand (in the storage device); the content of the register specified by the R2 field 306 specifies the location of the second operand (in the storage device); the content of the register specified by the R3 field 308 specifies the location of the third operand (in the storage device). The content of R1 + 1 specifies the length of the first operand, and the content of R2 + 1 specifies the length of the second operand. In one example, bits 20 - 23 of the instruction are reserved bits and shall contain zeros; otherwise, future operations of the program may be incompatible. As used herein, the program is the program that issues the DEFLATE transform call instruction. It can be a user program, an operating system, or another type of program.

[0084] In one embodiment, the execution of the instruction includes using one or more implicit general-purpose registers (i.e., registers not explicitly specified by the instruction). For example, as described herein, general-purpose registers 0 and 1 are used to execute the DEFLATE transform call instruction. In one example, general-purpose register 0 is used to specify the function to be executed (and the history buffer type described below), and general-purpose register 1 is used to provide the location of the parameter block used by the instruction.

[0085] As an example, referring to Figure 3B , general-purpose register 0 (309) includes a history buffer type field 310 and a function code field 312. In a particular instance, bit position 56 of general-purpose register 0 contains the history buffer type, and bit positions 57 - 63 of general-purpose register 0 contain the function code; however, in other embodiments, other bits may be used to contain the history buffer type and / or the function code. In one example, when bits 57 - 63 of general-purpose register 0 specify an unassigned or not-yet-installed function code, a specified exception is recognized.

[0086] Figure 3C, exemplary function codes assigned to the DEFLATE conversion call instruction are shown, for example, including: function code 0 (313) indicating the DFLTCC-QAF (query available functions) function; function code 1 (315) indicating the DFLTCC-GDHT (generate dynamic-Huffman table) function; function code 2 (317) indicating the DFLTCC-CMPR (compression) function; and function code 4 (319) indicating the DFLTCC-XPND (extension) function. Each code uses a parameter block, and in one example, the size of the parameter block depends on the function. For example, the parameter block of the DFLTCC-QAF function is 32 bytes; the parameter block of the DFLTCC-GDHT function is 384 bytes; and the parameter blocks of the DFLTCC-CMPR and DFLTCC-XPND functions are 1536 bytes. In this example, no other function codes are assigned. Although exemplary functions and function codes are described, other functions and / or function codes may be used.

[0087] When the specified function is DFLTCC-CMPR or DFLTCC-XPND, bit 56 of general register 0 specifies the type of history buffer (HBT) used during operation. When HBT is 0, the history buffer is called an inline history buffer. When an inline history buffer is used, if DFLTCC-CMPR is specified, the history is, for example, immediately to the left of the second operand; if DFLTCC-XPND is specified, the history is, for example, immediately to the left of the first operand. When HBT is 1, the history buffer is called a circular history buffer. When a circular history buffer is used, if DFLTCC-CMPR or DFLTCC-XPND is specified, the history is part or all of the third operand. If the DFLTCC-QAF or DFLTCC-GDHT function is specified, bit 56 of general register 0 is ignored. In one example, bit positions 0-31 of general register 0 are ignored. Further, in one example, bit positions 32-55 of general register 0 are reserved bits and should contain zeros; otherwise, future operations of the program may be incompatible.

[0088] See also Figure 3D , further details are described regarding another implicit register (general register 1) used by the DEFLATE conversion call instruction. The contents of general register 1 (314), for example, specify the logical address 316 of the leftmost byte of a parameter block in storage. In one example, the parameter block is specified on a 4K byte boundary; otherwise a specified exception is recognized. Further details regarding the parameter block are described further below.

[0089] For a specified function (e.g., DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR, DFLTCC-XPND), the contents of general registers 0, 1, and R3 are not modified. Further, in one example, the R1 field 304 specifies an even-odd pair of general registers. To specify an even-numbered register, do not specify general register 0; otherwise, a specified exception is recognized..

[0090] As Figures 3E - 3F shown and further described in detail herein, the contents of general register R1 318 indicate the first operand address 320, and the contents of general register R1+1 322 are used to determine the length 324 of the first operand. For example, when the specified function is DFLTCC-CMPR or DFLTCC-XPND, the contents of general register R1 318 specify the logical address of the leftmost byte of the first operand. When the specified function is DFLTCC-CMPR, the contents of general register R1+1, together with the values of the new task (NT) and sub-byte boundary (SBB) fields of the parameter block (described below), specify the length of the first operand. The following table provides examples showing that the length of the first operand for the DFLTCC-CMPR function is a function of the contents of general register R1+1, the NT field, and the SBB field:

[0091]

[0092] When the specified function is DFLTCC-XPND, the contents of general register R1+1 specify the length of the first operand. When the specified function is DFLTCC-CMPR or DFLTCC-XPND, the result of compressing or decompressing the data is stored in the first operand location. When the DFLTCC-QAF or DFLTCC-GDHT function is specified, the contents of general registers R1 and R1+1 are ignored.

[0093] In addition, in one example, for a specified function (e.g., DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR, and DFLTCC-XPND), the R2 field 306 specifies an even-odd pair of general registers. To specify an even-numbered register, do not specify general register 0; otherwise, a specified exception is recognized.

[0094] As Figures 3G - 3HAs shown and described in further detail herein, the content of general register R2 326 indicates the second operand address 328, and the content of general register R2+1 330 is used to determine the length 332 of the second operand. For example, when the specified function is DFLTCC-GDHT, DFLTCC-CMPR, or DFLTCC-XPND, the content of general register R2 specifies the logical address of the leftmost byte of the second operand. When the specified function is DFLTCC-CMPR or DFLTCC-GDHT, the content of general register R2+1 specifies the length of the second operand. When the specified function is DFLTCC-XPND, the content of general register R2+1, together with the values of the NT field and the SBB field of the parameter block, specifies the length of the second operand. At the start of instruction execution, when the second operand length is referenced and has a non-zero value, data is extracted from the second operand location. At the start of instruction execution, when the second operand length is referenced and has a zero value, and at the start of instruction execution when the continue flag (CF) field of the parameter block is 1, the second operand is not accessed.

[0095] When the DFLTCC-QAF function is specified, the content of general registers R2 and R2+1 is ignored. When the DFLTCC-GDHT function is specified and the content of general register R2+1 specifies a length equal to zero, the specified exception is recognized and the second operand is not accessed. When the DFLTCC-CMPR or DFLTCC-XPND function is specified, the continue flag (CF) field of the parameter block is zero at the start of instruction execution, and the content of general register R2+1 specifies a length equal to zero, the specified exception is recognized and the second operand is not accessed.

[0096] As Figure 3I shown, when the specified function is DFLTCC-CMPR or DFLTCC-XPND and the history buffer type (HBT) is circular (e.g., HBT 310 = 1), the content of general register R3 335 specifies the circular history buffer address 337. For example, it specifies the logical address of the leftmost byte of the third operand. It is required to specify a boundary of, for example, 4K bytes; otherwise, the specified exception is recognized. In one example, the circular history buffer is located at the third operand location. When the specified function is DFLTCC-CMPR or DFLTCC-XPND and HBT is zero, the content of general register R3 is ignored. When the DFLTCC-QAF or DFLTCC-GDHT function is specified, the content of general register R3 is ignored. For the specified functions (e.g., DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR, and DFLTCC-XPND), the R3 field shall not specify general register 0 or general register 1; otherwise, in one example, the specified exception is recognized.

[0097] As part of the operation, when the specified function is DFLTCC-CMPR, the address in general register R1 is incremented by the number of processed bytes of the first operand handling bit position 0, and the length in general register R1+1 is decremented by the same number; the address in general register R2 is incremented by the number of processed bytes of the second operand, and the length in general register R2+1 is decremented by the same number. The number of processed bytes of the first operand handling bit position 0 is, for example, the integer quotient obtained from an integer division, where the divisor is the sum of the number of processed output bits and the original value of SBB, and the divisor is the value 8. The formation and update of the address and length depend on the addressing mode, as described below.

[0098] As part of the operation, when the specified function is DFLTCC-XPND, the address in general register R1 is incremented by the number of processed bytes of the first operand, and the length in general register R1+1 is decremented by the same number; the address in general register R2 is incremented by the number of processed bytes of the second operand handling bit position 0, and the length in general register R2+1 is decremented by the same number. The number of processed bytes of the second operand handling bit position 0 is the integer quotient obtained from an integer division, where the divisor is the sum of the number of processed input bits and the original value of SBB, and the divisor is the value 8. The formation and update of the address and length depend on the addressing mode, as described below.

[0099] In one embodiment, in 24-bit addressing mode, the following applies:

[0100] · The contents of bit positions 40-63 of general registers 1, R1, R2, and R3 respectively constitute the addresses of the parameter block, the first operand, the second operand, and the circular history buffer, and the contents of bit positions 0-39 are ignored.

[0101] · Bits 40-63 of the updated first and second operand addresses respectively replace the corresponding bits in general registers R1 and R2. The carry of bit position 40 of the updated address is ignored, and the contents of bit positions 32-39 of general registers R1 and R2 are set to zero. The contents of bit positions 0-31 of general registers R1 and R2 remain unchanged. When the instruction ends with partial or normal completion and the updated operand address is equal to the operand address at the start of the instruction execution, the bit positions 32-39 of the corresponding general register are set to zero.

[0102] · The contents of bit positions 32-63 of general registers R1+1 and R2+1 form 32-bit unsigned binary integers respectively specifying the number of bytes in the first and second operands. The contents of bit positions 0-31 of general registers R1+1 and R2+1 are ignored.

[0103] · Bits 32 - 63 of the updated first and second operand lengths respectively replace the corresponding bits in general registers R1+1 and R2+1. The contents of bits 0 - 31 of general registers R1+1 and R2+1 remain unchanged.

[0104] In one embodiment, in 31 - bit addressing mode, the following applies:

[0105] · The contents of bits 33 - 63 of general registers 1, R1, R2, and R3 respectively form the addresses of the parameter block, the first operand, the second operand, and the circular history buffer, and the contents of bits 0 - 32 are ignored.

[0106] · Bits 33 - 63 of the updated first and second operand addresses respectively replace the corresponding bits in general registers R1 and R2. The carry of bit 33 of the updated address is ignored, and the contents of bit 32 of general registers R1 and R2 are set to zero. The contents of bits 0 - 31 of general registers R1 and R2 remain unchanged. When the instruction ends with partial or normal completion and the updated operand address is equal to the operand address at the start of the instruction execution, the content of bit 32 of the corresponding general register is set to zero.

[0107] · The contents of bits 32 - 63 of general registers R1+1 and R2+1 form 32 - bit unsigned binary integers respectively specifying the number of bytes in the first and second operands. The contents of bits 0 - 31 of general registers R1+1 and R2+1 are ignored.

[0108] · Bits 32 - 63 of the updated first and second operand lengths respectively replace the corresponding bits in general registers R1+1 and R2+1. The contents of bits 0 - 31 of general registers R1+1 and R2+1 remain unchanged.

[0109] In one embodiment, in 64 - bit addressing mode, the following applies:

[0110] · The contents of bits 0 - 63 of general registers 1, R1, R2, and R3 respectively form the addresses of the parameter block, the first operand, the second operand, and the circular history buffer.

[0111] · Bits 0 - 63 of the updated first and second operand addresses respectively replace the corresponding bits in general registers R1 and R2. The carry of bit 0 of the updated address is ignored.

[0112] · The contents of bits 0 - 63 of general registers R1+1 and R2+1 form 64 - bit unsigned binary integers respectively specifying the number of bytes in the first and second operands.

[0113] · Bits 0 - 63 of the updated first and second operand lengths respectively replace the corresponding bits in general registers R1+1 and R2+1.

[0114] In the access - register mode, access registers 1, R1, R2, and R3 respectively specify the address spaces containing the parameter block, the first operand, the second operand, and the circular history buffer. When specifying DFTCC - CMPR with an inline history buffer in the access - register mode, access register R2 specifies the address space containing the inline history. When specifying DFTCC - XPND with an inline history buffer in the access - register mode, access register R1 specifies the address space containing the inline history.

[0115] Further details regarding the various functions are described below:

[0116] Function code 0: DFLTCC - QAF (Query Available Functions)

[0117] The DFLTCC - QAF (Query Available Functions) function provides a mechanism for indicating the availability of installed functions and installed parameter block formats. Refer to Figure 3J , for an example format of the parameter block that describes the DFLTCC - QAF function. In one example, the parameter block 340 of the DFLTCC - QAF function (e.g., function code 0) includes an installed function vector 342 and an installed parameter block format vector 346. In a specific example, these vectors are stored in bytes 0 - 15 and bytes 24 - 25 of the parameter block respectively. Each of these vectors is further described below.

[0118] As an example, bits 0 - 127 of the installed function vector 342 respectively correspond to function codes 0 - 127 of the DEFLATE transform call instruction. When a bit is, for example, 1, the corresponding function is installed; otherwise, the function is not installed.

[0119] Further, in one example, bits 0 - 15 of the installed parameter block format vector 346 respectively correspond to parameter block formats 0 - 15 of the DFLTCC - GDHT, DFLTCC - CMPR, and DFLTCC - XPND functions. When a bit is 1, the corresponding parameter block format is installed; otherwise, the parameter block format is not installed. In one example, zeros are stored in the reserved bytes 16 - 23 and 26 - 31 of the parameter block.

[0120] Although certain fields are described with respect to parameter block 340, additional, fewer, and / or other fields may be included in other embodiments.

[0121] In one embodiment, the DFLTCC-QAF function ignores the contents of general-purpose registers R1, R2, R3, R1+1, and R2+1.

[0122] When applicable, identify PER (program event recording) storage change events for the parameter block. When applicable, identify PER zero-address detection events for the parameter block.

[0123] In one example, when the execution of the DFLTCC-QAF function is complete, condition code 0 is set; in one example, condition codes 1, 2, and 3 are not applicable to the query function.

[0124] Function code 1: DFLTCC-GDHT (Generate Dynamic-Huffman Table)

[0125] When the DFLTCC-GDHT function is specified, for example, using the second operand as the source to generate a compressed representation of a dynamic-Huffman table (DHT) as specified by the DEFLATE standard.

[0126] In one example, the DFLTCC-GDHT function uses a parameter block, referring to Figure 3K , which shows an example of the parameter block. In the example parameter block described herein, the specific location of a specific field within the parameter block and the specific size of the field (e.g., specific bytes and / or bits) are indicated. However, other locations and / or sizes may be provided for one or more fields. Further, although it is specified that bits are set to specific values, such as 1 or 0, this is merely an example. In other instances, bits may be set to different values, such as opposite values or another value. Many variations are possible.

[0127] Additionally, in one example, the parameter block includes one or more reserved fields and one or more preserved fields. The DFLTCC-GDHT function does not modify the preserved fields. The reserved fields are distinguished from the preserved fields so that a program can initialize a single storage location, use that storage location for the parameter block of the DFLTCC-GDHT function, and subsequently use the same storage location for the parameter block of the DFLTCC-CMPR function. The preserved fields are to contain zeros; otherwise, future operations of the program may be incompatible. When the operation ends, the preserved fields may be stored as zeros or may remain unchanged.

[0128] Furthermore, some fields are used by other functions (e.g., DFLTCC-CMPR or DFLTCC-XPND), and thus, aspects related to these functions may also be described in conjunction with the descriptions of these fields.

[0129] In one example, the parameter block 360 of the DFLTCC-GDHT function includes the following fields:

[0130] Parameter Block Version Number (PBVN) 362: Bytes 0-1 of the parameter block specify the version and size of the parameter block. Bits 0-11 of the PBVN are reserved bits and shall contain zeros; otherwise, future operations of the program may be incompatible. Bits 12-15 of the PBVN contain an unsigned binary integer that specifies the format of the parameter block. The DFLTCC-QAF function provides a mechanism to indicate the available parameter block formats. When the specified format of the parameter block is not supported by the model, a general operand data exception is recognized. The PBVN is specified by the program and is not modified during instruction execution.

[0131] Model Version Number (MVN) 363: Byte 2 of the parameter block is an unsigned binary integer that identifies the model that executes the instruction. It is not required for the program to initialize the MVN. The MVN is updated during instruction execution. The value stored in the MVN is model-dependent.

[0132] Dynamic - Huffman Table (DHT) Generation Control (DHTGC) 364: Bit 2 of byte 17 of the parameter block applies to the generation of the dynamic - Huffman table (DHT). The DHT specifies the Huffman codes for symbols representing literal bytes, repeat string lengths, end-of-block (EOB) symbols, and repeat string pointer distances. The value of the Huffman code for a particular symbol is a function of the count of occurrences of the entity that the symbol represents in the uncompressed form of the data. When the count of a symbol is zero, there is no Huffman code for that symbol in the DHT. In one example, DHTGC specifies how a count equal to zero is to be handled as follows:

[0133]

[0134] A DHT that specifies Huffman codes for every possible value of literal bytes, EOB symbols, repeat string lengths, and repeat string pointer distances is called a universal DHT. A DHT that does not specify Huffman codes for values of literal bytes, repeat string lengths, or repeat string pointer distances that do not occur in the uncompressed form of the data is called a non-universal DHT.

[0135] For all values of DHTGC, the resulting DHT specifies Huffman codes for all possible repeat string lengths and pointer distances as defined by the DEFLATE standard. Thus, the HLIT (Huffman literal) and HDIST (Huffman distance) sub-elements of the compressed form of the resulting DHT, described further below, each contain a value such as 29.

[0136] When the DFLTCC-GDHT function is specified, DHTGC is an input to the operation. When the DFLTCC-CMPR or DFLTCC-XPND function is specified, DHTGC does not apply to the operation. In one embodiment, DHTGC is not modified during the execution of the instruction.

[0137] Operation End Supplemental Code (OESC) 365: Byte 19 of the parameter block is an unsigned binary integer that provides additional information when a condition is reported to the program. Since this field is used by multiple functions, some conditions relate to fields in parameter blocks used by other functions (e.g., the parameter block used by the DFLTCC-CMPR and DFLTCC-XPND functions). Figure 3L When the reported condition is a general operand data exception, the operation is considered inhibited although the OESC field of the parameter block is updated. In one example, in this case it is defined as follows:

[0138]

[0139]

[0140]

[0141]

[0142] When the operation ends without reporting a general operand data exception, zero is stored in the OESC field.

[0143] Support for supplemental codes other than zero is model-dependent. When there are multiple conditions, which code (if any) is reported in the OESC field is model-dependent.

[0144] Compressed Dynamic-Huffman Table Length (CDHTL) 366: Twelve bits starting from bit 4 of byte 56 to bit 7 of byte 57 of the parameter block contain an unsigned binary integer that specifies the length of the compressed format of the DHT in the CDHT field of the parameter block (e.g., CDHT 367) as a bit count.

[0145] CDHTL is an output from the operation when the DFLTCC-GDHT function is specified.

[0146] When the DFLTCC-CMPR function is specified and the Huffman Table Type (e.g., Figure 3L HTT 376) is 1, CDHTL is an input to the operation. When CDHTL does not specify the appropriate length of the CDHT, a general operand data exception is recognized. When the DFLTCC-CMPR function is specified, CDHTL is not modified.

[0147] When the DFLTCC-XPND function is specified and the operation ends after decoding only a part of a block with a BTYPE value of binary 10, the length of the compressed representation of the DHT in the block is stored in this field. When the DFLTCC-XPND function is specified and the operation ends at a block boundary or after decoding only a part of a block with a BTYPE value of binary 00 or 01, zero is stored in this field. When decompression operation is resumed within a block with a BTYPE value of binary 10 (i.e., when the continue flag 373 of CF( Figure 3L is equal to 1 and the IFS (incomplete function status 383) is equal to hexadecimal C or D, as described below), this field is an input to the operation.

[0148] Compressed Dynamic-Huffman Table (CDHT) 367: Bytes 64 - 351 of the parameter block contain the compressed format of the Dynamic-Huffman Table (DHT).

[0149] The DHT specifies Huffman codes (bit sequences) representing two sets of elements. The elements of one set include literal bytes, the EOB symbol, and repeat string lengths. The elements of the other set include repeat string pointer distances. The compressed representation of the DHT defines a set of code lengths and specifies a code length (CL) for each element of each set. The Huffman code for an element expected to be referenced during an operation is derived from the CL specified for that element and the number of elements in the same set with the same specified CL. Specifically, the compressed representation of the DHT includes, for example, the following:

[0150] · The HLIT field, which is used to specify the number of Huffman codes representing literal bytes, the EOB symbol, and repeat string lengths.

[0151] · The HDIST field, which is used to specify the number of Huffman codes representing repeat string pointer distances.

[0152] · The HCLEN (Huffman code length) field, which is used to specify the number of Huffman codes representing code lengths.

[0153] · A code sequence that specifies the bit lengths of each of, for example, 19 code lengths defined for the compressed DHT.

[0154] · A code sequence that specifies the code length of each element in the set consisting of literal bytes, the EOB symbol, and repeat string lengths.

[0155] · A code sequence that specifies the code length of each element in the set consisting of repeat string pointer distances.

[0156] Further details of the compressed representation of the DHT are described below with reference to the description of the compressed data block with a block type value of binary 10.

[0157] In one example, the compressed representation of the DHT in the CDHT field is left-aligned. That is, the rightmost bit of byte 64 contains the least significant bit of the HLIT sub-element of the compressed representation of the DHT.

[0158] When the DFLTCC-GDHT function is specified, the compressed representation of the DHT is the output from the operation.

[0159] When the DFLTCC-CMPR function is specified and the HTT described below is 1, the compressed representation of the DHT is the input to the operation. The CDHT field is not modified by the DFLTCC-CMPR function.

[0160] When the DFLTCC-XPND function is specified and the operation ends after decoding only a part of a block with a BTYPE value of binary 10, the compressed representation of the DHT in the block is stored in this field. When the DFLTCC-XPND function is specified and the operation ends at a block boundary or after decoding only a part of a block with a BTYPE value of binary 00 or 01, zero is stored in this field. When the decompression operation is resumed within a block with a BTYPE value of binary 10 (i.e., when CF equals 1 and IFS equals hexadecimal C or D), this field is the input to the operation.

[0161] When the CDHT is modified, the bits that are not used to represent the compressed representation of the DHT in this field are stored as zero.

[0162] Although the various fields have been described above with respect to parameter block 360, additional, fewer, and / or other fields may be included in other embodiments.

[0163] Aspects of DHT generation are specified to the machine by the program using the Dynamic-Huffman Table Generation Control (DHTGC) field 364 of the parameter block. The source is to contain uncompressed data, and after the operation is completed, the DFLTCC-CMPR function that compresses the same source is specified for the generated result.

[0164] In one embodiment, there is no history to be referenced from a previous operation during the processing of the current operation.

[0165] In one example, when the content of general register R2+1 specifies a length greater than, for example, 32K bytes, the following applies:

[0166] · Only the first 32K bytes of the second operand are used to generate the DHT.

[0167] · Access exceptions are not recognized for positions other than those of the first 32K bytes of the second operand.

[0168] When the content of general register R2+1 specifies a length equal to zero, a specified exception is recognized and the second operand is not accessed.

[0169] The resulting compressed DHT includes a Huffman code representing an end-of-block (EOB) symbol.

[0170] The compressed format of the generated DHT is stored in the Compressed Dynamic-Huffman Table (CDHT) field 367 of the parameter block. The length of the compressed format of the generated DHT is stored in the CDHTL field 366 of the parameter block.

[0171] The operation includes storing the model identification into the model version number field 363 of the parameter block.

[0172] When the operation ends without recognizing a general operand data exception, zero is stored into the Operation End Supplemental Code (OESC) field 365 of the parameter block.

[0173] When the execution of the DFLTCC-GDHT function is completed, condition code 0 is set; condition codes 1, 2, and 3 do not apply to the DFLTCC-GDHT function.

[0174] The operation does not modify general registers R2 and R2+1.

[0175] When the DFLTCC-GDHT function is specified, the contents of general registers R1, R1+1, and R3 are ignored.

[0176] When applicable, a PER zero-address detection event is recognized for the second operand location and for the parameter block. Function code 2: DFLTCC-CMPR (Compression)

[0177] When the DFLTCC-CMPR function is specified, a compression operation is performed. The operation includes encoding the data from the second operand location into a compressed data symbol, and the compressed data symbol is stored into the first operand location.

[0178] In one example, the DFLTCC-CMPR function uses a parameter block, an example of which is referenced Figure 3L has been described. Some fields have been described above with respect to parameter block 360, and thus, these fields are listed below with the same tag numbers and will not be elaborated further.

[0179] In one example, parameter block 370 includes:

[0180] Parameter Block Version Number (PBVN) 362.

[0181] Model Version Number (MVN) 363.

[0182] Continue Flag (CF) 373: When bit 63 of the parameter block is 1, it indicates that the operation is partially completed, and the operation can be resumed with the content of the continue status buffer (e.g., in the continue status buffer field 392). The program initializes the continue flag (CF) to zero and does not modify CF when the instruction is re-executed for the purpose of resuming the operation; otherwise the result is unpredictable.

[0183] New Task (NT) 374: When bit 0 of byte 16 of the parameter block is 1, it indicates that the operation applies to the start of a compressed data set. Therefore, no history and check value from a previous operation apply to the current operation. When NT is 1 at the start of the operation and the operation ends after being partially completed, zero is stored into the NT field. When NT is zero, the history and check value from the previous operation apply to the current operation.

[0184] Check Value Type (CVT) 375: Bit 2 of byte 16 of the parameter block specifies the type of the check value contained in the check value field (e.g., field 387) of the parameter block. When CVT is zero, the check value type is, for example, 32-bit Cyclic Redundancy Check (CRC-32). In the case where CVT is 1, the check value type is, for example, 32-bit Adler checksum (Adler-32). The CVT bit is not modified during instruction execution.

[0185] Huffman Table Type (HTT) 376: When bit 4 of byte 16 of the parameter block is zero, it specifies the table containing the fixed-Huffman code (FHT) defined by the DEFLATE standard to be used during the compression operation. When HTT is 1, the table containing the dynamic-Huffman code (DHT) specified in the CDHT field of the parameter block is used during the compression operation. HTT does not apply to the decompression operation. The HTT bit is not modified during instruction execution.

[0186] Block Continuation Flag (BCF) 377: Applicable when specifying the DFLTCC-CMPR function, bit 5 of byte 16 of the parameter block. When it is zero, before storing any compressed data element, the 3-bit block header and—if applicable—the compressed format of the dynamic-Huffman table specified in the CDHT field (e.g., field 367) of the parameter block are stored into the first operand location. When it is 1, neither the block header nor the compressed format of the DHT is stored into the first operand location. When NT is 1, the BCF is considered equal to 0. The BCF bit is not modified during instruction execution.

[0187] Block Closing Control (BCC) 378: When the DFLTCC-CMPR function is specified, bit 6 of byte 16 of the parameter block applies. When it is 1 after storing all compressed data symbols, the End-of-Block (EOB) symbol is stored into the first operand location. When HTT specifies the use of FHT, for example, the Huffman code 00000 binary 00 (which corresponds to the mid-integer representation of 256 for the codes in the table that specify literal bytes, EOB symbols, and repeat string lengths) is used for the EOB symbol. When HTT specifies the use of DHT, the Huffman code for the EOB symbol is specified in the DHT. When the BCC bit is zero, the EOB symbol is not stored into the first operand location. The BCC bit is not modified during instruction execution.

[0188] Block Header Final (BHF) 379: When the DFLTCC-CMPR function is specified and BCF 377 is 0 or NT 374 is 1, bit 7 of byte 16 of the parameter block applies; otherwise, BHF does not apply. When it is 1, the first bit (BFINAL) of the block header is set to 1 before storing the block header into the first operand location. When it is 0 and applicable, the first bit (BFINAL) of the block header is set to zero before storing the block header into the first operand location. The BHF bit is not modified during instruction execution.

[0189] DHT Generation Control (DHTGC) 364: When the DFLTCC-CMPR function is specified, DHTGC does not apply to the operation. DHTGC is not modified during instruction execution.

[0190] Sub-Byte Boundary (SBB) 381: Bits 5 - 7 of byte 18 of the parameter block contain an unsigned binary integer that specifies the boundary between the processed bits and the unprocessed bits within a byte of the compressed data stream. The byte of the referenced stream, when the operation ends, is the last referenced byte (i.e., the rightmost byte), and when the operation starts or resumes, is the first byte to be referenced (i.e., the leftmost byte). When the DFLTCC-CMPR function is specified, SBB applies to the byte specified by the first operand address. When the DFLTCC-XPND function is specified, SBB applies to the byte specified by the second operand address. SBB specifies the number of the rightmost processed bits. SBB is an input to the operation and an output of the operation.

[0191] Figure 4 An example of the compressed data stream when SBB has the binary value 011 is shown. The data that has been processed after the operation ends is shown at 400; the data to be processed before the operation starts is shown at 402.

[0192] Further, Figures 5A - 5C an example showing how the SBB applies to the DFLTCC-CMPR function is provided. For example, Figure 5A an example of how the SBB applies before and after performing the DFLTCC-CMPR function is shown. Figures 5B - 5C Other examples are shown. When NT 374 is 1, the SBB 381 is considered equal to binary 000.

[0193] Return Figure 3L , and describe other fields of the parameter block 370:

[0194] Operation Ending Supplemental Code (OESC) 365.

[0195] Incomplete Function Status (IFS): When certain operations end, bits 4-7 of byte 21 of the parameter block contain status information. In one example, when the decompression operation ends, the IFS conveys information about the second operand as follows:

[0196]

[0197]

[0198] In one embodiment, the decompression operation may end with the IFS equal to binary 0000, not meeting normal completion. In such a case, the operation ends with condition code 1 or 3 set.

[0199] When the compression operation ends, the IFS field is undefined but can be modified.

[0200] The IFS is not an input to the operation.

[0201] Incomplete Function Length (IFL): When certain operations end, bytes 22-23 of the parameter block contain length information. For the decompression operation, the IFL applies to the second operand. When the decompression operation ends after decoding some but not all of the blocks with a BTYPE equal to binary 00, the IFL contains an unsigned binary integer specifying the number of unprocessed bytes of the block in the second operand. Bytes 22-23 contain the IFL in, for example, big-endian byte order, which is different from the LEN field of the block with a BTYPE equal to binary 00, which is in little-endian byte order, for example.

[0202] When the decompression operation ends after decoding a complete block where BTYPE is equal to binary 00 and BFINAL is equal to 1, zero is stored into the IFL field. When the decompression operation ends after decoding some but not all of the blocks with non-zero BTYPE, or at a block boundary, the IFL field is undefined but may be modified.

[0203] When the compression operation ends, the IFL field is undefined but may be modified.

[0204] IFL is not an input to the operation.

[0205] History Length (HL) 385: Bytes 44 - 45 of the parameter block contain an unsigned binary integer specifying the number of bytes of history in the history buffer that can be referenced during the operation. HL applies to both inline and circular history buffers. When New Task (NT) is equal to 1, no history applies at the start of the operation and the history length is considered zero, as an input to the operation.

[0206] When the history length is greater than, for example, 32,768 and NT is equal to zero, a general operand data exception is recognized.

[0207] The history length is modified during compression and decompression operations. When the sum of the original HL and the number of uncompressed data bytes processed during the operation is less than or equal to, for example, 32,768, the updated HL is equal to the sum of the original HL and the number of uncompressed data bytes processed during the operation; otherwise, the updated HL is equal to the value 32,768.

[0208] History Offset (HO) 386: When the history buffer type is circular, fifteen bits from bit 1 of byte 46 to bit 7 of byte 47 of the parameter block contain an unsigned binary integer specifying the offset in the third operand. The sum of the contents of R3 and the history offset indicates the position of the first byte of history in the circular history buffer, which is the byte of the least recently processed uncompressed data in the buffer. When the history buffer type is circular, the history offset is an input to the operation and is updated at the end of the operation. When the sum of the original HL and the number of uncompressed data bytes processed during the operation is less than or equal to, for example, 32,768, the updated HO is equal to the original HO; otherwise, the updated HO is equal to the modulo 32,768 of the sum of the original HO, the original HL, and the number of uncompressed data bytes processed during the operation.

[0209] When the historical buffer type is in-line, the HO field of the parameter block is undefined but can be modified.

[0210] Checksum 387: Bytes 48 - 51 of the parameter block contain the checksum. As part of the operation, the checksum is generated. The checksum applies to the uncompressed data operand. That is, the checksum applies to the second operand of the DFLTCC-CMPR function and the first operand of the DFLTCC-XPND function. When bit 375 of CVT is zero, a 32-bit cyclic redundancy check checksum (CRC-32) is generated, for example. When the CVT bit is 1, a 32-bit Adler checksum checksum (Adler-32) is generated, for example.

[0211] The input for generating the checksum is, for example, a 4-byte base and the uncompressed data that has been processed during the operation. The base input provides a means to calculate a single and consistent checksum for a set of compressed data blocks, regardless of how many DFLTCC instructions are executed to process the entire set of compressed data blocks. When the NT bit is 0, the original value in the checksum field is used as the base input for generating the checksum.

[0212] In one example, when generating the Adler-32 checksum, the following applies:

[0213] · When the NT bit is 1, the value 1 is used for the 4-byte base input.

[0214] · The sum defined in the generation of the Adler-32 checksum is taken modulo 65,521.

[0215] · The result is stored in the checksum field in big-endian byte order. That is, the most significant byte of the checksum is in byte 48, and the least significant byte of the checksum is in byte 51.

[0216] In one embodiment, when generating the CRC-32 checksum, the following applies:

[0217] · When the NT bit is 1, the value 0 is used for the 4-byte base input.

[0218] · The polynomial used as the divisor when generating the CRC-32 checksum is x 32 +x 26 +x 23 +x 22 +x 16 +x 12 +x 11 +x 10 +x 8 +x 7 +x 5 +x 4 +x 2+x 1 +x 0 , represented as hexadecimal 104C11DB7. In this representation, the leftmost bit corresponds to the most significant bit.

[0219] · The first and last phases of generating the check value are calculating the one's complement of the radix input before storing the result and calculating the one's complement of the result, respectively.

[0220] · Store the result in the check value field in little-endian byte order. That is, the least significant byte of the check value is in byte 48, and the most significant byte of the check value is in byte 51.

[0221] In one example, the check value is meaningful to the program only if the operation ends with condition code 0 set; otherwise, the check value is only an intermediate result and is meaningful only for recovery operations. When the DFLTCC-CMPR function is specified and the operation ends with condition code 1, 2, or 3 set, some bytes to the left of the byte specified by the second operand address may not be included in the calculation of the resulting check value. When the DFLTCC-XPND function is specified and the operation ends with condition code 1, 2, or 3 set, some result bytes that have not been stored to the right of the byte specified by the first operand address may already be included in the calculation of the resulting check value.

[0222] End-of-Block Symbol (EOBS) 388: Fifteen bits from bit 0 of byte 52 to bit 6 of byte 53 of the parameter block contain the End-of-Block (EOB) symbol. The End-of-Block Length (EOBL) field 389 of the parameter block specifies the length of the EOB symbol in the EOBS field. The EOB symbol is left-aligned in the EOBS field. Bits in the EOBS field not occupied by the EOB symbol store zeros. When compressing data, the EOBS field is the output of the operation, regardless of the type of Huffman table applied. The EOBS field is not used as an input to the operation.

[0223] Bit 0 of byte 52 contains the most significant bit of the EOB symbol. When the length of the EOB symbol is 7 bits, bit 6 of byte 52 contains the least significant bit of the EOB symbol. When the length of the EOB symbol is 15 bits, bit 6 of byte 53 contains the least significant bit of the EOB symbol.

[0224] For blocks using FHT, the EOB symbol is binary 0000000 as defined by the DEFLATE standard. For blocks using DHT, the EOB symbol is defined by DHT. The EOB symbol is transmitted to provide the program with the ability to close blocks.

[0225] When the DFLTCC-XPND function is specified, the EOBS field is undefined but can be modified.

[0226] End-Of-Block Length (EOBL) 389: Bits 0 - 3 of byte 54 of the parameter block contain an unsigned binary integer specifying the length of the End-Of-Block (EOB) symbol in the EOBS field 388 of the parameter block. This length specifies the number of bits occupied by the EOB symbol in the EOBS field. When compressing data, the EOBL field is an output of the operation, regardless of the type of Huffman table applied. The EOBL field is not used as an input to the operation.

[0227] When the DFLTCC-XPND function is specified, the EOBL field is undefined but may be modified.

[0228] Compressed Dynamic-Huffman Table Length (CDHTL) 366.

[0229] Compressed Dynamic-Huffman Table (CDHT) 367: When the DFLTCC-CMPR function is specified and HTT is 1, the compressed representation of the DHT is an input to the operation. The CDHT field is not modified by the DFLTCC-CMPR function.

[0230] Continue State Buffer (CSB) 392: When the condition causes the value 1 to be stored in the CF field 373, the internal state data is stored into bytes 384 - 1535 of the parameter block; otherwise, bytes 384 - 1535 of the parameter block are undefined and may be modified. The stored internal state data is model-dependent and may subsequently be used for recovery operations. It is expected - but not required - that the program initialize the continue state buffer to contain, for example, all zeros. After an instruction has terminated with a non-zero condition code and before re-executing the instruction for the purpose of recovery operations, the program should not modify the continue state buffer; otherwise, the results are unpredictable.

[0231] Although the various fields have been described above with reference to parameter block 370, additional, fewer, and / or other fields may be included in other embodiments.

[0232] An example of the compression operation is described below with respect to compressed data.

[0233] Normal completion of the DFLTCC-CCMPR function occurs when the entire second operand has been compressed and stored into the first operand location. In one example, when the operation ends due to normal completion, the following occurs:

[0234] · Model-dependent values are stored into the Model Version Number (MVN) field 363 of the parameter block.

[0235] · The Continue Flag (CF) field 373 of the parameter block is set to zero.

[0236] · The sub-byte boundary (SBB) field 381 of the parameter block is updated.

[0237] · The end-of-block length (EOBL) 389 and end-of-block symbol (EOBS) 388 fields of the parameter block are updated.

[0238] · The history length (HL) field 385 of the parameter block is updated.

[0239] · When applicable, the history offset (HO) field 386 of the parameter block is updated.

[0240] · The operation end supplementary code (OESC) field 365 of the parameter block is set to zero.

[0241] · The checksum field 387 of the parameter block is updated.

[0242] · The address increment in general register R1 includes the number of processed bytes of the first operand that processes bit 0, and the length decrement in general register R1+1 is the same number. The number of processed bytes of the first operand that processes bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed output bits and the original value of SBB, and the divisor is the value 8.

[0243] · The address increment in general register R2 processes the number of source bytes, and the length decrement in general register R2+1 is the same number.

[0244] · Set condition code 0.

[0245] The formation and update of the address and length depend on the addressing mode.

[0246] When normal completion occurs, the CSB field 392 of the parameter block is not defined after the operation ends.

[0247] In one example, when the number of bytes determined by the CPU has been processed, the operation ends and the following occurs:

[0248] · The continue flag (CF) bit 373 in the parameter block is set to 1.

[0249] · The continue status buffer (CSB) field 392 in the parameter block is updated.

[0250] · The sub-byte boundary (SBB) field 381 of the parameter block is updated.

[0251] · The history length (HL) field 385 of the parameter block is updated.

[0252] · When applicable, the history offset (HO) field 386 of the parameter block is updated.

[0253] · The checksum value field 387 of the parameter block is updated.

[0254] · The model-dependent value is stored in the model version number (MVN) field 363 of the parameter block.

[0255] · The end-of-block length (EOBL) 389 and end-of-block symbol (EOBS) 388 fields of the parameter block are updated.

[0256] · The operation end supplementary code (OESC) field 365 of the parameter block is set to zero.

[0257] · The address increment in general register R1 includes the number of processed bytes of the first operand that processes bit 0, and the length decrement in general register R1+1 is the same number. The number of processed bytes of the first operand that processes bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed output bits and the original value of SBB, and the divisor is the value 8.

[0258] · The address increment in general register R2 processes the number of source bytes, and the length decrement in general register R2+1 is the same number.

[0259] · Set condition code 3.

[0260] The formation and update of the address and length depend on the addressing mode.

[0261] The number of bytes determined by the CPU depends on the model and can be a different number each time the instruction is executed.

[0262] After the instruction ends with condition code 3 set, it is expected that the program does not modify any of the instruction's input or output specifications and branches back to re-execute the instruction to resume operation.

[0263] In some cases, although the instruction ends with condition code 3 set, the parameter block and general registers are not updated. These situations can occur when the CPU performs a silent operation while executing the DEFLATE transform call instruction or when the CPU retries. In these cases, the number of bytes determined by the CPU that have been processed is zero, data may have been stored in the first operand location, data may have been stored in the third operand location (if applicable), and the corresponding change bits have been set.

[0264] In one example, the length of the first operand is insufficient to complete the operation when any of the following conditions apply:

[0265] · The length of the first operand as specified by the content of general register R1+1 is zero at the start of the instruction execution.

[0266] · The length of the first operand becomes equal to zero during the instruction execution and no normal completion occurs.

[0267] In one example, when the content of general register R1+1 is zero, the first operand length is zero regardless of the values in the NT field and the SBB field of the parameter block.

[0268] In one embodiment, when the first operand length becomes equal to zero during the execution of the instruction, the operation ends and the following occurs:

[0269] · The continue flag (CF) bit 373 in the parameter block is set to 1.

[0270] · The continue status buffer (CSB) field 392 in the parameter block is updated.

[0271] · The sub-byte boundary (SBB) field 381 of the parameter block is updated.

[0272] · The history length (HL) field 385 of the parameter block is updated.

[0273] · When applicable, the history offset (HO) field 386 of the parameter block is updated.

[0274] · The checksum field 387 of the parameter block is updated.

[0275] · A model-dependent value is stored into the model version number (MVN) field 363 of the parameter block.

[0276] · The end-of-block length (EOBL) 389 and end-of-block symbol (EOBS) 388 fields of the parameter block are updated.

[0277] · The operation end supplementary code (OESC) field 365 of the parameter block is set to zero.

[0278] · The address increment in general register R1 includes the number of processed bytes of the first operand that handles bit 0, and the length in general register R1+1 is decremented by the same number. The number of processed bytes of the first operand that includes handling bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed output bits and the original value of SBB, and the divisor is the value 8.

[0279] · The address in general register R2 increments by the number of processed source bytes, and the length in general register R2+1 is decremented by the same number.

[0280] · Condition code 1 is set.

[0281] The formation and update of the address and length depend on the addressing mode.

[0282] In one embodiment, when the first operand length is zero at the start of the execution of the instruction, the operation ends and the following occurs:

[0283] · Condition code 1 is set.

[0284] After the instruction ends with condition code 1 set, the program is expected to modify the first operand length, the first operand address, or both, and re-execute the instruction to resume operation.

[0285] When applicable, the following PER storage change events are recognized:

[0286] · Store to the parameter block, as described below.

[0287] · Store to the first operand location.

[0288] · Store to the third operand location, which occurs, for example, when the history buffer type (HBT) is 1 (circular).

[0289] When the entire parameter block overlaps the PER storage area specification, when applicable, the PER storage change event for the parameter block is recognized. When only a part of the parameter block overlaps the PER storage area specification, the following model-dependent situations occur:

[0290] · When applicable, the PER storage change event for the parameter block is recognized.

[0291] · When applicable, the PER storage change event for the part of the storage of the parameter block is recognized.

[0292] When applicable, when the HBT is 1 (circular), the PER zero-address detection events for the parameter block, the first operand location, the second operand location, and the third operand location are recognized.

[0293] Condition code 2 is not applicable to the DFLTC-CCMPR function.

[0294] When the instruction ends with condition code 1 or 3 set, the input data referenced from the second operand location may be processed either completely or only partially. When the input data is only partially processed, the results in the first operand location, the first operand address, the first operand length, and the SBB field of the parameter block do not represent a state consistent with the updated second operand address and length. In these cases, the partially processed data and internal status information may be placed in the CSB field of the parameter block. The amount of partially processed data depends on the conditions and model present at the end of the operation. Although some data may be only partially processed, the results stored to the left of the location specified by the updated first operand address are complete and will not be modified when the operation resumes. Additionally, it is expected that the program will subsequently re-execute the instruction to resume the operation, at which time the contents of the CSB field are referenced before resuming the operation. When the instruction ends with condition code 0 set, all data is processed completely and all results associated with the input and output data represent a consistent state.

[0295] After the instruction ends with a non-zero condition code set and before re-executing the instruction for the purpose of resuming the operation, the program shall not modify any fields of the parameter block; otherwise the results are unpredictable.

[0296] Function code 4: DFLTCC-XPND (Expand)

[0297] When the DFLTCC-XPND function is specified, a decompression operation is performed. This operation includes decoding the compressed data symbol from the second operand location into uncompressed data, and the uncompressed data is stored to the first operand location.

[0298] In one example, the DFLTCC-XPND function uses a parameter block, an example of which is shown above regarding Figures 3K - 3L An example of the parameter block is shown.

[0299] An example of the DFLTCC-XPND operation is described below with respect to decompressing data.

[0300] Normal completion occurs when all elements of the final block of the data set in the second operand have been decoded and all uncompressed data has been stored to the first operand location. The last block of the data set is identified when the BFINAL bit of the block header is 1. In one embodiment, when the operation ends due to normal completion, the following occurs:

[0301] · Model-related values are stored to the model version number (MVN) field 363 of the parameter block.

[0302] · The continue flag (CF) field 373 of the parameter block is set to zero.

[0303] · The sub - byte boundary (SBB) field 381 of the parameter block is updated.

[0304] · The history length (HL) field 385 of the parameter block is updated.

[0305] · When applicable, the history offset (HO) field 386 of the parameter block is updated.

[0306] · The compressed dynamic - Huffman table (CDHT) 367 and the compressed dynamic - Huffman table length (CDHTL) field 366 of the parameter block are set to zero.

[0307] · The operation end supplementary code (OESC) field 365 of the parameter block is set to zero.

[0308] · The checksum field 387 of the parameter block is updated.

[0309] · The number of bytes stored with the address incremented in the first operand position in general - purpose register R1, and the length in general - purpose register R1 + 1 is decremented by the same number.

[0310] · The number of processed bytes of the second operand that includes processing bit 0 with the address incremented in general - purpose register R2, and the length in general - purpose register R2 + 1 is decremented by the same number. The number of processed bytes of the second operand that includes processing bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed input bits and the original value of SBB, and the divisor is the value 8.

[0311] · Condition code 0 is set.

[0312] The formation and update of the address and length depend on the addressing mode.

[0313] When normal completion occurs, the CSB field 392 of the parameter block is not defined after the operation ends.

[0314] In one embodiment, when the number of bytes determined by the CPU has been processed, the operation ends and the following occurs:

[0315] · The continue flag (CF) bit 373 in the parameter block is set to 1.

[0316] · The continue status buffer (CSB) field 392 in the parameter block is updated.

[0317] · The sub - byte boundary (SBB) field 381 of the parameter block is updated.

[0318] · The Compressed Dynamic - Huffman Table (CDHT) 367 and Compressed Dynamic - Huffman Table Length (CDHTL) 366 fields of the parameter block are updated. When partial completion occurs while processing a block with a BTYPE value of binary 10, the bytes of the CDHT field that are not needed to represent the table are stored as zero. When partial completion occurs while processing a block with a BTYPE value of binary 00 or 01, zeros are stored into the CDHT and CDHTL fields.

[0319] · The History Length (HL) field 385 of the parameter block is updated.

[0320] · When applicable, the History Offset (HO) field 386 of the parameter block is updated.

[0321] · The Checksum field 387 of the parameter block is updated.

[0322] · Model - related values are stored into the Model Version Number (MVN) field 363 of the parameter block.

[0323] · The Operation End Supplementary Code (OESC) field 365 of the parameter block is set to zero.

[0324] · The Incomplete Function Status (IFS) field 383 of the parameter block is updated.

[0325] · When applicable, the Incomplete Function Length (IFL) field 384 of the parameter block is updated.

[0326] · The number of bytes by which the address in general register R1 is incremented is stored at the first operand location, and the length in general register R1 + 1 is decremented by the same number.

[0327] · The number of bytes by which the address in general register R2 is incremented contains the number of processed bytes of the second operand that processes bit 0, and the length in general register R2 + 1 is decremented by the same number. The number of processed bytes of the second operand that processes bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed input bits and the original value of SBB, and the divisor is the value 8.

[0328] · Condition code 3 is set.

[0329] The formation and update of the address and length depend on the addressing mode.

[0330] The number of bytes determined by the CPU depends on the model and can be different each time the instruction is executed.

[0331] After the instruction ends with condition code 3 set, it is expected that the program does not modify any of the instruction's input or output specifications and branches back to re - execute the instruction to resume operation.

[0332] In some cases, although the instruction ends with condition code 3 set, the parameter block and general registers are not updated. These situations can occur when the CPU performs a silent operation while executing the DEFLATE transform call instruction or when the CPU retries. In these cases, the number of bytes determined by the processed CPU is zero, data may have been stored to the first operand location, data may have been stored to the third operand location (if applicable), and the corresponding change bit has been set.

[0333] When, for example, the following situations apply, the second operand length is insufficient to complete the operation:

[0334] · During the operation, the last element of the compressed data block for which BFINAL equals 1 has not been decoded, and the number of bits in the second operand specified by the second operand length and SBB is less than the number of bits of the next element to be decoded, and all results from decoding the data at the second operand location have been placed at the first operand location.

[0335] In one embodiment, when the second operand length is insufficient to complete the operation, the operation has been partially completed, the operation ends, and the following occurs:

[0336] · The continue flag (CF) bit 373 in the parameter block is set to 1.

[0337] · The continue state buffer (CSB) field 392 in the parameter block is updated.

[0338] · The sub-byte boundary (SBB) field 381 of the parameter block is updated.

[0339] · The compressed dynamic-Huffman table (CDHT) 367 and the compressed dynamic-Huffman table length (CDHTL) field 366 of the parameter block are updated. When partial completion occurs while processing a block with a BTYPE value of binary 10, the bytes of the CDHT field that are not needed to represent the table are stored as zero. When partial completion occurs while processing a block with a BTYPE value of binary 00 or 01, zero is stored into the CDHT and CDHTL fields.

[0340] · The history length (HL) field 385 of the parameter block is updated.

[0341] · When applicable, the history offset (HO) field 386 of the parameter block is updated.

[0342] · The checksum value field 387 of the parameter block is updated.

[0343] · The model-related value is stored into the model version number (MVN) field 363 of the parameter block.

[0344] · The operation end supplementary code (OESC) field 365 of the parameter block is set to zero.

[0345] · The incomplete function status (IFS) field 383 of the parameter block is updated.

[0346] · When applicable, the incomplete function length (IFL) field 384 of the parameter block is updated.

[0347] · The address in general register R1 is incremented by the number of bytes stored at the first operand position, and the length in general register R1+1 is decremented by the same number.

[0348] · The address in general register R2 is incremented by the number of processed bytes of the second operand that processes bit 0, and the length in general register R2+1 is decremented by the same number. The number of processed bytes of the second operand that includes processing bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed input bits and the original value of SBB, and the divisor is the value 8.

[0349] · Condition code 2 is set.

[0350] The formation and update of the address and length depend on the addressing mode.

[0351] After the instruction ends with condition code 2 set, the program is expected to modify the second operand length, the second operand address, or both, and re-execute the instruction to resume the operation.

[0352] When, for example, the following situations apply, the first operand length is insufficient to complete the operation:

[0353] · The result of decoding the data from the second operand position cannot be placed at the first operand position because the first operand length is equal to zero.

[0354] In one embodiment, when the first operand length is insufficient to complete the operation, the operation has been partially completed, the operation ends, and the following occurs:

[0355] · The continue flag (CF) bit 373 in the parameter block is set to 1.

[0356] · The continue status buffer (CSB) field 392 in the parameter block is updated.

[0357] · The sub-byte boundary (SBB) field 381 of the parameter block is updated.

[0358] · The Compressed Dynamic - Huffman Table (CDHT) 367 and the Compressed Dynamic - Huffman Table Length (CDHTL) field 366 of the parameter block are updated. When partial completion occurs while processing a block with a BTYPE value of binary 10, the bytes of the CDHT field that are not needed to represent the table are stored as zeros. When partial completion occurs while processing a block with a BTYPE value of binary 00 or 01, zeros are stored into the CDHT and CDHTL fields.

[0359] · The History Length (HL) field 385 of the parameter block is updated.

[0360] · When applicable, the History Offset (HO) field 386 of the parameter block is updated.

[0361] · The checksum field 387 of the parameter block is updated.

[0362] · Model - related values are stored into the Model Version Number (MVN) field 363 of the parameter block.

[0363] · The Operation End Supplemental Code (OESC) field 365 of the parameter block is set to zero.

[0364] · The Incomplete Function Status (IFS) field 383 of the parameter block is updated.

[0365] · When applicable, the Incomplete Function Length (IFL) field 384 of the parameter block is updated.

[0366] · The address increment in general - purpose register R1 stores the number of bytes at the first operand position, and the length in general - purpose register R1 + 1 is decremented by the same number.

[0367] · The address increment in general - purpose register R2 stores the number of processed bytes of the second operand that processes bit 0, and the length in general - purpose register R2 + 1 is decremented by the same number. The number of processed bytes of the second operand that processes bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed input bits and the original value of SBB, and the divisor is the value 8.

[0368] · Condition code 1 is set.

[0369] The formation and update of the address and length depend on the addressing mode.

[0370] After the instruction ends with condition code 1 set, the program is expected to modify the first operand length, the first operand address, or both, and re - execute the instruction to resume the operation.

[0371] When applicable, PER storage change events are identified for the following:

[0372] · Storage into the parameter block, as described below.

[0373] · Store to the first operand location.

[0374] · Store to the third operand location, which occurs, for example, when the history buffer type (HBT) is 1 (circular).

[0375] In one example, when the entire parameter block overlaps with the PER storage area specification, a PER storage change event for the parameter block is identified, if applicable. In one embodiment, when only a portion of the parameter block overlaps with the PER storage area specification, the following model-dependent scenarios occur:

[0376] · A PER storage change event for the parameter block is identified, if applicable.

[0377] · A PER storage change event for the portion of the storage of the parameter block is identified, if applicable.

[0378] If applicable, when the HBT is 1 (circular), a PER zero-address detection event for the parameter block, the first operand location, the second operand location, and the third operand location is identified.

[0379] When the instruction ends with condition code 1, 2, or 3 set, the input data referenced from the second operand location may be processed either completely or only partially. When the input data is only partially processed, the results in the first operand location, the first operand address, the first operand length, the SBB field of the parameter block, the checksum field of the parameter block, the HL field of the parameter block, the IFS field of the parameter block, and (if applicable) the third operand location and the HO field of the parameter block do not represent a state consistent with the updated second operand address and length. In these cases, the partially processed data and internal state information may be placed in the CSB field of the parameter block. The amount of partially processed data depends on the conditions and model present at the end of the operation. Although some data may be only partially processed, the results stored to the left of the location specified by the updated first operand address are complete and will not be modified upon resumption of the operation. Additionally, it is expected that the program will subsequently re-execute the instruction to resume the operation, at which time the contents of the CSB field are referenced before the operation is resumed. When the instruction ends with condition code 0 set, all data is processed completely and all results associated with the input and output data represent a consistent state.

[0380] After the instruction ends with a non-zero condition code set and before the instruction is re-executed for the purpose of resuming the operation, the program shall not modify any fields of the parameter block; otherwise the results are unpredictable.

[0381] Compressed Data Blocks

[0382] In one example, the bytes of a compressed data block in a storage device are processed, for example, from left to right. The compressed data block may or may not start or end on a byte boundary. The compressed data block is, for example, a bit stream. The elements of the block are loaded into the storage device one bit at a time. The bit stream is loaded, for example, from right to left within each byte of the storage device and in byte order from, for example, left to right. When the element is a Huffman code, the bits are stored in order from, for example, the most significant bit to the least significant bit of the element. When the element is not a Huffman code, the bits are stored in order from, for example, the least significant bit to the most significant bit of the element.

[0383] Figure 6 An example of a block 600 with a block type value of binary 00 is shown, which does not contain compressed data symbols. In one embodiment, the following applies to this example:

[0384] · The compressed data block 600 consists of a bit stream 602 that starts with bit 4 (identified as b0) of byte 0 and ends with bit 0 (identified as b 60 ) of byte 7.

[0385] · The first element that appears in the bit stream is the BFINAL (block header final bit) in bit 4 of byte 0.

[0386] · The second element that appears in the bit stream is the BTYPE (block type) in bits 2 - 3 of byte 0. In the example, the BTYPE is binary 00.

[0387] · When the BTYPE is binary 00, the bits to the left of the BTYPE and to the right of the byte boundary are ignored. In the example, these are bits 0 - 1 of byte 0.

[0388] · The third element that appears in the bit stream is the least significant byte (LSB) of the LEN field, followed by the most significant byte (MSB) of the LEN field. The LEN field specifies the number of bytes in the block that have literal data. For example, the original data is uncompressed data. The bytes with literal data are after the NLEN field in the bit stream. NLEN is the one's complement of LEN. In one example, bytes 1 - 2 contain the LEN field in little - endian byte order.

[0389] · The elements that appear in the bit stream after the LEN field are the least significant byte of the NLEN field and then the most significant byte of the NLEN field. Bytes 3 - 4 contain the NLEN field in little - endian byte order. The NLEN field is the one's complement of the LEN field.

[0390] · The elements that appear in the bitstream after the NLEN field are uncompressed data, identified as literal bytes. Bytes 5 - 7 contain uncompressed data that is taken unchanged from the source data used to generate the block.

[0391] · None of the elements contained in the block are Huffman codes. Each element in the block is stored in the bitstream in order from the least significant bit of the element to the most significant bit, as defined by the DEFLATE standard. Since the LEN, NLEN, and literal elements are each an integer number of bytes aligned on byte boundaries, these elements can be processed in byte units and do not necessarily have to be processed in bit units.

[0392] Figure 7 An example of a block 700 with a block type value of binary 01 is shown. This block 700 contains compressed data symbols generated using a fixed Huffman table (FHT). In one embodiment, the following applies to this example:

[0393] · The compressed data block 700 consists of a bitstream 702 that starts with bit 4 of byte 0 (identified as b0) and ends with bit 3 of byte 11 (identified as b 89 )

[0394] · The first element that appears in the bitstream is BFINAL in bit 4 of byte 0.

[0395] · The second element that appears in the bitstream is BTYPE in bits 2 - 3 of byte 0. In this example, BTYPE is binary 01.

[0396] · The fixed - Huffman table (FHT) is not a component of the block.

[0397] · The third element that appears in the bitstream is the first compressed data symbol, which starts in bit 1 of byte 0. In one example, the compressed data symbol consists of the following subelements that appear in the bitstream in the order listed:

[0398] 1. A variable - length Huffman code. The most significant bit of the code specifies the length of the code. The code appears in the bitstream starting with the most significant bit of the code and ending with the least significant bit of the code. When the code represents a literal value or a block - end symbol, the code is the only subelement of the compressed data symbol. When the code represents the length of a pointer to the history buffer, the code is followed by the subsequent subelements of the compressed data symbol.

[0399] 2. When applicable, as specified by the DEFLATE standard, extra length bits may follow the Huffman code representing the pointer length. The extra length bits that appear in the bit stream start with the least significant bit of the extra length bits and end with the most significant bit of the extra length bits.

[0400] 3. The next sub - element that appears in the bit stream is a 5 - bit distance code for the pointer to the history buffer. The distance code that appears in the bit stream starts with the most significant bit of the distance code and ends with the least significant bit of the distance code.

[0401] 4. When applicable, as specified by the DEFLATE standard, extra distance bits may follow the distance code. The extra distance bits that appear in the bit stream start with the least significant bit of the extra distance bits and end with the most significant bit of the extra distance bits.

[0402] · As an example, bits 0 - 1 of byte 0, all bits of bytes 1 - 9, and bits 2 - 7 of byte 10 contain bits of the compressed data symbol.

[0403] · The last element that appears in the bit stream is a compressed data symbol containing a single sub - element, which is the Huffman code representing the end - of - block (EOB) symbol. The EOB symbol for a block with BTYPE value binary 01 is binary 0000000. In the example, bit 1 of byte 10 contains the most significant bit of the EOB symbol, and bit 3 of byte 11 contains the least significant bit of the EOB symbol.

[0404] · Bit 3 of byte 11 contains the last bit of the bit stream, which is the last bit of the compressed data block.

[0405] Figure 8 An example of a block 800 with block type value binary 10 is shown. Block 800 contains compressed data symbols generated using a dynamic - Huffman table (DHT). In one embodiment, the following applies to this example:

[0406] · The compressed data block 800 consists of a bit stream 802 that starts with bit 4 of byte 0 (identified as b0) and ends with bit 3 of byte 11 (identified as b 89 )

[0407] · The first element that appears in the bit stream is BFINAL in bit 4 of byte 0.

[0408] · The second element that appears in the bit stream is BTYPE in bits 2 - 3 of byte 0. In the example, BTYPE is binary 10.

[0409] · The third element that appears in the bitstream is a compressed representation of the Dynamic Huffman Table (DHT), which begins in bit 1 of byte 0. In one example, the compressed representation of the DHT consists of the following subelements that appear in the bitstream in the order listed:

[0410] 1. HLIT: The sum of a 5-bit HLIT subelement and 257 specifies the number of Huffman codes that represent literal bytes, the EOB symbol, and repeat string lengths. The valid value range of HLIT is, for example, 0 - 29. The HLIT bits that appear in the bitstream start with the least significant bit of the HLIT subelement and end with the most significant bit. In the example, bit 1 of byte 0 (identified as b3) is the least significant bit of the HLIT subelement.

[0411] 2. HDIST: The sum of a 5-bit HDIST subelement and 1 specifies the number of Huffman codes that represent repeat string pointer distances. The valid value range of HDIST is, for example, 0 - 29. The HDIST bits that appear in the bitstream start with the least significant bit of the HDIST subelement and end with the most significant bit.

[0412] 3. HCLEN: The sum of a 4-bit HCLEN subelement and 4 specifies the number of Huffman codes that represent code lengths. The valid value of HCLEN is, for example, 0 - 15. The HCLEN bits that appear in the bitstream start with the least significant bit of the HCLEN subelement and end with the most significant bit.

[0413] 4. A code sequence that specifies the bit length of each code length in the code lengths defined for the compressed DHT. The number of codes is equal to the sum of HCLEN and 4. Each code is 3 bits.

[0414] 5. A code sequence that specifies the code length for each element in the set consisting of literal bytes, the EOB symbol, and repeat string lengths. The number of specified code lengths is equal to the sum of HLIT and 257.

[0415] When the last code length (CL) for the set of literal bytes, the EOB symbol, and repeat string lengths is 16, 17, or 18 and the additional bits after CL specify repeating CL for more elements than there are elements defined for the set, the code length also applies to the set of repeat string pointer distances. The code sequence that specifies the code length for the set of literal bytes, the EOB symbol, and repeat string lengths and the code sequence that then specifies the code length for the repeat string pointer distances are consecutive sequences for the two sets.

[0416] 6. A code sequence that specifies the code length for each of the elements in the set consisting of repeat string pointer distances. The number of specified code lengths is equal to the sum of HDIST and 1.

[0417] · The fourth element that appears in the bitstream is the first compressed data symbol. In one embodiment, the compressed data symbol consists of the following subelements that appear in the bitstream in the listed order:

[0418] 1. A variable-length Huffman code. The most significant bit of the code specifies the length of the code. The code that appears in the bitstream starts with the most significant bit of the code and ends with the least significant bit of the code. When the code represents a literal value or an end-of-block symbol, the code is the only subelement of the compressed data symbol. When the code represents the length of a pointer to the history buffer, the code is followed by the subsequent subelements of the compressed data symbol.

[0419] 2. When applicable, as specified by the DEFLATE standard, additional length bits can follow the Huffman code that represents the length of the pointer. The additional length bits that appear in the bitstream start, for example, with the least significant bit of the additional length bits and end with the most significant bit of the additional length bits.

[0420] 3. The next subelement that appears in the bitstream is a 5-bit distance code for the pointer to the history buffer. The distance code that appears in the bitstream starts, for example, with the most significant bit of the distance code and ends with the least significant bit of the distance code.

[0421] 4. When applicable, as specified by the DEFLATE standard, additional distance bits can follow the distance code. The additional distance bits that appear in the bitstream start, for example, with the least significant bit of the additional distance bits and end with the most significant bit of the additional distance bits.

[0422] · The subsequent bits that appear in the bitstream (up to and including bit 5 of byte 10, for example) contain the bits of the compressed data symbol.

[0423] · The last element that appears in the bitstream is a compressed data symbol that contains a single subelement, which is a Huffman code that represents an end-of-block (EOB) symbol. In this example, bit 4 of byte 10 contains the most significant bit of the EOB symbol, and bit 3 of byte 11 contains the least significant bit of the EOB symbol.

[0424] · Bit 3 of byte 11 contains the last bit of the bitstream, which is the last bit of the compressed data block.

[0425] In the above descriptions of the different block types, certain constant values and specific bits, bytes, directions, etc. are specified. These are only examples. In other embodiments, other constant values, bits, bytes, directions, etc. can be specified.

[0426] Processing the compressed data set

[0427] Provide examples of processing compressed data sets to illustrate the example usage of the DEFLATE transform call instruction and the description of the various fields of the enhancement parameter block. These examples do not describe all possible scenarios, requirements, and capabilities, but illustrate different scenarios, requirements, and / or capabilities. These examples and descriptions apply, for example, to compressed data sets in storage, Figure 9 An example of such a compressed data set is shown. As shown, the compressed data set 900 includes a plurality of compressed data blocks 902, and the start of the data set 900 is indicated by the Compressed Data Set Beginning Address (CDSBA) 904.

[0428] For the examples described herein, in one embodiment, a program intended to process a compressed data set considers the following:

[0429] · A single parameter block can be defined and referenced by multiple uses of the DEFLATE transform call instruction to process the entire compressed data set. The checksum value 387 and checksum type 375 fields of the parameter block will apply to the compressed data blocks (e.g., all blocks) in the compressed data set. The sub-byte boundary field 381 of the parameter block will apply to the transformation between individual blocks. The history length 385 and history offset 386 can apply to multiple blocks. In one example, the remaining fields of the parameter block only apply to the individual compressed data blocks being processed by a particular execution of the DEFLATE transform call instruction.

[0430] · Individual checksums apply to, for example, all uncompressed data represented by the compressed data set.

[0431] · There is no history for the first compressed data symbol in block 1 to reference. Subsequent symbols in block 1 can reference a history corresponding to a previously occurring symbol in block 1. Symbols in block 2 can reference a history corresponding to previously occurring symbols in block 2 and block 1. Symbols in block 3 can reference a history corresponding to previously occurring symbols in block 3, 2, and 1.

[0432] Figure 10 Lists a sample program 1000 for compressing Figure 9 part of the data in the compressed data set 900 described above. Further, Figure 11 lists the values of certain fields of the parameter block used during the execution of the DFLTCC instruction at the instruction address labeled IABLK1(1002) located in Figure 10 above. For example, Figure 11 shows different parameter block fields 1100; the values 1102 of these fields at the start of the compression operation; the values 1104 of these fields when the operation ends and condition code 1, 2, or 3 is set; and the values 1106 of these fields when the operation ends and condition code 0 is set.

[0433] Similarly, Figure 12 lists certain field values of the parameter block used during the execution of the DFLTCC instruction at the instruction address labeled IABLK2(1004) located at Figure 10 . These figures illustrate some details associated with the repeated use of the DEFLATE transform call instruction to process an entire compressed data set.

[0434] In addition, referring to Figure 13 , an example of a portion of a sample program 1300 for decompressing the data in a Figure 9 compressed data set is shown.

[0435] Compressed data

[0436] The process of compressing data includes generating one or more compressed data blocks. The compression function of the DEFLATE transform call instruction is used to construct a portion of a single block. The portion can be the entire block. This function generates a portion of a block with a block type (BTYPE) value of binary 01 or 10 instead of 00. When the new task bit (NT) of the parameter block is 1, the first compressed data block is generated and there is no history from a previously executed compression operation to reference.

[0437] In one example, a single block contains the following elements in the order in which they are listed:

[0438] 1. Final block indicator (BFINAL).

[0439] 2. Block type (BTYPE).

[0440] 3. Compressed format of the dynamic - Huffman table (if applicable).

[0441] 4. Compressed data symbol.

[0442] 5. End - of - block (EOB) symbol.

[0443] The compression operation generates elements specified in the order defined for the block. The elements can start or end between byte boundaries in the storage device. The sub - byte boundary (SBB) applies to storing the first element into the first operand location. The compressed data block is a bit stream. The components of the block are loaded into memory one bit at a time. As an example, the bit stream is loaded from right - to - left within each byte of the storage device and from left - to - right in byte order.

[0444] When the SBB is non - zero, the reference to the first byte at the first operand location is an updated reference.

[0445] The uncompressed data from the second operand location is compressed and stored as a compressed data symbol into the first operand location.

[0446] When the length of the first operand is zero at the start of the execution of an instruction, the first operand is not accessed, and the first operand address and the first operand length in general-purpose registers R1 and R1+1 are not changed respectively. This applies when the value of the CF field 373 ( Figure 3L ) is 0 or 1 at the start of the execution of the instruction.

[0447] When the length of the second operand is zero at the start of the execution of an instruction, the second operand is not accessed, and the second operand address and the second operand length in general-purpose registers R2 and R2+1 are not changed respectively. For example, in the following cases, the length of the second operand is zero at the start of the execution of the instruction:

[0448] · The instruction is re-executed to resume an operation (the CF field 373 of the parameter block is 1 at the start of the execution of the instruction), and the completion of the operation can be executed by referring to the CSB field 392 of the parameter block instead of referring to the second operand.

[0449] In one embodiment, the program performs the following operations without using the DEFLATE transform call instruction:

[0450] · Generate an empty compressed data block. The empty compressed data block consists of, for example, a block header, the compressed format of the DHT (if applicable), and an EOB symbol.

[0451] · Close an open compressed data block. That is, only store the EOB symbol at the end of the compressed data block.

[0452] The compression algorithm includes searching for a byte string in the update history of the most recently compressed data that matches the data currently being compressed from the second operand position. In one embodiment, prior to the start or resumption of a compression operation, the following applies:

[0453] · When the new task (NT) 374 is 1, there is no initial history available for reference.

[0454] · When NT is zero and bit 56 of general-purpose register 0 (HBT) is zero (inline), the initial history available for reference is located to the left of and adjacent to the leftmost byte of the second operand, and the length of the initial history is specified by the history length (HL) field 385 of the parameter block.

[0455] · When NT is zero and bit 56 of general-purpose register 0 (HBT) is 1 (circular), the initial history available for reference is located in the third operand position as specified by the history offset (HO) 386 and history length (HL) 385 fields of the parameter block.

[0456] During a compression operation, fetch-type references can be made to the entire history, regardless of which bytes of the history are used to perform the operation. Additionally, when the history buffer type is circular, fetch-type references can be made to the entire 32K-byte history buffer, regardless of which bytes of the history are used to perform the operation.

[0457] During a compression operation, the history is updated. After one or more bytes of source data have been encoded into a compressed data symbol without a general operand data exception condition occurring, the source bytes are concatenated to the end of the history. The most recently processed bytes of the source data (up to 32K bytes) constitute the updated history, which can be used for reference during the processing of subsequent bytes of the source data.

[0458] In one example, when a compression operation ends, the following applies to the resulting history that can be used for subsequent resume operations or to start another operation:

[0459] · When the HBT is inline, no storage update to the second operand location is required when updating the history. The updated second operand address and the updated HL specify the updated location and updated length of the resulting history.

[0460] · When the HBT is circular, a storage update to the third operand location is performed when updating the history. The third operand address, the updated HO, and the updated HL specify the updated location and updated length of the resulting history.

[0461] As an example, Figures 14A - 14C illustrates the position of the inline history buffer for the second operand before and after multiple executions of the DEFLATE transform call instruction that specifies the DFLTCC-CMPR function and an inline history (e.g., bit 310 = 0) in cases where each execution ends in partial completion. For example, Figure 14A shows the inline history before the first execution of DFLTCC-CMPR; Figure 14B shows the inline history before the second execution of DFLTCC-CMPR and after the first execution; Figure 14C shows the inline history after the second execution of DFLTCC-CMPR. Figure 14C The explanations provided in Figure 14A and 14B .

[0462] When the HBT (History Buffer Type) specified by bit 56 of General Register 0 is circular (e.g., bit 310 = 1), the history is maintained in a 32K-byte buffer located, for example, at the third operand position. The position of the first byte of the history within the buffer (HB) is specified by the sum of, for example, the content of General Register R3 and the history offset (HO) 386( Figure 3L ). The first byte of the history is the least recently processed byte of the uncompressed data in the buffer. For example, the position of the last byte of the history within the buffer (HE) is specified by the following equation:

[0463] HE = R3 + modulo32K(HO + HL - 1)

[0464] The last byte of the history is the most recently processed byte of the uncompressed data in the buffer. When the sum of the history offset (HO) 386( Figure 3L ) and the history length (HL) 385 exceeds the size of the third operand (e.g., 32K bytes), the history wraps from the end of the third operand to the start of the third operand.

[0465] As an example, Figures 15A - 15E illustrates the position of the history within the circular history buffer before and after multiple executions of the DEFLATE transform call instruction that specifies the DFLTCC-CMPR function and a circular history buffer (bit 310 = 1) when each execution ends in a partial completion. For example, Figure 15A shows the circular history buffer before the first execution of DFLTCC; Figure 15B shows the circular buffer before the second execution of DFLTCC and after the first execution; Figure 15C shows the circular buffer before the third execution of DFLTCC and after the second execution; Figure 15D shows the circular buffer before the fourth execution of DFLTCC and after the third execution; Figure 15E shows the circular buffer after the fourth execution of DFLTCC. Figure 15E The explanations provided in Figures 15A - 15D .

[0466] In one example, when the HBT is circular and the number of bytes processed in the second operand position is less than, for example, 32,768, the following applies:

[0467] · Store a byte range at the third operand position. The byte range includes and starts at a position specified, for example, by:

[0468] · R3 + modulo32K(HOO + HLO), where

[0469] ·HOO: Historical offset before instruction execution.

[0470] ·HLO: Historical length before instruction execution.

[0471] ·This byte range includes and ends at a location specified, for example, by:

[0472] ·R3 + modulo32K(HOO + HLO + BP - 1), where

[0473] ·BP: Number of bytes processed during instruction execution in the second operand location.

[0474] As an example, the storage to the byte range just described is affected by storage type access exceptions, PER storage change events, and set change bits.

[0475] ·Storage that does not modify the content of the storage location and is not required can be made to bytes in the third operand location that are not included in the range just described. Storage to these locations is also affected by storage type access exceptions, PER storage change events, and set change bits.

[0476] When HBT is circular and the number of bytes processed in the second operand location is greater than or equal to, for example, 32,768, all bytes in the third operand location are stored and are affected by storage type access exceptions, PER storage change events, and set change bits.

[0477] When the block continue flag (BCF) 377 is 0, a 3-bit block header (including BFINAL, followed by BTYPE) is stored to the first operand location. The BFINAL bit of the block header is set equal to the block header final bit (BHF) 379 of the parameter block. When the Huffman table type (HTT) 376 is 0, the BTYPE field of the block header is set to, for example, binary 01; when HTT is 1, the BTYPE field of the block header is set to, for example, binary 10. When storing the block header, the BFINAL bit is stored to the bit in the first byte of the first operand specified by SBB. Subsequently, the BTYPE is stored to the first operand location. When BCF is 1, the block header is not stored.

[0478] When the Huffman table type (HTT) is 1, for a general operand data exception condition, the compression format of the dynamic-Huffman table (DHT) 367 specified in the parameter block is checked. When the specified compression format of the DHT has a general operand data exception condition, the compressed DHT is called invalid and is not used for compressing data. Example definitions of general operand data exception conditions are further described below. When the bit length of the code length specified by the DHT's compression format is greater than the length of the code length required by the Huffman algorithm to specify a proper and functional Huffman tree, or the code length of a literal byte, the EOB symbol, the repeat string length, or the repeat string pointer distance, the compressed DHT is still used to derive the functional DHT and compress data. When the block continue flag (BCF) is 0 and HTT is 1, the compression format of the DHT specified in the CDHT field 367 of the parameter block is stored in the first operand location.

[0479] During the compression operation, the source data from the second operand location is encoded into compressed data symbols. As part of the encoding, the source data is compared with the history. When no match is found, the intermediate representation of the source data is a literal byte, which is the same as the source data. When a match is found, the intermediate representation of the source data is a pointer to the location within the history that contains a copy of the source data. The pointer consists of a length and a distance. The length is the number of source data bytes that match the string in the history. The distance is the number of bytes from the end of the history to the start of the string that matches the source data. In one example, two Huffman code trees from the Huffman table are used to encode the intermediate representation of the source data into compressed data symbols. When the Huffman table type (HTT) is zero, the fixed-Huffman table (FHT) as described by the DEFLATE standard specifies the two Huffman code trees used to encode the intermediate result. When HTT 376 is 1, the dynamic-Huffman table (DHT) specified in the CDHT field 367 of the parameter block, derived from the compressed representation of the DHT, specifies the two Huffman code trees used to encode the intermediate result. Encoding is performed as described by the DEFLATE standard. When a non-general DHT that does not specify the Huffman code to be used for encoding the intermediate representation of the source data is used, a general operand data exception is recognized. Before storing the result in the first operand location, the bits of the resulting compressed data symbols are arranged in the order specified by the DEFLATE standard.

[0480] In one example, the repeat string length ranges from 3 bytes to 258 bytes.

[0481] Before processing further source data, the history is updated as described herein.

[0482] In one example, the process is repeated until all source bytes have been processed.

[0483] After all source bytes (e.g., all source bytes) have been processed and the block close control (BCC) 378 is 1, the end-of-block (EOB) symbol is stored in the first operand location. When using a fixed-Huffman table, the Huffman code binary 0000000 is used as the EOB symbol. When using a dynamic-Huffman table (DHT), the Huffman code specified by the DHT is used as the EOB symbol. Before storing the EOB symbol in the first operand location, the bits of the EOB symbol are arranged in the order specified by the DEFLATE standard.

[0484] In one example, when the last compressed data symbol (including the EOB symbol) of an operation occupies only a part of the last byte to be stored, the bits that do not include the part of the last symbol are stored as zero.

[0485] In one embodiment, after processing the last compressed data symbol, the following occurs:

[0486] · The model-related value is stored in the model version number (MVN) field 363 of the parameter block.

[0487] · The sub-byte boundary (SBB) field 381 of the parameter block is updated.

[0488] · The end-of-block length (EOBL) 389 and end-of-block symbol (EOBS) 388 fields of the parameter block are updated.

[0489] · The address increment in general register R1 includes the number of processed bytes of the first operand that processes bit 0, and the length decrement in general register R1+1 is the same number. The number of processed bytes of the first operand that processes bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of processed output bits and the original value of the SBB, and the divisor is the value 8.

[0490] · The address increment in general register R2 is the number of processed source bytes, and the length decrement in general register R2+1 is the same number.

[0491] The formation and update of the address and length depend on the addressing mode.

[0492] Consistent with the compressed source data, the source data is the input used to generate the 32-bit check value as described above. The resulting check value is stored in the check value field 387 of the parameter block.

[0493] Decompressed data

[0494] In one embodiment, the extended function of the DEFLATE conversion call instruction is used to decode a compressed data set into uncompressed data. The compressed data set in the second operand location includes one or more consecutive compressed data blocks. In one example, the blocks of the data set are processed from left to right, and for example, the bytes of the blocks are processed from left to right. A block may or may not begin or end on a byte boundary. Each block is decoded independently of the other blocks in the data set. The general register R2 specifies the logical address of the leftmost byte of the first block in the data set. The last block in the data set is the block for which the BFINAL bit equals 1 during processing. In one example, there are three types of blocks to be processed. The technique for decoding the content of a block is a function of the block type (BTYPE).

[0495] When the operation begins (e.g., when the continue flag field 373 of the parameter block is zero), the bit specified by the general register R2, the new task (NT) field 374, and the sub-byte boundary (SBB) field 381 are interpreted as the first bit (the BFINAL bit of the block header) of the compressed data block.

[0496] The extended function includes referencing an updated history of the most recently decoded uncompressed data. In one embodiment, prior to the start or resumption of the decompression operation, the following applies:

[0497] · When the new task (NT) 374 is 1, there is no initial history available for reference.

[0498] · When NT is zero and bit 56 of the general register 0 (HBT) is zero (inline), the initial history available for reference is located to the left of and adjacent to the leftmost byte of the first operand, and the length of the initial history is specified by the history length (HL) field 385 of the parameter block.

[0499] · When NT is zero and bit 56 of the general register 0 (HBT) is 1 (circular), the initial history available for reference is located in the third operand location as specified by the history offset (HO) 386 and history length (HL) 385 fields of the parameter block.

[0500] During the operation, extractive references can be made to the entire history, regardless of which bytes of the history are used to perform the operation. Additionally, when the history buffer type is circular, extractive references can be made to the entire history buffer (e.g., 32K bytes), regardless of which bytes of the history are used to perform the operation.

[0501] During the decompression operation, update the history. After decoding the source data without a general operand data exception condition, concatenate the result bytes in the uncompressed data to the end of the history. For example, the most recently decoded bytes of up to 32K bytes of uncompressed data constitute the updated history, which can be used for reference during the processing of subsequent source data.

[0502] In one example, when the decompression operation ends, the following applies to the result history that can be used for subsequent recovery operations or to start another operation:

[0503] · When the HBT is inline, the storage update to the first operand location also constitutes an update to the result history. The updated first operand address and the updated HL specify the updated location and updated length of the result history.

[0504] · When the HBT is circular, a storage update to the third operand location is made when updating the history. The third operand address, the updated HO, and the updated HL specify the updated location and updated length of the result history.

[0505] As an example, Figures 16A - 16C illustrates the position of the inline history buffer for the first operand before and after multiple executions of the DEFLATE transform call instruction that specifies the DFLTCC-XPND function and specifies an inline history. For example, Figure 16A shows the inline history before the first execution of DFLTCC-XPND; Figure 16B shows the inline history before the second execution of DFLTCC-XPND and after the first execution; Figure 16C shows the inline history after the second execution of DFLTCC-XPND. Figure 16C The explanations provided in Figure 16A also apply to 16B .

[0506] When the HBT specified by bit 56 of general register 0 is circular, maintain the history in a 32K byte buffer located, for example, at the third operand position. The position of the first byte of the history within the buffer (HB) is specified by the sum of the contents of general register R3 and the history offset (HO) 386. The first byte of the history is the earliest processed byte of the uncompressed data in the buffer. The position of the last byte of the history within the buffer (HE) is specified by, for example, the following equation:

[0507] HE = R3 + modulo32K(HO + HL - 1).

[0508] The last byte of history is the most recently processed byte of the uncompressed data in the buffer. When the sum of the history offset (HO) and the history length (HL) exceeds the size of the third operand (e.g., 32K bytes), the history wraps around from the end of the third operand to the start of the third operand. As described herein Figures 15A - 15E illustrates examples of the position of the history in the circular history buffer before and after multiple executions of a DEFLATE transform call instruction that specifies the DFLTCC-XPND function and specifies an inline history, when each execution ends in a partial completion.

[0509] In one example, when the HBT is circular and the number of bytes stored to the first operand location is less than, for example, 32,768, the following applies:

[0510] · Store a byte range at the third operand location. The byte range includes and begins at, for example, the location specified by:

[0511] R3 + modulo32K(HOO + HLO), where

[0512] HOO: The history offset before instruction execution.

[0513] HLO: The history length before instruction execution.

[0514] The byte range includes and ends at, for example, the location specified by:

[0515] R3 + modulo32K(HOO + HLO + BP - 1), where

[0516] BP: The number of bytes stored to the first operand location during instruction execution.

[0517] · Storage that does not modify the contents of the storage location and is not required can be made to bytes in the third operand location that are not included in the range just described. Storage to these locations is also affected by storage type access exceptions, PER storage change events, and set change bits.

[0518] When the HBT is circular and the number of bytes stored to the first operand location is greater than or equal to, for example, 32,768, all bytes of, for example, the third operand location are stored and are affected by storage type access exceptions, PER storage change events, and set change bits.

[0519] When the BTYPE is binary 00, the block does not contain compressed data. As described herein Figure 6Shows an example of a block with a BTYPE equal to binary 00. The LEN field specifies the number of literal bytes in the block. The byte order of the LEN field is little - endian. The LEN field can specify zero literal bytes. The literal bytes of the block are placed at the first operand position. As previously described, the history is also updated using each literal byte of the block.

[0520] When the BTYPE is binary 01, the block contains compressed data symbols generated using a fixed Huffman table (FHT). The FHT is defined by the DEFLATE standard and is not part of the block. As described herein, Figure 7 Shows an example of a block with a BTYPE value equal to binary 01. After interpreting the block header, the compressed data symbols are decoded in the order in which they appear in the block. For example, the bytes of the block are processed from left to right, and for example, the bits within each byte of the block are processed from right to left. In one example, each symbol is fully processed before processing the next symbol in the block. Each symbol that is not an end - of - block (EOB) symbol represents either a literal value or a pointer to a previously decoded substring in the history buffer. The previously decoded substring is also referred to as a repeat string. In one example, the repeat string length ranges from 3 bytes to 258 bytes. The pointer consists of a code representing the substring length and the distance from the end of the history to the start of the substring. When the symbol represents a substring in the history, the substring is referenced from the history buffer. The uncompressed data resulting from decoding the symbol is placed at the first operand position.

[0521] Before processing further source data, the history is updated as previously described.

[0522] The updated history applies to decoding the next symbol of the block. When an EOB symbol appears, the processing of the block is complete.

[0523] When the BTYPE is binary 10, the block contains compressed data symbols generated using a dynamic - Huffman table (DHT). The compressed format of the DHT used is an element of the compressed data block. Described herein Figure 8Shows an example of a block with a BTYPE equal to binary 10. After interpreting the block header, check the compressed format of the DHT provided within the compressed data block for a general operand data exception condition. When the compressed format of the provided DHT has a general operand data exception condition, the compressed format of the DHT is said to be invalid and is not used to decompress the data. When the compressed format of the DHT specifies a bit length for a code length, or the code length of a literal byte, an EOB symbol, a repeat string length, or a repeat string pointer distance that is greater than the length required for a proper and functional Huffman tree as specified by the Huffman algorithm, the compressed DHT is still used to derive the functional DHT and the compressed data. After checking the compressed format of the DHT, decode the compressed data symbols in the order in which they appear in the block. For example, process the bytes of the block from left to right, and for example, process the bits within each byte of the block from right to left. In one example, each symbol is fully processed before processing the next symbol in the block. The processing of the symbols in a block with a BTYPE value of binary 10 is the same as the processing of the symbols in a block with a BTYPE value of 01 described previously, except that the former uses the DHT provided to decode the symbols, while the latter uses the FHT to decode the symbols. When a non - general DHT that does not specify the Huffman code to be used to decode the compressed data symbols is provided, a general operand data exception is recognized.

[0524] Consistent with decompressing the second operand, the uncompressed data is the input used to generate a check value (e.g., a 32 - bit check value). The resulting check value is stored in the check value field 387 of the parameter block.

[0525] In one embodiment, after processing the last block of a data set, the following occurs:

[0526] · Model - related values are stored in the model version number (MVN) field 363 of the parameter block.

[0527] · The sub - byte boundary (SBB) field 381 of the parameter block is updated.

[0528] · The address in general register R1 is incremented by the number of bytes stored at the first operand location, and the length in general register R1 + 1 is decremented by the same number.

[0529] · The address in general register R2 is incremented by the number of processed bytes of the second operand that includes processing bit 0, and the length in general register R2 + 1 is decremented by the same number. The number of processed bytes of the second operand that includes processing bit 0 is the integer quotient obtained from an integer division, where the divisor is the sum of the number of processed input bits and the original value of the SBB, and the divisor is the value 8.

[0530] The formation and update of the address and length depend on the addressing mode.

[0531] When the length of the first operand is zero at the start of the execution of an instruction, the first operand is not accessed, and the first operand address and the first operand length in general-purpose registers R1 and R1 + 1 are not changed respectively. This applies when the value of the CF field 373 at the start of the execution of the instruction is zero or 1.

[0532] When the length of the second operand is zero at the start of the execution of an instruction, the second operand is not accessed, and the second operand address and the second operand length in general-purpose registers R2 and R2 + 1 are not changed respectively. In one embodiment, the length of the second operand is zero at the start of the execution of the instruction for the following cases:

[0533] · The instruction is re-executed (e.g., the CF field 373 of the parameter block is 1 at the start of the execution of the instruction), and the entire second operand was processed when the instruction was previously executed.

[0534] The decompression operation can end without storing any result to the first operand location, even if data from the second operand location has been processed. In one example, this occurs when the processed data from the second operand location contains only any one of the following compressed data block elements:

[0535] · Block header.

[0536] · The LEN field of a block with a block type value of binary 00.

[0537] · The NLEN field of a block with a block type value of binary 00.

[0538] · Compressed format of the dynamic-Huffman table.

[0539] · End-of-block (EOB) symbol.

[0540] In one or more embodiments, the following conditions apply to the execution of the DEFLATE transform call instruction:

[0541] In one example, when the DFLTCC-GDHT function is specified and the following conditions occur, a general operand data exception is recognized:

[0542] · The model does not support the parameter block format specified by the parameter block version number 362.

[0543] In one example, when the DFLTCC-CMPR function is specified and any one of the following conditions occurs, a general operand data exception is recognized:

[0544] · The model does not support the parameter block format specified by the parameter block version number 362.

[0545] ·NT 374 is zero and HL 385 is greater than, for example, 32,768.

[0546] ·HTT 376 is 1 and CDHTL 366 is less than, for example, 42 or greater than, for example, 2283.

[0547] ·HTT 376 is 1 and CDHTL 366 is not equal to the length of the compression format of the DHT specified in the CDHT field 367.

[0548] ·HTT 376 is 1 and the HLIT sub-element of the compression format of the DHT is greater than, for example, 29 (invalid DHT).

[0549] ·HTT 376 is 1 and the HDIST sub-element of the compression format of the DHT is greater than, for example, 29 (invalid DHT).

[0550] ·HTT 376 is 1 and the compression format of the DHT (the content of the CDHT field 367) specifies a code in a code sequence of bit lengths, for example, 19 code lengths defined for the compressed DHT, and the code is less than the length required for the Huffman tree specified by the Huffman algorithm (invalid DHT).

[0551] ·HTT 376 is 1 and the compression format of the DHT (the content of the CDHT field 367) specifies that the code length, for example, 16 (copy the previous code length), is the first code length of a set of elements consisting of literal bytes, EOB symbols, and repeat string lengths (invalid DHT).

[0552] ·HTT 376 is 1 and the compression format of the DHT (the content of the CDHT field 367) specifies a code in a code sequence that specifies the code length of literal bytes, and the code does not match any code in the set of codes determined to represent the reference code lengths as previously specified in the compressed DHT (invalid DHT).

[0553] ·HTT 376 is 1 and the compression format of the DHT (the content of the CDHT field 367) specifies a code that assigns the code length 0 (CL0) to the EOB symbol. In this case, the corresponding DHT does not specify a Huffman code to represent the EOB symbol (invalid DHT).

[0554] ·HTT 376 is 1 and the compression format of the DHT (the content of the CDHT field 367) specifies a code in a code sequence that specifies the code lengths of repeat string lengths and pointer distances, and the code does not match any code in the set of codes determined to represent the reference code lengths as previously specified in the compressed DHT.

[0555] ·HTT 376 is 1, and the number of code lengths specified by the compressed format of the DHT (the content of the CDHT field 367) is greater than the number of Huffman codes in the DHT - as specified by the values in the HLIT field, the HDIST field, and the sum such as 258 for example. This is possible, for example, in the case of incorrect use of code lengths 16, 17, and 18 (invalid DHT).

[0556] ·HTT 376 is 1, and the code lengths of the set of literal bytes, EOB symbols, and repeat string lengths specified by the compressed format of the DHT (the content of the CDHT field 367) are less than the lengths required to specify a functional Huffman tree by the Huffman algorithm (invalid DHT).

[0557] ·HTT 376 is 1, and the code lengths of the set of repeat string pointer distances specified by the compressed format of the DHT (the content of the CDHT field 367) are less than the lengths required to specify a functional Huffman tree by the Huffman algorithm (invalid DHT).

[0558] ·The CPU attempts to generate compressed data symbols to represent literal bytes in the second operand, and the DHT derived from the content of the CDHT field is non - generic and does not specify a Huffman code corresponding to that literal byte.

[0559] ·The CPU attempts to generate compressed data symbols to represent a repeat string in the second operand, and the DHT derived from the content of the CDHT field is non - generic and does not specify a Huffman code corresponding to that repeat string length or pointer distance.

[0560] As an example, when, for example, the DFLTCC - XPND function is specified and any of the following conditions occur, a general operand data exception is recognized:

[0561] ·The model does not support the parameter block format specified by the parameter block version number 362.

[0562] ·NT 374 is zero, and HL385 is greater than, for example, 32,768.

[0563] ·A compressed data block with BTYPE equal to binary 11 appears.

[0564] ·A compressed data block with BTYPE equal to binary 00 and NLEN not equal to the one's complement of LEN appears.

[0565] ·The compressed format of the DHT appears (the content of the compressed data block with BTYPE equal to binary 10), and the HLIT sub - element of this compressed DHT is greater than, for example, 29 (invalid DHT).

[0566] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), and the HDIST sub - element of the compressed DHT is greater than, for example, 29 (invalid DHT).

[0567] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), which specifies a code in a code sequence of bit lengths, for example, 19 code lengths defined for the compressed DHT, and is less than the length required for the Huffman tree specified by the Huffman algorithm (invalid DHT).

[0568] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), which specifies that the code length, for example, 16 (copy the previous code length), is the first code length of a set of elements consisting of literal bytes, EOB symbols, and repeat string lengths (invalid DHT).

[0569] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), which specifies a code in a code sequence that specifies the code length of literal bytes, and this code does not match any of the codes determined to represent the set of reference code lengths as previously specified in the compressed DHT (invalid DHT).

[0570] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), which specifies a code that assigns a code length of 0 (CL0) to the EOB symbol. In this case, the corresponding DHT does not specify a Huffman code to represent the EOB symbol (invalid DHT).

[0571] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), which specifies a code in a code sequence that specifies the code lengths of repeat string lengths and pointer distances, and this code does not match any of the codes determined to represent the set of reference code lengths as previously specified in the compressed DHT.

[0572] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), and the number of specified code lengths is greater than the number of Huffman codes in the DHT - as specified by the values in the HLIT field, HDIST field, and, for example, the sum of 258. For example, this is possible when codes 16, 17, and 18 are used incorrectly (invalid DHT).

[0573] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), which specifies the code lengths of a set of literal bytes, EOB symbols, and repeat string lengths, which is less than the length required for the functional Huffman tree specified by the Huffman algorithm (invalid DHT).

[0574] · The compressed format of DHT appears (the content of the compressed data block with BTYPE equal to binary 10), which specifies the code lengths of a set of repeat string pointer distances, which is less than the length required for the functional Huffman tree (invalid DHT) specified by the Huffman algorithm.

[0575] · The compressed data symbol that appears in the compressed data block with BTYPE equal to binary 10 specifies a Huffman code that is not defined by a non-universal DHT derived from the compressed format of DHT in the same block. In this case, the number of bits available for processing of the second operand (for the purpose of identifying a general operand data exception) is model-dependent. More specifically, a model that attempts to decode an undefined code may process, for example, 15 bits before identifying the exception, even though the exception can be determined after processing fewer bits.

[0576] · The compressed data symbol appears, which is a repeat string pointer and specifies a distance greater than the length of the history available at the time of processing the symbol.

[0577] · The compressed data symbol that appears in the compressed data block with BTYPE equal to binary 01 specifies an invalid code (for example, the binary code 11000110 or 11000111 for the repeat string length, or the binary code 11110 or 11111 for the repeat string pointer distance). In this case, the number of bits available for processing of the second operand (for the purpose of identifying a general operand data exception) is model-dependent. More specifically, a model that attempts to decode an invalid code may process, for example, 8 bits (in the case of the repeat string length) or 5 bits (in the case of the repeat string pointer distance) before identifying the exception, even though the exception can be determined after processing fewer bits.

[0578] When a general operand data exception is recognized, the operation is considered inhibited even if the operation to update the parameter block ends with the supplementary code (OESC) 365 and the model version number (MVN) field 363 being updated to provide additional information associated with the exception.

[0579] When the DFLTCC-CMPR or DFLTCC-XPND function is being executed and a general operand data exception is to be identified for the second operand, the result is either the identification of the exception or the operation ends partially completed and, for example, condition code 3 is set. If condition code 3 is set, then when the instruction is executed again to continue processing the same operand and the exception condition still exists, the exception will be identified.

[0580] Other conditions include, for example:

[0581] The execution of the instruction is interruptible. When an interruption occurs, the addresses in general-purpose registers R1 and R2, the lengths in general-purpose registers R1+1 and R2+1, and specific fields of the parameter block are updated so that the instruction resumes at the interruption point when re-executed.

[0582] When the DFLTCC-CMPR or DFLTCC-XPND function is being executed and an access exception is to be recognized for the first or second operand, the result is either that the exception is recognized or the operation ends partially completed and, for example, condition code 3 is set. If condition code 3 is set, the exception will be recognized when the instruction is re-executed to continue processing the same operand and the exception condition still exists.

[0583] As observed by this CPU, other CPUs, and channel programs, references to the parameter block, first, second, and third operands may be multiple-access references, accesses to these storage locations are not necessarily block-concurrent, and the order of these accesses or references is undefined.

[0584] In one embodiment, if the DFLTCC-CMPR or DFLTCC-XPND function is specified and any of the following apply, the result is unpredictable:

[0585] · The parameter block overlaps the first or second operand.

[0586] · The first operand overlaps the second operand.

[0587] · The specified history buffer type (HBT) is circular and the third operand overlaps the first operand, second operand, or parameter block.

[0588] · The specified history buffer type (HBT) is inline, the DFLTCC-CMPR function is specified, and the history overlaps the first operand or parameter block.

[0589] · The specified history buffer type (HBT) is inline, the DFLTCC-XPND function is specified, and the history overlaps the second operand or parameter block.

[0590] In some cases, although the execution of the DEFLATE conversion call instruction ends with the number of processed bytes determined by the CPU being zero, data may have been stored in the first operand location, data may have been stored in the third operand location (when applicable), and the corresponding change bits may have been set (when applicable). In these cases, the contents of the parameter block and the general-purpose registers have not been modified from their original values. These cases may occur when the CPU performs a silent operation while executing the DEFLATE conversion call instruction or when the CPU retries.

[0591] The following are exemplary condition codes obtained from the execution of the DEFLATE conversion call instruction:

[0592] 0 Normal completion

[0593] 1 The length of the first operand is insufficient to complete the operation

[0594] 2 The length of the second operand is insufficient to complete the operation (DFLTCC-XPND)

[0595] 3 The amount of processed data determined by the CPU

[0596] Program exceptions:

[0597] · Access (extract, operand 2, inline history; extract and store, parameter block, operand 1, operand 3)

[0598] · Data with DXC 0, general operand

[0599] · Operation (if the DEFLATE conversion facility is not installed)

[0600] · Specification

[0601] · Transaction constraints

[0602] The exemplary priorities for the execution of the DEFLATE CONVERSION CALL instruction are as follows:

[0603] 1. - 6. Exceptions with the same priority as the program interruption conditions in the general case.

[0604] 7.A Access exception for the second instruction halfword.

[0605] 7.B Operation exception.

[0606] 7.C Transaction constraints.

[0607] 8A. Specification exception attributed to an invalid function code or an invalid register number.

[0608] 8.B Specification exception attributed to a parameter block not specified on a 4K byte boundary.

[0609] 8. A specified exception attributed to a circular history buffer not specified on a 4K byte boundary.

[0610] 9. An access exception for an access parameter block.

[0611] 10. A general operand data exception when the specified format of the parameter block is not supported by the mode.

[0612] 11. A specified exception attributed to the second operand length being equal to zero and CF being equal to zero at the start of the execution of the instruction.

[0613] 12. A specified exception attributed to the first operand length being equal to zero and condition code 1 of DFLTCC - CMPR being specified at the start of the execution of the instruction.

[0614] 13A. A general operand data exception attributed to the history length field being greater than 32,768 and the new task field being equal to zero when DFLTCC - CMPR or DFLTCC - XPND is specified.

[0615] 13.B An access exception for accessing the first operand and the first operand length being non - zero.

[0616] 13.C An access exception for accessing the second operand and the second operand length being non - zero.

[0617] 13.D An access exception for accessing the specified inline history at the start of the execution of the instruction.

[0618] 13.E An access exception for accessing the third operand.

[0619] 14.A. A general operand data exception attributed to conditions other than those included in items 10 and 13.A above.

[0620] 14.B A condition code 1, 2, or 3 attributed to conditions other than those included in item 12 above.

[0621] 15. Condition code 0.

[0622] Before use, check if there are general operand data exception conditions for the compression format of the DHT. When the length of the compression format of the DHT is not precisely defined due to general operand data exception conditions, the interpreted length may depend on the condition, on the model, and not exceed, for example, 286 bytes. As a result, when the DFLTCC - XPND function is specified and the compression format of the DHT with general operand data exception conditions appears in, for example, the rightmost 286 bytes of the second operand, whether an abnormal condition (priority 14.A) or condition code 2 (priority 14.B) is recognized is model - dependent.

[0623] Exemplary programming annotations are provided below:

[0624] 1. When compressing or decompressing data, it may generally be more efficient to perform the operation with the minimum number of times of executing the instruction for DEFLATE transformation call. In other words, executing DFLTCC with large operands is many times more efficient than executing DFLTCC with small operands.

[0625] 2. For compression and decompression operations, when condition code 3 is set, the general-purpose registers used by the instruction and the parameter block have been updated, enabling the program to branch back to the instruction to continue the operation.

[0626] 3. In one embodiment, the DEFLATE transformation call instruction can be completed after a sub-part of the processing specified by the parameters of the instruction determined by the CPU has been executed. When the instruction is completed after only executing the amount of processing determined by the CPU rather than all the specified processing, the instruction sets condition code 3. At such a completion, the instruction address in the PSW (Program Status Word) specifies the next sequential instruction, and the operand parameters of the instruction have been adjusted such that the processing of the instruction can be resumed by branching back to the instruction to execute the instruction again. When the instruction has executed all the specified processing, it sets a condition code other than 3.

[0627] 4. When the DFLTCC-CMPR function is specified and the operation ends with a non-zero value in the sub-byte boundary (SBB) field of the parameter block, the operation includes storing to the byte specified by the result first operand address. When the DFLTCC-XPND function is specified and the operation ends with a non-zero value in the SBB, the operation includes extracting the byte specified by the result second operand address.

[0628] 5. When the operation ends with a non-zero condition code set, the CSB field 392 of the parameter block may contain partially processed data, and it is expected that the program re-executes the instruction to resume the operation.

[0629] 6. After the operation ends with a non-zero condition code set and before re-executing the instruction for the purpose of resuming the operation, the program does not modify any fields of the parameter block; otherwise the result is unpredictable.

[0630] 7. When the DFLTCC-GDHT function is specified, according to the Huffman algorithm, the compressed representation of the generated DHT describes three appropriately complete Huffman code trees. That is, no under-complete Huffman code tree is described. An under-complete Huffman code tree is derived from the compressed representation of the DHT, which specifies the code lengths of elements greater than the length required by the Huffman algorithm for specifying appropriate and functional Huffman trees.

[0631] When the DFLTCC-CMPR function is specified, HTT is 1, and the compressed representation of the DHT includes a description of an incomplete Huffman code tree, the DFLTCC-XPND function can be utilized to convert the compressed data result to the original uncompressed data. However, not all decoders compliant with the DEFLATE standard are capable of converting the result to the original uncompressed data. For example, this can occur when the compressed representation of the DHT specified by the program of the DFLTCC-CMPR function is not generated due to the execution of the DFLTCC-GDHT function.

[0632] 8. When the DFLTCC-CMPR function ends with condition code 1 set, the result stored in the sub-byte boundary (SBB) field 381 of the parameter block is binary 000. Identifying this situation can be relevant to a program that allocates an output buffer for use with the DEFLATE conversion call instruction.

[0633] As described herein, in one aspect, a single instruction (e.g., a single architected machine instruction at a hardware / software interface, such as the DEFLATE conversion call instruction) is provided to perform compression and / or decompression operations using a general-purpose processor. The instruction is, for example, a hardware instruction defined in an instruction set architecture (ISA). Thus, the complexity of the program associated with compression and / or decompression operations is reduced. In addition, the performance of the operations is improved, and thus the performance of the processor is improved.

[0634] Advantageously, the DEFLATE conversion call instruction is dispatched by a programmer, for example, on a general-purpose processor (e.g., a central processing unit, referred to herein as a processor) rather than a dedicated processor (such as an I / O device, an application-specific device connected via an I / O interface, or other types of dedicated processors). Compared to a software implementation, significantly fewer execution cycles are required to execute the disclosed instruction to perform the same operation. Further, compared to dispatching an operation to an I / O device, executing the disclosed instruction does not require an I / O operation of the operating system and does not trigger the operating system to perform a task switch while waiting for the operation to complete.

[0635] Although various fields and registers are described, one or more aspects of the present invention can use other, additional, or fewer fields or registers, or fields and registers of other sizes, etc. Many variations are possible. For example, implicit registers can be used in place of explicitly specified instruction registers or fields, and / or explicitly specified registers or fields can be used in place of implicit registers or fields. Other variations are also possible.

[0636] See Figure 17, describes an embodiment of using a DEFLATE transform call instruction. In one example, a program executed on a processor (e.g., a general-purpose processor) specifies details of an operation to be performed and the location of a parameter block in a storage device (step 1700). For example, depending on the function to be performed, one or more fields of a parameter block (e.g., parameter blocks 340, 360, or 370) are provided or set. Further, in step 1702, the program specifies the operation to be performed (e.g., query, generate, compress, expand, etc.). Additionally, the program specifies or updates the location and amount of input data in the storage device (step 1704) and the location and size of a result buffer in the storage device (step 1706).

[0637] Thereafter, the program executes a DEFLATE transform call (DFLTCC) instruction, step 1708. In one example, the instruction is dispatched on a general-purpose processor. As an example, the instruction is processed on a general-purpose processor, or at least in part by hardware coupled to the general-purpose processor and accessible without using an I / O interface.

[0638] Based on the termination of the instruction, it is determined whether the condition code generated by the execution is equal to a first defined value (e.g., 0) (query 1710). If the condition code is equal to the first defined value, then the processing of the instruction is complete (step 1712). However, if the condition code is not equal to the first defined value, it is further determined whether the condition code is equal to a second defined value (e.g., 3) (query 1714). If the condition code is equal to the second defined value, which indicates that there is additional data to be processed, the instruction is re-executed (step 1708). However, if the condition code is not equal to the second defined value, another determination is made as to whether the condition code is set to a third defined value (e.g., 1) (query 1716). If the condition code is set to the third defined value, which indicates that the length of the first operand is insufficient, the processing continues at step 1706; otherwise, the length of the second operand is insufficient for the function, and the processing continues at step 1704.

[0639] As described above, the DEFLATE transform call instruction can be executed multiple times to compress or decompress a single data stream. Thus, in one aspect, the DEFLATE transform call instruction includes an attribute of a mechanism that provides a program statement buffer (e.g., a 32K-byte buffer) for accumulating a history of uncompressed data processed during operations of multiple executions of the DEFLATE transform call instruction. The buffer is, for example, a circular history buffer.

[0640] In one aspect, the DEFLATE transform call instruction uses an indicator (e.g., a bit) in an implicit register (e.g., GR0.56) to indicate the use of the circular history buffer. When the circular history buffer is indicated and the specified function to be performed by the DEFLATE transform call instruction is to compress or decompress data, the instruction field (e.g., R3) specifies the location in memory of a buffer, such as 32K bytes, which the processor uses to extract history from at the start of the operation and store history into at the end of the operation. The length of the history within the circular history buffer is specified by a field (e.g., the HL field 385) of the parameter block associated with the DEFLATE transform call instruction, and the start of the history within the buffer is specified by an offset in another field (e.g., the HO field 386) contained in the parameter block.

[0641] See Figure 18 for further details on the use of the circular history buffer. In one example, a program executing on a processor (e.g., a general-purpose processor) specifies the details of the operation to be performed and the location of the parameter block in a storage device (step 1800). For example, one or more fields of the parameter block (e.g., parameter block 360 or 370) are provided or set according to the function to be performed. Further, the program specifies the operation to be performed (e.g., compress, expand, etc.).

[0642] Further, in one example, the program allocates and specifies the location in memory of a circular buffer of a predefined size (e.g., 32K bytes) (step 1802). Additionally, the program places a portion of the uncompressed data stream into the buffer and specifies the location and size of the buffer as input to the DEFLATE transform call instruction (step 1804), and specifies or updates the location and size of the result buffer in the storage device (step 1806).

[0643] The DEFLATE transform call instruction is then executed (step 1808). Based on the execution of the instruction, the processor extracts history from the circular history buffer (e.g.) as input to the operation (step 1820) and performs the specified operation as described herein (step 1822). Further, the processor modifies the history in the circular history buffer as output of the operation (step 1824). A determination is made as to whether the entire data stream has been processed, query 1826. If not, the process continues at step 1804. Otherwise, the process is complete.

[0644] As an example, the use of the circular history buffer provides the following:

[0645] When the size of the input or output buffer designated for a single execution of a DEFLATE transform call instruction is small (e.g., 512 bytes), multiple segments of up to, for example, 32K bytes of cross-buffer data can be used as the input to the DEFLATE transform call instruction, which processes a small number of bytes.

[0646] When the input or output buffer designated for a single execution of a DEFLATE transform call instruction is large (e.g., 128K bytes), up to, for example, 32K bytes of the history of the previous segments of the buffered data can be used as the input to the DEFLATE transform call instruction for the first 32K bytes of the data being processed.

[0647] In both cases, more history is available for processing the data compared to other means. As a result, the effectiveness of detecting duplicate strings is improved, leading to an improved overall compression ratio. This is beneficial for processing within a computing environment and improves performance.

[0648] One or more aspects of the present invention are inextricably linked to computer technology and facilitate processing within a computer, thereby improving its performance. Using a single architected machine instruction to perform compression and / or decompression improves performance within a computing environment. Compressing / decompressing data can be used in many technical fields for managing and / or using data, such as computer processing, medical processing, security, inventory control, etc. By providing optimizations in compression / decompression, these technical fields are improved by reducing execution time.

[0649] See Figures 19A - 19B for further details describing an embodiment that facilitates processing within a computing environment related to one or more aspects of the present invention.

[0650] See Figure 19A , in one embodiment, a general-purpose processor of a computing environment obtains an instruction (1900) to execute one of a plurality of functions supported by the instruction. The instruction is, for example, a single architected instruction (1902) of an instruction set architecture conforming to a compression industry standard. The instruction is executed (1904), and the execution includes transforming the state of the input data between an uncompressed form of the input data and a compressed form of the input data based on whether the function is a compression function or a decompression function to provide a transformed data state (1906). The transformed data state to be used when performing a task is provided as an output (1908).

[0651] In one embodiment, transforming the state of the input data uses a compression format conforming to an industry standard (1910). The compression format includes, for example, the DEFLATE compression format (1912).

[0652] As an example, the tasks are selected from a group of tasks consisting of: performing one or more operations using the output, where the output includes compressed data; sending the output; performing one or more operations using the output, where the output includes uncompressed data (1914).

[0653] In one embodiment, referring to Figure 19B , the instruction includes an opcode field and a plurality of register fields. The opcode field includes an opcode specifying an operation, and the plurality of register fields specify a plurality of registers to be used by the instruction (1920). The plurality of registers include, for example, a register for identifying an output operand location to be used as an output by the instruction and another register for identifying an input operand location to be used as an input by the instruction, where the input depends on the function (1922).

[0654] As an example, based on the function being a compression function, the input includes data from the input operand location that is to be encoded to provide compressed data symbols to be stored at the output operand location, and, based on the function being a decompression function, the input includes compressed data symbols from the input operand location that are to be decoded to provide uncompressed data to be stored at the output operand location (1926).

[0655] Further, in one embodiment, the instruction uses one selected register to indicate one of a plurality of functions to be performed by the instruction (1928). The plurality of functions include, for example, a query function, a compression function, a generate dynamic-Huffman table function, and a decompression function (1930). Still further, in one embodiment, the instruction uses another selected register to provide the address of a parameter block used by the instruction for one or more of the plurality of functions (1932).

[0656] In a further aspect, the function to be performed is the generate dynamic-Huffman table function, and the performing includes: based on the function being the generate dynamic-Huffman table function, generating a compressed representation of the dynamic-Huffman table to be used when the function to be performed in another execution of the instruction is the compression function or the decompression function (1934).

[0657] Other variations and embodiments are possible.

[0658] Aspects of the present invention can be used by many types of computing environments. Refer to Figure 20A the description of a computing environment that includes and uses one or more aspects of the present invention. In this example, the computing environment 10 includes (for example) a local central processing unit (CPU) 12, a memory 14, and one or more input / output devices and / or interfaces 16 that are coupled to each other via (for example) one or more buses 18 and / or other connections. As an example, the computing environment 10 can include one provided by International Business Machines Corporation of Armonk, New York, USA Processors; HP Superdome with Intel Itanium II processors, provided by Hewlett-Packard Company, Palo Alto, California, USA; and / or other machines based on architectures provided by International Business Machines Corporation, Hewlett-Packard, Intel Corporation, Oracle, or other companies. IBM, z / Architecture, IBM Z, z / OS, PR / SM, and PowerPC are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

[0659] The local central processing unit 12 includes one or more local registers 20, 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 representing the state of the environment at any given point in time.

[0660] In addition, the local central processing unit 12 executes instructions and code stored in the memory 14. In one particular example, the central processing unit executes emulator code 22 stored in the memory 14. This code enables a computing environment configured in one architecture to emulate another architecture. For example, the emulator code 22 allows a machine based on an architecture other than the z / Architecture hardware architecture (such as a PowerPC processor, an HP Superdome server, or others) to emulate the z / Architecture hardware architecture and execute software and instructions developed based on the z / Architecture hardware architecture.

[0661] Reference Figure 20B , describes further details regarding the emulator code 22. The guest instructions 30 stored in the memory 14 include software instructions (e.g., related to machine instructions) developed for execution in an architecture different from the architecture of the local CPU 12. For example, the guest instructions 30 may have been designed to execute on a processor based on the z / Architecture hardware architecture but are instead emulated on the local CPU 12, which may be, for example, an Intel Itanium II processor. In one example, the emulator code 22 includes an instruction fetch routine 32 to obtain one or more guest instructions 30 from the memory 14 and optionally provide local buffering for the obtained instructions. It also includes an instruction translation routine 34 to determine the type of the obtained guest instructions and translate the guest instructions into one or more corresponding native instructions 36. This translation includes, for example, identifying the function to be performed by the guest instructions and selecting native instructions to perform the function.

[0662] Further, the emulator code 22 includes an emulation control routine 40 to cause native instructions to be executed. The emulation control routine 40 may cause the local CPU 12 to execute a routine of native instructions that simulate one or more previously obtained guest instructions, and at the end of this execution, return control to the instruction fetch routine to simulate the obtaining of the next guest instruction or set of guest instructions. The execution of the native instructions 36 may include loading data from the memory 14 into a register as determined by the translation routine; storing data from the register back into the memory; or performing some type of arithmetic or logical operation.

[0663] Each routine is implemented in software, for example, the software is stored in the memory and executed by the local central processing unit 12. In other examples, one or more of the routines or operations are implemented in firmware, hardware, software, or some combination thereof. The registers of the emulation processor may use the registers 20 of the local CPU or be simulated by using locations in the memory 14. In an embodiment, the guest instructions 30, the native instructions 36, and the emulator code 22 may reside in the same memory or may be distributed among different memory devices.

[0664] The computing environments described above are only examples of computing environments that can be used. Other environments can be used, including but not limited to other non-partitioned environments, other partitioned environments, and / or other emulation environments; the embodiments are not limited to any one environment.

[0665] Each computing environment can be configured to include one or more aspects of the present invention. For example, according to one or more aspects of the present invention, each can be configured to provide sorting and / or merging.

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

[0667] It should be understood that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings recited herein is not limited to a cloud computing environment. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0668] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services), which can be rapidly configured and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0669] The characteristics are as follows:

[0670] On-demand self-service: Cloud consumers can automatically and unilaterally provision computing capabilities, such as server time and network storage, as needed, without human interaction with the service provider.

[0671] Broad network access: Capabilities are provided over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0672] Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned as needed. There is a sense of location independence in that consumers generally have no control or knowledge of the exact location of the provided resources, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0673] Rapid elasticity: Capabilities can be configured quickly and elastically, automatically scaling out rapidly in some cases and rapidly releasing to scale in quickly. To the consumer, the capabilities available for configuration generally appear to be unlimited and can be purchased in any quantity at any time.

[0674] Measured service: The cloud system automatically controls and optimizes resource use by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized services.

[0675] The service models are as follows:

[0676] Software as a Service (SaaS): The capabilities provided to the consumer are to use the provider's applications running on a cloud infrastructure. These applications can be accessed from different client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0677] Platform as a Service (PaaS): The capabilities provided to the consumer are to deploy consumer-created or acquired applications on a cloud infrastructure, where the applications are created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but has control over the deployed applications and possibly the application hosting environment configuration.

[0678] Infrastructure as a Service (IaaS): The function provided to consumers is to offer the processing, storage, networking, and other basic computing resources that enable consumers to deploy and run any software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure but have control over the operating systems, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0679] The deployment models are as follows:

[0680] Private cloud: The cloud infrastructure is operated only for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0681] Community cloud: The cloud infrastructure is shared by multiple organizations and supports a specific community with common concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0682] Public cloud: The cloud infrastructure is available to the public or large industry groups and is owned by the organization selling the cloud services.

[0683] Hybrid cloud: The cloud infrastructure is composed of two or more clouds (private, community, or public), which remain unique entities but are bound together through standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0684] The cloud computing environment is service-oriented, emphasizing statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that includes a network of interconnected nodes.

[0685] Now refer to Figure 21 , which depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 52, and local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or cellular phone 54A, desktop computer 54B, laptop computer 54C, and / or in-vehicle computer system 54N, can communicate with the cloud computing nodes 52. The nodes 52 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as in the private cloud, community cloud, public cloud, or hybrid cloud or a combination thereof as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, and cloud consumers do not need to maintain resources on their local computing devices. It should be understood that Figure 21The types of computing devices 54A-N shown are only illustrative, and the computing nodes 52 and the cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network addressable connection (e.g., using a web browser).

[0686] Now referring to Figure 22 , a set of functional abstraction layers provided by the cloud computing environment 50 ( Figure 21 ) is shown. It should be understood in advance that Figure 22 the components, layers, and functions shown are only illustrative, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0687] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a host 61; a server 62 based on a RISC (Reduced Instruction Set Computer) architecture; a server 63; a blade server 64; a storage 65; and network and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0688] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: a virtual server 71; a virtual storage 72; a virtual network 73, including a virtual private network; virtual applications and operating systems 74; and virtual clients 75.

[0689] In one example, the management layer 80 can provide the functions described below. Resource provisioning 81 provides for the dynamic acquisition of computing resources and other resources for performing tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources can include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. The user portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management such that the required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides for the pre-arrangement and procurement of cloud computing resources for future requirements of cloud computing resources as expected according to the SLA.

[0690] The workload layer 90 provides examples of functions that can utilize the cloud computing environment. Examples of workloads and functions that can be provided from this layer include: maps and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and compression / decompression processing 96.

[0691] Aspects of the present invention may be systems, methods, and / or computer program products at any possible level of integration of technical details. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

[0692] 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 is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0693] The computer-readable program instructions described herein may 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 may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0694] The computer-readable program instructions for performing the operations of the present technical solution may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, 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++, etc., and procedural programming languages such as the "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, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., through the Internet using an Internet service provider). 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 execute the computer-readable program instructions by using the state information of the computer-readable program instructions to personalize the electronic circuit so as to perform aspects of the present technical solution.

[0695] Aspects of the present technical solution will now be described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the technical solution. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0696] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, which is executed by the processor of the computer or other programmable data processing device to create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing device, and / or other devices that act in a specific manner, such that the computer-readable storage medium having the instructions stored therein includes an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0697] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices that enable a series of operational steps to be performed on a computer, other programmable apparatus, or other devices to produce a computer-implemented process such that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions and actions specified in one or more blocks of the flowchart and / or block diagram.

[0698] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present technical solution. To this end, each block in the flowchart or block diagram may represent a module, segment, or portion of an instruction, which includes one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, depending on the functionality involved, two consecutive blocks shown may actually be executed substantially simultaneously, or these blocks may sometimes be executed in the reverse order. It will also be noted that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware that performs the specified functions or actions or performs a combination of dedicated hardware and computer instructions.

[0699] In addition to the above, one or more aspects may be provided, promised, deployed, managed, served, etc. by a service provider that provides customer environment management. For example, the service provider may create, maintain, support computer code and / or computer infrastructure that executes one or more aspects for one or more customers. In return, the service provider may receive payment from consumers, 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.

[0700] In one aspect, an application for executing one or more embodiments may be deployed. As an example, the deployment of the application includes providing a computer infrastructure operable to execute one or more embodiments.

[0701] As another aspect, a computing infrastructure may be deployed, including integrating computer-readable code into a computing system, wherein the code combined with the computing system is capable of executing one or more embodiments.

[0702] As yet another aspect, a process for integrating a computing infrastructure may be provided, the process including integrating computer-readable code into a computer system. The computer system includes a computer-readable medium, wherein the computer medium includes one or more embodiments. The code combined with the computer system is capable of executing one or more embodiments.

[0703] Although the various embodiments are described above, these are only examples. For example, computing environments of other architectures may be used to incorporate and use one or more embodiments. Further, different instructions or operations may be used. Additionally, different registers and / or other types of indications (in addition to register numbers) may be specified. Many variations are possible.

[0704] Further, other types of computing environments may benefit and may 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 directly or indirectly coupled to a memory element via a system bus. The memory element includes, for example, local memory employed during actual execution of the program code, mass storage devices, and a cache memory that provides at least some temporary storage of the program code to reduce the number of times code must be retrieved from the mass storage device during execution.

[0705] 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.) may be coupled to the system directly or via an intermediate I / O controller. A network adapter may also be coupled to the system so that the data processing system can become coupled to other data processing systems or remote printers or storage devices via an intervening private or public network. Modems, cable modems, and Ethernet cards are only a few of the available types of network adapters.

[0706] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that when the terms "comprises" and / or "comprising" are used in this specification, they specify the presence of the 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.

[0707] All apparatus or steps in the following claims, plus the corresponding structures, materials, acts, and equivalents of the functional elements (if any), are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments were chosen and described in order to best explain the various aspects and practical applications, such that those of ordinary skill in the art can understand the various embodiments with different modifications suitable for the particular purposes contemplated.

Claims

1. A computer program product for facilitating processing in a computing environment, the computer program product comprising: Instructions readable by a processing circuit and for performing a method, the method comprising: Obtaining, by a general-purpose processor of the computing environment, instructions to perform one of a plurality of functions supported by the instructions, the instructions being a single architected instruction of an instruction set architecture compliant with a compression industry standard, the plurality of functions including at least a compression function and a decompression function, the function to be performed being specified by a function code of the instruction, and the instruction including an opcode field and a plurality of register fields, the opcode field including an opcode for specifying an operation, the plurality of register fields for specifying a plurality of registers to be used by the instruction, the specification of the opcode being separate from the specification of the function to be performed; and Executing the instruction, the execution comprising: Based on whether the function is a compression function or a decompression function, transforming a state of input data between an uncompressed form of the input data and a compressed form of the input data to provide a transformed data state; and Providing the transformed data state as an output for performing a task.

2. The computer program product according to claim 1, wherein, The transforming the state of the input data uses a compression format compliant with the industry standard.

3. The computer program product according to claim 2, wherein, The compression format includes the DEFLATE compression format.

4. The computer program product according to claim 1, wherein, The task is selected from a group of tasks consisting of: performing one or more operations using the output, the output including compressed data; transmitting the output; performing one or more operations using the output, the output including uncompressed data.

5. The computer program product according to claim 1, wherein, The plurality of registers includes a register for identifying an output operand location to be used as an output by the instruction and another register for identifying an input operand location to be used as an input by the instruction, the input depending on the function to be performed.

6. The computer program product according to claim 5, wherein, Based on the function being the compression function, the input includes data to be encoded from the input operand location to provide a compressed data symbol to be stored at the output operand location, and wherein, based on the function being the decompression function, the input includes a compressed data symbol to be decoded from the input operand location to provide uncompressed data to be stored at the output operand location.

7. The computer program product according to claim 1, wherein, The instruction also uses a selected register to indicate the function among the plurality of functions to be performed by the instruction.

8. The computer program product according to claim 7, wherein, The instruction further uses another selected register to provide an address of a parameter block used by the instruction for one or more of the plurality of functions.

9. The computer program product according to claim 1, wherein, The plurality of functions further includes a query function and a generate dynamic-Huffman table function.

10. The computer program product according to claim 9, wherein, The function to be performed is the generate dynamic-Huffman table function, and wherein, the execution includes: based on the function being the generate dynamic-Huffman table function, generating a compressed representation of a dynamic-Huffman table to be used when the function to be performed is the compression function or the decompression function during another execution of the instruction.

11. A computer system for facilitating processing in a computing environment, the computer system comprising: A memory; And A general-purpose processor coupled to the memory, wherein the computer system is configured to perform a method, the method comprising: Obtain an instruction by the general - purpose processor to execute one of a plurality of functions supported by the instruction, the instruction being a single architected instruction of an instruction - set architecture conforming to a compressed industry standard, the plurality of functions including at least a compression function and a decompression function, the function to be executed being specified by a function code of the instruction, and the instruction including an opcode field and a plurality of register fields, the opcode field including an opcode for specifying an operation, the plurality of register fields for specifying a plurality of registers to be used by the instruction, and the specification of the opcode being separate from the specification of the function to be executed; and Execute the instruction, the execution including: Based on whether the function is a compression function or a decompression function, transform the state of the input data between the uncompressed form of the input data and the compressed form of the input data to provide a transformed data state; and Provide the transformed data state as an output for task execution.

12. The computer system according to claim 11, wherein, The transformation of the state of the input data uses a compression format conforming to the industry standard.

13. The computer system according to claim 11, wherein, The plurality of registers include a register for identifying an output operand location to be used as an output by the instruction and another register for identifying an input operand location to be used as an input by the instruction, the input depending on the function to be executed.

14. The computer system according to claim 13, wherein, Based on the function being the compression function, the input includes data to be encoded from the input operand location to provide a compressed data symbol stored to the output operand location, and wherein, based on the function being the decompression function, the input includes a compressed data symbol to be decoded from the input operand location to provide uncompressed data stored to the output operand location.

15. The computer system according to claim 11, wherein, The plurality of functions further include a query function and a generate - dynamic - Huffman - table function, the function to be executed being the generate - dynamic - Huffman - table function, and wherein, the execution includes: based on the function being the generate - dynamic - Huffman - table function, generate a compressed representation of a dynamic - Huffman table to be used when the function to be executed is the compression function or the decompression function during another execution of the instruction.

16. A computer-implemented method for facilitating processing in a computing environment, the computer-implemented method comprising: Obtain an instruction by the general - purpose processor of the computing environment to execute one of a plurality of functions supported by the instruction, the instruction being a single architected instruction of an instruction - set architecture conforming to a compressed industry standard, the plurality of functions including at least a compression function and a decompression function, the function to be executed being specified by a function code of the instruction, and the instruction including an opcode field and a plurality of register fields, the opcode field including an opcode for specifying an operation, the plurality of register fields for specifying a plurality of registers to be used by the instruction, and the specification of the opcode being separate from the specification of the function to be executed; and Execute the instruction, the execution including: Based on whether the function is a compression function or a decompression function, transform the state of the input data between the uncompressed form of the input data and the compressed form of the input data to provide a transformed data state; and Provide the transformed data state as an output for task execution.

17. The computer-implemented method according to claim 16, wherein, The state of the input data being transformed uses a compression format compliant with the industry standard.

18. The computer-implemented method according to claim 16, wherein, The plurality of registers includes a register for identifying an output operand location to be used as an output by the instruction and another register for identifying an input operand location to be used as an input by the instruction, the input depending on the function to be performed, wherein, based on the function being the compression function, the input includes data to be encoded from the input operand location to provide a compressed data symbol to be stored at the output operand location, and wherein, based on the function being the decompression function, the input includes a compressed data symbol to be decoded from the input operand location to provide uncompressed data to be stored at the output operand location.

19. The computer-implemented method according to claim 16, wherein, The plurality of functions further includes a query function and a generate dynamic-Huffman table function, the function to be performed being the generate dynamic-Huffman table function, and wherein, the execution includes: based on the function being the generate dynamic-Huffman table function, generating a compressed representation of a dynamic-Huffman table to be used when the function to be performed is the compression function or the decompression function during another execution of the instruction.

Images