本、Art of Assemblyから、私はこの引用をコピーします：
2の補数システムでは、数値のHOビットは符号ビットです。HOビットがゼロの場合、数値は正です。HOビットが1の場合、数値は負になります。例：
16ビット数の場合：
8000hHOビットが1であるため、負になります。
100hHOビットがゼロであるため、は正です。
7FFFh正です。
0FFFFh負です。
0FFFh正です。
最後の2つの例がわかりません。2つの例をバイナリに変換する0000 1111 1111 1111 1111と、最初の例と0000 1111 1111 11112番目の例が得られます。前者がネガティブで後者がポジティブなのはなぜですか？両方の最上位ビットは0であるため、両方が正である必要があるように思われます。
0FFFFHの先行0の理由は、Fが数値の一部であるというヒントをアセンバー/コンパイラーに与えるためです。すべてのアセンブラがこれを必要とするわけではありません。
したがって、負の数は実際にはFFFFhであるため、1111 111111111111は負になります。
テキストには次のように書かれています：16ビットの数字。したがって、右から16番目のビットを確認する必要があります。0FFFFでは、これは1になります。先行ゼロに関しては、値が単語ではなく（つまり変数ではない）数値であるという表記上のヒントです。
有効な数値は数字でのみ開始できるという規則を確立すると、パーサー（アセンブラーを含む）は数値リテラルをより簡単に解析できます。人間もそうです。DEADBEEFは有効な16進数です。
0FFFFが5桁である理由を説明できますか？FFFFと同じですか
それは同じではありません。単純なFFFFhは、アセンブラによってシンボルとして解釈されます。また、「FFFFh」という名前のシンボルが見つからないため、コンパイルエラーが発生します。その前に0を付けると、アセンブラーはそれを数値として解釈します。
数値が16ビットである必要がある場合、16番目のビットが符号ビットと見なされます。最初に、
0FFFFh
16番目のビットはそのまま1です
0000 1111 1111 1111 1111
2番目の例では、
0FFFh
16番目のビットはそのまま0です
0000 1111 1111 1111
16番目のビットは0ですが、16桁を超えていますが、binaryは最初の16桁のみを考慮します。したがって、最初の値は負で、2番目の値は正です。