JP4475820B2 - 拡張可能な埋込み型のパラレルデータを圧縮及び圧縮解除するためのシステムと方法 - Google Patents

拡張可能な埋込み型のパラレルデータを圧縮及び圧縮解除するためのシステムと方法 Download PDF

Info

Publication number
JP4475820B2
JP4475820B2 JP2000596668A JP2000596668A JP4475820B2 JP 4475820 B2 JP4475820 B2 JP 4475820B2 JP 2000596668 A JP2000596668 A JP 2000596668A JP 2000596668 A JP2000596668 A JP 2000596668A JP 4475820 B2 JP4475820 B2 JP 4475820B2
Authority
JP
Japan
Prior art keywords
data
symbols
compression
symbol
decompression
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.)
Expired - Lifetime
Application number
JP2000596668A
Other languages
English (en)
Other versions
JP2002536863A (ja
Inventor
エイ ダイ トーマス
ジェイ アルバレス 二世 マヌエル
ガイガー ペーター
Original Assignee
モスマン ホールディングス エルエルシー
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
Priority claimed from US09/239,659 external-priority patent/US7190284B1/en
Priority claimed from US09/491,343 external-priority patent/US6822589B1/en
Application filed by モスマン ホールディングス エルエルシー filed Critical モスマン ホールディングス エルエルシー
Publication of JP2002536863A publication Critical patent/JP2002536863A/ja
Application granted granted Critical
Publication of JP4475820B2 publication Critical patent/JP4475820B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

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
    • 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/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
    • H03M7/3086—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method employing a sliding window, e.g. LZ77
    • 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/3084—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method
    • H03M7/3088—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction using adaptive string matching, e.g. the Lempel-Ziv method employing the use of a dictionary, e.g. LZ78
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/436—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation using parallelised computational arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Description

発明の名称
拡張可能な埋込み型のパラレルデータを圧縮及び圧縮解除するためのシステムと方法。
発明の属する技術分野
本発明は、コンピュータシステムアーキテクチャに関し、一層詳しくはシステム帯域を減少させ、かつ効率を改善するためにパラレルデータを圧縮及び圧縮解除する、システムと方法に関するものである。
関連発明の説明
1981年初期段階以来、パーソナルコンピュータシステムのアーキテクチャは、本質的に変わっていない部分を残している。コンピュータシステムアーキテクチャにおける現状技術は、システムメモリーと接続するメモリー制御インターフェイスに同様に繋がれる中央演算処理部（CPU）を有する。コンピュータシステムは、また、ビデオディスプレイに接続するための分離された画像インターフェイスを有している。更に、コンピュータシステムは、キーボード、マウス、フロッピードライブ、不揮発性メモリ他、さまざまなI/Oデバイス用の入出力制御ロジックを有している。
現代のコンピュータアーキテクチャの動作は、一般に次の通りである。プログラムとデータは、個々のI/O装置、例えばフロッピーディスクやハードドライブからオペレーティングシステムによって読み取られる。またプログラムやデータは、システムメモリに臨時に貯えられる。一旦、ユーザープログラムがシステムメモリに移されると、CPUは、メモリーコントローラを介してシステムメモリからのコードやデータを読み取ることで、プログラムを実行する。アプリケーションのコードやデータは、システムCPUによって操作されたときにスペックの結果を生じるように予定されている。CPUは、コードとデータを処理し、データは一つあるいはそれ以上のいろいろな出力装置（アウトプットディバイス）に供給される。コンピュータシステムは、ビデオディスプレイ、オーディオ（スピーカ）、プリンタその他を含む幾つかの出力装置を備える。ほとんどのシステムでは、ビデオディスプレイが基本の出力装置である。
CPUによって処理されたグラフィック出力データは、ディスプレイモニタに表されるためにグラフィカルインターフェイスディバイスに書き込まれる。グラフィカルインターフェイスディバイスは単なるＶＧＡカードで良い。あるいはシステムが、別途のビデオラム（ＶＲＡＭ）を有する専用のビデオプロセッサやビデオアクセラレイションカードを含むものでも良い。分離された専用のビデオプロセッサを有するコンピュータシステムでは、ビデオプロセッサは、主CPUの負担を少なくするグラフィック能力をもつ。パーソナルコンピュータシステムの最近の先行技術は、PCI（Peripheral Component Interface）バス、AGP(Advanced Graphics Port)、あるいは他のローカルバス標準に基づくローカルバスビデオシステムを含んでいる。ビデオのサブシステムは、一般に、処理能力を上げるためにCPUの近くのローカルバスに配置される。
したがって、概略すると、プログラムコードとデータは、最初に不揮発性メモリ、例えばハードディスクからシステムメモリに読み込まれる。プログラムコードとデータは、次に、システムメモリからCPUに読み込まれる。データはCPUによって処理され、またグラフィックデータは、ディスプレイモニタに表示するためのグラフィカルインターフェイスディバイスのビデオラムに書き込まれる。
メモリコントローラへのシステムメモリインターフェイスは、必要とされるアプリケーションとシステムに対し釣合いのとれた帯域幅のデータを必要とする。したがって、システムパフォーマンスを向上させるためには、より広いデータバスあるいはより高速の特別なメモリディバイスが必要となる。これらの解決策は、システムコストとパワーとノイズを増加させるといった付加的側面での効果が生じるのを余儀なくさせる。図1は、従来技術を使用する典型的なコンピュータメモリコントローラとシステムメモリにおけるデータの伝送経路を示す。
CPUは、システムメモリからデータを通常のあるいは非圧縮のフォーマットでローカルバスを介して読み取り、次いで、処理データもしくはグラフィックデータをグラフィカルインターフェイスディバイスが配置されているI/Oバスもしくはローカルバスに戻し、そこで書き込みを行う。グラフィカルインターフェイスディバイスは、ディスプレイモニタを動作させる適切なビデオ信号を作り出す。注意するのは、先行技術のコンピュータアーキテクチャとその操作の場合、システムメモリとCPUの間あるいはシステムメモリとローカルI/Oバスの間のデータのやり取りにデータの圧縮と圧縮解除（展開もしくは解凍）を行わないという点である。先行技術のコンピュータアーキテクチャは、また、ユーザーのアプリケーションやオペレイティングシステムのソフトウェアを動作させるに必要なシステムメモリのサイズを小さくするために、何も行わない。加えるに、圧縮及び圧縮解除のアルゴリズムによって制御された
図面の簡単な説明
図１は、従来のコンピュータシステムアーキテクチャを示す。
図２Ａは、本発明の一実施例に係る、メモリF/Xテクノロジを有する統合メモリコントローラ（IMC）を備えたコンピュータシステムを示す。
図２Ｂは、本発明の一実施例に係る、メモリF/Xテクノロジを有するノースブリッジメモリコントローラを備えたコンピュータシステムを示す。
図２Ｃは、本発明の一実施例に係る、メモリF/Xテクノロジを有するCPUを備えたコンピュータシステムを示す。
図２Ｄは、本発明の一実施例に係る、メモリF/Xテクノロジを有するメモリモジュールを少なくとも一つ備えたコンピュータシステムを示す。
図２Ｅは、本発明の一実施例に係る、メモリF/Xテクノロジを有するネットワークインターフェイスを備えたコンピュータシステムを示す。
図３Ａと３Ｂは、本発明の一実施例に係る、メモリF/Xテクノロジを有するメモリモジュールを示す。
図４は、本発明の一実施例に係る、メモリF/Xテクノロジを有するネットワークディバイス，例えばルータを示す。
図５は、本発明の一実施例に係る、メモリF/Xテクノロジを有する携帯端末を示す。
図６は、本発明の一実施例に係る、IMCの内部構造を示す。
図７は、IMCのメモリコントローラの内部構造を示すブロックダイアグラムを示す。
図８は、IMC140を構成する圧縮／圧縮解除ロジックを示すさらに詳細なブロックダイアグラム。
図９Ａは、従来技術の辞書ベースのＬＺシリアル圧縮アルゴリズムによるシーケンシャル圧縮技術を示す。
図９Ｂは、本発明の一実施例に係る、パラレル圧縮アルゴリズムを示す。
図１０は、パラレル圧縮の操作を示すハイレベルのフローチャートダイアグラムである。
図１１は、パラレル圧縮の操作を示すさらに詳細なフローチャートダイアグラムである。
図１２は、パラレル圧縮及び圧縮解除ユニットのエントリデータヒストリと、比較入力データと結果計算とを示す。
図１３は、パラレルセレクションと出力発生ブロックダイアグラムを示す。
図１４ａと１４ｂは、本発明においてパラレル圧縮操作が行われている間の出力セレクションのために用いられるパラレル出力マスクと、出力カウンタと、マスクカウンタ値との操作を示す表。
図１４ｃは、出力マスクの集合あｋら結合マスクの生成を示す。
図１５は、出力ジェネレータフローダイアグラムを示す。
図１６は、多重サイクルを通るデータフローを示すパラレル圧縮操作の一例を示す。
図１７は、不可逆的圧縮と可逆的圧縮エンジンを示す。
図１８は、アルファ値を含まないイメージデータの不可逆的圧縮出力フォーマットを示すテーブルである。
図１９は、アルファ値を含むイメージデータの不可逆的圧縮出力フォーマットを示すテーブルである。
図２０は、不可逆的と可逆的圧縮及び圧縮解除操作を結合したブロックダイアグラムである。
図２１は、圧縮及び圧縮解除メモリの有効性のためにIMCによって用いられるソース及びデスティネイションデータの複数の圧縮フォーマットを示す。
図２２と２３は、本発明の一実施例に係る、圧縮モードを用いるメモリアクセスの操作を示すフローチャートダイアグラムである。
図２４は、圧縮アドレストランスレーションと、ディクショナリと、オーバーフローブロックアドレストランスレーションの流れを示す。
図２５は、圧縮割り当てテーブル及びオーバーフローテーブルと、圧縮メモリエリア及びオーバーフローメモリエリアのためのメモリ割り当てフィールドを示す表である。
図２６は、圧縮アドレストランスレーションテーブルのための初期化プロセスフローを示す。
図２７は、圧縮及び圧縮解除ユニットのための記録トランザクションプロセスを示す。
図２８は、メモリフェッチプロセスフローを示す。
図２９は、次のアドレス生成プロセスフローを示す。
図３０は、本発明の一つの実現法に従ったメモリ割り当てスペースと圧縮比率を示す表である。
図３１は、要求システムエージェントによって連続するメモリ読取サイクルの待ち時間を減らすために使用する圧縮再指令アルゴリズムを示す。
図３２は、本発明の一実施例に係る、不可逆的圧縮解除エンジンを提供するためのヘッダ情報を示す表である。
図３３は、本発明の一実施例に係る、パラレル可逆的圧縮アルゴリズムのために用いられる４ステージを示す。
図３４は、本発明の一実施例に係る、パラレル圧縮解除プロセスのために用いられるスタートカウントを生成するに必要な８つのデコーダステージを示す。
図３５は、本発明の一実施例に係る、図３３のステージ入力セレクタとバイトカウンタによって用いられる単一デコーダブロックを示す。
図３６ａは、本発明の一実施例に係る、デコードブロックの正当性チェック結果テーブルを示す表である。
図３６ｂは、本発明の一実施例に係る、バイトチェックセレクトロジックとデータ入力に基づいたデータ生成出力を表す表である。
図３７は、本発明の一実施例に係る、セレクトとオーバーフローを計算するための図３３に示す４ステージの二番目の部分を表す。
図３８は、本発明の一実施例に係る、最終セレクトのステージ２において生成された予測セレクトを変換するために図３３に示す４ステージの三番目の部分を示す。
図３９は、本発明の一実施例に係る、最初の３ステージにおいて生成されたセレクトから非圧縮出力バイトを生成するために図３３で示す４ステージの四番目の部分を示す。
図４０は、本発明の一実施例に係る、パラレル可逆的圧縮エンジンを通過するデータフローを示す。
図４１は、パラレル圧縮解除プロセスに用いられる情報を生成するとともに３２ビットの入力データを受け入れるための３つのデコーダステージの一実施例を示す。
図４２ａは、本発明の一実施例に係る、４つの入力バイトと、３つのデコーダと、４つの出力バイトを有する圧縮解除エンジンを示す。
図４２ｂは、本発明の一実施例に係る、図４２ａに示す圧縮解除エンジンへの入力の圧縮解除を例示を示す。
図４３ａは、パラレル圧縮解除エンジンのハイレベルのフローチャートを示す。図４３ｂは、本発明の一実施例に係る、パラレル圧縮解除法を示すフローチャートである。
図４３ｃは、本発明の一実施例に係る、圧縮データから複数のトークンをパラレルに調査するためのプロセスを示すフローチャートである。
図４３ｄは、本発明の一実施例に係る、一つもしくはそれ以上のトークンを圧縮解除されたものに解凍するためのプロセスを示すフローチャートである。
図４３ｅは、本発明の一実施例に係る、カウント及びインデックスあるいはデータバイト情報をパラレルに生成するためのプロセスを示すフローチャートである。
図４３ｆは、本発明の一実施例に係る、結合されたヒストリウィンドウ内の記号に複数のセレクトを生成するためのプロセスを示すフローチャートである。
図４３ｇは、本発明の一実施例に係る、予備的なセレクトを生成するためのプロセスを示すフローチャートである。
図４３ｈは、本発明の一実施例に係る、最終セレクトを生成するためのプロセスを示すフローチャートである。
図４３ｉは、本発明の一実施例に係る、結合されたヒストリウィンドウから非圧縮記号を書き込むためのプロセスを示すフローチャートである。
図４３ｊは、本発明の一実施例に係る、カレント圧縮解除サイクルによって非圧縮とされた記号をヒストリウィンドウに書き込むプロセスを示すフローチャートである。
図４３ｋは、本発明の一実施例に係る、図４３ｂ、４３ｃ、４３ｄを結合した圧縮解除プロセスを示すフローチャートである。
好ましい実施例の詳細な説明
先行技術のコンピュータシステムアーキテクチャ
図1は、先行技術のコンピュータシステムアーキテクチャのブロックダイアグラムを示す。図示するように、先行技術のコンピュータアーキテクチャは、キャッシュシステム104に接続したCPU102を含んでいる。CPU102はキャッシュシステム104に接続してあり、またローカルバス106に接続してある。ノースブリッジ108として関係づけられるメモリーコントローラ108は、ローカルバス106に接続してある。また、メモリーコントローラ108は、システムメモリ110に接続してある。グラフィックアダプタ112は、分離されたローカル拡張バス、例えばＰＣＩもしくはＡＧＰに接続してある。したがって、ノースブリッジメモリコントローラ108は、CPU102と主システムメモリ110との間に接続され、ノースブリッジロジックはまたグラフィックアダプタ112が配置されたローカル拡張バスに接続してある。グラフィックアダプタ112は、ディスプレイモニタに実際に表示されるピクセルデータとして関係づけられるビデオデータを貯えるフレームバッファメモリ114に接続してある。
現代の先行技術コンピュータシステムは、典型的には、1から8メガバイトのビデオメモリを含んでいる。I/Oサブシステムコントローラ116は、図示されるようにローカルバス106に接続されている。ＰＣＩバスを含んだコンピュータシステムでは、I/OサブシステムコントローラはＰＣＩバスに接続されている。I/Oサブシステムコントローラ116は、セカンダリの入力／出力（I/O）バス118に接続してある。不揮発性メモリ、例えばハードディスク120、キーボード122、マウス124、及びオーディオディジタルアナログコンバータ（ＤＡＣ）238を含むいろいろな周辺I/O装置は、一般にI/Oバス18に接続されている。
先行技術のコンピュータシステムアーキテクチャは、一般に次のように動作する。第一に、プログラムやデータは一般にハードディスクに記憶されている。もし、ソフトウェアの圧縮アプリケーションが用いられているとすると、データは圧縮フォーマットでハードディスク120に記録されているかも知れない。CPU102の指図にしたがって、プログラムとデータ、はハードディスクからI/Oサブシステムコントローラ116を介しメモリコントローラ108経由でシステムメモリ110に伝送される。
もし、ハードディスク120から読み取られるデータが圧縮フォーマットで記録されているとすると、データは、システムメモリ110に伝送される前にCPUによって実行されるソフトウェアにより圧縮解除される。したがって、圧縮アプリケーションソフトウェアは、システムメモリ110に記録される前に圧縮データをハードディスク120からCPU102へ伝送する必要がある。
CPU102は、メモリコントローラ108とローカルバス106を介してシステムメモリ110に記録されたプログラムとデータにアクセスする。プログラムコードとデータの処理において、CPU102は、ローカルバス106と一般的にはＰＣＩバスもしくはＡＧＰバスを介して指示とデータをグラフィックアダプタ112に提供する。グラフィックアダプタ112は、CPU102からグラフィックに関する指示もしくはピクセルデータを受け取り、フレームバッファメモリ114に記録されるピクセルデータを作成する。グラフィックアダプタ112は、フレームバッファメモリ114に記録されたピクセルデータを表示するためのビデオディスプレイ装置（図示せず）を駆動させるに必要なビデオ信号を作成する。スクリーン上のウィンドウがアップデートされあるいは変更されると、上記プロセスが繰り返され、CPU102がローカルバス106を介してシステムメモリ110からデータを読取り、データをローカルバス106とローカル拡張バスを介してグラフィックアダプタ112とフレームバッファメモリ114に伝送して戻す。
コンピュータシステムが、データを圧縮フォーマットでハードディスク120に記録したい場合、データはCPUによって読み取られ、圧縮アプリケーションソフトによって圧縮される。圧縮データはそれからハードディスク120に記録される。もし、圧縮データがシステムメモリ110に記録されていると、CPU102は、圧縮データを読み取り、そのデータを圧縮解除し、そして圧縮解除されたデータをシステムメモリ110に戻して書き込むことを要求される。
しかしながら、現在のコンピュータシステムあるいはコンピュータ製品では、システムメモリコントローラは、メインシステムメモリにとっての有効帯域幅を最適化するための圧縮と圧縮解除の技術を備えていない。
ＲＡＭＢＵＳのような特殊な技術は、少ないピン数に高帯域幅を供給するために、メモリディバイスとメモリコントロールユニットの両方に用いられる。ＲＡＭＢＵＳメモリのアーキテクチャに関する更なる情報については、1993年7月発行の「ＲＡＭＢＵＳ,Ｉｎｃ」社による「ＲＡＭＢＵＳアーキテクチャル概観、第2版」、1992年3月発行の「ＲＡＭＢＵＳ,Ｉｎｃ」社によ「デスクトップコンピュータのメインメモリサブシステムにＲＡＭＢＵＳを適用するための技術、第1版」を参照いただきたい。ＲＡＭＢＵＳの技術は、低いメモリチップで高い帯域幅を達成するけれども、ＲＡＭＢＵＳチャンネルの超高周波伝送効果によってコスト上の問題と同様にパワーとノイズについての問題を惹きおこすことについては譲歩せざるを得ない。加えるに、より高い帯域幅を達成するために、伝送チャンネルは、メモリコントローラとメモリそれ自身の両方に付加的なロジック（論理）を必要とする。そして、またより高いパワーとノイズを惹きおこす。
64メガバイトかそれ以上のメインメモリＤＲＡＭは、パッケージサイズやアドレス及びデータピンの数を増加させ続ける。この傾向に起因したピン数の増加によって、かつてのより小さなＤＲＡＭアーキテクチャにより有効帯域幅をバンク（ｂａｎｋ）状ＤＲＡＭがより高い帯域幅にするという能力は帳消しとなる。
実施例
図2Ａは、本発明を組み込んだシステムの一実施例のブロックダイアグラムを示す。図2Ａは実施例の一例である。ここに記載された技術は、さまざまなシステムやアーキテクチャにおけるものを含んでいることに注意されたい。例えば、本発明技術は、コンピュータシステム、テレビジョンシステム（ＨＤＴＶ）、
、インターネット装置、ＰＤＡ（携帯用情報端末）、あるいはデータを伝送しあるいは記録データのメモリを含む他のシステムにおけるものを含んでいる。本発明の技術は、本発明の使用の一例であるコンピュータシステムアーキテクチャを参照しつつ下記される。図1におけるものと類似あるいは同一である図2Ａのエレメントは、便宜上同じ符号を付してある。
図示するように、CPU102を有するコンピュータシステムは、キャッシュシステム104に接続されている。CPU102は、内部第一レベルのキャッシュシステムを有し、キャッシュ104は第2レベルキャッシュから成る。キャッシュシステム104は、第一レベルのキャッシュシステムでも良いしあるいは望みによっては省略しても良い。CPU102とキャッシュシステム104は、ローカルバス106に接続されている。CPU102とキャッシュシステム104は、本発明の一実施例に見られるように、ローカルバス106を介して集積メモリコントローラ140に直接、接続されている。
集積メモリコントローラ（IMC）140は、メモリを制御する要素であり、コンピュータシステムのパフォーマンスを著しく増加させるメモリF/Xテクノロジ200を有する。知られているように、IMCは、メインシステムメモリ110のコントローラとして用いられ、あるいは望みに応じて他のメモリサブシステムをコントロールするために用いられる。IMC140は、システムメモリ110に接続されている。システムメモリ110は、一つもしくはそれ以上のDRAMから成り、また複数の異なるタイプのメモリディバイスから成っている。IMCは、本発明でメモリF/Xテクノロジコア200として参照されるメモリコントローラコアを有する。メモリF/Xテクノロジコア200は、好ましくはIMC140内に埋め込まれるが、IMC140の外部にあってもあるいはCPU102内に含まれていても良い。IMC140の全体は、CPU102に集積されたものであっても良い。他の実施例では、メモリF/Xテクノロジ200はノースブリッジ108内に含まれ、例えば標準的なチップセットロジックに埋め込まれる。メモリF/Xテクノロジコア200は、メモリ圧縮や圧縮解除、システムメモリのコントロール、圧縮フォーマット、キャッシュディレクトリ、データキャッシュコントロール、有効データ帯域幅及びシステムメモリ転送の有効性を改善するためのデータの多重送信を実行する。
IMC140は、望むとおりの様々なタイプのメモリに接続できる。好ましい例では、IMC140は、RAMBUSを介してシステムメモリ110に接続される。RAMBUSメモリアーキテクチャに関する詳細な情報については、上記したRAMBUS参照個所を見てもらいたい。さらに別の実施例では、システムメモリ110は、SGRAMあるいはSIMM（Single in -line memory modules）から成る。上記したように、本発明のIMC140は望みの様々なタイプのメモリに接続できる。
IMC140は、また、ビデオディスプレイ装置142のための適切なビデオ信号を発する。IMC140は、ビデオディスプレイにイメージを生成するための水平及び垂直同期信号と同様に赤、緑、青（RGB）の信号を発する。したがって、集積されたメモリコントローラ140は、メモリコントローラとビデオ及びグラフィックコントローラの能力を一つの論理ユニットに集積したものである。このことは、バスのデータ通行量を著しく減らし、システムパフォーマンスを向上させる。一つの実施例では、IMC140は、また、オーディオプレゼンテーションのためのオーディオDAC238に提供される適切なデータ信号を発する。あるいはIMC140は、オーディオプロセッシングとオーディオDACの能力を統一し、スピーカに直接提供されるオーディオ信号を出力する。
本発明のIMC140は、好ましくはメインCPUバスか高速システム周辺バスに配置される。IMC140は、またCPU102の近くあるいはそれに直接まとめられ、例えばCPU102の同じチップを構成するようにしても良い。図2Ａと3に示す実施例では、IMC140は、ローカルバス106あるいはCPUバスに直接接続されている。そこではIMC140は、Ｌ2キャッシュシステム104を介してCPU102に面している。代わりの実施例では、Ｌ2キャッシュとコントローラ104は、CPU102あるいはIMC140に統一されていても良く、また用いられなくとも良い。
I/Oサブシステムコントローラ116は、ローカルバス106に接続されている。I/Oサブシステムコントローラ116は、またオプショナルI/Oバス118に接続されている。様々なI/O装置、例えばハードディスク120のような不揮発性メモリ、キーボード122、マウス124を含むI/O装置がI/Oバスに接続されている。
一つの実施例では、I/OバスはPCIバスであり、I/Oサブシステムコントローラ116はPCIバスに接続されている。
典型的なコンピュータプログラムは、アプリケーションデータを伝送するために、CPUによって実行されるプログラムコードを伝送するよりも多くのローカルバス帯域幅を必要とする。アプリケーションデータには、ビットマップイメージ、テキストを出力するためのフォントテーブル、テーブルや初期設定情報のように定数として決定付けられる情報などを含む。グラフィック及び／またはビデオデータは、ビデオデータがグラフィック出力装置に書き出される前に、例えばCPU102によってディスプレイ実行される。したがって、殆どのケースでは、実際のプログラムコードは、CPU102によって実行され、CPU102は、記録するのにアプリケーションデータそれ自体よりもかなり少ないシステムメモリ110しか消費しないアプリケーションデータを操作する。
IMC140は、新規なシステムアーキテクチャを含んでいる。このアーキテクチャは、システム帯域幅のボトルネックを減じ、CPU102がアプリケーションデータ及び／もしくはプログラムコードを操作し、移動するのに要求される余分な操作を取り除くのに役立つ。ある実施例によれば、IMC140は、データの圧縮／圧縮解除エンジンを含んでいる。このエンジンは、アプリケーションデータ及び／もしくはプログラムコード、すなわちシステム内のあらゆるデータが圧縮フォーマットで動くのを許容する。IMC140の圧縮／圧縮解除エンジンの操作は、下記に詳説される。
IMC140は、また、グラフィックデータあるいはビデオデータを操作するためのハイレベルのプロトコルを含んでいる。このプロトコルは、ビデオ操作に必要とされるバスを通過するデータの流れの量を著しく少なくし、システムパフォーマンスを大きく向上させる。このハイレベルプロトコルは、ビデオリフレッシュシステム及び方法に基づいたディスプレイリストを含んでいる。それによって、ビデオディスプレイ装置142に表示される対象物（オブジェクト）の動きは、システムメモリ110のピクセルデータの移動を必ずしも必要とすることがなく、むしろディスプレイリフレッシュリスト内のディスプレイアドレスポインタの操作だけが必要であり、ピクセルビットブロック伝送やアニメーション及び2D，3Dオブジェクトの操作のパフォーマンスが大きく向上する。IMC140のビデオ／グラフィックの操作に関する詳細については、米国特許第5,838,334号を参照されたい。IMC140は、また3Dオブジェクトを表示するための改良されたシステムと方法を含んでいる。
図2Ａは、IMC140を有するコンピュータシステムのデータ転送パスの一例を示すものでもある。上記したように、典型的なコンピュータシステムでは、プログラムコードとデータは、当初、不揮発性メモリ120に記録される。そして、第一に、IMC140は、DMA（direct memory access）方法及び／もしくはバスコントロール方法を用いて不揮発性メモリ120に貯えられたプログラムコードやデータを読み取る。そこでは、IMC140はローカルバス106のマスタとして動作する。プログラムコードとデータがIMC140によって不揮発性メモリ120から読み取られ、システムメモリ110に記録される。他の実施例では、プログラムコードやデータは、CPUの制御下で不揮発性メモリ120からIMC140に伝送される。データは、圧縮フォーマットの状態で不揮発性メモリ120からシステムメモリ110に伝送されても良い。このようなデータは、ディスクへの記録サイズが小さくて済み、ローカルバスの帯域幅を減少させる。データが不揮発性メモリ120からIMC140に伝送されると、データは、IMC140内の圧縮解除エンジンによって解凍され、圧縮解除された状態でシステムメモリバンク110に記録される。一般に、磁気媒体（ハードディスク）のI/O伝送率は、ゆっくりした速度であり、圧縮データがディスク120から受け取られたときにそのデータを圧縮解除して記録するには十分である。データは、圧縮フォーマットの状態でシステムメモリに記録されても良い。また、データは、非圧縮状態でキャッシュに記録されても良い。
CPU102は、最近に圧縮解除されたシステムメモリ110からのプログラムコードを読み取ることによって、プログラム実行を始めても良い。また、IMC140の圧縮解除エンジンは、システムメモリ110内にある圧縮解除データ記録するのと平行して、圧縮解除データをCPU102に提供する。他の代わりの実施例では、データは圧縮フォーマットの状態でメモリに記録され、CPU120が、圧縮解除されてCPU102に送られる結果データにアクセスする。
プログラムコードの一部は、ビデオディスプレイ142上のディスプレイ出力を制御するようIMC140に命令するための特別なグラフィカルプロトコルを用いて、データ及び／もしくは指令をIMC140に書き戻すために必要な情報を含んでいる。多くの場合、システムメモリ110に正しく記録されるグラフィカルデータは、システムメモリ110に残される必要はなく、また、システムメモリ110内の他の場所に移す必要もなく、むしろ、本発明のIMC140の高度なグラフィカルプロトコルとリストを基準とするディスプレイ操作とによって、CPU112がIMC104にどのようにしてウインドウや他のグラフィカルデータをスクリーンに表示するかを指示することができる。これにより、先行システムに対する大きな改良をもたらす。
図2Ｂから2Ｅ：別の実施例
図2Ｂは、本発明を組み込んだシステムの一例を示すブロック図である。図2Ｂの例において、メモリF/Xテクノロジ200はノースブリッジ108内に設けられいる。すなわちメモリF/Xテクノロジ200は標準的なチップセットロジック内に埋め込まれている。
図2Ｃは、本発明を組み込んだシステムの一例を示すブロック図である。図2Ｃの例において、メモリF/Xテクノロジ200はCPU102の内部にある。メモリF/Xテクノロジ200は、CPU及び／またはCPUL1あるいはL2キャッシュコントローラ内のいろいろな望みの場所に設けられる。
図2Ｄはシステムの一例を示すブロック図で、この例では、メモリF/Xテクノロジ200は、少なくとも一つのメモリモジュール110上に設けられている。一つあるいはそれ以上のシステムメモリモジュール110は、メモリF/Xテクノロジであるのと同様にメモリ構成部材もしくは装置であり、一つもしくはそれ以上の双方向圧縮／圧縮解除エンジンを含んでいる。メモリF/Xテクノロジは、モジュール上に設けられたメモリ構成部材もしくは装置へ／からデータが伝送されるときに、そのデータを圧縮／圧縮解除の処理操作を行うことができる。
図2Ｂの一つあるいはそれ以上のフレームバッファメモリモジュール114は、同様に本発明に係るメモリF/Xテクノロジを含んでいる。一つあるいはそれ以上のフレームバッファメモリモジュール114は、メモリF/Xテクノロジを成すのと同様にメモリ構成部材もしくは装置を成す。
メモリモジュール110及び／または114上に設けられたメモリ構成部材もしくは装置は、どのようなタイプのものであっても良い。例えばSDRAM（static dynamic random access memory）、DIMM（dual in-line memory module）あるいは他のタイプのメモリ構成部材であっても良い。加えるに、RAMBUSのような特殊技術は、メモリ装置や、少ないピン数のものに高帯域幅を持たせるためのメモリコントロールユニットのいずれにも用いることができる。RAMBUSメモリアーキテクチャの更なる情報については、RAMBUS社が1993年7月に発行した「RAMBUSアーキテクチャ概観（第2.0版）」と、RAMBUS社が1992年3月に発行した「デスクトップコンピュータのメインメモリシステムへのRAMBUS適用技術（第1.0版）」を参照されたい。
本発明の他の実施例では、メモリF/Xテクノロジは、例えばノースブリッジ108もしくはIMC140のようなメモリコントローラと一つもしくはそれ以上のメモリモジュール110との間に配設される。
図2Ｅは、システムの一例のブロック図である。そこでは、メモリF/Xテクノロジは、ネットワークインターフェイス装置もしくはカード121上に設けられている。ネットワークインターフェイス装置121は、
ネットワーク、例えばインターネット、構内ネットワーク（LAN）その他の広域ネットワーク（WAN）へデータを伝送し／これらネットからデータを受け取るときに、そのデータを圧縮／圧縮解除する処理操作を行うことができる。
図3Ａと3Ｂ：メモリモジュール実施例
図3Ａと3Ｂは、メモリF/Xテクノロジを含んだメモリモジュール571のボードアセンブリ（基板上の集合配置）の一例を示す。メモリモジュール571は、メモリF/Xテクノロジの小型チップ250と同じく複数のメモリ装置573を有する。メモリF/Xテクノロジ小型チップ250は、サブセットタイプだけのものあるいはメモリF/Xテクノロジ全体であっても良い。例えば、メモリF/Xテクノロジ小型チップ250は、リアルタイムで圧縮を行うメモリF/Xテクノロジの並列的に圧縮／圧縮解除を行うエンジン部のみを含んでいる。メモリF/Xテクノロジ小型チップ250は、また、並列的に圧縮／圧縮解除をおこなう技術を用いて、改良された仮想メモリファンクションを実行するための仮想メモリロジックを含んでいる。
図3Ａはモジュールの前面を、また図3Ｂはモジュールの裏面を表している。図3Ａと図3Ｂは、メモリモジュールデザインの好ましい例を示している。好ましくは、インテルPC100あるいはPC133のスペックに順応する256MBレジスタのDIMMである。他の実施例では、より大きな及び／または小さなサイズのレジスタのDIMMとして設計されたものであっても良いし、あるいは異なるフォームファクタあるいはスペックのものであっても良い。メモリF/Xテクノロジ200は、勿論他のメモリモジュールデザインのものに含まれるようにしても良い。付け加えるに、メモリF/Xテクノロジ200あるいはメモリF/Xテクノロジ200の変形例は、RAMBUSあるいはダブルデータレートDRAM装置に用いられても良い。他の異なる実施例では、JDEC規格で提案されているようなメモリタイプや異なるDRAM群オプションを含む。また、他の実施例は、多重の異なるメモリモジュール規格に沿ったこれらのメモリタイプを混合したものを含む。
図4−ネットワーク装置
図4は、メモリF/Xテクノロジ200が含まれたルータのようなネットワーク装置を示す。ネットワークインターフェイスディバイス121のように、ネットワーク装置130は、ネットワーク、例えばインターネット、構内ネットワーク（LAN）その他の広域ネットワーク（WAN）へデータを伝送し／これらネットからデータを受け取るときに、そのデータを圧縮／圧縮解除する処理操作を行うことができる。このようにして、本発明は、インターネットあるいは他のネットワークを介して伝送されたほとんどあるいは全てのデータが、圧縮フォーマットの状態で伝送される設備を提供できる。
図5−PDA
図5は、メモリF/Xテクノロジ200を有する携帯用情報端末（PDA−personal data assistant）あるいはインターネット装置を表している。
ネットワークインターフェイス装置121やネットワーク装置と同じように、PDA132は、ネットワーク、例えばインターネット、構内ネットワーク（LAN）その他の広域ネットワーク（WAN）へデータを伝送し／内部メモリからデータを受け取るときに、そのデータを圧縮／圧縮解除する処理操作を行うことができる。
図2Ａから2Ｅ、3ＡからＢ、図4そして図5に示された上記システムのそれぞれにおいては、システムは、単に、メモリF/Xテクノロジ200のサブセットタイプのものあるいは全体を含むものである。例えば、上記したシステムは、メモリF/Xテクノロジ200の並列的な圧縮／圧縮解除を行うエンジン部だけを含んでいる。本発明の下記する実施例では、メモリF/Xテクノロジはメモリコントローラ、例えばIMC140内に組み込まれている。図6から8は、メモリF/XテクノロジがIMC内に組み込まれた実施例を示す。図9は、進んで、メモリF/Xテクノロジの操作を示す。下記する説明では、メモリF/Xテクノロジがメモリコントローラ内にあるものとして記載されているが、メモリF/Xテクノロジは、上記した典型的な実施例に記されているように様々な装置に含まれる。
図6−IMCのブロック図。
図6は、好ましい実施例においてIMC140の内部構成を示すブロック図である。IMC140は、本発明にしたがってメモリF/Xテクノロジを組み込んである。図示するように、本発明は、IMC140のメモリコントローラユニット220の内部に、データを圧縮／圧縮解除するエンジンとコントロールファンクションを統合してある。これにより、不揮発性データへの格納量あるいは要求される書庫への格納量が減り、またシステム内でデータを伝送するために必要な帯域幅の量が減り、この結果、全体にわたるシステムコストの低減となる。このことは、システムメモリリソースの必要とされる量を減らすことになる。そのため、データが記録のために圧縮されたときに、最近は使用されていないあるいはスクリーンに表示されないデータは、より多くのデータがシステムメモリに格納される。
本発明は、上記したような様々なシステムアーキテクチャを持ついろいろなタイプのコンピュータシステムあるいは装置に組み込まれることに、留意すべきである。他の実施例では、データを圧縮／圧縮解除するエンジンは、どのような装置（デバイス）内に統合されても良い。ある実施例では、本発明は、I/Oバスを増加させたり、システムへのコストを上げたりすることなく、帯域幅や有効性について改善できる。
メモリコントローラは、異なる圧縮モードにも動作する。
一つのモードは、通常の圧縮モードで、使用されるメモリ量を少なくする。オペレーティングシステムによって割り当てられたアドレスを新しいアドレス、つまり実行される圧縮にしたがってメモリの使用量を最小にするアドレスに移動することによって、使用されるメモリ量を減少させる。また、この実施例では使用されるメモリ量を少なくするけれども、優先圧縮モードである互換モードの場合、メモリサイズの節約を行うものではなく、その代わりに全ての待ち時間をより少なくしまた帯域幅をより高くするために付加的にセーブされたメモリを交換する。優先圧縮モードにおいて、圧縮／圧縮解除を改良したものにするには、ソフトウェアあるいはOS（Operating system software）になんの変更もしないことが必要である。通常圧縮モードと優先圧縮モードは、下記する通りである。
図６にある様々な要素は、互いに接続されている。多様な接続手段は、図６を単純化するために記されていない。IMC140は、ホストコンピュータシステムに接続するためのバスインターフェイスロジック202を有している。好ましい例では、ローカルバス106はCPUバスあるいはホストバスである。別の例では、ローカルバス106はPCIバスで、バスインターフェイスロジック202はPCIバスに接続してある。命令記憶装置／復号ロジック（図示しない）は、バスインターフェイスロジック202に接続されている。
バスインターフェイスロジック202は、メモリコントロールユニット220に接続してある。メモリF/Xテクノロジは、好ましくはメモリコントロールブロック220の内部に設けられる。コントロールバス201は、全てのユニットをローカルCPUインターフェイス202に接続する。実行エンジン210コントロールバス201と介してローカルCPUインターフェイス202とメモリインターフェイス221に接続され、また実行エンジン210は、メモリコントローラに接続してある。ローカルバス106のデータと指令は、ローカルCPUインターフェイスを介してローカルバス201に送られる。ローカルバス201は、実行エンジン210、メモリインターフェイス221、グラフィックエンジン212、周辺I/Oバスインターフェイス234、VDRLエンジン240、ビデオ入力及びフォーマット変換ユニット235、最後にオーディオ及びモデムサブシステム236に、順に接続される。加えるに、実行エンジン210は、メモリコントローラ220及びメモリインターフェイス221を通してメインシステムメモリ110に接続されている。
グラフィックエンジン212は、また、メモリコントローラ220及びメモリインターフェイス221を通してメインシステムメモリに接続されている。こうして、データは、メモリコントローラ220によるデータ伝送と効率性に関する助力を得て、グラフィックエンジン212によってラスター化とピクセル描画出力のために読み込まれ、かつ書き込まれる。更に、他のブロックは、同じような環境下で、メモリコントローラ220とメモリインターフェイス221を通してシステムメモリ110に接続されている。
図６に示すように、メモリコントローラ220は、データをシステムメモリ110とリクエスティングユニットとの間に伝送する。リクエスティングユニットは、実行エンジン210、ローカルCPUあるいはRISCインターフェイス202、オーディオ及びモデムサブシステム236、ビデオI/Oインターフェイス、VDRLエンジン240、周辺バスインターフェイス234、並びにグラフィックエンジン212を含んでいる。リクエスティングユニットは、メモリコントローラ220に、システムメモリインターフェイス221を通してシステムメモリ110にデータを伝送する処理を行うよう要求する。各リクエスティングユニットは、メモリの効率がより高くなるよう、異なる圧縮フォーマットを表現しあるいは役立たせる。このようにして、リクエスティングユニットの制御とメモリコントローラブロック220による支援の下に、複数のデータ圧縮フォーマットが存在する。
図７−メモリコントロールユニット
図７は、メモリコントロールブロック220を示す。好ましい実施例では、メモリコントローラ220は、並列（parallel）圧縮及び圧縮解除エンジン251を含んでいる。別の実施例では、メモリコントローラ220は、単一あるいはシリアル（連続的）な圧縮エンジンと、単一あるいはシリアルな圧縮解除エンジンとを含んでいる。また、並列圧縮及び圧縮解除ユニット251は、分離された不可逆な（lossy）圧縮及び圧縮解除を行うエンジン（後に詳説）を含んでいる。このエンジンは、分離されあるいは統一されたユニットとして設計される。他の別の実施例では、個別の圧縮及び／もしくは圧縮解除を行うユニットが、圧縮と圧縮解除を最適に効率良く行うためにIMC140の複数の領域に配置される。
メモリコントロールブロック220は、一つもしくはそれ以上のパラレルもしくはシリアルの圧縮／圧縮解除エンジンを含んでいる。このエンジンには、一つもしくはそれ以上のパラレル及び／もしくはシリアルの圧縮／圧縮解除を行うエンジン、及び／もしくは一つもしくはそれ以上のパラレル及び／もしくはシリアルの不可逆な圧縮／圧縮解除を行うエンジンを含む。ここで用いられる「圧縮／圧縮解除エンジン」という語は、一つもしくはそれ以上のパラレル、シリアル、可逆な（lossless）及び／もしくは不可逆な（lossy）圧縮／圧縮解除エンジンの全ての組み合わせを含むことを意図している。これらのエンジンは、統合されたブロックあるいは分離されたブロックにあろうとそうでなかろうと構わないし、メモリコントローラの内部にあるか外部にあるかを問わないし、他のユニット例えばCPU102にあろうと構わない。
メモリコントローラ220の好ましい実施例にあるサポートブロックは、スイッチロジック261、圧縮コントロールユニット281、圧縮データディレクトリ271、Ｌ3データキャッシュメモリ291、及びメモリインターフェイスロジック221を含んでいる。図７においてメインシステムメモリ110は、メモリコントローラブロック220の外部にあり、参照符合でのみ表してある。加えて、Ｌ3データキャッシュ291は、外部メモリのない標準的なメモリ（SRAMあるいは埋込型のDRAM）であり、またキャッシュタイプのメモリとして形成されるものでも良い。メモリコントローラ220への入力信号は、図７に示されるように、IMC140内の各リクエスティングユニットからのリクエストバスやコントロールバス211、並びに複数のアドレスバス215やデータバス216を構成する。更に、リクエスティングエージェントのそれぞれは、共通のアドレス／データバスを共有している。メモリコントローラ220は、メインシステムメモリ110に橋渡しする出力信号を発生する。これらの出力信号は、前記した多様なDRAMメモリ装置を駆動させるに必要な複数の制御信号を形成する。
再度、図７を参照するに、スイッチロジック261は、メモリコントローラ220に提示される正しいデータやアドレスサイクルを示すに必要なコントロールバスやストロウブを含む全てのリクエスティングユニットのアドレスとデータバスに相互伝送可能に接続（interface）されている。スイッチロジック261は、また、メモリコントローラ220内にある他のユニットにアドレスとデータを追いやるのに必要なポートを有する。スイッチロジック261は、パラレル圧縮及び圧縮解除ユニット251と圧縮コントロールユニット281から読み込みあるいはこれらに書き込みするデータを制御する。加えるに、圧縮されていないあるいは圧縮解除されないデータ（通常あるいはバイパスデータ）に関しては、スイッチロジック261は、メモリインターフェイスロジック221へのインターフェイスを直接制御する。異なるデータ圧縮フォーマットのためにアドレスととデータの切り換え方向を適切に制御するために、スイッチロジック261は、圧縮コントロールユニット281とリエストバス211から制御入力信号を受け取る。スイッチロジック261は、また、後で詳説するように、パラレル圧縮及び圧縮解除ユニット251と相互に作用しあう。こうして、スイッチロジック261は、優先計画に沿ってリクエストをランキングし、また通常あるいは圧縮メモリトランザクションのためのリクエストをフィルタリングしながら、メモリ制御とデータ伝送処理のために入ってくるリクエストを間にたって裁定する。
図７をもう一度参照するに、圧縮コントロールユニット281は、メモリトランザクションリクエストをリクエスト及びコントロールバスから受けとり、またスイッチユニット261から各メモリトランザクションの制御のためのアドレスを受け取る。圧縮コントロールユニット281は、各メモリトランザクションリクエストを適切に処理し、セットアップするために、スイッチロジック261と、圧縮データディレクトリ271と、ローカルデータキャッシュメモリ（Ｌ3データキャッシュ）291と、メモリインターフェイスロジック221と、パラレル圧縮及び圧縮解除ユニット251を指揮する。圧縮コントロールユニット281は圧縮データディレクトリ271と相互伝送可能に接続されている。圧縮データディレクトリ271は、ＬＬ3データキャッシュ291、SRAMバッファ（パラレル圧縮及び圧縮解除ユニット251内に設けられている）、システムメモリ110のどれかのアドレスブロックが開始する位置を捜し出すために用いられる。こうして、圧縮コントロールユニット281は、IMC140内の他のユニットからのリクエストを受け取り、アドレスによる位置を翻訳し、圧縮ブロックサイズを決定し、そして、メインシステムメモリ110から読み込んだり、メインシステムメモリ110に書き込んだりするのに必要な適切なアドレスとデータトランザクションのためにメモリコントローラ220のサブユニットを制御する。
図７に見られるデータキャッシュ291は、最近使われたリクエストデータを戻すことによって、処理の待ち時間を最小にするために用いられる。データキャッシュ291は、CPU102あるいはシステムがＬ1とＬ2キャッシュを含んでいる場合のＬ3データキャッシュである。キャッシュ291は、所望に応じてCPU102のためＬ2あるいはＬ1キャッシュとして動作するものであっても良い。この説明では、キャッシュ291は、Ｌ3キャッシュとしてある。
Ｌ3データキャッシュのサイズは、IMC140のリクエスティングユニットにデータを戻すに必要なクロックの平均的な数字を決める。本実施例では、最も最近用いられたデータは、Ｌ3データキャッシュ291に圧縮されずに記録される。Ｌ3データキャッシュ291に常駐するデータには、パラレル圧縮及び圧縮解除ユニット251による圧縮や圧縮解除は行われない。こうして、ヒットされたＬ3データキャッシュへのトランザクションリクエストは、メインメモリ110にリクエストする場合に比べ、データをほとんど待ち時間なしに戻すことができる。Ｌ3データキャッシュ291は、典型的には、圧縮されていないデータのみを有している。別の実施例では、Ｌ3データキャッシュ291は、最も最近用いられたデータを圧縮フォーマットの状態で記録しても良いし、圧縮フォーマットと非圧縮フォーマットの混在した状態で記録しても良い。メモリコントローラ210内のＬ3データキャッシュ291は、コンベンショナルメモリコントローラと共働して、最も最近用いられたデータを通常の待ち時間遅れを生じさせることなしに戻すことができる。
パラレル圧縮及び圧縮解除エンジン251がSRAMバッファ記憶装置を有しない実施例では、Ｌ3データキャッシュ291は、将来的な圧縮のための書き込みブロックと将来的な圧縮解除のための読み込みブロックを記録するために用いられるSRAMバッファを２倍にすることができる。Ｌ3データキャッシュ291は、読み込みか書き込み処理用の将来的な圧縮解除を待つ圧縮ブロックを記録するために用いられるようにしても良い。例えば、Ｌ3データキャッシュ291は、圧縮されて不揮発性メモリに伝送されるために待っているLRUページの記録に用いられるようにしても良い。Ｌ3データキャッシュ291とこれに共働するキャッシュコントロールロジック281は、非圧縮処理（圧縮しないあるいは圧縮解除）を要求する圧縮／圧縮解除トランザクションあるいはトランザクションの両方を読み書き両処理するためのメモリアクセスの待ち時間を改良するためにトランザクションをバッファに入れる。
再度、図７を参照して、メモリインターフェイスロジック221は、圧縮コントロールユニット281から制御信号を受け取り、スイッチロジック261（圧縮しないというトランザクション）あるいは圧縮データディレクトリ271のいずれかからアドレスとデータを受け取り、そして、DRAMデバイスのタイプに基づいてメインメモリ110への配送電圧のレベルとタイミングを制御する。メモリインターフェイスロジック221は、こうしてメモリのコンフィギュレーションとデバイスタイプの一致するメインシステムメモリ110につながれるために用いられる。
パラレル圧縮及び圧縮解除ユニット251は、次のセクションで詳説される。
図８−圧縮／圧縮解除エンジン
図８に見られるように、パラレル圧縮及び圧縮解除ブロック251は、圧縮エンジン570/575と圧縮解除エンジン550/555を含んでいる。上記したように、パラレル圧縮及び圧縮解除エンジン251は、単一の可逆なパラレル圧縮及び圧縮解除エンジン、及び／もしくは単一の不可逆な圧縮及び圧縮解除エンジン、あるいは可逆及び／もしくは不可逆なエンジンの組合せを有するものであっても良い。
パラレル圧縮及び圧縮解除ユニット251は、従来実行されているようなシリアル記号データストリームに代えてパラレル記号データストリームを用いながら高速でパラレル圧縮及び圧縮解除を行う。圧縮及び圧縮解除ユニット251のパラレル処理は、帯域幅を減少するために最適化され、待ち時間を減少される。こうして、パラレル圧縮及び圧縮解除エンジンは、より高速で圧縮解除と圧縮を行い、帯域幅を実質的に増加し、先行技術の圧縮および圧縮解除エンジンよりも待ち時間を少なくする。パラレル圧縮のためのアルゴリズムの詳細については、下記する。
図８は、また、スイッチロジック261の内部ダイアグラムを示している。スイッチは、IMC140ない複数の他のユニットからの多様なリクエストの裁定と同様に、データのフォーマットとアドレスのコンバートを実行する。スイッチロジック261は、カレントメモリトランザクションリクエスト（current memory transaction request）の選択を行うクロスバースイッチ502を含んでいる。この選択は、リアルタイムでメモリトランザクションを操作するユニットに最初にデータを送ることを意図して、複数の裁定手段の一つによって実行される。より好ましい実施例では、そのようなリクエスティングユニットの優先命令は、最初にはVDRLエンジン240からのディスプレイをリフレッシュするリクエストであり、次いでビデオI/Oユニット235、オーディオとモデム236、ローカルCPU/RISCインターフェイス202、グラフィックエンジン212と実行エンジン210によるものであり、そして次に周辺I/Oバスインターフェイスによるものである。優先命令とブロックサイズとリクエスト待ち時間は、IMC140のためのインターフェイスドライバソフトウェアによってプログラミング可能なソフトウェアである。こうして、システムパフォーマンスとメモリトランザクション効率及び／もしくはレスポンスが、インターフェイスドライバによって実行されるソフトウェアコントロールにより、動的に調整される。こうしたインターフェイスソフトウェアは、好ましくはCPU102上で実行されるが、別に実行エンジン210によって処理されるものとすることもできる。
スイッチロジック261は、好ましくは、通常の非圧縮読み書きデータと圧縮読み書きデータを分離する詳細なデータセレクションユニットを有する。圧縮解除スイッチ512は、コマンドと、アドレスと、ブロックタグと、データタイプ及び長さ情報を圧縮解除エンジン550と555に送ることによって、ブロックの読取り処理を決定する。加えるに、圧縮解除スイッチ512は、圧縮解除されたデータとトランザクションタグ情報を圧縮解除エンジン550及び／もしくは555から受け取る。圧縮解除スイッチ512は、好ましくは、複数のシステムメモリが同時にリクエストを読み取るためにパイプライン化されている。タグフィールドは、多様で顕著なリクエストが圧縮解除エンジン550及び／もしくは555に並列的に発行されるのを許容する。
同じように、スイッチロジック261は、圧縮しないあるいは圧縮解除する処理を必要とする読み書きトランザクションのための通常のメモリスイッチ514を有する。好ましい実施例では、あるデータアドレスの範囲、あるいは詳細なリクエストユニットからのリクエストは、圧縮操作を持つ必要はない。メモリスイッチ514は、メモリインターフェイスユニット560にインターフェイスするためのブロック伝送、アドレスの世代、データタグ、長さ、及びコマンド情報を生成する。
スイッチロジック261は、圧縮スイッチ516を含んでいる。圧縮スイッチ516は、圧縮エンジン570及び／もしくは575のためのコマンド、アドレス、タグ、長さ及びデータタイプの準備を実行する。複数のリクエスティングユニット211によってメモリコントローラ220に書き込まれたデータは、圧縮スイッチ516によって受けとられ、そして、メインメモリ110に圧縮されて書き込まれるか、あるいはＬ3データキャッシュ291の世紀のアドレスレンジ内にあるのであれば、メモリスイッチ514の制御下でＬ3データキャッシュ291に書き込まれる。
こうして、圧縮キャッシュコントロールユニット281は、スイッチユニット261とともに、Ｌ3データキャッシュ291かパラレル圧縮及び圧縮解除ユニット251かメインメモリインターフェイス560かのいずれかによって、トランザクションを完成するに必要なトランザクションタイプと、優先順位と、制御とを決める。図８に見られるように、好ましい実施例では、トランザクションサイズが１６データバイトであることを示してある。別の実施例では、トランザクションサイズはどの数のデータバイトでも良い。
図７において上で述べたように、Ｌ3データキャッシュ291は、キャッシュコントロールユニット281と相互に作用する。Ｌ3データキャッシュ291内に位置する補助データにアドレスレンジを持つトランザクションのためには、圧縮解除エンジン550とメモリインターフェイス560と圧縮エンジン570は用いられず、データはＬ3データキャッシュ291に直接的に読み込もしくは書き込みされる。こうして、Ｌ3データキャッシュ291がヒットするためには、データはパラレル圧縮及び圧縮解除ユニットをバイパスし、圧縮されないフォーマットの状態で、Ｌ3データキャッシュ291へ／から直接的に読み込まれあるいは書き込まれる。
さらに、図８を再度参照するに、パラレル圧縮及び圧縮解除エンジン251は、データ及びコマンド伝送マルチプレクサ522を含み、データをマルチプレクサ590に書き込む。コマンド伝送マルチプレクサ522は、データと、コマンドアドレスと、タグと、並びに、圧縮解除エンジン550／555とメモリインターフェイス560と圧縮エンジン570/575に切り換えて接続する長さとを処理する。別の実施例では、これに含まれる伝送マルチプレクサ522は、複数バスデザインよりも単一バスデザインのスイッチロジック261内にある。書き込みデータマルチプレクサ５９０は、メインメモリへの通常（圧縮されていない）データ書き込みと圧縮データ書き込みとの選択を行う。
メモリインターフェイスユニット221は、ステイタス、タグ及び読み込みデータのため圧縮解除エンジン550及び/もしくは555にインターフェイスとりしてあり、また読み書き両方の制御、アドレス、タグのためメモリインターフェイス560にインターフェイスとりしてあり、さらに書き込みデータのため圧縮エンジン570及び/もしくは575にインターフェイスとりしてある。メモリインターフェイスユニット221は、DRAMコントローラ592とDRAM I/Oインターフェイス594を含んでいる。DRAMコントローラ592は、メインメモリバンク110を制御するため、DRAM I/Oインターフェイス594への制御信号とアドレスのタイミングをとる。好ましい実施例では、SDRAMメモリは、DRAM I/Oインターフェイス594内に位置する高速アナログRACによって制御される。別の実施例では、SDRAM、DRDRAM、SLDRAM、あるいはＶＭＣのような他のメモリタイプは、DRAM I/Oインターフェイス594内に追加ロジックを必要とする。こうして、メモリインターフェイスロジック221は、メモリコントローラ220の内部にあり、信号、アドレスのためのスイッチロジック261、タグ、コントロール及びデータ信号、アドレスのためのパラレル圧縮及び圧縮解除ユニット、並びにコントロール及びデータトランザクションを制御する圧縮コントロールユニット281にインターフェイスとりしてある。加えるに、メモリインターフェイスロジック221は、システムメモリ110にインターフェイスとりするために信号の調整とメモリのインターフェイスとりを行う。
パラレル可逆圧縮及び圧縮解除
パラレル圧縮と圧縮解除の作用を行うパラレル圧縮／圧縮解除ユニットもしくはエンジン251について、述べる。このエンジン251は、好ましくは、専用のコーデック（符号器／復号器）ハード゛ウェアエンジンであり、例えばロジック回路から成る。一つの実施例では、コーデックエンジン251は、プログラムできるDSPあるいはCPUコア、あるいはプログラムできる圧縮／圧縮解除プロセッサから成る。これらは、一つもしくはそれ以上のROMｓあるいはRAMｓを有し、これらのROMｓには、圧縮、圧縮解除、特別なタイプのグラフィック圧縮及び圧縮解除、並びに望みによってはビットブリット操作といった作用を行うためのマイクロコードの異なる複数セットが格納されている。本実施例では、コーデックエンジン251は、一つもしくはそれ以上のメモリ内のマイクロコードの異なるセットの間で、実行される作用に基づいて動的にシフトする。圧縮／圧縮解除エンジンは、また、再構成できあるいはプログラミング可能なロジック、例えば一つあるいはそれ以上のFPGAｓ、を用いて実行できる。
図８に見られるように一つの実施例では、エンジン251は、データがシステムメモリ110へ／から伝送されるときにデータを圧縮及び圧縮解除するよう設計された、埋め込み型の可逆のパラレルデータ圧縮エンジン570とパラレル圧縮解除エンジン550とを含んでいる。
圧縮エンジン570と圧縮解除エンジン550は、エンジン251に示された技術を用いて作られ、ロジック回路、プログラム可能なCPUｓ、DEPｓ、専用の圧縮／圧縮解除プロセッサ、あるいは再構成可能もしくはプログラミング可能なロジックを含んでおり、本発明のパラレル圧縮と圧縮解除法を実行する。本発明にしたがってメモリコントローラに圧縮／圧縮解除手段を埋め込むために、他のさまざまな実行手段が用いられる。好ましい実施例では、圧縮エンジン570と圧縮解除エンジン550は、IMC140内のハードウェアエンジンから成り、また別には、圧縮及び圧縮解除のための同様なエンジンの一部を用いる。下記する記載では、パラレル圧縮及び圧縮解除ユニットは、分離された圧縮エンジンと圧縮解除エンジン570,550を有するものとして記載されている。
メインシステムコントローラ内に圧縮及び圧縮解除エンジンを用いる場合の方法と利点の一般的な概略については、「埋込型のデータ圧縮及び圧縮解除エンジンを含むメモリコントローラ」という名称のUSパテントを参照されたい。このパテントは、発明者がトーマス エイ ダイで、出願日が1995年6月5日で、出願番号が08/463,106である。
IMC140は、「圧縮」データと「圧縮されていな（non-compressed）いデータ」２つのデータフォーマットを含んでいる。圧縮データフォーマットは、記録に要する容量の少ないことが要求され、これによって高価でなくなる。圧縮フォーマットは、また、データをシステムメモリ110とI/Oサブシステムとの間で伝送するためのシステム帯域幅をより小さくする。圧縮データフォーマットから通常のデータフォーマットに圧縮解除すると、小さな実行ペナルティを惹きおこす。しかしなが、通常、隠されている付加された待ち時間はあるかもしれないけれども、圧縮されていないデータフォーマットを圧縮データフォーマットに圧縮することは、関連づけられたペナルティを有するものではない。もし、データがうまく圧縮されないと、圧縮を必要とするストアの長いシリーズがあり、バスは、バックアップされて、プロセッサに読取りやうろうろするような遅れを惹きおこさせる。
一つの実施例では、圧縮エンジン570は、CPU102によってソフトウェアで実現される。
好ましい実施例では、IMC140内の圧縮エンジン570と圧縮解除エンジン550は、一つあるいはそれ以上のハードウェアエンジンから成る。ハードウェアエンジンは、新規なパラレルな可逆的（lossless）圧縮法、好ましくは圧縮及び圧縮解除のアルゴリズムに基づいた「パラレル」な辞書を実行する。パラレルアルゴリズムは、例えば圧縮と圧縮解除のアルゴリズムに基づいたLZ77（好ましくはLZSS）辞書のように、アルゴリズムに基づいたシリアル辞書をベースとするものであっても良い。パラレルアルゴリズムは、LZ77、LZ78、LZW及び／もしくはLZRWを含む従来のシリアルLZ圧縮のさまざまな態様をベースとするものであっても良い。
パラレルアルゴリズムは、また、ランレングス方式のエンコーディング、予測型エンコーディング、ハフマン、演算、その他可逆的圧縮アルゴリズムに基づくものでも良い。しかしながら、これらのパラレルアルゴリズムは、圧縮能力が低く及び／もしくはハードウェアのコストが高いためにそれほど好ましいものではない。
基本的な技術としては、どのような可逆的圧縮法を用いても良い。上記したように、LZSS圧縮のパラレル実現法は、用いるのに好ましい例である。他の可逆的圧縮法は、メモリの帯域幅と有効性の改善を目的として設計され、パラレル圧縮と圧縮解除を速く行うものであるけれども。
シリアルLZ圧縮を用いるデータ圧縮と圧縮解除システムに関する更なる情報については、米国特許第4,464,650号を参照されたい。上記特許は、ＬＺ77データ圧縮法の実現法を提案している。LZ77データ圧縮法は、ランペル（Lempel）及びジブ(Ziv)によって次の著作に表されている。「『可変レートコーディングを経た個別シーケンスの圧縮』、情報理論のIEEEトランザクション、IT-5、1977年９月、530-537頁」、「『シーケンシャルデータ圧縮のためのユニバーサルアルゴリズム』、情報理論のIEEEトランザクション、２３巻、No.3（IT-23-3）、1977年5月、337-343頁」。米国特許第4,701,745号（発明の名称「データ圧縮システム」1987年10月20日発行）は、LZRW1と呼ばれるLZ77の変形例を示している。LZ78アルゴリズムの変形版は、LZWとして示され、米国特許第4,558,302号に記載されている。LZWの他の変形例は、米国特許第4,814,746号に示されている。
別の実施例において、データ圧縮及び圧縮解除エンジン570と550は、1995年4月25日に発行された「データ圧縮／圧縮解除プロセッサ」と題する米国特許題5,410,671号に開示された技術に基づくパラレル圧縮／圧縮解除プロセッサハードウェアを実用化する。
IMC140は、また、さまざまな他のシリアル技術に基づいた本発明のパラレル圧縮／圧縮解除技術を実用化するものである。別の実施例では、パラレルもしくはシリアルデータ圧縮／圧縮解除法が用いられる。
本発明の圧縮／圧縮解除エンジン251は、イメージデータのための特別な圧縮／圧縮解除エンジン575/555を含む。不可逆な圧縮／圧縮解除エンジンの好ましい例は、図１７から２０を参照して示される。パラレル圧縮解除の例は図32から43を参照して示される。
図９Ａ−先行技術
先行技術は、コンピュータハードウェアのデザインのためにLZ圧縮アルゴリズムを用いる。しかし、圧縮された出力ストリームを適切に生じさせるために入力データを連続的に調べ直す必要があることから、データストリームの帯域幅は制限される。図9Aは、先行技術の実現方法の通常のヒストリーテーブルを表現している。
LZ圧縮アルゴリズムは、データの反復された記号あるいは記号のグループを探すことによって格納するデータに必要とされるビット数を減らそうとする。LZ７７アルゴリズムのハードウェア実現方法は、入ってくるデータと比較できるようにデータストリームの最後のｎ記号を記憶しておくためにヒストリーテーブルを使用する。入力ストリームとヒストリーテーブルとの間に一致が見られるときは、ストリームから一致記号が圧縮記号に置き換えられる。これは、ヒストリーテーブルから記号をどのようにして回復するかを示す。
図9B−パラレル圧縮アルゴリズム
本発明の一実施例は、辞書に基礎を置いた（あるいはヒストリーテーブルに基礎を置いた）圧縮／圧縮解除のパラレルな実現方法を提供する。パラレルなヒストリーテーブルと連係比較ロジックを設計することによって、圧縮アルゴリズムの帯域幅は何回も増加される。この仕様は、４つの記号をパラレルに圧縮するアルゴリズムの実現方法を開示し、データの圧縮比率を減らさない実現方法の帯域幅に４回の改良をもたらす。別の実施例では、記号の数とパラレルなヒストリーテーブルは、パラレルな処理と帯域幅を改善するために増やされ、また４つを超えて大きくされ、あるいはハードウェア回路の必須条件を容易にするために減らされる。一般的に、パラレル圧縮アルゴリズムは、２記号のパラレルアルゴリズムかそれ以上で、好ましくは２の倍数、例えば4,8,16,32他である。パラレル圧縮アルゴリズムは、以下の記載では、図示の目的のために４記号のパラレルアルゴリズムとしてある。
パラレル圧縮アルゴリズムは、シリアルアルゴリズムの並列する３つの部分を備える。ヒストリーテーブル（あるいはヒストリーウィンドウ）と、記号と圧縮されたストリームセレクションの分析部と、出力発生部である。好ましい実施例では、ヒストリーテーブルを通るデータの流れは、単一記号のヒストリーテーブルの代わりに４記号のパラレルな流れになる。また、４記号は、並列的に分析され、多重に圧縮された出力が同様に並列的に提供される。他の別の実施例は、個々のデータブロックの圧縮解除間に文脈切り換えを行いながら多重の流れを圧縮解除する複数の圧縮ウィンドウを備える。このような別の実施例は、コストを増加させ、また命令取出し処理の間の待ち時間を減らすべく他のブロックの圧縮解除のために現在のブロックの圧縮解除を一時停止する有利さを持つとゲイトカウント数を増加させる。議論を容易にするため、本説明では、記号は１バイトのデータと仮定してある。記号は、実現方法によって必要とされる、理由あるどのようなサイズであっても良い。図9Bは、パラレルなヒストリーテーブルのデータフローを示す。
図10−パラレルな圧縮アルゴリズムの高レベルなフローチャート
図１０は、好ましい実施例におけるパラレル圧縮アルゴリズムの動作を示す高レベルなフローチャートダイアグラムである。フローチャートのステップは、同時にあるいは異なる順番で起こる。
ステップ402において、手法（method）は、複数のエントリから成るヒストリーテーブル（ヒストリーウィンドウとも呼ばれる）を維持している。そこでは、各エントリは、一つの記号を構成する。ヒストリーテーブルは、データストリームの最後のｎ記号を記録するスライディングウィンドウであるのが好ましい。
ステップ404において、手法は、前の記号がヒストリーテーブル内のエントリと比較されたときに生じた先行照合のカレントカウント（現在の計数）を維持する。カレントカウントは、現在のデータストリームのために維持され、各エントリはこのエントリが照合の出発点であることを示すために最大カウントフラグを維持する。好ましさがやや劣る別の実施例では、分離カウントは、ヒストリーテーブル内の各エントリのために維持される。現在のところ好ましい実施例は、単一のカレントカウントを維持し、ヒストリーテーブル内の各エントリのために分離カウントフラグを維持する。というのは、この実施例は、ヒストリーテーブル内の各エントリのために分離カウントを維持するよりも少ないロジックを必要とするからである。
現在の開示内容において、「カウント情報」という用語には、先行照合のカウントと、ヒストリーテーブル内の各エントリのために維持されるカウントフラグとを含ませてある。また、「カウント情報」という用語には、ヒストリーテーブル内の各エントリのために維持され複数のカレントカウントを含ませてある。
ヒストリーテーブルとカレントカウントフラグの保守は、前に受け取られた記号に基づいたアルゴリズムを通して実行され、好ましくは、最初の複数の記号が圧縮のために受け取られたときに開始する。
ステップ406において、手法は非圧縮データを受け取る。ここでは非圧縮データは複数の記号から成る。こうしてパラレル圧縮アルゴリズムは一度に複数の記号を操作する。これが、一度にただ一つの記号を連続的に取り扱う従来の先行技術であるシリアルアルゴリズムと異なる点である。複数の記号は、２つもしくはそれ以上の記号から成り、好ましくは２の累乗である。好ましい実施例では、パラレル圧縮アルゴリズムは、一度に４つの記号を取り扱う。しかしながら、8、16、32あるいはそれ以上の記号を用いる実現方法は、２を累乗しない他の数と同様に、ここに述べたアルゴリズムを容易に用いることができる。
ステップ408において、手法は、複数の記号をヒストリーテーブルにある各エントリと並列的に比較する。この比較によって比較結果が生じる。ヒストリーテーブル内の各エントリは、好ましくは、複数の記号のそれぞれと同時に、すなわち並列的に、改善されたスピードで比較される。
ステップ410において、手法は、カレントカウントフラグと比較結果に基づいて複数の記号のそれぞれのための照合情報（match information）を決定する。照合情報を決定するステップ410は、ゼロであると決定することあるいはヒストリーテーブル内の各エントリに複数の記号をさらに照合することを含む。さらに詳しくは、ステップ410は、カレントカウントと比較結果に基づいて最長の連続した照合を決定し、それから最長の連続した照合が照合を停止しているかどうかを決定することを含む。もし、最長の連続した照合が照合することを停止したら、そのときは、手法は、カレントカウントフラグと最大カウントをアップデートする。
ステップ412において、手法は、照合情報に応答して圧縮データ情報を出力する。ステップ412は、例えば異なる照合及び／もしくは非照合記号のために、並列的に圧縮データ情報の複数セットを出力することを含む。ステップ412は、もしあるのなら、照合を停止させた最長の連続した照合に対応する圧縮されたデータ情報を出力することを含む。連続した照合は、先の複数の記号からの照合を含むものでも良い。ステップ412は、先の照合から、圧縮されたデータ情報を出力することを含むものでも良い。ステップ４１２は、また、ヒストリ内のどのエントリとも照合しない非照合記号のために、非照合記号を非圧縮フォーマットで出力することを含む。連続する照合のために、圧縮データ情報は、カウント値とエントリ指標とを含んでいる。エントリ指標は、連続した照合を生じさせたヒストリーテーブル内のエントリを指し示す。また、カウント値は、連続した照合内の照合記号の数を示す。一つの実施例において、符号化された値は、カウント値として出力される。そこでは、しばしば起きるカウントは、あまり起きないカウントより少ないビットで符号化される。
ステップ402から412は、もうこれ以上データが入手できなくなるまで１回あるいはそれ以上の回数、繰り返される。もうデータが入手できないとき、もしどのようなカレントカウントも零でないなら、手法は、ヒストリーテーブル内に最も長く残っている照合のために、圧縮データを出力する。
手法は、複数の記号を同時に操作しながらパラレル圧縮を実行するので、与えられた複数の記号の範囲内で構成される記号照合を特別なケースとして明らかにする。ここでは、複数の記号は、最初の記号と、最後の記号と、一つもしくはそれ以上の中間の記号を含んでいると仮定する。照合情報を決定するステップ410は、少なくとも一つの連続した照合が一つもしくはそれ以上の個々の連続した中間記号で起きるかどうか、また一つもしくはそれ以上の連続した中間記号が個々の連続した中間記号の前あるいは後にあるどの記号とも照合に関係しないかどうかを検出することを含む。もし、この状態が検出されたら、そのとき、手法は、中間記号に関係する一つもしくはそれ以上の最も大きな重複しない連続した照合を選択する。この場合には、ステップ412は、中間記号に関係する選択された照合のおのおののために圧縮されたデータを出力することを含む。
図１１−パラレル圧縮アルゴリズムの詳細なフローチャート
図１１は、好ましい実施例におけるパラレル圧縮アルゴリズムの動作を示すさらに詳細なフローチャートダイアグラムである。ステップは、図１０におけるものと似ておりあるいは等しい。便利なように同じ参照符号を用いてある。
図１１のフローチャートにおいて、手法は、それぞれが一つの記号から成るエントリを含んでいるヒストリーテーブルを維持していると仮定されている。ヒストリーテーブルは、好ましくは、データストリームの最後のｎ記号を記録するスライディングウィンドウである。また、手法は、前の記号がヒストリーテーブル内のエントリと比較されたときに生じたカレントカウントの先の照合を維持するものであると仮定されている。カウントフラグは、ヒストリーテーブル内の各エントリのために維持される。上記したように、ヒストリーテーブルとカレントカウントフラグの保守は、好ましくは、アルゴリズムを通して行われ、最初の複数の記号が圧縮のために受け取られたときに開始する。
ステップ406において、手法は、非圧縮の入力データを受け取る。そこでは、非圧縮のデータは複数（もしくはグループ）の記号から成る。こうして、パラレル圧縮アルゴリズムは一度に複数の記号を取り扱う。これは、一度にただ一つの記号を連続的な態様で取扱う従来技術のアルゴリズムとは異なるところである。また、上記したように、パラレル圧縮アルゴリズムは、一度にいくつもの数の記号をも扱うことができる。入力データは、データストリームからの最初のグループの記号であり、またはデータストリームの中間もしくは最後からのグループの記号である。
ステップ408において、手法は、複数の記号を並列的な態様でヒストリーテーブル内の各エントリと比較する。この比較によって比較結果が生じる。ヒストリーテーブル内の各エントリは、好ましくは、複数の記号のそれぞれと同時に、すなわち並列的に、改善されたスピードで比較される。
ステップ422において、手法は、ゼロであること、あるいはヒストリーテーブル内の各エントリに複数の記号をさらに照合することを決定する。換言すると、ステップ422において、手法は、各エントリのために、エントリが複数の記号のどれかとマッチするかどうかを決定する。この決定は、比較結果に基づく。
ステップ422において、複数の記号についてなにも一致しないと検出されると、ステップ432において、手法は、前に何らかの一致があったかどうかを決める。換言すると、ステップ432は、一つあるいはそれ以上の終端記号がヒストリーテーブル内のエントリに一致するかどうかを決める。そして、圧縮された情報は、これらの記号にはまだ出力されない。というのは、手法は、より長い連続する一致を決定できる新しい複数の記号を待っているからである。もし、ステップ432において決められるような一つあるいはそれ以上の以前の一致があるとすると、ステップ434では、手法は、以前の圧縮されたデータ情報を出力する。この場合、先の記号グループからの先の一致が、現在のグループ内のいかなる記号とも連続していないので、以前の圧縮されたデータ情報は、出力される。ステップ434の後で、動作はステップ４３６に進む。
もし、ステップ432あるいはその後のステップ434で決定されるように、以前に一致がないとすると、ステップ436において手法は、複数の記号の各記号を非圧縮記号として出力する。複数の記号のそれぞれは、ヒストリーテーブルのどのエントリとも一致しないので、複数記号のそれぞれは非圧縮フォーマットで出力される。ステップ４３６の後、ステップ438において全てのカウントフラグは０にリセットされる。ステップ472において、非圧縮記号は、ヒストリーウィンドウに追加され、更なる入力情報、すなわち更なる入力記号を受け取るために操作はステップ４０６に戻る。
もし、ステップ422の複数の記号に一つあるいはそれ以上の一致が検出されると、ステップ442において、手法は、全ての複数の記号が一つの一致された状態から成るかどうかを決定する。もし、そうであるなら、ステップ444において、手法は、一致する記号の数、例えば4記号によってマッチカウント（match count）を増やし、個々のエントリに最大のカウントフラグをセットする。ステップ474において、非圧縮記号はヒストリウィンドウに付加され、より多くの入力データ、すなわちより多くの入力記号を受け取るために操作はステップ406に戻る。この場合、手法は、連続する次のグループのどのような記号も現在一致している記号とマッチするかどうかを待ちかつ決定するために、いかなる出力情報の提供も延期する。
ステップ442で決定されるように、もし、複数の記号の全てが一つの一致された状態から成るものでないなら、ステップ４５２において手法は、以前に一致したものが存在したかどうかを決定する。ステップ452における決定は、ステップ432における決定と似ており、先行する記号グループからの一つもしくはそれ以上の終端記号がヒストリーテーブル内のエントリと一致するかどうかを決定することを含む。そして、圧縮された情報は、手法が、より長い連続した一致を決定できる新しい複数の記号を待っているので、まだこれらの記号には出力されない。
もし、ステップ452で決定されるように、以前に一つもしくはそれ以上の一致が存在するなら、ステップ454において、手法は、以前の一致を含む最も長く連続する一致を選択する。ステップ456において、手法は、最も長く連続する一致とみなす圧縮されたデータ情報を出力する。この圧縮されたデータ情報は、以前の圧縮されたデータ情報を含んでいる。というのは、それは、前の記号グループとの以前の一致を少なくとも部分的に含んでいるからである。もし、現在の複数の記号のうちの最初の記号が以前の一致と連続的に一致していないなら、圧縮されたデータ情報は、以前の圧縮されたデータ情報のみから成る。ステップ456の後、操作はステップ462に進む。
ステップ462から470は、各入力記号を並列的に処理する。言葉を換えると、ステップ462から470は、各入力記号のために同時に操作される。ステップ462から470は、図示を容易にするため、連続的態様で示されている。
ステップ462において、手法は、個々の記号が一致状態を含んでいるかどうかを決定する。もしそうでないなら、ステップ464において、手法は、非圧縮記号を出力する。この場合、個々の記号は、ヒストリーテーブル内のどのエントリとも一致しない。記号は非圧縮状態で出力される。
ステップ462で決定されるように、もし、個々の記号が一致状態を含んでいるなら、ステップ466において、手法は、一致が最後の記号を含むかどうかを決定する。もしそうでないなら、ステップ486において、手法は、一致のために圧縮データ情報を出力する。このことは、一つもしくはそれ以上の中間記号のみから成る一致を含んだ特別な場合であることに留意すべきである。
ステップ466で決定されるように、もし、一致が最後の記号を含むのであれば、ステップ470において、手法は、一致に含まれない記号の数に対するカウンタをリセットする。この場合、圧縮された情報はこれらの記号のために出力されない。というのは、手法は、より長い連続した一致を決定できる新しい複数の記号を待っているからである。
一旦、ステップ462-470が各入力記号のために並列して実行されると、ステップ472において非圧縮記号がヒストリーウィンドウに付加される。操作は、それからもっと多くの入力データ、すなわち新しい複数のあるいはグループの入力記号を受け取るためにステップ406に戻る。もし、もっと多くの入力データが入手できあるいは受け取られると、ステップ480において、手法は、残っている以前の一致部分を一気に消去する。すなわち圧縮された情報を残っている以前の一致部分に提供する。
図１１の手法は、また上記した中間記号の一致部分を計算する。
図１２と１３−パラレル圧縮アルゴリズム
図１２と１３は、パラレル圧縮アルゴリズムの操作を示すハードウェアダイアグラムである。先行技術のLZシリアルアルゴリズムと同じように、ヒストリーテーブルの各エントリは、記号（バイト）データを有し、データ610の入力ストリームと比較される。入力ストリーム610は、データ0、データ1、データ2及びデータ3から成る。図１２は、エントリD602として参照される、ヒストリーテーブルのエントリを示す。図示されているように、エントリD602は入力ストリーム610の各記号と比較される。図１２は、パラレルな実現方法のエントリD602とその入力及び出力を示している。コンパレータ608は、各データバイトエントリを入力ストリーム610からの４バイトと比較し、４つの比較信号（エントリDのD3を通してD0と呼ばれる）を生成する。比較信号D0は、エントリDにおいて用いられる。比較信号D1は、ヒストリーテーブルの次のエントリEによって用いられる。比較信号D2は、エントリFによって用いられる。そして、比較信号D3は、エントリGによって用いられる。したがって、エントリDは、エントリAからの比較信号3、エントリBからの比較信号2、及びエントリCからのコード1を用いる。これらは、図１２の結果計算ブロック606への入力として示される。この比較結果は、このエントリのための出力マスク値を決定するために用いられる。出力マスク値は、入力データが圧縮されたものであるかそうでないかを決定するための圧縮ストリーム選択ロジック612/614/616（図１３）に送られる。この情報は、出力への圧縮されていないデータから圧縮ストリームデータのいずれかを送る出力発生ロジック618に進められる。
カウンタのアップデート値とエントリ最大カウントフラグとに添って、結果計算ブロック606から出力マスクを発生させることについては、図14のテーブルに記載されている。
新しいカウンタ値は、Ａ3の始めに生じる一致する数をＤ0までカウントすることによって計算される。例えば、C1マッチなしでA3とB2のマッチは、カウンタを２にセットする。全ての４つの比較マッチングの特別なケースでは、現在のカウンタ値に４を付加する。
出力マスクは、このエントリで起きたマッチと最大カウントフラグに基づく符号値である。図１４ａと１４bの表は、この値の発生の一つの実施例を示している。図１４ｃは、出力マスクのコレクションからの結合マスクの生成を示す。
圧縮ストリーム選択ロジック（Compressed Stream Selection Logic）
図１３は、選択ロジック612/614/616と出力ストリーム生成ロジック（output stream generation logic）のブロックダイアグラムを示す。圧縮ストリーム選択ロジック612/614/616は、結果計算ブロック606からのエントリのそれぞれから出力カウンタと出力マスクを集合し、出力ストリームジェネレータ618のためのインデックスとカウントを生成する。インデックスは、選択カウントを生成したエントリを示す。選択ロジック612/614/616の主な機能は、入力ストリーム外で圧縮された最も大きなブロック、すなわち最大の連続するマッチを見つけることである。これは、エントリから最大の出力カウントを見つけることによって達成される。パラレル圧縮、すなわち複数の記号が並列的に処理されるから、出力部に送られる必要のある多様な圧縮ブロックが存在する。この理由から、４つの記号をパラレルに扱う実施例において、２つのカウントと３つのインデックスが出力ロジック618に提供される。これらは、先のカウント及びインデックスと、スタートのカウント及びインデックスと、LZ12インデックスとして参照される。
マッチの終端を示すマスクのあるインデックスを選択することによって、先のカウント及びインデックスが生成される。これは、このサイクルのデータ入力の一つで終わる圧縮ブロックを示している。インデックスは、このマスクを生成した単に最初のエントリナンバーであり、カウントは結合された出力マスクから生成された最大カウント値からのものである。第一番目の入力記号で始まり、複数の入力記号内で終わる最大のマッチを選択することにより、スタートカウントとインデックスが生成される。これは、第一番目の記号で始まるサイクルを受け取る４記号の一つもしくはそれ以上を含む圧縮ブロックを示す。このエントリからのマスクは、同様に、出力ジェネレータ618に進められる。LZ12インデックスは、特別な事例のマスクを戻したブロックを示す。特別な事例には、上記した一つもしくはそれ以上の中間記号の連続する一致が含まれる。結合された圧縮マスクブロック616は、全てのマスクのロジカルANDから成る結合された圧縮マスクを生成し、これを出力ジェネレータ618に進める。
図１５−出力ストリームジェネレータフローチャート
出力ストリームジェネレータ618ロジック（図１０）は、図１５に示すフローチャートにしたがって出力ストリームを生成する。このフローチャートにおいて「CCM」の語は、結合された圧縮マスク（Combined Compress Mask）を意味し、CCM(0)とは、図１４のテーブルで用いられるような最も少ない有効ビットである。出力ジェネレータ618は、圧縮されていないこを示す適切なフラグを含む非圧縮データ、あるいは圧縮ブロックであることを示すフラグを含む圧縮ブロックのいずれかを、符号化されたカウントと、オリジナル入力を再生成するための圧縮解除するロジックによって用いられるインデックスと共に送り出す。
図示するように、ステップ721において、手法は、以前のカウントがゼロに等しいかどうかを決定する。もし等しくなければ、手法は、結合マスクが1111に等しいかどうかをステップ729において決定する。もし等しくなければ、手法は、ステップ723において圧縮ブロックを送出し、ステップ725において最大カウントを４かそれ以下に調整する。操作は、それからステップ727に進む。もし、結合マスクがステップ729において1111と等しいなら、操作はステップ753に進む。そこでは、最大カウントは操作を完遂する前に４ずつ増加される。
ステップ727において、手法は、スタートCntがゼロと等しいかどうかを決定する。もし等しくなければ、手法は、ステップ731において圧縮ブロックを送り出す。操作は、それからステップ735に進む。もし、スタートCntがステップ727でゼロに等しいと決定されると、凹さはステップ735に直接進む。
ステップ735において、手法は、CCM(3)が１と等しいかどうかを決定する。等しくなければ、手法は、ステップ733において、データゼロを送り出す。操作は、それからステップ737に進む。もし、CCM(3)がステップ735においてゼロに等しいと決定されると、操作は、直接ステップ737に進む。
ステップ737において、手法はCCM(3,2,1)が011に等しいかどうかを決定する。等しいと、ステップ739において手法は、CCM(2)が１と等しいかどうかを決定する。等しくないと、ステップ741において手法は、データゼロを送り出し、操作は、それからステップ745に進む。もし、CCM（2）がステップ739において１と等しいと決定されると、操作はステップ745に直接進む。ステップ745において、手法は、CCM(1)が１と等しいかどうかを決定する。等しくないなら、ステップ747において手法はデータゼロを送り出す。操作は、それからステップ749に進む。もし、CCM(1)がステップ745において１に等しいと決定されると、操作はステップ749に直接進む。
もし、CCM(4,2,1)がステップ737において０１１に等しいと決定されると、ステップ743において、手法は、LZ12圧縮ブロックを送り出す。操作は、それからステップ749に進む。ステップ749において、手法はCCM(0)が１に等しいかどうかを決定する。等しくなければ、Sっ法はステップ751においてデータゼロを送り出す。操作は、それで完結する。CCM(0)がステップ749において１に等しいと決定されると、それで操作は完結する。
もし、単一バイト圧縮がこのロジックによって実行されるものであるとすると、すなわち、個々の記号が圧縮されるものであるとすると、バイトのそれぞれの付加的なインデックスが選択ロジックによって生成されるべきで、これにより、外部ジェネレータがこれらを圧縮できるようになる。そうでなければ、外部ジェネレータロジックは、圧縮ストリームの出力が単一バイトの圧縮されていない出力になり、フラグをそれにしたがって調整する事例もまた取扱うべきである。以前のデータ3は、先のマッチが1カウントであるときの事例において出力ジェネレータ618によって同様に要求されても良い。
好ましくは、単一バイトのマッチを取扱う一つの方法は、単一バイトが図１４の表を調整することである。
例えば、10ｘｘ行において、もしセーブされたカウントがゼロなら、カウントアウトはD0単一バイトマッチのための圧縮ブロックを生成しないよう11xxのマスクに添ってゼロであるべきである。
図１６−パラレルアルゴリズム例
図１６は、パラレルアルゴリズム例を示している。一つのウィンドウ（ヒストリーテーブルの長さ）が１６エントリであるとして、それは次の値に初期化される。エントリ0＝Ｆ0、エントリ１＝Ｆ1、……エントリ15＝ＦＦ。また、全てのエントリカウンタフラグが０であり、マッチしたカウント値が０であるとする。下記のシーケンスは、４つの表示された入力の変化状態を示す。
ステート0では、入力データは、受け取られた指令においてＦ９、Ｆ8、Ｆ7、Ｃ0である。入力データは、図１３の右から左への到着指令内に示されている。すなわち、入力データＤ3：Ｄ0＝Ｃ0,Ｆ7,Ｆ8,Ｆ9である。ステート0では、入力は、エントリ9内の最初の３つの記号がマッチされていることを見つけ出す。これにより、これらの３つの記号は出力ストリーム内で一致したカウント３とインデックス９を示す圧縮データによって置き換えられることになる。出力マスク値「18」は、圧縮データがこれらの記号を表示する出力であることから、これらの非圧縮記号が出力ストリーム内に含まれるのを妨げる。また、ステート0において、記号Ｃ5はヒストリーテーブル内のどのエントリとも一致しないよう決定される。こうして記号Ｃ5は非圧縮フォームで、出力ストリーム内に提供される。こうしてステート0内の出力は、右から左にかけて、Ｃ0,(9,3)となる。
ステート１では、入力データは、受け取られた指令において、Ｂ5,Ｆ2,Ｆ1,Ｆ0である。記号Ｂ5はヒストリーテーブルのどのエントリとも一致しない。記号Ｂ5は出力ストリーム内で非圧縮態様で提供される。また、ステート１において、３つの入力記号はエントリ７内で３つの記号と一致する。一致する部分は前のエントリにあるが、この一致のための結果計算はエントリ7で起きることに注意すべきである。換言すると、実際に一致するエントリは、エントリ6,5,4である。しかしながら、この一致は、エントリ7によって検出される。エントリ7が４つの入力記号をエントリ7,6,5,4と比較するからである。圧縮データは、ステート１でのこの一致のためには生成されない。というのは、エントリは、一致が入力記号の次のセットに続くかどうか解らないからである。こうして、出力カウントは０である。エントリ7のためのマスク値は一致データが出力ストリームに含まれないようにする。ステート１での出力は、Ｂ5である。エントリ７のカウント値は、ステート１での３つの一致を示すために、ステート2に見られるように３にアップデートされる。
ステート２において、受け取られた指令において、入力データは、Ｆ９，Ｆ8,Ｆ7,Ｂ5である。エントリ７での一致は３以上の記号続き、それで終わる。エントリ７は、新しく一致する記号のためのマスクを出力する。加えて、エントリ６は記号Ｂ5で一致している。エントリ６は、そのカウントフラグをステート３の１にアップデートする。しかしながら、記号Ｂ5は、入力記号のこのグループの最後の記号であるから、エントリは、一致が次のセットの入力記号に続くかどうか解らない。こうして、エントリ６のため、マスク値はその記号が出力されるのを妨げる。ステート2の出力は(7,6)である。
ステート３では、もはやそれ以上の連続する一致は、ステート２からの記号Ｂ5に関して存在しない。エントリ６に関して、出力カウントは、ステージ２以降の記号Ｂ5に関するエントリ６から、1である。また、入力記号Ｅ2に関して一致は見られない。したがってＥ2は非圧縮記号として出力される。ステート３において、一致は中間記号Ｃ0とＢ5に関して見られる。この一致は、エントリ９によって検出される。そして、0Ｆマスクがエントリ９から出力される。このマスクは、圧縮された出力となる入力の中央にある２つの記号を示す（この例ではＢ5Ｃ0）特殊な事例マスクである。実際の圧縮出力データあるいはブロックはフラグと２のカウントとインデックスを含む。ステート３からの出力は、右から左に、(9,2)、Ｅ2、（6,1）である。個々の記号が圧縮されない実施例では、出力は、別の出力ボックスに見られるように(9,2)、Ｅ2、Ｂ5である。
本実施例の最終ステート４は、ステート３のエントリ３にＦ3の一致がある結果としてエントリ７のカウントに１を有する。この一致からのマスクは、Ｆ3をステート３の出力ストリームに送るのを妨げる。もし、これが入力ストリームの終端なら、ウィンドウは消去され、この一致によって単一記号圧縮ブロックを生じさせる。出力は、インデックス７に１の一致を示す。ステート３の入力が受け取られた最後のデータとすると、ストリームの最終出力は、(7,1)である。別の出力ボックスに見られるように、単一記号の一致は、記号Ｆ3として圧縮されないで送られる。
不可逆的圧縮アルゴリズム
「埋込み型データ圧縮及び圧縮解除エンジンを有するメモリコントローラ」という名称の米国特許（1995年6月5日出願、シリアルナンバー08/463,106、発明者：トーマス エイ ダイ）に、不可逆（lossy）な圧縮フォーマットの実例が示されている。「不可逆」の語は、データが変更され、圧縮後にオリジナルデータと近似したものによって示される、圧縮／圧縮解除操作に用いられる。
図２１を参照して、ある圧縮変換フォーマットは不可逆的圧縮が用いられ、他では可逆的圧縮が用いられる。好ましい実施例では、テクスチャ302、イメージデータ（圧縮ブロック380）、ビデオデータ（圧縮ブロック380）、及びディスプレイデータ300、そしてあるケース「Ｚ」もしくはデプスデータが、不可逆的アルゴリズムで圧縮される。別の実施例では、これらのフォーマットもしくは可逆的圧縮アルゴリズムで圧縮される追加フォーマットを有する。コントロールデータ、プログラム、VDRL、あるいは３Ｄパラメータデータ、あるいはもとの内容からロスなしに圧縮されるべきその他のデータは、本発明にしたがって可逆的パラレル圧縮プロセスを用いて圧縮される。
図１７−不可逆的圧縮及び圧縮解除エンジン
図１７は、不可逆的圧縮エンジン575と不可逆的圧縮解除エンジン555の好ましい例を示す。これら２つのエンジンは、好ましくは、パラレル圧縮及び圧縮解除ユニット251に配設される。
不可逆的圧縮エンジン５７５と不可逆的圧縮解除エンジン555は、分離されたブロックもしくは集合された単一ユニットである。エンジン５７５,555は、いろいろな態様で実現され、それにはディスクリートロジック、プログラム可能なCPU、DSP、あるいはマイクロコントローラ、FPGAのような再構成可能なロジック、その他を含む。好ましくは、不可逆的圧縮エンジン575は、イメージ、テクスチャ、ビデオ、及びデプスデータのために不可逆的圧縮アルゴリズムを実行する。RGBあるいはYUVのいずれかのデータは、メモリコントローラ220のスイッチロジック261によって不可逆的圧縮エンジン575に提供される。もし、こうしたデータがRGBフォーマットのものであるなら、ソースコンバータ762が、RGBを輝度(Y)値（YRB）に符号変換（エンコード）するために用いられる。この変換プロセスの操作は、技術分野で知識を有する者にとって標準的なことである。変換する理由は、圧縮とそれに続く圧縮解除手続に亘って生じる色彩複製を改善するためである。YUVデータは、ブロック762によって変換されないで、むしろ圧縮アルゴリズムによって処理される。
データは、SRAM記憶装置によって通常データとして記憶し、かつ符号768と766によって最小及び最大の計算を個別にするために、マルチプレクサ（多重変換装置《Mux》multiplexer）764によって選択される。SRAM770に記録されるデータは、図１８と１９の表にしたがった値を選択される。YRB/YUVの値は、マックスＹ（ユニット）766とミニＹ（ユニット）768に配設されたコントロールロジックによる制御信号の下で選択スイッチ772によって補間される。不可逆的データエンコーダ774は、YRB選択スイッチによって出力される選択値に制御ビット挿入（control bit insertion）を行う。不可逆的圧縮エンジン575からの不可逆的圧縮データは、メインシステムメモリ110に記憶されるため、メモリインターフェイスロジック221に出力される。
同様に、不可逆的圧縮エンジン555は、不可逆的圧縮解除を行うため、圧縮データをメモリインターフェイスロジック221から受け取る。データは、プロセス制御情報のためのヘッダを消去して適切な信号を不可逆データデコーダ778とピクセル複製ロジック780に送る圧縮ストリームセパレータ776によって最初に処理される。不可逆データデコーダ778は、ピクセル複製ユニット780において実行される複製プロセスを制御する。赤と緑（あるいはＵとV）に関連したミニ及びマックスY値のデータは、出力ピクセルの４×４の配列に配置される。ＹをＧに変換するコンバータ（以下、ＹｔｏＧコンバータという）782によって実行される最終ステップは、圧縮データのブロックを伴うヘッダによって示されるように、YRB/YUVデータフォーマットをオリジナルのRGBフォーマットに変換する。YUVデータを圧縮解除するために、ＹからＧへの変換プロセスがスキップされ、データはYｔｏＧコンバータ782から直接出力される。別の実施例では、他のカラーソースフォーマットが用いられる。そこでは、圧縮法が、圧縮下にあるデータのグループもしくはブロックの最小及び最大輝度を決めるための輝度値を取扱う。
好ましい実施例では、不可逆的圧縮アルゴリズムは、RGBフォーマットにおけるピクセルの４×４ブロックでスタートし、4×４ブロックの特徴に依存してそれらをいろいろなサイズに圧縮する。別の実施例では、続くプロセスに単にサイズが拡大された初期ソースデータブロックを用いる。また、好ましい実施例では、各ブロックは異なるサイズに符号変換される。そのサイズは、圧縮解除エンジンが適切に機能できるようにデータを変換させたものである。別に、消費者用製品や埋込み型DRAMのようなアプリケーションは、固定されたサイズのメモリ環境に対応するために固定された圧縮比率が必要である。固定圧縮比率により、ソフトウェアはメモリを知られたサイズに割り当てることができ、またメモリサイズの物理的制限を通りこしてデータがオーバーフローするのを補正する。この別の実施例で、固定圧縮比率が必要とされるところでは、不可逆的アルゴリズムは、容易に変更されて特別な事例を除去し、より良い圧縮比率を可能とする。
また、別の実施例では、CPU102は、圧縮及び／もしくは圧縮解除を本発明にしたがってソフトウェアで実行する。他の実施例では、圧縮解除のプロセスは、圧縮がCPU102のソフトウェア実行によって操作されるロジックによって実行される。
データ入力は、YUVフォーマット（典型的にはビデオ）あるいはRGBフォーマット（典型的にはグラフィック）で始まり、透過効果のためにアルファ（alpha）に結合される。好ましい実施例において、もし、圧縮されるべきデータが赤と緑と青のフォーマットにあるとすると、データは、Ｙ（輝度）の適切なデータフォーマットに変換され、赤及び／もしくは青は、もしそれがオリジナルソースフォーマットであるならYUVフォーマットに残される。ソース読取プロセスの間、データフォーマットは、より好ましいフォーマットに変換され、比較ステップの数は、各ブロックで実行される。ロードの間の4×4ピクセルのブロックのＹ値は、２ピクセルの前の最大及び最小Ｙ値の以前の値と比較される。一旦、関連したＲとＧが発見されると、値は、そのような最小及び最大Ｙ値に対応して記憶される。こうして、最大Ｙと最小Ｙは各ブロックごとに決定される。各ピクセルのためのデータが読み取られると、最大及び最小Ｙが位置付けられ、最小及び最大Ｙピクセルのための関連したＲ、Ｂ、及びアルファ値が同様に記憶される770。
アルファコンポネントなしの圧縮操作のために、図１８は、ブロックを出力するのに用いられるアルゴリズムを示す。同様に、アルファを用いた不可逆的圧縮操作のために、図１９の値が用いられる。図１８と１９の表を参照して、Ｐビットは、圧縮解除ステージの間に出力ピクセル位置が決定されるような圧縮データを伴う。もし、１６ビットが必要とすると、各ピクセルは、ブロック内で見つけられる２色と比較される。そして、０はピクセルが最小カラー（Min color）（Ｙmin、Ｒmin、Ｂmin、Ａmin）であることを示し、もしくは１はピクセルが最大カラー（Max color）であることを示す。２色よりも大きいときあるいはアルファが最小768及び最大766 ロジックによって決定されるものとして提供されるとき、３２ビットが用いられる。３２ビットが用いられるとき、圧縮ユニットは、最大及び最小Ｙ値の間の1/6thと1/2と5/6thの中間Ｙ値を計算する。各ピクセルのＹ値はこれらの値と比較され、もし1/6th値よりも少ないか等しいなら、00がこのピクセルのために用いられる。もし、1/6th値よりも大きく、1/2よりも少ないか等しいなら、ａ01がこのピクセルのために用いられる。同様にして、10（1/2値と5/6th値の間の場合）と11（5/6th値より大きい場合）が用いられる。圧縮解除エンジンはＹmaxとＹminとの間の1/3rdと2/3rd値を計算する。そして、もしピクセルの値が00なら、Ｙminが用いられる。もし、01なら、1/3rd値が用いられ、10なら2/3ｒｄ値が用いられ、11ならＹmax値が用いられる。圧縮解除の間に、Ｙ，Ｒ，ＢカラーフォーマットはオリジナルデータフォーマットのR,G,B,もしくはY,U,Vに再変換される。固定圧縮比率が要求されるアプリケーションあるいはシステム要件にとって、デフォルトのアルゴリズムは、１６ビット及び３２ビットデータ入力フォーマットのための図１８と１９に示された最後のエントリを用いることができる。別の実施例では、各ピクセルのＰビットあるいはピクセルのための個々の色に基づくＰビットとして、より大きなあるいは少ないビットが用いられる。加えるに、不可逆的圧縮の別の実施例では、より少ない圧縮であるがより高品質のイメージとより高い固定圧縮比率を生じる。
図２０−結合圧縮
好ましい実施例では、圧縮に必要な条件の性質に基づいて、不可逆的及び可逆的エンジンを結合したものを用いて高品質の固定されたあるいは可変のイメージ及びビデオ圧縮比率を実現する新しい方法を紹介する。IMC140は、多重的なデータタイプとフォーマットを先に述べたようにして圧縮する。イメージデータがただ一つの不可逆的アルゴリズムによって圧縮されるとき、高度なディテイルを持つイメージデータは、ぼやけたりあるいは色あせしたりする。先行技術は、周波数帯域に変換する離散コサイン変換によってイメージデータに不可逆的圧縮を実行する。これらは、ビデオやグラフィックを時間領域から周波数帯域にリアルタイムで伝送するのに高い帯域幅を必要条件とするために、実施するには、高価である。
これらを解決するために、並列的に動作する不可逆的及び可逆的エンジン575,570を結合したものが実行され、一方のエンジンからの出力が基準に基づいて選択される。
図２０に見られるように、オリジナルソースデータ120、例えばディスク、サブシステム、あるいはCPU102からのデータは、入力バスを横切って入力スイッチ261に伝送される。入力スイッチ261はアドレスの決定とブロックサイズや圧縮操作のための認定とを行う。データは、それから、パラレルな可逆的圧縮エンジン570と不可逆的圧縮エンジン575の両方に送られる。そこでは、SRAM記憶メモリ581,582に個別に記録される前に適切な圧縮が行われる。
ソースデータは、可逆的圧縮エンジン570と不可逆的圧縮エンジン575の両者に並列的に読み取られる。両方のエンジンは、入力ブロックのサイズに等価なデータに圧縮する。各エンジンからの圧縮された出力サイズは異なる。
図２０の好ましい実施例では、圧縮ストリームへの挿入のために不可逆的あるいは可逆的圧縮結果のいずれを選択するかを、エラータームが決定する。不可逆的圧縮エンジン575は、入ってくるデータストリームの圧縮の間、エラータームを生成する。詳しく言うと、配列比較ユニット（array compare unit）584は、不可逆的圧縮エンジン575からの出力に応答してエラー信号を生成する。エラー信号は、好ましくは、最小Ｙ（MinＹ）と最大Ｙ（MaxＹ）の値の間の違いに基づいて生成される。別に、不可逆的圧縮プロセスの間、オリジナルデータは、変換されあるいは不可逆的に圧縮されたデータから差し引かれ、エラータームを生み出す。このエラーは、それから、圧縮ストリームに挿入するためのブロックが不可逆的圧縮フォームであるか可逆的圧縮フォームであるかを決定する。エラー信号は、可逆的エンジン570あるいは不可逆的エンジン575のいずれかからの圧縮データを選択する、出力フォーマットスイッチあるいはマルチプレクサ586に提供される。図に見られるように、可逆的エンジン570と不可逆的エンジン575の出力は、出力フォーマットスイッチ586に提供される前にSRAM記憶装置581,582に一時的に記録される。もし、エラー信号があるしきい値より下にあるなら、不可逆的圧縮エンジン575の圧縮出力に低エラーを示し、それから不可逆的圧縮エンジン575の出力が用いられる。もし、エラー信号があるしきい値より上にあるなら、不可逆的圧縮エンジン575の圧縮出力のエラーは受け入れられない高さにあるとみなされ、可逆的圧縮エンジン570の出力が選択される。
輝度の違いの大きさによる高エラーを示す範囲では、可逆的パラレル圧縮データが用いられる。エラーの最小のしきい値を示すデータに関しては、不可逆的圧縮データが用いられる。この技術の利点は、ノイズを持って圧縮されるイメージのブロックが不可逆的エンジンでより良く圧縮されることである。同様にして、個々のディーテイル、高周波画像あるいは詳細な繰り返しデータは、可逆的パラレル圧縮でより効果的に圧縮される。
圧縮ブロックへの書き込みが行われている間、ヘッダは、使用された圧縮のタイプを示すタグビットを有する。このタグビットは、圧縮解除の間、データに適切な圧縮解除を行うために用いられる。
エラータームの選択は、また、固定圧縮比率を確保するための動的な要素である。本実施例では、もし、固定圧縮比率が望まれるなら、動的なしきい値が、不可逆的圧縮を受け入れ可能とみなされたエラーの大きさを変えるために調整される。現在の圧縮比率の実行遅れは、しきい値を動的に調整するために用いられる。それは、可逆的圧縮ブロックが不可逆的圧縮ブロックに変わってどこで用いられるかを決定する。もし、カレントブロックの動作率が要求される圧縮比率にあるなら、しきい値はデフォルト値にセットされる。もし、カレントブロックの動作率が超過した位置にあるなら、エラーしきい値は、出力選択が不可逆的圧縮エンジン575からのものであるように増加する。こうして、動的な圧縮エラーしきい値は、保証された圧縮比率を達成するために不可逆比率を可逆的データにどのようして調整するかを決定する。
圧縮解除の間、好ましくは、出力フォーマットスイッチ588は、最初に、圧縮解除エンジン出力選択を決定するためのヘッダを取り除く。一つの実施例では、圧縮データは、エンジン555と550の両方によって並列的に圧縮解除される。この例では、圧縮解除の間、好ましくは、圧縮解除の完成後、各フロックのヘッダは、デスティネイションピクセル（destination pixel）が不可逆的圧縮解除エンジン555あるいは可逆的圧縮解除エンジン550のどちらから選択されるかを決定する。出力フォーマットスイッチ588は、圧縮解除エンジン出力を選択を行う。
他の実施例では、選択されたいずれかの圧縮解除エンジン555もしくは550だけがデータを取扱う。この例では、圧縮データは、ヘッダによって決定される圧縮モードに持ちづいて適切な圧縮解除エンジンに効果的に配置される。
図２１−圧縮フォーマット
図２１に見られるように、本発明の好ましい実施例では、複数の圧縮記憶フォーマットを使うことで、より早いメモリアクセスタイムを可能とする。システムは、システムデータのタイプに基づいて圧縮及び圧縮解除比率を最適化するよう設計されている。プログラムに用いられるデータあるいは他のデータの処理をコントロールするために用いられるデータは、圧縮され、可逆的フォーマット（可逆的圧縮）で記録される。同様にして、回復あるいは圧縮解除の間にロスを持つ圧縮が行われるデータは、不可逆的フォーマットで圧縮される。各フォーマットは、最高の圧縮解除比率と格納サイズのために、特定のアドレスとメモリオリエンテーションとを有する。加えて、各特定の圧縮と圧縮解除フォーマットは、圧縮及び圧縮解除プロセスの間、非圧縮メモリを記録するために用いられるキャッシュメモリの量に基づいて実行帯域幅に拡大縮小する。
図２１を参照して、可逆的フォーマットと不可逆的フォーマットに加えるに、IMC140は、好ましくは、メモリコントローラデバイスに帯域幅を有効かつ最適にするための多重の圧縮及び圧縮解除フォーマットを備える。データソースブロック310,320,330,340,350は、データの圧縮フォーマットを示す。このフォーマットは、システムメモリ110から読み込まれ、CPU102から書き込まれ、不揮発性メモリ120から読み込まれ、I/Oシステムコントローラ116から読み込まれ、あるいはIMC装置140の内部グラフィックブロックから読み込まれ、あるいは図１の先行技術にあるように、PCIもしくはAGPバスからIMC140から読み込まれる。デスティネイションブロック360,370,380,390,396.300は、データの圧縮フォーマットを示す。こおフォーマットは、システムメモリ110に書き込まれ、I/Oシステムコントローラ116に書き込まれ、IMC装置140の内部グラフィックブロックに書き込まれ、あるいは図１の先行技術にあるように、PCIもしくはAGPバスからIMC140に書き込まれる。したがって、ブロック310,320,330,340,350は、データが流れ込むあるいはIMC内で生成されるデータソースフォーマットと考えられる。ブロック360,370,380,390,396,300は、データがIMCの外に流れ出すデスティネイションフォーマットである。デスティネイションフォーマットは、IMC140によって続いて起きるアクセスのソースフォーマットになる。こうして、圧縮フォーマットはソースフォーマット／デスティネイションフォーマットとして参照される。
ブロック302,304,306,308,309は、データのタイプを示す。これらのデータタイプは、テクスチャデータ302,3D-DL304，2D-DL306,DV-DL308,VDRL309を含む。これらのデータは以下で簡単に議論される。
VDRL、間接的圧縮ライン
好ましい実施例におけるデータの一つのフォームは、上記で参照した米国特許第5,838,334に示されているビデオディスプレイリフレッシュリスト（VDRL）データである。VDRLデータは、典型的にはさまざまな非連続メモリ領域からディスプレイをリフレッシュすべく、スパンラインベースのピクセル／ビデオデータを参照するための指令及び／もしくはデータから成る。VDRL圧縮データは、さまざまな傾斜（slopes）と整数データを含むスタート及びストップポインタのロングストリームであることが期待されている。そのようなデータは、好ましい実施例における可逆的圧縮及び圧縮解除プロセスで圧縮される。グラフィックエンジンの下記するVDRLコンテクストレジスタフィールドは、ＶＤＲＬ実行の間、スクリーンデータが可逆的圧縮スクリーンライン（あるいはサブライン）としてシステムメモリに書き戻されるようにプログラムされる。
DestEn
DestType={Linear,XY,or LineCompessed}
pDestTopLinePtr //Pointer to compressed pointer list
pDestTopLine //pointer to screen data
DestMode={Draw&Refresh|DrawOnly}
DestPixFmt
DestPitch
可能なときには、表現もしくはディスプレイ（一つもしくはそれ以上のVDRLセグメントを処理することに基づいて）される各スクリーンライン（あるいはスパンライン）は、独立して（各スクリーンラインごとに、新しい圧縮ストリームはスタートされかつ閉じられる）圧縮され、ｐＤｅｓｔTopLineのカレントバイトのオフセット位置でメモリに書き戻される。加えて、グラフィックエンジンは、ｐＤｅｓｔTopLinePtrのカレントバイトのオフセット位置でポインタを圧縮スクリーンラインに書き戻す。ｐＤｅｓｔTopLineとｐＤｅｓｔTopLinePtrでのカレントオフセットは、グラフィックエンジンによって取り扱われる。圧縮スクリーンデータ300と対応するポインタリストは、続くVDRL309によって圧縮ウィンドウとして参照される。好ましくは、圧縮ウィンドウに関連するワークスペースは、圧縮スクリーンデータに直接アクセスするグラフィックエンジンによって用いられる下記するフィールドを含んでいる。
pTopLine
pToplinePtr
SrcType={Linear|XY|lineCompressed}
pixFmt
Pitch
スクリーンラインは、ライン390（もしくはサブライン）で圧縮され、続くVDRL３０９だけが、カレントスクリーンをリフレッシュされる必要のあるこれらのラインを参照しなければならない。
注：3Ｄ−ＤＬ304とDV-DL308は、また、間接的圧縮スクリーンライン396を同様にして表現できる。しかしんがら、生じた間接的圧縮スクリーンラインは続くVDRLによって消費される。
注：DV-DL308は、基本的には処理及び描画ブロックに基づく。描かれたスクリーンの広さをカバーするに十分な格納ブロックを持たないものを実施するためには、スクリーンライン390,300は、サブラインベースでメモリに圧縮して戻される。
スタティックデータ（静的データ：Static Data）
各独立したトライアングルのために、３Ｄ-トライアングルは、エンジンが、標準的なリニア圧縮360を用いて２つの可逆的に圧縮されたスティックデータブロック：実行用のスタティックデータブロックとグラフィックエンジンスタティックデータブロックを生成するのをセットアップする。与えられた3Dウィンドウあるいはオブジェクトに関し、全てのスタティックデータは、特別なベースアドレス（pTopStatic）に始まりを書き込まれる。各スタティックデータは個別に（各スタティックデータブロックごとに、新しい圧縮ストリームが開始されて閉じられる）圧縮され、pTopStaticへのカレント圧縮ブロックのオフセット位置でメモリに書き戻される。加えて、3Dトライアングルは、エンジンがポインタを適切なスタティックポインタラインバケットにある圧縮スタティックデータブロック（pStatic）に書き戻すのをセットアップする。ｐStaticのフォーマットは、次のフィールドから成る：スタティックデータブロックポインタオフセット、スタティックフォーマット（データが圧縮されているかどうかを示す）、実行スタティックデータブロックと関係する圧縮ブロックの数、及びグラフィックエンジンスタティックデータブロックと関係する圧縮ブロックの数。各スタティックデータブロックタイプのための圧縮ブロックの数は、どのくらいのデータが圧縮解除されるかを圧縮解除エンジンに指示するために用いられることに注意されたい。
3D-DL
3D-DLは、3Dイメージをメモリもしくはディスプレイにレンダリングするための３次元描画リストを備える。各3Dウィンドウライン（あるいはサブライン）のために、3D実行エンジンが３Ｄ-DL304の可逆的圧縮ストリームを生成する。各3D-DLラインは個別に（すなわち、各3DDLラインのために、新しい圧縮ストリームがスタートされ、そして閉じられる）圧縮され、結果である圧縮3D-DLライン390は、メモリ110に書き戻される。3D-DLの連続するラインがメモリ内に連続する必要はない。加えて、IMC140の3D実行エンジンは、3D-DLポインタを、3D-DLポインタリストへのカレントポインタのオフセット位置で圧縮3D-DLラインに書き戻す。結果である圧縮3D-DLライン390と対応する3D-DLポインタリスト304は、構文解析され、3Dグラフィックエンジン212によって消費される。グラフィックエンジン212は次の3D-DLコンテクストレジスタフィールド（context register field）を用いる。
p3DDL
p3DDLPtr
コンテクストレジスタフィールドは、3D-DLの実行の間、コンテクスト情報をＩＭＣ140に提供することを操作する。
注：3D-DLは、ライン390（あるいはサブライン）ベイシス（basis）で圧縮され、3Dウィンドウ（VDRLウィンドウ優先解像度からのフィードバックに基づく）の視認可能な部分だけが描画される必要がある。
テクスチャ（Textures）
レンダリングのためのテクスチャデータ302は、本発明にしたがって同様に圧縮及び圧縮解除される。不可逆的アルゴリズムが、イメージを圧縮する。別の実施例では、不可逆的と可逆的アルゴリズムのパラレルな結合が、時間の遅れを付け加えることなしにイメージやテクスチャマップの質を改善するために用いられる。テクスチャデータ302は、本発明のブロック圧縮フォーマット380において圧縮及び圧縮解除される。Ｔテクスチャを持つ不可逆的（あるいは可逆的）圧縮テクスチャテーブルのロジカルフォーマットは、次の通りである。
pTopTex-＞
opTex0-＞
pLod0Blk0-＞ 8×8 圧縮テクスチャサブブロック
pLod0Blk0(last)-＞
pLod(last)Blk(last)-＞
opTexl-＞
pLod0Blk0-＞
opTex(T-1)-＞ ．．．．
pTopTexは、圧縮テクスチャテーブルへのベースポインタである。ｐTopTexは、3Dウィンドウベイシスごとのグラフィックエンジン212にロードされる。opTexは、ｐTopTexへのオフセットである。ｐTopTexは、グラフィックエンジン212を備える。グラフィックエンジン212は、ターゲットとなるテクスチャと関係する最初に圧縮されたテクスチャサブブロック（すなわち、LOD0、サブブロック0）へのポインタを有する。ｏｐＴｅｘは、グループ属性（attribute）データブロック、レンダ-ステイト(ＲｅｎｄｅｒＳｔａｔｅ)に配置されたフィールドである。レンダ-ステイトは、トライアングルのグループによって割り当てられた属性を有する。グループ属性データブロックポインタ、pレンダ-ステイト（pＲｅｎｄｅｒＳｔａｔｅ）は、各3D-DL304セグメントに含まれる。ｐTopTex、ｏｐTex、及び全てのテクスチャ属性とモディファイアを用いることで、グラフィックエンジンのテクスチャアドレス生成エンジンの一つが、先取りするためのどれかの臨界テクスチャサブブロック380（ｐLodBlk）を決定する。
テクスチャサブブロックのサイズは、好ましくは、８×８テクセルである。圧縮テクスチャのサブブロックは、圧縮テクスチャキャッシュに読み込まれる。ｐＬodBlkポインタは８×８圧縮テクスチャサブブロック380を指し示すことに注意すべきである。
DV-DLビデオ
DV-DLフォーマットは、ディジタルビデオをメモリあるいはディスプレイにレンダリングするディジタルビデオドローリストから成る。ブロック圧縮フォーマット380は、ビデオとビデオモーション予測データのために用いられる。加えるに、ディスプレイデータ300は圧縮フォーマットで記憶される。ディスプレイデータ300は、２ｋバイトよりも大きいスキャンラインブロック内のRGBもしくはYUVデータを順次アクセスされる。ディスプレイデータ300の好ましい圧縮法は、並列的に可逆的フォーマットで全てのスパンラインをライン圧縮３９０することである。
ビデオ入力データは、可逆的、不可逆的、あるいはその結合といいたどのようなフォーマットであれ圧縮される。ビデオデータは、リニアでもしくはX/Yフォーマットでアドレス指定された２次元的ブロック３８０に圧縮及び圧縮解除される。
各データタイプは、入ってくるソースフォーマットの最も効果的なナチュラルデータと一致する特異なアドレススキームを持つ。
特別なグラフィック、ビデオ、及びオーディオデータタイプ306,308,310に関し、データタイプは、システムにとって最適の圧縮比率を達成するために各圧縮フォーマットを関連付けられる。
ブロック310,360は、CPU102とシステムソフトウェアによって詳細をリニアにアドレス指定された圧縮もしくは圧縮解除データブロックの可逆的もしくは不可逆的圧縮及び圧縮解除フォーマットを示す。データブロックのサイズとデータ圧縮のタイプは帯域幅とアプリケーション及びシステムのコスト条件とに依存する。ブロック310に適用されたソースデータは、もしシステムメモリからのものであるなら、圧縮解除され、ノーマル（非圧縮）データあるいは圧縮解除に関連した幾分のロスのあるデータとして、デスティネイションに書き込まれる。ブロック310に提供された圧縮データの入力帯域幅は、圧縮比率の違いによって分割されたノーマルな圧縮されていないデータに要求される帯域幅と同じである。圧縮比率は、多重の制約条件の一つの要素であり、それには圧縮ブロックのサイズ、データのタイプ、そひてデータフォーマットが含まれる。さらに、非圧縮のデスティネイションデータの帯域幅は、オリジナルの非圧縮のソースデータの帯域幅と等しい。加えるに、ソースデータは、圧縮されて多くの圧縮フォーマットの一つによってデスティネーションに書き込まれる非圧縮のノーマルデータである。これをブロック360,380,390,396によって示す。
ソースデータブロック320は、圧縮によって変化していない、入り込んでくるデータを示す。このケースでは、データは、テクスチャタイプを示し、3Dテクスチャメモリスペースを最適に使用するため、圧縮ブロックフォーマット380で書き込まれる。同様に、３Ｄ-Ｄｒａｗ（3D-DDL）タイプのデータは、非圧縮フォーマットでソースデータとして受け取られ、処理され、非圧縮370もしくはライン圧縮390デスティネイションフォーマットのどちらかで出力されるためにフォーマットされる。同様な操作は、ソースが既に圧縮ブロックフォーマット330にあるときにも生じる。
圧縮ライン340/390は、VDRL309指示から生成され、後に他のリクエスティングエイジェントによって使用されるために、部分的に圧縮ラインセグメント340/390に格納される。これらの圧縮ラインセグメントは、標準のリニアアドレスフォーマットにアドレス指定される。
中間の圧縮ラインセグメント350/396は、中間ライン350/396を圧縮するために圧縮ブロック330/380から変換を行う特別なケースである。圧縮中間ラインは、圧縮ブロック330/380とディジタルビデオドローリスト（DV-DL）308の間の変換技術として用いられる。
ディスプレイデータ300も、また圧縮され、典型的にはリニア完全スパンライン（linear complete span lines）である可逆的フォーマットで圧縮される。ディスプレイにビデオをリフレッシュする間、3Dグラフィックエンジン212によってモディファイされていないディスプレイ圧縮スパンライン300が個々のディスプレイデバイススパンラインのディスプレイを圧縮解除する。
ビデオとテクスチャデータ302は、非圧縮320/370の状態かあるいは圧縮ブロック330/380フォーマットのデータである。ブロックフォーマット330/380は、典型的にはX/Yアドレスを示す８×８ブロックであるが、８バイトのピッチを持つリニア６４バイトとしてシステムメモリ内で参照される。圧縮ブロックフォーマット330/380において、圧縮解除は32×32テクスチャブロックとなり、X/Yフォーマットでアドレス指定される。
VDRL（video display refresh list，ビデオディスプレイリフレッシュリスト）309、DV-DL（digital video draw list，ディジタルビデオドローリスト）308、3D-DL（3-D draw list，3-Dドローリスト）のような指示リスト（Instruction list）は、リニアアドレス指定のある可逆的圧縮フォーマットで記録される。CPUデータは、リニアアドレス指示のある可逆的圧縮フォーマットによって記録される。これらの指示リストは、ジオメトリ（geometry）リストに対応してメモリ内でピクセルデータを表示するために実行でき、また、ディスプレイ装置のディスプレイ用にメモリからビデオ/ピクセルデータにアクセス可能である。これらの表示（描画）結果は、図２１に示すフォーマットを持つ。例えば、ソースとしての非圧縮リニアアドレスデータ320は、操作され、3D-DL304指示リストによって読み取られ、圧縮ライン390フォーマットで圧縮されて記録され、あるいは非圧縮370データフォーマットで記録される。図２１に示された各操作は、データの移行と記録のための好ましいフォーマットを有する。
タイプ2Dドローリスト306であるデータは、非圧縮320フォーマットもしくはブロック圧縮396フォーマットでソースデータとして受け取られる。２D-DLデータタイプ306は、出力データが非圧縮370でもしくは中間ライン圧縮396フォーマットのデータである。
ディジタルビデオドローリスト（DV-DL）308に関しては、DV-DL308のソースデータは、非圧縮320フォーマットであるいはブロック圧縮330フォーマットで受け取られる。デスティネイションへのその出力は、中間圧縮396フォーマットである。
VDRLデータタイプのソースデータは、非圧縮320、圧縮ライン340、あるいは中間圧縮ライン350フォーマットのいずれかで受け取られる。そして、圧縮ライン390としてデスティネイションアドレスに出力され、あるいはディスプレイ装置に直接出力される。
最後に、ディスプレイフォーマットタイプ300のデータは、ノーマルデータあるいはリニアスパンアレスィングフォーマットの可逆的圧縮データである。
米国特許第5,838,334号に示されているように、ワークスペースエアリアは、メモリに位置し、ウィンドウあるいはオブジェクトタイプを定義づける。ワークスペース域と圧縮及び圧縮解除操作との間の関係は、次の通りである。各ワークスペースは、ウィンドウあるいはディスプレイのオブジェクトを再生するための圧縮のタイプや質を示すデータエリアを有する。アプリケーションソフトウェア（API）、グラフィカルユーザーインターフェイス(GUI)あるいはオペレーティングシステム(OS)ソフトウェアは、タイプとメモリアロケーションの必要条件を決定し、コストとパフォーマンスと有効性を最適なものにする。オリジナルの内容から変化し、あるいはサイズの変更がされたウィンドウあるいはオブジェクトは、メインシステムメモリのウィンドウワークスペースエアリアに示されているディスプレイに最終的に表示するために、複数の質のレベルで表示される。加えて、3Dオブジェクトあるいはテクスチャは、圧縮の質の属性を含んでいる。圧縮タイプと、アドレスフォーマットと、表現の質を個別のウィンドウもしくはオブジェクトのワークスペースエアリア内で割り当てることにより、システムは、メモリサイズと帯域幅の要求条件を除外でき、コストとパフォーマンスが最適化される。
データタイプであるテクスチャデータ302、3D-ドローリスト304、2D-ドローリスト306、ディジタルビデオドローリスト308、及びヴァーチャル（ビデオ）ディスプレイリフレッシュリスト309は、米国特許第5,838,334号で参照できるように、全て、IMCのオーディオ、ビデオ、グラフィックメディアのフォーマットを示す。
核となる圧縮ブロックフォーマットによって、多重のデータタイプをさまざまなソースの入力として用いることができる。圧縮及び圧縮解除のフォーマットは、受け取られるデータのタイプに合わせてデータを最も小さく格納可能なユニットに高効率で圧縮する。これを達成するために、メモリコントローラ210は、受け取るデータのタイプを理解する。
したがって、IMC140は、CPU102、システムメモリ110、及びビデオディスプレイの詳細なフォーマットをデザインすることによってシステム内を移動されるデータの量を少なくし、その結果、コンピュータシステムのパフォーマンスを改善してコストを低減させる。本発明によれば、CPU102は、さまざまなサブシステムの間でデータが移動する時間を大幅に少なくする。これによって、CPU102の自由度が増し、CPU102がアプリケーションプログラムを動作させる時間を大幅に増やす。
後述するように、CPUからのデータは圧縮され、さまざまなブロックサイズを持つリニアアドレスメモリに格納される。CPUからのこのデータは、グラフィックデータには関係しないし、またキャッシュラインあるいは最近使われたページ（LRU）あるいはCPUベースのアプリケーションからの要求されるメモリが無効であることから生じる。本実施例で、圧縮を求めるドライバは、メモリ割り当てと、圧縮と圧縮解除の両方のデータのためのディレクトリ要素を取扱う。
待ち時間と効率性
メモリコントローラ220は、新規な２つの方法によって読取りのための待ち時間を最小にする。それぞれの方法は、好ましい実施例を参照しつつ後で議論する。待ち時間を減らすためのコントロールファンクションのほとんどは、スイッチロジック261内に位置し、また圧縮スイッチロジック516と圧縮解除スイッチ512とノーマルメモリスイッチ514内に位置している。圧縮ブロックとＬ3データキャッシュブロックのデータアドレスの場所が、待ち時間を減少させるのに大きな役割を果たす。待ち時間減少と効率性を確保するさまざまな方法には次の方法が含まれる。パラレル圧縮／圧縮解除（上記した）、選択的圧縮モード、優先的圧縮モード、変更可能な圧縮ブロックサイズ、L3データキャッシュ、および圧縮記録。図２２と２３―基準に基づく圧縮／圧縮解除の選択
パラレル圧縮及び圧縮解除ユニット251は、米国特許出願08/463,106号に示されているように、要求エージェント、アドレスレンジ、あるいはデータタイプ及びフォーマットの一つあるいはそれ以上に基づいて、圧縮／圧縮解除モードあるいはタイプを選択的に実行する。圧縮／圧縮解除モード（圧縮モード）は、可逆的圧縮、不可逆的圧縮、圧縮なし、及び図２１に見られるさまざまな圧縮フォーマットを含む。圧縮モードは、ディスプレイに表示されるビデオ／グラフィカルオブジェクトあるいはウィンドウのための不可逆的圧縮のレベルを変えることを含む。IMC140は、最初のデータのための可逆的圧縮、二番目のデータのための不可逆的圧縮、三番目のための圧縮なしの状態を選択的に実行できる。
図２２と２３は圧縮及び圧縮解除スキームを選択的に用いることを示すフローチャートである。図２２と２３の方法は、圧縮／圧縮解除エンジンから成るメモリコントローラによって実行される。メモリコントローラは、システムメモリをコントロールするためのシステムメモリコントローラである。そこではシステムメモリはCPUによって実行されるアプリケーションコードとデータを記録する。
ステップ802の手法は、非圧縮データを最初に受け取る。データはCPUアプリケーションデータ、オペレーティングシステムデータ、グラフィックス／ビデオデータ、あるいは他のタイプのデータである。データは、さまざまな要求エージェントから生じたものである。
ステップ804において手法は、データの圧縮法を決定する。圧縮モードは可逆的圧縮、不可逆的圧縮、圧縮なしの一つから成る。他の圧縮モードは、図２１に示す圧縮タイプ、例えば、圧縮リニア、圧縮ブロック、圧縮ライン、あるいはＩ圧縮ラインの一つと結合される可逆的あるいは不可逆タイプのいずれかを含む。
圧縮モードは、データが格納されるアドレスレンジ、データを提供する要求エージェント、及び／もしくはデータのデータタイプの一つあるいはそれ以上に対応して決定される。
アドレスレンジが圧縮モードの決定に用いられると、手法は、圧縮モードを決定するためのデータを受け取られるデスティネイションアドレスを分析する。そこでは、デスティネイションアドレスは、メモリ内のデータの格納デスティネイションを示す。例えば、最初のアドレスレンジが可逆的圧縮フォーマットで設計されると仮定すると、第二のアドレスレンジは不可逆的圧縮フォーマットで設計され、第三のアドレスレンジは圧縮されないフォーマットで設計される。この事例で、圧縮モードを決定するステップ804は、アドレスが第一のアドレスレンジ、第二のアドレスレンジ、あるいは第三のアドレスレンジにあるかを決定するデスティネイションアドレスを分析することから成る。
要求エージェントは、圧縮モードを決定するために用いられる。手法は、誰が要求エージェントであるかを決め、それから要求エージェントに基づいて圧縮モードを決定する。例えば、要求エージェントがCPUアプリケーションあるいは関連ドライバなら、可逆的圧縮が適用される。要求エージェントがビデオ／グラフィックドライバなら、不可逆的圧縮が適用される。
データタイプは圧縮モードを決定するために用いられるところでは、手法は、データタイプを調べ、データタイプに基づく圧縮モードを決定する。上記した例を用いると、データがアプリケーションデータなら、圧縮モードは可逆的圧縮に決定される。データがビデオ／グラフィックデータなら、圧縮モードは不可逆的圧縮になる。好ましい実施例では、圧縮モードの決定は、生来的にはデータタイプに基づいて行われる。アドレスレンジの使用あるいは要求エージェントは、潜在的に、アドレスレンジに格納されたデータタイプあるいは要求エージェントの源であるデータタイプに基づいて圧縮モードを決定する。
さらに、圧縮モードは、ディスプレイに表示されるビデオ／グラフィカルオブジェクトあるいはウィンドウの不可逆的圧縮のレベルを変化させることも含んでいる。より大きな圧縮比率での不可逆的圧縮は、ディスプレイの背景にあるオブジェクトに適用される。より小さな圧縮比率での不可逆的圧縮は、ディスプレイの前景にあるオブジェクトに適用される。上記したように、グラフィッカル／イメージデータのために、ステップ804において圧縮モードはオブジェクトごとのベースで決定される。例えば、オブジェクトが前景にあるか背景にあるか、あるいはグラフィカルオブジェクトの属性に基づいて決定される。不可逆的圧縮のレベルを2,4,8,16に変化させることは、オブジェクトの属性に基づいてグラフィカル／イメージデータに適用される。
ステップ806において、手法は、非圧縮データをデータの圧縮モードに基づいてあるいは対応して選択的に圧縮する。ステップ806において、データは、もし、圧縮モードが可逆的圧縮なら、可逆的圧縮フォーマットを用いてメモリに格納される。データは、もし圧縮モードが不可逆的圧縮を示すなら、メモリに不可逆的圧縮によりメモリに格納あれる。また、もし圧縮モードがデータのなんの圧縮も示してないなら、データは非圧縮フォーマットでメモリに格納される。
メモリへのデータの格納は、データの圧縮モード情報の格納を含む。圧縮モード情報は、圧縮データの圧縮解除の手続をも示す。圧縮モード情報は、データの圧縮モードを無視して圧縮されないフォーマットで記録される。
圧縮モード情報は、データに埋め込まれる。すなわち、分離されたテーブルやディレクトリに記録されるのではない。ヘッダは、最初のデータの圧縮情報を示す圧縮モード情報を含むように作成される。ヘッダは、また、データのトップに位置される。すなわち、アドレスの最初であり、データが後を続く。データの最後あるいは指定された位置に設けるようにしても良い。
別の実施例では、IMC140は、IMC140のメモリ内に、オーバーフロータグとオーバーフローテーブルエントリナンバーのためのスペースを予約する。IMC140は分離されたオーバーフローキャッシュと、エントリーテーブルと、コントロールロジックを含む。別の実施例では、オーバーフロー表示は、通常（ノーマル）圧縮操作に用いられる同じコントロール及び翻訳キャッシュロジックブロックによって処理される。
図２３は、記憶データの圧縮解除を示す。ステップ812において、手法はデータの要求を受け取る。
ステップ814において、手法は、要求に対応してメモリからデータにアクセスする。
ステップ816において、手法は、要求を受け取ることに対応したデータのための圧縮モードを決定する。圧縮モードは、記録されるデータから形成され、好ましくはヘッダを備える。データは、ステップ８１６で圧縮モードが決定される前に、始めにステップ814においてアクセスされる。ステップ818において、手法は、データを圧縮解除する。圧縮解除のタイプあるいはモードは、データの圧縮モードに基づいて選択される。ステップ818の選択される圧縮解除において、データは、もし圧縮モードがデータの可逆的圧縮であるなら可逆的圧縮を使うことが決定され、もし圧縮モードがデータの不可逆的圧縮であるなら不可逆的圧縮が用いられ、また圧縮モードがデータを圧縮されない状態なら、圧縮されない。
ステップ820において、手法は、圧縮解除の後、要求に答えるデータを提供する。待ち時間をさらに減らすために、選択されたあるデータが、圧縮されない通常の操作によってまたは不可逆的あるいは可逆的な圧縮モードで記録／回復される。これは、アドレスレンジを、圧縮されていないことを示す特別のフラグを含んでいるメモリマネジメントユニット（MMU）ブロックで比較することによって達成される。パワーオン構成のために、これらの圧縮されないアドレスレンジは、オペレイティングシステムによって用いられる監視モードコード及びデータブロックによってセットされる。
メモリコントローラ210内のMMUは、もし必要ならどの圧縮フォームかを決定する（例えば4096バイトレンジ）。この決定は、メモリページバウンダリ（memory page boundary）のMMU翻訳テーブルに位置する圧縮フィールドに基づく。別の実施例では、タイプフラグの圧縮は、複数のバウンダリレンジに位置される。メモリ圧縮データタイプを決めるためにアドレスレンジ調査を用いる手法は、「埋込み型データ圧縮及び圧縮解除エンジンを有するメモリコントローラ」という名称の特許（1995年6月5日出願、出願番号08/463,106、発明者：トーマス エイ、ダイ）に開示されている。
圧縮データのためのメモリ割り当て―優先的及び通常圧縮モード
IMC140は、速く有効なメモリ配置とデータ回復のために２つの異なる圧縮モードを含む。２つのモードとは、「優先圧縮モード」と「通常圧縮モード」である。「優先圧縮モード」のアーキテクチャは、非侵入型（non-intrusive）のメモリ割り当てスキームである。優先モードは、より速い有効帯域幅にとって、システムソフトウェアを変更することなしにメモリF/Xテクノロジを具体化する能力があり、これには圧縮／圧縮解除能力を含む。ＯＳを変更しないこのケースにおいて、IMC140のメモリコントローラ210は、メモリサイズを保全するよりも帯域幅改良にもっとぴったりする。メモリ割り当てと圧縮操作は、オーバーフロースペースのために圧縮アルゴリズムによって空けられた付加メモリを用いる。オーバーフロースペースは、可逆的圧縮によって圧縮前のオリジナルデータのサイズよりもより多くのデータを生じるケースにおいて、用いられる。優先モードは、より速くデータ伝送を行う必要があってメモリ保全の必要のないシステムで用いられる。
優先モード操作のケースでは、オーバーフローアドレスは、圧縮操作によって先に減少されたメモリブロック内にある。優先モードでは、システムソフトウェアの再割り当ては、メモリ割り当てとサイズをする必要がない。二次レベルのオーバーフローあるいはメモリ割り当てによって提供されたオーバーフローエリアにフィットしないオーバーフローはシステムレベルの中断ドライバによって取り扱われる。このケースでは、リアルタイムイベントはセカンドレベルの中断遅れを取扱うことができない。要求サイズの固定圧縮比率が別の実施例のもとで用いられる。
優先モードは、データを圧縮し、圧縮データをコンピュータシステムのメモリに格納するために用いられる。コンピュータシステムのそこの部分は、圧縮のためのアカウントには必要でない。優先モードで、コンピュータシステム、例えばオペレイティングシステムは、最初に、非圧縮データのメモリブロックを割り当てる。メモリブロックは、非圧縮データが記録されると仮定される部分に割り当てられる。オペレイティングシステムは、圧縮操作をアカウントする必要はなく、圧縮操作に気がつかない
メモリコントローラは、後で、非圧縮データと、一つもしくはそれ以上の対応するデスティネイションアドレスを受け取る。デスティネイションアドレスは、割り当てられたメモリブロック内の最初のデータの記録デスティネイション（storage destination）を表示する。メモリコントローラは、それから、一つもしくはそれ以上のデスティネイションアドレスで割り当てられたメモリブロック内の圧縮された最初のデータを記録する。この記録操作は、待ち時間を減らすために一つもしくはそれ以上のデスティネイションアドレスのアドレス翻訳を行わない。優先モードは、メモリ最小化の実行を企てるものではない。オーバーフロー記録は、必要があれば、割り当てられたメモリブロック内で割り当てられる。
要求エージェントが圧縮データを後に要求するとき、デスティネイションアドレスは、メモリから圧縮データにアクセスし、圧縮データを圧縮解除し、また要求に答えて圧縮解除データを提供するために用いられる。
１． 通常モード圧縮
通常圧縮モード（非優先モード）において、IMC140は、圧縮解除プロセスの間、速く有効なデータ検索を行うために新しいメモリディレクトリを用いる。新しいディレクトリによって、メモリ割り当てと、ディレクトリテーブルと、コンピュータのメインシステムメモリバンク110で用いるオペレーシングシステムソフトウェアを助けるための固定エリア割り当てを保持するメモリ消費量が最小になる。
可逆的圧縮解除
圧縮されたデータの可逆的圧縮解除のための平行した圧縮解除エンジン５５０の１つの化身が今明らかにされる。 データ圧縮方法が圧縮解除されたデータからのただ１つだけのシンボルが調べられて、そして一度に圧縮される連続的な圧縮方法と圧縮解除されたデータからのシンボルの複数性が調べられて、そして一度に圧縮されるかもしれない上に記述された、新奇な並列圧縮方法を含むかもしれない。 １つの化身で、平行した圧縮解除エンジン５５０は連続的であるか、あるいは並列圧縮解除方法によって圧縮されたデータを圧縮解除することが可能であるかもしれない。 同じく、現在の発明の平行した圧縮解除技術を使っている圧縮されたデータの圧縮解除は公知の事実連続的な圧縮解除テクニックを使っている同じ圧縮されたデータの圧縮解除と比べて同じ圧縮解除されたデータ流を作り出す。 上に記述された並列圧縮方法を使って作られた圧縮されたデータは連載の圧縮アルゴリズムを使って引き起こされて圧縮されたデータとまったく同じであるよう意図される；それ故に、連続的であるか、あるいは平行した圧縮解除エンジンによって上に記述された並列方法で圧縮されたデータを圧縮解除することは同じ圧縮解除されたデータをもたらすだろう。 なるべく、圧縮解除が圧縮オペレーションとして、あるいはより速く同じぐらい速く行われる。 同じく、代わりの化身で、圧縮解除エンジン５５０/５５５がシステムの中で場所の複数性で置かれるかもしれない、あるいは多数の圧縮解除エンジンが圧縮解除プロセスと注文制のバンド幅あるいはスループットの注文制のオペレーションに割り当てる回路が圧縮解除エンジン５５０で使われた段階の数に頼って設計されるかもしれない。 従って、公知の事実連載のアルゴリズムより広帯域で屈服する平行した圧縮解除エンジン５５０のために下に平行した圧縮解除アルゴリズムだ。
Fi es ３２ − ４３ − 平行した圧縮解除エンジン (Parallel Decompression Engine) の化身
平行した圧縮解除エンジン５５０は一連の段階、なるべくパイプラインで送られた段階に分けられるかもしれない。
圧縮解除エンジン５５０の段階は図３３で例証される。 見せられるように、圧縮解除エンジン５５０はデコーダを含んでいる最初の段階２５５０１を含むかもしれない、（同じくイニシャルあるいは予備選挙と呼ばれる）２番目のステージ２５５０５を含んでいる下準備が世代ロジック、３番目のステージ２５５０９を含んでいる最終の選り抜きの世代ロジックと４番目の段階２５５１３のデータ選択を含んでいるそしてアウトプットのロジックを選ぶ。 パイプレジスタ２５５０３が最初のステージ２５５０１と２番目のステージ２５５０５につながれるかもしれない。 パイプレジスタ２５５０７が２番目のステージ２５５０５と３番目のステージ２５５０９につながれるかもしれない。 パイプレジスタ２５５１１が３番目のステージ２５５０９と４番目のステージ２５５１３につながれるかもしれない。 １つの化身によればパイプラインで送られた模様は ０.２５u CMOS 技術を使って１３３ MHz において走るために４つの段階を利用することを期待される。 これらの段階はなるべく分けられるか、あるいは、プロセス技術が必要とするシリコンとして、代わりに結合される。 ただこのパイプライン２５５１３の中の最後の段階だけがヒストリーウインドウを使う、そしてその最終のステージは最小ロジックを含んでいる。 これに基づいて、この機能は、もし際立ってより速い時計が利用可能であるなら、４以上の段階に延長されるかもしれない。
それで、代わりの化身で、処理が良くなり、そして時計率が増加する（時・から・につれて・ように）、圧縮解除エンジン５５０の段階は同じインプット圧縮ストリームで圧縮解除率を引き上げるために増加するかもしれない。 しかしながら、望ましい embodment のために見せられた４つの段階は機能の論理的な部門だ。 他の化身が４以下の段階を含むかもしれない。 例えば、３段階の embodement が１つの段階の中に２番目と３番目のステージを結合するかもしれない。
圧縮解除エンジン５５０が含む望ましい化身でパイプラインで送られた！多段階のデザイン。 圧縮解除エンジン５５０のパイプラインで送られた、多段階のデザインはそれぞれの段階でデータの十分に同時か、あるいは同時の処理を可能にする。 ここに使われるように、アジサシ「圧縮解除サイクル」はデータのセットの上にすべてのパイプラインの段階のオペレーションを含む、トークンの分析からそうする最初の段階でデータのインプットセクションでアウトプットの生産が最後のステージでデータを圧縮解除した。 それで、多数の「圧縮解除サイクル」が、十分に同時に、ｉ、ｅ．を実行しているかもしれない、多数の「圧縮解除サイクル」の diffierent 段階が同時に十分に実行しているかもしれない。
例えば、最初の段階２５５０１は（同じくトークンと呼ばれる）コードの最初の複数性を受けて、そして最初の圧縮解除サイクルの始めにおいてデコーダに最初のトークンを載せるかもしれない。 デコーダーは最初の印から種々の最初の解読されたインフォメーションを抽出するかもしれない、そしてこの最初の解読されたインフォメーションはパイプレジスタ２５５０３の中に掛け金で締められるかもしれない。
最初の解読されたインフォメーションはそれから２番目の段階２５５０５の予備の選り抜きのロジックにロードされるかもしれない。 ２番目の段階２５５０５の予備の選り抜きのロジックが最初の解読されたインフォメーションに作用している間に、トークン（２番目のトークン）の次の複数性が、十分に同時に、２番目の解読されたインフォメーションを作り出す２番目の圧縮解除サイクルの始めの中に最初の段階２５５０１によって受け取られて、そして積み込まれて、そしてにおいて解読者によって処理されるかもしれない。
２が事前で生成して完了した段階が最初の圧縮解除サイクルで初めから解読された ingformation を選ぶ、下準備が選択する時２番目の圧縮解除サイクルでパイプレジスタ２５５０７の中に掛け金で締められる。
同様に、１（人・つ）が第２を生成して完成したステージが２番目の圧縮解除サイクルでインフォメーションを解読した時、この２番目の解読されたインフォメーションはパイプレジスタ２５５０３の中に掛け金で締められるかもしれない。 もしその時が決勝戦の中への解決のための段階２５５０９が選ぶ第３に載せられたなら、下準備は選択する、他方２番目の圧縮解除サイクルのために最初の段階２５５０１で生成された２番目の解読されたインフォメーションは２番目の段階２５５０５にロードされる、そしてトークンの次の（３分の１）複数性が最初の段階２５５０１によって受けられて、そして３番目の圧縮解除サイクルを始めるためにデコーダに載せられる。 それで、圧縮解除の４段階の化身でエンジン５５０、４つの圧縮解除サイクルが十分に同時に圧縮解除エンジン５５０でアクティブであるかもしれない。
ここに使われるように、最初のステージという環境で現在の圧縮解除サイクルで並列に圧縮されたデータからトークンの複数性を調べて、「平行の」用語はトークンの複数性が圧縮解除エンジン５５０のひとつのパイプライン段階の間にロジックによって作用されるかもしれないという考えを含む。 期間は「並列に」同じくデコーダの複数性が圧縮解除エンジン５５０のひとつのパイプライン段階の間にトークンの複数性に作用するという考えを含むかもしれない。 トークンの複数性は実際に連続的に、あるいは consecutively にインプットデータセクションから抽出されるかもしれない。 トークンの複数性はそれから、（彼・それ）らがインプットデータセクションから抽出される（時・から・につれて・ように）、利用可能なデコーダに割り当てられるかもしれない。 印が利用可能なデコーダに割り当てられた途端に、デコーダによってのトークンの処理の１部が並列に行われるかもしれない。 加えるに、「平行の」期日は同じくデコーダの複数性がパイプラインの次の段階に並列に解読されたインフォメーションを出力したという考えを含むかもしれない。
ここに、複数性を生み出すことについての文脈で使われるようにについて並列に期間「並列に」十分に同時にトークンの複数性に対応しているインフォメーションそして／あるいはロジックが作用するかもしれない選り抜きの（人たち・もの）が生み出す選り抜きのロジック（段階２そして／あるいは３）が解読されて同時に処理するかもしれない考えが十分に同時に出力された圧縮解除されたシンボルの複数性のために選ぶ組み込みを選ぶ。 下に記述されるように、選り抜きのロジックはインフォメーションに関係することを共有するそれを選ぶ異なったアウトプットによって圧縮解除されたシンボルのために並列に生成されている。
それ故に、一般的であって、さらに多くを減圧することのためのインフォメーショントークンが（そのために）トークンと結果の上に段階、行われた段階のオペレーションの中に載せられるかもしれない（の・もの・人）よりトークンはそれから次のステージで処理のためにパイプ記録の中に段階から掛け金で締められるかもしれない。 それぞれの段階で、インプットの複数性について「並列に」十分に同時のオペレーションを行うことに対してロジックのコピーがあるかもしれない。
例えば、最初の段階２５５０１で、引き抜かれたトークンがそれぞれの可能性があるアウトプットバイトで段階のオペレーションを行って、２番目の３番目、そして４番目の段階での、デコーダがそこ（に・で）（そのために）ロジックの１コピーであるかもしれない（の・もの・人）に割り当てられる。 若干の若干の段階でのオペレーションが連続的な処理を利用してもよい属国を持っているかもしれないことを注意を払え。
例えば、最初の段階２５５０１の２番目のデコーダに２番目のトークンを載せることは最初のデコーダで最初のトークンの荷積みによって生み出されてカウントと他のインフォメーションを利用するかもしれない。
この新奇な圧縮解除を理解するために、図３２のテーブルはサンプルコードのために圧縮マスクとインデックスコーディングアルゴリズムを例証する。 代わりの化身で、他のコードが圧縮解除ユニットのデザインを変えるかもしれない。 １つの化身がコードが８ビットを使う１バイトを cmgpressing するコード以外図３２に含めたすべてを含むかもしれない。 圧縮されたインプットデータで、コードが同じく「トークンである」と述べられるかもしれない。
図３２のテーブルで見せられたコードで、図３４での圧縮解除ツリーは１つのサイクルでのせいぜい８バイトのインプットを解読することを許す。 この例で、せいぜい８バイト（６４ビット）がそれぞれの圧縮解除サイクルの図３３の圧縮解除エンジンへのインプットデータとして圧縮されたデータから抽出される。 最も小さいコード化されたデータは８ビットだ、それで図３４で、８バイトで示されたデコーダ（２５５２１-２５５３５）の最小数は８（６４ビット ／ ８ビット）だ。 これらのデコーダのそれぞれが多くのデータインプットの１つが事前の圧縮されたデータに頼っているのを見ることができた。
図３４がデコーダ段階２５５０１を例証する、そしてそれは図３３の圧縮解除エンジンの最初のステージだ。 圧縮解除の木は、図３４で見せられて、次の段階の適切なデータを決定するためにそれぞれの段階において非常に速い解読することを利用する。 伯爵 (Count) とデータバイトアウトプット（図３２）がなるべく次のステージのために掛け金で締められるウインドウインデックススタート (Start) 図３３のパイプラインを解読する。 これはパイプラインを解読するアウトプットデータのアセンプリを必要とする。
望ましい Decode ブロックのもっと多くの細部が図３５で見られることができる。
図３５が図３４の最初の段階デコーダの１つのロジックを例証する。 図３５で、２５５５３がそれほど十分に実証するチェック Valid ブロックビットはレジ係２５５５５（ − ｅ）のために利用可能だ。 １（つ・人）あるいはそれ以上の解読者によって解読されるインプットデータから１（つ・人）あるいはそれ以上のコードを抽出した後で、十分なビット完全な印を作図するためのインプットデータでないかもしれない。 例えば、サイクルでインプットデータの８バイト（６４ビット）を受け入れる上に記述された圧縮解除エンジンで、もし６つの１０ビットのコードが最初の６つのデコーダーにロードされるなら、４ビットがもう６４ビットのインプットデータを使っている例で完全な合計を組み立てるために、十分にではなく、インプットデータで置き残されるだろう、もし４ １O - ビットコードと１つの１３ビットのコードが最初の５つのデコーダーにロードされるなら、１１ビットがインプットデータで残される。 チェック Valid ブロック２５５５３は１１ビットに完全なコードがあるかどうか決定するために１１ビットでそれからフラグインフォメーションをチェックするかもしれない（８、９あるいはすべてビットコード）。 もし完全なコードがあるなら、コードは次のデコーダでロードされる。 もしフラグインフォメーションが（１３あるいは２５ビットのコード）、そして次にビットがそうである１１ビットがロードしないそして調査したより長く１１ビットが不完全なコードであることを示すなら後にサイクルを解読する。 チェック Valid ブロックのためのテーブルは図 (Figures) ３６a と ３６b のテーブルで例証される。 望ましい化身で、チェック Valid ２５５５３を通しての最も長いパスは３つの門であるべきである、そしてバイトチェック２５５５５（ − ｅ）は、チェックがアウトプットであるから、ただ１つの門を加えるだけであるであろう可能にする。 Check 正当なロジック２５５５３と図３５でのバイトチェックロジック２５５５５からのアウトプットは最上位ビットと６としてＯが最下位ビットであることを示す。
データはインプットデータがチェック選り抜きの２５５５５のインプットに基づかせた２５５５７が多重通信であるロジックを生み出す。 せいぜい、１バイトチェック２５５５５は正当なデータのためにアクティブになるべきだ。 代わりの化身が１バイト小切手が正当なデータのためにアクティブであることを確かめるためのこのデコーダに加えられるチェッカーの駒を含むかもしれない。 数字 ３６b のテーブルは Generate がデータインプット (Data Input) に基づいて出力する、そしてそれらに類似しているコードのために選り抜きのバイトチェックが図３２で例証したデータを記述する。
圧縮解除エンジン５５０の段階２５５０５がポインタを計算し始める瞬間、再び図３３に言及する（同じく呼ぶ「選択する」）圧縮されたデータのために１の６８ビットのパイプレジスタ２５５０３で掛け金で締められたヒストリーの窓から適切なバイトまで。 それぞれのデコーダのために、段階２がインデックス、スタートカウント、正当なビット、１データバイトと正当なデータバイトがかんだインデックスを受け取る。 図３３の化身で、段階２が８つのインデックス、８つのスタートカウント、８インデックス正当なビット、８データバイトと８データバイト正当なビット、ステージ１の中８つのデコーダのそれぞれからの（の・もの・人）を受け取るだろう。 ‖で‖１つ‖化身‖データ‖バイト‖ある‖通過する‖無しで‖なる‖使う‖によって‖段階‖２‖、‖で‖１つ‖化身‖、‖指数‖、‖使い始める‖数に入れる‖、‖指数‖効力がある‖ bit ‖、‖と‖データ‖バイト‖効力がある‖ bit ‖ことで‖それぞれの‖と‖デコーダ‖ある‖繰り返す‖ように‖予備‖選択する‖ロジック‖を見つけようと‖それぞれの‖と‖産出する‖バイト‖と‖段階‖２‖このように‖、‖で‖化身‖と‖図‖３３‖、‖予備‖選択する‖ロジック‖を見つけようと‖それぞれの‖と‖１日‖６‖産出する‖バイト‖受信する‖指数‖、‖使い始める‖数に入れる‖、‖指数‖効力がある‖ bit ‖と‖データ‖バイト‖効力がある‖ bit ‖ことで‖それぞれの‖と‖８‖デコーダ‖で‖段階‖１つ‖。
最小のロジックで、選り抜きの下準備が段階４２５５１３の１６アウトプットバイトのそれぞれのために計算されるかもしれない。 下準備は選択する１４４ビットのパイプレジスタ２５５０７で掛け金で締められる。 それぞれ２５５０７の中に掛け金で締められて選択する７ビットが（６４の入り口の窓のために）シングルでビット余剰物をコード化するということである。 これらのシグナルは掛け金で締められた２５５０７だ、そしてステージ３で次のユニット２５５０９によって使われた。 １つの化身で意志を選ぶ、もし８データバイトの１つが、もしこのアウトプットバイトでのデータが他の類似の１（つ・人）あるいはさらに多くの結果であるなら、このアウトプットバイトとあふれのために使われるなら、もしウインドウ値がこのアウトプットバイト、６４-７１のために使われるなら、０-６３の値を持つ（このデータで起こることを解読する。 ３番目の段階２５５０９は前の段階２５５０５からあふれのそれぞれを抑制する。 もし活動していないなら、７ビット選り抜きの（人たち・もの）は変化していなくて渡される。 もしアクティブであるなら、正しい段階２つのデコーダ２５５０５からの選り抜きの（人たち・もの）はこのアウトプットバイトで選り抜きの行の上に繰り返される。
圧縮解除の最終の段階、同じぐらい図３３で例証された段階４２５５１３、はヒストリーウインドウからデータを選ぶ、あるいはデータバイトは初めからアウトプットデータを構築するための段階を通り越した。 次の（人たち・もの）が解読するアセンブルされるバイトがそれから（そのために）ヒストリーウインドウに加えられるアウトプットは自転車に乗って行く。
１つの化身で最初のステージは、サイクルでインプットデータからコードを解読する時、アウトプットバイトの数を考慮するかもしれない。 例えば、図３３の化身の最大のアウトプットはサイクル毎に１６バイトだ。 もし最初のデコーダで解読されている最初のコードが１６アウトプットバイト以上の代理を務めるなら、最初の段階２５５０１は最初のコードがそれとしての自転車がとる同じぐらい多くが最初のコードによって代理を務められてアウトプットバイトのすべてを圧縮解除する最初のデコーダでロードされる状態にしておくかもしれない。 他のデコーダでロードされるかもしれない他のコードが、圧縮解除されたシンボルがトークンから生成されるために目的地としてサポートするべき利用可能なアウトプットデータバイトがあるまで、解読されない。
例えば、もし最初のデコーダでロードされた最初のコードが２４アウトプットバイトの代理を務めるなら、２４アウトプットバイトの１６が、最初のサイクルで、解読されるかもしれないそして２番目のサイクルでリング８のままでいる。 これは他のデコーダで他のコードのために８アウトプットバイトを残す。 さらに、最後の段階２５５１３は、適切なアウトプットデータ集合が、もし１以下の６バイトがどんな１つのサイクルのためにでも解読されることができるなら、起こることができるように、データ正当なビットを含むかもしれない。
図３７ − 最初の Calculating − は図３７が例証する発明の１つの化身に従って計算することに対して最初の２６０１２が発明の１つの化身によれば選んで、そしてあふれ出る論理を選んで、そしてあふれ出る。 １つの化身でこの論理は、図３３で例証されるように、圧縮解除エンジンの２番目のステージ２５５０５に含められる。 １つの化身に圧縮解除エンジン５５０にそれぞれのアウトプットバイトに２番目の段階に１つのロジック２６０１２がある。 例えば、図３３で例証された圧縮解除エンジンで、ステージ２、それぞれのアウトプットバイトでの（の・もの・人）にロジック２６０１２の１６があるだろう。 ロジック２６０１２が最初のステージから図３３で１の６８ビットのパイプレジスタ２５５０３で掛け金で締められた圧縮されたデータのためのヒストリーウインドウからの適切なバイトへのポインタの計算を始める。 化身で図３７に示されて、それぞれのステージ２でのロジック２６０１２がステージ１でそれぞれのデコーダーからインデックス２６００６とカウント２６０００のコピーを受け取る。 それぞれのステージ２でのロジック２６０１２が同じくそれぞれのデコーダーからデータバイト Valid ビット２６００２とインデックス Valid ビット ２６０O４ を受け取る。
最小のロジックで、予備の選り抜きの ２６０１O がアウトプットバイトのそれぞれのためにステージ２で計算されるかもしれない、そしてもしその時が図３３の １４l - ビットパイプレジスタ２５５０７で掛け金で締められたなら、下準備は２６０１０を選ぶ。 例えば、７ビットが（６４項目のウインドウ、そして８データバイトのために） sigle でコード化する選り抜きの下準備がそうであるかもしれないそれぞれが余剰物２６００８をかんだ。 ヒストリーウインドウそして／あるいはデータバイトの他の数の他の大きさを持っている化身が１ビットの異なった数を必要とするかもしれない、そして下準備のための異なったナンバリング案が選択する。 ２６０１０がそうである下準備が選択する、図３３に示されるように、ステージ３で次のユニット２５５０９によって２５５０７の中に掛け金で締められて、そして使う。 選択する、もしウインドウ値が、もし８データバイトの１つがこのアウトプットバイトのために使われるなら、このアウトプットバイトあるいは６４７１の値のために使われるなら、０-６３の値を持つかもしれない。 余剰物ビット２６００８は、もし他の類似の１（つ・人）あるいはさらに多くがこのデータで起こって解読する選り抜きの２６０１０が結果である下準備のデータであるなら、セットされるかもしれない。 この場合、インデックスは下準備を解決するための３がこのアウトプットバイトでもう１つのアウトプットバイトから選り抜きの（人たち・もの）まで選り抜きの適切な（人たち・もの）をまねることによって選ぶ段階で使われるかもしれない。
他の化身が３２の項目から４０９６の（あるいはより大きい）項目まで、例えば、種々の大きさのヒストリーウインドウを使うかもしれない。 ヒストリーウインドウの大きさはデザインのために利用可能な門の数、段階４と切望される圧縮比率のタイミングによって決定されるかもしれない。 もっと多くのヒストリーウインドウ項目が典型的にもっと良い圧縮比率をもたらすかもしれない。 サイズ変更、インデックスの大きさ、下準備と決勝戦が選ぶヒストリーウインドウが同じく変化するかもしれない（時・から・につれて・ように）。 例えば、２０４８の項目を持っているヒストリーウインドウが１１ビットのインデックスを必要とするだろう、１３ビットの（１１ビットインデックス、少しも、データバイトを示す１ビットが余剰物を示すために）選り抜きの下準備と１２ビットの決勝戦が（インデックスのための１１ビット、データバイトを示すための１ビット）を選ぶ。
１つの例でについて最初のデータバイトとデコーダが２番目の印を解読して、そして２番目のデータバイトへのポインタを出力してもよい１秒最初のデコーダーが最初のトークンと１ポインタアウトプットを解読するかもしれないかまれたあふれがセットされるかもしれない所を解読する。 ３番目のデコーダーが最初そして２番目のトークンから最初そして２番目のデータバイトを含めて圧縮されたストリングを表す３番目の印を解読するかもしれない。 これらのデータとしてバイトはヒストリーウインドウでまだ現在の（人たち・もの）が解読するビット２６００８が３番目のデコーダのアウトプットバイトでのデータが（それ・そこ）で事前のデコーダの１つまでに定義されることを示す予定になっている余剰物じゃない。 ３番目のデコーダのための２番目の段階の予備の選り抜きのアウトプットは３番目のステージで選り抜きで決勝戦の中に決意される。 最初が２番目のデコーダのアウトプットバイトを指し示すという状態で最初のデコーダのアウトプットバイトと第２に指さすという状態で、これで下準備が選ぶ例、２が３番目のトークンのために生成されるかもしれない。
図３７で、もし選り抜きの下準備が１データバイトであるなら、余剰物ビット２６００８はセットされないだろう、最上位ビット（ビット６）はつけられるだろう、そして０-２が使われるかもしれないビットがアウトプットバイトが８データバイトのいずれに関係するか明示する。 もし選り抜きの下準備が１ウインドウバイトである、余剰物ビット２６００８勝利がセットされないなら、最上位ビット（ビット６）はつけられないだろう、そして０-５が使われるかもしれないビットがアウトプットバイトが６４ウインドウバイトのいずれに関係するか明示する。
もし下準備についてこの下準備の前に選択する０-６が指定するかもしれないビットが選ぶ予備の（人たち・もの）がそれから選ぶビットが予定になっている余剰物がこの下準備のデータの場所を突き止めるために使われるなら、選択しろ。図３７で、Ｎはロジック２６０１２のためにアウトプットバイト数だ。 この例で、１６アウトプットバイトがある、それでＮはＯと１５の間に整数だ。 この例で、最初の段階に８つのデコーダがある。 １スタートカウント２６０００、１インデックス２６００６、と１データバイト正当なビットと１インデックス正当なビットがそれぞれのデコーダからのインプットだ。 デコーダのためのスタートカウントはステージ１でアウトプットバイトのインプット数にこのデコーダの上に生成されるアウトプットバイトの数を加えることによってすべての前のデコーダ（すなわち前のデコーダのためのスタートカウント）の上に生成されることを計算に入れている。 例えば、４つのデコーダ（０-３）がある、そしてデコーダＯが１アウトプットバイトを解読するためにコードでロードされるとすれば、デコーダ１が３アウトプットバイトを解読するために規約を積まれる、デコーダ２が４アウトプットバイトを解読するために規約を積まれる、そしてデコーダ３が２アウトプットバイトを解読するために規約を積まれる。 デコーダＯのためのスタートカウントは（０ ＋ １） ＝ １だ。 私がそうであるデコーダ（１ ＋ ３） ＝ ４のためのスタートカウント。 デコーダ２のためのスタートカウントは（４ ＋ ４） ＝ ８だ。 デコーダ３のためのスタートカウントは（８ ＋ ２） ＝ １０だ。
図３７のブロック２６００１がＮ（このロジック２６０１２のためのアウトプットバイト数）でデコーダのためにインプットスタートカウントを比較する。 ブロック２６００１がスタートカウント ＜ ＝ Ｎで最後のデコーダを選択する。 例えば、もし８つのスタートが０-７がそうであるデコーダ（１３６７１１１４１５２０）とＮ ＝ ９（これが第１０番目のアウトプットバイトである）から図３７で２６０００を数えるなら、デコーダ４（スタートカウント ＝ １１）が選択されるだろう。 これはそ（れ・こ）からこのアウトプットバイトが生成されるはずであるデコーダを選択するのに役立つ。
この例で、ブロック２６００１が３ビットのコード化されたデコーダ数とデコーダ数の８ビットの解読されたバージョンを出力する。 解読された版がアウトプットである８ - ビットは２６００３、２６００５、と２６００７を選ぶ、そしてそこでそれはデータバイト正当なビット２６００２を選んで、正当なビット ２６０O４ にインデックスを付けて、そしてデコーダがこのアウトプットバイトを生成することに関して２６００６にインデックスを付けるために使われる。
もし選択されたデコーダのためのデータバイト正当なビット２６００２がセットされ、そして選択されたデコーダのためのインデックス正当なビット２６００４が明確であるなら、２６０１０（最下位ビット）とビット６（最上位ビット）がセットされる下準備の０-２が選ぶビットが予備の（人たち・もの）が選ぶことを示す数が出力されるコード化された３ビットのデコーダは１データバイトだ。６４項目のヒストリーウインドウと前に記述された８つのデータバイト化身のために、データバイト選り抜きの値が８データバイトの１つを選ぶために距離６４-７１にあることを注意を払え。
もし選択されたデコーダのためのインデックス正当なビット２６００４がセットされ、そしてデコーダのためのデータバイト正当なビット２６００２が明確であるなら、事前の選り抜きの２６０１０のビット６（ MSB ）がきれいにされる。 ナンバーＮがインデックス２６００６から引かれるアウトプットバイト選択されたデコーダと調節されたインデックスが予備でビット０-５の上に産出される結果として生じることは２６０１０を選ぶ。 例を通って、８インプットバイトを持っている圧縮解除エンジン、８つのデコーダ（０-７）、が１６アウトプットバイト（０-１５）と６４項目のヒストリーウインドウ（０-６３）であると思え。 もしデコーダＯが４アウトプットバイトを生み出しているコードを解読することであるなら、アウトプットバイトＯのためのロジック２００１２が４アウトプットバイトの最初のバイトがデコーダＯの上にコードから生成されることに関して選り抜きの下準備を生み出すだろう。 もしデコーダＯからのインデックス２６００６が１６、そして次に１６ − Ｏ ＝ １６ − をであるなら。
これはアウトプットの最初のバイトコードからデコーダＯの上に解読されることはヒストリーウインドウで入り口１６から来るはずであることを意味する、入り口Ｏが最も最近の項目と項目であるところ（に・で）６３が最も古い項目だ。 アウトプットバイト１のためのロジック２６０１２が４アウトプットバイトの２番目のバイトがデコーダＯの上にコードから生成されることに関して選り抜きの下準備を生み出すだろう。 ２番目のバイトの、選り抜きの下準備は１６ − １ ＝ １５だ。 アウトプットの２番目のバイトコードからデコーダＯの上に解読されることはヒストリーウインドウで入り口１５から来るはずだ。 継続して、下準備は第３のために選択する、そして４番目のアウトプットバイトは、アウトプットバイト２と３でロジック２６０１２の上に生成されて、それぞれ１４と１３だ。
現在の圧縮解除サイクルでデータが生成されることに関してであることは選り抜きの存在が２６０の１２１つのロジックで生み出した下準備にとって可能だ、そしてそれでアウトプットバイト勝利のデータはまだヒストリーウインドウにない、この場合、インデックスからアウトプットバイト番号Ｎを引くことは否定的な結果を引き起こすだろう、そして余剰物ビット２６００８勝利が選り抜きで下準備にセットされる。 例えば、もしデコーダ３が３アウトプットバイトを生み出しているコードを解読しているなら、アウトプットバイト５は次の利用可能なアウトプットバイトだ、そしてデコーダ３のためのインデックスは私だ、その時アウトプットバイト５のためのロジック２６０１２が１ − Ｏ ＝ １、１下準備バイト６が生み出すであろうアウトプットのための２６０１２が１について選ぶロジック − について選り抜きの下準備 − １ − ２つの ＝ − １ − の１の ＝ Ｏと１下準備バイト７が生み出すであろうアウトプットのための２６０１２が選ぶロジック − を生み出すだろう。 − １の選り抜きの下準備がアウトプットバイトでのデータが現在の圧縮解除サイクルの最初のアウトプットバイトから来るはずであることを示す。 アウトプットバイト７のためにかまれた余剰物はこの選り抜きの下準備がまだヒストリーウインドウにないデータのためであることを示すことに定められるだろう。 ビット０-５の上の予備の選り抜きのアウトプットは下準備のいずれがこの下準備のデータへのポイントが選ぶ現在の圧縮解除サイクルで選択するか示すだろう。
ロジック２６０１２の１つの化身で、データバイト正当なビット２６００２とインデックス正当なビット２６００４は NOR であるそうするであろう、そして NOR のアウトプット下準備の５つと６つがもし両方の正当なビットがデコーダのためにＯであるなら選ぶビット、そして次に化身で６４のヒストリーウインドウ項目と８データバイトで、７１の上の値が有効じゃないという予備の選り抜きのノートが選ぶ５と６が（そのために）つけられるであろうビットにそうであるか、あるいはそうするであろう。 それで、この化身で５と６がつけた１ビットを持っているアウトプットバイトで選り抜きの下準備がデータがこの圧縮解除サイクルでアウトプットバイトで生成されていないことを示すために使われるかもしれない。 異なったヒストリーウインドウ大きさを持っている他の化身、アウトプットバイトのデータバイトの数、そして／あるいは数がデータが圧縮解除サイクルで１アウトプットバイトで生成されていないことを示すために他の無効な選り抜きの値を使うかもしれない。
３８ − Converting − が決定的で選ぶフィギュアが選択する
図３８が図３３のステージ３２５５０９のような圧縮解除エンジン５５０の３番目の段階の１つの化身を描写する。 ３番目のステージは下準備が前のステージからアウトプットバイトで２６０５０を選ぶことを調べる。 もし下準備の（図３７の２６００８）が選ぶかまれたあふれがセットされないなら、アウトプットバイト（図３７の事前の選り抜きの２６０１０のビット０-６）で選り抜きの７ - ビットは現在の圧縮解除サイクルで生成されてこれがこのアウトプットバイトでのデータがそうであることを示すもしかまれたあふれがセットされるなら変化していない次の段階に渡される。 選り抜きの下準備のデータは現在の圧縮解除サイクルでアウトプットバイトが選ぶ前のものの１つによって指し示されるだろう。 前のアウトプットバイトでの選り抜きの（人たち・もの）はこのアウトプットバイトで選り抜きの鉱山の上に repkicated される。 現在の（人たち・もの）が言及するべき選り抜きの（人たち・もの）のために解読する「事前である」が選択する余剰物がノーが選り抜きの（事前の選り抜きのＯ）がじゃないであろう最初のためにあるから万事整うまでかんだというメモ。 それで、変化していないステージ３を通して同じぐらい最終の予備の選り抜きのＯパスが下準備のそれぞれを解決するためのロジックが次で選ぶ最終の選り抜きのＯがインプットであるＯ．をＯ（下準備がＮ - １を通して１を選ぶ）を選ぶよう選ぶ。
私が予備で確認して（そのために）ロジックの中に入力される最終の選り抜きのＯと選り抜きの下準備が１を選ぶ。 もし私がそうである下準備のために上流になるまでかまれた余剰物が選り抜きでその時予備になったなら、私は最終の選り抜きの１として変化していなくて通過される。 もしかまれたあふれがセットされるなら、最終の選り抜きのＯは、最終の（人たち・もの）が選り抜きの１で選択する（時・から・につれて・ように）、通される。 決勝戦がＯを選ぶ、そして選り抜きの２が予備で確認して（そのために）ロジックの中に入力される私と下準備は２を選ぶ。 もし事前の選り抜きの２のためにかまれたあふれがセットされないなら、事前の選り抜きの２が最終の選り抜きの２として通される、もしかまれたあふれがセットされるなら、事前の選り抜きの２が決勝戦が選択するインプット（Ｏとｌ）のいずれが最終の選り抜きの２として出力されるはずであるか決定するために使われる。 一般に、この手順は予備のインプットが選択するＮの au のために従われる。 それで、確認するためのロジックへのインプット決勝戦が（そのために）選択する選り抜きのＮ - １が含む下準備がＮ - ２と事前の選り抜きのＮ - １を通してＯを選択する。 もし
余剰物ビットは事前の選り抜きのＮ - １の予定になっていない、それで事前の選り抜きのＮ - １が最終の選り抜きのＮ - １として変化していなくて通される。 もしかまれたあふれがセットされるなら、事前の選り抜きのＮ - １の内容は決勝戦が選択するインプットのいずれが価値として最終の選り抜きのＮ - １のために使われるはずであるか決定するために使われる。
３９ − Generatin − が生成されてアウトプットバイトを圧縮解除したフィギュアが選択する
図３９が図３３のステージ４２５５１３のような圧縮解除エンジン５５０の４番目の段階の１つの化身を描写する。 ４、決勝戦が選ぶステージで、図３８で描写されるように、３番目のステージから産出された２６０６８が２６０６４が最初のステージから通り越したヒストリーウインドウ２６０６２からのバイトあるいはデータバイトを選ぶことによってアウトプットバイト２６０７０をアセンブルするために使われる。 この化身で、それぞれのアウトプットバイト選択者２６０６６がヒストリーウインドウ２６０６２で６４バイト（Ｏ - ６３）の１つから選択してもよい、あるいは８バイトの１つから（６４-７１）データバイト２６０６４で、１つの化身でヒストリーウインドウ２６０６２とデータバイト２６０６４が結合されたヒストリーウインドウ２６０６０で結合されるかもしれない。 他の化身で、データバイトとヒストリーウインドウは別に保守されるかもしれない。 ２６０６８がそうである決勝戦が選択するヒストリーウインドウ２６０６２あるいは２６０６４がステージ１から通り越したデータバイトの中にインデックスを付ける。 次の（人たち・もの）が解読するアセンブルされる ２６O７０ がそうであるかもしれないバイトが（どんな前の圧縮解除サイクルでもからのアウトプットバイトの終わりに添えられる）アウトプットデータ流に送って、そしてヒストリーウインドウに挿入されるかもしれないアウトプットは自転車に乗って行く。 ステージ４が２００７０が適切なアウトプットデータ集合が、もし最大の数より少数であるなら、起こるようにバイト（この化身での１６）について解読されるはずであるアウトプットバイトのそれぞれのために同じく（見せられない）データ正当なビットを含むかもしれないサイクルを解読する。 １つの化身で１アウトプットバイトで選り抜きの決勝戦での無効なインデックス値がアウトプットバイトがこの圧縮解除サイクルで正当なデータを含んでいないことを示すためにかまれてデータをクリアするかもしれない。 正当じゃないアウトプットバイトがアウトプットデータに行かせられるか、あるいはヒストリーウインドウで書かれないかもしれない。
図４０ − 圧縮解除エンジンを通してのデータ流れ
図４０が圧縮解除エンジン５５０の１つの化身を通してデータ流れを例証する。 圧縮解除エンジン５５０は圧縮されたインプットストリーム１０００を受け取る。 １（つ・人）あるいはさらに多くが解読する １OOO がそれから圧縮解除される圧縮されたインプットストリーム（あるいは圧縮解除）は、圧縮解除されたアウトプットストリームをもたらして、自転車に乗って行く。
第一歩として圧縮解除サイクルの、１時から圧縮されたデータ流１０００からのＮのトークンまでの１００２が圧縮解除サイクルのために選ばれて、そして圧縮解除エンジン５５０で積み込まれるかもしれない、そしてそこでＮはステージ１でデコーダの最大の数だ。 トークンはデータ流１０００で名ばかりで初めから連続的に選ばれる。 １つの化身で、セクションが圧縮解除サイクルのインプットデータの役をするために圧縮されたデータ流 １OOO から抽出されるかもしれない、そしてトークンは引き抜かれたセクションから抽出されるかもしれない。 例えば、１つの化身で４バイト（３２ビット）のセクションがとられるかもしれない、そしてもう１つの化身で８バイト（６４ビット）のセクションがとられるかもしれない、１つの化身で９１０から９２０までのステップフィギュアで例証されるように、 ４３d が圧縮解除サイクルのためにＮのトークンに１を選ぶために従われるかもしれない。 In one embodiment a token may be selected from the input data stream １０００ for the decompression cycle if １) there is a decoder available (i.e., one or more decoders haven't been assigned a token to decode in the decompression cycle); and ２) the remaining bits in an input section of the compressed data comprise a complete token (after extracting one or more tokens from the input data, the remaining bits in the input data may not comprise a complete token), If any of the above conditions fails, then the decompression cycle continues, and the last token being examined (the one that failed one of the conditions) is the first token to be loaded in the next decompression cycle. なるべく、正確に方式を決められた印が今までにまったく拒絶されない；すなわち、どんな圧縮解除自転車勝利に関して考えられた最初のトークンとして圧縮解除サイクルに手渡されたトークンでもすべての条件付きの必要条件を満たす。 換言すれば、 １) デコーダが常に圧縮解除サイクルの始めにおいて利用可能であるだろう、そして ２) ビットでのインプットデータ大きさはビットで少なくとも最も大きい名ばかりの大きさと比べて同じぐらい大きい。
１Ｎに圧縮解除サイクルのためのトークンが最初のステップ１００２で選択される途端に、トークンが渡される I to N は解読することのために１１００６を演出する。 １つの化身でステップ １OO２ が段階の一部として行われるかもしれない１人圧縮解除エンジン５５０。 １つの化身で、１つの印が１つのデコーダに割り当てられる、そして１人の解読者が圧縮解除サイクルで１トークンを処理してもよい。 ステージ１がＮデコーダを含むかもしれない。 なるべく少なくともインプットデータであるかもしれないトークンの最大の数を受け入れるのに十分の解読者がいる。 例えば、もしインプットデータが３２ビットであり、そして最小名ばかりの大きさが９ビットであるなら、なるべく少なくとも３つのデコーダがある。 なるべく、デコーダの数はインプットデータでトークンの最大の数に等しい。 図３４が８つのデコーダで圧縮解除エンジン５５０の化身を例証する。 図４１-４２は３つのデコーダで圧縮解除エンジン５５０の化身を例証する。 図３５がデコーダの化身を例証する。 段階１１００６のデコーダーはＸアウトプットバイトのそれぞれが圧縮解除サイクルで生成されるためにそれぞれのデコーダからのそれぞれの１コピーが段階２１００８に渡されるという状態で、スタートカウント、インデックス、正当なフラグと正当なデータがフラグを付けるインデックス、の中にインプットの印を解読する。
１のＮにオリジナルのインプットデータバイトは段階１から結合されたヒストリーウインドウ１０１４までパスする。 １データバイトが、デコーダの上に解読されている印が圧縮されたデータを作った圧縮エンジンによってトークンで圧縮解除されたフォーマットにストアされた１バイトを表す場合に限り、正当だ。 この場合、圧縮解除されたバイトはデコーダのためにデータバイトでパスする、データバイトデコーダのための正当なビットがセットされる、そしてデコーダのためのインデックス正当なビットはきれいにされる。
２ １００８が段階１つの １OO６ からインプットに要して、そして予備で生成する段階が１で１０に１０が１つの圧縮解除サイクルで解読されるかもしれない１アウトプットバイトの最大の数であるアウトプットバイトを選ぶ。 段階２つの １OO８ が同じく下準備が選択する２がそれから通り越すそれぞれの事前の選り抜きの段階のためにかまれたあふれを、そして段階３１０１０に余剰物ビットを生成する。 段階３１０１０が下準備のそれぞれのためのビットが選ぶ余剰物を点検する。 もし下準備について上流になるまでかまれたあふれがセットされないなら、選り抜きの下準備の中味は、もし正当なビットがアウトプットバイト、あるいはデータバイトの１つに（そのために）セットされるインデックスが、もしデータバイト正当なビットがアウトプットバイトの予定になっているなら、結合されたヒストリーウインドウに段階から１１００６を渡したなら、ヒストリーウインドウ１０１４で項目の１つにポイントする。 下準備がセットされてビットが誰の余剰物であるか選択する同じぐらい最終の４ １０１２が修正無しで選ぶ段階に渡される。 もしかまれたあふれがセットされるなら、選り抜きの下準備の内容は下準備が選択する他のいずれがこの選り抜きの下準備が参照するデータを生成しているか決定するために調べられる。 選り抜きの正しい下準備の内容はその時選り抜きでこの下準備の上に繰り返される、そして選り抜きの修正された下準備は決勝戦としての４ １０１２が選ぶ段階に渡される。 １つの化身で、ビットセットがただ事前の下準備に知らせるだけであるかもしれない余剰物で選り抜きの下準備がこの圧縮解除サイクルで選択する。 例えば、もしアウトプットバイト３のために選り抜きの下準備のためにかまれたあふれがセットされるなら、選り抜きの下準備は通り過ぎて生成されてデータを参照するかもしれない１人下準備が２を通してＯを選んで、そして下準備にではなく完全に４を選ぶ（Ｎ - １）。 １つの化身段階で２と３が１つの段階の中に結合されるかもしれない。
それが結合されたヒストリーウインドウ１０１４からバイト項目を抽出するために段階３つの １O１O から受け取る決勝戦が選ぶ段階４ １０１２使用。 もしバイトあるいはデータバイトが過ぎ去ったいずれかのヒストリーウインドウへのポイントが１ １００６を演出したなら、決勝戦は選択する。 感覚がない（人たち・もの）はビットについて選り抜きの決勝戦でヒストリーウインドウの中の項目の数そしてデータバイトの数によって決意している。 例えば、６４バイトのヒストリーウインドウそして８データバイトが、決勝戦毎に７ビットが選り抜きであることを必要として、結合されたヒストリーウインドウで７２の可能な参加を合計する。 他のヒストリーウインドウ大きさそして／あるいはデータバイトの数が異なった最終の選り抜きの大きさを必要とするかもしれない。 段階４１０１２が結合されたヒストリーウインドウからデータを抽出して、そしてデータバイト１０１６１の間そしてＸの圧縮解除されたアウトプットのアウトプットを組み立てる。 段階４１０１２がこのこの圧縮解除サイクルでのアウトプットデータバイトのためにＸアウトプットデータバイトのそれぞれがもし１データバイトが産出されているなら示すべきデータ正当なフラグを使うかもしれない。 データ正当なフラグは、圧縮解除サイクルでアウトプットバイト（１０）の最大の量を減圧することは常に可能じゃないかもしれないから、必要だ。 アウトプットバイト１０１６がそれからアウトプットデータ流に添えられて、そしてヒストリーウインドウ１０１４に書き込まれるかもしれない。 １つの化身で、もしヒストリーウインドウがいっぱいであるなら、最も年がいった参加者は新しいアウトプットバイト１０１６のために席を空けるためにヒストリーウインドウから変えられるかもしれない、あるいは代わりにヒストリーウインドウはリングバッファにストアされるかもしれない、そして新しい項目は最も古い項目に上書きするかもしれない。 圧縮解除サイクルは、インプットストリーム１０００での印のすべてが減圧されるまで、繰り返されるかもしれない。
図４１ − ３２ビットインプットデータの acc ｔに３つのデコーダ段階
図４１が３つのデコーダで段階（の・もの・人）の化身を例証する。 化身は図３４で見せられた８つのデコーダで化身に類似している。 化身のために図４１に示されて、インプットデータ１１００は４バイト（３２ビット）を含むだろう。 圧縮されたデータは図３２で見せられたそれらに類似しているコードでコード化されるだろう、しかし１バイトを圧縮する８ビットのコードは与えられない。 それで、最小印あるいはコード、大きさが、トークンのために１の圧縮解除されたバイトを表す９ビットだ。 図４１のインプットデータ１１００はせいぜい３の完全なトークン（３２/９ ＝ ３、５一緒に残っているビット、）を含むかもしれない。 それで、この化身は圧縮解除サイクルのインプットデータから抽出されることができるトークンの最大の数を受け入れるために３つのデコーダを必要とする。
ビットがするこの化身： D２４ でデコーダＯ１１０２に通り越される。 デコーダＯ１１０２が名ばかりのデコーダＯ１１０２のビット大きさがビット EO を通り越す１１０４にそれからビット大きさを通り越すと決定するために DO において始まってトークンのフラグフィールドを調べる：デコーダ１１１０６への E２２ （２３ビット、最も小さい名ばかりの大きさ、９を差し引いたインプットデータ１１００、３２、でのビットの数）。 ２３ビットはビット D９ を含むかもしれない： D３１ がもしデコーダＯ１１０２であるなら９ビットの名ばかりのビット D１O を解読している： D３１ がもしデコーダＯ l１０２ であるなら１０ビットのトークンあるいはビット D１３ を解読している： D３１ がもしデコーダＯ１１０２であるなら１３ビットの印を解読している。 もしデコーダＯ１１０２が２５ビットの印を解読しているなら、残っている７ビットは完全なトークンを含んでいない、それでビットがＯ l１０２ （２５）が示すデコーダからこれで使われないことがそうであるデコーダ１１１０６までデコーダ１１１０６に手渡されたビットが解読するこれでの１１０４からの１ １１０６がサイクルと数を解読するデコーダにパスしない自転車に乗って行く。 もしデコーダ１１１０６が１１０４からビットを受け取るなら、デコーダ１１１０６がビットで最初のトークンの旗フィールドを調べる。 もしトークンの旗フィールドがトークンが２５ビットのトークンであることを示すなら、トークンは完全じゃない、そしてデコーダ１１１０６とデコーダ２つの １１１O がこの圧縮解除サイクルで使われない。 もしトークンの旗フィールドがこれが９、１０あるいは１３ビットのトークンであることを示すなら、トークンはデコーダ１１１０６に載せられる、そして使われたビットの合計の数は１１０８にそしてデコーダ２つの １１１O に通り越される。 １１０８がデコーダ２つの １１１O にビット FO ： F１３ （１４ビット、最も小さい名ばかりの大きさの２倍、９を差し引いたインプットデータ１１００、３２、でのビットの数）を渡す）。 １４ビットはビット E９ を含むかもしれない： E２２ がもしデコーダ１１１０６であるなら９ビットのトークン、ビット E１O を解読している： E２２ がもしデコーダ１１１０６であるなら９ビットのトークン、あるいはビット E１３ を解読している： E２２ がもしデコーダ１１１０６であるなら１３ビットの印を解読している。 デコーダ２１１１０がそれから FO において名ばかりの大きさを決定し始めてトークンの旗フィールドを調べてもよい。 デコーダ２つの １１１O がそれから名ばかりのビット大きさをトークンが完全であるかどうか決定するための（最初の２つのデコーダによってビットが使ったインプットから決定された）ビットの残っている数と比較するかもしれない。 もしトークンが完全であるなら、トークンはこの圧縮解除サイクルで解読することのためにデコーダ２つの １１１O に載せられる。 もしトークンが完全じゃないなら、デコーダ２１１１０がこの圧縮解除サイクルで使われない。
少数の荷積みのトークンの例が荷積み令状を例証するために与えられる。 もしインプットデータ１１００が１ビットＯで始まっている２５ビットのトークンを含むなら a) O) 、それから、ただ７ビットだけデコーダＯが積み込まれたあとのインプットデータ１１００で２５ビットのトークンを残される。 この場合、デコーダ１と２がこの圧縮解除サイクルでトークンで載せられない。 もしデコーダＯが９、 １O あるいは１３ビットの印、で積み込まれ、そしてインプットデータ１１００での残っているビットが、（不完全なトークンでフラグフィールドから決定されるように）、不完全な２５ビットのトークンであるなら、それでデコーダ１と２がこの圧縮解除サイクルで載せられない。 インプットデータ１１００でのトークンの他のコンビネーションがデコーダ１と２が裕福であるか、あるいはすべての３つのデコーダで圧縮解除サイクルのために含みが多いという結果になるかもしれない。
４インプットバイト、３つのデコーダと４アウトプットバイトで ４２a − 圧縮解除エンジンを計算しろ
数字 ４２a が４インプットバイト１１２０が３２ビット、ステージ１１１２２、と４アウトプットバイト１１３６での３つのデコーダを含むという状態で、圧縮解除エンジン５５０の化身を例証する。 この化身は図３２で描写されるそれらに類似しているコード（印）を解読して、１の圧縮されたバイトをコード化するために使われた８ビットのコードを除去することに対して適当だ。
数字 ４２a が（この化身、４アウトプットバイトで）アウトプットバイトのそれぞれを生成することに対してステージ２１１２６、ステージ３１１３０とステージ４１１３４、に平行したロジックがあることを説明する。
１（つ・人）あるいはそれ以上のトークンがインプットバイト１１２０から抽出されて、そして段階１１１２２でデコーダに載せられる。 印は解読者によって解読される、そしてスタートカウントインデックス、正当なインフォメーション１１２４が渡される正当なインデックスとデータが２ １１２６を演出する。 （示されない）データバイトインフォメーションが同じくデコーダのために作り出されて、そして段階４１１３４で使用のために完全に渡されるかもしれない。 それぞれのデコーダからのインフォメーション１１２４はそれぞれのアウトプットバイトで段階２つのロジックにコピーされる。 ２ １１２６が予備で生み出す段階が１１２４が段階１１１２２から過ぎ去ったインフォメーションから１１２８を選ぶ。
下準備が選択する段階２ １１２６パスが３ １１３０を演出する。 １１２８が段階２１１２６から通り越した下準備が選択する決勝戦が１１３２を選ぶ３ １１３０が生み出す段階。 見せられるように、１アウトプットバイトで１の１３０１つのステージ３ロジックの上に生成された最終の選り抜きの１１３２はすべての次のアウトプットバイトで段階３つのロジックに渡される。 これは余剰物ビットセットがアウトプットバイトでのデータが現在の圧縮解除サイクルで生成されていることを示すという状態で、事前の選り抜きの１１２８に正しいアウトプットバイトがこのアウトプットバイトで選り抜きの決勝戦として用いられるために選り抜きの決勝戦をまねることによって決意されることを許す。 １１３２がそうである決勝戦が選択する段階に４ １１３４を渡す。 （見せられない）ヒストリーウインドウあるいはデータバイトが段階１１１２２でデコーダから渡して、そして選択されたデータをコピーする決勝戦が１１３２を項目を選ぶよう選ぶ４ １１３４がインデックスインフォメーションを使うステージがバイト１１３６を産出した。 アウトプットバイト１１３６がそれからアウトプットデータに書き込まれる（見せられない）かもしれなくて、そして同じく最近のヒストリーウインドウ項目としてヒストリーウインドウに書き込まれるかもしれない。
ステージ１での使われたデータ Calculation ロジック１１２３が現在の圧縮解除で生成されているアウトプットバイトのカウントを保守して、そして同じく数の、解読されて、そして現在の圧縮解除サイクルで減圧されているトークンのカウントを保守するために使われるかもしれない。 このインフォメーションはインプットバイト１１２０引き抜くことの前に圧縮されたデータを変えることに対してステージ１で使われる後の圧縮解除サイクルで。 使われたデータ Calculation ロジック１１２３がさらに圧縮解除サイクルが数字 ４２b で記述した例によって説明される。
４２b − 例圧縮解除 − を計算しろ
数字 ４２b が、数字 ４２a で例証されるように、圧縮解除エンジン５５０の化身にインプットの例圧縮解除を例証するために使われる。 この例で、３トークンがインプットバイト１１２０から抽出された。
最初のトークン、２の圧縮されたバイトを表している alO - ビットのトークン、はデコーダＯに載せられる。 ２番目のトークン、３の圧縮されたバイトを表している alO - ビットのトークン、はデコーダ１に載せられる。 ３番目のトークン、１の圧縮解除されたバイトを表している a９ - ビットのトークン、はデコーダ２に載せられる。 デコーダＯが最初のトークンのためにインフォメーション（スタートカウント ＝ ２、インデックス ＝ iO 、正当なインデックス ＝ （本当の）１、（偽りの）データ正当な ＝ Ｏ）を生み出す。 スタートカウント（２）はデコーダ１に渡される。 デコーダｌが２番目のトークンのためにインフォメーション（スタートカウント ＝ ５、インデックス ＝ １１、正当なインデックス ＝ １、データ正当な ＝ Ｏ）を生成する。 スタートカウントはデコーダＯとデコーダ１（２ ＋ ３ ＝ ５）のためにアウトプットバイトカウントの金額だ。 スタートカウント（５）はデコーダ２に渡される。 デコーダ２が３番目のトークンのためにインフォメーション（スタートカウント ＝ ６、インデックス ＝ d２ 、インデックス正当な ＝ Ｏ、正当なデータ ＝ １）を生成する。 この例で（ｉ）から始まっているインデックスがヒストリーウインドウで項目へだ、そして（ｄ）から始まっているインデックスがデータバイトである。
段階２１１２６が４アウトプットバイトのために１１２４が予備で生成するべき１ １１２２が選ぶステージでデコーダから生み出したインフォメーションを使う。 ２アウトプットバイトがデコーダＯで名目上で初めから生み出されている。
アウトプットバイトＯのための段階２つのロジックはインフォメーション１１２４を調べて、そしてそれが最初のトークンで圧縮された最初のバイトで事前の選り抜きの１１２６を生成するはずであると決定する。 アウトプットバイトＯのための予備の選り抜きのアウトプットｉ１２８はインデックス ＝ iO だ。 アウトプットバイト１のための段階２つのロジックはインフォメーション１１２４を調べて、そしてそれが２番目のバイトでの選り抜きの１ １２６が最初のトークンで圧縮した下準備を生成するはずであると決定する。 アウトプットバイトＯのための予備の選り抜きのアウトプット１１２８はインデックス ＝ （ iO − １ − ）だ。 アウトプットバイト数はこのアウトプットバイトで実際のインデックス数を生み出すためにオリジナルのインデックスから引かれる。 それで、下準備が最初のトークンから作り出されるバイトが最初の２アウトプットバイト（そのために）生成されるアウトプットのために選択する。 アウトプットバイト２のための段階２つのロジックはインフォメーション１１２４を調べて、そしてそれが２番目のトークンで圧縮された最初のバイトで事前の選り抜きの１１２６を生成するはずであると決定する。 アウトプットバイト２のための予備の選り抜きのアウトプットｉ１２８はインデックス ＝ （ il − ２ − ）だ。 アウトプットバイト３のための段階２つのロジックはインフォメーション１１２４を調べて、そしてアウトプットバイト３のための予備の選り抜きのアウトプット１１２８が（ − ３を il しろ）インデックス ＝ である名ばかりの秒に圧縮された２番目のバイトでそれが事前の選り抜きの１１２６を生成するはずであると決定する。
この圧縮解除サイクルで、バイトが（今まで）そうであったアウトプットが予備で生み出したものであったすべては選択する。 しかしながら、２番目の印と３番目の印によって表されるデータの au によって表されるデータの若干がこの圧縮サイクルで圧縮解除されない。 これらのトークンの圧縮解除が１（つ・人）あるいはそれ以上の次の圧縮解除サイクルで完了されるだろう。
この例で、１１２８がそうである下準備が選択する１１３２が産出される３ １１３０と決勝戦が選ぶ段階によって選り抜きの下準備が決勝戦をまねて解決される１３４が、もし下準備が１アウトプットバイトで１ １２８を選ぶなら１余剰物ビットがその時（それに）なるようにする私がアウトプットバイトで選り抜きの決勝戦として用いられるために前のアウトプットバイトからアウトプットバイトまで選ぶ段階４を調べる。 もし事前の選り抜きの１１２８のためにかまれたあふれがセットされないなら、事前の選り抜きの１１２８は決勝戦としての１ １３４がアウトプットバイト（そのために）１１３２を選ぶ段階３を通ってパスする。
ステージ１で、圧縮解除サイクルに載せられたトークンのための大きさインフォメーションが調べられるかもしれないカウントとトークンがデータ計算論理１１２３年を使った。 もし１（つ・人）あるいはそれ以上の印が完全に減圧されたなら、トークンのビットの合計の数は次のインプットバイト次の圧縮解除サイクルのための１１２０を一列に並べるために圧縮されたデータを変えるために使われる。 部分的に処理されたトークンから生成されたアウトプットバイトの数の計算がいずれの部分的に処理されたトークンで表されるバイトが前の圧縮解除サイクルで圧縮解除される最初のバイトであるか決定するために次の圧縮解除サイクルで段階１１１２２で使われるかもしれない。 例で数字 ４２b に示された、最初の印は圧縮解除サイクルで完全に減圧された。 最初のトークンの大きさは１０ビットだ、それで圧縮されたデータはインプットバイト次のサイクルのための１１２０を一列に並べるために変えられた I O ビットであるかもしれない。 ２番目の印によって表される３バイトの２つが圧縮解除サイクルで圧縮解除された、それで２のバイトカウントが２番目のトークンの圧縮解除を続けるために次の圧縮解除サイクルで使われる。
次の圧縮解除自転車がスタートする時、トークンが新たに一列に並べられたインプットバイト１１２０から抽出されて、そしてサイクルのためにデコーダで積み込まれる。 この例で、内金の、含みが多い秒デコーダで私は最初の圧縮解除サイクルで、新しい圧縮解除サイクルでデコーダＯで載せられる。 ３番目のトークンは、最初の圧縮解除サイクルでデコーダ２に載せられて、新しい圧縮解除サイクルでデコーダ、ｉ、に載せられる。 もしインプットバイト l１２０ での次のトークンが完全なトークンであるなら、それは新しい圧縮解除サイクルのためにデコーダ２でロードされるだろう、新しい圧縮解除サイクルで、事前の選り抜きの１１２８が２番目のトークンで圧縮された３番目のバイトでアウトプットバイトＯのために生成されるだろう。
選り抜きの１１２８が（そのために）生成されるであろう下準備が３番目のトークンでデータバイトでバイトｉを出力した。 もしデコーダ２に減圧されている印があるなら、事前の選り抜きの１１２８がトークンで圧縮された最初のバイトでアウトプットバイト２のために生成されるだろう。 もしデコーダ２で減圧されている印が１の圧縮されたバイト以上を表すなら、事前の選り抜きの１１２８がトークンで圧縮された２番目のバイトでアウトプットバイト３のために生成されるだろう。
もしデコーダＯで解読されている印が圧縮解除されてＮを表すなら、バイトと圧縮解除エンジンはサイクルでせいぜいＭアウトプットバイトを圧縮解除することができる、それで印はＮ／Ｍ圧縮解除で完全に減圧されることができる
そこにＮ／Ｍが、もしＮがＭ．によって平等に可分じゃないなら、次の最も高い整数に集められるサイクル。 図 ４２b 、Ｍ ＝ ４で例証された化身で。 ２５ビットのトークンが、図３２で例証されるように、最高４０９６のシンボルを表すことができる、数字 ４２b で例証された化身で、完全に印を減圧するのに４００６/４ ＝ １０２４のサイクルを要するだろう。 もし１バイト圧縮解除されてＮを表しているトークンが圧縮解除サイクルで部分的に減圧されるなら、ある場合にはそれは減圧するのにＮ／Ｍ ＋ Ｉサイクルを要するかもしれない。 例えば、図３３で例証された圧縮解除エンジン５５０の化身で、もし４０９６のシンボルを表している２５ビットのトークンが初めにデコーダＯに載せられるなら８インプットバイト（６４ビット）、８つのデコーダと１６アウトプットバイト、がある、完全に印を減圧するのに４０９６１１６ ＝ ２５６のサイクルを要するだろう。 もしトークンが初めにデコーダ１に載せられ、そしてデコーダＯに載せられたトークンがトークンから私が勝つデコーダで１６以下のシンボル（例えば、８）、そして次に最初の８つのシンボルを表すなら、最初のサイクルで減圧されろ。 名ばかりの勝利は２番目のサイクルでデコーダＯに載せられる。 印によって表される残っている４０８８のシンボルは４０８８/１６ ＝ ２５６のサイクル（分数は切り上げられる）で減圧されるだろう。 それで、完全に印を減圧するのに２５７のサイクルを要するだろう。
１つの化身で、印が多数のサイクルの上に減圧されている（時・から・につれて・ように）、生成される残っているアウトプットシンボルは段階１でそして中古のデータ Calculation １１２３に他のデコーダに出力されるかもしれない。 これは他の解読者が、利用可能なアウトプットバイトがあるまで、印を解読するのを阻止するかもしれなくて、そして同じくインプットデータが、印が完全に減圧されるまで、変えられるのを阻止してもよい。 若干の化身で、アウトプットバイトの最大の数が印がセーブするべきこのサイクルで圧縮解除を完了しないであろうと合図するために解読者によって出力されるかもしれないより大きい番号がビットを出力した。 例えば、数字 ４２b で例証された化身で、５がデコーダＯ勝利で含みが多い印が現在の圧縮解除サイクルで完全に減圧されないことを示すためにデコーダＯによって産出されるかもしれない。 ５を産出することは３ビットをとる、他方４０９６を産出することは１２ビットをとるだろう。
~ ４３a を計算する ４３k − 平行した圧縮解除エンジンを記述しているフローチャート −
４３a - ４３k が圧縮解除エンジン５５０の化身で平行した圧縮解除処理の化身を記述しているフローチャートを例証すると思う。
４３a − 平行した圧縮解除エンジンのオペレーション − を計算しろ
数字 ４３a が平行した圧縮解除エンジン５５０の化身で圧縮解除処理の化身を例証するレベルが高いフローチャートだ。 平行した圧縮解除エンジン５５０が減圧されるために圧縮されたデータ９００を受け取る、そしてアウトプットがデータ９７０を圧縮解除した。 圧縮されたデータ９００は圧縮解除されたデータ９７０の圧縮された表示だ。 圧縮されたデータ ９０O が１（つ・人）あるいはそれ以上のトークンを含むかもしれない。 それぞれの圧縮されたデータ９００でのトークンが圧縮解除されたデータ９７０で１（つ・人）あるいはそれ以上の圧縮解除されたシンボルのコード化された記述であるかもしれない。 圧縮されたデータ９００がいろいろな圧縮方法のいずれによっても圧縮されたかもしれない、それは下記を含む、しかし並列、そして連続的な圧縮方法に制限された。 ４３b - ４３k がより大きい詳細で数字 ４１a のフローチャートを例証すると思う
４３b − 並列圧縮解除方法 − を計算しろ
数字 ４３b が数字 ４３a の平行した圧縮解除エンジン５５０の１つの化身で行われた並列圧縮解除方法の化身を例証する。 数字 ４３b が圧縮されたデータが調べられて、そしてそれぞれのサイクルで並列に圧縮解除された圧縮されたデータから一連のサイクルで、１（つ・人）あるいはそれ以上のトークンで圧縮解除されるかもしれないことを説明する。 ブロック９０６で、平行した圧縮解除エンジンは圧縮解除されたデータからトークンの複数性を調べるかもしれない。 トークンの複数性は並列に調べられるかもしれない、ｉ、ｅ．、が１トークン以上一度に調べられるかもしれない、もしすべての圧縮されたデータでの印が圧縮解除エンジンによって減圧されたとブロック９０６で決定されるなら、圧縮解除プロセスが止めるかもしれないブロック９３２で、もし調べられて、そして減圧されるトークンがあるとブロック９０６で決定されるなら、トークンは調べられる、そしてブロック９０６で印から抽出されたインフォメーションが９３４を妨げるために合格されるかもしれない。 １つの化身で、印から抽出されたインフォメーションは並列に９３４を妨げるために合格される。
ブロック９３４で、９０６がそうであるかもしれないブロックが複数性を生み出したものであった中に印から抽出されたインフォメーションは選択する、あるいはポインター、それは結合されたヒストリーウインドウでシンボルを示す。 結合されたヒストリーウインドウは圧縮解除エンジンの前のサイクルから圧縮解除されたシンボルを含むかもしれない。 前の圧縮解除サイクルから圧縮解除されたシンボルを含んでいる結合されたヒストリーウインドウの部分はヒストリーウインドウあるいはヒストリーテーブルであると述べられるかもしれない。 結合されたヒストリーウインドウは現在の圧縮解除サイクルから同じく圧縮解除されたシンボルを含むかもしれない。 現在の圧縮解除サイクルからの圧縮解除されたシンボルは「データバイトである」と述べられるかもしれない。 圧縮の間に、１（つ・人）あるいはそれ以上の圧縮解除されたシンボルが圧縮されていないかもしれなくて、そしてトークンで圧縮解除された形式にしまっておかれるかもしれない。 圧縮解除エンジンは圧縮解除されたシンボルを含んでいる印を認識して、印から圧縮解除されたシンボルを抽出して、そして結合されたヒストリーウインドウ変化していない人たちに圧縮解除されたシンボルを手渡す。 これ、現在のサイクルで減圧されている印から前の圧縮解除サイクルあるいは圧縮解除されたシンボルからあるいは圧縮解除されたシンボルまで９３４が向けるかもしれないブロックで生成されて選択する。
ブロック９５４、圧縮解除エンジン使用で１（つ・人）あるいはさらに多くを引き抜くためにブロック９３４で生成されて選択する
通り過ぎて指し示されてシンボルを圧縮解除するヒストリーウインドウから選択して、そして圧縮解除されたアウトプットデータ９７０に引き抜かれた圧縮解除されたシンボルをコピーする。 圧縮解除されたシンボルはアウトプットデータ９７０について終わりまで付加されるかもしれない。 アウトプットデータはアウトプットデータ流であるかもしれない、すなわち、データは、それが減圧される、あるいは代わりにアウトプットデータ９７０が、全部の圧縮されたデータ９００が圧縮解除されるまで、リリースされない圧縮解除されたアウトプットファイルであるかもしれない（時・から・につれて・ように）、求めることプロセスに外に流れ転送されるかもしれない。
ブロック９６０で、現在の圧縮解除サイクルからの圧縮解除されたシンボルはヒストリーウインドウに書き込まれるかもしれない。 もしヒストリーウインドウがこの圧縮解除から圧縮解除されたシンボルを書いて自転車が前ヒストリーウインドウから動かされるかもしれない前の圧縮解除からの楽しみ、最も古いシンボルの１（つ・人）あるいはさらに多くであるなら
自転車に乗って行け。 最も古いシンボルはヒストリーウインドウから変えられるかもしれない、あるいは代わりにヒストリーウインドウは「リングバッファ」であるかもしれない、そして最も古いシンボルは新しいシンボルによって上書きされるかもしれない。 ４３c - ４３k がより大きい詳細で数字 ４３b のフローチャートを例証すると思う
並列にトークンの複数性を ４３c - 調べている人物
数字 ４３c が並列に圧縮されたデータ９００からトークンの複数性を調べることのための方法の１つの化身を例証している数字 ４３b のブロック９０６の上に膨張する。 ブロック９０８で、現在の圧縮解除サイクルで並列に減圧される１（つ・人）あるいはそれ以上のトークンが圧縮されたデータ９００から抽出されるかもしれない。 トークンはそうであるかもしれない
データを圧縮した圧縮エンジンによって圧縮されて最初のトークンにおいて始まって、そして圧縮エンジンによって圧縮された最後のトークンにおいて終わって圧縮されたデータから抽出された。 トークンの最大の数が１つのサイクルで減圧されるかもしれない。 例として、図３３で例証された圧縮解除ロジックは圧縮解除サイクルで８トークンの最大限を受け入れる。 なるべく、圧縮解除エンジンがトークンの最大の数以下しか圧縮解除サイクルで受け入れないかもしれない。 それで、図３３で例証された圧縮解除ロジックは、ただ１だけのトークンが減圧させるために残される時、例えば、最後の圧縮解除サイクルでの圧縮解除サイクルで名ばかりの（の・もの・人）の最小限を受け入れる。 もしトークンが圧縮解除サイクルで圧縮され得るより多くの圧縮解除されたアウトプットシンボルを表すなら、それは完全に印を減圧するための１つの圧縮解除サイクルよりさらに撮影に勝つ。
トークンでのインフォメーションがトークンを引き抜くことにおいて使われるかもしれない。 例えば、トークンの大きさと印によって減圧されるシンボルの数はトークンを引き抜くことにおいて使われるかもしれない、１つの化身で、トークン：否の大きさはトークンのビットで大きさだ。 数字 ４３d がより大きい詳細でトークンを引き抜くプロセスの１つの化身を例証する。
ブロック９２４で、この圧縮解除サイクルのために引き抜かれたトークンは並列に調べられるかもしれない、そしてトークンについてのインフォメーションが圧縮解除サイクルで使用のために生成されるかもしれない。 名ばかりの組み込みから抽出されるかもしれない、しかし「このトークンが表す圧縮解除されたシンボル、データバイトインフォメーションとインデックスインフォメーションの数を表しているカウント」に制限されないインフォメーションの例。 データバイトインフォメーションが、もしこのトークンが圧縮エンジンによって圧縮されなかったシンボルを表すなら、圧縮解除されたシンボルを含むかもしれない。 データバイトインフォメーションが同じく１データバイトこのトークンのためのデータバイトが正当であることを示している正当な板石を含むかもしれない。 １つの化身で、データバイト正当な板石が、もしデータバイトが正当じゃないなら、もしデータバイトが正当で、そして定められていない（Ｏ）なら、つけられる１ビット（１）であるかもしれない。 インデックスインフォメーションがインデックスを含むかもしれない。 １つの化身でインデックスは圧縮解除されたデータ９７０におけるポジションからの差し引き計算がこのトークンでのこれでのインフォメーションからポジションにコピーされる最初の前に常気圧の中に戻されて、そして圧縮解除されたデータ９７０にストアされた圧縮解除されたシンボルまで減圧される最初の圧縮解除されたシンボルを受け取ると申し立てるかもしれない。 １つの化身で１（つ・人）あるいはそれ以上の圧縮解除サイクルからの前に減圧されたシンボルはヒストリーウインドウにあるかもしれない、そしてインデックスのための最大の値はヒストリーウインドウの長さと関係があるかもしれない。 １つの化身でインデックス正当なフラグは、もしインデックスが正当じゃないなら、もしインデックスが正当で、そして定められていない（Ｏ）なら、つけられる１ビット（１）であるかもしれない。 数字 ４３e がより大きい詳細で並列にトークンからインフォメーションを生成するプロセスの１つの化身を例証する。
−−並列に減圧される１（つ・人）あるいはそれ以上のトークンを引き抜いて−− ４３d を計算しろ
数字 ４３d が数字 ４３c のブロック９０８の上に広がって、そして圧縮されたデータ９００から並列に減圧される１（つ・人）あるいはそれ以上のトークンを抽出することのための方法の１つの化身を例証する。 数字 ４３d のブロック９１０で、方法は減圧される圧縮されたデータ９００にもしもっと多くのトークンが残っているならもっと多くのインプットデータ、ｉ、ｅ．、があるかどうか決定する。 もしそうであるなら、それからブロック９１２で方法はデコーダが利用可能であるかどうか決定する。 もしデコーダが利用可能じゃないなら、すべてのデコーダは減圧されるトークンを割り当てられた、そして圧縮解除サイクルは数字 ４３c のブロック９２４で継続する。
もしデコーダがブロック９１２で利用可能であると決定されるなら、方法は１４から９２０までののブロック９に進むかもしれない。 ブロック１４から９２０までの９が流れで使うべき９００が圧縮されたデータのどれだけを解読するか決定するかもしれなくて、そして同じく流れで使うべきデコーダーが何（個・人）を解読するか決定してもよい。 １つの化身で、９１４から９２０までのブロックが段階で行われるかもしれない１人図３３で例証された圧縮解除エンジン。 ブロック９１４で、方法は圧縮されたデータを表しているトークンの大きさを決定するかもしれない、ブロック９１５で、方法はそれが完全なトークンであるかどうか見るためにトークンを調べるかもしれない。 もしトークンが圧縮されたデータのセクション、例えば３２ビットのセクション、からデコーダに載せられているなら、少なくとも１のトークンを引き抜いた後で、インプットデータでの残っているビットは全部のトークンを含まないかもしれない。 ブロック９１４で決定されたトークンの大きさは完全なトークンがあるかどうか決定するためにインプットデータで左にビットの数と比較してであるかもしれない。 もしトークンが完全じゃないなら、方法は数字 ４３c の９２４をふさぎ続けるかもしれない。
ブロック９１６で、方法はこのトークンの圧縮解除によって生成されるであろうシンボルの数を決定するかもしれない。 ブロック９１８で、方法は圧縮されたデータ９００での次の圧縮されたトークンをこのプロセスによって強いられるためにアクセス可能であるようにするためにトークンの大きさによってインプットデータを動かすかもしれない。 インプットデータがシフトすることは、圧縮解除自転車が何（個・人）の印がこのサイクルで完全に減圧されるであろうか決定するまで、起こらないかもしれない、そしてデータはこのサイクルですべての完全に減圧された印のビットで完全な大きさによって変えられるかもしれない。 移行することは次の圧縮解除サイクルのインプットデータを準備するかもしれない。 ブロック９２０で、方法は最大のアウトプット幅より１つの圧縮解除サイクルのために（調べられている現在のトークンを計算に入れて）この圧縮解除サイクルで減圧されるためにシンボルが勝つさらに多くが印によって減圧されるかどうか決定するかもしれない。 すでにトークンの圧縮解除によって引き起こされる圧縮解除されたシンボルの数がこの圧縮解除サイクルのために引き抜いた１つの自転車マイナスで圧縮解除されるかもしれない圧縮解除されたシンボルの最大番号は調べられて現在トークンから減圧されるかもしれないシンボルの最大の数をもたらす。 もしアウトプット幅が立ち向かわれるか、あるいは超えられたなら、圧縮解除サイクルはデコーダに割り当てられて調べられて現在のトークン無しで継続するかもしれない。 化身、トークンが部分的に感覚がなくて１最大限それに保険を掛けるための圧縮解除サイクルで圧縮されるかもしれない（の・もの・人）でシンボルがサイクルで減圧される。 最初の名ばかりの完全に減圧されたのではなく勝利は次の圧縮解除サイクルで引き抜かれる最初のトークンだ。 もしアウトプット幅がブロック９２０で決定されるように立ち向かわれてか、あるいは超えられなかったなら、方法はブロック９１Ｏに戻る、そしてブロック９１０-９２０が、（これ・それ）以上のデータがないまで、繰り返されるか、あるいはアウトプット幅がそうになるまで会われるか、あるいは超えられるかもしれない。
ブロック９２２で、もしブロック９１０に決定されるように（これ・それ）以上のインプットデータがない、しかし１（つ・人）あるいはそれ以上の印が解読することのためにデコーダに割り当てられたなら、それから圧縮解除サイクルは数字 ４３c のブロック９２４で続く。 これは、圧縮されたデータ９００に（これ・それ）以上のトークンがない時、ケースをカバーする、しかしトークンが（それ・そこ）でデコーダに割り当てられた１（つ・人）あるいはさらに多くが９１０-９２０を妨げる。 ブロック９２２で、もしブロック９１０に決定されるように（これ・それ）以上のインプットデータがない、そして印がデコーダに割り当てられなかったなら、圧縮されたデータの圧縮解除は完全だ、そして圧縮解除が止まる。
−−並列にカウントとインデックスあるいはデータバイトインフォメーションを生成して−− ４３e を計算しろ
４３e が数字 ４３c のブロック９２４の上に広がって、そして並列にトークンの複数性からインフォメーションを生成するプロセスの１つの化身を例証すると思う、１（つ・人）あるいはそれ以上のそれに類似しているロジックが図３４で例証したデコーダによって現在の圧縮解除サイクルで並列に解読されている印から抽出されるかもしれないいくつかの項目が例証される。
数字 ４３e のブロック９２６で、カウントがそれぞれの印が現在の圧縮解除サイクルで解読されることに関して生成されるかもしれない。 トークンのためのカウントはトークンの圧縮解除が引き起こすであろう圧縮解除されたシンボルの数を表すかもしれない。 トークンのためのカウントは１（人・つ）と印によって表されることができるシンボルの最大の数の間にあるかもしれない。 例えば、図３２のテーブルで、２５ビットのトークンが最高４０９６の圧縮解除されたシンボルを表すことができる。 圧縮解除されたシンボルを表しているトークンのためのカウントは１であるだろう。
ブロック９２８で、インデックスインフォメーションがそれぞれの印が現在の圧縮解除サイクルで解読されることに関して生成されるかもしれない。 インデックスインフォメーションはそれぞれの印が減圧されることに関して１（つ・人）あるいはそれ以上の減圧されている印とインデックス正当なフラグのためにインデックスを含むかもしれない。 正当なインデックスが、もしトークンが１（つ・人）あるいはそれ以上の圧縮されたシンボルを表すなら、トークンのために生成されるかもしれない。 １つの化身で、インデックスは最初の圧縮解除されたシンボルの圧縮解除されたデータ９７０における目的地ポジションからのシンボルでの距離がこのトークンから前に常気圧の中に戻されて、そして圧縮解除されたデータ９７０にストアされた最初の圧縮解除されたシンボルまで減圧されると申し立てるかもしれない。
１つの化身で、１（つ・人）あるいはそれ以上の圧縮解除サイクルからの前に減圧されたシンボルはヒストリーウインドウにしまっておかれるかもしれない、そしてインデックスはヒストリーウインドウで前に圧縮解除されたシンボルに対する差し引き計算であるかもしれない、不変のインデックス正当なフラグが少しもそうであるかもしれない１つの化身で（１）もしインデックスが正当で、そして定められていないなら、 (O) もしインデックスが正当じゃないなら、インデックス正当なフラグは（そのために）インデックスが生成される印の予定になっているかもしれない。 １つの化身で、インデックス正当なフラグは、もしインデックスが正当じゃないなら、もしインデックスが正当で、そして定められていない（Ｏ）なら、つけられる１ビット（１）であるかもしれない。
ブロック９３０で、データバイトインフォメーションが１（つ・人）あるいはそれ以上の印が現在の圧縮解除サイクルで解読されることに関して生成されるかもしれない。 トークンのためのデータバイトインフォメーションが、もしこのトークンが圧縮エンジンによって圧縮されなかったシンボルを表すなら、圧縮解除されたシンボル（データバイト）を含むかもしれない。 データバイトインフォメーションが同じく１データバイトこのトークンのためのデータバイトが正当であることを示している正当な板石を含むかもしれない。 １つの化身でデータバイト正当な板石が、もしデータバイトが正当じゃないなら、もしデータバイトが正当で、そして定められていない（Ｏ）なら、つけられる１ビット（１）であるかもしれない。
複数性を ４３f - 生み出している Fi ｅについて結合されたヒストリーウインドウでシンボルに選択する
４３f が数字 ４３b のブロック９３４の上に拡大して、そしての並列に複数性を生み出すプロセスの１つの化身を例証するフィギュアが結合されたヒストリーウインドウでシンボルに選択する。 ブロック９３６で、下準備が選択する１（つ・人）あるいはさらに多くがこの圧縮解除サイクルのためにブロック９２４で生成されたインフォメーションを使って生成されるかもしれない。 選り抜きの下準備がシンボルのそれぞれが現在の圧縮解除サイクルで常気圧の中に戻されることに関して生成されるかもしれない。 １つの化身で選り抜きの下準備がひとつのビットあふれを持っている調節されたインデックスだ。 インデックスは前の圧縮解除されたシンボルでシンボルのストリングのスタートしているインデックスから差し引き計算によって調節される。 選り抜きの下準備の大きさはヒストリーウインドウの結合された大きさ、（デコーダの数によって決定された）データバイトの最大の数、によって決定される、そして余剰物はかんだ。 例えば、６４項目のヒストリーウインドウ、そして８データバイト、そしてひとつの余剰物ビットのために、選り抜きの下準備が８ビットの最小限であるかもしれない。 この例で、選択する、もしウインドウ値が、もし８データバイトの１つがこのアウトプットシンボルのために使われるなら、このアウトプットシンボルあるいは６４-７１の値のために使われるなら、０-６３の値を持つかもしれない。 かまれた余剰物アウトプットはこの圧縮解除サイクルで解読されて、もしアウトプットシンボルのデータが他のトークンの１（つ・人）あるいはさらに多くによって生み出されているなら、セットされるかもしれない。 ビットの他のコンビネーションが後の段階にデータがこの圧縮解除サイクルでこのアウトプットシンボルのために生成されていないと合図するために使われるかもしれない。
１つの例でについて最初のデータバイトとデコーダが２番目の印を解読して、そして２番目のデータバイトへのポインタを出力してもよい１秒最初のデコーダーが最初のトークンと１ポインタアウトプットを解読するかもしれないかまれたあふれがセットされるかもしれない所を解読する。 ３番目のデコーダーがバイトが初めから生み出した最初そして２番目のデータと２番目のトークンを含めて圧縮されたストリングを表す３番目の印を解読するかもしれない。 これらのデータとしてバイトが、ヒストリーウインドウでまだ、現在の（人たち・もの）が解読するビット２６００８が３番目のデコーダのアウトプットバイトでのデータが（それ・そこ）で事前のデコーダの１つまでに定義されることを示す予定になっている余剰物じゃない。 最初が２番目のデコーダのデータバイトを指し示すという状態で最初のデコーダのデータバイトと第２を指し示すという状態で、３番目の段階で、この例、最終の２で選り抜きの決勝戦が選ぶデコーダが解決される第３の間の２番目の段階の予備の選り抜きのアウトプットは３番目のトークンのために生成されるかもしれない。
図４３ − 下準備を生成することは選択する
数字 ４３g が数字 ４３f のブロック９３６の上に広がって、そして結合されたヒストリーウインドウでの下準備を生成するプロセスの化身がシンボルに選択する（の・もの・人）を例証する。 選り抜きの下準備がアウトプットシンボルのそれぞれが現在の圧縮解除サイクルでブロック９２４で生成されたインフォメーションを使うことに関して生成されるかもしれない。 ９３８、下準備が（それ・そこ）でシンボルに選択するブロックでヒストリーウインドウは例えば生成されるかもしれない、もしヒストリーウインドウが６４インデックスを付けられた項目０-６３を含むなら、Ｏが最も最近の項目、アウトプットシンボルのためにヒストリーウインドウで８番目に最も最近の項目からコピーされる theh であるという状態で、７のインデックスが生成されるだろう。
９４０、下準備が（それ・そこ）でデータバイトに選択するブロックで結合されたヒストリーウインドウは生成されるかもしれない。 例えば、ヒストリーウインドウは８データバイトがステージ１で８つのデコーダから渡した０-６３と結合されたヒストリーウインドウが含むインデックスを付けられた６４の項目を含む、８データバイトはデータバイト６４-７１としてインデックスを付けられるかもしれない。 アウトプットシンボルが３番目のデータバイトからコピーされるために、６６のインデックスが生成されるだろう。 ９４２、下準備がシンボルに選ぶブロックで現在の圧縮解除サイクルで生成されることは生成されるかもしれない。 換言すれば、アウトプットシンボルを圧縮解除するように要求されたシンボルはまだヒストリーウインドウにいない、しかしこの圧縮解除サイクルで事前のアウトプットシンボルによって生み出されている。 下準備が選択するこれらのために、予備の（人たち・もの）が選択するビットが指し示すことに定められるあふれが決意される必要がある。 選り抜きで下準備のために生み出されたインデックスはこの圧縮解除サイクルで事前のアウトプットシンボルのいずれがこのアウトプットシンボルによって必要とされるシンボルを含んでいるか示す。 例えば、もし４つのアウトプットシンボル０-３があるなら、そしてこれは、それから、もしかまれたあふれがセットされるなら、３番目のアウトプットシンボル（アウトプットシンボル２）である、インデックスはシンボルが生成されているこのアウトプットのデータがシンボルＯあるいは１を出力したことを示すかもしれない、しかしアウトプットシンボル３の上に。
数字 ４３h − 最終の Generating − は選択する
数字 ４３h が数字 ４３f のブロック９４４の上に広がって、そして結合されたヒストリーウインドウでの決勝戦を生成するプロセスの化身がシンボルに選択する（の・もの・人）を例証する。 選り抜きの決勝戦がアウトプットシンボルのそれぞれが現在の圧縮解除サイクルでブロック９２４で生成されたインフォメーションを使うことに関して生成されるかもしれない、ブロック９４６で、下準備のそれぞれのビットが選ぶ余剰物は調べられるかもしれない。 もしかまれたあふれがセットされないなら、予備の（人たち・もの）が選択する：否が、最終の（人たち・もの）がアウトプットシンボルのために選択するように、 unmodified を通してパスする。 もしかまれたあふれがセットされるなら、選り抜きの下準備は解決される。 このシンボルのために選り抜きの下準備と決勝戦が選択する１つの化身でそれぞれの事前のアウトプットシンボルがそれぞれのアウトプットシンボルのためにインプットとして予備の選り抜きの解像度ロジックに渡される。 もしアウトプットシンボルのために選り抜きの下準備が解決される必要があるなら、アウトプットシンボルのために選り抜きの下準備でパスするインデックスはこのアウトプットシンボルのデータを含んでいるであろう事前のアウトプットシンボルの数を生み出すために使われる。 事前のアウトプットシンボルのために選り抜きの決勝戦は、最終の（人たち・もの）がこのアウトプットシンボルのために選択する（時・から・につれて・ように）、完全にその時パスする。 例えば、もし４つのアウトプットシンボルがあるなら、０-３と余剰物ビットが３番目のアウトプットシンボル（アウトプットシンボル２）の予定になっている、それから、もしインデックスがこのアウトプットシンボルのデータが生成されていることを示すなら、私、決勝戦がアウトプットシンボルから選ぶアウトプットシンボルの上に私はまねられて、そしてアウトプットシンボル２のために選り抜きの決勝戦として通過される。 アウトプットシンボルｉ：否から選り抜きの決勝戦はヒストリーウインドウであるいは１データバイトに１シンボルいずれかにインデックスだ。
流れの中の事前のデコーダを解読する。 最初が２番目のデコーダのデータバイトを指し示すという状態で最初のデコーダのデータバイトと第２を指し示すという状態で、３番目の段階で、この例、最終の２で選り抜きの決勝戦が選ぶデコーダが解決される第３の間の２番目の段階の予備の選り抜きのアウトプットは３番目のトークンのために生成されるかもしれない。
数字 ４３g − 下準備を生成することは選択する
数字 ４３g が数字 ４３f のブロック９３６の上に広がって、そして結合されたヒストリーウインドウでの下準備を生成するプロセスの化身がシンボルに選択する（の・もの・人）を例証する。 選り抜きの下準備がアウトプットシンボルのそれぞれが現在の圧縮解除サイクルでブロック９２４で生成されたインフォメーションを使うことに関して生成されるかもしれない。 ９３８、下準備が（それ・そこ）でシンボルに選択するブロックでヒストリーウインドウは例えば生成されるかもしれない、もしヒストリーウインドウが６４インデックスを付けられた項目０-６３を含むなら、Ｏが最も最近の項目、アウトプットシンボルのためにヒストリーウインドウで８番目に最も最近の項目からコピーされる theh であるという状態で、７のインデックスが生成されるだろう。
９４０、下準備が（それ・そこ）でデータバイトに選択するブロックで結合されたヒストリーウインドウは生成されるかもしれない。 例えば、ヒストリーウインドウは８データバイトがステージ１で８つのデコーダから渡した０-６３と結合されたヒストリーウインドウが含むインデックスを付けられた６４の項目を含む、８データバイトはデータバイト６４-７１としてインデックスを付けられるかもしれない。 アウトプットシンボルが３番目のデータバイトからコピーされるために、６６のインデックスが生成されるだろう。 ９４２、下準備がシンボルに選ぶブロックで現在の圧縮解除サイクルで生成されることは生成されるかもしれない。 換言すれば、アウトプットシンボルを圧縮解除するように要求されたシンボルはまだヒストリーウインドウにいない、しかしこの圧縮解除サイクルで事前のアウトプットシンボルによって生み出されている。 下準備が選択するこれらのために、予備の（人たち・もの）が選択するビットが指し示すことに定められるあふれが決意される必要がある。 選り抜きで下準備のために生み出されたインデックスはこの圧縮解除サイクルで事前のアウトプットシンボルのいずれがこのアウトプットシンボルによって必要とされるシンボルを含んでいるか示す。 例えば、もし４つのアウトプットシンボル０-３があるなら、そしてこれは、それから、もしかまれたあふれがセットされるなら、３番目のアウトプットシンボル（アウトプットシンボル２）である、インデックスはシンボルが生成されているこのアウトプットのデータがシンボルＯあるいは１を出力したことを示すかもしれない、しかしアウトプットシンボル３の上に。
数字 ４３h − 最終の Generating − は選択する
数字 ４３h が数字 ４３f のブロック９４４の上に広がって、そして結合されたヒストリーウインドウでの決勝戦を生成するプロセスの化身がシンボルに選択する（の・もの・人）を例証する。 選り抜きの決勝戦がアウトプットシンボルのそれぞれが現在の圧縮解除サイクルでブロック９２４で生成されたインフォメーションを使うことに関して生成されるかもしれない、ブロック９４６で、下準備のそれぞれのビットが選ぶ余剰物は調べられるかもしれない。 もしかまれたあふれがセットされないなら、予備の（人たち・もの）が選択する：否が、最終の（人たち・もの）がアウトプットシンボルのために選択するように、 unmodified を通してパスする。 もしかまれたあふれがセットされるなら、選り抜きの下準備は解決される。 このシンボルのために選り抜きの下準備と決勝戦が選択する１つの化身でそれぞれの事前のアウトプットシンボルがそれぞれのアウトプットシンボルのためにインプットとして予備の選り抜きの解像度ロジックに渡される。 もしアウトプットシンボルのために選り抜きの下準備が解決される必要があるなら、アウトプットシンボルのために選り抜きの下準備でパスするインデックスはこのアウトプットシンボルのデータを含んでいるであろう事前のアウトプットシンボルの数を生み出すために使われる。 事前のアウトプットシンボルのために選り抜きの決勝戦は、最終の（人たち・もの）がこのアウトプットシンボルのために選択する（時・から・につれて・ように）、完全にその時パスする。 例えば、もし４つのアウトプットシンボルがあるなら、０-３と余剰物ビットが３番目のアウトプットシンボル（アウトプットシンボル２）の予定になっている、それから、もしインデックスがこのアウトプットシンボルのデータが生成されていることを示すなら、私、決勝戦がアウトプットシンボルから選ぶアウトプットシンボルの上に私はまねられて、そしてアウトプットシンボル２のために選り抜きの決勝戦として通過される。 アウトプットシンボルｉ：否から選り抜きの決勝戦はヒストリーウインドウであるいは１データバイトに１シンボルいずれかにインデックスだ。
４３i − アウトプットデータ数字 ４３i に圧縮解除されたシンボルを書き込むことは数字 ４３b のブロック９５４の上に広がって、そしてアウトプットバイトで圧縮解除されたアウトプットデータにシンボルを書き込むプロセスの１つの化身を例証する。 ブロック９５６で、決勝戦はデータバイトデコーダからパスするバイトが使われるかもしれないデータが場所を突き止めるインデックスを付けることを選ぶ、そして原稿が圧縮解除されたデータバイト決勝戦がヒストリーウインドウでシンボルにインデックスを付けて選ぶ、ブロック９５８での、アウトプットデータの中に圧縮解除されたシンボルの場所を突き止めて、そしてシンボルをアウトプットデータにコピーするために使われるかもしれない。 アウトプットシンボルは圧縮解除エンジンでアウトプットシンボルのオーダーでアウトプットデータで組み立てられるかもしれない。 examlple のために、もし生成されている１６アウトプットシンボル（０-１５）があるなら、Ｏが最初であるかもしれない圧縮解除サイクル、アウトプットシンボルでアウトプットデータとアウトプットシンボル１５は最後の（人・もの）であるかもしれない。 圧縮解除サイクルがアウトプットシンボルのフルのセットを作らないかもしれない。 例えば、前の例で１６最大限アウトプットシンボルで、圧縮解除サイクルがただ９つだけのアウトプットシンボル（アウトプットシンボル０-８）を生み出すかもしれない。 なるべく、すべての圧縮解除サイクルがアウトプットシンボルの最大の数に可能な限り近く減圧させる。 若干の圧縮解除サイクル、例えば、最後の圧縮解除サイクル、がアウトプットシンボルの最大の数を生み出さないかもしれない。
ヒストリーウインドウへの図４３フィートの Written シンボル
数字 ４３j が数字 ４３b のブロック９６０の上に広がって、そしてヒストリーウインドウに圧縮解除サイクルで圧縮解除されたシンボルを書き込むプロセスの１つの化身を例証する。 １つの化身でヒストリーの窓はバッファとして組み立てられるかもしれない、そして最も古いデータは最も新しいデータのために席を空けるために外にシフトされるかもしれない。
もう１つの化身でヒストリーの窓はリングバッファとして組み立てられるかもしれない、そして最も古いデータは最も新しいデータによって上書きされるかもしれない。 ９６２と９６４が想定するブロック最も古いデータはヒストリーウインドウから変えられるかもしれない、そしてヒストリーウインドウのためにリングバッファを使っている化身で必要じゃないかもしれない。 ブロック９６２で、ヒストリーウインドウは調べられる、そしてもしこのサイクルに減圧された十分なシンボルのための空領域がないなら、ブロック９６４でヒストリーウインドウの中のデータは新しいデータのために席を空けるためにシフトされる。 １つの化身でヒストリーウインドウはブロック９６６で新しいデータのために席を空けるためにすべての圧縮解除サイクルの後にシフトされるかもしれない、新たに圧縮解除されたシンボルはヒストリーウインドウの終わりに書き込まれる。 シンボルが記述された方法をシンボルを書き込むために使ってヒストリーウインドウに書き込まれるかもしれない１つの化身でアウトプットデータはブロックのために数字 ４３i の９５６と９５８を記述した。
結合して ４３k − 圧縮解除プロセス − を計算する図 ４３b ４３c と ４３d
数字 ４３k で、図 (Figures) ４３a - ４３j からのブロックのいく人かがさらに圧縮解除サイクルの１つの化身を例証するために結合される。 ９ １０-９２２がからのブロックが ４３d を計算して、そして数字 ４３c のブロック９０８の上に広がる、インプットから並列に減圧される１（つ・人）あるいはそれ以上のトークンを抽出することのための方法の１つの化身を例証することは、数字 ４３d のために記述されるように、データを圧縮した。 ブロック９２４で、この圧縮解除サイクルのために引き抜かれたトークンは並列に調べられるかもしれない、そしてトークンについてのインフォメーションが圧縮解除サイクルで使用のために生成されるかもしれない。 インフォメーションが印から抽出した ４３c と、ブロック９３４での、 ４３e が使われるかもしれない図 (Figures) が複数性を生み出す９２４が記述されるブロックのオペレーションは選択する、あるいはポインター、それは結合されたヒストリーウインドウでシンボルを示す。 ブロック９３４のオペレーションは図 ４３b 、 ４３f 、 ４３g と ４３h で記述される。 ブロック９５４、圧縮解除エンジン使用で１（つ・人）あるいはさらに多くが示されたシンボルを圧縮解除した引き抜くべきブロック９３４で生成されて選択するヒストリーウインドウから選択して、そして圧縮解除されたアウトプットデータに引き抜かれた圧縮解除されたシンボルをコピーする。 オペレーションについて
流れの中の事前のデコーダを解読する。 最初が２番目のデコーダのデータバイトを指し示すという状態で最初のデコーダのデータバイトと第２を指し示すという状態で、３番目の段階で、この例、最終の２で選り抜きの決勝戦が選ぶデコーダが解決される第３の間の２番目の段階の予備の選り抜きのアウトプットは３番目のトークンのために生成されるかもしれない。
図４３ − 下準備を生成することは選択する
数字 ４３g が数字 ４３f のブロック９３６の上に広がって、そして結合されたヒストリーウインドウでの下準備を生成するプロセスの化身がシンボルに選択する（の・もの・人）を例証する。 選り抜きの下準備がアウトプットシンボルのそれぞれが現在の圧縮解除サイクルでブロック９２４で生成されたインフォメーションを使うことに関して生成されるかもしれない。 ９３８、下準備が（それ・そこ）でシンボルに選択するブロックでヒストリーウインドウは例えば生成されるかもしれない、もしヒストリーウインドウが、Ｏが最も最近の項目であるという状態で、６４インデックスを付けられた項目０-６３を含むなら、アウトプットシンボルがヒストリーウインドウで８番目に最も最近の項目からコピーされるために、７のインデックスが生成されるだろう。
９４０、下準備が（それ・そこ）でデータバイトに選択するブロックで結合されたヒストリーウインドウは生成されるかもしれない。 例えば、ヒストリーウインドウは８データバイトがステージ１で８つのデコーダから渡した０-６３と結合されたヒストリーウインドウが含むインデックスを付けられた６４の項目を含む、８データバイトはデータバイト６４-７１としてインデックスを付けられるかもしれない。 アウトプットシンボルが３番目のデータバイトからコピーされるために、６６のインデックスが生成されるだろう。 ９４２、下準備がシンボルに選ぶブロックで現在の圧縮解除サイクルで生成されることは生成されるかもしれない。 換言すれば、アウトプットシンボルを圧縮解除するように要求されたシンボルはまだヒストリーウインドウにいない、しかしこの圧縮解除サイクルで事前のアウトプットシンボルによって生み出されている。 下準備が選択するこれらのために、予備の（人たち・もの）が選択するビットが指し示すことに定められるあふれが決意される必要がある。 選り抜きで下準備のために生み出されたインデックスはこの圧縮解除サイクルで事前のアウトプットシンボルのいずれがこのアウトプットシンボルによって必要とされるシンボルを含んでいるか示す。 例えば、もし４つのアウトプットシンボル０-３があるなら、そしてこれは、それから、もしかまれたあふれがセットされるなら、３番目のアウトプットシンボル（アウトプットシンボル２）である、インデックスはシンボルが生成されているこのアウトプットのデータがシンボルＯあるいは１を出力したことを示すかもしれない、しかしアウトプットシンボル３の上に。
数字 ４３h − 最終の Generating − は選択する
数字 ４３h が数字 ４３f のブロック９４４の上に広がって、そして結合されたヒストリーウインドウでの決勝戦を生成するプロセスの化身がシンボルに選択する（の・もの・人）を例証する。 選り抜きの決勝戦がアウトプットシンボルのそれぞれが現在の圧縮解除サイクルでブロック９２４で生成されたインフォメーションを使うことに関して生成されるかもしれない、ブロック９４６で、下準備のそれぞれのビットが選ぶ余剰物は調べられるかもしれない。 もしかまれたあふれがセットされないなら、予備の（人たち・もの）が選択する：否が、最終の（人たち・もの）がアウトプットシンボルのために選択するように、 unmodified を通してパスする。 もしかまれたあふれがセットされるなら、選り抜きの下準備は解決される。 このシンボルのために選り抜きの下準備と決勝戦が選択する１つの化身でそれぞれの事前のアウトプットシンボルがそれぞれのアウトプットシンボルのためにインプットとして予備の選り抜きの解像度ロジックに渡される。 もしアウトプットシンボルのために選り抜きの下準備が解決される必要があるなら、アウトプットシンボルのために選り抜きの下準備でパスするインデックスはこのアウトプットシンボルのデータを含んでいるであろう事前のアウトプットシンボルの数を生み出すために使われる。 事前のアウトプットシンボルのために選り抜きの決勝戦は、最終の（人たち・もの）がこのアウトプットシンボルのために選択する（時・から・につれて・ように）、完全にその時パスする。 例えば、もし４つのアウトプットシンボルがあるなら、０-３と余剰物ビットが３番目のアウトプットシンボル（アウトプットシンボル２）の予定になっている、それから、もしインデックスがこのアウトプットシンボルのデータが生成されていることを示すなら、私、決勝戦がアウトプットシンボルから選ぶアウトプットシンボルの上に私はまねられて、そしてアウトプットシンボル２のために選り抜きの決勝戦として通過される。 アウトプットシンボルｉ：否から選り抜きの決勝戦はヒストリーウインドウであるいは１データバイトに１シンボルいずれかにインデックスだ。
数字 ４３i − アウトプットデータ数字 ４３i に圧縮解除されたシンボルを書き込むことは数字 ４３b のブロック９５４の上に広がって、そしてアウトプットバイトで圧縮解除されたアウトプットデータにシンボルを書き込むプロセスの１つの化身を例証する。 ブロック９５６で、決勝戦はデータバイトデコーダからパスするバイトが使われるかもしれないデータが場所を突き止めるインデックスを付けることを選ぶ、そして原稿が圧縮解除されたデータバイト決勝戦がヒストリーウインドウでシンボルにインデックスを付けて選ぶ、ブロック９５８での、アウトプットデータの中に圧縮解除されたシンボルの場所を突き止めて、そしてシンボルをアウトプットデータにコピーするために使われるかもしれない。 アウトプットシンボルは圧縮解除エンジンでアウトプットシンボルのオーダーでアウトプットデータで組み立てられるかもしれない。 例えば、もし生成されている１６アウトプットシンボル（０-１５）があるなら、Ｏが最初であるかもしれない圧縮解除サイクル、アウトプットシンボルでアウトプットデータとアウトプットシンボル１５は最後の（人・もの）であるかもしれない。 圧縮解除サイクルがアウトプットシンボルのフルのセットを作らないかもしれない。 例えば、前の例で１６最大限アウトプットシンボルで、圧縮解除サイクルがただ９つだけのアウトプットシンボル（アウトプットシンボル０-８）を生み出すかもしれない。 なるべく、すべての圧縮解除サイクルがアウトプットシンボルの最大の数に可能な限り近く減圧させる。 若干の圧縮解除サイクル、例えば、最後の圧縮解除サイクル、がアウトプットシンボルの最大の数を生み出さないかもしれない。
図４３の − ヒストリーウインドウにシンボルを書き込む
数字 ４３j が数字 ４３b のブロック９６０の上に広がって、そしてヒストリーウインドウに圧縮解除サイクルで圧縮解除されたシンボルを書き込むプロセスの１つの化身を例証する。 １つの化身でヒストリーの窓はバッファとして組み立てられるかもしれない、そして最も古いデータは最も新しいデータのために席を空けるために外にシフトされるかもしれない。
もう１つの化身でヒストリーの窓はリングバッファとして組み立てられるかもしれない、そして最も古いデータは最も新しいデータによって上書きされるかもしれない。 ９６２と９６４が想定するブロック最も古いデータはヒストリーウインドウから変えられるかもしれない、そしてヒストリーウインドウのためにリングバッファを使っている化身で必要じゃないかもしれない。 ブロック９６２で、ヒストリーウインドウは調べられる、そしてもしこのサイクルに減圧された十分なシンボルのための空領域がないなら、ブロック９６４でヒストリーウインドウの中のデータは新しいデータのために席を空けるためにシフトされる。 １つの化身でヒストリーウインドウはブロック９６６で新しいデータのために席を空けるためにすべての圧縮解除サイクルの後にシフトされるかもしれない、新たに圧縮解除されたシンボルはヒストリーウインドウの終わりに書き込まれる。 シンボルが記述された方法をシンボルを書き込むために使ってヒストリーウインドウに書き込まれるかもしれない１つの化身でアウトプットデータはブロックのために数字 ４３i の９５６と９５８を記述した。
結合して ４３k − 圧縮解除プロセス − を計算する図 ４３b ４３c と ４３d
数字 ４３k で、図 (Figures) ４３a - ４３j からのブロックのいく人かがさらに圧縮解除サイクルの１つの化身を例証するために結合される。 ９ １０-９２２がからのブロックが ４３d を計算して、そして数字 ４３c のブロック９０８の上に広がる、インプットから並列に減圧される１（つ・人）あるいはそれ以上のトークンを抽出することのための方法の１つの化身を例証することは、数字 ４３d のために記述されるように、データを圧縮した。 ブロック９２４で、この圧縮解除サイクルのために引き抜かれたトークンは並列に調べられるかもしれない、そしてトークンについてのインフォメーションが圧縮解除サイクルで使用のために生成されるかもしれない。 インフォメーションが印から抽出した ４３c と、ブロック９３４での、 ４３e が使われるかもしれない図 (Figures) が複数性を生み出す９２４が記述されるブロックのオペレーションは選択する、あるいはポインター、それは結合されたヒストリーウインドウでシンボルを示す。 ブロック９３４のオペレーションは図 ４３b 、 ４３f 、 ４３g と ４３h で記述される。 ブロック９５４、圧縮解除エンジン使用で１（つ・人）あるいはさらに多くが示されたシンボルを圧縮解除した引き抜くべきブロック９３４で生成されて選択するヒストリーウインドウから選択して、そして圧縮解除されたアウトプットデータに引き抜かれた圧縮解除されたシンボルをコピーする。 ブロック９５４のオペレーションは図 (Figures) ４３b と ４３i で記述される。 ブロック９６０で、現在の圧縮解除サイクルからの圧縮解除されたシンボルはヒストリーウインドウに書き込まれるかもしれない。 ブロック９５４のオペレーションは図 (Figures) ４３b と ４３j で記述される。
ヒストリーウインドウに圧縮解除されたシンボルを書き込んだ後で、オペレーションが時間がとれてもっと多くのインプットデータがあるかどうか決定するためにブロック ９１O に戻るかもしれない。 もしそれ以上何もないならブロック９１０で決定されるように利用可能なデータを入力して、そしてそこ（に・で）正当でノーである解読するブロック９２２で、それからオペレーションが完了することを同じぐらい決心した。 さもなければ、次の平行した圧縮解除自転車は始まる。
圧縮解除タイミング
再び図３３に言及して、それぞれのこのデザインでの段階が０.２５のμ技術と低い力水準缶詰デザインライブラリで１ ３３ MHz を成し遂げるために時間を測定された。 代わりの化身がより高い時計率あるいはより少ない段階を成し遂げるために注文製のデータ - 道あるいは注文製のセルを使うかもしれない。 段階１２５５０１は水準セルデザイン、 Stages ２２５５０５でタイミングのために最も重大であるかもしれない、３ ２５５０９と４ ２５５１３は同じくタイミングのために重要であるかもしれない。 段階４に論理が遅らせる若干の追加の電力を供給することがあるかもしれない、そしてそれは段階４２５５１３のタイミング限界のために問題じゃないかもしれない。
拡大縮小可能な圧縮／圧縮解除
IMC １４０は同じく拡大縮小可能な圧縮／圧縮解除を含む、その中に平行した圧縮／圧縮解除スライスの１（つ・人）あるいはさらに多くはデータ流の望ましいプライオリティに頼っている異なったデータ流のために選択的に適用され得る。同時発生
IMC １４０はエージェントを求めることについての複数性からあるいはリクエストがエージェントを求めているシングルから入力する多数のデータから多数のデータのリクエストのアロケーションによって同じくオペレーションの同時発生を許す。 平均して、圧縮と圧縮解除ユニットである時、２５：１が使われる、ブロックが現在の発明の使用無しでより早く（それより）引退させられる求められたデータ。 多数のデータ要請が同時に発生するソースから待ち行列に入れられる時、差し迫っている取引は公知の事実システムでより少ない潜伏期で完了することができる。 ブロック大きさが（それに）なるインプットと差し迫っている同時のデータのリクエストの数が増加する（時・から・につれて・ように）、現在の発明は潜伏期と増やされた効果的なバンド幅の縮小のためにますます魅力的になる。
現在の発明のシステムと方法が特定の書式がここに、しかしそれどころか明らかにしたそれが制限されるように意図されない望ましい化身に関連して記述されたけれども、相応に付加されたクレームによって定義されるように発明の精神と機会の中で含まれ得るように、このような選択肢、修正と同等物、をカバーすることことが意図される。

