OS-9

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動先: 案内検索

テンプレート:Infobox OS OS-9オーエスナイン)は、マイクロウェア(現RadiSys)によってモトローラの8ビットMPU MC6809のために開発されたリアルタイムオペレーティングシステム(以下、RTOS)である。 当時、マイクロウェアは、モトローラの依頼により共同でプログラミング言語Basic09を開発していた。この言語の開発・実行環境としてマイクロウェアが開発したのがOS-9である。

その後680x0に移植され、さらにx86/PowerPC/SH/ARMなど幅広いCPUに対応した。

特徴

プリエンプティブ・マルチタスク

OS-9は、プリエンプティブ・マルチタスク(詳細はプリエンプションも参照のこと。)をおこなうRTOSである。

マルチプロセス

多くの組み込み用RTOSでは、全ての実行コードを単一のロードイメージにリンクしてメモリに展開・実行するので、並行実行されるタスクはスレッドモデルであることが一般的だが、OS-9では各タスクは独立したプログラムイメージ(プログラムテキストは複数タスクで共有可)を実行するプロセスモデルである。

プロセスモデルでは各タスクは論理的に独立しているのでタスク間のデータの共有や通信にコストがかかりがちだが、OS-9では「データモジュール」と呼ばれる一種の共有メモリ機能で高速なプロセス間通信を提供している。ただし、タスク間通信に不可欠なセマフォが提供されたのはかなり後のことである。また後のバージョンではPOSIXに準拠したプロセス内の複数スレッドをサポートする。

OS-9/6809レベル2ではMMUを使った仮想アドレス空間をサポートしたが、その他のバージョンでは単一のアドレス空間しか持たないフラットメモリモデルである。OS-9/6809レベル2及びOS-9/68030以降のバージョンではハードウェアによるプロセス間のメモリ保護機能がある。

OS-9での新プロセス作成はUNIX流の現在のプロセスのコピーではなく、(仮想アドレス空間を持つOS-9/6809レベル2でさえ)実行プログラムを指定するWindowsの「spawn」に近いモデルである。これは、ベース(セグメント)レジスタを持たないCPUアーキテクチャでフラットメモリモデルを採用する限りある程度必然であり、UNIXでも多くの場合せっかくコピーした子プロセスの元の実行イメージは捨てられてexecで新しい実行イメージに置き換えられることを考えれば効率的でもある(マイクロウェアはこれを逆手にとって「OS-9のforkはUNIXよりX倍速い」と喧伝していた)。

モジュール構造

OS-9を構成するすべての部分は、モジュールと呼ばれる統一された構造を持っており、必要な機能だけを選択して使用することができ、自由度の高い構造になっている。これにより、OS-9は以下の特徴を有する。

