"動くものを書く。それは、動かすものと向き合うことから始まる。"
「このコードはハードウェアに近い」
そう語られることがある。
だが、“近い”とは一体何を意味するのか？
- 制御レジスタを直接叩くことか？
- 割り込みを自前で処理することか？
- クロックサイクル単位での命令チューニングか？
この曖昧な表現の奥には、
ソフトウェアと物理の境界を巡る深い哲学的問いがある。
本章では、アセンブリという語彙を通して、
「ハードウェアに近い」とはどういう状態なのかを再定義していく。
そもそも「近い」とは何か？
「近さ」は本質的に抽象レイヤーの数で定義される。
- C言語はアセンブリより高い
- PythonはCよりもはるかに抽象的
- OSのAPIはハードウェアの直接操作から隔てられている
つまり、**中間に介在する層が少ないほど、「近い」**とされる。
だがここで注意すべきは：
抽象を減らすこと＝制御可能性を高めることではない
という事実である。
制御権と近接性：真の意味での「近さ」
真にハードウェアに近いとは、
**「抽象を超えて、動作そのものを制御できる」**ことを意味する。
例：
- アセンブリで書かれた命令が、そのまま電気信号に翻訳されること
- I/Oポートに書き込むことで、物理デバイスが反応すること
- 割り込みベクタを操作して、CPUの挙動を直に変えること
ここで言う「近さ」は、相対的な物理的距離ではなく、
動作支配における直接性だ。
抽象の重ねすぎがもたらす「遠さ」
たとえば、以下のコードを考えてみよう：
print("Hello, world!")
この一行の背後には：
- インタプリタ
- 標準ライブラリ
- システムコール
- OSのI/Oマネージャ
- デバイスドライバ
- PCIバス
- メモリマップトI/O
といった、数十層に及ぶ抽象が存在する。
このコードがどのタイミングでどのハードウェアを叩いているのかは、
書いた本人ですら知る由もない。
これこそが「遠さ」だ。
アセンブリにおける「近さ」の感触
アセンブリを書くとき、
設計者は次のような事実と対峙する：
- レジスタは存在し、今ここで使える
- スタックは触れば変わるし、壊せる
- 割り込みは止めれば止まるし、呼べば発火する
- メモリはアドレスでしかなく、誤ればクラッシュする
これが「近さ」だ。
- 触れば壊れる
- 壊せば止まる
- 止まれば責任は設計者に帰す
この感触が、
高級言語では得られない「設計の実在性」である。
ハードウェアに近づくと、設計者は何を得るか？
-
動作に対する責任感
- 成功も失敗も設計の結果と知る
-
リソース感覚の獲得
- メモリは無限ではなく、CPU時間は有限であることを肌で知る
-
抽象化の根拠を学べる
- OSや言語設計が、なぜそう構造化されたかの“理由”が分かる
-
本質的な制御可能性の感覚
- ソフトウェアが“可能性”ではなく、“物理”と向き合っている実感を得る
「近い」設計をすべきとき、すべきでないとき
向いているケース：
- 組み込み開発
- デバイスドライバ設計
- リアルタイムシステム（RTOS）
- セキュリティ/バイナリ解析
- 自作OS、ブートローダ
向いていないケース：
- 業務アプリケーション
- Webフロントエンド
- データベース設計
- 高頻度のメンテナンスが必要な環境
「近い」設計は、高精度な理解と責任を要する。
適切に使い分けることが、設計者の成熟を示す。
結語：距離とは、制御できる範囲のこと
ハードウェアに近いとは、
物理的な「場所」ではなく、
設計者が責任を持って制御できる範囲のことである。
- それは知識と経験によってのみ近づける
- それは責任を負う意志がなければ近づけない
抽象に逃げることで得られる速度は、
ときに破綻と無理解を伴う。
だが近づくことで得られる遅さには、
設計の正確さと、動作の確かさがある。
"ハードウェアに近づくとは、世界に触れることだ。ソフトウェアの設計とは、本来そういうものだったのではないか？"