アセンブリと ISA 基礎

C、C++、Rust、Go コンパイラはソースを アセンブリ(assembly)(mov、add、call のような文字ニーモニック)に変換し、 アセンブラがそれを 機械語(machine code)(CPU がデコードする生バイト)に変換する。 アセンブリは機械語の 1 対 1 の人間可読ビュー、ラベル、コメント、 そして機械語対応のない .data や .text のようなひと握りの疑似命令を含む。

命令セットアーキテクチャ(ISA)は公開された契約: 合法な opcode のリスト、それらが使うレジスタ、受け入れるアドレッシングモード、それぞれの副作用。 ISA は CPU ベンダが実装するもの、ソフトウェアはそれを対象にする。 同じ C ソースを x86-64 と ARM64 用にコンパイルすると、2 つの ISA は異なる opcode を持つので、 まったく異なる機械語ながら同じことを行うものができる。

最小例

典型的な入門関数:

int add(int a, int b) {
    return a + b;
}

gcc -O2 で x86-64(Linux/Mac は SysV ABI)向けにコンパイルすると、吐かれるアセンブリは:

add:
    lea  eax, [rdi + rsi]   ; 2 つの引数レジスタを加算
    ret                     ; 戻り番地をポップ、ジャンプ

2 命令。呼び出し規約により、引数は rdi と rsi に到着する (次節で説明する);戻り値は eax(rax の下位 32 ビット)に残される。 メモリは関与しない —— 小さなリーフ関数は完全にレジスタ内に住み、現代コードがこれほど速い理由の 1 つ。lea(load effective address)命令は加算のために濫用される:lea eax, [rdi + rsi] は 1 命令で rdi + rsi を計算して格納し、 キャリーフラグを触らない —— コンパイラの一般的なトリック。

ARM64 上の同じ関数

add:
    add  w0, w0, w1         ; 引数 0 = 引数 0 + 引数 1
    ret                     ; リンクレジスタへジャンプ

2 命令、構造的に同じ仕事、異なるニーモニックとレジスタ名。 ARM の SysV スタイル ABI は最初の 8 整数引数を x0–x7(32 ビット int は w0–w7)で渡し、戻り値は x0/w0。 ARM の ret はリンクレジスタ(lr = x30)へジャンプし、 そこには呼び出し元の bl(branch with link)命令がセットした戻り番地が入っている。

なぜアセンブリを読むのか

アセンブリの読解力が報われる 3 つの具体的瞬間:

• プロファイラ属性。perf report はホット命令をアセンブリで表示する。 各ニーモニックのコスト —— lea は 1 サイクル、div は 20+、 メモリへの mov はヒット 1 サイクル / ミス ~100 —— を知っていれば、 「ソース 1 行のパーセンテージ」を実行可能な仮説に変えられる。
• コンパイラの説明。コンパイラはそのループをベクトル化したか? 配列境界チェックを消したか?std::move はコピーを回避したか? アセンブリが地上の真実、ソースは願望思考。Compiler Explorer (godbolt.org) がソースとアセンブリを並べる、これを教える最高のツール。
• マイクロアーキテクチャデバッグ。分岐誤予測、キャッシュミス、 ロックフリーコードのメモリ順序バグ、期待通りに動かないアトミック操作 —— これらはすべてソースレベルではなくアセンブリレベルで説明される。 強いメモリモデルを持つ言語(Java、Rust)はこれを稀にするが、C/C++ ではシニアレベルで不可欠。

アセンブリを書く必要はない。perf report の 20 行関数が 不透明に感じなくなる程度に読めればよい。

x86-64(Intel と AMD)は CISC 設計。命令は可変長 —— 各 1 から 15 バイト。汎用 64 ビットレジスタは 16 個(32 ビット x86 では元々 8 個、REX 接頭辞で 16 に拡張)。 数百の異なる opcode が複雑なアドレッシングモードをカバーする:mov rax, [rbx + rcx*8 + 16] は 1 命令で、 「1 つのベースレジスタ + 8 でスケールされた 1 つのインデックスレジスタ + 即値オフセット」から 計算されたアドレスでメモリを読む。CPU フロントエンドは命令の境界を判別するのに実際の労力を割く必要がある。

