携帯電話のような大規模な組み込みシステムになった場合の開発の複雑さはシステム試験の難しさなどからなのか、一度作ってしまった過去の資産あるいは遺産を相続せざるを得ないという判断が通常の通信機メーカーには渦巻いている。「変えれるものならばスパッと変えたいですよ」とは知人の弁である。通信キャリア仕様などにべったりと漬かった製品開発からの決別は、まったく異なった国向けの開発チャンス位しかないといえる。「そんなチャンスがあれば、是非にも活かしたい」と目を輝かせる若者達もいるのだが製品開発の舵取りをする世代にはそうした元気がなくなっているようだ。

プラットホーム開発を進めながらも、最後のところで行詰っている様には何か変えられない壁があるようにも映る。新たなバイナリー開発環境を提示しつつ、フル活用した実装が出てくる段階で足かせになっているのは既存の組み込みアプリケーションパッケージであったりする。抽象化の進んだ実装仕様などの不評もあるのだが、意外に重いアプリケーションの全貌にはシェアや実績などとは裏腹の面が伺えるようだ。逆にキャリアから不評を買っているソース未公開のアプリケーションの実装性能などは、逆に流石といえる性能を出していたりもする。世の中の評判と実際の評価のギャップは内容や性能などを見ない体質に根ざしてしまい政治的な判断のみで動いている現実に隠されてきたようだ。

組み込みアプリケーションの多くは、ＩＴＲＯＮベースの実装に基づいた開発が国内での主流となっている。これは坂村先生の成果でもあり、アプリケーションの雛型としてRTOSベースのタスクとして設計することで今までのギリギリの開発が実現されてきたようだ。しかし、そうした実装に支えられているにもかかわらず何故大規模なシステムとして携帯電話の開発が複雑怪奇になってしまうのかについては言及がないように見える。RTOSベースのＩＴＲＯＮなどの標準的なスタイルでメーラーもブラウザも開発されているはずだ。日曜プログラマーのWindowsプログラムとの差異はどこにあるというのだろうか。実は、標準と捉えているRTOSベースの設計に問題点があるのではないかという疑念が湧いているのだが。

リアルタイム性能を実現すべき部分としては、通信プロトコルスタックなどがあるのは厳然とした事実ではあるのだが、それ以外のアプリケーション部分までもそうしたスタイルと同様の進め方で行っていくことが良いのかどうかには言及がないように見える。実は、以前開発したＲＴＯＳではスパゲッティになるようなコーディングからの決別という意味も含めて発散型ともいえる花火のようなスタイルのイベントモデルでの設計に範をとったＩＴＲＯＮ準拠のRTOSという摩訶不思議なものを開発して実用化に漕ぎ着けているのだ。並行処理の概念で課題となるスタック領域問題に手をつけたシングルスタック領域による並行処理システムである。

無論こんな書き方をすると荒唐無稽のように思われるかもしれないのだが、実際には記述する言語であるC言語の特性を利用していくことで柔軟にこうしたシステムで開発することが出来るのである。やりたいことを実際にコードの上で前処理してしまうことが出来れば容易なのであり、このためにはコンパイラ開発のツールであるYACC/BISONなどのGNUツールなどでちゃっちゃっとコードを書き上げるという手法が適用できるのである。幸いにしてANSI-CベースのYACCコードなどはインターネットからでも入手が出来るし、YACCの書籍にもついていたりする。問題は、そうした経験をした技術者が少ないこととそうした言語処理を組み込み開発の中で手がけるというテーマとしてとらえている開発チームがいないことなどが重なっているからだろう。

同様にコンパイラ技術で出来る範囲の事と、RTOS開発やタスクコンテキストのシステム設計にまで配慮できる技術者も少ないので殆ど途方も無い果ての成果だとも言える。製造メーカーの開発現場でRTOSや言語処理の開発をしたうえでシステム開発の経験といったスキルマップを踏んでいける幸運を掴むということも現在では皆無なのかもしれない。異能の技と呼ばれるかも知れないが、開発当時の目的は実は、組み込み開発現場で直面する不安定な現象であったりするITRONベースの組み込み開発手法に潜在しているスタック障害を解決することであった。言い換えればスタックを使わないでＩＴＲＯＮベースの並行処理を実現するという方法論の模索でもあった。

タスクとして掛かれたそれぞれのメイン関数においてのみシステムコールを利用することが出来るという大前提を作り出したのだが、この制限が特徴でもあり使いにくいと呼ばれる理由でもある。明示的に必要なコンテキストとは、こうしたメイン関数の中のローカル変数をタスクコンテキストであるとするのがこのシステムの肝でもある。ローカル変数をタスクコンテキストにするためには、タスクメイン関数の中のローカル変数の宣言を外部構造体の参照定義に変えるということが必要になる。これはローカル変数の宣言ブロックの識別が出来れば可能である。そしてこの構造体のサイズをタスククリエートで呼び出される処理としてサイズオブ演算子で返却することでカーネルがヒープから切り出して割り付けるのである。後述するイニシャライザ部分である。

