x86-64 ABI のポインタに 32 ビット オフセットを追加する場合、符号またはゼロ拡張は必要ですか? 質問する

はい、引数または戻り値レジスタの上位 32 ビットにはゴミが含まれていると想定する必要があります。逆に、呼び出しまたは戻り値を返すときに、上位 32 ビットにゴミを残すことは許可されています。つまり、上位ビットを無視する負担は受信側にあり、上位ビットをクリーンアップする負担は渡す側にあるわけではありません。

64ビットの実効アドレスの値を使用するには、64ビットに符号またはゼロ拡張する必要があります。x32ABIgcc は、配列インデックスとして使用される潜在的に負の整数を変更するすべての命令に対して、64 ビットのオペランド サイズを使用する代わりに、32 ビットの実効アドレスを頻繁に使用します。

標準：

のx86-64 システム V ABI_Boolレジスタのどの部分がゼロにされるか（つまり）についてのみ言及していますbool。20 ページ:

型の値_Boolがレジスタまたはスタックに返されるか渡される場合、ビット 0 には真理値が含まれ、ビット 1 から 7 はゼロになります (脚注 14: 他のビットは未指定のままであるため、それらの値のコンシューマー側は、8 ビットに切り捨てられたときに 0 または 1 になることを信頼できます)

%alまた、全体ではなく、可変引数関数の FP レジスタ引数の数を保持することについても%rax。

そこにはgithub の問題を開くこの質問についてx32 および x86-64 ABI ドキュメントの github ページ。

ABI は、引数や戻り値を保持する整数レジスタやベクトル レジスタの上位部分の内容にそれ以上の要件や保証を課していないため、要件や保証はありません。この事実は、Michael Matz (ABI のメンテナーの 1 人) からの電子メールで確認されています。「一般に、ABI で何かが指定されていないと、それを信頼することはできません。」

彼はまた、例えばclang >= 3.6 では、addps高位要素のゴミによって速度が低下したり、余分な FP 例外が発生する可能性がある がバグとして使用されています。（そういえば、報告すべきだった）。彼は、AMDのglibc数学関数の実装でこの問題が一度あったと付け加えた。通常のCコードできるdoubleスカラーまたは引数を渡すときに、ベクトル regs の上位要素にゴミを残しますfloat。

標準では（まだ）文書化されていない実際の動作:

狭い関数の引数、たとえ_Bool/であってもbool、32ビットに符号またはゼロ拡張されます。clangは、この動作に依存するコードも作成します。（どうやら2007年から）. ICC17それをしない、 それでICCとclangはABI互換ではないC の場合でも、最初の 6 つの整数引数のいずれかが 32 ビットより狭い場合は、x86-64 SysV ABI の ICC コンパイル コードから clang コンパイル関数を呼び出さないでください。

これは戻り値には適用されず、引数にのみ適用されます。gcc と clang はどちらも、受け取る戻り値にはその型の幅までの有効なデータのみが含まれると想定しています。たとえば、 gcc は を返す関数を作成しchar、 の上位 24 ビットにゴミを残します。%eax

あABIディスカッショングループの最近のスレッド8 ビットおよび 16 ビットの引数を 32 ビットに拡張するためのルールを明確にし、実際にこれを要求するように ABI を変更するという提案でした。主要なコンパイラ (ICC を除く) はすでにこれを行っていますが、呼び出し元と呼び出し先の間の契約が変更されることになります。

ここに例があります（他のコンパイラで確認するか、コードを微調整してください）Godboltコンパイラエクスプローラーここでは、パズルの 1 つのピースだけを示す単純な例を多数含めましたが、これは多くのことを示す例でもあります):

extern short fshort(short a);
extern unsigned fuint(unsigned int a);

extern unsigned short array_us[];
unsigned short lookupu(unsigned short a) {
  unsigned int a_int = a + 1234;
  a_int += fshort(a);                 // NOTE: not the same calls as the signed lookup
  return array_us[a + fuint(a_int)];
}

# clang-3.8 -O3  for x86-64.    arg in %rdi.  (Actually in %di, zero-extended to %edi by our caller)
lookupu(unsigned short):
    pushq   %rbx                      # save a call-preserved reg for out own use.  (Also aligns the stack for another call)
    movl    %edi, %ebx                # If we didn't assume our arg was already zero-extended, this would be a movzwl (aka movzx)
    movswl  %bx, %edi                 # sign-extend to call a function that takes signed short instead of unsigned short.
    callq   fshort(short)
    cwtl                              # Don't trust the upper bits of the return value.  (This is cdqe, Intel syntax.  eax = sign_extend(ax))
    leal    1234(%rbx,%rax), %edi     # this is the point where we'd get a wrong answer if our arg wasn't zero-extended.  gcc doesn't assume this, but clang does.
    callq   fuint(unsigned int)
    addl    %ebx, %eax                # zero-extends eax to 64bits
    movzwl  array_us(%rax,%rax), %eax # This zero-extension (instead of just writing ax) is *not* for correctness, just for performance: avoid partial-register slowdowns if the caller reads eax
    popq    %rbx
    retq