x86の未定義命令がなぜ「ud2」と呼ぶのか？数字の「2」の意味を解明！

x86アーキテクチャで未定義命令を実行した際に発生する「ud2」という命令コード。なぜただの「ud」ではなく「2」が付いているのでしょうか？実はこれ、初期のx86設計における命令セットの進化や、かつての「UD（Undefined）」命令との歴史的経緯が関係しています。技術的に深掘りすると、プロセッサが不正なオペコードを検知して例外を投げるための、実に興味深い仕組みが見えてきます。

自分はx86にあまり詳しくないんだけど、他のアーキテクチャならソフトウェア割り込みや例外を発生させられるよね。x86にはそれがないの？それとも、そういった機能ではユースケースをカバーしきれないとか？

今ではUD0、UD1、UD2がSDMやAPMに記載されてるよ。x86-64の64ビットモードで追加された1バイト版のUDB（D6）もあるしね。それに昔からあるUDW（FF FF）、いわゆるグループ#5（1つ目のFF）とModRMバイト（mod=11b r/m=111b (/7) reg=111bの2つ目のFF）もある。これは全ビットが1のメモリや、デバイスがアクセス要求をしない時に全1で終端されるバスなどで重要になるやつだ。

これって彼の推測にすぎないの？それとも何か根拠があるのかな？

最初のハードドライブのドライブレターがCなのと似たような理由だよ。

「0F FFというバリアントが遡及的にud0と命名され、0F B9がud1と命名されたことで、推奨される未定義オペコードとしてud2が残った」という箇所には驚かされたよ。この文を読んだ時、自分は0f ffが#1で、0fb9が#2になるものだと思い込んでたから。でも違うんだね。Intelは0から数えるから、3つ目のudが存在するってわけだ。

ついに0F FF信者たちが報われたな。彼らはオペコードUD0という栄誉を与えられ、唯一無二の正当なる無効オペコードの地位を手に入れたわけだ。これで0F B9派はUD1という汚名を着せられて永久に恥をさらすことになるね。

最近、ランダムに失敗するビルドのデバッグをやってたんだけど、V8からのud2が待ち構えていたよ。

「ud2にしておくのが無難だ。挙動が一貫していてアーキテクチャ的に保証されているからね」

ああ、ついに「挙動が一貫していてアーキテクチャ的に保証されている」未定義命令に出会えたよ！