こうしたタスクを呼び出す実体を仮想カーネルと呼ぼう。このカーネルはITRON準拠のシステムコールなどをカバーできれば特に拡張の必要も無い。無論サブセットのチップセットベンダー特製のRTOSでも構わない。この仮想カーネルが動作するのは大本のRTOSでのUIタスクの位置付けで走行するのである。仮想カーネルの配下には複数の仮想タスク(大本のタスクとは異なるという意味で仮想タスクと呼ぶ)が収容できる。仮想タスク毎に管理すべきは、タスクコンテキストであるところのヒープから切り出した領域変数とレジスタ、最後にシステムコール呼び出しで抜けた時の引き数と出口番号である。ITRONスタイルのオリジナルコードからは、イニシャライザ部分、スレッドデスパッチャ部分と、システムコールごとに切り出されたスレッドブロック、そして元の処理のQuit処理であるターミネータ部分などが生成される。

システムコールを予約語としてパースした結果、この単位でコードが分割されてシステムコール部分では、パース順で発行されたＩＤが割り付けられて引き数とともに保持されて仮想カーネルにリターンしていく。このシステムでは仮想タスクが仮想カーネルから呼び出されて動作しているのでシステムコールとは引き数をもってリターンしていくことをさすのである。この辺りの概念が最も理解されにくいようだ。このリターンで引き渡された引き数でTCBに積みつつ実際のシステムコール処理を仮想カーネル自身が行う。仮想カーネルは自身がRTOSとして複数の仮想タスクを管理しているためにこれらのスケジューラ処理を行い必要な仮想タスクに実行遷移をする。システムコールの結果としての外部からのイベントやシグナルあるいはメールボックスなどで仮想カーネルとしてディスパッチしていく。

仮想カーネルから復帰する処理では、レジスタ復帰処理とヒープポインタの復帰などを行い、発行元のＩＤに基づいてディスパッチ先に戻っていく。この辺りは、生成されたスレッドディスパッチャ部分などを利用してswitch/case等で分岐していくのも実装例のひとつといえる。無論戻った先である、各スレッドブロックで行われる処理で参照されるローカル変数のコードは領域変数ポインタで参照される構造体の要素としてアクセスされるわけでもある。ＩＴＲＯＮ的に設計したコード処理を機械的にヒープを用いたコーディングに変換するというのが、この方法論のもうひとつの肝でもある。

ここまでの事をしてどんなメリットがあるのかといえば、アプリケーションごとの独立性が高まるということになる。メモリプロテクションなどがないシステムにおいてRTOSが管理しているスタック領域のオーバーフローなどによる侵犯があった際の暴走を皆無に出来るのである。実際に適用された端末システムにおいて当時の16ビットマイコンでの実装で有用な成果を得ているのである。すでに7年くらい昔の話であるが。実は当時、このRTOSの開発目的は基盤要素技術開発を進めていた研究所の次世代RTOSまでの繋ぎの位置付けで当時問題となっていたシステム開発での障害ランクで高位にあったスタック障害を避けるという目的でのみ開発されて、当時数年利用していた。

そんな過去の事例を忘れていたものの組み込み開発の方法論をRTOSベースの並行処理モデルのままで、開発規模の拡大に向かっていった携帯端末の姿でもある。こうしたRTOSに内在するスタック問題には手をつけずに個々の複雑なアプリケーションの開発成果を一気に鳴き合わせをして組み込みシステムテストで評価していくという無体な方法論が実はまかり通っているようであり、こうした流れの中ではスタック問題から切り離してアプリケーションの完成度と自立度あるいは独立性を確保していくという方策検討には不十分だったといえるのではないか。日々の開発の中で、こうした開発方法論までも踏み込んだ改善をしていくということが、あるべき姿だと考えている。

さて、ここまでの道具立てを用意して従来型のソフトウェアの移植を自動的に行う手助けをするということよりも、実は、もとよりそうしたスタイルで設計すればという声が出てくるのもやむなしなのである。道具立てを用意する意味は、開発に疲弊した意識の無い過去の遺産相続に支払う税金対策であり、新たに遺産放棄をすることで新規に設計することの軽さや容易さという点を考え直してほしいという意味の比較論でもある。ソースコートなどで保有する遺産を出来る限り利用したいもののUIベースの処理のみ開発設計スタイルの変更への手助けとなれば、疲弊した携帯電話のバベルの塔建設の一助になればと願ったりもするコンサルタントとしての思いでもあるのだが・・・。