Compress / decompress instructions specifying the history buffer to be used in data compression / decompression.

Abstract

Obtain instructions to perform one of a plurality of functions. These instructions are single, structured instructions conforming to an industry-standard instruction set architecture for compression. Execute the instructions, including performing the function specified by the instructions. The executed function includes: based on whether the function is a compression or decompression function, transforming the state of input data between its uncompressed and compressed forms to provide a transformed data state. During the execution of the function, access the history of the function. This history is to be used to transform the state of the input data between uncompressed and compressed forms.

Description

Technical Field

[0001] One or more aspects in general relate to facilitating processing within a computing environment, specifically to facilitating compression and decompression operations. Background Technology

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

[0003] In such an environment, the operating system (OS) provides mechanisms for performing compression and decompression operations. In one example, to provide these operations, the OS includes a zlib open-source software library that conforms to the DEFLATE standard compression technology as defined in the IETF (Internet Engineering Task Force) RFC (Request for Comments) 1951 specification. This mechanism can include a software implementation where a user executes numerous instructions on a general-purpose processor to perform compression or decompression, or it can be implemented using dedicated hardware connected to the system's input / output (I / O) ports, where the I / O devices perform the operations. Summary of the Invention

[0004] This invention overcomes the shortcomings of the prior art and provides additional advantages by providing a computer program product for facilitating processing in a computing environment. The computer program product includes a computer-readable storage medium that can be read by processing circuitry and stores instructions for performing a method. The method includes obtaining instructions from a processor of the computing environment to perform one of a plurality of functions supported by the instructions. The instructions are single, structured machine instructions conforming to an instruction set architecture of a compression industry standard. Execution of the instructions includes performing the function specified by the instructions. The execution of the function includes: transforming the state of input data between an uncompressed form and a compressed form of the input data, based on whether the function is a compression or decompression function, to provide a transformed data state. During the execution of the function, a history of the function is accessed. This history is to be used to transform the state of the input data between the uncompressed and compressed forms. The transformed data state is provided as output for performing the task.

[0005] By using history to process data when performing functions such as compression or decompression, the effectiveness of performing these functions—including, for example, detecting duplicate strings as part of the function's execution—is improved, thereby increasing the overall compression ratio.

[0006] In one example, the processor is a general-purpose processor. Furthermore, in another example, the state of the input data is transformed using an industry-standard compression format.

[0007] By using a single, structured instruction dispatched on a general-purpose processor to perform compression and / or decompression functions (also known as operations), a significant subset of the primitive software instructions used to perform those functions is replaced by a single, structured instruction. Replacing those primitive instructions with a single structured instruction reduces program complexity and eliminates the need for code to optimize those primitive instructions, thus improving overall performance. Furthermore, by not dispatching these operations to input / output devices, the operating system avoids task switching while waiting for I / O devices to perform operations.

[0008] The instruction includes an opcode field and multiple register fields. The opcode field contains an operation code specifying the operation, and the multiple register fields specify multiple registers that will be used by the instruction. These registers may include, for example, a register identifying the location of output operands to be used as output by the instruction and another register identifying the location of input operands to be used as input by the instruction.

[0009] In one example, the instruction uses one selected register to specify the location of the buffer in memory and another selected register to provide the address of the parameter block the instruction will use. The parameter block specifies an offset within the buffer that indicates the start of the history within the buffer. Furthermore, in one example, the parameter block includes the length of the history within the buffer, and the instruction uses selected registers to specify the type of buffer. The type of buffer is, for example, a circular buffer.

[0010] By using a separate buffer for history (e.g., a circular buffer), more history can be input to an operation than is available when only inline history is used (e.g.).

[0011] In one embodiment, the input depends on the function to be performed, wherein, based on the function being a compression function, the input includes compressed data symbols to be encoded in the input operand locations to provide data stored in the output operand locations, and data to be copied from the input operand locations and stored in a buffer as history, and wherein, based on the function being a decompression function, the input includes compressed data symbols to be decoded from the input operand locations to provide uncompressed data stored in the output operand locations and the buffer.

[0012] This document also describes and claims protection for computer-implemented methods and systems related to one or more aspects. Furthermore, this document also describes and claims protection for services related to one or more aspects.

[0013] Additional features and advantages are achieved through the techniques described herein. Other embodiments and aspects, which are considered part of the claimed aspects, are described in detail herein. Attached Figure Description

[0014] The claims at the end of the specification specifically point out and clearly claim protection for one or more aspects of the exemplary form. The objects, features, and advantages of the above and one or more aspects will be apparent from the following detailed description taken in conjunction with the accompanying drawings, wherein:

[0015] Figure 1A An example of a computing environment that includes and uses one or more aspects of the present invention is shown;

[0016] Figure 1B One or more aspects of the invention are shown. Figure 1A Further details about the processor;

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

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

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

[0020] Figure 3C An example of functional code for the DEFLATE conversion call instruction according to one aspect of the present invention is shown;

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

[0022] Figure 3E An example of the contents of register R1 specified by the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0023] Figure 3FAn example of the contents of register R1+1 used by the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0024] Figure 3G An example of the contents of register R2 specified by the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0025] Figure 3H An example of the contents of register R2+1 used by the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0026] Figure 3I An example of the contents of register R3 specified by the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0027] Figure 3J An example of the contents of a parameter block used by the DFLTCC-QAF (Query Available Functions) function of the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0028] Figure 3K An example of the contents of a parameter block used by the DFLTCC-GDHT (Generate Dynamic-Huffman Table) function of the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0029] Figure 3L An example of the contents of a parameter block used by the DFLTCC-CMPR (compressed) and DFLTCC-XPND (extended) functions of the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0030] Figure 4 An example of a subbyte boundary according to one or more aspects of the present invention is shown;

[0031] Figures 5A-5C An example illustrating how subbyte boundaries apply to the DFTLCC-CMPR function according to an aspect of the present invention is shown;

[0032] Figure 6 An example of an uncompressed data block according to one aspect of the invention is shown;

[0033] Figure 7 An example of a block of compressed data using a fixed-Huffman table (FHT) is shown according to one aspect of the invention;

[0034] Figure 8An example of a block of compressed data using a Dynamic-Huffman Table (DHT) is shown according to one aspect of the invention;

[0035] Figure 9 An example of a compressed dataset in a memory according to one aspect of the invention is shown;

[0036] Figure 10 An example of a sample program for compressing data into three blocks of a compressed dataset according to one aspect of the present invention is shown;

[0037] Figure 11 An example of the parameter block content of the DFLTCC-CMPR function acting on a first compressed data block of a dataset according to one aspect of the invention is shown;

[0038] Figure 12 An example of the parameter block content of the DFLTCC-CMPR function acting on a second compressed data block of a dataset according to one aspect of the present invention is shown;

[0039] Figure 13 An example of a program sample for decompressing data in a dataset according to one aspect of the present invention is shown;

[0040] Figures 14A-14C An example of an inline history buffer before and after multiple executions of DFLTCC-CMPR according to one aspect of the invention is shown;

[0041] Figures 15A-15E An example of a circular history buffer before and after multiple executions of DFLTCC is shown according to one aspect of the invention;

[0042] Figures 16A-16C An example of an inline history buffer before and after multiple executions of DFLTCC-XPND according to one aspect of the invention is shown;

[0043] Figure 17 An example of using the DEFLATE conversion call instruction according to one aspect of the invention is shown;

[0044] Figure 18 An example of the use of a circular history buffer according to one aspect of the invention is shown;

[0045] Figures 19A-19B An example illustrating a process facilitated within a computing environment according to one aspect of the invention is shown;

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

[0047] Figure 20B It shows Figure 20A Further details about the memory;

[0048] Figure 21 An example of a cloud computing environment is shown; and

[0049] Figure 22 An example of an abstract model layer is shown. Detailed Implementation

[0050] According to one aspect of the invention, a capability to facilitate processing in a computing environment is provided. As an example, a single instruction (e.g., a single architectural hardware machine instruction at a hardware / software interface) is provided to perform functions (also referred to as operations) such as compression or decompression to compress and / or decompress (also referred to as decompress) data. The instruction is part of a general-purpose processor instruction set architecture (ISA) dispatched by a program (e.g., an operating system or user program) on a general-purpose processor. By using ISA instructions for compression / decompression, the operating system does not need to perform task switching to perform compression / decompression operations, thereby saving execution cycles. Furthermore, by using a single instruction to compress and / or decompress data, execution time within the processor (such as a general-purpose processor) is reduced.

[0051] In one example, the instruction performs compression and decompression operations conforming to an industry standard (known as the DEFLATE standard), and this instruction is called a DEFLATE Conversion Call instruction. The DEFLATE standard includes descriptions of compressed data symbols representing duplicate strings in the raw form of the data (the uncompressed form). These symbols include pointers and lengths of the duplicate strings, describing the position and length of previously processed duplicate strings relative to the current position of the data being processed. The previously processed uncompressed data is called the history. In one example, the history is a contiguous set of bytes in memory, which can be as large as, for example, 32KB.

[0052] In one aspect, history is placed in a separate buffer (e.g., a circular buffer) used by instructions (e.g., as a supplement to or replacement of inline history as part of an uncompressed / raw data stream). A circular history buffer provides the ability to present more history as input to operations than using only inline history.

[0053] refer to Figure 1AThe description includes an embodiment of a computing environment that incorporates and uses one or more aspects of the present invention. The computing environment 100 includes, for example, a processor 102 (e.g., a central processing unit), memory 104 (e.g., main memory; also referred to as system memory, main storage device, central storage device, storage device), 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.

[0054] In one example, processor 102 is based on z / Architecture provided by International Business Machines Corporation of Armonk, New York, USA. ® Hardware architecture, and is part of the server, such as IBM Z. ® Part of the server, which was also provided and implemented by International Business Machines (IBM) using the z / Architecture hardware architecture. An embodiment of the z / Architecture hardware architecture is described in the publication titled "z / Architecture Principles of Operation" (IBM Publication No. SA22-7832-11, 12). th The invention is described in the edition of (September 2017), which is hereby incorporated herein by reference in its entirety. However, the z / Architecture hardware architecture is merely an exemplary architecture; other architectures and / or other types of computing environments may include and / or use one or more aspects of this invention. In one example, the processor executes an operating system, such as z / OS, also provided by International Business Machines Corporation. ® operating system.

[0055] Processor 102 includes multiple functional components for executing instructions. For example... Figure 1BAs shown, these functional components include, for example, an instruction extraction component 120 for extracting instructions to be executed; an instruction decoding unit 122 for decoding the extracted instructions to obtain operands of the decoded instructions; an instruction execution component 124 for executing the decoded instructions; a memory access component 126 for accessing memory used 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 invention, one or more of these components may include at least a portion of one or more other components as described herein for compression / decompression processing (or other processing that may utilize one or more of the further aspects of the invention), or have access to one or more other components as described herein for compression / decompression processing (or other processing that may utilize one or more of the further aspects of the invention). The one or more other components include, for example, a compression / decompression component (or other component) 136.

[0056] refer to Figure 2 Another example of a computing environment that incorporates and uses one or more aspects of the present invention is described. In one example, the computing environment is based on the z / Architecture hardware architecture; however, the computing environment may be based on other architectures provided by IBM or other companies.

[0057] Reference Figure 2 In one example, the computing environment includes a central electronic complex (CEC) 200. The CEC 200 includes multiple components, such as memory 202 (also known as system memory, main memory, central storage device, or storage device) coupled to one or more processors (also known as central processing units (CPUs)) 204 and input / output subsystems 206.

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

[0059] Each logical partition 208 can function as a separate system. That is, each logical partition can be reset independently, running a guest operating system 220 such as z / OS or another operating system, and operated by different programs 222. The operating system or application running in the logical partition appears to have access to the entire system, but in reality, only a portion of the system is available.

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

[0061] Furthermore, 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 coupled to the central electronic complex, as well as input / output (I / O) devices 240.

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

