CN101620526A - 一种减少流处理器片上指令存储器资源消耗的方法 - Google Patents

Abstract

本发明公布了一种减少流处理器片上指令存储器资源消耗的方法，要解决的技术问题基于现有成熟的硬件存储器结构，不增加复杂的编译算法，有效减少指令存储器的资源消耗。技术方案是将流处理器中纯软件管理的指令存储器修改为软硬件混合指令存储器；在编译器中增加kernel热代码查找模块，根据判定热代码的定理查找流应用中的kernel热代码；且在流级编译时，在各个kernel热代码之前添加指令流加载指令；采用软件管理静态存储器存储kernel热代码以保证其高命中率，采用硬件管理的cache存储其他指令，通过缩短指令占用指令存储器的时间来减少指令存储器对存储器容量的需求，从而可以减少指令存储器的容量。采用本发明能减少指令存储器在芯片中的资源消耗。

Description

一种减少流处理器片上指令存储器资源消耗的方法

技术领域

本发明涉及减少芯片中指令存储器资源消耗的方法，尤其指一种减少流处理器片上指令存储器资源消耗的方法。

背景技术

基于流体系结构的流处理器是新一代面向密集计算的高性能微处理器的典型代表，专门面向流应用。流应用主要分为两类：一类是媒体应用；另一类是科学计算。流应用具有以下几个主要特征：计算密集性，与传统的桌面应用相比，流式应用对每次从内存取出的数据都要进行大量的算术运算；并行性，以数据级并行为主，同时存在指令级和任务级并行；局域性，是指应用中的数据重用局域性。流应用程序通常包含kernel级程序和流级程序两部分：流级程序负责组织输入和输出数据，kernel程序是运算的核心，负责对这些数据进行运算。

由于流处理器中多以超长指令字(VLIW：Very Long Instruction Word)的方式组织指令来开发指令级并行，这种结构使得流处理器指令存储器的宽度很大(因为指令存储器每行至少要能容纳1条VLIW)；另一方面，流处理器的片上指令存储器大多采用软件静态管理的方式，存储空间的分配以kernel为粒度，因此，指令存储器必须有能力同时容纳多个kernel，这使得流处理器指令存储器的深度很大。对宽度和深度的要求直接导致指令存储器的容量增加，从而使得其在芯片中占用的面积比例增加。如Imagine中核心指令存储器的面积占芯片面积的10％，MASA中核心指令存储器占芯片面积的26％。编译器静态调度指令码的管理方式保证了指令存储器能为计算单元高效地提供指令，然而以kernel为调度粒度使得在kernel的生命周期中，存在大量的无效指令或不常使用指令长时间占用指令存储空间。这增加了指令存储器的资源消耗，即增加了构建存储器所需的硬件存储单元的消耗。

对于超长指令字结构的处理器，减少指令存储器资源消耗主要有指令压缩、分布式指令存储器和指令生命周期分析优化等方法。指令压缩是通过某种编码算法对指令码进行压缩，减少指令码的长度，从而降低指令码对存储空间的需求。由于应用程序中有限的指令级并行使得VLIW中不可避免的含有很多空操作，该方法最大的问题是将压缩后的指令还原时会引入额外的指令流出延迟。分布式指令存储器是将VLIW存储器分割为多个窄的指令存储器，每个存储器分别与一个计算功能单元对应，当VLIW中对应的功能单元出现空操作时，与该功能单元对应的指令存储器则可以不存储指令，从而可以减少指令存储空间的需求。这是一种采用修改存储器硬件结构设计来压缩指令的方法，它的主要问题是由于不同应用对各功能单元的需求不同，使得VLIW中空操作出现的比例不同，会造成部分功能单元对应的局部指令存储器不够用，而另一部分指令存储器则有多余的现象。此方法与前一种方法类似，都是通过横向压缩指令来减少指令对存储空间的需求，从而减少存储器资源消耗。指令生命周期分析优化是通过缩短指令占据存储器的时间来降低应用程序对存储空间的需求，从而可通过减少总的存储容量来减少存储器的资源消耗。该方法主要是通过分析程序的局域性，预测程序中各部分指令的生命周期，通过编译器控制指令导入存储器的时机，并指导各指令在其生命周期结束后及时的释放存储空间，从而尽量缩短指令占据存储器的时间，在纵向上压缩指令来减少指令存储器的资源消耗。该方法过分依赖软件编译器的能力，若编译器预测错误，则会造成程序性能极为低下。

发明内容

本发明要解决的技术问题是提供一种减少流处理器片上指令存储器资源消耗的方法。该方法基于现有成熟的硬件存储器结构，增加少量的指令读取延迟，不增加复杂的编译算法，能有效的减少指令存储器的资源消耗。

本发明的方案是：将流处理器中纯软件管理的指令存储器修改为软硬件混合指令存储器，根据流应用中kernel程序的特征，定义kernel热代码；根据kernel热代码的定义，得到三个判定kernel热代码的定理；在编译器中增加kernel热代码查找模块，由kernel热代码查找模块根据三个判定定理查找流应用中的kernel热代码；采用软件管理静态存储器存储kernel热代码以保证其高命中率，采用硬件管理的cache存储其他指令，通过缩短指令占用指令存储器的时间来减少程序对存储空间的需求，从而可以缩减总存储容量，从而减少指令存储器的资源消耗。

