TW201643758A - 依據輸入區塊類型使用動態散列演算法之硬體資料壓縮器 - Google Patents

依據輸入區塊類型使用動態散列演算法之硬體資料壓縮器 Download PDF

Info

Publication number
TW201643758A
TW201643758A TW105114413A TW105114413A TW201643758A TW 201643758 A TW201643758 A TW 201643758A TW 105114413 A TW105114413 A TW 105114413A TW 105114413 A TW105114413 A TW 105114413A TW 201643758 A TW201643758 A TW 201643758A
Authority
TW
Taiwan
Prior art keywords
hash
engine
input block
character
string
Prior art date
Application number
TW105114413A
Other languages
English (en)
Other versions
TWI591500B (zh
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
Application filed by 上海兆芯集成電路有限公司 filed Critical 上海兆芯集成電路有限公司
Publication of TW201643758A publication Critical patent/TW201643758A/zh
Application granted granted Critical
Publication of TWI591500B publication Critical patent/TWI591500B/zh

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/42—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code using table look-up for the coding or decoding process, e.g. using read-only memory
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/174—Redundancy elimination performed by the file system
    • G06F16/1744—Redundancy elimination performed by the file system using compression, e.g. sparse files
    • 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/60—General implementation details not specific to a particular type of compression
    • H03M7/6017—Methods or arrangements to increase the throughput
    • 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/60—General implementation details not specific to a particular type of compression
    • H03M7/6064—Selection of Compressor
    • H03M7/6082—Selection strategies
    • H03M7/6088—Selection strategies according to the data type

Abstract

一種硬體資料壓縮器，用以利用背向指標取代一字元輸入區塊內之字元字串以壓縮字元輸入區塊，此背向指標指向字元輸入區塊內出現在先之匹配字串。此硬體資料壓縮器包括一散列表，複數個散列索引產生器，一字元輸入區塊類型指標，以及一選擇器。散列表用以搜尋輸入區塊內之匹配字串。各個散列索引產生器對待取代之字元字串之開始部分施以不同之散列演算法，以產生一相對應之索引。選擇器依據輸入區塊之類型，選擇其中一個散列索引產生器所產生之索引作為散列表之索引。

Description

依據輸入區塊類型使用動態散列演算 法之硬體資料壓縮器
本申請案主張申請日為2015年5月11日之美國專利第62/159,352號臨時申請案之國際優先權。此優先權案之全文併入本案以供參考。
有效率的資料壓縮已經成為電腦世界中一個重要需求。這主要是因為許多檔案都是經過壓縮後再透過網路傳送，並在被接收後經過解壓縮再為被接收端所利用。此種傳輸方式可以降低網路傳送之檔案大小，以節省傳輸時間以及網路頻寬之使用。
有鑑於此，本發明提供一種硬體資料壓縮器，利用背向指標取代一字元輸入區塊內之字元字串以壓縮字元輸入區塊，此背向指標指向字元輸入區塊內出現在先之匹配字串。此硬體資料壓縮器包括一散列表，複數個散列索引產生器，一字元輸入區塊類型指標，以 及一選擇器。散列表係用以搜尋該輸入區塊內之該匹配字串。各個散列索引產生器對待取代之字元字串之一開始部分施以不同之散列演算法，以產生一相對應之索引。選擇器依據輸入區塊之類型，選擇其中一個散列索引產生器所產生之索引作為散列表之索引。
本發明並提供一種方法。首先，接收一字元輸入區塊類型指標。此字元輸入區塊利用背向指標取代字元輸入區塊內之字元字串以進行壓縮，而背向指標指向字元輸入區塊內出現在先之匹配字串。隨後，依據輸入區塊之類型，在多個散列演算法中選擇其一。接下來，利用所選擇之散列演算法對待取代之字元字串之一開始部分施以散列處理，以產生一索引用於一散列表。然後，利用此散列表搜尋輸入區塊內之匹配字串。
本發明並提供一種編碼於至少一非暫態電腦可使用媒體以供一電腦裝置使用之一電腦程式產品。此電腦程式產品包括內含於該媒體之電腦可使用程式碼，描述一硬體資料壓縮器，用以利用背向指標取代一字元輸入區塊內之字元字串以壓縮字元輸入區塊，此背向指標指向字元輸入區塊內出現在先之匹配字串。此電腦可使用程式碼包括第一程式碼，第二程式碼，第三程式碼與第四程式碼。第一程式碼描述一散列表，用以搜尋輸入區塊內之匹配字串。第二程式碼描述複數個散列索引產生器，各個散列索引產生器對待取代之字元字串之一開始部分施以不同之散列演算法，以產生一相對應之索引。第三程式碼描述一字元輸入區塊類型指標。 第四程式碼描述一選擇器，用以依據輸入區塊之類型，選擇其中一個散列索引產生器所產生之索引作為此散列表之索引。
本發明所採用的具體實施例，將藉由以下之實施例及圖式作進一步之說明。
100‧‧‧硬體資料壓縮器
101‧‧‧輸入區塊記憶體
102‧‧‧LZ77引擎
103‧‧‧散列記憶體
104‧‧‧分類引擎
105‧‧‧背向指標與旗標記憶體
106‧‧‧霍夫曼編碼表建構引擎
107‧‧‧表單記憶體
108‧‧‧霍夫曼編碼引擎
109‧‧‧輸出記憶體
212‧‧‧標記
214‧‧‧準備完成訊號
401‧‧‧頻率表
402‧‧‧頻率
403‧‧‧分類列
404‧‧‧分類索引
406‧‧‧符號值
407‧‧‧尾端指標
1108‧‧‧霍夫曼編碼
1112‧‧‧位元長度
1202‧‧‧分類列變更旗標
1204‧‧‧分類列未變更計數器
1802‧‧‧邏輯
1804‧‧‧分類列變更計數器
1806‧‧‧臨界值
1808‧‧‧符號倒數計數器
2102‧‧‧“參考”霍夫曼編碼表
2402‧‧‧當前搜尋目標位置
2404‧‧‧輸入區塊
2432‧‧‧3字元散列索引產生器
2442‧‧‧4字元散列索引產生器
2431‧‧‧散列鏈
2441‧‧‧散列鏈
2434‧‧‧3字元散列表索引
2444‧‧‧4字元散列表索引
2436‧‧‧輸入區塊之3個字元
2446‧‧‧輸入區塊之4個字元
2438‧‧‧3字元散列表
2448‧‧‧4字元散列表
2602‧‧‧掃描引擎
2604‧‧‧鏈分類引擎
2606‧‧‧字元輸入區塊
2611‧‧‧節點散列鏈
2702‧‧‧輸入區塊指標
2703‧‧‧機率
2704‧‧‧年齡
2705‧‧‧下一個指標
2706‧‧‧節點
3302‧‧‧查找表
3612‧‧‧標記
3901‧‧‧輸入區塊類型
3902‧‧‧當前搜尋目標位置
3904‧‧‧輸入區塊
3936‧‧‧開始字元
3941‧‧‧散列鏈
3942‧‧‧散列索引產生器
3944‧‧‧索引
3948‧‧‧散列表
3954‧‧‧索引
A 3954-A‧‧‧索引
B 3954-B‧‧‧索引
C 3954-C‧‧‧索引
3999‧‧‧多工器
4202、4302‧‧‧處理器
4204‧‧‧系統匯流排
4206‧‧‧記憶體
4208‧‧‧其他周邊
第一圖係一硬體資料壓縮器之方塊示意圖。
第二A圖係一方塊示意圖，顯示第一圖之硬體資料壓縮器之一部分。
第二B圖係一時序圖，顯示第二A圖之LZ77引擎與分類引擎之處理程序。
第三圖係一流程圖，顯示第二A圖之LZ77引擎與分類引擎之處理程序。
第四圖係一方塊圖，顯示供第一圖之分類引擎使用之頻率表、分類列與尾端指標。
第五圖係一流程圖，顯示第一圖之分類引擎依據第三圖之實施例進行之處理程序。
第六圖係一方塊圖，顯示第四圖中被分類引擎更新之頻率表、分類列與尾端指標。
第七圖係一方塊圖，顯示第六圖中被分類引擎更新之頻率表、分類列與尾端指標。
第八圖係一方塊圖，顯示第七圖中被分類引擎更新之頻 率表、分類列與尾端指標。
第九圖係一時序圖，以圖形顯示傳統DEFLATE類型輸入區塊壓縮所費時間的各個部份。
第十圖係一時序圖，以圖形顯示同步符號列分類之實施例之DEFLATE類型輸入區塊壓縮所費時間的各個部份。
第十一A圖係一方塊圖，顯示本發明另一實施例之分類列。
第十一B圖係一方塊圖，顯示本發明另一實施例之頻率表。
第十二圖係一方塊圖，顯示第一圖之硬體資料壓縮器之另一實施例。
第十三圖係一時序圖，以圖形顯示依據本發明另一實施例進行壓縮所費時間的各個部分。
第十四A圖係一流程圖，顯示第一圖之LZ77引擎配合動態初期霍夫曼編碼執行資料壓縮之處理程序。
第十四B圖係一流程圖，顯示第一圖之霍夫曼編碼表建構引擎配合動態初期霍夫曼編碼執行資料壓縮之運作。
第十四C圖係一流程圖，顯示第一圖之霍夫曼編碼引擎配合動態初期霍夫曼編碼執行資料壓縮之運作。
第十五圖係一時序圖，以圖形顯示傳統上對DEFLATE型輸入區塊進行壓縮所費時間的各個部分。
第十六圖係一時序圖，以圖形顯示依據本發明之動態初期霍夫曼編碼表對DEFLATE型輸入區塊進行壓縮所費時間的各個部分。
第十七A圖係一流程圖，顯示硬體資料壓縮器建構動態初期霍夫曼編碼表之運作之一實施例。
第十七B圖係一流程圖，顯示硬體資料壓縮器建構動態初期霍夫曼編碼表之運作之一實施例。
第十七C圖係一流程圖，顯示硬體資料壓縮器建構動態初期霍夫曼編碼表之運作之一實施例。
第十八圖係一方塊圖，顯示第一圖之硬體資料壓縮器之硬體之一實施例。
第十九圖係一流程圖，顯示分類引擎通知建構霍夫曼編碼表之處理程序。
第二十圖係一時序圖，以圖形顯示本發明對DEFLATE型輸入區塊進行壓縮所費時間的各個部分之另一實施例。
第二十一圖係一方塊圖，顯示第一圖之硬體資料壓縮器之一部分。
第二十二圖係一流程圖，顯示硬體資料壓縮器壓縮資料之處理程序。
第二十三A圖係一流程圖，顯示第二十二圖之步驟之一實施例。
第二十三B圖係一流程圖，顯示第二十二圖之步驟之另一實施例。
第二十四圖係一方塊圖，顯示第一圖之LZ77引擎之一部分。
第二十五圖係一流程圖，顯示第二十四圖之LZ77引擎之運作。
第二十六圖係一方塊圖，顯示本發明硬體資料壓縮器之一實施例。
第二十七圖係一方塊圖，顯示第二十六圖之散列鏈之節點。
第二十八圖係一流程圖，顯示硬體資料壓縮器利用動態節點機率之實施方式，執行第二十六圖所示於散列表中插入新節點顯示之運作。
第二十九圖係一時序圖，顯示第二十六圖之硬體資料壓縮器依據第二十八圖之流程執行之運作。
第三十圖係一流程圖，顯示第二十六圖之硬體資料壓縮器依據動態節點機率之實施例分類散列鏈之運作。
第三十一圖係一時序圖，例示硬體資料壓縮器依據第二十六至三十圖執行之運作。
第三十二圖係一流程圖顯示產生第三十三圖所示之查找表之方法，此查找表係用於靜態散列鏈節點機率之實施例。
第三十三圖係用於靜態散列鏈節點機率實施例之一查找表。
第三十四圖係一流程圖，顯示第二十六圖之硬體資料壓縮器依據靜態節點機率之實施例分類散列鏈之運作。
第三十五圖係一時序圖，例示第二十六圖之硬體資料壓縮器依據第三十四圖執行之運作。
第三十六圖係一方塊圖，顯示本發明硬體資料壓縮器之另一實施例。
第三十七圖係一流程圖，顯示第三十六圖之硬體資料壓縮器之運作。
第三十八圖係一時序圖，顯示第三十六圖之硬體資料壓縮器依據第三十七圖之方法執行之運作。
第三十九圖係一方塊圖，顯示第一圖之LZ77引擎之一部分。
第四十圖係一流程圖，顯示第三十九圖之LZ77引擎之運作。
第四十一圖係一方塊圖，詳細顯示第三十九圖之散列索引產生器。
第四十二圖係一方塊圖，顯示包含如第一圖所示之硬體資料壓縮器100之系統。
第四十三圖係一方塊圖，顯示包含硬體資料壓縮器之系統之另一實施例。
常見的檔案壓縮程式，如gzip與zlib，係將一輸入檔案壓縮，期能產生一較小的輸出檔案。此輸出檔案具有一設定格式，使檔案解壓縮程式(例如gzip與zlib)可以將其解壓縮並產生與原本輸入檔案相同之一解壓縮檔案。壓縮檔案包含一系列之塊(block)，對應至輸入檔案之連續資料塊。此壓縮檔案之各個塊之格式係符合RFC1951規範，DEFLATE壓縮資料格式規範版本1.3(DEFLATE compressed data format specification version 1.3)所定義之無損(lossless)壓縮資料格式，輸入檔案之各個塊係同時使用LZ型演算法(例如LZ77)與霍夫曼(Huffman)編碼進行壓縮演算。此技術可參照Ziv J.,Lempel A.,“A Universal Algorithm for Sequential Data Compression,”IEEE Transactions on Information Theory,Vol.23,No.3,pp.337-343；以及Huffman,D.A.,“A Method for the Construction of Minimum Redundancy Codes,”Proceedings of the Institute of Radio Engineers,September 1952,Volume 40,Number 9,pp.1098-1101。
LZ77壓縮演算法(以及其變化版本)係將一輸入資料串流內重複出現之資料或字串，利用指向輸入資料串流中較早出現字串的背向指標(back pointer)進行取代，以將輸入資料串流壓縮為一無損型式。字串係由一個或多個連續字元構成。背向指標係一有序對(ordered pair)(即長度、距離)，長度係定義在輸入資料串流之當前掃描位置之字串的字元數，距離則是定義與此字串相同之前一個字串之開始位置與當前掃描位置之距離。背向指標可由以下敘述加以理解：“後續每一個長度字元等同於在未壓縮串流之距離字元正前方之字元”。此演算法利用背向指標取代重複字串之字元以進行壓縮。進一步來說，LZ77演算法係始於當前掃描位置，於輸入資料串流內，反向搜尋一字串匹配(例如：如果有匹配字串的話，其中長度最長之匹配字串)，並以一個背向指標進行取代。若是找到適當的匹配，此演算法就會為此匹配字串產生一背向指標，反之，此演算法就會 產生詞彙輸入字元(literal input characters)，如當前掃描位置之三個字元，並更新當前掃描位置。DEFLATE規範係使用“詞彙”來表示演算法產生輸入字元而非利用背向指標來取代輸入字元之情況。依此，LZ77壓縮之有效輸出會是一個由詞彙與背向指標(有時也包含各個詞彙與背向指標頻率之直方圖，這部分在後續段落會有更詳細的描述)構成之串流。在此規範中，詞彙與背向指標係稱為標記，因此LZ77壓縮會輸出一標記串流。所達成之壓縮量主要受到輸入資料串流內字串重複的程度以及重複字串的長度影響。
DEFLATE規範係將霍夫曼編碼，通常也稱為前置編碼(prefix coding)，描述為“前置編碼係以位元序列(字碼)表示先前已知符號集之符號，每個符號賦予一個字碼，不同符號可由不同長度之位元序列來表示，然而解析器總是可以對一編碼字串逐個符號清楚地進行解析。對於一具有已知符號頻率之符號集，霍夫曼演算法可以建構一最佳前置編碼(即對於此符號集，在各種可能的前置編碼中，利用最少位元來表示具有該些符號頻率之字串之編碼)。此編碼即稱為霍夫曼編碼”。DEFLATE規範係區分兩種不同的符號集。其中一種符號集，其符號係詞彙(項目0至256)之值與關聯於背向指標長度(項目257至285)之值或索引。另一種符號集，其符號係關聯於背向指標距離(項目0至29)之值或索引。這兩種符號集會各別產生其霍夫曼編碼表，這部分在後續段落會有更詳細的描述。
依據DEFLATE規範，輸出檔案之各個壓縮塊之標頭內包含有位元，以指出壓縮此區塊所使用之霍夫曼編碼表是否內含於此輸出區塊。若否，此霍夫曼編碼表就會是隱含或指定於DEFLATE規範之段落3.2.6。依據DEFLATE規範，前者(內含霍夫曼編碼表)表示利用動態霍夫曼編碼進行壓縮，後者(隱含霍夫曼編碼表)表示利用固定的霍夫曼編碼進行壓縮。使用動態編碼之缺點在於，壓縮檔案必須包含一標誌表示霍夫曼編碼表，此標誌會佔據輸出區塊之空間，而與縮小輸出檔案之目標不符。因此，相較於使用動態編碼，使用固定編碼在小輸入檔案的情況下，可以產生較小的輸出檔案。
使用動態編碼之優點在於，可以將較可能產生優於使用DEFLATE規範之固定霍夫曼編碼表之編碼結果的霍夫曼編碼，指派給符號集之符號。在本文中，較佳之霍夫曼編碼，表示此動態霍夫曼編碼表相較於固定霍夫曼編碼，可以在LZ77輸出串流產生較高壓縮率。這是因為固定霍夫曼編碼表是一般的霍夫曼編碼表，因而往往無法對於此二個符號表中各種不同符號出現於經霍夫曼壓縮之LZ77輸出串流內的或然率或相對頻率做出非常好的預測，這是因為輸出串流並非為特定字元量身訂作之故。如前述，動態霍夫曼編碼表可以將較短的編碼指派給LZ77輸出串流中出現頻率較高之符號表符號，而將較長的編碼指派給LZ77輸出串流中出現頻率較低之符號表符號，以獲得較高之壓縮率。傳統上(例如gzip或zlib執行之壓縮流程)，使用動態霍夫曼編碼進行 之壓縮流程需要三個步驟(如下所述)來壓縮一輸入區塊，期能產生一較小且符合DEFLATE規範之輸出區塊。
首先，此壓縮流程對於輸入區塊執行LZ77壓縮，以產生一標記(token)(詞彙與背向指標)之串流，也稱為LZ77輸出串流。此步驟也被稱為是對輸入區塊進行掃描，並涉及在輸入區塊中反向搜尋字串匹配。在掃描輸入區塊時，此程式並依據標記串流產生兩個直方圖，一個直方圖包含之項目對應於詞彙/長度符號表之各個符號，而另一個直方圖之項目對應於距離符號表之各個符號，直方圖的各個項目表示與LZ77標記輸出串流之符號出現次數有關的頻率。值得注意的是，背向指標標記具有兩個相關符號：詞彙/長度符號表內之一個長度符號與距離符號表內之一個距離符號。
在第二個步驟中，此壓縮流程利用第一個步驟所產生之直方圖，建構相對應之一個詞彙/長度霍夫曼編碼表與一個距離霍夫曼編碼表。
在第三個步驟中，此壓縮流程利用建構於前步驟之霍夫曼編碼表，對LZ77標記輸出串流進行霍夫曼壓縮，以產生壓縮輸出區塊。此輸出區塊係一系列包含有可變長度霍夫曼編碼之位元。輸出區塊內表示一背向指標之長度的霍夫曼編碼，會接續在表示此背向指標之距離的霍夫曼編碼後方。
前述對於DEFLATE形式輸入區塊使用動態霍夫曼編碼表進行壓縮之三步驟壓縮流程的缺點為，這些步驟需依序執行。也就是說，霍夫曼編碼步驟(第 三個步驟)必須在建構完霍夫曼編碼表(第二個步驟)後才能執行，而霍夫曼編碼表必須在(第一個步驟中)直方圖完全產生後才能建構。
不過，舉例來說，如同使用固定霍夫曼編碼表執行之壓縮程序，前述第一個與第三個步驟應可同時執行。本案發明人觀察到此點，並利用此架構一硬體資料壓縮器，以改善使用動態霍夫曼編碼表所能提供之壓縮率，同時避免因使用動態霍夫曼編碼表對於壓縮速度之妨礙。本案發明人觀察對輸入區塊之開始部分掃描後所產生之直方圖，並將其與整個輸入區塊掃描後所產生之直方圖進行比較。在許多例子之比較結果中觀察到，對於符號表內不同符號間之相對頻率而言，此兩種狀況之頻率幾乎不隨時間改變。也就是說，相較於只掃描開始部分所產生之直方圖，掃描完輸入區塊之剩餘部分所產生之直方圖內的相對頻率並不會有太大的改變。舉例來說，只掃描輸入區塊之前10%得出“A”的頻率為6，“B”的頻率為3，而“C”的頻率為4；而在掃描整個輸入區塊後，得出“A”的頻率為62，“B”的頻率為31，而“C”的頻率為44。就相對比較而言，只掃描輸入區塊之前10%與掃描整個輸入區塊所得出的頻率並沒有差別。
這個觀察結果非常有用，因為霍夫曼編碼表可基於符號表之符號間的相對頻率，而非其絕對頻率值來產生。也就是說，如前述，會將較短的霍夫曼編碼(亦即較少位元)指派給相對頻率較高之符號表符號，而對較常出現之符號給予較短的編碼，以最佳化對於輸 入區塊之壓縮程序。
基於此觀察結果，本發明之實施例提出一硬體資料壓縮器，在掃描輸入區塊之開始部分後就停止更新直方圖，而使用此“不完整”的直方圖來建構霍夫曼編碼表-在此稱為“動態-初期(dymanic-prime)”霍夫曼編碼表-然後，在掃描輸入區塊之剩餘部分之同時，使用此動態初期霍夫曼編碼表來對LZ77輸出標記串流進行編碼。如此可使硬體資料壓縮器之霍夫曼編碼引擎在LZ77壓縮引擎對於輸入區塊之剩餘部分進行掃描之過程中執行之霍夫曼編碼，而使霍夫曼編碼所花費之至少部分(若非全部)時間，涵蓋於LZ77壓縮時間內。由於霍夫曼編碼所花費的時間往往少於LZ77壓縮程序中掃描輸入區塊所花費的時間，依據建構霍夫曼編碼表的時間點，在某些情況下，霍夫曼編碼步驟在輸入區塊壓縮流程外幾乎不會額外花費任何時間。
此外，如第九圖所示，本案發明人觀察到，依據各個符號的出現頻率來對直方圖進行分類(這是建構一有效率之霍夫曼編碼表的必要步驟)相當費時並且是壓縮流程之關鍵步驟的一環，但這會導致總壓縮時間之增加。相較之下，在本發明實施例中，此依據頻率進行之分類步驟係以遞增方式進行-舊一實施例而言若利用LZ77引擎產生各個符號(舉例來說，可參照第二A與第二B圖)，可由另一個硬體引擎來執行分類步驟-並與輸入區塊之掃描同時執行，而使分類步驟所需花費的時間涵蓋於輸入區塊之掃描時間內，以減少總花費時間分 類引擎可由本案發明人之觀察結果獲得助益。若是利用LZ77引擎產生各個符號，而其頻率值的變化只有一，就會有很高的可能性不需改變此符號在分類列的位置。不過，也會有很高的可能性只需對其位置進行短距離之調整，而此調整能很快地完成。尤其是，完成前述改變符號在分類列之位置所需的時間有很高的可能性會少於LZ77引擎搜尋並找到匹配目標字串的時間。此外，有利的是，此遞增與同步符號列分類機制還可與動態初步霍夫曼編碼表之實施例結合。
硬體資料壓縮器
第一圖係一方塊圖，顯示一硬體資料壓縮器100。此硬體資料壓縮器100包含一輸入區塊記憶體101；一壓縮引擎102(例如一LZ77引擎)；一散列記憶體103；一分類引擎104；一背向指標與旗標記憶體105；一霍夫曼編碼表建構引擎106；一表單記憶體107以儲存一頻率表，一符號分類列與霍夫曼編碼表；一霍夫曼編碼引擎108；與一輸出記憶體109。壓縮引擎102，分類引擎104與霍夫曼編碼表建構引擎108為硬體引擎。硬體引擎係一包含硬體狀態機器之硬體，此硬體可包含組合與順序邏輯。硬體引擎不同於可程式化處理器是由記憶體內提取指令並加以執行，不過，硬體引擎可以從一個或多個記憶體內讀取資料作為其輸入資料，並將輸出資料寫入一個或多個記憶體。
輸入區塊記憶體101儲存一待壓縮之字元 輸入區塊。在一實施例中，此輸入區塊記憶體101是一個32KB記憶體，在另一實施例中，此輸入區塊記憶體101是一個16KB記憶體，不過，本發明並不限於此。一般而言，此字元輸入區塊是一待壓縮輸入檔案字元之一部分。舉例來說，此待壓縮檔案可以是一影像檔(如JPG，TIFF)、一音訊檔(如AIFF，WAV)、一文字檔、一電子表單、由文字處理器或簡報應用程式、或其他類型的檔案(如PDF)。在此實施例中，輸入區塊內之各個字元是一資料位元組。輸入區塊記憶體101提供輸入區塊至壓縮引擎102與霍夫曼編碼引擎108。在一實施例中，輸入區塊記憶體101是一雙埠記憶體以減少壓縮引擎102與霍夫曼引擎108同時存取輸入區塊記憶體101之衝突。壓縮引擎101存取輸入區塊記憶體101以掃描輸入區塊(例如：提取當前搜尋位置之字串，並在輸入區塊內搜尋在前的匹配)進行壓縮(例如：產生背向指標以取代匹配字串)，而霍夫曼引擎108存取輸入區塊記憶體101以對輸出標記串流之詞彙符號(輸入區塊之字元中未被背向指標取代之字元)執行霍夫曼壓縮。在一實施例中，輸入區塊由系統記憶體載入輸入區塊記憶體101。
壓縮引擎102利用輸入區塊內指向在前字串之背向指標，來取代輸入區塊內與此在前字串匹配之字元字串以壓縮輸入區塊。就一實施例而言，此壓縮引擎102係一LZ77引擎。此LZ77引擎102可使用文獻Ziv J.,Lempel A.,“A Universal Algorithm for Sequential Data Compression,”IEEE Transactions on Information Theory, Vol.23,No.3,pp.337-343所提及的演算法，或其變形，不過本發明並不限於此。此壓縮引擎102亦可使用其他無損壓縮演算法產生背向指標以取代字串。
在此實施例中，LZ77引擎102產生背向指標並將其儲存於背向指標記憶體105。在一實施例中，此LZ77引擎102在背向指標記憶體105內維持一旗標陣列。在一實施例中，各個旗標係為對應於輸入區塊之一字元之單一位元(舉例來說，對於具有16K字元之輸入區塊，就會有16K位元之旗標)。若旗標值為真，即表示儲存於背向指標記憶體105之背向指標已取代字串，而此字串於輸入區塊內之開始位置係對應於此旗標於旗標陣列內之位置。舉例來說，若是在索引3742之旗標為真，就表示LZ77引擎102已產生一背向指標來取代始於輸入區塊之位置3742之字串。反之(若是旗標為非)，即表示位於輸入區塊內對應於此旗標之索引的字元係被視為一“詞彙”字元，而屬於此LZ77引擎102之輸出標記串流之一部分。詞彙係一符號，其於後續步驟中會由霍夫曼編碼引擎108執行霍夫曼編碼並儲存於輸出記憶體109內。
在此實施例中，LZ77引擎102使用散列表(hash table)與散列技術以降低搜尋匹配字串的時間。此技術在後續段落會有更詳細的說明。散列表係儲存於散列記憶體103內。在一實施例中，此LZ77引擎利用雙散列表以提升壓縮時間。此技術在後續段落也會有更詳細的說明。
LZ77引擎102、分類引擎104、霍夫曼編 碼表建構引擎106、與霍夫曼編碼引擎108可以存取表單記憶體107。表單記憶體107內之頻率表(例如第四圖之元件401)儲存LZ77引擎102輸出標記串流內出現之各個符號的頻率(第四圖之元件402)或次數。在一實施例中，LZ77引擎102係維持頻率表401之各個頻率值402。在另一實施例中，分類引擎104係因應LZ77引擎102產生之標記212，來維持頻率表401之各個頻率值402。在另一實施例中，霍夫曼編碼表建構引擎106因應LZ77引擎102產生之標記212，來維持頻率表401之各個頻率值402。分類引擎104依據各個符號之頻率(例如使用第四圖之頻率表401之項目的分類索引欄位404)，來維持一符號分類列(例如第四圖之元件403)，這部分在後續段落會有更詳細的描述。此外，霍夫曼編碼表建構引擎106並利用此以頻率分類之符號分類列來建構霍夫曼編碼表，供霍夫曼編碼引擎108對關聯於LZ77引擎102輸出串流之標記的符號進行霍夫曼編碼，以儲存於輸出記憶體109。
就一實施例而言，此霍夫曼編碼引擎108係利用兩個霍夫曼編碼表，其一供詞彙與長度符號之用，另一個供距離符號之用，因而需維持兩個相對應的頻率表與分類列供建構此二個霍夫曼編碼表之用。在一實施例中，此霍夫曼編碼表建構引擎106依據已知之典型霍夫曼編碼程序，例如DEFLATE規範中使用之程序，來建構霍夫曼編碼表。就一實施例而言，對一常值符號進行霍夫曼編碼，係表示輸出關聯於此詞彙符號之值(例如第十一A圖之符號值406或第十一B圖之頻率表401內 的索引)之霍夫曼編碼(例如第十一A與十一B圖之霍夫曼編碼1108)；對一背向指標長度進行霍夫曼編碼，係表示輸出關聯於此長度符號值之霍夫曼編碼，其長度範圍涵蓋此背向指標之長度，加上任何用以指定此背向指標長度(如後續表1所示，此表係擷取自DEFLATE規範之段落3.2.5)之額外位元；對一背向指標距離進行霍夫曼編碼，係表示輸出關聯於此距離符號之值之霍夫曼編碼，其距離範圍係涵蓋此背向指標之距離加上任何用以指定此背向指標距離(如後續表2所示，此表係擷取自DEFLATE規範之段落3.2.5)之額外位元。需理解的是，表1內出現“編碼”的用語係因為此用語使用於DEFLATE規範之圖表內。不過，表1之“編碼(Code)”欄內的值並非如第十一A與十一B圖之元件1108所示之霍夫曼編碼，而是如對應於第四圖之實施例的符號值406，亦即第四圖之頻率表401之索引值。與距離符號有關之表2亦同。
在其他實施例中，亦可省略分類引擎104，而由霍夫曼編碼表建構引擎106在LZ77引擎102完成頻率表之更新後，執行頻率表之符號分類。一般而言，LZ77引擎102會在完成整個輸入區塊之掃描後才停止更新頻率表，不過本發明之實施例之LZ77引擎102則是在 掃描完輸入區塊之開始部分後就停止更新頻率表，而霍夫曼編碼表建構引擎106隨即開始建構霍夫曼編碼表-在本文稱為“動態-初始”霍夫曼編碼表。
輸入區塊掃描時維持分類符號列
第二A圖係一方塊圖顯示第一圖之硬體資料壓縮器100之一部分。如圖中所示，第一圖之LZ77引擎102產生一標記212至分類引擎104。標記212係一背向指標或是一詞彙字串(可為單一個詞彙字元)之標誌。在一實施例中，此標記212係輸入區塊記憶體101內詞彙字串位置之一指標或索引。在此實施例中，分類引擎104可存取輸入區塊記憶體101。在另一實施例中，標記212係詞彙字串本身，例如字元字串之值。在一實施例中，標記係一指標或是指標記憶體105內背向指標位置之索引。在此實施例中，分類引擎104可存取指標記憶體105。在另一實施例中，標記212係背向指標本身，例如背向指標之長度或距離值。分類引擎104依據更新表單記憶體107內頻率表401與分類列403之進度，產生一準備完成信號214至LZ77引擎。這部分在後續段落，尤其是第三圖的部分，會有更詳細的說明。
由後續第三至八圖之描述可推知，若是符號的頻率與其他多個位於符號列上方之符號的頻率相同時，分類引擎104在符號頻率遞增之過程中就需要執行多個交換動作以確認符號在分類列403中之正確位置，而會產生病態案例(pathological case)。此外，此符號遞增頻 率可能等於位於其上方但具有較後之語彙值(lexical value)之多個符號，因此分類引擎104在符號頻率遞增之過程中就需要執行多個交換動作以確認符號在分類列403中之正確位置。若是分類引擎104繁忙而無法由LZ77引擎102接收標記212，對輸入區塊執行壓縮所需要的時間就會增加。
一般而言，病態案例較可能發生於符號頻率之分布相當均勻之情形，此情形特別容易發生於掃描輸入記憶體之初期，因為在開始的時候所有的頻率值都是零。值得注意的是，在本文第十四A至十四C圖與第十六圖所述之實施例中，其頻率值係初始化為不同數值，因而可以降低產生病態案例的可能性。
在一實施例中，硬體資料壓縮器100在LZ77壓縮引擎102與分類引擎104間包含一短的先進先出記憶體，在必要時暫時儲存由LZ77壓縮引擎102提供給分類引擎104之標記212，以減少或在部分情況下消除此病態案例對於壓縮程序之衝擊。此先進先出記憶體之一滿溢旗標(full flag)輸出信號可作為提供給LZ77壓縮引擎102之準備完成信號214。
第二B圖係一時序圖，顯示第二A圖之LZ77引擎102與分類引擎104之處理程序。此時序圖之上部分顯示LZ77引擎102之處理程序，下部份顯示分類引擎104之處理程序。時間進程係由左而右。圖中無時間單位而以相對時間描繪。不過，圖中之時間可以時鐘週期、奈秒，或其他相關的時間單位表示。
如圖中所示，在時間0的時候，LZ77引擎102對於始在當前搜尋位置之字串，掃描輸入區塊搜尋是否有字串匹配(如第三圖之步驟302)，而在時間6的時候，輸出一標記212(標示為標記N)至分類引擎104。因應此標記N，分類引擎104遞增各個關聯於標記N之符號的頻率，並重新對分類列之符號進行分類(例如第四圖之分類列403)以維持各個符號依頻率(或詞彙順序)之分類順序(如第三圖之步驟316)。此重分類結束於時間12，早於LZ77引擎102結束下一次搜尋並輸出標記N+1之時間18。因應標記N+1，分類引擎104遞增各個關聯於標記N+1之符號的頻率，並重新對分類列之符號進行分類，以維持各個符號依頻率之分類順序。此重分類結束於時間25，早於LZ77引擎102結束下一次搜尋並輸出標記N+2之時間38。因應標記N+2，分類引擎104遞增各個關聯於標記N+1之符號的頻率，並重新對分類列之符號進行分類以維持分類順序。此重分類結束於時間47，早於LZ77引擎102結束下一次搜尋並輸出標記N+3之時間。在此情況下，準備完成信號214將會使LZ77引擎102暫停，等待分類引擎104完成分類動作(除非如前所述，存在先入先出記憶體而此記憶體尚未存滿)。
如第二B圖所示，在LZ77引擎102掃描輸入區塊之同時，分類引擎104漸進維持依頻率分類之符號列，因而可以使維持符號分類列所需之時間，涵蓋在輸入區塊之掃描時間內。這部分在本文會有更詳細的說明。
第三圖係一流程圖，顯示第二A圖之LZ77 引擎102與分類引擎104之處理程序。在第三圖中，LZ77引擎執行步驟302至308，而分類引擎104執行步驟312至318。此流程始於步驟302。
在步驟302中，LZ77引擎102掃描輸入區塊，並在輸入區塊中之當前搜尋目標位置搜尋字串之匹配。接下來流程前進至步驟304。
在決策步驟304中，LZ77引擎102檢視準備完成信號214以確認分類引擎104是否完成準備而能接收來自LZ77引擎102之標記212。若是，流程前進至步驟306；否則就會回到步驟304，直到分類引擎完成準備。
在步驟306中，LZ77引擎102產生標記212至分類引擎104。接下來流程前進至由LZ77引擎102執行之步驟308，同時前進至由分類引擎104執行之步驟312。
在步驟308中，LZ77引擎102更新當前搜尋目標位置。接下來流程回到步驟302，LZ77引擎102搜尋下一個字串，直到接觸到區塊字元的末端。
在決策步驟312中，分類引擎104確認LZ77引擎是否產生提供給分類引擎104之標記212。若是，流程前進至步驟314；否則就會回到步驟312直到LZ77引擎產生標記212。
在步驟3134中，分類引擎104輸出一非(false)值於準備完成信號214。接下來前進至步驟316。
在步驟316中，對於從LZ77引擎102接收之標記212的各個符號，分類引擎104會遞增符號的頻率(如第四圖之步驟402所示)，並依據符號出現頻率與詞 彙順序維持分類列(如第四圖之步驟403所示)。此部分在後續第五圖會有更詳細的說明。接下來前進至步驟318。
在步驟318中，分類引擎104輸出一真(true)值於準備完成信號214。接下來，流程回到步驟312。
如前述，一般而言，分類引擎104執行步驟316所花費之時間會少於LZ77引擎執行步驟302所花費的時間。因此，分類引擎104因應LZ77引擎102產生之標記執行步驟316維持符號分類列所需的時間基本上會涵蓋於LZ77引擎102在步驟102中產生下一個標記所需的時間內。如同本案發明人之觀察，因為符號之頻率值的變化只有一，因而有很高的可能性，不須改變符號在分類列的位置。但就算要改變在分類列的位置時，也會有很高的可能性只需對其位置進行短距離的調整，而分類引擎104執行此操作所花時間，通常可以比LZ77引擎102執行字串搜尋來得快。
第四圖係一方塊圖顯示供第一圖之分類引擎104使用之一頻率表401、一分類列403與一尾端指標407。頻率表401係一項目陣列，而各個項目包含兩個欄位：一頻率欄位402與一分類索引欄位404。各個項目係關聯於將由第一圖之霍夫曼編碼引擎108編碼之各個符號的符號空間中不同的符號，符號的值為頻率表401的索引，符號的頻率402會在每次符號出現於LZ77引擎102之輸出串流時進行更新。在第四圖之實施例中，符號空間包含數值0至285，作為頻率表401之索引。符號空間值0 至285對應於DEFLATE規範所定義之詞彙與長度符號，不過本發明並不限於此。其他符號之符號表也可用於本發明並利用本文所述，在硬體壓縮引擎掃描輸入區塊(如第二B圖所示)的過程中同時使用一硬體分類引擎漸進地維持依頻率分類之符號列。頻率表401內之項目的分類索引404，係被一符號值指標作為索引指向分類列403中，被分類引擎104所掃描的符號值406之上。這部分在第五圖會有更詳細的描述。
分類列403是一個與頻率表401具有相同項目數量之陣列。位於分類列403之頂端的項目，即項目0，係儲存LZ77引擎102之輸出串流內出現頻率最高之符號的符號值406；項目1係儲存LZ77引擎102之輸出串流內出現頻率次高之符號的符號值406；以此類推。對於出現次數相同的符號，就依照字符順序，即較小的符號值406會被分到分類列403的較高處。因此，此分類列403之索引會依照出現頻率與語彙值顯示符號的順序，而其符號值406係依據索引項目儲存於分類列403之內。
分類列403本身就會指回頻率表401。也就是說，分類列403之項目的符號值406即為位於分類列403此項目之符號在頻率表401之索引。因此，由當前符號值開始(亦即，其頻率402開始遞增)，利用位於分類列403上一個項目之符號值406作為頻率表401之索引，即可由頻率表401獲得當前符號之上一個項目符號的頻率402。如此即可將這兩個產生的頻率402(如第五圖之步驟512與516所示)進行比較，以確認當前符號是否需要在分類 列403中向上移動。
尾端指標407指向分類列403中下一個可用項目，作為放置LZ77引擎102輸出串流下一個新出現符號的位置。位於尾端指標407及其下方之項目均為空白。
本實施例僅呈現單一個頻率表401與單一個分類列403(例如：用於詞彙與長度)，不過本技術所屬技術領域者當可推知，本實施例另維持一個用於距離之頻率表與分類列。舉例來說，在DEFLATE規範中，距離頻率表401與距離分類列403係分別具有30個項目(項目0至29)，而非如供詞彙與距離使用之頻率表與分類列具有286個項目。
第四圖顯示多種不同數值以說明頻率表401與分類列403之使用。舉例來說，頻率表401之項目1具有一頻率402，其值為180，與一分類索引404，其值為24，此分類索引404指向分類列403之項目24，而此分類列403之項目24具有之符號值為1。類似地，頻率表401之項目3具有一頻率402，其值為20，與一分類索引404，其值為137，此分類索引404指向分類列403之項目137，而此項目具有之符號值為3；頻率表401之項目27具有一頻率402，其值為180，與一分類索引404，其值為25，此分類索引404指向分類列403之項目25，而此項目具有之符號值為27；頻率表401之項目29具有一頻率402，其值為181，與一分類索引404，其值為23，此分類索引404指向分類列403之項目23，而此項目具有之符號值為29； 頻率表401之項目279具有一頻率402，其值為1000，與一分類索引404，其值為1，此分類索引404指向分類列403之項目1，而此項目具有之符號值為279。這些數值係用於第六至八圖中以說明第五圖之分類引擎104之運作。
第五圖係一流程圖，顯示第一圖之分類引擎104執行第三圖之步驟316之一實施例。在以下第五圖之描述中係利用虛擬程式碼來說明分類引擎104之處理程序，不過需注意的是，此分類引擎104是一個以硬體而非軟體執行多種不同操作之硬體引擎。此流程始於步驟502。
在步驟502中，分類引擎104從LZ77引擎接收一標記212，並確認關聯於此標記212之符號。分類引擎104會對每一個符號都執行此處理程序，儘管，第五圖只描述分類引擎104針對單一關聯符號進行之處理程序。如前述，若是標記212是一個背向指標，此標記212會具有兩個關聯符號：背向指標之長度與距離。不過，若是標記212是一個詞彙字串，此標記212具有之關聯符號的數量就會與此字串之字元數相同，而這些符號就會是字串字元值。舉例來說，15字元之ASCII詞彙字串標記212，“This is the day”，具有15個符號，即“T”,“h”,“i”,“s”,“ ”,“i”,“s”,“ ”,“t”,“h”,“e”,“ ”,“d”,“a”,“y”，或由下列數字表示84,104,105,115,32,105,115,32,116,104,101,32,100,97,121。接下來，流程前進至決策步驟504。以下之虛擬程式碼可說明步驟502之運作：increment freq_tbl[this_symbol_val].freq
在決策步驟504，分類引擎104確認此符號是否首次出現。例如，分類引擎104可透過檢視頻率表401內此符號之頻率402值，來確認此符號是否首次出現。若是首次出現，此流程會前進至步驟506；否則就會前進至決策步驟508。以下之虛擬程式碼可說明步驟504之運作：if (freq_tbl[this_symbol_val].freq == 1)
在決策步驟506，分類引擎104將符號插入分類列403之尾端(如尾端指標407指向之項目)並更新尾端指標407(例如使尾端指標407遞增)。此流程終止於步驟506。以下之虛擬程式碼可說明步驟506之運作：freq_tbl[this_symbol_val].sorted_idx = tail_ptr sorted_list[tail_ptr] = this_symbol_val increment tail_ptr
在決策步驟508，分類引擎104確認此符號是否位於分類列403之頂端。若是，此流程終止於此；否則，此流程會前進至步驟512。以下之虛擬程式碼可說明步驟508之運作：if (freq_tbl[this_symbol_val].sorted_idx == 0)
在決策步驟512，分類引擎104確認此符號之頻率402是否大於頻率列403中位於其上方之符號的頻率402。若是，流程前進至步驟514；否則，流程前進至步驟516。以下之虛擬程式碼可說明步驟512之運作：X = freq_tbl[this_symbol_val].freq this_sorted_idx = freq_tbl[this_symbol_val].sorted_idx above_symbol_val = sorted_list[this_sorted_idx - 1] Y = freq_tbl[above_symbol_val].freq if (X > Y)
在步驟514中，分類引擎104將此符號於分類列403中向上移動。也就是說，分類引擎104會將此符號於分類列403中之位置與位於其上方項目內符號之位置互換。這不只涉及更新分類列403中相關項目之符號值406，還涉及更新頻率表401之相關項目之分類索引404值。流程會由步驟514回到步驟508，來判斷此符號是否需要在分類列403中再次向上移動。以下之虛擬程式碼可說明步驟514與步驟522之運作：decrement freq_tbl[this_symbol_val].sorted_idx increment freq_tbl[above_symbol_val].sorted_idx sorted_list[this_sorted_idx] = above_symbol_val sorted_list[this_sorted_idx - 1] = this_symbol_val
在決策步驟516中，分類引擎104確認此符號之頻率402是否等於分類列403中位於其上方之符號的頻率402。若是，流程前進至決策步驟518；否則就終止。以下之虛擬程式碼可說明步驟516之運作：X = freq_tbl[this_symbol_val].freq this_sorted_idx = freq_tbl[this_symbol_val].sorted_idx above_symbol_val = sorted_list[this_sorted_idx - 1] Y = freq_tbl[above_symbol_val].freq if (X == Y)
在決策步驟518，分類引擎104確認此符號 值的詞彙順序是否早於分類列403中位於其上方之符號，也就是確認此符號是否具有一較小的值。若是，流程前進至步驟522；否則就終止。以下之虛擬程式碼可說明步驟518之運作：if (this_symbol_val < sorted_list[this_symbol_val-1])
在步驟522中，分類引擎104將符號於分類列403中向上移動，類似於前述步驟514。流程會從步驟522回到決策步驟516，判斷此符號是否需要在分類列403中再次向上移動。
第六圖係一方塊圖，顯示第四圖之頻率表401、分類列403與尾端指標407經分類引擎104進行更新的情形。第六圖顯示頻率表401與分類列403在分類引擎104已執行所接收之符號27後的狀態。特別是，分類引擎104會依據第五圖之步驟502，使頻率表401之索引27處的頻率402由180增加至181。此外，分類引擎會依據第五圖之步驟512確認符號27之頻率402，其值為181，現在大於在第四圖分類列403中位於其上方之符號的頻率402，也就是符號1，其頻率為180。因此，分類引擎104就會依照第五圖之步驟514，將分類列403中符號27與符號1之位置互換。此步驟涉及將項目24之符號值406從1變更為27，將項目25之符號值406從27變更為1，也涉及互換其相對應之分類索引404值。就一實施例而言，分類引擎104會將符號1之分類索引404值從24增加至25，而將符號27之分類索引404值從25減少到24。第六圖中係以灰底方塊顯 示前述數值變更，並以虛線箭頭顯示相關聯的分類索引404指標值。
第七圖係一方塊圖，顯示第六圖之頻率表401、分類列403與尾端指標407經分類引擎104進行更新的情形。第七圖顯示第六圖之頻率表401與分類列403在分類引擎104再次執行所接收之符號27後的狀態。特別是，分類引擎104依據第五圖之步驟516確認符號27之頻率402，其值為181，等於第六圖之分類列403中位於其上方之符號的頻率402，也就是符號29，此符號之頻率也是181。分類引擎104並依據決策步驟518確認符號27之值的詞彙順序早於分類列403中位於其上方之符號29。於是，分類引擎104就會依照第五圖之步驟522，將分類列403中符號27與符號29之位置互換。此步驟涉及將項目23之符號值406從29變更為27，將項目24之符號值406從27變更為29，也涉及互換其相對應之分類索引404值。就一實施例而言，分類引擎104會將符號29之分類索引404值從23增加至24，而將符號27之分類索引404值從24減少到23。第七圖中係以灰底方塊顯示前述數值變更，並以虛線箭頭顯示相關聯的分類索引404指標值。
第八圖係一方塊圖，顯示第七圖之頻率表401、分類列403與尾端指標407經分類引擎104進行更新的情形。第八圖係顯示第七圖之頻率表401與分類列403在分類引擎104執行所接收之符號283後的狀態。特別是，分類引擎104會依據第五圖之步驟502，使頻率表401之索引283處的頻率402由0增加至1。此外，分類引擎會 依據第五圖之決策步驟504確認符號283是否首次出現。是以，分類引擎104就會依照第五圖之步驟506，將符號283插入分類列403之尾端，即第八圖中分類列403之索引278處。這涉及將符號值283插入由第七圖之尾端指標407指向之項目的符號值406欄位，即項目278，這亦涉及將第七圖之尾端指標407，其值為278，儲存至頻率表401之項目283的分類索引404中。分類引擎104並使尾端指標407從278增加至279。第八圖中係以灰底方塊顯示前述數值變更，並以虛線箭頭顯示相關聯的分類索引404指標與尾端指標407值。
利用第三至八圖所述之操作，分類引擎104可以有效地在LZ77引擎102完成或接近完成掃描輸入區塊時，提供以頻率與詞彙順序進行分類之符號列403。換言之，符號分類時間(如第十圖之時序圖中方塊1003所示)-除了可能出現之對於分類列中關聯於最後一個標記之符號進行更新所需之時間-會與LZ77引擎102掃描輸入區塊之時間(如第十圖之時序圖中方塊1002所示)重疊，因此相較於第九圖之傳統壓縮方式，本發明可以減少總壓縮時間。此外，在大部分的情況下，更新分類列403中關聯於LZ77輸出標記串流之最後標記212之符號位置所費的時間會相當少。這是因為，此時，頻率表401之頻率分布，相對而言很可能是呈現不均勻的狀態，因此在大部分的情況下，此最後標記之頻率402的遞增過程將不需要對分類列403進行更新，而很可能只需要單一個向上移動的步驟。此最後符號通常是一區塊 終點(end-of-block)符號，這個符號在處理過程中從未見過，因而將會被插入分類列的尾端。分類引擎104會對此而不具有背向指標之區塊終點符號的詞彙執行一特殊檢測，因此霍夫曼編碼表之建構過程就不需因為此區塊終結符號而產生延遲。
第九圖係一時序圖，以圖形顯示傳統上對DEFLATE型輸入區塊進行壓縮所費時間的各個部分。如方塊902之步驟所示，在壓縮開始時掃描輸入區塊並產生一LZ77標記串流，同時維持一直方圖以顯示符號出現頻率。在方塊902之步驟完成後，在方塊903所示之步驟中，符號會依其頻率順序進行分類。在方塊903之步驟完成後，在方塊904所示之步驟中，就會利用前述以頻率進行分類的符號來建構霍夫曼編碼表。在方塊904之步驟完成後，在方塊906所示之步驟中，就會使用前述霍夫曼編碼表來對輸入區塊進行霍夫曼編碼，亦即對LZ77輸出標記串流進行霍夫曼編碼。前述關聯於方塊902,903,904與906操作係依其順序連續地執行。因此，總壓縮時間就會是關聯於方塊902,903,904與906所費時間之總和。
第十圖係一時序圖，以圖形顯示依據本發明同步符號列分類之實施例，對DEFLATE型輸入區塊進行壓縮所費時間的各個部分。如方塊1002之步驟所示，在壓縮開始時，LZ77引擎102掃描輸入區塊記憶體101內之字元輸入區塊並產生一標記212串流，例如重複第三圖之步驟302至308以產生標記212。在壓縮開始後沒多久，即LZ77引擎102產生第一個標記212時，如方塊1003所示 之步驟中，分類引擎104會持續地依據符號出現頻率以及當頻率相同時依照詞彙順序進行分類之符號列，如第三圖之步驟312至318所示。方塊1003之步驟所費的時間基本上可以被涵蓋在執行方塊1002之步驟所費的時間內。如前所述，這是因為對於大部分的標記而言，分類引擎104因應LZ77引擎102產生之標記而依據第三圖之步驟316維持分類列所需之時間，係涵蓋在LZ77引擎102依據第三圖之步驟302產生下一個標記所費的時間內。
當LZ77引擎102完成對於字元輸入區塊之掃描，以及(在必要時)分類引擎104因應關聯於最後標記212之符號完成對於分類列403之更新後，在方塊1004之步驟中，霍夫曼編碼表建構引擎106會使用分類列403來建構霍夫曼編碼表。隨後，在方塊1006所示之步驟中，霍夫曼編碼引擎108會對此字元輸入區塊進行利用由方塊1004之步驟所建構之霍夫曼編碼表進行編碼-或者更精確地說，利用LZ77引擎102產生之背向指標與輸入區塊中不被取代之詞彙進行之取代動作-並將壓縮輸出寫入輸出記憶體109。(霍夫曼編碼表也會經霍夫曼編碼後被寫入輸出記憶體，而讓解壓器可以重建此用於壓縮之霍夫曼編碼表。)。透過比較第九圖與第十圖可以發現，相較於傳統的壓縮方式，分類引擎104維持分類符號列與LZ77引擎102掃描輸入區塊之操作同時進行，可以減少總壓縮時間。
第十一A圖係一方塊圖，顯示本發明另一實施例之分類列403。在第十一A圖之實施例中，分類列 403之各個項目並包含關聯於符號值406之一霍夫曼編碼1108與位元長度1112。如此，霍夫曼編碼建構引擎106就可為此分類列403符號，指派霍夫曼編碼1108、與相關聯的位元長度1112。就一實施例而言，霍夫曼編碼表建構引擎106可依據典型之霍夫曼編碼程序來指派霍夫曼編碼1108。位元長度1112表示霍夫曼編碼1108之位元數。第十一A圖所示之分類列403可搭配第四圖之頻率表401作為一霍夫曼編碼表。也就是說，對於一給定符號值(例如DEFLATE型詞彙/長度表之值0至285，或DEFLATE型距離表之值0至29)，此符號值會作為頻率表401之索引，以確認此符號之分類索引404值，而此分類索引404值隨後會做為第十一A圖之分類列403之索引，以取得關聯於此符號之霍夫曼編碼1108。避免間接層(level of indirection)以實現霍夫曼編碼表之另一個實施例在後續第十一B圖會進行說明。
第十一B圖係一方塊圖，顯示本發明另一實施例之頻率表401。在第十一B圖之實施例中，頻率表401之各個項目並包含關聯於一符號之一霍夫曼編碼欄位1108與一位元長度1112，而此符號之數值係作為頻率表401之索引。如此，霍夫曼編碼表建構引擎106就可為此數值作為頻率表401索引之符號，指派霍夫曼編碼1108與相關聯的位元長度1112，因而可建構一直接查找(direct lookup)霍夫曼編碼表作為頻率表401之一部分(例如第十圖之方塊1004所示)。
第十二圖係一方塊圖，顯示第一圖之硬體 資料壓縮器100之另一實施例。第十二圖之硬體資料壓縮器100包含一分類列變更旗標1202與一分類列未變更計數器1204。每一次分類引擎104變更分類列403(如步驟514與522)，分類引擎104就會設定分類列變更旗標1202並重設分類列未變更計數器1204。每一次霍夫曼編碼表建構引擎106成功地利用分類列403完成霍夫曼編碼表之建構後(如方塊1004所示)，它就會清除分類列變更旗標1202。若是霍夫曼編碼表建構引擎106在建構霍夫曼編碼表之過程中而分類引擎104變更分類列403時，霍夫曼編碼表建構引擎106就會停止建構霍夫曼編碼表，然後再一次重新開始建構。每一次當LZ77引擎102產生之標記212不需變更分類列403時，分類引擎104就會遞增分類列未變更計數器1204之計數。關於分類列變更旗標1202與分類列未變更計數器1204之使用可參照後續第十三圖之實施例。
第十三圖係一時序圖，以圖形顯示依據本發明另一實施例進行壓縮所費時間的各個部分。第十三圖之實施例類似於第十圖之實施例，不過在第十三圖之實施例中，方塊1004是由方塊1304所取代。在方塊1304之步驟中，霍夫曼編碼表建構引擎之運作與LZ77壓縮引擎102執行方塊1002所示掃描輸入區塊之運作同時進行，並且與分類引擎104執行方塊1003將霍夫曼編碼1108指派給分類列403之符號值406以維持分類列403之運作同時進行。如此，方塊1304之步驟中，利用分類列403建構霍夫曼編碼表所需之時間，會大部分重疊並涵蓋於 方塊1002之輸入區塊掃描時間與方塊1003之分類列維持時間，因而可以進一步降低總壓縮時間。就一實施例而言，第十三圖之實施例會使用分類列變更旗標1202，以及選擇性地使用第十二圖之分類列非變更計數器1204。也就是說，每一次分類引擎104變更分類列403(如步驟514與522)，分類引擎104就會設定分類列變更旗標1202並通知霍夫曼編碼表建構引擎106，而霍夫曼編碼表建構引擎106隨即利用分類列403之符號值406開始建構霍夫曼編碼值1108。若是霍夫曼編碼表建構引擎106在分類引擎104再次變更分類列403之前，成功地完成霍夫曼編碼表之建構，霍夫曼編碼表建構引擎106就會清除分類列變更旗標1202。而在方塊1002掃描輸入區塊之步驟完成後，如方塊1006之步驟所示，一旦分類列變更旗標1202被清空，霍夫曼編碼引擎108就會開始對輸入區塊進行霍夫曼編碼。如此，方塊1304之步驟中建構霍夫曼編碼表之部分-在某些情況下則是全部-的時間會重疊並涵蓋於方塊1002之輸入區塊掃描時間與方塊1003之分類列維持時間內。
在一實施例中，霍夫曼編碼表建構引擎106在每一次分類引擎104變更分類列403的時候，都會建構霍夫曼編碼值1108。不過，在另一實施例中，霍夫曼編碼表建構引擎106只在分類引擎104變更分類列403而分類列未變更計數器1204顯示在分類引擎104最後一次變更分類列403後已出現一預設數量之標記212時，才會建構霍夫曼編碼值1108。前述預設數量可程式調整。如 此，硬體資料壓縮器100之耗能可以降低，並且可以緩和表單記憶體107存取壅塞(access congestion)的問題。因為在方塊1002對輸入區塊進行掃描之過程中，霍夫曼編碼表建構引擎106會較不頻繁地執行方塊1304之操作。前述實施例係利用分類列未變更計數器1204來縮減或霍夫曼編碼表之建構時間，不過本發明並不限於此。舉例來說，霍夫曼編碼表建構引擎106可以在分類引擎變更分類列403，並且在分類引擎104最後一次變更分類列403後已出現一預設數量之符號，而非一預設數量之標記212的時候，開始建構霍夫曼編碼值1108。在另一個例子中，霍夫曼編碼表建構引擎106可以在分類引擎變更分類列403，並且在分類引擎104最後一次變更分類列403後已經過一預設數量之時鐘週期，而非一預設數量之標記212的時候，開始建構霍夫曼編碼值1108。
值得注意的是，在掃描輸入區塊之初期，通常需要頻繁地變更分類列403，因為此時頻率分布相對而言很可能時比較均勻的。不過在掃描輸入區塊之後期通常就不需要頻繁地變更分類列403，因為此時的頻率分布相對而言很可能是比較不均勻的。因此，在某些情況下，霍夫曼編碼表建構引擎106最後一次建構霍夫曼編碼值1108的運作會在完成輸入區塊之掃描前開始進行，而在某先情況下，霍夫曼編碼表建構引擎106最後一次建構霍夫曼編碼值1108的運作會在完成輸入區塊之掃描前完成。例如，若是最後N個標記212都不會導致分類列403變更，LZ77引擎102掃描輸入區塊以產生最後N個標記所 花費的時間，就至少會與霍夫曼編碼表建構引擎106由分類列403建構霍夫曼編碼表所花費的時間相同。
需要注意的是，本文描述之硬體資料壓縮器係利用分類引擎依據標記串流之出現頻率維持一分類符號列，而此操作係與利用無損壓縮演算方式之壓縮引擎(如LZ77引擎)產生此標記串流之步驟同時進行，不過本發明並不限於此。在另一實施例中，分類引擎依據標記串流之出現頻率維持一分類符號列，而此操作與利用破壞性壓縮(lossy compression)演算方式(如JPEG,MPEG,MP3)之壓縮引擎產生此標記串流之步驟同時進行。此壓縮引擎之輸出會再利用一分類符號列透過一編碼引擎進行編碼(如霍夫曼編碼)，以產生編碼表。
值得注意的是，利用傳統方式對符號列進行分類(即非如本文所述以遞增方式且與掃描輸入區塊之操作同步者)通常是屬於記憶存取密集(memory intensive)之操作。這對於軟體資料壓縮程式(如gzip)而言並不會構成問題，因為軟體資料壓縮程式通常可以使用大量的記憶體，如系統記憶體。不過基於成本與效能的考量，硬體資料壓縮器傾向於使用相對較小的記憶體，因為越大的記憶體就會產生越多的存取遲延。因此，在對輸入區塊進行掃描之過程中，以遞增方式同步維持分類列，對於硬體資料壓縮器特別有助益。
“動態-初期(Dynamic-Prime)”霍夫曼編碼
第十四A圖係一流程圖，顯示第一圖之 LZ77引擎102配合動態初期霍夫曼編碼執行資料壓縮之處理程序。就一實施例而言，在第十四A圖中，LZ77引擎102係配合第十四B圖之霍夫曼編碼表建構引擎106與第十四C圖之霍夫曼編碼引擎108共同運作，而使這三個程序中有相當多的部分是同步運作的，以達成如第十六圖所示對於字元輸入區塊進行硬體資料壓縮之目的。此流程始於步驟1402。
在步驟1402中，LZ77引擎102初始化輸入區塊內之一當前搜尋目標位置。就一實施例而言，此硬體資料壓縮器100包含一暫存器(未圖示)以儲存搜尋目標位置之值。此當前搜尋目標位置係字元輸入區塊之索引。就一實施例而言，此搜尋目標位置係經初始化以指向輸入區塊之第二個字元。接下來流程前進至步驟1404。
在步驟1404中，LZ77引擎102對於一開頭位於搜尋目標位置之字串，在輸入區塊中搜尋字串匹配。也就是說，LZ77引擎102從輸入區塊之搜尋目標位置開始取得一字元字串-即目標字串-並在輸入區塊內搜尋出現在前並與之匹配之字串。一般而言，LZ77引擎102會在輸入區塊搜尋它所能找到的最長匹配字串。不過LZ77引擎102可能會限制所搜尋之字串長度，以縮短搜尋時間並/或限制背向指標之最大長度。此外，LZ77引擎102可以限制其由當前搜尋位置回溯之搜尋範圍，以縮短搜尋時間並/或限制背向指標之最大距離。LZ77引擎102可以利用各種不同的技術於輸入區塊內回溯搜尋當前掃描位置之字串的匹配，如本文第二十四與二十五圖所述 使用雙散列表(dual hash table)的實施例。接下來前進至步驟1406。
在步驟1406中，LZ77引擎102產生一標記212。如前述，此標記212係一背向指標或是來自輸入區塊之詞彙。在一實施例中，從輸入區塊產生一詞彙，就只是將此詞彙留在輸入區塊記憶體101，而使其於後續程序能由霍夫曼編碼引擎108讀取並使用動態初期霍夫曼編碼表進行編碼。在一實施例中，如前述，背向指標被寫入背向指標記憶體105，而記憶體105內對應於輸入區塊中位於待取代或匹配目標字串之開始處的字元位置之旗標會被設定，以表示存在一個要進行取代之背向指標。LZ77引擎102並會更新搜尋目標位置。就一實施例而言，若是LZ77引擎102產生一背向指標，LZ77引擎102就會從搜尋目標位置增加此匹配字串之長度；不過，若是LZ77引擎102產生詞彙，LZ77引擎102就會以所產生之詞彙數量來移動搜尋目標位置。在具有分類引擎104之實施例中，如第三圖之步驟316所示，分類列403也會被更新。接下來流程前進至決策步驟1408。
在決策步驟1408中，LZ77引擎102會確認是否已完成對於輸入區塊之開始部份的掃描，以通知開始建構動態初期霍夫曼編碼表。是否完成輸入區塊之開始部分可由多種不同方式來確認。在一實施例中，LZ77引擎102會在其完成掃描一預設數量之輸入字元(例如3,000個字元)後，認定其已完成此開始部分之掃描。在一實施例中，LZ77引擎102會在其完成掃描輸入區塊大 小之一預設比例(例如輸入區塊之字元之前十分之一)後，認定其已完成此開始部分之掃描。在一實施例中，當符號空間之符號總數大於一第二預設值，而這些符號已被觀察至少一第一預設次數(例如一、二、三)，LZ77引擎102就會認定其已完成此開始部分之掃描。舉例來說，假定第一預設次數為三，硬體資料壓縮器100每次使頻率402增加到數值三，它就會使一初始化為零的計數器開始遞增。而當此計數器達到第二預設值(如85)時，就完成開始部分之掃描。此第二預設值亦可以是符號空間內符號數量之一預設比例(如33%)。在一實施例中，如第十八與十九圖所述，分類引擎104基於在分類列403中出現的變化來確認輸入區塊之開始部分。在一實施例中，此開始部分可由使用者定義，例如一硬體資料壓縮器100之壓縮指令的運算元。值得注意的是，一般而言，如果要改善壓縮效率，就須選用數值較大的開始部分，但需要犧牲壓縮速度；如果要提升壓縮速度，就須選用較小的開始部分，但需要犧牲壓縮效率。若是LZ77引擎102已完成對於輸入區塊之開始部分的掃描程序，流程就會前進至步驟1412；否則，流程就會前進至步驟1414。
在步驟1412中，LZ77引擎102通知霍夫曼編碼表建構引擎106來建構霍夫曼編碼表。也就是說，在輸入區塊之開始部份完成掃描的時候，才可以建構霍夫曼編碼表(如第十四B圖之步驟1424所示)，也才能開始霍夫曼編碼程序(如第十四C圖之步驟1434所示)。流程會回到步驟1404依據更新後的搜尋目標位置來搜尋匹 配。需要理解的是，雖然第十四A圖之流程似乎表示每次完成開始部分之掃描程序後就會依循步驟1404、1406與1408之途徑通知建構霍夫曼編碼表，不過此通知步驟只會執行一次。
步驟1414會對關連於步驟1406所產生之標記212的各個符號，更新其頻率402。在一實施例中，分類引擎104會遞增各個符號的頻率402。在另一實施例中，不具有分類引擎104，而是由LZ77引擎102遞增各個符號的頻率402。在又一實施例中，不具有分類引擎104，而是由LZ77引擎102產生標記212提供給霍夫曼編碼表建構引擎106，再由霍夫曼編碼表建構引擎106遞增各個符號的頻率402，前述提供步驟類似於第二A圖中由LZ77引擎102產生標記212提供給分類引擎104之步驟。流程接下來會回到步驟1404，依據更新後的搜尋目標位置來搜尋匹配。需要注意的是，流程在抵達輸入區塊尾端(例如接觸到塊字元的尾端)後隨即終止，而不經由步驟1412、1414或1416再回到步驟1404，接下來則會對下一個輸入區塊重複第十四A圖之運作。
如前述，一旦完成對於輸入區塊之開始部分的掃描程序，就不再更新頻率表401內的頻率402。當硬體資料壓縮器100掃描輸入區塊時，一旦完成輸入區塊之開始部分的掃描程序，硬體資料壓縮器100就會停止更新頻率表401。如此可以減少對於表單記憶體107之存取次數，以降低能耗並緩和存取表單記憶體107之衝突狀況，使其他引擎可以更快速地存取表單記憶體以提升效 能，這個優點在表單記憶體的存取埠由多個引擎共享之實施例中特別明顯。此外，此技術有利於使用存取埠數量較少之記憶體，而能縮減設計尺寸。
第十四B圖係一流程圖，顯示第一圖之霍夫曼編碼表建構引擎106配合動態初期霍夫曼編碼執行資料壓縮之運作。流程始於步驟1422。
在步驟1422中，霍夫曼編碼表建構引擎106接收一信號，通知建構霍夫曼編碼表。在一實施例中係由LZ77引擎102通知霍夫曼編碼表建構引擎106建構霍夫曼編碼表。在一實施例中係由分類引擎104通知霍夫曼編碼表建構引擎106建構霍夫曼編碼表。接下來流程前進至步驟1424。
在步驟1424中，霍夫曼編碼表建構引擎106利用只有輸入區塊之開始部分掃描後，也就是霍夫曼編碼表建構引擎106在步驟1422收到通知的時點，產生之頻率表401與其頻率402值，建構動態初期霍夫曼編碼表。第十七A至十七C圖顯示建構動態初期霍夫曼編碼表之實施例。流程前進至步驟1426。
在步驟1426中，霍夫曼編碼表建構引擎106通知霍夫曼編碼引擎108開始對輸入區塊進行霍夫曼編碼程序。此流程終止於步驟1426。
第十四C圖係一流程圖，顯示第一圖之霍夫曼編碼引擎108配合動態初期霍夫曼編碼執行資料壓縮之運作。流程始於步驟1432。
在步驟1432，霍夫曼編碼引擎108接收第 十四B圖之步驟1426所產生之信號，開始對輸入區塊進行霍夫曼編碼。接下來前進至步驟1434。
在步驟1434，霍夫曼編碼引擎108利用步驟1424所建構之霍夫曼編碼表對整個輸入區塊進行編碼。也就是說，霍夫曼編碼引擎108利用步驟1424中只有輸入區塊之開始部分被掃瞄時所建構之霍夫曼編碼表，對背向指標與整個輸入區塊中未被取代的詞彙執行霍夫曼編碼，並將霍夫曼編碼輸出(連同霍夫曼編碼表之霍夫曼編碼版本)儲存至輸出記憶體109。流程終止於步驟1434。
第十五圖係一時序圖，以圖形顯示傳統上對DEFLATE型輸入區塊進行壓縮所費時間的各個部分。如方塊1502之步驟所示，在壓縮開始時掃描整個輸入區塊並產生一LZ77標記串流，同時維持一直方圖顯示符號出現頻率。一旦完成方塊1502之步驟，如方塊1504所示，就會利用由整個輸入區塊取得的符號頻率來建構霍夫曼編碼表。完成方塊1504之步驟後，如方塊1506所示，就會利用霍夫曼編碼表來對輸入區塊進行霍夫曼編碼程序，也就是對LZ77標記輸出串流進行霍夫曼編碼程序。前述關聯於方塊1502,1504與1506之操作係依其順序連續地執行。因此，總壓縮時間就會是關聯於方塊1502,1504與1506所費時間之總和。
第十六圖係一時序圖，以圖形顯示依據本發明之動態初期霍夫曼編碼表對DEFLATE型輸入區塊進行壓縮所費時間的各個部分。如方塊1602-A之步驟所 示，在壓縮開始時，LZ77引擎102掃描輸入區塊記憶體101內之字元輸入區塊之開始部分並產生一標記212串流，如本文重複第十四A圖之步驟所產生之標記212(以及第三圖之步驟302至308)。在完成對於輸入區塊之開始部分之掃描程序後，就會收到建構霍夫曼編碼表之信號(如依據第十四A圖之方塊1412所執行之步驟)，然後如方塊1604所示，霍夫曼編碼表建構引擎106就利用方塊1602-A之步驟，對輸入區塊之開始部分進行掃描之過程中所維持之頻率表401的頻率402來建構霍夫曼編碼表(如依據第十四B圖之方塊1424所執行之步驟)。此外，如方塊1602-B所示，LZ77引擎會持續掃描輸入區塊記憶體101內字元輸入區塊之剩餘部分，以產生標記212串流。
一旦霍夫曼編碼表建構引擎106利用方塊1604所示之開始部分頻率建構出動態初期霍夫曼編碼表，如方塊1606所示，霍夫曼編碼引擎108就會利用此動態初期霍夫曼編碼表對整個輸入區塊進行霍夫曼編碼程序(或更精確來說，由LZ77引擎102產生之背向指標與輸入區塊中未被取代之詞彙所進行之取代動作)，並將壓縮輸出寫入輸出記憶體109。基本上，因為動態初期霍夫曼編碼表利用對於輸入區塊之開始部分進行掃描所取得之符號出現頻率來建構，而非如傳統方式係對於整個輸入區塊進行掃描，因此，方塊1604與1606之運作時間可以涵蓋於方塊1602-B之運作時間內。透過比較第十五與十六圖可以發現，相較於傳統方式，使用本發明之動態初期霍夫曼編碼表-即由掃描輸入區塊開始部分取得之 出現頻率來建構之霍夫曼編碼表-可以縮短總壓縮時間。
第十七A圖係一流程圖顯示硬體資料壓縮器100建構動態初期霍夫曼編碼表之運作之一實施例。此流程始於步驟1702。
在步驟1702中，頻率表401之頻率402被初始化為零，此初始化步驟可由如LZ77引擎102、分類引擎104或霍夫曼編碼表建構引擎106來執行。接下來流程前進至步驟1704。
在步驟1704中，LZ77引擎102掃描輸入區塊之開始部分，並遞增關聯於所產生標記之符號的頻率402(可由如LZ77引擎102、分類引擎104或霍夫曼編碼表建構引擎106執行)。接下來流程前進至步驟1706。
在步驟1706中，在建構霍夫曼編碼表之開始部分(如方塊1604所示)，對符號空間內各個具有零頻率值之符號(如詞彙與長度表401之符號值0至285與距離表401之符號值0至29)而言，此霍夫曼編碼表建構引擎106(在另一實施例中也可以是分類引擎104)將此零頻率值以非零值取代。就一實施例而言，此非零值是一個小的數值，例如數值1。如此，在建構霍夫曼編碼表時，對於符號空間之各個符號值都會存在一霍夫曼編碼。此步驟是不可或缺的，如前述，這是因為掃描輸入區塊之開始部分的過程中(如方塊1602-A所示)未出現的符號，仍然可能出現在掃描輸入區塊之剩餘部分的過程中(如方塊1602-B所示)。而當霍夫曼編碼引擎108對輸入 區塊進行霍夫曼編碼程序時，它將需要動態初期霍夫曼編碼表內符號的霍夫曼編碼值(如方塊1606所示)。接下來流程前進至步驟1708。
在步驟1708中，霍夫曼編碼表建構引擎106利用步驟1702至1706所產生之頻率表401的頻率402來建構霍夫曼編碼表。重要的是，所建構的動態初期霍夫曼編碼表會包含符號空間之各個符號的霍夫曼編碼值，因為各個符號都具有一非零頻率402值。如前述，就一實施例而言，霍夫曼編碼表建構引擎106係建構典型之霍夫曼編碼表。此流程終止於此。
第十七B圖係一流程圖，顯示硬體資料壓縮器100建構動態初期霍夫曼編碼表之運作之一實施例。此流程始於步驟1712。
在步驟1712中，頻率表401之頻率被初始化為零，或其他非零數值。將各個頻率402都初始化為非零數值之結果為，霍夫曼編碼表建構引擎106將會對動態初期霍夫曼編碼表(例如由步驟1718建構霍夫曼編碼表)之符號空間之各個符號都指派一霍夫曼編碼。接下來流程前進至步驟1714。
在步驟1714中，LZ77引擎102掃描輸入區塊之開始部分，並如同前述步驟1704所述，遞增關聯於所產生標記之符號的頻率402。接下來前進至步驟1718。
在步驟1718中，霍夫曼編碼表建構引擎106利用步驟1712至1714所產生之頻率表401的頻率402來建構霍夫曼編碼表。重要的是，所建構的動態初期霍 夫曼編碼表會包含符號空間之各個符號的霍夫曼編碼值，因為步驟1712之初始化過程已確保各個符號都具有一非零頻率402值。此流程終止於此。
第十七C圖係一流程圖，顯示硬體資料壓縮器100建構動態初期霍夫曼編碼表之運作之一實施例。此流程始於步驟1722。
在步驟1722中，頻率表401之頻率402被初始化為一組非零數值，此組非零數值係從關聯於符號空間之符號之一組預編譯非零數值中予以選定。也就是說，不同於第十七B圖所執行之步驟1712對各個符號的頻率402都指派相同的非零數值，在步驟1722中，依據先前已知(即對輸入區塊進行壓縮前)符號空間之符號的相對頻率的發生或然率，將符號頻率初始化至修正過的數值。舉例來說，眾所皆知，長度較短的背向指標長度通常會有較高的出現頻率。因此，這組預編譯非零頻率可包含相對較大的非零頻率值提供給符號空間內長度較短的背向指標長度。在另一個例子中，假定此輸入區塊係ASCII字元文字。眾所皆知，在輸入區塊中ASCII“E”出現頻率高於ASCII“Z”的可能性很高。因此，這組預編譯非零頻率可以對ASCII“E”提供一較大的非零頻率值。如此，這些初始非零數值係基於教育過的猜測來調整頻率402，而非對各個符號都初始化為相同的非零數值。此處理方法的優點在於，如前述第二A至八圖使用分類引擎104之實施例提及，提升頻率表401之頻率402之初始值的不均勻程度可以減少需要的分類程序，也就 是減少如第五圖之步驟514與522所示在分類列403中交換符號位置的次數。在一實施例中提供硬體資料壓縮器100多個預編譯非零數值組，硬體資料壓縮器100依據一準則來選擇其中一個預編譯組，例如依照輸入區塊之來源檔案類型(如影像檔、音樂檔、文字檔、一電子表單、由文字處理器或簡報應用程式，或其他類型的檔案)。接下來前進至步驟1724。
在步驟1724中，LZ77引擎102掃描輸入區塊之開始部分，並如同前述步驟1704所述，遞增關聯於所產生之標記之符號的頻率402。接下來前進至步驟1728。
在步驟1728中，霍夫曼編碼表建構引擎106利用步驟1722至1724產生之頻率表401頻率來建構霍夫曼編碼表。重要的是，所建構的動態初期霍夫曼編碼表會包含符號空間之各個符號的霍夫曼編碼值，因為步驟1722之初始化過程已確保各個符號都具有一非零頻率402值。此流程終止於此。
第十八圖係一方塊圖，顯示第一圖之硬體資料壓縮器100之硬體之一實施例。第十八圖之硬體資料壓縮器100包含一分類列變更計數器(sorted list change counter,SLCC)1804、一臨界值1806、一符號倒數計數器(symbol countdown counter,SCDC)1808、與連接至前述各元件之邏輯1802。臨界值1806可以是一可程式化暫存器。分類列變更計數器1804顯示前一次重置分類列變更計數器1804後，分類列403變更(如步驟514或522所示) 之次數的計算值。符號倒數計數器1808係先載入一預設值，而在每次符號頻率402增加時(如步驟1414所示)進行遞減。當符號倒數計數器1808倒數至零的時候，若是分類列變更計數器1804的數值小於臨界1806值，邏輯1802就會通知建構霍夫曼編碼表，否則就會再次將預設值載入符號倒數計數器1808，這部分在第十九圖會有更詳細的說明。就一實施例而言，第十八圖之硬體係包含於分類引擎104內，而非包含於LZ77引擎102內(如第十四A圖之步驟1412所示)，分類引擎104會通知霍夫曼編碼表建構引擎106建構霍夫曼編碼表(如第十九圖之步驟1916所示)。在一實施例中，計數器1808係在每次標記產生時就進行遞減，而非在每次符號頻率402增加時。在一實施例中，計數器1808係在每個時鐘週期都進行遞減，而非在每次符號頻率402增加時。
第十九圖係一流程圖，顯示分類引擎104通知建構霍夫曼編碼表之處理程序。此流程始於步驟1902。
在步驟1902中，分類引擎104使第十八圖之分類列變更計數器1804初始化為零。接下來流程前進至步驟1904。
在步驟1904中，分類引擎104將一初始數，或一預設值(如100)，載入符號倒數計數器1808。接下來流程前進至步驟1906。
在步驟1906中，分類引擎104由LZ77引擎102接收一標記212，並因應各個關聯於此標記212之符 號，遞減符號倒數計數器1808的數值。此外，若依據關聯於標記212的符號需要變更分類列403，分類引擎104還會遞增符號列變更計數器1804的數值。接下來前進至決策步驟1908。
在決策步驟1908中，邏輯1802確認符號倒數計數器1808之數值是否到達零。若是，流程前進至決策步驟1912；否則，流程就回到步驟1906等待下一個標記212。
在決策步驟1912，邏輯1802確認分類列變更計數器之數值是否小於臨界1806值。若是，流程前進至步驟1914；否則，流程會回到步驟1904。
在步驟1914中，邏輯1802通知霍夫曼編碼表建構引擎106建構霍夫曼編碼表。在一實施例中，分類引擎104需於輸入區塊內至少一最低數量之字元完成掃描後(如500或5%)，才會通知建構霍夫曼編碼表。流程終止於此。
第二十圖係一時序圖，以圖形顯示本發明對DEFLATE型輸入區塊進行壓縮所費時間的各個部分之另一實施例。如同前文關於第十四A至十九圖之說明，在完成輸入區塊之開始部分的掃描步驟後就開始進行霍夫曼編碼程序可以減少總壓縮時間。第二十圖之實施例中不使用透過掃描輸入區塊開始部分維持的頻率來建構之動態初期霍夫曼編碼表，而是讓硬體資料壓縮器100在完成輸入區塊之開始部分的掃描程序後，就在多個預編譯霍夫曼編碼表中選擇其一對輸入區塊進行霍夫曼 編碼程序，使霍夫曼編碼之時間與對輸入區塊剩餘部分進行掃描之時間重疊。在本實施例中，在掃描輸入區塊之開始部分的過程中，硬體資料壓縮器100會持續追蹤使用各個預編譯霍夫曼編碼表進行壓縮所產生之壓縮輸出的尺寸。此硬體資料壓縮器100隨後選擇壓縮開始部分產生最小輸出之預編譯霍夫曼編碼表，並使用此選定的預編譯霍夫曼編碼表來對整個輸入區塊進行霍夫曼編碼程序。
在壓縮開始時，如方塊2002-A所述，LZ77引擎102掃描輸入區塊記憶體100內之字元輸入區塊之開始部分，並產生一標記212之串流。在完成輸入區塊之開始部分之掃描程序後，如方塊2003所述，硬體資料壓縮器100使用多個霍夫曼編碼表之預編譯對(如詞彙/長度表與距離表)之每一個，來計算(而非產生)利用此預編譯對將會產生之輸出尺寸，以對輸入區塊之開始部分進行霍夫曼編碼。此外，如方塊2002-B所述，LZ77引擎102持續掃描輸入區塊記憶體101內字元輸入區塊之剩餘部分，並產生一標記212之串流。
在完成輸入區塊之開始部分的掃描程序後，如方塊2004所述，硬體資料壓縮器100係於多個霍夫曼編碼表之預編譯對中選擇其一。隨後，如方塊2006所述，霍夫曼編碼引擎108使用此選定之霍夫曼編碼表預編譯對來對整個輸入區塊進行霍夫曼編碼程序，並將壓縮輸出結果寫入輸出記憶體109。如圖中所示，方塊2004至2006之運作時間可以涵蓋在方塊2002-B之運作時間 內，因而可以減少總壓縮時間。
相較於第十四A至十九圖之實施例，第二十圖之實施例可以減輕霍夫曼編碼表建構引擎106之負擔。不過，第十四A至十九圖之實施例之動態初期霍夫曼編碼表，除了能與第二十圖之實施例有相同優異的壓縮速度外，還具有額外的優點。對於某些輸入區塊，在第二十圖之實施例未具有理想的預編譯霍夫曼編碼表供硬體資料壓縮器100選擇之情況下，第十四A至十九圖之實施例可以產生較小的輸出。舉例來說，假定輸入區塊之字元係來自一較區域性的語言，因而不存在預編譯霍夫曼編碼表，例如匈牙利(Hungaria)萬國碼。在此情況下，相較於第二十圖使用霍夫曼編碼表預編譯對之實施例，第十四A至十九圖使用動態初期霍夫曼編碼之實施例較可能產生較小的輸出。
預先霍夫曼編碼程序對匹配字串或背向指標進行選擇性霍夫曼編碼
第二十一圖係一方塊圖，顯示第一圖之硬體資料壓縮器100之一部分。第一圖之LZ77引擎102與第一圖之表單記憶體107保持聯繫。表單記憶體107儲存有“參考”霍夫曼編碼表2102。此參考霍夫曼編碼表2102供LZ77引擎用以對一標記進行預先霍夫曼編碼程序以確認其尺寸，並確定是產生匹配字串之常值或是產生指向匹配字串之背向指標，這部分在第二十二與二十三圖會有更詳細的說明。此參考霍夫曼編碼表2102可以相同或 不同於霍夫曼編碼引擎108在後續霍夫曼編碼程序中對LZ77引擎102之輸出字串進行編碼之霍夫曼編碼表。
此LZ77引擎102包含邏輯以確認使用參考霍夫曼編碼表2102之兩個尺寸。第一個尺寸標示為尺寸X，其使用參考霍夫曼編碼表2102對匹配字串之詞彙符號，進行霍夫曼編碼所輸出之霍夫曼編碼的總位元數。也就是說，LZ77引擎會使用參考霍夫曼編碼表2102，確認各個詞彙符號之霍夫曼編碼的位元數，並將其相加產生一總數，此總數即為尺寸X。就一實施例而言，LZ77引擎102之邏輯會在參考詞彙霍夫曼編碼表2012平行查找各個詞彙符號，以確認各個詞彙符號之霍夫曼編碼位元數(如第十一B圖之位元長度1112)並將其加總以產生尺寸X。在一實施例中，邏輯係用以確認不超過一預設字元數(例如五)之字串的尺寸X，如此，若是字串長度大於此預設字元數，在後續步驟2206中就會假定尺寸X大於尺寸Y。第二個尺寸標示為尺寸Y，是使用參考霍夫曼編碼表2102指向匹配字串(假定存在一個匹配字串)之背向指標，進行霍夫曼編碼所輸出之霍夫曼編碼的總位元數。也就是說，LZ77引擎會使用參考霍夫曼編碼表2102，確認此指標之各個長度與距離之霍夫曼編碼的位元數(如第十一B圖之位元長度1112)，包含這些額外位元，並將其相加產生一總數，此總數即為尺寸Y。就一實施例而言，LZ77引擎102之邏輯會在參考長度與距離霍夫曼編碼表2012平行查找各個長度與距離符號，以確認各個長度與距離符號之霍夫曼編碼位元數 並將其加總以產生尺寸Y。
第二十二圖係一流程圖，顯示硬體資料壓縮器100壓縮資料之處理程序。此流程始於步驟2202。
在步驟2202中，LZ77引擎搜尋並找到位於當前搜尋目標位置之字串的匹配，並採用與前文描述之方式(如步驟302或步驟1404所採用之方式)相類似的方式，計算從當前搜尋目標位置指向匹配字串之背向指標。接下來流程前進至步驟2204。
在步驟2204中，LZ77引擎102確認第二十一圖所述之尺寸X與尺寸Y。也就是說，LZ77引擎102會就詞彙與背向指標之位元數進行預先霍夫曼編碼程序。接下來流程前進至決策步驟2206。
在決策步驟2206中，LZ77引擎102確認尺寸X是否小於尺寸Y。若是，流程前進至步驟2212；否則就前進至步驟2208。
在步驟2208中，LZ77引擎102產生步驟2202計算出來的背向指標。亦即，LZ77引擎102輸出背向指標(如步驟306或1406之方法)供霍夫曼編碼引擎108進行後續霍夫曼編碼程序。接下來流程前進至步驟2214。
在步驟2212中，LZ77引擎102產生此匹配字串之詞彙。也就是說，LZ77引擎102輸出一詞彙指標(如步驟306或1406之方法)供霍夫曼編碼引擎108進行後續霍夫曼編碼程序。接下來流程前進至步驟2214。
在步驟2214中，霍夫曼編碼引擎108對步驟2208或步驟2212產生之輸出，即匹配字串之背向指標 或詞彙，進行霍夫曼編碼程序。在一實施例中，霍夫曼編碼引擎108使用異於參考霍夫曼編碼表2102之霍夫曼編碼表，對背向指標或詞彙進行霍夫曼編碼程序。舉例來說，霍夫曼編碼引擎108用以對輸入區塊進行霍夫曼編碼(如步驟1006、1434、1606或2006)之霍夫曼編碼表，可以是在掃描輸入區塊之開始部分後所建構(如第十六圖)或選擇(如第二十圖)之霍夫曼編碼表，如此，在掃描輸入區塊開始部分之過程中，就需要使用參考霍夫曼編碼表2102來計算尺寸X與尺寸Y。也就是說，在依據第二十二圖之步驟2202至2212所執行之最佳化步驟時，就需要取得參考霍夫曼編碼表2102。即使用於計算尺寸X與尺寸Y之霍夫曼編碼表不同於最終用於對輸入區塊進行編碼之霍夫曼編碼表，第二十二圖之處理程序仍然有助於提升壓縮率，也就是可以縮減未使用第二十二圖處理程序之傳統方法的輸出大小。此流程終止於此。
就一實施例而言，此流程必須對LZ77引擎102產生之各個標記212執行第二十二圖之預先霍夫曼編碼處理，以供掃描整個字元輸入區塊。不過，如以下所述，在某些實施例中，需執行預先霍夫曼編碼程序之標記212只用於掃描部分輸入區塊，舉例來說，就使用動態初期霍夫曼編碼表之實施例中，即為完成輸入區塊開始部分之掃描程序後的剩餘部分。
現在請參照第二十三A圖，此圖係一流程圖顯示第二十二圖之步驟2204之一實施例。此流程始於步驟2302。
在步驟2302中，LZ77引擎102利用預編譯霍夫曼編碼表確認尺寸X與尺寸Y。此預編譯霍夫曼編碼表於硬體資料處理器100開始對字元輸入區塊進行壓縮前進行編譯。舉例來說，此預編譯霍夫曼編碼表可以是DEFLATE規範定義的固定霍夫曼編碼表，此規範之詞彙/長度表大致呈現於表3(變更部分以括弧表示)。DEFLATE規範定義之固定霍夫曼編碼表的距離碼031以(固定長度)5位元碼表示，可能出現之額外位元如前文表二所示。另外，此預先編譯霍夫曼編碼表可以是基於一具代表性之輸入區塊之符號頻率建構之霍夫曼編碼表或是多個具代表性之輸入區塊之一取樣來進行建構。在一實施例中，此預先編譯霍夫曼編碼表對於符號空間之每一個符號都包含有一個霍夫曼編碼。在另一實施例中，對於符號空間中之某些符號，LZ77引擎102不需為其計算尺寸X與尺寸Y，不需執行決策步驟2206之比較，以及執行步驟2208以產生背向指標，霍夫曼編碼表可將其霍夫曼編碼排除在外。
現在請參照第二十三B圖，此圖係一流程圖顯示第二十二圖之步驟2204之另一實施例。此流程開始並終止於步驟2312。
在步驟2312中，LZ77引擎利用如第十四A至二十圖之實施例所建構之動態初期霍夫曼編碼表確認尺寸X與尺寸Y。在本發明一實施例中，第二十二圖之處理程序需要在建構動態初期霍夫曼編碼表之後(如第十六圖之步驟1604所示)才會對標記執行，並且早於步驟2208所述LZ77壓縮引擎102產生背向指標之時點，而非計算尺寸X與尺寸Y並基於尺寸X與尺寸Y之關係選擇性地產生背向指標之時點。在另一實施例中，在建構動態初期霍夫曼編碼表之前利用參考霍夫曼編碼表2102來執行步驟2204，而在建構動態初期霍夫曼編碼表之後則是利用動態初期霍夫曼編碼表以執行步驟2204。
使用預先霍夫曼編碼程序之優點如下。某些傳統方式之LZ77壓縮演算法甚至不會考慮去搜尋三位元組字串之匹配並以背向指標取代；不過，本文所述之部分實施例則會對此三位元組匹配字串產生背向指標(如步驟2208)，因而可以達到更高的壓縮率。此外，在LZ77引擎102在掃描輸入區塊之下一個匹配的過程中同時執行步驟2204之預先霍夫曼編碼程序與步驟2206之決策步驟的情況下，也不會犧牲壓縮速度。
基於不同散列尺寸在散列表中搜尋多字串匹配
執行LZ77型壓縮程序時，在輸入區塊內反向搜尋目標字串之匹配會消耗大量時間。一種顯而易見的方式是從輸入區塊的開頭開始搜尋，順著整個輸入區塊逐個字元移動(直到當前搜尋點)並標註最常匹配 字串的位置。不過，這種處理方式非常緩慢。
一個較快的處理方式是使用散列表。在掃描輸入區塊的過程中會建構散列表，散列表可用以縮減輸入區塊內需搜尋之位置數量。也就是說，散列表可以將搜尋目標鎖定在輸入區塊中較可能產生匹配的位置，亦即較可能儲存至少一定搜尋目標字元數量(如三個)之位置。因為在掃描輸入區塊的過程中就會確認當前搜尋目標位置前方之字元，因此散列表可依據掃描輸入區塊之過程獲得的資訊來建構。
舉例來說，位於當前搜尋目標位置之三個字元，係依據一散列邏輯打散後以產生散列表項目之索引，此項目係一指標散列鏈之頭部，而這些指標對應於輸入區塊內曾被打散至相同索引之位置，如此即可確保搜尋目標位置之三個字元有很高的可能性(可能性的高低會受到散列邏輯、散列表大小與輸入區塊字元之特性影響)也會出現在指標指向的位置。這部分在DEFLATE規範段落4有相關說明。
基本上，對於至少某些輸入檔案(如Lewis Carroll所著之愛麗絲夢遊仙境的文字)而言，使用四字元散列所產生之輸出檔案大小會大於使用三字元散列所產生之輸出檔案，不過產生檔案所費之時間也比較短，其他部分則相同。會產生較大的輸出檔案，是因為此壓縮方式會喪失某些三字元匹配，而損失較多將輸入區塊之詞彙以背向指標取代之機會。
壓縮速度的提升同時涉及多個因素，其中 至少包含一個因素，就是預期會產生較短的散列鏈搜尋。假定三字元字串“she”在輸入區塊之掃描過程中一共出現37次。這37次出現都會被插入三字元散列表中相同的散列鏈內。假定這37次出現之“she”字串中，某些情況係在“she”字串後還接上其他字元，舉例來說，假定“shea”出現21次，“shel”出現12次，而“shed”出現4次。假定四字元散列演算法將這三個不同的四字元字串插入四字元散列表中三個不同的散列鏈。亦即表示在四字元散列表中依據開頭為“she”之字串搜尋匹配之散列鏈，其長度很有可能會短於在三字元散列表中需要搜尋之散列鏈的長度，其他部分則相同，例如忽略非“she”之字串散列在三字元散列表中散列至與“she”字串相同散列鏈之衝突情況，以及非“she”之三字元接上其他字元所構成之字串在四字元散列表中散列至與“she”接上“a”、“l”與“d”字元之三個相同散列鏈之衝突情況。
為了兼顧四字元散列之速度與三字元散列之輸出大小的優點，本發明提出下列實施例。此硬體資料壓縮器100具有兩個散列表，其中一個是基於三字元散列，另一個則是基於四字元散列。四字元散列表會首先用於搜尋最少為四字元之匹配，三字元散列表只有在利用四字元散列表沒有找到四字元匹配之情況下，才用於搜尋至少為三字元之匹配。對於某些輸入區塊而言，四字元散列表會具有較短的散列鏈，一般而言也會有較快的搜尋速度。不過，在必要時，此實施例也會使用三字元散列表而能達到三字元散列表之壓縮率。值得注意 的是，一般而言，因為任何使用四字元散列表找到的匹配至少會跟三字元散列表找到的匹配具有相同長度，因此，若是使用四字元散列表找到匹配，就不需要使用三字元散列表來進行搜尋動作。
前述使用三字元與四字元散列表的目的是要達到比僅使用三字元散列更快的壓縮速度，以及比僅使用四字元散列更小的壓縮大小。以下舉例說明，假定對於一輸入區塊，90%之時間係用於搜尋四字元或更大之匹配，而只有10%之時間係用於搜尋三字元匹配。在此情況下，因為壓縮率可以從前述10%之三字元匹配獲得助益，因此壓縮器之壓縮輸出通常會小於僅使用四字元散列之實施例。此外，就統計上來看，四字元散列鏈之長度較短而能達到較快的搜尋速度，因此進行搜尋所產生輸出之速度也會比僅使用三字元散列之實施例來的快。
請參照第二十四圖，此圖係一方塊圖顯示第一圖之LZ77引擎102之一部分。此LZ77引擎包含一四字元散列表2448。此四字元散列表2448係一個利用由四字元散列表產生器2442產生之四字元散列表索引2444作為其索引之項目陣列，此四字元散列表產生器2442利用四字元散列演算法，依據位於當前搜尋位置2402之字元對輸入區塊內之四字元單位進行散列處理，以產生此四字元散列表索引。下表5顯示此四字元散列演算法之一實施例，不過本發明並不限於此。表5之演算法僅為一例示，而非限定本發明之範圍。在一實施例中，如後續第 三十九至四十一圖所示，散列演算法係與輸入區塊之類型有關。需要理解的是，四字元散列表索引2444係四字元散列表2448之索引，而非一四字元值。此索引2444之大小會受到散列表2448尺寸影響。此四字元散列表2448之項目即為由節點2406構成之散列鏈2441的頭部。就一實施例而言，各個散列鏈2441係一列節點2406之連結，不過亦不限於此，此散列鏈亦可為陣列、樹狀分布等等。各個節點包含一個指向散列鏈2441之下一個節點之指標，各個節點並包含一指標，指向輸入區塊內之當前搜尋位置2402後方之四字元字串的位置。此四字元字串係於先前步驟經散列處理產生四字元散列表2448之項目索引2444值，而此四字元散列表2448之散列鏈2441包含節點2406。在這些節點2406中填入數值的程序會在後續第二十五圖有更詳細的說明。如第二十四圖所示，各個散列鏈2441的長度會隨著輸入區塊2404之掃描過程而改變，而某些散列鏈可能會被清空。在一實施例中，四字元散列表2448之項目數為16,384，不過本發明並不限於此。
LZ77引擎102並包含一個三字元散列表2438。此三字元散列表2438係一個利用由三字元散列表產生器2432產生之三字元散列表索引2434作為其索引之項目陣列，此三字元散列表產生器2432利用三字元散列演算法，依據位於當前搜尋位置2402之字元對輸入區塊內之三字元單位進行散列處理，以產生此三字元散列表索引。下表4顯示此三字元散列演算法之一實施例，不過 本發明並不限於此，表4之演算法僅為一例示，而非限定本發明之範圍。在一實施例中，如後續第三十九至四十一圖所示，散列演算法與輸入區塊之類型有關。需要理解的是，三字元散列表索引2434係三字元散列表2438之索引，而非一三字元值。此索引2434之大小會受到散列表2438尺寸影響。此三字元散列表2438之項目即為由節點2406構成之散列鏈2431的頭部。就一實施例而言，各個散列鏈2431係一列節點2406之連結，不過亦不限於此，此散列鏈亦可為陣列、樹狀分布等等。各個節點包含一個指向散列鏈2431之下一個節點之指標。各個節點並包含一指標，指向輸入區塊2404內之當前搜尋位置2402後方之三字元字串的位置。此三字元字串係於先前步驟經散列處理產生三字元散列表2438之項目索引2434值，而此三字元散列表2438之散列鏈2431包含節點2406，在這些節點2406中填入數值的程序會在後續第二十五圖有更詳細的說明。如第二十四圖所示，各個散列鏈2431的長度會隨著輸入區塊2404之掃描過程而改變，而某些散列鏈可能會被清空。在一實施例中，四字元散列表2438之項目數為16,384，不過本發明並不限於此。
在一實施例中，四字元散列表2448與三字元散列表2438係儲存於第一圖之散列記憶體103。在另一實施例中，硬體資料壓縮器100包含不同的記憶體，用於儲存四字元散列表2448與三字元散列表2438。在一實施例中，散列鏈2441/2431的節點2407與散列表2438/2448係儲存於不同的記憶體。
以下所示之表4與表5分別為三位元組與四位元組散列演算法之範例。
現在請參照第二十五圖，本圖係一流程圖顯示第二十四圖之LZ77引擎102之運作。此流程始於步驟2501與2511。就一實施例而言，此二步驟係同時開始。
在步驟2501中，四字元散列索引產生器2442對位於輸入區塊2404之當前搜尋目標位置2402之四個字元進行散列處理，以產生一個四字元散列表索引2444。接下來流程由步驟2501前進至步驟2502。
在步驟2511中，三字元散列索引產生器2432對位於輸入區塊2404之當前搜尋目標位置2402之三個字元進行散列處理，以產生一個三字元散列表索引2434。接下來流程由步驟2511前進至步驟2512。
在步驟2502中，LZ77引擎102利用步驟2501產生之索引2444所對應之四字元散列表2448的散列鏈2441，在輸入區塊2404中搜尋當前搜尋目標位置2402之字串的匹配。也就是說，LZ77引擎102先在輸入區塊2404中，索引鏈2441頭部之節點2406指向的位置搜尋匹配，然後在輸入區塊2404中，索引鏈2441之下一個節點2406指向的位置以尋找長度更長的匹配，然後在輸入區塊2404中，索引鏈2441之下一個節點2406指向的位置以尋找長度更長的匹配，依此類推，直到滿足一搜尋中止標準(例如，使用過之節點2406數超過一預設值，使用過的散列鏈2441比例超過一預設值，或是匹配字串長度超過一預設值)或是抵達索引鏈2441之末端。接下來流程前進至決策步驟2503。
在決策步驟2503中，若是步驟2502中有找到匹配，流程就會前進至步驟2504；否則就會前進至步驟2512。
在步驟2504中，LZ77引擎102為此所找到之匹配產生一背向指標。接下來流程前進至步驟2506與2516。就一實施例而言，此流程會同時前進至此二個步驟。
在步驟2506中，LZ77引擎102將一節點2406插入四字元散列表2448中位於步驟2501所產生之索引2444處的散列鏈2441，此節點2406指向當前搜尋目標位置2402。就一較佳實施例而言，此節點2406係插入散列鏈2441之頭部，藉此，新節點2406的搜尋就會先於舊 節點2406，而有助於縮減背向指標之距離值。不過，本發明並不限於此。在本文第二十六至三十五圖所示之另一個實施例中，這些節點2406係依據另一種順序進行排列。接下來流程前進至步驟2507。
在步驟2507中，LZ77引擎102更新當前搜尋目標位置2402。就一實施例而言，若是所使用的散列表為三字元散列表2438，就會將當前搜尋目標位置2402前移三字元，而若是所使用的散列表為四字元散列表2448，就會將當前搜尋目標位置2402前移四字元。此流程終止於此。
在步驟2512中，LZ77引擎102利用步驟2501產生之索引2434所對應之三字元散列表2438的散列鏈2431，在輸入區塊2404中搜尋當前搜尋目標位置2402之字串的匹配。也就是說，LZ77引擎102先在輸入區塊2404中，索引鏈2431頭部之節點2406指向的位置搜尋匹配，然後在輸入區塊2404中，索引鏈2431之下一個節點2406指向的位置以尋找長度更長的匹配，然後在輸入區塊2404中，索引鏈2431之下一個節點2406指向的位置以尋找長度更長的匹配，依此類推，直到滿足一搜尋中止標準(例如，使用過之節點2406數超過一預設值，使用過的散列鏈2431比例超過一預設值，或是匹配字串長度超過一預設值)或是抵達索引鏈2431之末端。接下來流程前進至決策步驟2513。
在決策步驟2513中，若是步驟2512中有找到匹配，流程就會前進至步驟2514；否則就會前進至步 驟2515。
在步驟2514中，LZ77引擎102為此所找到之匹配產生一背向指標。接下來流程前進至步驟2506與2516。就一實施例而言，此二步驟可同時進行。
在步驟2515中，LZ77引擎102產生當前搜尋目標位置2402之詞彙符號。在一實施例中，LZ77引擎102產生三個詞彙符號，不過在另一實施例中，LZ77引擎102則是產生四個詞彙符號。在一實施例中，詞彙符號的數量可透過程式調整。接下來流程前進至步驟2506與2516。就一實施例而言，此流程會同時前進至此二個步驟。
在步驟2516中，LZ77引擎102將一節點2406插入三字元散列表2438中位於步驟2511所產生之索引2434處的散列鏈2431。此節點2406指向當前搜尋目標位置2402。就一實施例而言，此節點2406係插入散列鏈2431之頭部，藉此，新節點2406的搜尋就會先於舊節點2406，而有助於縮減背向指標之距離值。不過，本發明並不限於此。在本文第二十六至三十五圖所示之另一個實施例中，這些節點2406依據另一種順序進行排列。接下來流程前進至步驟2507。
值得注意的是，雖然本文僅描述三字元與四字元散列表之實施例，不過本發明並不限於此。實則本發明可廣泛地應用於使用M字元與N字元散列表之實施例，其中M大於二而N大於M。舉例來說，本發明即可使用三字元與五字元散列表，四字元與六字元散列表等 等。
此外，值得注意的是，雖然本文僅描述使用二個散列表之實施例，不過本發明並不限於此。實則本發明可廣泛地應用於具有J個散列表之實施例，其中J大於一。舉例來說，本發明之實施例可利用三字元、四字元與六字元散列表；三字元、五字元與六字元散列表等等。值得注意的是，相較於使用單一散列表，使用多個散列表通常需要更多記憶體作為代價，而這通常是為了提升壓縮速度值得付出的成本。
基於節點串匹配機率對散列鏈進行分類
如前述，在搜尋匹配字串以產生背向指標時，若是LZ77引擎102遇到一搜尋中止標準，即可縮短其橫跨索引散列鏈之歷程。也就是說，LZ77引擎102可以不需橫跨整個散列鏈來使用散列鏈之所有節點進行搜尋。舉例來說，LZ77引擎102在找到長度超過一預設值之匹配字串後，或是使用一預設數量之節點來搜尋匹配字串後，或是使用散列鏈中一預設比例的節點後，即可中止搜尋。如此即可提升壓縮速度，不過，因為可能失去某些長度較長的字串匹配，而可能會犧牲壓縮率。
一般而言，產生長度較長而距離較短的背向指標可以提升壓縮率。這是因為較長的長度值表示輸入區塊中有更多字元被取代，而較短的距離值表示霍夫曼編碼需要較少的額外位元。DEFLATE規範有利於使用小距離值之背向指標來改善霍夫曼編碼之壓縮，這是因為較短的距離值需要較少的額外位元，而DEFLATE規範 係透過將新節點插入散列鏈開端來實現。也就是說，此實施方式將散列鏈之節點依據其年齡排列。此方式有助於產生距離較短之背向指標，不過也會產生長度較短背向指標，而不利於提升壓縮率。
因為某些散列鏈會變得非常長，因而有必要設定搜尋中止標準。舉例來說，假定輸入區塊為英文字。因為三字元字串”The”有很高的可能性會頻繁地出現在輸入區塊內，此字串所產生之散列鏈的長度就有可能非常長。不過，一般而言，對輸入區塊內所有以“The”為開端的位置，加上後續搜尋目標後產生匹配之機率不盡相同。也就是說，在輸入區塊內會有許多不同位置之開端為“The”，但這些字串後面可能接上許多可能產生字串匹配的不同字元組合，而各個不同的字元組合產生匹配的可能性也不同。例如，相較於指向“Ther”或“Then”的節點，指向“Thez”或“Theq”或“Thej”的節點一般而言較不可能產生匹配。但對於傳統上嚴格依據年齡排序之散列鏈的節點而言，指向“Thez”或“Theq”或“Thej”的節點也可能是相對而言較新的節點，而會出現在散列鏈之前端部分，更精確地說，即佔據散列鏈中搜尋中止點前方的位置，而使某些指向“Ther”或“Then”的節點只能佔據散列鏈中搜尋中止點後方的位置。如此，LZ77引擎102可能無法到達並使用某些指向“Ther”或“Then”的節點，因為這些節點的排序超過搜尋中止標準。
第二十六圖係一方塊圖，顯示本發明硬體資料壓縮器100之一實施例。此硬體資料壓縮器100包含 第一圖中之輸入區塊記憶體100，LZ77引擎與散列記憶體103。由字元2606構成之輸入區塊儲存於輸入區塊記憶體101內。散列鏈2611(與圖中未示，指向散列鏈2611之散列表)儲存於散列記憶體103，此散列鏈2611係如前所述。不過，第二十六圖之散列鏈2611包含以機率2703來提升之節點2706(在後續第二十七圖會進行描述)。LZ77引擎102依據各節點之機率2703，並於相同機率時依據其年齡，來排列散列鏈2611之節點2706，而非嚴格依據其年齡排列，以提升找到較長之匹配字串的可能性。這在後續章節會有更詳細的說明。
LZ77引擎102包含互相連接之一掃描引擎2602與一鏈分類引擎2604，並且這兩個引擎都連接至輸入區塊記憶體101與散列記憶體103。在一實施例中，鏈分類引擎2604會檢視掃描引擎2602與散列記憶體103之連接，以偵測掃描引擎2602存取的散列鏈2611(如散列鏈索引)，並依此將掃描引擎2602更新過的散列鏈2611分類。這在後續章節會有更詳細的說明。
現在請參照第二十七圖，此圖係一方塊圖顯示第二十六圖之散列鏈2611之節點2706。節點2706包含一輸入區塊指標2702、一機率值2703、一年齡值2704與一後續指標2705。此後續指標2705指向散列鏈2611之下一個節點2706。輸入區塊指標2702指向第二十六圖之字元輸入區塊2606中，一個連同其周邊字元(如一三字元字串)一併被進行散列處理以產生散列表索引之字元，如第二十八圖之步驟2802所述。年齡值2704係表示 此節點2706相較於散列表中之其他節點2706之產生時點。在一實施例中，係利用一計數器來維持一後續年齡值。當LZ77引擎102開始對輸入區塊進行掃描時，此計數器係初始化為零，而後每當產生一新節點2706，就增加計數器之計數。在此情況下，年齡值2704就會是類似於一系列的數字。機率值2703係一相對指標，表示背向指標指向一匹配字串之可能性，而此匹配字串係以LZ77引擎102將會產生之輸入區塊指標2702所指向之一字元為開頭。鏈分類引擎2604利用機率值2703來對散列鏈2611之節點2706進行排序，而提升找到較佳匹配字串的可能性。以下描述有動態機率與靜態機率之實施例。此外，值得注意的是，靜態機率之實施例可用於提供節點2706之機率2703的一初始值，此數值於後續過程中可依據動態機率之實施例進行更新。
現在請參照第二十八圖，此圖係一流程圖，顯示硬體資料壓縮器100利用動態節點機率之實施方式，執行第二十六圖所示於散列表中插入新節點顯示之運作。此流程始於步驟2802。
在步驟2802中，掃描引擎2602對位於當前掃描目標位置之三個字元進行散列處理以產生一散列表索引。本發明亦可應用於其他不同字元數量之實施例，如前文第二十四與二十五圖所述。接下來流程前進至步驟2804。
在步驟2804中，鏈分類引擎2604產生一新節點2706，並以當前搜尋目標位置填入輸入區塊指標 2702，以零值填入機率值2703，以後續年齡暫存器之當前值填入年齡值2704，而後增加後續年齡暫存器之數值。就一實施例而言，此掃描引擎2602係提供鏈分類引擎2602產生新節點2706所需之資訊，例如當前搜尋目標位置。在另一實施例中，掃描引擎2602產生新節點2706並通知鏈分類引擎2604。接下來流程前進至步驟2806。
在步驟2806中，鏈分類引擎2604將新節點2706插入步驟2802產生之散列表索引所對應之散列鏈2611中。就一實施例而言，此鏈分類引擎2604會找到具有零機率值2703之最早(亦即，離散列鏈之頭部最近)節點2706，在此標示為節點X；隨後在新節點2706之後續指標2705中填入數值以指向節點X；然後，更新節點2706中指向節點X之後續指標2705(當節點X位於散列鏈2611頭部時，此指標就可能為頭部指標)，使其指向新節點2706。在另一實施例中，掃描引擎2602將新節點插入散列鏈2611之頭部，並通知鏈分類引擎2604需要對散列鏈進行分類，也就是需要將新節點放在散列鏈2611中適當的位置。流程終止於此。
現在請參照第二十九圖，此圖係一時序圖，顯示第二十六圖之硬體資料壓縮器依據第二十八圖之流程執行之運作。在第二十九圖中，時間進程往下為遞增，而節點2706旁邊標示有其年齡值2704與機率值2703。圖中並未顯示輸入區塊指標2702，不過圖中從各個節點2706延伸出來的箭頭可呈現其後續指標2705所指向的節點。在第一時點，散列鏈2611之第一列包含五個 節點。散列鏈2611之頭部具有一節點2706，其年齡2704值為2，機率值2703為3，其後方之節點2706之年齡2704值為1，機率值2703為2，再後方之節點2706之年齡2704值為4，機率值2703為0，再後方之節點2706之年齡2704值為3，機率值2703為0，再後方之最後一個節點2706之年齡2704值為0，機率值2703為0。
在第一時點後的第二時點產生一新節點2706(如步驟2804)，其年齡2704值為5，而機率值2703為0。此新節點2706插入(如第二十八圖步驟2806)年齡2704值為1與年齡值2704為4之二個節點間，這是因為年齡2704值為4的節點2706是節點鏈2611之機率值2703為零的節點中，最早的節點2706。
現在請參照第三十圖，此圖係一流程圖顯示第二十六圖之硬體資料壓縮器100依據動態節點機率之實施例分類散列鏈之運作。此流程始於步驟3002。
在步驟3002中，掃描引擎2602在輸入區塊2606中找到匹配之字元字串，並且散列鏈2611內具有一節點2706，在此標示為節點K，其輸入區塊指標2702指向此字串之開頭位置。此散列鏈2611具有於步驟2802中所產生之索引。也就是說，此匹配字串在輸入區塊2606內有一匹配字元字串，而當前目標搜尋位置指向此匹配字元字串之開頭字元。因應於此，掃描引擎2602對此匹配字串產生一背向指標，即一長度與距離順序對。就一實施例而言，LZ77引擎102會將此匹配字串視為在給定限制下的最佳匹配，這些給定限制例如是背向指標之距 離值不大於一預設臨界值，或是如果存在給定中止標準，長度值必須是在給定中止標準下所找到之最大長度值。接下來前進至步驟3004。
在步驟3004，掃描引擎2602遞增節點K之機率值2703。在另一實施例中則可由鏈分類引擎2604增加此機率值2703，而掃描引擎2602僅提供所需之資訊，如節點K之位置，至鏈分類引擎2604。接下來流程前進至步驟3006。
在步驟3006中，鏈分類引擎2604依據此遞增後的機率值2703對包含有節點K之散列鏈2611進行分類。進一步來說，只要節點K的機率值2703大於散列鏈2611中位於其前方之節點2706的機率值2703，鏈分類引擎2604就會將節點K朝向節點鏈2611之較早部分移動(也就是朝向節點鏈2611之頭部移動)。若是節點K的機率值2703等於散列鏈2611中位於其前方之節點2703的機率值，而節點K的年齡2704比位於其前方之節點2706新，鏈分類引擎2604就會將節點K朝向散列鏈2611之較早部分移動。對於年齡2704值遞增的實施例而言，若是第一個節點2706之年齡2704值大於第二個節點2706之年齡2704值，第一個節點2706就會是比第二個節點2706年輕或是新。此流程終止於此。
現在請參照第三十一圖，此圖係一時序圖，例示硬體資料壓縮器100依據第二十六至三十圖之運作。在第三十一圖中，時間進程係往下遞增，而節點2706旁邊係標示有其年齡值2704與機率值2703。圖中並未顯 示輸入區塊指標2702，不過圖中從各個節點2706延伸出來的箭頭可呈現其後續指標2705所指向的節點。在第一時點，散列鏈2611之第一列包含三個節點。散列鏈2611之頭部具有一節點2706，其年齡2704值為0，機率值2703為3，其後方之節點2706之年齡2704值為1，機率值2703為2，再後方之最後一個節點2706之年齡2704值為2，機率值2703為1。
接下來，掃描引擎2602依據使用節點2之輸入背向指標2702(即年齡2704值為2之節點2706)找到的字串匹配產生一背向指標，如第三十圖之步驟3002所示。依此，在第一時點後的第二時點，如第二列所示，掃描引擎2602會將節點2的機率2703值由1增加為2。因應於此，如圖中第二列所示，因為此時節點2的機率2703值(2)與節點1相同，但節點2比較新，鏈分類引擎2604就會將散列鏈2611中節點2與其前方節點，即節點1(也就是年齡2704值為1的節點2706)的位置互換，如第三十圖步驟3006所示。
隨後，掃描引擎2602再次依據使用節點2之輸入背向指標2702找到的字串匹配產生一背向指標。依此，在第二時點後的第三時點，如第三列所示，掃描引擎2602會將節點2的機率2703值由2增加為3。因應於此，如圖中第三列所示，因為此時節點2的機率2703值(3)與節點0相同，但節點2比較新，鏈分類引擎2604就會將散列鏈2611中節點2與其前方節點，即節點0(也就是年齡2704值為0的節點2706)的位置互換。
現在請參照第三十二與三十三圖，第三十二圖係一流程圖顯示產生第三十三圖所示之查找表3302之方法，此查找表係用於靜態散列鏈節點機率之實施例。就一實施例而言，第三十二圖所述的方法係採自動化執行，如軟體。就一實施例而言，使用者(如硬體資料壓縮器100之生產者或終端用戶)會在利用硬體資料壓縮器100壓縮字元輸入區塊前執行此方法。舉例來說，可由生產者執行此方法並將其連同硬體資料壓縮器100提供給終端用戶。在另一實施例中，生產者可先產生查找表3302，隨後終端用戶再從生產者下載查找表3302。在另一實施例中，終端用戶可以依據其使用硬體資料壓縮器100經常壓縮之檔案自己客製化產生一客戶端查找表。此時，生產者通常會提供終端用戶所需之軟體。在一實施例中，此查找表3302儲存於表單記憶體107，不過本發明並不限於此。此查找表3302亦可儲存於其他記憶體，如記憶體101、記憶體103或記憶體105。在一實施例中，此查找表3302係儲存於一內容可定址記憶體(content-addressable memory,CAM)，其中，相較於輸入位址，第三十三圖之四字元字串3303為內容，而此內容可定址記憶體輸出對應於此匹配字串3303之分數3304。若是沒有找到匹配，此內容可定址記憶體會在一未命中指標上產生一真值。此流程始於步驟3202。
在步驟3202中，使用者(例如生產者或終端用戶，如伺服器農場管理者)蒐集一組字元輸入區塊作為後續由硬體資料壓縮器100執行壓縮之輸入區塊的 之代表。舉例來說，以英文字為例，使用者可以從數百個英文作品中蒐集一組輸入區塊。在另一個例子中，使用者可以從許多HTML檔案、音訊檔或影像檔中蒐集一組輸入區塊。隨後，使用者會從這一組輸入區塊中編譯出一列數據，包含J個最常出現的四字元字串以及其出現頻率。J是一個相當大的整數，例如介於500至5000之間，端視可配置給查找表3302之記憶體容量，以及利用節點2706機率2703對散列鏈2611進行分類後對匹配字串搜尋效率之提升幅度而定。接下來流程前進至步驟3204。
在步驟3204中，使用者利用LZ77引擎102所使用之散列演算法(如第二十四圖之三字元散列索引產生器2432使用之散列演算法)，對步驟3202所編譯之J個四字元字串表單內的每一個四字元字串的前三個字元進行散列處理，以對字串產生索引。因此，此索引與後續步驟中LZ77引擎102產生作為散列記憶體103內之散列表的索引(如第二十四圖中作為三字元散列表2438之三字元散列表索引2434)會具有相同的數值。接下來前進至步驟3206。
對於步驟3204所產生之各個索引值，以及前三個字元散列至索引之J個字串中每一群字串，使用者在步驟3206中檢視同一群字串之頻率並依據其相較於同一群其他字串之相對頻率對各個字串賦予一分數。舉例來說，假定四個字串散列至同一個索引，而這四個字串由步驟3202取得之頻率分別為8，11，98與16。隨後，使用者會對第一個字串賦予最低的分數，對第二個字串賦 予次低的分數，對第三個字串賦予最高的分數，對第四個字串賦予次高的分數，舉例來說，這些分數可以是1、2、3、4。隨後，這些分數可用於填入查找表3302，如步驟3208所述。若是這些四字元字串之後出現在硬體資料壓縮器100正在壓縮之字元輸入區塊內，就會為這些字串產生一節點2706以插入散列串2611，而鏈分類引擎2604就可利用查找表3302內之分數來進行分類。這部分在後續章節有更詳細的說明。接下來流程會前進至步驟3208。
在步驟3208中，使用者依據步驟3202編譯之四字元字串與步驟3206中所賦予的分數產生一查找表3302。第三十三圖係此查找表3302之一範例。第三十三圖所示之查找表3302係一陣列，不過本發明並不限於此。此查找表3302亦可以其他型式排列，如樹狀或散列表之型式。如後續第三十四與三十五圖所示，此查找表3302可用於對散列鏈2611之節點2706賦予機率2703值。此流程終止於此。
現在請參照第三十四圖，此圖係一流程圖顯示第二十六圖之硬體資料壓縮器100依據靜態節點機率之實施例分類散列鏈之運作。此流程始於步驟3402。
在步驟3402中，掃描引擎2602對位於當前搜尋目標位置之三個字元進行散列處理以產生一散列表索引。接下來流程前進至步驟3404。
在步驟3404中，鏈分類引擎2604產生一新節點2706並將後續年齡暫存器之當前值填入輸入區塊指標2702，隨後增加後續年齡暫存器之數值。就一實施例 而言，掃描引擎2602會提供鏈分類引擎2604產生新節點2706所需之資訊，如當前搜尋目標位置。在另一實施例中，掃描引擎2602會產生此新節點2706，並通知鏈分類引擎2604。接下來流程前進至步驟3406。
在步驟3406中，鏈分類引擎2604取得由位於當前搜尋目標位置之三個字元(即步驟3402中進行散列處理之三個字元)與輸入區塊中其後鄰接之字元構成之四字元字串。接下來流程前進至步驟3408。
在步驟3408中，鏈分類引擎2604以查找表3302內之字串3303在步驟3406所產生之四字元字串中尋找其匹配。若有找到匹配，鏈分類引擎2604會將關聯於此匹配字串3303之分數3304賦予新節點作為其機率2703；否則，鏈分類引擎2604會將零值賦予此新節點作為其機率2703。接下來流程前進至步驟3412。
在步驟3412中，鏈分類引擎2604將新節點2706插入步驟3402在散列鏈2611所產生之索引處。鏈分類引擎2604會依據新節點2706相較於其他節點2706之機率，將新節點2706插入散列鏈2611中。特別是，鏈分類引擎2604將新節點2706插入散列鏈2611之位置係先於其他具有較低機率2703之節點2706，但後於其他具有較高機率2703之節點2706。對於具有相同機率2703之節點2706而言，鏈分類引擎2604會將新節點2706排列在相對較舊的節點2706前方。此新節點2706在此時點為最新的節點，因而會被插入在其他所有具有相同機率之節點的前方。此流程終止於此。
現在請參照第三十五圖，此圖係一時序圖，例示第二十六圖之硬體資料壓縮器100依據第三十四圖執行之運作。在第三十五圖中，時間進程下向遞增，而節點2706旁邊標示有其年齡值2704與機率值2703。圖中並未顯示輸入區塊指標2702，不過圖中從各個節點2706延伸出來的箭頭可呈現其後續指標2705所指向的節點。在第一時點，散列鏈2611之第一列包含五個節點。散列鏈2611之頭部具有一節點2706，其年齡2704值為2，機率值2703為8，其後方之節點2706之年齡2704值為1，機率值2703為6，再後方之節點2706之年齡2704值為4，機率值2703為5，再後方之節點2706之年齡2704值為3，機率值2703為1，再後方之最後一個節點2706之年齡2704值為0，機率值2703為0。
在第一時點後的第二時點產生一新節點2706(如步驟3404至3408)，其年齡2704值為5，而機率值2703為1。此新節點2706插入(如第三十四圖步驟3412)年齡2704值為4與年齡值2704為3之二個節點間。這是因為年齡2704值為4之節點2706的機率2703值大於新節點2706，並且相較於年齡2704值為3的節點2706，新節點與其機率2703值相同，但比較新。
前述實施例係對三個字元進行散列處理，而查找表3302內之字串長度為四個字元，不過本發明並不限於此。本發明當可應用於對三個以上字元進行散列處理以及字串長度大於四個字元之實施例。不過，字串長度必須大於散列處理之字元數，使散列字元後方 接續有一個或多個字元供確認。
依據第二十六至三十五圖之描述可以發現，散列鏈2611之各個節點2706可依據其機率2703排列，如此掃描引擎2602即可產生指向以輸入區塊字元作為開頭之匹配字串的背向指標，期能提升相較於僅依據年齡排列散列表之情況下，掃描引擎2602在到達其中止標準前找到較長匹配字串的可能性。第二十八至三十一圖之實施例係利用動態方式進行，若是節點2706在掃描輸入區塊2606之過程更頻繁地用於尋找匹配字串以產生背向指標，其機率2703就會增加。不過，第三十二至三十五圖之實施例則是利用靜態方式進行，也就是依據對於具代表性之輸入區塊樣本內的字串頻率進行預先分析，來賦予節點2706機率2703。
對來自LZ77引擎之標記直接進行霍夫曼編碼之硬體資料壓縮器
隨著伺服器，如網路伺服器，之廣泛使用，透過網路在伺服器間傳遞壓縮檔案的情況有顯著增加，因此，在伺服器中使用硬體資料壓縮器的需求也會隨之提升。這會驅動對低成本低功耗硬體資料壓縮器之需求。
現在請參照第三十六圖，此圖係一方塊圖顯示本發明硬體資料壓縮器3600之另一實施例。此硬體資料壓縮器3600包含一輸入區塊記憶體101、一LZ77引擎102、一散列記憶體103、一霍夫曼編碼引擎108與一輸 出記憶體109，這些元件類似於第一圖之硬體資料壓縮器100。以下對此進行更詳細的描述。此硬體資料壓縮器3600直接提供標記3612給霍夫曼編碼引擎108，而霍夫曼編碼引擎108隨即對所接收到的各個標記3612進行霍夫曼編碼程序，並將所產生之霍夫曼編碼寫入輸出記憶體109。如此，此硬體資料壓縮器3600就不需要背向指標記憶體105。此外，因為使用預編譯霍夫曼編碼表，此硬體資料壓縮器3600就不需要包含第一圖之分類引擎104或是霍夫曼編碼表建構引擎106。相較於如第一圖所示之實施例，當硬體資料壓縮器3600以此模式運作時，即可省略或至少不使用背向指標記憶體105，而能降低成本、尺寸與耗能。
在一實施例中，此霍夫曼編碼引擎108包含一內容可定址記憶體，霍夫曼編碼表之符號值即為其內容，而不同於受編碼的輸入符號，並且此內容可定址記憶體會輸出對應於匹配輸入符號霍夫曼編碼。就一實施例而言，此內容可定址記憶體係用於同時接收三個符號輸入，並同時輸出三個相對應之霍夫曼編碼，以配合標記3612關聯有三個詞彙之情形，或是背向指標標記3612之長度與距離輸入內容可定址記憶體之情形。此內容可定址記憶體在LZ77引擎102開始掃描輸入區塊前係載入預編譯詞彙/長度與距離霍夫曼編碼表。就一實施例而言，對於內容可定址記憶體之三個輸入中的每一個輸入，LZ77引擎102都會提供一相對應訊號，標示此符號為詞彙/長度或是距離，使內容可定址記憶體可確認究竟 是要存取詞彙/長度或是距離霍夫曼編碼表。就一實施例而言，背向指標之長度與距離之額外位元係由LZ77引擎102，經適當排列後與內容可定址記憶體所輸出之數值同時傳遞並寫入輸出記憶體109。
現在請參照第三十七圖，此圖係一流程圖顯示第三十六圖之硬體資料壓縮器3600之運作。在第三十七圖中，LZ77引擎102執行步驟3702與3704，而霍夫曼編碼引擎108執行步驟3712與3714。此流程始於步驟3702。
在步驟3702中，LZ77引擎102掃描輸入區塊，並搜尋輸入區塊中位於當前搜尋目標位置之字串的匹配。接下來流程前進至步驟3704。
在步驟3704中，LZ77引擎102產生標記3612至霍夫曼編碼引擎108並更新當前搜尋目標位置。對於LZ77引擎102而言，接下來流程回到3702以搜尋下一個字串(直到抵達字元塊之尾端)，同時，對於霍夫曼編碼引擎108而言，流程會前進至決策步驟3712。
在決策步驟3712中，霍夫曼編碼引擎108會確認LZ77引擎102是否產生標記3612提供給霍夫曼編碼引擎108。若是，流程會前進至步驟3714，否則就會回到決策步驟3712直到LZ77引擎102產生標記3612。
在步驟3714中，對於從LZ77引擎102接收之標記中的各個符號，霍夫曼編碼引擎108會對此符號進行霍夫曼編碼程序並將霍夫曼編碼寫入輸出記憶體109。接下來流程會回到決策步驟3712。
霍夫曼編碼引擎108執行步驟3712與3714之運作的時間，不少於LZ77引擎102執行步驟3702與3704之運作之時間。也就是說，LZ77引擎102持續產生標記3612之間隔時間，係大於或等於霍夫曼編碼引擎108接收標記3612、對其進行霍夫曼編碼程序並將產生之霍夫曼編碼寫入輸出記憶體109所需之時間。因而不需要將標記3612寫入一中間儲存記憶體，也不需要從記憶體中讀取標記3612。
現在請參照第三十八圖，此圖係一時序圖，顯示第三十六圖之硬體資料壓縮器3600依據第三十七圖之方法執行之運作。此時序圖之上部分顯示LZ77引擎102之運作，而下部分顯示霍夫曼編碼引擎108之運作。時間進程係由左而右遞增。圖中以時鐘週期表示時間，不過，亦可使用其他相關時間單位，如奈秒。
如圖中所示，在週期0的時候，LZ77引擎102開始從當前搜尋位置掃描輸入區塊，以執行字串匹配之第一次搜尋(標示為S1)，如第三十七圖之步驟3702所示，而在週期3的時候，LZ77引擎102輸出一標記3612(標示為TOK1)至霍夫曼編碼引擎108。因應於此，霍夫曼編碼引擎108對關聯於標記TOK1之各個符號進行霍夫曼編碼程序，並將產生之霍夫曼編碼寫入輸出記憶體109，如第三十七圖之步驟3714所示，此運作終止於週期6，而此時點早於LZ77引擎102結束其下一次搜尋(S2)並輸出一第二標記(TOK2)之時點，即週期10。因應此第二標記TOK2，霍夫曼編碼引擎108對關聯於標記TOK2之各 個符號進行霍夫曼編碼程序，並將產生之霍夫曼編碼寫入輸出記憶體109，此運作終止於週期13，而此時點早於LZ77引擎102結束其下一次搜尋(S3)並輸出另一個標記(TOK3)之時點，即週期13。因應此標記TOK3，霍夫曼編碼引擎108對關聯於標記TOK3之各個符號進行霍夫曼編碼程序，並將產生之霍夫曼編碼寫入輸出記憶體109，此運作終止於週期16，而此時點早於LZ77引擎102結束其下一次搜尋(S4)並輸出另一個標記(TOK4)之時點，即週期72。因應此標記TOK4，霍夫曼編碼引擎108對關聯於標記TOK4之各個符號進行霍夫曼編碼程序，並將產生之霍夫曼編碼寫入輸出記憶體109，此運作終止於週期75，而此時點早於LZ77引擎102結束其下一次搜尋(S5)並輸出另一個標記(TOK5)之時點，即週期75。因應此標記TOK5，霍夫曼編碼引擎108對關聯於標記TOK5之各個符號進行霍夫曼編碼程序，並將產生之霍夫曼編碼寫入輸出記憶體109，此運作終止於週期78。
如第三十七圖所示，LZ77引擎102產生標記3612所需的時鐘週期並非維持不變，舉例來說，搜尋程序S4需要59個時鐘週期，這通常表示一個相對較長的散列鏈；而搜尋程序S1、S3與S5只需要3個時鐘週期，這通常表示一個空白的散列鏈。不過，只要LZ77引擎102產生了標記3612，霍夫曼編碼引擎108就會對關聯於此標記3612的符號進行霍夫曼編碼程序，而能降低將背向指標寫入記憶體或從記憶體中讀取背向指標之需求。
在一實施例中，記憶體中大約有25KB保 留給如第一圖所述之實施例，其中背向指標與旗標記憶體105係用以儲存大約8K x 24位元背向指標與16K x 1位元旗標。
在一實施例中，硬體資料壓縮器100包含背向指標與旗標記憶體105(此記憶體可用於以執行於其他模式，如第三至二十圖所述)，但用於執行第三十六至三十八圖所述之模式。此實施例未必可以省略記憶體硬體，不過仍然可以降低耗能，因為在此實施例中，LZ77引擎102不須將背向指標與旗標寫入記憶體，而霍夫曼編碼引擎108也不須從記憶體中讀取背向指標與其標。
基於輸入區塊類型使用動態散列演算法之硬體資料壓縮器
本發明在產生散列演算法供散列索引產生器使用的過程中，如第二十四圖所示之散列索引產生器2432與2442，係存在有一目標，希望能對散列表儘量提供一個相對而言分布比較平均的散列索引。因而傾向於減少產生長度非常長之散列鏈的可能性，或至少不要使這個問題惡化，以改善依據LZ77引擎之掃描步驟來搜尋匹配字串所需使用之搜尋時間。這個問題至少有部分原因是來自於散列混淆(hash aliasing)，或稱為散列衝突(hash collision)。散列混淆會發生在對於不同輸入進行散列處理後會得到相同的散列索引之情形。舉例來說，依據所使用的散列演算法，字元“the”與字元“was”可能會得到相同的散列索引，而這個問題對於大部分的英文 字輸入區塊特別不利，因為字元“the”與字元“was”都是英文字中頻繁出現的字元，而有很高的可能性會產生非常長的散列鏈來進行索引。
如前述，若是提供一種散列演算法，具有將常用英文字散列處理至不同索引之傾向，將會對此帶來助益。不過硬體資料壓縮器100也會用於壓縮英文字以外之其他類型的輸入區塊。因此，較佳的方式是提供多個散列演算法給其他語言，包含不可說/寫之語言(如HTML、JAVA等)，而這些散列演算法傾向於產生一相對而言比較平均的散列索引分布。此外，對其他輸入區塊類型而言，包含非語言之輸入區塊(如電子表單、可執行二維檔案等)，提供散列演算法，傾向於產生一相對而言比較平的散列索引分布，亦有助益。
現在請參照第三十九圖，此圖係一方塊圖顯示第一圖之LZ77引擎102之一部分。在第三十九至四十一圖之實施例中，輸入區塊類型3901(如文字、電子表單、文字處理器、pdf、HTML、JAVA等)提供至硬體資料壓縮器100以指出所要壓縮之輸入區塊類型，而LZ77引擎102會依據輸入區塊類型3901使用不同的散列演算法。在某些實施例中，散列處理之位元數會隨著散列類型而改變。舉例來說，若是輸入區塊是ASCII文字，各個字元(位元組)之上方位元就不會包含在散列處理內，舉例來說，如第四十一圖所示，此時只有21個位元進行散列處理，而非24個位元。一般而言，因為上方位元均為零，而會扭曲散列索引之分布，因此前述處理方 式可以提供一個較佳的分布。在其他實施例中，由散列演算法執行之算術/邏輯運算會隨著輸入區塊類型改變。此外，在其他實施例中，輸入區塊中，散列演算法執行散列處理之字元數會隨著輸入區塊之類型改變。
LZ77引擎112包含一散列表3948與節點3906構成之散列鏈3941。此處之散列表3948，散列鏈3911與節點3906係類似於第二十四、二十六與二十七圖中的散列表、散列鏈與節點，即元件2448,2438,2431,2441,2611,2406與2706。多工器3999輸出之索引3944係作為散列表3948之索引。此多工器3999接收輸入區塊類型指標3901作為一控制信號，並依據輸入區塊類型指標3901在多個索引3954-A、3954-B與3954-C(標號3954可泛指其個別與整體)中選擇其一輸出為索引3944。這些索引3954係由相對應的散列表索引產生器3942-A、3942-B與3942-C(標號3942可泛指其個別與整體)產生。各個散列表產生器3942都是對輸入字元區塊3904中位於當前搜尋目標位置3902之初始字元3936(如3)進行散列處理，不過會產生其相對應的索引3954，這些散列處理使用不同的散列演算法，分別以演算法A、演算法B與演算法C表示。在一實施例中，前述一個或多個散列演算法可以是選自第二十四圖與第二十五圖之演算法，即三位元與四位元之散列演算法。
現在請參照第四十圖，此圖係一流程圖顯示第三十九圖之LZ77引擎102之運作。此流程始於步驟4002。
在步驟4002中，多工器3999接收到輸入區塊類型3901。接下來流程前進至步驟4004。
在步驟4004中，各個散列表索引產生器3942會利用其對應之散列演算法對初始位元3936進行散列處理以產生其相對應之索引3954提供給多工器3999。此多工器3999會依據輸入區塊類型3901在這些索引3954中選擇其一輸出以作為索引3944。如此，多工器3999即可有效地依據輸入區塊類型3901選擇適當的散列演算法。接下來流程前進至步驟4006。
步驟4006利用步驟4004所產生之索引3944作為散列表3948之索引以選擇其中一個散列鏈3911。LZ77引擎102可使用此選定的散列鏈3911，從輸入區塊3904中當前搜尋目標位置3902指向的位置開始，然後搜尋此選定散列鏈3911之節點3906指向的位置，以尋找匹配字串。此流程終止於此。
現在請參照第四十一圖，此圖係一方塊圖，詳細顯示第三十九圖之散列索引產生器3942。第四十一圖之散列索引產生器3942的特殊之處，在於它並不在其散列演算法中使用來自輸入區塊3936之字元內的所有位元。進一步來說，如圖中所示，散列索引產生器3942會接收輸入區塊3936之各個三字元中，除了最顯著位元(most significant bit,MSB)以外的所有位元並將其用於散列演算法。這三個字元在第四十一圖中標示為第一字元、第二字元與第三字元。散列索引產生器3942一共對21個位元進行散列處理，即第一、第二與第三字元之下 方7個位元，以產生索引3954提供給第三十九圖中的多工器3999。以下表6係第四十一圖之散列索引產生器3942用以對這21個位元進行散列處理所使用之散列演算法之一範例。不過，表6之散列演算法僅為本發明之一例示，而非限定本發明之範圍。此外，除了在各個字元中使用最少7個位元進行散列處理之實施例外，本發明亦可應用於其他進行散列處理之位元數少於輸入區塊3936字元之全部位元的態樣。第四十一圖之實施例特別適合於輸入區塊類型3901為ASCII文字之情形，因為對ASCII文字而言，各個字元(或位元組)之上方位元傾向於變成零，而會導致散列索引分布不平。
現在請參照第四十二圖，此圖係一方塊圖，顯示包含如第一圖所示之硬體資料壓縮器100之一系統4200。此系統4200包含一處理器4202，此硬體資料壓縮器100與其他周邊4208。此處理器4204透過一系統匯流排4204連接至一記憶體4206。處理器4202透過系統匯流 排4204送出命令至硬體資料壓縮器100。就一實施例而言，此硬體資料壓縮器100包含控制與狀態暫存器，處理器4202送出如壓縮字元輸入區塊之命令時，控制與狀態暫存器就會映射至輸入輸出空間。在另一實施例中，控制與狀態暫存器可為記憶體映射，而非輸入輸出映射。此外，就一實施例而言，硬體資料壓縮器100中存在一個或多個記憶體映射至記憶體空間。特別是，輸入區塊記憶體101，輸出記憶體109與表單記憶體107可由處理器4202進行寫入或讀取。舉例來說，處理器4202可將一待壓縮之字元輸入區塊從系統記憶體4206寫入輸入區塊記憶體101(或是引發直接記憶體存取來執行此操作)，當硬體資料壓縮器100完成輸入區塊之壓縮程序後，處理器4202可從輸出區塊記憶體109讀取壓縮輸出區塊，並將其傳送至系統記憶體4206(或是引發直接記憶體存取來執行此操作)。在另一個實施例中，處理器4202可提供系統記憶體4206中字元輸出區塊之位址給硬體資料壓縮器100，而硬體資料壓縮器100可讀取此字元輸出區塊並將其放入輸入區塊記憶體101(或是或是引發直接記憶體存取來執行)，當硬體資料壓縮器100完成輸入區塊之壓縮程序後，處理器4202可將系統記憶體4206中想要寫入壓縮塊的位址提供給硬體資料壓縮器100，而硬體資料壓縮器100可將其由輸出區塊記憶體109寫入系統記憶體4206(或是或是引發直接記憶體存取來執行)。此外，處理器4202還可在表單記憶體107中填入霍夫曼編碼表(以本文前述方式)，如前述預編譯霍夫曼編碼表以及/或是“參 考”霍夫曼編碼表。
現在請參照第四十三圖，此圖係一方塊圖顯示包含硬體資料壓縮器100一系統4300之另一實施例。此系統4300類似於第四十二圖所示之系統4200。不過，在第四十三圖之系統4300中，處理器4302內包含有硬體資料壓縮器100。也就是說，硬體資料壓縮器100係處理器4302內之一架構功能單元。此處理器4302之指令集架構包含指令在處理器4302上執行以控制與存取此硬體資料壓縮器100。在一實施例中，此處理器4302包含一COMPRESS BLOCK指令，此指令包含一來源運算元，一目的運算元與一控制運算元。來源運算元定義系統記憶體4206內待壓縮字元輸入區塊之位置，目的運算元定義塊壓縮後之寫入位置，而控制運算元定義硬體資料壓縮器100執行資料壓縮所需之控制資訊。舉例來說，控制資料可包含參數指出是否需要優先考慮壓縮速度，以及/或壓縮速度需要到甚麼程度。藉此硬體資料壓縮器100可選擇是否執行以下功能：同步符號列分類；動態初期霍夫曼編碼表；預先霍夫曼編譯來決定產生匹配字串或背向指標；雙散列表；基於節點字串匹配機率之散列鏈分類，若是，是否需執行靜態或動態優先處理方式，若是前者，就提供一查找表；基於輸入區塊類型從多個散列演算法選擇其一；以及/或是直接對來自LZ77引擎之輸出標記進行霍夫曼編碼程序。在另一實施例中，控制資料可包含多個參數分別對應上述各個功能。其他參數還可包含所使用之霍夫曼編碼表的資訊，如是否使用 DEFLATE規範定義之固定的霍夫曼編碼表，包含“參考”霍夫曼編碼表之預編譯霍夫曼編碼表，動態初期霍夫曼編碼表等等。
惟以上所述者，僅為本發明之較佳實施例而已，當不能以此限定本發明實施之範圍，即大凡依本發明申請專利範圍及發明說明內容所作之簡單的等效變化與修飾，皆仍屬本發明專利涵蓋之範圍內。舉例來說，軟體可以執行本發明所述之裝置與方法的功能、製造、形塑、模擬、描述以及/或測試等。這可由一般的程式語言(如C、C++)、硬體描述語言(HDL)包含Verilog HDL,VHDL等，或是其他既有程式來達成。此軟體可以設置於任何已知的電腦可利用媒介，如磁帶、半導體、磁碟、光碟(如CD-ROM、DVD-ROM等)、網路接線、無線或是其他通訊媒介。此處描述之裝置與方法的實施例可被包含於一半導體智財核心，例如一微處理核心(如以硬體描述語言的實施方式)並且透過積體電路的製作轉換為硬體。此外，本文所描述之裝置與方法亦可包含硬體與軟體之結合。因此，本文所述的任何實施例，並非用以限定本發明之範圍。此外，本發明可應用於一般通用電腦之微處理器裝置。最後，所屬技術領域具有通常知識者利用本發明所揭露的觀念與實施例作為基礎，來設計並調整出不同的結構已達成相同的目的，亦不超出本發明之範圍。
藉由以上具體實施例之詳述，希望能更加清楚描述本發明之特徵與精神，而並非以上述所揭露的 具體實施例來對本發明之範疇加以限制。相反地，其目的是希望能涵蓋各種改變及具相等性的安排於本發明所欲申請之專利範圍的範疇內。
100‧‧‧硬體資料壓縮器
101‧‧‧輸入區塊記憶體
102‧‧‧LZ77引擎
103‧‧‧散列記憶體
104‧‧‧分類引擎
105‧‧‧背向指標與旗標記憶體
106‧‧‧霍夫曼編碼表建構引擎
107‧‧‧表單記憶體
108‧‧‧霍夫曼編碼引擎
109‧‧‧輸出記憶體

Claims (19)

  1. 一種硬體資料壓縮器，利用背向指標取代一字元輸入區塊內之字元字串以壓縮該字元輸入區塊，該背向指標指向該字元輸入區塊內出現在先之匹配字串，該硬體資料壓縮器包括：一散列表，用以搜尋該輸入區塊內之該匹配字串；複數個散列索引產生器，各該散列索引產生器對該待取代之字元字串之一開始部分施以不同之散列演算法，以產生一相對應之索引；一字元輸入區塊類型指標；以及一選擇器，依據該輸入區塊之類型，選擇其中一個該散列索引產生器所產生之索引作為該散列表之索引。
  2. 如請求項第1項之硬體資料壓縮器，其中，該複數個散列索引產生器中之一第一散列索引產生器進行散列處理之位元少於該字串之該開始部分之該字元之所有位元，並且該複數個散列索引產生器中之一第二散列索引產生器係對該字串之該開始部分之該字元之所有位元進行散列處理。
  3. 如請求項第2項之硬體資料壓縮器，其中，該第一散列索引產生器係對該字串之該開始部分之各該字元中，除了上方位元以外之所有位元進行散列處理。
  4. 如請求項第3項之硬體資料壓縮器，其中，若是該輸入區塊類型指標顯示為ASCII文字，該選擇器選擇該第一散列索引產生器所產生之該索引作為該散列表之索引。
  5. 如請求項第1項之硬體資料壓縮器，其中，該複數個散列索引產生器中之一第一散列索引產生器對該字串之該開始部分之該字元施以一第一組算術與/或邏輯運算，該複數個散列索引產生器中之一第二散列索引產生器對該字串之該開始部分之該字元施以一第二組算術與/或邏輯運算，並且該第一組算術與/或邏輯運算不同於該第二組算術與/或邏輯運算。
  6. 如請求項第1項之硬體資料壓縮器，其中，該複數個散列索引產生器中之一第一散列索引產生器對該字串之該開始部分之一第一數量之字元進行散列處理，該複數個散列索引產生器中之一第二散列索引產生器對該字串之該開始部分之一第二數量之字元進行散列處理，並且該第一數量不同於該第二數量。
  7. 一種方法，包括：接收一字元輸入區塊類型指標，其中，該字元輸入區塊係利用背向指標取代該字元輸入區塊內之字元字串以進行壓縮，該背向指標指向該字元輸入區塊內出 現在先之匹配字串；依據該輸入區塊之類型，在多個散列演算法中選擇其一；利用所選擇之散列演算法對該待取代之字元字串之一開始部分施以散列處理，以產生一索引用於一散列表；以及利用該散列表搜尋該輸入區塊內之該匹配字串。
  8. 如請求項第7項之方法，其中，該複數個散列演算法中之一第一散列演算法進行散列處理之位元少於該字串之該開始部分之該字元之所有位元，並且該複數個散列演算法中之一第二散列演算法對該字串之該開始部分之該字元之所有位元進行散列處理。
  9. 如請求項第8項之方法，其中，該第一散列演算法係對該字串之該開始部分之各該字元中，除了上方位元以外之所有位元進行散列處理。
  10. 如請求項第9項之方法，其中，依據該輸入區塊之類型，在多個散列演算法中選擇其一之步驟包括：若是該輸入區塊類型指標顯示為ASCII文字，選擇該第一散列演算法。
  11. 如請求項第7項之方法，其中，該複數個散列演算法中之一第一散列演算法對該字串之該開始部分之該字元施以一第一組算術與/或邏輯運算，該複數個散列演算法中之一第二散列演算法對該字串之該開始部分之該字元施以一第二組算術與/或邏輯運算，並且該第一組算術與/或邏輯運算不同於該第二組算術與/或邏輯運算。
  12. 如請求項第7項之方法，其中，該複數個散列演算法中之一第一散列演算法對該字串之該開始部分之一第一數量之字元進行散列處理，以及該複數個散列演算法中之一第二散列演算法對該字串之該開始部分之一第二數量之字元進行散列處理，並且該第一數量不同於該第二數量。
  13. 一種編碼於至少一非暫態電腦可使用媒體以供一電腦裝置使用之一電腦程式產品，包括：內含於該媒體之電腦可使用程式碼，描述一硬體資料壓縮器，利用背向指標取代一字元輸入區塊內之字元字串以壓縮該字元輸入區塊，該背向指標係指向該字元輸入區塊內出現在先之匹配字串，該電腦可使用程式碼包括：第一程式碼，描述一散列表，用以搜尋該輸入區塊內之該匹配字串； 第二程式碼，描述複數個散列索引產生器，各該散列索引產生器對該待取代之字元字串之一開始部分施以不同之散列演算法，以產生一相對應之索引；第三程式碼，描述一字元輸入區塊類型指標；以及第四程式碼，描述一選擇器，依據該輸入區塊之類型，選擇其中一個該散列索引產生器所產生之索引作為該散列表之索引。
  14. 如請求項第13項之電腦程式產品，其中，該複數個散列索引產生器中之一第一散列索引產生器進行散列處理之位元少於該字串之該開始部分之該字元之所有位元，並且，該複數個散列索引產生器中之一第二散列索引產生器對該字串之該開始部分之該字元之所有位元進行散列處理。
  15. 如請求項第14項之電腦程式產品，其中，該第一散列索引產生器對該字串之該開始部分之各該字元中，除了上方位元以外之所有位元進行散列處理。
  16. 如請求項第15項之電腦程式產品，其中，若是該輸入區塊類型指標顯示為ASCII文字，該選擇器選擇該第一散列索引產生器所產生之該索引作為該散列表之索引。
  17. 如請求項第13項之電腦程式產品，其中，該複數個散列索引產生器中之一第一散列索引產生器對該字串之該開始部分之該字元施以一第一組算術與/或邏輯運算，該複數個散列索引產生器中之一第二散列索引產生器對該字串之該開始部分之該字元施以一第二組算術與/或邏輯運算，並且該第一組算術與/或邏輯運算不同於該第二組算術與/或邏輯運算。
  18. 如請求項第13項之電腦程式產品，其中，該複數個散列索引產生器中之一第一散列索引產生器對該字串之該開始部分之一第一數量之字元進行散列處理，該複數個散列索引產生器中之一第二散列索引產生器對該字串之該開始部分之一第二數量之字元進行散列處理，並且該第一數量不同於該第二數量。
  19. 如請求項第13項之電腦程式產品，其中，該至少一非暫態電腦可使用媒體係選自光碟、磁帶，或其他磁性、光學或電子儲存媒體所構成之一群組。
TW105114413A 2015-05-11 2016-05-10 依據輸入區塊類型使用動態散列演算法之硬體資料壓縮器 TWI591500B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562159352P 2015-05-11 2015-05-11
US14/883,106 US9509337B1 (en) 2015-05-11 2015-10-14 Hardware data compressor using dynamic hash algorithm based on input block type

Publications (2)

Publication Number Publication Date
TW201643758A true TW201643758A (zh) 2016-12-16
TWI591500B TWI591500B (zh) 2017-07-11

Family

ID=54608389

Family Applications (1)

Application Number Title Priority Date Filing Date
TW105114413A TWI591500B (zh) 2015-05-11 2016-05-10 依據輸入區塊類型使用動態散列演算法之硬體資料壓縮器

Country Status (4)

Country Link
US (2) US9509337B1 (zh)
EP (1) EP3094004B1 (zh)
CN (1) CN106021356B (zh)
TW (1) TWI591500B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI637313B (zh) * 2016-03-16 2018-10-01 美光科技公司 使用經壓縮與經解壓縮資料操作的裝置與方法

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI610573B (zh) * 2016-03-22 2018-01-01 晨星半導體股份有限公司 收視記錄處理電路與相關方法
CN107180018B (zh) * 2017-05-17 2018-11-20 上海兆芯集成电路有限公司 基于散列的加速压缩方法以及使用此方法的装置
CN107168936B (zh) * 2017-05-17 2019-02-19 上海兆芯集成电路有限公司 基于散列的加速压缩方法以及使用此方法的装置
US10521400B1 (en) * 2017-07-31 2019-12-31 EMC IP Holding Company LLC Data reduction reporting in storage systems
US10135463B1 (en) * 2017-09-29 2018-11-20 Intel Corporation Method and apparatus for accelerating canonical huffman encoding
US10097201B1 (en) * 2017-11-30 2018-10-09 Intel Corporation LZ77 compression of data with data runs
US10333548B1 (en) 2018-04-09 2019-06-25 International Business Machines Corporation Efficient software closing of hardware-generated encoding context
CN109802685B (zh) * 2019-01-30 2022-12-27 上海兆芯集成电路有限公司 加速压缩方法以及加速压缩装置
US10944423B2 (en) * 2019-03-14 2021-03-09 International Business Machines Corporation Verifying the correctness of a deflate compression accelerator
US11223369B2 (en) 2019-04-02 2022-01-11 International Business Machines Corporation Automatic hash function selection
US11955995B2 (en) * 2020-05-11 2024-04-09 Intel Corporation Apparatus and method for two-stage lossless data compression, and two-stage lossless data decompression
US11663119B2 (en) 2020-05-29 2023-05-30 International Business Machines Corporation Select decompression headers and symbol start indicators used in writing decompressed data
CN112737596A (zh) * 2021-01-07 2021-04-30 苏州浪潮智能科技有限公司 一种基于排序网络的动态霍夫曼编码方法、装置及设备
CN116304056B (zh) * 2023-04-11 2024-01-30 山西玖邦科技有限公司 一种用于计算机软件开发数据的管理方法

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5532694A (en) 1989-01-13 1996-07-02 Stac Electronics, Inc. Data compression apparatus and method using matching string searching and Huffman encoding
US5049881A (en) 1990-06-18 1991-09-17 Intersecting Concepts, Inc. Apparatus and method for very high data rate-compression incorporating lossless data compression and expansion utilizing a hashing technique
US5051745A (en) 1990-08-21 1991-09-24 Pkware, Inc. String searcher, and compressor using same
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
US5532693A (en) 1994-06-13 1996-07-02 Advanced Hardware Architectures Adaptive data compression system with systolic string matching logic
JP4242970B2 (ja) 1998-07-09 2009-03-25 富士通株式会社 データ圧縮方法及びデータ圧縮装置
US6130630A (en) 1998-10-27 2000-10-10 Hewlett-Packard Company Apparatus and method for compressing Huffman encoded data
US6304197B1 (en) 2000-03-14 2001-10-16 Robert Allen Freking Concurrent method for parallel Huffman compression coding and other variable length encoding and decoding
US7064489B2 (en) 2000-09-28 2006-06-20 Roke Manor Research Limited Huffman data compression method
US7283591B2 (en) 2003-03-28 2007-10-16 Tarari, Inc. Parallelized dynamic Huffman decoder
US7283686B2 (en) 2003-04-14 2007-10-16 Hewlett-Packard Development Company, L.P. Image processor
US6879270B1 (en) 2003-08-20 2005-04-12 Hewlett-Packard Development Company, L.P. Data compression in multiprocessor computers
US20060106870A1 (en) 2004-11-16 2006-05-18 International Business Machines Corporation Data compression using a nested hierarchy of fixed phrase length dictionaries
US7650429B2 (en) 2005-02-04 2010-01-19 Cisco Technology, Inc. Preventing aliasing of compressed keys across multiple hash tables
US7307552B2 (en) 2005-11-16 2007-12-11 Cisco Technology, Inc. Method and apparatus for efficient hardware based deflate
CN101467149A (zh) * 2006-06-30 2009-06-24 电子地图北美公司 具有可变压缩的自适应索引
WO2009005758A2 (en) * 2007-06-29 2009-01-08 Rmi Corporation System and method for compression processing within a compression engine
US7970128B2 (en) * 2007-07-20 2011-06-28 Freescale Semiconductor, Inc. Systems and methods for efficient generation of hash values of varying bit widths
US7737870B1 (en) 2007-09-04 2010-06-15 Nortel Networks Limited Bit-stream huffman coding for data compression
FI2297856T3 (fi) 2008-07-11 2023-03-30 Fraunhofer Ges Forschung Menetelmä symbolin koodaamiseksi, menetelmä symbolin dekoodaamiseksi, menetelmä symbolin lähettämiseksi lähettimeltä vastaanottimelle, kooderi, dekooderi ja järjestelmä symbolin lähettämiseksi lähettimeltä vastaanottimelle
US8766872B2 (en) 2008-12-24 2014-07-01 Enzo Dalmazzo Autonomous wireless antenna sensor system
US7834781B2 (en) 2009-04-06 2010-11-16 International Business Machines Corporation Method of constructing an approximated dynamic Huffman table for use in data compression
US9160611B2 (en) 2009-04-22 2015-10-13 Webroot Inc. System and method for performing longest common prefix strings searches
US9392005B2 (en) * 2010-05-27 2016-07-12 Samsung Sds Co., Ltd. System and method for matching pattern
US8462781B2 (en) * 2011-04-06 2013-06-11 Anue Systems, Inc. Systems and methods for in-line removal of duplicate network packets
US8542135B2 (en) 2011-11-24 2013-09-24 International Business Machines Corporation Compression algorithm incorporating automatic generation of a bank of predefined huffman dictionaries
US8610606B2 (en) 2011-11-24 2013-12-17 International Business Machines Corporation Compression algorithm incorporating dynamic selection of a predefined huffman dictionary
KR20130062889A (ko) 2011-12-05 2013-06-13 삼성전자주식회사 데이터 압축 방법 및 시스템
KR101956031B1 (ko) 2012-10-15 2019-03-11 삼성전자 주식회사 데이터 압축 장치 및 방법, 데이터 압축 장치를 포함하는 메모리 시스템
CN202931289U (zh) * 2012-11-14 2013-05-08 无锡芯响电子科技有限公司 一种硬件lz77压缩实现系统
US9002792B2 (en) * 2012-11-19 2015-04-07 Compellent Technologies Confirming data consistency in a data storage environment
US8704686B1 (en) 2013-01-03 2014-04-22 International Business Machines Corporation High bandwidth compression to encoded data streams
US8766827B1 (en) 2013-03-15 2014-07-01 Intel Corporation Parallel apparatus for high-speed, highly compressed LZ77 tokenization and Huffman encoding for deflate compression
US8933824B1 (en) 2013-08-28 2015-01-13 International Business Machines Corporation Hardware decompression of deflate encoded data with multiple blocks
US9252807B2 (en) 2013-10-21 2016-02-02 Globalfoundries Inc. Efficient one-pass cache-aware compression
US9258013B1 (en) 2015-09-01 2016-02-09 Rockwell Collins, Inc. Data compression with Huffman code on multicore processors

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI637313B (zh) * 2016-03-16 2018-10-01 美光科技公司 使用經壓縮與經解壓縮資料操作的裝置與方法
US10379772B2 (en) 2016-03-16 2019-08-13 Micron Technology, Inc. Apparatuses and methods for operations using compressed and decompressed data
US11314429B2 (en) 2016-03-16 2022-04-26 Micron Technology, Inc. Apparatuses and methods for operations using compressed and decompressed data

Also Published As

Publication number Publication date
CN106021356B (zh) 2019-07-16
US9768803B2 (en) 2017-09-19
US20160380649A1 (en) 2016-12-29
US20160336962A1 (en) 2016-11-17
US9509337B1 (en) 2016-11-29
EP3094004A1 (en) 2016-11-16
CN106021356A (zh) 2016-10-12
TWI591500B (zh) 2017-07-11
EP3094004B1 (en) 2022-05-11

Similar Documents

Publication Publication Date Title
TWI591500B (zh) 依據輸入區塊類型使用動態散列演算法之硬體資料壓縮器
TWI594238B (zh) 直接對ｌｚ７７引擎輸出之標記進行霍夫曼編碼程序之硬體資料壓縮器
TWI586113B (zh) 利用預先霍夫曼編碼決定對匹配字串或背向指標執行霍夫曼編碼程序之硬體資料壓縮器
TWI606699B (zh) 建構並使用動態初期霍夫曼編碼表之硬體資料壓縮器
TWI597943B (zh) 基於節點字串匹配機率對散列鏈進行分類之硬體資料壓縮器、方法與電腦程式產品
TWI598756B (zh) 硬體資料壓縮器及其方法
TWI639926B (zh) 在輸入區塊掃描時維持分類符號列之硬體資料壓縮器
JP6363581B2 (ja) 入力ブロックのスキャンと同時にソート済みシンボル・リストを維持するハードウェア・データ圧縮器