最近の若い技術者の教育においては、機械語やアセンブラを教えずにC言語でそうした制御を行わせるらしい。まあ、メーカーの技術者にとってはソフトウェア仕様書が処理手続きの言語であって、C言語は機械語であるのかも知れない。メーカーによっては、ポインターの使用を禁じているところもあるらしい。ポインターを使わないという選択肢を選ぶ限りにおいては、C言語での利用は安全なものとなるのだろうか。ある意味でそれを狙っているのならば正しいのかもしれないが、配列とループで構成されるソフトウェアを見ても何も感じない感覚に陥ってしまう人たちを指導したいのならば機械語を正しく教えることは必要なことだろう。「最近はマイコンが速いから関係ありません」などと仰る人はパソコンアプリの開発に従事しているからだろうか。

組み込み開発という世界は、それぞれのターゲットアプリケーションを実現する上で必要なシステムを構築するということである。自動車電話というシステムを構築するために、当初はマイコンなど存在していなかった。マイコンの代わりに構築されていたプロトコルを処理実現するための制御コントローラを起こすことから始まっていた。RCAの4000シリーズなどで作られたコントローラはプログラム機能を持ち弁当箱程度の容積をそのためだけに必要としていた。後年にも画像処理の世界でも同様で、TV画像処理のエフェクターを開発していた先輩技術者は、高速なビットスライスプロセッサーを組み合わせて使って専用のマイクロプログラムを書き起こしシステムを開発していくという時代でもあった。ハードもソフトも開発していく・・・。組み込みソフトの起源は、こんな風景から始まったといえる。

アセンブラや機械語という世界から高級言語の世界が組み込み開発に登場してくるのには、高速なマイコンか高性能なコンパイラかの二つの切り口が必要だった。また、割り込み処理とメインといった組み合わせで実現していたシステムに高機能を持ち込んでいくためにはTRONなどのRTOSが必要となっていた。そうしてC言語とRTOSの両面が組み込みソフト開発を新たな開発に導いてきたのである。現在では4ビットマイコンなどで開発していた家電調理機器までも8ビットあるいは16ビットマイコンなどでC言語で開発しているらしい。開発効率や性能がバランスが取れてきたことが背景といえる。マイコンコードとC言語の期待する動作振る舞いの差異などをノウハウと考えていた時代から、最近ではC言語のコード効率が最良になるようなハード設計がなされるようになったりしている。

自身でCコンパイラの開発を経験すると、マイコンコードの生成についての思想やシステム動作としての思想などについて何か別の解があるように思えてきた。そんな中で、出会ったテーマは携帯電話システム開発のデジタル化という技術提案という入札チャレンジであった。低消費電力のマイコンを高性能に使いこなすという技術は、高度な効率で制御を使いこなすというテーマともいえた。自社製マイコンではなかったものの、なぜか慣れ親しんでしまっていたあるマイコンのアーキテクチャー自体に使いこなせていないアーキテクチャーが存在していることが気がかりとなっていた。使われない命令やレジスタがあるというのは、ベースとなるアーキテクチャから移行あるいは流用してきた過程で発生したらしかった。マイコンメーカーが不要と割り切ったアーキテクチャーを使いこなそうとするには専用のコンパイラが必要だった。

主題となる技術提案は、四多重のTDMA制御を行っていく基地局装置の実装に向けて低価格かつ低消費電力で実績のあるマイコンをフル活用すべくタスクとしての属性をコンパイラに理解させてリエントラントなコードを展開可能にするというものだった。RTOSからのインタフェースもTRONに合わせた形で設計検討をした技術提案だったが、無謀とも映る提案は、「ハード性能が不十分だということですか」「通常のコンパイラが使えないということですか」といった視点でしか見られることはなかった。基地局装置のラックに配備されることを想定した上でファンのいらない構造を想定した上での性能着地点などを見越しての提案の意図は、理解されることはなかった。コンパイラを扱うということはアプリケーション実現の上で大きな意味を持つということが自身の中で消化されてきたことの萌芽ともいえた。

いつまでも慣れたマイコンに縛られていては、次に移れないということも自身の技術好奇心の方向を少しずつ変えていった。自社製の高性能マイコンの登場などとの連携や、自身ですべてのコンパイラを開発していくわけには行かないという事実などから新たなことを模索することにした。コンパイラの前処理系としての取り組みが出来ないだろうかというのが私の頭の中のイメージから離れないで居た。辿り着いた結論は、C言語で記述されたコードを前処理してスタックを使わない形のCコードに変換するというものだった。この技術にはプリコンパイラと名づけたのだが、実際の処理コードのイメージとRTOSとの分担などを定義して高性能で大規模なアプリケーションをリソース少なく動作させるということが狙いだった。この目的にはプリコンパイルという技法がマッチした、実際の実装開発をしたチームにまでは実現方法について強要しなかったため彼らが作りやすいマルチパスのスクリプトとして開発がなされていた。

