对于Cortex M0 M3 M4 的我知道可以在其《Technical Reference Manual 》> Programmers Model > Instruction set summary 里面查看
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/CHDCICDF.html
但是到了M7， 他告诉我去ARM-V7-M的手册中找
“The processor implements the ARMv7-M instruction set and features provided by the ARMv7E-M architecture profile. For more information about the ARMv7-M instructions, see the ARM®v7-M Architecture Reference Manual.” -----《ARM Cortex-M7 Processor Technical Reference Manual》Programmers Model > Instruction set summary > Binary compatibility with other Cortex processors
但是在 V7-M 手册里，也没有找到具体的指令执行周期。请问应该去哪里找呢
原来如此，那么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透明。
make sense 了，另外 dual-issue的判断是由哪一个部分进行管理的，跟PFU，branch predictor是一起工作的吗？ 找了半天感觉相关资料很少，是不是也属于非公开资料?
然后您说的
当你只有一个ALU的时候，你永远无法同时发射两个数值运算指令就是这个道理。Cortex-M7拥有两个ALU，但是只有一个LSU（Load Store Unit），所以，很容易根据这个信息判断出哪些指令存在双发射的可能。
我不是特别理解具体如何判断。是指：只有一个LSU说明两个Data相关的指令无法同时进行，这个意思吗？最起码无法同时load/store。也就是说两个ADD指令，在M7里【1】，第一个stage取两个指令，然后用两个stage分别decode，经过两个stage（E1,E2）在ALU中计算完成，一个stage store到Register。，dual-issue是这样工作的吧？然后俩个LDR就无法dual-issue。那么LDR,LDR,ADD,STR这样的组合呢？
我用Keil-MDK debug STM32F746,是个M7核，trace一般的指令比如MOV,VLDR，STR,CMP都是12个clock cycle，这样测然后想加是不是无法反映实际运行的情况？
另外【1】中的这个2nd issue stage，看上去是不是，不管可不可以dual-issue都会被执行？
【1】community.arm.com/.../how-long-are-the-cortex-m7-pipeline-stages
不好意思，你问的这些问题已经属于非公开的内容了。我无法具体回答，我只能给你一些大体的信息：
- 两个无数据相关的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，确实很好用。只是有个问题是DWT中除了CYCCNT外的counter，都只有8bit的register。所以如果一段程序稍长一点的话就溢出了，既然CPI是统计的话，一段一端的测程序好像会不太准的样子。这个overflow，v7-M 手册里说会触发counter overflow event，但是我没找到怎么收集这个event，是需要设置一个中断触发吗？ 因为这个，我最后还是选择keil debug中的trace，用ITM来trace 这些event，因为里面可以累加counter的值，也能读到overflow事件。只是跟DWT printf出来的，有点不太一样。
另外我看keil debug的话，时钟周期的测量也是通过coresight来trace的，如果一段程序稍长一些的（不是by instruction），keil里显示的数据跟DWT CYCCNT出来的是一样的。
非常感谢。
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什么的算法