不能将 uint64_t 与 rdrand 一起使用，因为它需要 unsigned long long，但 uint64_t 被定义为 unsigned long

Posted 2023-02-16

【中文标题】不能将 uint64_t 与 rdrand 一起使用，因为它需要 unsigned long long，但 uint64_t 被定义为 unsigned long

【英文标题】：Can't use uint64_t with rdrand as it expects unsigned long long, but uint64_t is defined as unsigned long

【发布时间】：2021-03-14 03:11:27

【问题描述】：

我在尝试使用 rdrand 内在函数时遇到了以下烦恼。

在我当前的编译器中，unsigned long 和 unsigned long long 都是 64 位的。然而，uint64_t 被定义为unsigned long，而_rdrand64_step 需要一个指向unsigned long long 的指针。

在英特尔的网站上，该函数被定义为int _rdrand64_step (unsigned __int64* val)。如何以便携的方式处理这个问题？

 #include <immintrin.h>
 #include <stdint.h>

 uint64_t example_rdrand64()
 
     uint64_t n;
     _rdrand64_step(&n);
     return n;
 

clang 11.0 -march=ivybridge -O2 (https://godbolt.org/z/55sjsG)：

error: no matching function for call to '_rdrand64_step'
note: candidate function not viable: no known conversion
from 'unsigned int *' to 'unsigned long long *' for 1st argument
_rdrand64_step(unsigned long long *__p)

【问题讨论】：

使用unsigned long long n;有什么问题？这会失败_rdrand64_step (unsigned __int64* val)吗？

@chux-ReinstateMonica 我担心的是，由于英特尔用__int64 定义了内在函数，可能会有一个编译器（或未来的编译器）用unsigned long 定义内在函数，如果我使用unsigned long long。

【参考方案1】：

使用unsigned long long n;您仍然可以将其返回为uint64_t。

它works fine on the Godbolt compiler explorer 包含所有 4 个主要 x86 编译器（GCC、clang、ICC、MSVC）的当前版本。请注意，_rdrand64_step 仅适用于 x86-64 C++ 实现，因此限制了可移植性问题的范围很多。

所有 4 个主流 x86 编译器都将 _rdrand64_step 定义为与 unsigned long long 兼容的类型，因此在这种情况下，只需遵循 clang 的标头即可。

不幸的是（或不是），gcc/clang 的 immintrin.h 实际上并没有定义一个 __int64 类型来匹配 Intel 的内在文档，否则你可以使用它。 ICC 和 MSVC 确实让您实际使用 unsigned __int64 n。 (https://godbolt.org/z/v4xnc5)

---

immintrin.h 完全可用意味着a lot of other things 关于编译器环境和类型宽度，并且未来的某些 x86-64 C 实现极不可能（但并非不可能）使unsigned long long 成为除 qword 之外的任何东西（ uint64_t)。

虽然如果他们这样做了，也许他们只是将英特尔的__int64 映射到不同的类型，因为英特尔的文档从不使用long 或long long，只是__int64，例如AVX2_mm256_maskload_epi64(__int64 const* mem_addr, __m256i mask)。 （甚至 __m128i* 用于 movq 负载内在：__m128i _mm_loadl_epi64 (__m128i const* mem_addr). 很久以后，引入了一个更理智的 __m128i _mm_loadu_si64 (void const* mem_addr)（以及 AVX512 内在函数。）

但是，带有unsigned long long 的 C++ 实现不完全是 64 位可能会破坏一些内在代码，所以这不是您需要花任何时间真正担心的问题。在 this 实例中，如果它更宽，那仍然可以。您只需返回它的低 64 位，_rdrand64_step(&n); 将结果放在其中。 （或者，如果 C++ 实现具有内在的 unsigned long 或者它们定义 uint64_t 而不是 unsigned long long，则会出现编译错误。

因此，在任何假设的未来 C++ 实现中，静默数据损坏/截断的可能性为零。 ISO C++ 保证 unsigned long long至少为 64-位类型。 （实际上是通过value-range指定的，无符号表示它的value位是普通二进制，但是一样的区别。）

您不需要移植到 DeathStation 9000，只需要移植到任何人可能真正想要使用的任何假设的未来编译器，这几乎意味着它希望与现有的 Intel 内在代码库兼容，如果它提供的话内在函数的风格。 （而不是使用不同的名称和类型从头开始重新设计，在这种情况下，您必须更改此函数中的 2 行才能使其正常工作。）

【讨论】：

无论内在函数在做什么，_rdrand_step 和相关函数最终都源自我为首先在第一个测试芯片上执行 RdRand 指令而编写的库。该库的当前版本使用 stdint 并且在这里：github.com/dj-on-github/rdrand_stdint。您可能会发现这些函数很熟悉，我发现它们比内在函数更麻烦。

@DavidJohnston：int _rdrand64_step (unsigned __int64* val) 是具有 64 位操作数大小的 rdrand instruction 的内在函数。 （它的 asm 手册条目确实列出了 _rdrand64_step ）。它应该始终扩展为恰好一条rdrand 指令，CF 结果作为返回值，输出寄存器作为按引用操作数。我假设内在名称包含“步骤”以提醒用户他们需要在 dowhile() 或类似方法中检查 bool-as-int 返回值。 （大概这是您的想法，他们使用了您的库中的名称。）

作为内在函数，编译器可以直接在 CF 结果上进行分支，而不是像您的库使用 inline-asm 那样在 GP 整数寄存器中将其具体化为实际的 int。不过，感谢您链接您的库，这对重试功能很有用。

【参考方案2】：

我是 RdRand 和 RdSeed 背后的 RNG 的设计师。我使用自己的库，而不是内在函数，因为它们总是给我带来问题。图书馆在这里：https://github.com/dj-on-github/rdrand_stdint