Claims (26)

  1. データのパラレル圧縮を行う方法であって、該方法は、
    非圧縮データを受け取ることであって、該非圧縮データは、複数の記号を含み、該複数の記号は、最初の記号と最後の記号と一つ以上の中間記号とを含む、ことと、
    該複数の記号をヒストリーテーブル内の複数のエントリとパラレルな態様で比較することであって、該複数の記号を比較するステップは、該非圧縮データの連続する記号の連続するグループに対してパラレルに実行され、該ヒストリーテーブルは、複数のエントリを含み、各エントリは、少なくとも一つの記号に関連付けられており、該パラレルな態様での比較は、１つのグループ内の該複数の記号のそれぞれを該ヒストリーテーブルの各エントリと同時に比較することを含み、該比較が比較結果を生成する、ことと、
    該比較結果に基づいて該複数の記号のそれぞれに対する一致情報を決定することであって、該一致情報を決定することは、該最初の記号または該最後の記号のいずれかの記号との一致を含まない連続する一致が、該グループの一つ以上の連続する中間記号のうちの一つ以上に対して生じたか否かを決定することを含む、ことと、
    該決定された一致情報に基づいて、該ヒストリーテーブルを更新することと、
    該一致情報に応答して圧縮データを出力することと
    を含み、
    該決定するステップは、該グループの最後の記号と該関連付けられた少なくとも一つの記号との間で一致が生じたか否かを決定することを含み、該グループの該最後の記号と該関連付けられた少なくとも一つの記号との間で一致が生じたことが決定された場合には、該圧縮データを出力するステップは、より長い連続した一致が存在するか否かを決定するために、該複数の記号を該グループの直後のグループと比較するステップを実行するために遅延される、方法。
  2. 該連続する中間記号のうちの一つ以上と、該最初の記号または該最後の記号のうちの少なくとも一方とに関与する連続した一致が生じたか否かを決定することをさらに含む、請求項１に記載の方法。
  3. 前記圧縮データを出力することは、前記一つ以上の連続する中間記号に関与する一致に対して圧縮データを出力することを含む、請求項１または２に記載の方法。
  4. 前記一致情報を決定することは、一つ以上の個々の連続する中間記号に関与する連続する一致が生じたか否かを決定することを含み、該一つ以上の個々の連続する中間記号は、該一つ以上の個々の連続する中間記号の前または後のいずれかの記号との一致に関与しない、請求項１から３のいずれかに記載の方法。
  5. 複数の中間記号をさらに含む、請求項１から４のいずれかに記載の方法。
  6. 前記一つ以上の中間記号は、複数の中間記号を含み、
    前記一致情報を決定することは、複数の異なる連続する中間記号の一致が該複数の中間記号の間で生じたか否かを決定することを含み、該複数の異なる中間記号の一致のそれぞれは、該複数の中間記号の間で起こり、該複数の異なる連続する中間記号の一致のそれぞれは、該最初の記号または該最後の記号のうちのいずれにも関与せず、
    前記圧縮データを出力することは、複数の異なる連続する中間記号の一致のそれぞれに対して圧縮データを出力することを含む、請求項１から５のいずれかに記載の方法。
  7. 少なくとも一つの連続する一致が一つ以上の連続する個々の中間記号について起き、該一つ以上の連続する個々の中間記号が該個々の連続する中間記号の前または後のいずれかの記号との一致に関与しない場合には、
    該一つ以上の個々の連続する中間記号に関与する該一つ以上の最も大きな重なりのない連続する一致を選択する、請求項１から６のいずれかに記載の方法。
  8. 前記一致情報を決定することは、
    少なくとも一つの連続する一致が前記複数の中間記号のうちの一つ以上の連続する個々の中間記号について起き、該一つ以上の連続する個々の中間記号が該個々の連続する中間記号の前または後のいずれかの記号との一致に関与しない場合には、
    該一つ以上の個々の連続する中間記号に関与する該一つ以上の最も大きな重なりのない連続する一致を選択することを含む、請求項１から７のいずれかに記載の方法。
  9. 前記一致情報を決定することは、
    少なくとも一つの連続する一致が前記複数の中間記号のうちの二つ以上の連続する個々の中間記号について起き、該二つ以上の連続する個々の中間記号が該個々の連続する中間記号の前または後のいずれかの記号との一致に関与しない場合には、
    該一つ以上の個々の連続する中間記号に関与する該一つ以上の最も大きな重なりのない連続する一致を選択することを含み、
    前記圧縮データを出力することは、該二つ以上の個々の連続する中間記号に関与する該選択された一致のそれぞれに対して圧縮データを出力することを含む、請求項１から８のいずれかに記載の方法。
  10. 前記圧縮データを出力することは、連続する一致のためのカウント値とエントリポインタとを出力することを含み、
    該エントリポインタは、該連続する一致を生成した該ヒストリテーブルのエントリを指し、該カウント値は、該連続する一致において一致する記号の数を示す、請求項１から９のいずれかに記載の方法。
  11. 前記カウント値を出力することは、前記カウント値を示す値をエンコードすることを含み、より多い頻度で起きるカウントが、より少ない頻度で起きるカウントより少ないビットでエンコードされる、請求項１から１０のいずれかに記載の方法。
  12. 前記圧縮データを出力することは、前記ヒストリーテーブルのどのエントリとも一致しない不一致記号に対して、該不一致記号を出力することをさらに含む、請求項１から１１のいずれかに記載の方法。
  13. 前記受け取るステップ、維持するステップ、比較するステップ、更なるデータが利用可能でなくなるまで１回以上決定するステップを繰り返すことと、
    更なるデータが利用可能でない場合には、前記ヒストリーテーブル内の残っている一致について圧縮データを出力することと
    をさらに含む、請求項１から１２のいずれかに記載の方法。
  14. 前記一致情報を決定することは、前記複数の記号と前記ヒストリーテーブル内の複数のエントリとの一致を決定することを含む、請求項１から１３のいずれかに記載の方法。
  15. 以前の複数の記号が前記ヒストリーテーブル内の複数のエントリと比較された場合に生じる先の一致のカウントを含むカウント情報を維持することをさらに含み、
    前記一致情報を決定することは、該カウント情報と前記比較結果とに基づいて、前記複数の記号のそれぞれに対して該一致情報を決定するように動作する、請求項１から１４のいずれかに記載の方法。
  16. 前記カウント情報は、前記ヒストリーテーブルの各エントリに対して維持される先の一致の現在のカウントを含む、請求項１５に記載の方法。
  17. 前記方法は、前記ヒストリーテーブルの各エントリに対してカウントフラグをさらに維持し、
    前記決定することは、前記現在のカウントと、該カウントフラグと、前記比較結果とに基づいて、前記複数の記号のそれぞれに対して一致情報を決定する、請求項１６に記載の方法。
  18. 前記一致情報を決定することは、連続する一致が前記複数の記号のうちの一つに一致しないことを前記比較結果が示した場合には、前記カウントと前記カウントフラグとをリセットすることを含む、請求項１７に記載の方法。
  19. 全てのエントリに対する前記カウントおよび前記カウントフラグは、連続する一致において一致しない複数の記号の数に基づいてリセットされる、請求項１７に記載の方法。
  20. 前記一致情報を決定することは、前記比較結果に従って前記現在のカウントを更新することを含む、請求項１６に記載の方法。
  21. 前記一致情報を決定することは、
    前記現在のカウントと前記比較結果とに基づいて連続する一致を決定することと、
    該連続する一致が一致を停止したか否かを決定することと、
    該連続する一致が一致を停止した場合には、該比較結果に従って該現在のカウントを更新することと
    を含み、
    前記圧縮データを出力することは、該連続する一致に対応する圧縮データを出力することを含む、請求項１６に記載の方法。
  22. 前記連続する一致に対応する圧縮データを出力することは、カウント値とエントリポインタとを出力することを含み、
    該エントリポインタは、該連続する一致を生成した前記ヒストリーテーブル内のエントリを指し、該カウント値は、該連続する一致において一致した記号の数を示す、請求項２１に記載の方法。
  23. 前記複数の記号は、少なくとも４つの記号を含む、請求項１から２２のいずれかに記載の方法。
  24. 前記複数の記号は、少なくとも８つの記号を含む、請求項１から２２のいずれかに記載の方法。
  25. 前記方法は、前記ヒストリーテーブル内の各エントリに対してカウントフラグをさらに維持し、
    前記決定することは、前記現在のカウントと、該カウントフラグと、前記比較結果とに基づいて、前記複数の記号のそれぞれに対して一致情報を決定し、
    該一致情報を決定することと該一致情報に応答して圧縮信号を出力することとは、
    前記複数の記号と前記ヒストリーテーブル内の各エントリとのゼロ以上の一致を決定することと、
    各エントリに対して比較結果を調査することと、
    該ヒストリーテーブル内のどのエントリとも一致しない不一致記号に対して、該不一致記号を出力することと、
    いずれかのエントリが一致を停止した場合には、全てのエントリに対して、該現在のカウントと、該カウントフラグと、該比較結果とを調査することと、
    該現在のカウントと該比較結果とに基づいて前記連続する一致を決定することと、
    該連続する一致が一致を停止したか否かを決定することと、
    該連続する一致が一致を停止した場合には、カウント値とエントリポインタとを出力することであって、該エントリポインタは、該連続する一致を生成した該ヒストリーテーブル内のエントリを指し、該カウント値は、該連続する一致において一致した記号の数を示す、ことと、
    該比較結果に従って該現在のカウントを更新することと
    を含み、
    前記方法は、更なるデータが利用可能でない場合において、該現在のカウントがゼロでない場合には、該ヒストリーテーブル内の残っている一致に対してカウント値とエントリポインタとを出力することをさらに含む、請求項１から２４のいずれかに記載の方法。
  26. データのパラレル圧縮を行うシステムであって、該システムは、
    非圧縮データを受け取るための入力であって、該非圧縮データは、複数の記号を含み、該複数の記号は、最初の記号と最後の記号と一つ以上の中間記号とを含む、入力と、
    複数のエントリを含むヒストリーテーブルであって、各エントリは、少なくとも一つの記号を含む、ヒストリーテーブルと、
    該複数の記号を該ヒストリーテーブル内の複数のエントリとパラレルな態様で比較する複数のコンパレータであって、該複数のコンパレータは、該非圧縮データの連続する記号の連続するグループに対して該複数の記号をパラレルに比較するように構成されており、該複数のコンパレータは、１つのグループ内の該複数の記号のそれぞれを該ヒストリーテーブル内の各エントリと同時に比較するように動作可能であり、該複数のコンパレータは、比較結果を生成する、複数のコンパレータと、
    該複数のコンパレータに結合され、該比較結果に基づいて該複数の記号のそれぞれに対して一致情報を決定する一致情報ロジックであって、該一致情報ロジックは、該最初の記号または該最後の記号のいずれかの記号との一致を含まない連続する一致が、該一つ以上の中間記号のうちの一つ以上に対して生じたか否かを決定するように動作可能である、一致情報ロジックと、
    該一致情報ロジックに結合され、該一致情報に応答して圧縮データを出力するための出力と
    を含み、
    該一致情報ロジックは、該グループの該最後の記号と該少なくとも一つの記号との間で致が生じたか否かを決定するようにさらに動作可能であり、該一致情報に応答して該圧縮データを出力することは、より長い連続した一致が存在するか否かを決定するために、該複数のコンパレータが該複数の記号を該グループの直後のグループと比較するために遅延される、システム。
