驚愕の4MBの空間を使い切る

最近の携帯端末のソフトウェアサイズは，うなぎのぼりである。8MBのFLASHを積みながらもハードウェアの制約で4MBしかコード空間にはアサインできず残りの領域はデータファイル領域としている。EFSが組み込まれているのも最近の特徴かもしれない。UIでのアニメーションやカラー化の影響などでRAMも2MBは必要と言われる時代になっている。8MBのFLASHと2MBのSRAMが必須になりつつあるのだ。また、こうした状況では機能の取捨選択をするにも事欠き結果として積み込み一方となっているのも元凶かもしれない。コンパイラが賢ければ、もっと効率のよいことが出来るかもしれないがドライバとアプリケーションを同一方法論で搭載する時代は終わりに近づいているように思われる。KVMなどの搭載が叫ばれるこのごろであるがムーア博士のFORTH言語などの適用が、より実践的なアプリケーションサイズ削減に貢献するように思われる。コンパイラの出力コードをアセンブラからFORTHに切り替えて生成することを追及してみるのも現実的な技術として面白いかもしれない。すでにMicrosoftCではライブラリとして中間コードを生成して解釈系を作り出す機構が昔から搭載されていたようだし組み込みの世界もこうしたサイズオーバーの時代を迎えて直す必要があるのだろう。端末技術の追求の中でコンパイラにまで手を広げる必要があるかないかは意見が分かれるところだが開発環境やソースコードで提供していけるメーカーであれば考えてみる価値があるように思われる。

私が気になるのはコンパイラが生成する余剰空間の取り扱いである。たとえばポインターとして作り出すコードは32ビットを生み出すわけだがコード空間は16MBを超えることがないと仮定した場合にはポインターサイズは24ビットでよいことになる。しかしアーキテクチャの制限から32ビットのポインタを作り出してしまう。バイト型で十分な変数があるにも関わらずアーキテクチャの制限から不要なRAMをスタックやSRAMやFLASHに浪費している。こうした空き領域がどれほどなのかを検討してみるのも意味があるとおもうのだがいかがだろうか。無駄と思われるコードも性能を追求する部分においては正しいが機能を満たすことが求められているアプリケーションにおいては別の解決策があるように思われる。解釈系を介在させることによる効率化は計り知れないものがある。私は機能競争に拍車をかけるつもりはないがケータイに求められている機能が拡大している今日においては従来の方法論のまま進めているだけでは意味がないように思われて仕方ない。

開発の手を緩めることなくこうした技術革新にもてを染めていくことが総合メーカーの技術力として必要なことではないのだろうか。音声を圧縮するデジタル化技術は通話という技術のデジタル化に必須であった。今、通話・通信は出来てあたりまえで音質も良くてあたりまえになろうとしている。ことさらに方式の是非を比較するのは単なる宣伝効果を狙った延命策にすぎないのだ。今手を染めるべき次世代の通信技術や端末開発技術について革新的な方法論を考えているのかどうかが、今後発生してくる各種新技術の吟味の目を養うことにつながってくると思われる。携帯端末のサイズ競争や重量競争の時代を過ぎたことは、カシオの端末が売れていることなどからみても明白である。小さすぎて使いにくさが出てきたりすることが発生するとなんの競争なのかがわからなくなる。

リーナスが参画しているベンチャーではインテルアーキテクチャを活用する斬新なソフトウェア構造をもつ新型チップを開発した。消費電力あたりの性能などにも思いがまわり。またかつてバイナリーコンパイルという技術が登場し消えうせたかにみえたものも取り込み実は醸成していたことなどからも、まだまだこうした端末での戦場は，場所や品を変えて進んでいくように思われる。提供されるプラットホームを待っているだけではメーカーはいけないのではないだろうか。

やはりメーカーには基本OSや開発言語などへの基本技術の研究に携わる人材を活用していくことが、必要なのだと思う。不遇な人材がいるとしたら社会への罪悪である。公共の器を活用していくという翁の説話などからも、会社を叱咤する立場への転籍なども必要なことであろう。かつて第五世代開発などでICOTを興したりした日本ではあるが組み込み技術の大国でもあった匠たちの技を今失おうとしているのではないのだろうか。

