Maintain compatibility for complex functions across multiple machine generations

Abstract

A system including multiple machines includes a first generation machine and a second generation machine. Each of the multiple machines includes a machine version. The first generation machine executes a first virtual machine and a virtual architecture level. The second generation machine executes a second virtual machine and a virtual architecture level. The virtual architecture level provides a compatibility level for complex interruptible instructions of the first virtual machine and the second virtual machine. The compatibility level is built for the lowest common denominator machine version across the multiple machines. The compatibility level includes a lowest common denominator indicator identifying the lowest common denominator machine version.

Description

Background Art

[0001] The present invention generally relates to maintaining compatibility of complex functions across multiple machine generations.

[0002] Regarding allowing workloads to migrate between machines of different machine generations, each machine needs to be able to continue work initiated by another machine. For example, when running in an environment where a system can migrate between different computers, there needs to be a common architectural level between these environments. For instructions with complex parameter block formats that can change between architectures, a machine needs to be able to use the common architectural level between these environments to create and consume each previously generated parameter block format. However, creating and consuming each previously generated parameter block format can cause implementation and verification complexities. For example, for complex instructions that may see different parameter block definitions across five generations, the latest generation machine needs to understand and generate five different parameter blocks. Summary of the Invention

[0003] According to an embodiment of the present invention, a system is provided that includes a plurality of machines. The plurality of machines includes a first generation machine and a second generation machine. Each of the plurality of machines includes a machine version. The first generation machine executes a first virtual machine and a virtual architecture level. The second generation machine executes a second virtual machine and a virtual architecture level. The virtual architecture level provides a compatibility level for complex interruptible instructions of the first virtual machine and the second virtual machine. A compatibility level is constructed for the lowest common denominator machine version across the plurality of machines. The compatibility level includes a lowest common denominator indicator that identifies the lowest common denominator machine version. The technical effects and benefits of the embodiments herein may include that when, for complex instructions / functions, each machine generation supports at most only two different parameter blocks (its own parameter block and the compatibility level), verification and validation are reduced to testing only the current and compatibility versions of the parameter blocks.

[0004] According to one or more embodiments of the present invention or the above system embodiment, the compatibility level includes a local parameter block format for complex interruptible instructions for each of the plurality of machines, and the local parameter block format is constructed for the machine version that is local to each of the plurality of machines.

[0005] According to one or more embodiments of the present invention or any of the above system embodiments, the lowest common denominator indicator is generated by the machine among the plurality of machines that first executes the complex interruptible instruction.

[0006] According to one or more embodiments of the present invention or any of the above system embodiments, the least common denominator indicator is propagated from the machines among a plurality of machines to first execute the complex interruptible instructions to the remaining number of the plurality of machines. The technical effects and benefits of the embodiments herein may include: for the first generation, its parameter block format represents the "origin" format and only one format needs to be supported / tested. Thus, the machine-specific parameter block content of any subsequent generation can be optimized for that machine without having a downstream impact on future machine generations.

[0007] According to one or more embodiments of the present invention or any of the above system embodiments, the least common denominator indicator within the compatibility level is controlled by a series of facility bits that identify which functions are available in a particular virtual machine.

[0008] According to one or more embodiments of the present invention or any of the above system embodiments, the complex interruptible instructions include DEFLATE transform call instructions.

[0009] According to one or more embodiments of the present invention or any of the above system embodiments, the complex interruptible instructions include instructions from a complex instruction set running on an accelerator.

[0010] According to one or more embodiments of the present invention, any of the above system embodiments can be implemented as a method or a computer program product.

[0011] According to one or more embodiments, a method is provided for a first machine to implement complex interruptible instructions and indicate a parameter block that supports the first machine for the complex interruptible instructions at the virtual architecture level. Moreover, the parameter block of the first machine is propagated to each virtual machine running in the complex. The technical effects and benefits of the embodiments herein may include reducing the verification and validation for testing the current and compatibility versions of the parameter block.

[0012] According to one or more embodiments of the present invention or any of the above method embodiments, the method may include: detecting a new machine going online; identifying the parameter block of the first machine as the least common denominator of the machine versions across the complex; and propagating the parameter block of the first machine to the new machine.

[0013] According to one or more embodiments of the present invention, any of the above method embodiments can be implemented as a system or a computer program product.

[0014] Additional technical features and benefits are realized through the technology of the present invention. Embodiments and aspects of the present invention are described in detail herein, and these embodiments and aspects are considered to be part of the claimed subject matter. For a better understanding, reference is made to the detailed description and the drawings. Description of the Drawings

[0015] The details of the exclusive rights described herein are particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other features and advantages of embodiments of the present invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0016] Figure 1A An example of a computing environment incorporating and using one or more aspects of the present invention is depicted;

[0017] Figure 1B Depicts further details of a Figure 1A processor in accordance with one or more aspects of the present invention;

[0018] Figure 2 Another example of a computing environment incorporating and using one or more aspects of the present invention is depicted;

[0019] Figure 3A Depicts a format of a DEFLATE transform call (DFLTCC) instruction in accordance with one aspect of the present invention;

[0020] Figure 3B Depicts an example of fields of an implicit register (general - purpose register 0) used by a DEFLATE transform call instruction in accordance with one aspect of the present invention;

[0021] Figure 3C Depicts an example of function code for a DEFLATE transform call instruction in accordance with one aspect of the present invention;

[0022] Figure 3D Depicts an example of fields of an implicit register (general - purpose register 1) used by a DEFLATE transform call instruction in accordance with one aspect of the present invention;

[0023] Figure 3E Describes an example of the content of register R1 specified by a DEFLATE transform call instruction in accordance with one aspect of the present invention;

[0024] Figure 3F Depicts an example of the content of register R1 + 1 used by a DEFLATE transform call instruction in accordance with one aspect of the present invention;

[0025] Figure 3G Depicts an example of the content of register R2 specified by a DEFLATE transform call instruction in accordance with one aspect of the present invention;

[0026] Figure 3H Depicts an example of the content of register R2 + 1 used by a DEFLATE transform call instruction in accordance with one aspect of the present invention;

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

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

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

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

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

[0032] Figures 5A - 5C Describes an example according to one aspect of the present invention showing how a sub-byte boundary is applied to the DFTLCC-CMPR function;

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

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

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

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

[0037] Figure 10 Depicts an example of a sample program that compresses data into three blocks of a compressed data set according to one aspect of the present invention;

[0038] Figure 11Describes an example of the content of a parameter block of a DFLTCC-CMPR function operating on a first compressed data block of a set;

[0039] Figure 12 Describes an example of the content of a parameter block of a DFLTCC-CMPR function operating on a second compressed data block of a set;

[0040] Figure 13 Depicts an example of a sample of a program for decompressing data from a compressed data set according to one aspect of the present invention;

[0041] Figures 14A - 14C Depicts examples of an online history buffer before and after performing DFLTCC-CMPR multiple times according to one aspect of the present invention;

[0042] Figures 15A - 15E Depicts examples of a loop history buffer before and after performing DFLTCC multiple times according to one aspect of the present invention;

[0043] Figures 16A - 16C Depicts examples of an online history buffer before and after performing DFLTCC-XPND multiple times according to one aspect of the present invention;

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

[0045] Figure 18 Depicts an instance of using a loop history buffer according to one aspect of the present invention;

[0046] Figure 19 Depicts a system according to an embodiment of the present invention;

[0047] Figure 20 Depicts a process flow according to an embodiment of the present invention;

[0048] Figure 21 Depicts a system according to an embodiment of the present invention; and

[0049] Figure 22 Depicts a processing system according to one or more embodiments.

[0050] The figures depicted herein are illustrative. Many variations to the figures or operations described herein can occur without departing from the spirit of the invention. For example, these actions can be performed in a different order, or actions can be added, deleted, or modified. Similarly, the term "coupled" and its variants describe having a communication path between two elements and do not imply a direct connection between these elements, without an intermediate element / connection between them. All such variations are considered to be part of the specification.

[0051] In the following detailed description of the drawings and the disclosed embodiments, the different elements shown in the drawings are equipped with two or three numerical reference numerals. In the case of minor exceptions, the leftmost digit of each reference number corresponds to the figure in which its element is first shown. Detailed Description

[0052] According to one or more embodiments, the present invention relates to a virtual architecture level that includes a compatibility level for complex interruptible instructions such that any virtual machine can utilize complex interruptible instructions. In this regard, the compatibility level is built for the lowest common denominator machine version among all virtual machines, where the lowest common denominator indicator identifies that machine version.

[0053] According to one aspect of the present invention, there is provided an ability to facilitate processing in a computing environment. As an example, a single instruction (e.g., a single architected hardware machine instruction at a hardware / software interface) is provided to perform a function (also referred to as an operation), such as a compression or decompression function, to compress and / or decompress (also referred to as uncompress) data. The instruction is part of a general-purpose processor instruction set architecture (ISA) dispatched by a program (e.g., an operating system or a user program) on a general-purpose processor. By performing compression / decompression via an ISA instruction, there is no need for the operating system to perform a task switch for compression / decompression operations, saving execution cycles. Further, by using a single instruction to compress and / or decompress data, the execution time within the processor (e.g., a general-purpose processor) is reduced.

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

[0055] See Figure 1ADescribe an embodiment of a computing environment incorporating and using one or more aspects of the present invention. Computing environment 100 includes, for example, a processor 102 (e.g., a central processing unit), a memory 104 (e.g., a main memory; also known as, system memory, main memory, central memory, memory), 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.

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

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