本发明技术方案是：

为说明本发明技术方案，先给出如下定义和定理：

定义1：循环LOOP1是循环LOOP2的外层循环，若LOOP2不失效能保证80％以上的LOOP1指令不失效，则称LOOP2是LOOP1的热代码。

定义2：如果kernel中某个循环的所有指令不失效能保证kernel中最外层循环80％以上的指令不失效，则称这个循环是“kernel热代码”，称kernel中其他指令为“kernel凉代码”。

在kernel中，最外层循环之外的指令在整个kernel的执行过程中只会执行一次，而对于没有预取功能的指令存储器来说，这些指令都存在不可避免的强制失效，即在首次使用这些指令(也是唯一的一次)时，它们没有装载进指令存储器中而引发的失效。而对于循环内部的指令，由于它们都需要被反复多次执行，若指令存储器有足够的能力捕捉其时间局域性，即存储器有足够的容量或高效的替换策略使得它们在反复执行的过程中一直存于存储器中，那么就能极大保证循环内部指令的命中率，从而提高整个kernel的命中率。因此，kernel热代码定义主要考虑了kernel最外层循环内指令的命中率，而忽略外层循环之外的指令的影响，在指令存储器的硬件设计中再对外层循环之外的指令进行优化。

根据热代码和kernel热代码的定义，得到判定热代码的三个定理。

定理1：循环LOOP1长度为L1，LOOP2长度为L2，循环次数为C2，LOOP1是LOOP2的外层循环。若满足(C₂-1)*(L₂/L₁)＞4，则LOOP2是LOOP1的“热代码”。

证明：考虑最坏的情况：存储器仅有能力捕捉LOOP2的时间局域性，而完全不能捕捉LOOP1的时间局域性。也就是说，每次LOOP1执行一次新的循环时，LOOP1中的所有指令都会失效一次，即LOOP1每开始一轮新循环，其中LOOP2的第一遍循环会全部失效，但本次LOOP1的循环中LOOP2的后续循环将全部命中。可以计算出，在这种情况下，LOOP1的失效指令数(MI，Miss Instructions)和失效率(MR，Miss Rate)分别为：

MI＝L₁

$\mathrm{MR}=\frac{L_1}{C_1[L_1+L_2(C_2-1)]}=\frac{1}{C_1[1+\frac{L_2}{L_1}(C_2-1)]}$

若LOOP2在LOOP1每一轮新循环中都存在强制失效的情况下，都能保证LOOP1的命中率大于80％，那么LOOP2的指令不失效就更加能保证80％以上的LOOP1指令不失效，即LOOP2是LOOP1的热代码。因此有如下推导：

LOOP2是LOOP1的热代码

1-MR＞80％

$\⇔1-\frac{1}{1+\frac{L_2}{L_1}(C_2-1)}>80\%$

$\⇔\frac{L_2}{L_1}(C_2-1)>4$

定理2：LOOP1是kernel中的最外层循环，若LOOP1没有热代码，则LOOP1是kernel热代码；若LOOP2是LOOP1的热代码，则LOOP2为kernel热代码。

证明：由定义1和定义2显然得证。

由于kernel结构不同，在进行kernel热代码分析时，多层循环嵌套进行kernel热代码分析比较复杂。因此，提出三层循环嵌套的kernel热代码判定定理：

定理3(三层嵌套循环kernel热代码判定定理)：LOOP1、LOOP2、LOOP3是kernel中的由外到内三层嵌套循环，L1、L2、L3分别为三个循环的长度，C1、C2、C3分别为对应的循环次数。LOOP3是kernel热代码，当且仅当命题1和命题2同时成立：

命题1：LOOP3是LOOP2的热代码；

命题2： $\frac{L_2}{L_1-L_2}*C_2>\frac{\frac{1}{h}-1}{1.25-\frac{1}{h}},$ 其中 $h=\frac{L_3{C}_2(C_3-1)}{C_2(L_2-L_3)+L_3{C}_3{C}_2}$ (h表示当LOOP3中指令的不失效时，LOOP2的最低命中率)；

证明：

1.若LOOP3不是LOOP2的热代码，也就是说，LOOP3指令不失效时，LOOP2的命中率小于80％，那么LOOP2的外层循环LOOP1的命中率会更低，从而可知LOOP3不是kernel热代码；

2.若LOOP3是LOOP2的热代码，LOOP1的最低命中率(HR，Hit Rate)为：

$\mathrm{HR}=\frac{L_3{C}_2{C}_1(C_3-1)}{C_1(L_1-L_2)+C_1{C}_2(L_2-L_3)+L_3{C}_3{C}_2{C}_1}$

3.LOOP3是kernel热代码

HR＞80％

$\⇔\frac{L_3{C}_2{C}_1(C_3-1)}{C_1(L_1-L_2)+C_1{C}_2(L_2-L_3)+L_3{C}_3{C}_2{C}_1}>80\%$