梅雨までのひとときを楽しんでいたのだが、もう雨がちな陽気に変わってきそうである。半年の研鑽期間を経て、とりまく環境も大きく変わろうとしている。巷ではブラフと言われていた弊社の基地局参入騒動だが、実際問題としてブラフなんかではなくて、まさに国際化の流れの渦中にいることを郵政省自身が気づいたのではないだろうか。国内三社のぬるま湯的な状況においてIMT2000の割付を進めてきていたところに、「無償でチャネルの権利を入手できる」というおいしい話を米国と共同で焚き付けたのだから大変だ。日本の通信業界は官民馴れ合いとなっていて、天下りを受け入れつつ仕事の人脈を広げていくまさに日本式のロビー活動なのかもしれない。ベルを分割して競争させ、周波数権利もオークションにかけている米国の状況が参入してくるとは考えてもみなかったのだろう。結果はDDIの技術トップの間違った判断を是正することで解決をみてしまい、面白みにかける展開となった。DDIを買いとるという選択枝もあったようだが、免許申請をすることの方が容易なのだった。

今回の波紋は、今後の日本の無線行政に大きな一矢をはなったと思われる。NTT法が改正され外部への展開が進むだろうという事とともに、双方向の大きな流れをまた産んでしまうと考えられる。こうした法の庇護の下で暮らしていた、ある種の業界にとっては大きな転機を迎えたともいえるだろう。

ベンチャーのよい特性がまだ残っているこの会社の前向きな取り組み姿勢は、私の意識にも共感する。無線機器の開発に限らず多くの製品・サービスは、ソフトウェアの介在なくては競争力を産まない。物づくりとしてのソフトウェアの力と先進な要素技術としてのソフトウェアの二面を追求していかなければならない。仕様書を定義してくれれば生産としてのソフトを構築出来るという感性の仕事と、サービス・製品の技術方向性を見定めつつソフトウェアの基礎研究を進めていくということが求められる。私自身もメーカーに在籍して四半世紀近く技術屋として暮らしてきた結果としてそういう事を認識してきた。日本では、そうしたサイクルを回すよい土壌としてＮＴＴと各メーカーとの関係があったのだと思う。

メーカーとＮＴＴとの関係を支えてきたのは、互いに補完しあう相互技術があったからに相違なかった。トラックの荷台に装置を積んで自動車電話の開発を進めてきたベンチャー精神を私は尊敬する。またそうした流れにのっとり子連れ狼ならぬ乳母車に積んだPHSの開発などもそうしたものに違いはない。そうしたベンチャー精神に支えられてビジネスモデルを提起して一事業を興してきた業務用無線の歴史なども興味深い。いまそうしたビジネスモデルの考案をしていくことも研究テーマの大きな範囲であろう。ビジネスモデルが特許になる時代なのだから。豊かな端末の提供で、PHSなどの価格１００円や無料の広告などをみると「通信の水道哲学の領域にまで達したか」という見方もあるだろうが、サービス費用や能力などの面から昨今のi-MODEのサーバーダウンや投資効果という観点での技術力などにおいても、もっとシステム的な観点で取り組むことで道が開けると思うのだがトラック３に入札することで精一杯になってしまうのではまずいのだろう。

超高速なマイコンの開発というテーマが最近では、単位面積あたりあるいは投資コストあたりの最高速なマイコンの開発というテーマに変わりつつあるようだ。インテルの命令をバイナリーコンパイルしつつ自分の考える合理的な命令に置き換えて効率よく低消費電力で実現するこうした技術を、さらに利用して群体で動作するシステム提案が出来れば、ビジネスモデルの改善につながり顧客満足につながっていくのである。

