[TOPPERS] tf のシンタックスはなぜこんなに汚いのか？

昨日、やっとのことでリリースになったコンフィギュレータの最新版ですが、予定より大幅に遅れてしまい、各方面にご迷惑をおかけしてしまいました。そのこととは直接関係はないのですが、これをきっかけとして、たまにはコンフィギュレータのことも書いてみようか思います。今回の話題は、TOPPERS新世代カーネル向けコンフィギュレータの入力として用いるテンプレートファイルについてです。

新世代カーネル向けコンフィギュレータには、マクロプロセッサという一種のインタープリタが搭載されています。このマクロプロセッサは、テンプレートファイルというソースファイルを解釈実行することで、コンフィギュレータの詳細な制御を行うことができます。テンプレートファイルは、慣習的に .tf という拡張子を付けますので、tf という通称で呼ばれています。

TOPPERS/ASPカーネルやFMPカーネルに触れたことがあるなら（特にポーティングに関わったことあるなら）、この tf のシンタックスがいかに汚いかは知っているはずです。作っている私がいうぐらいですから間違いありません。そこで今回は、tf のシンタックスがこんなに汚くなった経緯について、少しだけ言い訳をしてみることにします。

TOPPERS新世代カーネルは、標準割り込みモデルというものを模索するところから出発しました。μITRONの割り込み関連の仕様は、実装依存の部分が多く、（割り込みに関しては）カーネルの実装は比較的容易であり、かつ効率もよかったのですが、数年を経て、CPUは速く、メモリサイズも大きくなった状況では、効率を若干犠牲にしてでも移植性を向上させるほうがメリットがあると判断したからです。

この標準割り込みモデルを実現するには、一世代前のJSPカーネルのようなターゲットに依存しないコンフィギュレータでは限界がありました。かといって、ターゲットが増えるたびにコンフィギュレータ自体を修正するのは現実的ではありません。そこで、必要最小限のターゲット依存部を生成するための「ひな形」を外部ファイルとして与え、その中のマクロを必要な文字列で置換する方法が考えられたのです。「マクロプロセッサ」や「テンプレートファイル」という呼称はここから来ています。

さまざまなプロセッサの割り込みアーキテクチャを調査していくと、単純なマクロの置換だけでは済まないケースがあり、簡単な条件分岐と反復が必要になりました。そこで、IFやFOREACHといった制御構造が導入されることになります。基本的なシンタックスはこのころ方向性が定まりました。

基本的な制御構造が使えるようになると、ターゲット依存部だけでなく、ターゲット非依存部の制御も tf を用いて記述できることがわかりました。ただし、ターゲット非依存部の tf は、もともとはコンフィギュレータ内部でのみ用いることを想定しており、カーネル開発者も含めた（コンフィギュレータの）ユーザーに公開するつもりはありませんでした。ところが、ターゲット非依存部を少なくともカーネル開発者に公開すれば、ASPやFMPなどのさまざまなカーネルにコンフィギュレータを対応させることが容易になります。そこで、当初の想定では、カーネルのポーティングを行う程度のエンジニアが触れることはないと思われたほどの、長く複雑な tf が皆さんの目の前に現れたのです。

こうした長い tf が多くの目に触れるようになると、細部のシンタックスにもいろいろな意見が出始めます。最初のころに出てきた意見に、IFやFOREACHのブロック内部を、見やすく字下げまたは改行したいというものでした。それまでは、字下げのためのタブや改行文字は、そのまま出力結果に反映されていたのですが、この要望を実現するために、SPC, TAB, NLといった変数を明示的に記述しなければならなくなりました。結果として、可読性が上がったのか下がったのか、かなりの疑問が残ります。

tf の複雑化が見え始めた時点で、実をいうと別の提案をしたことがあります。独自のマクロプロセッサはやめ、既存のスクリプト言語やマクロプロセッサを使ってはどうかというものです。候補もいろいろ検討しました。マクロプロセッサという意味では m4 が便利ですが、慣れないとかなり扱いにくいのでやめました。私としては、結合の容易さ、機能性、移植性、ライセンスなどを考慮した結果、Tcl を推していました。他には、埋め込み形のスクリプトという点では PHP も捨てがたいものがありました。ユーザーの多くがCプログラマであることを考慮しても、文法的に近い PHP には魅力がありました。他には、CINT を用いてC/C++を使うとか、AzaraCのような方式でC/C++を使うというのも考えました。

結局、そのようなフルセットの言語処理系を導入するのではなく、ごく簡単なマクロ置換＋αの機能でどうにかしようということで現在の方針になったわけですが、その決定とは裏腹に仕様は膨らみ続け、結果としてこんなに汚いシンタックスになってしまいました。

そうはいっても、ターゲット依存部だけを実装するエンジニアにとっては、当初の想定とそう変わらない程度の内容しか記述する必要はないはずです。（きっと陰ではいろいろな不平・不満が出ていると思いますが）直接要望としては上がってきていないので、おそらくこのままの路線で突き進むことになると思います。私としては、別のことも企んではいるのですが、取り組むための時間が割けるかどうかも分かりませんし、できたとしても、正式にリリースされるものに反映されるかどうかはまったく不明です。