移植性が高い
移植に必要なモジュールだけを新たに作成すればよい。個々のモジュールも容易に作成可能。
アップグレードが簡単
対象モジュールのみ交換可能。再起動を必ずしも必要としない。
外部プログラムを主記憶に常駐させる事が簡単
主記憶(ROM/RAM)上のモジュールはモジュールディレクトリと呼ばれるファイルシステムディレクトリに似た構造で管理される。外部記憶上のプログラムも予めロードする事によりROM化されたモジュールと同様に主記憶上に常駐した状態にすることが可能[1][2]
セキュリティに強い
各モジュールにCRCがあり、モジュールをモジュールディレクトリへ登録する際にチェックされるため、正当なモジュールのみメモリへロード可能[3]
デバッグが簡単
OS自体が構造化されているため、問題点の切り分けが行いやすい。
リビジョン/エディション
モジュールにはリビジョン番号とエディション番号があり、同一名のモジュールがメモリ中に複数ある場合、最新のモジュールのみ有効となる。ROM化されたシステムをアップグレードする場合、古いモジュールを削除することなく、新しいモジュールのROMを追加するだけでよい(あるいは外部記憶上の新しいモジュールをRAMへロードするだけでも良い)。
ROM化可能
すべてのモジュールがリロケータブル(かつリエントラント)であることからROM化特有のアドレスを意識しないでプログラミングしたものを、そのままROM化できる。各モジュール(プログラム)は、すべて主記憶空間内のROM上で直接実行が可能である。
プログラムが使用する変数・スタック領域はカーネルによって実行時に動的に割り当てられる。
再入可能(リエントラント
プログラムがリエントラントであることはOS-9において必須の条件であり、リエントラントでないコードは利用できない[4]。プログラムは自身を実行中に書き換えてはならない(自己書き換えコードはリエントラントではない)。
メモリ使用効率が高い
プログラムがリエントラントであるため、コード領域を各プロセスで共有することが可能になり、メモリの利用効率が高くなる。また、OS自身がモジュールの集合であるので、必要なモジュールのみをロード(あるいはROM化)すればよい。
遅い
汎用性は高いが、専用に設計されたモノリシックOSに比べるとオーバヘッドが生じる。例えばデバイスドライバはそれぞれ固有のスタティックストレージと呼ばれる大域変数領域を持つため、カーネルの機能を利用する際には単純な関数呼び出しではなく原則としてソフトウェア割り込みを伴うシステムコールを用いる必要がある。

OS-9のモジュールの種類

  • カーネルモジュール
    • kernel (6809版を除くカーネル本体)
    • OS9p1 拡張モジュール(6809版ではカーネルのうち起動に最小限必要部分)
    • OS9p2 (6809版ではカーネルのうちOS9p1に含まれない残り部分)
    • OS9p3 (漢字変換処理等の拡張で日本語版のみ)
  • ioman - I/Oシステムの総合管理(後に68000版でkernelに吸収されモジュールとしては存在しなくなったが、OS-9000では再び独立したモジュールとしてkernelから分離された)
  • ファイルマネージャモジュール
    • RBF - Random Block File Manager (ディスク)
    • SCF - Sequencial Character File Manager (コンソールなど)
    • SBF - Sequencial Block File Manager (テープ)
    • PipeMan - Pipe File Manager (パイプ)
    • IBF - IEEE 488 Interface Bus File Manager (エーアールケーコーポレーション製)
    • PCF - PC-DOS equivarent File Manager(PC-DOSファイルの操作)
    • NVFM - non-volatile File Manager(CD-iのデータ保存のための、ディレクトリを持たず、バッファリングしないファイルシステム)
    • CDFM - Compact Disk File Manager
    • NRF - Non-Volatile RAM File Manager
    • UCM - User Communication File Manager
    • DSM - Display Support Manager
    • GFM - Graphics File Manager
    • MFM - MAUI File Manager
    • NFM - Network File Manager
    • SOCKMAN - Socket File Manager (OS-9/ISP - Internet Support Package に含まれている)
    • IFMAN - 通信インターフェース・ファイル・マネージャ
    • PKMAN - 仮想キーボード・ファイル・マネージャ
    • SPF - Stacked Protocol File Manager (LANComm/SoftStax ネットワーク・サブシステム)
  • デバイスドライバモジュール
    • (例)sc6821 - MC6821用汎用コンソールドライバ
  • デバイスディスクリプタモシュール
    • (例)t0 - デバイスのアドレス、設定値などを保持
  • プログラムモジュール
    • (例)shell、標準ユーティリティプログラム
    • cc - Microware C Compiler[5] / ucc - Ultra C Compiler[6]
  • データモジュール
    • (例)init - システム初期化定数などを保持
  • BASIC中間コードモジュール
  • 共有ライブラリモジュール(サブルーチンモジュール)
    • runb - MW-BASIC/Basic09ランタイムライブラリ
    • cio - Microware C Compiler 用入出力ライブラリ・サブルーチン・モジュール
    • csl - C language shared library[7]
    • psl - presentation support library(CD-i用)
  • システム・モジュール
    • cache - メモリ・キャッシュの効率的使用
    • ssm - System Security Module - MMU等を利用したメモリ保護機能
    • fpu - 浮動小数点コプロセッサの利用(または演算ライブラリ)
    • vector - ハードウェア割り込み管理(OS-9000)
    • ティッカ・ドライバ - 定周期割り込み
    • RTCドライバ - 時刻の取得・設定
    • align - アライメントエラーに相当するメモリアクセスの支援

ダイナミックローディング

カーネル以外の多くのモジュールが、システムの稼動中、任意の時点で追加、削除、更新が可能である。例えばデバイスドライバは任意の時点でメモリにリンク(ロード)/アンリンク(アンロード)が可能であるため、デバッグ中もカーネルを壊さない限りシステムの再起動を必ずしも必要としない。

またモジュールをメモリにリンク(ロード)するときにリンクカウントがインクリメントされるほか、モジュールを利用(オープン)する度にリンクカウントがインクリメントされ、プロセスでモジュールの利用が終わるとリンクカウントがデクリメントされる仕組みがある。よってモジュールを利用しているプロセスがある間は、故意にアンリンクしようとしてもアンリンク(アンロード)されない。またリンクカウントがゼロになるとモジュールがメモリからアンリンク(アンロード)される。

メモリ保護

ハードウェアがMMUを持つ場合、メモリ保護機能が有効となる。システム空間とユーザ空間が分離され、また、各ユーザプロセス間も分離される。デバッグ中のユーザープロセスが他のプロセスやシステムを破壊することがない。OS-9/6809では特にLevel2と呼び、最大2MBのメモリを管理できる。

マルチユーザ

組み込み用途だけではなく、一般のコンピュータとして使用可能であり、UNIXと同様のマルチユーザの機能を備えたTSSの環境がある。ユーザ、グループ別にファイルやプロセスのアクセス権がある。なお、PC用のOSとして見た場合、8bitや16bit時代の一般的なユーザには、マルチタスク・マルチユーザのメリットが理解されなかった。

UNIXライク

以上のようなRTOSの上で、UNIXライクな開発環境が構築されている。簡易なものであるがシェルも実装されており、ファイルシステムも階層構造を始めとしてUNIXに近い機能を実現している(ユニファイドI/O)。

OS-9LAN

OS-9には独自のLAN、OS-9LANがある。LAN上の他のコンピュータの資源に対して、透過的にアクセスが可能な優れたものである。フルパスリストの先頭にコンピュータ名を追加するだけで、そのコンピュータのファイルやデバイスにアクセス可能で、例えばシェルからリダイレクトして、LAN上の他のコンピュータに接続されたプリンタに出力可能である。

なお、開発は当初星光電子により、OS-9/6809と富士通FM-11+ARCNetという構成でおこなわれた。

X68000用のOS-9LANは、マイクロボードより販売されていた。

ウインドウシステム

OS-9/680x0には以下のようなウインドウシステムが発売された。

  • X Window System:マイクロウェアが移植。Motifも付属。
  • Personal-Window:マイクロウェアジャパンが、X68000のために開発。
  • G-Windows: ドイツのGESPAC(代理店:フォークス)が開発。
  • XiBase9: ドイツのXiSysが開発。

欠点

  • UNIXと異なり、仮想記憶機能が存在しないため、搭載された主記憶容量以上の記憶空間が使えない(もっとも、仮想記憶を利用するとリアルタイム性が担保できなくなるため、RTOSとしての意義がなくなる)。
  • 製品として販売した場合、極めて容易に分析、解析が可能である。また、実際にメモリ上にあるモジュールを保存することでコピーが可能であるため、いわゆるコピープロテクトが原理的に不可能である。
  • ユーザプログラムがハードウェア資源に直接アクセスできるCP/MMS-DOSなどのOSに慣れたユーザは、アドレス空間をユーザとスーパバイザに分離したOSにおいて、ハードウェアへのアクセスにドライバが必要なことに不満を述べることが多い(アドレス空間を分離するか否かは、OS-9のレベルやバージョン、使用するハードウェアによる)。
  • プロセス優先順位の逆転現象[8]が存在し、マイクロウェア社が顧客向けに発行する機関紙 "Microware Pipelines" においては、優先したいプロセスのプライオリティを極端に低く設定する事例が頻繁に紹介されていた。
  • 2013年現在、OS-9単独では対称型マルチプロセッシングをサポートしていない。

OS-9/680x0

OS-9は、モトローラ社の16ビットCPU68000に移植された。以後、6809用はOS-9/6809、68000用はOS-9/68000と呼称されるようになった。その後、68000が68020、68030とシリーズ展開されるようになると、それらに最適化したOS-9/68020、OS-9/68030が開発された。

これらOS-9/680x0は、産業用RTOSとして高いシェアを占めていた。これは、20世紀末には、産業用システムのMPU(CPU)に680x0が広く採用されていたこと、ハードウェア資源を効率的に扱う多くの特徴を持っていること、OS-9自体の移植(ポーティング)が容易なことから必然的にそうなったのである。

例えば、ドライバ・モジュールのサンプルコードが多数提供されたことで、個別のハードウェアに対するドライバ・モジュールの移植が容易であり、ドライバモジュールの中であれば割り込み処理を通常のサブルーチンまたは関数として記述できるなど制約が少なく、安全で柔軟なシステム設計ができた。

また、アプリケーションをセルフで開発できることも評価されていた。ある程度規模の大きな産業用システムではVMEバスベースのシステムが採用されることが多かったが、これら自体によるセルフ開発が可能である。OS-9は数少ない、ターゲット上でセルフ開発が出来るRTOSであった(ただし、登場時のUNIXと同程度のCUIを利用する必要があった。その後、クロス開発環境が一般的になるにつれ、CodeWarriorが採用された時期もあった。現在ではWindowsで動作するGUIのクロス開発環境Microware Hawk もしくはEclipseによるクロス開発のみ)。

様々な機能の追加による肥大化もあって、多機能版カーネル(デバッグ機能つき)と小型版カーネル(アトミックカーネル)の2種類に分化した。

(68000版を除いて)Ver.3からはセマフォマルチスレッド機能も追加され、必要な場合はPOSIXスレッドを使用することも可能となった。

OS-9000(マルチプラットフォーム化)

その後、OS-9は全体がC言語で書き直され、OS-9000としてIntel 80386MIPSSPARCPowerPCARM日立 SH-3、SH-4、SH-5等に移植された。アメリカではCで書き直されたOS-9000/68000も発売されたが、市場からは全く相手にされず短期間で販売を終了した。

現在商標は統一され、OS-9のみとなっている[9]。6809用、680x0用OS-9の実体は従来のアセンブリ言語で書かれたOS-9、その他CPU用OS-9の実体はOS-9000である。

OS-9の稼動する汎用のコンピュータ

日本では、OS-9/6809が富士通FM-7/8シリーズ、FM-11シリーズに移植され富士通から発売、日立製作所ベーシックマスターレベル3シリーズやMB-S1にも移植された(開発はどちらも星光電子)。

また、シャープX68000シリーズには、独自のウインドウシステム(Personal Window)を装備したOS-9/680x0 Ver.2.4が、OS-9/X68000としてシャープから販売された(開発はマイクロウェアジャパン)。その後継製品として、マイクロウェア社から、X68030用のOS-9/X68030 Ver.2.4.3も発売された。

他に、フォークスから、FM-11やFM-16βPC-9801に68000ボードを搭載してOS-9/68000を稼動させる製品、FM-Rに68020ボードを搭載してOS-9/68020を稼動させる製品が発売されていた。

初期のOS-9/68000の開発環境として著名なものが、星光電子を始めとした国内のデベロッパーが広く使用していたマイクロボード(マイクロウェアジャパンの親会社)の製品である。同社のVMEバスボードを筐体に収めてセット販売したもので、いわば純正品(?)である。同社からはVMEバスの各種カードが産業用として発売されたが、それ以外にも、PC/ATマザーボードと同規格の基板にMC68030を載せたPCスタイルの製品も発売された。

また、マイクロボード以外にも多くのメーカーのVMEバス(VXIバス)、マルチバスPCI/CompactPCIバスのボードがOS-9に対応していた(いる)。例えば、モトローラ(代理店:丸文)、アドバネットアバールデータオムロンシャープ橘テクトロンタンバック電産東京エレクトロン デバイスフォークスフォース・コンピュータ(代理店:インターニックス)、マイクロクラフトなどの製品である。(五十音順)

米国では、AppleII用の6809カード(The Mill)がOS-9/6809を標準OSとしていた他、タンディカラーコンピュータ(CoCo)、MM/1等、また、PC/ATに68020カード(アルプス電気製)を搭載してOS-9/68020を稼動させる製品が発売されていた。また、Macintosh用OS-9/68000も発売されていた。これは、すべてがスーパバイザモードで動作する当時のMacintosh OSをうまく利用し、TOOLBOXを利用可能としていた。

OS-9が採用された代表的な機器

評価と現状

2012年現在、誕生から30余年を経たOS-9は市場から消え行く存在である。開発は既に終了している模様で、もともとオペレーティングシステムではなくマルチメディア関連のミドルウェアが目当てでマイクロウェアを2001年に買収したRadisysのウェブサイトでOS-9は[Microware OS-9]として紹介され、ライセンスの販売(そしておそらくはサポートも)は古くからOS-9を手がけてきたシステムビルダ3社による代理販売となっていたが、Radisysは最終的に2013年3月にOS-9とMicrowareに関わるブランドを含む全権利をこの3社による共同事業体(Microware LP)に譲渡した。

関連書籍

洋書

テンプレート:Refbegin

テンプレート:Refend

和書

テンプレート:Refbegin

テンプレート:Refend

外部リンク

脚注

テンプレート:脚注ヘルプ

  1. ROM化されたモジュールはカーネルが起動時にROM領域を検索してモジュールディレクトリに登録する。
  2. ひとつのディレクトリにファイル名が同じファイルを複数置けないのと同様に、モジュールディレクトリにモジュール名が同じモジュールを置く事が出来ない。モジュールディレクトリがシステムにひとつしかないOS-9(6809版と68000版)ではマルチユーザで運用する際に時々問題となったが、この対策としてOS-9000ではモジュールディレクトリに階層構造がサポートされた。
  3. 6809のような8ビットCPUにはモジュールのCRCチェックは重い負荷であったため、外部プログラムの実行開始がもたつく事があったが、必要なモジュールを予めロードすることでCRCチェックを先に済ませておく事が出来た
  4. 富士通FM-77AVシリーズの日本語カード用漢字変換のようにOS-9のモジュールでない外部プログラムコードを利用していたケースがある。
  5. 当時、マイクロウェアはMicroware C Compiler をANSI準拠と称していた。実際にパーサーも改良され、ANSI準拠のライブラリも準備されたが、最期までプロトタイプが実装されず、実質はK&R準拠のCコンパイラであった。
  6. Ultra C Compiler は ANSI X3.159-1989準拠のコンパイラである。
  7. ANSI C準拠ライブラリモジュール。Micoware Ultra Cでコンパイルされたモジュールを実行するのに必要となる。
  8. OS-9ではプロセスのプライオリティはタイムスライス事に加算されるエイジの初期値であり、スケジューラはエイジの値によって次にアクティブにするプロセスを決定する。CPU時間が割り当てられたプロセスのエイジは初期化されるが、優先度が高いプロセスは優先度の低いプロセスより大きなエイジ値が維持されやすいのでCPU時間が割り当てられる可能性が高い。優先度の低いプロセスもCPU時間が割り当てられない事でエイジ値が大きくなり、どこかの時点で優先度の高いプロセスのエイジ値を上回る事になる。この「優先度の低いプロセスにもいつかは必ずCPU時間が割り当てられる」事がOS-9のスケジューラの特徴であり、優先度が高いプロセスがレディ状態であってもより優先度が低いプロセスがアクティブになる事がある理由である(この点からOS-9はリアルタイムOSではないとする主張もある)。後にシステム変数によって優先度の低いプロセスのエイジ値の上限を設定できるようになり、ある程度の制御は出来るようになった。
  9. OS-9 Ver.3よりOS-9の名でRISCプロセッサをサポート。

テンプレート:リアルタイムオペレーティングシステム