第2回　メインフレーム温故知新

日本アイ・ビー・エム株式会社
システムズ＆テクノロジー・エバンジェリスト
北沢 強
2008/7/23

マイクロ・プログラム方式（マイクロコード）の功績

　仮想化の実装の中で、S/360のその後の成功に最も影響したのが、S/370（1970年）で採用された「マイクロ・プログラム方式（マイクロコード）」だと考えます。

　マイクロコードはハードウェアの中で動くソフトウェアで、ファームウェアの一種でもあるのですが、これは「ハードウェア・アーキテクチャの仮想化」だといえます（図3）。

図3　制御アーキテクチャ

　メインフレームはISA（Instruction Set Architecture：命令セット・アーキテクチャ）を採用しており、POWERやx86、SPARC、Itanium2など現存するアーキテクチャのほとんどもISAです。ISAでは通常、アセンブラ1ステップに該当する1命令は、プロセッサ内ではハードワイヤードされたシリコン上の回路で処理します。これに対してマイクロ・プログラム方式では、それをエミュレーションでも処理できますし、ハードウェアに命令が存在しなければ処理例外としてOSにエラーを返して、OS内でエミュレーションすることもできるのが特徴です。

　つまり、OSからハードウェアを隠蔽（いんぺい）し、ソフトウェアとハードウェアのセマンティック・ギャップ（Semantic Gap）をマイクロコードによって埋めています。ハードウェアテクノロジおよびソフトウェアテクノロジの進歩をマイクロコードによって吸収し、その境界面をアーキテクチャとして定義しています。

　これにより、上位互換と下位互換を保証できるようになりました。例えば、新しいCPUに変わったとしても、マイクロコードの中で互換性を保つようにすれば、OSやアプリケーションには変更が要りません。逆に、古いCPU上でも、新しいOSやソフトウェアをエミュレーションによって動かすことができます。

　この上位互換・下位互換は、ユーザーが膨大な投資をして開発したソフトウェアや蓄積されたデータ、そして運用ノウハウを無駄にせず、継続して利用できることを保証するための技術なのです。

　また、マイクロコードは「ファミリーの概念」を実現しました。ユーザー企業の中には大きい会社もあれば小さい会社もあります。電算化によってビジネスが成功すれば、その会社はもっと成長するかもしれません。しかしながら、会社規模が大きくなってマシンのモデルが変わっても、アプリケーションには変更を加えることなく、同じように使えることが理想です。

　そこで、小型機から大型機までアプリケーションが同じように稼働できることを保証するのが、ファミリーの概念です。規模が大きいユーザーは大型モデルを、規模が小さいユーザーは小型モデルを使うことになります。大型モデルではほとんどをハードワイヤードにして高速化し、小型モデルではマイクロコードによるエミュレーションによって高価なハードの使用を抑えて低価格にする、というアプローチを取りました。

　また、ユーザー企業のビジネスが成功して会社規模が大きくなり、システム能力を増強したい場合には、MES（Miscellaneous Equipment Specifications、機械仕様変更）によって、互換性を保ったままモデル変更やシステム能力の増減ができるようになっています。PCやUNIXのオープン系システムでは、安く調達して数年で捨ててしまい、新しいハードウェアに買い替えるというのが一般的ですが、メインフレームは誕生した当初から、長期にわたって継続的に使い続けることを前提に作られてきました。

　マイクロコードはハードウェアの中のソフトウェアですから、マイクロコードで新機能を追加する方が、回路で実装するよりも簡単です。また、回路での実装が難しい複雑なロジックもマイクロコードで実装することができます。

　ソフトウェアから見るとアセンブラ1ステップ相当の1命令なのですが、マイクロコードが複雑な処理をしてくれるのです。たった2つの命令で高速ソートを実行するソート命令や、Unicode文字列を一気に変換するUNICODE命令などは、その典型例でしょう。複数のLinuxを高速で接続するためのハイパーソケット（HiperSockets）という仮想LANも、マイクロコードで実装されました。Linuxが必要とするハードウェア機能は、今後もマイクロコードで素早く実装されてゆくでしょう。

　メインフレームのRAS機能の多くも、マイクロコードで実装されています。

　例えば、CPUスペアリングという機能があります。CPU内での障害を検知したら、R-Unit（リカバリーユニット）により代替CPUに切り替わるというものです。これは、1命令以内で切り替え処理を行うため、ソフトウェアには影響がありません。この複雑な処理をマイクロコードが実行しています。このような複雑な判断処理は、回路化が困難であるためです。I/Oチャネル・パスにおけるマルチパス制御やI/O優先度制御などもマイクロコードが処理します。

　つまり、メインフレームではRAS機能をハードウェアで実装しているのですが、PCやUNIXサーバではソフトウェアで実装されるケースが多いようです。Linuxをメインフレームで動かすと、ハードウェアのRAS機能はほぼすべて活用できます。

　なお、1997年のG4プロセッサ以降で実装されている垂直マイクロコードは、「ミリコード（Millicode）」と呼ばれています。ミリコードはアセンブラで書かれているため、水平マイクロコードより処理単位が大きいことから、ミリコードと呼ばれるようになりました。

System/360登場の経緯

　S/360が誕生する前のコンピュータは、業務の用途に応じて専用装置を用意し、そのハードウェア専用のソフトウェアを開発していました。それぞれの業務においては、専用マシンですから個別に見れば効率的なのですが、そのコンピュータがほかの目的では使えなかったり、プログラムに互換性がなかったりで、コンピュータ化する業務が増えてくると、その数だけコンピュータが必要になりました。当時のコンピュータは大きくて高価でしたから、非常に非効率です。

　そこでIBMは50億ドルという開発費を掛けて、それまで5系統あったIBMのコンピュータを統合する形で、System/360およびOS/360を開発します（図4）。1964年のIBMの売り上げが32億ドルですから、売り上げの1.5倍以上もの開発投資をしたわけです。これに社運をかけていたことがうかがえます。結果としてS/360は3万3000台を出荷しましたので、投資は十分に回収でき、現在のIBMがあるわけです。

図4　System/360以前のIBMコンピュータ年表（出典：IBM Journal of Research and Development, p.364, vol.25, No.5, September 1981）

　面白いのは、業務ごとにバラバラに専用マシンが立ち並んでいた当時の状況というのが、企業内でのオープン系のマシンが乱立している現在の状況とよく似ていることです（図5）。

図5　メインフレームLinuxのシステム形態

　システム構成のトレンドは、分散と集中を繰り返してきましたが、メインフレームで仮想的に既存サーバを統合する流れがあるのも、「歴史は繰り返される」1つの例といえそうですね。

［次回予告］第3回

今回は、メインフレームの使われ方や、メインフレーム・ハードウェアにおける特徴的な実装について、歴史的背景を踏まえながら解説しました。PCやUNIXのユーザーから見ると異質な世界のメインフレーム。次回は、メインフレームにLinuxをどのように移植したのか、その実装方法を解説します。

3/3

Index あなたの知らないメインフレームLinuxの世界 　第2回　メインフレーム温故知新

Page 1 メインフレームに歴史あり 基幹業務システムに求められる厳しい要件 　 Page 2 メインフレームLinuxの発現経緯 メインフレームでLinuxを動かすことの価値 Page 3 マイクロ・プログラム方式（マイクロコード）の功績 System/360登場の経緯

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）