$\⇔\frac{1}{\frac{L_1-L_2}{L_3{C}_2(C_3-1)}+\frac{C_2(L_2-L_3)+L_3{C}_3{C}_2}{L_3{C}_2(C_3-1)}}>80\%$

$\⇔\frac{1}{\frac{1}{C_2}*\frac{\frac{L_1}{L_2}-1}{\frac{L_3}{L_2}(C_3-1)}+\frac{1}{h}}>80\%$ (∵ $h=\frac{L_3{C}_2(C_3-1)}{C_2(L_2-L_3)+L_3{C}_3{C}_2}\⇒\frac{L_3}{L_2}(C_3-1)=\frac{h}{1-h}$ )

$\⇔\frac{1}{\frac{1}{C_2}*(\frac{L_1}{L_2}-1)*(\frac{1}{h}-1)+\frac{1}{h}}>80\%$

$\⇔\frac{L_2}{L_1-L_2}*C_2>\frac{\frac{1}{h}-1}{1.25-\frac{1}{h}}$

本发明最多只对3层嵌套循环进行kernel热代码分析，因为kernel作为流应用中的计算核心，通常不会含有多层循环嵌套的程序结构。3层嵌套循环的情况已经很少见，多于3层循环的kernel基本上没有。对于超过3层循环的kernel也按照3层循环的情况来处理。

本发明的具体步骤是：

第一步，将流处理器中纯软件管理的指令存储器修改为软硬件混合指令存储器。软硬件混合指令存储器由软件管理静态存储器和硬件管理的cache两部分组成。设计方法如下：

1.1.软件管理静态存储器与地址产生控制器、片外存储器和计算簇相连，它从片外存储器获得程序中的kernel热代码，即流控制器根据从地址产生控制器获得的写地址将各kernel热代码由片外存储器写入软件管理静态存储器；程序执行时，软件管理静态存储器给计算簇提供数据，即计算簇根据地址产生控制器中的读地址从软件管理静态存储器中读取kernel热代码。

软件管理静态存储容量设定为流处理器中原有的静态指令存储器容量的一半。通过查找典型应用中的kernel热代码，发现kernel热代码量通常为原程序指令代码量的一半左右，所以静态指令存储器的容量减小为原来容量的一半。

1.2.硬件管理的cache是一个直接映射的经典cache，包括存储体、Tag存储器和cache控制器三个部分，它从片外存储器获得程序中的kernel凉代码。

存储体与cache控制器、片外存储器和计算簇相连。存储体从片外存储器获得程序中的kernel凉代码，即流控制器将kernel凉代码从片外存储器写入cache控制器指定的存储体的地址；程序执行时，硬件管理的cache向计算簇提供kernel凉代码，即计算簇根据cache控制器产生的kernel凉代码的读地址，从存储体中读取kernel凉代码。

Tag存储器与cache控制器相连。在kernel凉代码导入存储体时，cache控制器根据凉代码中指令的写地址解析出对应的Tag位和Tag存储器写地址，根据Tag存储器写地址将Tag位写入Tag存储器；在计算簇从存储体中读取kernel凉代码中的指令时，cache控制器根据指令读地址解析出与其对应的Tag存储器读地址，根据该读地址从Tag存储器读取对应Tag位。

cache控制器与地址产生控制器、Tag存储器和存储体相连。当计算簇从存储体读取指令时，cache控制器从地址产生控制器获取指令读地址，根据指令读地址解析出存储体读地址、指令对应的Tag位和Tag存储器读地址。根据存储体读地址从存储体中读出指令，根据Tag存储器读地址从Tag存储器中读取对应的Tag位。将指令对应的Tag位与从Tag存储器中读出的Tag位进行比较，若二者相等，则表示cache命中，存储体中读取的指令有效；若二者不相等，则表示cache失效，存储体中读取的指令无效。cache控制器中包含一个硬件预取部件，当cache失效时，硬件预取部件向片外存储器发cache取指令请求，请求将失效指令以及失效指令后续的若干条指令(即凉代码)一并写入存储体。硬件预取有很多种方式，最常见的是采用cache行预取，即一次cache写操作写入一个cache行，一个cache行内包含多条指令。当cache取指令请求被片外存储器响应后，地址产生控制器将cache写地址送入cache控制器，cache控制器根据指令写地址解析出该指令对应的存储体写地址、Tag存储器写地址和指令对应的Tag位，根据存储体写地址将指令写入存储体，根据Tag存储器写地址将Tag位写入Tag存储器。

硬件管理的cache的存储体大小通常为2的整数次幂(cache访问地址是由片外存储器地址截位而得，所以2的整数次幂方便地址变换)。因为kernel大小一般不会超过1024条VLIW，kernel凉代码通常不会超过kernel大小的一半，所以存储体的容量通常为512条VLIW。若流处理器是专门面向某类应用，也可以根据该类应用的特征对其容量进行定制。

第二步，在编译器中增加kernel热代码查找模块，由kernel热代码查找模块查找kernel热代码。对于含有n个kernel的应用程序，kernel热代码查找模块的流程是：

2.1.令i的初始值为1；

