西田 亙の本：GNU 開発ツール -- hello.c から a.out が誕生するまで --
Categories Books | Hard | Hardware | Linux | MCU | Misc | Publish | Radio | Repository | Thoughts | Time | UNIX | Writing | プロフィール
さて、DJ Bernstein 氏が着目した RDTSC 命令であるが、この暗号のような名前は ReaD Time Stamp Counter に由来している。
余り知られていないが、Pentium 以降の x86 シリーズは、クロックレベルの解像度を持った６４ビットカウンターを内部に有している(MSR: Model Specific Registers のひとつ)。この超高精度カウンターは、電源ＯＮでゼロリセットされ、CPU 稼働中は１クロックサイクル毎に１ずつインクリメントされる。RDTSC 命令は本カウンターの現在値を EDX/EAX レジスターペアに格納するための命令である。
これだけではあまり実感が湧かないので、実際に計算してみよう。1GHz のクロック周波数をもった CPU の1クロックサイクルは、1/10^9 秒、すなわち１ナノ秒。光の速度をもってしても、30cm しか進めないほどの短い間隔で、６４ビットカウンターは回り続けることになる。
頭の中でイメージすると、あっと言う間にカウンターがオーバーフローしてしまいそうな感じがするが、６４ビットのパワーは底知れないものがある。bc を使って計算してみよう。まずは、６４ビット長で表現可能な最大の整数値(unsigned)はどれぐらいの大きさになるのだろうか？
$ bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 2^64-1 18446744073709551615
なんと２０桁である。見ただけでゲンナリする程だが、この数値に１ＧＨｚの場合の１クロック時間を掛け合わせてみる。
(2^64-1)/10^9 18446744073
かなり、小さくなった。１ＧＨｚ CPU の６４ビットカウンターが一杯になるのは、電源が投入されてから１８４億秒後である。まだ、実感が湧かない。
(2^64-1)/10^9/(60*60*24) 213503 (2^64-1)/10^9/(60*60*24)/365 584
そうですか、５８４年後ですか。後１０回生まれ変わったとしても、心配いらない訳ね。失礼しました。
本題に戻る。これも余り知られていないのだが、x86 GCC は６４ビット長整数値に対応しており、long long 宣言を使用することができる。int は３２ビットだが、long long を使うことで、一気に６４ビットの世界を堪能することが可能になるのだ。
これに併せて、当然のことながら glibc も対応済みである。取り急ぎ、私達が知りたいのは printf での出力制御である。次の ll.c を見てほしい。
#include <stdio.h> // printf()
int main() {
int i = -1;
long long l = -1;
printf("%X?n", i);
printf("%llX?n", l);
printf("%u?n", i);
printf("%llu?n", l);
}
このプログラムを見るだけで、GCC 上での６４ビット整数値の使いこなしのポイントはお分かり頂けるだろう。それでは、実行してみよう。
$ gcc -o ll ll.c $ ./ll FFFFFFFF FFFFFFFFFFFFFFFF 4294967295 18446744073709551615
詳細は省くが、int, long long 変数共に ー１を指定しているのは、このバイナリー値が unsigned では最大値に相当するからである。実際、実行結果は先ほど計算した 2^32-1, 2^64-1 と同じ値になっている。
なお、printf 中で６４ビットを表示するためには、このプログラム例のように "ll" を前置する必要があるので注意してほしい。"ll" を指定しなければ、３２ビット分の情報しか表示されない。詳細は、man 3 printf 中の "The length modifier" を参照してほしい。
それでは、RDTSC 命令・・と行きたいところだが、その前にどうしても、理解しておかねばならないことがある。それは、関数の戻り値の正体である。
これも世の中の教科書にはほとんど書かれていないのだが、実践では極めて重要。x86 GCC における次の事実は、知っておいて損はない。
しかし、これも所詮は机上の知識に過ぎない。実際に、次に示す simple_func.c で確認してみよう。
int simple_func(void); // Declare simple_func as an
// function entry address
asm("simple_func: "); // simple_func entry address
asm(" movl $123, %eax "); // return 123
asm(" ret ");
int main() {
return simple_func();
}
このコードは GCC のインラインアセンブリ機能を用いて、simple_func 関数をまるごとアセンブリ言語で記述したものである。この３行のアセンブリソースは、Ｃ言語で simple_func() { return 123; } で記述した場合と同じ(正確にはより短縮した)コードに相当する。狐につままれた人も多いかと思うが、ともかく実行してみよう。
$ gcc -o simple_func simple_func.c $ ./simple_func ; echo $? 123
意図通り、親プロセスであるシェルに１２３が返されていることから、アセンブリ言語版 simple_func 関数は正常に動作していることが分かる。
simple_func.c は、アセンブリ言語を知らない人が見れば、思わず面食らってしまう内容だが、実は機械語こそがＣ言語の正体なのである。逆に言えば、アセンブリ言語・機械語を知らずして、Ｃ言語を制覇することは到底不可能だと、私は信じている。
にもかかわらず、世の中のＣ言語入門書は、一冊としてアセンブリ言語理解の必要性を説くものはない。それどころか、「１週間で分かる」、「すぐ分かる」、「猫でも分かる」などと甘い言葉で読者を誘い、「皆さん分かりますか？変数というのは箱なんですよ」という決まり文句で、善良なる初心者を迷宮に招き入れるのである。「変数＝箱」という概念に囚われている限り、Ｃ言語を体得することは不可能。「変数＝関数＝構造体＝メモリー」の境地に達した時、初めてＣ言語の本質が見えてくるのだが、このためには機械語の知識が必須である。
志を胸に秘めてＣ言語入門書を手に取ったものの、途中で挫折した若い人達の数は一体どれだけの数に上ることか？しかし、挫折した人はまだいい。中には「自分はＣ言語を理解できた」と思いこんでいる読者も少なくない。実は、これが一番たちが悪い。そして、「思いこませる」技術に長けた著者のテキストが、ベストセラーになるという悪循環が、この日本で続いている。
日本が置かれた暗い影ばかり見ていても仕方がない。世界には、ワクワクするようなことが満ちあふれている。知的好奇心を満たしてくれるものが、毎日のように登場している。人生、楽しまなければ損である。しかし、心底楽しむためには、それなりの技術と知識・経験が必要。プログラミングも、機械語の知識が加わることで、スクリプト言語やコンパイラーとは全く違う楽しみ方が出来るようになる。やってみよう。
先ほど紹介したように、Pentium CPU 内部のタイマーカウンターは６４ビット長である。これに対してレジスターは３２ビット長しかない。困った、半分のサイズしかないよ・・。
でも大丈夫。x86 では６４ビット長の場合は、EDX および EAX レジスターの２つを組み合わせることで、演算を遂行することができるのである。本当？紙に書かれた文言ではなく、この目で確認することが大切だ。
#include <stdio.h> // printf()
long long simple_longlong(void); // Declare simple_longlong as an
// function entry address
asm("simple_longlong: "); // simple_longlong entry address
asm(" movl $0x55667788, %eax "); // return 0x1122334455667788
asm(" movl $0x11223344, %edx ");
asm(" ret ");
int main() {
printf("%llx?n", simple_longlong());
return 0;
}
６４ビットでデータを扱う場合、上位３２ビット(ワード)は EDX レジスター、下位３２ビットは EAX レジスターに格納する決まりになっている。このため、simple_longlong 関数では、EDX に 0x11223344、EAX に 0x55667788 を転送した。
$ gcc -o longlong longlong.c $ ./longlong 1122334455667788
ブラボ〜！おっしゃる通りだね。それでは、準備は全て完了した。いよいよ RDTSC 命令を実行してみよう。このためには、インラインアセンブリーを用いて、Ｃソース中に直接 rdtsc 命令を展開する必要がある。
#include <stdio.h> // printf()
long long exec_rdtsc(void); // Declare exec_rdtsc as an
// function entry address
asm("exec_rdtsc: "); // exec_rdtsc entry address
asm(" rdtsc "); // Do RDTSC instruction
asm(" ret ");
int main() {
printf("%lld?n", exec_rdtsc());
return 0;
}
rdtsc.c は上のようになった。簡単である。asm() 文中に rdtsc と記載しているだけである。後は、ret (RETurn)命令を使って、呼び出し元へ帰るのみ。おみやげに、６４ビットカウンターの値を EDX/EAX レジスターに携えながら。それでは、気合いを入れて実行。
$ gcc -o rdtsc rdtsc.c $ ./rdtsc 3225565264110002
お〜〜、いかにもそれらしい値が現れた。この値を検証してみよう。まず最初に、マシンの CPU およびそのクロック周波数を確認しておく。これには、/proc/ ディレクトリの cpuinfo が便利だ。
$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 11 model name : Intel(R) Celeron(TM) CPU 1000MHz stepping : 1 cpu MHz : 1002.306 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1998.84
Celeron 1GHz であることが分かった。uptime からのデータを元に、rdtsc が返した値を検算してみよう。
$ uptime ; ./rdtsc 18:51:06 up 37 days, 6:23, 3 users, load average: 1.02, 1.01, 1.00 3227200233459745 $ bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 3227200233459745/(60*60*24) 37351854553
６４ビットカウンターから逆算すると、このサーバーの uptime は 37.35 日であることが分かる。uptime の表示値とは多少ズレがあるが、これこそが今後検討すべき課題である。
「時間道」は、まだ始まったばかりなのだ。
本日、ついに「CPU の創りかた」が到着した。この日をどれほど待ちわびたことか。新刊書をこれほどの期待感で迎えるなど、生まれて初めてのような気がする。
期待感に萌えていたのは、どうやら私だけではないようで、ネット上を検索してみると発刊前にもかかわらず多くの人達が、この本に触れている。本書の副題は「初歩のデジタル回路動作の基本原理と製作」であるが、この手の本がここまで話題をさらったのは、日本初ではなかろうか？
実際、この珍現象は数字にも裏付けされており、amazon.co.jp におけるコンピューター関連書ではダントツの一位。驚くべきは、なんと一般書も含めた「和書トップ１００」の中で、トップ８に位置しているのである！１冊の本が、これから理工学出版界を揺るがすことは間違いないだろう。
恐るべし、萌えパワー。これから、この手の萌え本がブームになりそうな予感がするが、この本を世に送り出した毎日コミュニケーションズの担当者へのインタビューを、是非とも読んでみたい。
さて、その内容だが、半分まで読んだところで睡魔に引きずり込まれてしまった。２０年前なら、間違いなく徹夜で読破していただろうに・・。老化とは嫌なものである。
詳細は、追ってまた。ひとつ言えることは、やはりこの本は「日本のコンピューター史に残る」だけの価値がある。２０数年手に取ってきた、コンピューター和書の中で、最もオリジナリティーに溢れている。これを英訳すれば、恐らく世界的評価も受けるだろう。ついに、日本から世界に向けて発信できるだけのテキストが誕生したのだ。
感動した。そして、この瞬間に立ち会えたことに感謝。
GPS 探索を続けていく中で、今回購入する GPS receiver の最終候補は Motorola の UT+ Oncore に決定した。「このレシーバーさえあれば、しょぼい NTP サーバーなんか No thank you!」という感じ、だね。ちなみに先日紹介した、KEK/Kamiokande の時刻同期システムでも、補助システムとしてこの Oncore が使われている。
Oncore は Motorola の製品だが、このドキュメントがとてつもなく凄い。Motorola ほどの巨大企業ともなると、エンドユーザー向けの技術資料など、なかなか整備してくれないもの。しかし、そこは世界を代表する超一流企業、気合いの入れようが違う。私は、Oncore のドキュメント群をダウンロードして、速攻この製品を購入することを決めた。丁寧な文書を通して、技術者やテクニカルライター達の自社製品に対する愛情、そしてエンドユーザーに対する誠意を感じたからである。
英語を学んでつくづく良かったと思うことは、じつはこういう時である。知識を入手できることよりも、その背景にある人間性や会社の成熟度が見えてくる方が、個人的には遙かに面白い。残念なことに、私はこのような感覚を日本の企業を通して、感じたことはまだ一度もないが・・。ドキュメントを通して見た日本企業は、実に未熟である。
さて、ここからが本題だ。Motorola のホームページをチェックしている最中に、先日超弩級の記事を見つけた。「Motorola and Nintendo Join Forces to Define Wireless Portable Gaming」と題したプレスリリースは、とんでもない内容である。なんと、Motorola がＧＢＡ用の無線通信モジュールを Nintendo に供給するというのだ！うっそ〜〜〜、である。
詳しい仕様はまだ明らかになっていないが、2.4GHz の帯域で TDMA (Time Division Multiple Access)というプロトコルを用いて、最大５人の同時プレーを可能にするらしい。来るべき時が、来ましたか・・。モジュール本体はこんな形。何やら、鬼のツノのようなものが見えるが、恐らくこれが Motorola 自慢の通信アンテナではないかと思われる。通信モジュールと本体の接続は、この写真から判断すると、通信ポートが使われている。
気になるのは、"The Motorola chipset contains a 32-bit RISC architecture baseband processor" という件。私が察するに、これは ARM7 だね。なぜなら、Oncore も ARM7 を搭載しているし、何より Nintendo との Colaboration が発表された数日後の「Motorola Expands ARM Core-Based Product Roadmap for Mobile Multimedia Applications on Smart Handheld Devices」というプレスリリースが、その可能性をプンプン臭わせている。
それにしても、ARM の選択といい、Nintendo の選択眼の素晴らしさには恐れ入る。Nintendo がなぜ国内企業にソッポを向けて、Motorola と組んだのか。その理由を想像すると面白い。人間同士の関わりであるから、単に技術力の問題だけでなく、先にも述べた会社や人間の成熟度というのも大きなファクターなのではなかろうか？
参考までに、同プレスリリースを Game freeks 向けに焼き直したものは、ここやあそこにある。
このネタは大層インパクトがあるので、日本でも色々な雑誌やメディアで取り上げられるだろう。しかし、記事としての面白さは「なぜ Motorola なのか？」まで踏み込めるかどうかにかかっている。そういう目で、メディアを読み込んでいくと、なかなか面白い。
さて、お兄さん。ARM and ARM かもしれんですよ、とうとう GBA も来年から無線通信ですよ、となると当然 Linux ホストにこのモジュールをつなげたいよね。なんだか最近、年甲斐もなくドキドキすることが多いのである。秋だから？
二晩をかけて CPU の創りかたを舐めるように読んだ。ここまで手間暇かけて丁寧に読み込んだのは、SICP と共に久しぶりのことだ。いくつか問題点はあるものの、本書の中身は私の想像を遙かに超えるものだった。
前評判は「萌える CPU 本」ということで、世間の話題をさらった訳だが、派手なのは表紙だけ。中身はほとんど「萌えていない」と私は思う。「もっとイラスト増やした方がいいんじゃない？」と、感じたほどだ。個人的には結構、気に入っていたりする。
しかしである。文章まで萌えるのは、いかがなものか。読者の気を引こうと努力しているのは分かるが、この文章は少々悪ふざけが過ぎる。優れた内容を記述しているにもかかわらず、文章でその価値が激減している点は、いかにも惜しい。文章はあくまでも、簡潔明瞭にが大原則である。文体は Dry すぎる位が、読者にとっては理解しやすいのだ。叶うことなら、改訂第二版では文章を全面的に書き直し、その分イラストで萌えまくってほしい。
で、内容であるが軽妙な文体に騙されそうになるのものの、要所要所で本質をグサッと貫くことが書かれている。捉え方は人それぞれだろうが、私の場合は第７章でクライマックスを迎えた。この章ではフリップフロップが紹介され、1bit CPU が登場する。私は、この章の170, 171 ページを読んだ時、目からウロコどころか、まぶたが落ちた。
ここで、著者は「CPU の本質は転送命令にある、演算は転送命令の修飾形に過ぎない」ことを強調している。この一言で、ハードウェア音痴の私は開眼した。アルキメデスは比重を風呂場で発見した際、感激のあまり素っ裸であたりを走り回ったというが、まさにその通り。私も嬉しさのあまり、この感動を誰かに伝えたいとあたりを見渡した。が、そこには高イビキで眠り込む嫁さんと娘しかいなかった・・。人生とは孤独なものである。
これまで一体何冊の電子・論理回路の解説書を購入してきたことだろうか？数十冊どころの騒ぎではないような気がする。浪人をきっかけにして目覚めたコンピューターにハマルこと、２０数年。論理回路の本質を語りかけてくれる書籍に、この歳で出会えたことは望外の幸せである。逆に言えば、世の中の「アタマのいい大先生方」や老舗の出版社は、この２０年間一体何をやっていたのだろうか？
実は、この９月に「コンピュータ設計の基礎知識」という本が共立出版から発刊されている。DesignWave Magazine にも連載を寄稿されている清水氏によるものであり、副題は「ハードウェア・アーキテクチャ・コンパイラの設計と実装」と多岐に渡っている。もちろん私も購入したが、授業のテキストを念頭に執筆されている背景は分かるが、余りにもハショリ過ぎである。内容自体は大切な事が書かれているので、清水氏の一ファンとしては誠に残念。このテキストを持参して、東海大学で授業を受けることができるのであれば、最高なのだろうが。
また、本の造り方も２０年前と変わることのない共立スタイル。「教科書というものは、威厳があり難しくなければならぬ」という社是でもあるのだろうか？SICP を見れば一目瞭然だが、難しいことと、読者が理解できることは、全く別物である。SICP が述べているような高度に抽象的なテーマであっても、優れた著作家の手になれば、平易な文章で読者は納得することができるのである。「小難しくて、訳分かんない」が、日本の理工学出版界が生み出したスタイルだと言っても過言ではないだろう。可哀想なのは、私達読者である。
ちなみに、現時点で amazon.co.jp における売り上げランキングは、「CPU の創りかた」が６位、「コンピュータ設計の基礎知識」が 38,681 位。売れる本が良い本とは限らない。それは分かっている。しかし、読者の心を掴むことができるというのは、とても大切なことだ。日本の技術者は、心の底で疎外感に悩まされている。だから、「どうして？」本が売れるのだろう。CPU の創りかたは、この市場に「萌え」と「CPU 本」を掛け合わせることで挑戦し、結果として大成功を納めたと言える。
おそらく、ほとんどの読者は「ノリ」で購入しているのだろう。読了後に一体何人の読者がハンダゴテを握りしめるのか、その数は知れているだろう。しかし、千人の中に一人でも、TD4 (Toriaezu Dousa surudakeno 4bit CPU)製作に取り組む読者がいれば、本書が日本にもたらす貢献は２０年来の快挙だと私は思う。
読了後、直ちに TD4 製作体制に入った。「これで読むだけやったら、男がすたる」わね。「はじめに」の中で著者も言っている「一生に一度も CPU を作らないのは末代までの恥・・といった意味不明で素敵な発想が出来る人」。私って素敵？
さて、こうなると辛いのが田舎ものの悲しさである。田んぼや畑はあるが、秋葉原・日本橋はない、どこにもない。この現実をどう受け止めるか？通信販売も良いが、品揃えが今一だし、時間もかかる。思い立ったが吉日、パーツはすぐ欲しい、明日欲しい。
こんな田舎者の願いを叶えてくれるのが、「アールエスコンポーネンツ」だ。まだ利用したことはなかったが、日頃の情報検索からこの会社のサービスが迅速であることを知っていたので、無料カタログだけは取り寄せておいたのである。これが、今回役だった。週日の午後６時までに発注すれば、なんと翌日には届くらしい。「ホンマか〜〜！」
ホンマでした。詳細は、また後日。最後に「はじめに」から著者の言葉を引用しておこう。
「CPU を作ったことがある」というココロの肩書きは一生有効です。 ええ、経験というモノは死ぬまでタダで使えます。 最速ＰＣの賞味期限よりは長いはずです。
御意。
本業と執筆作業に追われ、すっかりメモのアップデートが遅れてしまった。アカンアカン・・。
いつも思うのだが、ソフトウェア野郎よりは、ハードウェア野郎の方が、遙かにハートが熱いような気がする。私が知っているハードウェア野郎の中で主だった方々は、いしかわきょうすけ氏、成松宏氏、ChaN 氏だが、このお三方のページを拝見するにつけ、「あ〜、ワシもハードウェア野郎になりたい！」と妄想しまくるのである。「これだけ自在にハードウェアを操ることが出来たら、どれ程人生が豊かになることだろう・・」と、本気で考える。
日頃プログラミング関連のサイトを訪ねることは多いが、ここまでの衝撃と感動を受け取ることは、極めて稀だ。自作というのは、農業・工学・陶芸など、分野の違いを超えて、とてつもないパワーを秘めているものなのか？
でも、これまではいつも妄想するだけであった。日本が誇るマイコン野郎達には、到底及ぶべくもないのだが、私も TD4 自作を契機にして、新しい世界に向けてジャンプアップしてみたい。果たしてどんな世界が待ち受けているのだろう？
ネット上を徘徊していると、時としてとんでもない情報に出会うことがある。本日出会ったベルメックスインターナショナルがまさにそうだ。同サイトの「モデルエンジニアリング」のページに曰く。
当社で展示してある模型は実物を完全縮小したスケールモデルであったり、 実物と全く同じ構造になっておりますので、石炭の火力で水を蒸気に 変えてその圧力で動く古き良き時代のメカニズムそのままです。 動く模型を作ることは奥が深く一生楽しめるホビーです。
エンジンを自作するんですか、自作の蒸気機関車にまたがるんですか、爺さんになっても一生楽しめるんですか・・絶句。さらに「ミニS/L鉄道を開業しよう」というページは、思わず背筋も凍る(?)ような内容である。再び曰く。
ヨーロッパでの小規模農園の経営は人件費の安い国からの農産物の流入や 大規模農業との競争で経営的に成り立ちません、したがって古くから ミニS/L鉄道などを取り入れて観光農園として経営している農家が 各地にあります。
やはりヨーロッパって、凄い。ホビーひとつとっても、日本とは桁違いに奥が深いのよね。それにしても、まだまだ修行が甘いと痛感。世の中は広い。そして、ハードウェア野郎は万国共通「熱い」のだ。
先にも書いたが、ハードウェア野郎(もしくは予備兵)にとって、地方というハンディキャップは大きい。当然のことながら小さなパーツショップ、もしくは通信販売に頼らざるを得ない訳だが、昔とは違い通販の充実ぶりには目を見張るものがある。私自身がこれまでに利用したサービスの中から、いくつかご紹介しておこう。
先日も書いた通り、私はＣ言語を体得するためには、まず最初に機械語を理解する必要があると考えている。現在、具体的にどのようなアプローチでアセンブリ言語からＣ言語への橋渡しを実現すれば良いのか、その方法を模索している最中だが、今日は先日作成した Toy code を紹介しよう。以下は、RDTSC 命令を紹介した際に使用したコードを若干改変した、simple_func.c である。
int simple_func(void); // Declare simple_func as an
// function entry address
asm("simple_func: "); // simple_func entry address
asm(" movl $123, %eax "); // return 123
asm(" ret ");
int main() {
return simple_func();
}
お馴染みのインラインアセンブラーを用いて、123 を返すだけの単純な simple_func 関数を定義している。その実体は、mov 命令と ret 命令の２つだ。
$ gcc -o simple_func simple_func.c $ ./simple_func ; echo $? 123
私達の意図通り、コードは正常に動作している。さて、ここからが面白いところ。simple_func.c に手を加え dump_func.c を用意した。
1 #include <stdio.h> // printf()
2
3 int simple_func(void); // Declare simple_func as an
4 // function entry address
5
6 asm("simple_func: "); // simple_func entry address
7 asm(" movl $123, %eax "); // return 123
8 asm(" ret ");
9 asm(" .byte 0x55, 0xAA "); // Mark the end of function
10
11 int main() {
12 unsigned char* p;
13
14 p = (unsigned char*) simple_func;
15 while ((*p != 0x55) || (*(p + 1) != 0xAA))
16 printf("%02X ", *p++);
17 printf("?n");
18 }
simple_func 関数の最終尾に .byte 疑似命令を用いて、0x55 0xAA の２バイトをマーキング代わりに配置した。ret 命令の後ろなので、関数コード自体に影響はない。次に、main 関数内部で simple_func アドレスからのメモリー内容を 0x55 0xAA が見つかるまで、ダンプさせている。
この時、１４行目のキャスト演算子 (unsigned char*) に注目してほしい。困ったことに、世の中で売られているほとんどのＣテキストは、キャスト演算子を説明する際に、int <--> float 間の型変換にしか言及していない。しかし、システムプログラミング上でキャスト演算子が活躍するのは、上記例のようにコンパイラーに対して、ポインタ変数が指すオブジェクトの型を伝えるケースがほとんどなのである。simple_func シンボルは、関数のエントリーアドレスであるが、(unsigned char*) キャストを用いることで、Ｃコンパイラーは simple_func を unsigned char 配列の先頭アドレスとみなすようになるのである。すなわち、「キャスト演算子の真の意義は、馬鹿正直なＣコンパイラーを騙すことにある」と言っても過言ではない。これは、Ｃ言語を縦横無尽に使いこなす上で、とても大切な認識だ。
にもかかわらず、時としてこの型変換を「まぁ、お行儀が悪いこと！」と、顔をしかめる先生方がおられるらしい。困ったことである。この状況は大学で行われる英語の授業に酷似している。英語の楽しさや素晴らしさを伝えることなく、やたらと文法だけにはこだわる教官。しかも目線の先は生徒ではなく、つまらないテキストだけに向いている。最悪だ。
ついでながら、業界的には、Ｃ言語の熟達度を知るためには「ポインタ変数を理解できているかどうか」がバロメーターになるらしい。が、私の見方は少々違う。私がＣプログラマーの力量をテストするのであれば、まず「ポインタ変数とキャスト演算子の組み合わせをマスターしているかどうか」をチェックするだろう。実際、ポインタ変数とキャスト演算子の組み合わせは、カーネル・ライブラリーソース中では山ほど登場する。世の中の教科書が教える int <--> float 変換は、システムプログラミング上ではほとんど登場しないのである。
話を元に戻そう。dump_func.c をビルドし、実行すると次のようになる。
$ gcc -o dump_func dump_func.c $ ./dump_func B8 7B 00 00 00 C3
この結果から、simple_func 関数の実体は 0xB8, 0x7B, 0x00, 0x00, 0x00, 0xC3 の計６バイトであることが分かる。先頭５バイトが movl $123, %eax 命令、最後の１バイトが ret 命令の機械語である。このようにポインタ変数とキャスト演算子を組み合わせることで、神聖な実行コードと言えども、ただの配列データとして取り扱うことが可能になるのである。この調子で、もう一段踏み込んでみよう。
1 #include <stdio.h> // printf()
2
3 int simple_func(void); // Declare simple_func as an
4 // function entry address
5
6 asm("simple_func: "); // simple_func entry address
7 asm(" movl $123, %eax "); // return 123
8 asm(" ret ");
9 asm(" .byte 0x55, 0xAA "); // Mark the end of function
10
11 unsigned char text[ 256 ]; // .text section holder
12
13 int main() {
14 unsigned char *src, *dst;
15 int (*fn)(void);
16
17 src = (unsigned char*) simple_func;
18 dst = text;
19 while ((*src != 0x55) || (*(src + 1) != 0xAA)) {
20 printf("%02X ", *src);
21 *dst++ = *src++;
22 }
23 text[ 1 ] = 88;
24 printf("?n");
25
26 fn = (int (*)(void)) text;
27 return (*fn)();
28 }
今度の create_func.c は本邦初公開であるが、なかなか面白いコードである。simple_func アドレスからのバイトデータを、text 配列に転送している(１７〜２２行)。ここまでは、dump_func.c の延長線だが、面白いのは２６行。なんと、text 配列の先頭アドレスをまたもやキャスト演算子を用いて、関数のエントリーアドレスへ読み替え、関数ポインター変数である fn にコピーしている。そして極めつけは、２７行で text 配列中のデータを実行コードとみなして実行しているのである！
神をも恐れぬ不届き者とは、まさにこのことであるが、こんな暴挙が許されて良いのであろうか？良いのである。
$ gcc -o create_func create_func.c $ ./create_func ; echo $? B8 7B 00 00 00 C3 88
オ〜マイガァ〜〜！実行できてしまったよ。あれ、何か変でないかえ？create_func プロセスの終了ステータスが１２３ではなく、８８になっているよ。
賢明な読者諸氏は既にお気づきのように、これは２３行で１２３を８８に書き換えているからである。このことは、Ｃ言語プログラムであっても、自分自身でプログラムを創造できることを意味している。
素晴らしきかな、ポインタ変数＆キャスト演算子。この２つがある限り「Ｃ言語は不滅です」。
GCC プログラミング工房書籍化にあたり、第１章をどうスタートさせるか、まる１ヵ月間悩んでしまった。連載を書籍化する場合、基本的には既存原稿ベースで進めるらしいが、第１回は２年も前の原稿である。私自身もその間に成長しているので、今読み直すとあちこちに不十分な点が目について仕方がない。
ということで、わずかに第１回の痕跡を残しながら、第１章は大幅加筆することにした(ちなみに渡辺編集長は最初からお見通しだった模様・・)。結果、完成した原稿は特大ホームラン級の内容に膨らんでしまった。１章だけで、全体の1/4以上のページ数書いてどうすんだよ＞我。
う〜〜ん、本当にどうなるんだろう。心配になってきた・・と思いつつ、編集長に送信。いつもいつも、すみませんです。
しかしながら、内容は自分でも納得できるレベルに仕上がった。今回重要視したのは、binutils/GCC を使ったビルドの全体像である。Ｃプログラムのビルドは、「前処理・コンパイル・アセンブル・リンク」の４工程で構成されるが、gcc hello.c を実行した際に、舞台裏で一体何が起きているのか？その一部始終を白日の下にさらしつつ、ひとつひとつの作業の「意味」を解説できたと思う。
４工程の中でも、リンクは最大の難所であり、連載中でもほとんど触れていなかったのだが、今回この鬼門に真っ向から挑んでみた。正直、これは非常に手強い強敵だったが、おかげで collect2 コマンドにおける、crt (C RunTime startup)、ライブラリー指定の技術背景を、初めて明らかにすることができた。
その一部を簡単にご紹介しよう。まずはお決まりの hello.c である。
#include <stdio.h> // printf()
#define MESSAGE "Hello, world!?n"
int main() {
printf("%s", MESSAGE);
return 123;
}
どうということはないソースリストである。これを普通にビルドすると・・
$ gcc -o hello hello.c $ ./hello ; echo $? Hello, world! 123
となる。当たり前である。いや、「これまでは」当たり前のこととされてきた。しかし、この「当たり前」の中にこそ、開発ツールを使いこなすためのノウハウが山ほど隠されているのである。ここで、-v オプションを追加して同じコマンドを実行してほしい。
$ gcc -o hello hello.c -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem= posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ hello.c -quiet -dumpbase hello.c -version -o /tmp/cctU6LlJ.s GNU CPP version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (cpplib) (i386 Linux/ELF) GNU C version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (i386-redhat-linux) compiled by GNU C version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). ignoring nonexistent directory "/usr/i386-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include /usr/include End of search list. as -V -Qy -o /tmp/cccGbXzm.o /tmp/cctU6LlJ.s GNU assembler version 2.13.90.0.18 (i386-redhat-linux) using BFD version 2.13.90.0.18 20030206 /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o hello /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crt1.o /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crti.o /usr/lib/gcc-lib/i3 86-redhat-linux/3.2.2/crtbegin.o -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2 -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../.. /tmp/cccGbXzm.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtend.o /usr/lib/gcc-lib/i386-redha t-linux/3.2.2/../../../crtn.o
-v (Verbose) は連載中でも何度も登場したオプションだが、gcc ドライバーによるコマンドの実行状況を表示するためのものだ。-v を指定することで、私達は gcc の裏側で一体何が起きているのかを、初めて知ることが可能になる。
それにしても、これはまさに「呪文」である。訳が分からない・・というのが、ほとんどの人の反応だろう。だからこそ、このダンプリストに隠された「本質」が、現在に至るまで封印されてきたのかもしれない。
さて、この暗号を丁寧に解き明かしていくと、その本質は以下のようになる。
$ `gcc --print-prog-name=cpp0` hello.c > hello.i
$ `gcc --print-prog-name=cc1` hello.i
$ as -o hello.o hello.s
$ ld -o hello /usr/lib/crt1.o /usr/lib/crti.o hello.o /usr/lib/crtn.o -lc -dynamic-linker /lib/ld-linux.so.2
驚くほどシンプルになったが、この４行で gcc が出力したコードと同じものが出力される。「ビルドって、シンプルじゃん！」本書を手にした読者の方々が、この境地に達することができるよう、さらに精進しよう。
skyfree.org での連載フォローアップが停止したままである。申し訳ございません。tDiary の手軽さに慣れてしまうと、重戦車のような GoLive を起動して HTML を編集する生活にはもう戻れない・・。ということで、tDiary base でサポートページを再開する予定。
本日、注文していた「パリティの 2003 年６月号」が届く。目的は、この号に掲載された翻訳記事「相対論とＧＰＳ」にある。
原著は、「Physics today 2002' May」に掲載されたコロラド大学教授 Neil Ashby 氏の記事だ。
秒速４ｋｍで高度２万ｋｍをぶっ飛ぶ Navstar 衛星における時間の進み方と、地上におけるそれはことなる。その誤差が測位距離に与える影響は、１１ｋｍにも及ぶというのだから、凄まじい。アインシュタイン博士は、この誤差に潜む謎を数式で解き明かした訳だが、この恩恵により現在のＧＰＳがもたらされている・・というのが、その趣旨だ。
残念なことに、数式アレルギーの私にはそのすべてを理解することはかなわぬが、時刻同期という一見単純なテーマの底に、物理学の基礎理論が活躍する素晴らしさは、十分理解できる。ちっぽけな人間が、数式を駆使することで、自然がもたらすブレの中から、極限の精度をもつ真の時間を見つけ出そうとする姿は、感動すら与えてくれる。
ＧＰＳ誕生の過程を詳細なドキュメントにすれば、これは最高に面白い読み物になるに違いない。ただし、この場合著者には数学と物理学の本質を素人にも分かるレベルで説明できる能力が求められる。誰か、「萌える数学」、「萌える物理学」、「萌える相対論」を書いてくれないだろうか？
それにしてもアメリカはやはり偉大だ。Ashby 氏のようなＧＰＳ界の重鎮が、物理好きの一般読者のために、身近なＧＰＳと相対論を結びつけるレビューを執筆するというのが、凄い。このセンス、日本では考えられないことだ。久々に、一流研究者の姿を垣間見たような気がする。入門者の視点に立てる研究者というのは、極めて稀である。
学位審査は日本の大学院生にとっても恐ろしいものである。普段おちゃらけた連中でも、さすがに審査日が近づくと目がつり上がり、寡黙になる。
その内容だが、「うむ、確かにこいつは博士としてふさわしい」と納得できるだけのプレゼンテーションをこなせる大学院生は、実はごくわずかである。中には「なんでこいつが博士やねん？単なる棚ボタちゃうんか？」という不届きな輩も確かにいる。それも結構な数だ。
噂というのは、悪いことの方が絶対速度は遙かに大きいので、「あの素敵な先輩を見習って、大学院で研究に打ち込むぞ！」とはならずに、「あんなボンクラ先輩でも、お情けで学位取れたらしいよ。仕事は全部上の先生がやったらしいけど・・」となる訳である。よって、大学内部における博士号取得者に対する評価はないに等しい。
「これっておかしいんちゃう？」私は常々、日本の学位審査に疑問を持っていた。この疑問の正当性を証明してくれる、衝撃的な手記を先日配られた学報に発見したので、紹介しよう。
その手記とは、「フィンランドで学位審査を体験して」と題するものである。これは、著者が University of Joensuu 物理学科における学位審査員に外部招聘研究者として参加した際の体験を綴ったもの。余りにも面白いので、大学の広報担当に「この記事をネット上で公開する予定はないのか」と尋ねたところ、目下「学内のみの公開となっており、その予定はない」とつれない返事。来春から独立行政法人化するという、この期に及んでも、いまだ親方日の丸なのだ。先が思いやられる。
とは言え、この貴重な手記を一地方大学の中だけに留めておくのは、あまりにも惜しいので、私の知見・意見も加えて、ダイジェスト型式でまとめておく(過激な箇所はすべて私の文章である)。
フィンランドにおける学位審査は、論文審査を行う２名の「reviewers」と、 最終口頭試問を行う「opponent」が担当する。日本やアメリカとはことなり、この３名は全て「学外」の専門家でなければならない。
日本では、学内で仲の良い教授同士が「まぁ、よろしいんじゃないでしょうか」と茶番劇を演じている風景はよく見られるが、フィンランドでは「何をか言わんや」ということになる。
そして、フィンランドの学位審査の厳しさを象徴するものが、Ph.D. 最終口頭試問、いわゆる「Ph.D. Defence」である。Ph.D. とは、Doctor of Philosophy の略であり、万国共通で「博士号」として通用する(哲学だけを意味するのではない)。
審査を受ける当の本人を「candidate」、審査員を「opponent」、そして彼らの仲裁役を「custodian」と呼ぶ。
これらの言葉からイメージできる通り、最終口頭試問はアカデミックな「戦い」なのだ。
この栄誉ある戦いは、大学関係者だけでなく、candidate の親族・友人・恋人も含めた 一般大衆も参加可能な公会堂で行われるが、３人は燕尾服着用でうやうやしく入場する。
この様子は http://eve.physics.ox.ac.uk/Personal/suominen/promootio.html を見ると、よく分かる。正式には、燕尾服に加えて、特注のシルクハット、そして大学のエンブレムが打ち込まれた「刀」の三点セットが必要なのだそうである。学位審査は、本来研究者の命をかけた戦いなのだ。実際、この最終弁論で失敗した candidate は、その後の研究者人生を諦めることもあるという。
candidate は自分の学位論文の内容を「専門家以外」にも分かる言葉で、約２０分をかけて「presentation」を行い、その後 candidate vs opponent の戦いが始まる。
これは学会でもそうであるが、その力量が試されるのは、発表者よりもむしろ質問者である。どうでもよいような、枝葉末節にこだわる質問を得意げに浴びせかける質問者というのは、どこの世界にもいるもの。経験ある研究者から最も嫌われるのはこの手の人間である。研究の本質を貫くような、鋭い質問が期待されているのだ。そして、一流の教授連中は、一連の質疑応答を実に注意深く観察している。会場の後ろで観察していると、彼らが「どいつが切れ者で、どいつがアホなのか」、一瞬にして看破してしまう様子がよく分かり勉強になる。フィンランド人が口頭試問で手にする「刀」は、決して飾りではないのである。
大学の既定によれば、この戦いは「４時間以上は続けるように」とあるらしい。この長丁場を candidate が乗り切り、opponent も十分と判断すると、「final statement」に入る。この中で opponent は「私は candidate が学位論文を成功裏に defend したことを認め、彼に Ph.D. を授与することを Faculty に進言する」と言い渡す。
口頭試問が終了すると、雰囲気は一変し、会場の外で candidate によるコーヒーとケーキが振る舞われる。和やかな雰囲気の中、candidate の母親が opponent である著者に語りかけた言葉が印象的だ。
「息子が大勢の人の前であなたから叩きのめされる姿を見ることになったらどうしようと、不安で仕方がなかった」
刀を携え緊張した面持ちで会場に向かう candidate、固唾を飲みながら口頭試問を見守る親族の姿、若き挑戦者に決闘を挑む opponent。いずれも日本では決して見られない光景だ。フィンランドでは、学位審査の厳しさを皆が知っているからこそ、Ph.D. が尊敬され、評価もされるのだろう。
「仏作って魂入れず」、現在の日本における学位量産体制は、まさにこの言葉に尽きるのではなかろうか？
上の手記を読んで、ふと思い出したことがある。あるシンポジウムが終わった後の、立食パーティーでのことだ。アメリカでの研究生活が長かった講演者と話す機会があったのだが、この中で「目からまぶた」級の面白いお話を伺った。
アメリカでは Debate がよく行われるが、この時同じ分野で「相反する主張」をもった複数の演者を招くのが慣例だそうである。ここからが面白いのだが、当人達は発表当日くじを引かされる。そのくじの先には、発表のお題がかかれているのだが、これらはいずれも「敵方のテーマ」なのだそうである。
例えば、Torvalds 氏が MINIX、Tanenbaum 教授が Linux 擁護派として、熱い議論を交わす光景を思い浮かべて欲しい。または、あるプログラミングテーマを与えられ、指定時間内にまつもと氏が Perl、Wall 氏が Ruby でコーディングに挑戦する光景でも良いかもしれない。
つまり、アメリカの優れた研究者には、独善に陥ることなく、敵対者の短所ばかりでなく、優れた点も冷静に把握できる懐の広さが求められているのである。そして聴衆は、全く逆の立場におかれた演者の言動や立ち居振る舞いをつぶさに観察することで、その人柄や能力を見抜く訳だ。恐るべし、アメリカ。
ついに「CPUの創りかた」が、あのスラッシュドットジャパンに登場した。10月８日のことであるから、いささか遅いような気もしたが、現時点で１００を超えるコメントが寄せられている。スラッシュドットジャパンの中では盛り上がった部類に入るのだろう。
さて、その内容だが残念なことに、いずれも薄氷のように薄いものばかりだ。これは、スラッシュドットジャパンに限らず、「匿名性」をベースに成り立っている２チャンネルなどにも共通した特徴である。
スラッシュドットジャパンには「編集者」なるものが存在するようだ。編集者を英語訳すれば Editor だが、本家 Slashdot のトップページにそのような項目は存在しない。どうも日本のオリジナル表現のようだが、彼らはこの言葉の意味を正しく理解しているのだろうか？
研究者の間では、一流雑誌の Editor ともなると、スーパーマンのような存在である。輝かしい業績を積み、学会にしかるべき貢献を果たした研究者だけが到達できる、極めて数少ないポジションだからだ。Editor によって癖はあるものの、超一流研究者の眼力は本物で、世界中から投稿された膨大な論文は、まず最初に彼らの「ふるい」にかけられる。もちろん、この選別理由は Editor のサイン入り書面で、投稿者に伝えられる。この厳しいふるいをくぐり抜けることが出来た論文だけが、複数の「reviewer」に送られ、専門家による厳しいチェックを受ける訳だ。
こういう厳しい世界で何度も Editor に泣かされた経験を持つ人間の目からすると、スラッシュドットジャパンで彼らが「編集者」を名乗っている姿は、何とも不可思議にして滑稽に思える。
「読者受けしやすいソースを選別する」という作業があるとは言え、彼らは鋭い考察を付けるわけでもなく、読者に丸投げしているだけである。にもかかわらず、自らを「編集者」と名乗ることには何か理由があるのだろうか？この点、本家 Slashdot においては、淡々と "Posted by *****. ##### writes..." と綴られているだけであり、選者を特別な存在として取り上げてはいない。これなら、了解できる。
また、見ていて面白いのは、日米間における署名欄の違いである。Slashdot の FAQ に "匿名で投稿できますか？" という項目がある。その答えは、次の通り。
We do, however, reserve the right to refer to you as an Anonymous Coward, and mock you mercilessly.
日本語で言えば、「どうぞどうぞ。でも世間からは情け容赦なく "臆病もののスカタン！" となじられまっせ」というところか。随分厳しい表現である(どっちが)。インターネットという公の場に、自分が書いた文章を投じる以上、その通りだと思う。実際、本家 Slashdot 上の発言を見ていると、そのほとんどに個人の URL が記載されていることに驚かされる(ペンネームも多いけれど)。Anonymous Coward による発言も散見されるが、そのスコアのほとんどはゼロである。つまり、名前も名乗らないような人間の発言には、誰も見向きもしないということだ。
それでは、スラッシュドットジャパンはどうだろうか？こちらは、Anonymous Coward の嵐である。しかも、それらのメッセージはかなりのスコアを獲得している。これを単なる文化の違いと済ませて、良いのだろうか？
アメリカでは Blog community が大流行しており、私も勉強がてら本日 TypePad なるものに挑戦してみた。登録作業を開始すると、Profile の画面中に 次のような項目が現れる。
Your One-Line Biography Describe yourself in one sentence. Your Extended Biography Enter the full biography that you'd like to appear on your About page.
実名どころか、「Blog community へ参加する前に、自分が何物であるのかを明らかにせよ」という訳だ。大人である。今の日本において文責という言葉は、もはや死語になってしまったのだろうか・・。
さて、本題に戻ろう。スラッシュドットジャパンにおいて「CPUの創りかた」に対して１００を超えるコメントが寄せられたのは、既に述べた通りだが、この中の誰一人として「TD4 製作に取り組んでみた」とは言っていない。出版後間もないコメントとは言え、そのほとんどが「通りすがりのエトランゼ」なのだ。
なぜだ？なぜこれほどの名著に対して、見過ごすことができるのだ？「しらふ」でいられるのだ？それとも、私の頭がどうかしているのだろうか？
この２０数年間手に取ってきたコンピューター和書の中で、「この内容であれば世界に通用する」と確信したものは、わずかに２冊。１冊は「はじめて読む４８６」、そしてもう１冊が「CPUの創りかた」。独創性、本質の掴み方において、後者は圧倒的に優れている。私にとっては、間違いなくここ数十年を代表するコンピューター書なのだが、世間はただ単に「面白がっている」ようにしか見えない。かえすがえすも、残念なことだ。
この本で描かれている TD4 は、実に用意周到にデザインされた４bit CPU である。芸術的と言っても良い。巧みに設計されたオペコードとそのオペランド、論理回路への反映。CPU の本質を TTL わずか１０個に封じ込めた著者の実力、そしてそのセンスたるや、世界的レベルにあると言える。
試しに Google で、TTL による CPU 設計を検索してみるとよい。８bit CPU であればかなりの数がヒットするが、４bit は意外に見当たらないものである。嬉しい事に、我が日本でも、４bit CPUをテーマにした授業が鹿児島大学で行われている。その名も ICS4004 というものだが、これとて３０個以上を必要とする(実に良く練られた教材なので必見。このような授業がある限り、日本の未来は明るい！)。
確かに、TD4 では RAM アクセスできないなど、重要な機能が削除されている。しかし私に言わせれば、この「削除」が一番難しいのである。不要な枝葉を削ぎ落とし、必要最低限の枝だけを残すことは、誰にでもできる仕事ではない。だからこそ、２０年もの間、本書に匹敵するテキストが誕生しなかったのだろう。
さらに付け加えれば、本書を出版したのは、CQ 出版・誠文堂・技術評論社・共立出版・オーム社、いずれでもない。毎日コミュニケーションズである。これだけの偉業が、なぜ老舗ではなく、新しい挑戦者によってなされたのか？その意味を私達はよく考える必要がある。
読者にできるのは購入を通じて、「この本に匹敵する良書をもっと提供せよ！良い本であれば、我々は喜んで買う」と、日本の出版界にアピールすることだ。その一方で、悪書には決して手を出さない姿勢が求められるが、このためには厳格な「書評」システムが必要である。残念なことに、今の日本に読者の信頼に応えることができる書評は、存在しないからだ。
この連休は楽しい楽しい TD4 製作のはずだったのに、原稿執筆に追われる(トホホ・・)。１０台分はあろうかというパーツに後ろ髪を引かれる思いで、GCCプログラミング工房・第２３回の下調べを続ける。
カーソル制御、ＯＫ。ビットプレーン２への、フォントデータダウンロード、これもＯＫ。当初は、90x60 テキストモードにも挑戦するつもりだったのだが、残念ながらページ数が尽きてしまった。もう１回延長か？それとも、いよいよ RS-232C か、どうする？
さて、テキストの正体が VGA では B800:0000 から始まる VRAM であることは、比較的良く知られている事実である。しかし、「なぜ B800:0000 なのか？」この素朴な問いに答えることが出来るプログラマーは、世界広しと言えども、それほど多くはないだろう。
この問いに答えるためには、VGA chip の最深部まで踏み込んだ知識が必要とされるのだが、困ったことにその詳細を述べた書籍が既に絶版になっているのだ。それは、Richard Wilton氏による「Programmer's guide to PC Video Systems」。日本語版は 1989年に出版された「PC&PS/2 ビデオシステム・プログラマーズガイド」だが、こちらも当然のことながら絶版。
どうしてもこの聖典を入手したければ、amazon.com の古書サービスを利用すると良いだろう。ただし、古書販売サービスを amazon.com から請け負っている業者のほとんどは、配達先をアメリカ国内に限っている。残念なことに、日本への発送は拒否されてしまうのだ。
目の前にぶら下がった人参を口にすることが出来ない、お馬さんの気分だが、この無念をはらすためには、「転送サービス」が有効である。現在、色々な転送サービスが存在するようだが、私はここ数年来 Cat Fish Club を利用している。手数料が少々高いのが玉に傷だが、サービスは丁寧で確実である。アメリカだけでなく、ヨーロッパの中小企業なども日本向けには発送していないお店が結構な頻度で存在するため、ハードウェアのパーツなど小物を取り寄せるときには、大層威力を発揮する。
ネット上で公開されている情報としては、FreeVGA Project が決定版である。詳細な VGA 全レジスターの入出力インターフェースが網羅されている。ただし、この内容を理解するためには、やはり上に紹介したようなリファレンスを通読しておく必要あるので、鶏が先か卵が先か、というジレンマに陥ることは否めない。
さて、オリジナルＯＳ構築に取り組んだプログラマーが最初に突き当たる壁は何かと言えば、画面モードの切り替えだろう。画面モード切替をすべて自分のコードで記述することは、至難の業だからである。このため、わざわざプロテクトモードから ROM-BIOS を呼び出すＯＳも、少なくない。
そんな時にお手本のコードとして役立つのが、Chris Giese 氏による modes.c である。このソースを読みこなすことが出来れば、もはや ROM-BIOS など無用の長物となる。
昨今の出版界は本が売れぬと悲観的だが、私はそうは思わない。「CPUの創りかた」が、2800円という値段にもかかわらず、発売後一瞬にして売り切れた事実を考えてみて欲しい。どれだけの読者が、その本質を理解できているのかは分からないが、彼らが本書がもつ独創性と群を抜いた明快な解説に惹かれたことは、間違いないだろう。
つまり、読者は「本物」を求めているのだ。好い加減な解説や書籍にはほとほと辟易しているのだ。私自身もそうである。CPUの創りかたが、たとえ 28000円であったとしても、喜んで購入していただろう。この本には、それだけの価値がある。実際、これまで購入したまま山のように積まれた論理回路解説書の合計金額は、この金額を遙かに上回るからだ。
今の日本に必要なものは、大学や専門学校ではなく、日本語による優れたリファレンスではなかろうか。当然のことながら、リファレンスが生まれるためには、渡波氏のような卓越したライターの存在が必要不可欠である。
しかし、これまでの歴史を考えると、同氏に匹敵する著者が再来するのはなんと２０数年後である。私はもう白髪の翁である・・。あの世に行く前に、少なくともあと１０冊ぐらいは、良い本を読みたい。冥土のみやげに持っていきたい。となると、是が非でも優れた若きライター達がスクスクと育ってもらわなければ困る。年寄りはとっても困る。我がニューロンは日々、死滅しているのである。
が、このまま黙っていては、無為に時間が過ぎるばかりである。学校が頼りにならないのは、歴史が証明している。商業誌にも、人を育てるだけの力はない。誰かが行動を起こさない限り、物事は前に向いて進まないということだ。
そんなことを日々考えながら、ふとした思いつきで、昨年夏、旧 skyfree.org 上で、"Brainstorming in Ehime" と題する勉強会の公募を行った。日本全国から、四国の松山市まで駆けつけてくださったのは、選りすぐりの６人。この日のために特別に作成したフロッピーディスク１枚を用いて、第一回は大盛況のうちに幕を閉じた。
参加してくださったのは、もちろん GCCプログラミング工房や、Interface 2002年7月特集号の熱心な読者の方々だったのだが、この会合を通じて、私は日本全国に素晴らしい才能を秘めた人達が溢れていることを知った。
そして、この人達にしかるべきチャンスが与えられ、彼らが著作や次の世代の教育に関わることができれば、「あの世に行くまでに世界に通用する日本生まれのテキストを１０冊は読みたい」という願いは、必ずや叶うに違いないと直感した。
人間一人が書ける原稿など、たかがしれている。私が腎虚になるまで書き続けたとしても、カバーできる範囲は微々たるものなのだ。しかし、幸い人間は「社会的動物」である。仲間を増やすことができる。互いに協力し合うことで、新しい大きな仕事を成し遂げることができる。
そんな思いは執筆２年目を迎えた今、ますます強まりつつある。そして本日、その夢の検証の場として Brainstorming を始動させた。果たしてどうなることか・・。
今週多忙のため、以下まとめて追記。
ふとしたことから、あの KEYENCE がデータ計測器を販売していることを知り、Web 上から資料請求を行った。初めてのことだ。で、四国の営業の方から電話連絡があり、早速お話を聞くことに。なんでも、川向こうの松下寿電子工業に毎週来られているらしい。
松下寿は、糖尿病患者の自己血糖測定センサーを開発しており、私も昨年お邪魔したことがある。この時、伺ったお話は大層刺激的だった。一時期、カセットテープ・レコーダーで世界市場の９割以上を支配していたり、Quantum から HDD の OEM 生産を請け負った際に、歩留まりを下げるため、世界で初めて HDD 生産にクリーンルームを採用した話など、まさにプロジェクトＸの世界。機会があれば、一度ご紹介できればと思う。
さて、KEYENCE である。こちらの話も、面白かった。私は分野が全く違う人との話は、大好きである。例えば、KEYENCE が誇る無接触型の厚み測定器が、実は西田家愛用の加ト吉の冷凍うどんに使われているという話。
知らんかった・・、あの冷凍うどんに KEYENCE の技術が使われていたとは・・。恐るべし、加ト吉。ちなみに、加ト吉の冷凍うどんファンの数は凄いらしい。特に、海外出張中のユーザーが多いと聞く。
ところで、冷凍うどんの話を取り上げたからには、「あのうどん」を取り上げない訳にはいかないだろう。数ある冷凍うどんの中で、加ト吉の製品は確かに高レベルを誇っているが、世の中には上がいるのである。
ズバリ、「日清冷凍食品の包丁切りうどん」は、私が知る限り銀河系一の冷凍うどんである。いや、少し謙遜して太陽系一か。惜しむらくは、値段が高いためほとんどのお店には置かれていない。よって、通信販売で注文する必要があるのだが、これが素晴らしい出来である。もちろん、本物の手打ちには及ばないが、近くにおいしいうどん屋がない場合は、これで耐え凌ぐことができる。私も、大阪単身赴任中は、いかりスーパーで日々包丁切りうどんを買い込んだものである。
あら、何の話だっけ？うどんじゃないよね。KEYENCE だよ。まぁ、いいか。おいしい冷凍うどんも、正確な計測器があってこそ・・というオチにしておこう。
ちなみに、某通販サイトで有名な「半生うどん」だが、これは止めておいた方が良い。消費者からの「こんなおいしいうどんに出会えて幸せです！」という書き込みに騙されて、私も購入したことがあるが、全くひどい代物である。現代冷凍技術の粋を尽くした、包丁切りうどんに及ばぬこと、約３万光年といったところか。
１０日以上をかけて、イギリスより CD-ROM 版 ELEKTOR がやって来た。この雑誌の存在は、先日紹介した OpenGPSRec で使われている PROTO-3 PCI prototyping board のページで知った。
で、同ボードが紹介されていた PCI 解説記事を読むべく、バックナンバーが納められた 2001 年版 CD-ROM を注文した。いや、正確には注文したつもりでいた。ところが、本日届いた郵便物の中身は、なんと 2002 年度版だったのである。激涙・・。
ショックの色は隠せないが、転んでもタダでは起きんぞと、中身をチェックする。「あら、面白い記事がたくさんあるじゃん！」と、すぐに機嫌が良くなり、ひたすらＰＤＦを印刷。
内容的にはＣＱ出版のトランジスタ技術に近いが、読者対象はよりホビースト向けという感じを受ける。ただし、文章の質、記事としての完成度は、世界向けの雑誌だけあり、ELEKTOR の方が上のようだ。参考文献の引用などは、商業誌とは思えぬほど充実している。大したものだ。
さらに特筆すべきは、各記事毎にパーツリストが添えられており、その殆どでプリント基板の有料配布サービスが利用可能になっている点である。ＰＣＢのお値段は、おおよそ２０００円弱といったところだが、日本にはないサービスである。これはひとつ、購読してみるかね。
「CPUの創りかた」でも紹介されていた 4bit ALU 74181 だが、当然のことながら、速攻検索。調べてみると、この IC はその昔 PDP-11 の周辺プロセッサ KMC11 にも採用されていたらしい。
しかし、何より心を動かされたのは、その美しい Logic Diagram である。あまりにも、美しすぎる・・。
で、購入するべく探したところ、日本では有名な若松通商・電子部品通販サイトが取り扱っていた。「CPUの創りかたは入手難と言っていたけれど、これなら楽勝じゃん！」私は大船に乗ったつもりで、74HC181 の到着を待った。
が、１週間立っても届かない。そのうち、自宅へ一本の電話あり。曰く、「あらゆる卸会社にあたってみたが、製造している会社が見つからず、手に入らない」とのこと。「そんな殺生な〜〜」である。渡波氏の言葉は本当だったのね、シクシク。
Never give up の精神で、google にて再検索したところ、ついに 74HC181 の在庫を持った通販会社を発見！すぐさま発注したのだが、本日最終確認の e-mail が到着。「２９個確保した」とのこと。気になるお値段は、１個あたり３米ドル。これで男のロマンが買えるのであれば、安いものである。
そのうち、Ｗｅｂ上で自作ＣＰＵコンテストでも開いて、賞品に使うことにしよう。まる。
自作ＣＰＵの資料は、世界中を探してもそれほど多くは見つからないが、Rex Fisher 氏による P8 CPU 解説資料は、一見の価値あり。ちなみに P8 CPU も、ALU に 74181 を採用している。
ＧＣＣプログラミング工房の原稿に使用するコードがまだ完成していない・・。数時間仮眠を取って、いざコーディング。追加するコードは VGA カード上における、アドレス変換の意味を理解するためのものだ。
「画面にテキスト文字が出る」、これはまるでリンゴが木から落ちるぐらい当たり前のことだ。しかし、なぜ文字が浮かび上がるのか？この問いに答えられる人は本当に少ない。恐らく、プログラミング人口の0.1%にも満たないことだろう。
なぜか？答えは簡単だ。ほとんどのプログラマーは、そのような仕組みを知る必要がない。printf と ＯＳが全ての作業を肩代わりしてくれるからだ。
しかし、必要がなければ知らなくても良いのだろうか？確かにほとんどのアプリケーションプログラマーにとって、VGA テキストの技術背景はオタク的知識以外の何物でもない。VGA の存在すら、意識する必要はないだろう。けれども、プログラミングの対象がデスクトップから、組み込み機器に移行すれば、そのような悠長なことは言っておられない。
組み込みの世界に printf という便利な代物はなく、自分の手で作り上げる必要があるからだ(もっとも最近は、組み込みの世界にまで統合開発環境が浸透しており、この限りではないが)。この時必要になるものは、メモリーマップや VGA register programming など、ハードウェアに立脚した知識である。日頃鍛えた「ライブラリー操作術」は、このような場面では、なんの役にも立たないことに驚く人も多いのではないだろうか。
昨今は、オブジェクトやデザインパターンといった抽象的概念が大流行しているようである。若い人が「先輩、ぼくアセンブラーというものを勉強してみたいんですけど、何から読めばいいですか？」と聞こうものなら、「そんなもので飯が食えるか！つべこべ言わずに、Java や Ruby でコードを書けるようになれ」、こんな返事が聞かれることだろう。
確かにそうだ。現代のプログラマーにとって、重厚長大なクラスライブラリーを使いこなせるかどうかは死活問題であるし、物事を抽象化して捉えるトレーニングも必要だろう。しかし、これだけで良いのだろうか？
歳を重ねるごとに痛感することがある。それは「全ての応用は基本の延長線上にある」ということ。基本の体得なくして、応用はあり得ない。
実例を挙げてみよう。オブジェクトや変数は、しばしば「箱」に例えられる。機械語の知識のない読者に対して、古来この「箱」は極めて有効な解説手段として使われてきた。しかし、多くの著者達が行ってきた、この安易な「逃げ」こそが、数多くのプログラマーの卵達を挫折に追いやったのではないだろうか？
箱モデルで、正確に変数・オブジェクトを解説することは不可能である。優秀な学生であれば、箱モデルで書かれた解説を読めば、その矛盾に悩むはずだ。変数への代入、ここまでは分かる。しかし、ポインター変数とは何なのか？参照演算子とは一体何物なのか？共用体ってなんなのよ？「箱モデル本」が、これらの問いに答えてくれることはない。なんという無責任さだろうか。読者はもっと、怒るべきである。
機械語レベルから変数・オブジェクトを捉えると、次のようになる。
変数・オブジェクトの実体は「メモリー」であり、オブジェクト参照の正体は、「間接アドレッシング」である。
「変数・オブジェクト」という抽象概念は、本来アセンブリ言語レベルの知識があって初めて了解することができるものなのだ。それにもかかわらず、誰も「君の頭の中のモヤモヤは、機械語を勉強することで、すべて解決する」とは言ってくれない。今や、機械語を知らずに教壇に立ったり、執筆を担当する人間の方が多いのであるから、無理もないのかもしれないが・・。
私は、自分の頭の中にモヤモヤを抱えることを一番のストレスと感じる人間である。プログラミングにおいて、Blackbox の存在は到底許すことが出来ない。そして、このモヤモヤを解消するためには自力で答えを見つけ出す必要があること、世の中の教科書やインターネット上の情報は殆どあてにならないことを経験的に知っている。
Blackbox を解体し、そのメカニズムを明らかにするためには、膨大な労力と時間が必要である。最深部まで到達することができず、挫折を経験することもしばしばだ。しかし、自力で頂上を制覇した時の快感たるや、言葉では表現できないものがある。文字通り世界は変わる。そして、次なる頂が視界に入ってくる。これが Linus Torvalds 氏が JUST FOR FUN で語っていた「Let there be light!」である。
私は、この感覚を一人でも多くのプログラマーに体験してもらいたいと切に願っている。VGA register programming は、「光」を見るために必要な道のりのひとつ。しかし、敵は手強い。メモリープレーンの切り替えに失敗しちゃったよ・・涙。という具合で、日曜日の朝を迎える。
記事中で使用する、全コードが完成する。昨日、バグだと思ったのは、どうやら VGA カードによりメモリープレーン中の未使用バイトへのマッピングがことなることが原因と判明。プログラムは正常に動作していた訳だ。ほっと一息。
早いもので、VGA シリーズは第２３回で３回目を迎える。初回は、テキスト VRAM をデバッガーで直接操作し、スクリーンに現れる文字の実体を知ることから始まった。
私自身が、テキスト VRAM 操作を体験したのは、PC-8001 が搭載していた ROM-BASIC の POKE 命令を通してであった。この頃は、まだ機械語が何たるかも知らなかったのだが、POKE で画面に字が現れ、アトリビュートコードをいじることで、色が変わりブリンクした瞬間の驚きと感動は、未だに忘れることができない。
PC/AT の VGA テキスト VRAM は、セグメント B800 に存在する。このセグメント内のオフセット０〜１番地が画面上の左上隅、9E〜9F番地が右上隅の文字に相当する訳だ。すなわち、２バイトが１文字を表現することになるが、この時偶数アドレスのバイトが ASCII コード、奇数アドレスのバイトが属性コードを現す決まりになっている。
ここで次のような疑問が生じる。なぜテキスト VRAM はセグメント B800 に位置しているのか？誰が B800 に決めたのか？なぜ ASCII コードと属性コードがチャンポンになっているのか？今回は、長い間封印されてきたこれらの謎が明らかになる。
ということで、今回の GCC プログラミング工房は、かなり高度な内容になった。VGA カード上のメモリープレーン制御プログラミングを行うことで、普段我々が目にしているテキスト VRAM の世界が、実は VGA chip が生み出した「幻影」に過ぎないことを知るのである。この事実を自分自身の目で確認するために、realvram.c プログラムを作成した。FreeDOS 上で実行した realvram プログラムの出力結果は次の通り。
Hello, world! 48 63 65 63 6C 63 6C 63 6F 63 2C 63 20 63 77 74 6F 74 72 74 6C 74 64 74 21 74 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 20 07 48 00 65 00 6C 00 6C 00 6F 00 2C 00 20 00 77 00 6F 00 72 00 6C 00 64 00 21 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 63 00 63 00 63 00 63 00 63 00 63 00 63 00 74 00 74 00 74 00 74 00 74 00 74 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00 07 00
このプログラムは画面クリアーを行った後に、ホームポジションに Hello, world! を色つきで出力する。その上で、セグメント B800 の先頭６４バイトの内容を最初に表示している。48 は H の ASCII コード、63 は属性コード、65 は e の ASCII コード、63 は再び属性コード・・と続く。これが、有名なテキスト VRAM であり、スクリーン上に表示されるテキストの正体、そのものである。ここまでは、比較的良く知られた事実だ。
それでは、２番目、３番目のダンプリストは何なのだろう？実は、これは VGA register programming を行うことで、VGA カード上のメモリープレーン０およびメモリープレーン１の先頭６４バイトをダンプしたものなのである。
あまり知られていないが、VGA カードには 64KB の大きさを持ったメモリープレーンが４つ、合計 256KB の RAM が搭載されている。メモリープレーン０には ASCII コード、メモリープレーン１には属性コード、メモリープレーン２にはフォントデータが格納されている。確かに、メモリープレーン０には ASCII コードのみ、メモリープレーン１には属性コードのみが格納されていることが分かる(２バイト単位)。
つまり、私達が普段目にしているセグメント B800 のメモリーイメージは、VGA カード上のメモリープレーン０とメモリープレーン１の内容を「交互に合成」したものだったことになる(Odd/even memory addressing)。俄には信じがたいが、これがハードウェア内部の真の姿なのである。
それでは、フォントデータを格納するメモリープレーン２はどうなっているのだろうか？多くの人が興味を持つであろうメモリープレーン２は、残念ながら普段はプロテクトされており、特別な VGA register programming を行わない限り、その内部にアクセスすることは出来ない。それでは、コードの力でプロテクトを解除してみよう。以下は、readfont プログラムの実行結果である。
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7E 81 A5 81 81 BD 99 81 81 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7E FF DB FF FF C3 E7 FF FF 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6C EE FE FE FE 7C 38 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
これはセグメント A000 の先頭１２８バイトを２回ダンプしたものだ。１回目はデフォルトの状態。通常、セグメント A000 にはメモリーが存在しないため、CPU からは何も見えない。ここで、メモリープレーン２の内容をセグメント A000 にマップするように VGA chip をプログラムした時の内容が、次のダンプリストである。
さっきまでは空っぽだった RAM 空間に、突如として３２バイト単位のデータ群が現れた。これが VGA テキストフォントの正体である。興味がある方は、このバイナリー値を２進数に直して並べてみると良いだろう。フォントの姿が浮かび上がるはずだ。
この知識を応用して、記事中では最後にフォントの書き換えに挑戦する。普段見慣れたフォントの姿を、自分の好きなデザインで変更してしまうのである。8x16 ではちと苦しいが、日本語も不可能ではない。恥ずかしながら、私も "GCCプログラミング工房" を VGA テキストで表現してみた。これが、結構いけて、楽しい。
ということで、記事の基本骨格となるコードとダンプリストが無事完成した。ここまで来れば完成したも同然で、半日をかけて文章を入れる。推敲を済ませて、渡辺編集長に送信。
秋の夜長に、VGA register programming を楽しんで頂ければ幸いである。
我が敬愛する「いしかわさん」のページで、Replica1の存在を知る。なんじゃこりゃ〜〜〜！思わず、目が点になる。
そう言えば、ちょっと前に Apple I のレプリカに挑戦している連中がアメリカにいる・・というのはどこかで見かけた気がするなぁ。そうそう、本家はここだ。とうとう、夢が実現した訳だね、素晴らしい。
で、早速本家で公開されている「System info」に見入る。いやぁ、この「Memory map」は面白いねぇ。最終尾２５６バイトのメモリー空間に位置している「Woz monitor」が光ってるなぁ。今時、モニターなんて完全に死語だもんなぁ。２５６バイトにモニターコードを納めるなんて、これぞ男のロマンだよなぁ・・。ほほぅ、E000 からの８ＫＢには、BASIC ROM が鎮座まします予定ですか。げげっ、カセットインターフェースも開発中ですとよ。懐かしいなぁ、Kansas city standard だよ、お兄さん。この歳になって、ピーヒョロが聞けるなんて夢にも思わなかったなぁ・・。
あ〜、ダメだ。重力には逆らえない・・ということで、レトロセットのページに辿り着く。懐かしの Apple II キーボードが、私を呼んでいる(呼んでないって・・)。
昨日の Replica1 に大層刺激を受ける(単純である)。Replica1 の画面出力回路はそのブロック図によれば、ATMEL の ATMEGA MCU とシフトレジスターを組み合わせただけの単純なものである。
テキスト表示回路の中身というのは、実は意外と簡単であり、PIC や AVR のような非力な MCU でも十分実現可能になっている。とは言え、実際に行動に移すことは難しい。
が、これを実践した偉大な人が我が日本におられるのである。これはトランジスター技術1997年5月号に掲載された、「ワンチップ・マイコンPIC 16Ｃ84でビデオ・ゲームを作る！！ワンチップ・ブレークアウト・ゲームの製作」という、タイトルを見ただけでも心躍る記事である。著者は、瀬戸口豊氏。
この記事が全国のマイコン少年(おじさん含む)の心を発火させた事は、言うまでもなく、様々なレポートがネット上に報告された(こちらとか、あちらとか)。テレビの前に置かれたトランジスタ技術の表紙が、泣かせるではないか。
この手の最近の記事としては、HAM Journal 2002年秋号に掲載された「PIC 16F628 を使ったビデオテキストジェネレータとナビトラ用レーダースコープ」がお勧めである。
「でも、どうせなら VGA でやりたいよね」、という悪魔の声にそそのかされて google。するとあった！ロシアの Lysenkov 氏による、「Generator of videosignal for VGA monitor on PIC 16x84」がそのページ。ちなみに、私の検索人生から判断すると、ロシアのハードウェア野郎やハッカーはとっても熱い。並みではないのである。
あらら、これで必要な材料は揃っちまったよ。もう言い訳はできんなぁ・・。ここはひとつ、PC/AT のパラレルポートを使ったコードを書いてみますか？
Replica1 は、私の心の奥底に隠されていた何かを解放してくれたようだ。８ビット時代の懐かしく甘い思い出が、凄まじい勢いでフラッシュバックする・・。
思えば、私のプログラミング人生の中であの頃が一番熱かったのかもしれない。実際、現在書いている連載ネタのほとんど全ては、浪人中の２年間に独学で培った知識がバックボーンになっている。
Replica1 は、私を育ててくれた８ビット環境が失われてしまったことの意味を、再考させる機会を与えてくれた。昔のオタクは高価なパソコンを購入できず、自慢のカセットテープ・ライブラリー持参でショップに日参したものだ。当時の支出は、月刊誌とカセットテープ代、この２つぐらいであるから、数千円にも満たない。けれど、マイコンオタクの心はお金では決して買えないもので、満たされていたはずだ。当時のショップに集う連中の目は、今思い出しても本当に生き生きとしていた。
これに対して現代のオタクは、自前のマシンはおろか、潤沢なパーツを買い揃えることができる。マザーボードやカードは、日々更新されるため、パーツ道に終わりはない。パーツ道とは消費の道である。創造の道ではないし、理解の道でもない。よって、いくらパーツを組み合わせたところで、彼らの欲望が満たされることはなく、フラストレーションと疎外感を解消するために、新しい買い物に走る訳だ。
こうしてみると、「彼らの救世主は８ビットマイコン、これしかないのではなかろうか？」と、ここ数日本気で考えるようになった。一個人が把握できるシステムとして、ちょうど良いサイズが８ビットなのだ。１６ビットは少々大きい、３２ビットなんてとんでもない。先日、Replica1 のメモリーマップを見た時に、この事を痛感した。
となると問題になるのは、８ビットマイコンである。Replica1 は少々高い。教育市場を考えれば、値段は１万円が限界だ。これはひとつ、真剣に考えてみよう。
がその前に、「カセットインターフェースをもう一度使ってみたいよね？」と再び悪魔の声がする・・。
で、ちょいと気合いを入れて検索した。が、思いの外ヒットせず。ひょっとすると、今でも PCI バス型式のカセットインターフェースカードが見つかるかと期待しのだが、なかった・・。Google を通じて、カセットインターフェースは、世界中で忘れさられつつあることが分かる。「そんなこと、おじさんは許さんよ！」と、息巻く。
辛抱強く検索を続けると、世界は広い、同志を何人か発見することができた。最初に紹介するのは、WikiPedia というサイト中の「Kansas City standard」という、そのものズバリのページ。カセットインターフェースを使ったことがない人も、その昔お世話になった人も、是非「この音色」を聞いてみてほしい。私は、泣きましたです、ハイ。と同時に、現代にこの技術を蘇らせるのじゃと、覚悟を決めました(日々この調子である)。
で、このページでも紹介されている「AC-30 Casstte Interface」だが、これはさすがに大袈裟過ぎ・・でも、貴重な一品である。
ということで、放浪の旅をしばし続ける。ソフトウェアインターフェース的な部分については、「THE ATARI CASSETTE」のページが優れている。ATARI 410 Program Recorder の技術仕様が詳細に書かれており、参考になる。ソフトウェア面は、この資料ひとつで間に合うだろう。
ところで、私は CASSETTE BOOT の項で、目が点になった。そうだよなぁ、男は黙ってカセットテープで起動だよ。リードエラーなしで、自分が書いたコードが起動した瞬間なんて、エクスタシーそのものだよなぁ・・。激しく妄想する。
しかし、まだ足りないものがある。ハードウェアだ。ソフトウェアだけの世界なんて、クリープを入れないコーヒーみたいなもんだ(古い)。最近、つくづくそう思う。で、丹念に検索を続けていくと、遂に目的の資料を発見した。「Commodore Cassette Interface」は、Linus Torvalds 氏も愛用していたコモドール・パソコンに採用されていたカセットインターフェースの仕様を、ハードウェアレベルから解説した、極めて貴重な文献である(一部画像が欠けているが、zip 型式の完全版 HTML ソース一式はこちら)。これは先日紹介した Elektor 誌に、1985年掲載された内容を公開したもののようである。なんてシンプルなのだろうか。これなら、私でも十分工作できそうだ。2003年、Matsuyama City Standard が誕生するのか？
昨日の検索で、おおよその見当はついたものの、私には当時のカセットインターフェースで使われていた FSK (Frequency Shift Keying)を裏付けするハードウェア的知識がない。しかし、さすがに２０年以上昔の技術に詳細に触れた資料はネット上に転がっていなかった。
しかし、大丈夫。我が日本には「ＣＱ出版のコピーサービス」という、世界に誇れるサービスがある。早速、トランジスタ技術のバックナンバーを探してみると、あるわあるわ・・。
思わず、ウハウハである。早速、トランジスタ技術コピーサービス宛に、現金書留を送る。１ページ１００円というのは少々痛いが、これで目的の情報が手に入るのであれば安いものだろう・・と言いたいところだが、送料込みで６９００円でありました(そりゃ、ページ数が多いんだよ)。せめて半額になればねぇ・・。ともかく、コピーが届く日が待ち遠しい！一日千秋の思いとは、このことだ。
表題の本が最近出版された。聞けば、「コンピュータ名著読書委員会が、コンピュータ出版史に残る歴史的名著を選出」したのだそうである。この本の出版があと一年先だったとして、「CPUの創りかた」は選出されただろうか？その目次を見る限り、おそらく否だろう。
選者はこうも言っている、「スピード時代は終わりを告げ、エンジニアの世界でも本質への回帰が叫ばれています」。その通りだと思うが、この１００選の中に本質を貫いた本は、一体何冊あるのだろうか？私が見た限り、SICP ぐらいしか思い浮かばない。選出された作品群の中で、私が読んだことがある本のほとんどは、枝葉末節にこだわり、幹を忘れてしまったものばかりである。
もうひとつ大切なことがある。１００選のほとんどは、海外で出版された本の翻訳である。日本オリジナルの本も、若干含まれてはいるが、この中に英語で翻訳され、世界的リファレンスとして支持されているものはあるのだろうか？
なぜ、世界に通用する教科書が日本から誕生しないのか？私達は、真剣にその意味を考える必要があるように思う。世界レベルに達していない教育環境が、生徒に「世界に通用する」ことを求めても、それは無理というものだ。
このような現状を考えると、ＣＱ出版というのは偉大である。インターフェースやトランジスタ技術の目次を見ると、日本語タイトルに加えて、英文のタイトルが付け加えられている。つまり、これらの雑誌は世界的な注目を集めていることになる。肝心の本文が英訳されていないとは言え、世界を視野に入れた技術系月刊誌が他にあるだろうか？しかも、先ほど紹介したように、ＣＱ出版は創刊時からの文献コピーサービスを提供している。
私に言わせれば、インターフェース・トランジスタ技術こそ、１００選にふさわしい存在である。この２冊以上に、日本の技術社会へ貢献した本を私は知らない。
さて、ここのところご無沙汰になっている「CPUの創りかた」だが、停滞している訳ではない。この本を通読した後、私の本能が「まだ手は付けるな」と警告しているような気がしたため、何が足りないのかしばらく考えていたのである。
もう一度、頭の中を整理してみる。CPUの創りかたの中から、自分にとって最も重要なページを１つだけ選べと言われたら、どうするか？私の場合は、迷わず１６９ページ。可愛いお姉さんが「迷ったらココに戻ってくるコト」とハタを手にしているイラストが印象的なページ。
この著者の本質の掴み方は、実に素晴らしい。クロックがつながったフリップフロップただひとつが、CPU の本質である転送機能を備えていると言い切っている(イラストも勘所を押さえている)。そして、次のページで NOT ゲートをつなぐことで、演算処理が可能な１ビットCPUを紹介している。この２ページを読むことで、読者は「演算命令は転送命令の修飾型に過ぎない」ことを知るのである。
おかげで開眼することができた訳だが、肝心な点が抜けている。フリップフロップが重要であることは分かったが、１７１ページからの「おまけ フリップ・フロップの仕組み」を読んでも、私にはその内容が理解できなかった。よく分からんのである。ここで思考が停止していた訳だ。
そこで本日、以前購入した秋田純一氏による「ゼロから学ぶディジタル論理回路」を引っ張り出す。恥ずかしながら、この本を購入した時は、カルノー図が登場したあたりで挫折していた。よって、本棚で埃をかぶっていたのだが、気になる存在ではあったので、CPUの創りかた読了後に再度挑戦してみた。
すると・・今度は分かるのである。「凄いぞ！＞俺」と半ば興奮しながら、読み進める。CPUの創りかたを通読することで、いつのまにか私には不完全ながらも論理回路の Overview が身に付いていたのだろう。フリップフロップの重要性も理解していたので、途中で放り出すことなく、第４章に登場する各種フリップフロップの解説を読み終えることが出来た。
一応その全体を読み終えたが、本書の白眉は何と言っても 4.2章 "記憶する論理回路：フリップフロップ" である。フリップフロップは以前から私を悩ませる存在であった。ぐるっと回ってニャンコの目ではないが、メビウスの輪のようなダブル NAND 回路は、人智を越えた存在だとばかり思っていた。
が、秋田氏は言う。情報の安定はインバーターペアによってもたらされる(これはさすがの私でも分かる)。そして、NAND 回路は、片方の入力を１にすることでインバーター、０にすれば出力は１に固定されるのだと。つまり、フリップフロップの正体とは、インバーターペアだった訳だ、素晴らしすぎる！
深夜遅く、私は再びアルキメデスの気分に浸る。神の啓示とは、こういうことなのかしらんと、愚考する。いずれにせよ、迷える子羊は救われた。こうなったら鬼に金棒である。これまで Black box だった、ラッチ・エッジトリガの技術背景も了解した。
残念ながら、本書の全体構成は中途半端であり、CPUの創りかたには大きく劣る。しかし、２冊を組み合わせることで、１＋１＝２ではなく０１＋０１＝１０になるのである。つまり一桁のオーダーで、情報の重みが増す訳だ。これは大切である。
この世に完全な書など存在しない。大事なことは、１冊１冊に含まれた本質を抽出し、得られた情報を自分の頭で統合整理する点にある。このためには、文献や書籍を著者の言いなりになって漫然と読み進めるのではなく、常に「情報の軽重」を意識し、日々のトレーニングを積む必要がある。
それにしても NAND というのは面白い。７４シリーズの中で、０番を冠しているだけのことはある。早速、ＲＳコンポーネンツに注文。到着を待って、フリップフロップの自作に挑戦だ！
日頃、ネット上で情報検索を続けていると、日本と海外における教育現場の違いに考えさせられることが多い。最近、北欧の教育現場において活躍する GBA 情報をいくつか発見したので、紹介しておこう。
まず最初は、スウェーデン・Halmstad 大学に通う学生お二人さんの登場である。Lysek, Persson の二人は、大学内の "Degree Project in Computer Systems Engineering" というプロジェクトにおいて、GBA 向けの ATA/ATAPI インターフェース GBA-CD を開発した。回路図の前に佇む彼らは、良い面構えをしている。見たところまだ若いのに大したものだが、このプロジェクトを積極的に応援した Halmstad 大学の対応にも感心させられる。大学からは、彼らのためにしかるべき予算が付いたと思われるが、このようなことが果たして日本の大学で可能だろうか？
そのようなことを考えながら Net cruising を楽しんでいると、偶然 Cypress の PSoC チップを使ったデザインコンテストの中に、「Educating Mario」という受賞作品を見つけた。これは、スイスの Nathan 氏が教育現場向けに開発したＰＣと GBA の通信モジュールである(いわゆるブートケーブル)。機能的には USB ブートケーブルには劣るが、その開発精神には目を見張るものがある。曰く、
We specialize in non-game applications for Nintendo Game Boy. Our products have been well received in Academic and Research markets, and we were asked to design a product for Middle and High school students.
通常、この手のケーブル販売は「ROM 吸い出し」を目的にしたゲームオタク向けに行われているが、著者が目指しているのは非ゲーム環境、すなわち "Academic markets" である。海外には、大学生のみならず、高校生まで念頭に置いた教育市場が存在し、彼らのためにより魅力的な教材を開発している訳だ。著者は次のようにも述べている。
GBA is an inexpensive, pocket size device, with color screen and full sound facilities. Sales of GBC (Game Boy Color) exceeded 1 million units a month, and GBA is expected to equal this performance. Its robustness rivals that of military grade equipment. All this at a price any student can afford.
GBA の堅牢さを軍用レベルだと表現しているのには参ったが、最後の一文は重要である。海外の優れた企業は、どの社も必ずこの視点を持っているし、実行している。翻って、我が日本はどうだろうか？
最後に、本日発見した超弩級のサイトを紹介。元々は、Rickard Gunee 氏の手になる PlayMobile が、きっかけだった。これは、同氏の修士論文(Master thesis)であり、GBA に Bluetooth module を接続し、無線通信を可能にしたものだ。１００ページに及ぶ論文は立派なものであり、Supervisor として Lund 大学の教官はもとより、Ericsson 社の技術者まで加わっている点が目を引く。彼は、論文の序文の中で次のように述べている。
During this project we enhanced our engineering knowledge as we developed an entire concept prototype from scratch, which meant that we had to solve many problems, ranging from hardware development to writing software applications. The people at Ericsson were very helpful and we would like thank everyone that helped us to make this project a success. First we would like to thank our supervisors at Ericsson, Magnus Hollstrom and Anders Borgstrom, for giving us the opportunity to do such an interesting project and giving us the trust to manage the project by ourselves. We also would like to thank our supervisor at the University of Lund, Jan Eric Larsson, for helping us with the report and presentation.
企業と大学が GBA という優れた素材を使った研究に、全面的に協力していることが分かる。このプロジェクトの中では、学生に主体性を持たせることが最優先され、問題は自力で解決するよう求められる。一方で、大学は徹底した writing と presentation の指導を行う。
この指導がいかに優れたものであったかは、彼の修士論文、そして彼のサイトが持つ卓越した内容から窺い知ることができる(サイトの内容については、余りにも凄いのでまた後日)。
最後に一言。GBA が教育現場で教材として用いられているという話を、私はまだ日本のネット上で見かけたことがない。少し目先が利いた教官であれば、GBA が５万円以上もする高価な組み込みボードよりも、遙かに優れた教材であることは、容易に分かるであろうに・・。
skyfree.org 上で「PIC プログラミング道場」を執筆していたＳ嬢が友人と共に、来松。PIC プログラミング道場は、私のサイトの中でもかなりの人気を博し、今でも「その後はどうなったのか？」と連絡を頂くことがある。
私の怠慢で尻切れトンボになっていたのだが、今春晴れて博士になられたＳ嬢は、若干時間の余裕が出来たらしい。聞けば、「是非とも機械語をマスターしたい」のだそうである。
「しかし、修行の道は厳しいのである。誰もが手軽に機械語をマスター出来る訳ではないのだよ。それでもやるかね？」という問いに対して、即座に「やります！」と。彼女の決心は固いらしい。心なしか、Ｓ嬢の目がウルウルしているように見える。秋晴れの空を見上げながら、二人は新しい門出に向けて、砥部焼きの絵付けに熱中するのであった・・(？)。
高級言語やスクリプト言語を自在に操るためには、アセンブリ言語・機械語レベルの知識が必要なことは、言うまでもない。一方で、BASIC や Ｃ の初歩レベルにある人達が、独学で機械語を習得することは、至難の技である。「機械語学習の必要性は頭では分かっているのだけれども、何から始めれば良いのか分からない・・」このような思いを秘めた人達は、全世界でかなりの数に上るのではなかろうか？
思い返せば、一人の人間がシステム全体を見渡すことが出来たのは、２０年前の８ビットマイコンまでのような気がする。６４ＫＢというメモリー空間は、今となっては猫の額にも満たないほどの広さだが、個人が好き勝手に暴れ回るには、これでも広大すぎる。１ＭＢ、１ＧＢなど、狂気の沙汰だ。過食はいけない。
とは言うものの、私達の身の回りにあるのはＧＨｚクラスの３２ビット・パソコンばかりだ。Replica1 という特殊なものもあるけれど、堅気の人達の手に届く範囲ではない。何より、高価である。
そこで私が一番最初に考えた候補が Microchip 社 の PIC である。日本でも秋月電子や書籍を通じて有名になったマイクロコントローラーだが、調べれば調べるほど、私の食欲は減退していった。理由は色々あるのだけれど、最大の理由はドキュメントが今ひとつであった点だろう。
PIC を探索している過程で、世の中のハードウェア野郎達の間で、すこぶる人気の高いマイクロコントローラーが存在することを知る。言わずと知れた ATMEL 社の AVR だ。これまで随分多くの会社のドキュメントを見てきたが、ATMEL 社が配布している文書群の品質たるや、ダントツ・ブッチギリの世界一である。先日紹介した Motorola でさえ、ATMEL には遠く及ばない。日本のデバイス企業など、月とスッポン、土俵に上がる前に勝負は付いている・・といったところか。
ATMEL 社の文書は、何が凄いのか？日本の企業には何が欠けているのか？これについては、いつかまとめるつもりだが、端的に言えば、ユーザーとの Eye contact を取ることができるかどうか、この点にかかっている。Eye contact はプレゼンテーションにおける、基本中の基本だが、その重要性を説く日本人は少ない。
なにがしかの授業をイメージしてほしい。ある教師は、目線を学生に合わせ、彼らの理解度を推し量りながら授業を進める。もう一人の教師の目線は、始終テキストと黒板にのみ向かい、学生と目を合わせることはない。良く見受けられる光景である。学会やシンポジウムでも、これと全く同じ光景を観察することができる。言うまでもなく、前者は ATMEL、後者は日本企業の姿だ。悲しいことだが、これが現実だ。
話を元に戻そう。教育上の観点から考えれば、学生に最もふさわしいマイクロコントローラーは、ATMEL AVR だろう。しかし、ここで立ちはだかるのが、「良いものが必ず売れる訳ではない」という法則だ。実際、AVR をベースにした優秀なキットは、日本では手に入れることが出来ない。
「それでも、ワシは AVR で勉強したいんや！」という、熱いハートを持った方には、ブルガリアの OLIMEX 社が販売している AVR ボードをお勧めする。私が知る限り、最もバランスが取れた AVR 学習キットである(しかも安価)。ブルガリアと言うと、ヨーグルトと新体操ぐらいしか知らなかったのだが、非常に丁寧な対応で、好感度大である(元々は 安価な PCB ボードデザインで有名な会社)。
ということで色々彷徨した挙げ句に辿り着いたのが、ルネサス(旧 日立・三菱)社の H8 シリーズ。正直、ATMEL の優れたドキュメントを知った後では、H8 の資料を読破するのは辛い作業だ。しかし、秋月電子の安価なキット、容易な入手性、GCC の対応状況、などを考慮すると、やはりこの選択肢しかないのである。
色々熟考した末、Ｓ嬢の機械語デビューには秋月電子の「AKI-H8/3664F タイニーマイコンボードキット単品」および「Ｈ８タイニーＩ／Ｏボード」を使用することに決定！(まだ商品が手元に到着していないので、変更の可能性あり)
驚くなかれ、ふたつ合わせて２７００円也である。これで16ビットレジスター16本を持った、16MHz CPU が手に入るのだ。しかも、CPU 内部には RAM 2KB、Flash ROM 32KB が搭載されており、RS-232C を通じて簡単にプログラム出来てしまうのである！全く、なんて素敵な時代になったのだ。こんな楽しいことを知らずにあの世へ参る訳には行かぬ。
Ｓ嬢よ、２７００円で機械語ワールドを飛翔するのじゃ！
実は週末の間、あるテーマをとことん追求した。それは「コンポジット信号の制御」。テレビとファミコンを接続する際に使う、RCA プラグと言えばお分かりであろうか。
私達が普段使っているパソコンの画面出力は、ご存じの通り RGB 出力だが、往年のマイコンが利用していたのは、最も原始的なコンポジット信号である。
GCCプログラミング工房では、register programming を通して VGA chip を自在に操ることを目指している。とは言うものの、所詮ハードウェアとの戯れに過ぎない。ソフトウェア野郎が到達できるのは、残念ながらこのレベルまでである。しかし、世界のハードウェア野郎達は、さらにこの上を行く。とってもとっても、悔しいではないか！
そこで、私はこの画像出力を、フルスクラッチで自作したコードで制御してやろうと目論んでいる。既に、多くのハードウェア野郎達が PIC や AVR を用いて、ブロック崩しなどに挑戦しているが、きちんとしたドキュメントはまだ存在しないからだ。
当初は、ありふれた VGA モニターへの出力を考えていたのだが、調査を重ねていくうちに、「NTSC をすっぽかしてはいかん！」と気付かされた。基本を疎かにすると、後でたたるのである。
で、先日紹介した Gunee 氏のサイトを足がかりにして、貴重な資料の数々をファイル１冊分ほど印刷した。同氏は、PIC および Ubicom 社の SX-28 CPU をベースにした、モノクロおよびカラーコンポジット信号の合成方法を丁寧に解説しているが、その内容もさることながら、参考文献の付け方が素晴らしい出来である。これはもう、学術論文のレベルと言っても過言ではない。おかげで、珠玉のリファレンスの山を前に、楽しく充実した時間を過ごさせてもらうことが出来た。感謝すると共に、Lund 大学における修士教育の充実度に舌を巻く。これこそが、教育の賜物だろう。
さて、まだ曖昧な点は多々残っているが、モノクロ・コンポジット信号の全体像はおおよそ把握できた。その中身はあっけないほどシンプルである。「モノクロテレビの映像信号の正体って、たったのこんだけ？」という感じ。
後は、オシロスコープで０〜１Ｖのアナログ波形を追い、タイミングにさえ気を付ければ、ビデオ出力ルーチンを作成することは、それほど骨の折れる作業ではないだろう。
と、納得していた。満足していた。正直言うと、トップページに書かれた「Mechanically scanned: Virtual Game System」という言葉が、心のどこかに引っ掛かってはいたのだけれど・・。
で、先ほど「何だろうなぁ？」とこのページをチェックして驚愕した。ぬわぁんと、ＬＥＤ１６個をＤＣモーター上でグルグルぶん回して、その残像を画像として空間に再現するというのだ！しかも、ピンポンやってるよ、テトリスやってるよ・・。
おじさん、腰抜けちゃったです、ハイ。何という発想の奇抜さ、素晴らしさだろう。以前、東急ハンズで振り子のように揺れるＬＥＤフラッシャーによるクロックを見かけたことがあるが、その３次元版という訳だ。しかも自作である。
調べてみると、この空間時計の起源は Bob Brick 氏による「Propeller clock」というもので、以後多くの亜種が世界中で生まれているらしい。Google のヒット状況を見る限り、日本のハードウェア野郎達は、まだ気づいていないようである。
コンポジット信号と言い、Propeller clock と言い、こりゃＨ８ボードのテーマとしては、最高だねぇ・・。
自宅に帰ると、秋月電子より H8/3664FP ボードなどが届いていた。素早いなぁ、秋月電子も今やＲＳコンポーネンツなみだね。
H8 ボードと言えば、これまでは H8/3048F が有名だった。私も何枚か持っていたりするのだが、3048 シリーズ には致命的な欠点がある。それは内部フラッシュメモリーの書き換えに、１２Ｖ電源が必要なこと。つまり、H8/3048F をプログラミングするためには、２電源が必要になるのである。これは大層不評だったらしく、最近の H8 シリーズは、５Ｖ単一電源で書き込み可能になっている。
H8/3664 は、3048 の機能を絞り込み、小型化を図ったものである。メモリー空間は１６ビット(64KB)に制限されており、搭載メモリもフラッシュが 32KB、RAM が 2KB と、3048 (128KB/4KB)に比べると一回りほど小さい。しかし、機械語の入門者にとっては、十分すぎるほどのスペックと言えるだろう。
3664 のパッケージには DIP (Dual Inline Package)に加えて FP (Flat Package) があるが、本日届いた K-159 キットは、後者を搭載しているため、40x27mm と驚くほど小さい。クリスタルを始め、RS-232C レベルコンバーターまで実装済みになっているため、ユーザーに必要とされる作業は、ピンコネクターをハンダ付けするだけである。なんと簡単なのだ。しかも、これだけの代物が１６００円である。つくづく、良い時代になったものである。
ちなみに秋月電子は、この基本モジュールに Windows 上の開発ソフトやライターソフトを添付したものを４５００円で販売している。拡張ボードが添付されているとは言え、２９００円もの差額は少々高すぎるのではなかろうか？
ほとんどの Windows ユーザーにとって、開発ツールは未だに「購入」するものなのだろう。私も１０年前まではそうだった。しかし、今は違う。開発ツールは、自分で「ビルド」するべきものである。
思い返せば、２０年前の私は「コピー」という原罪を背負いながら Lattice C を使っていた。心のどこかに、「悪いなぁ」という後ろめたさがあった。当時のＣ/Pascal コンパイラーには、１０万円を超える値段が付けられていたからである。私の原罪を払拭してくれた GNU 開発ツールと PC-UNIX 環境に、心から感謝したい。
さて、この「超小型 H8/3664FP ボード」だが、そのままでは使えない。別売りの「H8タイニーI/Oボード」と接続することで、RS-232C・電源回路(006P 使用)が提供される設計になっている。それぞれ１６００円、７００円であるから、なんと２３００円で乾電池駆動の高性能CPUボードが手に入る訳だ。
そして、H8 シリーズを何より特徴づけている点は、特別な外部回路を用意しなくても、RS-232C を通じて、ホストＰＣから手軽に内部フラッシュメモリーをプログラムできることにある。これに対して、AVR や PIC では、内部フラッシュをプログラムする際に、かなり煩雑な手順が必要であり、専用のライター回路を必要とする。私はこのメリットを高く評価し、最終的に H8 CPU ボードに落ち着いたのである。
さて、気分はＨ８モード全開。ひとつ、H8 クロス開発環境を整備してみますか？あ、Linux 上のライターソフトも書かないとね。
本日、ルネサステクノロジより、"H8/300H シリーズプログラミングマニュアル" および "H8/3664 グループハードウェアマニュアル" の２冊が届いた。
実は、一昨日の月曜日に同社のＷｅｂを通じて、「印刷版は入手可能でしょうか？」という、質問を送った。同社が販売している CPU 関連資料のすべては、ＰＤＦとして公開されている。しかし、私は古いタイプの人間なので、印刷物を常時手元に置き、好きなときに妄想を膨らませながらデータシートを読みたいのである。残念ながら、プリンター出力の資料では役不足。私としては「有償でも良いから」というつもりだったのだが、何と無料で立派なマニュアルが届いてしまった。印刷されたデータシートを入手したのは、２０年前の NEC uPD シリーズ以来のような気がする・・(もちろん有償だった)。
届いたマニュアルは「こんな立派なものをタダで貰って、ええんやろか？」と思うほどの出来。白いカバーとルネサスの赤いロゴがマッチした、美しいデザインだ。昨日、みそくそに書いた後に、なんという豹変ぶりだろうか？いや、優れたサービスには素直に感謝し、評価を示すべきだと、私は思う。足りないところは、みんなでフィードバックして行けば良い。
さて、現在Ｈ８の解説書はいくつか販売されているが、私の印象は「プログラミングテーマがつまらん」の一言につきる。「お前の言うとることは、つまらん！」とかいう、コマーシャルがあったと思うが、まさにその通り。
これは、Ｈ８に限らず、プログラミング書でもそうだ。テーマが余りにも凡庸・単調で、読者の知的好奇心を呼び起こすには程遠いものが多い。これは、恐らく著者達自身が、プログラミングの楽しさを知らないからではなかろうか？もちろん、中には素晴らしい独創的な題材を掲げた著書もあるが、極めて稀である。
授業も同じこと。単なる Duty として講義をする教師と、「これを学生に伝えたい」という熱い思いをもって講義に臨む教師の間では、雲泥の差がある。
さて、我が掌中にある２３００円のキットに、どのようなイメージを吹き込むか？ひとつ、真剣に考えてみよう。実は、この時間が一番楽しいのだけどね・・。
Net cruising している間に、またまたとんでもない代物を見つけてしまった。"Floppy the Robot" は、米国 Goodwin 大学の Fran Golden 氏によるフロッピーディスクドライブで駆動するロボットである。同氏のサイトでは、丁寧にその製作方法が解説されているが、その冒頭にこう書かれている。
The floppy drive has all of the motors and electronics you need to get started and compete in a robot contest.
言われてみればその通りで、フロッピーディスクドライブにはＤＣモーターはもとより、ステッピングモーターも搭載されており、ロボット製作の素材としては、最適である。
それにしても、海外の教官はどうしてここまで COOL な発想ができるのだろう？それとも、私達日本人が、体の芯まで「消費漬け」になっているのだろうか？今の日本は、あらゆることがお金で済まされる時代。生徒も教師も読者も出版社も、工夫する前に、お金で「解決したつもり」になっているのではなかろうか・・。
健気に走り回る Floppy のビデオクリップを見ながら、ふとそんなことを考えた(ちなみに 3.5' フロッピーディスクドライブの回転数は 300 rpm)。
Floppy に刺激されて、若かりし頃のめり込んだ FDC 765 (Floppy Disk Controller) を思い出す。
IBM-PC のフロッピーディスクドライブ制御には、日本が誇る NEC uPD765 FDC が採用され、Super I/O は未だにその互換機能を搭載している。そして、この FDC 制御は数ある I/O programming の中でも、最高に exciting な部類に入る。私の感覚では、VGA register よりもさらに面白い。なぜなら、FDC は Golden 氏が述べているように、「メカ」だからである。
自分が書いたコードでステッピングモーターを動かし、ヘッドをロードし、セクターを読み書きする。この操作の間、シーク音やヘッドロード音、モーター音など、様々な音が私達の耳に入る。裸のドライブを観察すれば、動きも目に入る。さらに、一般には知られていないディスクフォーマットの最深部は、麻薬のように刺激的である(read diagnostic command を発行することで、ディスク上のデータのビットパターンを観察することが可能になる)。これほど面白いプログラミングテーマは、なかなかないだろう。
残念なことに、FDC の直接制御方法を解説した書籍は、私が知る限り我が日本のコピープロテクト関連書しかなく、いずれも絶版になっている。また、ネット上でも十分な資料は公開されていない。どうしてもリファレンスが欲しければ、インターフェース誌のコピーサービスを通じて入手することが可能であるが、これらの記事を読みこなすためには、専門的知識が必要となる。
ということで、来年 GCC プログラミング工房上で、FDC programming をシリーズで執筆する予定。VGA, RS-232C, タイマー,割り込み処理,FDC。このあたりまで片づけば、オリジナル OS 構築も夢ではない。Let there be light! は近い・・かな？
本日帰宅すると、インターフェース・コピーサービス係から、依頼したコピーが届いていた。ちなみにトランジスタ技術は、未着。ページ数が多いので、手間取っているのかしらん。
さて、インターフェースより届いた文献はふたつ。ひとつは「1ビットプロセッサによる自動ドア制御の実験」、そしてもうひとつは「カセット・インターフェース --ソフト化の極限--」というもの。
前者は、バックナンバーのタイトルを眺めていて、「なんじゃこりゃ？」と思わず反応して注文してしまったもの。「1ビットで命令コードをどないして処理するねん？！」と、混乱していたのだが、届いた記事を読んで納得。レジスタ長が１ビットという意味だったのだ。レジスター１ビットでも、ここまで出来るのね。自動ドアさん、ご苦労様です。これでまた、自動ドアに対する世界観が変わったなぁ・・。
さて、問題のカセットインターフェースに関する文献だが、わずか２ページであるにもかかわらず、なかなか参考になる内容だった。インターフェース回路も、コンパレータ 3302 とフリップフロップそれぞれ１つを必要とするだけであり、おそらく最もシンプルなのではなかろうか？
ビット単位で同期を取るため、テープ走行の揺れはなんと±３０％の範囲まで対応できるらしい。しかも、これだけの安定性を誇りながら、速度は1000ボー。Ｈ８のカセットインターフェースは、こいつで決まりですか？
同記事によると、本回路のオリジナルは、1977年に BYTE 誌で発表されたものらしい。困ったことに、その原典が記事中に記載されていなかたったので、早速 google。目指す原著のタイトルをここで発見。
Rampil, Breimeir 両氏による "The Digital Cassette Subsystem, Part 1: Digital Recording Background and Head Interface Electronics" が、該当記事らしい。う〜〜ん、読みたい！このサイトを歩き回ると、1970年代の BYTE には、心ときめくタイトルがひしめいている事が分かる。何て素敵な時代だったのだろう・・。
ひょっとすると、BYTE のホームページ上において、過去記事が販売もしくは公開されているかと思ったが、お話にならず。ネット上にもこの記事は出回っていないようなので、何とかして入手しなければ。
それにしても、ＣＱ出版のコピーサービスは有り難い。McGraw-Hill 社 の対応を見て、再認識させられた。