[0058] Refer to Figure 2 to describe another example of a computing environment for incorporating and using one or more aspects of the present invention. In one example, the computing environment is based on the z / Architecture hardware architecture; however, the computing environment may be based on other architectures provided by International Business Machines Corporation or other companies.

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

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

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

[0062] Memory 202 is coupled to a processor (e.g., a 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 logical processor representing all or a share of the physical processor resources 204 that can be dynamically allocated to the logical partition.

[0063] Further, memory 202 is coupled to an I / O subsystem 206. The I / O subsystem 206 can be part of or separate from the central electronics complex. It directs the flow of information between main memory 202 and the input / output control unit 230 and the input / output (I / O) devices 240 coupled to the central electronics complex.

[0064] Many types of I / O devices can be used. One particular 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 aspects of the present invention.

[0065] As an example, each processor 204 includes at least one cache 260 (e.g., a local cache) of a cache memory hierarchy, the cache memory hierarchy including multiple cache levels, 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, which is used to perform one or more of the compression and / or decompression of data (and / or other operations of one or more aspects of the present invention). In different instances, there can be one or more components performing these tasks. Many variations are possible.

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

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

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

[0069] Further, the central electronic complex 200 can operate with many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that can be applicable to the central electronic complex 200 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, and so on.

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

[0071] According to one aspect of the present invention, a computing environment such as computing environment 100 or central electronics 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 a mechanism for compressing and decompressing data using the DEFLATE compressed data format. In one example, the conversion facility is installed in the system when a facility indicator is set to, for example, one. As a particular instance of the z / Architecture hardware architecture, when the conversion facility is installed in z / Architecture architecture mode, facility bit 151 is set to (for example) one. The facility includes, for example, a DEFLATE conversion call instruction, an embodiment of which is described below.

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

[0073] In one example, the uncompressed data is a sequence of bytes, and the compressed representation of the data includes symbols. A symbol represents either a single byte of the uncompressed data, called a literal byte, or a sequence of repeated occurrences of bytes of the uncompressed data, called a repeat string. As an example, a Huffman table specifies the encoding and decoding between the compressed data symbols and the uncompressed data. There are two types of Huffman tables: a fixed-Huffman table (FHT), which is a predefined specification that includes, for example, all possible encodings; and a dynamic Huffman table (DHT), which is a set of encodings created specifically for the data to be compressed, which can be a subset of all possible encodings. The compressed representation of data generated with a DHT is typically smaller than the compressed representation of the same data generated with an FHT. A portion of the most recently processed uncompressed data (referred to as history) is maintained for encoding and decoding the compressed data symbols that represent repeat strings. The history is a reference source for repeat strings. The history is updated as data is processed during operation. As indicated, in one instance, the DEFLATE transform call instruction uses the DEFLATE compressed data format, which is described in RFC 1951, DEFLATE Compressed Data Format Specification Version 1.3. Attributes of the DEFLATE standard applied to the DEFLATE transform call instruction include, for example:

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

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

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

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

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

[0079] When a compressed data element occupies only a portion rather than all of a byte in storage, the entire byte in storage is accessed. The storage operand length specifies the number of addressable bytes, which can specify more bits than the bits occupied by the compressed data.

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

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

[0082] In one embodiment, a program (e.g., an operating system or a user program) may execute the DEFLATE Transform Call instruction multiple times to compress or decompress a single data stream. For example, when applying compression or decompression to a large data stream (e.g., greater than 1M bytes), the operation may include multiple calls to compress or decompress a buffered portion of the data stream. According to one aspect of the present invention, the program declares a buffer (e.g., a 32K-byte buffer) that is used to accumulate the history of uncompressed data processed during operations spanning multiple executions of the DEFLATE Transform Call instruction. The buffer is referred to as a circular history buffer and is defined using the DEFLATE Transform Call instruction as described herein.

[0083] See Figure 3A , in one example, the format of the DEFLATE Transform Call (DFLTCC) instruction 300 is the RRF format representing a register and register operation with an extended opcode (opcode) field and additional register fields. As an example, the instruction includes: an opcode field 302 (e.g., bits 0 - 15) that has an opcode indicating a DEFLATE Transform Call operation; a first register field (R1) 304 (e.g., bits 24 - 27) 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 content of the register specified by the R1 field 304 specifies the location (in storage) of the first operand; the content of the register specified by the R2 field 306 specifies the location of the second operand (in storage); and the content of the R3 field 308 specifies the location of the third operand (in the storage device). The content of R1 + 1 specifies the length of the first operand, and the content of R2 + 1 specifies the length of the second operand. In one instance, bits 20 to 23 of the instruction are reserved and should contain zeros; otherwise, the program may operate incompatibly in the future. As used herein, a program is a program that issues the DEFLATE Transform Call instruction. It can be a user program, an operating system, or another type of program.

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

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

[0086] Example assigned function codes for DEFLATE transform call instructions are shown in Figure 3C and include, 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 (Compress) function; and function code 4 (319) indicating the DFLTCC - XPND (Expand) function. Each code uses a parameter block, and in one instance, the size of the parameter block depends on the function. For example, for the DFLTCC - QAF function, the parameter block is 32 bytes; for the DFLTCC - GDHT function, the parameter block is 384 bytes; for the DFLTCC - CMPR and DFLTCC - XPND functions, the parameter block is 1536 bytes. In this instance, no other function codes are assigned. Although example functions and function codes are described, other functions and / or function codes may be used.

[0087] When the specified function is DFLTCC-CMPR or DFLTCC-XPND, bit 56 of general register 0 specifies the history buffer type (HBT) to be used during the operation. When HBT is zero, the history buffer is called the online history buffer. When using the online history buffer, when DFLTCC-CMPR is specified, the history is, for example, immediately to the left of the second operand, and when 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 the circular history buffer. When using the circular history buffer, when DFLTCC-CMPR or DFLTCC-XPND is specified, the history is part or all of the third operand. When the DFLTCC-QAF or DFLTCC-GDHT functions are specified, bit 56 of general register 0 is ignored. In one instance, bits 0 through 31 of general register 0 are ignored. Further, in one instance, bits 32 through 55 of general register 0 are preserved and shall contain zeros; otherwise, the program may operate incompatibly in the future.

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

[0089] For the specified functions (e.g., DFLTCC-QAF, DFLTCC-GDHT, DFLTCC-CMPR, DFLTCC-XPND), the contents of general registers 0, 1, and R3 are not modified. Further, in one instance, the R1 field 304 specifies the parity pair of general registers. An even register is specified, not general register 0; otherwise, a specification exception is recognized.

[0090] As Figures 3E - 3FAs depicted and further described herein, the content of general register R1 318 indicates the first operand address 320, and the content of general 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 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 register R1+1, together with the value of the sub-byte boundary (SBB) field of the new task (NT) and parameter block (described below), specifies the length of the first operand. The following table provides an example of a function that illustrates the length of the first operand of the DFLTCC-CMPR function as the content of general register R1+1, the NT field, and the SBB field:

[0091]

[0092] When the specified function is DFLTCC-XPND, the content of general register R1+1 specifies the length of the first operand. When the specified function is DFLTCC-CMPR or DFLTCC-XPND, the result of data compression or decompression is stored at the first operand location. When the DFLTCC-QAF or DFLTCC-GDHT functions are specified, the content of general registers R1 and R1+1 is ignored.

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

[0094] As Figures 3G - 3HAs depicted and described in further detail herein, the contents of general register R2 326 indicate the second operand address 328, and the contents of general register R2+1 330 are 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 contents of general register R2 specify the logical address of the leftmost byte of the second operand. When the specified function is DFLTCC-CMPR or DFLTCC-GDHT, the contents of general register R2+1 specify the length of the second operand. When the specified function is DFLTCC-XPND, the contents of general register R2+1, together with the values of the NT field and the SBB field of the parameter block, specify the length of the second operand. When the second operand length is referenced and has a non-zero value at the start of the execution of the instruction, data is retrieved from the second operand location. When the second operand length is referenced and has a value of 0 at the start of the execution of the instruction, and the continue flag (CF) field of the parameter block is 1 at the start of the execution of the instruction, the second operand is not accessed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0115] Further details regarding different functions are described below:

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

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

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

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

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

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

[0122] When applicable, PER (Program Event Record) storage change events are identified for the parameter block. When applicable, PER zero address detection events are identified for the parameter block.

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

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

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

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

[0127] Additionally, in one instance, the parameter block includes one or more reserved fields and one or more reserved fields. The DFLTCC-GDHT function does not modify the reserved fields. The reserved fields are distinguished from the 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. The reserved fields contain zeros; otherwise, the program may not operate compatibly in the future. When the operation ends, the reserved fields may be stored as zeros or may remain unchanged.

[0128] Furthermore, some fields are used by other functions (e.g., DFLTCC-CMPR or DFLTCC-XPND), and thus, aspects related to these functions can also be described along with the description of these fields. In one instance, the parameter block 360 for 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. Bytes 0-11 of the PBVN are reserved and shall contain zeros; otherwise, the program may not operate compatibly in the future. Bytes 12-15 of the PBVN contain an unsigned binary integer that specifies the format of the parameter block. The DFLTCC-QAF function provides a mechanism to indicate the available parameter block formats. When the format of the specified parameter block is not supported by the model, a general operand data exception is recognized. The PBVN is specified by the program and is not modified during the execution of the instruction.

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

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

[0132] Meaning of DHTGC

[0133] 0 Treat counts of literal bytes, repeat string lengths, and pointer distances equal to zero as equal to 1 (generate a general DHT).

