技术领域：
：本申请案主张申请日为2015年5月11日的美国专利第62/159,352号临时申请案的国际优先权。此优先权案的全文并入本案以供参考。
背景技术：
：：有效率的数据压缩已经成为计算机世界中一个重要需求。这主要是因为许多文件都是经过压缩后再透过网络传送，并在被接收后经过解压缩再为被接收端所利用。此种传输方式可以降低网络传送的文件大小，以节省传输时间以及网络带宽的使用。技术实现要素：有鉴于此，本发明提供一种硬件数据压缩器，利用反向指针取代字符输入区块内的字符字符串以压缩字符输入区块，此反向指针指向字符输入区块内出现在先的匹配字符串。此硬件数据压缩器包括散列表，多个散列索引产生器，字符输入区块类型指针，以及选择器。散列表用以搜寻该输入区块内的该匹配字符串。各个散列索引产生器对待取代的字符字符串的开始部分施以不同的散列算法，以产生相对应的索引。选择器依据输入区块的类型，选择其中一个散列索引产生器所产生的索引作为散列表的索引。本发明还提供一种方法。首先，接收字符输入区块类型指针。此字符输入区块利用反向指针取代字符输入区块内的字符字符串以进行压缩，而反向指针指向字符输入区块内出现在先的匹配字符串。随后，依据输入区块的类型，在多个散列算法中选择其一。接下来，利用所选择的散列算法对待取代的字符字符串的开始部分施以散列处理，以产生索引用于散列表。然后，利用此散列表搜寻输入区块内的匹配字符串。本发明还提供一种编码于至少非瞬时计算机可使用媒体以供计算机装置使用的计算机程序产品。此计算机程序产品包括内含于该媒体的计算机可使用程序代码，描述硬件数据压缩器，用以利用反向指针取代字符输入区块内的字符字符串以压缩字符输入区块，此反向指针指向字符输入区块内出现在先的匹配字符串。此计算机可使用程序代码包括第一程序代码，第二程序代码，第三程序代码与第四程序代码。第一程序代码描述散列表，用以搜寻输入区块内的匹配字符串。第二程序代码描述多个散列索引产生器，各个散列索引产生器对待取代的字符字符串的开始部分施以不同的散列算法，以产生相对应的索引。第三程序代码描述字符输入区块类型指针。第四程序代码描述选择器，用以依据输入区块的类型，选择其中一个散列索引产生器所产生的索引作为此散列表的索引。本发明所采用的具体实施例，将通过以下的实施例及图式作进一步的说明。附图说明图1为硬件数据压缩器的方块示意图。图2A为方块示意图，显示图1的硬件数据压缩器的一部分。图2B为时序图，显示图2A的LZ77引擎与分类引擎的处理程序。图3为流程图，显示图2A的LZ77引擎与分类引擎的处理程序。图4为方块图，显示供图1的分类引擎使用的频率表、分类列与尾端指针。图5为流程图，显示图1的分类引擎依据图3的实施例进行的处理程序。图6为方块图，显示图4中被分类引擎更新的频率表、分类列与尾端指针。图7为方块图，显示图6中被分类引擎更新的频率表、分类列与尾端指针。图8为方块图，显示图7中被分类引擎更新的频率表、分类列与尾端指针。图9为时序图，以图形显示传统DEFLATE类型输入区块压缩所费时间的各个部分。图10为时序图，以图形显示同步符号列分类的实施例的DEFLATE类型输入区块压缩所费时间的各个部分。图11A为方块图，显示本发明另一实施例的分类列。图11B为方块图，显示本发明另一实施例的频率表。图12为方块图，显示图1的硬件数据压缩器的另一实施例。图13为时序图，以图形显示依据本发明另一实施例进行压缩所费时间的各个部分。图14A为流程图，显示图1的LZ77引擎配合动态初期霍夫曼编码执行数据压缩的处理程序。图14B为流程图，显示图1的霍夫曼编码表建构引擎配合动态初期霍夫曼编码执行数据压缩的运作。图14C为流程图，显示图1的霍夫曼编码引擎配合动态初期霍夫曼编码执行数据压缩的运作。图15为时序图，以图形显示传统上对DEFLATE型输入区块进行压缩所费时间的各个部分。图16为时序图，以图形显示依据本发明的动态初期霍夫曼编码表对DEFLATE型输入区块进行压缩所费时间的各个部分。图17A为流程图，显示硬件数据压缩器建构动态初期霍夫曼编码表的运作的一实施例。图17B为流程图，显示硬件数据压缩器建构动态初期霍夫曼编码表的运作的一实施例。图17C为流程图，显示硬件数据压缩器建构动态初期霍夫曼编码表的运作的一实施例。图18为方块图，显示图1的硬件数据压缩器的硬件的一实施例。图19为流程图，显示分类引擎通知建构霍夫曼编码表的处理程序。图20为时序图，以图形显示本发明对DEFLATE型输入区块进行压缩所费时间的各个部分的另一实施例。图21为方块图，显示图1的硬件数据压缩器的一部分。图22为流程图，显示硬件数据压缩器压缩数据的处理程序。图23A为流程图，显示图22的步骤的一实施例。图23B为流程图，显示图22的步骤的另一实施例。图24为方块图，显示图1的LZ77引擎的一部分。图25为流程图，显示图24的LZ77引擎的运作。图26为方块图，显示本发明硬件数据压缩器的一实施例。图27为方块图，显示图26的散列链的节点。图28为流程图，显示硬件数据压缩器利用动态节点机率的实施方式，执行图26所示于散列表中插入新节点显示的运作。图29为时序图，显示图26的硬件数据压缩器依据图28的流程执行的运作。图30为流程图，显示图26的硬件数据压缩器依据动态节点机率的实施例分类散列链的运作。图31为时序图，例示硬件数据压缩器依据图26至图30执行的运作。图32为流程图，显示产生图33所示的查找表的方法，此查找表用于静态散列链节点机率的实施例。图33为用于静态散列链节点机率实施例的查找表。图34为流程图，显示图26的硬件数据压缩器依据静态节点机率的实施例分类散列链的运作。图35为时序图，例示图26的硬件数据压缩器依据图34执行的运作。图36为方块图，显示本发明硬件数据压缩器的另一实施例。图37为流程图，显示图36的硬件数据压缩器的运作。图38为时序图，显示图36的硬件数据压缩器依据图37的方法执行的运作。图39为方块图，显示图1的LZ77引擎的一部分。图40为流程图，显示图39的LZ77引擎的运作。图41为方块图，详细显示图39的散列索引产生器。图42为方块图，显示包含如图1所示的硬件数据压缩器100的系统。图43为方块图，显示包含硬件数据压缩器的系统的另一实施例。具体实施方式常见的文件压缩程序，如gzip与zlib，是将输入文件压缩，以期能产生较小的输出文件。此输出文件具有设定格式，使文件解压缩程序(例如gzip与zlib)可以将其解压缩并产生与原本输入文件相同的解压缩文件。压缩文件包含一系列的块(block)，对应至输入文件的连续数据块。此压缩文件的各个块的格式符合RFC1951规范，DEFLATE压缩数据格式规范版本1.3(DEFLATEcompresseddataformatspecificationversion1.3)所定义的无损(lossless)压缩数据格式，输入文件的各个块同时使用LZ型算法(例如LZ77)与霍夫曼(Huffman)编码进行压缩演算。此技术可参照ZivJ.,LempelA.,“AUniversalAlgorithmforSequentialDataCompression,”IEEETransactionsonInformationTheory,Vol.23,No.3,pp.337-343；以及Huffman,D.A.,“AMethodfortheConstructionofMinimumRedundancyCodes,”ProceedingsoftheInstituteofRadioEngineers,September1952,Volume40,Number9,pp.1098-1101。LZ77压缩算法(以及其变化版本)将输入数据串流内重复出现的数据或字符串，利用指向输入数据串流中较早出现字符串的反向指针(backpointer)进行取代，以将输入数据串流压缩为无损型式。字符串由一个或多个连续字符构成。反向指针为有序对(orderedpair)(即长度、距离)，长度为定义在输入数据串流的当前扫描位置的字符串的字符数，距离则是定义与此字符串相同的前一个字符串的开始位置与当前扫描位置的距离。反向指针可由以下叙述加以理解：“后续每一个长度字符等同于在未压缩串流的距离字符正前方的字符”。此算法利用反向指针取代重复字符串的字符以进行压缩。进一步来说，LZ77算法始于当前扫描位置，于输入数据串流内，反向搜寻字符串匹配(例如：如果有匹配字符串的话，其中长度最长的匹配字符串)，并以一个反向指针进行取代。若是找到适当的匹配，此算法就会为此匹配字符串产生反向指针，反之，此算法就会产生词汇输入字符(literalinputcharacters)，如当前扫描位置的三个字符，并更新当前扫描位置。DEFLATE规范使用“词汇”来表示算法产生输入字符而非利用反向指针来取代输入字符的情况。依此，LZ77压缩的有效输出会是一个由词汇与反向指针(有时也包含各个词汇与反向指针频率的直方图，这部分在后续段落会有更详细的描述)构成的串流。在此规范中，词汇与反向指针称为标记，因此LZ77压缩会输出标记串流。所达成的压缩量主要受到输入数据串流内字符串重复的程度以及重复字符串的长度影响。DEFLATE规范将霍夫曼编码，通常也称为前置编码(prefixcoding)，描述为“前置编码是以位序列(字码)表示先前已知符号集的符号，每个符号赋予一个字码，不同符号可由不同长度的位序列来表示，然而解析器总是可以对编码字符串逐个符号清楚地进行解析。对于具有已知符号频率的符号集，霍夫曼算法可以建构最佳前置编码(即对于此符号集，在各种可能的前置编码中，利用最少位来表示具有这些符号频率的字符串的编码)。此编码即称为霍夫曼编码”。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压缩程序中扫描输入区块所花费的时间，依据建构霍夫曼编码表的时间点，在某些情况下，霍夫曼编码步骤在输入区块压缩流程外几乎不会额外花费任何时间。此外，如图9所示，本案发明人观察到，依据各个符号的出现频率来对直方图进行分类(这是建构有效率的霍夫曼编码表的必要步骤)相当费时并且是压缩流程的关键步骤的一环，但这会导致总压缩时间的增加。相较之下，在本发明实施例中，此依据频率进行的分类步骤以递增方式进行-旧一实施例而言若利用LZ77引擎产生各个符号(举例来说，可参照图2A与图2B)，可由另一个硬件引擎来执行分类步骤-并与输入区块的扫描同时执行，而使分类步骤所需花费的时间涵盖于输入区块的扫描时间内，以减少总花费时间分类引擎可由本案发明人的观察结果获得帮助。若是利用LZ77引擎产生各个符号，而其频率值的变化只有一，就会有很高的可能性不需改变此符号在分类列的位置。不过，也会有很高的可能性只需对其位置进行短距离的调整，而此调整能很快地完成。尤其是，完成前述改变符号在分类列的位置所需的时间有很高的可能性会少于LZ77引擎搜寻并找到匹配目标字符串的时间。此外，有利的是，此递增与同步符号列分类机制还可与动态初步霍夫曼编码表的实施例结合。硬件数据压缩器图1为方块图，显示硬件数据压缩器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可使用文献ZivJ.,LempelA.,“AUniversalAlgorithmforSequentialDataCompression,”IEEETransactionsonInformationTheory,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使用散列表(hashtable)与散列技术以降低搜寻匹配字符串的时间。此技术在后续段落会有更详细的说明。散列表储存于散列内存103内。在一实施例中，此LZ77引擎利用双散列表以提升压缩时间。此技术在后续段落也会有更详细的说明。LZ77引擎102、分类引擎104、霍夫曼编码表建构引擎106、与霍夫曼编码引擎108可以存取窗体内存107。窗体内存107内的频率表(例如图4的组件401)储存LZ77引擎102输出标记串流内出现的各个符号的频率(图4的组件402)或次数。在一实施例中，LZ77引擎102维持频率表401的各个频率值402。在另一实施例中，分类引擎104因应LZ77引擎102产生的标记212，来维持频率表401的各个频率值402。在另一实施例中，霍夫曼编码表建构引擎106因应LZ77引擎102产生的标记212，来维持频率表401的各个频率值402。分类引擎104依据各个符号的频率(例如使用图4的频率表401的项目的分类索引字段404)，来维持符号分类列(例如图4的组件403)，这部分在后续段落会有更详细的描述。此外，霍夫曼编码表建构引擎106并利用此以频率分类的符号分类列来建构霍夫曼编码表，供霍夫曼编码引擎108对关联于LZ77引擎102输出串流的标记的符号进行霍夫曼编码，以储存于输出内存109。就一实施例而言，此霍夫曼编码引擎108利用两个霍夫曼编码表，其一供词汇与长度符号之用，另一个供距离符号之用，因而需维持两个相对应的频率表与分类列供建构此二个霍夫曼编码表所用。在一实施例中，此霍夫曼编码表建构引擎106依据已知的典型霍夫曼编码程序，例如DEFLATE规范中使用的程序，来建构霍夫曼编码表。就一实施例而言，对常值符号进行霍夫曼编码，表示输出关联于此词汇符号的值(例如图11A的符号值406或图11B的频率表401内的索引)的霍夫曼编码(例如图11A与图11B的霍夫曼编码1108)；对反向指针长度进行霍夫曼编码，表示输出关联于此长度符号值的霍夫曼编码，其长度范围涵盖此反向指针的长度，加上任何用以指定此反向指针长度(如后续表1所示，此表撷取自DEFLATE规范的段落3.2.5)的额外位；对反向指针距离进行霍夫曼编码，表示输出关联于此距离符号的值的霍夫曼编码，其距离范围涵盖此反向指针的距离加上任何用以指定此反向指针距离(如后续表2所示，此表撷取自DEFLATE规范的段落3.2.5)的额外位。需理解的是，表1内出现“编码”的用语是因为此用语使用于DEFLATE规范的图表内。不过，表1的“编码(Code)”栏内的值并非如图11A与图11B的组件1108所示的霍夫曼编码，而是如对应于图4的实施例的符号值406，也即图4的频率表401的索引值。与距离符号有关的表2也相同。编码额外位长度25703258042590526006261072620826309264010265111，12266113，14267115，16268117，18269219-22270223-26271227-30272231-34273335-42274343-50275351-58276358-66277467-82278483-98279499-1142804115-1302815131-1622825163-1942835195-2262845227-257表1编码额外位距离001102203304415，6517，8629-127213-168317-249325-4310433-4811449-6412565-9613597-128146129-192156193-256167257-384177385-512188513-768198769-10242091025-15362191537-2048221102049-3072231103073-409624114097-614425116145-819226128193-12288271212290-16384281316385-24576291324577-32768表2在其它实施例中，也可省略分类引擎104，而由霍夫曼编码表建构引擎106在LZ77引擎102完成频率表的更新后，执行频率表的符号分类。一般而言，LZ77引擎102会在完成整个输入区块的扫描后才停止更新频率表，不过本发明的实施例的LZ77引擎102则是在扫描完输入区块的开始部分后就停止更新频率表，而霍夫曼编码表建构引擎106随即开始建构霍夫曼编码表-在本文称为“动态-初始”霍夫曼编码表。输入区块扫描时维持分类符号列图2A为方块图，显示图1的硬件数据压缩器100的一部分。如图中所示，图1的LZ77引擎102产生标记212至分类引擎104。标记212为反向指针或是词汇字符串(可为单一个词汇字符)的标志。在一实施例中，此标记212为输入区块内存101内词汇字符串位置的指针或索引。在此实施例中，分类引擎104可存取输入区块内存101。在另一实施例中，标记212为词汇字符串本身，例如字符字符串的值。在一实施例中，标记为指针或是指针内存105内反向指针位置的索引。在此实施例中，分类引擎104可存取指针内存105。在另一实施例中，标记212为反向指针本身，例如反向指针的长度或距离值。分类引擎104依据更新窗体内存107内频率表401与分类列403的进度，产生准备完成信号214至LZ77引擎。这部分在后续段落，尤其是图3的部分，会有更详细的说明。由后续图3至图8的描述可推知，若是符号的频率与其它多个位于符号列上方的符号的频率相同时，分类引擎104在符号频率递增的过程中就需要执行多个交换动作以确认符号在分类列403中的正确位置，而会产生病态案例(pathologicalcase)。此外，此符号递增频率可能等于位于其上方但具有较后的语汇值(lexicalvalue)的多个符号，因此分类引擎104在符号频率递增的过程中就需要执行多个交换动作以确认符号在分类列403中的正确位置。若是分类引擎104繁忙而无法由LZ77引擎102接收标记212，对输入区块执行压缩所需要的时间就会增加。一般而言，病态案例较可能发生于符号频率的分布相当均匀的情形，此情形特别容易发生于扫描输入内存的初期，因为在开始的时候所有的频率值都是零。值得注意的是，在本文图14A至图14C与图16所述的实施例中，其频率值初始化为不同数值，因而可以降低产生病态案例的可能性。在一实施例中，硬件数据压缩器100在LZ77压缩引擎102与分类引擎104间包含短的先进先出内存，在必要时暂时储存由LZ77压缩引擎102提供给分类引擎104的标记212，以减少或在部分情况下消除此病态案例对于压缩程序的冲击。此先进先出内存的满溢旗标(fullflag)输出信号可作为提供给LZ77压缩引擎102的准备完成信号214。图2B为时序图，显示图2A的LZ77引擎102与分类引擎104的处理程序。此时序图的上部分显示LZ77引擎102的处理程序，下部分显示分类引擎104的处理程序。时间进程由左而右。图中无时间单位而以相对时间描绘。不过，图中的时间可以时钟周期、奈秒，或其它相关的时间单位表示。如图中所示，在时间0的时候，LZ77引擎102对于始在当前搜寻位置的字符串，扫描输入区块搜寻是否有字符串匹配(如图3的步骤302)，而在时间6的时候，输出标记212(标示为标记N)至分类引擎104。因应此标记N，分类引擎104递增各个关联于标记N的符号的频率，并重新对分类列的符号进行分类(例如图4的分类列403)以维持各个符号依频率(或词汇顺序)的分类顺序(如图3的步骤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完成分类动作(除非如前所述，存在先入先出内存而此内存尚未存满)。如图2B所示，在LZ77引擎102扫描输入区块的同时，分类引擎104渐进维持依频率分类的符号列，因而可以使维持符号分类列所需的时间，涵盖在输入区块的扫描时间内。这部分在本文会有更详细的说明。图3为流程图，显示图2A的LZ77引擎102与分类引擎104的处理程序。在图3中，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会递增符号的频率(如图4的步骤402所示)，并依据符号出现频率与词汇顺序维持分类列(如图4的步骤403所示)。此部分在后续图5会有更详细的说明。接下来前进至步骤318。在步骤318中，分类引擎104输出真(true)值于准备完成信号214。接下来，流程回到步骤312。如前述，一般而言，分类引擎104执行步骤316所花费的时间会少于LZ77引擎执行步骤302所花费的时间。因此，分类引擎104因应LZ77引擎102产生的标记执行步骤316维持符号分类列所需的时间基本上会涵盖于LZ77引擎102在步骤102中产生下一个标记所需的时间内。如同本案发明人的观察，因为符号的频率值的变化只有一，因而有很高的可能性，不须改变符号在分类列的位置。但就算要改变在分类列的位置时，也会有很高的可能性只需对其位置进行短距离的调整，而分类引擎104执行此操作所花时间，通常可以比LZ77引擎102执行字符串搜寻来得快。图4为方块图，显示供图1的分类引擎104使用的频率表401、分类列403与尾端指针407。频率表401为项目数组，而各个项目包含两个字段：频率字段402与分类索引字段404。各个项目关联于将由图1的霍夫曼编码引擎108编码的各个符号的符号空间中不同的符号，符号的值为频率表401的索引，符号的频率402会在每次符号出现于LZ77引擎102的输出串流时进行更新。在图4的实施例中，符号空间包含数值0至285，作为频率表401的索引。符号空间值0至285对应于DEFLATE规范所定义的词汇与长度符号，不过本发明并不限于此。其它符号的符号表也可用于本发明并利用本文所述，在硬件压缩引擎扫描输入区块(如图2B所示)的过程中同时使用硬件分类引擎渐进地维持依频率分类的符号列。频率表401内的项目的分类索引404，被符号值指针作为索引指向分类列403中，被分类引擎104所扫描的符号值406之上。这部分在图5会有更详细的描述。分类列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(如图5的步骤512与516所示)进行比较，以确认当前符号是否需要在分类列403中向上移动。尾端指针407指向分类列403中下一个可用项目，作为放置LZ77引擎102输出串流下一个新出现符号的位置。位于尾端指针407及其下方的项目均为空白。本实施例仅呈现单一个频率表401与单一个分类列403(例如：用于词汇与长度)，不过本技术所属
技术领域：
：者当可推知，本实施例另维持一个用于距离的频率表与分类列。举例来说，在DEFLATE规范中，距离频率表401与距离分类列403分别具有30个项目(项目0至29)，而非如供词汇与距离使用的频率表与分类列具有286个项目。图4显示多种不同数值以说明频率表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。这些数值用于图6至图8中以说明图5的分类引擎104的运作。图5为流程图，显示图1的分类引擎104执行图3的步骤316的一实施例。在以下图5的描述中利用虚拟程序代码来说明分类引擎104的处理程序，不过需注意的是，此分类引擎104是一个以硬件而非软件执行多种不同操作的硬件引擎。此流程始于步骤502。在步骤502中，分类引擎104从LZ77引擎接收标记212，并确认关联于此标记212的符号。分类引擎104会对每一个符号都执行此处理程序，尽管，图5只描述分类引擎104针对单一关联符号进行的处理程序。如前述，若是标记212是一个反向指针，此标记212会具有两个关联符号：反向指针的长度与距离。不过，若是标记212是一个词汇字符串，此标记212具有的关联符号的数量就会与此字符串的字符数相同，而这些符号就会是字符串字符值。举例来说，15字符的ASCII词汇字符串标记212，“Thisistheday”，具有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的运作：incrementfreq_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_ptrsorted_list[tail_ptr]＝this_symbol_valincrementtail_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].freqthis_sorted_idx＝freq_tbl[this_symbol_val].sorted_idxabove_symbol_val＝sorted_list[this_sorted_idx-1]Y＝freq_tbl[above_symbol_val].freqif(X>Y)在步骤514中，分类引擎104将此符号于分类列403中向上移动。也就是说，分类引擎104会将此符号于分类列403中的位置与位于其上方项目内符号的位置互换。这不只涉及更新分类列403中相关项目的符号值406，还涉及更新频率表401的相关项目的分类索引404值。流程会由步骤514回到步骤508，来判断此符号是否需要在分类列403中再次向上移动。以下的虚拟程序代码可说明步骤514与步骤522的运作：decrementfreq_tbl[this_symbol_val].sorted_idxincrementfreq_tbl[above_symbol_val].sorted_idxsorted_list[this_sorted_idx]＝above_symbol_valsorted_list[this_sorted_idx-1]＝this_symbol_val在决策步骤516中，分类引擎104确认此符号的频率402是否等于分类列403中位于其上方的符号的频率402。若是，流程前进至决策步骤518；否则就终止。以下的虚拟程序代码可说明步骤516的运作：X＝freq_tbl[this_symbol_val].freqthis_sorted_idx＝freq_tbl[this_symbol_val].sorted_idxabove_symbol_val＝sorted_list[this_sorted_idx-1]Y＝freq_tbl[above_symbol_val].freqif(X＝＝Y)在决策步骤518，分类引擎104确认此符号值的词汇顺序是否早于分类列403中位于其上方的符号，也就是确认此符号是否具有较小的值。若是，流程前进至步骤522；否则就终止。以下的虚拟程序代码可说明步骤518的运作：if(this_symbol_val<sorted_list[this_symbol_val–1])在步骤522中，分类引擎104将符号于分类列403中向上移动，类似于前述步骤514。流程会从步骤522回到决策步骤516，判断此符号是否需要在分类列403中再次向上移动。图6为方块图，显示图4的频率表401、分类列403与尾端指针407经分类引擎104进行更新的情形。图6显示频率表401与分类列403在分类引擎104已执行所接收的符号27后的状态。特别是，分类引擎104会依据图5的步骤502，使频率表401的索引27处的频率402由180增加至181。此外，分类引擎会依据图5的步骤512确认符号27的频率402，其值为181，现在大于在图4分类列403中位于其上方的符号的频率402，也就是符号1，其频率为180。因此，分类引擎104就会依照图5的步骤514，将分类列403中符号27与符号1的位置互换。此步骤涉及将项目24的符号值406从1变更为27，将项目25的符号值406从27变更为1，也涉及互换其相对应的分类索引404值。就一实施例而言，分类引擎104会将符号1的分类索引404值从24增加至25，而将符号27的分类索引404值从25减少到24。图6中以灰底方块显示前述数值变更，并以虚线箭头显示相关联的分类索引404指针值。图7为方块图，显示图6的频率表401、分类列403与尾端指针407经分类引擎104进行更新的情形。图7显示图6的频率表401与分类列403在分类引擎104再次执行所接收的符号27后的状态。特别是，分类引擎104依据图5的步骤516确认符号27的频率402，其值为181，等于图6的分类列403中位于其上方的符号的频率402，也就是符号29，此符号的频率也是181。分类引擎104并依据决策步骤518确认符号27的值的词汇顺序早于分类列403中位于其上方的符号29。于是，分类引擎104就会依照图5的步骤522，将分类列403中符号27与符号29的位置互换。此步骤涉及将项目23的符号值406从29变更为27，将项目24的符号值406从27变更为29，也涉及互换其相对应的分类索引404值。就一实施例而言，分类引擎104会将符号29的分类索引404值从23增加至24，而将符号27的分类索引404值从24减少到23。图7中以灰底方块显示前述数值变更，并以虚线箭头显示相关联的分类索引404指针值。图8为方块图，显示图7的频率表401、分类列403与尾端指针407经分类引擎104进行更新的情形。图8显示图7的频率表401与分类列403在分类引擎104执行所接收的符号283后的状态。特别是，分类引擎104会依据图5的步骤502，使频率表401的索引283处的频率402由0增加至1。此外，分类引擎会依据图5的决策步骤504确认符号283是否首次出现。于是，分类引擎104就会依照图5的步骤506，将符号283插入分类列403的尾端，即图8中分类列403的索引278处。这涉及将符号值283插入由图7的尾端指针407指向的项目的符号值406字段，即项目278，这还涉及将图7的尾端指针407，其值为278，储存至频率表401的项目283的分类索引404中。分类引擎104并使尾端指针407从278增加至279。图8中以灰底方块显示前述数值变更，并以虚线箭头显示相关联的分类索引404指针与尾端指针407值。利用图3至图8所述的操作，分类引擎104可以有效地在LZ77引擎102完成或接近完成扫描输入区块时，提供以频率与词汇顺序进行分类的符号列403。换言之，符号分类时间(如图10的时序图中方块1003所示)－除了可能出现的对于分类列中关联于最后一个标记的符号进行更新所需的时间－会与LZ77引擎102扫描输入区块的时间(如图10的时序图中方块1002所示)重叠，因此相较于图9的传统压缩方式，本发明可以减少总压缩时间。此外，在大部分的情况下，更新分类列403中关联于LZ77输出标记串流的最后标记212的符号位置所费的时间会相当少。这是因为，此时，频率表401的频率分布，相对而言很可能是呈现不均匀的状态，因此在大部分的情况下，此最后标记的频率402的递增过程将不需要对分类列403进行更新，而很可能只需要单一个向上移动的步骤。此最后符号通常是区块终点(end-of-block)符号，这个符号在处理过程中从未见过，因而将会被插入分类列的尾端。分类引擎104会对此而不具有反向指针的区块终点符号的词汇执行特殊检测，因此霍夫曼编码表的建构过程就不需因为此区块终结符号而产生延迟。图9为时序图，以图形显示传统上对DEFLATE型输入区块进行压缩所费时间的各个部分。如方块902的步骤所示，在压缩开始时扫描输入区块并产生LZ77标记串流，同时维持直方图以显示符号出现频率。在方块902的步骤完成后，在方块903所示的步骤中，符号会依其频率顺序进行分类。在方块903的步骤完成后，在方块904所示的步骤中，就会利用前述以频率进行分类的符号来建构霍夫曼编码表。在方块904的步骤完成后，在方块906所示的步骤中，就会使用前述霍夫曼编码表来对输入区块进行霍夫曼编码，也即对LZ77输出标记串流进行霍夫曼编码。前述关联于方块902、903、904与906操作依其顺序连续地执行。因此，总压缩时间就会是关联于方块902、903、904与906所费时间的总和。图10为时序图，以图形显示依据本发明同步符号列分类的实施例，对DEFLATE型输入区块进行压缩所费时间的各个部分。如方块1002的步骤所示，在压缩开始时，LZ77引擎102扫描输入区块内存101内的字符输入区块并产生标记212串流，例如重复图3的步骤302至308以产生标记212。在压缩开始后没多久，即LZ77引擎102产生第一个标记212时，如方块1003所示的步骤中，分类引擎104会持续地依据符号出现频率以及当频率相同时依照词汇顺序进行分类的符号列，如图3的步骤312至318所示。方块1003的步骤所费的时间基本上可以被涵盖在执行方块1002的步骤所费的时间内。如前所述，这是因为对于大部分的标记而言，分类引擎104因应LZ77引擎102产生的标记而依据图3的步骤316维持分类列所需的时间，涵盖在LZ77引擎102依据图3的步骤302产生下一个标记所费的时间内。当LZ77引擎102完成对于字符输入区块的扫描，以及(在必要时)分类引擎104因应关联于最后标记212的符号完成对于分类列403的更新后，在方块1004的步骤中，霍夫曼编码表建构引擎106会使用分类列403来建构霍夫曼编码表。随后，在方块1006所示的步骤中，霍夫曼编码引擎108会对此字符输入区块进行利用由方块1004的步骤所建构的霍夫曼编码表进行编码－或者更精确地说，利用LZ77引擎102产生的反向指针与输入区块中不被取代的词汇进行的取代动作－并将压缩输出写入输出内存109。(霍夫曼编码表也会经霍夫曼编码后被写入输出内存，而让解压器可以重建此用于压缩的霍夫曼编码表。)。透过比较图9与图10可以发现，相较于传统的压缩方式，分类引擎104维持分类符号列与LZ77引擎102扫描输入区块的操作同时进行，可以减少总压缩时间。图11A为方块图，显示本发明另一实施例的分类列403。在图11A的实施例中，分类列403的各个项目并包含关联于符号值406的霍夫曼编码1108与位长度1112。如此，霍夫曼编码建构引擎106就可为此分类列403符号，指派霍夫曼编码1108、与相关联的位长度1112。就一实施例而言，霍夫曼编码表建构引擎106可依据典型的霍夫曼编码程序来指派霍夫曼编码1108。位长度1112表示霍夫曼编码1108的位数。图11A所示的分类列403可搭配图4的频率表401作为霍夫曼编码表。也就是说，对于给定符号值(例如DEFLATE型词汇/长度表的值0至285，或DEFLATE型距离表的值0至29)，此符号值会作为频率表401的索引，以确认此符号的分类索引404值，而此分类索引404值随后会做为图11A的分类列403的索引，以取得关联于此符号的霍夫曼编码1108。避免间接层(levelofindirection)以实现霍夫曼编码表的另一个实施例在后续图11B会进行说明。图11B为方块图，显示本发明另一实施例的频率表401。在图11B的实施例中，频率表401的各个项目并包含关联于符号的霍夫曼编码字段1108与位长度1112，而此符号的数值作为频率表401的索引。如此，霍夫曼编码表建构引擎106就可为此数值作为频率表401索引的符号，指派霍夫曼编码1108与相关联的位长度1112，因而可建构直接查找(directlookup)霍夫曼编码表作为频率表401的一部分(例如图10的方块1004所示)。图12为方块图，显示图1的硬件数据压缩器100的另一实施例。图12的硬件数据压缩器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的使用可参照后续图13的实施例。图13为时序图，以图形显示依据本发明另一实施例进行压缩所费时间的各个部分。图13的实施例类似于图10的实施例，不过在图13的实施例中，方块1004是由方块1304所取代。在方块1304的步骤中，霍夫曼编码表建构引擎的运作与LZ77压缩引擎102执行方块1002所示扫描输入区块的运作同时进行，并且与分类引擎104执行方块1003将霍夫曼编码1108指派给分类列403的符号值406以维持分类列403的运作同时进行。如此，方块1304的步骤中，利用分类列403建构霍夫曼编码表所需的时间，会大部分重叠并涵盖于方块1002的输入区块扫描时间与方块1003的分类列维持时间，因而可以进一步降低总压缩时间。就一实施例而言，图13的实施例会使用分类列变更旗标1202，以及选择性地使用图12的分类列非变更计数器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存取拥塞(accesscongestion)的问题。因为在方块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引擎)产生此标记串流的步骤同时进行，不过本发明并不限于此。在另一实施例中，分类引擎依据标记串流的出现频率维持分类符号列，而此操作与利用破坏性压缩(lossycompression)演算方式(如JPEG、MPEG、MP3)的压缩引擎产生此标记串流的步骤同时进行。此压缩引擎的输出会再利用分类符号列透过编码引擎进行编码(如霍夫曼编码)，以产生编码表。值得注意的是，利用传统方式对符号列进行分类(即非如本文所述以递增方式且与扫描输入区块的操作同步者)通常是属于记忆存取密集(memoryintensive)的操作。这对于软件数据压缩程序(如gzip)而言并不会构成问题，因为软件数据压缩程序通常可以使用大量的内存，如系统内存。不过基于成本与效能的考虑，硬件数据压缩器倾向于使用相对较小的内存，因为越大的内存就会产生越多的存取迟延。因此，在对输入区块进行扫描的过程中，以递增方式同步维持分类列，对于硬件数据压缩器特别有帮助。“动态－初期(Dynamic-Prime)”霍夫曼编码图14A为流程图，显示图1的LZ77引擎102配合动态初期霍夫曼编码执行数据压缩的处理程序。就一实施例而言，在图14A中，LZ77引擎102配合图14B的霍夫曼编码表建构引擎106与图14C的霍夫曼编码引擎108共同运作，而使这三个程序中有相当多的部分是同步运作的，以达成如图16所示对于字符输入区块进行硬件数据压缩的目的。此流程始于步骤1402。在步骤1402中，LZ77引擎102初始化输入区块内的当前搜寻目标位置。就一实施例而言，此硬件数据压缩器100包含缓存器(未图示)以储存搜寻目标位置的值。此当前搜寻目标位置为字符输入区块的索引。就一实施例而言，此搜寻目标位置为经初始化以指向输入区块的第二个字符。接下来流程前进至步骤1404。在步骤1404中，LZ77引擎102对于开头位于搜寻目标位置的字符串，在输入区块中搜寻字符串匹配。也就是说，LZ77引擎102从输入区块的搜寻目标位置开始取得字符字符串－即目标字符串－并在输入区块内搜寻出现在前并与之匹配的字符串。一般而言，LZ77引擎102会在输入区块搜寻它所能找到的最长匹配字符串。不过LZ77引擎102可能会限制所搜寻的字符串长度，以缩短搜寻时间和/或限制反向指针的最大长度。此外，LZ77引擎102可以限制其由当前搜寻位置回溯的搜寻范围，以缩短搜寻时间和/或限制反向指针的最大距离。LZ77引擎102可以利用各种不同的技术于输入区块内回溯搜寻当前扫描位置的字符串的匹配，如本文图24与图25所述使用双散列表(dualhashtable)的实施例。接下来前进至步骤1406。在步骤1406中，LZ77引擎102产生标记212。如前述，此标记212为反向指针或是来自输入区块的词汇。在一实施例中，从输入区块产生词汇，就只是将此词汇留在输入区块内存101，而使其于后续程序能由霍夫曼编码引擎108读取并使用动态初期霍夫曼编码表进行编码。在一实施例中，如前述，反向指针被写入反向指针内存105，而内存105内对应于输入区块中位于待取代或匹配目标字符串的开始处的字符位置的旗标会被设定，以表示存在一个要进行取代的反向指针。LZ77引擎102并会更新搜寻目标位置。就一实施例而言，若是LZ77引擎102产生反向指针，LZ77引擎102就会从搜寻目标位置增加此匹配字符串的长度；不过，若是LZ77引擎102产生词汇，LZ77引擎102就会以所产生的词汇数量来移动搜寻目标位置。在具有分类引擎104的实施例中，如图3的步骤316所示，分类列403也会被更新。接下来流程前进至决策步骤1408。在决策步骤1408中，LZ77引擎102会确认是否已完成对于输入区块的开始部分的扫描，以通知开始建构动态初期霍夫曼编码表。是否完成输入区块的开始部分可由多种不同方式来确认。在一实施例中，LZ77引擎102会在其完成扫描预设数量的输入字符(例如3,000个字符)后，认定其已完成此开始部分的扫描。在一实施例中，LZ77引擎102会在其完成扫描输入区块大小的预设比例(例如输入区块的字符的前十分之一)后，认定其已完成此开始部分的扫描。在一实施例中，当符号空间的符号总数大于第二默认值，而这些符号已被观察至少第一预设次数(例如一、二、三)，LZ77引擎102就会认定其已完成此开始部分的扫描。举例来说，假定第一预设次数为三，硬件数据压缩器100每次使频率402增加到数值三，它就会使初始化为零的计数器开始递增。而当此计数器达到第二默认值(如85)时，就完成开始部分的扫描。此第二默认值也可以是符号空间内符号数量的预设比例(如33％)。在一实施例中，如图18与图19所述，分类引擎104基于在分类列403中出现的变化来确认输入区块的开始部分。在一实施例中，此开始部分可由使用者定义，例如硬件数据压缩器100的压缩指令的操作数。值得注意的是，一般而言，如果要改善压缩效率，就须选用数值较大的开始部分，但需要牺牲压缩速度；如果要提升压缩速度，就须选用较小的开始部分，但需要牺牲压缩效率。若是LZ77引擎102已完成对于输入区块的开始部分的扫描程序，流程就会前进至步骤1412；否则，流程就会前进至步骤1414。在步骤1412中，LZ77引擎102通知霍夫曼编码表建构引擎106来建构霍夫曼编码表。也就是说，在输入区块的开始部分完成扫描的时候，才可以建构霍夫曼编码表(如图14B的步骤1424所示)，也才能开始霍夫曼编码程序(如图14C的步骤1434所示)。流程会回到步骤1404依据更新后的搜寻目标位置来搜寻匹配。需要理解的是，虽然图14A的流程似乎表示每次完成开始部分的扫描程序后就会依循步骤1404、1406与1408的途径通知建构霍夫曼编码表，不过此通知步骤只会执行一次。步骤1414会对关连于步骤1406所产生的标记212的各个符号，更新其频率402。在一实施例中，分类引擎104会递增各个符号的频率402。在另一实施例中，不具有分类引擎104，而是由LZ77引擎102递增各个符号的频率402。在又一实施例中，不具有分类引擎104，而是由LZ77引擎102产生标记212提供给霍夫曼编码表建构引擎106，再由霍夫曼编码表建构引擎106递增各个符号的频率402，前述提供步骤类似于图2A中由LZ77引擎102产生标记212提供给分类引擎104的步骤。流程接下来会回到步骤1404，依据更新后的搜寻目标位置来搜寻匹配。需要注意的是，流程在抵达输入区块尾端(例如接触到块字符的尾端)后随即终止，而不经由步骤1412、1414或1416再回到步骤1404，接下来则会对下一个输入区块重复图14A的运作。如前述，一旦完成对于输入区块的开始部分的扫描程序，就不再更新频率表401内的频率402。当硬件数据压缩器100扫描输入区块时，一旦完成输入区块的开始部分的扫描程序，硬件数据压缩器100就会停止更新频率表401。如此可以减少对于窗体内存107的存取次数，以降低能耗并缓和存取窗体内存107的冲突状况，使其它引擎可以更快速地存取窗体内存以提升效能，这个优点在窗体内存的存取端口由多个引擎共享的实施例中特别明显。此外，此技术有利于使用存取端口数量较少的内存，而能缩减设计尺寸。图14B为流程图，显示图1的霍夫曼编码表建构引擎106配合动态初期霍夫曼编码执行数据压缩的运作。流程始于步骤1422。在步骤1422中，霍夫曼编码表建构引擎106接收信号，通知建构霍夫曼编码表。在一实施例中由LZ77引擎102通知霍夫曼编码表建构引擎106建构霍夫曼编码表。在一实施例中由分类引擎104通知霍夫曼编码表建构引擎106建构霍夫曼编码表。接下来流程前进至步骤1424。在步骤1424中，霍夫曼编码表建构引擎106利用只有输入区块的开始部分扫描后，也就是霍夫曼编码表建构引擎106在步骤1422收到通知的时点，产生的频率表401与其频率402值，建构动态初期霍夫曼编码表。图17A至图17C显示建构动态初期霍夫曼编码表的实施例。流程前进至步骤1426。在步骤1426中，霍夫曼编码表建构引擎106通知霍夫曼编码引擎108开始对输入区块进行霍夫曼编码程序。此流程终止于步骤1426。图14C为流程图，显示图1的霍夫曼编码引擎108配合动态初期霍夫曼编码执行数据压缩的运作。流程始于步骤1432。在步骤1432，霍夫曼编码引擎108接收图14B的步骤1426所产生的信号，开始对输入区块进行霍夫曼编码。接下来前进至步骤1434。在步骤1434，霍夫曼编码引擎108利用步骤1424所建构的霍夫曼编码表对整个输入区块进行编码。也就是说，霍夫曼编码引擎108利用步骤1424中只有输入区块的开始部分被扫描时所建构的霍夫曼编码表，对反向指针与整个输入区块中未被取代的词汇执行霍夫曼编码，并将霍夫曼编码输出(连同霍夫曼编码表的霍夫曼编码版本)储存至输出内存109。流程终止于步骤1434。图15为时序图，以图形显示传统上对DEFLATE型输入区块进行压缩所费时间的各个部分。如方块1502的步骤所示，在压缩开始时扫描整个输入区块并产生LZ77标记串流，同时维持直方图显示符号出现频率。一旦完成方块1502的步骤，如方块1504所示，就会利用由整个输入区块取得的符号频率来建构霍夫曼编码表。完成方块1504的步骤后，如方块1506所示，就会利用霍夫曼编码表来对输入区块进行霍夫曼编码程序，也就是对LZ77标记输出串流进行霍夫曼编码程序。前述关联于方块1502、1504与1506的操作依其顺序连续地执行。因此，总压缩时间就会是关联于方块1502、1504与1506所费时间的总和。图16为时序图，以图形显示依据本发明的动态初期霍夫曼编码表对DEFLATE型输入区块进行压缩所费时间的各个部分。如方块1602-A的步骤所示，在压缩开始时，LZ77引擎102扫描输入区块内存101内的字符输入区块的开始部分并产生标记212串流，如本文重复图14A的步骤所产生的标记212(以及图3的步骤302至308)。在完成对于输入区块的开始部分的扫描程序后，就会收到建构霍夫曼编码表的信号(如依据图14A的方块1412所执行的步骤)，然后如方块1604所示，霍夫曼编码表建构引擎106就利用方块1602-A的步骤，对输入区块的开始部分进行扫描的过程中所维持的频率表401的频率402来建构霍夫曼编码表(如依据图14B的方块1424所执行的步骤)。此外，如方块1602-B所示，LZ77引擎会持续扫描输入区块内存101内字符输入区块的剩余部分，以产生标记212串流。一旦霍夫曼编码表建构引擎106利用方块1604所示的开始部分频率建构出动态初期霍夫曼编码表，如方块1606所示，霍夫曼编码引擎108就会利用此动态初期霍夫曼编码表对整个输入区块进行霍夫曼编码程序(或更精确来说，由LZ77引擎102产生的反向指针与输入区块中未被取代的词汇所进行的取代动作)，并将压缩输出写入输出内存109。基本上，因为动态初期霍夫曼编码表利用对于输入区块的开始部分进行扫描所取得的符号出现频率来建构，而非如传统方式是对于整个输入区块进行扫描，因此，方块1604与1606的运作时间可以涵盖于方块1602-B的运作时间内。透过比较图15与图16可以发现，相较于传统方式，使用本发明的动态初期霍夫曼编码表－即由扫描输入区块开始部分取得的出现频率来建构的霍夫曼编码表－可以缩短总压缩时间。图17A为流程图，显示硬件数据压缩器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建构典型的霍夫曼编码表。此流程终止于此。图17B为流程图，显示硬件数据压缩器100建构动态初期霍夫曼编码表的运作的一实施例。此流程始于步骤1712。在步骤1712中，频率表401的频率被初始化为零，或其它非零数值。将各个频率402都初始化为非零数值的结果为，霍夫曼编码表建构引擎106将会对动态初期霍夫曼编码表(例如由步骤1718建构霍夫曼编码表)的符号空间的各个符号都指派霍夫曼编码。接下来流程前进至步骤1714。在步骤1714中，LZ77引擎102扫描输入区块的开始部分，并如同前述步骤1704所述，递增关联于所产生标记的符号的频率402。接下来前进至步骤1718。在步骤1718中，霍夫曼编码表建构引擎106利用步骤1712至1714所产生的频率表401的频率402来建构霍夫曼编码表。重要的是，所建构的动态初期霍夫曼编码表会包含符号空间的各个符号的霍夫曼编码值，因为步骤1712的初始化过程已确保各个符号都具有非零频率402值。此流程终止于此。图17C为流程图，显示硬件数据压缩器100建构动态初期霍夫曼编码表的运作的一实施例。此流程始于步骤1722。在步骤1722中，频率表401的频率402被初始化为一组非零数值，此组非零数值从关联于符号空间的符号的一组预编译非零数值中予以选定。也就是说，不同于图17B所执行的步骤1712对各个符号的频率402都指派相同的非零数值，在步骤1722中，依据先前已知(即对输入区块进行压缩前)符号空间的符号的相对频率的发生概率，将符号频率初始化至修正过的数值。举例来说，众所皆知，长度较短的反向指针长度通常会有较高的出现频率。因此，这组预编译非零频率可包含相对较大的非零频率值提供给符号空间内长度较短的反向指针长度。在另一个例子中，假定此输入区块为ASCII字符文字。众所皆知，在输入区块中ASCII“E”出现频率高于ASCII“Z”的可能性很高。因此，这组预编译非零频率可以对ASCII“E”提供较大的非零频率值。如此，这些初始非零数值基于教育过的猜测来调整频率402，而非对各个符号都初始化为相同的非零数值。此处理方法的优点在于，如前述图2A至图8使用分类引擎104的实施例提及，提升频率表401的频率402的初始值的不均匀程度可以减少需要的分类程序，也就是减少如图5的步骤514与522所示在分类列403中交换符号位置的次数。在一实施例中提供硬件数据压缩器100多个预编译非零数值组，硬件数据压缩器100依据准则来选择其中一个预编译组，例如依照输入区块的来源文件类型(如影像文件、音乐文件、文字文件、电子窗体、由文字处理器或简报应用程序，或其它类型的文件)。接下来前进至步骤1724。在步骤1724中，LZ77引擎102扫描输入区块的开始部分，并如同前述步骤1704所述，递增关联于所产生的标记的符号的频率402。接下来前进至步骤1728。在步骤1728中，霍夫曼编码表建构引擎106利用步骤1722至1724产生的频率表401频率来建构霍夫曼编码表。重要的是，所建构的动态初期霍夫曼编码表会包含符号空间的各个符号的霍夫曼编码值，因为步骤1722的初始化过程已确保各个符号都具有非零频率402值。此流程终止于此。图18为方块图，显示图1的硬件数据压缩器100的硬件的一实施例。图18的硬件数据压缩器100包含分类列变更计数器(sortedlistchangecounter，SLCC)1804、临界值1806、符号倒数计数器(symbolcountdowncounter，SCDC)1808、与连接至前述各组件的逻辑1802。临界值1806可以是可程序化缓存器。分类列变更计数器1804显示前一次重置分类列变更计数器1804后，分类列403变更(如步骤514或522所示)的次数的计算值。符号倒数计数器1808先载入默认值，而在每次符号频率402增加时(如步骤1414所示)进行递减。当符号倒数计数器1808倒数至零的时候，若是分类列变更计数器1804的数值小于临界1806值，逻辑1802就会通知建构霍夫曼编码表，否则就会再次将默认值载入符号倒数计数器1808，这部分在图19会有更详细的说明。就一实施例而言，图18的硬件包含于分类引擎104内，而非包含于LZ77引擎102内(如图14A的步骤1412所示)，分类引擎104会通知霍夫曼编码表建构引擎106建构霍夫曼编码表(如图19的步骤1916所示)。在一实施例中，计数器1808在每次标记产生时就进行递减，而非在每次符号频率402增加时。在一实施例中，计数器1808在每个时钟周期都进行递减，而非在每次符号频率402增加时。图19为流程图，显示分类引擎104通知建构霍夫曼编码表的处理程序。此流程始于步骤1902。在步骤1902中，分类引擎104使图18的分类列变更计数器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％)，才会通知建构霍夫曼编码表。流程终止于此。图20为时序图，以图形显示本发明对DEFLATE型输入区块进行压缩所费时间的各个部分的另一实施例。如同前文关于图14A至图19的说明，在完成输入区块的开始部分的扫描步骤后就开始进行霍夫曼编码程序可以减少总压缩时间。图20的实施例中不使用透过扫描输入区块开始部分维持的频率来建构的动态初期霍夫曼编码表，而是让硬件数据压缩器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的运作时间内，因而可以减少总压缩时间。相较于图14A至图19的实施例，图20的实施例可以减轻霍夫曼编码表建构引擎106的负担。不过，图14A至图19的实施例的动态初期霍夫曼编码表，除了能与图20的实施例有相同优异的压缩速度外，还具有额外的优点。对于某些输入区块，在图20的实施例未具有理想的预编译霍夫曼编码表供硬件数据压缩器100选择的情况下，图14A至图19的实施例可以产生较小的输出。举例来说，假定输入区块的字符来自较区域性的语言，因而不存在预编译霍夫曼编码表，例如匈牙利(Hungaria)万国码。在此情况下，相较于图20使用霍夫曼编码表预编译对的实施例，图14A至图19使用动态初期霍夫曼编码的实施例较可能产生较小的输出。预先霍夫曼编码程序对匹配字符串或反向指针进行选择性霍夫曼编码图21为方块图，显示图1的硬件数据压缩器100的一部分。图1的LZ77引擎102与图1的窗体内存107保持联系。窗体内存107储存有“参考”霍夫曼编码表2102。此参考霍夫曼编码表2102供LZ77引擎用以对标记进行预先霍夫曼编码程序以确认其尺寸，并确定是产生匹配字符串的常值或是产生指向匹配字符串的反向指针，这部分在图22与图23会有更详细的说明。此参考霍夫曼编码表2102可以相同或不同于霍夫曼编码引擎108在后续霍夫曼编码程序中对LZ77引擎102的输出字符串进行编码的霍夫曼编码表。此LZ77引擎102包含逻辑以确认使用参考霍夫曼编码表2102的两个尺寸。第一个尺寸标示为尺寸X，其使用参考霍夫曼编码表2102对匹配字符串的词汇符号，进行霍夫曼编码所输出的霍夫曼编码的总位数。也就是说，LZ77引擎会使用参考霍夫曼编码表2102，确认各个词汇符号的霍夫曼编码的位数，并将其相加产生总数，此总数即为尺寸X。就一实施例而言，LZ77引擎102的逻辑会在参考词汇霍夫曼编码表2012平行查找各个词汇符号，以确认各个词汇符号的霍夫曼编码位数(如图11B的位长度1112)并将其加总以产生尺寸X。在一实施例中，逻辑是用以确认不超过预设字符数(例如五)的字符串的尺寸X，如此，若是字符串长度大于此预设字符数，在后续步骤2206中就会假定尺寸X大于尺寸Y。第二个尺寸标示为尺寸Y，是使用参考霍夫曼编码表2102指向匹配字符串(假定存在一个匹配字符串)的反向指针，进行霍夫曼编码所输出的霍夫曼编码的总位数。也就是说，LZ77引擎会使用参考霍夫曼编码表2102，确认此指针的各个长度与距离的霍夫曼编码的位数(如图11B的位长度1112)，包含这些额外位，并将其相加产生总数，此总数即为尺寸Y。就一实施例而言，LZ77引擎102的逻辑会在参考长度与距离霍夫曼编码表2012平行查找各个长度与距离符号，以确认各个长度与距离符号的霍夫曼编码位数并将其加总以产生尺寸Y。图22为流程图，显示硬件数据压缩器100压缩数据的处理程序。此流程始于步骤2202。在步骤2202中，LZ77引擎搜寻并找到位于当前搜寻目标位置的字符串的匹配，并采用与前文描述的方式(如步骤302或步骤1404所采用的方式)相类似的方式，计算从当前搜寻目标位置指向匹配字符串的反向指针。接下来流程前进至步骤2204。在步骤2204中，LZ77引擎102确认图21所述的尺寸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)的霍夫曼编码表，可以是在扫描输入区块的开始部分后所建构(如图16)或选择(如图20)的霍夫曼编码表，如此，在扫描输入区块开始部分的过程中，就需要使用参考霍夫曼编码表2102来计算尺寸X与尺寸Y。也就是说，在依据图22的步骤2202至2212所执行的最佳化步骤时，就需要取得参考霍夫曼编码表2102。即使用于计算尺寸X与尺寸Y的霍夫曼编码表不同于最终用于对输入区块进行编码的霍夫曼编码表，图22的处理程序仍然有助于提升压缩率，也就是可以缩减未使用图22处理程序的传统方法的输出大小。此流程终止于此。就一实施例而言，此流程必须对LZ77引擎102产生的各个标记212执行图22的预先霍夫曼编码处理，以供扫描整个字符输入区块。不过，如以下所述，在某些实施例中，需执行预先霍夫曼编码程序的标记212只用于扫描部分输入区块，举例来说，就使用动态初期霍夫曼编码表的实施例中，即为完成输入区块开始部分的扫描程序后的剩余部分。现在请参照图23A，此图为流程图，显示图22的步骤2204的一实施例。此流程始于步骤2302。在步骤2302中，LZ77引擎102利用预编译霍夫曼编码表确认尺寸X与尺寸Y。此预编译霍夫曼编码表于硬件数据处理器100开始对字符输入区块进行压缩前进行编译。举例来说，此预编译霍夫曼编码表可以是DEFLATE规范定义的固定霍夫曼编码表，此规范的词汇/长度表大致呈现于表3(变更部分以括号表示)。DEFLATE规范定义的固定霍夫曼编码表的距离码031以(固定长度)5位码表示，可能出现的额外位如前文表二所示。另外，此预先编译霍夫曼编码表可以是基于具代表性的输入区块的符号频率建构的霍夫曼编码表或是多个具代表性的输入区块的取样来进行建构。在一实施例中，此预先编译霍夫曼编码表对于符号空间的每一个符号都包含有一个霍夫曼编码。在另一实施例中，对于符号空间中的某些符号，LZ77引擎102不需为其计算尺寸X与尺寸Y，不需执行决策步骤2206的比较，以及执行步骤2208以产生反向指针，霍夫曼编码表可将其霍夫曼编码排除在外。常值[或长度]值位数[霍夫曼]编码0-143800110000至110111111144-2559110010000至111111111256-279700000000至0010111280-287811000000至11000111表3现在请参照图23B，此图为流程图，显示图22的步骤2204的另一实施例。此流程开始并终止于步骤2312。在步骤2312中，LZ77引擎利用如图14A至图20的实施例所建构的动态初期霍夫曼编码表确认尺寸X与尺寸Y。在本发明一实施例中，图22的处理程序需要在建构动态初期霍夫曼编码表之后(如图16的步骤1604所示)才会对标记执行，并且早于步骤2208所述LZ77压缩引擎102产生反向指针的时点，而非计算尺寸X与尺寸Y并基于尺寸X与尺寸Y的关系选择性地产生反向指针的时点。在另一实施例中，在建构动态初期霍夫曼编码表之前利用参考霍夫曼编码表2102来执行步骤2204，而在建构动态初期霍夫曼编码表之后则是利用动态初期霍夫曼编码表以执行步骤2204。使用预先霍夫曼编码程序的优点如下。某些传统方式的LZ77压缩算法甚至不会考虑去搜寻三字节字符串的匹配并以反向指针取代；不过，本文所述的部分实施例则会对此三字节匹配字符串产生反向指针(如步骤2208)，因而可以达到更高的压缩率。此外，在LZ77引擎102在扫描输入区块的下一个匹配的过程中同时执行步骤2204的预先霍夫曼编码程序与步骤2206的决策步骤的情况下，也不会牺牲压缩速度。基于不同散列尺寸在散列表中搜寻多字符串匹配执行LZ77型压缩程序时，在输入区块内反向搜寻目标字符串的匹配会消耗大量时间。一种显而易见的方式是从输入区块的开头开始搜寻，顺着整个输入区块逐个字符移动(直到当前搜寻点)并标注最常匹配字符串的位置。不过，这种处理方式非常缓慢。一个较快的处理方式是使用散列表。在扫描输入区块的过程中会建构散列表，散列表可用以缩减输入区块内需搜寻的位置数量。也就是说，散列表可以将搜寻目标锁定在输入区块中较可能产生匹配的位置，也即较可能储存至少一定搜寻目标字符数量(如三个)的位置。因为在扫描输入区块的过程中就会确认当前搜寻目标位置前方的字符，因此散列表可依据扫描输入区块的过程获得的信息来建构。举例来说，位于当前搜寻目标位置的三个字符，依据散列逻辑打散后以产生散列表项目的索引，此项目为指针散列链的头部，而这些指针对应于输入区块内曾被打散至相同索引的位置，如此即可确保搜寻目标位置的三个字符有很高的可能性(可能性的高低会受到散列逻辑、散列表大小与输入区块字符的特性影响)也会出现在指针指向的位置。这部分在DEFLATE规范段落4有相关说明。基本上，对于至少某些输入文件(如LewisCarroll所著的艾丽斯梦游仙境的文字)而言，使用四字符散列所产生的输出文件大小会大于使用三字符散列所产生的输出文件，不过产生文件所费的时间也比较短，其它部分则相同。会产生较大的输出文件，是因为此压缩方式会丧失某些三字符匹配，而损失较多将输入区块的词汇以反向指针取代的机会。压缩速度的提升同时涉及多个因素，其中至少包含一个因素，就是预期会产生较短的散列链搜寻。假定三字符字符串“she”在输入区块的扫描过程中一共出现37次。这37次出现都会被插入三字符散列表中相同的散列链内。假定这37次出现的“she”字符串中，某些情况在“she”字符串后还接上其它字符，举例来说，假定“shea”出现21次，“shel”出现12次，而“shed”出现4次。假定四字符散列算法将这三个不同的四字符字符串插入四字符散列表中三个不同的散列链。也即表示在四字符散列表中依据开头为“she”的字符串搜寻匹配的散列链，其长度很有可能会短于在三字符散列表中需要搜寻的散列链的长度，其它部分则相同，例如忽略非“she”的字符串散列在三字符散列表中散列至与“she”字符串相同散列链的冲突情况，以及非“she”的三字符接上其它字符所构成的字符串在四字符散列表中散列至与“she”接上“a”、“l”与“d”字符的三个相同散列链的冲突情况。为了兼顾四字符散列的速度与三字符散列的输出大小的优点，本发明提出下列实施例。此硬件数据压缩器100具有两个散列表，其中一个是基于三字符散列，另一个则是基于四字符散列。四字符散列表会首先用于搜寻最少为四字符的匹配，三字符散列表只有在利用四字符散列表没有找到四字符匹配的情况下，才用于搜寻至少为三字符的匹配。对于某些输入区块而言，四字符散列表会具有较短的散列链，一般而言也会有较快的搜寻速度。不过，在必要时，此实施例也会使用三字符散列表而能达到三字符散列表的压缩率。值得注意的是，一般而言，因为任何使用四字符散列表找到的匹配至少会跟三字符散列表找到的匹配具有相同长度，因此，若是使用四字符散列表找到匹配，就不需要使用三字符散列表来进行搜寻动作。前述使用三字符与四字符散列表的目的是要达到比仅使用三字符散列更快的压缩速度，以及比仅使用四字符散列更小的压缩大小。以下举例说明，假定对于输入区块，90％的时间用于搜寻四字符或更大的匹配，而只有10％的时间用于搜寻三字符匹配。在此情况下，因为压缩率可以从前述10％的三字符匹配获得帮助，因此压缩器的压缩输出通常会小于仅使用四字符散列的实施例。此外，就统计上来看，四字符散列链的长度较短而能达到较快的搜寻速度，因此进行搜寻所产生输出的速度也会比仅使用三字符散列的实施例来的快。请参照图24，此图为方块图，显示图1的LZ77引擎102的一部分。此LZ77引擎包含四字符散列表2448。此四字符散列表2448为一个利用由四字符散列表产生器2442产生的四字符散列表索引2444作为其索引的项目数组，此四字符散列表产生器2442利用四字符散列算法，依据位于当前搜寻位置2402的字符对输入区块内的四字符单位进行散列处理，以产生此四字符散列表索引。下表5显示此四字符散列算法的一实施例，不过本发明并不限于此。表5的算法仅为例示，而非限定本发明的范围。在一实施例中，如后续图39至图41所示，散列算法与输入区块的类型有关。需要理解的是，四字符散列表索引2444为四字符散列表2448的索引，而非四字符值。此索引2444的大小会受到散列表2448尺寸影响。此四字符散列表2448的项目即为由节点2406构成的散列链2441的头部。就一实施例而言，各个散列链2441为一列节点2406的连结，不过也不限于此，此散列链也可为数组、树状分布等等。各个节点包含一个指向散列链2441的下一个节点的指针，各个节点并包含指针，指向输入区块内的当前搜寻位置2402后方的四字符字符串的位置。此四字符字符串为于先前步骤经散列处理产生四字符散列表2448的项目索引2444值，而此四字符散列表2448的散列链2441包含节点2406。在这些节点2406中填入数值的程序会在后续图25有更详细的说明。如图24所示，各个散列链2441的长度会随着输入区块2404的扫描过程而改变，而某些散列链可能会被清空。在一实施例中，四字符散列表2448的项目数为16,384，不过本发明并不限于此。LZ77引擎102并包含一个三字符散列表2438。此三字符散列表2438为一个利用由三字符散列表产生器2432产生的三字符散列表索引2434作为其索引的项目数组，此三字符散列表产生器2432利用三字符散列算法，依据位于当前搜寻位置2402的字符对输入区块内的三字符单位进行散列处理，以产生此三字符散列表索引。下表4显示此三字符散列算法的一实施例，不过本发明并不限于此，表4的算法仅为例示，而非限定本发明的范围。在一实施例中，如后续图39至图41所示，散列算法与输入区块的类型有关。需要理解的是，三字符散列表索引2434为三字符散列表2438的索引，而非三字符值。此索引2434的大小会受到散列表2438尺寸影响。此三字符散列表2438的项目即为由节点2406构成的散列链2431的头部。就一实施例而言，各个散列链2431为一列节点2406的连结，不过也不限于此，此散列链也可为数组、树状分布等等。各个节点包含一个指向散列链2431的下一个节点的指针。各个节点并包含指针，指向输入区块2404内的当前搜寻位置2402后方的三字符字符串的位置。此三字符字符串为于先前步骤经散列处理产生三字符散列表2438的项目索引2434值，而此三字符散列表2438的散列链2431包含节点2406，在这些节点2406中填入数值的程序会在后续图25有更详细的说明。如图24所示，各个散列链2431的长度会随着输入区块2404的扫描过程而改变，而某些散列链可能会被清空。在一实施例中，四字符散列表2438的项目数为16,384，不过本发明并不限于此。在一实施例中，四字符散列表2448与三字符散列表2438储存于图1的散列内存103。在另一实施例中，硬件数据压缩器100包含不同的内存，用于储存四字符散列表2448与三字符散列表2438。在一实施例中，散列链2441/2431的节点2407与散列表2438/2448储存于不同的内存。以下所示的表4与表5分别为三字节与四字节散列算法的范例。full3＝{byte0,byte1,byte2当前第1页1 2 3 当前第1页1 2 3