TADが目指したものは何か:ドキュメント革命

たいそうなタイトルを付けてしまいましたが,TRONTADについての戯言です。

TADが,TRON Application Databusの略称であるところから妄想すると,これはBTRON上の共通データ形式を定義することだけが目的ではないことが見えてきます。

全てのデータを保存しておくのに必要な量の主記憶を装備することができないので,ファイルシステムにデータを置くことは間違っていないと思います。しかしながら,ファイルシステム上のデータの一時バッファのようにしか主記憶を使えない現状は何かが狂っているような気がしてなりません。

例えば仮想メモリ機構は正しいです。OSのメモリ管理機能によって,あたかも巨大なメモリがあるかのようにアプリケーションから扱うことができます。しかしこの目的と,単なるファイル置き場としてのファイルシステムの存在とがないまぜになっているところが直観的にひっかかります。

ファイルを扱うにはファイルアクセス専用のAPIやシステムコールを用いて特別な手続きをしなければなりません。アプリケーションを書く時,メモリの最大容量には気を払わなくても良い方向にOSは進化してきたといえます。これは隠蔽化であり好ましいと思います。けれどファイルはあいかわらずファイルであり,ファイルを操作する時,メモリはその一時バッファあるいはキャッシュとしてのみ用いられます。

多くのOSが,配下のリソースを「ファイル」として一元管理できるような指向を持っているようにも見受けられます(例.BSDソケットなど)これは大いに間違っているような気がするのです。なんでもかんでもファイルとみなすと言いつつその実態はファイルストリームです。ランダムアクセスが基準ではなくシーケンシャルアクセス可能なファイルにランダムアクセス可能な機構を取って付けただけのものに過ぎませんね。

原理から言えば,なんでもかんでもメモリに見えるようにするべきような気がしないでもないです。

なんでもメモリ」を解決するのがストリームならば,それでも良いです。けれどどうにも,ファイルを都合よく統合するためだけに編み出されたもののように見えます。本当に必要だったのは,
・柔軟にアクセス制限可能なメモリ
だったのではないでしょうか。アクセス制限の主目的は保護ですよね。触ってもよいプロセスとそうでないものを分離して,排他制御を行えるように。もちろんファイルシステムにも同じ仕組みは必要ですでに搭載されてます。
非常にきめ細かなメモリ保護と仮想化が可能なCPUであれば簡単にできそうな気がします。けれど現在主流のものでは役不足でもあったりします。

現在の主流で実現できないからといって,放置しておくのももったいないです。
この考え方とTADが目指した(であろうとごみため的妄想する何か)をかけあわせるとどうなるか考えてみました。

まず,頭の中からファイル/ファイルシステムを消し去ってみます。すると,メモリだけが残ります。このメモリは何らかの仕組みで不揮発性を持っているとします。

あるメモリ上のデータにアプリケーションAが情報を書き込む。別のアプリケーションBがその情報を読み出す。問題はそのデータを一意に特定できる仕組みです。名前が必要なら名前。唯一普遍なアドレスで表しても構わないと思います。同一メモリに対する排他制御にはアービタが必要となります。(まさにData-Bus!!!)アービタをOSの仕事とすればアプリケーションはシンプルにできますね。もちろんプロセッサが対応してくれないとパフォーマンスは出にくいでしょう。

びっくりするくらい同じことが,
http://www.os-omicron.org/~takano/doc/virtual_paper.html
に書いてありました。どうやら,Multicsにおいては,メモリ管理そのものがTAD風らしいです。(ごみため的解釈)むしろ,TADがmulticsに影響を受けていると考えるべきなんでしょうか。TAD=電紙,と考えると分かりやすいような気ががします。

なぜ,V4なのか?
「電紙」が前提とするデータ管理を実現するには,通常のデータ管理機構(Unix FS, etc)では,問題がある.通常のデータ管理機構は,ストリームベースで実装されていることから,リンク付けされたデータを扱うには,リンク付けされたデータの合成と分解が必要になる.なら,もっと簡単にリンクを含むデータを扱えないか,という着想から採用したのがワンレベルストアである.
さらに,ユーザが定義可能なユーザ属性など,OS自体に拡張性が必要になる.そこで,マイクロカーネルアーキテクチャを採用した.V4の詳細はそのうちwww.os-omicron.orgにまとめたいと思っているけど.