前処理系を開発して展開させたコードは、やはりCコードなのであり、見た目にはコード効率が低下するような印象を与えていたのだが・・・。実際のコード生成の観点からみると、ローカル変数のアクセスと外部構造体に配置された変数領域のアクセスは同一のコストで実現出来ることがわかった。最近のRISC志向のマイコンの構造は、シンプル過ぎるのかもしれなかった。三菱のマイコン向けに開発した技術を実際の製品に展開して新たなデジタル化無線端末の開発に成功した。実は、この技術は最近になってITRONベースのスパゲッティコーディングに鉄槌をくだしてイベントドリブンな設計に切り替えるための移植ツールとして使えるということなども解かった。ソフトウェア技術の追求をしていくことの奥は深く、いろいろな視点で技術を見ていくことが必要になると感じる。16ピットの時代のプリコンパイラが32ビットの時代でも、まだまだ活躍していけるのである。未開拓な技術分野といえるのかもしれない。

ポストコンパイラというものについても最近は、H君などと話をしているのだ。最近の通信機器メーカーではコード記述についての制限が多くて、シンタックスチェッカーの上から使えない技法がたくさんあるのだという。こうした会社では効率の良いコードが書けないらしい。効率よりも安全重視という世界になっているそうで、UIの動作などを見ているとシステムバランスの崩れた動作などをしているので検査体制が設計思想までを検査できていないように見られるのだが。まあ検査が通ったコードを安全かつ適正に効率よく変換できるツールがあれば、間違いのないコードで効率も果たせるのかもしれない。ここでいうポストコンパイラは蛸なコードを書き直して最適化してくれたCコードに書き直す技術なのである。この技術開発こそはXPスタイルでノウハウを高めつつ開発していくことが必要なのだと彼はいうのだが・・・。

こんなジョークも飛び出しつつの知己たちではあるのだが、最近は真剣に開発スタイルのシフトを離陸させようとしている。熱海の温泉旅館にも泊まり、問題点の再確認と再認識をしているという報告もあった。見直しをオブジェクト指向スタイルでの開発に切り替えて新たなプラットホームで推進するのだと、にこやかに語ってくれるOOP達人のチームには、システム開発をOOPで達成した若き技術者たちも新たな難しいテーマを求めて自ら集ってきているというのだ。最近ではLinuxベースの携帯電話の開発という話が進んでいるようで、先日のプロジェクトＸの視点と何か違和感を感じてしまうのは私だけなのだろうか。まあ、私自身は少し前のマッキントッシュのシステム６のマルチファインダーくらいの範囲で十分だと思っているのだが、そうしたアプリケーション開発をしてきたエンジニアの意見を聞きたいものである。無論超漢字が携帯の上で動くべきだという意見には大賛成である。

クロック16MHz程度の68000で動作していたマックのシステム６時代のことである。現在の携帯電話で、これ以上を望んでいるのだろうか。確か当時のパワーブック100は、国内のメーカーがOEMを肝いりで開発していたように思い返すのだが。実際、当時私もかなりPowerBook100を使いこなして重宝していた。あの程度のことが使えれば十分という思いはある。また80286で格段のパフォーマンスを実現してマルチメディア機能を実装していたBTRONなどを中心になって開発推進していたメーカーもあった。いずれも日本のメーカーであったと記憶している。これらのメーカーが携帯を開発しているのであれば、当時の技術を駆使して使いやすいすばらしい端末を作ってくれるはずなのだが、あいにくと最近物忘れが激しくて名前を思い出せないのがくやしい。あの一団の技術者がいるのなら雇って開発に当たらせたいものなのであるが・・・。

アプリケーションプロセッサも時代の趨勢からは取り残されそうな状況にあるらしい。やはり課題は消費電力であるようだ。モバイル用といって売り出した割には、携帯で必要とするアプリケーションには向かないという現実に遭遇しはじめたらしい。電池を燃料電池に切り替えて問題をすり替えないといけないようだ。低消費電力の設計には、やはり他社マイコンに一日の長があったのだろうか、それでそのメーカーと合併することになったのだろうか。専用ハードを無視して汎用のアプリケーションプロセッサで実装するという選択は、高機能化の流れの中で早くもメッキがはげ始めたらしい。コストと性能のいずれの点でも低消費電力には結びつかないということになるようだ。組み込みの本質を理解しないままにソフト開発を進めてきた開発の歴史が終わろうとしているといえる。お客様の問題点を技術者として着実にフォローしていくという当たり前のことがなされるべきなのである。