JP2000596668A 1999-01-29 2000-01-27 拡張可能な埋込み型のパラレルデータを圧縮及び圧縮解除するためのシステムと方法 Expired - Lifetime JP4475820B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US09/239,659 1999-01-29
US09/239,659 US7190284B1 (en) 1994-11-16 1999-01-29 Selective lossless, lossy, or no compression of data based on address range, data type, and/or requesting agent
US09/421,968 US6208273B1 (en) 1999-01-29 1999-10-20 System and method for performing scalable embedded parallel data compression
US09/421,968 1999-10-20
US09/491,343 US6822589B1 (en) 1999-01-29 2000-01-26 System and method for performing scalable embedded parallel data decompression
US09/491,343 2000-01-26
PCT/US2000/002355 WO2000045516A1 (en) 1999-01-29 2000-01-27 System and method for parallel data compression and decompression

Publications (2)

Publication Number Publication Date
JP2002536863A JP2002536863A (ja) 2002-10-29
JP4475820B2 true JP4475820B2 (ja) 2010-06-09

Family

ID=26932743

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000596668A Expired - Lifetime JP4475820B2 (ja) 1999-01-29 2000-01-27 拡張可能な埋込み型のパラレルデータを圧縮及び圧縮解除するためのシステムと方法

Country Status (6)