端末の開発のみで手一杯という状況ではお先真っ暗というのが現在ではないだろうか。幸いにしてこうしたインフラサイドの問題提起は社会からの要請もあって順風になってきた。おもしろい素材もあふれてきた。しかし残念ながらそうした面白さを伝える仕組みがなくなっているように感じる今日この頃である。仕事や技術の本質に好奇心を持つことが大きな鍵なのだが難しいのだろうか。いろいろな創業の時代に出会っていろいろな好奇心を大切に育てる事ができて今に至っている。これからあらたな創業を自分自身からの提案も踏まえて周囲の方々の力添えももらって進められそうである。こうした楽しさを少しでも伝えて、メーカーの方々にご理解いただきエンドユーザーへのサービス提供をはかっていくのが
当面の私の存在意義である。

そうしたメーカーの方々への支援作業において、あらたな創業の芽がありそうで諸先輩のお知恵を拝借し自分自身で咀嚼しているのだがよく噛まないと腹ごなしが悪い物である。一つのアイデアがメーカーと同一レベルの開発部隊を擁して日本サイドで先行開発の雛形を示していくということである。このことにより、各メーカーで競合する開発の部分の合理化が図れるというものだ。しかし、米国と日本の相互で仕事を依頼できるようなソフトハウスでデジタル無線の技術力があって英語に問題がなくて、独立系というようなところはなかなか見つかる物ではない。今は、W-CDMAで日本では技術屋がショートしているのが実状である。Y2Kが終わってあぶれてしまったような技術屋を掴まされるのがオチでもある。ソフトハウスの紹介にいって逆に「すぐに、優秀な人材を１００名そろえられますか」と京都で問いただされた事を思い出して苦笑した。３０名でも良いのだが無理な状況であろうか。ソフトハウス詣でをするのは、メーカーがFLASHROMなどを求めてさまようのとにている。

GWの憲法記念日など薫風のなかで歴史に思いをはせるのはよいことではないだろうか。皆さんは有意義な休日を過ごされただろうか。

最初の商用自動車電話にはサブルーチンがなかった。

富士通の出向研修を終えて、実務に戻った。事業部では、長年の開発で培ってきた自動車電話の出荷が始まり熱気に包まれていた。自動車電話では、マイコンを搭載して出来たと思われる人が多いのだが当初の自動車電話においては専用ステートマシンを搭載している場合も多かった。4bitマイコンなどでこしたステートマシンを構築した事例やRCA4000シリーズを駆使してCMOSのボードによるステートマシンを構築していたものもある。こうした商用サービス以前に開発されてきた試作マシンには、ロジックボードとマイコンボードとが別に出来ていたりした。

商用モデルにおいては、こうした自分達で開発したステートマシンの機能設計を利用すべくマクロ命令と呼ぶ仮想コードを解釈実行する構造を採用していた。アセンブラソースコードのイメージを抱いていた私にとって衝撃的な内容だった。フローチャート上にサブルーチンのアドレスのみが羅列されているようなコードと所々にラベルのような実際のコードが書かれていた。割り込み処理のような部分はあるのだが、メインルーチンというようなものが存在せずにフローが記載されているようなソースコードだった。

設計を担当されていた技術者の方々の英断により,当時高価で低速だったメモリインタフェースを取らずにドライバとインタプリタの通信速度を改善する目的で汎用レジスタの一部を相互通信用の高速スクラッチパッドレジスタに位置付けていた。すなわち割り込み処理で退避せずそのまま用いるということである。この英断によりドライバへの指示は、このレジスタへのビットセットにより行なわれ、また指示解除はリセットビットで行なわれていた。

Z80の裏レジスタの概念のように独立したレジスタ群を要求する声が多い中で逆転の発想でマイコンの仕様を見つめていたようだった。こうした犠牲になったレジスタは、スタックポインタであった。ドライバとマクロ命令という概念で設計を進められていた技術者にとってスタックポインタの効用を活かす道はないと判断して高速通信レジスタの位置付けで設計がなされていた。従って、この商用モデルにはサブルーチンというものが存在しなかった。しかしマクロ命令としての実装は実行すべきアドレスをそのまま機械語として配置した単純化した解釈系でありいわゆるFORTHのようなものであった。

