IBM i のウンチクを語ろう
～ その30：過去30年の間に最も大きく変わったもの -2
皆さん、こんにちは。IBM i のアプリケーション資産継承性は、AS/400登場以来30年間以上にわたり、仮想マシンであるTIMIが互換性を維持し続けていることによって達成されています。この特性は1995年に、従来の48ビットCISCプロセッサが64ビットRISCに置き換わった際にも変わる事はありませんでした。TIMIはOSの下位層に位置付けられていて、SLICによってソフトウェア的に形成されている仮想マシンであり、その実態はAPI（Application Programming Interface）、すなわちシステムが用意するサービス・プログラムの集合体です。ハードウェアにアクセスするプログラムを作成するために利用できる、と言う意味においては他のシステムと同様ですが、TIMIではAPIを利用する以外の手段は完全に封じられています。ユーザーがハードウェアから隔離されており内部に侵入できない事は、IBM i セキュリティの要ともなっています。
30年前にAS/400が登場した時は、TIMIの下のマイクロコードは二つの階層で構成されておりました。一つはVLIC （Vertical Licensed Internal Code）でTIMIの直下、すなわちOSに近い上位層に位置し、HLIC （Horizontal Licensed Internal Code）はハードウェア寄りの下位層に位置し、両者の境界はIMPI （Internal Micro Program Interface）と呼ばれています。AS/400の前身のSystem/38をご存知の方は、VLICとHLICという名称よりも、それぞれVMC （Vertical Micro Code）とHMC （Horizontal Micro Code）の方が馴染みがあるかも知れません。日本語では垂直マイクロコードと水平マイクロコード、名前だけを聞くとタテ長とヨコ長のマイクロコードといったような印象ですが何が違うのでしょう。
ものの本によると、垂直マイクロコードは1回のサイクルで1つの処理、水平マイクロコードは同時に複数処理を行うとされています。複数の演算ユニットを備えたシステムを想像する時、垂直マイクロコードはターゲットとなる演算ユニットを特定し、そのユニットに対してどのような処理を行うべきかを記述します。水平マイクロコードは複数の垂直マイクロコードを連結・統合し、全ユニットに対して一気に命令を投げ掛ける事で並列処理を行います。パフォーマンスを追求するには水平マイクロコードの方が有利ですが、処理の順序を維持しながら論理的矛盾が生じないよう、注意深くコーディングする必要があります。AS/400産みの親とされるソルティス博士によると、System/38 やAS/400における「水平・垂直」はその定義に合っておらず、System/370における名称を便宜上拝借したに過ぎないようです。
下層にあるHLIC (HMC)は、コンピュータ内部のハードウェアのエミュレータとして機能するという点と、1サイクルで複数の処理を並列的に実行できるという意味において、水平マイクロコードの定義に当てはまります。上層にあるVLIC （VMC）はハードウェアに依存するOS機能を提供するものであり、1サイクルで一つの処理という具合には必ずしも限定されないので、垂直マイクロコードという表現は正確ではありません。VMCをマイクロコードとして位置付けた背景には、System/38が発表された1978年当時の市場環境に対する配慮があるようです。
当時のIBMはSystem/360と後継のSystem/370によって、市場におけるシェアを急速に拡大させておりました。これに対抗して、IBM製品に接続可能（プラグ・コンパチブル）でより安価な機器類を販売しようとするメーカーが表れます。ユーザーがIBM製ソフトウェアを単独購入できる事が前提にある戦略なのですが、IBMとしてもこれを見過ごせばビジネスに悪影響が及びます。裁判になり、結果的にIBMはソフトウェアを単独で販売する事に同意します。当時は比較的一般的であったバンドリング・ビジネスに対して、厳しい目が向けられるようになったのです。ハードウェアとソフトウェアとがビジネス的に分離され、マイクロコードはハードウェアであるという認識が確立されます。
ハードウェアとソフトウェアを別個に販売するためには、どこかに両者の境界を設定する必要があります。ごく一般的な定義にしたがえば、IMPIを境界としてHMCと下層をハードウェア、VMCと上層をソフトウェア、という具合に分離するのが自然だったかもしれません。ところがSystem/38 において、テクノロジーの世代を超えたアプリケーションの互換性が維持されるのは、IMPIにおいてではありません。境界はTIMIでなくてはならず、ハードウェアに依存するOS機能（VMC）をマイクロコードとして扱う必要があります。製品開発元のロチェスターでは境界を明らかにするために、元々のOS開発チームを二つに分け、ハードウェア寄りの機能を受け持つチームをハードウェア開発部門に組み入れます。製品開発コストの計上においても、ハードウェア扱いである事が明らかになります。AS/400が登場する1988年頃になると、市場のバンドリングに対する拒否反応は弱まったので、マイクロコードである事を主張するようなVMC・HMCという呼称は、VLIC・HLICにあらためられています。
その後System/38以来採用されていた48ビットCISCプロセッサは、64ビットRISCへと置き換えられる事が決まります。プロセッサ命令セットは一新され、マイクロコードの全面的な書き換えが必要になります。RISCプロセッサにおいてはハードウェアのエミュレータであるHLICは不要になり、VLICに統合され、SLIC（System Licensed Internal Code）と言う名称が新たに与えられます。1992 年に始まったSLIC開発プロジェクトでは、既存機能を実装するだけではなく、RISCプロセッサ搭載モデルが発表されるまでの間に登場する、各バージョン・リリースの新たな機能も追加実装しなければなりません。「蜃気楼」を追いかけ続けるようなもので、SLICの開発生産性を如何にして高めるのかが重要になります。
まずは新しい SLIC を、プロセッサ・テクノロジーやOSバージョンに関わりなく旧来のVLICを踏襲するだけで良い機能群と、新規に開発するべき機能群とに分けます。VLICは元々PL/MPコンパイラを利用して開発されていました。汎用機でも利用されているPL/1言語コンパイラをベースとして、IMPIコードを生成するよう改変された、開発部門内で使用されているツールです。（MP とは Machine Product の事です。）これに手を入れて64ビットPowerPCコードを生成するように変更します。これで200万ステップ分のSLICコードが生成されました。残るは新規開発分です。様々な言語を検討する中で浮上したのが、オブジェクト指向型言語であるC++です。テスト的に使用してみたら、その開発生産性は従来の手続き型言語に比べて4倍の開きがある事がわかりました。それでも開発部門にとって巨大なプロジェクトである事に変わりはありません。C++言語のプログラマを新たに200人雇い入れて、「蜃気楼」を追いかけながらRISCモデル登場に備えます。これで追加の100万ステップが開発されました。
IBM i 史上類を見ない規模の変革であったにも関わらず、市場では極めてスムーズなテクノロジー移行が行われました。しかもTIMIの互換性は維持されていたので、ユーザー・アプリケーションを書き換える必要はありません。
かつてDEC社においても似たようなプロジェクトがあったそうです。旧来の32ビットCISCプロセッサ搭載VAXシステムを、Alphaと呼ばれる64ビットRISCプロセッサへと移行させようというものです。プロセッサに互換性は無い事はAS/400同様でしたが、TIMIのような仮想マシンの考え方はありません。アプリケーションの互換性を保つための様々な工夫がなされたにも関わらず、移行時にはプログラムの15から20%程度の書き換えが必要になりました。
ご存知のとおり、DEC社はその後コンパック社に吸収合併され、さらにコンパック社はHP社に吸収合併されています。テクノロジーの進化と移行は、どの製品においても見られる事です。主力製品におけるアプリケーション資産の継承性有無は、メーカーとしての死活を決定する重要な要素なのですね。
ではまた
