2の補数計算機 — 符号付き整数エンコーディング変換

早わかり回答

2の補数とは？

// -5 as an 8-bit byte, three ways to arrive at the same pattern
0b00000101        // 5
~0b00000101       // 11111010  ones' complement of 5
~0b00000101 + 1   // 11111011  two's complement = -5

// In JavaScript the width matters: bitwise operators are 32-bit,
// so anything wider has to go through BigInt.
BigInt.asIntN(8, 0xFBn)                 // -5n
BigInt.asUintN(8, -5n)                  // 251n
BigInt.asIntN(64, 0xFFFFFFFFFFFFFFFBn)  // -5n

// C23 made two's complement mandatory for signed integers.
// Before that, the other two encodings were legal but unused.

この計算機でできること

他の確認方法との比較

計算例

-5、ビット幅 8

符号絶対値表現  1000 0101
1の補数        1111 1010
2の補数        1111 1011  (0xFB)
ゲタばき表現    0111 1011

0xFB、ビット幅 8

符号なし        251
符号絶対値表現  -123
1の補数        -4
2の補数        -5
ゲタばき表現    123

-128、ビット幅 8

符号絶対値表現  この幅では表現なし
1の補数        この幅では表現なし
2の補数        1000 0000  (0x80)
ゲタばき表現    0000 0000

0xFFFFFFFFFFFFFF9C、ビット幅 64

2の補数    -100
符号なし   18446744073709551516

2の補数計算機の使い方

1. 1

   ビット幅を選ぶ

   4、8、16、32、64 のいずれか。これは表示の好みではありません。同じビットでも幅が違えば別の数を意味するので、選び間違えると答えそのものが変わります。

2. 2

   符号付き10進数を入力する

   マイナス符号も含めて整数を入力してください。4 つのエンコーディングが入力に合わせて更新され、それぞれの 16 進表記も同時に出ます。

3. 3

   またはビットから逆にたどる

   2 進文字列か 0x 付きの値を逆引きフィールドに貼り付けると、そのパターンが各解釈でどんな数になるかが、符号なしの読み方も含めて分かります。

4. 4

   注記が出たら読む

   つまずきやすい 2 点をページが知らせます。最小値には符号絶対値表現と 1 の補数の形が存在しないこと、そしてその 2 つではゼロに 2 つ目のビットパターンがあることです。

誤った答えを生む間違い

5   = 00000101
~5  = 11111010   <- ones' complement, not -5

5        = 00000101
~5       = 11111010
~5 + 1   = 11111011   <- -5 in two's complement

0xFFFFFFFFFFFFFFFB        // 18446744073709552000  -- the literal is already rounded
~0xFFFFFFFFFFFFFFFB + 1   // 0  -- silently wrong, expected -5

BigInt.asIntN(64, 0xFFFFFFFFFFFFFFFBn)   // -5n

int8  0xFB  (-5)
int16 0x00FB  (251)   <- zero-extended

int8  0xFB  (-5)
int16 0xFFFB  (-5)    <- sign-extended

-128 sign-magnitude: 10000000   <- that pattern means -0

-128 sign-magnitude: no representation at width 8
-128 two's complement: 10000000

実際に必要になる場面

センサーレジスタを読む

温度レジスタが 0xFF9C を返します。符号なしなら 65436 で、これは温度ではありません。ビット幅 16 の 2 の補数の行は −100 を示し、0.1 °C のスケール係数と合わせれば、センサーが言っているのは −10.0 °C です。

型情報のないプロトコルのデバッグ

Modbus、CAN、そして多くのバイナリテレメトリは、符号の情報を持たない生のワードを運びます。クライアントと機器の値が食い違うとき、同じワードの両方の読み方を突き合わせれば、たいていどちら側の思い込みが誤りだったか分かります。

計算機アーキテクチャの課題

符号絶対値表現、1 の補数、2 の補数、ゲタばき表現は、入門講義の定番の 4 つです。同じビット幅で並べれば、違いは暗記するものではなく見えるものになります。

整数オーバーフローを追う

カウンタが 2147483647 から −2147483648 へ飛んだとき、両方を 32 ビットのパターンで見れば、桁上げが符号ビットに入ったことが分かります。値が意味不明になったのではなく、エンコーディングの規則どおりに回り込んだだけです。

シリアライズ処理を書く

手書きのエンコーダを信用する前に、各ビット幅で負の値を 1 つずつこのページと照合してください。符号の扱いは書き間違えやすく、しかも最初の本物の負の数が来るまで、出力は構造的に問題なく見えてしまいます。

4つのエンコーディングの作り方

符号絶対値表現

最上位ビットが符号で、残りの n−1 ビットが絶対値を普通の符号なし数として表します。範囲は −(2^(n−1)−1) から 2^(n−1)−1 で対称、ゼロは 2 つ。IEEE 754 の浮動小数点数が使っているのが、このレイアウトです。

1の補数

負の値はその絶対値のビット反転、すなわち 2^n − 1 − x です。範囲も 2 つのゼロも符号絶対値表現と同じ。加算にはエンドアラウンドキャリー（巡回桁上げ）が必要で、まさにそれが 2 の補数の取り除いた面倒です。英語表記でアポストロフィの位置が違うのは誤植ではありません。ones' complement は全ビット 1 のワードを基準にし、two's complement は 2 のべき乗 1 つを基準にします。

2の補数

負の値 −x は 2^n − x として格納されます。範囲は −2^(n−1) から 2^(n−1)−1、意図的に非対称で、ゼロは 1 つ。加算・減算、そして下位ワードの乗算はすべて符号に依存せず、これが勝因のすべてです。

ゲタばき表現

value + 2^(n−1) を格納するので −2^(n−1) が全 0 になり、パターンの並び順が、それが表す値の順序と一致します。2 の補数のパターンの最上位ビットを反転したものに等しいです。名前には注意してください。IEEE 754 の指数部は 2^(e−1)−1 でバイアスされており、ここで使うオフセットより 1 小さい値です。

なぜ計算にBigIntを使うのか

JavaScript は &、|、~ とシフトのオペランドを 32 ビット整数に変換してから演算し、終わってから戻します。そのため 64 ビットの値は、何のエラーも出さずに上半分を失います。このページの変換はすべて任意精度整数の上で行うので、64 ビットの両端も正確に出ます。

符号付きの値を正しく扱うために

何よりも先にビット幅を決める

フィールドの幅を言うまで、ビットパターンには値がありません。データシートとデバッガの食い違いは、たいてい片方が 16 ビット、もう片方が 32 ビットを仮定していたという話に落ち着きます。

最小値は特別扱いする

どのビット幅でも符号反転はあふれます。2 の補数の符号付きバイトでは −(−128) はやはり −128 のままです。絶対値を計算するコードにはこの入力への方針が要りますし、テストにも必ず含めるべきです。

符号の有無をデータから推測しない

ビットをいくら眺めても、そのフィールドが符号付きかどうかは分かりません。データシート、スキーマ、構造体定義から取ってください。当てずっぽうは、本番に最初の負の値が来るまでは通用します。

幅を広げるときは符号拡張する

8 ビットの 0xFB を 16 ビットのフィールドに 0x00FB として写すと、−5 が 251 になります。符号付きの値を広げるとは符号ビットを複製することで、正しくは 0xFFFB です。

言語標準の変換を優先する

JavaScript の BigInt.asIntN、Python の int.from_bytes(..., signed=True)、C の固定幅型は、意図を明示していて境界も処理してくれます。手書きの ~x + 1 こそが、ビット幅バグの発生源です。

よくある質問