如何查找 Cortex M7 的指令执行周期？

两条指令之所以安排他们同时执行，就是因为两条指令同时的执行时间小于二者之和啊。应该说，和最长的那条指令执行时间一样长——你会发现，双发射的流水线连回答“他的执行时间与一条指令单独执行相比如何？”都是不容易做到的。

如果你从MIPS过来，应该更多接触过超标量，甚至是Out of Order的流水线。超标量，甚至是Out of Order的流水线理论上都无法精确的标注一条指令的执行周期，这种情况下，为了评估系统吞吐量，往往用另外一个概念，也就是CPI（Cycle per Instruction）或者IPC（Instruction per Cycle）。对于Cortex-M0这种顺序执行的流水线来说，CPI一定是 >= 1的，但是对于超标量以及OOO的流水线来说，CPI是可以做到 < 1的。

至于你说的参考表，如果你非要一个大体的参考，那么可以不那么严格的参照Cortex-M3/M4的数据。

至于你说的出一个二维表格……你有考虑过这个表格有多大么？从排列组合的角度来说，这是一个可怕的全排列啊……当你要考虑两个指令的可能性的时候，实际上要考虑三条指令的全排列……也就是说从所有支持的指令中任意找出3条指令，然后对他们进行全排列……

这是没有意义的。真正有意义的是，计算一条流水线的CPI最大值和最小值。

两条指令之所以安排他们同时执行，就是因为两条指令同时的执行时间小于二者之和啊。应该说，和最长的那条指令执行时间一样长——你会发现，双发射的流水线连回答“他的执行时间与一条指令单独执行相比如何？”都是不容易做到的。

如果你从MIPS过来，应该更多接触过超标量，甚至是Out of Order的流水线。超标量，甚至是Out of Order的流水线理论上都无法精确的标注一条指令的执行周期，这种情况下，为了评估系统吞吐量，往往用另外一个概念，也就是CPI（Cycle per Instruction）或者IPC（Instruction per Cycle）。对于Cortex-M0这种顺序执行的流水线来说，CPI一定是 >= 1的，但是对于超标量以及OOO的流水线来说，CPI是可以做到 < 1的。

至于你说的参考表，如果你非要一个大体的参考，那么可以不那么严格的参照Cortex-M3/M4的数据。

至于你说的出一个二维表格……你有考虑过这个表格有多大么？从排列组合的角度来说，这是一个可怕的全排列啊……当你要考虑两个指令的可能性的时候，实际上要考虑三条指令的全排列……也就是说从所有支持的指令中任意找出3条指令，然后对他们进行全排列……

这是没有意义的。真正有意义的是，计算一条流水线的CPI最大值和最小值。

原来如此，那么CPI的计算是如何进行的呢？写完程序后手测还是有啥别的方法？另外dual-issue可不可以进行是CPU判断的还是编译器编译的时候就能进行判断？

CPI 其实就是个统计的活……你跑一段Benchmark（找点知名的，比如CoreMark或者Dhrystone之类），然后用处理器自带的PMU（Performance Monitor Unit）计算下某段函数实际跑了多少指令周期，然后除以这段函数有多少条指令。这就计算出来了。原理很简单，操作起来可能有点费劲。

而且，一个程序不同位置的CPI是变化的，甚至同一段程序的CPI也有可能是变化的，这里面干扰因素主要来源于存储器的延时，prefetch，cache policy等等。

是否可以dual issue的判断是流水线硬件来完成的，对compiler是透明的。当然，ARM Compiler在明确知道目标处理器是Cortex-M7的情况下，甚至会交换某些指令的顺序（保证逻辑等效的情况下），以最大限度的保证更多的指令可以被dual-issue。

最后我要说一下，依赖compiler是不靠谱的……要想最大程度的利用dual-issue，还是要程序员写代码的时候有所注意。简单举个例子，比如C语言中全局变量或者寄存器，往往都有volatile修饰。这保证了逻辑的正确性，却阻断了compiler优化的可能。另外，volatile的使用，使得函数内，每一个对变量的访问都要实际进行Load/Store操作，这就导致大量的Load/Store操作密集存在于同一段代码中，这些密集存在的读写操作会导致大量的Structural Hazard，从而妨害dual issue的进行。另外对volatile变量的数值运算，也会由于运算指令和Load/Store指令存在依赖关系而无法dual issue。所以，针对这种情况我们要在函数需要优化的地方，通过局部变量人为的进行“读、改、写”操作——也就是先用局部变量保存volatile变量的值，然后后续运算全部针对这个局部变量，最后再把计算结果保存回去——这是一个例子。具体软件优化方法，取决于编译器、你掌握的目标处理器的信息以及C语言的各类技巧。内容太大，这里就不方便展开了。

