1990年のコンピュータ環境 BTRON OS（月刊ASCII 1987年7月号10）

BTRONマシンの開発者にインタービューした記事をスクラップする。


あおりをスクラップする。

BTRON OSの検証を進める BTRONマシンの開発者に聞く 松下電器株式会社 中央研究所 情報グループ 　松下電器産業が発表したBTRONマシンの実験機は,初めてTRONのアーキテクチャを実現したマシンとして,多くの人々に注目されています。今月は、その開発にあたった中央研究所の技術者に,開発状況と検証内容をインタビューし,技術者から見たTRONの魅力について語っていただきました.
　あわせて,32bit以降のCPUとして関心を集めているTRONチップの概要と,各社の開発状況をお届けします.
　90年代の技術を見越し,次世代の標準アーキテクチャを目指す「TRON」の現状と,今後の動向を探ってみましょう.

はてさてこの時点（34年前）ではTRONはどうだったのか。その後の展開をどう予想又は期待していたのかスクラップする。

――3月に発表されたBTRONマシンの実験機の検証内容と,BTRONのOSの一般的な話という,この2点を中心にうかがいます.
　とりあえず,今回の実験機の目的というか,検証の目的は何だったんでしょうか.
櫛木　BTRONの機能確認ですね.OSの核部,外核部を実際に作ってみて,性能がどのくらい出るか,実際に,メモリサイズ,それからハードウェアの管理において問題がないのかという,もろもろの機能確認をしようというのが目的です.キーボードについても,実際に使ってみての評価をするつもりです.
286の相性と開発環境
――今回搭載した80286CPUとBTRONとの相性はいかがだったんでしょうか.
櫛木　メモリサイズなどで問題になるかな,という懸念もあったんですが,64Kバイトの壁をクリアするように,ラージモデルをサポートできるコンパイラを作り,OS核でも64バイトを超えるデータをサポートできるようにしました.そういう意味からしますと,大きな問題もなく達成できたのではないかと思っています.プロテクトモードなどの使い方についても,BTRONOSとの相性は一応評価できたな、というところです.
　ここで,16ビットと32ビットの差がどこに出るのかということになりますと,1つの問題は,イメージデータなどの大きなデータを扱うと,それだけで64Kバイトを超えてしまうという点です.つまり,連続データで64Kバイトを超えた場合には,286ではプログラムが複雑になってしまうという問題が残っています.これは,今後の課題の1つですね.それから,Lispなどを動かそうとすると,1セグメント64Kバイトの壁,または,16Mバイト空間という制限は,苦しいと思います.これは,一般的に16ビットと32ビットの能力差で,BTRONだからという問題ではないですがね.
――開発の手順は,ハードウェアの設計,コンパイラなどの環境部分の作成,そしてOS部分の作成,という3つが同時に進行していたわけですか.
櫛木　そうですね。だいたい同時進行でやっています。
――開発は,ミニコンなどを使って,クロス開発のようなかたちで進められたんですか。
櫛木　開発システムは,UNIXをベースにしたシステムの上に,クロス開発環境が使えるようになっています.UNIXの上に,Cのクロスコンパイラ,アセンブラ,リンカ,これの標準ライブラリなどを作り,開発マシン上でコンパイル,リンクを行い,それをダウンロードして実験機に持ってくるという方法をとっています.
　当然,セルフにも持ち込めるようにはしていますが,やはり,OSを開発するとなると,能力的に実験機では苦しい.一般に,パソコンで使っているハードディスクでは,やっぱりスピードが遅いわけです.リンクやコンパイルをするのに時間がかかりますから、そういうものは,クロス系で開発しています.
――メモリ管理などは,286のプロテクトモードをそのまま利用しているんですか.
櫛木　そうです.
――画面関係ですが,特別にデバイスを作ったというようなことは……
櫛木　メインに使っている石は,DPUと呼んでいますが,MN8355です.これは松下電器で開発したもので,松下電子工業から発売しているものです.主にBitBltなどのVRAMと,メインメモリ間のメモリ転送を高速にするためのディスプレイコントローラです。独自に,8355を強化するような若干のゲートアレイは追加していますが,特殊なハードウェアを使っているわけではないんです.
――今回の検証の際に,TRONチップの搭載を想定していましたか.
櫛木　TRONチップに対して,出せる範囲での要求は出すようにはしています.しかし,OSの検証という作業から,CPUに対して特殊なスペックを要求するということは,それほどないんじゃないかと思っています.
　ただ,実際にいろいろな検討がなされているなかで,何がいちばん脚光を浴びる機能として採用されるかなど,まだ予断を許さない部分はあるんです.

