「RT-11」はUNIXの“/usr”ディレクトリの語源なのか 歴史と機能から検証する：リアルタイムOS列伝（48）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第48回は、UNIXの“/usr”ディレクトリの語源という説が流れた「RT-11」について、その歴史や機能を紹介する。

[大原雄介，MONOist]

APIに相当するものがない、限りなくベアメタルに近い構成

　ちなみに、こういった起動を行う場合のシステムのサイズは、当然搭載メモリ量以下に抑える必要がある。ただ、もう少しメモリを搭載してディスクを利用できる（ディスク用のドライバをロードできる）環境では、オーバーレイを利用してメモリサイズ以上のプログラムを実行することが可能になっている。

　RTOSでオーバーレイを利用するというのは、レイテンシ増大や最悪応答時間が変動するなどの観点から悪手と思われるかもしれないが、何しろ1973年の話である。搭載されていたKA-11 CPUのマシンサイクルは250ns、つまり4MHz動作である（内部では半分の125nsのサイクルタイムでクロック信号が利用されていた）が、もちろんパイプライン動作にはなっておらず、また全ての命令が1サイクルで動作するわけでもないため、実質的にはもっと遅い。もうちょっと後に出た廉価版であるPDP-11/34のDhrystone 1.1 Scoreが0.25である。4.77MHz駆動のIntel 8088が0.23だから、たぶんIntel 8088よりは遅く、Intel 8080と同程度と考えておくのが無難なところだろう。この程度のマシンでリアルタイムといっても、それは応答時間がmsやμsecではなく、secあるいは10sec程度になるので、オーバーレイを実装したからといって性能に致命的な影響があるというわけでもなかったようだ。

　RT-11そのものはシングルユーザー／シングルジョブで、カーネルに相当するものはSystem Monitorという名称で提供される（ちなみにRT-11 v2のマニュアルによれば、このSystem Monitorのフットプリントは4KB少々だったそうだ）。開発者はこのSystem Monitorを自分のプログラムと併せてビルドする形でシステムのローダブルイメージを作成、これを直接実行するという格好である。デバイスドライバは、v1.0ではビルド時に組み込むしか方法がない。ただこれはv1.0の話で、途中から完全にローダブルに切り替わり、動的なロードが可能になった。また、プログラムはもちろんアセンブラのみで、MACRO-11と呼ばれるマクロアセンブラがこのために提供されている（RT-11 v2以降はこれに加えてFortranやBASICを利用したプログラムも実行できるようになった）。

　こういう構成なので、実はRT-11にはAPIに相当するものもほとんどない。その意味では限りなくベアメタルに近い構成といえなくもない。それでも、以下のような、ベアメタルとして利用するよりも便利な機能が幾つか提供されるというメリットがあった。

• ブートストラップをはじめとするStartup Code
• 標準的なデバイスに対するデバイスドライバ
• 開発環境一式およびデバッグ／パッチ環境

　一応、Fixed Priorityを利用したScheduleは可能である。シングルジョブだから同時に稼働できるジョブそのものは1つしかないが、フォーグラウンドジョブ／バックグラウンドジョブという形で複数のジョブを稼働させることは可能だった。この際には、上述のようにFixed PriorityのSchedulingが行われる。Time-Sliceの考え方はないので、最もTime Criticalなジョブが最高のPriorityになり、そのジョブが待機状態になったらより低いPriorityのジョブが実行される、というシンプルな構成である。

　もっとも、1970年代とはいえ、中にはこれではちょっと不都合という処理もあったようで、バージョンが上がるごとに少しずつマルチタスク（というかマルチジョブ）の機能が充実していった。ただこれでは飽き足りないというユーザーも少なからず居たようで、サードパーティーから提供されていたRT-11互換のRTOS（Fuzzball、SHAREplus、TSX-11）などはマルチタスクや後にマルチユーザー／マルチプロセッサの機能を追加するなどして、こうした飽き足りないユーザーを獲得していたようだ。