[0063] As an example, each processor 204 includes at least one cache 260 (e.g., a 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 for performing one or more of the compression and / or decompression of data (and / or other operations of one or more aspects of the invention). In different instances, there may be one or more components performing these tasks. Many variations are possible.

[0064] In one embodiment, a processor (e.g., processor 204) receives an instruction (e.g., a DEFLATE translation call instruction), interprets the instruction, performs the setup of the instruction, including translating the address to be used by the instruction, and then sends the instructions to a component coupled to the processor, such as component 262, to perform the function specified by the instruction. Component 262 may access cache levels and memory such that, while performing the specified function, component 262 reads data, processes data, and stores the processed data back. As an example, component 262 is a hardware component.

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

[0066] Central electronic complex 200 may include and / or be coupled to removable / non-removable, volatile / non-volatile computer system storage media. For example, central electronic complex 200 may include and / or be coupled to non-removable non-volatile magnetic media (commonly referred to as a "hard disk drive"); 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 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 archiving storage systems.

[0067] Furthermore, the Central Electronic Complex 200 can operate with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of known computing systems, environments, and / or configurations that may be suitable for the Central Electronic Complex 200 include, but are not limited to: personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the aforementioned systems or devices, etc.

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

[0069] According to one aspect of the 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 the facility indicator is set to, for example, 1. As a specific instance of the z / Architecture hardware architecture, when the conversion facility is installed in 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.

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

[0071] In one example, uncompressed data is a sequence of bytes, and the compressed representation of the data includes symbols. A symbol represents a single byte of uncompressed data—called a literal byte—or a sequence of repeating bytes in 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: Fixed-Huffman Tables (FHT), which are predefined specifications that include, for example, all possible encodings; and Dynamic-Huffman Tables (DHT), which are sets of encodings specifically created for the data to be compressed, and this set can be a subset of all possible encodings. The compressed representation of data generated using a DHT is typically smaller than the compressed representation of the same data generated using an FHT. A portion of recently processed uncompressed data (called history) is maintained for encoding and decoding the compressed data symbols representing duplicate strings. History is a reference source for duplicate strings. During operation, history is updated as data is processed.

[0072] As described above, in one example, the DEFLATE conversion call instruction uses the DEFLATE compressed data format described in "RCF 1951, DEFLATECompressed Data Format Specification version 1.3". The properties of the DEFLATE standard applicable to the DEFLATE conversion call instruction include, for example:

[0073] A compressed dataset consists of a series of blocks. There are three types of blocks. One type includes a 3-bit header, followed by length information and uncompressed data; the other two types include a 3-bit header followed by compressed data elements.

[0074] Compressed data elements may include a compressed representation of a dynamic-Huffman table, compressed data symbols, and end-of-block (EOB) symbols.

[0075] Compressed data elements have different bit lengths.

[0076] Compressed data elements can begin or end between byte boundaries in a storage device.

[0077] Compressed data elements are loaded into bytes in, for example, from the rightmost bit position to the leftmost bit position.

[0078] When a compressed data element occupies part but not all of a byte in a storage device, the entire byte in the storage device is accessed. The storage operand lengths specify the number of addressable bytes, which can be more bits than the compressed data occupies.

[0079] Further details regarding compressed data blocks are described below.

[0080] See Figure 3A-3L This describes one embodiment of the DEFLATE translation call (DFLTCC) instruction. In one example, a general-purpose processor (e.g., processor 102 or 204) is used to execute the instruction. In this description, 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. Furthermore, while 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 the opposite or another value. Many variations are possible.

[0081] In one embodiment, a program (e.g., an operating system or a user program) may execute the DEFLATE transformation 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., larger than 1 MB), the operation may include multiple calls to compress or decompress buffered portions of the data stream. According to one aspect of the invention, a program declares a history buffer (e.g., a 32 KB buffer) for accumulating uncompressed data processed during the multiple executions of the DEFLATE transformation call instruction. This buffer, referred to as a circular history buffer, is defined using the DEFLATE transformation call instruction as described herein.

[0082] See Figure 3AIn one example, the format of the DEFLATE translation call (DFLTCC) instruction 300 is an RRF format representing register operations 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) having an opcode indicating the DEFLATE translation call operation; a first register field (R1) 304 (e.g., bits 24-27) specifying a first pair of general-purpose registers; a second register field (R2) 306 (e.g., bits 28-31) specifying a second pair of general-purpose registers; and a third register field (R3) 308 (e.g., bits 16-19) specifying a third general-purpose register. The contents of the registers specified by the R1 field 304 specify the location of the first operand (in the storage device); the contents of the registers specified by the R2 field 306 specify the location of the second operand (in the storage device); and the contents of the registers specified by the R3 field 308 specify the location of the third operand (in the storage device). The contents of R1+1 specify the length of the first operand, and the contents of R2+1 specify the length of the second operand. In one example, bits 20-23 of the instruction are reserved and should contain zeros; otherwise, future operations of the program may be incompatible. As used herein, the program is the one that issues the DEFLATE conversion call instruction. It can be a user program, an operating system, or another type of program.

[0083] In one embodiment, instruction execution includes the use of 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 translation 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.

[0084] As an example, refer to Figure 3B General-purpose register 0 (309) includes a history buffer type field 310 and a function code field 312. In one particular instance, bit position 56 of general-purpose register 0 contains the history buffer type, and bits 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, a specified exception is identified when bits 57-63 of general-purpose register 0 indicate an unassigned or uninstalled function code.

[0085] Figure 3CThe diagram illustrates exemplary function codes assigned to the DEFLATE conversion invocation instruction, including, for example: 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, the size of which, in one example, depends on the function. For example, the parameter block for the DFLTCC-QAF function is 32 bytes; the parameter block for the DFLTCC-GDHT function is 384 bytes; and the parameter blocks for the DFLTCC-CMPR and DFLTCC-XPND functions are 1536 bytes. No other function codes are assigned in this example. Although exemplary functions and function codes are described, other functions and / or function codes may be used.

[0086] When the specified function is DFLTCC-CMPR or DFLTCC-XPND, bit 56 of general-purpose register 0 specifies the type of history buffer (HBT) used during the operation. When HBT is 0, the history buffer is called an in-line history buffer. When using an in-line history buffer, 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 using a circular history buffer, 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-purpose register 0 is ignored. In one example, bits 0-31 of general-purpose register 0 are ignored. Further, in one example, bits 32-55 of general-purpose register 0 are reserved and should contain zeros; otherwise, future operations of the program may be incompatible.

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

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

[0089] like Figure 3E-3F As shown and further described in detail here, the content of general-purpose register R1 318 indicates the address 320 of the first operand, and the content of general-purpose register R1+1 322 is used to determine the length 324 of the first operand. For example, when the specified function is DFLTCC-CMPR or DFLTCC-XPND, the content of general-purpose register R1 318 specifies the logical address of the leftmost byte of the first operand. When the specified function is DFLTCC-CMPR, the content of general-purpose register R1+1, together with the values ​​of the New Task (NT) and Subbyte Boundary (SBB) fields of the parameter block (described below), specifies the length of the first operand. The examples provided in the following table show functions for which the length of the first operand of the DFLTCC-CMPR function is the content of general-purpose register R1+1, the NT field, and the SBB field:

[0090]

[0091] When the specified function is DFLTCC-XPND, the content of general-purpose register R1+1 specifies 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 specified function is DFLTCC-QAF or DFLTCC-GDHT, the contents of general-purpose registers R1 and R1+1 are ignored.

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

[0093] like Figure 3G-3HAs shown and further described in detail here, the content of general-purpose register R2 326 indicates the address 328 of the second operand, and the content of general-purpose 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-purpose 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-purpose register R2+1 specifies the length of the second operand. When the specified function is DFLTCC-XPND, the content of general-purpose register R2+1, together with the values ​​of the NT field and SBB field of the parameter block, specifies the length of the second operand. At the start of instruction execution, when the length of the second operand is referenced and has a non-zero value, data is fetched from the second operand location. At the start of instruction execution, when the length of the second operand is referenced and has a zero value, and at the start of instruction execution, when the continuation flag (CF) field of the parameter block is 1, the second operand is not accessed.

[0094] When the DFLTCC-QAF function is specified, the contents of general-purpose registers R2 and R2+1 are ignored. When the DFLTCC-GDHT function is specified and the contents of general-purpose register R2+1 are specified to be of zero length, a specification exception is detected, and the second operand is not accessed. When the DFLTCC-CMPR or DFLTCC-XPND function is specified, the continuation flag (CF) field of the parameter block is zero at the start of instruction execution, and the contents of general-purpose register R2+1 are specified to be of zero length, a specification exception is detected, and the second operand is not accessed.

[0095] like Figure 3I As 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-purpose register R3335 specifies the circular history buffer address 337. For example, it specifies the logical address of the leftmost byte of the third operand. A boundary of, for example, 4KB should be specified; otherwise, a specified exception is identified. In one example, the circular history buffer is located at the third operand position. When the specified function is DFLTCC-CMPR or DFLTCC-XPND and HBT is zero, the content of general-purpose register R3 is ignored. When the DFLTCC-QAF or DFLTCC-GDHT function is specified, the content of general-purpose register R3 is ignored. For the specified functions (e.g., DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR, and DFLTCC-XPND), the R3 field should not specify general-purpose register 0 or general-purpose register 1; otherwise, in one example, a specified exception is identified.

[0096] As part of the operation, when the specified function is DFLTCC-CMPR, the address increment in general-purpose register R1 includes the number of bytes processed for the first operand whose bit position is 0, and the length in general-purpose register R1+1 is decreased by the same number; the address increment in general-purpose register R2 includes the number of bytes processed for the second operand, and the length in general-purpose register R2+1 is decreased by the same number. The number of bytes processed for the first operand whose bit position is 0 is, for example, an 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. The formation and updating of the address and length depend on the addressing mode, as described below.

[0097] As part of the operation, when the specified function is DFLTCC-XPND, the address in general-purpose register R1 is incremented by the number of bytes processed for the first operand, and the length in general-purpose register R1+1 is decremented by the same number; the address in general-purpose register R2 is incremented by the number of bytes processed for the second operand, including the bit set to 0, and the length in general-purpose register R2+1 is decremented by the same number. The number of bytes processed for the second operand, including the bit set to 0, is an integer quotient obtained by 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 updating of the address and length depend on the addressing mode, as described below.

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

[0099] The contents of bits 40-63 in general-purpose registers 1, R1, R2, and R3 constitute the addresses of the parameter block, the first operand, the second operand, and the circular history buffer, respectively, while the contents of bits 0-39 are ignored.

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

[0101] The contents of bits 32-63 in general-purpose registers R1+1 and R2+1 form, for example, 32-bit unsigned binary integers that specify the number of bytes in the first and second operands, respectively. The contents of bits 0-31 in general-purpose registers R1+1 and R2+1 are ignored.

[0102] The updated first operand and bits 32-63 of the second operand length replace the corresponding bits in general-purpose registers R1+1 and R2+1, respectively. The contents of bits 0-31 in general-purpose registers R1+1 and R2+1 remain unchanged.

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

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

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

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

[0107] The updated first operand and bits 32-63 of the second operand length replace the corresponding bits in general-purpose registers R1+1 and R2+1, respectively. The contents of bits 0-31 in general-purpose registers R1+1 and R2+1 remain unchanged.

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

[0109] The bits 0-63 of general-purpose 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.

[0110] The bits 0-63 of the updated first and second operand addresses replace the corresponding bits in general-purpose registers R1 and R2, respectively. Carry-over bits at the updated address bits are ignored.

[0111] The contents of bits 0-63 in general-purpose registers R1+1 and R2+1 form 64-bit unsigned binary integers that specify the number of bytes in the first and second operands, respectively.

[0112] The updated first operand and the second operand length bits 0-63 replace the corresponding bits in general-purpose registers R1+1 and R2+1, respectively.

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

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

[0115] Function code 0: DFLTCC-QAF (Query available functions).

[0116] The DFLTCC-QAF (Query Available Features) function provides a mechanism for indicating the availability of installed features and the format of installed parameter blocks. (See reference) Figure 3J This describes an example format for a parameter block that describes a DFLTCC-QAF function. In one example, parameter block 340 for a DFLTCC-QAF function (e.g., function code 0) includes an installed function vector 342 and an installed parameter block format vector 346. In a particular illustration, 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.

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

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

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

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

[0121] Where applicable, identify PER (program event recording) memory change events for parameter blocks. Where applicable, identify PER zero-address detection events for parameter blocks.

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

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

[0124] When the DFLTCC-GDHT function is specified, for example, the second operand is used as the source to generate a compressed representation of a Dynamic-Huffman Table (DHT) as specified by the DEFLATE standard.

[0125] In one example, the DFLTCC-GDHT function uses a parameter block, referencing... Figure 3K The diagram illustrates an example of this parameter block. In the example parameter block described herein, a specific position of a particular field within the parameter block and a specific size of the field (e.g., a specific byte and / or bit) are indicated. However, other positions and / or sizes can be provided for one or more fields. Furthermore, while it is specified that bits are set to specific values, such as 1 or 0, this is merely an example. In other instances, bits can be set to different values, such as the opposite or another value. Many variations are possible.

[0126] In one example, the parameter block contains one or more reserved fields and one or more reserved fields. The DFLTCC-GDHT function does not modify reserved fields. Reserved fields are distinguished from reserved fields so that the 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. Reserved fields must contain zeros; otherwise, future program operations may be incompatible. When the operation is complete, reserved fields can be stored as zeros or remain unchanged.

[0127] Furthermore, some fields are used by other functions (e.g., DFLTCC-CMPR or DFLTCC-XPND), so aspects related to these functions can also be described along with the descriptions of these fields.

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

[0129] 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 PBVN are reserved and should contain zeros; otherwise, future program operations may be incompatible. Bits 12-15 of PBVN contain an unsigned binary integer specifying the format of the parameter block. The DFLTCC-QAF function provides a mechanism to indicate the available parameter block formats. When the specified parameter block format is not supported by the model, a general operand data anomaly is identified. PBVN is specified by the program and is not modified during instruction execution.

[0130] Model Version Number (MVN) 363: Byte 2 of the parameter block is an unsigned binary integer identifying the model for which the instruction is being executed. No program initialization of the MVN is required. The MVN is updated during instruction execution. The values ​​stored in the MVN are model-dependent.

