/ «2004-11-30 (Tue) ^ 2005-01-12 (Wed)» ?
   西田 亙の本:GNU 開発ツール -- hello.c から a.out が誕生するまで --

Categories Books | Hard | Hardware | Linux | MCU | Misc | Publish | Radio | Repository | Thoughts | Time | UNIX | Writing | プロフィール


2005-01-11 (Tue)

[Thoughts] アーキテクチャを学ぶために

煮詰まる

しばらく連載執筆から遠ざかると、このようなちょっとした物書きさえも億劫になってしまう。日々の継続、そして大脳への刺激付けが大切というところだろうか。

GCCプログラミング工房を休載させて頂いた表向きの理由は、「書籍化に集中したいため」だったのだが、白状すると実はもうひとつあった。「今後、どの方向にテーマを展開していくべきなのか」、答えを見つけ出すことが出来ず、かなり煮詰まっていたのである。

登坂ルート

PC-UNIX の魅力に取り憑かれ、ご本尊であるカーネルの踏破に挑戦する人々は多いが、この山は大層険しい。よほど基礎体力と才能に恵まれた人間でない限り、まず間違いなく"遭難"が待ち受けている。かく言う私自身も、「あ〜れ〜〜!」と何度滑落したことか。

未だ踏破できた訳ではないが、ここ数年のトレーニングの甲斐あって、周りの見晴らしは随分良くなってきた。山の頂きも、くっきり見える。以前のように、息切れすることもない。これなら、無酸素登頂も夢ではないだろう。問題は、登坂ルートをどこに取るかだ。

3つの関所

最近は、Linux や FreeBSD のカーネル解説書などが豊富に出回るようになってきたが、これらの資料だけでカーネルを理解することは、極めて難しい。私自身の経験から考えると、カーネル・OSを理解するために、避けて通れぬ関門は以下のように3つある。

  • 開発ツール
  • カーネル内部のデータ構造
  • 標的アーキテクチャ

2番目については、これまで多くの解説が行われてきた訳だが、開発ツールとアーキテクチャについては、不思議なことにほとんど注目されることはなかった。むしろ、看過されてきたと言っても良いだろう。

カーネルの成り立ち、ひいては内部動作を正確に把握するためには、膨大なカーネルソースツリーから、一体どのようなコードとデータ構造が現れるのかを知る必要がある。PC-UNIX では、GNU 開発ツールが用いられるが、特に Linux では GNU ツール特有の、高度な使いこなしが随所で活用されている。このため、カーネルソースを読みこなすためには、GNU 開発ツールに通じることはもちろん、生成オブジェクトファイルおよび実行可能ファイルを規定する ELF 形式の内部構造も把握しておかねばならない。

GNU 開発ツールと ELF については、過去2年間の執筆を通じて、最低限知っておかねばならない勘所については、解説できたのではないかと思う。

残る関門はアーキテクチャであるが、IA-32 および PC-AT アーキテクチャは、あまりに壮大すぎて、どこから手を付けていいのやら皆目見当が付かない。手を付けるにしても、これまでアセンブラーや機械語に接した経験がない方々に対して、誰もが分かる明快な解説を書き下ろすことは至難の業、いや不可能に近い。

と、散々悩んだ挙げ句に、当時の私が出した結論が "仮想機械 Octopus" 編である。機能を絞り込んだ8ビットマシンのコーディングを通じて、レジスター・演算・スタックなど CPU の基本構造を理解し、FreeDOS 上での PS/2 キーボード・VGA カードプログラミング(いわゆるポート直叩き)を通じて、I/O 制御の意味とその素晴らしさを、読者の方々に体験して頂こうという、今にして思えばてんこ盛り状態の内容であった。

結果として中途半端なシリーズになってしまったことは否めなく、この頃からアーキテクチャ理解のための優れた素材探しが始まった。

アーキテクチャの師はいずこに

無論、最初から 486 もしくは Pentium プロセッサを理解できるに越したことはない。私自身、486 の解説書執筆に向けて、これまで数え切れないほど構想を練ってきた。しかし、現在に至るまで、納得できるアプローチを見つけ出すことは出来ていない。

その一方で、私の青春時代の経験が、「たとえ8ビット CPU でも良いから、ひとつの単純なアーキテクチャを徹底的に理解することが、何よりも大切ではないのか?」とも言っている。

確かにその通りだ。PC-8001 を20年以上昔のポンコツマシンと侮ることなかれ。この非力なマシンの中に、システムプログラミングの基本の多くは宿っていた。16ビットのアドレス空間は、今となっては鼠、いやノミの額ほどだが、それでも現在の初学者にとっては、十二分に広大な世界であり、壮大なロマンも秘めている。すっかり死語となってしまった Relocation という言葉も、16ビットの世界ではきらめきを取り戻す。

私を始めとする20年前のマイコン小僧達の周りには、このように理解する上で最適のサイズをもつアーキテクチャが、ゴロゴロしていた。かの Linus 氏も、おじいちゃんから譲り受けた Commodore VIC20 (CPU 6502)を、最初にしゃぶり尽くしたらしい。8ビットマシンは、基礎トレーニングを積むためのファームとして、最適のものであったと言えるだろう。

これに対して、現代のパソコン小僧達は受難続きだ。何と言っても、最初に目にするパソコンが、いきなり Athlon64 である。64ビットなど、もはやビットを数える気力すら萎えてしまう。これ以上にはないほど複雑化したマシンを前にして、ゲーマーもしくはインストール野郎と化す彼らを誰が責めることが出来よう。人間、自分が理解できない代物に対しては、条件反射的に思考停止するものである。

以上より、一個人が理解できるサイズを持つ、最適の16ビットアーキテクチャを探し求める旅が始まった。この20年の間に生じてしまった、アーキテクチャの Missing-link を紡ぎ直すためだ。ちなみに命令コードも16ビット長であることを条件に加えたのは、Octopus での苦い経験に基づいている。8ビット長命令コードは、確かに単純ではあるが、その後の発展性を著しく欠いてしまうからだ。