[0134] 1 Treat counts of repeat string lengths and pointer distances equal to zero as equal to one.

[0135] The DHT that specifies the Huffman codes for each possible value of literal bytes, EOB symbols, copy string lengths, and copy string pointer distances is called the general DHT. The DHT that does not specify the Huffman codes for the values of literal bytes, repeat string lengths, or repeat string pointer distances that occur in the uncompressed form of the data is called a non-general DHT.

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

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

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

[0139]

[0140]

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

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

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

[0144] When the DFLTCC-CMPR function is specified and the Huffman Table Type (e.g.,

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

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

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

[0148] The DHT specifies Huffman codes (byte sequences) to represent two sets of elements. The elements of one set include literal bytes, the EOB symbol, and repeat string lengths. The elements of the other set include repeat string pointer distances. The compressed representation of the DHT defines a set of code lengths and specifies the code length (CL) for each element of each set. The Huffman code for 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:

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

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

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

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

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

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

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

[0156] In one example, the compressed representation of the DHT is kept aligned in the CDHT field. 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.

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

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

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

[0160] When the CDHT is modified, the bits of the fields not used to represent the compressed representation of the DHT are stored as zeros.

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

[0162] Aspects of DHT generation are specified to the machine by a program using the dynamic Huffman table generation control (DHTGC) field 364 of the parameter block. The given source contains uncompressed data, and after the operation is completed, the DFLTCC-CMPR function is specified to compress the same source with the resulting output.

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

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

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

[0166] · For locations beyond the first 32K bytes of the second operand, access exceptions are not recognized.

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

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

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

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

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

[0172] The condition code 0 is set when the execution of the DFLTCC - GDHT function is complete; condition codes 1, 2, and 3 do not apply to the DFLTCC - GDHT function.

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

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

[0175] When applicable, the PER zero - address detection event is recognized as the second operand location and the parameter block.

[0176] Function code 2: DFLTCC - CMPR (Compress)

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

[0178] In one instance, the DFLTCC - CMPR function uses the parameter block, refer to Figure 3L the instance that describes the parameter block. Some fields have been described above regarding the parameter block 360, and thus the same reference numbers are listed below and not described in further detail.

[0179] In one instance, the parameter block 370 contains:

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

[0181] Model Version Number (MVN) 363.

[0182] Continue flag (CF) 373: Bit 63 of the parameter block (when 1) indicates that the operation part is completed, and the content of the continue status buffer (e.g., in continue status buffer field 392) can be used to resume the operation. The program initializes the continue flag (CF) to zero and does not modify CF in the case of re-executing an instruction for the purpose of resuming the operation; otherwise the result is unpredictable.

[0183] New task (NT) 374: Bit 0 of byte 16 of the parameter block indicates at 1 that the operation applies to the start of a compressed data set. Therefore, no history and check values from a previous operation apply to the current operation. When NT is 1 at the start of an operation and the operation ends after partial completion, zero is stored into the NT field. When NT is zero, history and check values from a previous operation apply to the current operation.

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

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

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

[0187] Block Close Control (BCC) 378: When the DFLTCC-CMPR function is specified, bit 6 of byte 16 of the application parameter block is applied. When it is 1 after storing all compressed data symbols, the End of Block (EOB) symbol is stored to the first operand location. When HTT is specified using FHT, as an example, the Huffman code 0000000 binary (which corresponds to the middle integer representation of 256 in the table of codes specified for literal bytes, EOB symbols, and repeat string lengths) is used for the EOB symbol. When HTT is specified using 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 to the first operand location. The BCC bit is not modified during the execution of the instruction.

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

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

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

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

[0192] Further, Figures 5A - 5CExamples are provided showing how SBB is applied to the DFLTCC-CMPR function. For example, in Figure 5A an example of how SBB is applied before and after performing the DFLTCC-CMPR function is depicted. In Figures 5B - 5C other examples are depicted. When NT374 is 1, SBB381 is considered equal to 000 binary.

[0193] Return Figure 3L , describing additional fields of parameter block 370:

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

[0195] Incomplete Function Status (IFS) 383: When certain operations end, bits 4-7 of byte 21 of the parameter block contain status information. At the end of the decompression operation, IFS passes the following information about the second operand, in one example:

[0196]

[0197] In one embodiment, the decompression operation can end with an IFS equal to 0000 binary and not meet normal completion. In such a case, the operation ends with condition code 1 or 3 set.

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

[0199] IFS is not an input to the operation.

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

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

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

[0203] The IFL is not an input to the operation.

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

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

[0206] 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 equals the sum of the original HL and the number of uncompressed data bytes processed during the operation; otherwise, the updated HL equals the value of 32,768.

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

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

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

[0210] The input for generating the check value is, for example, a 4-byte base and processes the uncompressed data during operation. The basic input provides a means for calculating a single and consistent check value for a set of compressed data blocks, regardless of the number of times the DFLTCC instruction is executed to process the complete set of compressed data blocks. When the NT bit is 0, the original value in the check value field is used as the basic input for generating the check value.

[0211] In one example, when generating an Adler-32 check value, the following applies:

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

[0213] · The sum defined in the Adler-32 check value generation is modulo 65,521.

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

[0215] In one embodiment, when a CRC-32 check value is generated, the following applies:

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

[0217] · The polynomial used as the divisor when generating the CRC-32 check value is x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x1 + x0, represented as 104C11DB7 in hexadecimal. In this representation, the leftmost bit corresponds to the most significant bit.

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

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

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

[0221] End-of-Block Symbol (EOBS) 388: Fifteen bytes starting from byte 0 of byte 52 to byte 6 of byte 53 of the parameter block contain the End-of-Block (EOB) symbol. The End-of-Block Length (EOBL) field 389 of the parameter block specifies the length of the EOB symbol in the EOBS field. The EOB symbol is left-aligned in the EOBS field. Bytes in the EOBS field not occupied by the EOB symbol are stored as zero. The EOBS field is the output of the operation when compressing data, regardless of which type of Huffman table is applied. The EOBS field is not used as an input to the operation.

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

[0223] For blocks using FHT, the EOB symbol is the 0000000 binary defined by the DEFLATE standard. For blocks using 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.

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

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

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

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

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

[0229] Continuous State Buffer (CSB) 392: When conditions cause the value 1 to be stored in the CF field 373, the internal state data is stored into bytes 384 - 1535 of the parameter block; otherwise, bytes 384 - 1535 of the parameter block are undefined and may be modified. The stored internal state data is model-dependent and 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. After an instruction ends with a non-zero set of condition codes and before re-executing the instruction for the purpose of recovery operations, the program should not modify the continuation state buffer; otherwise the results are unpredictable.

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

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

[0232] Normal completion of the DFLTCC - CCMPR function occurs when the entire second operand has been compressed and stored into the first operand location. When the operation ends due to normal completion, in one instance, the following occurs: · Model-dependent values are stored into the Model Version Number (MVN) field 363 of the parameter block.

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

[0234] · The Sub-Byte Boundary (SBB) field 381 of the parameter block is updated.

[0235] · The End-of-Block Length (EOBL) 389 and End-of-Block Symbol (EOBS) 388 fields of the parameter block are updated.

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

[0237] · The History Offset (HO) field 386 of the parameter block is updated when applicable.

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

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

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

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

[0242] · Set condition code 0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0257] · Set condition code 3.

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

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

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

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

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

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

[0264] · The length of the first operand becomes equal to zero during the execution of the instruction and normal completion does not occur.

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

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

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

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

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

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

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

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

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

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

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

[0276] · The address increment in general register R1 includes the number of bytes for processing the first operand that handles bit 0, and the length decrement in general register R1+1 is the same number. The number of bytes for processing the first operand that handles bit 0 is the integer quotient generated by integer division, where the divisor is the sum of the number of output bits being processed and the original value of SBB, and the divisor is the value 8.

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

[0278] · Set condition code 1.

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

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

[0281] · Set condition code 1.

[0282] After the instruction ends with condition code 1 set, it is expected that the program modifies the first operand length, the first operand address, or both, and re-executes the instruction to resume the operation.

[0283] When applicable, the PER storage change event is identified as follows:

[0284] · Stored into the parameter block, as described below.

[0285] · Stored into the first operand location.

[0286] · Stored into the third operand location, which occurs, for example, when the history buffer type (HBT) is one (circular).

[0287] When the entire parameter block overlaps with the PER storage area specification, when applicable, the PER storage change event is identified for the parameter block. When only a part of the parameter block overlaps with the PER storage area specification, which of the following occurs is model-dependent:

[0288] · The PER storage change event is identified when applicable to the parameter block.

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

[0290] When applicable, for the parameter block, when HBT is 1 (loop), the PER zero address detection event, the first operand position, the second operand position, and the third operand position are recognized.

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

[0292] When the instruction ends by setting condition code 1 or 3, the input data referenced from the second operand position can be processed completely or only partially. When the input data is only partially processed, it causes the first operand position, the first operand address, the first operand length, and the SBB field of the parameter block not to represent a state consistent with the updated second operand address and length. In these cases, the partially processed data and the 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 the model existing at the end of the operation. Although some data may only be partially processed, the result stored to the left of the location specified by the updated first operand address is complete and will not be modified when the operation resumes. Additionally, it is expected that the program will subsequently re - execute the instruction to resume the operation, at which time the content of the CSB field is referenced before resuming the operation. When the instruction ends by setting condition code 0, all data is processed completely, and all results associated with the input and output data represent a consistent state.

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

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

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

[0296] In one example, the DFLTCC - XPND function uses the parameter block, an example of which was described above Figures 3K - 3L as described for the parameter block.