何か所か専門用語に脚注があったが、それは省略した。34年前は知らなかったが、今は知っている用語だし、ググれば済むことだから省略した。

BTRON OSの特徴と従来OSとの違い
――BTRONOSは,UNIXなどとかなり違ってくると思うんですが,いちばんの違いはどういうところでしょう.
櫛木　いろいろあるんですが,まず,日本語処理などの言語処理機能をOS内部に組み込みました.これによって,言語に依存する処理は統一されます.
　ご存知のように,TRONでは「実身/仮身モデル」というファイルシステムを採用しています.これは、言ってみれば,ネットワーク型のファイルシステムです。一方,UNIXやMS-DOSは,ツリー型の階層型ファイルシテムですから,ここが最大の相違点です.
　また,OSの核自身は,マルチタスクでリアルタイム性を備えています.現時点で発売されているMS-DOSやUNIXの標準バージョンでは、達成されていないことですね.
　マルチウィンドウが,実身/仮身モデルにフィットした形となっているのも,TRONの特徴でしょう.
　BTRONのウィンドウはマルチアクティブになっており,クリッピングが非常に難しくなります.そのため,ウィンドウシステムとグラフィックの描画システムとが互いにリンクして,クリッピングする領域を間違いなく実行できるようになっています.たとえば,他のウィンドウがかぶさった部分には書かない,というように,他のウィンドウがかぶさっていない変則多角形のなかだけに書く,という機能……クリッピング機能を持っているわけです.
　ですから,ウィンドウシステムそのものも,実身/仮身モデルや描画システムとかなりリンクしています.
　MS-DOSですと,MS-WindowsとMS-DOSが分離されていて,ウィンドウのなかに,マルチタスク機能から,描画システムから,全部入ってきますね.これに対してTRONでは,OSとして持つべきマルチタスクの機能と,リアルタイム機能を持ちながら,ウィンドウが独立して,描画システムと連繋している.そういう意味では,自然な形態なんです.
実身/仮身モデルとウィンドウシステム
――実身/仮身モデルとウィンドウシステムとの関係を,もう少し詳しく紹介してください.
小林　実身/仮身モデルによって表示されるウィンドウの構造は,かなり複雑になるんです。単なるオーバーラップウィンドウではなくて,オーバーラップしているウィンドウのなかに,仮身が入っています.さらに,その仮身をウィンドウを通して開けるので,ネスティング構造を持ったウィンドウシステムという性格を持っているんです.
　もう1つの特徴は,リアルタイムOSですので,階層構造を持つウィンドウにおいて,同時描画をどうやって行うかという点が,いまいちばんの問題となっています。
　いままでのウィンドウシステムと比べて,新しく考え出されている点は,マルチウィンドウに同時描画とネスティング構造を加え,かなり複雑なクリッピングも行うという機能です.一体化したウィンドウとして,しかもスピードの落ちないシステムを作るというのが,最大の課題だと思います.
――具体的には,描画プロセスみたいなものが並行して動く,という形態になるんですか。
小林　各プロセスごとに独立していて,各ウィンドウに対して描画する,という作業が可能です.
――OS側で何か書けという命令がプログラムから来たときに,プロセスと描画システムとの間で,どういう形でデータの受け渡しを行っているのでしょうか.
小林　イベントの流れで,だいたい処理ができるようになっています.実際は,「描画環境」というものが,1つ1つのウィンドウごとに設定されていて(図1),これがクリッピング関係のすべてと,TRONの場合はカラー表示ができますので,カラー属性,線属性などの情報を持っています.
　各アプリケーションは、描画環境に対して同時に指令を与えれば,自分の持っているウィンドウに対しては描画できる.ただ,各アプリケーションは,どういうふうにウィンドウが動いているかは知りませんので,ウィンドウマネージャで,それぞれのウィンドウ環境を全部設定してあるわけです。
――つまり,不定型の領域でクリッピングするということですね.これは,なかなかたいへんだったんじゃないですか.Sunワークステーションなどですと,矩形に分割して,その組合せでクリッピング領域を構成していますよね.
小林　実際は,それに近いのですが,TRONでも,矩形に分けて,その小さくなった矩形ごとに描画していきます.ただ,速いので見えないんですが……
――TRONの場合には,あるウィンドウのなかに入っているウィンドウは,その親となるウィンドウからは出られないとというようなことはあるんですか.つまり,ウィンドウ位置の制限みたいなことですが、
小林　それは,あります.子供のウィンドウは,親のウィンドウから出ることはできません.親のウィンドウの枠より外の部分は見えなくなりますが,拡大することはできます. ――親のウィンドウでクリッピングされるということですね.
小林　そうです。
――ウィンドウ間のカット・アンド・ペーストみたいな機能は,ウィンドウマネージャで行っているんですか.
小林　トレイ管理機能(表1)というのがあるんですが,それは一応,各プロセス間で共有できるようになっていますので,任意のプロセスから蓄えられたデータを取っていくことができます.これによって,カット・アンド・ペースト機能のようなものを実現しています.
――このトレイというのは,いわゆるクリップボードみたいなものですね.
小林　そうです.カット・アンド・ペースト機能を実現するには,クリップボードとか,カットバッファとか,いろいろな手法がありますが,TRONでは,現在,スタック方式を考えております.
――場合によっては,ウィンドウが複数のタスクから同時にアクセスされることがありますよね。
小林　その可能性はあります.
――トレイによるデータ交換は,人間が操作する以外にも,タスク間でこれを使うということはあるんですか.
小林　ウィンドウ間のデータ転送は,だいたいは人間の操作に基づくものだと思います。
――ウィンドウ内の基本機能と言いますか,ウィンドウのなかでの簡単な行エディットみたいな部分……バックスペースのときの字詰め,スクロール……といった機能は,ファンクションコールレベルで用意されているのですか.
櫛木　外核機能のなかに、1行のラインエディット機能は入っています.ですから,かな漢字変換も含めて,たとえばグラフのなかに文字列を埋めるという程度のことは全部,ファンクションとして用意しています。ところが,ワープロクラスになって,書式設定もする,頁変えもする,ヘッダーやフッターをつけるということになると,基本文書エディタレベルの話になってきますね。
――いわゆるウィンドウマネージャは、OSの1つ外側のユーザーのアプリケーションと,OSのカーネルの間に入るようになるわけですね.
櫛木　そうですね.ユーザーとカーネルの間ですけれども,ウィンドウは,ソフトウェアの構成上,外核部のなかに入っています(表1).そして,その上にユーザーアプリケーションがきます.システムアプリケーションは,UNIXで言えばviとかshellにあたる,基本エディタやTACL(タックル)がここに入ります。

