CN105959013A - 利用预先霍夫曼编码决定对匹配字符串或反向指针执行霍夫曼编码程序的硬件数据压缩器 - Google Patents

Abstract

一种硬件数据压缩器，包括第一硬件引擎与第二硬件引擎。第一硬件引擎为：寻找字符区块中位于当前位置的字符字符串的匹配，此匹配早于字符字符串出现于字符区块；确认第一尺寸，此第一尺寸为利用霍夫曼编码表对匹配字符串执行霍夫曼编码程序所产生的总位数；计算反向指针，此反向指针从当前位置指向早先出现的字符串；以及确认第二尺寸，此第二尺寸利用霍夫曼编码表对反向指针执行霍夫曼编码程序所产生的位数。当第一尺寸小于第二尺寸时，第二硬件引擎对匹配字符串执行霍夫曼编码程序，否则就对反向指针执行霍夫曼编码程序。

Description

利用预先霍夫曼编码决定对匹配字符串或反向指针执行霍夫曼编码程序的硬件 数据压缩器

技术领域

本申请案主张申请日为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(DEFLATE compresseddata format specification version 1.3)所定义的无损(lossless)压缩数据格式，输入文件的各个块同时使用LZ型算法(例如LZ77)与霍夫曼(Huffman)编码进行压缩演算。此技术可参照Ziv J.,Lempel A.,“A Universal Algorithm forSequential Data Compression,”IEEE Transactions on Information Theory,Vol.23,No.3,pp.337-343；以及Huffman,D.A.,“A Method for the Construction ofMinimum 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压缩程序中扫描输入区块所花费的时间，依据建构霍夫曼编码表的时间点，在某些情况下，霍夫曼编码步骤在输入区块压缩流程外几乎不会额外花费任何时间。

