一个关于mov占用时钟周期的问题。-CSDN论坛
一个关于mov占用时钟周期的问题。
mov&&edx,dword&ptr&[ecx+edx*4+8]
mov&&eax,dword&ptr&[eax+14h]
lea&&eax,[eax+edx*8]
我不知道[ecx+edx*4+8]这个里面的乘法和加法是不是也要占用时钟周期？
这3句要占用多少时钟周期呢？
Microsoft&(R)&Macro&Assembler&Version&6.11
&&&&06/03/08&21:01:15
&&&&&Page&1&-&1
&&&&& .386
&&&&&code segment use32
&&&&& assume&cs:code
&&&&&start:
&&&&5&&&8B&54&91&08 &&&&& mov&&edx,dword&ptr&[ecx+edx*4+8]
&&&&4&&&8B&40&14 &&&&& mov&&eax,dword&ptr&[eax+14h]
&&&&2&&&8D&04&D0 &&&&& lea&&eax,[eax+edx*8]
&&&&&code ends
&&&&& end start
详细的方法请参考偶置顶的文章:
http://blog.csdn.net/mydo/archive//1776304.aspx
指令周期在不同的cpu上都有差别，即使是同一个型号的不同cpu之间也应该有差别，不同型号的cpu必然有差别，俺上学时看过一本书，讲的是代码极端速度优化的，开始时就指明了不要全信资料上说的，我还照着做了几个实验，果然是那样。
指令时钟周期在原理上讲的和实际运行是有一定差别。
各种指令的周期与CPU有关，你可以利用rdtsc来测一下，用类似下面的写法（注意地址有效性，以免发生异常）：
mov&ebx,&eax
mov&eax,&dword&ptr&[esi+ecx*4+8]&
mov&eax,&dword&ptr&[esi+14h]&
lea&eax,&[eax+edx*8]&
sub&eax,&ebx
rdtsc指令是取处理器从reset开始经历了多少个周期，返回值是eax和edx组成的64位数，低两位固定为0。该指令需要80H个周期。测试某一条指令的周期可以在两次rdtsc之间重复执行若干次要测试的指令，然后计算平均值。
看了mydo的文章，这个测周期的方法好像很不错，可我工程是c++的在vc6里调试，用/Sc好像不行，在vc6里调试有没有类似的方法啊
&&8B&54&91&08&&&&&mov&&edx,dword&ptr&[ecx+edx*4+8]&
&&8B&40&14&&&&&mov&&eax,dword&ptr&[eax+14h]&
&&8D&04&D0&&&&&lea&&eax,[eax+edx*8]&
每一条的时钟周期是怎么构成的？
比如第一条时钟周期5是怎么来的？
1&时钟周期与指令周期是不同的!指令周期应该是与CPU类型无关的,所以指令周期在不同的CPU上是一样的;但时钟周期就不一样了,有的CPU流水线等不同,一个时钟周期可以完成的指令数可能是1或小于1,也有可能是大于1;
2&指令周期由至少二个部分时钟周期决定:存储器访问周期与CPU处理的时钟(粗略认为是主频吧)
3&所有指令一定占用了机器周期,好在我们可以用指令周期替代更复杂的,与机器相关(如CPU)的周期,如一楼所说的例子一样.
该回复于 08:33:08被版主删除
MASM里输出的时钟周期数是死记硬背下来的，是很老的处理器上的典型数据。
从它的输出例子来看，MASM&6.11里的时钟周期数应该还是386时代的数字（也许更早），与今天的处理器相比已经差异太大了，以此作为优化的依据有盲人摸象的可能性。:)
比如它说：
mov&ax,offset&table&需要&4个
lea&ax,table&则需要&8&个
而&idiv&table&更是夸张的用到了超过&177&个时钟周期。
这显然是严重过时的数据。
从486以来的处理器，mov和lea的典型时钟周期数都是1，最差的情况也是2（源地址中包括两个寄存器）。
在Pentium+的超标量架构中，象mov、lea这种常用指令的等效执行时间甚至会小于1个时钟周期。
而idiv指令，据《i486&microprocessor&programmer's&reference&manual》的数字，32除以32是27/最多28个时钟周期，64除以32是43/最多44个时钟周期。在PentiumIII以来的处理器中，不会超过15个时钟周期（没有准确数字，我需要先测试一下）。
LS可能有点误会,IDE并不计算时钟,而是通过占用空间的地址,再通过指令结构(长度等)来完成对指令的运行时间推测.
不同的机器,只要指令格式(如RISC)确定,则知道了指令存储空间,所用时间可以基本得知(与指令命中率,每机器脉冲时长,流水深度以及前读栈等相关).
一般时钟周期按寻址(存储器读写时间)\控制器时长\每微指令长度等来计算,再说就太长了,但有一点是对的,MASM的指令周期计算算法是最权威的,因为INEEL团队成员,大部分是深入IBM核心指令设计的.相信IMTEL水平没有IBM的高,因为指令设计的电路级是由IBM领先的(INTEL与AMD这一部分)
错了一句子,不好意思
相信INTEL水平没有IBM的高
LS可能有点误会,IDE并不计算时钟,而是通过占用空间的地址,再通过指令结构(长度等)来完成对指令的运行时间推测.
======================================================
指令的执行时间是推测出来的？？？
不同的机器,只要指令格式(如RISC)确定,则知道了指令存储空间,所用时间可以基本得知(与指令命中率,每机器脉冲时长,流水深度以及前读栈等相关).
======================================================
我必须评价你：胡扯。
一条指令执行所需要的时间，决定性的因素是它所完成功能的复杂度，与“指令存储空间”没有必然的联系（因为不存在正相关，也可以说无关）。
你看到mydo给出的数据：
&&8B&54&91&08&&&&&mov&&edx,dword&ptr&[ecx+edx*4+8]
&&8B&40&14&&&&&mov&&eax,dword&ptr&[eax+14h]
&&8D&04&D0&&&&&lea&&eax,[eax+edx*8]&
就想当然地得出一个指令执行时间和指令长度成正比的结论来？
D5&0A&&&&&&&&&&&&&&&&&AAD
0F&BD&C2&&&&&&&&&&&&&&BSR&EAX,EDX
85&0C&82&&&&&&&&&&&&&&TEST&[EAX*4+EDX],ECX
8D&04&95&00&00&41&00&&LEA&EAX,[EDX*4+]
你来“基本得知”一下它们的执行时间，验证一下你的结论“知道了指令存储空间,所用时间可以基本得知”。:)
一般时钟周期按寻址(存储器读写时间)\控制器时长\每微指令长度等来计算,再说就太长了,但有一点是对的,MASM的指令周期计算算法是最权威的,
======================================================
据你所说，是“推测出来的”，还能“权威”？更不要说“最权威”了。
因为&INEEL团队成员,大部分是深入IBM核心指令设计的.
======================================================
不知所云。
请问intel的“团队成员”参与过什么IBM处理器的设计？又深入到什么“IBM核心指令”的设计。
相信IMTEL水平没有IBM的高,因为指令设计的电路级是由IBM领先的(INTEL与AMD&这一部分)
======================================================
这属于你的个人看法，就不评价了。
我必须评价你：胡扯。&
一条指令执行所需要的时间，决定性的因素是它所完成功能的复杂度，与“指令存储空间”没有必然的联系（因为不存在正相关，也可以说无关）。&
**************
LS不要发火
参考资料如下:
1&QuGuoping.AResearchontheInstruction-levelSimulationoftheDigitalSystem.AdvancesinModelling&Simu-lation,(3):35~42
2&Ｗｉｌｌｉａｍ&Ｓｔａｌｌｉｎｇｓ．Ｃｏｍｐｕｔｅｒ&Ｏｒｇａｎｉｚａｔｉｏｎ&ａｎｄ&Ａｒｃｈｉｔｅｃｔｕｒｅ－&Ｄｅｓｉｇｎｉｎｇ&ｆｏｒ&Ｐｅｒｆｏｒｍａｎｃｅ（ｆｏｕｒｔｈ&ｅｄｉｔｉｏｎ）&［Ｍ］．Ｐｒｅｎｔｉｖｅ&Ｈａｌｌ，１９９６．
3&ASodani,GSSohi.DynamicInstructionReuse[A].Procof24thAnnualInt.lSymponComputerArchitecture[C].
**********
如果看不习惯,请看一般教科书
高级体系结构(如郑为民的),组成原理也有讲的(如白什么英的)
*********************
其实我说的不是什么个的结论,你看看一些相关研究就行,沈绪榜先生说:中国人的指令就应该从低层改革
我终于看到难度啦
**********
谢谢LS评介,各位也看看呀
“相关研究”自然是看过的，并非只有您学过计算机系统结构和组成原理。:)
关键问题是你所谓的“知道了指令存储空间,所用时间可以基本得知”这种结论从哪里来的？哪家的计算机系统结构和组成原理里有这种说法？
清华那本郑纬民（不是郑为民）的《计算机系统结构》，第二章&指令系统，我没有看到那里有指令长度和执行时间基本成正比这种概念。
至于你举出的参考资料123，请问具体说明你的结论的文字在什么地方？不妨列出来给大家看一看。坦率地说，我不相信世界上有任何关于计算
机系统结构的书中能有“知道了指令存储空间,所用时间可以基本得知”这种荒唐透顶的说法，除非它针对某种特定的处理器，而这“特定的处
理器”，恐怕也很难说真的存在。
从优化的设计原则来说，指令集的设计应该遵循Huffman编码的基本原则，越常用的指令编码越短，这样有助于快速译码而且可以提高存储效率
和缓存的命中率。不过x86在长时间的发展过程中已经变得十分复杂了，为了保持指令集兼容，很多常用指令的编码反而很长，象mov、lea，指
令长度可能从2字节到7字节不等。可以负责任地说，在x86架构中不存在“知道了指令存储空间,所用时间可以基本得知”这种规律。也许是我
孤陋寡闻，我也不知道有任何其他的架构存在这种“规律”。
至于RISC处理器，你的结论更是无的放矢，因为RISC处理器采用定长指令，所有指令都一样长（大部分RISC处理器的指令都是32位长度），那
么所谓“知道了指令存储空间,所用时间可以基本得知”从何谈起？
RISC的设计思想是尽可能简单，追求每指令一个时钟周期，普遍每指令一个时钟周期是真的，不过这是设计的结果，只要指令完成的功能简单
到一定程度就可以，与指令长度4个字节还是8个字节没有必然的联系，没有什么“知道了指令存储空间,所用时间可以基本得知”！
我还可以负责任地说，MASM里输出的指令timing数就是死记硬背下来的，根据在程序中的.386、.486、.586、.686之类的汇编指示（这里面还
有一个BUG，因为与此帖没有直接的关系，我另外发一帖说明），输出一个实现保存的表中的数字而已，既没有实测，也没有“推测”。
masm输出的时钟周期数只能是“仅供参考”，比如以.586p指示为例测试，它输出test指令周期数一般是2，test&reg,imm是1，这恰好是i486手
册里记载的数据，再比如lea指令，masm输出总是1，但是lea指令如果源地址中包括两个寄存器，或者一个寄存器带比例乘+立即数基址，则是
两个时钟周期。显然，不管你当前用什么型号的处理器，masm就是照单输出，并非实测，要说“推测”，那也是根据一个表来“推测”的，与
“指令存储空间”没有关系。
下面就是我在14楼列出的几条指令的实测执行时间（单位：时钟周期数），你看看与“指令存储空间”有没有关系？
D5&0A&&&&&&&&&&&&&&&&&AAD
0F&BD&C2&&&&&&&&&&&&&&BSR&EAX,EDX
85&0C&82&&&&&&&&&&&&&&TEST&[EAX*4+EDX],ECX
8D&04&95&00&00&41&00&&LEA&EAX,[EDX*4+]&
Instruction&&&clock&cycle(s)
&&&&&&&&&&&&&&PentiumM&&Pentium4&&Xeon&E5335
AAD&&&&&&&&&&&2&&&&&&&&22&&&&&&&&&2
BSR&&&&&&&&&&&2&&&&&&&&&8&&&&&&&&&2
TEST&&&&&&&&&&1&&&&&&&&&1&&&&&&&&&1
LEA&&&&&&&&&&&1&&&&&&&&&2*&&&&&&&&1
IDIV&&&&&&&&&39&&&&&&&&54&&&&&&&&10
*&简单的lea在Pentium4上也是一个时钟周期，只是这一条是2。
另外关于idiv，我要更正一个说法（在11楼），我曾经认为Pentium+以来的处理器任何指令都不会比486慢，看来我犯了一个想当然的错误，只有在新的core架构上，idiv的速度才有显著提高。
怎么测出来的啊？
不给分的,讲毛啊.
买个银河III的,就不费时间了.
16这样说还是不错的,基本上我说的只是想纠正一个说法:
MASM里输出的时钟周期数是死记硬背下来的，是很老的处理器上的典型数据。&
从它的输出例子来看，MASM&6.11里的时钟周期数应该还是386时代的数字（也许更早），与今天的处理器相比已经差异太大了，以此作为优化的依据有盲人摸象的可能性
至于你说的一些说法,我真的说不出来原地了(如郑为民写划一样),很久没玩了.只是你后来说的一些说法我是同意的,例子如下&:
坦率地说，我不相信世界上有任何关于计算机系统结构的书中能有“知道了指令存储空间,所用时间可以基本得知”这种荒唐透顶的说法，除非它针对某种特定的处理器，而这“特定的处理器”，恐怕也很难说真的存在
---end----
这里的时间推测算法比较多吧,不然你说周期如何得出,真的是你说的"死记硬背"吗?
“相关研究”自然是看过的，并非只有您学过计算机系统结构和组成原理。:)&
如果看过最好再看下集成电路的系统(SYstem)设计相关的文章吧
***********
再是讨教下:
指令周期是时间的单位,还是步骤(同步)的概念!
太累了,看客自己处理吧!
我想搞过OS设计的基本是对这个理解充分的,你说的"死记硬背"我不敢认同!
如果mov&eax,ebx要一秒,
在我的电脑上要1g个时钟.
指令设计的三个部分:
1&时延结构
&&操作码时延=操作控制时延+操作码识别时延(分析时延(区分地址标识)+前读栈等缓冲时延+识别代码(译码器法时为多路状态唯一电路)时延+计数器控制时延等)
&&寻址(端口)时延=MMU控制时延(不同寻址路径确定等很多算法的)+总线时延(总线写时延+总线传输时延+总线存储写时延+等,包括缓冲与命中算法产生的时延)+总线控制时延(太多算法)
2&操作码控制结构(一般也对应时延)
&&简单串行结构
&&并行结构
&&以上包括流水线,标量等设计方法,主要对指令的运行时间影响大,对指令周期也就产生影响,影响因子约为0.1左右;
3&相关时延或等待时延
&&每次操作后因为数据相关或表数问题,需要基本延时处理,现代CPU设计中,由于低能耗设计,这一时延要求更多(有的书上叫占空比)
*****************
以上说法,希望不是胡说.
指令周期=指令时延,只是一种观点.但对于程序员来说这样理解就行了,但更深入些,个人以为应该了解指令的时延结构,而这些时延结构多以空间占用下的步骤来表示,一个完整的功能所需要的步骤,一般叫可靠指令过程.而这个过程所需要的时间,在程序员看好象就是"指令时延"
****************
时钟周期并不就是指令周期,二个时延关系对不同的处理器也不是完全一致的.所以有以上结论
***************
中午休息了一下,写点娱乐下!
欢迎拍砖!只是别粗口太重!大家是在学习不是吵架呀!
你东拉西扯的没有用。
再说一遍：
关键问题是你所谓的“知道了指令存储空间,所用时间可以基本得知”这种结论从哪里来的？哪家的计算机系统结构和组成原理里有这种说法？&
指令周期并不是时间单位，不过指令周期的时间单位是时钟周期。
“时钟周期并不就是指令周期”这就是典型的废话，完全没有意义。
时钟周期只是一个计时单位，单独说它等于缺少主语，谁的时钟周期？或者多少时钟周期？
指令周期是执行一条指令所需要步骤的序列，每一步需要1个或者多个时钟周期来完成。因此一条指令的执行也可以表示为若干个时钟周期的序列，每个时钟周期进行一个操作（在处理器的流水线中，就是所谓的微操作micro-op）。
时钟周期当然不“就是指令周期”，正如你完成一天的工作需要8小时，工作当然不等于时间，但是工作是可以用时间来衡量的！
那么你想证明什么呢？我说过“时钟周期就是指令周期”这种话？
还是&因为“时钟周期并不就是指令周期”，所以“知道了指令存储空间,所用时间可以基本得知”？（好一个蒙太奇式的逻辑推理&:）
MASM里输出的时钟周期数是死记硬背下来的，是依据程序中给出的指令集指示（.386之类）查表找出来的，而这个表是事先保存的数据，既不是实测的，更不可能是“推测”的。关于这一点，我是十分确信的，而且前面的帖子也给出了一些证据。
你要“纠正”这一观点，没有问题，但是要有确切的证据，用“知道了指令存储空间,所用时间可以基本得知”这种明显荒唐的言论能纠正吗？:)
时钟是方波是过滤比它高的频率的,
没有比时钟更快的计算了.
多线程的cpu一个时钟执行好几个指令的,
以前的cpu一个指令要好几个时钟的.
引用&20&楼&jxc25&的回复:如果mov&eax,ebx要一秒,
在我的电脑上要1g个时钟.
你的处理器才1GHz？:)
1GHz&Pentium3还是1GHz&G4？
本电脑使用Intel&Pentium&M&处理器
有关此CPU的技术请参阅http://www.intel.com
你东拉西扯的没有用。&
再说一遍：&
关键问题是你所谓的“知道了指令存储空间,所用时间可以基本得知”这种结论从哪里来的？哪家的计算机系统结构和组成原理里有这种说法？
**********你的用词太少了,如果你能礼貌些,可能我说的更多,只是与你说话太累**********
注意我的前提:(希望不要偷梁换柱)
不同的机器,只要指令格式(如RISC)确定,则知道了指令存储空间,所用时间可以基本得知(与指令命中率,每机器脉冲时长,流水深度以及前读栈等相关).&
***********
好了,只是这点就行了吧
***********以下说法我赞成***********
可以负责任地说，在x86架构中不存在“知道了指令存储空间,所用时间可以基本得知”这种规律。也许是我孤陋寡闻，我也不知道有任何其他的架构存在这种“规律”。
**********************************
&我真的不相信你看了我推荐的几个文章,里面说的很清楚,如果你没有看过,再推荐几个,大家也看看.
X86结构中微程序ROM的实现技术浅析----微电子学与计算机不通2007年第24卷第4期
这个文章比较浅显的说明了,ROM中码点压缩算法对指令(周期)影响.也就是从空间到时间的影响(微指令形成)
***************
RISC微处理器的结构和发展----轻工机械,&1992年&02期
***************
微程序汇编器的设计与实现-----计算机工程与应用&1985年&02期
还有太多,希望你能看看.空间与时间是计算机的基本问题,而你说的IDE是对"老的死记硬背",真的是误人.当然也许你有特别的理解
好了,不说了,省的LZ说我离题了.
仔细看看,是真的看看哟
少胡扯，把你的所谓文章贴上来！
我还就不相信这世界有人蠢到发表“知道了指令存储空间,所用时间可以基本得知”这种文章。
我前面不是给你举出很多例子吗，你怎么还东拉写扯的不着边际？
D5&0A&&&&&&&&&&&&&&&&&AAD
0F&BD&C2&&&&&&&&&&&&&&BSR&EAX,EDX
85&0C&82&&&&&&&&&&&&&&TEST&[EAX*4+EDX],ECX
8D&04&95&00&00&41&00&&LEA&EAX,[EDX*4+]
这指令的存储空间你看到了吧，你来“基本得知”一下它们的所用时间好不好？怎么得知？方法是什么？我请教了！
无知也没你这么个无知法的，脑子一堆浆糊，还扯来扯去这个文章、那个文章，就是不敢把具体文字贴上来。你已经丢人一次了，搬出郑纬民的书唬人，我告诉你说了书里没有你那个“知道了指令存储空间,所用时间可以基本得知”的说法，这种把戏你还要继续玩下去吗？
再说一次：决定一条指令执行时间的决定顶性因素是它所完成的功能的复杂度，不是什么存储空间！指令长度对执行时间有影响那也是老得掉牙的没有cache、没有指令预取部件、没有流水线、按照取指令、取数据、执行、写结果这种步骤一条指令完全执行完之后再执行下一条指令的原始处理器。即便这种处理器，指令长度的影响也不是决定性的，比如8088上的idiv&reg，需要100多个时钟周期，但是指令只有2字节，而mov&mem,imm长6个字节，却可以在8个时钟周期之内完成。
我在11楼说的：
================================================================================
MASM里输出的时钟周期数是死记硬背下来的，是很老的处理器上的典型数据。
从它的输出例子来看，MASM&6.11里的时钟周期数应该还是386时代的数字（也许更早），...
================================================================================
这是针对mydo举的例子输出而言的（看到“从它的输出例子来看”这句了吗），经过测试，ml是依据不同的指令集指示(.386之类)查表输出timing数的，我在16楼已经说过了。即便“是很老的处理器上的典型数据”这句不确切，“MASM里输出的时钟周期数是死记硬背下来的”这个结论是绝对没有问题的（前面也有证据，你不服气的话，我可以更明确地证明一下）。
而你的说法：timing推测的，而推测的依据居然是所谓“知道了指令存储空间,所用时间可以基本得知”，就荒唐到了离奇的程度。
都不说“推测”说和你所谓的“MASM的指令周期计算算法是最权威的”之间的自相矛盾。
你这种经不起推敲的逻辑直接就可以证伪：
就假设所谓“知道了指令存储空间,所用时间可以基本得知”是真的，那ml怎么“推测呢”？
比如LEA&EAX,[EDX*4+]这条指令，机器码是8D&04&95&00&00&41&00，从386到现在的4核处理器都一样，既然“指令存储空间”是一样的，那么timing数应该一样才对呀？可事实上，使用不同的指令集指示，.386、.486、.586...&输出结果是不一样的。
要推测，那也要有一个合理的、通用的推测方法才可以，象您这样，整出一个“依据指令存储空间推测”的荒唐方法，您是想忽悠别人，还是您其实是个二把刀，却以为自己是大厨？:)
恕我直言，从您几个帖子的表现，经常语无伦次、辞不达意、前言不搭后语（诸如“因为&INEEL团队成员,大部分是深入IBM核心指令设计的”、“相信IMTEL水平没有IBM的高,因为指令设计的电路级是由IBM领先的”），您的思维能力确实不咋地，您应该经常检查一下颈动脉的供血状况，否则您的“创造能力”还会一发不可收拾。:)
引用&27&楼&jxc25&的回复:本电脑使用Intel&Pentium&M&处理器
有关此CPU的技术请参阅http://www.intel.com
1GHz的PentiumM，超低功耗的那种，性能最多也就相当于1.4GHz的Pentium4，勉为其难哪。:)
1GHz的PentiumM，超低功耗的那种，性能最多也就相当于1.4GHz的Pentium4，勉为其难哪。:)&
该回复于 16:04:49被版主删除
每条指令有自己的时钟周期，方括号内的表达式属于寻址方式，不占用计算的时钟周期。各条指令的时钟周期得去查处理器手册，如intel手册。
又见CSDN论战，学到一些东西，谢谢
lea&指令非常快
论战没什么，被指责为“误人”也没有关系，关键是要把事实搞清楚。
所谓“知道了指令存储空间,所用时间可以基本得知”，在一个了解计算机系统结构的人看来，就如同地理学家被告知“大地只是驮在鲤鱼背上的一个圆盘”，两个字评价：荒唐，再加两个字的话，就是：荒唐透顶！
我宁愿相信母猪上树、时光倒流、耶稣复活、外星人到来...，也不可能相信这种指令存储空间能推测执行时间的奇谈怪论。
还可以确信的是，这位“一刀”先生在有生之年也拿不出可以证明“知道了指令存储空间,所用时间可以基本得知”的论文，所谓资料123、xxx刊...，这些名字，还是不必反复贴的为好，名字可以作为证据，那我把全国一二级学术期刊的目录贴上来又当如何。:)
欢迎加入群，.net之家
简单的手册不一定能查到,&在现在的一些CPU中,&都可以并行处理了,&
引用&44&楼&zzz3265&的回复:简单的手册不一定能查到,&在现在的一些CPU中,&都可以并行处理了,&
所以大家没有必要争这些可以从手册上查到的东西，是什么的看什么的手册就好了。
不想参与争论希望能带来答案。
mov&&edx,dword&ptr&[ecx+edx*4+8]&
mov&&eax,dword&ptr&[eax+14h]&
lea&&eax,[eax+edx*8]
目前Inte&and&AMD的商用cpu都是superscaler的结构也就是说一个周期取多条指令以及并行执行和提交多条指令，至于多少条取决于指令的长度还有是否是与16byte对齐，&比如上面某条指令如果在16byte的交界处，执行这条指令至少需要两个取指周期。所以看到一位朋友说与指令长度有关应该是这个意思，也可能还涉及到Length-Changing&Prefixes&(LCP)的问题。另外这还与解码顺序有关比如4-1-1-1规则，还有并行执行的uops数量有关
好回到原先的问题，lea&&eax,[eax+edx*8]&这条指令在decode&之后被拆分成&shl&$3,&%edx,&add&%edx,&%eax&两个uops，所以在理想的情况下（忽略指令地址对齐，解码顺序，指令相关，指令调度...）至少需要2个周期。我喜欢lea主要原因是因为它使代码长度变小，在敏感区域取指令的周期往往对速度有着很大的影响，譬如对我来说少1个取指周期就提高10%的性能。
对自己的内容补充一下
Inte&and&AMD的商用cpu一次取指令为16byte，但是如果是跳转的的目的地址在预测成功的情况下是32byte，与指令个数无关。
1.&lea在P6族的处理器、PentiumM、core架构的处理器上都是1个时钟，在Pentium4上是2个时钟周期。
2.&Pentium有2个译码器、P6有3个，Pentium4只有1个，每时钟能译码指令的数量与此有关，与是否16字节对齐无关。
3.&再告诉你一次：指令执行时间的决定性因素是功能的复杂度，与指令的长度无关。你那“一位朋友”就是你自己吧，他是什么意思你都这么清楚？你看了他写的那些胡说八道了吗？:)
1.&“lea在P6族的处理器、PentiumM、core架构的处理器上都是1个时钟，在Pentium4上是2个时钟周期。“
&&&&a.能否看看你说的资料？lea&&eax,[eax+edx*8],不可能在一个时钟周期内完成，因为shl&$3,&%edx,&add&%edx这两个uops存在RAW冲突。
2.&"Pentium有2个译码器、P6有3个，Pentium4只有1个，每时钟能译码指令的数量与此有关，与是否16字节对齐无关。"
&&&a.&这里是Pentium&Pro,&II&and&III&还有pentium&M的decode&解释,简单的说就是&The&4-1-1&rule，自己找资料看看。
&&&b.&关于core的decode&为&4-1-1-1&rule，具体的你可以到网上找到.
3）“再告诉你一次：指令执行时间的决定性因素是功能的复杂度，与指令的长度无关。你那“一位朋友”就是你自己吧，他是什么意思你都这么清楚？你看了他写的那些胡说八道了吗？:)&“
&&讨论问题不要加入情绪。
“指令执行时间的决定性因素是功能的复杂度，与指令的长度无关“，你的这句话是不对的，如果你有兴趣可以去做实验，用严格的benchmark说话，我可以清楚地给你数据，所以你错的。
4）“你那“一位朋友”就是你自己吧，他是什么意思你都这么清楚？你看了他写的那些胡说八道了吗？:)“&
我就是我，一个工程师，工作在一个芯片公司，已经修改strlen&strcpy&strcmp，memcmp&函数，使他们的性能提高了2倍。
实测的几种指令的时钟周期数在16楼已经给出了。
我给出的“时钟周期”是指等效时钟周期数，即指令在程序中表现出的执行时间（不过已经排除了超标量并行的影响），不是指流水线周期数（注意一般意义上讨论指令的执行时间，诸如intel手册给出的、还有有关汇编优化的书中给出的都是等效时钟周期数，而不是流水线周期数）。
“指令执行时间的决定性因素是功能的复杂度，与指令的长度无关“，你的这句话是不对的，如果你有兴趣可以去做实验，用严格的benchmark说话，我可以清楚地给你数据，所以你错的。
==============================================================
做什么实验？
RISC处理器使用定长指令设计，所有指令都一样长，根本谈不上指令长度与执行时间的关系。
CISC处理器，虽然普遍使用变长指令，但是指令的编码与指令完成的功能之间没有必然的联系，一个复杂功能可能使用短编码（诸如aad、bsr、idiv），而简单功能反而可能编码较长（带地址和/或者立即数）。
用严格的benchmark说话？
好，请你先解释一下我在16楼给出的测试数据（不相信我的数据你也可以自己再测试一下），指令长度和执行时间有什么关系？？？
你不是要“用严格的benchmark说话”吗？
好啊，请你拿出一个x86全部指令（基本ALU指令即可，不必包括FPU、MMX、SSE等等）的指令长度和执行时间的对比，我还就是想看看我是怎么“错的”！
4）“你那“一位朋友”就是你自己吧，他是什么意思你都这么清楚？你看了他写的那些胡说八道了吗？:)“
我就是我，一个工程师，工作在一个芯片公司，已经修改strlen&strcpy&strcmp，memcmp&函数，使他们的性能提高了2倍。
==============================================================
注意你自己说的话“讨论问题不要加入情绪”。
你是谁无关紧要，我也根本不感兴趣。不过象您这样注册之后几个月没登录，今天一上来就直扑到这里，还一开口就是你理解“那个朋友”的意思，一上来就搞出个“你错的”，您以为别人是傻子啊？您的身份就那么无懈可击吗？可以说您不是“那个朋友”本人，也真的是“那个朋友”
的“朋友”。:)
不过，不管你是谁，一句话：你能辩则辩，辩不了就不要口出狂言。
我就要看看你怎么把“那个朋友”的荒唐言论“知道了指令存储空间,所用时间可以基本得知”辩出个花来！你的数据在哪里？？？
至于您那所谓的“已经修改strlen&strcpy&strcmp，memcmp&函数，使他们的性能提高了2倍”，这种东西还是不要拿出来炫耀为好，与这个帖子有关吗？能证明您的言论自然正确？这种简单的函数改一改提高一下性能就值得自鸣得意？
我也不妨发一句狂言：在我面前摆老资格，你还差得远。人还是先要搞清楚自己吃几碗干饭。:)
看不懂，硬着头皮看。
看样子还是有人看的懂俺说的话!
***************************
我也不妨发一句狂言：在我面前摆老资格，你还差得远。人还是先要搞清楚自己吃几碗干饭。:)&
***************************
DelphiGuy&，
烦请你运行如下两种代码，你一定能够发现速度的差异（让他们跳转成功&即r11为&0x1234），他们指令都完全相同，唯一不同的是编译之后代码长度不同。做完之后我们再来讨论你是否能&随随便便的将上面的简单函数提高2被以上。
一个“摆资格的工程师“
&&&&&&&pxor&&&&%xmm0,%xmm0&&&&&&&&&&&&&&&&&&&&&&&&&&pxor&&&&%xmm0,%xmm0&&&&&&&&&&&&&&
&&&&&&&&mov&&&&&%rsi,%rax&&&&&&&&&&&&&&&&&&&&&&&&&&mov&&&&&%esi,%eax&&&&&&&&&&&&&&&&
&&&&&&&&mov&&&&&%rdi,%rax&&&&&&&&&&&&&&&&&&&&&&&&&&mov&&&&&%edi,%eax&&&&&&&&&&&&&&&&
&&&&&&&&and&&&&&$15,%rax&&&&&&&&&&&&&&&&&&&&&&&&&&&and&&&&&$15,%eax&&&&&&&&&&&&&&&&&
&&&&&&&&and&&&&&$15,%rdx&&&&&&&&&&&&&&&&&&&&&&&&&&&and&&&&&$15,%edx&&&&&&&&&&&&&&&&&
&&&&&&&&mov&&&&&%rax,%rcx&&&&&&&&&&&&&&&&&&&&&&&&&mov&&&&&%eax,%ecx&&&&&&&&&&&&&&&&
&&&&&&&&or&&&&&&%rdx,%rcx&&&&&&&&&&&&&&&&&&&&&&&&&or&&&&&&%edx,%ecx&&&&&&&&&&&&&&&&
&&&&&&&&cmp&&&&&$0x1234,%r11&&&&&&&&&&&&&&&&&&&&&&cmp&&&&&$0x1234,%r11d&&&&&&&&&&&&
&&&&&&&&je&&&&&&LABEL(ashr_16_offset_0)&&&&&&&&&&je&&&&&&LABEL(ashr_16_offset_0)
&&&&.p2align&4&//&&&&
LABEL(ashr_16_offset_0):
mov&rcx,&%rax
补充一下，清将代码起始地址设为16byte对齐。
我也补充下:
1&本人很认真地在三台机器(586_266M,PII_800M,以及现用的1,7GCPU),DOS3.0\5.0\6.22\pdos7.0;使用masm3.1,masm5.0,masm6.11;
2&主要验证三个指令lz的,".386\.586\.386P"与默认下的指令周期,堆栈原理(不同CPU,堆栈操作结果不同);
3&结果大家可以试试
发现如俺想证实的
可能又是胡扯了吧!
**************************
DelphiGuy&，
烦请你运行如下两种代码，你一定能够发现速度的差异（让他们跳转成功&即r11为&0x1234），他们指令都完全相同，唯一不同的是编译之后代码长度不同。...
===================================================================================
呵呵呵...还有你这么可笑的人。
还以为你拿出什么独门密技证明“一刀”先生的高论“知道了指令存储空间,所用时间可以基本得知”呢，原来就是这么不着边际的生搬硬套啊。
“指令存储空间”是什么？是每条指令占据的空间大小，不是一段代码的大小！你就这么偷换概念，有意思吗？
再说了，你的两段代码使用不同模式的寄存器，一个使用64位寄存器，一个使用32寄存器，性能能一样那倒是有点巧合了。
我算是搞明白了，你所谓“用严格的benchmark说话，我可以清楚地给你数据，所以你错的”原来就是用“代码越长，执行时间越长”来证明啊？？？
这就算是证明了“知道了指令存储空间,所用时间可以基本得知”？？？
哈哈哈哈哈...
你要搞清楚那位“一刀”先生的结论是对每条指令的timing数说的（见他12楼的发言），不是“一段代码的执行时间”！搞懂了没？糊涂蛋。
你要是明知故辩、偷换概念，那我倒不怪你了，可如果你居然不幸到连基本文字都看不懂的程度，那你还是趁早治疗，耽误别人的时间事小，耽误了自己的健康可是要命的。:)
我也补充下:
1&本人很认真地在三台机器(586_266M,PII_800M,以及现用的1,7GCPU),DOS3.0\5.0\6.22\pdos7.0;使用masm3.1,masm5.0,masm6.11;
2&主要验证三个指令lz的,".386\.586\.386P"与默认下的指令周期,堆栈原理(不同CPU,堆栈操作结果不同);
3&结果大家可以试试
发现如俺想证实的
可能又是胡扯了吧!&
==============================================================
你这人还要不要脸？一而再、再而三地胡说八道，又是这本书、那本书，这文章、那文章，现在又进步了，终于“验证”了？？？
可惜你从来贴不上任何具体的文字引用和测试数据，就摆出一句“发现如俺想证实的”充数。有意思吗？？？不觉得丢人哪？
你要证明你所谓的“知道了指令存储空间,所用时间可以基本得知”，怎么证明？我都不要求你拿出具体的算法和公式，这种定量的计算你到死也搞不出来。
只要求你先定性证明一下：在大多数情况下，指令的执行时间与指令长度成正比。
看样子还是有人看的懂俺说的话!
***************************
我也不妨发一句狂言：在我面前摆老资格，你还差得远。人还是先要搞清楚自己吃几碗干饭。:)
***************************
==================================================
难得呀，才注意到您一贯语无伦次、前言不搭后语的风格也偶有一次语句通顺的时候。
您这“呵呵!无语”用得很好，很恰当！
您显然不可能看不到您的“亲密战友”---几个月不露面，一上来就和您心灵相通，直接扑过来“理解”您的意思的那位---在49楼最后一段的发言，您还能说什么呢？也只能“呵呵!无语”了，您舍不得对他用，转用到我身上，那自然是再恰当不过的了。
无他，我不过在这位“摆资格的工程师”面前摆一面镜子而已。
曾子曰：“吾日三省吾身”，苏格拉底说：“认识你自己”，贤达尚且如此，凡人搞清楚自己吃几碗干饭更不是一件容易的事。
自己照镜子，往往只看到优点甚至能看到并不存在的优点而忘乎所以，被人在不情愿的时候强迫照镜子呢，又痛苦了些。
人，怎一个虚荣了得，奈何！:)
唇枪舌战，好不精彩
来来来，“黄山一刀”老兄，请教过你很多次了，你就是避而不谈，再请教一次：
按照您在12楼的说法，MASM里输出的timing数是“推测的”，而推测的方法是“知道了指令存储空间,所用时间可以基本得知”，这没错吧。
问了好多次，您也拿不出任何理论上的依据证明这个结论，所以也就不问了，想来您在有生之年也拿不出来。
就请教，您怎么“推测”？方法是什么？您能不能现身说法，拿出几个例子来，给大家看看推测的过程？
然后我们再讨论您这“推测”理论能不能成立，是特例，还是普遍成立？
怎么样？:)
不要人身攻击.
lea只要一个时钟周期.
最优化的编译器都会尽量使用Lea指令,不仅仅它短而且快.
乘以32的运算
通常编译器编译的结果是
shl&eax,5&&&&&&;4个时钟周期
而最优化的Intel&C++编译器生成的代码是
lea&&eax,&DWORD&PTR[edx&+&edx]
上面全部指令不超过3个时钟周期&&&&&&&&&&&
lea和Add都是执行快,吞吐量高的指令.
lea和ADD,SUB所使用的执行单元是不同的,当ALUs(算术逻辑单元)繁忙的时候Lea还是可以工作.之际上Lea也提高了指令的并行度
lea不是上面有些人想当然的要拆开成shl什么指令去执行的.
嗯，这个似乎不是最优化。
lea&eax,[edx*8]
lea&eax,[eax*4]
只需要2个时钟周期。
Intel的编译器确实是优化成这个样子
lea&&eax,&DWORD&PTR[edx&+&edx]&
我估计这样的代码是针对Pentium4做的优化，
对其他处理器，还是shl最快，从486以来就是1个时钟周期。
lea&&eax,&DWORD&PTR[edx&+&edx]&
上面这个为什么是3个周期，怎么算的？
另外lea&eax,[edx*32]行不行？&
lea&eax,[edx*8]用一个周期吗？
lea&eax,[edx*8+4]要多少周期？&
两个add是可以并行的，虽然看起来有依赖关系，但是乱序执行功能可以把几个add&eax,eax延迟到与之后的若干指令并行，利用这些指令没有用到某个执行单元来执行，所谓“见逢插针”。
lea&eax,[edx*32]不行，比例乘只支持1、2、4、8。
lea&eax,[edx*8]、lea&eax,[edx*8+4]都是1个时钟周期，486以来都是如此。
看起来有些费解，但是实际情况确实如此。
lea和ADD,SUB所使用的执行单元是不同的,当ALUs(算术逻辑单元)繁忙的时候Lea还是可以工作.之际上Lea也提高了指令的并行度&
lea不是上面有些人想当然的要拆开成shl什么指令去执行的.
----------------------------------------------
好，lea在address-generation&units&(AGUs）中执行的，但是他也一定会使用2个uops运行&就是shl,&add,但并不是在ALU中运行。&因为在&x86(AMD&&&Intel&Pentium4之后)所有in-flight（解码之后）得指令都是1个uops&:-)
是不是说延迟到某条可以和add同时执行的指令时，一条add指令就插进去和它在一个周期完成，直到4条add指令都执行完？
2条add同时执行可以吗？操作数都是eax自己啊。
上面说的所用时钟周期是根据cpu说明书上的说明得出来的吗，还是说我们能实际测出来？
乱序执行并不是说不管前面的指令直接执行后面的指令，这只是一般逻辑上的理解。
实际执行中，不能执行的指令要被暂时挂起放到一个缓冲区中（所谓的reservation&stations），在那里一直等到它的操作数可用为止。
这样多条有依赖关系的指令是可以同时被挂起的，就好象它们并行了一样，而真正的执行是在之后的某个时刻。
社区卫生管理软件
社区卫生信息服务管理系统2008
天使卫生服务管理系统2008
(单机版/完整版/广域版)下载中心:http://www.hhtianshi.com/images/sqwssoft2007.exe
适用于地市级卫生局管理中心；区县级卫生局管理中心；社区卫生服务中心（卫生院）、社区卫生服务站（诊所）
联系人：王先生&联系电话：&&
公司网址:http://www.hhtainshi.com
我来回答你们的问题
所谓指令需要多少时钟周其来运行，可以这样分解
取指令阶段，如果前一条指令导致了内存面面的切换，然后这个页面又不在CPU的缓存中，
哪么会先从内存读入这一页（页的大小具体跟处理器有关)，这段其间流水线是阻塞的，
可能会好费几万个时钟周期,如果你的内存是DDR或SDRAM,然后内存正在刷新中(64ms左右一个刷新周期)，
哪么你得先等8192个时钟左右来等待内存的ready（注意，这个时钟是内存的时钟，一般比处理器时钟慢几倍，由北桥芯片来做)，
如果是SRAM，哪是不用等的，直接读它。
但如果之前内存处于写的状态，哪么有读写切换的时钟要等待(北桥）。
然后在CPU得到总线控制权的情况下，把内存读出并载入到缓存(因为可能有pci之类的设备占用内存总线，使处理器暂时无法得到总线)。
当这个页载入完成，再把指定的指令放到指令译码寄存器中开始译码，（很好，一切很顺利）
然后指令过长，或者因为是cisc的变长指令系统，可能当前的指令和操作数没法全部取得装入到内部指令译码寄存器，哪就打一拍从缓存中读入下一条指令
好，现在可以执行了，如果是加减操作，一个时钟可以完成，乘除操作的话就比较麻烦有协处理器的话应该也可以,协处理器要工作在比处理器高得多的频率下,或者在流水线的开始就把所有可能的寄存器开始做运算，然后在具体指令执行时选择适当的结果。如果是一条跳转指令，然后跳转条件为真，而且是一个长跳转，哪就麻烦大了（短跳转也存在流水线的问题，但是通过n项指令自动预测之类的，基本会好很多），流水线得全部停掉，以前预取的指令要全部无效掉。然后等待n周期，流水线也恢复后,才能继续执行.
如果要是mov指令，然后指令后面的寻址有寄存器的乘法操作,应该会在第一个时钟计算数据地址,第二个时钟才能把这条指令完成
所以具体某条指令运行多少时钟，跟指令长度有点关系（因为是变长指令系统，不能知道是否当前指令是否已完全在指令译码寄存器中，和指令的位置。但关系不大，因为可能intel的指令译码寄存器很长）
大多数情况下，基本的指令都能在1个时钟完成，而且缓存很大，所以命中率比较高，换页比较少，所以因为涉及到很多问题，不要讨论这些无谓的事情了吧
引用&3&楼&jennyvenus&的回复:指令周期在不同的cpu上都有差别，即使是同一个型号的不同cpu之间也应该有差别，不同型号的cpu必然有差别，俺上学时看过一本书，讲的是代码极端速度优化的，开始时就指明了不要全信资料上说的，我还照着做了几个实验，果然是那样。
不同意。指令周期是指完成一条指令所需要的时钟周期数，不存在半个周期的指令。
流水线的影响是多条不使用相同部条的指令可以同时被处理。
如果要得到精确的CPU时间，你应该在单任务系统上测试。去除其它中止影响sti后测试.
使用相同型号的CPU，你能每次都得到近似的值，当然你必须使用一样的主板和内存，访问内存的周期不由CPU决定
特定8086架构上，指定一种CPU上，指令周期是和功能性复杂度相关联的，依据为常识逻辑的直白推论。赞一个
不同cpu设计,确定指令格式(如RISC),则知道指令存储空间,指令周期基本可知。储存空间说的不对，空间不仅仅是储存空间的。而和时间对应的却是空间，而非储存空间。
设计cpu默认的一定把空间和时间对应起来。前楼有提及按照霍夫曼编码优化指令的，就是依据这种说法，指令的空间和时间对应着处理的。但时间却也不仅仅是指令周期。
不懂汇编,但个人觉得
指令周期和cpu无直接关系,而只和
指令集及编译器有关,
当然,如果cpu不支持此指令集就和cpu有关了
口水战开始了,斑猪就给推荐,嗯,和谐
我建议：你们门外单挑去
自己测试一下么。。。。看看你的电脑上的测试和这里的朋友们说的有什么差别么
二位不要吵了。
我觉的黄山一刀兄弟说的没有什么错。
只是语言表达上，有空可钻而已。
饶了他吧！
菜鸟，在学习中&
建立一个群，欢迎高手、菜鸟，一起来学习，一起讨论，一起进步&
新群，人员还不多
引用&80&楼&dqlihb&的回复:不懂汇编,但个人觉得
指令周期和cpu无直接关系,而只和
指令集及编译器有关,
当然,如果cpu不支持此指令集就和cpu有关了
指令周期和CPU是有关的。不同架构的处理器指令周期是不一样的。比如i386，多少年来一直都是它，但是时钟周期是在不断的变化的。以前在CSDN看过一条各指令的时钟周期，忘了在哪儿看的了。回头再找找
什么呀，两位大侠炒的这么凶，可楼主的问题还没说啊。我很想知道答案。
这个楼主没道理,人家认真回答了,他又扯到礼貌上去了,同学们不要学这样的人
来观望，大量学习
具体看微指令的设计了，我们是不知道的，只能看芯片的手册了
看不懂，标记一下，磨刀后再来学习
此贴如此精彩，顶了
回复}