超级军网一种提高RISC处理器速度的想法
来源：百度文库 编辑：超级军网 时间：2024/04/29 04:08:17
很多RISC处理器的指令都是32位固定长度，通常RISC处理器的处理速度都是每周期一条指令，指令都是直接针对寄存器操作。现代的处理器都是哈弗结构，或者哈弗混合普林斯顿结构，也就是有独立的指令总线和数据总线，现在的技术存储器的位宽很容易提升。假如处理器的内部总线是256bit，指令缓存和数据缓存也是256bit，数据缓存供应2个128位的SIMD算术器，这样的处理器通常也就做成2~4指令并行的超标量结构，取指令为256bit位宽，也就是一个周期可以取8条指令，考虑到指令预取和分支预测，指令预取器的入口时是8条指令，出口只有2~4条指令。
同时，像立即数指令，对于32位处理器来说需要2条指令处理一个立即数，64位处理器则需要4条指令。而对于处理器来说，通常我们看到的寄存器是16个或者32个，但是当处理器处于不同状态时，访问的寄存器是不同的。
基于以上原因，我提出一种提高RISC速度的方法，也就是来源于X86的微码和指令融合。虽然每条RISC指令都是32位对齐，但是在流水线取指后，送入译码器，译码器可以把32位长的指令扩展成40位（对32位寄存器）或者80位（对64位寄存器）。首先受益的就是立即数指令，而一些简单的指令，则可以一条32位长的指令扩成40位或者80位，因为RISC的指令并不多，因此硬件不会有多复杂，而且扩位发生在CPU流水线里面，不会消耗存储空间。另外这种方法还能使分支跳转得到优化，在指令预取后，直接译码后就能得到分支跳转地址，这时只要提高L1 cache位宽和预读指令空间，就能减少分支预测错误时发生流水线清空的概率。很多RISC处理器的指令都是32位固定长度，通常RISC处理器的处理速度都是每周期一条指令，指令都是直接针对寄存器操作。现代的处理器都是哈弗结构，或者哈弗混合普林斯顿结构，也就是有独立的指令总线和数据总线，现在的技术存储器的位宽很容易提升。假如处理器的内部总线是256bit，指令缓存和数据缓存也是256bit，数据缓存供应2个128位的SIMD算术器，这样的处理器通常也就做成2~4指令并行的超标量结构，取指令为256bit位宽，也就是一个周期可以取8条指令，考虑到指令预取和分支预测，指令预取器的入口时是8条指令，出口只有2~4条指令。
同时，像立即数指令，对于32位处理器来说需要2条指令处理一个立即数，64位处理器则需要4条指令。而对于处理器来说，通常我们看到的寄存器是16个或者32个，但是当处理器处于不同状态时，访问的寄存器是不同的。
基于以上原因，我提出一种提高RISC速度的方法，也就是来源于X86的微码和指令融合。虽然每条RISC指令都是32位对齐，但是在流水线取指后，送入译码器，译码器可以把32位长的指令扩展成40位（对32位寄存器）或者80位（对64位寄存器）。首先受益的就是立即数指令，而一些简单的指令，则可以一条32位长的指令扩成40位或者80位，因为RISC的指令并不多，因此硬件不会有多复杂，而且扩位发生在CPU流水线里面，不会消耗存储空间。另外这种方法还能使分支跳转得到优化，在指令预取后，直接译码后就能得到分支跳转地址，这时只要提高L1 cache位宽和预读指令空间，就能减少分支预测错误时发生流水线清空的概率。
同时，像立即数指令，对于32位处理器来说需要2条指令处理一个立即数，64位处理器则需要4条指令。而对于处理器来说，通常我们看到的寄存器是16个或者32个，但是当处理器处于不同状态时，访问的寄存器是不同的。
基于以上原因，我提出一种提高RISC速度的方法，也就是来源于X86的微码和指令融合。虽然每条RISC指令都是32位对齐，但是在流水线取指后，送入译码器，译码器可以把32位长的指令扩展成40位（对32位寄存器）或者80位（对64位寄存器）。首先受益的就是立即数指令，而一些简单的指令，则可以一条32位长的指令扩成40位或者80位，因为RISC的指令并不多，因此硬件不会有多复杂，而且扩位发生在CPU流水线里面，不会消耗存储空间。另外这种方法还能使分支跳转得到优化，在指令预取后，直接译码后就能得到分支跳转地址，这时只要提高L1 cache位宽和预读指令空间，就能减少分支预测错误时发生流水线清空的概率。很多RISC处理器的指令都是32位固定长度，通常RISC处理器的处理速度都是每周期一条指令，指令都是直接针对寄存器操作。现代的处理器都是哈弗结构，或者哈弗混合普林斯顿结构，也就是有独立的指令总线和数据总线，现在的技术存储器的位宽很容易提升。假如处理器的内部总线是256bit，指令缓存和数据缓存也是256bit，数据缓存供应2个128位的SIMD算术器，这样的处理器通常也就做成2~4指令并行的超标量结构，取指令为256bit位宽，也就是一个周期可以取8条指令，考虑到指令预取和分支预测，指令预取器的入口时是8条指令，出口只有2~4条指令。
同时，像立即数指令，对于32位处理器来说需要2条指令处理一个立即数，64位处理器则需要4条指令。而对于处理器来说，通常我们看到的寄存器是16个或者32个，但是当处理器处于不同状态时，访问的寄存器是不同的。
基于以上原因，我提出一种提高RISC速度的方法，也就是来源于X86的微码和指令融合。虽然每条RISC指令都是32位对齐，但是在流水线取指后，送入译码器，译码器可以把32位长的指令扩展成40位（对32位寄存器）或者80位（对64位寄存器）。首先受益的就是立即数指令，而一些简单的指令，则可以一条32位长的指令扩成40位或者80位，因为RISC的指令并不多，因此硬件不会有多复杂，而且扩位发生在CPU流水线里面，不会消耗存储空间。另外这种方法还能使分支跳转得到优化，在指令预取后，直接译码后就能得到分支跳转地址，这时只要提高L1 cache位宽和预读指令空间，就能减少分支预测错误时发生流水线清空的概率。
感觉针对指令的优化应该考虑指令出现的频率吧
立即数指令经常出现么？
立即数指令经常出现么？
happywar 发表于 2012-10-8 22:39 ![]()
感觉针对指令的优化应该考虑指令出现的频率吧
立即数指令经常出现么？
跳转指令，函数调度，中断调度貌似几率比较高
感觉针对指令的优化应该考虑指令出现的频率吧
立即数指令经常出现么？
跳转指令，函数调度，中断调度貌似几率比较高
lz多虑了，其实Intel的cpu实际上是混有risc的理念的，目前它已经做得很好了。
真nb就去写论文
到这里来语焉不详装b玩么
到这里来语焉不详装b玩么
马甲2 发表于 2012-10-9 02:08 ![]()
lz多虑了，其实Intel的cpu实际上是混有risc的理念的，目前它已经做得很好了。
针对龙芯，神威之类非x86的提速
lz多虑了，其实Intel的cpu实际上是混有risc的理念的，目前它已经做得很好了。
针对龙芯，神威之类非x86的提速
先不说别的，译码器真的有楼主所说的功能么？32位最多有2的32次方种组合，楼主通过什么方式产生出40或者80位？
32位长的指令扩展成40位（对32位寄存器）或者80位（对64位寄存器）
这玩意该怎么扩展?
这玩意该怎么扩展?
dreamsea 发表于 2012-10-9 09:34 ![]()
先不说别的，译码器真的有楼主所说的功能么？32位最多有2的32次方种组合，楼主通过什么方式产生出40或者80位 ...
扩，RISC的指令是可以直接执行的，但是为了保证处理器效率，指令长度都是32位定长格式。有些操作需要多条指令才能完成。比如立即数指令可以两条指令合并，对于简单的逻辑指令，32位长度的也可以扩展到40位，只需要往高位添0就行了，通常相互关联的指令都是相邻的，而取指令的时候，指令总线都是比内部流水线宽，从技术上完全可以做到。
先不说别的，译码器真的有楼主所说的功能么？32位最多有2的32次方种组合，楼主通过什么方式产生出40或者80位 ...
扩，RISC的指令是可以直接执行的，但是为了保证处理器效率，指令长度都是32位定长格式。有些操作需要多条指令才能完成。比如立即数指令可以两条指令合并，对于简单的逻辑指令，32位长度的也可以扩展到40位，只需要往高位添0就行了，通常相互关联的指令都是相邻的，而取指令的时候，指令总线都是比内部流水线宽，从技术上完全可以做到。
carsbus 发表于 2012-10-9 10:29 ![]()
32位长的指令扩展成40位（对32位寄存器）或者80位（对64位寄存器）
这玩意该怎么扩展?
RISC指令都是分类的，比如算术指令，立即数指令，存取指令，跳转指令，可以通过标志位来弄
如果加法指令机器码是0x8000，扩展后是机器码0x08000
如果是立即数指令，比如立即数0x2345加载到寄存器R0，两条指令是LDL R0 0x23,LDH R0 0x45
，对应机器码是0x6023,0xE023，那么这两条指令可以融合为0x62345(6位LD操作，0为寄存器0，6+8 = C,8是寄存器高低段标志)
32位长的指令扩展成40位（对32位寄存器）或者80位（对64位寄存器）
这玩意该怎么扩展?
RISC指令都是分类的，比如算术指令，立即数指令，存取指令，跳转指令，可以通过标志位来弄
如果加法指令机器码是0x8000，扩展后是机器码0x08000
如果是立即数指令，比如立即数0x2345加载到寄存器R0，两条指令是LDL R0 0x23,LDH R0 0x45
，对应机器码是0x6023,0xE023，那么这两条指令可以融合为0x62345(6位LD操作，0为寄存器0，6+8 = C,8是寄存器高低段标志)
楼主还是高GPU高速并行化吧 那更简单 更有效
楼主申请专利受intel和AMD的税。
楼主，你说的那几类指令最多占程序5%左右，而能有用的处理器占市场5%左右。
再看看代价，楼主你为了这么点优化，首先把问题搞复杂了，编译器很多优化可能要重做。
最终实际效率的提升基本不存在任何意义。
你认为这有用吗？
再看看代价，楼主你为了这么点优化，首先把问题搞复杂了，编译器很多优化可能要重做。
最终实际效率的提升基本不存在任何意义。
你认为这有用吗？
我了个去……risc去提升直接数指令效率……这跟risc的设计概念南辕北辙了好不好……
RISC的基本原则就20%的指令的使用率高达80%以上，那么去专门优化那20%指令的实现，那些80%的指令用20%指令功能组合实现即可，从而简化了处理器设计。
连内存操作都被阉割的差不多的RISC居然还去碰使用率更低的直接数操作……
RISC的基本原则就20%的指令的使用率高达80%以上，那么去专门优化那20%指令的实现，那些80%的指令用20%指令功能组合实现即可，从而简化了处理器设计。
连内存操作都被阉割的差不多的RISC居然还去碰使用率更低的直接数操作……
warz 发表于 2012-10-9 17:15 ![]()
楼主，你说的那几类指令最多占程序5%左右，而能有用的处理器占市场5%左右。
再看看代价，楼主你为了这么点 ...
20年前大概有5%，现在原则上不用。
楼主，你说的那几类指令最多占程序5%左右，而能有用的处理器占市场5%左右。
再看看代价，楼主你为了这么点 ...
20年前大概有5%，现在原则上不用。
跟前几年流行的 超长指令字(VLIW)什么关系?
acoustics 发表于 2012-10-9 17:55 ![]()
跟前几年流行的 超长指令字(VLIW)什么关系?
超长指令字的原理是编译器将多条可以同时执行的指令单独打成一条，保证这些指令在同一个周期内执行。
这样用不着CPU自己来调度先后顺序，可以简化处理器指令分配的设计。
你看
一个是把麻烦从CPU里拿出来，一个是把麻烦往CPU里塞进去，完全不同的
跟前几年流行的 超长指令字(VLIW)什么关系?
超长指令字的原理是编译器将多条可以同时执行的指令单独打成一条，保证这些指令在同一个周期内执行。
这样用不着CPU自己来调度先后顺序，可以简化处理器指令分配的设计。
你看
一个是把麻烦从CPU里拿出来，一个是把麻烦往CPU里塞进去，完全不同的
实在没有搞明白把32位扩展成40位有什么明确的意义：
首先如果是前后两条立即数指令合并成一条指令，那么有一个很麻烦的地方在于如果指令预取时，正好取到前一条立即数指令结束，那该怎么办？如果动态添加一条预取，那么本质上就变成变长指令或者VLIW一类的东西了，处理起来很麻烦。如果不处理，和现在情况有什么区别？
第二点，当前risc处理器中，译码之后，指令往往要做域的展开，在流水线中不止32位的情况
第三点，对于转移预测，论文有一大堆。比较流行的方法是BHT结合BTB，直接在预取阶段就进行转移预测和转移地址预测，而不是放到译码阶段处理的
最后，RICS的设计和优化方法始终是量化优化方法，即基于定量分析的方法分析瓶颈，提出优化方案，权衡利弊，在修改之后定量分析改进带来的加速比和适用范围。
首先如果是前后两条立即数指令合并成一条指令，那么有一个很麻烦的地方在于如果指令预取时，正好取到前一条立即数指令结束，那该怎么办？如果动态添加一条预取，那么本质上就变成变长指令或者VLIW一类的东西了，处理起来很麻烦。如果不处理，和现在情况有什么区别？
第二点，当前risc处理器中，译码之后，指令往往要做域的展开，在流水线中不止32位的情况
第三点，对于转移预测，论文有一大堆。比较流行的方法是BHT结合BTB，直接在预取阶段就进行转移预测和转移地址预测，而不是放到译码阶段处理的
最后，RICS的设计和优化方法始终是量化优化方法，即基于定量分析的方法分析瓶颈，提出优化方案，权衡利弊，在修改之后定量分析改进带来的加速比和适用范围。
yigua 发表于 2012-10-9 18:19 ![]()
实在没有搞明白把32位扩展成40位有什么明确的意义：
首先如果是前后两条立即数指令合并成一条指令，那么有 ...
这种想法只是把CISC中的微码执行融入到RISC中，取指宽度大于译码宽度，当一条立即数在译码器中时，肯定下一条指令已经在取指令缓冲区了。
实在没有搞明白把32位扩展成40位有什么明确的意义：
首先如果是前后两条立即数指令合并成一条指令，那么有 ...
这种想法只是把CISC中的微码执行融入到RISC中，取指宽度大于译码宽度，当一条立即数在译码器中时，肯定下一条指令已经在取指令缓冲区了。
楼主的想法似乎是在证明高级货必须走 CISC 路线。
铁血烈鹰 发表于 2012-10-9 20:27
这种想法只是把CISC中的微码执行融入到RISC中，取指宽度大于译码宽度，当一条立即数在译码器中时，肯定下 ...
目前多发射处理器核就可以实现取指宽度大于译码宽度吧？
另外据我理解，CISC的微码本质上就是把原本的边长指令转换为一段RISC指令进行扩展执行。目前已经是RISC的基础上，再这么做的意义比较有限。当然如果面对某些特别应用（比如通信，DSP，图形处理等）增加一些复杂含义的指令也是可以的。但这个目前就是SIMD指令阿
铁血烈鹰 发表于 2012-10-9 20:27
这种想法只是把CISC中的微码执行融入到RISC中，取指宽度大于译码宽度，当一条立即数在译码器中时，肯定下 ...
目前多发射处理器核就可以实现取指宽度大于译码宽度吧？
另外据我理解，CISC的微码本质上就是把原本的边长指令转换为一段RISC指令进行扩展执行。目前已经是RISC的基础上，再这么做的意义比较有限。当然如果面对某些特别应用（比如通信，DSP，图形处理等）增加一些复杂含义的指令也是可以的。但这个目前就是SIMD指令阿
CPU的效率提高关键在提高流水线的效率，不要让流水线停下来等待。立即数操作用一个周期还是两个周期从全局来看对于提高流水线的效率几乎毫无帮助。
你可以理解为risc编译器的部分功能做到cpu里面就成了cisc
你可以理解为risc编译器的部分功能做到cpu里面就成了cisc
是兼容么?
是兼容么?
xsx 发表于 2012-10-10 01:19 ![]()
你可以理解为risc编译器的部分功能做到cpu里面就成了cisc
CISC是硬件开发者向软件开发者妥协，软件喜欢这么来那么硬件就把这个做好，软件需要某个奇葩功能那么就在硬件上直接实现。
RISC是软件开发者向硬件开发者妥协，硬件不管软件那边方便不方便只管自己效率高不高，把多余的东西去掉精简设计减少晶体管浪费，提高性能功耗比。
你可以理解为risc编译器的部分功能做到cpu里面就成了cisc
CISC是硬件开发者向软件开发者妥协，软件喜欢这么来那么硬件就把这个做好，软件需要某个奇葩功能那么就在硬件上直接实现。
RISC是软件开发者向硬件开发者妥协，硬件不管软件那边方便不方便只管自己效率高不高，把多余的东西去掉精简设计减少晶体管浪费，提高性能功耗比。
yigua 发表于 2012-10-9 21:41 ![]()
目前多发射处理器核就可以实现取指宽度大于译码宽度吧？
另外据我理解，CISC的微码本质上就是把原本的 ...
CISC不支持多发射的时候，是直接执行指令，指令按序执行，每个指令配有相关的处理单元。
后来有了微码执行，一条CISC指令可以分解为多个微码指令。
CISC和RISC的最大区别就是RISC的指令长度都是定长且格式统一，而CISC指令是不定长。定长的好处就是逻辑控制单元简单，扩展方便，RISC可以很容易实现指令并行。
取指令宽度是指令总线从L1缓存或指令存储器中取指令的数量，通常取指令单元还有预取缓冲，如果遇到分支跳转指令可以减少流水线停顿。
目前多发射处理器核就可以实现取指宽度大于译码宽度吧？
另外据我理解，CISC的微码本质上就是把原本的 ...
CISC不支持多发射的时候，是直接执行指令，指令按序执行，每个指令配有相关的处理单元。
后来有了微码执行，一条CISC指令可以分解为多个微码指令。
CISC和RISC的最大区别就是RISC的指令长度都是定长且格式统一，而CISC指令是不定长。定长的好处就是逻辑控制单元简单，扩展方便，RISC可以很容易实现指令并行。
取指令宽度是指令总线从L1缓存或指令存储器中取指令的数量，通常取指令单元还有预取缓冲，如果遇到分支跳转指令可以减少流水线停顿。
木瓜 发表于 2012-10-9 20:45 ![]()
楼主的想法似乎是在证明高级货必须走 CISC 路线。
恰好相反，RISC才是很容易提升性能，RISC最大的好处就是指令定长，在微电子技术发展，硅片上集成度更高，并行总线更宽的前提下受益更多。VLIW其实也是和RISC很类似，区别是RISC一条指令对应一个处理单元，VLIW一条指令对应多个处理单元。
另外ARM的thumb，可以看做一种压缩指令，为了减少外部存储空间，对指令进行压缩，典型的就是cortex M3，指令有2字节，4字节两种。取指令时要么取两条2字节，要么取1条4字节，但是译码和执行只能处理一条指令。所以M3经常有取指令停顿下来等待后面的流水线。而芯片商甚至有用采用低速的FLASH ROM配高速的CPU核，比如STM32，这样可以降低成本
楼主的想法似乎是在证明高级货必须走 CISC 路线。
恰好相反，RISC才是很容易提升性能，RISC最大的好处就是指令定长，在微电子技术发展，硅片上集成度更高，并行总线更宽的前提下受益更多。VLIW其实也是和RISC很类似，区别是RISC一条指令对应一个处理单元，VLIW一条指令对应多个处理单元。
另外ARM的thumb，可以看做一种压缩指令，为了减少外部存储空间，对指令进行压缩，典型的就是cortex M3，指令有2字节，4字节两种。取指令时要么取两条2字节，要么取1条4字节，但是译码和执行只能处理一条指令。所以M3经常有取指令停顿下来等待后面的流水线。而芯片商甚至有用采用低速的FLASH ROM配高速的CPU核，比如STM32，这样可以降低成本
多发射CISC取指不是看条是看容量
现代X86处理器的L1I位宽是256bit，一次取32个字节的指令。
现代X86处理器的L1I位宽是256bit，一次取32个字节的指令。
百臂巨人 发表于 2012-10-10 11:05 ![]()
CISC是硬件开发者向软件开发者妥协，软件喜欢这么来那么硬件就把这个做好，软件需要某个奇葩功能那么就在 ...
应该这么说，RISC设计是综合考虑了软件应用，编译优化，硬件开发设计之间的关系和实际情况之后共同折衷妥协的结果，并不是某一方妥协向另一方。实际上使用RISC之后整体效率相比CISC是提高的，而并非单看所谓的软件效率和硬件效率。量化分析优化运行时间，是当年RISC被提出时的基础，也是RISC设计的立身之本
CISC是硬件开发者向软件开发者妥协，软件喜欢这么来那么硬件就把这个做好，软件需要某个奇葩功能那么就在 ...
应该这么说，RISC设计是综合考虑了软件应用，编译优化，硬件开发设计之间的关系和实际情况之后共同折衷妥协的结果，并不是某一方妥协向另一方。实际上使用RISC之后整体效率相比CISC是提高的，而并非单看所谓的软件效率和硬件效率。量化分析优化运行时间，是当年RISC被提出时的基础，也是RISC设计的立身之本
铁血烈鹰 发表于 2012-10-10 13:49 ![]()
CISC不支持多发射的时候，是直接执行指令，指令按序执行，每个指令配有相关的处理单元。
后来有了微码执 ...
我可能没有说清楚，目前的多发射RISC处理器，每次从L1取指宽度一般都不止32位，即每次往往取多个指令（不过会和当前流水线状况有关联）
下面的回复没有问题，但是与我们的分歧没有关联。关键是我还是不明白怎样优化立即数指令来获得加速比的。如果是为了减少转移指令和跳转指令（这两者有所不同）导致流水线暂停导致的开销，现在是有许多方法的，比如MIPS的转移延迟技术，激进的推测式执行技术，高效的基于地址的转移预测技术，乃至于多发射乱序执行技术等等，都有相当不错的一方面。单纯基于立即数优化，这一点还是像楼上的各位所讲，实际立即数占用的比例是多少，如果比例很低，说不定优化导致的CPU频率下降（只要增加逻辑门就一定会有这个开销）带来的开销要多于实际优化的一两个周期。
所以，还是要基于量化分析
CISC不支持多发射的时候，是直接执行指令，指令按序执行，每个指令配有相关的处理单元。
后来有了微码执 ...
我可能没有说清楚，目前的多发射RISC处理器，每次从L1取指宽度一般都不止32位，即每次往往取多个指令（不过会和当前流水线状况有关联）
下面的回复没有问题，但是与我们的分歧没有关联。关键是我还是不明白怎样优化立即数指令来获得加速比的。如果是为了减少转移指令和跳转指令（这两者有所不同）导致流水线暂停导致的开销，现在是有许多方法的，比如MIPS的转移延迟技术，激进的推测式执行技术，高效的基于地址的转移预测技术，乃至于多发射乱序执行技术等等，都有相当不错的一方面。单纯基于立即数优化，这一点还是像楼上的各位所讲，实际立即数占用的比例是多少，如果比例很低，说不定优化导致的CPU频率下降（只要增加逻辑门就一定会有这个开销）带来的开销要多于实际优化的一两个周期。
所以，还是要基于量化分析
yigua 发表于 2012-10-10 17:34 ![]()
我可能没有说清楚，目前的多发射RISC处理器，每次从L1取指宽度一般都不止32位，即每次往往取多个指令（不 ...
用指令合并，立即数指令都是相邻的，多条指令并行发往译码单元。这种思路不光可以优化立即数指令，中断状态也能优化，比如寄存器重命名，32位的指令，通常是关联当前状态和当前访问寄存器。如果扩展到40位，就直接访问寄存器了，比如ARM的SP寄存器有多种模式，如果处理器内部按照40位来处理堆栈访问指令，虽然从内存里面读取的指令都是POP或者PUSH，但是目标地址不一样。
我可能没有说清楚，目前的多发射RISC处理器，每次从L1取指宽度一般都不止32位，即每次往往取多个指令（不 ...
用指令合并，立即数指令都是相邻的，多条指令并行发往译码单元。这种思路不光可以优化立即数指令，中断状态也能优化，比如寄存器重命名，32位的指令，通常是关联当前状态和当前访问寄存器。如果扩展到40位，就直接访问寄存器了，比如ARM的SP寄存器有多种模式，如果处理器内部按照40位来处理堆栈访问指令，虽然从内存里面读取的指令都是POP或者PUSH，但是目标地址不一样。