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年近く経過してなお続くこうした事情は、携帯の今後の開発でも同様に必要であるのだろうと思う。初めてシミュレータでツールを動作させた感激は、今も同様なケースで感じる。お客様の開発するソフトウェアの検証に自社での環境も必要でありそうした仮想的な環境についても、考えている。まだまだこれからも楽しめると思う。歴史は繰り返し、その都度新しい技術を学ばせてくれる。