しかしスタックポインタを犠牲にしていることなどからレジスタやRAMをインタフェースとしてマクロ命令の相互での情報のインタフェースは為されていた。サブルーチンのないこの商用化モデルの一号機は、華々しくデビューしていった。こうしたマクロ命令の機能を網羅する測定器としてフローモニターがあった。マクロ命令のインストラクションポインタとして配置された特定メモリの更新をトレースするロジックアナライザのような道具である。インタフェースは16個のLEDと放電プリンタである。

銀色の光沢のある、独特な用紙に電気を通して皮膜を破壊すると下地の層が見えて黒く印字される機構であった。昨今の方々はまったく知らない世界かも知れない。これによりリアルタイムトレースが実現されていた。仮想マシンの振る舞いをトレースするだけでは不十分であり、マクロ命令の通過情報のみをトレースするマーカーという機能も実装されていた。マーカーは特定アドレスへの書き込みのみをトレースする機能であり実際には、マクロ命令のトレースとの相違はアドレスの違いのみであった。こうした仕組みのよりパフォーマンスを時刻つきでリアルタイムトレースして検証できるようにしていた。富士通での研修成果は、こうした概念の理解を推進するのには役立ったが諸先輩の匠の技に到達するのは容易な所業ではなかった。
輸出向け自動車電話の端末開発チームはもぬけの殻
商用モデルの対応のなかで、解釈系処理の技術を身に付けつつあるなかで、輸出向け自動車電話端末の開発の応援に借り出された。自社でフルセットターンキーで納入する交換機・基地局含めての大規模な開発であった。100名を擁するソフトウェア技術者の集団が当時の初芝ソフトのビッグプロジェクトでもあった。端末開発は、8ビットマイコンで行なわれていて仕様からなにからすべて自社で開発したこともあり端末開発チームサイドの外人部隊二名は数多い仕様変更に耐えうるべくテーブル構造で端末動作を記述していた。これも国内向け商用モデルと同様の考え方ではあったが、彼らは割り込みとメイン処理とでレジスタを共有するほど多くのレジスタを持ち合わせてはいなかった。二個のアキュムレータとインデックスとスタックしかなかったのである。仕様変更の話などを聞きつつ彼らの応援をしていたが、いつしか彼らが蒸発してしまった。こなくなったのである。自分ですべて面倒を見ることになり8000行ほどのソースコードを引き受けた。問題の多くは端末の振る舞いをどのように実装するのかということとプロトコル自体があいまいであることなどだった。

このことによりソフトウェアの機能変更はしょっちゅうであった。端末の限られた空間8kBではその機能の実装自体が無理だったのかも知れない。テーブル構造の見直しやインタプリタの再帰利用などでテーブル自体のサブルーチン化などを達成しつつ日々機能追加とコード圧縮の日々となった。気がつくとソースは10000行に達していた。コードサイズは同じである。機能を網羅する部分と性能を満足する部分とがソフトウェアにはある。これらを同一の方法論で行なうと効率が悪化する。効率の追求をこうした限界状態で経験できたのはこの上ないチャンスであった。割り込み処理で倍速を達成すべく(途中で伝送速度を600bpsから1200bps)に向上させる必要が生じた。機能は毎日のように追加が要求された。コードサイズの増加は許されなかった。解釈系が機能網羅を果たし割り込み処理によるドライバは性能を満足させるという構図である。しかし、ハードウェアの不備があり性能はどうしても果たせないことがある日判明した。RAMが4bit幅でしか誤り訂正などの機能を実現できないためである。割り込み処理のスライディング配置など工夫は凝らしたものの要求水準としての着信応答あるいは発信接続には至らなかった。全二重通信が処理できないのであった。こうした極限下での動作は、インタプリタがあとから追いついて機能を満たしていくというのが目で見て取れる状況であった。最後どうしても機能が入らなくなった。アセンブラソースをいくら眺めてもアイデアが出てこなくなった。仕方なく機械語のダンプリストを眺めて一日過ごした。午後になり気になる点に気がついた。コードに偏りがあることが判明した。全般にテーブルが4kB近くありこのテーブルが16ビットのアドレスで出来ていたのだが、EとかFとかが多いのだった。6802を採用していたこともあり8kBのROM空間しか持たないことがこうした制御テーブルでのそれとしてはE000-FFFFまでのアドレスを示すことから仕方がなかったのだった。私が着目したのは、アドレスの上位3ビットが無駄に思えたのである。テーブル構造の見直しというよりも仮想マシンとしてコードの定義をすることにした。上位3ビットで命令をデコードするようにした。111ならばモジュールで011ならばテーブル内での分岐、101ならば条件分岐といった具合である。仮想マシンコードとしてのアイデア持込でようやく機能集約が可能になり出荷先での三度目のROM交換も達成できた。三度にもおよぶ回収費用は大変であったと思うがその後の出荷以降で採算が取れたようだ。私は、勉強を兼ねて最終ソフト完成後現地に三週間ほど初めての海外出張として赴いた。後年悲劇の地と呼ばれることになるDOHAである。

