最近的 Intel CPU 的前端包含一个复杂的解码器和许多简单的解码器。复杂解码器可以处理解码为多个微操作的指令，而简单解码器仅支持解码为单个(融合域)微操作的指令。
是否所有 1-µop 指令都可以由简单解码器解码，或者是否存在只能由复杂解码器处理的 1-µop 指令？
最佳答案
不，有些指令只能解码 1/clock
Andreas 的评论表明 xor eax,eax/setnle al似乎有一个 1/clock 的解码瓶颈。我发现与 cdq 相同的事情: 读取 EAX，写入 EDX，从 DSB(uop 缓存)中运行得更快，并且不涉及部分寄存器或任何奇怪的东西，并且不需要破坏 dep 的指令。
更好的是，作为单字节指令，它只需一小段指令就可以击败 DSB。 (导致在某些 CPU 上的测试结果产生误导，例如在 Agner Fog 的表和 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 Lake 测试使用足够小的展开计数 (10) 进行测试，不会破坏 DSB，发现吞吐量为 0.6。 (考虑到循环开销后，实际吞吐量为 0.5，完全可以通过与 cqo 相同的后端端口压力来解释。IDK 为什么您会发现 0.6 而不是 0.55，而循环中 p6 只有一个额外的 uop。)
(Zen 可以以 0.25c 的吞吐量运行此指令；没有奇怪的解码问题，并且由每个整数 ALU 端口处理。)times 10 cdq在 dec/jnz 循环中可以从 uop 缓存运行，并在 Skylake (p06) 上以 0.5c 的吞吐量运行，加上循环开销也会竞争 p6。times 20 cdq对于一个 32 字节的机器代码块，超过 3 个 uop 缓存行，这意味着循环只能从旧版解码运行(循环顶部对齐)。在 Skylake 上，每个 cdq 运行 1 个周期。 .性能计数器确认 MITE 每个周期提供 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)
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
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
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
只有 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上的端口压力)，而不是前端。
关于x86 - 最近英特尔微架构中的简单解码器可以处理所有 1-µop 指令吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61980149/