実身/仮身モデルへの期待
――実身/仮身モデルですが,具体的にどうやって実現しているのですか.
櫛木　このモデルのインプリメンテーションについては,次回の研究会ぐらいに,きちんとした報告をしたいと思っています。
――やはり,このファイルシステムは,パフォーマンスという点からして,今回の開発においてかなりの比重を占めていたんですか.
櫛木　むしろ,比重は,開発よりも検証のほうにあります.実身/仮身モデルは,ネットワーク型のファイルシステムで,非常にユニークなものなんです.それが,ワープロとかOAシステムにおいて,どのように使われていくのかという点が,興味ありますね.そういう使われ方の検証と,それに付随してくる問題点,それ以外にスピード,ファイルシステムそのものの信頼性,などの隠された問題があります.そういった意味で,いま作業を進めています.
――作られた立場からの印象は,どうなんでしょうか。
櫛木　実身/仮身モデルをテストしている段階では,おもてに見える機能がおもしろいなと思いました.また,使い勝手として、文章を作るとか,論文を作るとか,文章のアーキテクチャを作っていくという面ではおもしろいなと思っています.実際,早く使ってみたいですね. ――私たちも,そういうところに注目しています.文章を作っているときは,「参照」という作業が多いんですね.たとえば,あるところを訂正したら,参照したところを全部直したい.こういうケースは,実身/仮身モデルだと簡単に解決できそうですね。でも考えていくと,ファイルの中に他の1つの実身の中に他の実身を指すようなポインタ(仮身)があるというような形では,たいへんじゃないかという印象もあるんです.それから,いちばん元の実身を削除した場合にはどうなるのか,つまり,その段階では実身なり仮身なりをどうやって探していくのか……インプリメントの段階で,このあたりは問題になったんですか.
櫛木　ソフトウェアのアーキテクチャをどう構成するかについて,いろいろと検討しました.最初のアルゴリズムがうまく動いてくれればよいのですが,だめだったら,アルゴリズムそのものを作り変えるということになります.そういう意味で,研究会に報告する前に,いろいろな検証が必要だと思っています.
デバイスファイルの取り扱い
――いまのウィンドウの話に関連したことですが,デバイスファイルという形で,機器やデバイスをまとめていますね.アプリケーション側から,そのデバイスはどのように見えるのでしょうか.UNIXでも,デバイスはデバイスファイルという形になっていて,そこにウィンドウシステムが入ってくると,1つのディスプレイをウィンドウデバイスみたいな形で扱う形式になっていますが,TRONでは,デバイスはどういう形になっていて,どのように管理されているのでしょうか.
安藤　現在は、デバイス名でデバイスをオープンし、そのデバイスへコマンドを送れたり,アクセス権の管理などができます.これらの管理は、デバイス管理部が行っています.また,ダイナミックローディングの機能もありますので,新しいデバイスが加わった段階で,OSが走っていながら,デバイスドライバをローディングしてこられます.そういう意味では、任意の時点でハードウェア構成が追加されても,それに対応することができます.
――動的な機器構成の変更ができる.たとえば,応用プログラムの使用時だけに,RAMディスクを設定することなどが可能であるというわけですね.
安藤　結局、ある時点でダイナミックに指定して,RAMディスクのデバイスドライバを呼び出してくることができるので,可能だという意味です.
――この場合,あるデバイスを,特定のプログラムからしか見えないようにする,といった管理まで行えるのですか.
安藤　ええ,可能です。
――要するに,ある特定のタスクにのみ使えるデバイスみたいな形で,制御できる.
安藤　それも可能ですけれども,オープンにすることも当然できます.
――そうすると,UNIXに非常に似た機能を持っているなという感じなのですが,デバイス管理の具体的な相違点というと,どのあたりになるのでしょう.たとえば,UNIXのデバイスは,どのデバイスも一応ファイルシステムであり,同じように見えますね.一方,TRONでは,デバイスを特定のタスクからしか見えないようにすることもできる.UNIXの場合,いわゆるデバイスのアクセス権を,個々のタスクごとに設定したりしなくてはならないわけですが,TRONは,どういうふうにしているんですか.デバイスの構成に応じたファンクションコールが設定されるみたいな……
安藤　そうですね.デバイスに応じたI/0要求を,個々に出すことができます.したがって,特殊なデバイスであるとか,追記型ディスクであるとか,いろいろなものへの対応が可能になります.
――いわゆる仮想デバイスみたいな,たとえばフロッピーディスクとハードディスクを同じように見るとか,複数のボリュームを1つに見立てるというようなことも可能なんでしょうか.
櫛木　特に,「仮想デバイス」という用語を使っているわけではありません.そういうふうに機能を拡張することは,将来あるかもしれませんが,現時点では、とにかくアプリケーションは,システムコールを使って書く.そして,システムコールの下には,当然,それに相当するファイルシステムやデバイス管理システムがあるという構造になっていますから,そのなかで仮想にするかどうかは,現在検討中です。
――先ほど話題になっていた動的な機器構成の変更についてですが,これは,BTRONの仕様ということですか.
安藤　仕様上は動的な機器構成の変更ができるということになっているのですが,これらはインプリメントに依存しており,これはおもしろい機能だということで,設計時につけ加えたわけです.
――BTRONのインプリメントによっては,こうした動的な機器構成ができないので,あらかじめやっておくという場合もあるわけですね.
安藤　そういう,普通のコンフィグレーション方式もあります.
――坂村先生が,ICカードに個人のデータを入れておいて,それをマシンに入れれば、どこでも同じようにTRONが操作できると言われたのは,そういった部分も含めてということなんですか(本誌6月号「姿を現し始めたTRON」を参 照).
櫛木　そうですね.そういうことも関係してきますね.
　ですから,たとえば,ICカードでコンビネーションを構成するというのは,ICカードでコンビネーションの情報を読み込んで,その内容に応じてデバイスドライバを選択する,というようなことが起きてくる場合があります.もちろん,そういう場合は,それが実現できるように,核部を作っておかなければなりません.