[0297] An instance of the DFLTCC - XPND operation is described below with respect to the decompressed data.

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

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

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

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

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

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

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

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

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

[0307] · The number of bytes whose addresses are incremented and stored in the first operand location is stored in general register R1, and the length is decremented by the same number in general register R1+1.

[0308] · The number of bytes whose addresses are incremented and which contain the processing of the second operand for handling bit 0 is stored in general register R2, and the length is decremented by the same number in general register R2+1. The number of bytes for the processing of the second operand including handling bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of input bits being processed and the original value of the SBB, and the divisor is the value 8.

[0309] · Condition code 0 is set.

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

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

[0312] When the CPU determines that the number of bytes has been processed, the operation ends and the following occurs, in one embodiment:

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

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

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

[0316] · 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 10 binary, the bytes representing the CDHT fields that indicate the table is not needed are stored as zero. When partial completion occurs while processing a block with a BTYPE value of 00 or 01 binary, zeros are stored into the CDHT and CDHTL fields.

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

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

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

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

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

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

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

[0324] · The number of bytes whose addresses are incremented in general - purpose register R1 is stored at the first operand position, and the length is decremented by the same number in general - purpose register R1 + 1.

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

[0326] · Set condition code 3.

[0327] The formation and update of addresses and lengths depend on the addressing mode.

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

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

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

[0331] The second operand length is not sufficient to complete the operation when applying operations such as:

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

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

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

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

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

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

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

[0339] · When applicable, the history offset (H0) field 386 in the parameter block is updated.

[0340] · The check value field 387 of the parameter block is updated.

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

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

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

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

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

[0346] · The number of bytes whose addresses are incremented in the general register R2 is for processing the second operand including handling bit 0, and the length in the general register R2+1 is decremented by the same number. The number of bytes for processing the second operand including handling bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of input bits being processed and the original value of SBB, and the divisor is the value 8.

[0347] · Set the condition code 2.

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

[0349] After the instruction ends with the condition code 2 set, it is expected that the program modifies the second operand length, the second operand address, or both, and re-executes the instruction to resume the operation.

[0350] When applying the following operations, the length of the first operand is insufficient to complete the operation, for example:

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

[0352] When the length of the first operand is insufficient to complete the operation, the operation has been partially completed, the operation ends, and in one embodiment the following occurs:

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

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

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

[0356] · 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 10 binary, the bytes representing the CDHT fields that are not required for the table are stored as zero. When partial completion occurs while processing a block with a BTYPE value of 00 or 01 binary, zeros are stored into the CDHT and CDHTL fields.

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

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

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

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

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

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

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

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

[0365] · The number of bytes whose addresses are incremented in the general register R2 includes the processing of the second operand for handling bit 0, and the length is decremented by the same number in the general register R2+1. The number of bytes for the processing of the second operand including the handling of bit 0 is the integer quotient obtained from integer division, where the divisor is the sum of the number of input bits being processed and the original value of SBB, and the divisor is the value 8.

[0366] · Set condition code 1.

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

[0368] After the instruction ends with condition code 1 set, it is expected that the program modifies the first operand length, the first operand address, or both, and re-executes the instruction to resume the operation.

[0369] When applicable, the PER storage change event is recognized as follows:

[0370] · As described herein, store to the parameter block.

[0371] · Store to the first operand location.

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

[0373] In one instance, when the entire parameter block overlaps with the PER storage area designation, when applicable, identify the PER storage change event for the parameter block. In one embodiment, when only a portion of the parameter block overlaps with the PER storage area designation, one of the following occurs model - independently:

[0374] · The PER storage change event is identified when applicable to the parameter block.

[0375] · When applicable, the PER storage change event is identified for the portion of the parameter block being stored.

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

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

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

[0379] Compressed data block

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

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

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

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

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

[0385] · When the BTYPE is 00 binary (which is bits 0 - 1 of byte 0 in this example), the bits to the left of the BTYPE and to the right of the byte boundary are ignored.

[0386] · The third element encountered in the bit stream is the least significant byte (LSB) of the LEN field, followed by the most significant byte (MSB) of the LEN field. The LEN field specifies the number of bytes in a block with literal data. For example, the original data is uncompressed data. The bytes with literal data follow the NLEN field in the bit stream. NLEN is the complementary sequence of LEN. In one example, bytes 1 - 2 contain the LEN field in little - endian order.

[0387] · The elements encountered in the byte stream after the LEN field are, respectively, the least significant byte of the NLEN field, followed by the most significant byte of the NLEN field. Bytes 3 to 4 contain the NLEN field in little - endian order. The NLEN field is the one's complement of the LEN field.

[0388] · The elements encountered in the byte stream after the NLEN field are the uncompressed data, identified as literal bytes. Bytes 5 to 7 contain the uncompressed data, which is unchanged from the source data used to generate this block.

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

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

[0391] · The compressed data block 700 consists of a byte stream 702 that starts with bit 4 of byte 0, identified as b0, and ends with bit 3 of byte 11, identified as b89.

[0392] · The first element encountered in the bitstream is BFINAL in bit 4 of byte 0.

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

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

[0395] · The third element encountered in the bitstream is the first compressed data symbol, which starts in bit 1 of byte 0. In one example, the compressed data symbol consists of the following sub - elements encountered in the order in which they are listed, in the order encountered in the bitstream:

[0396] 1. A variable - length Huffman code. The most significant bit of the code specifies the length of the code. The code is encountered in the byte stream, starting with the most significant bit of the code and ending with the least significant bit of the code. When the code represents a literal value or a block - end symbol, the code is the only sub - element of the compressed data symbol. When the code represents the length of a pointer to the history buffer, the code is followed by the subsequent sub - elements of the compressed data symbol.

[0397] 2. When applicable, as specified by the DEFLATE standard, additional length bits may follow the Huffman code representing the pointer length. The additional length bits are encountered in the bitstream, starting with the least significant bit of the additional length bits and ending with the most significant bit.

[0398] 3. The next sub - element encountered in the bitstream is a 5 - bit distance code for the pointer to the history buffer. The distance code is encountered in the byte stream, starting with, for example, the most significant bit of the code and ending with the least significant bit of the code.

[0399] 4. When applicable, as specified by the DEFLATE standard, additional distance bits may follow the distance code. When the additional distance bits are encountered in the bit stream, the additional distance bits start from the least significant bit of the additional distance bits and end with the most significant bit of the additional distance bits.

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

[0401] · The last element encountered in the bit stream is the compressed data symbol that contains a single subelement, which is the Huffman code representing the end-of-block (EOB) symbol. The EOB symbol for a block with BTYPE 01 binary is 0000000 binary. In this 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.

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

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

[0404] · The compressed data block 800 consists of a byte stream 802 that starts with bit 4 of byte 0, identified as b0, and ends with bit 3 of byte 11, identified as b89.

[0405] · The first element encountered in the bit stream is BFINAL in bit 4 of byte 0.

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

[0407] · The third element encountered in the bit stream is the compressed representation of the dynamic Huffman table (DHT), which starts in bit 1 of byte 0. The compressed representation of the DHT includes the following subelements, which, in one example, are encountered in the bit stream in the order they are listed:

[0408] 1. HLIT: The sum of a 5-bit HLIT sub-element and 257 specifies the number of Huffman codes representing literal byte amounts, EOB symbols, and repeat string lengths. The valid values of HLIT range from, for example, 0 to 29. The HLIT bits are encountered in the bit stream starting from the least significant bit of the HLIT sub-element and ending with the most significant bit. In this example, bit 1 of byte 0 (identified as b3) is the least significant bit of the HLIT sub-element.

[0409] 2. HDIST: The sum of a 5-bit HDIST sub-element and 1 specifies the number of Huffman codes representing the copy string pointer distance. The valid values of HDIST range from, for example, 0 to 29. The HDIST bits are encountered in the bit stream starting from the least significant bit of the HDIST sub-element and ending with the most significant bit.

[0410] 3. HCLEN: The sum of a 4-bit HCLEN sub-element and 4 specifies the number of Huffman codes representing code lengths. The valid values of HCLEN are, for example, 0 to 15. The HCLEN bits are encountered in the bit stream starting from the least significant bit of the HCLEN sub-element and ending with the most significant bit.

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

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

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

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

[0415] · The fourth element encountered in the bit stream is the first compressed data symbol. In one embodiment, the compressed data symbol consists of the following sub-elements, which are encountered in the bit stream in the order listed:

[0416] 1. Variable - length Huffman codes. The most significant bit of the code specifies the length of the code. When the code is encountered in a byte stream, it starts with the most significant bit of the code and ends with the least significant bit of the code. When the code represents a literal value or an end - of - block symbol, the code is the sole subelement of the compressed data symbol. When the code represents the length of a pointer to a history buffer, the code is followed by the subsequent subelements of the compressed data symbol.

[0417] 2. When applicable, as specified by the DEFLATE standard, additional length bits may follow the Huffman code representing the pointer length. When the additional length byte is encountered in the byte stream, it starts with, for example, the least significant byte and ends with the most significant byte of the additional length byte.

[0418] 3. The next subelement encountered in the bit stream is a 5 - bit distance code for a pointer to the history buffer. When the distance code is encountered in the byte stream, the distance code starts with, for example, the most significant bit of the code and ends with the least significant bit of the code.

[0419] 4. When applicable, as specified by the DEFLATE standard, additional distance bits may follow the distance code. When the additional distance bits are encountered in the bit stream, they start with, for example, the least significant bit of the additional distance bits and end with the most significant bit.