[0131] Dynamic-Huffman Table (DHT) Generation Control (DHTGC) 364: Bit 2 of byte 17 of the parameter block is used to generate the Dynamic-Huffman Table (DHT). The DHT specifies the Huffman code for a symbol representing a literal byte, repeat string length, end-of-block (EOB) symbol, and repeat string pointer distance. The value of the Huffman code for a particular symbol is a function of the count of occurrences of the entity represented by that symbol in its uncompressed data form. When the count of a symbol is zero, there is no Huffman code for that symbol in the DHT. In one example, DHTGC specifies that a count equal to zero will be handled as follows:

[0132]

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

[0134] For all values ​​of DHTGC, the resulting DHT specifies Huffman codes for all possible repeating string lengths and pointer distances, as defined by the DEFLATE standard. Therefore, the compressed form of the resulting DHT, with its HLIT (Huffman literal) and HDIST (Huffman distance) sub-elements each containing, for example, 29 values, is further described below.

[0135] When the DFLTCC-GDHT function is specified, the DHTGC is the input to the operation. When the DFLTCC-CMPR or DFLTCC-XPND function is specified, the DHTGC is not used in the operation. In one embodiment, the DHTGC is not modified during instruction execution.

[0136] Operation End Supplement Code (OESC) 365: Byte 19 of the parameter block is an unsigned binary integer that provides additional information when the condition is reported to the program. Because this field is used by multiple functions, some conditions involve parameter blocks used by other functions (e.g., those used by the DFLTCC-CMPR and DFLTCC-XPND functions). Figure 3L The OESC field of the parameter block. When the reported condition is a general operand data anomaly, the operation is considered suppressed even though the OESC field of the parameter block is updated. In one example, it would be defined as follows in this case:

[0137]

[0138]

[0139]

[0140]

[0141]

[0142] When an operation is completed without reporting any abnormalities in the general operand data, zero is stored in the OESC field.

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

[0144] Compression Dynamic-Huffman Table Length (CDHTL) 366: The 12 bits of the parameter block from bit 4 of byte 56 to bit 7 of byte 57 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 the 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 When CDHTL (HTT 376) is 1, CDHTL is the input to the operation. An anomaly in the general operand data is detected when CDHTL does not specify an appropriate length for CDHT. CDHTL is not modified when the DFLTCC-CMPR function is specified.

[0147] When the DFLTCC-XPND function is specified and the operation ends after decoding only a portion 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 portion 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( Figure 3L When the continuation flag 373 is equal to 1 and IFS (incomplete function state 383) is equal to hexadecimal C or D, as described below, this field is the input for the operation.

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

[0149] The DHT specifies Huffman codes (bit sequences) representing two sets of elements. Elements of one set include literal bytes, EOB symbols, and repeat string lengths. Elements of the other set include repeat string pointer distances. The compressed representation of the DHT defines sets of code lengths and specifies a code length (CL) for each element in each set. The Huffman code of an element expected to be referenced during 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 specifies the number of Huffman codes representing literal bytes, EOB symbols, and repeating string lengths.

[0151] The HDIST field specifies the number of Huffman codes representing the distance between repeating string pointers.

[0152] The HCLEN (Huffman code length) field specifies the number of Huffman codes representing the code length.

[0153] The code sequence, which is specified as the bit length of each of, for example, 19 code lengths as defined by the compressed DHT.

[0154] The code sequence specifies the code length of each element in a set consisting of literal bytes, EOB symbols, and repeating string length.

[0155] A code sequence that specifies the code length of each element in a set consisting of the distances between repeating string pointers.

[0156] The following description of the compressed representation of DHT refers to the description of a 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 derived from the output of the operation.

[0159] When the DFLTCC-CMPR function is specified and 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 portion 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 portion of a block with a BTYPE value of binary 00 or 01, zero is stored in this field. This field is the input to the operation when resuming decompression within a block with a BTYPE value of binary 10 (i.e., when CF equals 1 and IFS equals hexadecimal C or D).

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

[0162] Although 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] The various 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 must contain uncompressed data, and after the operation is complete, the generated result is specified using the DFLTCC-CMPR function, which compresses the same source.

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

[0165] In one example, when the content of general-purpose register R2+1 is specified to be greater than, for example, 32KB, the following applies:

[0166] The DHT is generated using only the first 32KB of the second operand.

[0167] Access exceptions are not identified for locations other than the first 32KB of the second operand.

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

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

[0170] The compressed format of the generated DHT is stored in the Compression 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 identifier in the model version number field 363 of the parameter block.

[0172] When an operation ends without identifying any abnormality in the general operand data, zero is stored in the Operation End Supplement Code (OESC) field 365 of the parameter block.

[0173] When the DFLTCC-GDHT function completes execution, condition code 0 is set; condition codes 1, 2 and 3 are not applicable to the DFLTCC-GDHT function.

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

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

[0176] When applicable, PER zero address detection events are identified for the second operand position and for the parameter block.

[0177] Function code 2: DFLTCC-CMPR (compression).

[0178] When the DFLTCC-CMPR function is specified, a compression operation is performed. The operation involves encoding data from the second operand location into compressed data symbols, which are then stored in the first operand location.

[0179] In one example, the DFLTCC-CMPR function uses a parameter block; an example of a parameter block can be found here. Figure 3L The description has been provided. Some fields have already been described above regarding parameter block 360, therefore, these fields are listed below with the same label numbers and will not be described in detail again.

[0180] In one example, parameter block 370 contains:

[0181] Parameter block version number (PBVN) 362.

[0182] Model version number (MVN) 363.

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

[0184] New Task (NT) 374: When bit 0 of byte 16 of the parameter block is 1, it indicates that the operation applies to the beginning of the compressed dataset. Therefore, no history or checksum from previous operations applies to the current operation. When NT is 1 at the beginning of the operation and the operation ends after partial completion, zero is stored in the NT field. When NT is zero, history and checksum from previous operations apply to the current operation.

[0185] Check Value Type (CVT) 375: Bit 2 of byte 16 of the parameter block specifies the type of 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, a 32-bit Cyclic Redundancy Check (CRC-32). When CVT is 1, the check value type is, for example, a 32-bit Adler checksum (Adler-32). The CVT bit is not modified during instruction execution.

[0186] Huffman Table Type (HTT) 376: When bit 4 of byte 16 of the parameter block is zero, it specifies a table containing Fixed-Huffman Code (FHT) as defined by the DEFLATE standard, used during compression operations. When HTT is 1, a table containing Dynamic-Huffman Code (DHT) as specified in the CDHT field of the parameter block is used during compression operations. HTT is not used for decompression operations. The HTT bit is not modified during instruction execution.

[0187] Block Continuation Flag (BCF) 377: When the DFLTCC-CMPR function is specified, bit 5 of byte 16 of the parameter block applies. When zero, 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 in the first operand location before storing any compressed data elements. When 1, neither the DHT block header nor the compressed format is stored in the first operand location. When NT is 1, BCF is considered equal to 0. The BCF bit is not modified during instruction execution.

[0188] Block Closing Control (BCC) 378: When the DFLTCC-CMPR function is specified, bit 6 of byte 16 of the parameter block applies. When the bit is 1 after storing all compressed data symbols, the End-of-Block (EOB) symbol is stored in the first operand location. When HTT specifies the use of FHT, for example, the Huffman code 00000 binary 00 (which corresponds to the 256-bit intermediate integer representation of the code for the specified literal byte, EOB symbol, and repeat string length in the table) 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 in the first operand location. The BCC bit is not modified during instruction execution.

[0189] 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 BHF is 1, the first bit (BFINAL) of the block header is set to 1 before storing the block header in the first operand location. When BHF is 0, the first bit (BFINAL) of the block header is set to zero before storing the block header in the first operand location. The BHF bit is not modified during instruction execution.

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

[0191] 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 processed and unprocessed bits within a byte of the compressed data stream. The referenced byte of the stream is the last referenced byte (i.e., the rightmost byte) when the operation ends, and the first referenced byte (i.e., the leftmost byte) when the operation begins or resumes. When the DFLTCC-CMPR function is specified, the SBB applies to the byte specified by the first operand address. When the DFLTCC-XPND function is specified, the SBB applies to the byte specified by the second operand address. The SBB specifies the number of rightmost bits processed. The SBB is both the input and output of the operation.

[0192] Figure 4 The image shows an example of a compressed data stream when the SBB has a binary value of 011. At 400, the data that has been processed after the operation ended is shown; at 402, the data that will be processed before the operation begins is shown.

[0193] Furthermore, Figures 5A-5C Examples demonstrating how SBB can be applied to DFLTCC-CMPR functionality are provided. For example, Figure 5A The document shows an example of how SBB applies before and after the DFLTCC-CMPR function is executed. Figures 5B-5C Other examples are shown below. When NT 374 is 1, SBB 381 is considered equal to binary 000.

[0194] return Figure 3L Other fields describing parameter block 370:

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

[0196] Incomplete Function Status (IFS) 383: When some operations are completed, bits 4-7 of byte 21 of the parameter block contain status information. In one example, when the decompression operation is completed, the IFS conveys the following information about the second operand:

[0197]

[0198]

[0199] In one embodiment, the decompression operation may end with IFS equal to binary 0000, failing to complete normally. In such a case, the operation ends with condition code 1 or 3 set.

[0200] When the compression operation is complete, the IFS field is undefined, but it can be modified.

[0201] IFS is not the input to the operation.

[0202] Incomplete Function Length (IFL) 384: Bytes 22-23 of the parameter block contain length information when some operations are completed. For decompression operations, the IFL applies to the second operand. When a decompression operation ends after decoding some, but not all, of a block with a BTYPE equal to binary 00, the IFL contains an unsigned binary integer specifying the number of bytes in the block in the second operand that have not yet been processed. Bytes 22-23 contain the IFL in, for example, big-endian byte order, which differs from the LEN field of a block with a BTYPE equal to binary 00, which is, for example, little-endian byte order.

[0203] When the decompression operation ends after decoding a complete block where BTYPE equals binary 00 and BFINAL equals 1, zero is stored in the IFL field. When the decompression operation ends after decoding some, but not all, of a block with non-zero BTYPEs, or ends at a block boundary, the IFL field is undefined but can be modified.

[0204] When the compression operation is complete, the IFL field is undefined, but it can be modified.

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

[0206] 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 inline and circular history buffers. When New Task (NT) equals 1, no history is available at the start of the operation, and the history length is considered zero as input to the operation.

[0207] When the history length is greater than, for example, 32,768 and NT equals zero, a general operand data anomaly is identified.

[0208] 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 of 32,768.

[0209] History Offset (HO) 386: When the history buffer type is circular, the fifteen bits from bit 1 of byte 46 to bit 7 of byte 47 in 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 uncompressed data least recently processed in the buffer. When the history buffer type is circular, the history offset is the 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 original HO, the original HL, and the sum of the number of uncompressed data bytes processed during the operation modulo 32,768.

[0210] When the history buffer type is inline, the HO field of the parameter block is undefined, but it can be modified.

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

[0212] The input for generating the checksum is, for example, a 4-byte base and the uncompressed data processed during the operation. The base input provides a means of calculating a single and consistent checksum for the entire 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.

[0213] In one example, the following applies when generating Adler-32 checksums:

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

[0215] Modulo the sum defined in the Adler-32 checksum generator: 65,521.

[0216] The results are stored in the check value field in big-endian byte order. That is, the most significant byte of the check value is located in byte 48, and the least significant byte of the check value is located in byte 51.

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

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

[0219] 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 This is represented as hexadecimal 104C11DB7. In this representation, the leftmost bit corresponds to the most significant bit.

[0220] The first and last stages of generating the check value are calculating the two's complement of the radix input and the two's complement of the result before storing the result, respectively.

[0221] The results are stored in the check value field in little-endian byte order. That is, the least significant byte of the check value is located in byte 48, and the most significant byte of the check value is located in byte 51.

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

[0223] End-Of-Block Symbol (EOBS) 388: The 15 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 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 the input of the operation.

[0224] Bit 0 of byte 52 contains the most significant bit of the EOB sign. When the EOB sign is 7 bits long, bit 6 of byte 52 contains the least significant bit of the EOB sign. When the EOB sign is 15 bits long, bit 6 of byte 53 contains the least significant bit of the EOB sign.

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

[0226] When the DFLTCC-XPND feature is specified, the EOBS field is undefined, but it can be modified.

[0227] End-Of-Block Length (EOBL) 389: A 54-byte unsigned binary integer containing bits 0-3 of the parameter block, 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 the output of the operation, regardless of the type of Huffman table applied. The EOBL field is not used as the input of the operation.

[0228] When the DFLTCC-XPND feature is specified, the EOBL field is undefined, but it can be modified.

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

[0230] Compression Dynamic-Huffman Table (CDHT) 367: When the DFLTCC-CMPR function is specified and HTT 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.

