#コンパイラ

x86 の命令列を見ていて `ud2` に出会うと、ちょっと不思議に感じる。どちらかというと「未定義命令」という雑な名前で十分に見えるのに、わざわざ 2 が付いているからだ。Raymond Chen の短い記事は、その素朴な疑問に対して、Intel の仕様と現場の歴史がどう重なって今の形になったのかをたどっている。単なる命名の話に見えるが、実際には「何を壊してよいのか」「どの挙動を仕様として保証するのか」という、CPU 設計のかなり大事な話でもある。 記事の出発点は、x86 のコンパイラ出力や、API を横取りするようなソフトウェアのクラッシュ解析で `ud2` を見かけることだ。`ud2` は architecturally undefined instruction、つまりアーキテクチャ上「未定義」とされる命令で、実行されると必ず “invalid opcode” 例外を起こす。コンパイラはこれを、そこに来ては困る場所の目印として使う。たとえば `[[noreturn]]` が付いた関数が、理屈の上では戻らないはずなのに戻ってきてしまった場合、その直後に `ud2` を置いておけば

「GPUで計算する」と聞くと、なんだか一瞬で魔法みたいに処理が終わる印象があります。 でも元記事は、その裏側にある泥臭い手順を、かなり執念深く追いかけています。しかも題材は、たった1行のベクター加算。`a[i] + b[i]` を並列に足すだけの、いちばん地味なCUDAプログラムです。地味だからこそ面白い。GPUという巨大な装置が、どれだけの段取りを踏んでこの1行を実行しているのかが、くっきり見えてきます。 `nvcc` は1つのコンパイラではなく、複数のコンパイラをまとめて動かす“司令塔”です CUDAのコードは、まずPTXという中間表現になり、その後SASSというGPU実機向け命令に変わります `vadd<<<4096, 256>>>(...)` のような記法は、ホスト側で引数を詰める「stub」に置き換えられます GPUカーネルの引数は、constant bank 0 に載って読み出されます 実行時には、CPU側のランタイム、`libcuda.so`、ドライバ、PCIe越しのGPUが連携して動きます ただ“GPUに投げた”だけに見える処理の背後で、かなり多くの機械的な準備が走って