旧来のデバイスを仮想化してエミュレート
| ||
|
新技術導入に関する基本的な考え方は，エミュレーションである。つまり旧来のものと同じように振る舞うようにして互換性を確保する。ただその機能やアーキテクチャによってエミュレーションのやり方は異なる。ハードウェアを直接制御したりせず，OSのAPIのみを利用するアプリケーションにおいては，OSのAPIとデバイス・ドライバによるエミュレーションで事足りる（図3[拡大表示]）。しかしそのデバイス・ドライバがすでに市場に浸透し，簡単に変更することが難しい場合は，エミュレーションのレイヤーを下げBIOSもしくはハードウェア・レベルでエミュレーションが必要となる。例えば，ブートローダーは，最も大きく技術革新の影響を受ける部分である。ソフトウェアの起動用デバイスとして一般的なハードディスクでは，管理可能な容量の拡大や，IEEE1394，USB 2.0，DVD-ROM，Serial ATAなどの新たなインタフェースを持ったストレージ・デバイスが続々と登場した。こうしたなか，OSは個々の技術に即座に対応できない。そこでBIOSが新しいインタフェースを既存インタフェースとしてOSに見せる。
BIOSによるエミュレーションの好例としてはUSBがある。USBはシリアル/パラレル・ポートなどの既存インタフェースを廃した「レガシーフリー」システムの急先鋒として1999年に登場した。機器によって異なっていたケーブルやコネクタを統一し，自動認識によってユーザーの設定を省力化するプラグ・アンド・プレイを実現することにより，パソコン・ユーザーの裾野を広げることに貢献した。
例えば，身近なデバイスであるキーボードやマウス（図4[拡大表示]）。既存のPS/2インタフェースを想定して設計されたドライバや，DOSアプリケーション，ブートローダーなどは，将来USBが登場することなど想定されていない。OSのインストーラやブートローダーは，まずシステムの起動に必要なコンポーネントを初期化するプログラムを起動して，徐々に複雑なハードウェアを起動するようになっている。USBは最近の技術であることから，初期化のタイミングもOS起動過程のかなり後段にある。つまりOSのUSBプロトコル・スタックが起動する前のBIOS設定画面やブートローダーの操作画面では，USBキーボード/マウスが利用できない。そこでBIOSで一部のUSBプロトコルを動作させて，PS/2ハードウェア相当の機能をソフトウェアでエミュレーションする。また，DOSやWindows 3.1時代の16ビット・アプリケーションなど，BIOSを経由せずにダイレクトにキーボード・コントローラのI/Oポートをアクセスするアプリケーションに対しては，OSのUSBプロトコル・スタックに接続することにより旧来のPS/2キーボード・コントローラと等価な機能を提供する。
身近な例としてUSBキーボード/マウスを挙げたが，互換を保つためのエミュレーション技術は，最近のテクニックではない。1985～86年頃に始まったCRTから液晶パネルへの移行でもニーズはあった。CRTと液晶パネルでは，画面をリフレッシュするタイミングが異なる。描画用の信号を生成するCRTC（CRT Controller）が管理するレジスタ群の機能を利用して，パネル特有のタイミングを発生させる必要がある。しかしCRTCを直接制御する既存のアプリケーションから見れば，CRTを想定しているため液晶パネルにCRTのタイミングで信号が供給されるためうまく表示できない。これらを制御するためには，グラフィックス・コントローラ内で，表示装置に合わせてうまくタイミングを制御すればいいのであるが，当時の半導体の集積度からすると相当のロジックを要する。そこでBIOSが間に入ることによって，アプリケーションがCRTCレジスタにアクセスするたびにその意図を類推し，液晶パネルへのタイミングに変換した信号を液晶パネルのコントローラに渡す方法をとった。このようにBIOSは，チップのゲート数削減，開発時間の短縮，さらには過渡期の多様なアプリケーションに対応できるよう，ファームウェアの元来の目的である半導体チップに汎用性を持たせる役割も兼ねていたのだ。
コードサイズの限界を超える
アーキテクチャの変容と互換性の維持は，BIOSのコードサイズの肥大化をもたらす。IBM PCが発表された当時のコードサイズは，バイナリでわずか8Kバイトだった。これが現在のノートパソコンなどのフル機能を装備したBIOSでは，512Kバイトを優に超える。ところが，BIOSに割り当てられるメモリー空間はIBM PC当初のデザインからほとんど変わっておらず，機能追加に伴うコードサイズの増加は常にBIOS技術者を悩ませてきた。そのため，バンク切り替えやコードの圧縮技術，さらにはメモリー管理機能をBIOSに組み込むことによって，実質的に利用可能なメモリー空間を広げてきた。最近では，メインメモリーにIBM PCの規定とは別のメモリー空間を確保する「フラットモデル」を導入するまでに至っている＊7。
ただBIOSが利用できるメモリー空間が広がったとしても，BIOSを収めるEEPROM（Electrically Erasable Programmable Read-Only Memory）の容量は現時点の最大で8Mビット（＝1Mバイト）に過ぎない。BIOSの機能を増やすには足りない。今では使われなくなった機能を削除したとして効果は微々たるものだ。しかも従来機能の削除は既存アプリケーションとの互換性を予測するのが難しい。
そこでBIOS技術者が着目したのが，BIOSを格納する新たな空間としてハードディスクを利用する方法である。ハードディスク容量の飛躍的な向上と，実効30M～50Mバイト/秒の転送速度，十数年前のHDDと比較して約20倍の平均故障間隔（MTBF：Mean Time Between Failures）といった，BIOSのようなコア・ソフトウェアを格納するに十分な条件が整ったことにより可能となってきた。その結果，コードサイズの縮小にこだわることなく，機能拡張が可能となった。このことは，BIOSの開発言語にアセンブラのような低級言語ではなく，C言語のような高級言語による開発が許されるということでもある。アセンブラによる最適化が必要になるコードは，微妙なタイミングに依存する部分に限られる。C言語の導入によって開発環境を改善することでアセンブラ・プログラマ人口の減少問題を乗り越え，BIOS開発の効率と品質の向上，および機能の更なる拡充に向けた可能性が広がるだろう。
津留雅文 Masahumi Tsuruフェニックステクノロジーズ チーフテクノロジーオフィサー1983年より，8ビット機およびIBM PC互換機のハードウェア/BIOS設計に従事。1990年，ストラテジックリサーチインスティチュートに入社し，AXパソコン向けBIOS開発に向け開発チームを率いる。1993年のパソコン向けBIOSの分野で圧倒的シェアを持つ米Phoenix Technologies社による企業買収を経て，一貫してBIOSの開発とリサーチ関連業務に携わる。最近では，複数の社外団体へ参画，標準化作業や米国本社との製品開発に関わる意見調整等に奔走する。 |