マイコンをシミュレータでデバッグする。
仮想命令を定義することは海外向けで技術的なメドだてを終えて以降のパーソナル無線の開発などに応用を果たしていった。時代は、アセンブラからC言語でという掛け声が連呼されたが、笛吹けど踊らずでVAXを一億円で導入するという当時の大英断にも関わらず利用者は、変わり者の烙印を押された私と当時の新入社員の女子大卒のうら若き乙女達だけであった。viでcのソースを開いていると勝手に画面に書き込みをしてくる実習テーマを与えた一部の指導員に文句も言いたくはなるが、将来の担い手である有望な若手技術者にそんなそぶりを見せてはいけなかった。初めてのc言語適用機種は4ビットマイコンを二個搭載したMCA無線機であった。

RFドライバCPUとUICPUの二つである。相互にシリアルでメッセージ交換をしてのシステム設計だったが、RFドライバマイコンは性能も含めて動作するもののUIサイドのマイコンにはフローが入りきれなかった。4ビットのマイコンという足かせは重く工夫の余地はなかった。液晶搭載のuiマイコンの一部のみを用いて8ビットマイコンとの組み合わせで製品は出荷された。この表示マイコンにのみc言語は適用されていた。c言語ではコードが三倍に膨れあがるなどと言われてはいたものの、それよりもアドレス空間の制限が4ビットの4kBという空間が重かった。

この悔しさをばねにして8ビットマイコン用にcコンパイラを開発してコードサイズのチューニングを果たしてアセンブラ並あるいはそれ以上の効率でコードを生成することに成功した。最初の版が、一ヶ月で出来たことに比べるとそれ以降5年近くは改善活動をしてきたのではあったが。このc言語を用いて新たな展開が出来た。お客様にソフトウェアを書いてもらうということが可能になったのである。新入社員にromライタとコンパイラだけを渡してツール開発に成功したのが、そうした感触を確かなものにしていた。まだunixでしか動作しないコンパイラではあったが、デバッグツールとしてマイコンシミュレータというものを海外から導入した。fortranのソースコードで書かれていたそのシミュレータは6301/6303をシミュレーションしてデバッグに供するものであった。機械語のインタプリタがシミュレータである。大阪の社員研修所でc言語中級というコースを開設してもらい、そこに講師として望んだ。自作のコンパイラで開発したターゲットコードをシミュレータを使ってvaxの上で動作させてデバッグする仮想的な開発環境である。いつか夢見ていたものが少し形になったような気がした。