[0231] Continuation State Buffer (CSB) 392: When a condition causes the value 1 to be stored in CF field 373, internal state data is stored in bytes 384-1535 of the parameter block; otherwise, bytes 384-1535 of the parameter block are undefined and can be modified. The stored internal state data is model-dependent and can be subsequently used for recovery operations. It is expected—but not required—that the program initialize the continuation state buffer to contain, for example, all zeros. The program should not modify the continuation state buffer after the instruction has ended with a non-zero condition code set, and before the instruction is re-executed for recovery operations; otherwise, the results are unpredictable.

[0232] Although the above reference parameter block 370 describes various fields, additional, fewer and / or other fields may be included in other embodiments.

[0233] The following is an example of a compression operation relative to compressed data.

[0234] The normal completion of the DFLTCC-CCMPR function occurs when the entire second operand is compressed and stored in the first operand location. In one example, when the operation ends due to normal completion, the following occurs:

[0235] Model-related values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

[0236] The continuation flag (CF) field 373 of the parameter block is set to zero.

[0237] The subbyte boundary (SBB) field 381 of the parameter block is updated.

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

[0239] The history length (HL) field of the parameter block 385 has been updated.

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

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

[0242] The validation field 387 of the parameter block has been updated.

[0243] The address increment in general-purpose register R1 includes the number of bytes processed for the first operand that handles bit 0, and the length increment in general-purpose register R1+1 is the same number decremented. The number of bytes processed for the first operand that handles bit 0 is an 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.

[0244] The address in general-purpose register R2 is incremented by the number of source bytes processed, and the length in general-purpose register R2+1 is decremented by the same number.

[0245] Set condition code 0.

[0246] The formation and updating of addresses and lengths depend on the addressing mode.

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

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

[0249] The continuation flag (CF) bit 373 in the parameter block is set to 1.

[0250] The Continuation State Buffer (CSB) field 392 in the parameter block is updated.

[0251] The subbyte boundary (SBB) field 381 of the parameter block is updated.

[0252] The history length (HL) field of the parameter block 385 has been updated.

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

[0254] The validation field 387 of the parameter block has been updated.

[0255] The model-dependent values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

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

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

[0258] The address increment in general-purpose register R1 includes the number of bytes processed for the first operand that handles bit 0, and the length increment in general-purpose register R1+1 is the same number decremented. The number of bytes processed for the first operand that handles bit 0 is an 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.

[0259] The address in general-purpose register R2 is incremented by the number of source bytes processed, and the length in general-purpose register R2+1 is decremented by the same number.

[0260] Set condition code 3.

[0261] The formation and updating of addresses and lengths depend on the addressing mode.

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

[0263] After the instruction ends with condition code 3, the program is expected not to modify any input or output specifications of the instruction and will branch back to re-execute the instruction to resume the operation.

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

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

[0266] The length of the first operand, as specified by the contents of the general-purpose register R1+1, is zero at the start of instruction execution.

[0267] The length of the first operand becomes zero during instruction execution, and no normal completion occurs.

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

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

[0270] The continuation flag (CF) bit 373 in the parameter block is set to 1.

[0271] The Continuation State Buffer (CSB) field 392 in the parameter block is updated.

[0272] The subbyte boundary (SBB) field 381 of the parameter block is updated.

[0273] The history length (HL) field of the parameter block 385 has been updated.

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

[0275] The validation field 387 of the parameter block has been updated.

[0276] The model-dependent values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

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

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

[0279] The address increment in general-purpose register R1 includes the number of bytes processed for the first operand that handles bit 0, and the length increment in general-purpose register R1+1 is the same number decremented. The number of bytes processed for the first operand that handles bit 0 is an 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.

[0280] The address in general-purpose register R2 is incremented by the number of source bytes processed, and the length in general-purpose register R2+1 is decremented by the same number.

[0281] Condition code 1 is set.

[0282] The formation and updating of addresses and lengths depend on the addressing mode.

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

[0284] Condition code 1 is set.

[0285] 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 restore the operation.

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

[0287] Store in the parameter block, as described below.

[0288] Store in the first operand position.

[0289] The data is stored in the third operand location, which occurs, for example, when the history buffer type (HBT) is 1 (circular).

[0290] When the entire parameter block overlaps with the PER storage area specified, a PER storage change event for the parameter block is identified, where applicable. When only a portion of the parameter block overlaps with the PER storage area specified, the following model-dependent scenarios occur:

[0291] When applicable, identify PER storage change events for parameter blocks.

[0292] When applicable, identify PER storage change events for portions of the storage of parameter blocks.

[0293] When applicable, when HBT is 1 (circular), PER zero address detection events are identified for parameter blocks, first operand positions, second operand positions, and third operand positions.

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

[0295] When an instruction terminates with condition code 1 or 3, the input data referenced from the second operand position may be processed completely or only partially. When the input data is processed only partially, the results in the first operand position, first operand address, first operand length, and the SBB field of the parameter block do not indicate a consistent state 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 data partially processed depends on the conditions and model present at the end of the operation. Although some data may be processed only partially, the results stored to the left of the position specified by the updated first operand address are complete and will not be modified when the operation is resumed. Furthermore, the program is expected to subsequently re-execute the instruction to resume the operation, at which point the contents of the CSB field are referenced before the operation was resumed. When an instruction terminates with condition code 0, all data is processed completely, and all results associated with the input and output data indicate a consistent state.

[0296] After an instruction ends with a non-zero condition code, and before the instruction is re-executed for the purpose of resuming the operation, the program should not modify any fields of the parameter block; otherwise, the result will be unpredictable.

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

[0298] When the DFLTCC-XPND function is specified, a decompression operation is performed. This operation involves decoding the compressed data symbols from the second operand location into uncompressed data, which is then stored in the first operand location.

[0299] In one example, the DFLTCC-XPND function uses a parameter block, as mentioned above. Figure 3K-3L An example of this parameter block is shown.

[0300] The following is an example of the DFLTCC-XPND operation describing the decompression of data.

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

[0302] Model-related values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

[0303] The continuation flag (CF) field 373 of the parameter block is set to zero.

[0304] The subbyte boundary (SBB) field 381 of the parameter block is updated.

[0305] The history length (HL) field of the parameter block 385 has been updated.

[0306] When applicable, update the history offset (HO) field 386 of the parameter block.

[0307] The Compressed Dynamic-Huffman Table (CDHT) 367 and Compressed Dynamic-Huffman Table Length (CDHTL) fields 366 of the parameter block are set to zero.

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

[0309] The validation field 387 of the parameter block has been updated.

[0310] The address in general-purpose register R1 is incremented by the number of bytes stored at the first operand location, and the length in general-purpose register R1+1 is decreased by the same number.

[0311] The address increment in general-purpose register R2 contains the number of bytes processed for the second operand that handles bit 0, and the length in general-purpose register R2+1 decreases by the same number. The number of bytes processed, including the second operand that handles bit 0, is an 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.

[0312] Condition code 0 is set.

[0313] The formation and updating of addresses and lengths depend on the addressing mode.

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

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

[0316] The continuation flag (CF) bit 373 in the parameter block is set to 1.

[0317] The Continuation State Buffer (CSB) field 392 in the parameter block is updated.

[0318] The subbyte boundary (SBB) field 381 of the parameter block is updated.

[0319] 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, bytes in 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 in the CDHT and CDHTL fields.

[0320] The history length (HL) field of the parameter block 385 has been updated.

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

[0322] The validation field 387 of the parameter block has been updated.

[0323] Model-related values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

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

[0325] The Incomplete Function Status (IFS) field 383 of the parameter block has been updated.

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

[0327] The address in general-purpose register R1 is incremented by the number of bytes stored at the first operand location, and the length in general-purpose register R1+1 is decreased by the same number.

[0328] The address increment in general-purpose register R2 contains the number of bytes processed for the second operand that handles bit 0, and the length in general-purpose register R2+1 decreases by the same number. The number of bytes processed, including the second operand that handles bit 0, is an 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.

[0329] Condition code 3 is set.

[0330] The formation and updating of addresses and lengths depend on the addressing mode.

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

[0332] After the instruction ends with condition code 3, the program is expected not to modify any input or output specifications of the instruction and will branch back to re-execute the instruction to resume the operation.

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

[0334] The operation is completed when the length of the second operand is insufficient, for example, in the following situations:

[0335] During the operation, the last element of the compressed data block where BFINAL equals 1 has not yet 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 from the second operand position have been placed at the first operand position.

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

[0337] The continuation flag (CF) bit 373 in the parameter block is set to 1.

[0338] The Continuation State Buffer (CSB) field 392 in the parameter block is updated.

[0339] The subbyte boundary (SBB) field 381 of the parameter block is updated.

[0340] The Compressed Dynamic-Huffman Table (CDHT) 367 and Compressed Dynamic-Huffman Table Length (CDHTL) fields 366 of the parameter block are updated. When partial completion occurs while processing a block with a BTYPE value of binary 10, bytes in 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 in the CDHT and CDHTL fields.

[0341] The history length (HL) field of the parameter block 385 has been updated.

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

[0343] The validation field 387 of the parameter block has been updated.

[0344] Model-related values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

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

[0346] The Incomplete Function Status (IFS) field 383 of the parameter block has been updated.

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

[0348] The address in general-purpose register R1 is incremented by the number of bytes stored at the first operand location, and the length in general-purpose register R1+1 is decreased by the same number.

[0349] The address increment in general-purpose register R2 contains the number of bytes processed for the second operand that handles bit 0, and the length in general-purpose register R2+1 decreases by the same number. The number of bytes processed, including the second operand that handles bit 0, is an 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.

[0350] Condition code 2 is set.

[0351] The formation and updating of addresses and lengths depend on the addressing mode.

[0352] 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 restore the operation.

[0353] The length of the first operand is insufficient to complete the operation when, for example, the following situations apply:

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

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

[0356] The continuation flag (CF) bit 373 in the parameter block is set to 1.

[0357] The Continuation State Buffer (CSB) field 392 in the parameter block is updated.

[0358] The subbyte boundary (SBB) field 381 of the parameter block is updated.

[0359] 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, bytes in 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 in the CDHT and CDHTL fields.

[0360] The history length (HL) field of the parameter block 385 has been updated.

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

[0362] The validation field 387 of the parameter block has been updated.

[0363] Model-related values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

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

[0365] The Incomplete Function Status (IFS) field 383 of the parameter block has been updated.

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

[0367] The address in general-purpose register R1 is incremented by the number of bytes stored at the first operand location, and the length in general-purpose register R1+1 is decreased by the same number.

[0368] The address increment in general-purpose register R2 contains the number of bytes processed for the second operand that handles bit 0, and the length in general-purpose register R2+1 decreases by the same number. The number of bytes processed, including the second operand that handles bit 0, is an 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.

[0369] Condition code 1 is set.

[0370] The formation and updating of addresses and lengths depend on the addressing mode.

[0371] 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 restore the operation.

[0372] When applicable, identify PER storage change events for the following:

[0373] Store in the parameter block, as described below.

[0374] Store in the first operand position.

[0375] The data is stored in the third operand location, which occurs, for example, when the history buffer type (HBT) is 1 (circular).

[0376] 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, where applicable. In one embodiment, when only a portion of the parameter block overlaps with the PER storage area specification, the following model-dependent scenario occurs:

[0377] When applicable, identify PER storage change events for parameter blocks.

[0378] When applicable, identify PER storage change events for portions of the storage of parameter blocks.

[0379] When applicable, when HBT is 1 (circular), PER zero address detection events are identified for parameter blocks, first operand positions, second operand positions, and third operand positions.

[0380] When an instruction ends with condition code 1, 2, or 3, the input data referenced from the second operand position may be processed completely or only partially. When the input data is processed only partially, the results in the first operand position, first operand address, first operand length, SBB field of the parameter block, checksum field of the parameter block, HL field of the parameter block, IFS field of the parameter block, and (where applicable) the third operand position and 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 can 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 processed only partially, the results stored to the left of the position specified by the updated first operand address are complete and will not be modified when the operation is resumed. Furthermore, the program is expected to subsequently re-execute the instruction to resume the operation, at which point the contents of the CSB field are referenced before the operation was resumed. When the operation ends with condition code 0, all data is fully processed, and all results associated with the input and output data represent a consistent state.

[0381] After an instruction ends with a non-zero condition code, and before the instruction is re-executed for the purpose of resuming the operation, the program should not modify any fields of the parameter block; otherwise, the result will be unpredictable.

[0382] Compressed Data Blocks

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

[0384] Figure 6 An example of 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:

[0385] The compressed data block 600 consists of a bit stream 602, which begins with bit 4 of byte 0 (identified as b0) and ends with bit 0 of byte 7 (identified as b...). 60 )Finish.

[0386] The first element to appear in the bitstream is BFINAL (the final bit of the block header) in bit 4 of byte 0.

[0387] The second element appearing in the bitstream is BTYPE (block type) in bits 2-3 of byte 0. In the example, BTYPE is binary 00.

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

[0389] The third element appearing in the bitstream 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 containing literal data in the block. For example, the original data is uncompressed. Bytes containing literal data follow the NLEN field in the bitstream. NLEN is the two's complement of LEN. In one example, bytes 1-2 contain the LEN field in little-endian byte order.

[0390] In the bitstream, the elements following the LEN field are the least significant byte of the NLEN field and the most significant byte of the NLEN field, respectively. Bytes 3-4 contain the NLEN field in little-endian byte order. The NLEN field is the two's complement of the LEN field.

