彷徨の果て、現在市販されている16bit MCUの中から、私のハートを射止めたのは、既に何度も紹介した Texas Instruments 社のMSP430である。
MSP430は、消費電流が1MIPSあたり250μA・待機時1μA未満という、超低消費電力が最大の謳い文句となっており、市中の電気・ガスメーター、血圧計やパルスオキシメーターなどの医療器具、テスター、果てはシューズなどに、幅広く採用されているMCUである。
アーキテクチャ野郎にとって気になるのは、まずレジスタ構成と、命令コードであるが、内部には16ビット汎用レジスターがR0からR15まで計16本、そして７つのアドレッシングモードが用意されており、Ｃ言語への最適化効率を強く意識した設計になっている。逆に、命令数は極限まで絞り込まれ、その数は驚くなかれたったの27である。基本的かつ必要最低限の命令セットのみが提供され、「足りない部分は、各自ソフトウェアで工夫して頂戴」という訳だ。
最近のMCUは、多機能化を計るあまり、ニーモニック(MOV, INC など命令の略称)を見ただけでは、一体何をする命令なのか、全く予想もつかないものが多い(中でも国内メーカーのニーモニックやポート名に対するネーミングセンスの悪さは際だっている)。結果として、プログラマーは新しい命令体系の習得および難解な略称名の暗記に、膨大な時間を費やされることになる。
これに対して、MSP430の場合は一瞥しただけで了解できる、汎用ニーモニックで構成されているため、過去にアセンブラーの経験があるプログラマーであれば、マニュアルをざっと斜め読みする程度で、命令セットの全体像を把握できてしまう。この分かりやすさが、初学者にも大きなメリットとなることは、言うまでもない。
よく練られたMCUはいくつか存在するが、MSP430が飛び抜けて際だっているのは、自身を支える豊富で良質のドキュメント環境にある。
先日、H8/300H に初めて興味を持ったユーザーが、Renesas Japan のサイトから、その製品概略を知ることは極めて難しいことを書いた。Texas Instruments ではどうだろうか？
まず、トップページでは、H8/300H と同じく１０行前後の要約が示されているが、先頭に示された次の一行は、これ以上の名文は考えられないほど、完璧にMSP430の特徴を言い表している。
The MSP430 family of ultra-low-power 16-bit RISC mixed-signal processors from Texas Instruments provides the ultimate solution for battery-powered measurement applications.
超低消費電力、16ビット RISC、Mixed signal processor、バッテリー駆動の計測機器に最適。この一文を読めば、経験あるエンジニアであれば、「ほー、アナログに強いTIのことやから、得意のADコンバーターやオペアンプ内蔵型の16bit RISC core MCU を出して来たんかいな。しかも、超低消費電力ねぇ、面白そうやんけ！」と来る訳だ。そして、読者の読みを予測したかのように、補足説明が下段で示されている(さりげなく値段も)。何気ない１０行に見えるが、実は練りに練られた文章であることが分かる。
この１０行、実は学術論文で言うところの "Abstract" に相当する。ちなみに、論文は通常以下のパートから構成される。
大学院生は、仕事が出来上がると、この枠組みに従い慣れない Paper work にいそしむことになる。誰もが最初は Results および Discussion にしか目が向かず、残りはケーキの飾りぐらいにしか捉えていないものだが、実は全てのパートが同じぐらいに重要なのである。一流誌になればなるほど、Reviewer (査読者)は Introduction から References に至るまで、実に細かく注文を付けてくる。また、経験を積むにつれ、Title と Abstract が持つ重みが分かるようになる。
PubMed (医学生物学文献データベース) や ACM Digital Library などで文献検索を行った場合、適切なキーワード設定を行っていれば、そこそこの数の文献一覧が表示される。このあたりの感覚は、Google と同じであるが、文献検索における違いは、論文のタイトルおよび Abstract をチェックすることで、非常に高い確度で論文の "選別" を行える点にある。
参考までに、ACM Portal Digital Library 上で "Plan 9" の検索を行った際、トップに現れる文献を挙げておこう。この文献は、Rob Pike 氏による Plan 9 の Overview であるが、平易にして明快な Abstract はさすがだ。このように、文献検索においてはその場で論文の絞り込みが行えるよう、必ず Abstract が表示可能になっている。ちなみに、Digital library 中の全文PDFを入手するためには、会員登録(有料)が必要だが、このあたりに関しては Google Scholar と併せて、後日取り上げてみたい。
さて、情報がこれほど身の回りに溢れてくると、玉石混淆の中から、自分にとって価値ある情報をいかに効率的に拾い上げるかが、重要になってくる。ヒットした文献を片っ端から読みまくり、質の低い論文に「あ〜ぁ、またしょうもない論文を読んでしまったよトホホ・・」と、溜め息をついているようでは、限られた時間を有効に使うことは到底出来ないからだ。こうして、短い Abstract から真贋を読み取る "嗅覚のトレーニング" を積まざるを得なくなるのである。嗅覚が犬並みに研ぎ澄まされてくると、不思議なことに書き方のツボも分かってくる。
推察するに、MSP430 の Abstract を担当した著者も、その昔トホホを経験したに違いない。そして、自分の経験から、駄文がいかに読者の貴重な時間を損なうものであるかを学び、優れた文書がいかに読者の理解と成長を助けることができるかを悟ったことだろう。
MSP430 のサイト全体からは、このようなトレーニングを積んだ著者(達)が、持てる力のすべてを注ぎ込みながら、ユーザーのために尽力している姿が伺える。中でも私が度肝を抜かれたのは、Abstract 中の MSP430 Family でリンクされた、PDF ファイル。合計９ページから構成されるこのファイルは、エンドユーザーを対象にした MSP430 の Overview である。中でも、２ページという限られた空間の中で繰り広げられる、図入りの特徴紹介は神業的な完成度だ。見事という他ない。このような良質で魅力的なパンフレットを見せられれば、初めてのユーザーも「ちょっと検討してみようか」という気になるだろう。
このほか、Publications や Contributed articles という、堅気の人は到底使わない Academic な表現がサイト上で使われているところから見ても、著者もしくはサイト監修者は大学院において徹底的なトレーニングを受けた、Ph.D. (博士号取得者)ではないかと思われる。
上記のように書くと、「会社が売り上げを伸ばすために、ドキュメント整備に奔走するのは、当たり前なのではないか？」という指摘を受けることがある。確かに背景はその通りであろうが、「上司から命令されたので書きました」という "させられ体験" から、優れた文書は決して生まれない。著者自身が文書の価値と意義を知り、なおかつ担当したテーマに "惚れ込んでいる" 必要がある。
まさに心意気の世界であるが、MSP430 の最深部まで踏み込むと、TI エンジニアの凄さが垣間見えてくる。
つづく
さて、理想の16ビットアーキテクチャを求めて、旅が始まった訳だが、ガンダーラへの道のりは決して平坦なものではなかった。途中の道中をつぶさに記述していくと、立派な連載が出来上がってしまうので止めておくが、いくつか重要な点を記しておこう。
私も日本人であるから、当初は国産MCUもいくつか下調べを行った。ところが、国内メーカーは、私のような一見客を最初から相手にする気がないのか、それとも彼らのプレゼンテーション能力自体に問題があるのか、Web 上に用意された資料のお粗末さは目を覆うばかりである。
具体的に、現在日本でベストセラーとなっているルネサスの H8/300H (旧日立)を見てみよう。トップページを開くと、H8/300H グループの一覧が家系図のようにズラズラと現れ、いきなり「どこ見ていいのか、訳分かんない」状態に陥る。
それでもめげずに、Overview を探すと "シリーズ概要" という項目の中に、H8/300H シリーズの特徴 というページが見つかる。「これこれ、このページを読めば概略が分かるのねぇ〜」と鼻歌交じりでクリックすると、一瞬我が目を疑うことになる。呪文にも等しいこの１０行から、私達に一体何を読み取れというのか？H8/300H というプロセッサに興味をもって訪れたユーザーに対して、これほど冷たい仕打ちはないであろう。
「まぁまぁ、ここは日本だから」と、切れかかった自分をなんとか抑えつつ、「概略が用意されていないなら、ドキュメントを見れば良いのよ」と、次に "ドキュメント一覧" をクリック。と、そこに現れ出でたるは、153行にもおよぶ H8/300H ファミリーのデータテーブル。どうやら、「自分の目的にかなったMCUのPDFを、勝手にダウンロードして頂戴」ということらしい。新しいアーキテクチャを理解する上で、極めて重要な意味を持つアプリケーションノートも、閑古鳥が鳴くほど寂しい品揃えである。
悲しいことだが、これらのページを見る限り、エンドユーザーに自社製品を理解してもらおうという姿勢は、微塵も感じられない。大口の顧客に対しては、ルネサス社からの手厚い技術指導が用意されているのかもしれないが・・。
教材として考えた場合、プロセッサの単純さや、命令コードの対称性が重要になることはもちろんだが、それ以上に大切なことは、優れたドキュメント体系が整備され、良質のサンプルコードが用意されているか、否かである。こうして、H8 は教材候補の中から真っ先に消えていった。
蛇足ながら、同じ Renesas でも北米のページは、日本のものとは少々趣がことなる。試しに、同じ話題を扱った マイクロコンピュータ ラインアップ と MPU and MCU を見比べてみてほしい。また、H8S family のページ上に用意された Architecture というページからは、複雑なファミリー全体像を図から理解してもらおうという、工夫の跡が伺える。レジスター構成図もきちんと添えられており、感心(というか、本来これが当たり前なのだが)。日米のこの差は、一体何に由来しているのであろうか？
その後も遍路を重ね、購入した評価ボードは数知れず。途中、Atmel 社 の AVR 嬢に、しばし心を奪われることになった。Atmel 社のドキュメント群は質が高く、Application notes も充実していることに、いたく感心。すっかり Atmel 贔屓になってしまったのだが、命令体系、中でもアドレッシングモードがMCU向けにかなり特殊であったこと、プログラム書き込みに別途ライターが必要であること、下位機種には JTAG が装備されていないことなどから、最終的に断念した。
一方で、AVR は Olimex を始め、優れた学習キットが市場に出回っているので、手軽に楽しむことが出来る。また、binutils/GCC も AVR をサポートしており、GNU 開発ツールを活用してマイクロコントローラー・プログラミングに挑戦したいという方には、お勧めのプロセッサーと言えるだろう。
つづく
しばらく連載執筆から遠ざかると、このようなちょっとした物書きさえも億劫になってしまう。日々の継続、そして大脳への刺激付けが大切というところだろうか。
GCCプログラミング工房を休載させて頂いた表向きの理由は、「書籍化に集中したいため」だったのだが、白状すると実はもうひとつあった。「今後、どの方向にテーマを展開していくべきなのか」、答えを見つけ出すことが出来ず、かなり煮詰まっていたのである。
PC-UNIX の魅力に取り憑かれ、ご本尊であるカーネルの踏破に挑戦する人々は多いが、この山は大層険しい。よほど基礎体力と才能に恵まれた人間でない限り、まず間違いなく"遭難"が待ち受けている。かく言う私自身も、「あ〜れ〜〜！」と何度滑落したことか。
未だ踏破できた訳ではないが、ここ数年のトレーニングの甲斐あって、周りの見晴らしは随分良くなってきた。山の頂きも、くっきり見える。以前のように、息切れすることもない。これなら、無酸素登頂も夢ではないだろう。問題は、登坂ルートをどこに取るかだ。
最近は、Linux や FreeBSD のカーネル解説書などが豊富に出回るようになってきたが、これらの資料だけでカーネルを理解することは、極めて難しい。私自身の経験から考えると、カーネル・ＯＳを理解するために、避けて通れぬ関門は以下のように３つある。
２番目については、これまで多くの解説が行われてきた訳だが、開発ツールとアーキテクチャについては、不思議なことにほとんど注目されることはなかった。むしろ、看過されてきたと言っても良いだろう。
カーネルの成り立ち、ひいては内部動作を正確に把握するためには、膨大なカーネルソースツリーから、一体どのようなコードとデータ構造が現れるのかを知る必要がある。PC-UNIX では、GNU 開発ツールが用いられるが、特に Linux では GNU ツール特有の、高度な使いこなしが随所で活用されている。このため、カーネルソースを読みこなすためには、GNU 開発ツールに通じることはもちろん、生成オブジェクトファイルおよび実行可能ファイルを規定する ELF 形式の内部構造も把握しておかねばならない。
GNU 開発ツールと ELF については、過去２年間の執筆を通じて、最低限知っておかねばならない勘所については、解説できたのではないかと思う。
残る関門はアーキテクチャであるが、IA-32 および PC-AT アーキテクチャは、あまりに壮大すぎて、どこから手を付けていいのやら皆目見当が付かない。手を付けるにしても、これまでアセンブラーや機械語に接した経験がない方々に対して、誰もが分かる明快な解説を書き下ろすことは至難の業、いや不可能に近い。
と、散々悩んだ挙げ句に、当時の私が出した結論が "仮想機械 Octopus" 編である。機能を絞り込んだ８ビットマシンのコーディングを通じて、レジスター・演算・スタックなど CPU の基本構造を理解し、FreeDOS 上での PS/2 キーボード・VGA カードプログラミング(いわゆるポート直叩き)を通じて、I/O 制御の意味とその素晴らしさを、読者の方々に体験して頂こうという、今にして思えばてんこ盛り状態の内容であった。
結果として中途半端なシリーズになってしまったことは否めなく、この頃からアーキテクチャ理解のための優れた素材探しが始まった。
無論、最初から 486 もしくは Pentium プロセッサを理解できるに越したことはない。私自身、486 の解説書執筆に向けて、これまで数え切れないほど構想を練ってきた。しかし、現在に至るまで、納得できるアプローチを見つけ出すことは出来ていない。
その一方で、私の青春時代の経験が、「たとえ８ビット CPU でも良いから、ひとつの単純なアーキテクチャを徹底的に理解することが、何よりも大切ではないのか？」とも言っている。
確かにその通りだ。PC-8001 を２０年以上昔のポンコツマシンと侮ることなかれ。この非力なマシンの中に、システムプログラミングの基本の多くは宿っていた。16ビットのアドレス空間は、今となっては鼠、いやノミの額ほどだが、それでも現在の初学者にとっては、十二分に広大な世界であり、壮大なロマンも秘めている。すっかり死語となってしまった Relocation という言葉も、16ビットの世界ではきらめきを取り戻す。
私を始めとする２０年前のマイコン小僧達の周りには、このように理解する上で最適のサイズをもつアーキテクチャが、ゴロゴロしていた。かの Linus 氏も、おじいちゃんから譲り受けた Commodore VIC20 (CPU 6502)を、最初にしゃぶり尽くしたらしい。８ビットマシンは、基礎トレーニングを積むためのファームとして、最適のものであったと言えるだろう。
これに対して、現代のパソコン小僧達は受難続きだ。何と言っても、最初に目にするパソコンが、いきなり Athlon64 である。64ビットなど、もはやビットを数える気力すら萎えてしまう。これ以上にはないほど複雑化したマシンを前にして、ゲーマーもしくはインストール野郎と化す彼らを誰が責めることが出来よう。人間、自分が理解できない代物に対しては、条件反射的に思考停止するものである。
以上より、一個人が理解できるサイズを持つ、最適の16ビットアーキテクチャを探し求める旅が始まった。この20年の間に生じてしまった、アーキテクチャの Missing-link を紡ぎ直すためだ。ちなみに命令コードも16ビット長であることを条件に加えたのは、Octopus での苦い経験に基づいている。8ビット長命令コードは、確かに単純ではあるが、その後の発展性を著しく欠いてしまうからだ。
つづく
最近は、もっぱら「にわか天文学オジサン」と化して、本屋の天文学コーナーを熊のようにウロウロすることが多い。そんな折り、オレンジ色の "なっちゃん" の中に PIC マイコンの基盤が埋め込まれた摩訶不思議な表紙の本を見つけた。そのタイトルを「上がれ!空き缶衛星」という。副題は "CANSAT PROJECT" となっているから、これは Can Satellite Project に違いない。
うっそ〜〜〜！？カンカンを衛星にするんですか？マジですか？表帯に書かれたキャッチコピーが、また泣かせる。
熱い思いと、仲間がいれば、きっと上がる！ 日本初の超小型衛星プロジェクトに青春をかけた工学部大学生たちの１年間の記録 熱血理科系ドキュメント！
と来たもんだ。裏帯のコピーは次のように続く。
机上でしか宇宙を知らなかった学生たちが突然、小さな人工衛星を作ることになった。 資金はほとんどない。 あるのは根気と体力と情熱、かき集めた皆の知恵だけ。 失敗の連続、思わぬ助っ人の登場、不夜城と化した研究室。 やがて、運命の打ち上げの日が来る・・・。
本書片手に、既に夢の世界へトリップしつつあった自分にふと気付く。「いかんいかん、この続きはお家で」
で、一気に読み切った訳だが、久々にムラムラとこみ上げてくる熱いものを感じた。読後感は、「なんで学生ばっかりこんな面白い事が出来て、税金払っとるオジサン連中には許されへんのや！」という、何とも自己中極まりないものである。正直、私はこの学生さんたちが、羨ましくて仕方がない。しばらくの間「オジサンはとっても悔しい、ウッキ〜〜！」と叫びつつ、Google 上でネタ元のチェックを行った。
残念ながら、本書の巻末には日本の NPO 法人である UNISEC (University Space Engineering Consortium) へのリンクが示されているだけであり、その後の感動的な CubeSat 打ち上げや、お世話になった AERO-PAC, ARLISS への URL が示されていない。"References" を欠いた学術論文は世の中に存在しないように、一般書と言えども出典は明示すべきであろう。
そこで、アメリカの偉大なるロケット野郎達と Twiggs 教授に心からの敬意を表しつつ、以下私なりに若干の補足をしておきたいと思う。
ハードウェア野郎に国境はないが、こと "ロケット野郎" に関しては、日本は大きな遅れを取っている。川島レイ氏が書き上げる空き缶衛星物語は、アメリカはネバダ州、Black Rock 砂漠を本拠地に活動するロケット野郎達、AERO-PAC (Association of Experimental Rocketry of the Pacific) の粋な心意気からスタートした。AERO-PAC のサイトを覗くと、トップページでは２匹のアライグマがロケットに乗ってスッ飛んでいる。素敵すぎる・・。
本書を読むと分かるが、この CanSat Project は缶ジュースサイズの超小型衛星の打ち上げを目的として、スタンフォード大学の Robert Twiggs 教授が発案したものである。記念すべき第１回のプロジェクトには、日本から東大および東工大の学生チームが参加したが、肝心の打ち上げロケットを調達することが難しかったため、ロケット野郎達の胸を借りて、地上4000mの高度まで打ち上げることになった。約１５〜２０分間の滞空時間を利用して、地上局との遠隔測定データの通信、パラシュート制御による目標点への最短着陸(comeback competition)などが、各参加大学チーム間で争われる。昨年の様子はこちらから伺うことが出来る。お勧めは、砂漠から打ち上げられるロケット映像。オジサンも Black Rock 砂漠で「ヒュ〜ヒュ〜」って、言ってみたいのである(マジ)。
この他、現地での ARLISS 活動の様子は日本大学のページがお勧め。砂漠を背に歩く、８人の学生諸君のカッコ良いこと！
詳細については、ARLISS (A Rocket Launch for International Student Satellites)のサイトを参照して頂きたい。トップページ上では、Black Rock 砂漠を背にして、バズーカ砲を二回りほど大きくしたようなごっついロケットを担いだサングラスのオジサンが、妙な迫力を持って読者に迫る(ひょっとして、この人が Twiggs 教授であろうか？)。
それにしても、同写真の下に掲げられたメッセージが渋い。曰く、
The Rocket Launch for Can Do Students
この短い言葉は、ARLISS プロジェクトの神髄を実に良く物語っていると思う。翻って、我が日本において "Can Do Students" を育てることは、果たして可能なのであろうか？
その後、CanSat は CubeSat に進化し、遂に人工衛星として、地球周回を果たす。まさに「オネアミスの翼」そのものである。UNISEC 上には、CubeSat 物語と題して、東大チームと東工大チームの手記がそれぞれ掲載されているが、ひとつの読み物として私達の心を捉えるのは東工大チームであろう。
中でも、打ち上げのクライマックス、「ピギャー」が聞こえた日のふたつは、読みながら思わず目頭がジンと来てしまった。第三者の言葉よりも何よりも、実際に製作に携わった学生達の生の言葉は、圧倒的な力を持っていることが分かる。それにしても、「体中の細胞という細胞から、涙が出たって感じでした」とは、なんて素敵な表現だろう。オジサン、完敗である。
最後に、エピローグに添えられた川島氏のメッセージを紹介しておきたい。
人生、先はわからない。 明日、生きているかどうかさえ、本当のところはわからない。 でも、あのとき、砂漠で彼らが強烈な一瞬を共有したのだということは、何があっても変わらない。 あの一瞬は、確かに彼らの十ヵ月の努力が凝縮したときだった。 ・・中略・・ たくさんのひとたちの努力が、その一瞬、一つになる。 同じ夢を、その一瞬に、いっしょに見る。 そういう想いが凝縮した一瞬は、永遠なのだと思う。 永遠に残る「一瞬」を自らの手で作った学生たちに、心からの賛辞をささげたい。
本書をきっかけとして、学生さんから "元気" を分けてもらったような気がする。川島氏の次回作、CubeSat 編に期待しよう。
色々考えた末に、全く新しい観点から「UNIX 入門編」を書いている。世の中には当たり前とされていることが多いけれど、深く考えてみると実は納得がいかないことばかりだ。
UNIX time はそのひとつ。Linux 上の man page は、ctime に関して次のように言っている。
The ctime(), gmtime() and localtime() functions all take an argument of
data type time_t which represents calendar time. When interpreted as an
absolute time value, it represents the number of seconds elapsed since
00:00:00 on January 1, 1970, Coordinated Universal Time (UTC).
"UNIX time" が、西暦1970年1月1日の０時を起点(UNIX epoch)にした「経過時間(秒)」であることは、良く知られた事実である。タイムスタンプやオーナーID など、UNIX ファイルのメタデータは、inode 上に記録されるが、Linux の場合、UNIX time は atime/mtime/ctime (この３つの使い分けが、また曲者なのだが)共に、32ビット符号付き整数として取り扱われる。と言ってもこのままでは「絵に描いた餅」に過ぎないから、実際に自分の目で確認してみよう。
$ touch test $ ls -l test -rw-r--r-- 1 wataru wataru 0 Nov 17 01:44 test
簡単である。ただ単に、touch コマンドで空のファイルを作成し、そのタイムスタンプを確認しただけである。次に、coreutils パッケージに含まれる stat コマンドに登場願おう。
$ stat test File: `test' Size: 0 Blocks: 0 IO Block: 131072 regular empty file Device: 302h/770d Inode: 29362 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ wataru) Gid: ( 1000/ wataru) Access: 2004-11-17 01:44:06.138216672 +0900 Modify: 2004-11-17 01:44:06.138216672 +0900 Change: 2004-11-17 01:44:06.138216672 +0900
察しの良い方は既にお分かりの通り、この情報は inode 上に格納された test ファイルのメタデータを人間様に読みやすい形式で出力したものである。これでは実感が湧かないので、-t (Terse) オプションを指定する。
$ stat -t test test 0 0 81a4 1000 1000 302 29362 1 0 0 1100623446 1100623446 1100623446 131072
この訳の分からない数値の羅列が「inode」すなわち test の正体である。それぞれの値が一体何を意味するのか？誰しもそう思うだろうが、驚いたことに man 1 stat 中にその答えはない。「ええ加減にせんかい！」とモニターを叱り付けながら、stat.c のソースを紐解くことになる。
その答えは省略するが、数値を見れば容易に予測がつく通り、1100623446 が目指す UNIX time である。根性のある方は、このバイナリー値から時刻表記を導き出してみて欲しい。
さて、上記の英語表現の中には、実は２つの「まやかし」が隠されている。１つは、"second" の定義である。古来、数多くの天文学者達がより正確な「秒の定義」を目指して、骨身を削ってきたが、その努力は今も続いている。1秒の定義は時代の変遷と共に、大きく変化しておきており、「1970年の１秒」と「1972年の１秒」は厳密に言えば違うのである。これは 1961年から1971年までが「旧協定世界時 UTC」に基づいているのに対して、1972年以降は「(新)協定世界時 UTC」に基づいているためである。
国際原子時(TAI)という絶対的物差しで見た場合、1972年は1970年よりも約２秒遅れている。よって、UNIX epoch は本来 "TAI - 8 seconds" (国際原子時に遅れること８秒)と表記すべきだと私は思うのだが、世界中どこを探してもそのような記述はない。唯一、あの D. J. Bernstein 氏が次のように述べている。
Arthur David Olson's popular time library uses an epoch of 1970-01-01 00:00:10 TAI.
Arthur David Olson 氏は、UNIX おける Time Zone に関して大きな貢献を果たしている一人だが、この "1970-01-01 00:00:10 TAI" という表記は私が下した結論に最も近い。D. J. Bernstein 氏が発表した clockspeed および libtai も含め、さらに深い調査が必要なようだ。「時間道は厳しい」が、時を巡る先人の苦労と知恵を知ることは、何よりも楽しい。
最後に、２つめのまやかしであるが、これは "UNIX time の時系" が明記されていない点にある。"since 00:00:00 on January 1, 1970, Coordinated Universal Time (UTC)" という表記を読めば、誰しも UNIX time は UTC に基づく時系だと考えることだろう。私も最初はそう考えた。
しかし、UNIX time と協定世界時 UTC は、全く違う。UTC は閏秒を含むが、UNIX time は閏秒を無視しているからである(POSIX も閏秒は無視すると明記している)。にもかかわらず、UNIX time と UTC が示す時刻は現時点で「一致しているように見える」。
本来両者が一致するはずはないのだが、この矛盾こそが UNIX における時間管理のアキレス腱となっている。Time Zone を適切に設定すれば、glibc は閏秒にも対応可能である。しかしながら、カーネルレベルでは、Linux はもちろん *BSD でさえ、その対応はおぼつかない。「時刻と時間」に関する正しい理解が、今こそ必要なのではないだろうか？