[0420] · The subsequent bits (up to and including, for example, bit 5 of byte 10) encountered in the bit stream contain the bits of the compressed data symbol.

[0421] · The last element encountered in the bit stream is a compressed data symbol containing a single subelement, which is a Huffman code representing an end - of - block (EOB) symbol. In this instance, 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.

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

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

[0424] Processing a Compressed Data Set

[0425] Examples are provided for processing a compressed data set to illustrate the example usage of DEFLATE transform call instructions and the description of different fields of an enhancement parameter block. The examples do not describe all possible scenarios, requirements, and capabilities, but illustrate different scenarios, requirements, and / or capabilities. The examples and descriptions apply, for example, to a compressed data set in a storage device, the example of which is in Figure 9is shown. As shown, the compressed data set 900 includes a plurality of compressed data blocks 902, and the start of the data set 900 is indicated by a Compressed Data Set Beginning Address (CDSBA) 904.

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

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

[0428] · Individual check values apply, for example, to all uncompressed data represented by the compressed data set.

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

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

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

[0432] In addition, referring to Figure 13 , an example of a portion of a sample program 1300 for decompressing data from a Figure 9 compressed data set is depicted.

[0433] Compressed data

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

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

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

[0437] 2. Block type (BTYPE).

[0438] 3. Compressed format of the dynamic Huffman table, when applicable.

[0439] 4. Compressed data symbols.

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

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

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

[0443] Uncompressed data from the second operand location is compressed and stored as a compressed data symbol into the first operand location.

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

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

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

[0447] · In one embodiment, the program does not use the DEFLATE transform call instruction to perform the following operations: · Generate an empty compressed data block. The empty compressed data block consists of, for example, a block header, the compressed format of the DHT (when applicable), and an EOB symbol.

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

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

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

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

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

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

[0454] During the compression operation, the history is updated. After encoding one or more bytes of source data 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 (up to 32K bytes) of the source data constitute the updated history that can be used for reference while processing subsequent bytes of the source data.

[0455] When the compression operation ends, in one example, the following applies to the resulting history that can be used for subsequent recovery operations or to start another operation:

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

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

[0458] As an example, Figures 14A - 14C illustrates the position of the online history relative to the second operand before and after multiple executions of a DEFLATE transform call instruction with a specified DFLTCC-CMPR function and a specified online history (e.g., bit 310 = 0) when each execution ends in a partially completed state. For example, Figure 14A depicts the online history before DFLTCC-CMPR execution number 1; Figure 14B depicts the online history before DFLTCC-CMPR execution number 2 and after execution number 1; and Figure 14C depicts the online history after DFLTCC-CMPR execution number 2. Figure 14C The explanations provided in Figure 14A also apply to 14B .

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

[0460] HE = R3 + modulo 32K (HO + HL - 1)

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

[0462] As an example, Figures 15A - 15E illustrates the position of the history within the cyclic history buffer before and after multiple executions of the DEFLATE transform call instruction with a specified DFLTCC-CMPR function and a specified cyclic history buffer (bit 310 = 1) when each execution ends in a partial completion. For example, Figure 15A depicts the cyclic history buffer before DFLTCC execution number 1; Figure 15B depicts the cyclic buffer before DFLTCC execution number 2 and after execution number 1; Figure 15C depicts the cyclic buffer before DFLTCC execution number 3 and after execution number 2; Figure 15D depicts the cyclic buffer before DFLTCC execution number 4 and after execution number 3; and Figure 15E depicts the cyclic buffer after DFLTCC execution number 4. Figure 15E The explanations provided in Figures 15A - 15D .

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

[0464] · Store the byte range in the third operand position. The byte range includes, for example, the positions specified below and starts from the positions specified below:

[0465] R3 + modulo 32K(HOO + HLO), where

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

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

[0468] The byte range contains, for example, the positions specified by the following and ends at the positions specified by the following:

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

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

[0471] As an example, the storage of the byte ranges just described is subject to a storage type access exception, a PER storage change event, and a set change bit.

[0472] · Stores that do not modify the contents of the storage location and that are not mandatory can be made to bytes in the third operand location that are not included in the ranges just described. Stores to these locations are also subject to a storage type access exception, a PER storage change event, and a set change bit.

[0473] When HBT is looped and the number of bytes processed from the second operand location is greater than or equal to, for example, 32,768, all bytes of the third operand location are stored and are subject to a storage type access exception, a PER storage change event, and a set change bit.