[0391] The elements appearing after the NLEN field in the bitstream are uncompressed data, identified as literal bytes. Bytes 5-7 contain uncompressed data, which comes unchanged from the source data used to generate this block.

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

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

[0394] Compressed data block 700 consists of bit stream 702, which begins with bit 4 of byte 0 (identified as b0) and ends with bit 3 of byte 11 (identified as b). 89 )Finish.

[0395] The first element to appear in the bitstream is BFINAL in bit 4 of byte 0.

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

[0397] Fixed-Hoffman Table (FHT) is not a component of the block.

[0398] The third element appearing in the bitstream is the first compressed data symbol, which begins in bit 1 of byte 0. In one example, the compressed data symbol consists of the following sub-elements appearing in the bitstream in the listed order:

[0399] 1. Variable-length Huffman code. The most significant bit of the code specifies its length. Code appears in the bitstream starting with the most significant bit and ending with the least significant bit. When the code represents a literal value or block end symbol, it is the only child element of the compressed data symbol. When the code represents the length of a pointer to a history buffer, subsequent child elements of the compressed data symbol follow the code.

[0400] 2. Where applicable, as specified by the DEFLATE standard, extra length bits may follow the Huffman code indicating the pointer length. Extra length bits appearing in the bitstream begin with the least significant bit and end with the most significant bit.

[0401] 3. The next sub-element appearing in the bitstream is a 5-bit distance code, a pointer to the history buffer. Distance codes appearing in the bitstream, for example, begin with the most significant bit and end with the least significant bit.

[0402] 4. Where applicable, as specified by the DEFLATE standard, extra distance bits may follow the distance code. The extra distance bits appear in the bitstream starting with the least significant bit and ending with the most significant bit.

[0403] As an example, bits 0-1 of byte 0, all bits of byte 1-9, and bits 2-7 of byte 10 contain bits of compressed data symbols.

[0404] The last element appearing in the bitstream is a compressed data symbol containing a single sub-element, which is Huffman code representing the end-of-block (EOB) symbol. The EOB symbol for a block with a BTYPE value of 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.

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

[0406] Figure 8 An example of block 800 with a block type value of 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:

[0407] Compressed data block 800 consists of bit stream 802, which begins with bit 4 of byte 0 (identified as b0) and ends with bit 3 of byte 11 (identified as b). 89 )Finish.

[0408] The first element to appear in the bitstream is BFINAL in bit 4 of byte 0.

[0409] The second element appearing in the bitstream is BTYPE in bits 2-3 of byte 0. In the example, BTYPE is binary 10.

[0410] The third element appearing in the bitstream is the 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 sub-elements appearing in the bitstream in the listed order:

[0411] 1. HLIT: The sum of the 5-bit HLIT sub-element and 257 specifies the number of Huffman codes representing the literal byte, EOB symbol, and repeating string length. Valid values ​​for HLIT range from 0 to 29. HLIT bits appearing in the bitstream begin with the least significant bit of the HLIT sub-element and end with the most significant bit. In the example, bit 1 (identified as b3) of byte 0 is the least significant bit of the HLIT sub-element.

[0412] 2. HDIST: The sum of the 5-bit HDIST sub-element and 1 specifies the number of Huffman codes representing the distance between repeating string pointers. Valid values ​​for HDIST range from 0 to 29. HDIST bits appearing in the bitstream begin with the least significant bit of the HDIST sub-element and end with the most significant bit.

[0413] 3. HCLEN: The sum of the 4-bit HCLEN sub-element and 4 specifies the number of Huffman codes representing the code length. Valid values ​​for HCLEN are, for example, 0-15. HCLEN bits appearing in the bitstream begin with the least significant bit of the HCLEN sub-element and end with the most significant bit.

[0414] 4. A code sequence, specifying the bit length of each code length defined in the compressed DHT. The number of codes equals the sum of HCLEN and 4. Each code is 3 bits.

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

[0416] When the final code length (CL) for the literal byte set, EOB symbol, and repeat string length is 16, 17, or 18, and the extra bits after CL specify repeating CL for more elements than defined for that set, the code length also applies to the repeat string pointer distance set. The code sequence specifying the code length for the literal byte set, EOB symbol, and repeat string length, followed by the code sequence specifying the code length for the repeat string pointer distance, are consecutive sequences of two sets.

[0417] 6. Code sequence, which specifies the code length of each element in the set consisting of the pointer distances of repeating strings. The number of specified code lengths is equal to the sum of HDIST and 1.

[0418] The fourth element appearing in the bitstream is the first compressed data symbol. In one embodiment, the compressed data symbol consists of the following sub-elements appearing in the bitstream in the listed order:

[0419] 1. Variable-length Huffman code. The most significant bit of the code specifies its length. Code appearing in the bitstream begins with its most significant bit and ends with its least significant bit. When the code represents a literal value or block end symbol, it is the only child element of the compressed data symbol. When the code represents the length of a pointer to a history buffer, subsequent child elements of the compressed data symbol follow the code.

[0420] 2. Where applicable, as specified by the DEFLATE standard, extra length bits may follow the Huffman code indicating the pointer length. Extra length bits appearing in the bitstream may begin, for example, with the least significant bit of the extra length bits and end with the most significant bit of the extra length bits.

[0421] 3. The next sub-element appearing in the bitstream is a 5-bit distance code to the pointer to the history buffer. Distance codes appearing in the bitstream are, for example, started with the most significant bit and ended with the least significant bit.

[0422] 4. Where applicable, as specified by the DEFLATE standard, additional distance bits may follow the distance code. Additional distance bits appearing in the bitstream begin, for example, with the least significant bit of the additional distance bit and end with the most significant bit of the additional distance bit.

[0423] Subsequent bits appearing in the bitstream (up to and including, for example, bit 5 of byte 10) contain bits with compressed data symbols.

[0424] The last element appearing in the bitstream is a compressed data symbol containing a single sub-element, which is Huffman code representing the 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.

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

[0426] The above descriptions of different block types specify certain constant values ​​and specific bits, bytes, directions, etc. These are merely examples. In other embodiments, other constant values, bits, bytes, directions, etc., may be specified.

[0427] Processing compressed datasets

[0428] Examples of processing compressed datasets are provided to illustrate sample usage of the DEFLATE transformation call instruction and descriptions of various fields in the enhanced 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 are applicable to compressed datasets, for example, in storage devices. Figure 9 An example of this compressed dataset is shown in the figure. As shown, the compressed dataset 900 includes multiple compressed data blocks 902, and the start of the dataset 900 is indicated by the Compressed Dataset Start Address (CDSBA) 904.

[0429] For the examples described herein, in one embodiment, a program intended for processing compressed datasets should consider the following:

[0430] A single parameter block can be defined and referenced multiple times by the DEFLATE transformation call instruction to process the entire compressed dataset. The checksum 387 and checksum type 375 fields of the parameter block will apply to compressed data blocks in the compressed dataset (e.g., all blocks). The subbyte boundary field 381 of the parameter block will apply to transformations 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 apply only to the individual compressed data block being processed by a specific execution of the DEFLATE transformation call instruction.

[0431] Individual checksums apply to, for example, all uncompressed data represented by a compressed dataset.

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

[0433] Figure 10 List of compression methods Figure 9 This is an example of a portion of the data from the compressed dataset 900 described in the sample program 1000. Further, Figure 11 Listed in Figure 10 The values ​​of certain fields in the parameter block used during the execution of the DFLTCC instruction at the instruction address marked IABLK1 (1002). For example, Figure 11 Different parameter block fields 1100 are shown; the values ​​of these fields at the start of the compression operation 1102; the values ​​of these fields at the end of the operation and when condition code 1, 2 or 3 is set 1104; and the values ​​of these fields at the end of the operation and when condition code 0 is set 1106.

[0434] Similarly, Figure 12 Listed in Figure 10 The figures show the values ​​of certain fields in the parameter block used during the execution of the DFLTCC instruction at instruction address IABLK2 (1004). These figures illustrate some details associated with the multiple uses of the DEFLATE transformation call instruction to process the entire compressed dataset.

[0435] In addition, refer to Figure 13 This shows the method for decompression. Figure 9This is an example of a sample program 1300 containing data from a compressed dataset.

[0436] Compressed data

[0437] The process of compressing data involves generating one or more compressed data blocks. The compression function of the DEFLATE conversion 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. The first compressed data block is generated when the New Task bit (NT) of the parameter block is 1, and there is no history from previously performed compression operations to reference.

[0438] In one example, individual blocks contain the following elements in the order they are listed:

[0439] 1. Final Block Indicator (BFINAL).

[0440] 2. Block type (BTYPE).

[0441] 3. Compressed format of dynamic-Huffman tables (where applicable).

[0442] 4. Compress data symbols.

[0443] 5. End of Block (EOB) symbol.

[0444] The compression operation generates elements in the order specified for the block definition. Elements can begin or end between byte boundaries in the storage device. Subbyte boundaries (SBBs) are used to store the first element at the first operand location. The compressed data block is a bitstream. The components of the block are loaded into memory one bit at a time. As an example, the bitstream is loaded from right to left and byte-by-byte order from left to right within each byte of the storage device.

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

[0446] The uncompressed data from the second operand position is compressed and stored as compressed data symbols in the first operand position.

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

[0448] When the second operand length is zero at the start of instruction execution, the second operand is not accessed, and the addresses and lengths of the second operand in general-purpose registers R2 and R2+1 remain unchanged. For example, the second operand length is zero at the start of instruction execution in the following cases:

[0449] The instruction is re-executed to resume the operation (CF field 373 of the parameter block is 1 at the start of instruction execution), and the operation can be performed using a reference to CSB field 392 of the parameter block instead of a reference to the second operand.

[0450] In one embodiment, the program does not use the DEFLATE conversion call instruction to perform the following operations:

[0451] Generate an empty compressed data block. An empty compressed data block consists of, for example, a block header, the DHT compression format (where applicable), and an EOB symbol.

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

[0453] The compression algorithm involves searching the update history of recently compressed data for a byte string that matches the currently compressed data from the second operand position. In one embodiment, the following applies before the compression operation begins or resumes:

[0454] When New Task (NT) 374 is 1, there is no initial history available for reference.

[0455] When NT is zero and bit 56 of general purpose register 0 (HBT) is zero (inline), the initial history that can be referenced 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.

[0456] When NT is zero and bit 56 of general purpose register 0 (HBT) is 1 (circular), the initial history that can be referenced 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.

[0457] During compression, the entire history can be fetch-type referenced, regardless of which bytes of history are used to perform the operation. Furthermore, when the history buffer type is circular, the entire 32KB history buffer can be fetch-type referenced, regardless of which bytes of history are used to perform the operation.

[0458] During the compression operation, the history is updated. After one or more bytes of the source data are encoded into compressed data symbols without encountering a general operand data exception condition, the source bytes are concatenated to the end of the history. The most recently processed bytes of the source data (up to 32KB) constitute the updated history and can be referenced during the processing of subsequent bytes of the source data.

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

[0460] When the HBT is inline, a storage update of the second operand location is not required when updating the history. The updated second operand address and the updated HL specify the location and length of the updated result history.

[0461] When the HBT is circular, the storage update of the third operand location is performed when updating the history. The third operand address, the updated HO, and the updated HL specify the location and length of the update in the result history.

[0462] As an example, Figures 14A-14C This example illustrates the location of the inline history buffer for the second operand before and after multiple executions of a DEFLATE transition call instruction that specifies the DFLTCC-CMPR function and inline history (e.g., bit 310 = 0), in the case where each execution ends partially. For example, Figure 14A Showing the inline history prior to the first execution of DFLTCC-CMPR; Figure 14B Showing the inline history before the second execution of DFLTCC-CMPR and after the first execution; Figure 14C This shows the inline history after the second execution of DFLTCC-CMPR. Figure 14C The explanation provided in the text also applies. Figure 14A and 14B .

[0463] When the HBT (History Buffer Type) specified by bit 56 of general-purpose register 0 is circular (e.g., bit 310 = 1), history is maintained in a 32KB buffer, for example, located at the third operand position. This is achieved by, for example, the content of general-purpose register R3 and the history offset (HO) 386 (…). Figure 3LThe sum of the values ​​of the first byte of the history within the buffer (HB) specifies the position of the first byte of the history. The first byte of the history is the least recently processed byte of 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:

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

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

[0466] As an example, Figures 15A-15E This example illustrates the position of history within the circular history buffer before and after multiple executions of the DEFLATE transition call instruction, which specifies the DFLTCC-CMPR function and a circular history buffer (bit 310=1), when each execution ends partially. For example, Figure 15A This shows the circular history buffer prior to the first execution of DFLTCC; Figure 15B The circular buffer is shown before the second execution of DFLTCC and after the first execution; Figure 15C The circular buffer is shown before the third execution of DFLTCC and after the second execution; Figure 15D The circular buffers are shown before the fourth execution of DFLTCC and after the third execution of DFLTCC. Figure 15E The circular buffer is shown before and after the fourth execution of DFLTCC. Figure 15E The explanation provided in the text also applies. Figures 15A-15D .