TRON坂村健氏インタビュー（月刊ASCII 1987年6月号6） 「姿を現し始めたTRON」
今読むと大体雰囲気が分かる。34年前はチンプンカンプンだったはずだ。知らない用語を調べ解説を読んでも理解できないことがかなりあった。話は変わるがパソコンがマイコンと呼ばれていた頃知人はフラグという用語がピンとこなかったと言っていた。フラグ＝旗　なのだが、それがCPUの処理結果に係る状態を示すものだと理解するまでハードルがあったと言っていた。コンピュータ用語にはそういうところがある。私はダンプリストがそうだった。ダンプカーが積み荷をドシャーと一気に下すように、メモリの内容を一気に吐き出すということだったのかと理解するまで時間がかかった。なにぶん、私たちは素人、趣味でパソコンを触っていたのだからこういうことにもなるのだ。

BTRONの持つ開発環境
――今回,開発用にCコンパイラを作成されましたね.今後,BTRONで具体的にアプリケーションを開発していく場合にも,Cコンパイラは標準的なものになると見ていいんでしょうか.
櫛木　まあ、いまのところはそういう進み方ですね.坂村先生は,次に新しいシステム記述言語を開発なさる意向のようです.しかし,先に何か使えるランゲージプロセッサがないと仕事が始まりませんので,とりあえずCを使うことになっています.もともとUNIXとかCについては,開発マシンとして使おうということになっていましたし……
安藤　ご存じだと思いますけれど,開発用に作ったCコンパイラでは,データアクセスなどで,farやnearを使い分けており,24ビットまでアドレス空間を広げられます.ところが,すべてをラージモデルというか,大きなアドレスにするとパフォーマンスが落ちて,その結果,アプリケーションプログラムに少々負担がかかるんです.しかし,場合場合に応じてアドレス空間の幅を考えながら,小さな空間であれば、頻繁にアクセスするデータはデフォルトのデータセグメント上に置くというように,プログラムレベルで工夫しています.
――アプリケーションになった場合,最初のうちは小さい絵や文書も,継ぎ足していくうちに大きくなって64Kを超えてしまう場合もあるでしょうし,実身と仮身をどんどんつなげていけば,印刷する際に,全部展開しなくてはいけなくなるほど,非常に大きなデータになってしまう.このように,データは動的に大きくなったり、小さくなったりすると思うんですが,そのあたりはCコンパイラで十分対応しきれるのでしょうか.
櫛木　OSとか外核部を作る段階で,ユーザーのデータを直接触るというケースは,比較的少ないと言っていいでしょう.
　OSの核部と外核部が使うデータのサイズは,だいたい分かりますので,ある程度,そのサイズを予測したうえで作ります。
　アプリケーションプログラムでは,かなりの量のイメージを扱うといったような場合には,farでデータを参照する確率が高いですね.
――共有ライブラリについて伺いますが,これは,複数のタスクからライブラリ部分を共有する.要するに,プログラムという単位とは別に,ライブラリ部分だけ別に置くということですね.
安藤　はい,そうです.