[0474] When the block continue flag (BCF) 377 is 0, a 3-bit block header (including BFINAL, followed by BTYPE) is stored to the first operand location. The BFINAL byte of the block header is set equal to the block header final byte (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, and when HTT is 1, the BTYPE field of the block header is set to, for example, binary 10. When storing the block header, the BFINAL bit is stored to the bit specified by SBB in the first byte of the first operand. Subsequently, the BTYPE is stored to the first operand location. When BCF is 1, the block header is not stored.

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

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

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

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

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

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

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

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

[0483] · The model-related values are stored into the model version number (MVN) field 363 of the parameter block.

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

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

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

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

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

[0489] Consistent with the compressed source data, the source data is the input for generating the 32-bit check value as described above. The resulting check value is stored into the check value field 387 of the parameter block.

[0490] Decompressed data

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

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

[0493] The extended functionality includes an updated history that references the most recently decoded uncompressed data. In one embodiment, prior to the start or resumption of a decompression operation, the following applies:

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

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

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

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

[0498] During the decompression operation, the history is updated. After decoding the source data without encountering a general operand data exception condition, the resulting byte string of the uncompressed data is concatenated to the end of the history. The most recently decoded bytes of the uncompressed data up to a maximum of, for example, 32K bytes constitute the updated history available for reference when processing subsequent source data.

[0499] In one instance, when the decompression operation ends, the following applies to the resulting history available for subsequent resume operations or the start of another operation:

[0500] · When HBT is online, the storage update to the first operand position also constitutes an update to the resulting history. The updated first operand address and the updated HL specify the updated position and updated length of the resulting history.

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

[0502] As an example, Figures 16A - 16CShows an example of the position of the online history buffer relative to the first operand before and after multiple executions of a DEFLATE transform call instruction with a specified DFLTCC-XPND function and a specified online history, when each execution ends in a partial completion. The history length (HL) 385 is modified during operation. For example, Figure 16A Depicts an instance of the online history before DFLTCC-XPND execution number 1; Figure 16B Depicts an example of the online history before DFLTCC-XPND execution number 2 and after execution number 1; and Figure 16C Depicts an example of the online history after DFLTCC-XPND execution number 2. Figure 16C The explanations provided in Figures 16A - 16B .

[0503] When the HBT specified by bit 56 of general register 0 is cyclic, the history is maintained in a 32K-byte 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 content of general register R3 and the history offset (HO) 386. The first byte of the history is the least recently processed byte of the uncompressed data in the buffer. The position of the last byte of the history within the buffer (HE) is specified by, for example, the following equation:

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

[0505] The last byte of the history is the most recently processed byte of the uncompressed data in the buffer. When the sum of the history offset (H0) and the history length (HL) exceeds the size of the third operand (e.g., 32K bytes), the history wraps around from the end of the third operand to the beginning of the third operand. The Figures 15A - 15E Shows an example of the position of the history within the cyclic history buffer before and after multiple executions of a DEFLATE transform call instruction with a specified DFLTCC-XPND function and a cyclic history buffer, when each execution ends in a partial completion.

[0506] In one instance, when the HBT is cyclic and the number of bytes stored to the first operand position is less than, for example, 32,768, the following applies:

[0507] · Store to a range of bytes in the third operand position. The range of bytes includes and starts from the position specified by the following:

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

[0509] HO0: The history offset before instruction execution.

[0510] HLO: Historical length before instruction execution.

[0511] The byte range includes and ends at positions specified, for example, by

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

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

[0514] The store to the byte range just described is subject to a store - type access exception, a PER store change event, and a set change bit.

[0515] · Stores can be made to bytes in the third operand position that are not included in the range just described, without modifying the contents of the storage location and not being required. Stores to these positions are also subject to a store - type access exception, a PER store change event, and a set change bit.

[0516] When HBT is a loop and the number of bytes stored to the first operand position is greater than or equal to, for example, 32,768, all bytes of, for example, the third operand position are stored and are subject to a store - type access exception, a PER store change event, and a set change bit.

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

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

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

[0520] The updated history is applicable to decoding the next symbol of the block. When an EOB symbol is encountered, processing of the block is complete.

[0521] When BTYPE is the binary value 10, the block contains compressed data symbols generated using a dynamic Huffman table (DHT). The compressed format of the DHT used is an element of the compressed data block. An example Figure 8 showing a block with BTYPE equal to the binary value 10 is presented. After interpreting the block header, the compressed format of the DHT provided within the compressed data block is examined for general operand data anomalies. When there is a general operand data anomaly in the compressed format of the provided DHT, the compressed format of the DHT is said to be invalid and is not used to decompress the data. When the compressed format of the DHT specifies a byte length for a code length, or the code length for a literal byte, the EOB symbol, the repeat string length, or the copy string pointer distance that is greater than the length required for a Huffman tree that is appropriate and functional for the Huffman algorithm, the compressed DHT is still used to derive the functional DHT and the compressed data. After examining the compressed format of the DHT, the compressed data symbols are decoded in the order in which they appear in the block. For example, the bytes of the block are processed from left to right, and for example, the bits within each byte of the block are processed from right to left. In one example, each symbol is fully processed before processing the next symbol in the block. The processing of symbols in a block with BTYPE equal to the binary value 10 is the same as the processing previously described for processing symbols in a block with BTYPE 01, 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-general DHT is provided (which does not specify the Huffman codes to be used for decoding the compressed data symbols), a general operand data anomaly is identified.

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

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

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

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

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

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

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

[0529] When the first operand length is zero at the start of the execution of the instruction, the first operand is not accessed, and the first operand address and the first operand length in general registers R1 and R1+1 respectively do not change. This applies when the value of the CF field 373 is zero or one at the start of the execution of the instruction.

[0530] When the second operand length is zero at the start of the execution of the instruction, the second operand is not accessed, and the second operand address and the second operand length in general registers R2 and R2+1 respectively do not change. In one embodiment, the second operand length is zero at the start of the execution of the instruction for the following cases:

[0531] · The instruction is re-executed (e.g., the CF field 373 of the parameter block is 1 at the start of the execution of the instruction),

[0532] and the entire second operand was processed when the instruction was previously executed.

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

[0534] · Block header.

[0535] · LEN field of a block with block type 00 binary.

[0536] · NLEN field of a block with block type 00 binary.

[0537] · Compressed format of the dynamic Huffman table.

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

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

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

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

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

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

[0544] · NT374 is zero and HL385 is greater than, for example, 32768.

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

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

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

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

[0549] · HTT 376 is 1, and the compressed format of the DHT (content of the CDHT field 367) specifies a code that is in the code sequence for the byte lengths specified for use, for example, for the 19 possible code lengths defined for the compressed DHT, and is less than the length required for the Huffman algorithm to specify the functional Huffman tree (invalid DHT).

[0550] · HTT 376 is 1 and the compression format of the DHT (content of CDHT field 367) specifies the code length (e.g., 16 (copying the previous code length)) as the first code length for the set of elements consisting of literal bytes, EOB symbols, and repeat string lengths (invalid DHT).

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

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

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

[0554] · HTT376 is 1, and the compression format of the DHT (content of CDHT field 367) specifies a number of code lengths greater than the number of Huffman codes in the DHT, as specified by the sum of the HLIT field, HDIST field, and a value such as 258. As an example (invalid DHT), this is possible in the case of incorrect use of code lengths 16, 17, and 18.

[0555] · HTT376 is one and the compression format of the DHT (content of CDHT field 367) specifies the code lengths for the set of literal bytes, EOB symbols, and repeat string lengths that are less than the lengths required to specify a functional Huffman tree by the Huffman algorithm (invalid DHT).

[0556] · HTT376 is 1, and the compression format of the DHT (content of CDHT field 367) specifies the code lengths for the set of copy string pointer distances that are less than the lengths required to specify a functional Huffman tree by the Huffman algorithm (invalid DHT).

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

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

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

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

[0561] · NT374 is zero and HL385 is greater than, for example, 32768.

[0562] · A compressed data block with BTYPE equal to binary 11 is encountered.

[0563] · A compressed data block with BTYPE equal to binary 00 and the 1's complement of NLEN not equal to LEN is encountered.

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

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

[0566] · A compressed format of the DHT (content of a compressed data block with BTYPE equal to binary 10) is encountered, which specifies a code in a code sequence that specifies a bit length, for example, one of the 19 possible code lengths defined for the compressed DHT, and is less than the length required for the Huffman algorithm to specify the functional Huffman tree (invalid DHT).

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

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

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

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

[0571] · Encounter a compressed format of DHT (content of a compressed data block with BTYPE equal to 10 binary) that specifies a number of code lengths greater than the number of Huffman codes in the DHT, as specified by the sum of the HLIT field, HDIST field, and a value such as 258. For example (invalid DHT), this may incorrectly use code lengths 16, 17, and 18.

[0572] · Encounter a compressed format of DHT (content of a compressed data block with BTYPE equal to 10 binary) that specifies the code lengths for the literal byte set, EOB symbol, and repeat string lengths, which are less than the lengths required by the Huffman algorithm to specify a functional Huffman tree (invalid DHT).

[0573] · Encounter a compressed format of DHT (content of a compressed data block with BTYPE equal to 10 binary) that specifies the code lengths for the set of copy string pointer distances, which are less than the lengths required by the Huffman algorithm to specify a functional Huffman tree (invalid DHT).

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

[0575] · Encounter a compressed data symbol that is a copy string pointer and specifies a distance greater than the length of the history available at the point where the symbol is being processed.

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

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

[0578] When the DFLTCC-CMPR or DFLTCC-XPND function is being executed and a general operand data exception is recognized due to the second operand, the result is that the exception is recognized, or the operation ends partially completed and with a condition code (e.g., 3 is set). If condition code 3 is set, the exception will be recognized when the instruction is executed again to continue processing the same operand and the exception condition still exists.

[0579] Other conditions include, for example:

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

[0581] When the DFLTCC-CMPR or DFLTCC-XPND function is being executed and an access exception is recognized due to the first or second operand, the result is that the exception is recognized, or the operation ends partially completed and with a condition code (e.g., 3 is set). If condition code 3 is set, the exception will be recognized when the instruction is executed again to continue processing the same operand and the exception condition still exists.

[0582] As observed by this CPU, other CPUs, and the channel program, the references to the parameter block, the first, second, and third operands may be multi-access references, the accesses to these storage locations are not necessarily parallel blocks, and the sequence of these accesses or references is undefined.

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

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

[0585] · The first operand overlaps with the second operand.

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

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

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

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

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

[0591] 0 Normal completion

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

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

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

[0595] Program exception:

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

[0597] · Data with DXC 0, general operand

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

[0599] ·Specification

[0600] ·Transaction constraint

[0601] An example priority for the execution of the DEFLATE CONVERSION CALL instruction is as follows:

[0602] 1. - 6. Exceptions with the same priority as the program interruption conditions for general cases.

[0603] 7. A access exception for the second instruction halfword.

[0604] 7. B operation exception.

[0605] 7. C transaction limit.

[0606] 8. A specification exception attributed to an invalid function code or an invalid register number.

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

[0608] 8. C specification exception due to the loop history buffer not being specified on a 4K byte boundary.

[0609] 9. Access exception for accessing the parameter block.

[0610] 10. General operand data exception when the specified format of the parameter block is not supported by the mode.

[0611] 11. Specification exception due to the second operand length being equal to zero and CF being equal to zero at the start of the instruction execution.

[0612] 12. Condition code 1 due to the first operand length being equal to zero and specifying DFLTCC - CMPR at the start of the instruction execution.

[0613] 13. A general operand data exception when, when specifying DFLTCC - CMPR or DFLTCC - XPND, the history length field is greater than 32,768 and the new task field is zero.

[0614] 13. B Access exception for accessing the first operand, and the first operand length is non - zero. 13. C Exception for accessing the second operand, and the second operand length is non - zero.

[0615] 13. D Access exception for accessing the online history specified at the start of the instruction execution.

[0616] 13. E Access exception for accessing the third operand.

[0617] 14.A General operand data exception due to conditions other than those included in items 10 and 13.A above.

[0618] 14.B Condition code 1, 2, or 3 due to conditions other than those included in item 12 above.

[0619] 15. Condition code 0.

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

[0621] The following provides example programming notes:

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

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

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

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

[0626] 5. When the operation ends in 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 instruction to resume the operation.

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

[0628] 7. When the DFLTCC-GDHT function is specified, according to the Huffman algorithm, the compressed representation of the generated DHT describes three appropriate 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, and the DHT specifies the code lengths of elements greater than the length required for the Huffman tree specified by the appropriate and function of the Huffman algorithm.

[0629] When the DFLTCC-CMPR function is specified, HTT is 1, and the compressed representation of the DHT includes a description of the underflow Huffman code tree. The compressed data result is converted to the original uncompressed data using the DFLTCC-XPND function, but not all decoders compliant with the DEFLATE standard are able to convert the result to the original uncompressed data. For example, this may occur when the compressed representation of the DHT specified by the program of the DFLTCC-CMPR function is not generated due to the execution of the DFLTCC-GDHT function.

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

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

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

[0633] Although different fields and registers are described, one or more aspects of the present 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.

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

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

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

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

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

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

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

[0641] Next, the instruction calling for a DEFLATE transform is executed (step 1808). Based on the executed instruction, the processor extracts history from, e.g., a circular history buffer as input to the operation (step 1820), and performs the designated operation (step 1822), as described herein. Further, the processor modifies the history in the circular history buffer as output of the operation (step 1824). A determination is made as to whether the entire data stream has been processed, query 1826. If not, processing continues to step 1804. Otherwise, processing is complete.

[0642] The use of the circular history buffer provides the following, as an example:

[0643] When the size of the input or output buffer is designated for an individual execution of an instruction calling for a DEFLATE transform and is relatively small (e.g., 512 bytes), the history spans multiple segments of the buffered data, up to e.g., 32K bytes available as input to the instruction calling for a DEFLATE transform, which processes a small number of bytes.

[0644] When the size of the input or output buffer is designated for an individual execution of an instruction calling for a DEFLATE transform and is relatively large (e.g., 128K bytes), it is the history of prior segments of the buffered data, up to e.g., 32K bytes available as input to the instruction calling for a DEFLATE transform for the data being processed in the previous 32K bytes.

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

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

[0647] When referring to one or more aspects of the present invention, refer to Figures 19 - 22 for further details describing one or more embodiments.

[0648] Turning now to an overview of the technology more specifically related to aspects of the present invention, DEFLATE is an algorithm for compressing data that can be several gigabytes (GB) in size, where a single application may have only a small buffer and the compression must be done in relatively small chunks, which can be 1 megabyte (MB) or less. DEFLATE can generally refer to a complex instruction set running on an accelerator or NXU, which can be attached to a chip-level coherent subsystem (e.g., L3 cache) with an input / output (I / O) interface similar to that used for direct memory access (DMA). From an architectural perspective, DEFLATE needs to follow certain main rules

[0649] Further, complex interruptible instructions are instructions that have a state that needs to be saved (e.g., DEFLATE; DEFLATE transform call instruction; instructions from a complex instruction set running on an accelerator), such that the instruction can be restarted after the interrupt has been serviced. Note that the state can be any state that it needs to implement the restart, providing that it meets specific formatting requirements (e.g., parameter block format). The specific formatting requirements can be micro-architected specifically for the original machine model. Further, when introducing a new machine model with the same complex interruptible instructions, the state of the same complex interruptible instructions is micro-architected specifically for the new machine model. From a software perspective, the region of the state is opaque because it can only be understood by the machine model for which it was created. Thus, after introducing a new machine model, the computing environment includes two machines executing the same complex interruptible instructions with two different parameter block formats (e.g., the original machine model and the new machine).

[0650] For instructions with complex functions and parameter blocks, a new virtual architecture level (VAL) approach is taken according to one or more embodiments herein. That is, in different complex computing environments, VAL is used to handle migration systems such that all instructions support all inputs from any lower machine level by leveraging indicators (within VAL) set to the lowest common machine level for all virtual machines. Thus, one or more embodiments of the present invention address the above drawbacks by maintaining compatibility of complex functions across multiple machine generations (e.g., between the original machine model and the new machine in a computing environment). Further, one or more embodiments herein define a compatibility level between generations, which requires that each machine only understand two different parameter block formats. To this end, each machine implements its own level of instructions and parameter blocks as well as the lowest common denominator.

[0651] Figure 19FIG. 1900 depicts a system 1900 in accordance with an embodiment of the present invention. The system 1900 includes a machine version (n) 1910 that supports a virtual machine 1920 having a compatibility level 1929, which includes an assembler version n 1930 therein. The assembler version n 1930 includes an indicator for the lowest common denominator for all machine versions (e.g., lowest common denominator indicator 1931).

[0652] The system 1900 further includes a machine version (n + 1) 1940 that supports a virtual machine 1950 having a compatibility level 1959, which includes a resolution lock version n 1930 and a resolution lock version n + 1 1960 therein. The system 1900 further includes a machine version (n + 2) 1970 that supports a virtual machine 1980 having a compatibility level 1989, which includes a parmblock version n 1930 and a parmblock version n + 2 1990 therein. The lowest common denominator indicator 1931 within the compatibility levels 1929, 1959, and 1989 is controlled by a series of facility bits that identify which functions are available in a particular virtual machine 1920, 1950, and 1980.

[0653] Note that "n" is a generated designation; further, if n = 0, then the machine version 1910 is the first generation machine, the machine version 1940 is the second generation machine, and the machine version 1970 is the third generation machine. The machine versions 1910, 1940, and 1970 can be any device that includes a hardware / software combination that supports one or more virtual machines (e.g., virtual machines 1920, 1950, and 1980). For example, each of the machine versions 1910, 1940, and 1970 can be equivalent to Figure 22 an instance of the system 2200.

[0654] Typically, because the operating system can migrate between the virtual machines 1920, 1950, and 1980, each virtual machine 1920, 1950, and 1980 must have the same VAL. Having the same VAL means that if a complex (e.g., system 1900; Figure 2 of the CEC 200) has a machine version 1910 (e.g., first generation machine) and a machine version 1940 (e.g., second generation machine) and the virtual machine 1950 is moving from the first generation machine to the second generation machine, the virtual machine 1950 can execute first generation machine instructions once it has moved. Note that second generation machine instructions will not work on the first generation machine. Also note that the first and second generation machine instructions can be complex interruptible instructions (e.g., DEFLATE transform call instructions or instructions from a complex instruction set running on an accelerator) that respectively meet the specific formatting requirements of the first and second generation machines.

[0655] System 1900 maintains compatibility levels 1929, 1959, and 1989 for complex interruptible instructions within the VAL for each virtual machine 1920, 1950, and 1980. Each compatibility level 1929, 1959, and 1989 is constructed for the lowest common denominator machine version for cross-machine versions 1910, 1940, and 1970 and for the local parameter block format for complex interruptible instructions. Note that the local parameter block format is constructed for the local machine version for each of the machine versions 1910, 1940, and 1970. In this regard, virtual machine 1920 supports the parameter block format that can be executed on machine version 1910 (since this is the earliest version); virtual machine 1940 supports the parameter block format that can be executed on machine version 1910 (lowest common denominator) and machine version 1950 (local); and virtual machine 1970 supports the parameter block format that can be executed on machine version 1910 (lowest common denominator) and machine version 1980 (local). More specifically, since version n is the lowest common denominator, the grouped lock version n 1930 is replicated in each compatibility level 1929, 1959, and 1989 on each virtual machine 1920, 1950, and 1980.

[0656] According to one or more embodiments, the compatibility levels 1929, 1959, and 1989 can be generated by the machines in the machine versions 1910, 1940, and 1970 to execute the corresponding complex interruptible instructions. Further, the lowest common denominator indicator 1931 can be generated by the machines in the machine versions 1910, 1940, and 1970 to first execute the corresponding complex interruptible instructions. The VAL utilizes the compatibility level 1929 to carry the lowest common denominator indicator 1931 such that the grouped lock version n 1930 is replicated when generating the subsequent compatibility levels 1959 and 1989. The lowest common denominator indicator 1931 can be associated with the shown grouped block version n 1930 or can be a separate part of the compatibility level 1929 itself. According to one or more embodiments, the lowest common denominator indicator and / or the compatibility level can be propagated from the machines in the machine versions 1910, 1940, and 1970 that first execute the complex interruptible instructions to the remaining number of the machine versions 1910, 1940, and 1970.

[0657] Figure 20 Process flow 2000 in accordance with an embodiment of the present invention is depicted. Figure 21Illustrates system 2100 according to an embodiment of the present invention. System 2100 initially depicts machines having machine versions n, n - 1, and n - 2 (2110, 2140, and 2170 respectively), each machine version implementing a different parameter block format (parse lock version n 2130, parse lock version n - 1 2160, and parse lock version n - 2 2190 respectively). According to one or more embodiments, each parameter block 2130, 2160, and 2190 may be stored separately within machine versions n, n - 1, and n - 2 (2110, 2140, and 2170 respectively).

[0658] Process flow 2000 may be executed by system 2100. Process flow 2000 begins at block 2010, where the machine at level n - 2 (2170) is the first machine implementing complex interruptible instructions (e.g., DEFLATE; DEFLATE transform call instruction; instructions from a complex instruction set running on the accelerator of machine 2170). At block 2020, the virtual architecture level of system 2100 indicates, via the least common denominator indicator 2191, the parameter block for the execution / support of the complex interruptible instructions for the first machine (e.g., assembler version n - 2 2190). The grouped lock version n - 2 2190 format may be referred to as the compatibility level or origin format

[0659] At block 2030, the assembler version n - 2 2190 format with the least common denominator indicator 2191 is propagated to each virtual machine currently running in system 2100. As Figure 21 shown by the B arrow in, the combined version n - 2 2190 format is shared with virtual machines 2120 and 2150. Now, both virtual machines 2120 and 2150 executing at machine levels n and n - 1 can implement complex interruptible instructions with the parse lock version n - 2 2190 format. Additionally, virtual machine 2120 executing at machine level n can implement complex interruptible instructions corresponding to the parse lock version n 2130 format, and virtual machine 2150 executing at machine level n - 1 can implement complex interruptible instructions corresponding to the parse lock version n - 1 2160 format.

[0660] At block 2040, system 2100 detects that the first machine is offline. As Figure 21 shown by X in, the machine at level n - 2 (2170) is offline. At block 2050, system 2100 detects that a new machine is online. For example, the machine at level n + 1 (2191) comes online. At block 2060, system 2100 identifies the parameter block of the first machine as the least common denominator across machine versions.

[0661] At block 2070, system 2100 propagates the parameter block of the first machine to the new machine. As Figure 21As shown, system 2100 now includes a machine with machine version n+1 (2191), which implements a parameter block format (combination lock version n+1 2193). As Figure 21 shown by the D arrow in, it shares the combination version n-2 2190 format with virtual machine 2192. Thus, when migrating any virtual machine, it uses the n-2 level of functions.

[0662] The technical effects and benefits of the embodiments herein include: When, for complex instructions / functions, each machine generates at most only two different parameter blocks (its own parameter block and compatibility level) to support, verification and validation are reduced to testing against the current and compatibility versions of the parameter blocks. The technical effects and benefits of the embodiments herein further include that, for the first generation, its parameter block format represents the "origin" format and only one format needs to be supported / tested. Thus, the machine-specific parameter block content of any subsequent generation can be optimized for that machine without having a downstream impact on future machine generations.

[0663] Now turning to Figure 22 , system 2200 for implementing the teachings herein is shown in accordance with one or more embodiments of the present invention. In this embodiment, system 2200 has a processor 2201, which may include one or more central processing units (CPUs) 2201a, 2201b, 2201c, etc.

[0664] Processor 2201 (also referred to as processing circuitry, microprocessor, computing unit) is coupled to system memory 2203 and different other components via system bus 2202. System memory 2203 includes read-only memory (ROM) 2204 and random access memory (RAM) 2205. ROM 2204 is coupled to system bus 2202 and may include a basic input / output system (BIOS), which controls certain basic functions of system 2200. RAM is a read-write memory coupled to system bus 2202 for use by processor 2201.

[0665] Figure 22 System 2200 of includes a hard disk 2207, which is an example of a readable tangible storage medium executable by processor 2201. Hard disk 2207 stores software 2208 and data 2209. Software 2208 is stored as instructions (to execute processes, such as Figures 21 - 22 process flows 2100, 2200) to be executed by processor 2201 on system 2200. Data 2209 includes a set of values of qualitative or quantitative variables organized in different data structures to support the operation of software 2208 and used by the operation of software 2208.

[0666] Figure 22System 2200 includes one or more adapters (e.g., hard disk controllers, network adapters, graphics adapters, etc.) that interconnect and support communication between processor 2201, system memory 2203, hard disk 2207, and other components of system 2200 (e.g., peripheral devices and external devices). In one or more embodiments of the present invention, one or more adapters may be connected to one or more I / O buses that are connected to system bus 2202 via an intermediate bus bridge, and the one or more I / O buses may utilize a common protocol, such as Peripheral Component Interconnect (PCI).

[0667] As shown, system 2200 includes interface adapter 2220 that interconnects keyboard 2221, mouse 2222, speaker 2223, and microphone 2224 to system bus 2202. System 2200 includes display adapter 2230 that interconnects system bus 2202 with display 2231. Display adapter 2230 (and / or processor 2201) may include a graphics controller to provide graphics performance, such as the display and management of GUI 2232. Communication adapter 2241 interconnects system bus 2202 with network 2250, enabling system 2200 to communicate with other systems, devices, data, and software (such as server 2251 and database 2252). In one or more embodiments of the present invention, the operation of software 2208 and data 2209 may be implemented by server 2251 and database 2252 over network 2250. For example, network 2250, server 2251, and database 2252 may be combined to provide internal iterations of software 2208 and data 2209, as Platform as a Service, Software as a Service, and / or Infrastructure as a Service (e.g., as a web application in a distributed system).

[0668] Thus, as Figure 22 configured, the operation of software 2208 and data 2209 (e.g., system 2200) must be rooted in the computing power of processor 2201 and / or server 2251 to overcome and address the disadvantages described herein of the contemporary migration of workloads between different machines. In this regard, software 2208 and data 2209 improve the computing operation of processor 2201 and / or server 2251 of system 2200 by maintaining compatibility of complex functions across multiple machine generations (thereby reducing verification and validation and optimizing the content of any subsequent machine-specific parameter blocks without creating downstream impacts).

[0669] The different embodiments of the present invention are described herein with reference to the related drawings. Alternative embodiments of the present invention may be designed without departing from the scope of the present invention. Various connection and positional relationships (e.g., above, below, adjacent, etc.) are set forth between the elements in the following description and the drawings. Unless otherwise stated, these connection and / or positional relationships may be direct or indirect, and the present invention is not limited in this regard by the schematic diagrams. Thus, the coupling of entities may refer to direct or indirect coupling, and the positional relationship between entities may be direct or indirect positional relationship. In addition, the various tasks and process steps described herein may be incorporated into a more comprehensive program or process having additional steps or functions not detailed herein.

[0670] The following definitions and abbreviations are used to explain the claims and the specification. As used herein, the terms "comprises", "comprising", "includes", "including", "has", "having", "contains" or "containing" or any other variant thereof are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

[0671] In addition, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" can be understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "plurality" can be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connected" may include both indirect "connection" and direct "connection".

[0672] The terms "about", "substantially", "approximately" and their variants are intended to include the degree of error associated with the measurement of a specific quantity based on the available equipment at the time of filing the present application. For example, "about" may include a range of ±8% or 5%, or 2% of a given value.

[0673] For the sake of brevity, conventional techniques related to making and using various aspects of the present invention may or may not be described in detail herein. Specifically, different aspects of the computing systems and specific computer programs for implementing the different technical features described herein are well known. Thus, for the sake of brevity, many conventional implementation details are only briefly mentioned herein or completely omitted without providing well-known system and / or process details.

[0674] The present invention can be a system, method, and / or computer program product at any possible level of integrated technical detail. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to execute aspects of the present invention. A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punched card, or a raised structure in a groove having instructions recorded thereon), and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[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 to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network may include a copper transmission cable, an optical transmission fiber, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

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

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

[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 that, when executed by the processor of the computer or other programmable data processing apparatus, creates a means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0679] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices that cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more blocks of the 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 various embodiments of the present invention. Accordingly, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0681] The description of the various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein were chosen to best explain the principles of the embodiments, the practical application, or technical improvement over technologies found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments described herein.