ARM64(AArch64)は RISC 設計。命令は固定長 —— 各正確に 4 バイト。汎用 64 ビットレジスタは 31 個。opcode セットがより小さく規則的。 複雑なアドレッシングモードはない:[rbx + rcx*8 + 16] からのロードは ARM では 2〜3 のより単純な命令を要する。デコードハードウェアは相応により単純で小さく、 これが直接命令あたりの低電力に翻訳される。

なぜ当時トレードオフが重要だったか

• コード密度。CISC はバイトあたりより多くの意味を詰めるので、バイナリが小さい。 メモリが高価だった 1980 年代には極めて重要。ARM の固定 4 バイト命令は ディスク上で等価な x86 コードより 30% 大きい場合がある、 ARM の Thumb モード(ホットコード用 16 ビット命令)で一部相殺される。
• デコーダの複雑性。x86 デコーダは命令境界を見つけるためにバイトを直列にスキャンする必要がある (最長命令接頭辞は助けにならない —— 部分的にデコードするまで長さが分からない)。 ARM の 4 バイトアラインメントはデコーダが N 命令を並列に取得・デコードすることを自明にする。 これが ARM コアがワットあたりより高いデコード幅に到達する理由の一部。
• レジスタファイルサイズ。レジスタが多いほどメモリへの spill なしで より多くの生きた値を保持でき、spill はコンパイラができる最も高価なことの 1 つ。 ARM の 31 GPR は x86 の 16 個に対してコンパイラに真の人間工学的勝利、 特に JIT コンパイルされた JavaScript のようなレジスタ密度の高いコード。

なぜトレードオフが今重要か

2020 年代が歴史的風景を逆転させた。3 つが推進した:

• Apple Silicon。M1(2020)は十分な R&D を投じた ARM コアが Intel の最高峰を大幅に低い電力で凌駕できることを示した —— コアあたり持続 5–10W vs Intel の 25W+。 4 年内に出荷される全 Mac が ARM。
• AWS Graviton。ARM ベースのサーバチップがドルあたりの性能で 20–30% 良く、 主要なクラウド移行を駆動した。2024 年までに AWS の新 EC2 インスタンスの半分が Graviton。 全ての主要 web サービスが今やマルチアーキ配備をサポートしなければならない。
• スマートフォン。ARM は常にスマホの ISA だったが、2011 年の ARMv8 で デスクトップコアと競争力を持つようになった。今日ポケットの中のスマホは 2015 年のサーバ CPU より高いシングルスレッド IPC を持つ。

ソフトウェアにとって何を意味するか

アプリケーションエンジニアにとって、違いは主に 3 箇所で現れる:

• プロファイラのアセンブリの見た目が違う。同じアルゴリズムだが、 ニーモニック、レジスタ名、命令数が異なる。両方を読めるようになるには練習が要るが平易。
• アトミックメモリ順序の意外。x86 は TSO(Total Store Order)—— 多くの操作はすでに無償で逐次整合的。ARM は弱順序 —— 明示的バリアなしの x86 で動く素朴なロックフリーコードは ARM では静かに壊れる。 これは最頻のクロスアーキ移植バグ。
• コンテナイメージとバイナリ配布。Docker イメージはamd64 と arm64 の両方を宣言・ビルドする必要がある;docker buildx とマニフェストリストがこれを扱う。 GitHub releases の事前ビルドバイナリは両アーキを持つ必要がある。 マルチアーキビルドのコストは実在するが小さい。

呼び出し規約は、GCC でコンパイルされたコードが Clang コンパイルコード、C ライブラリ、 カーネルを透過的に呼べるようにするルール。各 OS+アーキテクチャに正典の ABI (Application Binary Interface)があり、すべてがそれを対象とする。 Linux/x86-64 では System V AMD64 ABI。 Windows/x86-64 では Microsoft x64 呼び出し規約。Apple/ARM64 では AAPCS64 のカスタム変種。 細部は異なるが構造は同じ。

SysV AMD64 を 1 画面に

引数レジスタ(整数):    rdi, rsi, rdx, rcx, r8, r9  (6 引数)
引数レジスタ(浮動):    xmm0..xmm7                  (8 引数)
戻り値(整数):          rax  (128 ビット int は rdx)
戻り値(浮動):          xmm0

caller-saved レジスタ:  rax, rcx, rdx, rsi, rdi, r8..r11
                        (caller が呼び出しを跨いで保存が必要なら自分で保存)

callee-saved レジスタ:  rbx, rbp, r12..r15
                        (callee が戻る前に復元しなければならない)