2.2.提取第i个kernel中各层循环的长度和除最外层循环外所有循环的循环次数，即L₁、L₂、L₃、C₂、C₃的值。

L₁、L₂和L₃的值为由外到内三层循环的长度，由编译器通过解析循环指令的循环跳转的范围得到，C₂、C₃为第二、第三层的循环次数，其值根据应用的特征而定。在流应用中，循环的次数与输入数据流的长度密切相关。对于典型的流应用(如视频编码、图像搜索等)，输入流的大小在绝大多数情况下是可预知的(如一帧图像的大小是确定的)，因此C₂、C₃的值通过kernel的输入流的长度除以每次循环处理数据的个数来确定。在极少数特殊应用中，少数kernel的输入流的不定长会造成C₂或C₃不可预知。对C₂或C₃不可预知的情况要分别进行处理；

2.3.若C₂不可预知，标记第一层循环为kernel热代码，转步骤2.5；若C₂可预知但C₃不可预知，转步骤2.4；若C₂和C₃都可预知，利用定理3判断第三层循环是否为kernel热代码，方法如下：

计算P₁＝(C₃-1)*(L₃/L₂)、 $P_2=\frac{L_2}{L_1-L_2}*C_2,$ $h=\frac{L_3(C_3-1)}{(L_2-L_3)+L_3{C}_3};$

若P₁＞4且 $P_2>\frac{\frac{1}{h}-1}{1.25-\frac{1}{h}},$ 则将第三层循环标记为kernel热代码，转步骤2.5；否则转步骤2.4；

2.4.利用定理1和定理2查找kernel热代码，方法如下：

计算P＝(C₂-1)*(L₂/L₁)；

若P＞4，则将第二层循环标记为kernel热代码，转步骤2.5；否则标记第一层循环为kernel热代码，转步骤2.5；

2.5.i＝i+1，若i＞n，则kernel热代码查找完毕，转入第三步；否则转步骤2.2。

第三步，在流级编译时，在各个kernel热代码之前添加指令流加载指令，该指令通常为如下格式：

StreamLoad<启动标志位完成标志位起始地址流长度指令相关性>

启动标志位表示该指令是否已经启动，一般0表示未启动，1表示已启动；完成标志位表示该指令是否已经完成，一般0表示未完成，1表示已完成。起始地址和流长度信息指定了kernel热代码在软件管理静态存储器中的空间分配；指令相关性包含了本条指令与它之前其他指令的相关性信息，当所有相关性都得到满足，本条指令流加载指令才能被启动执行，也就是说，指令相关性确定了kernel热代码导入软件管理静态存储器的时机。

第四步，将应用程序装载到软硬件混合指令存储器，启动程序运行，程序运行过程如下：

4.1.令j的初始值等于1；

4.2.查询第j个kernel的kernel热代码对应的指令流加载指令的状态，若启动标志位为未启动则转步骤4.3；若已启动但完成标志位指示为未完成则转步骤4.5；若完成标志位为已完成则转步骤4.6；

4.3.判断第j个kernel的kernel热代码对应的指令流加载指令的指令相关性是否满足，若满足则转步骤4.4，否则程序执行终止，输出“系统异常”。

当轮到第j个kernel执行时，它的kernel热代码对应的指令流加载指令的相关性必须得到满足，这是由编译器保证的。若得不到满足，则表示出现了系统异常。

4.4.启动第j个kernel的指令流加载指令，修改该指令的启动标志位为已启动。由地址产生控制器执行该指令流加载指令，获取软件管理静态存储器起始地址和指令流的长度，将第j个kernel的kernel热代码从外部存储器写入软件管理静态存储器；

4.5.等待第j个kernel的kernel热代码写入软件管理静态存储器，当第j个kernel的kernel热代码全部写入软件管理静态存储器，将第j个kernel的指令流加载指令的完成标志位修改为已完成；

4.6.令k＝j+1，启动第j个kernel运行，执行步骤4.7～4.8；同时导入后续kernel的kernel热代码，执行步骤4.9～4.11；

在第j个kernel执行时，同时导入后续kernel的kernel热代码，实现计算和存储操作的重叠执行，从而提高程序执行的效率。

4.7.若k＞n，转步骤4.12；若k≤n，判断第k个kernel的kernel热代码对应的指令流加载指令的指令相关性是否满足，若满足则启动第k个kernel的指令流加载指令，修改该指令的启动标志位为已启动，转步骤4.8；若不满足则直接转步骤4.8；

4.8.k＝k+1；转步骤4.7；

4.9.若第j个kernel执行完毕，转步骤4.12；否则执行步骤4.10；

4.10.根据地址产生控制器中的地址访问软硬件混合指令存储器。若地址产生控制器中的地址是软件管理静态存储器的地址，则计算簇从软件管理静态存储器中读取对应的指令；若是硬件管理的cache地址，则转步骤4.11；

4.11.若cache失效，则硬件预取部件请求从片外存储器中加载凉代码，写入硬件管理的cache；若cache命中，计算簇从硬件管理的cache存储体中读取对应的指令；转步骤4.9；

4.12.k＞n且第j个kernel执行完毕，转步骤4.13，否则转步骤4.12；