メモリモデル懐かしい。こんなものに注意を払わなければプログラムが書けなかった。プログラムを使っていて80286憎しと怒りがフツフツと沸いてきた。黙ってリニアな1Mを俺に寄越せやこの野郎と思いながらプログラムを書いていた。どんなメモリモデルがあったか調べてみたら
TINY　コード＋データが64Kbytes以内。これは使うことがなかった。
SMALL　コードが64Kbytes以内、データも64Kbytes以内。それぞれ別セグメントを使うので合計128Kbytesまでのプログラムを作れる。
COMPACT　コードが64Kbytes以内、データが64Kbytes以上。これはコードは1つのセグメントしか使えないが、データで複数のセグメントが使える。私は、もっぱらこれでプログラミングしていた。画像データを扱っていたのでデータ領域は大きいのが必要だった。昔々8bit機のころからシミュレーションとかしたかったので目的のプログラムを作る前にデータを圧縮することばかり考えていた。当然、目的のプログラムは完成しなかった。
MEDIUM　コードが64Kbytes以上、データが64Kbytes以内。コードに複数のセグメントが使える。データは1つのセグメントしか使えない。一体どんな用途のプログラムにこれが必要だったのか分からなかった。
LARGE　コードもデータも64Kbytes以上。コードもデータも複数のセグメントが使える。ただし、配列変数のサイズは64Kbytes以内。
HUGE　コードもデータも64Kbytes以上。コードもデータも複数のセグメントが使える。配列変数のサイズは64Kbytes以上でも良い。でかい配列を使う（今から思えば64Kbytes以上の配列がでかいとは昔はなんと貧弱な機械を使っていたのだろうか。今から思えば絶望的になる）
以上が私が知っていたメモリモデル。それ以外に
FLAT　プロテクトモード(32bit)用のメモリモデル。コードとデータが同一のセグメントを使用する。Windows用だとのこと。これは、使ったことがなかった。まあ、Windows用のプログラムを作ったことがないのでしょうがない。フラットなメモリ空間にはあこがれていた。
とにかく80286という腐れCPUは速いプログラムを書くには適していないCPUだった。これも互換性の呪縛によるものだった。もっと早くに8080互換性を諦めれば良かったのに。歴史は私の気に入らない方向に進んできた。

