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

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

我在尝试使用 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; 您仍然可以将其作为 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 内在函数。）

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

因此，在任何假设的未来 C++ 实现中，静默数据损坏/截断的可能性为零。 ISO C++ 保证 unsigned long long 至少 64 位类型。 （实际上是通过值范围指定它，并且它的值位是纯二进制的无符号，但相同的区别。）

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