CPI的计算就是个统计的过程。对一段已知代码来说，有多少条指令是知道的，然后就是统计这段代码执行用了多少个指令周期。Cortex-M7有PMU（Performance Monitor Unit），通过它可以方便的统计指令周期。

Dual-issue是否可以进行是流水线硬件进行判断的，对compiler透明。

不好意思，你问的这些问题已经属于非公开的内容了。我无法具体回答，我只能给你一些大体的信息：

- 两个无数据相关的ALU操作可以duel-issue

- 两个无数据依赖关系的ALU和LS操作可以dual-issue

- 某些Load/Store指令的组合可以dual-issue

另外，关于Cortex-M7 CPI的计算，系统有一个专门的系统外设DWT（Data Watchpoint and Trace Unit），这个外设提供了一个Clock Cycle Counter（CYCCNT），可以方便的用来计算CPI。具体细节，你自己看看资料吧（ARMv7-M Architecture Reference Manual）

真是非常感谢您，明白了很多。

DWT本身就是个低成本的东西，设计目的就是应对局部。大程序（运行时间长的）要用高精度的示波器（或者逻辑分析仪）配合IO口翻转来测量时间（在测量开始的时候拉低电平，在测量结束的时候拉高电平，最终计算的时候，由拉低电平引入的误差基本忽略不计）——我还是那句话，不要相信Debug，一切都要实测。

DWT也算是debug的一种？用示波器测io反转的话，只能获得该段程序运行的运行事件，具体的指令数量看来只能动手数了。非常感激大神的耐心解答。

DWT严格来说只是一个系统的辅助外设，Debug可以访问而已。CYCCNT也不过就是帮你记录一个时间而已，指令还是要你自己去数的。就是因为这么麻烦，通常，除了研究流水线的专业人士，普通人也就是只关注实系统的实际运行性能而已。而实际运行性能和CPI其实关系不大，因为这里存在一个间接的关系：

系统性能 = 完成指定的功能/应用/运算 所花费的时间

这里，完成指定功能的程序 又要经过编译器才能生成机器码，而生成怎样的机器码，即受到编译器的限制，又受到指令集的限制。在这种情况下，CPI好不代表最终系统性能好，因为你可能完成一个功能要很多很多指令，但是每个指令CPI都很不错，最终，完成功能所用的总时间却很长。

所以，评估性能，从应用层面，往往不看底层的CPI，看了没啥用啊，太间接了。所以，直接用Benchmark去跑分更实用。除非你是做热点代码优化的，否则CPI对你意义真的很有限。

就是怕你钻牛角尖，最后做了无用功才给你说这么多的。要有Big Picture，普通人关心CPI真是屁用不顶的。

是这样的，我老师让我在ARM上跑机器学习算法。对于这个机器学习算法性能的评估需要精确到clock cycle。arm不同的核，影响因素可能众多，我就想得到一个有参考价值的时间数值，比如机器周期，这样在往其他核移植的时候比较好评估，比如可以乘以一个该核CPI还有频率就能得到大致的时间范围。现在我在对这个模型做优化，想看看什么部分对时间影响比较严重。算法的每个部分消耗多大，store和load影响多大。需要store\load多一点来减小memory数量比较好，还是加点memory减少点store\load比较好这样的。

这种算法性能评估就是典型的应用，不建议用CPI。而普通benchemark生成最终跑分的方法非常具有参考价值。简单说，就是统计跑一个算法用了多少时间，然后normalized到某个频率下的数值就是结果。比如，你用100MHz频率跑某个算法用了时间T，那么T/100 （Normalized to 1MHz）的结果就是性能的跑分。

前面说过，由于测不准的问题，你现在就算跑出一个CPI，我跟你很负责任的讲，换个编译器，换个编译器版本，换个编译选项，甚至改了几行无关紧要的代码，最后CPI都会变的。这里水很深。不然Benchmark也不会有人说水很深了。

这样啊，感觉不只是水很深的样子了，简直是毫不可测。loop的时候，branch predicter 是不是也有影响，branch predicter里面是不是有pid什么的算法