技術者からみたTRON
――技術者の方から見て,TRONを開発することには,どういうメリットがあるんでしょうか.
櫛木　一言で言えば,新しいOSをつくるという機会は,そんなにないと思うんです.そういう意味では非常にありがたい経験ですね。もちろんオリジナルで,自分で勝手に作って自分で使う分には,それは経験できると思うんですが,TRONの場合は,「世の中の標準」という目標があるわけで,その意味で,意義を感じています.
特に,BTRON全体が特徴にしていることですが,マルチメディア対応にしていかなければいけないいままでのOA用のOSは,8ビットや16ビットのキャラクタを扱うことが中心のOSですから,マルチメディアに対応をターゲットとしては考えていなかったわけです.
　それから,操作の標準化を行うという点でやりがいがあります。われわれ開発者は標準化のあるべき姿を分析し,必要な部品を抽出したうえで,それにトライしていかなければなりません.
　あと,実身/仮身モデル.これは,ユーザー側から見れば、妥当なファイルシステムだと思うんです.
　従来の階層構造システムというのは,1つのマシンを複数の人が使ったときに,そのディスクのうち,ここは私の領分,そこまではあなたの領分ですから,ここからそっちは侵しません,という約束が必要となり,このファイルシステムが作られました.こういう形態は,UNIXが代表的ですね。
　UNIXはマルチユーザーシステムですから,ユーザー間でディスクを共同利用するために,ファイル管理システムが作られたのです.
　ところが,このような今までの階層構造システムに対して,実身/仮身モデルは,人間の発想を,もっと機械の側から助けてやろうという考えに基づいたファイルシステムなんです.
　そういう意味では,われわれ自身がユーザーの視点を持ち,本当に欲しいOSを作ろうという立場でやっていると思うんです.そこがある意味で,技術者冥利に尽きると言えますし,ユーザーの視点に立っていることで,真のユーザーとしてのアイデアを入れる余地が無数にありますね.そこが魅力だと思います.
小林　マンマシンインターフェイスを作成した者の立場から言いますと,いままでのOSと違って,TRONのスタンディングポイントは、使う人の方にあるんです.いままでのOSを見ると,UNIXもMSDOSもそうでしたが,パソコンを使っている人たちや、システム設計者,アプリケーション開発者の立場に立ったものが多かったんです.
　TRONは,そのような立場から一歩前進したと言うか、ユーザー側に向かっているコンセプトのOSで,これはおもしろいなと思いながら作っています.