4.13.j＝j+1；若j＞n，则程序执行结束；否则转步骤4.2。

采用本发明可以达到以下技术效果：

1.采用硬件管理的cache存储当前执行kernel的kernel凉代码，相对于纯软件管理的指令存储器，减少了其他非活跃kernel(非当前执行的kernel)的凉代码对存储空间的长期占用，从而减少了存储器容量的需求，减少了指令存储器在芯片中的面积消耗；

2.本发明采用硬件管理的cache存储当前执行kernel的kernel凉代码，并通过硬件预取等方法提高了凉代码的命中率。这是因为程序有顺序执行的特性，当某条指令被执行之后，若不出现跳转指令，则后续指令肯定被执行。因此，当某条指令发生失效，将其后续的若干条指令一并取入cache中，可以减少后续指令失效。由于流处理器中运算单元很多，分支操作通常会被转化为选择操作执行，即将分支操作的两条路径都执行，然后对根据分支条件对二者的结果进行选择。这样减少了流应用程序中的跳转指令；另外，kernel凉代码中的循环跳转要远少于整个kernel中的循环跳转，因此在cache中增加硬件预取功能对提高kernel的命中率有明显的效果。

3.本发明采用软件管理静态存储器保证了kernel热代码不失效，带预取功能的硬件管理的cache提高了凉代码的命中率，从而保证了整个kernel指令的高命中率；对kernel热代码和kernel凉代码的分别存储减少了非活跃kernel的凉代码对存储空间的长期占用，从而减少了存储器容量的需求；因此，本发明在保证指令高命中率的情况下降低了对指令存储器容量的需求，从而提高了指令存储器的利用率，减少了存储器的资源消耗。

附图说明

图1是本发明总体流程图。

图2是本发明第一步设计的软硬件混合指令存储器结构图。

图3是本发明第二步对含有n个kernel的应用程序kernel热代码查找方法流程图。

图4是本发明第四步采用本发明时含n个kernel的应用程序运行过程示意图。

图5是本发明指令在存储器中空间占用示意图。

图6是采用本发明后kernel运行时间及指令存储器资源消耗比较。

具体实施方式

图1是本发明的总体流程图。

第一步，将流处理器中纯软件管理的指令存储器修改为软硬件混合指令存储器。软硬件混合指令存储器由软件管理静态存储器和硬件管理的cache两部分组成。如图2所示。

第二步，在编译器中增加kernel热代码查找模块，由kernel热代码查找模块查找kernel热代码，查找方法流程如图3所示。

第三步，在流级编译时，在各个kernel热代码之前添加指令流加载指令。

第四步，将程序指令装载到软硬件混合指令存储器，启动程序运行。程序运行过程和软硬件混合指令存储器读/写操作的流程如图4所示。

图2是本发明第一步设计的软硬件混合指令存储器结构图。设计方法如下：

1.1.软件管理静态存储器与地址产生控制器、片外存储器和计算簇相连，它从片外存储器获得程序中的kernel热代码，即流控制器根据从地址产生控制器获得的写地址将各kernel热代码由片外存储器写入软件管理静态存储器；程序执行时，软件管理静态存储器给计算簇提供数据，即计算簇根据地址产生控制器中的读地址从软件管理静态存储器中读取kernel热代码。

软件管理静态存储容量设定为流处理器中原有的静态指令存储器容量的一半。通过查找典型应用中的kernel热代码，发现kernel热代码量通常为原程序指令代码量的一半左右，所以静态指令存储器的容量减小为原来容量的一半。

1.2.硬件管理的cache是一个直接映射的经典cache，包括存储体、Tag存储器和cache控制器三个部分。

存储体与cache控制器、片外存储器和计算簇相连。存储体从片外存储器获得程序中的kernel凉代码，即流控制器将kernel凉代码从片外存储器写入cache控制器指定的存储体的地址；程序执行时，硬件管理的cache向计算簇提供kernel凉代码，即计算簇根据cache控制器产生的kernel凉代码的读地址，从存储体中读取kernel凉代码。

Tag存储器与cache控制器相连。在kernel凉代码导入存储体时，cache控制器根据凉代码中指令的写地址解析出对应的Tag位和Tag存储器写地址，根据Tag存储器写地址将Tag位写入Tag存储器；在计算簇从存储体中读取kernel凉代码中的指令时，cache控制器根据指令读地址解析出与其对应的Tag存储器读地址，根据该读地址从Tag存储器读取对应Tag位。

cache控制器与地址产生控制器、Tag存储器和存储体相连。当计算簇从存储体读取指令时，cache控制器从地址产生控制器获取指令读地址，根据指令读地址解析出存储体读地址、指令对应的Tag位和Tag存储器读地址。根据存储体读地址从存储体中读出指令，根据Tag存储器读地址从Tag存储器中读取对应的Tag位。将指令对应的Tag位与从Tag存储器中读出的Tag位进行比较，若二者相等，则表示cache命中，存储体中读取的指令有效；若二者不相等，则表示cache失效，存储体中读取的指令无效。cache控制器中包含一个硬件预取部件，当cache失效时，硬件预取部件向片外存储器发cache取指令请求，请求将失效指令以及失效指令后续的若干条指令一并写入存储体。硬件预取有很多种方式，最常见的是采用cache行预取，即一次cache写操作写入一个cache行，一个cache行内包含多条指令。当cache取指令请求被片外存储器响应后，地址产生控制器将cache写地址送入cache控制器，cache控制器根据指令写地址解析出该指令对应的存储体写地址、Tag存储器写地址和指令对应的Tag位，根据存储体写地址将指令写入存储体，根据Tag存储器写地址将Tag位写入Tag存储器。

