JP7481073B2 - メモリ境界の収容のためのオーバーフロー管理方法、システム、プログラム - Google Patents

メモリ境界の収容のためのオーバーフロー管理方法、システム、プログラム Download PDF

Info

Publication number
JP7481073B2
JP7481073B2 JP2021545748A JP2021545748A JP7481073B2 JP 7481073 B2 JP7481073 B2 JP 7481073B2 JP 2021545748 A JP2021545748 A JP 2021545748A JP 2021545748 A JP2021545748 A JP 2021545748A JP 7481073 B2 JP7481073 B2 JP 7481073B2
Authority
JP
Japan
Prior art keywords
source
buffer
accelerator
operand
block
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021545748A
Other languages
English (en)
Other versions
JPWO2020174033A5 (ja
JP2022521465A (ja
Inventor
クルプ、ギリシュ、ゴパラ
クライン、マティアス
ソフィア、アントニー、トーマス
ブラッドベリー、ジョナサン
ミシュラ、アシュトシュ
ジャコビ、クリスチャン
バッタチャージー、ディーパンカー
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2022521465A publication Critical patent/JP2022521465A/ja
Publication of JPWO2020174033A5 publication Critical patent/JPWO2020174033A5/ja
Application granted granted Critical
Publication of JP7481073B2 publication Critical patent/JP7481073B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/4031—Fixed length to variable length coding
    • H03M7/4037—Prefix coding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30025—Format conversion instructions, e.g. Floating-Point to Integer, decimal conversion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Executing Machine-Instructions (AREA)
  • Table Devices Or Equipment (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、一般に、メモリ・ユニットの管理に関連しており、より詳細には、オーバーフローの状況におけるメイン・バッファおよびオーバーフロー・バッファの管理に関連している。
コンピューティング・システムは、多くの場合、データのサイズを変更するデータ変換動作を使用する。例えば、データ圧縮手法を使用して、大きいデータ・ファイルのサイズを縮小し、データ復元手法を使用して、元の大きいデータ・ファイルを復元することができる。例えば、コンピューティング・システムは、外部ソースから受信された数ギガバイト（ＧＢ）のファイルを圧縮することがある。しかし、圧縮を実行するアプリケーションは、より小さいサイズ（例えば、１メガバイト（ＭＢ））のバッファにしかアクセスできないことがあり、そのためアプリケーションは、大きいデータ・ファイル内の少量のデータしか、同時に読み取ること、または書き込むことができない。そのような場合、アプリケーションは、ファイル全体を一度に圧縮するのではなく、大きいファイルを任意の小さいサイズのブロックに分割し、各ブロックを個別に圧縮する必要がある。ブロックのサイズおよびアライメントは、使用可能なバッファ空間の特性であり、多くのＧＢのサイズで単一のストリームを表すことがある入力の構造と、通常は一致しない。
機械可読のレベルでは、データ・ファイルの内容は一連のシンボルである。本明細書において使用されるとき、「シンボル」という用語は、ビット・シーケンスの分割されない単位、およびデータ変換動作（例えば、圧縮動作／復元動作）において使用される、その対応部分のことを指す。「対応部分」の意味は、本明細書において後で説明される。一般に、個別の変換手法（例えば、圧縮手法／復元手法）は、ビット・シーケンスをそれらの意味にマッピングするテーブルを有する。例えば、テーブルが、文字「ａ」を表すとして「１０１００」を定義している場合、分割された部分「１０」および「１００」の各々が、文字「ａ」を表すために使用されず、異なる意味を表すために使用されることがあるため、ビット・シーケンス「１０１００」はシンボルである。この場合、シンボルの長さは５ビットである。しかし、多くの種類のシンボルが存在しており、シンボルの長さは、シンボルの種類に応じて変わる。例えば、圧縮データ・ファイルでは、ハフマン・コーディング・アルゴリズムによって生成された動的ハフマン・ツリー（ＤＨＴ：Dynamic Huffman Tree）を含む圧縮ヘッダーは、ＤＨＴを表す長いシーケンスの部分が失われた場合に、後に続く圧縮データをデコードできないため、シンボルになることができる。このヘッダーの最大サイズは、約２８８バイトである。
メイン・バッファの使用可能な空間が次のシンボルのサイズより短い（例えば、２８０バイトが残っているが、次のシンボルの長さが２８８バイトである）場合、従来のシステムでは、２つの選択肢がある。１つの選択肢は、残りの空間をシンボルの一部（例えば、最初の２８０バイト）で埋め、シンボルの他の残りの部分（例えば、最後の８バイト）を破棄することである。しかし、データの破棄は、処理において重大なエラーを引き起こすことがある。２番目の選択肢は、メイン・バッファの残りの空間を埋めずに、すでに格納されているシンボルのみを使用して変換動作を実行することである。これは、メモリ空間の浪費をもたらす可能性がある。場合によっては、アプリケーションのバッファの使用において、シンボルが完全に収まらない場合でも、使用可能なバッファ空間を完全に埋めることが必要になることがある。そのような環境では、コンピューティング・システムがオーバーフローの状況を管理する必要がある。
したがって、当技術分野において、前述の問題に対処する必要がある。
第１の態様から見ると、本発明は、処理ユニットと、アクセラレータと、外部ソースから受信されたソース・シンボルの第１の部分を格納するように構成されたメイン・ソース・バッファ（main source buffer）と、アクセラレータから受信された出力シンボルを格納するように構成されたメイン・ターゲット・バッファ（main target buffer）と、オーバーフロー・ソース・バッファ（overflow source buffer）を含むメモリ・ブロックとを備えているシステムを提供し、オーバーフロー・ソース・バッファが、メイン・ソース・バッファから受信されたソース・シンボルの第１の部分を格納するように構成され、アクセラレータが、オーバーフロー・ソース・バッファに格納されたソース・シンボルの第１の部分およびメイン・ソース・バッファに格納されたソース・シンボルの第２の部分をフェッチし、ソース・シンボルの第１および第２の部分を一緒に出力シンボルに変換する変換動作を実行するように構成され、ソース・シンボルの第２の部分が、ソース・シンボルの第１の部分に含まれていないソース・シンボルの部分を含み、処理ユニットが、アクセラレータを呼び出して変換動作を実行するように構成される。
さらに別の態様から見ると、本発明は、処理ユニットと、アクセラレータと、外部ソースから受信されたソース・シンボルを格納するように構成されたメイン・ソース・バッファと、アクセラレータから受信された出力シンボルの第１の部分を格納するように構成されたメイン・ターゲット・バッファと、オーバーフロー・ターゲット・バッファ（overflow target buffer）を含むメモリ・ブロックとを備えているシステムを提供し、オーバーフロー・ターゲット・バッファが、アクセラレータから受信された出力シンボルの第２の部分を格納するように構成され、出力シンボルの第２の部分が、第１の部分に含まれていない出力シンボルの部分を含んでおり、アクセラレータが、ソース・シンボルを出力シンボルに変換する変換動作を実行するように構成され、処理ユニットが、アクセラレータを呼び出して変換動作を実行するように構成される。
さらに別の態様から見ると、本発明は、処理ユニットまたはアクセラレータによって、外部ソースから受信されたソース・シンボルの第１の部分をメイン・ソース・バッファに格納することと、第１の部分が、外部ソースから受信されたソース・シンボルの第２の部分を含まず、完成されていないということの決定に基づいて、処理ユニットまたはアクセラレータによって、ソース・シンボルの第１の部分をオーバーフロー・ソース・バッファに格納することと、アクセラレータによって、オーバーフロー・ソース・バッファに格納されたソース・シンボルの第１の部分およびメイン・ソース・バッファに格納されたソース・シンボルの第２の部分をフェッチすることと、アクセラレータによって、ソース・シンボルの第１および第２の部分を出力シンボルに一緒に変換することと、処理ユニットまたはアクセラレータによって、アクセラレータから受信された出力シンボルをメイン・ターゲット・バッファに格納することとを含むコンピュータ実装方法を提供し、ソース・シンボルの第２の部分が、第１の部分に含まれていないソース・シンボルの部分を含み、アクセラレータがハードウェア・エンジンを含む。
さらに別の態様から見ると、本発明は、処理ユニットまたはアクセラレータによって、外部ソースから受信されたソース・シンボルをメイン・ソース・バッファに格納することと、アクセラレータによって、出力シンボルへのソース・シンボルの変換動作を実行することと、処理ユニットまたはアクセラレータによって、アクセラレータから受信された出力シンボルの第１の部分をメイン・ターゲット・バッファに格納することと、出力シンボルの第２の部分を格納することにメイン・ターゲット・バッファを使用できないということの決定に基づいて、処理ユニットまたはアクセラレータによって、アクセラレータから受信された出力シンボルの第２の部分をオーバーフロー・ターゲット・バッファに格納することとを含むコンピュータ実装方法を提供し、ソース・シンボルの第２の部分が、第１の部分に含まれていないソース・シンボルの部分を含み、アクセラレータがハードウェア・エンジンを含む。
さらに別の態様から見ると、本発明は、メモリ・ユニットを管理するコンピュータ・プログラム製品を提供し、このコンピュータ・プログラム製品は、処理回路によって読み取り可能な、本発明のステップを実行するための方法を実行するためにこの処理回路によって実行される命令を格納している、コンピュータ可読ストレージ媒体を備えている。
さらに別の態様から見ると、本発明は、コンピュータ可読媒体に格納された、デジタル・コンピュータの内部メモリに読み込み可能なコンピュータ・プログラムを提供し、このコンピュータ・プログラムは、コンピュータ上で実行された場合に本発明のステップを実行するためのソフトウェア・コード部分を含む。
本発明の１つまたは複数の実施形態に従って、処理ユニット、アクセラレータ、メイン・ソース・バッファ、メイン・ターゲット・バッファ、およびメモリ・ブロックを含むシステム・アーキテクチャが提供される。メイン・ソース・バッファは、外部ソースから受信されたソース・シンボルの第１の部分を格納するように構成される。メイン・ターゲット・バッファは、アクセラレータから受信された出力シンボルを格納するように構成される。メモリ・ブロックは、オーバーフロー・ソース・バッファを含む。オーバーフロー・ソース・バッファは、メイン・ソース・バッファから受信されたソース・シンボルの第１の部分を格納するように構成される。アクセラレータは、オーバーフロー・ソース・バッファに格納されたソース・シンボルの第１の部分およびメイン・ソース・バッファに格納されたソース・シンボルの第２の部分をフェッチし、ソース・シンボルの第１および第２の部分を出力シンボルに一緒に変換する変換動作を実行するように構成される。ソース・シンボルの第２の部分は、ソース・シンボルの第１の部分に含まれていないソース・シンボルの部分を含む。処理ユニットは、変換動作を呼び出すように構成される。利点としては、アーキテクチャがメイン・ソース・バッファに格納された部分的ソース・シンボルを失うのを防ぐこと、およびソース・シンボルの結合された部分全体をアクセラレータに送信し、アクセラレータが、変形なしで意図された出力シンボルを復元するように、ソース・シンボルの部分全体を一緒に変換することなどがあり得る。アクセラレータがハードウェア・エンジンである場合の別の利点は、処理速度が、ソフトウェアによって実装された圧縮の処理速度よりも高速であることである。
本発明の追加または代替の実施形態に従って、上記の変換動作は、ソース・シンボルの第１および第２の部分を出力シンボルに一緒に復元する復元動作を含む。
本発明の追加または代替の実施形態に従って、処理ユニットは、ミリコードを介してアクセラレータの動作を制御する。
本発明の追加または代替の実施形態に従って、メイン・ソース・バッファは、ソース・シンボルの第１の部分をメイン・ソース・バッファの最後の使用可能な空間に格納する。利点としては、一連のシンボルのうちのオーバーフロー・ソース・バッファに格納される対象になるソース・シンボル、およびオーバーフロー・ソース・バッファの空間の必要な量を、プロセッサが認識するのに役立つことなどがある。
本発明の追加または代替の実施形態に従って、ソース・シンボルが圧縮ヘッダーを含む。利点としては、これによって、オーバーフロー・ソース・バッファの最大の空間がどれくらい必要かをプロセッサに知らせることなどがある。
本発明の追加または代替の実施形態に従って、メモリ・ブロックは、変換動作を再開するのに必要な情報をさらに含む。利点としては、メモリ・ブロックに格納された情報が、システムが復元プロセスを再開する必要があるタイミングをトリガーすることなどがある。
本発明の１つまたは複数の実施形態に従って、処理ユニット、アクセラレータ、メイン・ソース・バッファ、メイン・ターゲット・バッファ、およびメモリ・ブロックを含むシステム・アーキテクチャが提供される。メイン・ソース・バッファは、外部ソースから受信されたソース・シンボルを格納するように構成される。メイン・ターゲット・バッファは、アクセラレータから受信された出力シンボルの第１の部分を格納するように構成される。メモリ・ブロックは、オーバーフロー・ターゲット・バッファを含む。オーバーフロー・ターゲット・バッファは、アクセラレータから受信された出力シンボルの第２の部分を格納するように構成される。出力シンボルの第２の部分は、第１の部分に含まれていない出力シンボルの部分を含む。アクセラレータは、ソース・シンボルを出力シンボルに変換する変換動作を実行するように構成される。処理ユニットは、変換動作を呼び出すように構成される。利点としては、アーキテクチャがターゲット・シンボルのあふれた部分を失うのを防ぐこと、および出力シンボルを受信する別のデバイスが変形なしで元のデータを受信できるように、ターゲット・シンボルの結合された部分全体を次に使用可能なメイン・ターゲット・バッファに送信することなどがあり得る。
上記の変換動作は、ソース・シンボルを出力シンボルに復元する復元動作、またはソース・シンボルを出力シンボルに圧縮する圧縮動作を含んでよい。
本発明の１つまたは複数の実施形態に従って、コンピュータ実装方法が提供され、コンピュータ実装方法は、処理ユニットまたはアクセラレータによって、外部ソースから受信されたソース・シンボルの第１の部分をメイン・ソース・バッファに格納することと、第１の部分が、外部ソースから受信されたソース・シンボルの第２の部分を含まず、完成されていないということの決定に基づいて、処理ユニットまたはアクセラレータによって、ソース・シンボルの第１の部分をオーバーフロー・ソース・バッファに格納することと、アクセラレータによって、オーバーフロー・ソース・バッファに格納されたソース・シンボルの第１の部分およびメイン・ソース・バッファに格納されたソース・シンボルの第２の部分をフェッチすることと、アクセラレータによって、ソース・シンボルの第１および第２の部分を出力シンボルに一緒に変換することと、処理ユニットまたはアクセラレータによって、アクセラレータから受信された出力シンボルをメイン・ターゲット・バッファに格納することとを含む。ソース・シンボルの第２の部分は、第１の部分に含まれていないソース・シンボルの部分を含み、アクセラレータはハードウェア・エンジンを含む。利点としては、ソース・シンボル全体を使用して、再開された変換を実行できることなどがある。
本発明の１つまたは複数の実施形態に従って、コンピュータ実装方法が提供され、コンピュータ実装方法は、処理ユニットまたはアクセラレータによって、外部ソースから受信されたソース・シンボルをメイン・ソース・バッファに格納することと、アクセラレータによって、出力シンボルへのソース・シンボルの変換動作を実行することと、処理ユニットまたはアクセラレータによって、アクセラレータから受信された出力シンボルの第１の部分をメイン・ターゲット・バッファに格納することと、出力シンボルの第２の部分を格納することにメイン・ターゲット・バッファを使用できないということの決定に基づいて、処理ユニットまたはアクセラレータによって、アクセラレータから受信された出力シンボルの第２の部分をオーバーフロー・ターゲット・バッファに格納することとを含む。ソース・シンボルの第２の部分は、第１の部分に含まれていないソース・シンボルの部分を含み、アクセラレータはハードウェア・エンジンを含む。コンピュータ実装方法は、オーバーフロー・ターゲット・バッファに格納された出力シンボルの第２の部分をメイン・ターゲット・バッファに供給することによって、変換動作を再開することをさらに含んでよい。利点としては、変換された出力シンボル全体を他のデバイスに転送できることなどがある。
本発明の１つまたは複数の実施形態に従って、処理ユニット、アクセラレータ、メイン・ソース・バッファ、メイン・ターゲット・バッファ、およびオーバーフロー・ソース・バッファを含むシステム・アーキテクチャを管理するためのコンピュータ・プログラム製品が提供される。このコンピュータ・プログラム製品は、プログラム命令が具現化されているコンピュータ可読ストレージ媒体を含む。処理ユニットおよびアクセラレータによって実行可能なプログラム命令が、システム・アーキテクチャに方法を実行させ、この方法は、処理ユニットまたはアクセラレータによって、外部ソースから受信されたソース・シンボルの第１の部分をメイン・ソース・バッファに格納することと、第１の部分が、外部ソースから受信されたソース・シンボルの第２の部分を含まず、完成されていないということの決定に基づいて、処理ユニットまたはアクセラレータによって、ソース・シンボルの第１の部分をオーバーフロー・ソース・バッファに格納することと、アクセラレータによって、オーバーフロー・ソース・バッファに格納されたソース・シンボルの第１の部分およびメイン・ソース・バッファに格納されたソース・シンボルの第２の部分をフェッチすることと、アクセラレータによって、ソース・シンボルの第１および第２の部分を出力シンボルに一緒に変換することと、処理ユニットまたはアクセラレータによって、アクセラレータから受信された出力シンボルをメイン・ターゲット・バッファに格納することとを含む。ソース・シンボルの第２の部分は、第１の部分に含まれていないソース・シンボルの部分を含む。
その他の技術的特徴および利点が、本発明の手法によって実現される。本発明の実施形態および態様は、本明細書において詳細に説明され、請求される対象の一部と見なされる。さらに良く理解するために、詳細な説明および図面を参照すること。
本明細書に記載された専有権の詳細は、本明細書の最後にある特許請求の範囲において具体的に指摘され、明確に請求される。本発明の各実施形態の前述およびその他の特徴と長所は、添付の図面と共に行われる以下の詳細な説明から明らかになる。
本発明の１つまたは複数の態様を組み込んで使用するためのコンピューティング環境の一例を示す図である。 本発明の１つまたは複数の態様に従って、図１Ａのプロセッサの詳細をさらに示す図である。 本発明の１つまたは複数の態様を組み込んで使用するためのコンピューティング環境の別の例を示す図である。 本発明の態様に従って、デフレート変換呼び出し（ＤＦＬＴＣＣ：DEFLATE Conversion Call）命令の１つの形式を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令によって使用される暗黙のレジスタ（汎用レジスタ０）のフィールドの一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令の機能コードの一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令によって使用される暗黙のレジスタ（汎用レジスタ１）のフィールドの一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令によって指定されるレジスタ（Ｒ１）の内容の一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令によって使用されるレジスタ（Ｒ１＋１）の内容の一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令によって指定されるレジスタ（Ｒ２）の内容の一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令によって使用されるレジスタ（Ｒ２＋１）の内容の一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令によって指定されるレジスタ（Ｒ３）の内容の一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令のＤＦＬＴＣＣ－ＱＡＦ（使用可能な機能の照会）機能によって使用されるパラメータ・ブロックの内容の一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令のＤＦＬＴＣＣ－ＧＤＨＴ（動的ハフマン・テーブルの生成）機能によって使用されるパラメータ・ブロックの内容の一例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令のＤＦＬＴＣＣ－ＣＭＰＲ（圧縮）機能およびＤＦＬＴＣＣ－ＸＰＮＤ（展開）機能によって使用されるパラメータ・ブロックの内容の一例を示す図である。 本発明の１つまたは複数の態様に従って、サブバイト境界（sub-byte boundary）の一例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＣＭＰＲ機能へのサブバイト境界の適用方法を説明する例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＣＭＰＲ機能へのサブバイト境界の適用方法を説明する例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＣＭＰＲ機能へのサブバイト境界の適用方法を説明する例を示す図である。 本発明の態様に従って、圧縮されていないデータのブロックの一例を示す図である。 本発明の態様に従って、固定ハフマン・テーブル（ＦＨＴ：fixed-Huffmantable）を使用して圧縮されたデータを含むブロックの一例を示す図である。 本発明の態様に従って、動的ハフマン・テーブル（ＤＨＴ：dynamic-Huffman table）を使用して圧縮されたデータを含むブロックの一例を示す図である。 本発明の態様に従って、ストレージ内の圧縮データ・セットの一例を示す図である。 本発明の態様に従って、圧縮データ・セットの３つのブロックにデータを圧縮するプログラムのサンプルの一例を示す図である。 本発明の態様に従って、セットの第１の圧縮データ・ブロックに対して動作するＤＦＬＴＣＣ－ＣＭＰＲ機能のパラメータ・ブロックの内容の一例を示す図である。 本発明の態様に従って、セットの第２の圧縮データ・ブロックに対して動作するＤＦＬＴＣＣ－ＣＭＰＲ機能のパラメータ・ブロックの内容の一例を示す図である。 本発明の態様に従って、圧縮データ・セットからデータを復元するプログラムのサンプルの一例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＣＭＰＲを複数回実行する前後の直列履歴バッファ（in-line history buffer）の例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＣＭＰＲを複数回実行する前後の直列履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＣＭＰＲを複数回実行する前後の直列履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣを複数回実行する前後の円形履歴バッファ（circular history buffer）の例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣを複数回実行する前後の円形履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣを複数回実行する前後の円形履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣを複数回実行する前後の円形履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣを複数回実行する前後の円形履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＸＰＮＤを複数回実行する前後の直列履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＸＰＮＤを複数回実行する前後の直列履歴バッファの例を示す図である。 本発明の態様に従って、ＤＦＬＴＣＣ－ＸＰＮＤを複数回実行する前後の直列履歴バッファの例を示す図である。 本発明の態様に従って、デフレート変換呼び出し命令の使用の一例を示す図である。 本発明の態様に従って、円形履歴バッファの使用の一例を示す図である。 本発明の１つまたは複数の実施形態に従って、システム・アーキテクチャを示す図である。 本発明の１つまたは複数の実施形態に従って、図１９のシステム・アーキテクチャの追加の特徴を示す図である。 本発明の１つまたは複数の実施形態に従って、外部デバイスと図１９のシステム・アーキテクチャのメモリとの間のデータ・ファイル転送を示す概略図である。 本発明の１つまたは複数の実施形態に従って、図２１のメモリ内のメモリ・ブロックを示すブロック図である。 本発明の１つまたは複数の実施形態に従って、メモリ・ページ例外（memory page exception）を示す概略図である。
本明細書において示される図は、実例である。本発明の範囲から逸脱することなく、本明細書に記載された図または動作の多くの変形が存在することが可能である。例えば、動作は異なる順序で実行されることが可能であり、あるいは動作は追加、削除、または変更されることが可能である。また、「結合される」という用語およびその変形は、２つの要素間に通信経路が存在することを表しており、それらの要素間に要素／接続が介在しない要素間の直接的接続を意味していない。これらのすべての変形は、本明細書の一部であると見なされる。
添付の図および開示された実施形態の以下の詳細な説明では、図に示されたさまざまな要素が、２桁または３桁の参照番号付きで提供されている。わずかな例外を除いて、各参照番号の左端の数字は、その要素が最初に示された図に対応している。
本発明の１つまたは複数の実施形態は、オーバーフロー・バッファを利用して、命令を中断して一時的に停止することを可能にする。本発明の１つまたは複数の実施形態は、メモリ境界の収容のために一時的結果を溢れさせるための方法を提供する。パラメータ・ブロック（parms block）内のオーバーフロー・ソース・バッファを利用して、復元状態の不完全なソース・シンボルを収容することができ、パラメータ・ブロック内のあふれているターゲット・バッファを利用して、復元または圧縮によって生成された不完全な出力シンボルを収容することができる。本明細書において使用されるとき、「パラメータ・ブロック」という用語は、変換動作（例えば、圧縮動作または復元動作）のためのパラメータを含むメモリ・ブロックのことを指す。本発明の１つまたは複数の実施形態は、オーバーフロー・バッファのサイズを最小限に抑えるために、オーバーフロー・バッファに送信されるデータの量を最小限に抑える。オーバーフロー・バッファを、パラメータ・ブロックの一部として定義することができ、オーバーフロー・バッファに格納された内容を、パラメータ自体のように扱うことができる。その後の継続コマンド内で、ファームウェアがオーバーフロー・バッファの内容を適切なメモリ・ページにコピーする。オーバーフロー・バッファはパラメータ・ブロックの一部として定義されるため、圧縮命令／復元命令の各呼び出しでは、オーバーフロー・バッファのアドレスを気にする必要がない。この実装の結果、アクセラレータがソース・シンボルを完全に処理すること、またはターゲット出力シンボルを完全に格納することを、使用可能な空間が許さない場合でも、アクセラレータは、使用可能なソース・バッファおよびターゲット・バッファを完全に利用することができる。これによって、長いストリームにおいて固定サイズのソフトウェアによって提供されるバッファを可能にすることに加えて、アクセス例外の場合に、アクセラレータが先行するページを完全に利用できるようにする。
既存のメカニズムは、オーバーフロー・バッファを含まない相対的に小さいメイン・ソース・バッファおよびメイン・ターゲット・バッファ（例えば、１ＭＢ）を使用して、大きいデータ・ファイル（例えば、５ＧＢ）を復元する。復元段階でのソース・シンボルのサイズに起因して、場合によっては、メイン・ソース・バッファがシンボルの境界で終了しないことがある。既存のメカニズムでは、圧縮段階でも同様の状況が発生する可能性がある。オーバーフローに起因してシンボルの一部のみがメイン・バッファに格納され、格納されたシンボルのみがシンボルの残りの部分を追加せずに転送されて圧縮された場合、転送されて圧縮されたシンボルの内容は不完全であり、誤っている。この種類のエラーは、復元を実行するデバイスにおいて発生することもある。
本発明の１つまたは複数の実施形態は、データの残りの部分をオーバーフロー・バッファに一時的に格納できるように、オーバーフロー・バッファを追加することによって、現在の方法の上記の欠点／短所に対処する。
１つまたは複数のコンピューティング環境内で、元の圧縮されていない形態ではなく、情報の圧縮された形態が、ストレージ・デバイス上で維持される。この圧縮された形態は、元の形態よりも少ないバイトを占有する。その結果、情報の圧縮された形態を送信して維持するために必要な時間および空間は、情報の元の形態で同じ機能を実行することと比較して、それぞれ少ない。
そのような環境では、オペレーティング・システム（ＯＳ：operating system）が、圧縮動作および復元動作を実行するためのメカニズムを提供する。１つの例では、これらの動作を提供するために、オペレーティング・システムがｚｌｉｂオープンソース・ソフトウェア・ライブラリを組み込み、ｚｌｉｂオープンソース・ソフトウェア・ライブラリは、ＩＥＴＦ（Internet Engineering Task Force：インターネット・エンジニアリング・タスク・フォース）ＲＦＣ（Request for Comments：コメント要求）１９５１仕様において規定されたデフレート標準圧縮手法に従う。このメカニズムは、ユーザが、汎用プロセッサ上で圧縮または復元を実行するための多くの命令を実行するソフトウェアの実装を含んでよく、またはシステムの入出力（Ｉ／Ｏ：input/output）ポートに接続され、Ｉ／Ｏデバイスが動作を実行する、専用ハードウェアの実装を使用してもよい。
本発明の１つまたは複数の態様を組み込んで使用するためのコンピューティング環境の一実施形態が、図１Ａを参照して説明される。コンピューティング環境１００は、例えば、１つまたは複数のバス１０８またはその他の接続あるいはその両方を介して互いに結合された、例えば、プロセッサ１０２（例えば、中央処理装置）と、メモリ１０４（例えば、メイン・メモリであり、システム・メモリ、主記憶装置、中央記憶装置、ストレージとも呼ばれる）と、１つまたは複数の入出力（Ｉ／Ｏ）デバイスまたはインターフェイス１０６あるいはその両方とを含む。
１つの例では、プロセッサ１０２は、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ（ニューヨーク州アーモンク市）によって提供されるｚ／Ａｒｃｈｉｔｅｃｔｕｒｅ（Ｒ）ハードウェア・アーキテクチャに基づき、やはりＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎによって提供されてｚ／Ａｒｃｈｉｔｅｃｔｕｒｅハードウェア・アーキテクチャを実装するＩＢＭ Ｚ（Ｒ）サーバなどのサーバに含まれる。ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅハードウェア・アーキテクチャの一実施形態は、“z/Architecture Principles of Operation,” IBM Publication No. SA22-7832-11, 12th edition, September 2017という公開文献に記載されている。しかし、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅハードウェア・アーキテクチャは１つの例示的なアーキテクチャにすぎず、他のアーキテクチャまたは他の種類のコンピューティング環境あるいはその両方が、本発明の１つまたは複数の態様を含むか、または使用するか、あるいはその両方であってよい。１つの例では、プロセッサは、やはりＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるｚ／ＯＳ（Ｒ）オペレーティング・システムなどのオペレーティング・システムを実行する。ＩＢＭ、ＩＢＭ Ｚ、ｚ／ＯＳ、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅは、世界中の多くの管轄区域で登録されている、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎの商標である。
プロセッサ１０２は、命令を実行するために使用される複数の機能コンポーネントを含む。図１Ｂに示されているように、これらの機能コンポーネントは、例えば、実行される命令をフェッチするための命令フェッチ・コンポーネント１２０と、フェッチされた命令をデコードするため、およびデコードされた命令のオペランドを取得するための命令デコード・ユニット１２２と、デコードされた命令を実行するための命令実行コンポーネント１２４と、必要な場合に、命令を実行するためにメモリにアクセスするためのメモリ・アクセス・コンポーネント１２６と、実行された命令の結果を提供するための書き戻しコンポーネント１３０とを含む。これらのコンポーネントのうちの１つまたは複数は、本発明の１つまたは複数の態様に従って、本明細書において説明されているように、圧縮処理／復元処理（または本発明の１つまたは複数の態様を使用できるその他の処理）で使用される１つまたは複数の他のコンポーネントの少なくとも一部を含むか、またはそれらのコンポーネントにアクセスすることができてよい。１つまたは複数の他のコンポーネントは、例えば、圧縮コンポーネント／復元コンポーネント（またはその他のコンポーネント）１３６を含む。
本発明の１つまたは複数の態様を組み込んで使用するためのコンピューティング環境の別の例が、図２を参照して説明される。１つの例では、コンピューティング環境はｚ／Ａｒｃｈｉｔｅｃｔｕｒｅハードウェア・アーキテクチャに基づくが、コンピューティング環境は、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎまたはその他の企業によって提供される他のアーキテクチャに基づいてよい。
図２を参照すると、１つの例では、コンピューティング環境は中央電子回路複合体（ＣＥＣ：central electronics complex）２００を含む。ＣＥＣ２００は、例えば、１つまたは複数のプロセッサ（中央処理装置（ＣＰＵ：central processing unit）とも呼ばれる）２０４および入出力サブシステム２０６に結合されたメモリ２０２（システム・メモリ、メイン・メモリ、主記憶装置、中央記憶装置、ストレージとも呼ばれる）などの、複数のコンポーネントを含む。
メモリ２０２は、例えば、１つまたは複数の論理パーティション２０８、論理パーティションを管理するハイパーバイザ２１０、およびプロセッサ・ファームウェア２１２を含む。ハイパーバイザ２１０の１つの例は、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ（ニューヨーク州アーモンク市）によって提供されるプロセッサ・リソース／システム管理機構（ＰＲ／ＳＭ（ＴＭ）：Processor Resource/System Manager）ハイパーバイザである。本明細書において使用されるとき、ファームウェアは、例えば、プロセッサのマイクロコードを含む。ファームウェアは、例えば、上位レベルのマシン・コードの実装において使用される、ハードウェア・レベルの命令またはデータ構造あるいはその両方を含む。１つの実施形態では、ファームウェアは、例えば、信頼できるソフトウェアを含むマイクロコード、または基盤になるハードウェアに固有のマイクロコードとして通常は提供される、システムのハードウェアへのオペレーティング・システムのアクセスを制御する独自のコードを含む。
各論理パーティション２０８は、別々のシステムとして機能することができる。すなわち、各論理パーティションは、独立してリセットされて、ｚ／ＯＳオペレーティング・システムなどのゲスト・オペレーティング・システム２２０または別のオペレーティング・システムを実行し、異なるプログラム２２２と共に動作することができる。論理パーティション内で実行されるオペレーティング・システムまたはアプリケーション・プログラムは、完全なシステム全体にアクセスできるように見えるが、実際は、その一部のみが利用可能である。
メモリ２０２は、論理パーティションに割り当てることができる物理プロセッサ・リソースであるプロセッサ（例えば、ＣＰＵ）２０４に結合される。例えば、論理パーティション２０８は、１つまたは複数の論理プロセッサを含み、それらの論理プロセッサの各々は、論理パーティションに動的に割り当てることができる物理プロセッサ・リソース２０４の全部または一部を表す。
さらに、メモリ２０２は、Ｉ／Ｏサブシステム２０６に結合される。Ｉ／Ｏサブシステム２０６は、中央電子回路複合体の一部であるか、または中央電子回路複合体から分離し得る。Ｉ／Ｏサブシステム２０６は、主記憶装置２０２と、中央電子回路複合体に結合された入出力制御ユニット２３０および入出力（Ｉ／Ｏ）デバイス２４０との間の情報の流れを方向付ける。
多くの種類のＩ／Ｏデバイスが使用されてよい。１つの特定の種類は、データ・ストレージ・デバイス２５０である。データ・ストレージ・デバイス２５０は、１つまたは複数のプログラム２５２、１つまたは複数のコンピュータ可読プログラム命令２５４、またはデータ、あるいはその組み合わせなどを格納し得る。コンピュータ可読プログラム命令は、本発明の態様の実施形態の機能を実行するように構成されてよい。
１つの例として、各プロセッサ２０４は、１つまたは複数のローカル・キャッシュまたは１つまたは複数の共有キャッシュあるいはその両方などの、複数のレベルのキャッシュを含むキャッシュ階層の少なくとも１つのキャッシュ２６０（例えば、ローカル・キャッシュ）を含む。さらに、１つの実施形態では、ローカル・キャッシュおよびメモリ２０２が、データの圧縮または復元あるいはその両方（または本発明の１つまたは複数の態様の他の動作あるいはその両方）のうちの１つまたは複数の実行において使用される圧縮コンポーネント／復元コンポーネント（またはその他のコンポーネント）２６２に結合される。さまざまな例では、これらのタスクを実行する１つまたは複数のコンポーネントが存在し得る。多くの変形が可能である。
１つの実施形態では、プロセッサ（例えば、プロセッサ２０４）が命令（例えば、デフレート変換呼び出し命令）を取得し、命令をデコードし、命令によって使用されるアドレスの変換を含む、命令の設定を実行し、命令のコマンドを、コンポーネント２６２などのプロセッサに結合されたコンポーネントに送信し、命令によって指定された機能を実行する。コンポーネント２６２は、指定された機能の実行において、データを読み込んで処理し、処理されたデータを再び格納するように、キャッシュ階層およびメモリにアクセスすることができる。一例として、コンポーネント２６２は、ハードウェア・コンポーネントである。
さらに別の実施形態では、コンポーネント２６２の少なくとも一部が、プロセッサの一部として含まれる。多くの変形が可能である。
中央電子回路複合体２００は、取り外し可能／取り外し不可、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体を含むか、またはそのようなコンピュータ・システム・ストレージ媒体に結合されるか、あるいはその両方であってよい。例えば、中央電子回路複合体２００は、取り外し不可、不揮発性の磁気媒体（通常は、「ハード・ドライブ」と呼ばれる）、取り外し可能、不揮発性の磁気ディスク（例えば、「フロッピー（Ｒ）・ディスク」）に対する読み取りと書き込みを行うための磁気ディスク・ドライブ、あるいはＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、またはその他の光媒体などの取り外し可能、不揮発性の光ディスクに対する読み取りと書き込みを行うための光ディスク・ドライブ、あるいはその組み合わせを含むか、またはこれらに結合されるか、あるいはその両方であってよい。その他のハードウェア・コンポーネントまたはソフトウェア・コンポーネントあるいはその両方を、中央電子回路複合体２００と併用できるということが理解されるべきである。その例として、マイクロコード、デバイス・ドライバ、冗長プロセッシング・ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが挙げられるが、これらに限定されない。
さらに、中央電子回路複合体２００は、他の多数の汎用または専用のコンピューティング・システム環境または構成で運用されてよい。中央電子回路複合体２００での使用に適している可能性がある周知のコンピューティング・システム、環境、または構成、あるいはその組み合わせの例としては、パーソナル・コンピュータ（ＰＣ：personal computer）システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マイクロプロセッサ・システム、マイクロプロセッサベース・システム、セット・トップ・ボックス、プログラマブル・コンシューマ・エレクトロニクス、ネットワークＰＣ、マイクロコンピュータ・システム、メインフレーム・コンピュータ・システム、およびこれらの任意のシステムまたはデバイスを含む分散クラウド・コンピューティング環境などが挙げられるが、これらに限定されない。
本明細書ではコンピューティング環境のさまざまな例が説明されるが、本発明の１つまたは複数の態様が、多くの種類の環境と共に使用されてよい。本明細書で提供されるコンピューティング環境は、例にすぎない。
本発明の態様に従って、コンピューティング環境１００または中央電子回路複合体２００などのコンピューティング環境は、データを圧縮および復元するためのメカニズムを提供する変換機能を採用する。１つの例では、変換機能は、デフレート圧縮データ形式を使用してデータを圧縮および復元するためのメカニズムを提供するデフレート変換機能である。１つの例では、変換機能は、機能インジケータが例えば１に設定されたときに、システムにインストールされる。ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅハードウェア・アーキテクチャの１つの特定の例として、ｚ／Ａｒｃｈｉｔｅｃｔｕｒｅアーキテクチャ・モードで変換機能がインストールされたときに、機能ビット１５１が例えば１に設定される。この機能は、例えば、デフレート変換呼び出し命令を含み、デフレート変換呼び出し命令の実施形態が以下で説明される。
１つの例では、デフレート変換呼び出し命令は、データの元の（圧縮されていない）形態と、ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）ＲＦＣ（コメント要求）１９５１仕様（DEFLATE Compressed Data Format Specification version 1.3 Internet Engineering Task Force, Request for Comments 1951, May 1996に記載されている）などの選択された規格によって規定されたデータの圧縮表現との間でデータの状態を変換することに関連する機能を実行する。
１つの例では、圧縮されていないデータはバイトのシーケンスであり、データの圧縮表現はシンボルを含む。シンボルは、圧縮されていないデータの個別のバイト（リテラル・バイトと呼ばれる）を表すか、または圧縮されていないデータの繰り返されるバイトのシーケンス（重複列と呼ばれる）を表す。一例として、ハフマン・テーブルは、圧縮データ・シンボルと圧縮されていないデータの間のエンコーディングおよびデコーディングを指定する。２種類のハフマン・テーブルが存在しており、固定ハフマン・テーブル（ＦＨＴ）は、例えばすべての可能なコーディングを含む既定の仕様であり、動的ハフマン・テーブル（ＤＨＴ）は、圧縮されるデータに対して具体的に作成されたコーディングのセットであり、すべての可能なコーディングのサブセットであることができる。ＤＨＴを使用して生成されたデータの圧縮表現は、ＦＨＴを使用して生成された同じデータの圧縮表現よりも、通常は小さい。直前に処理された圧縮されていないデータの一部（履歴と呼ばれる）が、重複列を表す圧縮データ・シンボルをエンコードおよびデコードするために維持される。履歴は、重複列の参照元である。動作中にデータが処理されるときに、履歴が更新される。
示されているように、１つの例では、デフレート変換呼び出し命令は、RCF 1951,DEFLATE Compressed Data Format Specification version 1.3に記載されているデフレート圧縮データ形式を使用する。デフレート変換呼び出し命令に適用されるデフレート規格の属性は、例えば以下を含む。
・圧縮データ・セットが一連のブロックを含む。３種類のブロックが存在する。１つの種類は、３ビットのヘッダーならびにその後に続く長さの情報および圧縮されていないデータを含み、ブロックの２つの種類は、３ビットのヘッダーおよびその後に続く圧縮データ要素を含む。
・圧縮データ要素は、動的ハフマン・テーブルの圧縮表現、圧縮データ・シンボル、およびブロック終結（ＥＯＢ：end-of-block）シンボルを含んでよい。
・圧縮データ要素は、さまざまなビット長を有する。
・圧縮データ要素は、ストレージ内のバイト境界間で開始または終了し得る。
・圧縮データ要素は、例えば右端のビット位置から左端のビット位置まで、順番にバイトに読み込まれる。
圧縮データ要素が、ストレージ内のあるバイトの全部ではなく一部を占める場合、ストレージ内のそのバイト全体がアクセスされる。ストレージ・オペランドの長さは、アドレス指定可能なバイトの数を指定し、圧縮データが占めるビットよりも多くのビットを指定することができる。
以下では、圧縮データ・ブロックに関する詳細がさらに説明される。
デフレート変換呼び出し（ＤＦＬＴＣＣ）命令の一実施形態が、図３Ａ～３Ｌを参照して説明される。この命令は、１つの例では、汎用プロセッサ（例えば、プロセッサ１０２または２０４）を使用して実行される。本明細書における説明では、フィールドの特定の位置、特定のフィールド、またはフィールドの特定のサイズ、あるいはその組み合わせが（例えば、特定のバイトまたはビットあるいはその両方で）示される。しかし、他の位置、フィールド、またはサイズ、あるいはその組み合わせが提供されてよい。さらに、特定の値（例えば、１または０）へのビットの設定が指定されるが、これは単なる例である。ビットは、他の例では、反対の値または別の値などの異なる値に設定されてよい。多くの変形が可能である。
１つの実施形態では、プログラム（例えば、オペレーティング・システムまたはユーザ・プログラム）が、デフレート変換呼び出し命令を複数回実行して、単一のデータ・ストリームを圧縮または復元し得る。例えば、アプリケーションが大きい（例えば、１Ｍバイトより大きい）データ・ストリームを圧縮または復元する場合、動作は、データ・ストリームのバッファされた部分を圧縮または復元するための複数の呼び出しを含んでよい。本発明の１つの態様に従って、プログラムは、デフレート変換呼び出し命令の複数の実行にわたる動作中に処理された圧縮されていないデータの履歴を蓄積するために使用されるバッファ（例えば、３２Ｋバイトのバッファ）を宣言する。このバッファは、円形履歴バッファと呼ばれ、本明細書において説明されているように、デフレート変換呼び出し命令を使用して定義される。
図３Ａを参照すると、１つの例では、デフレート変換呼び出し（ＤＦＬＴＣＣ）命令３００の形式は、拡張されたオペレーション・コード（オペコード）フィールドおよび追加のレジスタ・フィールドを使用してレジスタおよびレジスタの動作を示すＲＲＦ形式である。一例として、この命令は、デフレート変換呼び出しの動作を示すオペレーション・コードを含むオペレーション・コード・フィールド３０２（例えば、ビット０～１５）と、汎用レジスタの第１の対を指定する第１のレジスタ・フィールド（Ｒ１）３０４（例えば、ビット２４～２７）と、汎用レジスタの第２の対を指定する第２のレジスタ・フィールド（Ｒ２）３０６（例えば、ビット２８～３１）と、第３の汎用レジスタを指定する第３のレジスタ・フィールド（Ｒ３）３０８（例えば、ビット１６～１９）とを含む。Ｒ１フィールド３０４によって指定されたレジスタの内容は、（ストレージ内の）第１のオペランドの位置を指定し、Ｒ２フィールド３０６によって指定されたレジスタの内容は、（ストレージ内の）第２のオペランドの位置を指定し、Ｒ３フィールド３０８によって指定されたレジスタの内容は、（ストレージ内の）第３のオペランドの位置を指定する。Ｒ１＋１の内容は第１のオペランドの長さを指定し、Ｒ２＋１の内容は第２のオペランドの長さを指定する。１つの例では、命令のビット２０～２３は予備であり、０を含むべきである。そうでない場合、プログラムは将来、互換性を維持して動作しなくなることがある。本明細書において使用されるとき、プログラムは、デフレート変換呼び出し命令の発行元である。プログラムは、ユーザ・プログラム、オペレーティング・システム、または別の種類のプログラムであってよい。
１つの実施形態では、命令の実行は１つまたは複数の暗黙の汎用レジスタ（すなわち、命令によって明示的に指定されないレジスタ）の使用を含む。例えば、本明細書において説明されているように、デフレート変換呼び出し命令の実行では汎用レジスタ０および１が使用される。汎用レジスタ０は、１つの例では、実行される機能（および、以下で説明されるように、履歴バッファ・タイプ）を指定するために使用され、汎用レジスタ１は、命令によって使用されるパラメータ・ブロックの位置を提供するために使用される。
一例として、図３Ｂを参照すると、汎用レジスタ０（３０９）が履歴バッファ・タイプ・フィールド３１０および機能コード・フィールド３１２を含む。１つの特定の例では、汎用レジスタ０のビット位置５６が履歴バッファ・タイプを含み、汎用レジスタ０のビット位置５７～６３が機能コードを含むが、他の実施形態では、履歴バッファ・タイプまたは機能コードあるいはその両方を含むために他のビットが使用されてよい。汎用レジスタ０のビット５７～６３が、割り当てられていないか、またはインストールされていない機能コードを指定している場合、１つの例では、指定例外が認識される。
デフレート変換呼び出し命令の例示的な割り当てられた機能コードが、図３Ｃに示されており、例えば、ＤＦＬＴＣＣ－ＱＡＦ（使用可能な機能の照会）機能を示す機能コード０（３１３）、ＤＦＬＴＣＣ－ＧＤＨＴ（動的ハフマン・テーブルの生成）機能を示す機能コード１（３１５）、ＤＦＬＴＣＣ－ＣＭＰＲ（圧縮）機能を示す機能コード２（３１７）、およびＤＦＬＴＣＣ－ＸＰＮＤ（展開）機能を示す機能コード４（３１９）を含む。各コードはパラメータ・ブロックを使用し、パラメータ・ブロックのサイズは、１つの例では、機能によって決まる。例えば、ＤＦＬＴＣＣ－ＱＡＦ機能の場合、パラメータ・ブロックは３２バイトであり、ＤＦＬＴＣＣ－ＧＤＨＴ機能の場合、パラメータ・ブロックは３８４バイトであり、ＤＦＬＴＣＣ－ＣＭＰＲ機能およびＤＦＬＴＣＣ－ＸＰＮＤ機能の場合、パラメータ・ブロックは１５３６バイトである。他の機能コードは、この例では割り当てられない。例示的な機能および機能コードが説明されているが、他の機能または機能コードあるいはその両方が使用されてよい。
指定された機能がＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤである場合、汎用レジスタ０のビット５６が、動作中に使用される履歴バッファ・タイプ（ＨＢＴ：history buffer type）を指定する。ＨＢＴが０である場合、履歴バッファは直列履歴バッファと呼ばれる。直列履歴バッファを使用しているときに、履歴は、ＤＦＬＴＣＣ－ＣＭＰＲが指定された場合、例えば第２のオペランドのすぐ左に存在し、ＤＦＬＴＣＣ－ＸＰＮＤが指定され場合、例えば第１のオペランドのすぐ左に存在する。ＨＢＴが１である場合、履歴バッファは円形履歴バッファと呼ばれる。円形履歴バッファを使用しているときに、履歴は、ＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤのいずれかが指定された場合、第３のオペランドの一部または全部である。ＤＦＬＴＣＣ－ＱＡＦ機能またはＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、汎用レジスタ０のビット５６が無視される。１つの例では、汎用レジスタ０のビット位置０～３１は無視される。さらに、１つの例では、汎用レジスタ０のビット位置３２～５５は予備であり、０を含むべきである。そうでない場合、プログラムは将来、互換性を維持して動作しなくなることがある。
デフレート変換呼び出し命令によって使用される別の暗黙のレジスタ（汎用レジスタ１）に関する詳細が、図３Ｄを参照してさらに説明される。汎用レジスタ１（３１４）の内容は、例えば、ストレージ内のパラメータ・ブロックの左端のバイトの論理アドレス３１６を指定する。１つの例では、パラメータ・ブロックは４Ｋバイト境界上で指定され、そうでない場合、指定例外が認識される。以下では、パラメータ・ブロックに関する詳細がさらに説明される。
指定された機能（例えば、ＤＦＬＴＣＣ－ＱＡＦ、ＤＦＬＴＣＣ－ＧＤＨＴ、ＤＦＬＴＣＣ－ＣＭＰＲ、ＤＦＬＴＣＣ－ＸＰＮＤ）の場合、汎用レジスタ０、１、およびＲ３の内容は変更されない。さらに、１つの例では、Ｒ１フィールド３０４が、偶数と奇数の汎用レジスタ対を指定する。これは、偶数番号が付けられたレジスタを指定することであり、汎用レジスタ０を指定することではなく、そうでない場合、指定例外が認識される。
図３Ｅ～３Ｆに示され、本明細書においてさらに詳細に説明されるように、汎用レジスタＲ１ ３１８の内容は、第１のオペランド・アドレス３２０を示し、汎用レジスタＲ１＋１ ３２２の内容は、第１のオペランドの長さ３２４を決定するために使用される。例えば、指定された機能がＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤである場合は、汎用レジスタＲ１ ３１８の内容は、第１のオペランドの左端のバイトの論理アドレスを指定する。指定された機能がＤＦＬＴＣＣ－ＣＭＰＲである場合、汎用レジスタＲ１＋１の内容は、パラメータ・ブロックの新しいタスク（ＮＴ：new task）フィールドおよびサブバイト境界（ＳＢＢ：sub-byte boundary）フィールドの値（以下で説明される）と共に、第１のオペランドの長さを指定する。以下の表は、汎用レジスタＲ１＋１の内容、ＮＴフィールド、およびＳＢＢフィールドに応じてＤＦＬＴＣＣ－ＣＭＰＲ機能の第１のオペランドの長さを示す例を提供している。
Figure 0007481073000001
指定された機能がＤＦＬＴＣＣ－ＸＰＮＤである場合、汎用レジスタＲ１＋１の内容は、第１のオペランドの長さを指定する。指定された機能がＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤである場合、データの圧縮または復元の結果が、第１のオペランドの位置に格納される。ＤＦＬＴＣＣ－ＱＡＦ機能またはＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、汎用レジスタＲ１およびＲ１＋１の内容が無視される。
さらに、指定された機能（例えば、ＤＦＬＴＣＣ－ＱＡＦ、ＤＦＬＴＣＣ－ＧＤＨＴ、ＤＦＬＴＣＣ－ＣＭＰＲ、およびＤＦＬＴＣＣ－ＸＰＮＤ）の場合、１つの例では、Ｒ２フィールド３０６が偶数と奇数の汎用レジスタ対を指定する。これは、偶数番号が付けられたレジスタを指定することであり、汎用レジスタ０を指定することではなく、そうでない場合、指定例外が認識される。
図３Ｇ～３Ｈに示され、本明細書においてさらに詳細に説明されるように、汎用レジスタＲ２ ３２６の内容は、第２のオペランド・アドレス３２８を示し、汎用レジスタＲ２＋１ ３３０の内容は、第２のオペランドの長さ３３２を決定するために使用される。例えば、指定された機能がＤＦＬＴＣＣ－ＧＤＨＴ、ＤＦＬＴＣＣ－ＣＭＰＲ、またはＤＦＬＴＣＣ－ＸＰＮＤである場合は、汎用レジスタＲ２の内容は、第２のオペランドの左端のバイトの論理アドレスを指定する。指定された機能がＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＧＤＨＴである場合、汎用レジスタＲ２＋１の内容は、第２のオペランドの長さを指定する。指定された機能がＤＦＬＴＣＣ－ＸＰＮＤである場合、汎用レジスタＲ２＋１の内容は、パラメータ・ブロックのＮＴフィールドおよびＳＢＢフィールドの値と共に、第２のオペランドの長さを指定する。命令の実行の開始時に、第２のオペランドの長さが参照され、０以外の値である場合、第２のオペランドの位置からデータがフェッチされる。命令の実行の開始時に、第２のオペランドの長さが参照され、０の値であり、かつ命令の実行の開始時に、パラメータ・ブロックの継続フラグ（ＣＦ：continuation flag）フィールドが１である場合、第２のオペランドがアクセスされない。
ＤＦＬＴＣＣ－ＱＡＦ機能が指定された場合、汎用レジスタＲ２およびＲ２＋１の内容が無視される。ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定され、汎用レジスタＲ２＋１の内容が、０に等しい長さを指定する場合、指定例外が認識され、第２のオペランドがアクセスされない。ＤＦＬＴＣＣ－ＣＭＰＲ機能またはＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、命令の実行の開始時に、パラメータ・ブロックの継続フラグ（ＣＦ）フィールドが０であり、汎用レジスタＲ２＋１の内容が、０に等しい長さを指定する場合、指定例外が認識され、第２のオペランドがアクセスされない。
図３Ｉに示されているように、指定された機能がＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤであり、履歴バッファ・タイプ（ＨＢＴ）が円形（例えば、ＨＢＴ３１０＝１）である場合、汎用レジスタＲ３ ３３５の内容が、円形履歴バッファのアドレス３３７を指定する。例えば、第３のオペランドの左端のバイトの論理アドレスが指定される。この指定は、例えば、４Ｋバイト境界を指定することであり、そうでない場合、指定例外が認識される。１つの例では、円形履歴バッファは、第３のオペランドの位置にある。指定された機能がＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤであり、かつＨＢＴが０である場合、汎用レジスタＲ３の内容が無視される。ＤＦＬＴＣＣ－ＱＡＦ機能またはＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、汎用レジスタＲ３の内容が無視される。指定された機能（例えば、ＤＦＬＴＣＣ－ＱＡＦ、ＤＦＬＴＣＣ－ＧＤＨＴ、ＤＦＬＴＣＣ－ＣＭＰＲ、およびＤＦＬＴＣＣ－ＸＰＮＤ）に関して、Ｒ３フィールドは汎用レジスタ０も汎用レジスタ１も指定せず、そうでない場合、１つの例では指定例外が認識される。
動作の一部として、指定された機能がＤＦＬＴＣＣ－ＣＭＰＲである場合、汎用レジスタＲ１内のアドレスが、ビット位置０の処理を含む第１のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが、同じ数だけデクリメントされ、汎用レジスタＲ２内のアドレスが、第２のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが、同じ数だけデクリメントされる。ビット位置０の処理を含む第１のオペランドの処理されたバイト数は、例えば、整数除算から得られた整数化した商であり、被除数は、処理された出力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。アドレスおよび長さの形成および更新は、下で説明されているように、アドレス指定モードによって決まる。
動作の一部として、指定された機能がＤＦＬＴＣＣ－ＸＰＮＤである場合、汎用レジスタＲ１内のアドレスが、第１のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが、同じ数だけデクリメントされ、汎用レジスタＲ２内のアドレスが、ビット位置０の処理を含む第２のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが、同じ数だけデクリメントされる。ビット位置０の処理を含む第２のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された入力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。アドレスおよび長さの形成および更新は、下で説明されているように、アドレス指定モードによって決まる。
１つの実施形態では、２４ビット・アドレス指定モードにおいて以下が当てはまる。
・汎用レジスタ１、Ｒ１、Ｒ２、およびＲ３のビット位置４０～６３の内容は、パラメータ・ブロック、第１のオペランド、第２のオペランド、および円形履歴バッファのアドレスをそれぞれ構成し、ビット位置０～３９の内容が無視される。
・更新された第１のオペランド・アドレスおよび第２のオペランド・アドレスのビット４０～６３は、汎用レジスタＲ１およびＲ２内の対応するビットをそれぞれ置き換える。更新されたアドレスのビット位置４０からの繰り上げが無視され、汎用レジスタＲ１およびＲ２のビット位置３２～３９の内容が０に設定される。汎用レジスタＲ１およびＲ２のビット位置０～３１の内容は変化しない。命令が部分的完了または正常完了の状態で終了し、更新されたオペランド・アドレスが命令の実行の開始時のオペランド・アドレスに等しい場合、対応する汎用レジスタのビット位置３２～３９が０に設定される。
・汎用レジスタＲ１＋１およびＲ２＋１のビット位置３２～６３の内容は、第１および第２のオペランド内のバイト数をそれぞれ指定する、例えば３２ビットの符号なし２進整数を形成する。汎用レジスタＲ１＋１およびＲ２＋１のビット位置０～３１の内容は無視される。
・更新された第１のオペランドおよび第２のオペランドの長さのビット３２～６３は、汎用レジスタＲ１＋１およびＲ２＋１内の対応するビットをそれぞれ置き換える。汎用レジスタＲ１＋１およびＲ２＋１のビット位置０～３１の内容は変化しない。
１つの実施形態では、３１ビット・アドレス指定モードにおいて以下が当てはまる。
・汎用レジスタ１、Ｒ１、Ｒ２、およびＲ３のビット位置３３～６３の内容は、パラメータ・ブロック、第１のオペランド、第２のオペランド、および円形履歴バッファのアドレスをそれぞれ構成し、ビット位置０～３２の内容が無視される。
・更新された第１のオペランド・アドレスおよび第２のオペランド・アドレスのビット３３～６３は、汎用レジスタＲ１およびＲ２内の対応するビットをそれぞれ置き換える。更新されたアドレスのビット位置３３からの繰り上げが無視され、汎用レジスタＲ１およびＲ２のビット位置３２の内容が０に設定される。汎用レジスタＲ１およびＲ２のビット位置０～３１の内容は変化しない。命令が部分的完了または正常完了の状態で終了し、更新されたオペランド・アドレスが命令の実行の開始時のオペランド・アドレスに等しい場合、対応する汎用レジスタのビット位置３２が０に設定される。
・汎用レジスタＲ１＋１およびＲ２＋１のビット位置３２～６３の内容は、第１および第２のオペランド内のバイト数をそれぞれ指定する、３２ビットの符号なし２進整数を形成する。汎用レジスタＲ１＋１およびＲ２＋１のビット位置０～３１の内容は無視される。
・更新された第１のオペランドおよび第２のオペランドの長さのビット３２～６３は、汎用レジスタＲ１＋１およびＲ２＋１内の対応するビットをそれぞれ置き換える。汎用レジスタＲ１＋１およびＲ２＋１のビット位置０～３１の内容は変化しない。
１つの実施形態では、６４ビット・アドレス指定モードにおいて以下が当てはまる。
・汎用レジスタ１、Ｒ１、Ｒ２、およびＲ３のビット位置０～６３の内容は、パラメータ・ブロック、第１のオペランド、第２のオペランド、および円形履歴バッファのアドレスをそれぞれ構成する。
・更新された第１のオペランド・アドレスおよび第２のオペランド・アドレスのビット０～６３は、汎用レジスタＲ１およびＲ２内の対応するビットをそれぞれ置き換える。更新されたアドレスのビット位置０からの繰り上げは無視される。
・汎用レジスタＲ１＋１およびＲ２＋１のビット位置０～６３の内容は、第１および第２のオペランド内のバイト数をそれぞれ指定する、６４ビットの符号なし２進整数を形成する。
・更新された第１のオペランドおよび第２のオペランドの長さのビット０～６３は、汎用レジスタＲ１＋１およびＲ２＋１内の対応するビットをそれぞれ置き換える。
アクセス・レジスタ・モードでは、アクセス・レジスタ１、Ｒ１、Ｒ２、およびＲ３が、パラメータ・ブロック、第１のオペランド、第２のオペランド、および円形履歴バッファを含むアドレス空間をそれぞれ指定する。アクセス・レジスタ・モードで、直列履歴バッファを含むＤＦＬＴＣＣ－ＣＭＰＲが指定された場合、アクセス・レジスタＲ２が、直列履歴を含むアドレス空間を指定する。アクセス・レジスタ・モードで、直列履歴バッファを含むＤＦＬＴＣＣ－ＸＰＮＤが指定された場合、アクセス・レジスタＲ１が、直列履歴を含むアドレス空間を指定する。
以下では、さまざまな機能に関する詳細がさらに説明される。
機能コード０：ＤＦＬＴＣＣ－ＱＡＦ（使用可能な機能の照会）
ＤＦＬＴＣＣ－ＱＡＦ（使用可能な機能の照会）機能は、インストール済み機能およびインストール済みパラメータ・ブロック形式の使用可能性を示すためのメカニズムを提供する。ＤＦＬＴＣＣ－ＱＡＦ機能のパラメータ・ブロックの１つの例示的な形式が、図３Ｊを参照して説明される。１つの例では、ＤＦＬＴＣＣ－ＱＡＦ機能（例えば、機能コード０）のパラメータ・ブロック３４０は、インストール済み機能ベクトル３４２およびインストール済みパラメータ・ブロック形式ベクトル３４６を含む。１つの特定の例では、これらのベクトルは、パラメータ・ブロックのバイト０～１５およびバイト２４～２５にそれぞれ格納される。これらのベクトルの各々が、以下でさらに説明される。
一例として、インストール済み機能ベクトル３４２のビット０～１２７は、デフレート変換呼び出し命令の機能コード０～１２７にそれぞれ対応する。あるビットが例えば１である場合、対応する機能がインストールされており、そうでない場合、その機能はインストールされていない。
さらに、１つの例では、インストール済みパラメータ・ブロック形式ベクトル３４６のビット０～１５が、ＤＦＬＴＣＣ－ＧＤＨＴ機能、ＤＦＬＴＣＣ－ＣＭＰＲ機能および、ＤＦＬＴＣＣ－ＸＰＮＤ機能のパラメータ・ブロック形式０～１５にそれぞれ対応する。あるビットが例えば１である場合、対応するパラメータ・ブロック形式がインストールされており、そうでない場合、そのパラメータ・ブロック形式はインストールされていない。１つの例では、パラメータ・ブロックの予備のバイト１６～２３および２６～３１には０が格納される。
パラメータ・ブロック３４０に関して特定のフィールドが説明されているが、他の実施形態では、追加のフィールド、より少ないフィールド、またはその他のフィールド、あるいはその組み合わせが含まれてよい。
１つの実施形態では、ＤＦＬＴＣＣ－ＱＡＦ機能によって汎用レジスタＲ１、Ｒ２、Ｒ３、Ｒ１＋１、およびＲ２＋１の内容が無視される。
パラメータ・ブロックに関して、適用可能な場合、ＰＥＲ（program eventrecording：プログラム・イベント記録）ストレージ変更イベントが認識される。パラメータ・ブロックに関して、適用可能な場合、ＰＥＲゼロ・アドレス検出イベントが認識される。
１つの例では、ＤＦＬＴＣＣ－ＱＡＦ機能の実行が完了したときに、条件コード０が設定され、条件コード１、２、および３は、照会機能には適用できない。
機能コード１：ＤＦＬＴＣＣ－ＧＤＨＴ（動的ハフマン・テーブルの生成）
ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、デフレート規格によって規定されているように、第２のオペランドは、例えば、動的ハフマン・テーブル（ＤＨＴ）の圧縮表現を生成するためのソースとして使用される。
１つの例では、ＤＦＬＴＣＣ－ＧＤＨＴ機能はパラメータ・ブロックを使用し、その例が図３Ｋを参照して説明される。本明細書に記載された例示的なパラメータ・ブロックでは、特定のフィールドのパラメータ・ブロック内の特定の位置、およびフィールドの特定のサイズが（例えば、特定のバイトまたはビットあるいはその両方で）示される。しかし、フィールドのうちの１つまたは複数の他の位置またはサイズあるいはその両方が提供されてよい。さらに、特定の値（例えば、１または０）へのビットの設定が指定されるが、これは単なる例である。ビットは、他の例では、反対の値または別の値などの異なる値に設定されてよい。多くの変形が可能である。
さらに、１つの例では、パラメータ・ブロックが、１つまたは複数の保存フィールド（preserved fields）および１つまたは複数の予備フィールドを含む。保存フィールドは、ＤＦＬＴＣＣ－ＧＤＨＴ機能によって変更されない。保存フィールドは、プログラムが単一のストレージ位置を初期化することを可能にする予備フィールドとは区別され、そのストレージ位置をＤＦＬＴＣＣ－ＧＤＨＴ機能のパラメータ・ブロックに使用し、その後、同じストレージ位置をＤＦＬＴＣＣ－ＣＭＰＲ機能のパラメータ・ブロックに使用する。予備フィールドは０を含むべきである。そうでない場合、プログラムは将来、互換性を維持して動作しなくなることがある。動作が終了するときに、予備フィールドは、０として格納されてよく、または変化しなくてよい。
さらに、フィールドの一部が他の機能（例えば、ＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤ）によって使用され、したがって、それらのフィールドの説明と共に、それらの機能に関連する態様を説明することもできる。
１つの例では、ＤＦＬＴＣＣ－ＧＤＨＴ機能の場合、パラメータ・ブロック３６０は以下のフィールドを含む。
パラメータ・ブロック・バージョン番号（ＰＢＶＮ：Parameter Block Version Number）３６２：パラメータ・ブロックのバイト０～１は、パラメータ・ブロックのバージョンおよびサイズを指定する。ＰＢＶＮのビット０～１１は予備であり、０を含むべきである。そうでない場合、プログラムは将来、互換性を維持して動作しなくなることがある。ＰＢＶＮのビット１２～１５は、パラメータ・ブロックの形式を指定する符号なし２進整数を含む。ＤＦＬＴＣＣ－ＱＡＦ機能は、使用可能なパラメータ・ブロック形式を示すためのメカニズムを提供する。指定されたパラメータ・ブロックの形式がモデルによってサポートされていない場合、一般オペランド・データ例外が認識される。ＰＢＶＮは、プログラムによって指定され、命令の実行中に変更されない。
モデル・バージョン番号（ＭＶＮ：Model Version Number）３６３：パラメータ・ブロックのバイト２は、命令を実行したモデルを識別する符号なし２進整数である。プログラムがＭＶＮを初期化する必要はない。ＭＶＮは、命令の実行中に更新される。ＭＶＮに格納される値は、モデルに依存する。
動的ハフマン・テーブル（ＤＨＴ）生成制御（ＤＨＴＧＣ：Dynamic-Huffman Table (DHT) Generation Control）３６４：パラメータ・ブロックのバイト１７のビット２が、動的ハフマン・テーブル（ＤＨＴ）の生成に適用される。ＤＨＴは、リテラル・バイトを表すシンボルのハフマン・コード、重複列の長さ、ブロック終結（ＥＯＢ）シンボル、および重複列のポインタ距離を指定する。特定のシンボルのハフマン・コードの値は、データの圧縮されていない形態での、シンボルが表す実体の発生数に依って変わる。あるシンボルの発生数が０である場合、このシンボルのハフマン・コードはＤＨＴに存在しない。ＤＨＴＧＣは、１つの例では、０に等しい数が次のように扱われることを指定する。
ＤＨＴＧＣ 意味
０ ０に等しいリテラル・バイト、重複列の長さ、およびポインタ距離の数を、１に等しいとして扱う（汎用ＤＨＴ（universal DHT）を生成する）。
１ ０に等しい重複列の長さおよびポインタ距離の数を、１に等しいとして扱う。
リテラル・バイト、ＥＯＢシンボル、重複列の長さ、重複列のポインタ距離のすべての可能な値に対してハフマン・コードを指定するＤＨＴは、汎用ＤＨＴと呼ばれる。データの圧縮されていない形態で発生しないリテラル・バイト、重複列の長さ、または重複列のポインタ距離の値に対してハフマン・コードを指定しないＤＨＴは、非汎用ＤＨＴと呼ばれる。
デフレート規格によって規定されているように、ＤＨＴＧＣのすべての値に関して得られたＤＨＴは、すべての可能な重複列の長さおよびポインタ距離に対してハフマン・コードを指定する。したがって、下でさらに説明されているように、ＤＨＴの得られた圧縮された形態のＨＬＩＴ（ハフマン・リテラル（Huffman literal））部分要素およびＨＤＩＳＴ（ハフマン距離）部分要素は、例えば２９の値をそれぞれ含む。
ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、ＤＨＴＧＣが動作への入力である。ＤＦＬＴＣＣ－ＣＭＰＲ機能またはＤＦＬＴＣＣ－ＸＰＮＤ機能が指定された場合、ＤＨＴＧＣは動作に適用されない。１つの実施形態では、ＤＨＴＧＣは、命令の実行中に変更されない。
動作終了補助コード（ＯＥＳＣ：Operation Ending Supplemental Code）３６５：パラメータ・ブロックのバイト１９は、プログラムに報告されている条件に関する追加情報を提供する符号なし２進整数である。このフィールドは複数の機能によって使用されるため、条件の一部は、他の機能によって使用されるパラメータ・ブロック（例えば、ＤＦＬＴＣＣ－ＣＭＰＲ機能およびＤＦＬＴＣＣ－ＸＰＮＤ機能によって使用される図３Ｌのパラメータ・ブロック）のフィールドを参照する。報告されている条件が一般オペランド・データ例外である場合、パラメータ・ブロックのＯＥＳＣフィールドが更新されるが、動作は抑制されたと見なされ、その場合、１つの例では、ＯＥＳＣフィールドが次のように定義される。
ＯＥＳＣ（１６進数） 意味
００ 追加情報が提供されない。
０１ パラメータ・ブロック・バージョン番号３６２によって指定されたパラメータ・ブロックの形式が、モデルによってサポートされない。
０２ ＤＦＬＴＣＣ－ＣＭＰＲ機能またはＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、履歴長フィールド３８５（図３Ｌ）が例えば３２，７６８より大きく、新しいタスク・フィールド３７４（図３Ｌ）が０である。
１１ ＢＴＹＰＥ（ブロック・タイプ）が２進数１１に等しい圧縮データ・ブロックが発生する。
１２ ＢＴＹＰＥが２進数００に等しい圧縮データ・ブロック、およびＬＥＮ（長さ）の１の補数に等しくないＮＬＥＮが発生する。
２１ ＣＤＨＴＬフィールド３６６（図３Ｌ）が適用され、例えば、４２より小さいか、または２２８３より大きい。
２２ 動作中に使用される圧縮されたＤＨＴのＨＬＩＴ部分要素が、例えば２９より大きい（無効なＤＨＴ）。
２３ 動作中に使用される圧縮されたＤＨＴのＨＤＩＳＴ部分要素が、例えば２９より大きい（無効なＤＨＴ）。
２４ 動作中に使用される圧縮されたＤＨＴが、圧縮されたＤＨＴに対して定義された可能な（例えば、１９個の）コード長のビット長を指定するコードのシーケンス内にある、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコードを指定する（無効なＤＨＴ）。
２６ 動作中に使用される圧縮されたＤＨＴが、リテラル・バイト、ＥＯＢシンボル、および重複列の長さで構成されている要素のセットの第１のコード長としてコード長１６（前のコード長のコピー）を指定する（無効なＤＨＴ）。
２７ 動作中に使用される圧縮されたＤＨＴが、リテラル・バイトのコード長を指定するコードのシーケンス内にあるコードを指定し、このコードが、圧縮されたＤＨＴ内で前に指定された、参照されるコード長のセットを表すために決定されたコードのいずれにも一致しない（無効なＤＨＴ）。
２８ 動作中に使用される圧縮されたＤＨＴが、コード長０（ＣＬ０）をＥＯＢシンボルに割り当てるコードを指定する。この場合、対応するＤＨＴが、ＥＯＢシンボルを表すためのハフマン・コードを指定しない（無効なＤＨＴ）。
２９ 動作中に使用される圧縮されたＤＨＴが、重複列の長さおよびポインタ距離のコード長を指定するコードのシーケンス内にあるコードを指定し、このコードが、圧縮されたＤＨＴ内で前に指定された、参照されるコード長のセットを表すために決定されたコードのいずれにも一致しない（無効なＤＨＴ）。
２Ａ 動作中に使用される圧縮されたＤＨＴが、ＨＬＩＴフィールド、ＨＤＩＳＴフィールド、および例えば２５８の値の和によって指定された、ＤＨＴ内のハフマン・コードの数より大きいコード長の数を指定する。これは、例えば、コード長１６、１７、および１８の不適切な使用を伴っている可能性がある（無効なＤＨＴ）。
２Ｂ 動作中に使用される圧縮されたＤＨＴが、リテラル・バイト、ＥＯＢシンボル、および重複列の長さのセットに対して、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコード長を指定する（無効なＤＨＴ）。
２Ｄ 動作中に使用される圧縮されたＤＨＴが、重複列のポインタ距離のセットに対して、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコード長を指定する（無効なＤＨＴ）。
２Ｆ ＣＤＨＴＬフィールド３６６（図３Ｌ）が適用され、動作中に使用されるＣＤＨＴフィールド３６７（図３Ｌ）内の圧縮されたＤＨＴの長さに等しくない。
３１ 動作中に使用される圧縮されたＤＨＴが、動作中に処理されるリテラル・バイトまたは重複列の長さに対応するハフマン・コードを指定しないか（不完全な非汎用ＤＨＴ）、またはＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、ＢＴＹＰＥが２進数０１に等しい圧縮データ・ブロック内で発生する圧縮データ・シンボルが、重複列の長さに対して無効なコード（２進数１１０００１１０または１１０００１１１）を指定する。
３２ 動作中に使用される圧縮されたＤＨＴが、動作中に処理される重複列のポインタ距離に対応するハフマン・コードを指定しないか（不完全な非汎用ＤＨＴ）、またはＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、ＢＴＹＰＥが２進数０１に等しい圧縮データ・ブロック内で発生する圧縮データ・シンボルが、重複列のポインタ距離に対して無効なコード（２進数１１１１０または１１１１１）を指定する。
４０ 重複列のポインタであり、シンボルを処理する時点で使用可能な履歴の長さより大きい距離を指定する圧縮データ・シンボルが発生する。
一般オペランド・データ例外を報告せずに動作が終了した場合、０がＯＥＳＣフィールドに格納される。
０以外の補助コードのサポートは、モデルに依存する。複数の条件が存在する場合、コードがもしあれば、どのコードがＯＥＳＣフィールドに報告されるかは、モデルに依存する。
圧縮された動的ハフマン・テーブルの長さ（ＣＤＨＴＬ：Compressed Dynamic-Huffman Table Length）３６６：パラメータ・ブロックのバイト５６のビット４からバイト５７のビット７までの１２ビットが、パラメータ・ブロックのＣＤＨＴフィールド（例えば、ＣＤＨＴ３６７）内の圧縮形式のＤＨＴの長さをビット数として指定する符号なし２進整数を含む。
ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、ＣＤＨＴＬが動作からの出力である。
ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、ハフマン・テーブル・タイプ（例えば、図３ＬのＨＴＴ３７６）が１である場合、ＣＤＨＴＬが動作への入力である。ＣＤＨＴＬがＣＤＨＴの適切な長さを指定しない場合、一般オペランド・データ例外が認識される。ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定された場合、ＣＤＨＴＬは変更されない。
ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、ＢＴＹＰＥが２進数１０であるブロックの一部のみをデコードした後に動作が終了した場合、ブロック内のＤＨＴの圧縮表現の長さがこのフィールドに格納される。ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、ブロック境界で、またはＢＴＹＰＥが２進数００または０１であるブロックの一部のみをデコードした後に、動作が終了した場合、０がこのフィールドに格納される。ＢＴＹＰＥが２進数１０であるブロック内で復元動作が再開された場合（すなわち、下で説明されるように、ＣＦ（図３Ｌの継続フラグ３７３）が１に等しく、ＩＦＳ（incomplete function status：不完全な機能の状態３８３）が１６進数ＣまたはＤに等しい場合）、このフィールドが動作への入力である。
圧縮された動的ハフマン・テーブル（ＣＤＨＴ：Compressed Dynamic-Huffman Table）３６７：パラメータ・ブロックのバイト６４～３５１は、動的ハフマン・テーブル（ＤＨＴ）の圧縮形式を含む。
ＤＨＴは、要素の２つのセットを表すためのハフマン・コード（ビット・シーケンス）を指定する。１つのセットの要素は、リテラル・バイト、ＥＯＢシンボル、および重複列の長さを含む。他のセットの要素は、重複列のポインタ距離を含む。ＤＨＴの圧縮表現は、コード長のセットを定義し、各セットの要素ごとにコード長（ＣＬ：code length）を指定する。動作中に参照されることが期待される要素のハフマン・コードは、その要素に対して指定されたＣＬ、および同じ指定されたＣＬを持つ同じセット内の要素の数から導出される。具体的には、ＤＨＴの圧縮表現は、一例として以下を含む。
・リテラル・バイト、ＥＯＢシンボル、および重複列の長さを表すハフマン・コードの数を指定するためのＨＬＩＴフィールド。
・重複列のポインタ距離を表すハフマン・コードの数を指定するためのＨＤＩＳＴフィールド。
・コード長を表すハフマン・コードの数を指定するためのＨＣＬＥＮ（ハフマン・コード長）フィールド。
・圧縮されたＤＨＴに対して定義された例えば１９個のコード長の各々に対してビット長を指定するコードのシーケンス。
・リテラル・バイト、ＥＯＢシンボル、および重複列の長さで構成されるセットの要素の各々に対してコード長を指定するコードのシーケンス。
・重複列のポインタ距離で構成されるセットの要素の各々に対してコード長を指定するコードのシーケンス。
ＤＨＴの圧縮表現の詳細が、ブロック・タイプが２進数１０である圧縮データ・ブロックの説明を参照して下でさらに説明される。
１つの例では、ＤＨＴの圧縮表現は、ＣＤＨＴフィールド内で左詰めにされる。すなわち、バイト６４の右端のビットが、ＤＨＴの圧縮表現のＨＬＩＴ部分要素の最下位ビットを含む。
ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、ＤＨＴの圧縮表現が動作からの出力である。
ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、下で説明されるＨＴＴが１である場合、ＤＨＴの圧縮表現が動作への入力である。ＣＤＨＴフィールドは、ＤＦＬＴＣＣ－ＣＭＰＲ機能によって変更されない。
ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、ＢＴＹＰＥが２進数１０であるブロックの一部のみをデコードした後に動作が終了した場合、ブロック内のＤＨＴの圧縮表現がこのフィールドに格納される。ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、ブロック境界で、またはＢＴＹＰＥが２進数００または０１であるブロックの一部のみをデコードした後に、動作が終了した場合、０がこのフィールドに格納される。ＢＴＹＰＥが２進数１０であるブロック内で復元動作が再開された場合（すなわち、ＣＦが１に等しく、ＩＦＳが１６進数ＣまたはＤに等しい場合）、このフィールドが動作への入力である。
ＣＤＨＴが変更される場合、ＤＨＴの圧縮表現を表すために使用されないフィールドのビットが０として格納される。
パラメータ・ブロック３６０に関してさまざまなフィールドが上で説明されたが、他の実施形態では、追加のフィールド、より少ないフィールド、またはその他のフィールド、あるいはその組み合わせが含まれてよい。
ＤＨＴ生成の態様は、プログラムによって、パラメータ・ブロックの動的ハフマン・テーブル生成制御（ＤＨＴＧＣ）フィールド３６４を使用して、マシンに対して指定される。ソースが圧縮されていないデータを含み、動作の完了後に、生成された結果が、同じソースを圧縮するためのＤＦＬＴＣＣ－ＣＭＰＲ機能と共に指定されるということが、意図される。
１つの実施形態では、現在の動作の処理中に、参照するための前の動作からの履歴が存在しない。
汎用レジスタＲ２＋１の内容が、例えば３２Ｋバイトよりも大きい長さを指定する場合、１つの例では以下が当てはまる。
・第２のオペランドの最初の３２Ｋバイトのみが、ＤＨＴを生成するために使用される。
・第２のオペランドの最初の３２Ｋバイトを超える位置に対して、アクセス例外が認識されない。
汎用レジスタＲ２＋１の内容が、０に等しい長さを指定する場合、指定例外が認識され、第２のオペランドがアクセスされない。
得られた圧縮されたＤＨＴは、ブロック終結（ＥＯＢ）シンボルを表すハフマン・コードを含む。
生成された圧縮形式のＤＨＴが、パラメータ・ブロックの圧縮された動的ハフマン・テーブル（ＣＤＨＴ）フィールド３６７に格納される。生成された圧縮形式のＤＨＴの長さが、パラメータ・ブロックのＣＤＨＴＬフィールド３６６に格納される。
この動作は、モデル識別情報をパラメータ・ブロックのモデル・バージョン番号フィールド３６３に格納することを含む。
一般オペランド・データ例外を認識せずに動作が終了した場合、パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５に０が格納される。
ＤＦＬＴＣＣ－ＧＤＨＴ機能の実行が完了したときに、条件コード０が設定され、条件コード１、２、および３は、ＤＦＬＴＣＣ－ＧＤＨＴ機能に適用できない。
この動作によって、汎用レジスタＲ２およびＲ２＋１は変更されない。
ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、汎用レジスタＲ１、Ｒ１＋１、およびＲ３の内容が無視される。
第２のオペランドの位置およびパラメータ・ブロックに関して、適用可能な場合、ＰＥＲゼロ・アドレス検出イベントが認識される。
機能コード２：ＤＦＬＴＣＣ－ＣＭＰＲ（圧縮）
ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定された場合、圧縮動作が実行される。この動作は、第２のオペランドの位置のデータを、第１のオペランドの位置に格納される圧縮データ・シンボルにエンコードすることを含む。
１つの例では、ＤＦＬＴＣＣ－ＣＭＰＲ機能はパラメータ・ブロックを使用し、その例が図３Ｌを参照して説明される。フィールドの一部は、パラメータ・ブロック３６０に関して上で説明されているため、以下では同じ参照番号で示され、さらに詳細には説明されない。
１つの例では、パラメータ・ブロック３７０は以下を含む。
パラメータ・ブロック・バージョン番号（ＰＢＶＮ）３６２。
モデル・バージョン番号（ＭＶＮ）３６３。
継続フラグ（ＣＦ）３７３：パラメータ・ブロックのビット６３は、１である場合、動作が部分的に完了していることを示し、継続状態バッファ（例えば、継続状態バッファ・フィールド３９２）の内容が、動作を再開するために使用されてよい。プログラムは、継続フラグ（ＣＦ）を０に初期化し、動作を再開する目的で命令が再実行される場合にＣＦを変更しないようにするべきであり、そうでない場合、結果が予測不可能になる。
新しいタスク（ＮＴ）３７４：パラメータ・ブロックのバイト１６のビット０は、１である場合、動作が圧縮データ・セットの先頭に適用されることを示す。したがって、前の動作からの履歴およびチェック値が現在の動作に適用されない。動作の開始時にＮＴが１であり、部分的完了の後に動作が終了した場合、０がＮＴフィールドに格納される。ＮＴが０である場合、前の動作からの履歴およびチェック値が現在の動作に適用される。
チェック値タイプ（ＣＶＴ：Check Value Type）３７５：パラメータ・ブロックのバイト１６のビット２は、パラメータ・ブロックのチェック値フィールド（例えば、フィールド３８７）に含まれているチェック値のタイプを指定する。ＣＶＴが０である場合、チェック値タイプは、例えば３２ビットの巡回冗長チェック（ＣＲＣ－３２）である。ＣＶＴが１である場合、チェック値タイプは、例えば３２ビットのアドラー・チェックサム（Ａｄｌｅｒ－３２）である。ＣＶＴビットは、命令の実行中に変更されない。
ハフマン・テーブル・タイプ（ＨＴＴ：Huffman Table Type）３７６：パラメータ・ブロックのバイト１６のビット４は、０である場合、デフレート規格によって規定されているように、固定ハフマン・コードを含むテーブル（ＦＨＴ）を指定し、圧縮動作中に使用される。ＨＴＴが１である場合、パラメータ・ブロックのＣＤＨＴフィールドにおいて指定された、動的ハフマン・コードを含むテーブル（ＤＨＴ）が、圧縮動作中に使用される。ＨＴＴは、復元動作には適用されない。ＨＴＴビットは、命令の実行中に変更されない。
ブロック継続フラグ（ＢＣＦ：Block Continuation Flag）３７７：ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定された場合、パラメータ・ブロックのバイト１６のビット５が適用される。０である場合、３ビットのブロック・ヘッダー、および適用可能な場合、パラメータ・ブロックのＣＤＨＴフィールド（例えば、フィールド３６７）において指定された動的ハフマン・テーブルの圧縮形式が、圧縮データ要素を格納する前に、第１のオペランドの位置に格納される。１である場合、ブロック・ヘッダーも圧縮形式のＤＨＴも、第１のオペランドの位置に格納されない。ＮＴが１である場合、ＢＣＦが０に等しいとして扱われる。ＢＣＦビットは、命令の実行中に変更されない。
ブロック終了制御（ＢＣＣ：Block Closing Control）３７８：ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定された場合、パラメータ・ブロックのバイト１６のビット６が適用される。１である場合、すべての圧縮データ・シンボルを格納した後に、ブロック終結（ＥＯＢ）シンボルが第１のオペランドの位置に格納される。ＨＴＴがＦＨＴを使用することを指定する場合、一例として、２進数０００００００のハフマン・コード（リテラル・バイト、ＥＯＢシンボル、および重複列の長さのコードを指定するテーブル内の２５６の中間整数表現に対応する）がＥＯＢシンボルに使用される。ＨＴＴがＤＨＴを使用することを指定する場合、ＥＯＢシンボルのハフマン・コードがＤＨＴ内で指定される。ＢＣＣビットが０である場合、ＥＯＢシンボルが第１のオペランドの位置に格納されない。ＢＣＣビットは、命令の実行中に変更されない。
ブロック・ヘッダー終端（ＢＨＦ：Block Header Final）３７９：ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、ＢＣＦ３７７が０であるか、またはＮＴ３７４が１である場合、パラメータ・ブロックのバイト１６のビット７が適用され、そうでない場合、ＢＨＦが適用されない。適用可能であり、１である場合、ブロック・ヘッダーを第１のオペランドの位置に格納する前に、ブロック・ヘッダーの最初のビット（ＢＦＩＮＡＬ）が１に設定される。適用可能であり、０である場合、ブロック・ヘッダーを第１のオペランドの位置に格納する前に、ブロック・ヘッダーの最初のビット（ＢＦＩＮＡＬ）が０に設定される。ＢＨＦビットは、命令の実行中に変更されない。
ＤＨＴ生成制御（ＤＨＴＧＣ）３６４：ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定された場合、ＤＨＴＧＣは動作に適用されない。ＤＨＴＧＣは、命令の実行中に変更されない。
サブバイト境界（ＳＢＢ）３８１：パラメータ・ブロックのバイト１８のビット５～７は、圧縮データ・ストリームのバイト内の処理済みのビットと未処理のビットの間の境界を指定する符号なし２進整数を含む。参照されるストリームのバイトは、動作が終了するとき、参照される最後のバイト（つまり、右端のバイト）であり、動作が開始または再開するとき、参照される最初のバイト（つまり、左端のバイト）である。ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定された場合、ＳＢＢは、第１のオペランド・アドレスによって指定されたバイトに適用される。ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定された場合、ＳＢＢは、第２のオペランド・アドレスによって指定されたバイトに適用される。ＳＢＢは、処理された右端のビットの数を指定する。ＳＢＢは、動作への入力および動作の出力である。
ＳＢＢが２進数０１１の値を含む場合の圧縮データ・ストリームの一例が、図４に示されている。動作の終了後の処理されたデータが４００に示されており、動作の開始前の処理されるデータが４０２に示されている。
さらに、図５Ａ～５Ｃは、ＤＦＬＴＣＣ－ＣＭＰＲ機能へのＳＢＢの適用方法を示す例を提供する。例えば、ＤＦＬＴＣＣ－ＣＭＰＲ機能を実行する前後のＳＢＢの適用方法の一例が、図５Ａに示されている。その他の例が、図５Ｂ～５Ｃに示されている。ＮＴ３７４が１である場合、ＳＢＢ３８１が２進数０００に等しいとして扱われる。
図３Ｌを参照して、パラメータ・ブロック３７０の追加のフィールドが説明される。
動作終了補助コード（ＯＥＳＣ）３６５。
不完全な機能の状態（ＩＦＳ）３８３：パラメータ・ブロックのバイト２１のビット４～７は、特定の動作が終了するときの状態情報を含む。復元動作が終了するときに、ＩＦＳは、１つの例では、次のように第２のオペランドに関する情報を伝達する。
ＩＦＳ（２進数） 意味
００００ ＢＦＩＮＡＬが１に等しいブロックの最後の要素をデコードした後に、動作が終了した。
１０００ ＢＴＹＰＥが２進数００に等しく、ＢＦＩＮＡＬが０に等しいブロックの最後の要素以外の要素をデコードした後に、動作が終了した。
１００１ ＢＴＹＰＥが２進数００に等しく、ＢＦＩＮＡＬが１に等しいブロックの最後の要素以外の要素をデコードした後に、動作が終了した。
１０１０ ＢＴＹＰＥが２進数０１に等しく、ＢＦＩＮＡＬが０に等しいブロックの最後の要素以外の要素をデコードした後に、動作が終了した。
１０１１ ＢＴＹＰＥが２進数０１に等しく、ＢＦＩＮＡＬが１に等しいブロックの最後の要素以外の要素をデコードした後に、動作が終了した。
１１００ ＢＴＹＰＥが２進数１０に等しく、ＢＦＩＮＡＬが０に等しいブロックの最後の要素以外の要素をデコードした後に、動作が終了した。
１１０１ ＢＴＹＰＥが２進数１０に等しく、ＢＦＩＮＡＬが１に等しいブロックの最後の要素以外の要素をデコードした後に、動作が終了した。
１１１０ 動作がブロック境界で終了しており、ＢＦＩＮＡＬが１に等しいブロックの最後の要素がデコードされておらず、その後のブロックのブロック・ヘッダーの最初の要素がまだ処理されていない。
１つの実施形態では、復元動作が、２進数００００に等しいＩＦＳを伴って終了し、正常完了を満たさないことがある。そのような場合、条件コード１または３が設定されて動作が終了する。
圧縮動作が終了するときに、ＩＦＳフィールドは定義されないが、変更されてよい。
ＩＦＳは動作への入力ではない。
不完全な機能の長さ（ＩＦＬ：Incomplete Function Length）３８４：パラメータ・ブロックのバイト２２～２３は、特定の動作が終了するときの長さの情報を含む。復元動作の場合、ＩＦＬが第２のオペランドに適用される。ＢＴＹＰＥが２進数００に等しいブロックの全部ではなく一部をデコードした後に、復元動作が終了した場合、ＩＦＬは、第２のオペランド内のまだ処理されていないブロックのバイト数を指定する符号なし２進整数を含む。バイト２２～２３は、ＢＴＹＰＥが２進数００に等しいブロックの、例えばリトルエンディアン・バイト・オーダーであるＬＥＮフィールドとは異なり、例えばビッグエンディアン・バイト・オーダーでＩＦＬを含む。
ＢＴＹＰＥが２進数００に等しく、ＢＦＩＮＡＬが１に等しい完全なブロックをデコードした後に、復元動作が終了した場合、０がＩＦＬフィールドに格納される。復元動作が、ＢＴＹＰＥが０以外であるブロックの全部ではなく一部をデコードした後に終了するか、またはブロック境界で終了した場合、ＩＦＬフィールドは定義されないが、変更されてよい。
圧縮動作が終了するときに、ＩＦＬフィールドは定義されないが、変更されてよい。
ＩＦＬは動作への入力ではない。
履歴長（ＨＬ：History Length）３８５：パラメータ・ブロックのバイト４４～４５は、動作中に参照できる履歴バッファ内の履歴のバイト数を指定する符号なし２進整数を含む。ＨＬは、直列履歴バッファおよび円形履歴バッファに適用される。新しいタスク（ＮＴ）が１に等しい場合、履歴は動作の開始時に適用されず、動作への入力としての履歴長は、０として扱われる。
履歴長が例えば３２，７６８より大きく、ＮＴが０に等しい場合、一般オペランド・データ例外が認識される。
圧縮動作中および復元動作中に、履歴長が変更される。元のＨＬと、動作中に処理された圧縮されていないデータのバイト数との和が、例えば３２，７６８以下である場合、更新されたＨＬは、元のＨＬと、動作中に処理された圧縮されていないデータのバイト数との和に等しく、そうでない場合、更新されたＨＬは３２，７６８の値に等しい。
履歴オフセット（ＨＯ：History Offset）３８６：パラメータ・ブロックのバイト４６のビット１からバイト４７のビット７までの１５ビットは、履歴バッファ・タイプが円形である場合の第３のオペランド内のオフセットを指定する符号なし２進整数を含む。Ｒ３の内容および履歴オフセットの和は、円形履歴バッファ内の履歴の最初のバイトの位置を指定し、このバイトは、バッファ内の圧縮されていないデータのうちの処理されてから最も長い時間が経過したバイトである。履歴バッファ・タイプが円形である場合、履歴オフセットは動作への入力であり、動作の終了時に更新される。元のＨＬと、動作中に処理された圧縮されていないデータのバイト数との和が、例えば３２，７６８以下である場合、更新されたＨＯは、元のＨＬＯに等しく、そうでない場合、更新されたＨＯは、元のＨＯ、元のＨＬ、および動作中に処理された圧縮されていないデータのバイト数の和を３２，７６８で割った余りに等しい。
履歴バッファ・タイプが直列である場合、パラメータ・ブロックのＨＯフィールドは定義されないが、変更されてよい。
チェック値３８７：パラメータ・ブロックのバイト４８～５１はチェック値を含む。動作の一部として、チェック値が生成される。チェック値は、圧縮されていないデータ・オペランドに適用される。すなわち、チェック値は、ＤＦＬＴＣＣ－ＣＭＰＲ機能の場合、第２のオペランドに適用され、ＤＦＬＴＣＣ－ＸＰＮＤ機能の場合、第１のオペランドに適用される。ＣＶＴビット３７５が０である場合、例えば３２ビットの巡回冗長チェックのチェック値（ＣＲＣ－３２）が生成される。ＣＶＴビットが１である場合、例えば３２ビットのアドラー・チェックサムのチェック値（Ａｄｌｅｒ－３２）が生成される。
チェック値を生成するための入力は、例えば、４バイトのベース、および動作中に処理される圧縮されていないデータである。ベース入力は、圧縮データ・ブロックの完全なセットを処理するためにＤＦＬＴＣＣ命令が実行される回数に関わらず、圧縮データ・ブロックのセットに対して単一の一貫したチェック値を計算するための手段を提供する。ＮＴビットが０である場合、チェック値フィールド内の元の値が、チェック値の生成においてベース入力に使用される。
Ａｄｌｅｒ－３２チェック値が生成される場合、１つの例では、以下が適用される。
・ＮＴビットが１である場合、１の値が４バイトのベース入力に使用される。
・Ａｄｌｅｒ－３２チェック値生成において定義された和を６５，５２１で割った余りが計算される。
・その結果が、ビッグエンディアン・バイト・オーダーでチェック値フィールドに格納される。すなわち、チェック値の最上位バイトがバイト４８に位置し、チェック値の最下位バイトがバイト５１に位置する。
ＣＲＣ－３２チェック値が生成される場合、１つの例では、以下が適用される。
・ＮＴビットが１である場合、０の値が４バイトのベース入力に使用される。
・ＣＲＣ－３２チェック値の生成において除数として使用される多項式は、ｘ３２＋ｘ２６＋ｘ２３＋ｘ２２＋ｘ１６＋ｘ１２＋ｘ１１＋ｘ１０＋ｘ８＋ｘ７＋ｘ５＋ｘ４＋ｘ２＋ｘ１＋ｘ０であり、１６進数１０４Ｃ１１ＤＢ７として表される。この表現では、左端のビットが最上位ビットに対応する。
・チェック値を生成する最初の段階では、ベース入力の１の補数を計算し、最後の段階では、結果を格納する前に、結果の１の補数を計算する。
・その結果が、リトルエンディアン・バイト・オーダーでチェック値フィールドに格納される。すなわち、チェック値の最下位バイトがバイト４８に位置し、チェック値の最上位バイトがバイト５１に位置する。
１つの例では、条件コード０が設定されて動作が終了する場合にのみ、チェック値はプログラムにとって意味を持ち、そうでない場合、チェック値は、単に中間結果であり、動作を再開することのみのために意味を持つ。ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、条件コード１、２、または３が設定されて動作が終了した場合、第２のオペランド・アドレスによって指定されたバイトの左にある一部のバイトが、得られたチェック値の計算に含まれていないことがある。ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、条件コード１、２、または３が設定されて動作が終了した場合、第１のオペランド・アドレスによって指定されたバイトの右にあるまだ格納されていない一部の結果のバイトが、得られたチェック値の計算にすでに含まれていることがある。
ブロック終結シンボル（ＥＯＢＳ：End-Of-Block Symbol）３８８：パラメータ・ブロックのバイト５２のビット０からバイト５３のビット６までの１５ビットは、ブロック終結（ＥＯＢ）シンボルを含む。パラメータ・ブロックのブロック終結の長さ（ＥＯＢＬ：end-of-block length）フィールド３８９は、ＥＯＢＳフィールド内のＥＯＢシンボルの長さを指定する。ＥＯＢシンボルは、ＥＯＢＳフィールド内で左詰めにされる。ＥＯＢシンボルによって占められないＥＯＢＳフィールドのビットは、０として格納される。どのタイプのハフマン・テーブルが適用されるかに関わらず、データを圧縮する場合、ＥＯＢＳフィールドは動作の出力である。ＥＯＢＳフィールドは、動作への入力として使用されない。
バイト５２のビット０は、ＥＯＢシンボルの最上位ビットを含む。ＥＯＢシンボルの長さが７ビットである場合、バイト５２のビット６がＥＯＢシンボルの最下位ビットを含む。ＥＯＢシンボルの長さが１５ビットである場合、バイト５３のビット６がＥＯＢシンボルの最下位ビットを含む。
ＦＨＴを使用するブロックの場合、デフレート規格によって規定されているように、ＥＯＢシンボルは２進数０００００００である。ＤＨＴを使用するブロックの場合、ＥＯＢシンボルはＤＨＴによって定義される。ＥＯＢシンボルは、ブロックを閉じる能力をプログラムに提供するために伝達される。
ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定された場合、ＥＯＢＳフィールドは定義されないが、変更されてよい。
ブロック終結の長さ（ＥＯＢＬ）３８９：パラメータ・ブロックのバイト５４のビット０～３は、パラメータ・ブロックのＥＯＢＳフィールド３８８内のブロック終結（ＥＯＢ）シンボルの長さを指定する符号なし２進整数を含む。この長さは、ＥＯＢＳフィールド内でＥＯＢシンボルが占めるビット数を指定する。どのタイプのハフマン・テーブルが適用されるかに関わらず、データを圧縮する場合、ＥＯＢＬフィールドは動作の出力である。ＥＯＢＬフィールドは、動作への入力として使用されない。
ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定された場合、ＥＯＢＬフィールドは定義されないが、変更されてよい。
圧縮された動的ハフマン・テーブルの長さ（ＣＤＨＴＬ）３６６。
圧縮された動的ハフマン・テーブル（ＣＤＨＴ）３６７：ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、ＨＴＴが１である場合、ＤＨＴの圧縮表現が動作への入力である。ＣＤＨＴフィールドは、ＤＦＬＴＣＣ－ＣＭＰＲ機能によって変更されない。
継続状態バッファ（ＣＳＢ：Continuation State Buffer）３９２：条件が、１の値がＣＦフィールド３７３に格納されることを引き起こした場合、内部状態データがパラメータ・ブロックのバイト３８４～１５３５に格納され、そうでない場合、パラメータ・ブロックのバイト３８４～１５３５が定義されず、変更されてよい。格納される内部状態データは、モデルに依存し、動作を再開するために、その後使用されてよい。プログラムが、例えばすべて０を含むように継続状態バッファを初期化することが期待されるが、これは必須ではない。０以外の条件コードが設定されて命令が終了した後に、動作を再開する目的で命令を再実行する前に、プログラムは継続状態バッファを変更するべきではなく、そうでない場合、結果が予測不可能になる。
パラメータ・ブロック３７０に関してさまざまなフィールドが上で説明されたが、他の実施形態では、追加のフィールド、より少ないフィールド、またはその他のフィールド、あるいはその組み合わせが含まれてよい。
以下では、データの圧縮に関して圧縮動作の一例が説明される。
第２のオペランド全体が圧縮され、第１のオペランドの位置に格納されたときに、ＤＦＬＴＣＣ－ＣＭＰＲ機能の正常完了が発生する。正常完了に起因して動作が終了した場合、１つの例では、以下が発生する。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックの継続フラグ（ＣＦ）フィールド３７３が０に設定される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックのブロック終結の長さ（ＥＯＢＬ）３８９フィールドおよびブロック終結シンボル（ＥＯＢＳ）３８８フィールドが更新される。
・パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５が更新される。
・適用可能な場合、パラメータ・ブロックの履歴オフセット（ＨＯ）フィールド３８６が更新される。
・パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５が０に設定される。
・パラメータ・ブロックのチェック値フィールド３８７が更新される。
・汎用レジスタＲ１内のアドレスが、ビット０の処理を含む第１のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第１のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された出力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・汎用レジスタＲ２内のアドレスが、処理されたソース・バイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。
・条件コード０が設定される。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
正常完了が発生した場合、動作の終了後に、パラメータ・ブロックのＣＳＢフィールド３９２が定義されない。
ＣＰＵによって決定されたバイト数が処理されたときに動作が終了し、１つの例では、以下が発生する。
・パラメータ・ブロック内の継続フラグ（ＣＦ）ビット３７３が１に設定される。
・パラメータ・ブロック内の継続状態バッファ（ＣＳＢ）フィールド３９２が更新される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５が更新される。
・適用可能な場合、パラメータ・ブロックの履歴オフセット（ＨＯ）フィールド３８６が更新される。
・パラメータ・ブロックのチェック値フィールド３８７が更新される。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックのブロック終結の長さ（ＥＯＢＬ）３８９フィールドおよびブロック終結シンボル（ＥＯＢＳ）３８８フィールドが更新される。
・パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５が０に設定される。
・汎用レジスタＲ１内のアドレスが、ビット０の処理を含む第１のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第１のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された出力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・汎用レジスタＲ２内のアドレスが、処理されたソース・バイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。
・条件コード３が設定される。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
ＣＰＵによって決定されたバイト数は、モデルによって決まり、命令が実行されるたびに異なる数であってよい。
条件コード３が設定されて命令が終了した後に、プログラムが命令に関する入力の仕様も、出力の仕様も変更せずに、分岐して戻り、命令を再実行して動作を再開することが期待される。
特定の状況では、条件コード３が設定されて命令を終了したにもかかわらず、パラメータ・ブロックおよび汎用レジスタが更新されない。このような状況は、ＣＰＵが静止動作（quiescing operation）を実行するか、またはＣＰＵがデフレート変換呼び出し命令の実行中に再試行するときに、発生することがある。そのような場合、ＣＰＵによって決定された処理済みのバイト数は０であり、データが第１のオペランドの位置に格納されていてよく、適用可能な場合、データが第３のオペランドの位置に格納されていてよく、対応する変更のビットが設定されている。
１つの例では、次の条件のいずれかが当てはまる場合、第１のオペランドの長さは、動作を完了するのに不十分である。
・汎用レジスタＲ１＋１の内容によって指定された第１のオペランドの長さが、命令の実行の開始時に０である。
・命令の実行中に第１のオペランドの長さが０に等しくなり、正常完了が発生しない。
１つの例では、汎用レジスタＲ１＋１の内容が０である場合、パラメータ・ブロックのＮＴフィールドおよびＳＢＢフィールド内の値に関わらず、第１のオペランドの長さは０である。
命令の実行中に第１のオペランドの長さが０に等しくなった場合、動作が終了し、１つの実施形態では以下が発生する。
・パラメータ・ブロック内の継続フラグ（ＣＦ）ビット３７３が１に設定される。
・パラメータ・ブロック内の継続状態バッファ（ＣＳＢ）フィールド３９２が更新される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５が更新される。
・適用可能な場合、パラメータ・ブロックの履歴オフセット（ＨＯ）フィールド３８６が更新される。
・パラメータ・ブロックのチェック値フィールド３８７が更新される。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックのブロック終結の長さ（ＥＯＢＬ）３８９フィールドおよびブロック終結シンボル（ＥＯＢＳ）３８８フィールドが更新される。
・パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５が０に設定される。
・汎用レジスタＲ１内のアドレスが、ビット０の処理を含む第１のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第１のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された出力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・汎用レジスタＲ２内のアドレスが、処理されたソース・バイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。
・条件コード１が設定される。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
命令の実行の開始時に第１のオペランドの長さが０である場合、動作が終了し、１つの実施形態では以下が発生する。
・条件コード１が設定される。
条件コード１が設定されて命令が終了した後に、プログラムが、第１のオペランドの長さ、第１のオペランド・アドレス、またはその両方を変更し、命令を再実行して動作を再開することが期待される。
以下に関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。
・下で説明されているように、パラメータ・ブロックに格納する。
・第１のオペランドの位置に格納する。
・第３のオペランドの位置に格納し、この格納が、例えば履歴バッファ・タイプ（ＨＢＴ）が１（円形）である場合に発生する。
パラメータ・ブロック全体がＰＥＲストレージ領域指定と重なる場合、パラメータ・ブロックに関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。パラメータ・ブロックの一部のみがＰＥＲストレージ領域指定と重なる場合、以下のうちのどれが発生するかは、モデルに依存する。
・パラメータ・ブロックに関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。
・格納されたパラメータ・ブロックの一部に関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。
ＨＢＴが１（円形）である場合、パラメータ・ブロック、第１のオペランドの位置、第２のオペランドの位置、および第３のオペランドの位置に関して、適用可能な場合、ＰＥＲゼロ・アドレス検出イベントが認識される。
条件コード２は、ＤＦＬＴＣＣ－ＣＭＰＲ機能に適用できない。
条件コード１または３が設定されて命令が終了するとき、第２のオペランドの位置から参照された入力データは、完全に処理されているか、または部分的にのみ処理されていてよい。入力データが部分的にのみ処理されている場合、パラメータ・ブロックの第１のオペランドの位置、第１のオペランド・アドレス、第１のオペランドの長さ、およびＳＢＢフィールドにおける結果は、更新された第２のオペランドのアドレスおよび長さと一致する状態を表さない。そのような場合、部分的に処理されたデータおよび内部状態情報が、パラメータ・ブロックのＣＳＢフィールドに配置されてよい。部分的に処理されたデータの量は、動作の終了時に存在する条件およびモデルによって決まる。一部のデータのみが部分的に処理されることがあるが、更新された第１のオペランド・アドレスによって指定された位置の左に格納された結果は完成しており、動作が再開するときに変更されない。さらに、その後、プログラムが命令を再実行して動作を再開することが期待され、そのとき、動作を再開する前に、ＣＳＢフィールドの内容が参照される。条件コード０が設定されて命令が終了した場合、すべてのデータが完全に処理されており、入力データおよび出力データに関連付けられたすべての結果が一貫した状態を表す。
０以外の条件コードが設定されて命令が終了した後に、動作を再開する目的で命令を再実行する前に、プログラムはパラメータ・ブロックのどのフィールドも変更するべきではなく、そうでない場合、結果が予測不可能になる。
機能コード４：ＤＦＬＴＣＣ－ＸＰＮＤ（展開）
ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定された場合、復元動作が実行される。この動作は、第２のオペランドの位置の圧縮データ・シンボルを、第１のオペランドの位置に格納される圧縮されていないデータにデコードすることを含む。
１つの例では、ＤＦＬＴＣＣ－ＸＰＮＤ機能はパラメータ・ブロックを使用し、その例が図３Ｋ～３Ｌに関して上で説明されている。
以下では、データの復元に関してＤＦＬＴＣＣ－ＸＰＮＤ動作の一例が説明される。
第２のオペランド内のデータ・セットの最後のブロックのすべての要素がデコードされ、すべての圧縮されていないデータが第１のオペランドの位置に格納されたときに、正常完了が発生する。ブロック・ヘッダーのＢＦＩＮＡＬビットが１である場合、データ・セットの最後のブロックが識別される。正常完了に起因して動作が終了した場合、１つの実施形態では、以下が発生する。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックの継続フラグ（ＣＦ）フィールド３７３が０に設定される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５が更新される。
・適用可能な場合、パラメータ・ブロックの履歴オフセット（ＨＯ）フィールド３８６が更新される。
・パラメータ・ブロックの圧縮された動的ハフマン・テーブル（ＣＤＨＴ）フィールド３６７および圧縮された動的ハフマン・テーブルの長さ（ＣＤＨＴＬ）フィールド３６６が０に設定される。
・パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５が０に設定される。
・パラメータ・ブロックのチェック値フィールド３８７が更新される。
・汎用レジスタＲ１内のアドレスが、第１のオペランドの位置に格納されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。
・汎用レジスタＲ２内のアドレスが、ビット０の処理を含む第２のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第２のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された入力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・条件コード０が設定される。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
正常完了が発生した場合、動作の終了後に、パラメータ・ブロックのＣＳＢフィールド３９２が定義されない。
ＣＰＵによって決定されたバイト数が処理されたときに動作が終了し、１つの実施形態では、以下が発生する。
・パラメータ・ブロック内の継続フラグ（ＣＦ）ビット３７３が１に設定される。
・パラメータ・ブロック内の継続状態バッファ（ＣＳＢ）フィールド３９２が更新される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックの圧縮された動的ハフマン・テーブル（ＣＤＨＴ）フィールド３６７および圧縮された動的ハフマン・テーブルの長さ（ＣＤＨＴＬ）フィールド３６６が更新される。ＢＴＹＰＥ値が２進数１０であるブロックを処理しているときに部分的完了が発生した場合、テーブルを表すために必要とされないＣＤＨＴフィールドのバイトが０として格納される。ＢＴＹＰＥ値が２進数００または０１であるブロックを処理しているときに部分的完了が発生した場合、ＣＤＨＴフィールドおよびＣＤＨＴＬフィールドに０が格納される。
・パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５が更新される。
・適用可能な場合、パラメータ・ブロックの履歴オフセット（ＨＯ）フィールド３８６が更新される。
・パラメータ・ブロックのチェック値フィールド３８７が更新される。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５が０に設定される。
・パラメータ・ブロックの不完全な機能の状態（ＩＦＳ）フィールド３８３が更新される。
・適用可能な場合、パラメータ・ブロックの不完全な機能の長さ（ＩＦＬ）フィールド３８４が更新される。
・汎用レジスタＲ１内のアドレスが、第１のオペランドの位置に格納されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。
・汎用レジスタＲ２内のアドレスが、ビット０の処理を含む第２のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第２のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された入力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・条件コード３が設定される。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
ＣＰＵによって決定されたバイト数は、モデルによって決まり、命令が実行されるたびに異なる数であってよい。
条件コード３が設定されて命令が終了した後に、プログラムが命令に関する入力の仕様も、出力の仕様も変更せずに、分岐して戻り、命令を再実行して動作を再開することが期待される。
特定の状況では、条件コード３が設定されて命令を終了したにもかかわらず、パラメータ・ブロックおよび汎用レジスタが更新されない。このような状況は、ＣＰＵが静止動作を実行するか、またはＣＰＵがデフレート変換呼び出し命令の実行中に再試行するときに、発生することがある。そのような場合、ＣＰＵによって決定された処理済みのバイト数は０であり、データが第１のオペランドの位置に格納されていてよく、適用可能な場合、データが第３のオペランドの位置に格納されていてよく、対応する変更のビットが設定されている。
例えば、以下が当てはまる場合、第２のオペランドの長さは、動作を完了するのに不十分である。
・動作中に、ＢＦＩＮＡＬが１に等しい圧縮データ・ブロックの最後の要素がデコードされておらず、第２のオペランドの長さおよびＳＢＢによって指定された第２のオペランドのビット数が、次にデコードする要素のビット数よりも少なく、第２のオペランドの位置からのデータのデコーディングのすべての結果が第１のオペランドの位置に配置されている。
第２のオペランドの長さが、動作を完了するのに不十分である場合、動作が部分的に完了されており、動作が終了し、１つの実施形態では、以下が発生する。
・パラメータ・ブロック内の継続フラグ（ＣＦ）ビット３７３が１に設定される。
・パラメータ・ブロック内の継続状態バッファ（ＣＳＢ）フィールド３９２が更新される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックの圧縮された動的ハフマン・テーブル（ＣＤＨＴ）フィールド３６７および圧縮された動的ハフマン・テーブルの長さ（ＣＤＨＴＬ）フィールド３６６が更新される。ＢＴＹＰＥ値が２進数１０であるブロックを処理しているときに部分的完了が発生した場合、テーブルを表すために必要とされないＣＤＨＴフィールドのバイトが０として格納される。ＢＴＹＰＥ値が２進数００または０１であるブロックを処理しているときに部分的完了が発生した場合、ＣＤＨＴフィールドおよびＣＤＨＴＬフィールドに０が格納される。
・パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５が更新される。
・適用可能な場合、パラメータ・ブロックの履歴オフセット（ＨＯ）フィールド３８６が更新される。
・パラメータ・ブロックのチェック値フィールド３８７が更新される。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５が０に設定される。
・パラメータ・ブロックの不完全な機能の状態（ＩＦＳ）フィールド３８３が更新される。
・適用可能な場合、パラメータ・ブロックの不完全な機能の長さ（ＩＦＬ）フィールド３８４が更新される。
・汎用レジスタＲ１内のアドレスが、第１のオペランドの位置に格納されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。
・汎用レジスタＲ２内のアドレスが、ビット０の処理を含む第２のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第２のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された入力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・条件コード２が設定される。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
条件コード２が設定されて命令が終了した後に、プログラムが、第２のオペランドの長さ、第２のオペランド・アドレス、またはその両方を変更し、命令を再実行して動作を再開することが期待される。
例えば、以下が当てはまる場合、第１のオペランドの長さは、動作を完了するのに不十分である。
・第１のオペランドの長さが０に等しいため、第２のオペランドの位置からのデータのデコーディングの結果を第１のオペランドの位置に配置することができない。
第１のオペランドの長さが、動作を完了するのに不十分である場合、動作が部分的に完了されており、動作が終了し、１つの実施形態では、以下が発生する。
・パラメータ・ブロック内の継続フラグ（ＣＦ）ビット３７３が１に設定される。
・パラメータ・ブロック内の継続状態バッファ（ＣＳＢ）フィールド３９２が更新される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックの圧縮された動的ハフマン・テーブル（ＣＤＨＴ）フィールド３６７および圧縮された動的ハフマン・テーブルの長さ（ＣＤＨＴＬ）フィールド３６６が更新される。ＢＴＹＰＥ値が２進数１０であるブロックを処理しているときに部分的完了が発生した場合、テーブルを表すために必要とされないＣＤＨＴフィールドのバイトが０として格納される。ＢＴＹＰＥ値が２進数００または０１であるブロックを処理しているときに部分的完了が発生した場合、ＣＤＨＴフィールドおよびＣＤＨＴＬフィールドに０が格納される。
・パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５が更新される。
・適用可能な場合、パラメータ・ブロックの履歴オフセット（ＨＯ）フィールド３８６が更新される。
・パラメータ・ブロックのチェック値フィールド３８７が更新される。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５が０に設定される。
・パラメータ・ブロックの不完全な機能の状態（ＩＦＳ）フィールド３８３が更新される。
・適用可能な場合、パラメータ・ブロックの不完全な機能の長さ（ＩＦＬ）フィールド３８４が更新される。
・汎用レジスタＲ１内のアドレスが、第１のオペランドの位置に格納されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。
・汎用レジスタＲ２内のアドレスが、ビット０の処理を含む第２のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第２のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された入力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・条件コード１が設定される。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
条件コード１が設定されて命令が終了した後に、プログラムが、第１のオペランドの長さ、第１のオペランド・アドレス、またはその両方を変更し、命令を再実行して動作を再開することが期待される。
以下に関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。
・本明細書において説明されているように、パラメータ・ブロックに格納する。
・第１のオペランドの位置に格納する。
・第３のオペランドの位置に格納し、この格納が、例えば履歴バッファ・タイプ（ＨＢＴ）が１（円形）である場合に発生する。
１つの例では、パラメータ・ブロック全体がＰＥＲストレージ領域指定と重なる場合、パラメータ・ブロックに関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。パラメータ・ブロックの一部のみがＰＥＲストレージ領域指定と重なる場合、１つの実施形態では、以下のうちのどれが発生するかは、モデルに依存する。
・パラメータ・ブロックに関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。
・格納されたパラメータ・ブロックの一部に関して、適用可能な場合、ＰＥＲストレージ変更イベントが認識される。
ＨＢＴが１（円形）である場合、パラメータ・ブロック、第１のオペランドの位置、第２のオペランドの位置、および第３のオペランドの位置に関して、適用可能な場合、ＰＥＲゼロ・アドレス検出イベントが認識される。
条件コード１、２、または３が設定されて命令が終了するとき、第２のオペランドの位置から参照された入力データは、完全に処理されているか、または部分的にのみ処理されていてよい。入力データが部分的にのみ処理されている場合、第１のオペランドの位置、第１のオペランド・アドレス、第１のオペランドの長さ、パラメータ・ブロックのＳＢＢフィールド、パラメータ・ブロックのチェック値フィールド、パラメータ・ブロックのＨＬフィールド、パラメータ・ブロックのＩＦＳフィールド、ならびに適用可能な場合、第３のオペランドの位置およびパラメータ・ブロックのＨＯフィールドにおける結果が、更新された第２のオペランドのアドレスおよび長さと一致する状態を表さない。そのような場合、部分的に処理されたデータおよび内部状態情報が、パラメータ・ブロックのＣＳＢフィールドに配置されてよい。部分的に処理されたデータの量は、動作の終了時に存在する条件およびモデルによって決まる。一部のデータのみが部分的に処理されることがあるが、更新された第１のオペランド・アドレスによって指定された位置の左に格納された結果は完成しており、動作が再開するときに変更されない。さらに、その後、プログラムが命令を再実行して動作を再開することが期待され、そのとき、動作を再開する前に、ＣＳＢフィールドの内容が参照される。条件コード０が設定されて動作が終了した場合、すべてのデータが完全に処理されており、入力データおよび出力データに関連付けられたすべての結果が一貫した状態を表す。
０以外の条件コードが設定されて命令が終了した後に、動作を再開する目的で命令を再実行する前に、プログラムはパラメータ・ブロックのどのフィールドも変更するべきではなく、そうでない場合、結果が予測不可能になる。
圧縮データ・ブロック
１つの例では、ストレージ内の圧縮データ・ブロックのバイトが、例えば左から右に処理される。圧縮データ・ブロックは、バイト境界上で開始または終了してもしなくてもよい。例えば、圧縮データ・ブロックはビット・ストリームである。ブロックの要素は、一度に１ビットずつ、ストレージに読み込まれる。ビット・ストリームは、ストレージの各バイト内では例えば右から左へ読み込まれ、バイト・オーダーでは例えば左から右へ読み込まれる。要素がハフマン・コードである場合、ビットは、例えば要素の最上位ビットから最下位ビットへの順序で格納される。要素がハフマン・コードでない場合、ビットは、例えば要素の最下位ビットから最上位ビットへの順序で格納される。
図６は、圧縮データ・シンボルを含んでいない、ブロック・タイプが２進数００であるブロック６００の例を示している。１つの実施形態では、以下がこの例に当てはまる。
・圧縮データ・ブロック６００が、ｂ０として識別されるバイト０のビット４から開始し、ｂ６０として識別されるバイト７のビット０で終了するビット・ストリーム６０２で構成される。
・ビット・ストリームに出現する最初の要素が、バイト０のビット４におけるＢＦＩＮＡＬ（ブロック・ヘッダーの最後のビット）である。
・ビット・ストリームに出現する２番目の要素が、バイト０のビット２～３におけるＢＴＹＰＥ（ブロック・タイプ）である。この例では、ＢＴＹＰＥは２進数００である。
・ＢＴＹＰＥが２進数００である場合、ＢＴＹＰＥの左にあるビット（この例では、バイト０のビット０～１）およびバイト境界の右にあるビットが無視される。
・ビット・ストリームに出現する３番目の要素が、ＬＥＮフィールドの最下位バイト（ＬＳＢ：least significant byte）であり、その後にＬＥＮフィールドの最上位バイト（ＭＳＢ：most significant byte）が続く。ＬＥＮフィールドは、リテラル・データを含むブロック内のバイト数を指定する。リテラル・データは、例えば圧縮されていないデータである。リテラル・データを含むバイトは、ビット・ストリーム内のＮＬＥＮフィールドの後に続く。ＮＬＥＮは、ＬＥＮの１の補数である。１つの例では、バイト１～２が、リトルエンディアン・バイト・オーダーでＬＥＮフィールドを含む。
・ＬＥＮフィールドの後に続いてビット・ストリームに出現する要素が、ＮＬＥＮフィールドの最下位バイトであり、その後にＮＬＥＮフィールドの最上位バイトが続く。バイト３～４が、リトルエンディアン・バイト・オーダーでＮＬＥＮフィールドを含む。ＮＬＥＮフィールドは、ＬＥＮフィールドの１の補数である。
・ＮＬＥＮフィールドの後に続いてビット・ストリームに出現する要素が、リテラル・バイトとして識別される圧縮されていないデータである。バイト５～７は、このブロックを生成するために使用されるソース・データから変更されない、圧縮されていないデータを含む。
・このブロックに含まれているどの要素も、ハフマン・コードではない。このブロック内のすべての要素は、デフレート規格によって規定されているように、要素の最下位ビットから最上位ビットへの順序で、ビット・ストリームに格納される。ＬＥＮ、ＮＬＥＮ、およびリテラルの各要素が、バイト境界上でアライメントされた整数個のバイトであるため、これらの要素は、バイト単位で処理されてよく、必ずしもビット単位で処理されなくてよい。
図７は、固定ハフマン・テーブル（ＦＨＴ）を使用して生成された圧縮データ・シンボルを含む、ブロック・タイプが２進数０１であるブロック７００の例を示している。１つの実施形態では、以下がこの例に当てはまる。
・圧縮データ・ブロック７００が、ｂ０として識別されるバイト０のビット４から開始し、ｂ８９として識別されるバイト１１のビット３で終了するビット・ストリーム７０２で構成される。
・ビット・ストリームに出現する最初の要素が、バイト０のビット４におけるＢＦＩＮＡＬである。
・ビット・ストリームに出現する２番目の要素が、バイト０のビット２～３におけるＢＴＹＰＥである。この例では、ＢＴＹＰＥは２進数０１である。
・固定ハフマン・テーブル（ＦＨＴ）が、ブロックの構成要素ではない。
・ビット・ストリームに出現する第３の要素が、バイト０のビット１で開始する最初の圧縮データ・シンボルである。圧縮データ・シンボルは、１つの例では、示されている順序でビット・ストリームに出現する以下の部分要素で構成される。
１．変数の長さのハフマン・コード。このコードの最上位ビットは、コードの長さを指定する。このコードは、コードの最上位ビットから開始してビット・ストリームに出現し、コードの最下位ビットで終了する。このコードがリテラル値またはブロック終結シンボルを表す場合、このコードは、圧縮データ・シンボルの単なる部分要素である。このコードが履歴バッファへのポインタの長さを表す場合、このコードの後に、圧縮データ・シンボルのその後の部分要素が続く。
２．適用可能な場合、デフレート規格によって規定されているように、ポインタの長さを表すハフマン・コードの後に、追加の長さビットが続いてよい。追加の長さビットは、追加の長さビットの最下位ビットから開始してビット・ストリームに出現し、追加の長さビットの最上位ビットで終了する。
３．次にビット・ストリームに出現する部分要素は、履歴バッファへのポインタの５ビットの距離コードである。この距離コードは、例えばコードの最上位ビットから開始してビット・ストリームに出現し、距離コードの最下位ビットで終了する。
４．適用可能な場合、デフレート規格によって規定されているように、距離コードの後に、追加の距離ビットが続いてよい。追加の距離ビットは、追加の距離ビットの最下位ビットから開始してビット・ストリームに出現し、追加の距離ビットの最上位ビットで終了する。
・一例として、バイト０のビット０～１、バイト１～９のすべてのビット、およびバイト１０のビット２～７が、圧縮データ・シンボルのビットを含む。
・ビット・ストリームに出現する最後の要素が、単一の部分要素を含む圧縮データ・シンボルであり、この部分要素は、ブロック終結（ＥＯＢ）シンボルを表すハフマン・コードである。ＢＴＹＰＥが２進数０１であるブロックのＥＯＢシンボルは、２進数０００００００である。この例では、バイト１０のビット１が、ＥＯＢシンボルの最上位ビットを含み、バイト１１のビット３が、ＥＯＢシンボルの最下位ビットを含む。
・バイト１１のビット３が、圧縮データ・ブロックの最後のビットである、ビット・ストリームの最後のビットを含む。
図８は、動的ハフマン・テーブル（ＤＨＴ）を使用して生成された圧縮データ・シンボルを含む、ブロック・タイプが２進数１０であるブロック８００の例を示している。１つの実施形態では、以下がこの例に当てはまる。
・圧縮データ・ブロック８００が、ｂ０として識別されるバイト０のビット４から開始し、ｂ８９として識別されるバイト１１のビット３で終了するビット・ストリーム８０２で構成される。
・ビット・ストリームに出現する最初の要素が、バイト０のビット４におけるＢＦＩＮＡＬである。
・ビット・ストリームに出現する２番目の要素が、バイト０のビット２～３におけるＢＴＹＰＥである。この例では、ＢＴＹＰＥは２進数１０である。
・ビット・ストリームに出現する第３の要素が、バイト０のビット１で開始する動的ハフマン・テーブル（ＤＨＴ）の圧縮表現である。ＤＨＴの圧縮表現は、１つの例では、示されている順序でビット・ストリームに出現する以下の部分要素で構成される。
１．ＨＬＩＴ：５ビットのＨＬＩＴ部分要素および２５７の和が、リテラル・バイト、ＥＯＢシンボル、および重複列の長さを表すハフマン・コードの数を指定する。ＨＬＩＴの有効な値の範囲は、例えば０～２９である。ＨＬＩＴビットは、ＨＬＩＴ部分要素の最下位ビットから開始してビット・ストリームに出現し、ＨＬＩＴ部分要素の最上位ビットで終了する。この例では、ｂ３として識別されるバイト０のビット１が、ＨＬＩＴ部分要素の最下位ビットである。
２．ＨＤＩＳＴ：５ビットのＨＤＩＳＴ部分要素および１の和が、重複列のポインタ距離を表すハフマン・コードの数を指定する。ＨＤＩＳＴの有効な値の範囲は、例えば０～２９である。ＨＤＩＳＴビットは、ＨＤＩＳＴ部分要素の最下位ビットから開始してビット・ストリームに出現し、ＨＤＩＳＴ部分要素の最上位ビットで終了する。
３．ＨＣＬＥＮ：４ビットのＨＣＬＥＮ部分要素および４の和が、コード長を表すハフマン・コードの数を指定する。ＨＣＬＥＮの有効な値の範囲は、例えば０～１５である。ＨＣＬＥＮビットは、ＨＣＬＥＮ部分要素の最下位ビットから開始してビット・ストリームに出現し、ＨＣＬＥＮ部分要素の最上位ビットで終了する。
４．圧縮されたＤＨＴに対して定義されたコード長の各々に対してビット長を指定するコードのシーケンス。コードの数は、ＨＣＬＥＮおよび４の和に等しい。各コードは３ビットである。
５．リテラル・バイト、ＥＯＢシンボル、および重複列の長さで構成されるセットの要素の各々に対してコード長を指定するコードのシーケンス。指定されるコード長の数は、ＨＬＩＴおよび２５７の和に等しい。
リテラル・バイト、ＥＯＢシンボル、および重複列の長さのセットの最後のコード長（ＣＬ）が１６、１７、または１８であり、ＣＬの後に続く追加のビットが、このセットに対して定義されている要素よりも多い要素に対してＣＬを繰り返すことを指定する場合、このコード長は、重複列のポインタ距離のセットにも適用される。リテラル・バイト、ＥＯＢシンボル、および重複列の長さのセットに対してコード長を指定するコードのシーケンス、およびその後に続く、重複列のポインタ距離に対してコード長を指定するコードのシーケンスは、両方のセットに関する隣接するシーケンスである。
６．重複列のポインタ距離で構成されるセットの要素の各々に対してコード長を指定するコードのシーケンス。指定されるコード長の数は、ＨＤＩＳＴおよび１の和に等しい。
・ビット・ストリームに出現する第４の要素が、最初の圧縮データ・シンボルである。圧縮データ・シンボルは、１つの実施形態では、示されている順序でビット・ストリームに出現する以下の部分要素で構成される。
１．変数の長さのハフマン・コード。このコードの最上位ビットは、コードの長さを指定する。このコードは、コードの最上位ビットから開始してビット・ストリームに出現し、コードの最下位ビットで終了する。このコードがリテラル値またはブロック終結シンボルを表す場合、このコードは、圧縮データ・シンボルの単なる部分要素である。このコードが履歴バッファへのポインタの長さを表す場合、このコードの後に、圧縮データ・シンボルのその後の部分要素が続く。
２．適用可能な場合、デフレート規格によって規定されているように、ポインタの長さを表すハフマン・コードの後に、追加の長さビットが続いてよい。追加の長さビットは、例えば追加の長さビットの最下位ビットから開始してビット・ストリームに出現し、追加の長さビットの最上位ビットで終了する。
３．次にビット・ストリームに出現する部分要素は、履歴バッファへのポインタの５ビットの距離コードである。この距離コードは、例えばコードの最上位ビットから開始してビット・ストリームに出現し、距離コードの最下位ビットで終了する。
４．適用可能な場合、デフレート規格によって規定されているように、距離コードの後に、追加の距離ビットが続いてよい。追加の距離ビットは、例えば追加の距離ビットの最下位ビットから開始してビット・ストリームに出現し、追加の距離ビットの最上位ビットで終了する。
・ビット・ストリームに出現する、例えばバイト１０のビット５までの、ビット５を含むその後のビットは、圧縮データ・シンボルのビットを含む。
・ビット・ストリームに出現する最後の要素が、単一の部分要素を含む圧縮データ・シンボルであり、この部分要素は、ブロック終結（ＥＯＢ）シンボルを表すハフマン・コードである。この例では、バイト１０のビット４が、ＥＯＢシンボルの最上位ビットを含み、バイト１１のビット３が、ＥＯＢシンボルの最下位ビットを含む。
・バイト１１のビット３が、圧縮データ・ブロックの最後のビットである、ビット・ストリームの最後のビットを含む。
さまざまなブロック・タイプの上記の説明では、特定の一定の値に加えて、特定のビット、バイト、方向などが指定された。これらは例にすぎない。他の実施形態では、その他の一定の値、ビット、バイト、方向などが指定されてよい。
圧縮データ・セットの処理
デフレート変換呼び出し命令の使用例を説明し、パラメータ・ブロックのさまざまなフィールドの説明を補強するための圧縮データ・セットの処理の例が提供される。これらの例は、すべての可能なシナリオ、要件、および機能を説明するのではなく、さまざまなシナリオ、要件、または機能、あるいはその組み合わせを説明する。これらの例および説明は、例えばストレージ内の圧縮データ・セットに適用され、その例が図９に示されている。図に示されているように、圧縮データ・セット９００は、複数の圧縮データ・ブロック９０２を含んでおり、データ・セット９００の先頭が、圧縮データ・セット開始アドレス（ＣＤＳＢＡ：compressed data set begin address）９０４によって示されている。
本明細書に記載された例では、圧縮データ・セットを処理するプログラムが、１つの実施形態において以下を考慮することが意図されている。
・単一のパラメータ・ブロックが定義され、圧縮データ・セット全体を処理するために、デフレート変換呼び出し命令の複数の使用によって参照されてよい。パラメータ・ブロックのチェック値フィールド３８７およびチェック値タイプ・フィールド３７５が、圧縮データ・セット内の圧縮データ・ブロック（例えば、すべてのブロック）に適用されるべきである。パラメータ・ブロックのサブバイト境界・フィールド３８１が、個別のブロック間の移行に適用されるべきである。履歴長３８５および履歴オフセット３８６が複数のブロックに適用されてよい。パラメータ・ブロックの残りのフィールドは、１つの例では、デフレート変換呼び出し命令の特定の実行によって処理されている個別の圧縮データ・ブロックのみに適用される。
・個別のチェック値が、例えば、圧縮データ・セットによって表された圧縮されていないデータのすべてに適用される。
・ブロック１には、第１の圧縮データ・シンボルに関して参照する履歴が存在しない。ブロック１内のその後のシンボルは、以前にブロック１に出現したシンボルに対応する履歴を参照し得る。ブロック２内のシンボルは、以前にブロック２および１に出現したシンボルに対応する履歴を参照し得る。ブロック３内のシンボルは、以前にブロック３、２、および１に出現したシンボルに対応する履歴を参照し得る。
図１０は、図９で説明された圧縮データ・セット９００内のデータを圧縮するために使用されるサンプル・プログラム１０００の一部の一例を示している。さらに、図１１は、図１０のＩＡＢＬＫ１（１００２）というラベルが付けられた命令アドレスにあるＤＦＬＴＣＣ命令の実行中に使用されるパラメータ・ブロックの特定のフィールドの値を示している。例えば、図１１は、パラメータ・ブロックのさまざまなフィールド１１００、圧縮動作の開始時のそれらのフィールドの値１１０２、条件コード１、２、または３が設定されたときの動作の終了時のそれらのフィールドの値１１０４、および条件コード０が設定されたときの動作の終了時のそれらのフィールドの値１１０６を示している。
同様に、図１２は、図１０のＩＡＢＬＫ２（１００４）というラベルが付けられた命令アドレスにあるＤＦＬＴＣＣ命令の実行中に使用されるパラメータ・ブロックの特定のフィールドの値を示している。これらの図は、デフレート変換呼び出し命令を複数回使用して圧縮データ・セット全体を処理することに関連する詳細の一部を示している。
さらに、図１３を参照すると、図９の圧縮データ・セットからデータを復元するために使用されるサンプル・プログラム１３００の一部の一例が示されている。
データの圧縮
データ圧縮のプロセスは、１つまたは複数の圧縮データ・ブロックを生成することを含む。デフレート変換呼び出し命令の圧縮機能は、個別のブロックの部分を構築するために使用される。この部分は、ブロック全体であってよい。この機能は、ブロック・タイプ（ＢＴＹＰＥ）が２進数００ではなく２進数０１または１０であるブロックの部分を生成する。パラメータ・ブロックの新しいタスク（ＮＴ）ビットが１である場合、圧縮データの最初のブロックが生成され、以前に実行された圧縮動作からの参照する履歴が存在しない。
１つの例では、個別のブロックが、以下の要素を示されている順序で含む。
１．最後のブロックの指示（ＢＦＩＮＡＬ）。
２．ブロック・タイプ（ＢＴＹＰＥ）。
３．適用可能な場合、動的ハフマン・テーブルの圧縮形式。
４．圧縮データ・シンボル。
５．ブロック終結（ＥＯＢ）シンボル。
圧縮動作は、ブロックに対して定義された順序で、指定された要素を生成する。要素は、ストレージ内のバイト境界間で開始または終了し得る。サブバイト境界（ＳＢＢ）が、第１のオペランドの位置への第１の要素の格納に適用される。圧縮データ・ブロックはビット・ストリームである。ブロックの構成要素は、一度に１ビットずつ、ストレージに読み込まれる。一例として、ビット・ストリームは、ストレージの各バイト内では右から左へ読み込まれ、バイト・オーダーでは左から右へ読み込まれる。
ＳＢＢが０以外である場合、第１のオペランドの位置での最初のバイトへの参照は、更新参照である。
第２のオペランドの位置からの圧縮されていないデータが圧縮され、圧縮データ・シンボルとして第１のオペランドの位置に格納される。
命令の実行の開始時に第１のオペランドの長さが０であるときに、第１のオペランドはアクセスされず、汎用レジスタＲ１内の第１のオペランド・アドレスおよび汎用レジスタＲ１＋１内の第１のオペランドの長さは変更されない。これは、命令の実行の開始時にＣＦフィールド３７３（図３Ｌ）の値が０または１である場合に当てはまる。
命令の実行の開始時に第２のオペランドの長さが０であるときに、第２のオペランドはアクセスされず、汎用レジスタＲ２内の第２のオペランド・アドレスおよび汎用レジスタＲ２＋１内の第２のオペランドの長さは変更されない。一例として、以下の場合、命令の実行の開始時に第２のオペランドの長さは０である。
・動作を再開するために命令が再実行されており（命令の実行の開始時にパラメータ・ブロックのＣＦフィールド３７３が１であり）、第２のオペランドを参照せずに、パラメータ・ブロックのＣＳＢフィールド３９２を参照して、動作を完了させることができる。
１つの実施形態では、プログラムは、以下の動作を実行するためにデフレート変換呼び出し命令を使用しない。
・空の圧縮データ・ブロックを生成する。空の圧縮データ・ブロックは、例えばブロック・ヘッダー、適用可能な場合、圧縮形式のＤＨＴ、およびＥＯＢシンボルで構成される。
・開いている圧縮データ・ブロックを閉じる。すなわち、単にＥＯＢシンボルを圧縮データ・ブロックの末尾に格納する。
圧縮アルゴリズムは、第２のオペランドの位置からの現在圧縮されているデータに一致するバイト列に関して、最近圧縮されたデータの最新の履歴を検索することを含む。圧縮動作が開始または再開する前に、１つの実施形態では、以下が当てはまる。
・新しいタスク（ＮＴ）３７４が１である場合、参照できる初期履歴が存在しない。
・ＮＴが０であり、汎用レジスタ０のビット５６（ＨＢＴ）が０（直列）である場合、参照できる初期履歴が、第２のオペランドの左端のバイトの左に隣接して存在し、初期履歴の長さが、パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５によって指定される。
・ＮＴが０であり、汎用レジスタ０のビット５６（ＨＢＴ）が１（円形）である場合、参照できる初期履歴が、パラメータ・ブロックの履歴オフセット（ＨＯ）３８６フィールドおよび履歴長（ＨＬ）３８５フィールドによって指定された第３のオペランドの位置に存在する。
圧縮動作中に、動作を実行するために履歴のどのバイトが使用されるかに関わらず、履歴全体へのフェッチタイプの参照が行われてよい。さらに、履歴バッファ・タイプが円形である場合、動作を実行するために履歴のどのバイトが使用されるかに関わらず、３２Ｋバイトの履歴バッファ全体へのフェッチタイプの参照が行われてよい。
圧縮動作中に、履歴が更新される。一般オペランド・データ例外条件が発生せずに、ソース・データの１つまたは複数のバイトを圧縮データ・シンボルにエンコードした後に、ソース・バイトが履歴の末尾に連結される。最大で３２Ｋバイトまでの、ソース・データの直前に処理されたバイトが、ソース・データのその後のバイトの処理中に参照できる最新の履歴を構成する。
圧縮動作の終了時に、１つの例では、その後、動作を再開するため、または別の動作を開始するために使用できる得られた履歴に、以下が当てはまる。
・ＨＢＴが直列である場合、履歴が更新されるときに、第２のオペランドの位置に対するストレージの更新が不要である。更新された第２のオペランド・アドレスおよび更新されたＨＬは、得られた履歴の更新された位置および更新された長さを指定する。
・ＨＢＴが円形である場合、履歴が更新されるときに、第３のオペランドの位置に対するストレージの更新が実行される。第３のオペランド・アドレス、更新されたＨＯ、および更新されたＨＬは、得られた履歴の更新された位置および更新された長さを指定する。
例として、図１４Ａ～１４Ｃは、ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、かつ直列履歴が指定された（例えば、ビット３１０＝０）デフレート変換呼び出し命令の複数の実行の前後で、第２のオペランドに関して、各実行が部分的に完了して終了したときの直列履歴バッファの位置を示している。例えば、図１４Ａは、ＤＦＬＴＣＣ－ＣＭＰＲの実行番号１の前の直列履歴を示しており、図１４Ｂは、ＤＦＬＴＣＣ－ＣＭＰＲの実行番号２の前、および実行番号１の後の直列履歴を示しており、図１４Ｃは、ＤＦＬＴＣＣ－ＣＭＰＲの実行番号２の後の直列履歴を示している。図１４Ｃで提供される説明は、図１４Ａおよび１４Ｂにも当てはまる。
汎用レジスタ０のビット５６によって指定されたＨＢＴ（履歴バッファ・タイプ）が円形（例えば、ビット３１０＝１）である場合、履歴は、例えば第３のオペランドの位置にある３２Ｋバイトのバッファ内で維持される。バッファ内の履歴の最初のバイトの位置（ＨＢ）は、例えば、汎用レジスタＲ３の内容および履歴オフセット（ＨＯ）３８６（図３Ｌ）の和によって指定される。履歴の最初のバイトは、バッファ内の圧縮されていないデータのうちの処理されてから最も長い時間が経過したバイトである。バッファ内の履歴の最後のバイトの位置（ＨＥ）は、一例として、以下の方程式によって指定される。
ＨＥ＝Ｒ３＋ｍｏｄｕｌｏ３２Ｋ（ＨＯ＋ＨＬ－１）
履歴の最後のバイトは、バッファ内の圧縮されていないデータのうちの直前に処理されたバイトである。履歴オフセット（ＨＯ）３８６（図３Ｌ）および履歴長（ＨＬ）３８５の和が、第３のオペランドのサイズ（例えば、３２Ｋバイト）を超えた場合、履歴は、第３のオペランドの末尾から第３のオペランドの先頭に戻る。
例として、図１５Ａ～１５Ｅは、ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、かつ円形履歴バッファが指定された（ビット３１０＝１）デフレート変換呼び出し命令の複数の実行の前後で、各実行が部分的に完了して終了したときの円形履歴バッファ内の履歴の位置を示している。例えば、図１５Ａは、ＤＦＬＴＣＣの実行番号１の前の円形履歴バッファを示しており、図１５Ｂは、ＤＦＬＴＣＣの実行番号２の前、および実行番号１の後の円形バッファを示しており、図１５Ｃは、ＤＦＬＴＣＣの実行番号３の前、および実行番号２の後の円形バッファを示しており、図１５Ｄは、ＤＦＬＴＣＣの実行番号４の前、および実行番号３の後の円形バッファを示しており、図１５Ｅは、ＤＦＬＴＣＣの実行番号４の後の円形バッファを示している。図１５Ｅで提供される説明は、図１５Ａ～１５Ｄにも当てはまる。
ＨＢＴが円形であり、第２のオペランドの位置から処理されたバイト数が例えば３２，７６８未満である場合、１つの例では以下が当てはまる。
・第３のオペランドの位置のバイトの範囲への格納が行われる。このバイトの範囲は、例えば次式によって指定された位置から開始し、この位置を含む。
Ｒ３＋ｍｏｄｕｌｏ３２Ｋ（ＨＯＯ＋ＨＬＯ）
ここで、
ＨＯＯ：命令が実行される前の履歴オフセット。
ＨＬＯ：命令が実行される前の履歴長。
このバイトの範囲は、例えば次式によって指定された位置で終了し、この位置を含む。
Ｒ３＋ｍｏｄｕｌｏ３２Ｋ（ＨＯＯ＋ＨＬＯ＋ＢＰ－１）
ここで、
ＢＰ：命令の実行中に第２のオペランドの位置から処理されたバイト数。
前述したバイトの範囲に対して行われる格納は、一例として、格納タイプ・アクセス例外、ＰＥＲストレージ変更イベント、および設定変更ビットの対象になる。
・ストレージ位置の内容を変更しない、必要ではない格納が、前述した範囲に含まれない第３のオペランドの位置のバイトに対して行われてよい。そのような位置への格納も、格納タイプ・アクセス例外、ＰＥＲストレージ変更イベント、および設定変更ビットの対象になる。
ＨＢＴが円形であり、第２のオペランドの位置から処理されたバイト数が例えば３２，７６８以上である場合、格納は、第３のオペランドの位置のすべてのバイトに対して行われ、格納タイプ・アクセス例外、ＰＥＲストレージ変更イベント、および設定変更ビットの対象になる。
ブロック継続フラグ（ＢＣＦ）３７７が０である場合、ＢＦＩＮＡＬおよびその後に続くＢＴＹＰＥを含む３ビットのブロック・ヘッダーが、第１のオペランドの位置に格納される。ブロック・ヘッダーのＢＦＩＮＡＬビットは、パラメータ・ブロックのブロック・ヘッダーの最後のビット（ＢＨＦ）３７９と同じに設定される。ハフマン・テーブル・タイプ（ＨＴＴ）３７６が０である場合、ブロック・ヘッダーのＢＴＹＰＥフィールドが例えば２進数０１に設定され、ＨＴＴが１である場合、ブロック・ヘッダーのＢＴＹＰＥフィールドが例えば２進数１０に設定される。ブロック・ヘッダーが格納されるときに、ＢＦＩＮＡＬビットが、第１のオペランドの最初のバイト内のＳＢＢによって指定されたビットに格納される。その後、ＢＴＹＰＥが第１のオペランドの位置に格納される。ＢＣＦが１である場合、ブロック・ヘッダーは格納されない。
ハフマン・テーブル・タイプ（ＨＴＴ）が１である場合、パラメータ・ブロックで指定された動的ハフマン・テーブル（ＤＨＴ）３６７の圧縮形式が、一般オペランド・データ例外条件に関して検査される。ＤＨＴの指定された圧縮形式に関して一般オペランド・データ例外条件が存在する場合、圧縮されたＤＨＴは無効であると見なされ、データの圧縮に使用されない。以下では、一般オペランド・データ例外条件の例示的な定義がさらに説明される。圧縮形式のＤＨＴが、コード長に対するビット長、あるいはリテラル・バイト、ＥＯＢシンボル、重複列の長さ、または重複列のポインタ距離に対するコード長を指定し、これらの長さが、適切な機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さよりも大きい場合、機能するＤＨＴを導出してデータを圧縮するために、圧縮されたＤＨＴがまだ使用される。ブロック継続フラグ（ＢＣＦ）が０であり、ＨＴＴが１である場合、パラメータ・ブロックのＣＤＨＴフィールド３６７で指定された圧縮形式のＤＨＴが、第１のオペランドの位置に格納される。
圧縮動作中に、第２のオペランドの位置からのソース・データが、圧縮データ・シンボルにエンコードされる。このエンコーディングの一部として、ソース・データが履歴と比較される。一致が検出されない場合、ソース・データの中間表現は、ソース・データと同じであるリテラル・バイトである。一致が検出された場合、ソース・データの中間表現は、ソース・データの複製を含む履歴内の位置へのポインタである。ポインタは、長さおよび距離で構成される。この長さは、履歴内の列に一致するソース・データのバイト数である。この距離は、履歴の末尾から、ソース・データに一致する列の先頭までのバイト数である。１つの例では、ソース・データの中間表現を圧縮データ・シンボルにエンコードするために、ハフマン・テーブルからの２つのハフマン・コード・ツリーが使用される。ハフマン・テーブル・タイプ（ＨＴＴ）が０である場合、デフレート規格に記載されているように、固定ハフマン・テーブル（ＦＨＴ）が、中間結果をエンコードするために使用される２つのハフマン・コード・ツリーを指定する。ＨＴＴ３７６が１である場合、パラメータ・ブロックのＣＤＨＴフィールド３６７で指定されたＤＨＴの圧縮表現から導出された動的ハフマン・テーブル（ＤＨＴ）が、中間結果をエンコードするために使用される２つのハフマン・コード・ツリーを指定する。このエンコーディングは、デフレート規格に記載されている通りに実行される。ソース・データの中間表現をエンコードするために使用されるハフマン・コードを指定しない非汎用ＤＨＴが使用される場合、一般オペランド・データ例外が認識される。得られた圧縮データ・シンボルのビットは、結果を第１のオペランドの位置に格納する前に、デフレート規格によって指定された順序で配置される。
１つの例では、重複列の長さの範囲は３～２５８バイトである。
ソース・データをさらに処理する前に、本明細書において説明されているように、履歴が更新される。
このプロセスは、１つの例では、すべてのソース・バイトが処理されるまで繰り返される。
ソース・バイト（例えば、すべてのソース・バイト）が処理され、ブロック終了制御（ＢＣＣ）３７８が１になった後に、ブロック終結（ＥＯＢ）シンボルが第１のオペランドの位置に格納される。固定ハフマン・テーブルが使用される場合、２進数０００００００のハフマン・コードがＥＯＢシンボルに使用される。動的ハフマン・テーブル（ＤＨＴ）が使用される場合、ＥＯＢシンボルに使用されるハフマン・コードは、ＤＨＴによって指定される。ＥＯＢシンボルのビットは、ＥＯＢシンボルを第１のオペランドの位置に格納する前に、デフレート規格によって指定された順序で配置される。
動作の最後の圧縮データ・シンボル（ＥＯＢシンボルを含む）が、格納する最後のバイトの一部のみを占める場合、この最後のシンボルの一部を含まないビットは、１つの例では０として格納される。
最後の圧縮データ・シンボルを処理した後に、１つの実施形態では、以下が発生する。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・パラメータ・ブロックのブロック終結の長さ（ＥＯＢＬ）３８９フィールドおよびブロック終結シンボル（ＥＯＢＳ）３８８フィールドが更新される。
・汎用レジスタＲ１内のアドレスが、ビット０の処理を含む第１のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第１のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された出力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
・汎用レジスタＲ２内のアドレスが、処理されたソース・バイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
ソース・データを圧縮することと一致して、ソース・データは、前述した３２ビットのチェック値を生成するための入力になる。得られたチェック値は、パラメータ・ブロックのチェック値フィールド３８７に格納される。
データの復元
１つの実施形態では、デフレート変換呼び出し命令の展開機能が、圧縮データ・セットを圧縮されていないデータにデコードするために使用される。第２のオペランドの位置の圧縮データ・セットは、１つまたは複数の連続する圧縮データ・ブロックを含む。データ・セットのブロックは、１つの例では左から右へ処理され、ブロックのバイトは、例えば左から右へ処理される。ブロックは、バイト境界上で開始または終了してもしなくてもよい。各ブロックは、データ・セット内の他のブロックから独立してデコードされる。汎用レジスタＲ２は、データ・セット内の最初のブロックの左端のバイトの論理アドレスを指定する。データ・セット内の最後のブロックは、処理中に出現する、ＢＦＩＮＡＬビットが１に等しいブロックである。１つの例では、処理する３つのタイプのブロックが存在する。ブロックの内容をデコードする手法は、ブロック・タイプ（ＢＴＹＰＥ）に依って変わる。
動作が開始するとき（例えば、パラメータ・ブロックの継続フラグ・フィールド３７３が０であるとき）、汎用レジスタＲ２、新しいタスク（ＮＴ）フィールド３７４、およびサブバイト境界（ＳＢＢ）フィールド３８１によって指定されたビットは、圧縮データ・ブロックの最初のビット（ブロック・ヘッダーのＢＦＩＮＡＬビット）として解釈される。
展開機能は、最近デコードされた圧縮されていないデータの最新の履歴を参照することを含む。復元動作が開始または再開する前に、１つの実施形態では、以下が当てはまる。
・新しいタスク（ＮＴ）３７４が１である場合、参照できる初期履歴が存在しない。
・ＮＴが０であり、汎用レジスタ０のビット５６（ＨＢＴ）が０（直列）である場合、参照できる初期履歴が、第１のオペランドの左端のバイトの左に隣接して存在し、初期履歴の長さが、パラメータ・ブロックの履歴長（ＨＬ）フィールド３８５によって指定される。
・ＮＴが０であり、汎用レジスタ０のビット５６（ＨＢＴ）が１（円形）である場合、参照できる初期履歴が、パラメータ・ブロックの履歴オフセット（ＨＯ）３８６フィールドおよび履歴長（ＨＬ）３８５フィールドによって指定された第３のオペランドの位置に存在する。
動作中に、動作を実行するために履歴のどのバイトが使用されるかに関わらず、履歴全体へのフェッチタイプの参照が行われてよい。さらに、履歴バッファ・タイプが円形である場合、動作を実行するために履歴のどのバイトが使用されるかに関わらず、（例えば、３２Ｋバイトの）履歴バッファ全体へのフェッチタイプの参照が行われてよい。
復元動作中に、履歴が更新される。一般オペランド・データ例外条件が発生せずにソース・データをデコードした後に、圧縮されていないデータの得られたバイトが、履歴の末尾に連結される。例えば最大で３２Ｋバイトまでの、圧縮されていないデータの直前にデコードされたバイトが、その後のソース・データの処理中に参照できる最新の履歴を構成する。
復元動作の終了時に、１つの例では、その後、動作を再開するため、または別の動作を開始するために使用できる得られた履歴に、以下が当てはまる。
・ＨＢＴが直列である場合、第１のオペランドの位置に対するストレージの更新が、得られた履歴に対する更新も構成する。更新された第１のオペランド・アドレスおよび更新されたＨＬは、得られた履歴の更新された位置および更新された長さを指定する。
・ＨＢＴが円形である場合、履歴が更新されるときに、第３のオペランドの位置に対するストレージの更新が実行される。第３のオペランド・アドレス、更新されたＨＯ、および更新されたＨＬは、得られた履歴の更新された位置および更新された長さを指定する。
例として、図１６Ａ～１６Ｃは、ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、かつ直列履歴が指定されたデフレート変換呼び出し命令の複数の実行の前後で、第１のオペランドに関して、各実行が部分的に完了して終了したときの直列履歴バッファの位置の例を示している。動作中に、履歴長（ＨＬ）が３８５変更される。例えば、図１６Ａは、ＤＦＬＴＣＣ－ＸＰＮＤの実行番号１の前の直列履歴の一例を示しており、図１６Ｂは、ＤＦＬＴＣＣ－ＸＰＮＤの実行番号２の前、および実行番号１の後の直列履歴の例を示しており、図１６Ｃは、ＤＦＬＴＣＣ－ＸＰＮＤの実行番号２の後の直列履歴の例を示している。図１６Ｃで提供される説明は、図１６Ａ～１６Ｂにも当てはまる。
汎用レジスタ０のビット５６によって指定されたＨＢＴが円形である場合、履歴は、例えば第３のオペランドの位置にある３２Ｋバイトのバッファ内で維持される。バッファ内の履歴の最初のバイトの位置（ＨＢ）は、汎用レジスタＲ３の内容および履歴オフセット（ＨＯ）３８６の和によって指定される。履歴の最初のバイトは、バッファ内の圧縮されていないデータのうちの処理されてから最も長い時間が経過したバイトである。バッファ内の履歴の最後のバイトの位置（ＨＥ）は、例えば以下の方程式によって指定される。
ＨＥ＝Ｒ３＋ｍｏｄｕｌｏ３２Ｋ（ＨＯ＋ＨＬ－１）。
履歴の最後のバイトは、バッファ内の圧縮されていないデータのうちの直前に処理されたバイトである。履歴オフセット（ＨＯ）および履歴長（ＨＬ）の和が、第３のオペランドのサイズ（例えば、３２Ｋバイト）を超えた場合、履歴は、第３のオペランドの末尾から第３のオペランドの先頭に戻る。本明細書に記載された図１５Ａ～１５Ｅは、ＤＦＬＴＣＣ－ＸＰＮＤ機能および円形履歴バッファが指定されたデフレート変換呼び出し命令の複数の実行の前後で、各実行が部分的に完了して終了したときの円形履歴バッファ内の履歴の位置の例を示している。
ＨＢＴが円形であり、第１のオペランドの位置に格納されたバイト数が例えば３２，７６８未満である場合、１つの例では以下が当てはまる。
・第３のオペランドの位置のバイトの範囲への格納が行われる。このバイトの範囲は、次式によって指定された位置から開始し、この位置を含む。
Ｒ３＋ｍｏｄｕｌｏ３２Ｋ（ＨＯＯ＋ＨＬＯ）
ここで、
ＨＯＯ：命令が実行される前の履歴オフセット。
ＨＬＯ：命令が実行される前の履歴長。
このバイトの範囲は、例えば次式によって指定された位置で終了し、この位置を含む。
Ｒ３＋ｍｏｄｕｌｏ３２Ｋ（ＨＯＯ＋ＨＬＯ＋ＢＰ－１）
ここで、
ＢＰ：命令の実行中に第１のオペランドの位置に格納されたバイト数。
前述したバイトの範囲に対して行われる格納は、格納タイプ・アクセス例外、ＰＥＲストレージ変更イベント、および設定変更ビットの対象になる。
・ストレージ位置の内容を変更しない、必要ではない格納が、前述した範囲に含まれない第３のオペランドの位置のバイトに対して行われてよい。そのような位置への格納も、格納タイプ・アクセス例外、ＰＥＲストレージ変更イベント、および設定変更ビットの対象になる。
ＨＢＴが円形であり、第１のオペランドの位置に格納されたバイト数が例えば３２，７６８以上である場合、格納は、例えば第３のオペランドの位置のすべてのバイトに対して行われ、格納タイプ・アクセス例外、ＰＥＲストレージ変更イベント、および設定変更ビットの対象になる。
ＢＴＹＰＥが２進数００である場合、ブロックは圧縮データを含まない。本明細書に記載された図６は、ＢＴＹＰＥが２進数００に等しいブロックの一例を示している。ＬＥＮフィールドは、ブロック内のリテラル・バイト数を指定する。ＬＥＮフィールドのバイト・オーダーはリトルエンディアンである。ＬＥＮフィールドは、０のリテラル・バイトを指定し得る。ブロックのリテラル・バイトは、第１のオペランドの位置に配置される。前述したように、履歴も、ブロックの各リテラル・バイトで更新される。
ＢＴＹＰＥが２進数０１である場合、ブロックは、固定ハフマン・テーブル（ＦＨＴ）を使用して生成された圧縮データ・シンボルを含む。ＦＨＴは、デフレート規格によって規定されており、ブロックの一部ではない。本明細書に記載された図７は、ＢＴＹＰＥが２進数０１に等しいブロックの一例を示している。ブロック・ヘッダーを解釈した後に、圧縮データ・シンボルが、ブロックに出現する順序でデコードされる。ブロックのバイトは、例えば左から右へ処理され、ブロックの各バイト内のビットは、例えば右から左へ処理される。１つの例では、各シンボルは、ブロック内の次のシンボルを処理する前に、完全に処理される。ブロック終結（ＥＯＢ）シンボルでない各シンボルは、リテラル値、または履歴バッファ内の以前にデコードされた部分列へのポインタを表す。以前にデコードされた部分列は、重複列とも呼ばれる。１つの例では、重複列の長さの範囲は３～２５８バイトである。ポインタは、部分列の長さ、および履歴の末尾から部分列の先頭までの距離を表すコードで構成される。シンボルが履歴内の部分列を表している場合、この部分列は履歴バッファから参照される。シンボルのデコーディングから得られた圧縮されていないデータが、第１のオペランドの位置に配置される。
ソース・データをさらに処理する前に、前述したように、履歴が更新される。
最新の履歴が、ブロックの次のシンボルのデコーディングに適用される。ＥＯＢシンボルが出現するときに、ブロックの処理が完了する。
ＢＴＹＰＥが２進数１０である場合、ブロックは、動的ハフマン・テーブル（ＤＨＴ）を使用して生成された圧縮データ・シンボルを含む。使用される圧縮形式のＤＨＴは、圧縮データ・ブロックの要素である。本明細書に記載された図８は、ＢＴＹＰＥが２進数１０に等しいブロックの一例を示している。ブロック・ヘッダーを解釈した後に、圧縮データ・ブロック内で提供された圧縮形式のＤＨＴが、一般オペランド・データ例外条件に関して検査される。ＤＨＴの提供された圧縮形式に関して一般オペランド・データ例外条件が存在する場合、圧縮形式のＤＨＴは無効であると見なされ、データの復元に使用されない。圧縮形式のＤＨＴが、コード長に対するビット長、あるいはリテラル・バイト、ＥＯＢシンボル、重複列の長さ、または重複列のポインタ距離に対するコード長を指定し、これらの長さが、適切な機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さよりも大きい場合、機能するＤＨＴを導出してデータを圧縮するために、圧縮されたＤＨＴがまだ使用される。圧縮形式のＤＨＴを検査した後に、圧縮データ・シンボルが、ブロックに出現する順序でデコードされる。ブロックのバイトは、例えば左から右へ処理され、ブロックの各バイト内のビットは、例えば右から左へ処理される。各シンボルは、１つの例では、ブロック内の次のシンボルを処理する前に、完全に処理される。ＢＴＹＰＥが２進数１０であるブロック内のシンボルの処理は、ＢＴＹＰＥが０１であるブロック内のシンボルの処理に関して前に説明した処理と同じであるが、前者がシンボルをデコードするために提供されたＤＨＴを使用し、後者がシンボルをデコードするためにＦＨＴを使用するという点が異なる。圧縮データ・シンボルをデコードするために使用されるハフマン・コードを指定しない非汎用ＤＨＴが提供される場合、一般オペランド・データ例外が認識される。
第２のオペランドを復元することと一致して、圧縮されていないデータは、チェック値（例えば、３２ビットのチェック値）を生成するための入力になる。得られたチェック値は、パラメータ・ブロックのチェック値フィールド３８７に格納される。
データ・セットの最後のブロックを処理した後に、１つの実施形態では、以下が発生する。
・モデルに依存する値が、パラメータ・ブロックのモデル・バージョン番号（ＭＶＮ）フィールド３６３に格納される。
・パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１が更新される。
・汎用レジスタＲ１内のアドレスが、第１のオペランドの位置に格納されたバイト数だけインクリメントされ、汎用レジスタＲ１＋１内の長さが同じ数だけデクリメントされる。
・汎用レジスタＲ２内のアドレスが、ビット０の処理を含む第２のオペランドの処理されたバイト数だけインクリメントされ、汎用レジスタＲ２＋１内の長さが同じ数だけデクリメントされる。ビット０の処理を含む第２のオペランドの処理されたバイト数は、整数除算から得られた整数化した商であり、被除数は、処理された入力ビット数およびＳＢＢの元の値の和であり、除数は８の値である。
アドレスおよび長さの形成および更新は、アドレス指定モードによって決まる。
命令の実行の開始時に第１のオペランドの長さが０であるときに、第１のオペランドはアクセスされず、汎用レジスタＲ１内の第１のオペランド・アドレスおよび汎用レジスタＲ１＋１内の第１のオペランドの長さは変更されない。これは、命令の実行の開始時にＣＦフィールド３７３の値が０または１である場合に当てはまる。
命令の実行の開始時に第２のオペランドの長さが０であるときに、第２のオペランドはアクセスされず、汎用レジスタＲ２内の第２のオペランド・アドレスおよび汎用レジスタＲ２＋１内の第２のオペランドの長さは変更されない。１つの実施形態では、以下の場合、命令の実行の開始時に第２のオペランドの長さは０である。
・命令が再実行されており（例えば、命令の実行の開始時にパラメータ・ブロックのＣＦフィールド３７３が１であり）、命令が前に実行されたときに、第２のオペランド全体が処理された。
復元動作は、第２のオペランドの位置からデータが処理されたとしても、結果を第１のオペランドの位置に格納せずに終了し得る。これは、１つの例では、第２のオペランドの位置から処理されたデータが以下の圧縮データ・ブロックの要素のいずれかのみを含む場合に発生する。
・ブロック・ヘッダー。
・ブロック・タイプが２進数００であるブロックのＬＥＮフィールド。
・ブロック・タイプが２進数００であるブロックのＮＬＥＮフィールド。
・動的ハフマン・テーブルの圧縮形式。
・ブロック終結（ＥＯＢ）シンボル。
１つまたは複数の実施形態では、以下の条件がデフレート変換呼び出し命令の実行に適用される。
１つの例では、ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定され、以下の条件が発生した場合、一般オペランド・データ例外が認識される。
・パラメータ・ブロック・バージョン番号３６２によって指定されたパラメータ・ブロックの形式が、モデルによってサポートされない。
１つの例では、ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、以下の条件のいずれかが発生した場合、一般オペランド・データ例外が認識される。
・パラメータ・ブロック・バージョン番号３６２によって指定されたパラメータ・ブロックの形式が、モデルによってサポートされない。
・ＮＴ３７４が０であり、ＨＬ３８５が例えば３２，７６８より大きい。
・ＨＴＴ３７６が１であり、ＣＤＨＴＬ３６６が、例えば４２未満であるか、または例えば２２８３より大きい。
・ＨＴＴ３７６が１であり、ＣＤＨＴＬ３６６が、ＣＤＨＴフィールド３６７で指定された圧縮形式のＤＨＴの長さに等しくない。
・ＨＴＴ３７６が１であり、圧縮形式のＤＨＴのＨＬＩＴ部分要素が例えば２９より大きい（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、圧縮形式のＤＨＴのＨＤＩＳＴ部分要素が例えば２９より大きい（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、圧縮されたＤＨＴに対して定義された可能な例えば１９個のコード長のビット長を指定するコードのシーケンス内にある、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコードを指定する（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、リテラル・バイト、ＥＯＢシンボル、および重複列の長さで構成されている要素のセットの第１のコード長として例えばコード長１６（前のコード長のコピー）を指定する（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、リテラル・バイトのコード長を指定するコードのシーケンス内にあるコードを指定し、このコードが、圧縮されたＤＨＴ内で前に指定された、参照されるコード長のセットを表すために決定されたコードのいずれにも一致しない（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、コード長０（ＣＬ０）をＥＯＢシンボルに割り当てるコードを指定する。この場合、対応するＤＨＴが、ＥＯＢシンボルを表すためのハフマン・コードを指定しない（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、重複列の長さおよびポインタ距離のコード長を指定するコードのシーケンス内にあるコードを指定し、このコードが、圧縮されたＤＨＴ内で前に指定された、参照されるコード長のセットを表すために決定されたコードのいずれにも一致しない（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、ＨＬＩＴフィールド、ＨＤＩＳＴフィールド、および例えば２５８の値の和によって指定された、ＤＨＴ内のハフマン・コードの数より大きいコード長の数を指定する。これは、例えば、コード長１６、１７、および１８の不適切な使用を伴っている可能性がある（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、リテラル・バイト、ＥＯＢシンボル、および重複列の長さのセットに対して、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコード長を指定する（無効なＤＨＴ）。
・ＨＴＴ３７６が１であり、ＤＨＴ（ＣＤＨＴフィールド３６７の内容）の圧縮形式が、重複列のポインタ距離のセットに対して、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコード長を指定する（無効なＤＨＴ）。
・ＣＰＵが、第２のオペランド内のリテラル・バイトを表すために圧縮データ・シンボルを生成しようとし、ＣＤＨＴフィールドの内容から導出されたＤＨＴが非汎用であり、そのリテラル・バイトに対応するハフマン・コードを指定しない。
・ＣＰＵが、第２のオペランド内の重複列を表すために圧縮データ・シンボルを生成しようとし、ＣＤＨＴフィールドの内容から導出されたＤＨＴが非汎用であり、その重複列の長さまたはポインタ距離に対応するハフマン・コードを指定しない。
例えば、ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、例として以下の条件のいずれかが発生した場合、一般オペランド・データ例外が認識される。
・パラメータ・ブロック・バージョン番号３６２によって指定されたパラメータ・ブロックの形式が、モデルによってサポートされない。
・ＮＴ３７４が０であり、ＨＬ３８５が例えば３２，７６８より大きい。
・ＢＴＹＰＥが２進数１１に等しい圧縮データ・ブロックが発生する。
・ＢＴＹＰＥが２進数００に等しい圧縮データ・ブロック、およびＬＥＮの１の補数に等しくないＮＬＥＮが発生する。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、圧縮されたＤＨＴのＨＬＩＴ部分要素が例えば２９より大きい（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、圧縮されたＤＨＴのＨＤＩＳＴ部分要素が例えば２９より大きい（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、圧縮されたＤＨＴに対して定義された可能な例えば１９個のコード長のビット長を指定するコードのシーケンス内にある、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコードを指定する（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、リテラル・バイト、ＥＯＢシンボル、および重複列の長さで構成されている要素のセットの第１のコード長として例えばコード長１６（前のコード長のコピー）を指定する（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、リテラル・バイトのコード長を指定するコードのシーケンス内にあるコードを指定し、このコードが、圧縮されたＤＨＴ内で前に指定された、参照されるコード長のセットを表すために決定されたコードのいずれにも一致しない（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、コード長０（ＣＬ０）をＥＯＢシンボルに割り当てるコードを指定する。この場合、対応するＤＨＴが、ＥＯＢシンボルを表すためのハフマン・コードを指定しない（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、重複列の長さおよびポインタ距離のコード長を指定するコードのシーケンス内にあるコードを指定し、このコードが、圧縮されたＤＨＴ内で前に指定された、参照されるコード長のセットを表すために決定されたコードのいずれにも一致しない（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、ＨＬＩＴフィールド、ＨＤＩＳＴフィールド、および例えば２５８の値の和によって指定された、ＤＨＴ内のハフマン・コードの数より大きいコード長の数を指定する。これは、例えば、コード長１６、１７、および１８の不適切な使用を伴っている可能性がある（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、リテラル・バイト、ＥＯＢシンボル、および重複列の長さのセットに対して、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコード長を指定する（無効なＤＨＴ）。
・圧縮形式のＤＨＴ（ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックの内容）が発生し、このＤＨＴが、重複列のポインタ距離のセットに対して、機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより小さいコード長を指定する（無効なＤＨＴ）。
・ＢＴＹＰＥが２進数１０に等しい圧縮データ・ブロックに出現する圧縮データ・シンボルが、同じブロック内の圧縮形式のＤＨＴから導出された非汎用ＤＨＴによって定義されていないハフマン・コードを指定する。この場合、一般オペランド・データ例外を認識する目的で処理するために使用できる第２のオペランドのビット数は、モデルに依存する。より詳細には、定義されていないコードをデコードしようとするモデルは、より少ないビットを処理した後に例外を決定できたとしても、例外を認識する前に、例えば１５ビットを処理し得る。
・重複列のポインタであり、シンボルを処理する時点で使用可能な履歴の長さより大きい距離を指定する圧縮データ・シンボルが発生する。
・ＢＴＹＰＥが２進数０１に等しい圧縮データ・ブロックに出現する圧縮データ・シンボルが、無効なコード（例えば、重複列の長さの場合は２進数１１０００１１０または１１０００１１１のコード、あるいは重複列のポインタ距離の場合は２進数１１１１０または１１１１１のコード）を指定する。この場合、一般オペランド・データ例外を認識する目的で処理するために使用できる第２のオペランドのビット数は、モデルに依存する。より詳細には、無効なコードをデコードしようとするモデルは、より少ないビットを処理した後に例外を決定できたとしても、例外を認識する前に、例えば、重複列の長さの場合は８ビット、または重複列のポインタ距離の場合は５ビットを処理し得る。
一般オペランド・データ例外が認識された場合、例外に関連する追加情報を提供するように、パラメータ・ブロックの動作終了補助コード（ＯＥＳＣ）フィールド３６５およびモデル・バージョン番号（ＭＶＮ）フィールド３６３が更新されるとしても、動作は抑制されていると見なされる。
ＤＦＬＴＣＣ－ＣＭＰＲ機能またはＤＦＬＴＣＣ－ＸＰＮＤ機能が実行されており、一般オペランド・データ例外が、第２のオペランドに関して認識されることになっている場合、その結果は、例外が認識されるか、または動作が部分的に完了して終了し、例えば条件コード３が設定されるかのいずれかである。条件コード３が設定された場合、同じオペランドの処理を続行するために命令が再実行され、例外条件がまだ存在するときに、例外が認識される。
その他の条件として、例えば以下が挙げられる。
命令の実行が割り込み可能である。割り込みが発生した場合、命令が再実行されるときに割り込みの時点で再開するように、汎用レジスタＲ１およびＲ２内のアドレス、汎用レジスタＲ１＋１およびＲ２＋１内の長さ、およびパラメータ・ブロックの特定のフィールドが更新される。
ＤＦＬＴＣＣ－ＣＭＰＲ機能またはＤＦＬＴＣＣ－ＸＰＮＤ機能が実行されており、アクセス例外が、第１または第２のオペランドに関して認識されることになっている場合、その結果は、例外が認識されるか、または動作が部分的に完了して終了し、例えば条件コード３が設定されるかのいずれかである。条件コード３が設定された場合、同じオペランドの処理を続行するために命令が再実行され、例外条件がまだ存在するときに、例外が認識される。
このＣＰＵ、他のＣＰＵ、およびチャンネル・プログラムによって観察されるとき、パラメータ・ブロック、第１のオペランド、第２のオペランド、および第３のオペランドへの参照は、多重アクセス参照であってよく、これらのストレージ位置へのアクセスは、必ずしもブロック・コンカレントではなく、これらのアクセスまたは参照のシーケンスは定義されない。
１つの実施形態では、ＤＦＬＴＣＣ－ＣＭＰＲ機能またはＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、以下のいずれかが当てはまる場合、結果が予測不可能になる。
・パラメータ・ブロックが第１のまたは第２のオペランドと重なる。
・第１のオペランドが第２のオペランドと重なる。
・指定された履歴バッファ・タイプ（ＨＢＴ）が円形であり、第３のオペランドが、第１のオペランド、第２のオペランド、またはパラメータ・ブロックと重なる。
・指定された履歴バッファ・タイプ（ＨＢＴ）が直列であり、ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、履歴が、第１のオペランドまたはパラメータ・ブロックと重なる。
・指定された履歴バッファ・タイプ（ＨＢＴ）が直列であり、ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、履歴が、第２のオペランドまたはパラメータ・ブロックと重なる。
特定の状況では、ＣＰＵによって決定された処理済みのバイト数が０の状態で、デフレート変換呼び出し命令の実行を終了するにもかかわらず、データが第１のオペランドの位置に格納されていてよく、適用可能な場合、データが第３のオペランドの位置に格納されていてよく、適用可能な場合、対応する変更のビットが設定されている。そのような場合、パラメータ・ブロックおよび汎用レジスタの内容は、元の値から変更されていない。このような状況は、ＣＰＵが静止動作を実行するか、またはＣＰＵがデフレート変換呼び出し命令の実行中に再試行するときに、発生することがある。
デフレート変換呼び出し命令の実行から得られる例示的な条件コードを以下に示す。
０ 正常完了
１ 第１のオペランドの長さが、動作を完了するのに不十分である
２ 第２のオペランドの長さが、動作を完了するのに不十分である（ＤＦＬＴＣＣ－ＸＰＮＤ）
３ ＣＰＵによって決定された処理済みのデータの量
プログラム例外：
・アクセス（フェッチ、オペランド２、直列履歴、フェッチおよび格納、パラメータ・ブロック、オペランド１、オペランド３）
・ＤＸＣ０を含むデータ、一般オペランド
・演算（デフレート変換機能がインストールされていない場合）
・指定
・トランザクション制約
デフレート変換呼び出し命令の実行の例示的な優先度を以下に示す。
１．～６．一般的なケースに関する、プログラム割り込み条件の優先度と同じ優先度を持つ例外。
７．Ａ 第２の命令のハーフワードに関するアクセス例外。
７．Ｂ 演算例外。
７．Ｃ トランザクション制約。
８．Ａ 無効な機能コードまたは無効なレジスタ番号に起因する指定例外。
８．Ｂ ４Ｋバイト境界上で指定されないパラメータ・ブロックに起因する指定例外。
８．Ｃ ４Ｋバイト境界上で指定されない円形履歴バッファに起因する指定例外。
９．パラメータ・ブロックへのアクセスに関するアクセス例外。
１０．パラメータ・ブロックの指定された形式がモードによってサポートされていない場合の一般オペランド・データ例外。
１１．命令の実行の開始時に第２のオペランドの長さが０に等しく、ＣＦが０に等しいことに起因する指定例外。
１２．命令の実行の開始時に第１のオペランドの長さが０に等しく、ＤＦＬＴＣＣ－ＣＭＰＲが指定されたことに起因する条件コード１。
１３．Ａ ＤＦＬＴＣＣ－ＣＭＰＲまたはＤＦＬＴＣＣ－ＸＰＮＤが指定された場合に、履歴長フィールドが３２，７６８より大きく、新しいタスク・フィールドが０であることに起因する一般オペランド・データ例外。
１３．Ｂ 第１のオペランドへのアクセスに関するアクセス例外であり、第１のオペランドの長さが０以外である。
１３．Ｃ 第２のオペランドへのアクセスに関するアクセス例外であり、第２のオペランドの長さが０以外である。
１３．Ｄ 命令の実行の開始時に指定された直列履歴へのアクセスに関するアクセス例外。
１３．Ｅ 第３のオペランドへのアクセスに関するアクセス例外。
１４．Ａ 上の項目１０および１３．Ａに含まれている条件以外の条件に起因する一般オペランド・データ例外。
１４．Ｂ 上の項目１２に含まれている条件以外の条件に起因する条件コード１、２、または３。
１５．条件コード０。
使用の前に、一般オペランド・データ例外条件の存在に関して、圧縮形式のＤＨＴが検査される。一般オペランド・データ例外条件に起因して圧縮形式のＤＨＴの長さが正確に定義されない場合、解釈される長さは、条件によって決まってよく、モデルに依存してよく、例えば２８６バイトを超えない。その結果、ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、例えば第２のオペランドの右端の２８６バイトにおいて、一般オペランド・データ例外条件を伴う圧縮形式のＤＨＴが発生した場合、例外条件（優先度１４．Ａ）または条件コード２（優先度１４．Ｂ）が認識されるかどうかは、モデルに依存する。
例示的なプログラミングに関する注意事項を以下に示す。
１．データを圧縮または復元するときに、デフレート変換呼び出し命令が実行される回数を最小限に抑えて動作が実行された場合に、全体的な効率が高くなることがある。言い換えると、大きいオペランドを使用してＤＦＬＴＣＣを実行することは、小さいオペランドを使用して複数回ＤＦＬＴＣＣを実行することよりも効率的であることがある。
２．圧縮動作および復元動作で、条件コード３が設定された場合、プログラムが命令に分岐して戻り、動作を続行できるように、命令によって使用される汎用レジスタおよびパラメータ・ブロックが更新されている。
３．１つの実施形態では、命令のパラメータによって指定された処理の、ＣＰＵによって決定された下位部分を実行した後に、デフレート変換呼び出し命令が完了し得る。指定されたすべての処理の代わりに、ＣＰＵによって決定された量の処理のみを実行した後に命令が完了した場合、命令が条件コード３を設定する。そのような完了時に、命令に分岐して戻り、命令を再実行することによって命令の処理を再開できるように、ＰＳＷ（program status word：プログラム状態ワード）内の命令アドレスが次の順次命令を指定し、命令のオペランド・パラメータが調整されている。命令は、指定されたすべての処理を実行したときに、３以外の条件コードを設定する。
４．ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド内の０以外の値と共に動作が終了した場合、動作は、得られた第１のオペランド・アドレスによって指定されたバイトに格納することを含んでいた。ＤＦＬＴＣＣ－ＸＰＮＤ機能が指定され、ＳＢＢ内の０以外の値と共に動作が終了した場合、動作は、得られた第２のオペランド・アドレスによって指定されたバイトをフェッチすることを含んでいた。
５．０以外の条件コードが設定されて動作が終了した場合、パラメータ・ブロックのＣＳＢフィールド３９２が、部分的に処理されたデータを含んでよく、プログラムが命令を再実行して動作を再開することが期待される。
６．０以外の条件コードが設定されて動作が終了した後に、動作を再開する目的で命令を再実行する前に、プログラムはパラメータ・ブロックのどのフィールドも変更するべきではなく、そうでない場合、結果が予測不可能になる。
７．ＤＦＬＴＣＣ－ＧＤＨＴ機能が指定された場合、生成されたＤＨＴの圧縮表現が、ハフマン・アルゴリズムに従って、３つの正しい完全なハフマン・コード・ツリーを表す。すなわち、不完全なハフマン・コード・ツリーは表されない。不完全なハフマン・コード・ツリーは、適切な機能するハフマン・ツリーを指定するためにハフマン・アルゴリズムによって必要とされる長さより大きい要素のコード長を指定するＤＨＴの圧縮表現から導出される。
ＤＦＬＴＣＣ－ＣＭＰＲ機能が指定され、ＨＴＴが１であり、ＤＨＴの圧縮表現が不完全なハフマン・コード・ツリーの記述を含む場合、ＤＦＬＴＣＣ－ＸＰＮＤ機能を使用することによって、圧縮データの結果を元の圧縮されていないデータに変換することができるが、デフレート規格を順守する一部のデコーダは、結果を元の圧縮されていないデータに変換できないことがある。これは、例えば、ＤＦＬＴＣＣ－ＣＭＰＲ機能に対してプログラムによって指定されたＤＨＴの圧縮表現が、ＤＦＬＴＣＣ－ＧＤＨＴ機能の実行の結果として生成されなかった場合に、発生することがある。
８．条件コード１が設定されてＤＦＬＴＣＣ－ＣＭＰＲ機能が終了した場合、パラメータ・ブロックのサブバイト境界（ＳＢＢ）フィールド３８１に格納された結果は、２進数０００である。このシナリオを認識することは、デフレート変換呼び出し命令で使用するための出力バッファを割り当てるプログラムに関連することがある。
本明細書において説明されているように、１つの態様では、汎用プロセッサを使用して圧縮動作または復元動作あるいはその両方を実行するために、単一の命令（例えば、ハードウェア／ソフトウェア・インターフェイスでの単一の設計されたマシン命令（例えば、デフレート変換呼び出し命令））が提供される。例えば、この命令は、命令セット・アーキテクチャ（ＩＳＡ：Instruction Set Architecture）において定義されたハードウェア命令である。その結果、圧縮動作または復元動作あるいはその両方に関連するプログラムの複雑さが低減される。さらに、動作（したがって、プロセッサ）の性能が改善される。
デフレート変換呼び出し命令は、例えばプログラマーによって、Ｉ／Ｏデバイス、Ｉ／Ｏインターフェイスを介して接続されたアプリケーション固有のデバイス、またはその他の種類の専用プロセッサなどの専用プロセッサではなく、有利に、汎用プロセッサ（例えば、本明細書ではプロセッサと呼ばれる中央処理装置）上でディスパッチされる。開示された命令の実行は、ソフトウェアの実装と比較して、同じ動作を実行するために大幅に少ない実行サイクルを必要とする。さらに、開示された命令の実行は、動作をＩ／Ｏデバイスにディスパッチすることと比較して、オペレーティング・システムによるＩ／Ｏ操作を必要とせず、動作が完了するのを待っている間に、オペレーティング・システムがタスク切り替えを実行することを引き起こさない。
さまざまなフィールドおよびレジスタが説明されたが、本発明の１つまたは複数の態様は、その他の追加の、またはより少ないフィールドまたはレジスタ、あるいはその他のサイズのフィールドおよびレジスタなどを使用し得る。多くの変形が可能である。例えば、命令の明示的に指定されたレジスタまたはフィールドの代わりに、暗黙のレジスタが使用されてよく、または暗黙のレジスタまたはフィールドの代わりに、明示的に指定されたレジスタまたはフィールドが使用されてよく、あるいはその両方であってよい。その他の変形も可能である。
デフレート変換呼び出し命令の使用の一実施形態が、図１７を参照して説明される。１つの例では、汎用プロセッサなどのプロセッサ上で実行されているプログラムが、ストレージ内のパラメータ・ブロックにおいて、実行される動作の詳細を指定し、パラメータ・ブロックの位置を指定する（ステップ１７００）。例えば、実行される機能に応じて、パラメータ・ブロック（例えば、パラメータ・ブロック３４０、３６０、または３７０）のフィールドのうちの１つまたは複数が提供されるか、または設定される。さらに、プログラムは、実行される動作（例えば、照会、生成、圧縮、展開など）を指定する（ステップ１７０２）。さらに、プログラムは、ストレージ内の位置および入力データの量を指定するか、または更新し（ステップ１７０４）、ストレージ内の結果バッファの位置およびサイズを指定するか、または更新する（ステップ１７０６）。
その後、プログラムは、デフレート変換呼び出し（ＤＦＬＴＣＣ）命令を実行する（ステップ１７０８）。１つの例では、汎用プロセッサ上で命令がディスパッチされる。例えば、命令は、汎用プロセッサ上で処理されるか、または汎用プロセッサに結合された、Ｉ／Ｏインターフェイスを使用せずにアクセス可能なハードウェアによって、少なくとも部分的に処理される。
命令の終了に基づいて、実行から得られた条件コードが第１の定義された値（例えば、０）に等しいかどうかに関する判定が行われる（照会１７１０）。条件コードが第１の定義された値に等しい場合、命令の処理が完了する（ステップ１７１２）。しかし、条件コードが第１の定義された値に等しくない場合、条件コードが第２の定義された値（例えば、３）に等しいかどうかに関する判定がさらに行われる（照会１７１４）。条件コードが、処理される追加のデータが存在することを示す第２の定義された値に等しい場合、命令が再実行される（ステップ１７０８）。しかし、条件コードが第２の定義された値に等しくない場合、条件コードが第３の定義された値（例えば、１）に設定されているかどうかに関する別の判定が行われる（照会１７１６）。条件コードが、第１のオペランドの長さが不十分であることを示す第３の定義された値に設定されている場合、処理がステップ１７０６を続行し、そうでない場合、第２のオペランドの長さが機能のために不十分であり、処理がステップ１７０４を続行する。
示されているように、デフレート変換呼び出し命令は、単一のデータ・ストリームを圧縮または復元するために複数回実行されてよい。したがって、１つの態様では、デフレート変換呼び出し命令が属性を含み、この属性は、デフレート変換呼び出し命令の複数の実行にわたる動作中に処理された圧縮されていないデータの履歴を蓄積するために使用されるバッファ（例えば、３２Ｋバイトのバッファ）を宣言するためのメカニズムをプログラムに提供する。このバッファは、例えば円形履歴バッファである。
１つの態様では、デフレート変換呼び出し命令は、円形履歴バッファの使用を示すために、暗黙のレジスタ（例えば、ＧＲ０．５６）内のインジケータ（例えば、ビット）を使用する。円形履歴バッファが示され、デフレート変換呼び出し命令によって実行される指定された機能がデータの圧縮または復元である場合、命令のフィールド（例えば、Ｒ３）が、例えば３２Ｋバイトのバッファのメモリ内の位置を指定し、プロセッサが、この位置を使用して、動作の開始時に履歴をフェッチし、動作の終了時に履歴を格納する。円形履歴バッファ内の履歴の長さは、デフレート変換呼び出し命令に関連付けられたパラメータ・ブロックのフィールド（例えば、ＨＬフィールド３８５）によって指定され、バッファ内の履歴の先頭は、パラメータ・ブロックの別のフィールド（例えば、ＨＯフィールド３８６）に含まれているオフセットによって指定される。
円形履歴バッファの使用の詳細が、図１８を参照してさらに説明される。１つの例では、汎用プロセッサなどのプロセッサ上で実行されているプログラムが、ストレージ内のパラメータ・ブロックにおいて、実行される動作の詳細を指定し、パラメータ・ブロックの位置を指定する（ステップ１８００）。例えば、実行される機能に応じて、パラメータ・ブロック（例えば、パラメータ・ブロック３６０または３７０）のフィールドのうちの１つまたは複数が提供されるか、または設定される。さらに、プログラムは、実行される動作（例えば、圧縮、展開など）を指定する。
さらに、１つの例では、プログラムは、定義済みのサイズ（例えば、３２Ｋバイト）を有する円形バッファを割り当て、そのメモリ内の位置を指定する（ステップ１８０２）。さらに、プログラムは、圧縮されていないデータ・ストリームの一部をバッファに配置し、このバッファの位置およびサイズをデフレート変換呼び出し命令への入力として指定し（ステップ１８０４）、ストレージ内の結果バッファの位置およびサイズを指定するか、または更新する（ステップ１８０６）。
次に、デフレート変換呼び出し命令が実行される（ステップ１８０８）。命令の実行に基づいて、本明細書において説明されているように、プロセッサが、動作への入力として、例えば円形履歴バッファから履歴をフェッチし（ステップ１８２０）、指定された動作を実行する（ステップ１８２２）。さらに、プロセッサが、動作の出力として、円形履歴バッファ内の履歴を変更する（ステップ１８２４）。データ・ストリーム全体が処理されたかどうかに関する判定が行われる（照会１８２６）。データ・ストリーム全体が処理されていない場合は、処理がステップ１８０４を続行する。データ・ストリーム全体が処理された場合は、処理が完了する。
円形履歴バッファを使用することによって、例えば以下が可能になる。
デフレート変換呼び出し命令の個別の実行で使用するために指定された入力バッファまたは出力バッファのサイズが比較的小さい（例えば、５１２バイト）場合、バッファされたデータ（例えば、最大３２Ｋバイト）の複数のセグメントにわたる履歴が、少数のバイトを処理するデフレート変換呼び出し命令への入力として使用されてよい。
デフレート変換呼び出し命令の個別の実行で使用するために指定された入力バッファまたは出力バッファのサイズが比較的大きい（例えば、１２８Ｋバイト）場合、バッファされたデータ（例えば、最大３２Ｋバイト）の以前のセグメントの履歴が、データの最初の３２Ｋバイトを処理しているデフレート変換呼び出し命令への入力として使用されてよい。
どちらの場合も、他の方法で使用できるであろう履歴よりも多くの履歴を、データを処理するために使用できる。その結果、重複列の検出の有効性が改善され、全体的な圧縮率の改善が得られる。これによって、コンピューティング環境内の処理を容易にし、性能を改善する。
本発明の１つまたは複数の態様は、コンピュータ技術に密接に関係しており、コンピュータ内の処理を容易にし、その性能を改善する。圧縮または復元あるいはその両方を実行するために単一の設計されたマシン命令を使用することによって、コンピューティング環境内の性能を改善する。圧縮／復元されるデータは、データの管理または使用あるいはその両方を行う、コンピュータ処理、医用情報処理、セキュリティ、在庫管理などの多くの技術分野で使用されることがある。圧縮／復元における最適化を実現し、実行時間を削減することによって、これらの技術分野が改善される。
本発明の１つまたは複数の態様に関連している１つまたは複数の実施形態の詳細が、図１９～２３を参照してさらに説明される。
ここで図１９を参照すると、本発明の１つまたは複数の実施形態に従って、システム・アーキテクチャ１９０１が概して示されている。図１９に示されているシステム・アーキテクチャ１９０１は、中央処理装置（ＣＰＵ）チップまたは集積回路（以下では、「ＣＰ」と呼ばれる）１９１０を含んでおり、中央処理装置（ＣＰＵ）チップまたは集積回路１９１０は、バックプレーン１９１５と、少なくとも１つの処理ユニット（ＰＵ：processing unit）１９２０と、レベル３（Ｌ３）キャッシュおよびオンチップ・コヒーレンス・ユニット（on-chip coherency unit）（以下では、「オンチップ・コヒーレンス・ユニット」と呼ばれる）１９３０と、ＰＣＩｅブリッジ・ユニット（ＰＢＵ：PCIe Bridge Units）１９４０と、アクセラレータ１９５０と、メモリ・コア（ＭＣ：memory core）１９６０とを含む。ＰＵ１９２０、オンチップ・コヒーレンス・ユニット１９３０、ＰＢＵ１９４０、アクセラレータ１９５０、およびＭＣ１９６０は、バックプレーン１９１５上で支持され、配置される。各ＰＵ１９２０は、ＰＵ－Ｌ３インターフェイス１９３１によって、オンチップ・コヒーレンス・ユニット１９３０とそれぞれ通信する。オンチップ・コヒーレンス・ユニット１９３０は、外部バス１９３２を介して外部ＣＰおよびシステム・コントローラ（ＳＣ：system controllers）と通信する。各ＰＢＵ１９４０は、ＰＣＩ（peripheralcomponent interconnect）インターフェイス１９４１と通信してそれぞれ配置される。アクセラレータ１９５０は、ＮＸＵアクセラレータとして提供され得る。各ＰＢＵ１９４０およびアクセラレータ１９５０は、データをメモリおよびキャッシュ・サブシステムに格納し、データをメモリおよびキャッシュ・サブシステムから取り出すために、インターフェイスによってオンチップ・コヒーレンス・ユニット１９３０とそれぞれ通信する。本発明の１つまたは複数の実施形態に従って、インターフェイスは、ＤＭＡインターフェイスと類似する機能および構造を有する、ダイレクト・メモリ・アクセス（ＤＭＡ：direct memory access）のようなインターフェイス１９３３であってよい。図に示されず、本発明の追加または代替の実施形態に従って、アクセラレータ１９５０は、ＤＭＡのようなインターフェイス１９３３を介して任意のメモリ・ユニットにアクセスし得る。ＭＣ１９６０は、メモリ・インターフェイス１９６１によって外部メモリと通信する。
図１９に示されているアクセラレータ１９５０は、デフレート動作およびその他の可逆データ圧縮アルゴリズムを含むが、これらに限定されない、特定の機能および動作を実行するように構成される。デフレートは、数ギガバイト（ＧＢ）のサイズになることがあるデータの圧縮または復元のための（ＬＺ７７アルゴリズムとハフマン・コーディングの組み合わせを使用する）例示的な業界標準のアルゴリズムであり、このアルゴリズムでは、アプリケーションが小さいバッファのみを有することができ、１メガバイト（ＭＢ）以下であることがある比較的小さいブロック内で圧縮が完了する必要がある。
以下では、変換動作の一例として、デフレート命令の動作について説明する。デフレートは、実行を完了するために多くのサイクルを要することがある複合体の命令である。デフレート命令は、アクセラレータ１９５０上で実行される。アーキテクチャの観点からは、デフレートは、他の命令と同様の命令であり、同じ原理原則に従う必要がある。デフレートの使用事例の場合、ソフトウェアは、命令を呼び出すときにソース・バッファおよびターゲット・バッファを提供する。アクセラレータ１９５０は、それらのバッファのうちの少なくとも１つを完全に利用するか、または使用可能なバッファを正常に完了することができる。これは、ストリームを処理するために、アプリケーションがソース・データ（例えば、２５６バイト）を提供し、その後、さらに多くのソース・シンボルを処理するために使用できる（すなわち、アクセラレータによって利用される）完全なバッファを有することが必要になることがあるからである。このことは、ソース・シンボルが部分的シンボルで終了する場合でも当てはまる。言い換えると、最後の使用可能なソースが、シンボルの残りの部分なしではデコードされない部分的シンボルだけであることがある。ターゲットの側では、同じ理由から、このことは、生成された出力が使用可能なターゲットをあふれさせる場合でも、アクセラレータ１９５０がターゲット・バッファを完全に満たすことができる必要があるということを意味する。デフレート命令は、ソース・ページ・アドレス（コンピュータ・システムが圧縮／復元されるデータをフェッチするアドレス）およびターゲット・ページ・アドレス（コンピュータ・システムが圧縮／復元の結果を格納するアドレス）と共に提供される。ページのアドレスを使用できないことに起因して、デフレート命令が中断される可能性がある。ファームウェアに支援されて、後で命令が再び呼び出され、前の実行において停止した位置から続行される。この位置は、必要なアクセス例外を作成するために、使用できないページの先頭である必要がある。その結果、次のページがたまたま使用できない場合に、デフレート命令がソース・ページまたはターゲット・ページ全体を完全に利用することも必要である。本発明の１つまたは複数の実施形態は、不完全なソース・シンボルまたはあふれているターゲット・バッファあるいはその両方が存在する場合でも、デフレートがソース・バッファおよびターゲット・バッファを完全に利用できるようにするためのメカニズムを扱う。
アクセラレータ１９５０をＮＸＵアクセラレータとして提供できる限り、アクセラレータ１９５０は、ＰＵ１９２０が他のタスクに集中できるように、ＰＵ１９２０ではなく、事実上、実際のデフレート・アルゴリズム規格を実装する、ＤＭＡによって接続されるハードウェア・アクセラレータである。本発明の１つまたは複数の実施形態に従って、アクセラレータは、デフレート・アルゴリズムなどの、ただしこれに限定されない、特定の機能を実行するように特別に作成されたコンピュータ・ハードウェアを含むハードウェア・エンジンを含む。加えて、アクセラレータ１９５０は、処理速度におけるハードウェアの利点を利用して、ソフトウェアによって実装された圧縮／復元よりも高速に（例えば、２００倍高速に）圧縮／復元を処理することができる。アプリケーションがデフレート命令を実行するときに、ミリコードが、アプリケーションの代わりにアクセラレータ１９５０のハードウェアを操作して、実際のデフレート動作を実行する。本明細書において使用されるとき、「ミリコード」という用語は、アプリケーションの視点からは透過的であり、命令または命令の一部を実装するために使用される、低レベルのコードのことを指す。デフレートの場合、ミリコードは、アプリケーションの代わりにアクセラレータ１９５０を獲得して操作する。ＰＵ１９２０は、ミリコードを介してアクセラレータ１９５０の動作を制御する。例えば、アクセラレータ１９５０は、出力シンボルのあふれた部分をオーバーフロー・ターゲット・バッファ２１２０に格納する。言い換えると、プロセッサＰＵ１９１０上で実行されているミリコードは、出力シンボルのあふれた部分を受け取って、パラメータ・ブロック２１０３内のオーバーフロー・ターゲット・バッファ２１２０にコピーする。
図２０を参照すると、ドロワー２０１０内で、ＣＰ１９１０、１つまたは複数の追加または外部のＣＰ２００１、および１つまたは複数の追加または外部のＳＣ２００２が提供され得る。そのような場合、ＣＰ１９１０、１つまたは複数の追加または外部のＣＰ２００１、および１つまたは複数の追加または外部のＳＣ２００２は、外部バス２００３を介して互いに通信することができ、その間、１つまたは複数の追加または外部のＳＣ２００２は、ドロワー相互接続（drawer interconnects）２０１１を介して、ドロワー２０１０に対して外部に存在する他の機能と通信することもできる。
図２１および２２を参照すると、大量のデータに対してデフレート動作を実行することができる。例えば、デフレート動作を実行して、数ＧＢのサイズのファイルを圧縮することができ、または復元後に数ＧＢのサイズの別のファイルになるファイルを復元することができる。しかし、アプリケーションは、論理メイン・メモリ２１００内に、小さいサイズ（例えば、１ＭＢ）のメイン・ソース・バッファ２１０１またはメイン・ターゲット・バッファ２１０２あるいはその両方しか持っていないことがあり、そのためアプリケーションは、一度に少量のデータしか読み取ること、または書き込むことができない。そのような場合、本発明の１つまたは複数の実施形態に従って、アプリケーションは、ファイル全体を一度に圧縮するのではなく、ファイルを任意の小さいサイズのブロックに分割し、一度に１つずつブロックを圧縮する。論理メイン・メモリ２１００は、メモリ・コア（ＭＣ）１９６０内、またはメモリ・インターフェイス１９６１によってＰＵ１９２０に接続された外部メモリ内に含まれてよい。しかし、論理メイン・メモリ２１００の位置はこれらに限定されない。
図２１に示されているように、パラメータ・ブロック２１０３がメイン・メモリ２１００に含まれてよい。本発明の１つまたは複数の実施形態に従って、パラメータ・ブロック２１０３は、アプリケーションがデフレート動作をどのように使用するか（例えば、圧縮のさまざまなモード）に関する詳細な命令を含む小さいサイズ（例えば、１ＫＢ）のメモリ・ブロックである。パラメータ・ブロック２１０３は、圧縮／復元動作のパラメータを含む。パラメータ・ブロック２１０３は、実行する圧縮または復元の種類に関する命令を含む。例えば、ソフトウェアは、ＤＨＴを使用する代わりに（事前に定義されたエンコーディングである）固定ハフマン・テーブルを使用することによってデフレートを実行するよう要求することができ、またはソフトウェアは、開始時に新しいブロックを開くか、または終了時にブロックを閉じるよう（あるいは、そのどちらも行わないよう）要求することができる。ソフトウェアは、より良く圧縮することによって著しく多くの時間がかかる場合でも、そのような圧縮を試みるように指定することもできる。加えて、パラメータ・ブロック２１０３は、システムが中断されたか、または一時停止された場合に、圧縮動作／復元動作を再開するために必要な情報を含む。
図２２に示されているように、パラメータ・ブロック２１０３は、オーバーフロー・ソース・バッファ２１１０およびオーバーフロー・ターゲット・バッファ２１２０を含んでよい。ＰＵ１９０１内のミリコードが単独でパラメータ・ブロック２１０３を制御できるように、パラメータ・ブロック２１０３は、処理ユニットＰＵ１９０１によって常に使用可能であってよい。使用可能でない場合、デフレート呼び出しの外部で解決されるべきページ・アクセス例外が直ちに報告されることがある。オーバーフロー・ソース・バッファ２１１０およびオーバーフロー・ターゲット・バッファ２１２０は、一度にオーバーフロー・ソース・バッファ２１１０およびオーバーフロー・ターゲット・バッファ２１２０のうちの１つのみがバッファ領域を使用することによって、バッファ領域を共有し得る。本発明の追加または代替の実施形態に従って、キャッシュ・メモリ（例えば、５１２バイト）がオーバーフロー・ソース・バッファ２１１０およびオーバーフロー・ターゲット・バッファ２１２０として使用され得る。本発明の追加または代替の実施形態に従って、あふれているソースおよびあふれているターゲットのための個別のバッファが提供されてよい。
圧縮／復元手法では、さまざまなビット長を有する多くの種類のシンボルが存在する。シンボルの例示的な種類は次の通りである。
（ａ）圧縮されていないデータのリテラル・バイト、
（ｂ）３～２５８の長さを有する圧縮されていないデータのリテラル・バイトのシーケンス、
（ｃ）ハフマン・エンコーディングを適用した後の（ａ）の圧縮されたエンコーディング、
（ｄ）ハフマン・エンコーディングを適用した後の、単一の距離／長さの組によって表されると仮定する、（ｂ）の圧縮されたエンコーディング、
（ｅ）「ブロック終結」シンボルを付加して両方とも拡張された、（ｃ）および（ｄ）、ならびに
（ｆ）動的ブロックである場合はエンコードされたＤＨＴを含む、デフレート・ヘッダー（DEFLATE header）。
圧縮されていないデータのリテラルの長さは、例えば１バイトである。可逆データ圧縮において通常使用される１つのアルゴリズム（例えば、ＬＺ７７またはランレングス・エンコーディング・アルゴリズム）は、リテラル列の反復的発生を検出し、反復的シーケンスを代表的リテラル列および単一の距離／長さの組に置き換える。例えば、リテラル列「ａｌｉｃｅａｌｉｃｅａｌｉｃｅ」が存在すると仮定する。この文字列では、「ａｌｉｃｅ」が３回繰り返される。この場合、ＬＺ７７を使用した圧縮結果は、「ａｌｉｃｅ＜ＬＺｓｙｍｂｏｌＡ＞ｒ＜ＬＺＳｙｍｂｏｌＢ＞」となってよい。ここで、＜ＬＺｓｙｍｂｏｌＡ＞は「長さ５、５戻る一致」になり、＜ＬＺＳｙｍｂｏｌＢ＞は「長さ５、６戻る一致」または「長さ５、１１戻る一致」であってよい。このようなアルゴリズムを使用して、最大２５８バイトの反復的リテラル列を、例えば８ビットの長さおよび１５ビットの距離で構成されるエンコードされた一致に圧縮することができる。復元プログラムがそのようなエンコードされた一致（この一致は、１つのシンボルとして扱われる）を復元する場合、結果として得られるシーケンスのサイズは、対応する圧縮データの相対的に小さいサイズ（例えば、合計で２ビット～３１ビット）と比較して、最大２５８バイトに拡大することがある。これによって、ターゲット側でオーバーフローが引き起こされる可能性もある。シンボルの定義において、エンコードされた一致に対応するこの復元されたシーケンスは、エンコードされた一致の「対応部分」であり、この逆も同様である。したがって、復元されたシーケンスのうちの複数の単位列の破棄（例えば、ターゲット側でそれらに使用できるメモリ空間が存在しないことによる破棄）は、元のシーケンスと復元されたシーケンスの間に差異をもたらすため、反復的列の復元されたシーケンス（対応部分）は、分割されない「１つ」のシンボルとして扱われる。「対応部分」という用語は、シンボルの変換の結果として生成されたビット・シーケンスのことを指す。
圧縮／復元の例では、圧縮段階での「ターゲット・シンボル」という用語は、リテラルを表す圧縮されたシンボル、一致（例えば、ＬＺ７７アルゴリズムにおいて定義された一致、ランレングス・エンコーディングの結果など）を表すシンボル、または圧縮ヘッダー（例えば、ＤＨＴヘッダー）のことを指し、復元段階での「ソース・シンボル」という用語は、リテラルを表す圧縮されたシンボル、一致を表すシンボル、または圧縮ヘッダーのことを指し、復元段階での「ターゲット・シンボル」という用語は、リテラルを表す圧縮されたシンボルまたは一致を表すシンボルの復元の結果のことを指す。したがって、シンボルのサイズは、シンボルがソース側または出力側のいずれにあるか、およびシンボルが圧縮段階または復元段階のいずれにあるかに依って変化する。
アプリケーションにおいて比較的小さいメイン・ソース・バッファおよびメイン・ターゲット・バッファ（例えば、１ＭＢ）を使用して大きいファイル（例えば、５ＧＢ）を復元する場合、ターゲット・バッファ２１０２内の多くの空間がまだ使用可能であっても、メイン・ソース・バッファ２１０１の終端に達することがある。より多くのソースをメイン・ソース・バッファ２１０１内で処理させるには、使用可能な空間の最後のビットまで、メイン・ソース・バッファ２１０１を完全に利用する必要がある。そうでない場合、アプリケーションは、より多くのデータを同じメイン・ソース・バッファ２１０１に入力することができない。言い換えると、アプリケーションが、メイン・ソース・バッファ２１０１を再利用して、次のサイクルで部分的シンボルを完成させるために必要なビット（すなわち、残りの部分）を含む追加のソース・データを提供できるように、前述した部分的シンボルを利用する必要がある。復元段階でのソース・シンボルのサイズに起因して、場合によっては、メイン・ソース・バッファ２１０１がシンボルの境界で終了しないことがある。例えば、メイン・ソース・バッファ２１０１に格納された最後のシンボルが、メイン・ソース・バッファ２１０１の終端の９ビット前で終了することがある。次のシンボルのサイズが９ビットより大きい場合、残りの９ビットは、ソース・シンボル全体を収容するには不十分であることがある。圧縮段階でも同様の状況が発生する可能性がある。例えば、数百バイトの出力シンボルがメイン・ターゲット・バッファ２１０２の終端に達し、シンボルがページの境界を越え、次のターゲット・ページ上でページ・アクセス例外が発生することがある。この場合、例えば、１００バイトの長さの出力シンボルでは、１７バイトのみが使用可能なメイン・ターゲット・バッファ２１０２内に収まり、残りの８３バイトが次のページに流出する。すなわち、残りの８３バイトがメイン・ターゲット・バッファ２１０２に格納されずに残される。シンボルの長さが大きくなるにつれて、メモリ・ページまたはバッファの境界を越える可能性が高まる。
加えて、図２３を参照すると、ページ・アクセス例外が、ソース・バッファ／ターゲット・バッファの中央で発生することがある。本発明の１つまたは複数の実施形態に従って、シンボルが、ソース・バッファ／ターゲット・バッファまたはそのページの境界を越える場合、部分的シンボル（例えば、シンボルの第１の部分）がソース・バッファ／ターゲット・バッファの残りの空間を埋め、シンボルの残りの部分（例えば、シンボルの第２の部分）がオーバーフロー・バッファに格納される。ページのアドレスを使用できないことに起因して、デフレート命令が中断される可能性がある。ファームウェアに支援されて、後で命令が再び呼び出され、前の実行において停止した位置から続行され得る。
例えば、デフレート命令の後に、メイン・ソース・バッファ２１０１上のメモリの境界に近づいているときに、パラメータ・ブロック２１０３内のコマンドが、最後のソース・シンボルの部分的シンボルを含むソース・データ全体がメイン・ソース・バッファ２１０１内で利用されるということを伝える。言い換えると、アクセラレータ１９５０は、処理されるストリームの終端またはメイン・ソース・バッファ２１０１の終端に達するまで、メイン・ソース・バッファ２１０１内の完全なソース・シンボルを読み取る。メイン・ソース・バッファ２１０１の終端で、アクセラレータ１９５０が、シンボルの残りの部分（「第２の部分」）なしではデコードできない部分的シンボル（「第１の部分」）を受け取り、オーバーフロー・ソース・バッファ２１１０に格納する。この場合、ソース・シンボルの第２の部分がメイン・ソース・バッファ２１０１内にまだ存在しないため、アクセラレータ１９５０は、ソース・シンボルの第１の部分のみをオーバーフロー・ソース・バッファ２１１０にコピーし、オーバーフロー・ソース・バッファ２１１０内のソース・シンボルの第１の部分を、再呼び出し時に受信された第２の部分と一緒に後で処理する。本発明の追加または代替の実施形態に従って、アクセラレータ１９５０ではなく処理ユニット（ＰＵ）１９２０は、第１の部分をオーバーフロー・ソース・バッファ２１１０にコピーし得る。本発明の追加または代替の実施形態に従って、ソース・メモリ・ページＳ＋１上にアクセス例外が存在する場合に、ソース・メモリ・ページＳが部分的シンボルで終了することがある。この場合、ソースの処理されていない部分的シンボルがオーバーフロー・ソース・バッファ２１１０にコピーされる。復元動作の再開時に、オーバーフロー・ソース・バッファ２１１０内のソースの部分的シンボルが、ソース・データとしてアクセラレータ１９５０に供給され、その後に、次のサイクルで、メイン・ソース・バッファ２１０１に格納されているシンボルの残りの部分が続く。
別の例では、デフレート命令の後に、生成された出力が使用可能なメイン・ターゲット・バッファ２１０２を超える、メイン・ターゲット・バッファ２１０２上のメモリの境界に近づいているときに、パラメータ・ブロック２１０３内のコマンドが、メイン・ターゲット・バッファ２１０２の最後の使用可能な空間内に収まる部分的出力シンボルを含めて、メイン・ターゲット・バッファ２１０２全体が埋められるということを伝える。あふれている出力データ（最後のシンボルの残りの部分）が、パラメータ・ブロック２１０３のオーバーフロー・ターゲット・バッファ２１２０に格納される。言い換えると、アクセラレータ１９５０は、処理されるストリームの終端またはメイン・ターゲット・バッファ２１０２の終端に達するまで、変換されたターゲット・シンボルをメイン・ターゲット・バッファ２１０２に格納する。メイン・ターゲット・バッファ２１０２の終端で、アクセラレータ１９５０が、使用可能なメイン・ターゲット・バッファ２１０２をあふれさせる部分的出力シンボル（「第１の部分」）を受け取り、残りの部分的出力シンボル（「第２の部分」）をオーバーフロー・ターゲット・バッファ２１２０に格納する。本発明の追加または代替の実施形態に従って、ターゲット・メモリ・ページＴ＋１上にアクセス例外が存在する場合、完全な復元されたシンボルがターゲット・ページＴ内に収まらないことがある。この場合、アクセラレータ１９５０は、ページＴを完全に利用し、部分的シンボルＸをオーバーフロー・メイン・ターゲット・バッファ２１０２に入れる。パラメータ・ブロック２１０３が、圧縮動作／復元動作を再開するために必要な情報を含むため、圧縮の再開時に、パラメータ・ブロック２１０３のオーバーフロー・ターゲット・バッファ２１２０内の内容が、新たに使用可能なメイン・ターゲット・バッファ２１０２にコピーされる。
プロセッサＰＵ１９１０内のミリコードは、変換手法においてシンボルを定義するテーブル（例えば、ハフマン・テーブル）を使用して、シンボルがページまたはバッファの境界を越えるかどうかを検出し得る。ミリコードは、このテーブルを使用して、バッファの境界の最後の使用可能な空間に格納されたシンボルが、追加のソース・データなしでは完成されない部分的ソース・シンボルであるかどうかを検出し得る。
この実装の結果、アクセラレータがソース・シンボルを完全に処理すること、またはターゲット出力シンボルを完全に格納することを、バッファの使用可能な空間が許さない場合でも、アクセラレータ１９５０は、使用可能なソース・バッファおよびターゲット・バッファを完全に利用することができる。
オーバーフロー・バッファのサイズに関して、オーバーフロー・バッファは、シンボルの１ビットが前のメモリ・ページの最後、または次のメモリ・ページの最初に格納されるという状況を考慮して、シンボルの可能な最大長から１ビットを引いた長さを格納する必要がある。例えば、オーバーフロー・ソース・バッファ２１１０に関して、復元段階では、ＤＨＴヘッダーが最大のシンボルの長さを含んでよい。したがって、オーバーフロー・ソース・バッファ２１１０のサイズは、少なくとも、完全なＤＨＴヘッダーの最大長－１ビット（例えば、２８８バイト－１ビット）になる。
オーバーフロー・ターゲット・バッファ２１２０に関して、長さの要件は、動作が圧縮または復元のいずれであるかに依って変化する。圧縮段階でのオーバーフロー・ターゲット・バッファ２１２０の長さの要件は、復元段階でのオーバーフロー・ソース・バッファ２１１０の長さの要件（例えば、少なくとも、完全なＤＨＴヘッダーの最大長から１ビットを引いた長さ）と同じであってよい。復元段階では、オーバーフロー・ターゲット・バッファ２１２０の長さの要件は、少なくとも、シンボルの最大長から１ビットを引いた長さ（例えば、２５８バイト－１ビット）であってよい。本発明の追加または代替の実施形態に従って、オーバーフロー・ターゲット・バッファ２１２０の長さの要件は、１バイトがストレージの最小単位である場合、少なくとも、シンボルの最大長－１バイト（例えば、２５８バイト）であってよい。
本発明は、任意の可能な統合の技術的詳細レベルで、システム、方法、またはコンピュータ・プログラム製品、あるいはその組み合わせであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を含むコンピュータ可読ストレージ媒体を含んでよい。
コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持および格納できる有形のデバイスであることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組み合わせであってよいが、これらに限定されない。コンピュータ可読ストレージ媒体のさらに具体的な例の非網羅的リストは、ポータブル・フロッピー（Ｒ）・ディスク、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、読み取り専用メモリ（ＲＯＭ：read-only memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：erasable programmable read-only memoryまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：static random access memory）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：compact disc read-only memory）、デジタル・バーサタイル・ディスク（ＤＶＤ：digital versatile disk）、メモリ・スティック、フロッピー（Ｒ）・ディスク、パンチカードまたは命令が記録されている溝の中の隆起構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組み合わせを含む。本明細書において使用されるとき、コンピュータ可読ストレージ媒体は、それ自体が、電波またはその他の自由に伝搬する電磁波、導波管またはその他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、あるいはワイヤを介して送信される電気信号などの一過性の信号であると解釈されるべきではない。
本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から各コンピューティング・デバイス／処理デバイスへ、またはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、または無線ネットワーク、あるいはその組み合わせ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはその組み合わせを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。
本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：instruction-set-architecture）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路のための構成データ、あるいは、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの手続き型プログラミング言語を含む１つまたは複数のプログラミング言語の任意の組み合わせで記述されたソース・コードまたはオブジェクト・コードであってよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に実行すること、ユーザのコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行すること、ユーザのコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行すること、あるいはリモート・コンピュータ上またはサーバ上で全体的に実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）または広域ネットワーク（ＷＡＮ：wide area network）を含む任意の種類のネットワークを介してユーザのコンピュータに接続されてよく、または接続は、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行われてよい。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル論理回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ：field-programmable gate arrays）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：programmable logic arrays）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路をカスタマイズするためのコンピュータ可読プログラム命令を実行し得る。
本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して説明される。フローチャート図またはブロック図あるいはその両方の各ブロック、ならびにフローチャート図またはブロック図あるいはその両方に含まれるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装され得るということが理解されるであろう。
これらのコンピュータ可読プログラム命令は、コンピュータまたはその他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作を実施する手段を作り出すべく、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読ストレージ媒体がフローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作の態様を実施する命令を含む製品を備えるように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、または他のデバイス、あるいはその組み合わせに特定の方式で機能するように指示できるものであってもよい。
コンピュータ可読プログラム命令は、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で実行される命令が、フローチャートまたはブロック図あるいはその両方のブロックに指定される機能／動作を実施するように、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスに読み込まれてもよく、それによって、一連の動作可能なステップを、コンピュータ上、その他のプログラム可能な装置上、またはコンピュータ実装プロセスを生成するその他のデバイス上で実行させる。
図内のフローチャートおよびブロック図は、本発明のさまざまな実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表し得る。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生し得る。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、実質的に同時に実行されるか、または場合によっては逆の順序で実行されてよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、ならびにブロック図またはフローチャート図あるいはその両方に含まれるブロックの組み合わせは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組み合わせを実行する専用ハードウェアベースのシステムによって実装され得るということにも注意する。
本発明のさまざまな実施形態の説明は、例示の目的で提示されているが、網羅的であることは意図されておらず、開示された実施形態に限られない。説明された実施形態の範囲から逸脱することなく多くの変更および変形が可能であることは、当業者にとって明らかであろう。本明細書で使用された用語は、実施形態の原理、実際の適用、または市場で見られる技術を超える技術的改良を最も適切に説明するため、または他の当業者が本明細書に記載された実施形態を理解できるようにするために選択されている。
本明細書では、関連する図面を参照して、本発明のさまざまな実施形態が説明される。本発明の範囲を逸脱することなく、本発明の代替の実施形態が考案され得る。以下の説明および図面において、要素間のさまざまな接続および位置関係（例えば、上、下、隣接など）が示される。それらの接続または位置関係あるいはその両方は、特に規定されない限り、直接的または間接的であることができ、本発明はこの点において限定するよう意図されていない。したがって、各実体の結合は、直接的結合または間接的結合を指すことができ、各実体間の位置関係は、直接的位置関係または間接的位置関係であることができる。さらに、本明細書に記載されたさまざまな作業および工程段階は、本明細書に詳細に記載されない追加の段階または機能を含むさらに包括的な手順または工程に組み込まれ得る。
以下の定義および略称が、特許請求の範囲および本明細書の解釈に使用される。本明細書において使用されているように、「備える」、「備えている」、「含む」、「含む」、「有する」、「有している」、「含有する」、「含有している」という用語、またはこれらの任意のその他の変形は、非排他的包含をカバーするよう意図されている。例えば、要素のリストを含む組成、混合、工程、方法、製品、または装置は、それらの要素のみに必ずしも限定されず、明示されていないか、またはそのような組成、混合、工程、方法、製品、または装置に固有の、その他の要素を含むことができる。
さらに、「例」という用語は、本明細書では「例、事例、または実例としての役割を果たす」ことを意味するために使用される。「例」として本明細書に記載された実施形態または設計は、必ずしも他の実施形態または設計よりも好ましいか、または有利であると解釈されるべきではない。
本明細書では、「第１」、「第２」、「第３」などの用語が、さまざまな要素、コンポーネント、領域、層、またはセクション、あるいはその組み合わせを説明するために使用されてよいが、これらの要素、コンポーネント、領域、層、またはセクション、あるいはその組み合わせがこれらの用語によって制限されるべきではないということが、理解されるであろう。これらの用語は、ある要素、コンポーネント、領域、層、またはセクションを別の要素、コンポーネント、領域、層、またはセクションと区別するためのみに使用される。したがって、以下で説明される「第１の要素」、「コンポーネント」、「領域」、「層」、または「セクション」は、本明細書における教示から逸脱することなく、第２の要素、コンポーネント、領域、層、またはセクションと呼ばれ得る。
本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、制限することを意図していない。本明細書において使用されるとき、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、内容が特に明確に示していない限り、「少なくとも１つ」などの複数形を含むよう意図されている。「少なくとも１つ」は、「ａ」または「ａｎ」を制限していると解釈されるべきではない。「または」は、「および／または」を意味する。本明細書において使用されるとき、「および／または」という用語は、関連する示された項目のうちの１つまたは複数の任意の組み合わせまたはすべての組み合わせを含む。「複数」という用語は、２以上の任意の整数（すなわち、２、３、４、５など）を含むと理解されてよい。「接続」という用語は、間接的「接続」および直接的「接続」の両方を含んでよい。
「約」、「実質的に」、「近似的に」、およびこれらの変形の用語は、本願書の出願時に使用できる機器に基づいて、特定の量の測定に関連付けられた誤差の程度を含むよう意図されている。例えば、「約」は、特定の値の±８％または５％、あるいは２％の範囲を含むことができる。

Claims (25)

  1. 処理ユニットと、
    アクセラレータと、
    外部ソースから受信されたソース・シンボルの第１の部分を格納するように構成されたメイン・ソース・バッファと、ここで、前記受信されたソース・シンボルのサイズが前記メイン・ソース・バッファの使用可能なサイズよりも大きい、
    前記アクセラレータから受信された出力シンボルを格納するように構成されたメイン・ターゲット・バッファと、
    オーバーフロー・ソース・バッファと
    を含むメモリ・ブロックを備えているシステムであって、
    前記処理ユニットまたは前記アクセラレータが、前記メイン・ソース・バッファ内に格納された前記第1の部分を前記オーバーフロー・ソース・バッファにコピーし、そして、前記アクセラレータが、前記オーバーフロー・ソース・バッファ内にコピーされた前記第１の部分と、前記外部ソースから受け取った前記ソース・シンボルの第２の部分とをフェッチし、前記フェッチされた第１の部分と前記第２の部分とを一緒に前記出力シンボルに復元又は圧縮する復元動作又は圧縮動作を実行するように構成され、ここで、前記第２の部分が、前記第１の部分に含まれていない前記ソース・シンボルの部分を含んでおり、
    前記処理ユニットが、前記アクセラレータを呼び出して前記復元動作又は前記圧縮動作を実行するように構成されている、
    前記システム。
  2. 前記フェッチされた第１の部分と前記第２の部分とを一緒に前記出力シンボルに復元する復元動作を実行するように構成されている、請求項１に記載のシステム。
  3. 前記処理ユニットが、ミリコードを介して前記アクセラレータの前記復元動作又は前記圧縮動作を制御するために操作可能である、請求項１に記載のシステム。
  4. 前記第１の部分が、前記メイン・ソース・バッファ中の使用可能な最後のビット空間に格納される、請求項１ないし請求項３のいずれか１項に記載のシステム。
  5. 前記ソース・シンボルが圧縮ヘッダーを含む、請求項１ないし請求項４のいずれか１項に記載のシステム。
  6. 前記メモリ・ブロックが、前記復元動作又は前記圧縮動作が中断されたか、又は一次停止された場合に、前記復元動作又は前記圧縮動作を再開するのに必要なパラメータをさらに含む、請求項１ないし請求項５のいずれか１項に記載のシステム。
  7. 処理ユニットと、
    アクセラレータと、
    外部ソースから受信されたソース・シンボルを格納するように構成されたメイン・ソース・バッファと、
    前記アクセラレータから受信された出力シンボルの第１の部分を格納するように構成されたメイン・ターゲット・バッファと、ここで、前記受信された出力シンボルのサイズが前記メイン・ターゲット・バッファの使用可能なサイズよりも大きい、
    オーバーフロー・ターゲット・バッファと
    を含むメモリ・ブロックを備えているシステムであって、
    前記オーバーフロー・ターゲット・バッファが、前記アクセラレータから受信された前記出力シンボルの第２の部分を格納するように構成され、ここで、前記第２の部分が、前記第１の部分に含まれていない前記出力シンボルの部分を含んでおり、
    前記処理ユニットまたは前記アクセラレータが、前記メイン・ターゲット・バッファ内に格納された前記第1の部分を前記オーバーフロー・ターゲット・バッファにコピーし、そして、前記アクセラレータが、前記オーバーフロー・ターゲット・バッファ内にコピーされた前記第１の部分と、前記外部ソースから受け取った前記ソース・シンボルの第２の部分とをフェッチし、前記フェッチされた第１の部分と前記第２の部分とを一緒に前記出力シンボルに復元又は圧縮する復元動作又は圧縮動作を実行するように構成され、
    前記処理ユニットが、前記アクセラレータを呼び出して前記復元動作又は前記圧縮動作を実行するように構成されている、
    前記システム。
  8. 前記フェッチされた第１の部分と前記第２の部分とを一緒に前記出力シンボルに復元する復元動作を実行するように構成されている、請求項７に記載のシステム。
  9. 前記処理ユニットが、ミリコードを介して前記アクセラレータの前記復元動作又は前記圧縮動作を制御する、請求項７または請求項８のいずれか１項に記載のシステム。
  10. 前記メイン・ターゲット・バッファが、前記出力シンボルの前記第１の部分を前記メイン・ターゲット・バッファ中の使用可能な最後のビット空間に格納する、請求項７ないし請求項９のいずれか１項に記載のシステム。
  11. 圧縮モードで、前記ソース・シンボルが圧縮ヘッダーを含む、請求項７ないし請求項１０のいずれか１項に記載のシステム。
  12. 前記メモリ・ブロックが、記復元動作又は前記圧縮動作が中断されたか、又は一次停止された場合に、前記復元動作又は前記圧縮動作を再開するのに必要なパラメータをさらに含む、請求項７ないし請求項１１のいずれか１項に記載のシステム。
  13. コンピュータの情報処理による方法であって、
    処理ユニットまたはアクセラレータによって、外部ソースから受信されたソース・シンボルの第１の部分をメイン・ソース・バッファに格納すること、ここで、前記受信されたソース・シンボルのサイズが前記メイン・ソース・バッファの使用可能なサイズよりも大きい、
    前記第１の部分が、前記外部ソースから受信された前記ソース・シンボルの第２の部分を含んでないとの決定に基づいて、前記処理ユニットまたは前記アクセラレータによって、前記メイン・ソース・バッファ内に格納された前記第１の部分をオーバーフロー・ソース・バッファにコピーすること、
    前記アクセラレータによって、前記オーバーフロー・ソース・バッファにコピーされた前記第１の部分、前記外部ソースから受け取った前記ソース・シンボルの第２の部分とをフェッチすること、
    前記アクセラレータによって、前記フェッチされた第１の部分と前記第２の部分とを出力シンボルに一緒に前記出力シンボルに復元又は圧縮すること、
    前記処理ユニットまたは前記アクセラレータによって、前記アクセラレータから受信された前記出力シンボルをメイン・ターゲット・バッファに格納すること
    を含み、
    ここで、前記ソース・シンボルの前記第２の部分が、前記第１の部分に含まれていない前記ソース・シンボルの部分を含み、前記アクセラレータがハードウェア・エンジンを含む、
    前記方法。
  14. 前記処理ユニットが、ミリコードを介して前記アクセラレータの動作を制御する、請求項１３に記載の方法。
  15. 前記メイン・ソース・バッファが、前記ソース・シンボルの前記第１の部分を前記メイン・ソース・バッファ中の使用可能な最後のビット空間に格納する、請求項１３または請求項１４のいずれか１項に記載の方法。
  16. 前記使用可能な最後のビット空間が、ページ・アクセス例外が発生する位置の直前の前記メイン・ソース・バッファ内の空間である、請求項１５に記載の方法。
  17. 前記フェッチされた第１の部分と前記第２の部分とを一緒に前記出力シンボルに復元する復元動作を実行するように構成されている、請求項１３ないし請求項１６のいずれか１項に記載の方法。
  18. コンピュータの情報処理による方法であって、
    処理ユニットまたはアクセラレータによって、外部ソースから受信されたソース・シンボルをメイン・ソース・バッファに格納すること、
    前記処理ユニットまたは前記アクセラレータによって、前記アクセラレータから受信された出力シンボルの第１の部分をメイン・ターゲット・バッファに格納すること、ここで、前記受信された出力シンボルのサイズが前記メイン・ターゲット・バッファの使用可能なサイズよりも大きい、
    前記出力シンボルの第２の部分を格納することに前記メイン・ターゲット・バッファを使用できないということの決定に基づいて、前記処理ユニットまたは前記アクセラレータによって、前記アクセラレータから受信された前記第２の部分をオーバーフロー・ターゲット・バッファに格納すること
    前記アクセラレータによって、前記オーバーフロー・ターゲット・バッファに格納された前記第１の部分と前記第２の部分とを一緒に出力シンボルに復元動作又は圧縮動作を実行すること、
    を含み、
    ここで、前記ソース・シンボルの前記第２の部分が、前記第１の部分に含まれていない前記ソース・シンボルの部分を含み、前記アクセラレータがハードウェア・エンジンを含む、
    前記方法。
  19. 前記処理ユニットが、ミリコードを介して前記アクセラレータの前記復元動作又は前記圧縮動作を制御する、請求項１８に記載の方法。
  20. 前記メイン・ソース・バッファが、前記ソース・シンボルの前記第１の部分を前記メイン・ソース・バッファ中の使用可能な最後のビット空間に格納する、請求項１８または請求項１９のいずれか１項に記載の方法。
  21. 前記使用可能な最後のビット空間が、ページ・アクセス例外が発生する位置の直前の前記メイン・ソース・バッファ内の空間である、請求項２０に記載の方法。
  22. 前記復元動作又は前記圧縮動作が中断されたか、又は一次停止された場合に、前記オーバーフロー・ターゲット・バッファに格納された前記出力シンボルの前記第２の部分を前記メイン・ターゲット・バッファに供給することによって、前記復元動作又は前記圧縮動作を再開することをさらに含む、請求項１８ないし請求項２１のいずれか１項に記載の方法。
  23. 請求項１３ないし請求項２２のいずれか１項に記載の方法をコンピュータに実行させる、コンピュータ・プログラム。
  24. 請求項２３に記載の前記コンピュータ・プログラムをコンピュータ可読ストレージ媒体に格納した、ストレージ媒体。
  25. コンピュータ可読ストレージ媒体に格納されて、請求項１ないし請求項１２のいずれか１項に記載の前記システムのいずれかの内部メモリに読み込まれるコンピュータ・プログラムであって、前記コンピュータ・プログラムが前記システムで実行された場合に請求項１３ないし請求項２２のいずれか１項に記載の方法をコンピュータに実行させる、前記コンピュータ・プログラム。
JP2021545748A 2019-02-27 2020-02-27 メモリ境界の収容のためのオーバーフロー管理方法、システム、プログラム Active JP7481073B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/286,703 US10673460B1 (en) 2019-02-27 2019-02-27 Spilling temporary results for accommodation of memory boundaries
US16/286,703 2019-02-27
PCT/EP2020/055105 WO2020174033A1 (en) 2019-02-27 2020-02-27 Spilling temporary results for accommodation of memory boundaries

Publications (3)

Publication Number Publication Date
JP2022521465A JP2022521465A (ja) 2022-04-08
JPWO2020174033A5 JPWO2020174033A5 (ja) 2022-06-07
JP7481073B2 true JP7481073B2 (ja) 2024-05-10

Family

ID=69726569

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021545748A Active JP7481073B2 (ja) 2019-02-27 2020-02-27 メモリ境界の収容のためのオーバーフロー管理方法、システム、プログラム

Country Status (9)

Country Link
US (1) US10673460B1 (ja)
EP (1) EP3931971A1 (ja)
JP (1) JP7481073B2 (ja)
CN (1) CN113474999A (ja)
AU (1) AU2020230012B2 (ja)
CA (1) CA3131257A1 (ja)
IL (1) IL284763B1 (ja)
MX (1) MX2021010029A (ja)
WO (1) WO2020174033A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10831497B2 (en) * 2019-01-31 2020-11-10 International Business Machines Corporation Compression/decompression instruction specifying a history buffer to be used in the compression/decompression of data
US11119928B2 (en) 2019-02-27 2021-09-14 International Business Machines Corporation Instant quiescing of an accelerator
CN112988673B (zh) 2021-02-22 2023-02-28 山东英信计算机技术有限公司 一种处理解压缩过程中数据溢出的方法和设备
US11669331B2 (en) * 2021-06-17 2023-06-06 International Business Machines Corporation Neural network processing assist instruction

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180293028A1 (en) 2017-04-05 2018-10-11 International Business Machines Corporation In-place data compression with small working memory

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05189157A (ja) * 1992-01-13 1993-07-30 Toshiba Corp ディスク型記憶装置
JPH10232838A (ja) * 1996-11-05 1998-09-02 Hitachi Ltd ディスク記憶システム
CA2434257A1 (en) 2003-07-03 2005-01-03 Ibm Canada Limited - Ibm Canada Limitee Pairing of spills for parallel registers
US9031826B2 (en) 2006-03-30 2015-05-12 International Business Machines Corporation Method and apparatus for simulating operation in a data processing system
US20100030927A1 (en) 2008-07-29 2010-02-04 Telefonaktiebolaget Lm Ericsson (Publ) General purpose hardware acceleration via deirect memory access
WO2012103359A2 (en) 2011-01-27 2012-08-02 Soft Machines, Inc. Hardware acceleration components for translating guest instructions to native instructions
US8495258B2 (en) 2011-05-24 2013-07-23 International Business Machines Corporation Implementing storage adapter performance optimization with hardware accelerators offloading firmware for buffer allocation and automatically DMA
US8824569B2 (en) * 2011-12-07 2014-09-02 International Business Machines Corporation High bandwidth decompression of variable length encoded data streams
US9152673B2 (en) 2012-12-11 2015-10-06 Intel Corporation Non-deterministic finite automaton (NFA) overflow recovery that ejects an end of scan set of active states into a buffer
US9171007B2 (en) * 2013-03-15 2015-10-27 International Business Machines Corporation Compression/decompression accelerator protocol for software/hardware integration
CN105579959B (zh) 2013-09-24 2019-06-07 渥太华大学 硬件加速器虚拟化
US9306596B2 (en) * 2014-06-27 2016-04-05 Intel Corporation Hybrid CAM assisted deflate decompression accelerator
US9419647B2 (en) * 2014-12-16 2016-08-16 Intel Corporation Partitioned data compression using accelerator
US9755731B2 (en) 2015-01-10 2017-09-05 Hughes Network Systems, Llc Hardware TCP accelerator
US10067893B2 (en) 2015-04-03 2018-09-04 Futurewei Technologies, Inc. Acceleration framework with direct data transfer mechanism
US9952865B2 (en) * 2015-04-04 2018-04-24 Texas Instruments Incorporated Low energy accelerator processor architecture with short parallel instruction word and non-orthogonal register data file
US9690488B2 (en) * 2015-10-19 2017-06-27 Intel Corporation Data compression using accelerator with multiple search engines
US10169073B2 (en) 2015-12-20 2019-01-01 Intel Corporation Hardware accelerators and methods for stateful compression and decompression operations
US10177782B2 (en) * 2015-12-26 2019-01-08 Intel Corporation Hardware apparatuses and methods for data decompression
US10055255B2 (en) 2016-04-14 2018-08-21 International Business Machines Corporation Performance optimization of hardware accelerators
US10241956B2 (en) 2016-09-12 2019-03-26 International Business Machines Corporation Virtualizing coherent hardware accelerators
US9715470B1 (en) 2016-09-26 2017-07-25 International Business Machines Corporation Direct memory access between an accelerator and a processor using a coherency adapter
US10691996B2 (en) 2016-12-15 2020-06-23 Beijing Deephi Intelligent Technology Co., Ltd. Hardware accelerator for compressed LSTM
US11178063B2 (en) 2017-06-30 2021-11-16 Intel Corporation Remote hardware acceleration

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180293028A1 (en) 2017-04-05 2018-10-11 International Business Machines Corporation In-place data compression with small working memory

Also Published As

Publication number Publication date
EP3931971A1 (en) 2022-01-05
IL284763A (en) 2021-08-31
CA3131257A1 (en) 2020-09-03
WO2020174033A1 (en) 2020-09-03
IL284763B1 (en) 2024-09-01
JP2022521465A (ja) 2022-04-08
CN113474999A (zh) 2021-10-01
AU2020230012A1 (en) 2021-06-03
US10673460B1 (en) 2020-06-02
MX2021010029A (es) 2022-06-16
AU2020230012B2 (en) 2023-01-12

Similar Documents

Publication Publication Date Title
JP7481073B2 (ja) メモリ境界の収容のためのオーバーフロー管理方法、システム、プログラム
US10698854B1 (en) Secure and efficient application data processing
JP7442529B2 (ja) データの圧縮／解凍で使用する履歴バッファを指定する圧縮／解凍命令
JP7442526B2 (ja) 圧縮／解凍オペレーションを実行するための汎用プロセッサ命令
US11119928B2 (en) Instant quiescing of an accelerator
WO2020174300A1 (en) Functional completion when retrying non-interruptible instruction in bi-modal execution environment
US11487547B2 (en) Extended asynchronous data mover functions compatibility indication
JP7430195B2 (ja) 複数のマシン世代にわたる複合体の機能の互換性の維持

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20220512

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220527

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220725

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230630

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230711

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231005

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20231005

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231227

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240119

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240409

RD14 Notification of resignation of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7434

Effective date: 20240411

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240423

R150 Certificate of patent or registration of utility model

Ref document number: 7481073

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150