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

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 其实就是个统计的活……你跑一段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语言的各类技巧。内容太大，这里就不方便展开了。