此外，如图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可使用文献Ziv J.,Lempel A.,“AUniversal Algorithm for Sequential Data Compression,”IEEE Transactions onInformation 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内的频率表(例如图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也相同。

编码	额外位	长度
			257	0	3
258	0	4
			259	0	5
260	0	6
			261	0	7
262	0	8
			263	0	9
264	0	10
			265	1	11，12
266	1	13，14
			267	1	15，16
268	1	17，18
			269	2	19-22
270	2	23-26
			271	2	27-30
272	2	31-34
			273	3	35-42
274	3	43-50
			275	3	51-58
276	3	58-66
			277	4	67-82
278	4	83-98
			279	4	99-114
280	4	115-130
			281	5	131-162
282	5	163-194
			283	5	195-226
284	5	227-257

表1

编码	额外位	距离
			0	0	1
1	0	2
			2	0	3
3	0	4
			4	1	5，6
5	1	7，8
			6	2	9-12
7	2	13-16
			8	3	17-24
9	3	25-43
			10	4	33-48
11	4	49-64
			12	5	65-96
13	5	97-128
			14	6	129-192
15	6	193-256
			16	7	257-384
17	7	385-512
			18	8	513-768
19	8	769-1024
			20	9	1025-1536
21	9	1537-2048
			22	10	2049-3072
23	10	3073-4096
			24	11	4097-6144
25	11	6145-8192
			26	12	8193-12288
27	12	12290-16384
			28	13	16385-24576
29	13	24577-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中的正确位置，而会产生病态案例(pathological case)。此外，此符号递增频率可能等于位于其上方但具有较后的语汇值(lexical value)的多个符号，因此分类引擎104在符号频率递增的过程中就需要执行多个交换动作以确认符号在分类列403中的正确位置。若是分类引擎104繁忙而无法由LZ77引擎102接收标记212，对输入区块执行压缩所需要的时间就会增加。

一般而言，病态案例较可能发生于符号频率的分布相当均匀的情形，此情形特别容易发生于扫描输入内存的初期，因为在开始的时候所有的频率值都是零。值得注意的是，在本文图14A至图14C与图16所述的实施例中，其频率值初始化为不同数值，因而可以降低产生病态案例的可能性。

在一实施例中，硬件数据压缩器100在LZ77压缩引擎102与分类引擎104间包含短的先进先出内存，在必要时暂时储存由LZ77压缩引擎102提供给分类引擎104的标记212，以减少或在部分情况下消除此病态案例对于压缩程序的冲击。此先进先出内存的满溢旗标(full flag)输出信号可作为提供给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，“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中再次向上移动。

图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。避免间接层(level of indirection)以实现霍夫曼编码表的另一个实施例在后续图11B会进行说明。

图11B为方块图，显示本发明另一实施例的频率表401。在图11B的实施例中，频率表401的各个项目并包含关联于符号的霍夫曼编码字段1108与位长度1112，而此符号的数值作为频率表401的索引。如此，霍夫曼编码表建构引擎106就可为此数值作为频率表401索引的符号，指派霍夫曼编码1108与相关联的位长度1112，因而可建构直接查找(direct lookup)霍夫曼编码表作为频率表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引擎)产生此标记串流的步骤同时进行，不过本发明并不限于此。在另一实施例中，分类引擎依据标记串流的出现频率维持分类符号列，而此操作与利用破坏性压缩(lossy compression)演算方式(如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所述使用双散列表(dual hash table)的实施例。接下来前进至步骤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包含分类列变更计数器(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，这部分在图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-143	8	00110000至10111111
144-255	9	110010000至111111111
			256-279	7	0000000至0010111
280-287	8	11000000至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有相关说明。

基本上，对于至少某些输入文件(如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％的三字符匹配获得帮助，因此压缩器的压缩输出通常会小于仅使用四字符散列的实施例。此外，就统计上来看，四字符散列链的长度较短而能达到较快的搜寻速度，因此进行搜寻所产生输出的速度也会比仅使用三字符散列的实施例来的快。

请参照图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}；//Concatenate input bytes together mult3＝full3*8'hae；//Multiply by hexadecimal 0xAE hash_value3＝14'(mult3^(mult3>>12))；//Logical right shift by 12,then XOR with original,finally use only first 14bits ofresult.

表4

full4＝{byte0,byte1,byte2,byte3}；mult4＝full4*8'hae；hash_value4＝14'(mult4^(mult4>>14)^(mult4>>28))；

表5

现在请参照图25，本图为流程图，显示图24的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，而有助于缩减反向指针的距离值。不过，本发明并不限于此。在本文图26至图35所示的另一个实施例中，这些节点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，而有助于缩减反向指针的距离值。不过，本发明并不限于此。在本文图26至图35所示的另一个实施例中，这些节点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”的节点，因为这些节点的排序超过搜寻中止标准。

图26为方块图，显示本发明硬件数据压缩器100的一实施例。此硬件数据压缩器100包含图1中的输入区块内存100，LZ77引擎与散列内存103。由字符2606构成的输入区块储存于输入区块内存101内。散列链2611(与图中未示，指向散列链2611的散列表)储存于散列内存103，此散列链2611如前所述。不过，图26的散列链2611包含以机率2703来提升的节点2706(在后续图27会进行描述)。LZ77引擎102依据各节点的机率2703，并于相同机率时依据其年龄，来排列散列链2611的节点2706，而非严格依据其年龄排列，以提升找到较长的匹配字符串的可能性。这在后续章节会有更详细的说明。

LZ77引擎102包含互相连接的扫描引擎2602与链分类引擎2604，并且这两个引擎都连接至输入区块内存101与散列内存103。在一实施例中，链分类引擎2604会检视扫描引擎2602与散列内存103的连接，以侦测扫描引擎2602存取的散列链2611(如散列链索引)，并依此将扫描引擎2602更新过的散列链2611分类。这在后续章节会有更详细的说明。

现在请参照图27，此图为方块图，显示图26的散列链2611的节点2706。节点2706包含输入区块指针2702、机率值2703、年龄值2704与后续指针2705。此后续指针2705指向散列链2611的下一个节点2706。输入区块指针2702指向图26的字符输入区块2606中，一个连同其周边字符(如三字符字符串)一并被进行散列处理以产生散列表索引的字符，如图28的步骤2802所述。年龄值2704表示此节点2706相较于散列表中的其它节点2706的产生时点。在一实施例中，利用计数器来维持后续年龄值。当LZ77引擎102开始对输入区块进行扫描时，此计数器初始化为零，而后每当产生新节点2706，就增加计数器的计数。在此情况下，年龄值2704就会是类似于一系列的数字。机率值2703为相对指针，表示反向指针指向匹配字符串的可能性，而此匹配字符串以LZ77引擎102将会产生的输入区块指针2702所指向的字符为开头。链分类引擎2604利用机率值2703来对散列链2611的节点2706进行排序，而提升找到较佳匹配字符串的可能性。以下描述有动态机率与静态机率的实施例。此外，值得注意的是，静态机率的实施例可用于提供节点2706的机率2703的初始值，此数值于后续过程中可依据动态机率的实施例进行更新。

现在请参照图28，此图为流程图，显示硬件数据压缩器100利用动态节点机率的实施方式，执行图26所示于散列表中插入新节点显示的运作。此流程始于步骤2802。

在步骤2802中，扫描引擎2602对位于当前扫描目标位置的三个字符进行散列处理以产生散列表索引。本发明也可应用于其它不同字符数量的实施例，如前文图24与图25所述。接下来流程前进至步骤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中适当的位置。流程终止于此。

现在请参照图29，此图为时序图，显示图26的硬件数据压缩器依据图28的流程执行的运作。在图29中，时间进程往下为递增，而节点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插入(如图28步骤2806)年龄2704值为1与年龄值2704为4的二个节点间，这是因为年龄2704值为4的节点2706是节点链2611的机率值2703为零的节点中，最早的节点2706。

现在请参照图30，此图为流程图，显示图26的硬件数据压缩器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年轻或是新。此流程终止于此。

现在请参照图31，此图为时序图，例示硬件数据压缩器100依据图26至图30的运作。在图31中，时间进程往下递增，而节点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)找到的字符串匹配产生反向指针，如图30的步骤3002所示。依此，在第一时点后的第二时点，如第二列所示，扫描引擎2602会将节点2的机率2703值由1增加为2。因应于此，如图中第二列所示，因为此时节点2的机率2703值(2)与节点1相同，但节点2比较新，链分类引擎2604就会将散列链2611中节点2与其前方节点，即节点1(也就是年龄2704值为1的节点2706)的位置互换，如图30步骤3006所示。

随后，扫描引擎2602再次依据使用节点2的输入反向指针2702找到的字符串匹配产生反向指针。依此，在第二时点后的第三时点，如第三列所示，扫描引擎2602会将节点2的机率2703值由2增加为3。因应于此，如图中第三列所示，因为此时节点2的机率2703值(3)与节点0相同，但节点2比较新，链分类引擎2604就会将散列链2611中节点2与其前方节点，即节点0(也就是年龄2704值为0的节点2706)的位置互换。

现在请参照图32与图33，图32为流程图，显示产生图33所示的查找表3302的方法，此查找表用于静态散列链节点机率的实施例。就一实施例而言，图32所述的方法采自动化执行，如软件。就一实施例而言，使用者(如硬件数据压缩器100的生产者或终端用户)会在利用硬件数据压缩器100压缩字符输入区块前执行此方法。举例来说，可由生产者执行此方法并将其连同硬件数据压缩器100提供给终端用户。在另一实施例中，生产者可先产生查找表3302，随后终端用户再从生产者下载查找表3302。在另一实施例中，终端用户可以依据其使用硬件数据压缩器100经常压缩的文件自己客制化产生客户端查找表。此时，生产者通常会提供终端用户所需的软件。在一实施例中，此查找表3302储存于窗体内存107，不过本发明并不限于此。此查找表3302也可储存于其它内存，如内存101、内存103或内存105。在一实施例中，此查找表3302储存于内容可寻址内存(content-addressable memory，CAM)，其中，相较于输入地址，图33的四字符字符串3303为内容，而此内容可寻址内存输出对应于此匹配字符串3303的分数3304。若是没有找到匹配，此内容可寻址内存会在未命中指针上产生真值。此流程始于步骤3202。

在步骤3202中，使用者(例如生产者或终端用户，如服务器农场管理者)搜集一组字符输入区块作为后续由硬件数据压缩器100执行压缩的输入区块的的代表。举例来说，以英文字为例，使用者可以从数百个英文作品中搜集一组输入区块。在另一个例子中，使用者可以从许多HTML文件、音频文件或影像文件中搜集一组输入区块。随后，使用者会从这一组输入区块中编译出一列数据，包含J个最常出现的四字符字符串以及其出现频率。J是一个相当大的整数，例如介于500至5000之间，根据可配置给查找表3302的内存容量，以及利用节点2706机率2703对散列链2611进行分类后对匹配字符串搜寻效率的提升幅度而定。接下来流程前进至步骤3204。

在步骤3204中，使用者利用LZ77引擎102所使用的散列算法(如图24的三字符散列索引产生器2432使用的散列算法)，对步骤3202所编译的J个四字符字符串窗体内的每一个四字符字符串的前三个字符进行散列处理，以对字符串产生索引。因此，此索引与后续步骤中LZ77引擎102产生作为散列内存103内的散列表的索引(如图24中作为三字符散列表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。图33为此查找表3302的一范例。图33所示的查找表3302为数组，不过本发明并不限于此。此查找表3302也可以其它型式排列，如树状或散列表的型式。如后续图34与图35所示，此查找表3302可用于对散列链2611的节点2706赋予机率2703值。此流程终止于此。

现在请参照图34，此图为流程图，显示图26的硬件数据压缩器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在此时点为最新的节点，因而会被插入在其它所有具有相同机率的节点的前方。此流程终止于此。

现在请参照图35，此图为时序图，例示图26的硬件数据压缩器100依据图34执行的运作。在图35中，时间进程下向递增，而节点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插入(如图34步骤3412)年龄2704值为4与年龄值2704为3的二个节点间。这是因为年龄2704值为4的节点2706的机率2703值大于新节点2706，并且相较于年龄2704值为3的节点2706，新节点与其机率2703值相同，但比较新。

前述实施例对三个字符进行散列处理，而查找表3302内的字符串长度为四个字符，不过本发明并不限于此。本发明当可应用于对三个以上字符进行散列处理以及字符串长度大于四个字符的实施例。不过，字符串长度必须大于散列处理的字符数，使散列字符后方接续有一个或多个字符供确认。

依据图26至图35的描述可以发现，散列链2611的各个节点2706可依据其机率2703排列，如此扫描引擎2602即可产生指向以输入区块字符作为开头的匹配字符串的反向指针，以期能提升相较于仅依据年龄排列散列表的情况下，扫描引擎2602在到达其中止标准前找到较长匹配字符串的可能性。图28至图31的实施例利用动态方式进行，若是节点2706在扫描输入区块2606的过程更频繁地用于寻找匹配字符串以产生反向指针，其机率2703就会增加。不过，图32至图35的实施例则是利用静态方式进行，也就是依据对于具代表性的输入区块样本内的字符串频率进行预先分析，来赋予节点2706机率2703。

对来自LZ77引擎的标记直接进行霍夫曼编码的硬件数据压缩器

随着服务器，如网络服务器，的广泛使用，透过网络在服务器间传递压缩文件的情况有显著增加，因此，在服务器中使用硬件数据压缩器的需求也会随的提升。这会驱动对低成本低功耗硬件数据压缩器的需求。

现在请参照图36，此图为方块图，显示本发明硬件数据压缩器3600的另一实施例。此硬件数据压缩器3600包含输入区块内存101、LZ77引擎102、散列内存103、霍夫曼编码引擎108与输出内存109，这些组件类似于图1的硬件数据压缩器100。以下对此进行更详细的描述。此硬件数据压缩器3600直接提供标记3612给霍夫曼编码引擎108，而霍夫曼编码引擎108随即对所接收到的各个标记3612进行霍夫曼编码程序，并将所产生的霍夫曼编码写入输出内存109。如此，此硬件数据压缩器3600就不需要反向指针内存105。此外，因为使用预编译霍夫曼编码表，此硬件数据压缩器3600就不需要包含图1的分类引擎104或是霍夫曼编码表建构引擎106。相较于如图1所示的实施例，当硬件数据压缩器3600以此模式运作时，即可省略或至少不使用反向指针内存105，而能降低成本、尺寸与耗能。

在一实施例中，此霍夫曼编码引擎108包含内容可寻址内存，霍夫曼编码表的符号值即为其内容，而不同于受编码的输入符号，并且此内容可寻址内存会输出对应于匹配输入符号霍夫曼编码。就一实施例而言，此内容可寻址内存用于同时接收三个符号输入，并同时输出三个相对应的霍夫曼编码，以配合标记3612关联有三个词汇的情形，或是反向指针标记3612的长度与距离输入内容可寻址内存的情形。此内容可寻址内存在LZ77引擎102开始扫描输入区块前载入预编译词汇/长度与距离霍夫曼编码表。就一实施例而言，对于内容可寻址内存的三个输入中的每一个输入，LZ77引擎102都会提供相对应信号，标示此符号为词汇/长度或是距离，使内容可寻址内存可确认究竟是要存取词汇/长度或是距离霍夫曼编码表。就一实施例而言，反向指针的长度与距离的额外位由LZ77引擎102，经适当排列后与内容可寻址内存所输出的数值同时传递并写入输出内存109。

现在请参照图37，此图为流程图，显示图36的硬件数据压缩器3600的运作。在图37中，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。

现在请参照图38，此图为时序图，显示图36的硬件数据压缩器3600依据图37的方法执行的运作。此时序图的上部分显示LZ77引擎102的运作，而下部分显示霍夫曼编码引擎108的运作。时间进程由左而右递增。图中以时钟周期表示时间，不过，也可使用其它相关时间单位，如奈秒。

如图中所示，在周期0的时候，LZ77引擎102开始从当前搜寻位置扫描输入区块，以执行字符串匹配的第一次搜寻(标示为S1)，如图37的步骤3702所示，而在周期3的时候，LZ77引擎102输出标记3612(标示为TOK1)至霍夫曼编码引擎108。因应于此，霍夫曼编码引擎108对关联于标记TOK1的各个符号进行霍夫曼编码程序，并将产生的霍夫曼编码写入输出内存109，如图37的步骤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。

如图37所示，LZ77引擎102产生标记3612所需的时钟周期并非维持不变，举例来说，搜寻程序S4需要59个时钟周期，这通常表示一个相对较长的散列链；而搜寻程序S1、S3与S5只需要3个时钟周期，这通常表示一个空白的散列链。不过，只要LZ77引擎102产生了标记3612，霍夫曼编码引擎108就会对关联于此标记3612的符号进行霍夫曼编码程序，而能降低将反向指针写入内存或从内存中读取反向指针的需求。

在一实施例中，内存中大约有25KB保留给如图1所述的实施例，其中反向指针与旗标内存105用以储存大约8K x 24位反向指针与16K x 1位旗标。

在一实施例中，硬件数据压缩器100包含反向指针与旗标内存105(此内存可用于以执行于其它模式，如图3至图20所述)，但用于执行图36至图38所述的模式。此实施例未必可以省略内存硬件，不过仍然可以降低耗能，因为在此实施例中，LZ77引擎102不须将反向指针与旗标写入内存，而霍夫曼编码引擎108也不须从内存中读取反向指针与旗标。

基于输入区块类型使用动态散列算法的硬件数据压缩器

本发明在产生散列算法供散列索引产生器使用的过程中，如图24所示的散列索引产生器2432与2442，存在有目标，希望能对散列表尽量提供一个相对而言分布比较平均的散列索引。因而倾向于减少产生长度非常长的散列链的可能性，或至少不要使这个问题恶化，以改善依据LZ77引擎的扫描步骤来搜寻匹配字符串所需使用的搜寻时间。这个问题至少有部分原因是来自于散列混淆(hashaliasing)，或称为散列冲突(hash collision)。散列混淆会发生在对于不同输入进行散列处理后会得到相同的散列索引的情形。举例来说，依据所使用的散列算法，字符“the”与字符“was”可能会得到相同的散列索引，而这个问题对于大部分的英文字输入区块特别不利，因为字符“the”与字符“was”都是英文字中频繁出现的字符，而有很高的可能性会产生非常长的散列链来进行索引。

如前述，若是提供一种散列算法，具有将常用英文字散列处理至不同索引的倾向，将会对此带来帮助。不过硬件数据压缩器100也会用于压缩英文字以外的其它类型的输入区块。因此，较佳的方式是提供多个散列算法给其它语言，包含不可说/写的语言(如HTML、JAVA等)，而这些散列算法倾向于产生相对而言比较平均的散列索引分布。此外，对其他输入区块类型而言，包含非语言的输入区块(如电子窗体、可执行二维文件等)，提供散列算法，倾向于产生相对而言比较平的散列索引分布，也有帮助。

现在请参照图39，此图为方块图，显示图1的LZ77引擎102的一部分。在图39至图41的实施例中，输入区块类型3901(如文字、电子窗体、文字处理器、pdf、HTML、JAVA等)提供至硬件数据压缩器100以指出所要压缩的输入区块类型，而LZ77引擎102会依据输入区块类型3901使用不同的散列算法。在某些实施例中，散列处理的位数会随着散列类型而改变。举例来说，若是输入区块是ASCII文字，各个字符(字节)的上方位就不会包含在散列处理内，举例来说，如图41所示，此时只有21个位进行散列处理，而非24个位。一般而言，因为上方位均为零，而会扭曲散列索引的分布，因此前述处理方式可以提供一个较佳的分布。在其它实施例中，由散列算法执行的算术/逻辑运算会随着输入区块类型改变。此外，在其它实施例中，输入区块中，散列算法执行散列处理的字符数会随着输入区块的类型改变。

LZ77引擎112包含散列表3948与节点3906构成的散列链3941。此处的散列表3948，散列链3911与节点3906类似于图24、图26与图27中的散列表、散列链与节点，即组件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表示。在一实施例中，前述一个或多个散列算法可以是选自图24与图25的算法，即三位与四位的散列算法。

现在请参照图40，此图为流程图，显示图39的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指向的位置，以寻找匹配字符串。此流程终止于此。

现在请参照图41，此图为方块图，详细显示图39的散列索引产生器3942。图41的散列索引产生器3942的特殊之处，在于它并不在其散列算法中使用来自输入区块3936的字符内的所有位。进一步来说，如图中所示，散列索引产生器3942会接收输入区块3936的各个三字符中，除了最显著位(most significantbit，MSB)以外的所有位并将其用于散列算法。这三个字符在图41中标示为第一字符、第二字符与第三字符。散列索引产生器3942一共对21个位进行散列处理，即第一、第二与第三字符的下方7个位，以产生索引3954提供给图39中的多工器3999。以下表6为图41的散列索引产生器3942用以对这21个位进行散列处理所使用的散列算法的一范例。不过，表6的散列算法仅为本发明的一例示，而非限定本发明的范围。此外，除了在各个字符中使用最少7个位进行散列处理的实施例外，本发明也可应用于其它进行散列处理的位数少于输入区块3936字符的全部位的态样。图41的实施例特别适合于输入区块类型3901为ASCII文字的情形，因为对ASCII文字而言，各个字符(或字节)的上方位倾向于变成零，而会导致散列索引分布不平。

short3＝{byte0[6:0],byte1[6:0],byte2[6:0]}；//Concatenate lower 7bits of theinput bytes together mult3＝short3*8'hae；//Multiply by hexadecimal 0xAEhash_value3＝14'(mult3^(mult3>>11))；//Logical right shift by 11,then XOR withoriginal,finally use only first 14 bits of result.

表6

现在请参照图42，此图为方块图，显示包含如图1所示的硬件数据压缩器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中填入霍夫曼编码表(以本文前述方式)，如前述预编译霍夫曼编码表以及/或是“参考”霍夫曼编码表。

现在请参照图43，此图为方块图，显示包含硬件数据压缩器100系统4300的另一实施例。此系统4300类似于图42所示的系统4200。不过，在图43的系统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等)、网络接线、无线或是其它通讯媒介。此处描述的装置与方法的实施例可被包含于半导体智财核心，例如微处理核心(如以硬件描述语言的实施方式)并且透过集成电路的制作转换为硬件。此外，本文所描述的装置与方法也可包含硬件与软件的结合。因此，本文所述的任何实施例，并非用以限定本发明的范围。此外，本发明可应用于一般通用计算机的微处理器装置。最后，所属技术领域具有通常知识者利用本发明所揭露的观念与实施例作为基础，来设计并调整出不同的结构已达成相同的目的，也不超出本发明的范围。

通过以上具体实施例的详述，希望能更加清楚描述本发明的特征与精神，而并非以上述所揭露的具体实施例来对本发明的范畴加以限制。相反地，其目的是希望能涵盖各种改变及具相等性的安排于本发明所欲申请的权利要求的范畴内。

Claims (17)

1.一种硬件数据压缩器，用以压缩字符块，其特征在于，包括：

第一硬件引擎：

寻找该字符区块中位于当前位置的字符字符串的匹配，并且该匹配早于该字符字符串出现于该字符区块；

确认第一尺寸，该第一尺寸为利用霍夫曼编码表对该匹配字符串执行霍夫曼编码程序所产生的总位数；

计算反向指针，该反向指针从该当前位置指向该早先出现的该字符串；以及

确认第二尺寸，该第二尺寸为利用该霍夫曼编码表对该反向指针执行霍夫曼编码程序所产生的位数；以及

第二硬件引擎，当该第一尺寸小于该第二尺寸时，该第二硬件引擎对该匹配字符串执行霍夫曼编码程序，否则就对该反向指针执行霍夫曼编码程序。

2.根据权利要求1所述的硬件数据压缩器，其特征在于，该第一硬件引擎利用先于压缩该字符区块的步骤进行编译的霍夫曼编码表确认该第一与该第二尺寸。

3.根据权利要求1所述的硬件数据压缩器，其特征在于，还包括：

第三硬件引擎，于该第一硬件引擎只扫描该字符区块的开始部分后，依据扫描该开始部分所产生的符号频率建构霍夫曼编码表；

其中，于该第三硬件引擎建构该霍夫曼编码表后，该第一硬件引擎利用所建构的该霍夫曼编码表确认该第一与该第二尺寸。

4.根据权利要求3所述的硬件数据压缩器，其特征在于，于该第三硬件引擎建构该霍夫曼编码表前，该第一硬件引擎利用先于压缩该字符区块的步骤进行编译的霍夫曼编码表确认该第一与该第二尺寸。

5.根据权利要求3所述的硬件数据压缩器，其特征在于，于该第三硬件引擎建构该霍夫曼编码表前，该第二硬件引擎会对该反向指针而非对该匹配字符串进行霍夫曼编码程序，无论该第一尺寸是否小于该第二尺寸。

6.根据权利要求1所述的硬件数据压缩器，其特征在于，该第二硬件引擎对该匹配字符串与该反向指针执行霍夫曼编码程序所使用的霍夫曼编码表，不同于该第一硬件引擎确认该第一与该第二尺寸所使用的该霍夫曼编码表。

7.根据权利要求1所述的硬件数据压缩器，其特征在于，该第一硬件引擎依据LZ77无损数据压缩算法计算该反向指针。

8.一种压缩字符块的方法，其特征在于，包括：

寻找该字符区块中位于当前位置的字符字符串的匹配，并且该匹配早于该字符字符串出现于该字符区块；

确认第一尺寸，该第一尺寸为利用霍夫曼编码表对该匹配字符串执行霍夫曼编码程序所产生的总位数；

计算反向指针，该反向指针从该当前位置指向该早先出现的该字符串；

确认第二尺寸，该第二尺寸利用该霍夫曼编码表对该反向指针执行霍夫曼编码程序所产生的位数；以及

当该第一尺寸小于该第二尺寸时，对该匹配字符串执行霍夫曼编码程序，否则就对该反向指针执行霍夫曼编码程序。

9.如请求项第8项的方法，其特征在于，确认该第一与该第二尺寸的步骤利用先于压缩该字符块的步骤进行编译的霍夫曼编码表。

10.根据权利要求8所述的方法，其特征在于，还包括：

扫描该字符区块的开始部分后，依据扫描该开始部分所产生的符号频率建构霍夫曼编码表；

其中，于建构该霍夫曼编码表的步骤后，利用所建构的该霍夫曼编码表确认该第一与该第二尺寸。

11.根据权利要求10所述的方法，其特征在于，于建构该霍夫曼编码表的步骤前，利用先于压缩该字符区块的步骤进行编译的霍夫曼编码表确认该第一与该第二尺寸。

12.根据权利要求10所述的方法，其特征在于，于建构该霍夫曼编码表的步骤前，对该反向指针而非该匹配字符串进行霍夫曼编码程序，无论该第一尺寸是否小于该第二尺寸。

13.根据权利要求8所述的方法，其特征在于，对该匹配字符串与该反向指针执行霍夫曼编码程序所使用的霍夫曼编码表，不同于确认该第一与该第二尺寸所使用的该霍夫曼编码表。

14.根据权利要求8所述的方法，其特征在于，计算该反向指针的步骤利用LZ77无损数据压缩算法。

15.根据权利要求8所述的方法，其特征在于，该方法由硬件压缩引擎执行。

16.一种编码于至少非瞬时计算机可使用媒体以供计算机装置使用的计算机程序产品，其特征在于，包括：

内含于该媒体的计算机可使用程序代码，用以描述硬件数据压缩器，该计算机可使用程序代码包括：

第一程序代码，用以描述第一硬件引擎：

寻找该字符区块中位于当前位置的字符字符串的匹配，并且该匹配早于该字符字符串出现于该字符块；

确认第一尺寸，该第一尺寸为利用霍夫曼编码表对该匹配字符串执行霍夫曼编码程序所产生的总位数；

计算反向指针，该反向指针从该当前位置指向该早先出现的该字符串；以及

确认第二尺寸，该第二尺寸为利用该霍夫曼编码表对该反向指针执行霍夫曼编码程序所产生的位数；以及

第二程序代码，用以描述第二硬件引擎，当该第一尺寸小于该第二尺寸时，该第二硬件引擎对该匹配字符串执行霍夫曼编码程序，否则就对该反向指针执行霍夫曼编码程序。

17.根据权利要求16所述的计算机程序产品，其特征在于，该至少非瞬时计算机可使用媒体选自光盘、磁带，或其它磁性、光学或电子储存媒体所构成的群组。