では RCX CODE も制御プログラムなのか？赤外線を通じて RCX に転送された RCX CODE はインタープリタが解釈する中間コードだ。ものすごく乱暴に言ってしまうと、通常最初に RCX に転送するファームウェアが Java VM (バーチャルマシン)で、RCX CODE が Java VM 上で動作するJava プログラムに相当する。

RCX はその中間コードを逐次解釈して実行するので、プログラムは簡単に書けるし暴走させる危険性も無いが、その分ネイティブコードのような実行速度や、細かい操作は出来ない。本来の対象ユーザを考えれば当然な仕様といえる。

余談だが RCX CODE が転送される際の中間コードは、赤外線でリアルタイムに RCX を制御する時のコードと同じ物である。昔の BASIC インタープリタのコマンドが、直接打つと実行され、行番号を付けるとプログラムになるのを思い出す。

NQC も結局はこの中間コードを生成する環境だ。ただ RCX CODE が生成する中間コードでは、ファームウェアが解釈出来る機能の一部が使用出来ないが、NQC ではそこまで記述出来る分高機能であるといえる。もちろんテキストファイルのコードから即 RCX に転送出来るお手軽さ、Win / Linux / Mac というマルチプラットフォームでの動作も特徴的だ。しかし実行出来る機能や速度は RCX CODE と大きな違いはない。

(11/19加筆) ちなみに現時点では RCX CODE が生成する中間コードでは、標準ファームウェアの機能をフルに使いきっていないようなので、nqc でプログラミングする方が反応の良いソフトを作成することが出来るようだ。しかし同じファームを使用している関係上、RCX CODE 環境のバージョンアップによって両者の差は少なくなっていくと考えられる。

では RCX において、中間コードに対するネイティブコードとは何なのか？RCX には日立の H8 と呼ばれるマイコンが搭載されている。この H8 用のコードこそ、RCX にとってのネイティブコードなのだ。H8 用のコードを生成するクロスＣコンパイラやアセンブラを用意すればネイティブコードを生成する事が出来る。

H8 用クロスＣコンパイラやアセンブラは、本家の日立から販売されているものだけでなく、いくつかのサードパーティからも販売されている。しかしソースを公開したり共有する場合には、だれもがフリーで入手出来る GCC や GAS を使うのが一般的だろう。LSI-C86 試食版のように、気軽にフリーで使える H8 用コンパイラがあるとよいのだが....。

これだけあれば、RCX に接続されたモータを回すだけのプログラム程度なら作成出来るのだ。特に OS などといった物は必要ない。必要なのは RAM 上にプログラムを配置するリンク情報と、モータ制御用 I/O のあるアドレスと、ファームウェアと同じ様にRCX にダウンロード出来るようにするための文字列の３つだ。

さらにセンサを１個だけ使う程度なら、OS など必要ない。この場合は A/D コンバータの使い方と、場合によっては割込みの使い方が必要になる。

しかしここからが問題だ。複数のセンサやボタンのそれぞれの状態に応じて個別にモータを動かすといった動作を行なおうとした時には、タイマ割り込みでセンサの値の変化を監視し、値に応じて処理を切り替えるといったしくみが必要になる。

タッチセンサが CPU の割込みに入っていて、変化があれば割込みが入るようなシステムであれば割込みドリブンなプログラムを作成できるが、RCX のセンサはあいにく全て A/D 変換して値を読取るものだ。値が変化したかどうかはポーリング等の手法で定期的にチェックしなければならない。

ここまで来たら、もう OS が入ったも同然だ。先程のセンサ監視をするタイマ割り込み処理と、変化に応じて処理を切り替える部分を合わせたものが正に OS の核となるのだ。これに色々なサービスをシステムコールという名で提供すれば、もう OS らしさがプンプン漂う。

OS と言っても結局はプログラムの一部に過ぎない。何も特別なことをしている訳では無い。特に PC 用の OS と違って組み込み系の OS というのは、ファイルシステム等さえ無ければ簡単なものを指す言葉と思ってもいいだろう。

誰もが Linus Torvalds になれる世界がそこにある。