連載 IT管理者のためのPCエンサイクロペディア 第6回 本家IBM PCの歴史(4)〜プラグ・アンド・プレイの普及とIntelの台頭 元麻布春男 |
前回の「第5回 本家IBM PCの歴史(3)〜ローカルバスの興亡」では、Windows 3.0の大ヒットによりGUI表示を高速化するWindowsアクセラレータが登場するとともに、ISAバスの性能不足が露呈したことから、より高速なローカルバスがPCに組み込まれていった経緯を説明した。結局、ISAバスを代替できたのは、独自ローカルバスでもVL-Busでもなく、PCIだったことはご存じのとおり。今回は、そのPCIが備えていた新機能のうち、PCに多大な影響を及ぼした機能「プラグ・アンド・プレイ」と、このころからPCアーキテクチャのテクノロジー・リーダーの座を確保し始めたIntelの動きについて解説しよう。
プラグ・アンド・プレイ実現への長い道のり
ISAやVL-Busに比べてPCIが優れていたことの1つは、プラグ・アンド・プレイの機能が規格に含まれていたことだ。PCIより以前では、I/Oポートのアドレス(I/Oアドレス)や割り込み要求(IRQ)、DMAチャネル、メモリ・アドレスといった「システム・リソース」を拡張カードに設定するには、ユーザーがジャンパ・スイッチなどを手動で操作する必要があった。そして原則的に、1つのシステム・リソースは単一のデバイスでしか利用できず、複数のデバイスで共有するとコンフリクト(衝突)して正常に動作しなかった。それゆえ、複数のカード間で衝突しないよう、適切にシステム・リソースを各カードに配分するのはユーザーの責任だったのである。プラグ・アンド・プレイは、こうした面倒な作業をユーザーから解放し、システム・リソースの割り当てを自動化することを目的として規格化された。ユーザーがいちいち手動で設定することなく、拡張カードを「差したら動く」というシステムの実現を目指したものだ。PCIはプラグ・アンド・プレイという概念を取り込むことで、ハードウェアの歴史を塗り替えたのである。
だが、もともとPC/ATアーキテクチャに存在しないプラグ・アンド・プレイをサポートすることは容易ではない。特に、プラグ・アンド・プレイに対応していない既存のISAバスとの共存*1を考えると、プラグ・アンド・プレイのサポートは非常に厄介だ。いかにPCIがプラグ・アンド・プレイをサポートしていようと、ISAバス上のデバイスがどのようなシステム・リソースを占有しているのかが分からなければ、PCIデバイスの設定などできないからである。かといって、例えばPCIにはISAとは異なる専用の割り込みコントローラを用意するなどして、PCIデバイスとISAデバイスがそれぞれ使用するシステム・リソースを分離すると、古いソフトウェアがPCIデバイスを利用できなくなってしまう。プラグ・アンド・プレイをサポートするということは、既存のソフトウェア・モデルに対して手を加えなければならないということであり、何とか上位互換性を持った方法でそれを処理する必要があった。
*1 MCAが失敗した原因の1つがISAバスとの互換性をサポートしなかったことにあったことからも、当時、PCIがISAと共存することは必須といってよかった。 |
ISAに加わったプラグ・アンド・プレイのサポート
そこで、まず追加されたのが、ISAにプラグ・アンド・プレイ機能を付与したプラグ・アンド・プレイISAである。これはマザーボード側と拡張デバイスの両方がプラグ・アンド・プレイISAに対応して、初めてISAバスにおけるプラグ・アンド・プレイ機能が利用できる、というものだ。PCIシステム(マザーボード)は基本的にプラグ・アンド・プレイISAをサポートしたため、取りあえずシステムとしてプラグ・アンド・プレイの環境が整った。しかし、プラグ・アンド・プレイISAはISAカードにプラグ・アンド・プレイ機能を持たせただけで、性能的なアドバンテージがなかったため、AdaptecのSCSIホストアダプタや、3Comのネットワーク・カードなど、限られた製品が提供されるにとどまった。わざわざコストをかけて新しいカードを開発するのであれば、PCIにした方がよいと、多くのベンダが考えたのである。
難しかったISAのプラグ・アンド・プレイ・サポート プラグ・アンド・プレイISAカードの入手性には関係なく、プラグ・アンド・プレイISAスロットには、プラグ・アンド・プレイに対応しないISAカードがインストールされることも当然考えられる。つまり、PCIシステムには、プラグ・アンド・プレイに対応したバス・アーキテクチャをサポートするソフトウェアと、これに対応していないISA拡張デバイスをプラグ・アンド・プレイ環境で利用するためのソフトウェアの2種類が必要になる。プラグ・アンド・プレイをサポートするソフトウェアでまず必要になるのはBIOSだが、これについてはPCIをサポートした新しいマザーボードに添付されるので問題ない。プラグ・アンド・プレイに対応しないISAカードについては、設定をジャンパ・スイッチで行う以上、BIOSの出番はあまりない。従って問題はOS、あるいはOS上のユーティリティで、どうやって両者を共存させるか、ということになる。 PCIが登場した1993年は、日本でWindows 3.1が登場した年であると同時に、最初のWindows NTのリリースであるVersion 3.1(英語版)が登場した年でもある。しかし、いずれもプラグ・アンド・プレイに対応したOSではなかった。また、PCIのリリースに合わせて、タイムリーにOSのアップデートを行うことも難しかった。ハードウェアの進歩に合わせてOSのアップデートを行うことの難しさは、例えばUSB 1.xやUSB 2.0のハードウェアが出荷されてからOSレベルでのサポートが開始されるまでのタイムラグを見ても明らかである。そこで、既存のOS上でプラグ・アンド・プレイ環境を保証するべく登場したのがICU(ISA Configuration Utility)というユーティリティ・ソフトウェアだ。 ■ICUによるプラグ・アンド・プレイのサポート そもそもPCIデバイスは、システムにより認識されると、PCI BIOSによりシステム・リソースを自動的に割り振られ、その割り当て状況がシステム内にある使用中のシステム・リソースのデータベースへ登録される。このデータベースはESCD(Extended System Configuration Data)と呼ばれ、システムに搭載された不揮発性メモリに格納されている。次に新しいハードウェアが追加されると、PCI BIOSはESCDを参照して、重複しないようシステム・リソースを割り当てる。プラグ・アンド・プレイ環境にISAが混在した際の問題とは、プラグ・アンド・プレイに対応していないISAデバイスが、ESCDの関知しないところでシステム・リソースを使用して、ほかのデバイスとシステム・リソースの衝突を起こしてしまう可能性があるため、ESCDによるシステム・リソース配分の安全性を保証できない、ということなのである。ICUは、ISAデバイスが使用するシステム・リソースをユーザーが手動で入力することで、ESCDに登録するユーティリティである。ISAのシステム・リソースをESCDに登録してしまえば、プラグ・アンド・プレイに対応したデバイスは、BIOSが自動的にESCDに登録してくれる。 PCIシステムは、プラグ・アンド・プレイISA、そしてICUがそろって、ようやくシステムとして一応の完成を見たわけだが、このシステムがきちんと運用されていたかというと、必ずしもそうだとはいいがたい。恐らく大半のユーザーは、ICUによるISAのシステム・リソースの登録など行わなかったものと思われる。ICUの利用についてきちんと説明しなかったPCベンダは少なくなかったし、それどころかICUを添付しないPCIシステムを販売したベンダさえあった。また、いざユーザーがICUを利用しようとしても、販売されているISAカードのマニュアルに、その製品が利用するシステム・リソースが明記されていないことも少なくなかった。ありがちだったのは、I/Oアドレスやメモリ・アドレスで、ジャンパ・スイッチによる開始アドレスの設定が明記されているにもかかわらず、終了アドレスが不明なものだ。これでは、システム・リソースの正確な使用状況をICUで入力することなどできない。 ■不完全ながら実用になったプラグ・アンド・プレイ機能 こうした問題にもかかわらず、それでも多くの場合、何とかシステムが動作したのは、ポピュラーなISAデバイスが使用するシステム・リソースが既知であり、システム側あるいはドライバを含むPCIデバイス側でこうしたシステム・リソース(レガシー・リソース)の使用を回避していたからだ。VGAが利用するメモリ・アドレスや、ハードディスク・インターフェイスが利用するIRQといったシステム・リソースを、衝突覚悟で使用してくるPCIデバイスなどあるハズもない。よほど特殊なISAデバイスを使うのでもない限り、ICUを使わなくても何とかなった、というのが実情だろう。Windows NT系のOSは、2000年2月に発売されるWindows 2000まで、プラグ・アンド・プレイのサポートがなかったが、同じ理由で大きな問題にはならなかった。それに1990年代後半になると、ISAカードそのものがあまり使われなくなっていったため、さらに問題は減少した。 |
PCIにより導入されたプラグ・アンド・プレイのソフトウェア・モデルは、その後ACPI(Advanced Configuration and Power Interface)に継承された。ACPIによりプラグ・アンド・プレイおよびパワー・マネジメントの主役は、プラグ・アンド・プレイBIOSならびにAPM(Advanced Power Management)というBIOSレベルからOSレベルへと移行したわけだが、ここでプラグ・アンド・プレイのインプリメントを行った経験がなければ、ACPIもなかったことは間違いない。
Intel支配の始まりを予感させたPCIチップセット
さて、PCIをサポートした実際の製品だが、最初に登場したのは、Intelの486用チップセット「420TX(開発コード名:Saturn)」とPentium用の「430LX(開発コード名:Mercury)」の2つである。リリースされたのは、PCI 2.0がリリースされる直前の1993年3月であった。430LXは、初代Pentiumプロセッサ(開発コード名:P5)に対応したチップセットとして登場したが、広く普及したチップセットとはいいがたい。というのも、P5とIntel 486DX4プロセッサはほとんど性能差がなかったうえ、0.8μmプロセスで5V動作のP5に対して、0.6μmプロセスで3.3V動作の新型Pentiumプロセッサ(開発コード名:P54C)のリリースが予見されていたため、ユーザーの間には「待ち」の気分が強く、P5そのものが広まらなかったからだ。またIntel 486系プロセッサに対応した420TXも、P54C待ちの状況に加えて、Intel 486系プロセッサはVL-Busシステムで問題が少ないこと、拡張カード類がそろわないPCIより対応した製品が広く販売されているVL-Busの方が都合は良いといった事情もあり、商業的に大きく成功したわけではなかった。
Intel製のPentium対応チップセット「430NX」 |
赤線で囲った4個のチップが430NXを構成するものだ。このころから、PCにおけるPCIの本格的な普及が始まる。 |
PCIがプラットフォームとして普及し始めたのは、1994年3月にリリースされたP54C対応の「430NX(開発コード名:Neptune)」チップセットから、といえるかもしれない。その次の1995年1月にリリースされた「430FX(開発コード名:Triton)」で、Intelはチップセット市場においてシェアトップの地位を確立することになる。
次のページでは、PCIと同時期に登場したほかの技術やOS、そしてこのころから徐々にPCプラットフォームへの影響力を拡大していくIntelについて見ていく。
INDEX | ||
第6回 本家IBM PCの歴史(4)〜プラグ・アンド・プレイの普及とIntelの台頭 | ||
1.プラグ・アンド・プレイとPCIチップセットの勃興 | ||
2.Intelのプラットフォーム・リーダーへの道のり | ||
「System Insiderの連載」 |
- Intelと互換プロセッサとの戦いの歴史を振り返る (2017/6/28)
Intelのx86が誕生して約40年たつという。x86プロセッサは、互換プロセッサとの戦いでもあった。その歴史を簡単に振り返ってみよう - 第204回 人工知能がFPGAに恋する理由 (2017/5/25)
最近、人工知能(AI)のアクセラレータとしてFPGAを活用する動きがある。なぜCPUやGPUに加えて、FPGAが人工知能に活用されるのだろうか。その理由は? - IoT実用化への号砲は鳴った (2017/4/27)
スタートの号砲が鳴ったようだ。多くのベンダーからIoTを使った実証実験の発表が相次いでいる。あと半年もすれば、実用化へのゴールも見えてくるのだろうか? - スパコンの新しい潮流は人工知能にあり? (2017/3/29)
スパコン関連の発表が続いている。多くが「人工知能」をターゲットにしているようだ。人工知能向けのスパコンとはどのようなものなのか、最近の発表から見ていこう
|
|