"記憶のありかたを制御することは、未来を設計することだ。"
プログラムは、記憶の上を泳ぐ。
それは、データを置き、取り出し、再配置しながら動き続ける生命体だ。
だがその記憶（メモリ）は、無秩序に使われるわけではない。
プログラムのメモリ利用には、大きく二つの領域が存在する。
**スタック（Stack）**と、**ヒープ（Heap）**である。
この章では、スタックとヒープをアセンブリレベルで眺めながら、
記憶空間に対する設計の哲学を探っていく。
スタックとは何か？
スタックとは、**後入れ先出し（LIFO）**の原則に従うメモリ領域である。
具体的には：
- 関数呼び出しごとにローカル変数を確保
- 呼び出し終了時に自動で解放
- 関数の戻り先アドレスも保存
特徴は明確だ：
- サイズが小さいが高速
- 静的に管理される（順序が厳格）
- 生存期間がスコープに依存する
つまりスタックとは、**設計者があらかじめ計画した「一時的存在たちのための劇場」**である。
ヒープとは何か？
ヒープとは、動的に確保・解放されるメモリ領域である。
その特徴は次の通り：
- サイズが大きく、柔軟
- 確保と解放は設計者次第
- 生存期間はプログラムの意図に依存する
ヒープは、「秩序なき自由」の空間であり、
スタックとは異なり、設計者がその管理責任をすべて負う必要がある。
スタック操作をアセンブリで見る
x86アセンブリにおける基本的なスタック操作はこうだ：
PUSH EAX ; スタックにEAXの値を押し込む
POP EBX ; スタックのトップから値を取り出し、EBXに格納
内部では次のようなことが起きている：
-
PUSHは、スタックポインタ（ESP）を減少させ、そこにデータを書き込む -
POPは、スタックポインタが指すデータを読み取り、ESPを増加させる
この単純な構造により、スタックは関数の呼び出しと戻り、変数の生死管理を完璧に制御している。
関数呼び出しにおけるスタックフレーム
アセンブリレベルで関数を呼び出すと、次のことが行われる：
- 引数をスタックに積む（右から左へ）
-
CALL命令で関数アドレスへジャンプし、戻りアドレスをスタックに保存 - 関数内でローカル変数分スタックを確保
-
RET命令で戻りアドレスへ復帰
例（簡易版）：
PUSH 2
PUSH 3
CALL add
ADD ESP, 8 ; 引数の分だけスタックを戻す
この一連の流れにより、
スタックは一瞬のうちに「世界線」を作り、それを破棄する劇場となる。
ヒープ操作をアセンブリ視点で見る
ヒープメモリの確保は、通常アセンブリだけで直接行うことは少ない。
通常は、OSのシステムコールを通して行う。
例えばWindowsでは HeapAlloc、Linuxでは mmap や brk などを使用する。
しかし、その本質は：
- サイズを指定して
- メモリ空間を確保し
- ポインタを受け取る
という極めてプリミティブな操作に還元される。
この「動的確保」が、ヒープの自由さと危うさを生み出す。
スタックとヒープ：速度と制御の対比
| 項目 | スタック | ヒープ |
|---|---|---|
| 管理主体 | コンパイラ・CPU | プログラマ |
| 確保・解放 | 自動（関数呼び出し/終了） | 明示的に必要 |
| 速度 | 非常に高速（数サイクル） | 比較的遅い（数百サイクル） |
| サイズ制限 | 小さい（数MB〜） | 大きい（数GB以上） |
| 使用用途 | ローカル変数、一時データ | 大きな配列、動的オブジェクト |
この違いは、
「設計者はどこまで秩序を制御する覚悟があるか」
という問いに直結する。
なぜスタックとヒープを分けるのか？
それは、「確定しているもの」と「変動するもの」を設計レベルで峻別するためだ。
- スタック：確定した生存期間を持つ
- ヒープ：不確定な生存期間を持つ
プログラム設計とは、
変化と不変をどこで区切るかを決める行為であり、
スタックとヒープの設計は、その最初の境界線なのだ。
結語：記憶を制御する者が、設計を制する
スタックとヒープは、単なるメモリ空間の違いではない。
それは、秩序と混沌、確定と不確定、計画と即興という、
プログラム設計における根源的対立を象徴する存在である。
スタックを操るとは、設計の秩序を受け入れること。
ヒープを操るとは、設計の混沌に責任を持つこと。
"記憶を制御するとは、設計に秩序を与えることだ。スタックとヒープは、その秩序の地図である。"