Country Link
US (1) US6208273B1 (ja)
EP (2) EP1157470B1 (ja)
JP (1) JP4475820B2 (ja)
AT (1) ATE254358T1 (ja)
AU (1) AU2747600A (ja)
WO (1) WO2000045516A1 (ja)

Families Citing this family (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7190284B1 (en) 1994-11-16 2007-03-13 Dye Thomas A Selective lossless, lossy, or no compression of data based on address range, data type, and/or requesting agent
US6879266B1 (en) 1997-08-08 2005-04-12 Quickshift, Inc. Memory module including scalable embedded parallel data compression and decompression engines
US6092071A (en) * 1997-11-04 2000-07-18 International Business Machines Corporation Dedicated input/output processor method and apparatus for access and storage of compressed data
US6624761B2 (en) 1998-12-11 2003-09-23 Realtime Data, Llc Content independent data compression method and system
US6819271B2 (en) 1999-01-29 2004-11-16 Quickshift, Inc. Parallel compression and decompression system and method having multiple parallel compression and decompression engines
US6822589B1 (en) 1999-01-29 2004-11-23 Quickshift, Inc. System and method for performing scalable embedded parallel data decompression
US7538694B2 (en) 1999-01-29 2009-05-26 Mossman Holdings Llc Network device with improved storage density and access speed using compression techniques
US7129860B2 (en) * 1999-01-29 2006-10-31 Quickshift, Inc. System and method for performing scalable embedded parallel data decompression
US6885319B2 (en) * 1999-01-29 2005-04-26 Quickshift, Inc. System and method for generating optimally compressed data from a plurality of data compression/decompression engines implementing different data compression algorithms
US20010054131A1 (en) * 1999-01-29 2001-12-20 Alvarez Manuel J. System and method for perfoming scalable embedded parallel data compression
US6583887B1 (en) * 1999-02-26 2003-06-24 Hewlett-Packard Development Company, L.P. Method and apparatus for data compression
US6438609B1 (en) 1999-03-04 2002-08-20 International Business Machines Corporation Method of pacing the frequency at which systems of a multisystem environment compress log streams
US6539389B1 (en) * 1999-03-04 2003-03-25 International Business Machines Corporation Pacing the frequency at which systems of a multisystem environment compress log streams
US6604158B1 (en) * 1999-03-11 2003-08-05 Realtime Data, Llc System and methods for accelerated data storage and retrieval
US6601104B1 (en) 1999-03-11 2003-07-29 Realtime Data Llc System and methods for accelerated data storage and retrieval
US6349372B1 (en) * 1999-05-19 2002-02-19 International Business Machines Corporation Virtual uncompressed cache for compressed main memory
US6904402B1 (en) * 1999-11-05 2005-06-07 Microsoft Corporation System and iterative method for lexicon, segmentation and language model joint optimization
US6643752B1 (en) * 1999-12-09 2003-11-04 Rambus Inc. Transceiver with latency alignment circuitry
US7010642B2 (en) * 2000-01-05 2006-03-07 Rambus Inc. System featuring a controller device and a memory module that includes an integrated circuit buffer device and a plurality of integrated circuit memory devices
US7356639B2 (en) * 2000-01-05 2008-04-08 Rambus Inc. Configurable width buffered module having a bypass circuit
US20050010737A1 (en) * 2000-01-05 2005-01-13 Fred Ware Configurable width buffered module having splitter elements
US7363422B2 (en) * 2000-01-05 2008-04-22 Rambus Inc. Configurable width buffered module
US6502161B1 (en) * 2000-01-05 2002-12-31 Rambus Inc. Memory system including a point-to-point linked memory subsystem
US7266634B2 (en) * 2000-01-05 2007-09-04 Rambus Inc. Configurable width buffered module having flyby elements
US7404032B2 (en) * 2000-01-05 2008-07-22 Rambus Inc. Configurable width buffered module having switch elements
WO2001052523A1 (en) * 2000-01-12 2001-07-19 Advanced Communication Design, Inc. Compression and remote storage apparatus for data, music and video
US20010047473A1 (en) 2000-02-03 2001-11-29 Realtime Data, Llc Systems and methods for computer initialization
US7089391B2 (en) * 2000-04-14 2006-08-08 Quickshift, Inc. Managing a codec engine for memory compression/decompression operations using a data movement engine
US6734862B1 (en) * 2000-06-14 2004-05-11 Intel Corporation Memory controller hub
US7116331B1 (en) 2000-08-23 2006-10-03 Intel Corporation Memory controller hub interface
US6694490B2 (en) * 2002-07-10 2004-02-17 Hewlett-Packard Development Company, L.P. DIMM and method for producing a DIMM
US6725342B1 (en) * 2000-09-26 2004-04-20 Intel Corporation Non-volatile mass storage cache coherency apparatus
US6859208B1 (en) 2000-09-29 2005-02-22 Intel Corporation Shared translation address caching
US9143546B2 (en) 2000-10-03 2015-09-22 Realtime Data Llc System and method for data feed acceleration and encryption
US7417568B2 (en) 2000-10-03 2008-08-26 Realtime Data Llc System and method for data feed acceleration and encryption
US8692695B2 (en) 2000-10-03 2014-04-08 Realtime Data, Llc Methods for encoding and decoding data
US6779088B1 (en) * 2000-10-24 2004-08-17 International Business Machines Corporation Virtual uncompressed cache size control in compressed memory systems
JP2002149495A (ja) * 2000-11-15 2002-05-24 Nec Corp メモリ管理方式とその方法及びこの方法を記録した記録媒体
US20020101932A1 (en) * 2000-11-29 2002-08-01 Montgomery Dennis L. Method and apparatus for encoding information using multiple passes and decoding in a single pass
US6978047B2 (en) 2000-11-29 2005-12-20 Etreppid Technologies Llc Method and apparatus for storing digital video content provided from a plurality of cameras
US7047382B2 (en) 2000-11-29 2006-05-16 Quickshift, Inc. System and method for managing compression and decompression and decompression of system memory in a computer system
US6785767B2 (en) * 2000-12-26 2004-08-31 Intel Corporation Hybrid mass storage system and method with two different types of storage medium
GB0102572D0 (en) * 2001-02-01 2001-03-21 Btg Int Ltd Apparatus to provide fast data compression
US7386046B2 (en) 2001-02-13 2008-06-10 Realtime Data Llc Bandwidth sensitive data compression and decompression
KR100777271B1 (ko) * 2001-02-28 2007-11-20 엘지전자 주식회사 디지털 시스템의 메모리 관리 방법
JP2002264442A (ja) * 2001-03-12 2002-09-18 Ricoh Co Ltd 画像処理装置
EP1244221A1 (en) 2001-03-23 2002-09-25 Sun Microsystems, Inc. Method and system for eliminating data redundancies
US7409703B2 (en) * 2001-04-05 2008-08-05 The Directv Group, Inc. Method and system for efficient storage of data in a set top box
US7032158B2 (en) * 2001-04-23 2006-04-18 Quickshift, Inc. System and method for recognizing and configuring devices embedded on memory modules
US6864896B2 (en) * 2001-05-15 2005-03-08 Rambus Inc. Scalable unified memory architecture
US6789168B2 (en) * 2001-07-13 2004-09-07 Micron Technology, Inc. Embedded DRAM cache
US7564460B2 (en) * 2001-07-16 2009-07-21 Microsoft Corporation Systems and methods for providing intermediate targets in a graphics system
US20030028673A1 (en) * 2001-08-01 2003-02-06 Intel Corporation System and method for compressing and decompressing browser cache in portable, handheld and wireless communication devices
US6789169B2 (en) * 2001-10-04 2004-09-07 Micron Technology, Inc. Embedded DRAM cache memory and method having reduced latency
US6985853B2 (en) * 2002-02-28 2006-01-10 Broadcom Corporation Compressed audio stream data decoder memory sharing techniques
US20030167211A1 (en) * 2002-03-04 2003-09-04 Marco Scibora Method and apparatus for digitally marking media content
US7457519B2 (en) * 2002-04-03 2008-11-25 Broadcom Corporation Set-top box integration of integrated drive electronics
US7103608B1 (en) * 2002-05-10 2006-09-05 Oracle International Corporation Method and mechanism for storing and accessing data
US6981119B1 (en) 2002-08-29 2005-12-27 Advanced Micro Devices, Inc. System and method for storing performance-enhancing data in memory space freed by data compression
US7058783B2 (en) * 2002-09-18 2006-06-06 Oracle International Corporation Method and mechanism for on-line data compression and in-place updates
US7720999B2 (en) 2002-11-26 2010-05-18 Qualcomm Incorporated System and method for optimizing multimedia compression using plural encoders
US8749561B1 (en) 2003-03-14 2014-06-10 Nvidia Corporation Method and system for coordinated data execution using a primary graphics processor and a secondary graphics processor
KR101015497B1 (ko) * 2003-03-22 2011-02-16 삼성전자주식회사 디지털 데이터의 부호화/복호화 방법 및 장치
JP2005065043A (ja) * 2003-08-18 2005-03-10 Minolta Co Ltd データ処理装置
US6879270B1 (en) * 2003-08-20 2005-04-12 Hewlett-Packard Development Company, L.P. Data compression in multiprocessor computers
JP3753136B2 (ja) * 2003-08-22 2006-03-08 コニカミノルタビジネステクノロジーズ株式会社 データ処理装置及び処理方法
US6816093B1 (en) 2003-12-03 2004-11-09 International Business Machines Corporation Apparatus method and system for increased digital media recording throughput
US20050198395A1 (en) * 2003-12-29 2005-09-08 Pradeep Verma Reusable compressed objects
US7257693B2 (en) * 2004-01-15 2007-08-14 Intel Corporation Multi-processor computing system that employs compressed cache lines' worth of information and processor capable of use in said system
US7302543B2 (en) * 2004-06-16 2007-11-27 Nec Laboratories America, Inc. Compressed memory architecture for embedded systems
US8001294B2 (en) * 2004-09-28 2011-08-16 Sony Computer Entertainment Inc. Methods and apparatus for providing a compressed network in a multi-processing system
US20060085562A1 (en) * 2004-10-14 2006-04-20 Blaho Bruce E Devices and methods for remote computing using a network processor
AU2006255531B2 (en) * 2005-06-06 2011-02-10 Voyager Gaming Technologies Pty Ltd A gaming system
US7102552B1 (en) * 2005-06-07 2006-09-05 Windspring, Inc. Data compression with edit-in-place capability for compressed data
US8804765B2 (en) 2005-06-21 2014-08-12 Optis Wireless Technology, Llc Dynamic robust header compression
US20070030816A1 (en) * 2005-08-08 2007-02-08 Honeywell International Inc. Data compression and abnormal situation detection in a wireless sensor network
US7167115B1 (en) * 2005-08-26 2007-01-23 American Megatrends, Inc. Method, apparatus, and computer-readable medium for data compression and decompression utilizing multiple dictionaries
US7180433B1 (en) 2005-09-22 2007-02-20 Tandberg Storage Asa Fast data compression and decompression system and method
US7562271B2 (en) * 2005-09-26 2009-07-14 Rambus Inc. Memory system topologies including a buffer device and an integrated circuit memory device
US11328764B2 (en) 2005-09-26 2022-05-10 Rambus Inc. Memory system topologies including a memory die stack
US7464225B2 (en) * 2005-09-26 2008-12-09 Rambus Inc. Memory module including a plurality of integrated circuit memory devices and a plurality of buffer devices in a matrix topology
US7750912B2 (en) * 2005-11-23 2010-07-06 Advanced Micro Devices, Inc. Integrating display controller into low power processor
US8775704B2 (en) * 2006-04-05 2014-07-08 Nvidia Corporation Method and system for communication between a secondary processor and an auxiliary display subsystem of a notebook
WO2007135602A1 (en) * 2006-05-24 2007-11-29 Koninklijke Philips Electronics N.V. Electronic device and method for storing and retrieving data
US7596729B2 (en) * 2006-06-30 2009-09-29 Micron Technology, Inc. Memory device testing system and method using compressed fail data
US9418450B2 (en) 2006-08-31 2016-08-16 Ati Technologies Ulc Texture compression techniques
EP1990774A1 (en) * 2007-05-11 2008-11-12 Deutsche Thomson OHG Renderer for presenting an image frame by help of a set of displaying commands
US8736617B2 (en) * 2008-08-04 2014-05-27 Nvidia Corporation Hybrid graphic display
US9075559B2 (en) * 2009-02-27 2015-07-07 Nvidia Corporation Multiple graphics processing unit system and method
US9135675B2 (en) * 2009-06-15 2015-09-15 Nvidia Corporation Multiple graphics processing unit display synchronization system and method
US8766989B2 (en) * 2009-07-29 2014-07-01 Nvidia Corporation Method and system for dynamically adding and removing display modes coordinated across multiple graphics processing units
US8780122B2 (en) * 2009-09-16 2014-07-15 Nvidia Corporation Techniques for transferring graphics data from system memory to a discrete GPU
US9111325B2 (en) * 2009-12-31 2015-08-18 Nvidia Corporation Shared buffer techniques for heterogeneous hybrid graphics
US8838544B2 (en) * 2009-09-23 2014-09-16 International Business Machines Corporation Fast history based compression in a pipelined architecture
DE102009059939A1 (de) * 2009-12-22 2011-06-30 Giesecke & Devrient GmbH, 81677 Verfahren zum Komprimieren von Bezeichnern
US8160137B2 (en) * 2010-03-03 2012-04-17 Mediatek Inc. Image data compression apparatus for referring to at least one characteristic value threshold to select target compression result from candidate compression results of one block and related method thereof
US8781000B2 (en) * 2010-12-30 2014-07-15 Vixs Systems, Inc. Dynamic video data compression
RU2530351C2 (ru) * 2012-04-20 2014-10-10 Открытое акционерное общество "Информационные спутниковые системы" имени академика М.Ф. Решетнёва" Способ создания контекста для сжатия измерительных данных и способ проведения измерений
US8909608B2 (en) 2012-06-14 2014-12-09 International Business Machines Corporation Reducing decompression latency in a compression storage system
US8618960B1 (en) 2012-08-16 2013-12-31 International Business Machines Corporation Selective recompression of a string compressed by a plurality of diverse lossless compression techniques
KR101956031B1 (ko) * 2012-10-15 2019-03-11 삼성전자 주식회사 데이터 압축 장치 및 방법, 데이터 압축 장치를 포함하는 메모리 시스템
US9510041B2 (en) 2012-12-31 2016-11-29 Echostar Technologies L.L.C. Method and apparatus for gathering and using geocoded information from mobile devices
US10089645B2 (en) * 2012-12-31 2018-10-02 DISH Technologies L.L.C. Method and apparatus for coupon dispensing based on media content viewing
US8922414B2 (en) 2013-02-12 2014-12-30 Cortica, Ltd. Multi-layer system for symbol-space based compression of patterns
CN103280187B (zh) * 2013-06-09 2015-12-23 上海和辉光电有限公司 像素排列显示方法、装置及oled显示器
US9818379B2 (en) 2013-08-08 2017-11-14 Nvidia Corporation Pixel data transmission over multiple pixel interfaces
US9864536B2 (en) * 2013-10-24 2018-01-09 Qualcomm Incorporated System and method for conserving power consumption in a memory system
US9606870B1 (en) 2014-03-31 2017-03-28 EMC IP Holding Company LLC Data reduction techniques in a flash-based key/value cluster storage
US9864549B2 (en) 2016-02-29 2018-01-09 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for high throughput multi-input compression
US10120581B2 (en) * 2016-03-30 2018-11-06 Qualcomm Incorporated Generating compressed data streams with lookback pre-fetch instructions for pre-fetching decompressed data from a lookback buffer
US10013200B1 (en) * 2016-06-29 2018-07-03 EMC IP Holding Company LLC Early compression prediction in a storage system with granular block sizes
US9729168B1 (en) * 2016-07-17 2017-08-08 Infinidat Ltd. Decompression of a compressed data unit
US10453221B2 (en) * 2017-04-10 2019-10-22 Intel Corporation Region based processing
CN107196660A (zh) * 2017-04-24 2017-09-22 南京数维康信息科技有限公司 低功耗数据压缩算法
US10331558B2 (en) * 2017-07-28 2019-06-25 Apple Inc. Systems and methods for performing memory compression
US20190377804A1 (en) * 2018-06-06 2019-12-12 Yingquan Wu Data compression algorithm
CN109672888B (zh) * 2018-09-25 2022-04-22 平安科技（深圳）有限公司 图片压缩方法、设备及计算机可读存储介质
US10944423B2 (en) * 2019-03-14 2021-03-09 International Business Machines Corporation Verifying the correctness of a deflate compression accelerator
US11405622B2 (en) * 2020-04-22 2022-08-02 Apple Inc. Lossless compression techniques
US12028094B2 (en) 2020-12-23 2024-07-02 Intel Corporation Application programming interface for fine grained low latency decompression within processor core
KR102593034B1 (ko) * 2021-07-02 2023-10-23 고려대학교 산학협력단 다차원 데이터베이스를 위한 스토리지내 데이터 재구성 가속기

Family Cites Families (64)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4008460A (en) 1975-12-24 1977-02-15 International Business Machines Corporation Circuit for implementing a modified LRU replacement algorithm for a cache
US4688108A (en) 1985-10-11 1987-08-18 Teleconference Systems, Inc. High resolution graphics system for video/teleconferencing systems
US5247646A (en) 1986-05-15 1993-09-21 Aquidneck Systems International, Inc. Compressed data optical disk storage system
US4881075A (en) 1987-10-15 1989-11-14 Digital Equipment Corporation Method and apparatus for adaptive data compression
US4876541A (en) 1987-10-15 1989-10-24 Data Compression Corporation Stem for dynamically compressing and decompressing electronic data
US5016009A (en) 1989-01-13 1991-05-14 Stac, Inc. Data compression apparatus and method
US5003307A (en) 1989-01-13 1991-03-26 Stac, Inc. Data compression apparatus with shift register search means
US5146221A (en) 1989-01-13 1992-09-08 Stac, Inc. Data compression apparatus and method
US5532694A (en) 1989-01-13 1996-07-02 Stac Electronics, Inc. Data compression apparatus and method using matching string searching and Huffman encoding
US5126739A (en) 1989-01-13 1992-06-30 Stac Electronics Data compression apparatus and method
US5237675A (en) 1990-06-04 1993-08-17 Maxtor Corporation Apparatus and method for efficient organization of compressed data on a hard disk utilizing an estimated compression factor
US5247638A (en) 1990-06-18 1993-09-21 Storage Technology Corporation Apparatus for compressing data in a dynamically mapped virtual data storage subsystem
EP0470798B1 (en) * 1990-08-06 1997-10-29 Fujitsu Limited Dictionary searching system
US5237460A (en) 1990-12-14 1993-08-17 Ceram, Inc. Storage of compressed data on random access storage devices
US5627995A (en) 1990-12-14 1997-05-06 Alfred P. Gnadinger Data compression and decompression using memory spaces of more than one size
US5396343A (en) 1991-03-14 1995-03-07 Nec Electronics, Inc. Image compresssion systems with optimized data access
US5150430A (en) 1991-03-15 1992-09-22 The Board Of Trustees Of The Leland Stanford Junior University Lossless data compression circuit and method
US5414850A (en) 1991-08-23 1995-05-09 Stac Electronics, Inc. System for transparently compressing data files in a computer system
JP2550239B2 (ja) 1991-09-12 1996-11-06 株式会社日立製作所 外部記憶装置システム
US5426779A (en) 1991-09-13 1995-06-20 Salient Software, Inc. Method and apparatus for locating longest prior target string matching current string in buffer
US5455943A (en) 1992-10-08 1995-10-03 Salient Software, Inc. Method and apparatus for finding longest and closest matching string in history buffer prior to current string
US5155484A (en) 1991-09-13 1992-10-13 Salient Software, Inc. Fast data compressor with direct lookup table indexing into history buffer
CA2077271C (en) * 1991-12-13 1998-07-28 David J. Craft Method and apparatus for compressing data
US5510840A (en) 1991-12-27 1996-04-23 Sony Corporation Methods and devices for encoding and decoding frame signals and recording medium therefor
US5406278A (en) 1992-02-28 1995-04-11 Intersecting Concepts, Inc. Method and apparatus for data compression having an improved matching algorithm which utilizes a parallel hashing technique
US5371499A (en) 1992-02-28 1994-12-06 Intersecting Concepts, Inc. Data compression using hashing
US5379036A (en) 1992-04-01 1995-01-03 Storer; James A. Method and apparatus for data compression
US5353425A (en) 1992-04-29 1994-10-04 Sun Microsystems, Inc. Methods and apparatus for implementing a pseudo-LRU cache memory replacement scheme with a locking feature
US5353024A (en) 1992-05-01 1994-10-04 Intersecting Concepts, Inc. Method for data compression having an improved encoding algorithm which utilizes a token stacking technique
US5485526A (en) 1992-06-02 1996-01-16 Hewlett-Packard Corporation Memory circuit for lossless data compression/decompression dictionary storage
US5406279A (en) 1992-09-02 1995-04-11 Cirrus Logic, Inc. General purpose, hash-based technique for single-pass lossless data compression
US5836003A (en) 1993-08-26 1998-11-10 Visnet Ltd. Methods and means for image and voice compression
US5357614A (en) 1992-09-17 1994-10-18 Rexon/Tecmar, Inc. Data compression controller
US5559978A (en) 1992-10-14 1996-09-24 Helix Software Company, Inc. Method for increasing the efficiency of a virtual memory system by selective compression of RAM memory contents
US5337275A (en) 1992-10-30 1994-08-09 Intel Corporation Method for releasing space in flash EEPROM memory array to allow the storage of compressed data
US5467087A (en) 1992-12-18 1995-11-14 Apple Computer, Inc. High speed lossless data compression system
US5412429A (en) 1993-03-11 1995-05-02 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Picture data compression coder using subband/transform coding with a Lempel-Ziv-based coder
US5455577A (en) 1993-03-12 1995-10-03 Microsoft Corporation Method and system for data compression
US5420696A (en) 1993-06-24 1995-05-30 Xerox Corporation Image data transfer architecture and method for an electronic reprographic machine
CA2100700C (en) 1993-07-16 2000-01-11 Robert P. Bicevskis Multi-media computer architecture
US5563595A (en) 1993-12-23 1996-10-08 International Business Machines Corporation Method and apparatus for compressing data
WO1995019662A1 (en) 1994-01-13 1995-07-20 Telco Systems, Inc. Data compression apparatus and method
US5956372A (en) 1994-03-17 1999-09-21 Digital Compression Technology, L.P. Coding system for digital transmission compression
US5525982A (en) * 1994-04-15 1996-06-11 International Business Machines Corporation Method and means for character string pattern matching for compression and the like using minimal cycles per character
US5532693A (en) 1994-06-13 1996-07-02 Advanced Hardware Architectures Adaptive data compression system with systolic string matching logic
US5572206A (en) 1994-07-06 1996-11-05 Microsoft Corporation Data compression method and system
US5828877A (en) 1994-07-14 1998-10-27 Dell Usa, L.P. Circuit and method for optimizing creation of a compressed main memory image
US5548742A (en) 1994-08-11 1996-08-20 Intel Corporation Method and apparatus for combining a direct-mapped cache and a multiple-way cache in a cache memory
US5572209A (en) 1994-08-16 1996-11-05 International Business Machines Corporation Method and apparatus for compressing and decompressing data
US5883588A (en) 1994-10-04 1999-03-16 Nec Corporation Data compression system and data compression device for improving data compression rate and coding speed
US5812817A (en) 1994-10-17 1998-09-22 International Business Machines Corporation Compression architecture for system memory application
US6002411A (en) 1994-11-16 1999-12-14 Interactive Silicon, Inc. Integrated video and memory controller with data processing and graphical processing capabilities
US5838334A (en) 1994-11-16 1998-11-17 Dye; Thomas A. Memory and graphics controller which performs pointer-based display list video refresh operations
US5526363A (en) 1995-05-16 1996-06-11 Telco Systems, Inc. Multicontext compression system with shared data structures
US5621403A (en) 1995-06-20 1997-04-15 Programmed Logic Corporation Data compression system with expanding window
US5729228A (en) 1995-07-06 1998-03-17 International Business Machines Corp. Parallel compression and decompression using a cooperative dictionary
US5933104A (en) 1995-11-22 1999-08-03 Microsoft Corporation Method and system for compression and decompression using variable-sized offset and length fields
US5771011A (en) * 1996-07-15 1998-06-23 International Business Machines Corporation Match detect logic for multi-byte per cycle hardware data compression
JP3540109B2 (ja) 1996-12-24 2004-07-07 富士通株式会社 データ圧縮方法及び装置
US5798718A (en) 1997-05-12 1998-08-25 Lexmark International, Inc. Sliding window data compression method and apparatus
US5874908A (en) 1997-09-19 1999-02-23 International Business Machines Corporation Method and apparatus for encoding Lempel-Ziv 1 variants
US5877711A (en) 1997-09-19 1999-03-02 International Business Machines Corporation Method and apparatus for performing adaptive data compression
US5955976A (en) 1997-12-02 1999-09-21 Hughes Electronics Corporation Data compression for use with a communications channel
US5945933A (en) 1998-01-27 1999-08-31 Infit Ltd. Adaptive packet compression apparatus and method

Also Published As

Publication number Publication date
EP1164706A3 (en) 2005-03-23
JP2002536863A (ja) 2002-10-29
ATE254358T1 (de) 2003-11-15
AU2747600A (en) 2000-08-18
EP1164706A2 (en) 2001-12-19
EP1157470A1 (en) 2001-11-28
WO2000045516A1 (en) 2000-08-03
EP1157470B1 (en) 2003-11-12
US6208273B1 (en) 2001-03-27

Similar Documents

Publication Publication Date Title
JP4475820B2 (ja) 拡張可能な埋込み型のパラレルデータを圧縮及び圧縮解除するためのシステムと方法
US6822589B1 (en) System and method for performing scalable embedded parallel data decompression
US6885319B2 (en) System and method for generating optimally compressed data from a plurality of data compression/decompression engines implementing different data compression algorithms
US6819271B2 (en) Parallel compression and decompression system and method having multiple parallel compression and decompression engines
US7190284B1 (en) Selective lossless, lossy, or no compression of data based on address range, data type, and/or requesting agent
US6879266B1 (en) Memory module including scalable embedded parallel data compression and decompression engines
US10748510B2 (en) Framebuffer compression with controllable error rate
JP2986076B2 (ja) データを圧縮及び圧縮解除するための方法及び装置
US8761528B2 (en) Compression of image data
US8212828B2 (en) Hybrid multiple bit-depth video processing architecture
US7129860B2 (en) System and method for performing scalable embedded parallel data decompression
US6145069A (en) Parallel decompression and compression system and method for improving storage density and access speed for non-volatile memory and embedded memory devices
US20230153111A1 (en) Decompression Engine for Decompressing Compressed Input Data that Includes Multiple Streams of Data
JP4443165B2 (ja) 画像圧縮装置及び画像圧縮方法
US10191912B2 (en) Shared decompression engine
EP2787738B1 (en) Tile-based compression for graphic applications
Tomari et al. Compressing floating-point number stream for numerical applications
US11189005B1 (en) Index buffers in graphics processing systems
US11327687B2 (en) Encoding data arrays
US20170053376A1 (en) Technique for performing variable width data compression using a palette of encodings
US5880746A (en) Apparatus for forming a sum in a signal processing system
US5894568A (en) Apparatus and method for computing a difference in a digital processing system

Legal Events

Date Code Title Description
A625 Written request for application examination (by other person)

Free format text: JAPANESE INTERMEDIATE CODE: A625

Effective date: 20070129

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20070323

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20070323

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090522

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090817

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20090824

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091124

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20091124

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20091127

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: 20100218

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100309

R150 Certificate of patent or registration of utility model

Ref document number: 4475820

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130319

Year of fee payment: 3

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D04

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130319

Year of fee payment: 3

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D02

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140319

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term