硬件管理的cache的存储体大小通常为2的整数次幂(cache访问地址是由片外存储器地址截位而得，所以2的整数次幂方便地址变换)。因为kernel大小一般不会超过1024条VLIW，kernel凉代码通常不会超过kernel大小的一半，所以存储体的容量通常为512条VLIW。若流处理器是专门面向某类应用，也可以根据该类应用的特征对其容量进行定制。

图3是本发明第二步对含有n个kernel的应用程序kernel热代码查找方法流程图。。对于含有n个kernel的应用程序，kernel热代码查找模块的流程是：

2.1.令i的初始值为1；

2.2.提取第i个kernel中各层循环的长度和除最外层循环外所有循环的循环次数，即L₁、L₂、L₃、C₂、C₃的值。

L₁、L₂和L₃的值为由外到内三层循环的长度，由编译器通过解析循环指令的循环跳转的范围得到，C₂、C₃为第二、第三层的循环次数，其值根据应用的特征而定。在流应用中，循环的次数与输入数据流的长度密切相关。对于典型的流应用(如视频编码、图像搜索等)，输入流的大小在绝大多数情况下是可预知的(如一帧图像的大小是确定的)，因此C₂、C₃的值通过kernel的输入流的长度除以每次循环处理数据的个数来确定。在极少数特殊应用中，少数kernel的输入流的不定长会造成C₂或C₃不可预知。对C₂或C₃不可预知的情况要分别进行处理；

2.3.若C₂不可预知，标记第一层循环为kernel热代码，转步骤2.5；若C₂可预知但C₃不可预知，转步骤2.4；若C₂和C₃都可预知，利用定理3判断第三层循环是否为kernel热代码，方法如下：

计算P₁＝(C₃-1)*(L₃/L₂)、 $P_2=\frac{L_2}{L_1-L_2}*C_2,$ $h=\frac{L_3(C_3-1)}{(L_2-L_3)+L_3{C}_3};$

若P₁＞4且 $P_2>\frac{\frac{1}{h}-1}{1.25-\frac{1}{h}},$ 则将第三层循环标记为kernel热代码，转步骤2.5；否则转步骤2.4；

2.4.利用定理1和定理2查找kernel热代码，方法如下：

计算P＝(C₂-1)*(L₂/L₁)；

若P＞4，则将第二层循环标记为kernel热代码，转步骤2.5；否则标记第一层循环为kernel热代码，转步骤2.5；

i＝i+1，若i＞n，则kernel热代码查找完毕，转入第三步；否则转步骤2.2。

图4是本发明第四步采用本发明时含n个kernel的应用程序运行过程示意图。

4.1.令j的初始值等于1；

4.2.查询第j个kernel的kernel热代码对应的指令流加载指令的状态，若启动标志位为未启动则转步骤4.3；若已启动但完成标志位指示为未完成则转步骤4.5；若完成标志位为已完成则转步骤4.6；

4.3.判断第j个kernel的kernel热代码对应的指令流加载指令的指令相关性是否满足，若满足则转步骤4.4，否则程序执行终止，输出“系统异常”。

当轮到第j个kernel执行时，它的kernel热代码对应的指令流加载指令的相关性必须得到满足，这是由编译器保证的。若得不到满足，则表示出现了系统异常。

4.4.启动第j个kernel的指令流加载指令，修改该指令的启动标志位为已启动。由地址产生控制器执行该指令流加载指令获取软件管理静态存储器起始地址和指令流的长度，将第j个kernel的kernel热代码从外部存储器写入软件管理静态存储器；

4.5.等待第j个kernel的kernel热代码写入软件管理静态存储器，当第j个kernel的kernel热代码全部写入软件管理静态存储器，将第j个kernel的指令流加载指令的完成标志位修改为已完成；

4.6.令k＝j+1，启动第j个kernel运行，执行步骤4.7～4.8；同时导入后续kernel的kernel热代码，执行步骤4.9～4.11；

在第j个kernel执行时，同时导入后续kernel的kernel热代码，实现计算和存储操作的重叠执行，从而提高程序执行的效率。

4.7.若k＞n，转步骤4.12；若k≤n，判断第k个kernel的kernel热代码对应的指令流加载指令的指令相关性是否满足，若满足则启动第k个kernel的指令流加载指令，修改该指令的启动标志位为已启动，转步骤4.8；若不满足则直接转步骤4.8；

4.8.k＝k+1；转步骤4.7；

4.9.若第j个kernel执行完毕，转步骤4.12；否则执行步骤4.10；

