为什么 TZCNT 适用于我的 Sandy Bridge 处理器？

Question

我正在运行属于 Sandy Bridge 微架构的 Core i7 3930k。 执行以下代码时（在MSVC19、VS2015下编译），结果让我吃惊（见cmets）：

int wmain(int argc, wchar_t* argv[])
{
    uint64_t r = 0b1110'0000'0000'0000ULL;
    uint64_t tzcnt = _tzcnt_u64(r);
    cout << tzcnt << endl; // prints 13

    int info[4]{};
    __cpuidex(info, 7, 0);
    int ebx = info[1];
    cout << bitset<32>(ebx) << endl; // prints 32 zeros (including the bmi1 bit)

    return 0;
}

反汇编表明tzcnt指令确实是从内在发出的：

    uint64_t r = 0b1110'0000'0000'0000ULL;
00007FF64B44877F 48 C7 45 08 00 E0 00 00 mov         qword ptr [r],0E000h  
    uint64_t tzcnt = _tzcnt_u64(r);
00007FF64B448787 F3 48 0F BC 45 08    tzcnt       rax,qword ptr [r]  
00007FF64B44878D 48 89 45 28          mov         qword ptr [tzcnt],rax  

为什么我没有收到#UD 无效操作码异常，指令运行正常，CPU 报告它不支持上述指令？

这可能是一些奇怪的微代码修订版，其中包含指令的实现但不报告对它的支持（以及 bmi1 中包含的其他内容）？

我还没有检查过bmi1 的其余说明，但我想知道这种现象有多普遍。

Answer 1

Sandy Bridge（和更早的）处理器似乎支持lzcnt 和tzcnt 的原因是这两个指令都具有向后兼容的编码。

lzcnt eax,eax  = rep bsr eax,eax
tzcnt eax,eax  = rep bsf eax,eax

在较旧的处理器上，rep 前缀会被忽略。

好消息就这么多。
坏消息是两个版本的语义不同。

lzcnt eax,zero => eax = 32, CF=1, ZF=0  
bsr eax,zero   => eax = undefined, ZF=1
lzcnt eax,0xFFFFFFFF => eax=0, CF=0, ZF=1   //dest=number of msb leading zeros
bsr eax,0xFFFFFFFF => eax=31, ZF=0        //dest = bit index of highest set bit


tzcnt eax,zero => eax = 32, CF=1, ZF=0
bsf eax,zero   => eax = undefined, ZF=1
tzcnt eax,0xFFFFFFFF => eax=0, CF=0, ZF=1   //dest=number of lsb trailing zeros
bsf eax,0xFFFFFFFF => eax=0, ZF=0        //dest = bit index of lowest set bit

至少 bsf 和 tzcnt 在源 0 时生成相同的输出。bsr 和 lzcnt 不同意这一点。
此外，lzcnt 和 tzcnt 的执行速度也比 bsr/bsf 快得多。
bsf 和 tzcnt 不能就标志的使用达成一致，这完全糟透了。 这种不必要的不​​一致意味着我不能使用tzcnt 作为bsf 的替代品，除非我可以确定它的来源是非零的。