パッシブインタプリタというアイデア
c言語環境にはまるきっかけになったのは、バーコード端末の開発環境として自作してしまったことが理由なのであるが、確かに周辺も含めて自作のコンパイラで全て開発していた。そうして開発環境をお客様に配布するまでになっていた。各地で説明会の講師などもしていた。Basicが、まだ流行っている時代に組み込みCコンパイラを作成提供したので、さすがに時代から浮いてしまった。BASICで財を成した人もいるし、評価されつつもBASIC98のようになった事例もある。文字列処理とインタプリタがマッチしたのであろう。倍精度整数型と文字処理のみに特化したインタプリタを開発することになった。小文字が嫌いな人たちには、行番号つきのソースは理路整然と映るのだろう。今までの仮想マシンの経験などから機械語と中間コードの入り混じった、パッシブインタープリタという提案をして開発をした。文字列演算の中間コードのみ例外処理として動作させて命令コード例外の領域に割り付けたのがアイデアである。整数演算のコードは文字通り、機械語そのものである。中間コードにあたると例外処理として割り込みが起こり中間コード処理を行なう。インタプリタが積極的に解釈しないという特性から、こうした命名をしていた。暴走しつづけているという考え方もあり動作の保証としては難しいという話もあった。インタプリタ本体よりもコンパイラの開発が大変だった。人に頼むという仕事は大変である。わかり易いコードを基に共有できる優秀な仲間にであえばよいのだが・・・・・。デモソフトなどを作成して地方巡業を繰り返したが、結局皆Cコンパイラを使うことになった。カタログリストには多くのアイテムが必要であることが判った。少しでも多くの項目があったほうが良いのだろう。

高精度シミュレータの開発
8ビットマイコンでは自作ですっかりはまったのだが、いつまでもそんなことをしてはいられないということで16ビットマイコンではメーカー製のコンパイラを使うことになった。時代は携帯電話で端末開放の時代を迎えていた。C言語で動作するOSの仕様が配布されて各メーカーが、そのOSと本体を開発するという形態である。8ビットでは日立のマイコンを使用していたが、16ビットでは三菱に変えた。アーキテクチャが8ビットの日立のものに似ていたことや、消費電力が低いことなどが主な理由であった。MOVA-Pの物語で有名な状況で劣悪な開発環境としてICEやCコンパイラの出来の悪さなどがあげられていた。開発環境の改善と「ハードについて詳しくなりたい」という部下の希望とを合わせて高精度のマイコンシミュレータを開発して性能検証が出来る正確なツールにしようという構想で開発を行なった。デバッグの使い勝手の追求も含めて一年余りでこれを仕上げていった。ICEで動作検証を行い外部バスからみたプリフェッチの動作も含めて機能を実現していった。システムテストも視野に入れて、連携する外部周辺機器とのシミュレーションなどの機能も含めて開発を進めた全社規模のPHSの開発にあわせて、
開発を進めていった。途中から三菱のコンパイラの出来の悪さも見えてきていたのでこちらにも手を染めかけたが格段に途中から良くなってきたのとコンパイラの開発チームが考えすぎて頭が痛くなったらしいことなどからこちらは中断した。出来上がった環境について外部でセミナーや日経エレからの投稿要請などがあり応じているうちに同期のマイコン開発をしている電子工業の技術者から呼び出しを食らった。仮想的なマイコン開発環境の必要性と将来方向について、意見を述べて電子工業自体も自社マイコンの環境の取り組みとして以降取り組みをはじめていった。低消費点力高速動作というマイコンを開発していたのだった。

Java以前からJava評価まで
開発環境の開発などに手を染めているうちに研究所への顔パスを手に入れた。PHSなどの開発を通じて関連部門との連携が深まっていった。エージェント技術を開発していたチームと出会い彼らがPHSで評価していた技術を携帯電話にスクリプト言語を実装してコラボレーションのアプリケーションが動作するようにという思いが駆け巡り当時開発をはじめようとしていた米国向け第二世代業務用携帯に適用するという思いに到達していた。無線でエージェントとして動作させることを狙っていた。このためにはVMが必要だった。こうした幅広い技術の開発をしているのが大企業のすごいところであり、また埋もれていたりもする。PHSのスループットとWSでのソースコードスクリプティングという評価形態から、中間コード+携帯+16kbpsという世界には大きな隔たりがあり、Tcl/Tkのような画面処理GUIを可能にしようという話にも、時代を超えたものがあり夢多い仕事では在ったが、コストと神戸の地震とが、いろいろな面で開発を凍結してしまった。普通は中止なるものを凍結というのは意外だったが、その後解凍することも冷凍していることも忘れ去られてしまったようだ。技術者の思いは一つであり何かきっかけを待って思い描いている技術を実現するときを待っていたようだ。開発中断後も情報交換を続けWAPの前進となったHDMLやJavaの誕生を知り、またこれを見守ってきた。デモを綱島地区によんでしてもらったときに米国向け開発で描いていたもののいくつかの答えを見ることができて感慨無量だった。当時の研究所のメンバーも今はやはりスクリプト言語の追求をしてデジタルテレビに対応していくようだった。スクリプト言語の技術を進めてきた中でJavaの技術を端末に適用しようという取り組みをJavaのソースを入手して行なうことになった。評価は二点、UI系での仕様記述と実用化の可能性またJavaVMの実装の可能性だった。技術本部と共同でこの検討を進めてまた大阪の研究所の手も仰いだ。旧知の仲間との遭遇などもありJava応用という熱い話を進めていった。VMが200kb程度になることとUIでのデモなどがJavaで出来るところまでは来ていた。