4.10.根据地址产生控制器中的地址，访问软硬件混合指令存储器。若地址产生控制器中的地址是软件管理静态存储器的地址，则计算簇从软件管理静态存储器中读取对应的指令；若是硬件管理的cache地址，则转步骤4.11；

4.11.若cache失效，则启动硬件预取机制，从片外存储器中加载凉代码，写入硬件管理的cache；若cache命中，计算簇从硬件管理的cache存储体中读取对应的指令；转步骤4.9；

4.12.k＞n且第j个kernel执行完毕，转步骤4.13，否则转步骤4.12；

4.13j＝j+1；若j＞n，则程序执行结束；否则转步骤4.2。

图5是本发明指令在存储器中空间占用示意图。左图是指令在现有大多数流处理器采用的纯软件指令存储器中的空间占用示意图，右图是指令在本发明的软硬件混合指令存储器中空间占用示意图。可以看出，在纯软件指令存储器中，多个kernel的所有指令都同时存储于指令存储器中，所有的kernel凉代码在kernel的整个生命周期中都会一直占用存储空间，直到kernel结束才会释放存储空间。由于kernel凉代码在kernel的整个生命周期中很少被访问，这使得指令存储器的利用率降低。在本发明的软硬件混合指令存储器中，kernel热代码都存储于软件管理静态存储器，以保证其命中率。硬件管理的cache中只存储当前执行kernel的kernel凉代码，这种设计减少了kernel凉代码对片上指令存储器存储空间的占用，减少了应用对存储器容量的需求，减少了存储器的资源消耗。

图6是采用本发明后kernel运行时间及指令存储器资源消耗比较。以MASA流处理器为平台，分别采用本发明软硬件混合管理指令存储器、纯软件管理静态存储器和纯硬件管理的cache作为指令存储器，比较6个应用程序在这三种结构下kernel运行时间及指令存储器资源消耗。纯软件管理的静态存储器和纯硬件管理的cache容量都为2048条VLIW，本发明的存储器容量由两部分组成：软件管理静态存储器为1024条VLIW，硬件管理的cache为512条VLIW，比纯软件管理的静态存储器和纯硬件管理的cache的容量小512条VLIW。

分别采用上述三种存储器作为MASA流处理器的指令存储器，将RS、SUSAN、LUCAS、Ygx2、MPEG和H264等六个应用程序分别在MASA流处理器上执行，统计个应用程序的执行时间，并将所有的执行时间对采用纯软件管理静态存储器作为指令存储器的MASA的执行时间进行归一操作，即所有的执行时间都除以在纯软件管理的静态存储器下对应的执行时间，得到如图6中的柱状图。.

利用HP公司公布的存储器评测软件cacti获得三种存储器的资源消耗，并将所有资源消耗值对采用纯软件管理静态存储器作为指令存储器的资源消耗进行归一操作，得到如图6中的折线图。

可以看出，采用本发明，虽然有些应用的执行时间增加了少许，但指令存储器的资源消耗减少了很多。

Claims (4)

1.一种减少流处理器片上指令存储器资源消耗的方法，其特征在于包括以下步骤：

第一步，将流处理器中纯软件管理的指令存储器修改为软硬件混合指令存储器，软硬件混合指令存储器由软件管理静态存储器和硬件管理的cache两部分组成，设计方法如下：

1.1.软件管理静态存储器与地址产生控制器、片外存储器和计算簇相连，它从片外存储器获得程序中的kernel热代码，并在程序执行时给计算簇提供数据；

1.2.硬件管理的cache包括存储体、Tag存储器和cache控制器三个部分，它从片外存储器获得程序中的kernel凉代码；

第二步，在编译器中增加kernel热代码查找模块，kernel热代码查找模块的流程是：

2.1.令i的初始值为1；

2.2.由编译器通过解析循环指令的循环跳转的范围得到第i个kernel中由外到内三个循环的长度L₁、L₂、L₃，根据应用的特征确定第二、第三层的循环次数C₂、C₃：当kernel的输入流的大小预知时，C₂、C₃的值通过输入流的长度除以每次循环处理数据的个数来确定；当kernel的输入流不定长时C₂或C₃不可预知；

2.3.若C₂不可预知，标记第一层循环为kernel热代码，转步骤2.5；若C₂可预知但C₃不可预知，转步骤2.4；若C₂和C₃都可预知，判断第三层循环是否为kernel热代码，方法是计算P₁＝(C₃-1)*(L₃/L₂)、 $P_2=\frac{L_2}{L_1-L_2}*C_2$ 、 $h=\frac{L_3(C_3-1)}{(L_2-L_3)+L_3{C}_3},$ 若P₁＞4且 $P_2>\frac{\frac{1}{h}-1}{1.25-\frac{1}{h}},$ 则将第三层循环标记为kernel热代码，转步骤2.5；否则转步骤2.4；

2.4.查找kernel热代码，方法是计算P＝(C₂-1)*(L₂/L₁)，若P＞4，则将第二层循环标记为kernel热代码，转步骤2.5；否则标记第一层循环为kernel热代码，转步骤2.5；

2.5.i＝i+1，若i＞n，n为应用程序中含有的kernel个数，转第三步；否则转步骤2.2；

