From: anton@nospicedham.mips.complang.tuwien.ac.at   
      
   "James Van Buskirk"  writes:   
   >Looking at your code more carefully, it seems to consist of three   
   >blocks like:   
   >   
   >mov rax, rdi   
   >and rax, [mem]   
   >mul [mem]   
   >sub rdi, rdx   
   >   
   >There is a fourth block in there, but since it doesn't write rdi,   
   >it doesn't contribute to overall latency.   
      
   Actually, from what I see, the result of the whole sequence is not   
   used at all.  This means that the initiation interval of the   
   surrounding loop is not determined by the latency of bcd2bin, but by   
   resource constraints.  If the OP wants to measure latency, he/she   
   needs to make the input of bcd2bin repend on the result of the   
   previous invocation, maybe by using   
      
   add rdi,    
      
   instead of the "mov rdi, 0x123...."   
      
   >4*3 = 12 clock cycles might be believable if the MOV   
   >instruction could be handled by register renaming and   
   >the latency on rdx in the MUL instruction were only 2 clock   
   >cycles.   
      
   Nehalem does not have 0-cycle MOVs yet (came with Sandy Bridge IIRC),   
   and on a later Intel CPU (Haswell or Skylake) I found 6 cycles of   
   latency for the rdx result (4 for the rax result).  Nehalem is   
   probably similar.   
      
   - anton   
   --   
   M. Anton Ertl                    Some things have to be seen to be believed   
   anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen   
   http://www.complang.tuwien.ac.at/anton/home.html   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)