スタック:               呼び出し地点で 16 バイトアライン;下方向に伸びる;
                        rsp の下に 128 バイトのレッドゾーン。

多くの関数呼び出しで、最初の 6 整数引数と最初の 8 浮動小数点引数はすべてレジスタに収まり、 呼び出し自体はメモリを一切触らない。それを超える引数はスタックにプッシュされる。 戻り値は rax または xmm0 で返る。スタックアラインメントは 16 バイト —— SSE 命令がスタック上に確保されたベクタにトラップなしで動作できるための要件。

caller-saved vs callee-saved

この分割が存在するのは、caller と callee で物を保存するコストが異なるから。 caller-saved レジスタ(「スクラッチ」または「volatile」とも呼ばれる): 呼び出し関数は呼び出しを跨いで気にする値を知っており、それらだけを保存する。 大半を気にしなければ安い。callee-saved レジスタ: 呼ばれる関数は実際に使うものを知っており、それらだけを保存する。 関数が大半の callee-saved レジスタを使わなければ安い。

実務的にはコンパイラが変数ごとにどのタイプのレジスタに格納するかを決める。 ループカウンタや内側ループの一時値は通常 caller-saved レジスタに入る (ループ内で安く、作業中にホット)。関数呼び出しを越えて生存する長寿命値は callee-saved レジスタに入る(関数入口で一度保存、戻り際に一度復元 —— 呼び出しごとに再保存するよりずっと安い)。

スタックフレーム

高アドレス
   ┌──────────────────────┐
   │  caller の引数 #7..#n│  (6 整数引数を超える場合)
   ├──────────────────────┤
   │     戻り番地           │  ← 'call' がプッシュ
   ├──────────────────────┤  ← 入口時の caller の rsp
   │  保存された rbp(任意) │
   ├──────────────────────┤  ← callee がここに rbp を設定
   │     ローカル変数        │
   │   スピルされたレジスタ   │
   ├──────────────────────┤  ← callee の現在の rsp
   │  レッドゾーン(128 B)  │  ← rsp 調整なしで使える
   ├──────────────────────┤
低アドレス

関数呼び出しは戻り番地をスタックにプッシュしてジャンプする。callee プロローグは通常 フレームポインタをセットアップし(push rbp; mov rbp, rsp)、 ローカル用の領域を確保する(sub rsp, N)。 callee エピローグはこれを逆転させる(add rsp, N; pop rbp; ret)。 リーフ関数は命令節約のためフレームポインタを省くことが多い。

rsp の下の 128 バイトのレッドゾーンは、rsp を明示的に調整せずにリーフ関数のスクラッチ領域として予約される。 シグナルハンドラはそれを触ってはならない。シグナル安全コードが通常コードと異なる小さな細部の 1 つ。

なぜデバッグと FFI に重要か

• スタックトレースデコード。各スタックフレームは規約に従うので、 バックトレースは rbp(フレームポインタあり)または DWARF unwind 情報の読み出し (なし)でフレームを辿れる。規約が破られると(例:インラインアセンブリが callee-saved レジスタを宣言なしに clobber する)、バックトレースが壊れ、 クラッシュが不透明になる。
• FFI(Foreign Function Interface)。Python、Rust、Go、Java などから C を呼ぶのは常に共通言語として C ABI を通る。 各言語の FFI 層は引数を規約の期待するレジスタとスタックスロットへマーシャルする。 ミスマッチ(型幅の誤り、アラインメント不足)はメモリ破壊バグの一般的な原因。
• カスタム呼び出し規約。JIT(V8、LuaJIT、Java の JIT)はしばしば、 より多くの引数をレジスタで渡すか、プロローグ / エピローグ作業をスキップする独自の内部規約を発明する。 C コードに渡るときには ABI 規約に切り替える必要がある。

x86-64 または ARM64 の数百の命令のうち、ちょうど 1 つが特別: CPU をユーザモード(x86 で特権 ring 3、ARM で EL0)からカーネルモード(ring 0 / EL1)へ切り替える命令。 x86-64 では syscall 命令;ARM64 では svc #0。 プログラムが実行する他のあらゆる命令 —— ロード、ストア、加算、分岐 —— はユーザモードで動き、 CPU はプログラムがカーネルのマップしたメモリとデバイスしか触れないよう強制する。

アトミックに変化するもの

syscall 命令で、ハードウェアはいくつかの状態をアトミックに変える。 アトミック性こそが境界を安全にする:ユーザコードがカーネル特権で動いている瞬間、 またはカーネルコードがユーザページテーブルで動いている瞬間は存在しない。