今後の展開
――今回の検証は、どの段階で一段落つくのでしょうか。
櫛木　BTRONマニュアルが正式に発売されるときには,「検証」という役目は当然終わっていることになりますね.ただ,ソフトウェアの内部構造は,いろいろ改良していかなければならないでしょう.
――今回の実験機では,コミュニケーション関係の機能は装備していないようですが,次回は,まずコミュニケーション関連の搭載ということになりますか.
櫛木　いろいろ目白押しじゃないでしょうか.システムアプリケーションもありますし,コミュニケーションもあります.実際の基本的な応用ソフトについても,まだこれからです.いろいろ取り混ぜて,たいへんですね(笑い).
――具体的に,今後の見込みですが,アスキーの読者がBTRONのマシンを触れるというのは,どれぐらい先のことになるでしょうか.
櫛木　これは難しい質問ですね.今のところ,未定なんです.
――だいたい,これから3年ほどありますが、90年代というようなところでしょうか.坂村先生は,本誌のインタビューで,この秋ぐらいからマイクロBTRONで展開……
と言われているんですけれども.
櫛木　そういうムードが高まってくると,事業をする側も早い時期に乗り出す可能性が強くなるわけですね.TRONは,まったく新しいもので,アプリケーションも用意されていない状態からスタートするわけですから,いろいろな工夫をしないと,なかなかしんどい.正面切ってドーンといくわけにもいかないんです.世の中の情勢とか,どのぐらいムードが高まってきたかとか,マイクロBTRONが出たとか,いろいろな要素で決まっていく問題だと思います.
――いま、松下電器さんでは、社内的にBTRONの開発はどのような意味づけで進められているのですか.たとえば,基礎研究の意味あいが強いとか,それとも半分くらいは応用研究のつもりとか,そのあたりはどうですか.
櫛木　どちらも並行に進んでいると言えます.プロジェクトとしては非常にユニークな動きをしていますね.UNIXは,AT&Tの研究室で出来上がってきたし,MS-DOSは,IBMの基本OSに採用されたということで,ビジネス・オリエンテッドの方向で仕様などが決められてきましたね.その点,TRONは,最初にマルチクライアントな呼掛けと動きがあって,まずITRON*18が,電子協*19のマイクロコンピュータ技術委員会から出てきた要求書に基づき,坂村先生が中心になって、動き出したわけです.
　メーカーと大学の産学協同でいきながら,アカデミックな発表と規格を合わせてやっていきましょうということで,メーカー間の整合をとる技術委員会的なものが,産学協同の方向と並行して動いていますね,学会発表込みで、なおかつ,TRON協議会という組織が並行に動いているでしょう.これは,いままでにない動き方じゃないでしょうか.
　こういう技術が生まれる条件というものは,いろいろなものが壁になってしまい,いまや純粋に技術だけで動かされていく状況じゃないですからね。たとえば,UNIXやMS-DOSの将来はどうなるの・かという問題もあるでしょうし,逆に,MS-DOS,UNIXに対する不満という力も働くわけです.つまり,いろいろな要素が絡み合ったなかでの動きということになっていくのじゃないでしょうか.
――産学協同の役割分担は,どういうふうになっているのでしょうか.
櫛木　TRONのコンセプトとアーキテクチャ,仕様は,坂村先生が提唱されて,その後,基本コンセプトに添った仕様になっているかどうか,という見方で,チェックしていくわけです.ビジネスと結びつけるのは企業サイドの仕事になります.
　建物でいうと,建築デザイナーがいて,建物を作るときの構造計算から,材質は何にするという部分は,各建築会社が担当するわけでしょう.そのあたりに,商品化の中心があるわけです.そういう意味ではお互いに補完し合って,私どもも坂村先生の持つ,ユーザーオリエンテッドな見方とアカデミックな追求姿勢に賛同してやっているわけです.また,先生のほうも、メーカーサイドが持っている,作る過程でのノウハウとか,仕様のコンセプトに影響させなければいけない生臭いポイントについては,当然吸収していかれるわけです.そういう意味で,先生の力は非常に大きいものがあります.
　現在では,TRON協議会でTRONに関連する様々な技術移転や普及促進も行っています。産学協同のよい見本ではないでしょうか.
　――きょうは、どうもありがとうございました。

BTRON触りたかった。どうして、私たちの目の前にBTRONが出てこなかったのかスクラップを続けると分かる記事が出てくるかも。全く記憶していないから自然にフェードアウトしたのだろうか。