[0467] 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:

[0468] A range of bytes is stored at the third operand position. This range includes and begins at, for example, the position specified as follows:

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

[0470] HOO: The historical offset before instruction execution.

[0471] HLO: The length of the history before the instruction was executed.

[0472] This byte range includes and ends at, for example, the position specified by:

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

[0474] BP: The number of bytes processed during instruction execution in the second operand position.

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

[0476] Storage that does not modify the contents of a storage location and is not necessary can be performed on 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.

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

[0478] When the Block Continuation Flag (BCF) 377 is 0, a 3-bit block header (containing BFINAL, followed by BTYPE) is stored in the first operand location. The BFINAL bit of the block header is set to equal the final bit of the block header (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 in the bit specified by the SBB in the first byte of the first operand. Subsequently, BTYPE is stored in the first operand location. When BCF is 1, the block header is not stored.

[0479] When the Huffman Table Type (HTT) is 1, the compression format of the Dynamic-Huffman Table (DHT) 367 specified in the parameter block is checked for general operand data anomalies. If a general operand data anomaly exists in the specified compression format of the DHT, the compressed DHT is considered invalid and is not used to compress the data. Example definitions of general operand data anomalies are further described below. When the compression format of the DHT specifies a bit length greater than the code length required by the Huffman algorithm for an appropriate and functional Huffman tree, or a literal byte code length, EOB symbol, repeat string length, or repeat string pointer distance, the compressed DHT is still used to derive the functional DHT and compress the data. When the Block Continuation Flag (BCF) is 0 and the 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.

[0480] During the compression operation, the source data from the second operand position 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 that is identical to the source data. When a match is found, the intermediate representation of the source data is a pointer to a location in the history containing 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 beginning of the string that matches the source data. In one example, two Huffman code trees from a 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, a fixed-Huffman table (FHT) as described by the DEFLATE standard specifies two Huffman code trees for encoding the intermediate result. When HTT 376 is 1, a dynamic-Huffman table (DHT) derived from the compressed representation of the DHT and specified in the CDHT field 367 of the parameter block specifies two Huffman code trees for encoding the intermediate result. Encoding is performed as described in the DEFLATE standard. When a non-generic DHT is used that does not specify Huffman code to be used for encoding the intermediate representation of the source data, generic operand data anomalies are identified. The bits of the resulting compressed data symbols are arranged in the order specified in the DEFLATE standard before the result is stored in the first operand location.

[0481] In one example, the length of the repeating string ranges from 3 bytes to 258 bytes.

[0482] Update the history as described in this article before processing further source data.

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

[0484] After the source bytes (e.g., all source bytes) have been processed and 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 used as the EOB symbol is specified by the DHT. 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.

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

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

[0487] Model-related values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

[0488] The subbyte boundary (SBB) field 381 of the parameter block is updated.

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

[0490] The address increment in general-purpose register R1 includes the number of bytes processed for the first operand that handles bit 0, and the length increment in general-purpose register R1+1 is the same number decremented. The number of bytes processed for the first operand that handles bit 0 is an 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.

[0491] The address in general-purpose register R2 is incremented by the number of source bytes processed, and the length in general-purpose register R2+1 is decremented by the same number.

[0492] The formation and updating of addresses and lengths depend on the addressing mode.

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

[0494] Decompressed data

[0495] In one embodiment, an extended function of the DEFLATE conversion call instruction is used to decode the compressed dataset into uncompressed data. The compressed dataset in the second operand location comprises one or more consecutive blocks of compressed data. In one example, blocks of the dataset are processed from left to right, and for example, bytes of the blocks are processed from left to right. Blocks may or may not begin or end on byte boundaries. Each block is decoded independently of other blocks in the dataset. General-purpose register R2 specifies the logical address of the leftmost byte of the first block in the dataset. The last block in the dataset is the block whose BFINAL bit is equal to 1 during processing. In one example, there are three types of blocks to be processed. The technique for decoding the contents of a block is a function of the block type (BTYPE).

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

[0497] Extended functionality includes referencing the history of updates to recently decoded uncompressed data. In one embodiment, the following applies before decompression begins or resumes:

[0498] When New Task (NT) 374 is 1, there is no initial history available for reference.

[0499] When NT is zero and bit 56 of general purpose register 0 (HBT) is zero (inline), the initial history that can be referenced 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.

[0500] When NT is zero and bit 56 of general purpose register 0 (HBT) is 1 (circular), the initial history that can be referenced 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.

[0501] During operation, the entire history can be referenced extractively, regardless of which bytes of history are used to perform the operation. Furthermore, when the history buffer type is circular, the entire history buffer (e.g., 32KB) can be referenced extractively, regardless of which bytes of history are used to perform the operation.

[0502] During the decompression operation, the history is updated. After decoding the source data without encountering any general operand data anomalies, the resulting bytes from the uncompressed data are appended to the end of the history. For example, the most recently decoded bytes of up to 32KB of uncompressed data constitute the updated history, which can be referenced during the processing of subsequent source data.

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

[0504] When the HBT is inline, a 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 location and length of the update to the result history.

[0505] When the HBT is circular, the storage update of the third operand location is performed when updating the history. The third operand address, the updated HO, and the updated HL specify the location and length of the update in the result history.

[0506] As an example, Figures 16A-16C This example illustrates the location of the inline history buffer regarding the first operand before and after multiple executions of the DEFLATE transition call instruction, which specifies the DFLTCC-XPND function and inline history, when each execution ends with partial completion. For example, Figure 16A Showing the inline history prior to the first execution of DFLTCC-XPND; Figure 16B Showing the inline history of DFLTCC-XPND before its second execution and after its first execution; Figure 16C This shows the inline history after the second execution of DFLTCC-XPND. Figure 16C The explanation provided in the text also applies. Figure 16A and 16B .

[0507] When the HBT specified by bit 56 of general purpose register 0 is circular, the history is maintained in a 32KB buffer, for example, located 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 purpose register R3 and the history offset (HO) 386. The first byte of the history is the earliest processed byte of 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:

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

[0509] The last byte of the history is the most recently processed byte of 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., 32KB), the history wraps around from the end of the third operand to the beginning. Figures 15A-15E An example is shown showing the position of the history in the circular history buffer before and after multiple executions of the DEFLATE transition call instruction that specifies the DFLTCC-XPND function and inline history, when each execution ends with partial completion.

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

[0511] A range of bytes is stored at the third operand position. This range includes and begins at, for example, the following specified positions:

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

[0513] HOO: The historical offset before instruction execution.

[0514] HLO: The length of the history before the instruction was executed.

[0515] This byte range includes and ends at, for example, the position specified by:

[0516] R3 + modulo 32K (HOO + HLO + BP -1), where

[0517] BP: The number of bytes stored in the first operand position during instruction execution.

[0518] Storage that does not modify the contents of a storage location and is not necessary can be performed on 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.

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

[0520] When BTYPE is binary 00, the block does not contain compressed data. (As described herein...) Figure 6An example of a block with a BTYPE equal to binary 00 is shown. 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, each literal byte of the block is also used to update the history.

[0521] When 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 in this article, Figure 7 An example of a block with a BTYPE value equal to binary 0 or 1 is shown. After interpreting the block header, the compressed data symbols are decoded in the order they appear in the block. For example, bytes of the block are processed from left to right, and bits within each byte of the block are processed from right to left. In one example, each symbol is fully processed before the next symbol in the block is processed. Each symbol that is not an end-of-block (EOB) symbol represents a literal value or a pointer to a previously decoded substring in the history buffer. The previously decoded substring is also called a repeating string. In one example, the repeating string length ranges from 3 bytes to 258 bytes. The pointer consists of code representing the length of the substring and the distance from the end of the history to the beginning of the substring. When a symbol represents a substring in the history, that substring is referenced from the history buffer. The uncompressed data resulting from the decoded symbols is placed at the first operand position.

[0522] Update the history as previously described before processing further source data.

[0523] The updated history applies to decoding the next symbol in the block. The block processing is complete when the EOB symbol is encountered.

[0524] When BTYPE is binary 10, the block contains compressed data symbols generated using a Dynamic-Huffman Table (DHT). The compression format of the DHT used is the element of the compressed data block. (Described herein...) Figure 8An example of a block with a BTYPE equal to binary 10 is shown. After interpreting the block header, the compression format of the DHT provided within the compressed data block is examined for general operand data anomalies. When a general operand data anomaly exists in the compression format of the provided DHT, the DHT is considered invalid and is not used to decompress the data. The compressed DHT is still used to derive the functional DHT and compressed data when the DHT's compression format specifies a bit length greater than the code length required by the Huffman algorithm for an appropriate and functional Huffman tree, or the code length of a literal byte, EOB symbol, repeat string length, or repeat string pointer distance. After examining the DHT's compression format, the compressed data symbols are decoded in the order they appear in the block. For example, bytes of the block are processed from left to right, and bits within each byte of the block are processed from right to left. In one example, each symbol is fully processed before the next symbol in the block is processed. The handling of symbols in blocks with a BTYPE value of binary 10 is the same as the handling of symbols in blocks with a BTYPE value of 01 described previously, except that the former uses the DHT provided for decoding the symbols, while the latter uses the FHT to decode the symbols. When a non-generic DHT is provided that does not specify the Huffman code to be used for decoding compressed data symbols, generic operand data anomalies are identified.

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

[0526] In one embodiment, after processing the last block of the dataset, the following occurs:

[0527] Model-related values ​​are stored in the Model Version Number (MVN) field 363 of the parameter block.

[0528] The subbyte boundary (SBB) field 381 of the parameter block is updated.

[0529] The address in general-purpose register R1 is incremented by the number of bytes stored at the first operand location, and the length in general-purpose register R1+1 is decreased by the same number.

[0530] The address increment in general-purpose register R2 includes the number of bytes processed for the second operand that handles bit 0, and the length in general-purpose register R2+1 decreases by the same number. The number of bytes processed for the second operand that handles bit 0 is an 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.

[0531] The formation and updating of addresses and lengths depend on the addressing mode.

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

[0533] When the second operand length is zero at the start of instruction execution, the second operand is not accessed, and the second operand address and length in general-purpose registers R2 and R2+1 remain unchanged. In one embodiment, the second operand length is zero at the start of instruction execution for the following reasons:

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

[0535] The decompression operation can end without storing any results in 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 of the following compressed data block elements:

[0536] Block head.

[0537] The LEN field of a block whose block type value is binary 00.

[0538] The NLEN field of a block whose block type value is binary 00.

[0539] A compressed format for dynamic-Huffman tables.

[0540] End of Block (EOB) symbol.

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

[0542] In one example, a general operand data anomaly is identified when the DFLTCC-GDHT function is specified and the following conditions are met:

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

[0544] In one example, a general operand data anomaly is identified when the DFLTCC-CMPR feature is specified and any of the following conditions occur:

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

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

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

[0548] HTT376 is 1, and CDHTL366 is not equal to the length of the DHT compression format specified in CDHT field 367.

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

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

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

[0552] HTT 376 is 1, and the compression format of the DHT (the content of CDHT field 367) specifies a code length of, for example, 16 (the code length before copying), which is the first code length of the set of elements consisting of literal bytes, EOB symbols, and repeating string length (invalid DHT).

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

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

[0555] HTT 376 is 1, and the compressed format of the DHT (the content of CDHT field 367) specifies the code in the code sequence with the specified repeating string length and pointer distance, and the code does not match any code that is determined to represent the set of reference code lengths as previously specified in the compressed DHT.

[0556] HTT 376 is 1, and the number of code lengths specified by the DHT's compressed format (the content of CDHT field 367) 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 in cases where code lengths of 16, 17, and 18 are used incorrectly (invalid DHT).

[0557] HTT 376 is 1, and the compressed format of the DHT (the content of CDHT field 367) specifies the code length of the set of literal bytes, EOB symbols, and repeating string lengths, which is less than the length required by the Huffman algorithm to define the functional Huffman tree (invalid DHT).

[0558] HTT 376 is 1, and the compressed format of the DHT (the content of CDHT field 367) specifies the code length of the set of repeating string pointer distances, which is less than the length required by the Huffman algorithm to define the functional Huffman tree (invalid DHT).

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

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

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

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

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

[0564] A compressed data block with BTYPE equal to binary 11 has appeared.

[0565] A compressed data block containing a binary 00 BTYPE and a 1's complement of NLEN that is not equal to LEN.

[0566] A DHT in a compressed format (BTYPE equal to the content of a compressed data block of binary 10) exists, and the HLIT sub-element of the compressed DHT is greater than, for example, 29 (invalid DHT).

[0567] A DHT in a compressed format (BTYPE equal to the contents of a compressed data block of binary 10) exists, and the HDIST sub-elements of the compressed DHT are greater than, for example, 29 (invalid DHT).

[0568] The DHT compression format (BTYPE equals the contents of a compressed data block of binary 10) is specified as a code sequence of code length defined by the DHT as, for example, 19 code lengths, and is less than the length required by the Huffman algorithm to specify the function of the Huffman tree (invalid DHT).

