最近英特尔微体系结构中的简单解码器能处理所有的1-操作指令吗？

Question

最近英特尔CPU的前端包含一个复杂的解码器和一些简单的解码器。复杂解码器可以处理解码到多个操作的指令，而简单解码器只支持对单个(融合域)op进行解码的指令。

所有的1-运算指令都能被简单的译码器解码，还是只有复杂的译码器才能处理1-运算指令？

Answer 1

不，有些指令只能解码1/钟。

Andreas的评论表明，xor eax,eax / setnle al似乎有一个解码瓶颈1/时钟。我在cdq中也发现了同样的东西:读取EAX，编写EDX，从DSB (uop缓存)明显运行得更快，并且不涉及部分寄存器或任何奇怪的东西，并且不需要中断指令。

更好的是，作为一个单字节指令，它只需要一个短的指令块就可以击败DSB。(导致在某些CPU上测试的误导性结果，例如在Agner的表中和在https://uops.info/上，例如SKX显示为1c吞吐量。)由于不同的测试方法，https://www.uops.info/html-tp/SKX/CDQ-Measurements.html与https://www.uops.info/html-tp/CFL/CDQ-Measurements.html的吞吐量不一致:只有Coffee测试使用足够小的未滚动计数(10)进行测试，以不超过DSB，发现吞吐量为0.6。(在考虑循环开销后，实际吞吐量为0.5，完全由后端端口压力与cqo相同来解释。为什么在循环中只为p6找到一个额外的uop，而不是0.55 )。

(Zen可以以0.25c吞吐量运行这些指令；没有奇怪的解码问题，并且由每个整数-ALU端口处理。)

dec/jnz循环中的times 10 cdq可以从uop缓存中运行，并且在Skylake (p06)上以0.5c的吞吐量运行，加上循环开销，这也是p6的竞争对手。

对于一个32字节的机器代码块，times 20 cdq是3行以上的uop缓存行，这意味着循环只能从遗留解码(循环顶部对齐)运行。在Skylake上，每个cdq运行一个周期。Perf计数器确认螨每周期提供1 uop，而不是3或4组之间的空闲周期。

default rel
%ifdef __YASM_VER__
    CPU Skylake AMD
%else
%use smartalign
alignmode p6, 64
%endif

global _start
_start:
    mov  ebp, 1000000000

align 64
.loop:
    ;times 10 cdq   ; 0.5c throughput
    ;times 20 cdq   ; 1c throughput, 1 MITE uop per cycle front-end

    ; times 10 cqo        ; 0.5c throughput 2-byte insn fits uop cache
    ; times 10 cdqe       ; 1c throughput data dependency
    ;times 10 cld         ; ~4c throughput, 3 uops

    dec ebp
    jnz .loop
.end:

    xor edi,edi
    mov eax,231   ; __NR_exit_group  from /usr/include/asm/unistd_64.h
    syscall       ; sys_exit_group(0)

在我的Arch Linux桌面上，我将其构建到一个静态可执行文件中，以便在perf下运行：

3.9GHz)

• microcode
• i7-6700k与epp=balance_performance (max "turbo“=
• 0xd6 )(因此LSD禁用，这并不重要:循环只能在DSB循环缓冲区中运行，如果它们的uop都在IIRC.DSB uop缓存中)

。

     in a bash shell:
t=cdq-latency; nasm -f elf64 "$t".asm && ld -o "$t" "$t.o" && objdump -drwC -Mintel "$t" && taskset -c 3 perf stat --all-user -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,uops_issued.any,frontend_retired.dsb_miss,idq.dsb_uops,idq.mite_uops,idq.mite_cycles,idq_uops_not_delivered.core,idq_uops_not_delivered.cycles_fe_was_ok,idq.all_mite_cycles_4_uops ./"$t"

拆解

0000000000401000 <_start>:
  401000:       bd 00 ca 9a 3b          mov    ebp,0x3b9aca00
  401005:       0f 1f 84 00 00 00 00 00         nop    DWORD PTR [rax+rax*1+0x0]
...
  40103d:       0f 1f 00                nop    DWORD PTR [rax]

0000000000401040 <_start.loop>:
  401040:       99                      cdq    
  401041:       99                      cdq    
  401042:       99                      cdq    
  401043:       99                      cdq    
...
  401052:       99                      cdq    
  401053:       99                      cdq             # 20 total CDQ
  401054:       ff cd                   dec    ebp
  401056:       75 e8                   jne    401040 <_start.loop>