VAX仮想エミュレータの実用性
現場を離れて開発管理などをすることになり開発環境の保全という状況に遭遇してシステム件名物の開発環境としてのVAXの処遇が問題になっていた。5代目VAXが臨終の時を迎えようとしていた。山ほどある過去のツールはバイナリーのまま十年以上使われつづけてきていた。これを切り替えるには検証工数が膨大にかかる割には、保守のとき以外には表立ってこないのである。端末開発をしている事業部にはこうした責任はない。システム物でのみ発生する話なのである。VAXのシミュレータを開発して開発環境自体を動かそうとする提案をしたが実際に手をあげる人はいなかった。保守打ち切りを宣告されていたので産学協同という線も模索した結果、鳥取の元初芝にいた高専の先生を発見した。メールで説明をしてからの応対にひらめきを感じて米子まで夜行電車でおしかけた。半年かけて可能性の検証をすすめてきたが、課題は、UNIX4.2BSDのソースコードにあった。封印されてきた時代のUNIXで動作してきたツールが最近のFreeBSDなどと同様のAPIなのかどうかというのがかぎだった。しかしULTRIXにOSの切り替えをしてきたこともあって誰もソースの保全をしていなかった。UNIXのこうした時代も含めたフルソースアーカイブを配布している人がいるという情報を初芝の通信コミュニティから入手し、バークレーの先生にメールで顛末の説明をしたが、UNIXのライセンスシートが必要であるといわれてこんどはそれを探した。初芝ではまだ写植機にUNIXを搭載しているらしくライセンス管理をしている部署にそれはあった。FAXで送付してもらい、それを米国に中継した。米国からは許可をもらい早速発送してもらうとともに同様な事例をやったオーストラリアの先生を紹介しもらった。翌朝にはオーストラリアの先生からもメールをもらい彼のサーバにアクセスするパスワードを50回分もらった。初芝電器からは、なせ必要なのか説明にくるようにという呼び出しがあったが別件で大阪にいくおりまで話を伸ばした。こうしてから、半年かけて開発を進めてきた。昨年秋にこれが完成した。最近のPCマシンでFreeBSDの上で動作してFileアクセスなどの動作はFreeBSDが担当するという手の込みようである。今まで以上に高速で動作することになった。

x86仮想エミュレータの恩恵
初芝を離れていま、実はやはり仮想マシンにはまっている。今はvmwareというX86のシミュレータを動作させている。これがPENTIUMの400MHzクラスでは快適に動作するようだ。私は800MhzのpentiumIIIを使用している。なぜ使うのかというやはり古いツールが動かないからである。windos2000の上で一部にWINDOWS95の窓を設けてここでグループウェアのソフトを動かしている。linux版もあるそうなので、LINUXに変えようとも考えている。実機がない環境での開発という視点と古いツールを利用するという視点の二つが仮想的な環境を必要とする理由である。25年近く経過してなお続くこうした事情は、携帯の今後の開発でも同様に必要であるのだろうと思う。初めてシミュレータでツールを動作させた感激は、今も同様なケースで感じる。お客様の開発するソフトウェアの検証に自社での環境も必要でありそうした仮想的な環境についても、考えている。まだまだこれからも楽しめると思う。歴史は繰り返し、その都度新しい技術を学ばせてくれる。