[0569] A DHT compression format (containing compressed data blocks with a BTYPE equal to binary 10) has a specified code length, such as 16 (the code length of the previous copy), which is the first code length of the set of elements consisting of literal bytes, EOB symbols, and repeating string lengths (invalid DHT).

[0570] The DHT appears in a compressed format (containing the contents of a compressed data block with a BTYPE equal to binary 10), which specifies the code in a code sequence of a specified literal byte length, and the code does not match any code determined to represent the set of reference code lengths previously specified in the compressed DHT (invalid DHT).

[0571] A DHT with a compressed format (BTYPE equal to the contents of a compressed data block of binary 10) specifies that code length 0 (CL0) is assigned to the code of the EOB symbol. In this case, the corresponding DHT does not specify Huffman code to represent the EOB symbol (invalid DHT).

[0572] The DHT compression format (BTYPE equals the contents of a compressed data block of binary 10) is present, which specifies the code in the code sequence with a specified repeating string length and pointer distance, and the code does not match any code determined to represent the set of reference code lengths as previously specified in the compressed DHT.

[0573] A DHT compression format (containing compressed data blocks with a BTYPE equal to binary 10) exists where the specified code length 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. This is possible, for example, in cases where code lengths of 16, 17, and 18 are used incorrectly (invalid DHT).

[0574] A DHT compression format (containing compressed data blocks with a BTYPE equal to binary 10) has a code length that specifies the set of literal bytes, EOB symbols, and repeating string lengths, which is less than the length required by the Huffman algorithm to define a functional Huffman tree (invalid DHT).

[0575] A compressed format of DHT (containing compressed data blocks with a BTYPE equal to binary 10) appears, which specifies the code length of the set of repeating string pointer distances, and is less than the length required by the Huffman algorithm to specify a functional Huffman tree (invalid DHT).

[0576] Compressed data symbols appearing in a compressed data block where BTYPE equals binary 10 specify Huffman codes not defined by a non-generic DHT derived from the compressed format of the DHT in the same block. In this case, the number of bits available for processing of the second operand (for the purpose of identifying anomalies in generic operand data) is model-dependent. More specifically, a model attempting to decode undefined codes might process, for example, 15 bits before identifying an anomaly, even if the anomaly could be determined after processing fewer bits.

[0577] A compressed data symbol appears, which is a pointer to a repeating string and specifies a distance greater than the length of the history available at the time the symbol is processed.

[0578] Compressed data symbols appearing in compressed data blocks where BTYPE equals binary 0 or 1 specify invalid codes (e.g., binary codes 11000110 or 11000111 for the repeating string length, or binary codes 11110 or 11111 for the repeating string pointer distance). In this case, the number of bits available for processing on the second operand (for the purpose of identifying general operand data anomalies) depends on the model. More specifically, a model attempting to decode invalid codes may process, for example, 8 bits (in the case of repeating string length) or 5 bits (in the case of repeating string pointer distance) before identifying the anomaly, even if the anomaly can be determined after processing fewer bits.

[0579] When an anomaly is detected in the general operand data, the operation is considered suppressed even if the Operation End Supplement Code (OESC) 365 and Model Version Number (MVN) field 363 in the parameter block are updated to provide additional information associated with the anomaly.

[0580] 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 that an exception is identified, or the operation ends with partial completion and, for example, condition code 3 being set. If condition code 3 is set, the exception will be identified when the instruction is executed again to continue processing the same operand and the exception condition still exists.

[0581] Other conditions include, for example:

[0582] Instruction execution is interruptible. When an interrupt 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 can resume execution at the point of interruption when it is re-executed.

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

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

[0585] In one embodiment, if the DFLTCC-CMPR or DFLTCC-XPND functionality is specified and any of the following applies, the result is unpredictable:

[0586] The parameter block overlaps with the first or second operand.

[0587] The first operand overlaps with the second operand.

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

[0589] Specify that the history buffer type (HBT) is inline, specify the DFLTCC-CMPR function, and that the history overlaps with the first operand or parameter block.

[0590] Specify that the history buffer type (HBT) is inline, specify the DFLTCC-XPND function, and that the history overlaps with the second operand or parameter block.

[0591] In some cases, although the execution of the DEFLATE translation call instruction ends with the CPU determining that the number of bytes processed is zero, data may have already been stored in the first operand location, data may have already been stored in the third operand location (where applicable), and the corresponding change bits may have been set (where applicable). In these cases, the contents of the parameter block and general-purpose registers have not yet been modified from their original values. These situations can occur when the CPU performs a silent operation or retry while executing the DEFLATE translation call instruction.

[0592] The following are example condition codes obtained from executing the DEFLATE conversion call instruction:

[0593] 0 Completed normally

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

[0595] 2. The second operand is not long enough to complete the operation (DFLTCC-XPND)

[0596] 3. The amount of data processed as determined by the CPU

[0597] Program error:

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

[0599] Data with DXC 0, general operands

[0600] Operation (if DEFLATE conversion facility is not installed)

[0601] specification

[0602] Transaction constraints

[0603] The following are examples of the execution priorities of the DEFLATE CONVERSION CALL instruction:

[0604]

[0605]

[0606] Before use, check the DHT compression format for common operand data anomaly conditions. When the length of the DHT compression format is not precisely defined due to common operand data anomaly conditions, the interpreted length may depend on the condition, depend on the model, and not exceed, for example, 286 bytes. As a result, when the DFLTCC-XPND function is specified and a DHT compression format with a common operand data anomaly condition appears in, for example, the rightmost 286 bytes of the second operand, identifying whether the anomaly condition (priority 14.A) or condition code 2 (priority 14.B) depends on the model.

[0607] The following provides example programming annotations:

[0608] 1. When compressing or decompressing data, it is generally more efficient to perform the operation with the minimum number of DEFLATE transformation call instructions. In other words, performing a DFLTCC with a large number of operands is many times more efficient than performing a DFLTCC with a small number of operands.

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

[0610] 3. In one embodiment, the DEFLATE translation call instruction is interruptible, but can complete after the CPU has executed the sub-part of the processing specified by the instruction's parameters. When the instruction completes after executing only the CPU-determined processing amount, rather than all specified processing, the instruction sets condition code 3. Upon such completion, the instruction address in the PSW (Program Status Word) specifies the next sequential instruction, and the instruction's operand parameters have been adjusted so that the instruction's processing can be resumed by branching back to the instruction to re-execute it. When the instruction has executed all specified processing, it sets condition codes other than 3.

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

[0612] 5. When an operation ends with a non-zero condition code set, the CSB field 392 of the parameter block may contain partially processed data, and the program is expected to re-execute the instructions to resume the operation.

[0613] 6. After an operation ends with a non-zero condition code set, and before the instructions are re-executed for the purpose of restoring the operation, the program does not modify any fields of the parameter block; otherwise, the result is unpredictable.

[0614] 7. When the DFLTCC-GDHT functionality is specified, the compressed representation of the generated DHT, according to the Huffman algorithm, describes three properly complete Huffman code trees. That is, no incomplete Huffman code trees are described. An incomplete Huffman code tree is derived from the compressed representation of the DHT, specifying an element code length greater than the length required by the Huffman algorithm for a properly complete and functional Huffman tree.

[0615] 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 used to convert the compressed data result into raw uncompressed data. However, not all decoders conforming to the DEFLATE standard can convert the result into raw uncompressed data. This may happen, for example, when the compressed representation of the DHT specified by the DFLTCC-CMPR function is not generated due to the execution of the DFLTCC-GDHT function.

[0616] 8. When the DFLTCC-CMPR function ends with condition code 1 set, the result stored in the subbyte boundary (SBB) field 381 of the parameter block is binary 000. This situation may be related to the allocation of an output buffer for use with the DEFLATE conversion call instruction.

[0617] As described herein, in one aspect, a single instruction (e.g., a single architectural machine instruction at the hardware / software interface, such as the DEFLATE translation call instruction) is provided to perform compression and / or decompression operations using a general-purpose processor. This instruction is, for example, a hardware instruction defined in an instruction set architecture (ISA). Therefore, the complexity of the program associated with compression and / or decompression operations is reduced. Furthermore, the performance of the operation is improved, and thus the performance of the processor is enhanced.

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

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

[0620] See Figure 17 This describes an embodiment of using the DEFLATE conversion call instruction. In one example, a program executing on a processor (e.g., a general-purpose processor) specifies details of the operation to be performed in a parameter block in the storage device and specifies the location of the parameter block (step 1700). For example, depending on the function to be performed, one or more fields of the parameter block (e.g., parameter block 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 the result buffer in the storage device (step 1706).

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

[0622] Based on instruction termination, determine whether the condition code generated by execution is equal to a first defined value (e.g., 0) (prompt 1710). If the condition code is equal to the first defined value, then instruction processing is complete (step 1712). However, if the condition code is not equal to the first defined value, further determine whether the condition code is equal to a second defined value (e.g., 3) (prompt 1714). If the condition code is equal to the second defined value—indicating there is additional data to process—the instruction is re-executed (step 1708). However, if the condition code is not equal to the second defined value, another determination is made regarding whether the condition code is set to a third defined value (e.g., 1) (prompt 1716). If the condition code is set to the third defined value—indicating the first operand length is insufficient—process continues to step 1706; otherwise, the second operand length is insufficient for the function, and processing continues to step 1704.

[0623] As described above, the DEFLATE transformation call instruction can be executed multiple times to compress or decompress a single data stream. Therefore, in one aspect, the DEFLATE transformation call instruction includes the property of providing a mechanism to declare a buffer (e.g., a 32KB buffer) for accumulating the history of uncompressed data processed during multiple executions of the DEFLATE transformation call instruction. The buffer is, for example, a circular history buffer.

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

[0625] See Figure 18Further details on using a circular history buffer are described. 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 parameter block in the storage device (step 1800). For example, depending on the function to be performed, one or more fields of the parameter block (e.g., parameter block 360 or 370) are provided or set. Further, the program specifies the operation to be performed (e.g., compression, expansion, etc.).

[0626] Furthermore, in one example, the program allocates and specifies the location in memory of a circular buffer of a predefined size (e.g., 32KB) (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 conversion call instruction (step 1804), and specifies or updates the location and size of the result buffer in the storage device (step 1806).

[0627] Next, the DEFLATE conversion call instruction is executed (step 1808). Based on the executed instruction, the processor retrieves history from, for example, a circular history buffer 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 to the operation (step 1824). A query is made in step 1826 to determine whether the entire data stream has been processed. If not, processing continues to step 1804. Otherwise, processing is complete.

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

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

[0630] When a large (e.g., 128KB) input or output buffer is specified for a single execution of a DEFLATE conversion call instruction, up to, for example, 32KB of the history of a previous segment of buffered data can be used as input to the first 32KB of data being processed in the DEFLATE conversion call instruction.

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

[0632] One or more aspects of this invention are inextricably linked to computer technology and facilitate processing within a computer, thereby improving its performance. Using a single, structured machine instruction to perform compression and / or decompression improves performance within a computing environment. Compressed / decompressed data can be used in many technical fields of data management and / or utilization, such as computer processing, medical processing, security, inventory control, etc. These technical fields are improved by providing optimizations in compression / decompression, thereby reducing execution time.

[0633] See Figures 19A-19B Further details are described regarding one embodiment of facilitating processing within a computing environment, relating to one or more aspects of the present invention.

[0634] See Figure 19A In one embodiment, the processor of the computing environment receives instructions (1900) to perform one of a plurality of functions supported by instructions. The instructions are single, architectural instructions conforming to a compression industry standard instruction set architecture (1904). The instructions are executed (1906), the execution including performing the function specified by the instructions (1908), the execution including, based on whether the function is a compression or decompression function, transforming the state of the input data between an uncompressed form and a compressed form of the input data to provide a transformed data state (1910). During the execution of the function, a history of the function is accessed, the history to be used to transform the state of the input data between the uncompressed and compressed forms (1912). The transformed data state is provided as output for use when performing a task (1914).

[0635] In one example, the processor is a general-purpose processor (1916). The state of the input data is transformed using an industry-standard compressed format (1918). Furthermore, as an example, the history is stored in a buffer specified by instructions (1920).

[0636] As an example, see Figure 19B The instruction includes an opcode field and multiple register fields. The opcode field includes an opcode specifying the operation, and the multiple register fields specify multiple registers to be used by the instruction (1922). These multiple registers include, for example, a register identifying the location of an output operand to be used as output by the instruction and another register identifying the location of an input operand to be used as input by the instruction (1924). The instruction uses a selected register to specify the location of the buffer in memory and another selected register to provide the address of the parameter block to be used by the instruction (1926). The parameter block specifies an offset within the buffer that marks the beginning of the history within the buffer (1928). The parameter block further includes the length of the history within the buffer (1930).

[0637] Furthermore, in one example, the instruction uses the selected register to specify the type of buffer (1932), and in another example, the buffer is a circular buffer (1934).

[0638] In one example, the input depends on the function (1936), and, based on the function being a compression function, the input includes data in the input operand locations to be encoded to provide compressed data symbols stored in the output operand locations, and data to be copied from the input operand locations and stored in a buffer as history (1938). Further, based on the function being a decompression function, the input includes compressed data symbols in the input operand locations to be decoded to provide uncompressed data stored in the output operand locations and in a buffer (1940).

[0639] Other variations and implementations are possible.

[0640] This invention can be used in many types of computing environments. See also Figure 20A The description includes and uses one or more aspects of the present invention in a computing environment. In this example, computing environment 10 includes, for example, a local central processing unit (CPU) 12, memory 14, and one or more input / output devices and / or interfaces 16 coupled to each other via, for example, one or more buses 18 and / or other connections. As an example, computing environment 10 may include a PowerPC provided by International Business Machines Corporation of Armonk, New York, USA. ® Processor; HP Superdome featuring an Intel Itanium II processor, supplied by Hewlett-Packard, Inc., Palo Alto, California, USA; and / or other machines based on architectures supplied by International Business Machines Corporation, HP, 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 U.S. and other countries.

[0641] 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.

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

[0643] refer to Figure 20B Further details relating to emulator code 22 are described below. Client instructions 30 stored in memory 14 include software instructions (e.g., machine instructions) developed for execution in an architecture different from the native CPU 12. For example, client instructions 30 may have been designed to execute on a z / Architecture-based hardware processor, but are instead emulated on a native CPU 12, which could be, for example, an Intel Itanium II processor. In one example, emulator code 22 includes an instruction fetch routine 32 to fetch one or more client instructions 30 from memory 14, and optionally provides a local buffer for the fetched instructions. It also includes an instruction translation routine 34 to determine the type of the fetched client instructions and translate them into one or more corresponding native instructions 36. This translation includes, for example, identifying the function to be executed by the client instructions and selecting native instructions to execute said function.

[0644] Furthermore, emulator code 22 includes an emulation control routine 40 to cause native instructions to be executed. The emulation control routine 40 causes the local CPU 12 to execute a native instruction routine that emulates one or more previously fetched client instructions, and upon completion of this execution, returns control to the instruction fetch routine to emulate the fetching of the next client instruction or a set of client instructions. Execution of native instruction 36 may include, as determined by the translation routine, loading data from memory 14 into a register; storing data from a register back into memory; or performing some type of arithmetic or logical operation.

[0645] Each routine is implemented, for example, in software, which is stored in memory and executed by the local central processing unit 12. In other examples, one or more routines or operations are implemented in firmware, hardware, software, or a combination thereof. The registers of the emulated processor can be simulated using the local CPU's registers 20 or by using locations in memory 14. In embodiments, client instructions 30, native instructions 36, and emulator code 22 may reside in the same memory or may be distributed across different memory devices.

[0646] The computing environment described above is merely an example of a usable computing environment. Other environments may be used, including but not limited to other non-partitioned environments, other partitioned environments, and / or other simulation environments; the embodiments are not limited to any one of these environments.

[0647] 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.

[0648] One or more aspects may involve cloud computing.

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

[0650] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, storage, applications, virtual machines, and services) that can be rapidly configured and deployed with minimal management effort or interaction with a service provider. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0651] The features are as follows:

