驚愕の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を興したりした日本ではあるが組み込み技術の大国でもあった匠たちの技を今失おうとしているのではないのだろうか。