実装
少し,実装よりの話をすると,「電紙」はセグメントとして実装される.V4では,単一2次元アドレス空間を採用しており,アドレスはセグメントIDとオフセットの組(32bit + 32bit = 64bit)で指定する.Multicsの多重2次元アドレス空間とは異なり,Opalなどのようにすべてのタスクでアドレス空間を共有しているので,単一2次元アドレス空間なのである.
言うまでもないが,セグメントはCPUレベルのものである.V4がターゲットCPUをIntel x86にしている理由はここにある.gccが使えないのも,セグメントを利用しているからである(もちろん,完全に無理ではないけど).セグメント操作命令はすっごく遅いので(誰も使わないからIntelも高速化しないし),セグメント操作命令が瀕出するCATのコードが遅いのもうなずける.って,それでいいの!?
数年前には,CATにセグメントをエミュレートするコードを吐かせて,Alphaで動かすかと言う話もあったけど,今ではあまり利点がなくなったねぇ.Mercedでは,セグメント周辺はどうなるんだろう?

しかし,OS/omicronは既に活動を停止しています。中心の教授(高橋延匡氏)が亡くなったためと思われます。なむぅ;;

OSASKのファイルの考え方も何気にmulticsに近いような気がします。というか,「なんでもメモリ」で完全統一しているところは素晴らしい気がします。
http://osask.jp/filesystem.html#virtual_memory

仮想記憶機構との統合

      OSASKでは、ディスクキャッシュの延長に仮想記憶があります

        一般のOSでの仮想記憶機構は、スワップファイルというものを用意し、メモリが足りなくなったらこれと置き換えるという仕組みをとります。これを逆に捉えれば、メモリが足りていれば、スワップファイルなどは不要であります。これに対しOSASKでの仮想記憶は、メモリが足りていてもいなくてもハードディスク上のファイルを使います。

        上で説明したように、OSASKでは、ファイルへのアクセスはメモリへのアクセスと差がありません。それならば、メモリを直接使うことをやめ、全部ファイルにしてしまったらどうでしょう。たとえ全てがファイル上にあっても、ディスクキャッシュと遅延書き込みの拡張のおかげで、そのアクセススピードはメモリと大差ありません。・・・という突飛な発想を軸にして、OSASKの仮想記憶は設計されています。

      普通のOSとくらべて、メモリの扱いが概念的に異なります

        OSASKのアプリケーションプログラムにおいては、1セグメントが1ファイルに対応すると考えてください。プログラムコードはもちろんファイルですが、ワークエリアもスタックもファイルなのです。それぞれに別々のセグメントを割り振るなら、それは別々のファイルです。ファイルである以上、必ずディレクトリ構造をとり、ファイル名も存在します。タスクは1つのディレクトリを構成し、その中にワークエリアやスタックのファイルを持ちます。もちろん、現在のCやC++で主流のスタックとワークエリアを同一のセグメントに割り当てる方法なら、ファイルも一つです。

        OSASKにおいては、「ファイル」が基本です。もはやメモリは基本ではありません。アプリケーションの実行速度のことを考えなければ、メモリの存在を意識する必要もありません。言ってしまえば、メモリは所詮キャッシュ用のバッファでしかないのです。もしあなたの使っているCPUがL2キャッシュまでサポートしているなら、OSASKの仮想記憶は全メモリをL3キャッシュとして使うようなものです。そして主記憶はメモリではなく、ハードディスクなのです。この観点に立てば、メモリの増設はキャッシュメモリの増設ということになるでしょう。

これこそ実装は,OS/omicronに近いような気がしたりします。けれど目的はOSのシンプルさ,性能の優位性を元にしているので,電紙TADのようなドキュメント革命には意識が向いていないような感じが。

個人的には,TADはOSシステムコールおよびシェル機能によって,実身仮身ネットワークと絡むことによってシェル上でのみワンレベルストアをエミュレートしているということになりましょうか。しかしそれが足かせとなっている部分もあるようです。結局,ファイルという概念がある限り,それはTRON Application Databusを具現化したものではないということなんでしょう。

残念なのは,実身仮身ネットワークTADについてそういう視点で書かれたものを参照できないことです。きっと私が見つけられないだけなのでしょうが。

参考:
IPSJに出てくるTRON関係の投稿や論文
OS/omicronに関する論文(IPSJ)
V4 on VMは,まだ活動している模様
OmicronTiki

(2005.02.15追記)

Osask wiki
からリンクが張られている模様。
http://wiki.osask.jp/?rumors
う〜む。Kさん、暇なんやろうか・・・