英特爾DRNG給只給4字節的數據而不是8

Question

我想在C++中實現Intel DRNG。

根據它的引導，以產生64位無符號長長的代碼應該是：

int rdrand64_step (unsigned long long *rand) 
{ 
    unsigned char ok; 
    asm volatile ("rdrand %0; setc %1" 
        : "=r" (*rand), "=qm" (ok)); 
    return (int) ok; 
} 

然而該函數rand的輸出僅給我只有32位的輸出，如圖所示。

 bd4a749d 
     d461c2a8 
     8f666eee 
     d1d5bcc4 
     c6f4a412 

爲什麼會出現這種情況？

更多信息：我使用的IDE是代碼塊

Answer 1

從immintrin.h，而不需要編寫內聯彙編使用int _rdrand64_step (unsigned __int64* val)。你不需要它，有很多原因（包括本），以避免它：https://gcc.gnu.org/wiki/DontUseInlineAsm

---

在這種情況下，問題是，你可能編譯32位代碼，所以當然64位rdrand是不可編碼的。但是你使用inline-asm的方式最終會給你一個32位的rdrand，並在另一個寄存器中存儲垃圾。

gcc -Wall -O3 -m32 -march=ivybridge（和鐺類似）產生（on Godbolt）：

In function 'rdrand64_step': 
7 : <source>:7:1: warning: unsupported size for integer register 

rdrand64_step: 
    push ebx 
    rdrand ecx; setc al 
    mov  edx, DWORD PTR [esp+8] # load the pointer arg 
    movzx eax, al 
    mov  DWORD PTR [edx], ecx 
    mov  DWORD PTR [edx+4], ebx # store garbage in the high half of *rand 
    pop  ebx 
    ret 

我猜你叫與碰巧有ebx=0呼叫者此功能。否則你使用了一個不同的編譯器來做一些不同的事情。內聯後可能會發生其他事情。如果你看看反彙編你實際編譯的內容，你可以解釋到底發生了什麼。

---

如果你使用的內在，你會得到error: '_rdrand64_step' was not declared in this scope，因爲只有immintrin.h宣佈它在64位模式（並與-march設置，意味着rdrand支持。或者[-mrdrnd] 3。最佳選項：使用-march=native如果您正在目標機器上構建）。

您也會得到顯著更有效的代碼爲重試循環，至少鏗鏘：

unsigned long long use_intrinsic(void) { 
    unsigned long long rand; 
    while(!_rdrand64_step(&rand)); // TODO: retry limit in case RNG is broken. 
    return rand; 
} 

use_intrinsic:       # @use_intrinsic 
.LBB2_1:        # =>This Inner Loop Header: Depth=1 
    rdrand rax 
    jae  .LBB2_1 
    ret 

這避免了setcc，然後測試的是，這當然是多餘的。 gcc6具有用於從內聯asm返回標誌結果的語法。您也可以使用asm goto並在asm中放置一個jcc，跳轉到label: return 1;目標或落入return 0。 （。內聯彙編文檔有這樣https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html的例子也the inline-assembly tag wiki見）

使用您的內聯彙編，鐺（在64位模式），它編譯於：

use_asm: 
.LBB1_1: 
    rdrand rax 
    setb byte ptr [rsp - 1] 
    cmp  byte ptr [rsp - 1], 0 
    je  .LBB1_1 
    ret 

（鏗鏘對包含內存在內的多個選項的約束做出錯誤的決定。）

gcc7.2和ICC17實際上最終得到了比asm更好的代碼。他們使用cmovc得到0或1，然後test。這很愚蠢。但這是一個gcc/ICC未能優化，希望是。