0000000000401058 <_start.end>:
  401058:       31 ff                   xor    edi,edi
  40105a:       b8 e7 00 00 00          mov    eax,0xe7
  40105f:       0f 05                   syscall 

Perf的结果：

 Performance counter stats for './cdq-latency':

          5,205.44 msec task-clock                #    1.000 CPUs utilized          
                 0      context-switches          #    0.000 K/sec                  
                 0      cpu-migrations            #    0.000 K/sec                  
                 1      page-faults               #    0.000 K/sec                  
    20,124,711,776      cycles                    #    3.866 GHz                      (49.88%)
    22,015,118,295      instructions              #    1.09  insn per cycle           (59.91%)
    21,004,212,389      uops_issued.any           # 4035.049 M/sec                    (59.97%)
     1,005,872,141      frontend_retired.dsb_miss #  193.235 M/sec                    (60.03%)
                 0      idq.dsb_uops              #    0.000 K/sec                    (60.08%)
    20,997,157,414      idq.mite_uops             # 4033.694 M/sec                    (60.12%)
    19,996,447,738      idq.mite_cycles           # 3841.451 M/sec                    (40.03%)
    59,048,559,790      idq_uops_not_delivered.core # 11343.621 M/sec                   (39.97%)
       112,956,733      idq_uops_not_delivered.cycles_fe_was_ok #   21.700 M/sec                    (39.92%)
           209,490      idq.all_mite_cycles_4_uops #    0.040 M/sec                    (39.88%)

       5.206491348 seconds time elapsed

因此循环开销(dec/jnz)基本上是免费的，与最后一个cdq在同一个周期内解码。计数并不准确，因为我在一次运行中使用了太多的事件(启用了HT )，所以perf进行了软件复用。从另一个计数器较少的运行：

# same source, only these HW counters enabled to avoid multiplexing
          5,161.14 msec task-clock                #    1.000 CPUs utilized          

    20,107,065,550      cycles                    #    3.896 GHz                    
    20,000,134,955      idq.mite_cycles           # 3875.142 M/sec                  
    59,050,860,720      idq_uops_not_delivered.core # 11441.447 M/sec                 
        95,968,317      idq_uops_not_delivered.cycles_fe_was_ok #   18.594 M/sec                  

因此，我们可以看到，螨(遗留解码)基本上是活跃的每一个周期，而前端基本上从来没有"ok“。(即从不停止在后端)。

只有10个CDQ指令，允许DSB工作。

...
0000000000401040 <_start.loop>:
  401040:       99                      cdq    
  401041:       99                      cdq    
...
  401049:       99                      cdq        # 10 total CDQ insns
  40104a:       ff cd                   dec    ebp
  40104c:       75 f2                   jne    401040 <_start.loop>

 Performance counter stats for './cdq-latency' (4 runs):

          1,417.38 msec task-clock                #    1.000 CPUs utilized            ( +-  0.03% )
                 0      context-switches          #    0.000 K/sec                  
                 0      cpu-migrations            #    0.000 K/sec                  
                 1      page-faults               #    0.001 K/sec                  
     5,511,283,047      cycles                    #    3.888 GHz                      ( +-  0.03% )  (49.83%)
    11,997,247,694      instructions              #    2.18  insn per cycle           ( +-  0.00% )  (59.99%)
    10,999,182,841      uops_issued.any           # 7760.224 M/sec                    ( +-  0.00% )  (60.17%)
           197,753      frontend_retired.dsb_miss #    0.140 M/sec                    ( +- 13.62% )  (60.21%)
    10,988,958,908      idq.dsb_uops              # 7753.010 M/sec                    ( +-  0.03% )  (60.21%)
        10,234,859      idq.mite_uops             #    7.221 M/sec                    ( +- 27.43% )  (60.21%)
         8,114,909      idq.mite_cycles           #    5.725 M/sec                    ( +- 26.11% )  (39.83%)
        40,588,332      idq_uops_not_delivered.core #   28.636 M/sec                    ( +- 21.83% )  (39.79%)
     5,502,581,002      idq_uops_not_delivered.cycles_fe_was_ok # 3882.221 M/sec                    ( +-  0.01% )  (39.79%)
            56,223      idq.all_mite_cycles_4_uops #    0.040 M/sec                    ( +-  3.32% )  (39.79%)

          1.417599 +- 0.000489 seconds time elapsed  ( +-  0.03% )

正如idq_uops_not_delivered.cycles_fe_was_ok所报告的，基本上所有未使用的前端uop槽都是后端的错误( p0 /p6的端口压力)，而不是前端。