Claims

1. A system for maintaining compatibility of complex functions across multiple machine generations, comprising: Multiple machines, including a first generation machine, a second generation machine, and a third generation machine, each of the multiple machines including a machine version, the first generation machine, the second generation machine, and the third generation machine each containing a different machine version, the first generation machine executing a first virtual machine and a virtual architecture level, the second generation machine executing a second virtual machine and the virtual architecture level, the third generation machine executing a third virtual machine and the virtual architecture level, wherein, The virtual architecture level provides a compatibility level for complex interruptible instructions of the first virtual machine, the second virtual machine, and the third virtual machine; The compatibility level is built for the lowest common denominator machine version among the multiple machines; The compatibility level includes a lowest common denominator indicator identifying the lowest common denominator machine version; The complex interruptible instruction has a state that needs to be saved and conforms to a parameter block format; The compatibility level includes a parameter block format associated with the lowest common denominator indicator; The compatibility level includes a local parameter block format for the complex interruptible instruction for each of the multiple machines, the local parameter block format being architected for the machine version local to each of the multiple machines; The lowest common denominator indicator is generated by a machine among the multiple machines to first execute the complex interruptible instruction; The lowest common denominator indicator is propagated from the machine among the multiple machines that first executes the complex interruptible instruction to the remaining number of the multiple machines.