• 特権 ring 3 → 0。CPU のステータスレジスタのフラグが変わる。 この瞬間からプログラムは特権命令を実行でき、マップされたカーネルメモリにアクセスできる。
• ページテーブルベース切り替え。x86 では CR3 レジスタがカーネルの ページテーブルベースをロードする。Meltdown(2018)が KPTI(Kernel Page Table Isolation) を必須にして以来、ユーザとカーネルは別々のページテーブルを持つ —— 切り替えは実コスト(TLB フラッシュ)。
• スタックポインタ切り替え。ユーザモードの rsp が保存され、 スレッドごとのカーネルスタック(CPU の MSR に保持される)がロードされる。
• 命令ポインタがジャンプする先は、x86-64 で LSTAR model-specific レジスタに記録されたカーネルの syscall エントリポイント。

カーネル側

カーネルは指定されたレジスタ(Linux/x86-64 では rax、Linux/ARM64 では x8) から番号を読み、どの syscall が要求されたか識別する。その番号をsys_call_table(syscall ごとに 1 つの関数ポインタを持つテーブル)のインデックスに使い、 対応するハンドラを呼ぶ。引数レジスタ(Linux/x86-64 の syscall ではrdi/rsi/rdx/r10/r8/r9;rcx でなく r10 なのは、 syscall 命令自体が rcx を clobber するから)が引数を運ぶ。

コスト

syscall 自体は現代ハードウェアで 100–300 ns かかる(post-Meltdown の KPTI 込み)。 これは実際の作業の前 —— socket バッファからの read は syscall コスト + メモリコピー; ディスクからの read は syscall コスト + I/O レイテンシ。 syscall オーバーヘッドが床:カーネル遷移を含むあらゆることがそれより速くなることはない。

これが高性能サーバが syscall を回避するために大いに努力する理由。epoll は N 個の socket 準備クエリを N 個ではなく 1 つの syscall に凝縮する。io_uring はさらに進む —— ユーザ空間とカーネルが進行中操作のリングバッファを共有し、 I/O の提出と刈り取りが syscall なしで行われる。sendfile と splice はカーネルがファイルディスクリプタ間でバイトを ユーザ空間を経由せずにコピーできるようにする。

vDSO —— syscall に見える非 syscall

頻繁に使われる「syscall」のいくつか —— gettimeofday、clock_gettime、getcpu —— は vDSO(virtual Dynamic Shared Object)と呼ばれる 共有ユーザ空間ライブラリで実装され、カーネルがそれを全プロセスにマップする。 実装はカーネル管理データを読み取り専用ページから読み、即座に返す、特権遷移なし。 これはレイテンシを ~150 ns から ~15 ns に下げる —— これらを常に呼ぶ時間敏感なコード(ロギング、プロファイラ、トレースツール)に重要。

コードレビューの赤旗

• 適切な clobber 宣言のないインラインアセンブリ。asm volatile を使う関数はどのレジスタとメモリを変更するかコンパイラに伝える必要がある。 clobber の欠落は静かな破壊を引き起こし、コンパイラが asm ブロックを跨いで clobber されたレジスタに値を保持することを決めたときにのみ顕在化する。
• ARM で実行されることを意図した、明示的メモリバリアのないロックフリーコード。x86(TSO)で動くコードが ARM(弱順序)で静かに壊れる。 直し方は各アトミック操作に明示的な atomic_thread_fence または 適切な memory_order。
• 引数幅が不一致な FFI 宣言。Python や Rust から間違った型幅で C 関数を呼ぶと、 規約が次の呼び出し地点で見つけることを期待するレジスタ / スタックを破壊する。cffi、bindgen、Rust の libc クレートが 正しいバインディング生成のために存在する。
• 反復ごとに多くの syscall を発するタイトなループ。socket からの各 read が 1 syscall;1 メガバイトを 1 バイトずつ読むと 10 万 syscall になる。 ユーザ空間でバッファし、キロバイトごとに 1 回呼ぶ(または readv を使う)で償却する。
• 2025 年に走るコードのシングルアーキ Docker イメージ。FROM alpine が arm64 を指定または対応していなければ、 Graviton、M シリーズ Mac、あらゆる現代の開発環境で失敗する。docker buildx を --platform linux/amd64,linux/arm64 で使う。