[0652] On-demand self-service: Cloud consumers can automatically and unilaterally supply computing power, such as server time and network storage, on demand, without any manual interaction with service providers.

[0653] Extensive network access: Functionality is provided via a network and accessed through standard mechanisms that facilitate use by heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0654] Resource pooling: Providers' computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated as needed. Location independence is significant because consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify a higher level of abstraction (e.g., country, state, or data center).

[0655] Rapid and flexible: Features can be configured quickly and flexibly, automatically expanding rapidly in certain situations and quickly shrinking back down. For consumers, the available features often appear unlimited, and can be purchased in any quantity at any time.

[0656] Metrics-based services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a certain level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and users.

[0657] The service model is as follows:

[0658] Software as a Service (SaaS): This provides consumers with the functionality to use applications from a provider that run on cloud infrastructure. These applications can be accessed from various client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application functionality, with possible exceptions such as limited user-specific application configuration settings.

[0659] Platform as a Service (PaaS): This provides consumers with the ability to deploy consumer-created or acquired applications on cloud infrastructure, using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and, if any, the configuration of the application hosting environment.

[0660] Infrastructure as a Service (IaaS): This provides consumers with the processing, storage, networking, and other basic computing resources that enable them to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0661] The deployment model is as follows:

[0662] Private cloud: A cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0663] Community cloud: A cloud infrastructure shared by multiple organizations that supports a specific community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0664] Public cloud: Cloud infrastructure available to the public or large industry groups and owned by organizations that sell cloud services.

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

[0666] Cloud computing environments are service-oriented, emphasizing statelessness, loose coupling, modularity, and semantic interoperability. The core of cloud computing is its infrastructure, which includes a network of interconnected nodes.

[0667] See now Figure 21 The diagram illustrates 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 personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 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 a 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, without requiring cloud consumers to maintain resources on their local computing devices. It should be understood that... Figure 21 The types of computing devices 54A-N shown are intended to be illustrative only, and computing node 52 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connectivity (e.g., using a web browser).

[0668] See now Figure 22 This demonstrates the 50 (cloud computing environment) Figure 21 This provides a set of functional abstractions. It should be understood beforehand that... Figure 22 The components, layers, and functions shown are intended to be illustrative only, and embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0669] 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; storage 65; and networking and interconnection components 66. In some embodiments, software components include network application server software 67 and database software 68.

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

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

[0672] Workload layer 90 provides examples of functionalities that can be leveraged in a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; transaction processing 95; and compression / decompression processing 96.

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

[0674] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital universal disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punched cards or raised structures in grooves with instructions recorded thereon), and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0675] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network) to an external computer or external storage device. The network may include copper transmission cables, optical fiber transmission, 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 these instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0676] The computer-readable program instructions used to perform the operations of this technical solution may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, as well as 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, as a standalone 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 via any type of network (including a local area network (LAN) or a wide area network (WAN)) or may be connected to an external computer (e.g., via the Internet provided by an Internet service provider). In some embodiments, electronic circuits (including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs)) may execute computer-readable program instructions using status information to personalize the electronic circuits in order to perform various aspects of this technical solution.

[0677] This technical solution is described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the technical solution. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0678] 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 apparatus to produce a machine, which executes via the processor of the computer or other programmable data processing apparatus, creating means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium capable of instructing a computer, a programmable data processing apparatus, and / or other devices that function in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

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

[0680] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to different embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or part of an instruction, including one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions marked in the blocks may occur in a different order than indicated in the figures. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0681] In addition to the above, one or more aspects may be provided, committed to, deployed, managed, serviced, etc., by a service provider that provides customer environment management. For example, a service provider may create, maintain, and 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 payments from consumers, for example, under subscription and / or fee agreements. Additionally or alternatively, the service provider may receive payments from the sale of advertising content to one or more third parties.

[0682] In one aspect, an application for performing one or more embodiments can be deployed. As an example, deploying the application includes providing computer infrastructure operable for performing one or more embodiments.

[0683] On the other hand, deployable computing infrastructure includes integrating computer-readable code into a computing system, wherein the code combined with the computing system is capable of executing one or more embodiments.

[0684] In another aspect, a process for integrating computing infrastructure can 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 integrated with the computer system is capable of executing one or more embodiments.

[0685] While various embodiments have been described above, these are merely examples. For instance, computing environments with other architectures can be used to include and utilize one or more embodiments. Furthermore, different instructions or operations can be used. Additionally, different registers can be used and / or other types of instructions (besides register numbers) can be specified. Many variations are possible.

[0686] Furthermore, other types of computing environments can benefit and can be used. As an example, a data processing system suitable for storing and / or executing program code is available, comprising at least two processors directly or indirectly coupled to memory elements via a system bus. Memory elements include, for example, local memory used during the actual execution of the program code, mass storage devices, and cache memory providing temporary storage for at least some of the program code to reduce the number of times code must be retrieved from mass storage devices during execution.

[0687] Input / output (I / O) devices (including but not limited to keyboards, monitors, pointing devices, DASDs, tapes, CDs, DVDs, thumb drives, and other storage media) can be coupled to the system directly or via an intermediate I / O controller. Network adapters can also be coupled to the system, enabling the data processing system to be coupled to other data processing systems or remote printers or storage devices via an intermediary private or public network. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.

[0688] 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 “comprising” and / or “including” are used in this specification, they specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0689] All means or steps in the following claims, plus the corresponding structures, materials, actions, and equivalents of functional elements (if any), are intended to include any structure, material, or action for performing the function in conjunction with other claimed elements as specifically claimed. Descriptions of one or more embodiments have been given for purposes of illustration and description, but are not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments have been chosen and described in a manner that best explains various aspects and practical application, enabling those skilled in the art to understand different embodiments with different modifications suited to the particular intended use.

Claims

1. A computer program product for facilitating processing in a computing environment, the computer program product comprising: Instructions for performing a method, the method comprising: The processor of the computing environment obtains instructions to execute one of a plurality of functions supported by the instructions, the instructions comprising a single architecture-based instruction set architecture conforming to compression industry standards; and Executing the instructions, the execution including: Execute the function specified by the instruction, wherein, based on whether the function is a compression function or a decompression function, the execution includes 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; During the execution of the function, access is made to the history of the function, which is to be used to transform the state of the input data between uncompressed and compressed forms; and The transformed data state is provided as output for use when performing tasks; The history is stored in a buffer specified by the instruction, which includes an opcode field and multiple register fields. The opcode field includes an opcode for specifying the operation, and the multiple register fields specify multiple registers to be used by the instruction. The multiple registers include a register for identifying the location of an output operand to be used as an output by the instruction and another register for identifying the location of an input operand to be used as an input by the instruction. Furthermore, the instruction uses a selected register to specify the location of the buffer in memory and another selected register to provide the address of a parameter block to be used by the instruction, the parameter block specifying an offset within the buffer that marks the beginning of the history within the buffer, and the instruction uses a selected register to specify the type of the buffer.

2. The computer program product according to claim 1, wherein, The processor is a general-purpose processor.

3. The computer program product according to claim 1, wherein, The state of the input data is transformed using a compression format that conforms to the industry standard.

4. The computer program product according to claim 1, wherein, The input depends on the function to be performed, wherein, based on the function being the compression function, the input includes data to be encoded in the input operand positions to provide compressed data symbols stored in the output operand positions and data to be copied from the input operand positions and stored in the buffer as history, and wherein, based on the function being the decompression function, the input includes compressed data symbols to be decoded in the input operand positions to provide uncompressed data stored in the output operand positions and stored in the buffer.

5. The computer program product according to claim 1, wherein, The parameter block further includes the length of the history within the buffer.

6. The computer program product according to claim 1, wherein, The type of the buffer is a circular buffer.

7. A computer system for facilitating processing in a computing environment, the computer system comprising: Memory; as well as A processor coupled to the memory, wherein the computer system is configured to perform a method comprising: The processor obtains instructions to perform one of a plurality of functions supported by the instructions, the instructions comprising a single architecture-based instruction set architecture conforming to compression industry standards; and Executing the instructions, the execution including: Execute the function specified by the instruction, wherein, based on whether the function is a compression function or a decompression function, the execution includes 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; During the execution of the function, access is made to the history of the function, which is to be used to transform the state of the input data between uncompressed and compressed forms; and The transformed data state is provided as output for use when performing tasks; The history is stored in a buffer specified by the instruction, which includes an opcode field and multiple register fields. The opcode field includes an opcode for specifying the operation, and the multiple register fields specify multiple registers to be used by the instruction. The multiple registers include a register for identifying the location of an output operand to be used as an output by the instruction and another register for identifying the location of an input operand to be used as an input by the instruction. Furthermore, the instruction uses a selected register to specify the location of the buffer in memory and another selected register to provide the address of a parameter block to be used by the instruction, the parameter block specifying an offset within the buffer that marks the beginning of the history within the buffer, and the instruction uses a selected register to specify the type of the buffer.

8. The computer system according to claim 7, wherein, The type of the buffer is a circular buffer.

9. A computer-implemented method for facilitating processing in a computing environment, the computer-implemented method comprising: The processor of the computing environment obtains instructions to perform one of a plurality of functions supported by the instructions, the instructions including a single architecture instruction for an instruction set architecture conforming to compression industry standards; and Executing the instructions, the execution including: Execute the function specified by the instruction, wherein, based on whether the function is a compression function or a decompression function, the execution includes 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; During the execution of the function, access is made to the history of the function, which is to be used to transform the state of the input data between uncompressed and compressed forms; and The transformed data state is provided as output for use when performing tasks; The history is stored in a buffer specified by the instruction, which includes an opcode field and multiple register fields. The opcode field includes an opcode for specifying the operation, and the multiple register fields specify multiple registers to be used by the instruction. The multiple registers include a register for identifying the location of an output operand to be used as an output by the instruction and another register for identifying the location of an input operand to be used as an input by the instruction. Furthermore, the instruction uses a selected register to specify the location of the buffer in memory and another selected register to provide the address of a parameter block to be used by the instruction, the parameter block specifying an offset within the buffer that marks the beginning of the history within the buffer, and the instruction uses a selected register to specify the type of the buffer.

10. The computer-implemented method according to claim 9, wherein, The type of the buffer is a circular buffer.

Images