2. The system according to claim 1, wherein The lowest common denominator indicator within the compatibility level is controlled by a series of facility bits identifying which functions are available in a particular virtual machine.

3. The system according to claim 1, wherein the complex interruptible instruction includes a DEFLATE transform call instruction.

4. The system according to claim 1, wherein, The complex interruptible instruction includes an instruction from a complex instruction set running on an accelerator.

5. A method for maintaining compatibility of complex functions across multiple machine generations, comprising: Executing, by a first generation machine among the multiple machines, a first virtual machine and a virtual architecture level, the multiple machines including the first generation machine, a second generation machine, and a third generation machine, each of the multiple machines including a different machine version; Executing, by the second generation machine, a second virtual machine and the virtual architecture level; Executing, by the third generation machine, a third virtual machine and the virtual architecture level; and Providing, by the virtual architecture level, a compatibility level of complex interruptible instructions to the first, second, and third virtual machines, wherein, The compatibility level is architected for the lowest common denominator machine version among the multiple machines; The compatibility level includes a lowest common denominator indicator identifying the lowest common denominator machine version; The complex interruptible instruction has a state that needs to be saved and conforms to a parameter block format; The compatibility level includes a parameter block format associated with the lowest common denominator indicator; The compatibility level includes a local parameter block format for the complex interruptible instructions for each of the plurality of machines, the local parameter block format being architected for the machine version local to each of the plurality of machines; The least common denominator indicator is generated by a machine among the plurality of machines to first execute the complex interruptible instruction; The least common denominator indicator is propagated from a machine among the plurality of machines to first execute the complex interruptible instruction to the remaining number of the plurality of machines.

6. The method according to claim 5, wherein, The least common denominator indicator within the compatibility level is controlled by a series of facility bits that identify which functions are available in a particular virtual machine.

7. The method according to claim 5, wherein The complex interruptible instruction includes a DEFLATE transform call instruction.

8. The method according to claim 5, wherein The complex interruptible instruction includes an instruction from a complex instruction set running on an accelerator.

9. A computer program product, the computer program product including program instructions executable to cause operations including: A first virtual machine and a virtual architecture level are executed by a first generating machine among a plurality of machines, the plurality of machines including the first generating machine, a second generating machine, and a third generating machine, each of the plurality of machines including a different machine version; A second virtual machine and the virtual architecture level are executed by the second generating machine; A third virtual machine and the virtual architecture level are executed by the third generating machine; and The virtual architecture level provides a compatibility level of complex interruptible instructions to the first, second, and third virtual machines, wherein, The compatibility level is architected for the least common denominator machine version among the plurality of machines; The compatibility level includes a least common denominator indicator that identifies the least common denominator machine version; The complex interruptible instruction has a state that needs to be saved and conforms to a parameter block format; The compatibility level includes a parameter block format associated with the least common denominator indicator; The compatibility level includes a local parameter block format for the complex interruptible instructions for each of the plurality of machines, the local parameter block format being constructed for the machine version local to each of the plurality of machines; The least common denominator indicator is generated by a machine among the plurality of machines to first execute the complex interruptible instruction; The least common denominator indicator is propagated from a machine among the plurality of machines to first execute the complex interruptible instruction to the remaining number of the plurality of machines.

10. The computer program product according to claim 9, wherein, The least common denominator indicator within the compatibility level is controlled by a series of facility bits that identify which functions are available in a particular virtual machine.

11. The computer program product according to claim 9, wherein, The complex interruptible instruction includes a DEFLATE transform call instruction.

12. The computer program product according to claim 9, wherein, The complex interruptible instruction includes an instruction from a complex instruction set running on an accelerator.

Images