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

1990年のコンピュータ環境 BTRON OS のコラム記事をスクラップする。

TRONチップの開発状況
　TRONプロジェクトでは,同プロジェクトが提唱するアーキテクチャの能力を最大限に引き出すため,新たなVLSIマイクロプロセッサの開発を進めています.それが,「TRONチップ」と呼ばれるもので,マルチタスク処理やマルチウィンドウ処理などが,効率よく行えるための命令群が用意されています.
　現在,日立製作所(株),富士通株)および三菱電機(株)の3社が,共同でTRONチップの開発を行っています(各社の開発分担は,表1のようになっています).すでに,日立はエンジニアリング・ワークステーション向けの製品を,富士通はミニコン向けの開発をスしており,三菱はパーソナルコンピュータ向けの製品を開発することになっています.そして,これらのチップの総称として「GMICRO」(ジーマイクロ.Global MICROの略)の共通ブランドが使われることになっています.日立が発表しているH32/200の仕様を表2に示しました。
　このように,当初TRONチップは,データおよびアドレス・バスともに32ビットの仕様で登場してきます.しかし,TRONの基本仕様は、アドレス空間の拡大に対応できるように,アドレス,データ・バスともに64ビットまで拡張していくことを前提として設計されており,同プロジェクトは,1990年代には64ビットCPUを発表する計画を持っています.

64ビットCPUという単語に反応してしまった。歴史はTRONチップを抹殺した。まことに残念である。今使っている64bitはAMDが2000年8月に発表し、2003年4月に出荷したAMD64が基本でインテルがそれに乗っかったものだった。インテルは当初IA-64として8086の系譜とは互換性のないCPUを発表したが、結局8086系と互換性を維持したAMD64の軍門に下った。インテル32bitから64bitに移行するとき互換性を捨てるなんて手前遅いんだよ。どれだけインテルの互換性維持に素人プログラマは苦労した、呪っていたかわかってるのか。反省するのが遅すぎる。16bit化のときやってれや。8bit機のソフト資産なんて大してなかったのだから、16bitに移行する時が最大のチャンスだと思っていた。8bit機の価値あるソフトがあったとしても再コーディングすればよかったんだ。当時はその余裕があったはずだ。可能だったはずだ。

TRON OSのアクセスの管理とリアルタイム性
　TRONOSの概論的な部分から一歩踏み込んで,「アクセスの管理とリアルタイム性」についてインタビューしたので,以下に紹介します。
―――動的なデバイスの管理なんですが,非常に多くのタスクがあった場合,たとえば,あるタスクがRAMディスクを使い始めて,もう1つのタスクもRAMディスクを使いたいというときなど,アクセス権の設定の管理はどういうふうにしているんですか.
櫛木　RAMディスクを独占使用したい場合には,占有アクセス権が指定できますし,共有使用の場合は,通常のフロッピーのアクセスと同様に,ファイル管理でアクセスの管理が行われます。
　話は変わりますが,データやプログラムのアクセス管理ということでは,スーパーバイザーモードのデータやプログラムにレベル0,Iを与え,レベル0とIの中で,さらに重要性の高いものをレベル0で動かし,ユーザープロセスはレベル3で動かします(表).これによってマルチプロセスで動きながらも,レベルが違えば,お互いに領域を侵すことはありません.その意味での管理をしています.
　リアルタイム性を得るためのスケジューリングについては,OSはラウンドロビンとリアルタイムイベント駆動とを行っています。ラウンドロビンも行いますし,イベントがあったときには,イベントを優先してイベントキューに入れ,それでプロセスは起動されることになります.
　ですから,イベントは当然,ハードウェアイベントとソフトウェアイベントとがありますから,それで駆動されるプロセスは,形としてはリアルタイムの応答になるわけです.ラウンドロビンを行いながらも,リアルタイム性を優先して処理する.このあたりはUNIXなどになると,ラウンドロビンだけで割り当てを行っていますね.
――たとえば,マルチウィンドウでは,アクティブなプロセスが多数あって,さらにそれに対してイベントが起こるわけですね現在アクティブになっているウィンドウもあれば,イベント待ちのものもある.そういった部分の管理は,かなりたいへんなんじゃないですか.画面上でキーボードのイベント待ち状態になっているときにキーが押されると,イベントキューのなかにイベント待ちが入っていて……どれにイベントを振り分けるかとか,イベント待ちではなくタイマ割り込みが入ってきたときなどの管理は,どうなっているんですか。
安藤　キーボードとポインティングデバイスに関しては,会話権……これは,ユーザーと対話する権利ですが……が常時1つだけしか設定されていません。自分は権利を持っているというのをウィンドウマネージャから知らされるようになっているんです。その間は,ポインティングデバイスおよびキーボードは,自分のもので,どんどんイベントを取れる.
　OSのなかでは,キーの入力も1種のイベントであり,他のイベントと同じように管理しています.普通,キーボード入力でしたら,それを割り込みとしてだけ受け取って,プロセスを動かし出すという処理はしないOSもあると思うんです.それでも,最終的にはキー入力があれば,プログラムが動き出すことになっている.しかし,リアルタイムOSでしたら,キーボードから入力されると,すぐプロセスを呼び出すことになっています.そういった概念を,一般的な汎用OSのなかに取り入れているのだ,と思っていただいてかまわないでしょう。
――普通ですと,UNIX的なプライオリティをつけたラウンドロビンの状態があり,さらにイベントによる駆動があるみたいになりますね.そういうOS上でマルチタスクをしていると,1つのタスクのなかの非常にクリティカルな部分や,イベント割り込み中に,さらにイベント割り込みがあった場合にはどうするのか,というような部分のインプリメントは,たいへんですよね.TRONの場合,このあたりで,今までと、どのくらい違っているのですか.
安藤　キーボードやポインティングデバイスからの入力によるイベント待ちの解除も,ラウンドロビンも,スケジューラにとっては,Iつのプロセススケジューリングの契機として統一的に扱っています.したがって,その他のハードウェア割り込みと同様に,クリティカルな部分でも,排他処理や多重割り込みに対する処理も当然行われています.
　マルチプロセスではいろいろなプロセスが動いていますので,その他の要因,ファイルのI/Oであるとか,それに関する「待ち」の処理は,I/0が終われば、当然それで,I/0処理の間,休止していたプロセスを再起動するなど,プロセスのスケジューリングが行われる.そのへんに関しては一般的だと考えていただいてよいと思います.
櫛木　一般的ではありますが,考えられる限りの,よいスペックはほとんど取り入れている,と言えるんじゃないでしょうか。

ラウンドロビンバッファという用語初めて見たとき、凄く格好いいと思った。ミーハーなアマチュアプログラマだった私はどれほど素晴らしいものかと思ったが、普通だった。素直に考えればそうなるというものだった。