第三步，在流级编译时，在各个kernel热代码之前添加指令流加载指令，该指令格式为：

StreamLoad<启动标志位 完成标志位 起始地址 流长度 指令相关性>

启动标志位表示该指令是否已经启动，完成标志位表示该指令是否已经完成，起始地址和流长度信息指定了kernel热代码在软件管理静态存储器中的空间分配，指令相关性包含了本条指令与它之前其他指令的相关性信息，当所有相关性都得到满足，本条指令流加载指令才能被启动执行；

第四步，将应用程序装载到软硬件混合指令存储器，启动程序运行，程序运行过程和软硬件混合指令存储器读/写操作的流程如下：

4.1.令j的初始值等于1；

4.2.查询第i个kernel的kernel热代码对应的指令流加载指令的状态，若未启动则转步骤4.3，若未完成则转步骤4.5，若已完成则转步骤4.6；

4.3.判断kernel j的kernel热代码对应的指令流加载指令的相关性是否满足，若满足则转步骤4.4，否则程序执行终止，输出“系统异常”；

4.4.启动第j个kernel的指令流加载指令，修改该指令的启动标志位为已启动，由地址产生控制器执行该指令流加载指令，获取软件管理静态存储器起始地址和指令流的长度，将第j个kernel的kernel热代码从外部存储器写入软件管理静态存储器；

4.5.等待第j个kernel的kernel热代码写入软件管理静态存储器，当第j个kernel的kernel热代码全部写入软件管理静态存储器，将第j个kernel的指令流加载指令的完成标志位修改为已完成；

4.6.令k＝j+1，启动第j个kernel运行，执行步骤4.7～4.8；同时导入后续kernel的kernel热代码，执行步骤4.9～4.11；

4.7.若k＞n，转步骤4.12；若k≤n，判断第k个kernel的kernel热代码对应的指令流加载指令的指令相关性是否满足，若满足则启动第k个kernel的指令流加载指令，修改该指令的启动标志位为已启动，转步骤4.8；若不满足则直接转步骤4.8；

4.8.k＝k+1；转步骤4.7；

4.9.若第j个kernel执行完毕，转步骤4.12；否则执行步骤4.10；

4.10.若地址产生控制器中的地址是软件管理静态存储器的地址，则计算簇从软件管理静态存储器中读取对应的指令；若是硬件管理的cache地址，则转步骤4.11；

4.11.若cache失效，则硬件预取部件请求从片外存储器中加载凉代码，写入硬件管理的cache；若cache命中，计算簇从硬件管理的cache存储体中读取对应的指令，转步骤4.9；

4.12.k＞n且第j个kernel执行完毕，转步骤4.13，否则转步骤4.12；

4.13.j＝j+1；若j＞n，则程序执行结束；否则转步骤4.2。

2.如权利要1所述的一种减少流处理器片上指令存储器资源消耗的方法，其特征在于所述软件管理静态存储容量设定为流处理器中原有的静态指令存储器容量的一半。

3.如权利要1所述的一种减少流处理器片上指令存储器资源消耗的方法，其特征在于如果kernel中某个循环的所有指令不失效能保证kernel中最外层循环80％以上的指令不失效，则这个循环为kernel热代码，kernel中其他指令为kernel凉代码。

4.如权利要1所述的一种减少流处理器片上指令存储器资源消耗的方法，其特征在于所述硬件管理的cache中的存储体与cache控制器、片外存储器和计算簇相连，存储体从片外存储器获得程序中的kernel凉代码，并在程序执行时向计算簇提供kernel凉代码；Tag存储器与cache控制器相连，在kernel凉代码导入存储体时，cache控制器根据凉代码中指令的写地址解析出对应的Tag位和Tag存储器写地址，根据Tag存储器写地址将Tag位写入Tag存储器；在计算簇从存储体中读取kernel凉代码中的指令时，cache控制器根据指令读地址解析出与其对应的Tag存储器读地址，根据该读地址从Tag存储器读取对应Tag位；cache控制器与地址产生控制器、Tag存储器和存储体相连，当计算簇从存储体读取指令时，cache控制器从地址产生控制器获取指令读地址，根据指令读地址解析出存储体读地址、指令对应的Tag位和Tag存储器读地址，根据存储体读地址从存储体中读出指令，根据Tag存储器读地址从Tag存储器中读取对应的Tag位；将指令对应的Tag位与从Tag存储器中读出的Tag位进行比较，若二者相等，则表示cache命中，存储体中读取的指令有效；若二者不相等，则表示cache失效，存储体中读取的指令无效；cache控制器中包含一个硬件预取部件，当cache失效时，硬件预取部件向片外存储器发cache取指令请求，请求将失效指令以及失效指令后续的若干条指令一并写入存储体；当cache取指令请求被片外存储器响应后，地址产生控制器将cache写地址送入cache控制器，cache控制器根据指令写地址解析出该指令对应的存储体写地址、Tag存储器写地址和指令对应的Tag位，根据存储体写地址将指令写入存储体，根据Tag存储器写地址将Tag位写入Tag存储器。

Images