日本-日本語

製品  >  ソフトウェア  >  OpenVMS

HP OpenVMS Systems

OpenVMS テクニカル・ジャーナル V6
» 

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Send us your comments

Evolving business value

» Alpha RetainTrust program

News and promotions

» News
» Promotions

HP OpenVMS systems

» OpenVMS software
» OpenVMS solutions
» OpenVMS support
» OpenVMS services
» OpenVMS brochure
» OpenVMS success stories
» What customers are saying
» OpenVMS on Integrity
» OpenVMS documentation
» OpenVMS ITRC forums

OpenVMS software

» Operating system
» OpenVMS clusters
» OpenVMS Galaxy
» e-Business products
» Opensource tools
» Networking
» System management
» Storage management
» Security products
» Application development and integration
» Software licensing
» SPD listings
» Whitepapers
» Ask the wizard
» Training
» OpenVMS books

How to buy

» Configuration and Buying assistance

Related links

» HP Alpha systems
» HP Integrity servers
» HP Software
» HP Solutions
» HP Support
» HP Products & Services
» HP Storage
[Developer Forum]
[New HP Integrity system inovations]
Content starts here

HP Integrity サーバへの OpenVMS のポーティング

Clair Grant, OpenVMS Base Operating System Technical Leader

Distinguished Technologist, Hewlett-Packard Company

概要

この記事では,Integrity サーバへの OpenVMS のポーティングに取り組んだ 3 年半の作業について説明します。若干の歴史的背景,主な決定事項の背後にある根拠,いくつかの技術的な詳細を交えて,OpenVMS I64 V8.2 をもたらした技術を紹介します。最初に,このプロジェクトにおける主な出来事と決断を年代順に述べます。後半のセクションでは,最も面白く難関でもあったいくつかのテクノロジの詳細と,それらがいかにして連携して暫定リリースと最終リリースを生み出したかを説明します。

初期

決断

2001 年の前半,COMPAQ の上級エンジニア・グループによる Alpha プロセッサの評価が終わりました。Alpha は何年かの間,パフォーマンス面で Intel プロセッサよりも優位にありました。しかし,時間とともにその差は小さくなりつつありました。評価チームの結論は,計画中の Alpha プロジェクトがすべてスケジュール通りに完了したとしても,2 つのプロセッサ・ファミリのパフォーマンスは,おそらく 2005 年には同等になり,将来はほぼ間違いなく Alpha のほうが遅れをとるだろう,というものでした。

経済面を考えると,将来の Alpha 開発はもはやまったく実現可能なものではありませんでした。進行中だった EV7 の取り組みは継続しますが,それが Alpha プロセッサの開発の最後となり,関連するハードウェア・プラットフォームは,Alpha ラインの最後となります。EV8 プロセッサ開発はすべて打ち切られました。

発表

2001 年 6 月 25 日月曜日,COMPAQ の上級幹部は,Alpha 開発の打ち切りと,Intel Itanium アーキテクチャへの OpenVMS のポーティングを正式に発表しました。顧客へのメッセージは,はっきりとしていました。すなわち,将来は,現在の Alpha 計画を続行した場合よりも高速のシステムが低価格で提供される,というものです。さらに,その時期についても次のように発表しました:

「2004 年に OpenVMS の実運用品質のリリースを出荷する」

これは,一般の人々だけでなく,OpenVMS 開発チームにとっても衝撃的な発表でした。

アプリケーション・プロバイダへは,「再コンパイルと再リンクでポーティングが完了する」ことを約束しました。このバリエーションで有名になったのが,HP Integrity で動作させるまで「あとほんの少しのところいます」でした。これは極めて大胆なメッセージでした。我々はまだ,何をすべきかについて詳しい調査を始めてもいなかったからです。しかしながら,プロジェクトを通じて,実装に関する決定を行う上での非常に強力な判断基準となりました。

この巨大な計画のもう 1 つの特徴は,既存の Alpha OpenVMS のロードマップは変更しないということでした。このことの重要性は,過小評価してはなりません。我々の顧客にとっては重大なことだったのです。しかも,大量のエンジニアリング・リソース (エンジニア,ビルド・チーム,リリース・チーム,業務管理,認定と検証,ドキュメント) が OpenVMS 次期リリースに向けてすでに確保されており,変更するわけにはいきませんでした。

注: この発表からわずか数日のうちに,私は多数のメールを受信し,その内容は形はさまざまですが次のように書かれていました。「君たちはどうかしている!2 つの特権モードしかないプロセッサで VMS を実行するのは絶対に無理だ!」 そうした人たちに,「Itanium は実際には VAX とまったく同じ 4 モードのプロセッサであり,VMS はうまく行く」と安心してもらえるよう努めしました。

調査

2001 年 6 月 25 日は「発表」の日だっただけではく,我々がこのプロジェクトに取り組み始めた日でもありました。まず,顧客とアプリケーション・プロバイダに,我々が何をしようとしており,それが彼らにとって何を意味するのかが伝えられました。我々は,この新しい方針によって影響を受けるエンジニアリング組織とフィールド組織との話し合いもしました。最後に,計画とスケジュールのための情報収集を行う最初のエンジニア・チームを作りました。

マニュアルを読む

Intel の Web サイトには,ホワイト・ペーパー,最新のハードウェア製品の案内,将来の計画など,非常にたくさんの関連情報が掲載されています。我々は,『Intel IA-64 Architecture Software Developer's Manual』を読むことから始めました。この 4 分冊のマニュアル・セットは,今でもこのアーキテクチャに関する主要な情報源として使っています (http://www.csee.umbc.edu/help/architecture/ から入手できます)。Intel の ACPI (Advanced Configuration and Power Interface) 規格も欠かせないものでした。しかし,これだけで十分でないことは分かっていました。システムを構築し,実装した人たちと話す必要がありました。

質問: ワードはどのようなときにワードでなくなりますか?

回答: Intel Itanium の用語と Alpha の用語を並べて置いたとき。

1 バイトが 8 ビットというのはどちらのアーキテクチャでも同じですが,データ・サイズが同じなのはそこまでです。VAX/Alpha の「ワード」は 16 ビット長であるのに対し,Intel の「ワード」は 32 ビットです。(「付録 A - 完全な比較を行うために頭痛になる方法」を参照)。この「コミュニケーション・ギャップ」を乗り越えた後,このような根本的な違いをどのように文書化したらよいか,考えました。結局,OpenVMS についてだけ文書化するという長年の伝統を継続し,用語の相違は完全に無視することに決めました。安易な策でしたが,検討したほかの選択肢はどれも,ドキュメントの対応策としては見苦しく,何も明確にならなかったのです。

エンジニアとの話し合い

COMPAQ のコンパイラ・グループの何人かは,以前のプロジェクトで Intel を経験していました。OpenVMS コンパイラによって使用されていた GEM バックエンドはすでに「Itanium 対応」でした。我々はコンパイラ開発者たちに,どのように始めるべきかについてアドバイスを求めました。コードのコンパイルはポーティング・プロセスの第一歩であるため,彼らはすぐに重要な役割を果たしました。

知識の蓄積が勢いをつけはじめ,いくつか主だった決断をする必要があると分かったまさにそのころ,次の「発表」がありました。COMPAQ と HP の合併提案です。この発表は,毎年の COMPAQ Enterprise Technology Symposium のわずか数日前のことであったため,イベントの趣旨全体が一夜で変わってしまいました。合併完了までに 8 カ月かかるとは,当時の我々は思いもしませんでした。OpenVMS がようやく Hewlett-Packard の一部となったのは,2002 年の 5 月 7 日でした。

歴史についての補足: Intel Itanium プロセッサ・ファミリ上での OpenVMS の最初の公開エンジニアリング・プレゼンテーションは,カリフォルニア州アナハイムで開催された,例年の COMPAQ Enterprise Technology Symposium で行われました。プレゼンテーションは 2001 年 9 月 11 日火曜日朝に予定されていました。ところがその朝,世界が止まり,ニューヨーク市の世界貿易センター,ペンシルベニア西部,ワシントン D.C のペンタゴンでのいたましい事件を恐怖の中で見守りました。COMPAQ カンファレンスは,その週の残りの予定を変更することになりました。

「最初の発表」には,Tru64 UNIX もポーティングするという発表も含まれていました。一部の Tru64 エンジニアは,他のプロジェクトで Intel を経験していました。我々は全員同じ場所にいたので,2001 年 9 月中旬,Intel のアーキテクト・グループ数名を共同でナシュアに招き,命令セット,オペレーティング・システム・インタフェース,ブート・パス,ACPI を網羅した 3 日間のセミナーを開催しました。それはまさに,目からうろこが落ちる体験でした。マニュアルは我々に基本をみっちり教えてくれましたが,顔を付き合わせた会話を通じて,まだ長い道のりが残っていることが明確になりました。幸い,今度からは,質問があればいつでも相談できるエンジニアがいます。

HP は Itanium アーキテクチャを Intel と共同で開発していたため,HP のシステムはすべてその方向に動いており,我々は OpenVMS を求められているプラットフォームへすでにポーティングしていました。5 月 7 日火曜日,我々はすぐに HP のファームウェア・エンジニアから協力の申し出を受け,HP-UX エンジニアとの話し合いも始まりました。このほか,5 月 7 日には,COMPAQ と HP のネットワークと電子メールが結合するという出来事もありました。ドキュメントとエンジニアへのアクセスがわずか数回のキー・ストロークで行える距離に縮まったのです。数時間のうちに,我々と知識を共有することに意欲的な多数の開発組織へのアクセスが実現したことは,喜ばしいことであり,大いに心強いことでもありました。結局彼らは,我々が直面しようとしていたいくつもの障壁をすでに克服しているのです。彼らの知識はがとても貴重であることは間違いありません。

David Mosberger と Stephane Eranian による著書 『ia-64 linux kernel』は,非常に参考になりました。2002 年春,OpenVMS のエンジニアたちは,マサチューセッツ州マルボロで開催された Mosberger 氏のセミナーに参加しました。同書は,Intel のアーキテクチャについて学習したいすべての人にとって有益な参考書であり,http://www.lia64.org/book/ から入手できます。

大きな決断

プロジェクトのかなり早い段階で,我々はコードのポーティングに技術的に大きな影響を及ぼすいくつかの大きな決断をしなければなりませんでした。場合によっては,それらの決断は我々の顧客から見えることもありました。以降のセクションでは,これらの多くの決断について述べます。ただし我々には常に,最初に挙げた最優先課題がありました。それは,既存の Alpha コードの「バグをそのままバグとして」というレベルで互換性を保つポーティングにはしない,ということです。将来 OpenVMS を向上させるのであれば,思い切った決断もします。これから説明するように,何度か限界を押し広げましたが,製品の品質と顧客の要求が,我々の最優先課題でした。

1. Intel 呼び出し規約 (さらにそれ以上のもの) を実装する

これはまったく予測していない結果でした。長期の評価を終えた後,Intel 呼び出し規約のバリエーションを実装することにしたときには,我々自身も含めて誰もが驚きました。さらに,我々独自の OpenVMS 標準ではなく,より広く知られている ELF (Executable and Linking Format) 標準と DWARF (Debugging with Attributed Record Formats) 標準を使用することにしました。

この呼び出し規約に関する決断は,いくつかの考察に基づいています。パフォーマンスと共有ソフトウェア・テクノロジの利点から,我々はできる限り Intel の規約を使用するように努め,そこから逸脱するのは,多言語での互換性と相互運用性のために不可欠な,ユーザに見える特性,すなわちオリジナルの VAX の設計から引き継いでいる機能を残すために必要な場合に限定しました。このようなハイブリッド設計を作り出すことは画期的な決断であることは分かっていましたが,次の 2 年で,「画期的」という表現さえ,かなり控え目であったことを認識しました。

Intel の呼び出し規約を使用するという決断により,我々は,コンパイラ,ランタイム,OS のエキスパートからなる Calling Standard Committee (呼び出し規約委員会) を作る必要が生じました。委員会の仕事は,VAX および Alpha システム用 OpenVMS 呼び出し規約の細部をすべて体系的に評価し,維持すべき点,変更すべき点,「再コンパイルと再リンクでポーティングが完了する」というメッセージに対応するための最善策を取りまとめることでした。OpenVMS C++ および FORTRAN のコンパイラは,Intel から提供されることになっていたため,この決断は早い段階で Intel のコンパイラ開発者に伝える必要がありました。

2. ELF/DWARF ファイル形式

ELF/DWARF ファイル形式の選択は,大きな衝撃をもたらしました。コンパイラ,リンカ,ライブラリアン,デバッガ,ダンプ・アナライザ,イメージ・アクティベータなど (一部を挙げたに過ぎません) は,これまでとはまったく異なる入力や出力の形式を持つことになるからです。しかし我々は OpenVMS を,アプリケーションと分析ツールのポーティングという世界に,より受け入れられやすいものにしたかったのです。よりよく知られている内部フォーマットを採用すれば,それを理解できる開発者も増えるため,システムはアプリケーションにとって,より利用しやすくなります。

このプロジェクトの目標の 1 つは,OpenVMS の移植性を高めることでした。今度また誰かがこれを行うことになるかもしれません。呼び出し規約,ELF,DWARF の決断により,OpenVMS のポーティング期間は,コーディング時間だけでなく,まったく新しい実装の概念化とデバッグの時間も 2 倍になりました。きつい仕事でしたが,その結果 OpenVMS はより優れたシステムになりました。

3. Alpha アセンブラ・コード用のコンパイラは作成しない

OpenVMS の半分は MACRO-32 で書かれているため,コンパイラが必要でした。Alpha 上では AMACRO コンパイラを使用していたため,Integrity 上では IMACRO コンパイラを作成しました。Alpha アセンブラ・コードに関しては,特にアプリケーションの世界ではそれほど多くあるわけではなく,これから書かれることもないだろうという結論に達しました。命令には適切なコンパイラ組み込み関数を,内部の呼び出し規約には適切なライブラリ・ルーチン,たとえばスタックのアンワインドなどを提供することで,ほとんどの Alpha アセンブラを簡単に書き直せるようにできます。この 2 つが,ほとんどの実装担当者が Alpha アセンブラ・コードを書いた理由だと考えられます。

Integrity C コンパイラは asm 要素をサポートしません。我々は,既存の asm コードをすべて C で書き直すことにより,我々の理論の有効性を確認できました。つまり,Alpha アセンブラを含んだ C asm を Intel のアセンブラ・コードに置き換えることはありませんでした。これは非常に良い兆候で,すべてのアプリケーションにとって確実な方法とはいえませんでしたが,「コンパイラは使用しない」という我々の決断が裏付けられました。

4. Alpha イメージ用のバイナリ・トランスレータ

発表の日,我々は,VAX から Alpha へのポーティング用にあるようなバイナリ・トランスレータは用意しないと表明しました。バイナリ・トランスレータは,非常に大きく,難しいコードです。この決断はシステムのさまざまなコンポーネントに影響します。基本オペレーティング・システムのコンポーネント,いくつかの RTL,および Alpha ファームウェアにさえ,バイナリ・トランスレータ専用の固有のコードがあります。トランスレータを作成しなければ,我々の手間は大幅に削減できたはずでしたが,顧客向け製品用には必要であることが明らかになりました。この作業は Software Resources International (SRI) 社に委託しました。同社はこの種のアプリケーションを専門としており,別のプロジェクトですでに我々と協力関係にあったためです。

5. Ada - イエス,PL/I - ノー

OpenVMS はほぼ全面的に MACRO-32,BLISS,C で書かれており,少量の Intel アセンブラが必要であることは分かっていました。これ以外に何も使用しなくても,かなりのところまでは行けるはずです。ただし,Ada のコードは少しありました。これは一部の OpenVMS の顧客層では人気があります。我々は,OpenVMS I64 Ada コンパイラを提供するために,Ada Core Technologies と契約しました。

しかし,PL/I コンパイラに関しては反対の決断をしました。OpenVMS アプリケーションの世界では PL/I はほとんどなく,PL/I から C へのトランスレータが存在するからです (結局,MONITOR の PL/I の部分を C で書き直すことにはなりました。その結果,Alpha と Integrity で共通のコードになりました)。

6. デフォルトの浮動小数点形式は IEEE

浮動小数点形式は,当初予測していたよりもはるかに多くの影響をもたらした大きな決断でした。Alpha では,VAX の浮動小数点形式 (一般に F/D/G として知られています) と IEEE がすべてハードウェアに実装されています。つまり, IEEE に変換してもパフォーマンス上のメリットはありません。Integrity 上の OpenVMS では,VAX の浮動小数点形式がソフトウェア側でエミュレートされ,IEEE だけがハードウェア上にあります。アプリケーションによっては,パフォーマンスの違いが非常に大きくなる可能性があります。

我々は,IEEE を Integrity 上の OpenVMS のデフォルトとすることにしました。Alpha 上では,形式修飾子を指定せずにコンパイルすると,VAX 浮動小数点が生成されます。Integrity 上では,同じコンパイル・コマンドで IEEE 浮動小数点が生成されます。このことは,最高水準の精度が求められるいくつかの計算には影響を及ぼしますが,エミュレーションをデフォルトにすることから生じるパフォーマンスへの影響を正当化することはできませんでした。ソフトウェア・エミュレーションが遅くても,それが許容できる解決策であるアプリケーションに対しては,/FLOAT スイッチを使用することによって OpenVMS Integrity コンパイラは F/D/G をサポートします。

7. 数学ライブラリ

数学ランタイム・ライブラリは,システムにおいて,最も目立ったパフォーマンス重視のコンポーネントです。Alpha 上では,Alpha アーキテクチャ専用に C で書かれています。Integrity 上でこれを再コンパイルするのは好ましくありません。Integrity アーキテクチャ用に最適化された Intel Itanium の数学ライブラリが,有効な代案に思われました。我々は,Intel からこの数学ライブラリを入手することにしました。発表の一部に Intel とのコンパイラ・テクノロジの共有が含まれていましたが,この数学ライブラリは,我々がその恩恵を受けた最初の事例の 1 つでした。難点はありましたが,パフォーマンスの向上に比べれば非常に小さく,将来の変更への備えも強化されました。

8. カーネル・プロセス・モデルの拡張

Alpha 上では,RMS,XQP,DECnet などのいくつかの OpenVMS システム・コンポーネントが,複数の実行スレッドをコンポーネント自身で管理していました。つまり,個々のコンポーネントは,コンテキスト・スワップの詳細を知っており,実行コンテキストの中断と再開をするために個別の環境が必要としていた要素を実装していました。「コンテキスト」の細部の違いにより,これらの実装を Integrity 用に書き直さなければなりませんでした。一部の顧客も同じような設計上の決断をしたことを我々は知っていました。これらの変更はどのようなシステムにおいても困難ですが,Integrity では特に困難です。変更が必要なコンポーネント数を考えると,気が遠くなるほど大変な作業です。同様に,顧客にとっても Integrity へのポーティングは非常に大きな課題となります。このため我々は,「カーネル・プロセス」と呼ばれる内部のメカニズムを,どのようなモードからも呼び出せるように拡張し,プライベートなスレッド処理を行う OpenVMS コンポーネントのすべてを,拡張したルーチンを呼び出せるように変更することにしました。とても複雑なコードを一度だけ書き,その後呼び出し側を変換していくという方法は,非常に良いアプローチであり,コードの保守性が格段に向上します。もう 1 つの利点として,Alpha と Integrity で共通のコードになったことが挙げられます。Alpha コードのポーティングではなく,新しいルーチンへの変換 (強く推奨します) についてのサンプルを記したドキュメントがあります (Google で EXE$KP_START で検索してください)。

9. ライセンス

我々は,新たに HP 製品になることに関して懸念がありました。OpenVMS のライセンス方式は,HP の既存製品のいずれとも,まったく異なっていたからです。大がかりな変更をいとわなければ,このような懸念はなくなります。Integrity については (Alpha では違いますが),特定レベルのオペレーティング環境 (OE) を購入するという,HP-UX のライセンス・モデルを採用することになりました。これにより,我々はかなりの作業を行う必要が生じましたが,追求するべき正しい戦略でした。

テクノロジの概要

OpenVMS のように大規模で複雑なオペレーティング・システムでは,コードの大部分はプラットフォームや CPU アーキテクチャに依存しません。たとえば,デバイス・ドライバ,ネットワーク・プロトコル,クラスタ,ロック・マネージャ,ファイル・システムは,Integrity 上で実行するためにコーディングし直す必要はありませんでした。しかし,アーキテクチャに関する非常に大きな課題がいくつかあり,システムのいくつか集中した領域で多数の作業が発生しました。

以降のセクションでは,我々の作業の大部分を占めた,ベース・オペレーティング・システムのコンポーネントについて述べます。コンポーネントは次のどちらかのカテゴリに分類されます:

  1. Alpha に共通しているが,細部が異なるコンポーネント。
  2. Integrity に固有のコンポーネント。

なくなった Alpha コンソール

Alpha 上では,コンソールはファームウェア・パッケージの一部です。システムのブート時と,OpenVMS 用のデバイス検出の際に欠かせない役割を果たします。Intel Itanium アーキテクチャは,特定のオペレーティング・システムに特化せずに,複数のオペレーティング・システムの基本的な要件に対応することを目指しているため,そのブート・パスは必然的に汎用で最小の環境となっています。したがって,ブート・パスは SYSBOOT を開始するところまではまったく新しいコードになります。Integrity 上では,OpenVMS 自体が,Alpha のファームウェアが提供していた多くのランタイム・サービスを提供します。

なくなった Alpha の PAL (Privileged Architecture Library)

PAL もまた,Alpha のファームウェア・パッケージの一部です。Alpha アーキテクチャはオペレーティング・システムを選びません。オペレーティング・システムが固有の PAL を提供できるようになっています。OpenVMS PAL には,VAX キュー命令,VAX 特殊レジスタ,VAX IPL および権限モード変更管理,割り込み処理,トランスレーション・バッファ・ミスに対処するための PTE フォーマットの情報,およびアラインメント・フォルトのためのコードが含まれています。したがって,VAX でこれらの機能を使用するために特別に書かれたコードは,Alpha でも変更なしで動作できます。ここでも,Integrity 上では OpenVMS 自身がこれらの機能を提供することになります。Alpha PAL の置き換えは特に難しい仕事でした。

異なるプロセッサ・プリミティブ

Itanium のレジスタ・セットは,Alpha とはまったく異なり,サイズもはるかに大きいものです。Register Stack Engine は,オペレーティング・システムがこの巨大なスタック環境を管理するのを支援するメカニズムです。OpenVMS において全面的に新しいコードが必要でした。

Alpha では,load-locked 命令と store-conditional 命令のペアが,マルチプロセッサ環境でのデータへのアトミックなアクセスを保証しています。VAX と同様,Itanium にはアトミック性を保証する特定の命令があります。

新しいレジスタ・セットでは,プロセスのコンテキストの保存方法が変わります。このため,独自の「スレッド処理」を行っていたコードはすべて,本格的な改訂を行う必要がありました。

Alpha PAL は,オペレーティング・システムに割り込みについて通知する前に,多数の割り込み処理を実行します。このポーティング・プロジェクトの最も大きな部分の 1 つが,SWIS (Software Interrupt Services) でした。これは,割り込み処理,および関連するモード・チェックと管理を完全に制御する,Integrity 固有のコードです。

呼び出し規約の影響

Intel 呼び出し規約のレジスタ規約とスタックの使用法は,Alpha 呼び出し規約のそれとは大きく異なります。レジスタの違いから多数のソース・コード・モジュール,特に MACRO-32 と BLISS で書かれたモジュールを変更するのを避けるために,Alpha の R0 〜 R31 から Itanium の R0 〜 R31 へのマッピングを定義しました。コンパイラは,スイッチに基づいて自動的に変換を行います。ただし,プログラマはデバッグ時にこのレジスタのマッピングについて知っている必要があります。このマッピングは,ワークステーションにメモとして貼り付けられ,そこから PowerPoint スライド,やがてマウス・パッドへと進出していきました。マウス・パッドは,今でも貴重な参照先となっています。(レジスタ・セット全体については,「付録 B - OpenVMS Alpha と Itanium のレジスタのマッピング」を参照してください)。

Integrity の例外処理では,VAX と Alpha で慣れ親しんだ「フレーム・ポインタ」のスキームではなく,「PC マッピング」を使用します。さらに,2 つのスタックを調整する必要があります。すなわち,ハードウェアによって管理されている整数レジスタ・スタックと,生成されるコードによって管理されるメモリ・スタックです。VAX と Alpha では,情報を見つけるためにプログラマが「スタックを歩く」ということを行っています。Integrity のメモリ・スタックには,この種の情報はごくわずかしかありません。呼び出し元の保存レジスタを見つけるには,プログラマは,現在の PC をインデックスとして使用して,一連の保存レジスタを指す「アンワインド・テーブル」を探します。コンパイラによって作成されたアンワインド・データは,イメージの起動時にアンワインド・テーブルに読み込まれます。アンワインド・テーブルの使用は,例外処理の基礎となっています。

注: 我々は,OpenVMS においてこの情報の入手先が 1 つだけとなるように,LIBRTL 呼び出し規約内のルーチンを,すべての特権モードから使用できるようにしました。

基本オペレーティング・システムと LIBRTL アンワインド・インタフェースが正しく動作するまで,永遠に時間がかかるように思えました。我々が受け取る例外処理に関する問題レポートは,何カ月もの間,途切れることがありませんでした。コードが正しく機能するようになった後も,そのパフォーマンスの向上のために,2 回の書き直しが行われました。予想通り,ここはプロジェクトの中でも困難を極めた部分でした。

ELF/DWARF の影響

ELF/DWARF 内部フォーマットを使用するという決定により,大量のコードを追加することになりましたが,最も影響を受けたのが我々の開発ツールであったため,先の見通しを計画することも困難になりました。独創的なデバッギングの発想が何よりも重視されました。

計画

2001 年後半中に,我々は開発計画の断片を組み立てて暫定スケジュールを組みました。これは,初期の依存関係を把握するのに必要でした。長期の計画ではありませんが,全員が動き出し,自分たちが現状を把握しているかどうかを判断するには十分でした。

Alpha と Integrity の共通コード・ベース

実装に関する最初の決断は,Alpha と Integrity の共通コード・ベースを作ることでした (VAX と Alpha ではコード・ベースは異なります。このような失敗を繰り返すつもりはありませんでした)。実際には,既存の Alpha ソースに Integrity サポートを追加しました。以下の 3 種類の作業となりました:

  • Integrity 固有のモジュールをいくつか作成する
  • 既存モジュール内でコードを条件分岐させる
  • いくつかの既存ルーチンを両方のプラットフォームで実行できるように書き直す

共通コード・ベースを作成するということは,これから見ていくように,このプロジェクトが,VAX から Alpha へのポーティングとはまるで異なるプロジェクトになるということです。

外部の協力

我々が「OpenVMS Alpha のスケジュールは変更しない」と約束したことを思い出してください。我々は,Alpha の開発を継続しながらポーティング作業を行わなければなりませんでした。新しい Integrity 作業の一部は,特定の OpenVMS エンジニアにしかできない作業でした。しかし,それよりもはるかに多くの作業が「再コンパイルと再リンクでポーティングが完了」の方向に向けて必要です。

EDS は何年もの間 OpenVMS ユーティリティの多くをサポートしており,エンジニアも我々のコード,ビルド手順,インテグレーション・テストに精通していました。このため,多くの OpenVMS ユーティリティとレイヤード製品のポーティングを EDS に委託しました。その中には,EDS がサポートしたことのないものも含まれていました。OpenVMS コードの大部分のポーティングとテストを担当した EDS エンジニアのおかげで,我々はスケジュールを守ることができたのです。

さらにいくつかの協力会社が,我々の初期のスケジュール要件を満たす上で重要な役割を果たしました。以前から OpenVMS の内部について経験を積んでいたため,Integrity 固有のコードに初めて取り組んだ日からすぐに貢献してくれました。

プロジェクトの依存関係とスケジュール

簡単にいうと,指示は,書いて,コンパイルして,リンクして,実行するべし,というものでした。計画の初期段階から,我々は BLISS コンパイラと C コンパイラを先に用意する必要があり,数カ月後に Intel アセンブラ (IAS) と IMACRO,そして LINKER はかなり先でもよいと認識していました。コードのリンクとデバッグができるようになるまでに,大量のコードを書き,コンパイルしました。このことが,その後の数カ月に多くの影響をもたらしました。LINKER は,OpenVMS のコンポーネントと同じくらい多くの変更が生じることが考えられ,次の年に行うことの多くは,V8.0 のリリース後でさえ,LINKER の機能の進化に左右されました。

SCD (System Code Debugger) もまた遠い先の約束でした。SCD は,DEBUG と同等ですが,カーネルとドライバのデバッグに使われるという点が異なります。残念ながら,非常に長い間,我々がデバッグに使用できたのは XDELTA および print ステートメントだけでした。このことがスケジュールにどの程度影響するのか,認識していませんでした。確実に分かっていたのは,SCD がなければ何もかも長引くだろうということでした。

最大の難関は,十分に機能する OpenVMS を,レイヤード製品の無数のエンジニアリング・グループ (DECthreads,JAVA,DECnet,TCP/IP,DECwindows など) に届け,そのポーティング作業に入れるようにすることでした。

VAX から Alpha へのポーティングを参考に

このプロジェクトに携わる多くのエンジニアは,何年も前に VAX から Alpha へのポーティングも経験しました。その経験をできる限りたくさん,現在の作業に役立つ見識に置き換えようとしました。確かにいくつか共通点はありましたが,大きな違いもありました。VAX から Alpha へのポーティングと比較するのは避けられないことです。技術レベルでの顕著な違いは,「広く浅く」対「狭く深く」であるといえます。

VAX から Alpha へのポーティングには,主に 2 つの難問がありました。

  1. OpenVMS は過去に一度もポーティングされことがない。MACRO-32 コードのすべてをコンパイルし,妥当な期間内で動作させるにはどうすればよいか?
  2. OpenVMS は,32 ビット VAX アーキテクチャ専用に書かれている。それを 64 ビット・アーキテクチャで動作させるために,何をすべきなのか? Alpha の場合は,システムごとに OpenVMS 専用の PALcode があり,それがシステムを VAX によく似たものにしていたため,懸念事項はほとんどありませんでした。実際,プロジェクト全体は EVAX,すなわち「拡張 VAX」と呼ばれていました。

これは「広く浅い」プロジェクトでした。大量のコードを変更する必要がありましたが,大部分は難しい作業でなかったのです。

Alpha から Integrity へのポーティングは,大きな難関が 1 つありました。それは,Integrity は VAX とはまったく似ておらず,いくつかの概念とオペレーティング・システムのコア部分のコードは,完全に新しいものになることでした。一方,システムの大部分には,必要な作業はあってもごくわずかでした。これは「狭く深い」プロジェクトでした。エンジニアの数ははるかに少なかったのですが,「『1 ビットもなし』から『出荷開始』」の状態になるまでに必要な時間は VAX から Alpha へのポーティングとほぼ同じでした。

評価リリース

我々は正式なフィールド・テストの前に,1 つの内部用ベースレベルをいくつかの選抜グループに配布し,次に 2 つの外部用評価リリースを公開することにしました。内部用ベースレベルは,コンパイラ・グループに提供し,コンパイラ・グループが生成したコードが正しく動作するかを検証できるようにしました。

最初の評価リリース (E8.0) の目標は,開発者が Alpha 上でコンパイルおよびリンクして,生成されたイメージを Integrity 上で実行できる,「クロス・ツール」環境に仕上げることでした。限られたコンパイラ群で構成され,オペレーティング・システムの大部分を揃えます。制約はありましたが,E8.0 は我々の成果を少し公にすることになり,冒険好きなサードパーティ開発者に試してもらうことができます。

第 2 の評価リリース (E8.1) は 6 カ月後にリリースし,目標は Integrity システム上でコードのコンパイル,リンク,実行ができる「ネイティブな」環境を用意することでした。システムの完成度が高くなるたびに,パートナーを増やしました。この段階で,もう 1 つハードウェア・プラットフォームを追加できるかもしれません。

この 2 つの評価リリースは,Integrity 専用でした。Alpha と Integrity の両方の顧客が OpenVMS の新しいバージョンを目にするのは,正式なフィールド・テストのときでした (48 台の Alpha へのインストール,54 台の Integrity へのインストールという,OpenVMS 史上最大規模のフィールド・テストとなりました)。

開発が始まる

開発が始まった正確な日付を特定することはできません。次の数カ月間は,何が必要なのかを設計チームが把握し始めていく中で,こまごまとした作業が個別に発生していました。同時に,手順が確立され,それに基づいて開発環境が規定されました。2001 年末までに,小集団のエンジニアが連携するようになり,一体となって動き始め,勢いが増しました。初版のストリーム・コードの変更が行われたのは 2002年 1 月 15 日でした。

2002 年 2 月 1 日の「The Inquirer」の ヘッドラインは,我々への信頼感が感じられて光栄でした:

「コンパック,Itanic で VMS を起動」

クールです。このときはまだ最初のコード・チェックインの 13 日前でしたが,とにかくこの報道を気持ちよく読みました。

コンパイラ

当初,我々が使用できるのはクロス・ツール環境に限られていました。コンパイラを Alpha 上で実行し,Integrity 用のコードを生成しました。こうした状況が長い間続き,少なくとも,Integrity 上での OpenVMS の実行までに 1 年かかりました。ここでもまた,独創的な考え方が貴重であることが証明されました。

ビルド・コンパイラがすぐに適切なコードを生成していたら,実行可能なシステムにもっと早くたどり着いたことでしょう。C コンパイラ・エンジニアは,プロトタイプの Integrity Linux コンパイラを作成し,生成されたコードと ELF/DWARF の生成を Integrity Linux システムでテストしました。コンパイラに関する Linux の作業のほとんどは,我々が販売していた Alpha Linux コンパイラ用のものがすでに開発されていました。2001 年 9 月,Integrity Linux コンパイラの作業が開始し,既存のコンパイラを使っていたコンパイラ・エンジニアたちが,コード生成の約 95% と,最初のシステム・ブートに必要な ELF/DWARF 生成の大部分をテストしました。

初期のコンパイラ開発で重要だったのは,OpenVMS に必要な組み込み関数を特定する段階でした。コンパイラ・チームはいくつかの既存の Intel コンパイラを調べてその組み込み関数から着手し,オペレーティング・システムに必要なものが明らかになるにつれていくつかを追加しました。MACRO-32 と BLISS に関しては,Integrity に固有の新しいコードは C で書くことになっていたので,組み込み関数はほとんど必要ありませんでした。

OpenVMS は,Alpha 上ではかなりの量の C ASM を使用しています。これにより以下のことが可能です:

  • 呼び出し元のリターン・アドレス・レジスタとしての R26 の参照
  • LOAD-LOCKED / STORE-CONDITIONAL 命令を使用したアトミックなプログラミング

Alpha と Integrity の C コンパイラはどちらも,組み込み関数 __RETURN_ADDRESS および __CMP_SWAP_QUAD を定義していたので,ASM を排除して共通コードを作成しました。

MACRO-32 コードには特別な問題がありました。VAX から Alpha へのポーティングは,呼び出し規約がほぼ同じであったため (そのように設計したのです),簡単でした。今度は,まったく異なる呼び出し規約に直面しています。もっとも大きく異なるのは,Intel の呼び出し規約で定義されている汎用保存レジスタは 4 個だけ (R4 〜 R7) であるのに対し,Alpha では 14 個 (R2 〜 R15) だという点です。これは,MACRO-32 コードでの多くの前提条件が,Integrity では適切でないことを意味します。IMACRO (Integrity 上での MACRO-32 コンパイラ) は,この違いを認識しており,新しいコンパイラ・ディレクティブによって明示的に指定されない限り,危険にさらされる可能性のあるレジスタを保存/復元します。我々はこの種の処理を,特にパフォーマンスが重要な場合に適宜コードを書き直しました。

R0 または R1 以外のレジスタにデータを戻すルーチンへの CALL に対しても,IMACRO が戻された値を上書きしないように,新しいディレクティブによって指定する必要があります。我々は,レジスタの前提条件が有効でない可能性がある場合に,LINKER が診断警告メッセージを提供する手法を考え出しました。最初は手間がかかりましたが,その後これが大いに役立ちました。次に,OpenVMS で使用されているすべてのリンケージを新しいファイル $IA64_LINKAGES で定義しました。このファイルは,ARCH_DEFS.MAR を使って各 MACRO-32 ソース・モジュールに挿入されます。

MACRO-32 のもう 1 つの問題は,CALL の手動によるコーディングでした。つまり,引数を R16 〜 R21 へ移動し,引数の数を R25 に入れ,次に JSBing を標準の CALL ルーチンに置くという作業で,これはもうひどかった! 呼び出し規約の違いのために,これらのすべての出現箇所を変更しなければならなかったので,それらを CALL にコードを書き直しました。世の中が完璧だったとしたら,すべてが標準 CALL になっていたはずですが,そのようなことは,OpenVMS 開発の最初の 12 年間は誰も考えもしないことだったのです。ある意味では,「VAX から Alpha へのポーティングでは楽をしすぎた」のです (Alpha から Integrity へのポーティング・プロジェクトの間,これが我々の口癖になりました)。

BLISS グローバル・レジスタは予想外に難関でした。BLISS グローバル・レジスタは,イメージ内のすべてのモジュール (FAB を含む RMS の GLOBAL REGISTER など) で共用するために定義されたレジスタです。これは,どの Intel のレジスタ規約にも合いません。BLISS のコード生成は,「生きた」値が入っている可能性のあるレジスタを認識し,それを保護するように拡張されました。

何年も前に,「The Thing (遊星からの物体 X)」というホラー映画がありました。我々はその子孫の 1 つと思われる NaT (Not a Thing) というものに遭遇しました。NaT は,レジスタの 65 番目のビットです。これが設定されていると,そのレジスタの内容は無効であることを意味します。投機的アクセスの一部として使われます。特殊な命令を使用しない限り,レジスタをメモリに保存できるのは NaT ビットが 0 の場合 (レジスタが NaT でない場合) だけです。つまり,投機的アクセス (変更なし) はできますが変更はできないということです。

これは,IMACRO にとっては新しい概念であり,問題がなくなるまでしばらくかかりました。また,コンテキストの切り替え時に NaT の状態を正しく維持するのは簡単ではないことが分かり,オペレーティング・システムも苦しみました。そしてついに怪物は退治されました。

Itanium アセンブリ言語の学習

我々は,アセンブラ・コードはできる限り書かないという目標を持っていましたが,多少は発生すると分かっていました。アセンブラなしでどう始めればよいでしょう。IAS を OpenVMS にポーティングするまでに数カ月を要します。原因は難易度ではなく,タイミングとスケジュールです。最終的にはオープン・ソースの IAS アセンブラを使い,我々の ELF 拡張をいくつか追加し,比較的小規模の作業となりました。しかし一方で我々は,Itanium1 ProLiant DL590/64 を入手し,Linux をインストールしました。マニュアルを読むのも方法の 1 つですが,3 つの命令で構成されるバンドル,プレディケート,アンワインド・ディレクティブについて本当に学べたのは,Linux システム上で C コードを書いてコンパイルし,生成されたコードを調べることからでした。

実際,以下は最初に Linux 上で GNU C とアセンブラを使ってコンパイルし,デバッグしました。

  • SWIS
  • EXCEPTION
  • IVT (Interruption Vector Table)
  • TLB (Translation Lookaside Buffer) ミス・ハンドラ

しばらくの間,この重要なコードのコンパイル,リンク,デバッグには, Itanium ハードウェア上で実行する Linux ツールを使用しました。これにより,IPB と SYSBOOT で必要になったときには,OpenVMS の基本機能は準備できていました。

最初に ELF/DWARF を採用すると決定した時点では,初期の開発中にそれがどれだけ役に立つのか認識していませんでした。アプリケーションにとって意味があるとした根拠が,OpenVMS にとっても意味があったのです。

Alpha PALcode の置き換え

主に,次の 3 つの領域での作業となりました:

  • OpenVMS の知識をほとんど必要としない,割り込み,IPL,権限モード管理
  • 直接的な PAL ルーチン呼び出し
  • メモリ管理

期間短縮と簡便性を考え,我々は,C,IMACRO,BLISS 用に適切なヘッダとライブラリ・ファイルを作成することによって,個々の PAL 呼び出しに対してシステム・サービスを定義しました。これにより迅速に進み,その後のパフォーマンスの改善も楽になりました。

SWIS は,OpenVMS を Integrity 上で動作させている中心部です。システム内で IPL および権限モードのチェックと操作を必要とするものすべて,SWIS によって制御されます。SWIS ログのデータは,我々が遭遇した重大な問題のデバッグを行う上での頼みの綱となりました。

入り組んだ VAX キュー命令のエミュレーションは,「初日」から問題でした。このような命令は多数あり,複雑でもあります。OpenVMS は,このような命令の多くがないとまったく動作しません。

メモリ管理の変更としては,仮想アドレスから物理アドレスへの変換,アラインメント・フォルトの処理,PROBE エミュレーションがありました。我々は,Alpha の仮想アドレス変換および GH リージョンを持つアドレス空間レイアウトを維持する仕組みを,Itanium の基本要素である VHPT を使って考え出しました。

ポーティングのガイドライン

我々は,コーディング規則を記した簡単なドキュメントを作成しました。我々が Alpha の V7.3-2 を本格的に開発しながら,Integrity に対するサポートを Alpha ソース・コードに追加していたことを思い出してください。作業を必要としたのはコードそのものだけではありません。共通のソースから,共通のビルド手順で,同じクラスタ上で Alpha と Integrity を対象にビルドを行っていたため,開発環境にも本格的な拡張が必要でした。ポーティングのガイドラインは,プロジェクトのあらゆる面で必須だったのです。この小さなドキュメントは,充実するにつれて我々以外の開発グループにも使われるようになりました。

コンピュータ・プログラマが「バイナリ思考」なのは考えられることだと思うかもしれませんが,我々はかなり早い段階で,既存のコード・ベースの一部とビルド環境は,違いを考慮するべきなのに,「VAX か Alpha か」と決め打ちするようなアプローチを採っていることに気が付きました。これは,VAX から Alpha へポーティングしたときの我々の状況を考えれば,まったく理解できることでした。しかし,それは近視眼的であり,後で多くの手間がかかる要因となります。このような失敗を繰り返すつもりはありませんでした。

我々からプログラマへの最初の注意の 1 つは,「二元論的な条件分岐には注意」し,将来のためにできる限り汎用性のあるものに変更せよ,というものでした。条件分岐はすべて入念にチェックしなければならず,そのうちの多くは変更が必要でした。これは,DCL コマンド・プロシージャや,C や BLISS などに関しても同じでした。このことは非常に重要だったため,条件を 1 つずつチェックするたびに,変更が必要ない場合でも,エンジニアは「IA64 用に確認済み」というコメントを追加しました。以下にいくつか例を挙げます:

  • IF VAX (.....) ELSE (.....) ENDIF
  • IF ALPHA (.....) ELSE (.....) ENDIF
  • IF VAX (.....) ENDIF の後に IF ALPHA (.....) ENDIF

これらの命令は,3 つ目の選択肢がくると問題であることは明らかです。最初の 2 つの例では,Integrity 上で VAX または Alpha のコードが使われます。Integrity 上でコンパイル・エラーまたはリンク・エラーが発生し,プログラマは調整を考えなければなりません。しかし 3 つ目は,Integrity 上ではエラーがないながらもコードがまったく生成されないので,特に問題です。我々は既存の条件付きコードに対して必要な作業量を,明らかに過小評価していました。読みやすい共通のソースを維持するために,我々は頻繁に条件をマクロ内に埋め込みました。

ブート・シーケンスが形になる

2001 年の秋,我々は最初の HP i2000 を購入しました。我々は,まだ COMPAQ に属していましたが,HP との合併提案が発表された直後であり,i2000 があれば新生 HP で有利なスタートが切れると考えていました。

間もなく,ブート・パスの設計およびコード記述の担当者たちと,定期的な調整ミーティングが必要になりました。第 1 回目の「デバッグ・ミーティング」が 2001 年 11 月 14 日に開催され,その後約 2 年間,週に何回もこのミーティングが続きました。進捗確認のためではなく,我々の無知をさらけ出す間抜けな質問をしたり,特に互いに学び合ったりするためのミーティングで,毎回どこか愉快なミーティングでした。デバッグ・ミーティングは開発者のみが参加し (マネージャーは参加不可) ,30 〜 45 分程度で仕事に戻りました。何がうまくいき,何がうまく行っていないかや,どうしたら先に進むことができるかを,非常に細かいレベルで話し合うことが目的でした。

2002 年春,我々は,Intel プロセッサ・ベース製品の開発会社に貸し出される,Intel の「ホワイト・ボックス」数台,汎用の開発スターター・キット,エンジニアリング・サンプルを入手しました。これらのホワイト・ボックスで,システムの数は 2 倍近くに増えました。さらに,設計と開発に役立つさまざまな実験テクニックを学び始めていました。

本稿では,ブート・シーケンスの定義を,「ブート・コマンドの発行があってから,必要な execlet (OpenVMS のコアを構成するイメージ一式) をすべて読み込むまでに必要なコード」としました。次のコードが対象です:

  • VMS_LOADER.EFI
  • IPB.EXE
  • SYSBOOT.EXE
  • EXEC_INIT.EXE

コードの説明に入る前に,Intel によって定義されている汎用のブート・パス構造を見てみましょう。

  1. ブート・デバイス上には FAT (File Allocation Table) パーティションが必要です。OpenVMS には,PC で使われる意味でのディスクの「パーティション」はありません。OpenVMS の FAT パーティションはコンテナ・ファイルです。つまり,システム・ディスク上にあり,特殊な内容とフォーマットを持つ,通常の OpenVMS ファイルです。

  2. パーティション内のファイルの 1 つがオペレーティング・システムのローダです。このファイルは,Intel Itanium アーキテクチャ・システム上でのブートを目指す各オペレーティング・システム開発グループによって作成されます。

.EFI の拡張子から分かるように,実行する最初のコードは OpenVMS イメージではありません。OpenVMS Engineering によって書かれた EFI (Extensible Firmware Interface) アプリケーションであり,これがシステムを準備して IPB.EXE を読み込み,起動します。IPB は Itanium Primary Bootstrap で,Alpha 上では APB.EXE,VAX 上では VMB.EXE に相当するものです。このローダには,ブート・シーケンス・ロジックに加えてプリミティブなファイル・システムが含まれており,通常のメカニズムが利用可能になる前に,OpenVMS イメージの検索,読み込み,起動を実行できるようになっています。このため,実行される最初のコードでさえも,ELF イメージの内部構造について知っていなければならないのです。

このローダは Integrity 向けのまったく新しいコードです。ローダは,IPB.EXE が Alpha における同等のものとほとんど同様に機能できるように,環境を整える機能を持っているという見方もできます。VMS_LOADER.EFI は,構成ツリーと HWRPB の作成など,Alpha 上のファームウェアと同じことを多数実行します。IPB は,SYSBOOT.EXE のために Alpha 上と同じ状況を Integrity 上で実現するために,できる限りのことを実行します。一度 SYSBOOT.EXE が開始した後は,外部インタフェースから見ればいろいろなものが Alpha とほぼ同じに見えます (たとえば,システム・パラメータの調査と変更の停止など)。SYSBOOT.EXE はデータ構造体をいくつか作成し,いくつかの execlet を読み込み,最後に EXEC_INIT.EXE に制御を渡します。

この時点で,ブート・シーケンス内の大部分のプラットフォーム固有コードは完了します。EXEC_INIT.EXE は,残りの execlet (通常は二十数個) を読み込み,その初期化ルーチンを実行し,最後に SWAPPER プロセスに制御を渡します。

このプロジェクトのもう 1 つのテーマは,よほどの理由がない限り「違えない」でした。これは,いくつかの領域で難問になりましたが,特に ACPI とブート・パスとの関係がそうでした。「違えない」ことの 1 つは,他の HP Integrity オペレーティング・システムが Intel の仕様に従って何かを厳密に行っているのであれば,OpenVMS でもそのようにしなければならない,ということでした。我々は,アーキテクチャまたはファームウェアの設計者や実装担当者による特別な処置が必要にならないように努力しました。システムのブートは,オペレーティング・システムごとに大きく異なる可能性のある領域の 1 つです。具体的に言うと,ほとんどのオペレーティング・システムは,1 つのファイルが読み込まれることによって成り立っているのです。ACPI は,必要なコードがすべて実行しているとの認識のもとで,次にすべての構成データを提供します。これは,明らかにこれまでの説明の中で見てきた OpenVMS モデルではありません。

プリミティブ・デバッギング

デバッガが使える贅沢やクラッシュ・ダンプをとる能力が得られるまでは,さまざまな形の print 文が,問題を見つけ出す唯一の手段でした。我々はしばらく print 文に苦しみながらも進展していました。そこに特効薬の 1 つが実現しました。命令デコーダです。呼び出し可能な命令デコーダと命令フォーマット構造定義は,DELTA,XDELTA,DEBUG,SDA,SCD,PCA など,あらゆるデバッグ・ツールの土台となります。さらに,フォーマット定義はアラインメント・フォルト処理の際に基本オペレーティング・システムによって使われます。XDELTA が機能するようになると,ブレークポイントとシングル・ステップ命令が生産性向上に役立ちました。基盤となるデバッグ・コードのほとんどは,Integrity 用のまったく新しいコードでしたが,「古い」ものが 1 つありました。PSR.ss ビットの設定方法が VAX の Tbit にそっくりなのです。ただし Alpha 上よりはずっとシンプルです。

クラッシュ・ダンプが可能になったことは,このようなプロジェクトでは重大な出来事であり,最初の 1 回はまったく意図せずに起こりました。何かのコードを進めているときに,ブレークポイントが間違って配置されました。";P" によって ACCVIO が発生し,そして何と,クラッシュ・ダンプが完璧に実行されたのです。コードはコンパイルとリンクが済んでおり,実行されるのを待つだけでした。クラッシュが喜ばしい出来事になった,めったに見られない瞬間でした。

初期の「ビルド」

2002 年の前半中に,かなりの量のコードが書かれ,コンパイラも形になり始めました。いくつかの OpenVMS ソース・コードの機能は,Integrity 向けビルドの初期段階にありました。本格的な Integrity ビルドを目指すにはあまりに早い段階だったので,前進し続けるために必要ないくつかに集中しました。初期のうちは,これらいくつかのイメージだけをビルドして OpenVMS Alpha システム・ディスクにコピーし,それを使ってブートの初期段階をテストしました。少し面倒なやり方でしたが,少数のエンジニアしか必要とせず,とてもうまく進行しました。業界標準コンポーネントの使用で良かった点の 1 つは,いくつか新たにディスクが必要になったときにはいつでも,CompUSA に行って入手できるという点があります。これは OpenVMS の開発にとって,まったく新しい概念です。

プロジェクトのこの時点では,OpenVMS の大部分をどのようにビルドするかの中心部分である,LIBRARIAN はまだありませんでした。我々は,大きなオブジェクト・ライブラリは作成せず,.OBJ も削除しないようにビルド・プロセスを変更し,次に,すべてのリンク・プロシージャを変更して,.OBJ をライブラリから取り出すのではなくプロシージャに .OBJ を直接含むようにしました。

当時は LINKER の機能が非常に限定されていたため,OpenVMS を通常とはまったく異なる方法で実行せざるを得ませんでした。LINKER は単一のイメージをリンクしますが,ベース・イメージを通じて次々と呼び出される execlet をまだリンクできていませんでした。20 年前に OpenVMS を経験していた人であれば (V5.0 よりも前),モノリシックな SYS.EXE のことを思い出すでしょう。それは現在の我々が必要としているものではありませんでしたが,非常に巨大な SYSBOOT.EXE が役割を担いました。成長するブート・パスのデバッグの非常に早い段階では,通常は execlet にある,必要なすべてのコードが SYSBOOT.EXE にリンクされました。この先祖返りのような方法は長く使うものではありませんでしたが,1 日も無駄にはできませんでしたし,これが我々を動かし続けました。

2002 年 6 月 3 日,最初の全般的な Integrity ビルドが発表されました。ブート・パスの作業を担当した人以外にとっては,ここがコードのコンパイル結果を見るための実際の出発点でした (大まかに言い換えると,MACRO-32 コードが新しい IMACRO コンパイラをうまく通ったことが分かったという意味です)。

HP の所属となった我々は,2002 年 7月,rx2600 の最初の社内向けの出荷版を受け取りました。プロジェクトは,ほぼ正常に見え始めていました。つまり,定期的なビルドと定期ミーティングが行われ,開発システム数は増加し,いくつかのコードがうまく動作しました。i2000,ホワイト・ボックス,さらに rx2600 が導入され,重要な作業を行うそれぞれの開発者に独占的に使用できるシステムが行き渡りました。実装担当者の数が増えるにつれて,もっと優れた,多数のプロシージャが必要になりました。

Integrity 上でまだネットワーク機能がなかったため,開発クラスタから Integrity システムへ手早く簡単にファイルを移動する手段が必要でした。我々は HP ディスク・システム 2100 (「ピザ・ボックス」や「パンケーキ」などと呼んでいました) を持ってきて,これを小さな OpenVMS Alpha システムと 6 台の Integrity システムに接続し,同じ構成をいくつも再現しました。当然これは完全にサポート対象外の構成でしたが,マウントとマウント解除を慎重に行うことでうまく動作しました。我々は開発クラスタ上でビルドし,生成されたキットを「サーバ」の Alpha にコピーしました。各開発者は,指定されたディスク上でシステム・ディスク・ビルドを実行し,それをマウント解除し,Integrity システムをブートしました。

この頃から,再配置データ,アンワインド・データ,命令の数で,Integrity 上のイメージ・サイズがどれほど大きくなるのか認識し始めました。それに加え,現場のデバッグを支援するために作成すると決定したトレースバック情報もあります。その結果,Integrity 上の OpenVMS イメージ (アプリケーション・ソフトウェアとオペレーティング・システムのイメージ) は,Alpha 上の対応するイメージの約 3 倍の大きさでした。

ブート・コンテスト

「初ブート」は,このようなプロジェクトにおいては常に一大イベントです。しかし,技術的な観点からは,これは最終目標に到達できる可能性があるという,ささいな実証ポイントでしかありません。見えないところでのごまかしも多く行われるので,限りなく幻想に近いのです。大部分の人がこのことを理解しています。それでもやはり,積み上がった期待から非常に盛り上がるのです。

Integrity 上の OpenVMS の初ブートは,公開コンテストになりました。ブートの日付を正確に予測して,賞を獲得しよう! (そもそも何かを動作させるために奮闘しているところで,まして,システム・ブートのような目立つことを目指すのは,単にプレッシャーが増すだけでした。)。

コンテストには必ずルールがあります。「初ブート」の正式な定義は,次のとおりでした。

  1. システムは "MIN" でブートすること。
  2. SYSTEM としてログインできること。
  3. $ DIRECTORY が正しいファイル一覧を返すこと。

絶対的に必要ではないセキュリティ,ネットワーク,クラスタリング,SMP,バッチ,エディタなどについての定めはありませんでした。

プロジェクト計画のために予定日を見積る際に,我々は VAX から Alpha へのポーティングを振り返りました。そのときは,OpenVMS をブートしたのは,適度に信頼性のあるリンクされたイメージができてから 6 カ月後のことでした。当時我々は,開発中のハードウェアで作業していました。Alpha から Integrity への初ブートの場合は,実際に出荷されている HP 製品である Integrity システムを使っていることを考慮して,期間を半分と考えていたため,目標を 3 カ月と定めました。つまり,2003 年 2 月 13 日でした。苦心のエンジニアリング計画にもかかわらず,我々は 2002 年末までのブートを目指していると,誰かが世界に公表してしまいました。

幻想ばかりじゃない

最小の初ブートであっても,達成するためにはシステムの多くの基本部分が動作していなければなりません。以下にいくつか挙げます:

  • IMACRO-32,BLISS,C コンパイラ
  • LINKER
  • デバイス検出
  • メモリ・レイアウト
  • デバイス・ドライバ
  • プラットフォーム・サポート
  • 割り込み
  • クロック・チック
  • メモリ管理
  • IPL の引き下げ/引き上げ
  • AST 配信
  • MOUNT
  • ファイル・システム
  • RMS
  • DCL
  • イメージ・アクティベータ

これらの条件の範囲内であれば,ごまかしは許され,推奨さえされていました。例外処理,エラーの戻り,セキュリティ,課金は,DIRECTORY リストが正しい限り無視しても問題ありませんでした。

Integrity 上での OpenVMS の初ブートの正式な日時は,2003 年 1 月 31 日午後 3 時 31 分 (東部標準時間) で,HP i2000 (Itanium1) システム上でのことでした。ブートが確認されると,互いに抱き合い,握手し,お祝いの言葉を掛け合いました。我々の自信と安堵感も一気に高まりました。確認されたブート・コンテストのディレクトリ出力と,コンテストの勝者は,付録 D「ブート・コンテストの公式発表:2003 年 1 月 31 日午後 3 時 31 分 (東部標準時間)」に記されています。

注: ファイルをリストした後に,$ プロンプトに戻っていません。コンテストのルールで,特にそのようにしました (指摘に備えて念のために書いておきます)。理由は,DIRECTORY コマンドの処理の最後のイベントは,「ファイルが見つかりません」を戻すことだからです。システムでシグナルやエラーの処理が可能になるのはまだ先なので,最後のファイル名を出力した後,ブレークポイントで停止したのです。

初ブートで使用したファイルの完全なリストは,付録 E「ブート・コンテスト・コード」にあります。

内部用ベースレベル - 2003 年 3 月 28 日

2003 年 3 月 17 日,OpenVMS は HP rx2600 (Itanium2) システム上でブートしました。これが,我々の初期のユーザのほとんどが持つことになるプラットフォームでした。それから 2 週間と経たない 2003 年 3 月 28 日,我々は最初の内部用のベースレベルをコンパイラ・グループに公開しました。間違いなく順調に進んでいました。自信を持ってシステムを他のグループに提供し,彼らの開発とテストをしたいという期待に十分応えられる状態になったのは,飛躍的な前進でした。間もなく DECnet と TCP/IP が利用できるようになり,開発システムの共有が簡単になりました。

2003 年 5 月 15 日,我々は,初めて Alpha システムと VAX システムが混在するクラスタに Integrity システムをブートしました。クラスタのデモが最初に公開されたのは,2003 年 5 月 19 日,アムステルダムの HP-Interex Conference においてでした。我々の開発ラボ・クラスタからの $SHOW CLUSTER コマンドの出力については,付録 F「クラスタ T シャツ」を参照してください (クラスタには VAX が含まれていましたが,クラスタ内に VAX と Integrity を混在させた場合のサポートについて,当初は確実ではなかったため,編集して削除してあります)。

先はまだ長かったのですが,ネットワーク接続したクラスタ・システムをブートできたことで,Integrity 上で完全に機能する OpenVMS が可能だということを確信しました。始まったばかりの頃は,Alpha 上の OpenVMS の品質とパフォーマンスを達成できるわけがないと,多くの人が思っていました。そもそも動作させるのは不可能だという声もありました。12 年前,VAX から Alpha へのポーティングに関しても同じ疑問 (5%) があったことにも注目しなければなりません。OpenVMS のポーティングはまったく初めての試みで,それができるかどうか本当に疑わしかったので,1990 年に批判的だった人たちの意見には信頼性がありました。今回は,ポーティングができるかどうかについて疑問はまったくありませんでした。唯一の疑問は,システムがどれだけの性能を出せるかということだったのです。

OpenVMS V8.0 - 2003 年 6 月 30 日

V8.0 の内部的なコード・ネームは MAKO でした。開発環境はクロス・ツールを使用していました。Alpha 上でコンパイルおよびリンクし,イメージを Integrity システムに移動しました。この最初の評価リリースの目的は,一部のサード・パーティ・プロバイダ向けに,早期に着手できる機会を提供することでした。最初の一般リリースが出荷されるときには,サード・パーティ・プロバイダの準備が整っていてほしかったのです。また,我々独自の環境以外での限定的な公開にもなりました。重大な局面になりつつありました。

クロス・ツールは以下の通りです:

  • コンパイラ- BLISS32,BLISS64,C,IMACRO,FORTRAN
  • IAS アセンブラ
  • LINKER
  • CRFSHR
  • LIBRARIAN
  • CHECKSUM
  • CDU
  • ANALYZE_OBJ

OpenVMS Engineering は Fast Track と呼ばれる特別プログラムを用意し,ごく限られた OpenVMS 環境でしたが,厳選した 20 のパートナーに対して専用のサポートを提供しました。一方我々は,ものが形になり始めていることが分かりました。

2003 年 7 月 8 日と 9 日,ナシュアで行われた HP のファームウェア・グループとオペレーティング・システム・グループのエンジニアとの技術交換会は,特に Intel と共同で Itanium の開発を行った HP チームのメンバーの一人も参加していて,とても有意義でした。我々には十分に機能するシステムがありましたが,「知れば知るほど,知らないことが増える」という経験の 1 つでした。

そして,多くの OpenVMS エンジニアがシステムのさまざまなコンポーネントのコンパイルとリンクにかかわり始めました。我々は,エンジニアリング・コミュニティ全体を対象に,ランチタイム・セミナーを何度か開催しました。初期の開発作業に携わっていたエンジニアたちが,システム内で新しい Integrity 固有の領域の詳細をプレゼンテーションしました。

名前よりも中身

1998 年,ロサンゼルスで行われたごく一般的なフォーラムで,OpenVMS Business Management は「OpenVMS が V8.0 になることはない」と述べました。いつまでも V7.x であり続ける,つまり,その余生を通じて可能な限りシステムの変化を抑えるということでした。当時は OpenVMS の将来について考え方が異なっていたのです。

時代は変わりました。2003 年,OpenVMS Integrity のどのリリースを V8.0 と名付けるか,OpenVMS グループ内で議論が広がりました。 「V8」はローカルなキャッチフレーズとなり,あるジュース・メーカーの商品が,不思議とあちらこちらに大量に見られるようになりました。

OpenVMS V8.1 - 2003 年 12 月 18 日

V8.1 の内部コード・ネームは JAWS であり,それはネイティブな開発環境に由来します。我々は Integrity システムでコンパイルし,リンクしました。この第 2 の評価リリースの目的は,2 つありました。

  • パートナー数を増やすこと。
  • 完全な Integrity 環境を構築すること。

コンパイルとリンクが Integrity システム上でサポートされるようになり,クロス・ツールとファイル転送機能は不要になりました。実際,この環境の初期テストの 1 つは,ツール自体をネイティブでビルドすることでした (たとえば,コンパイラが自身をコンパイルするなど)。

プログラム全体の浮動小数点モード

浮動小数点...浮動小数点...浮動小数点! 浮動小数点の動作は,Alpha と Itanium ではまったく異なります。異なる浮動小数点修飾子 (制御,丸め,精度) でコンパイルされたソース・コード・モジュール,およびオブジェクトが,1 つのイメージにリンクされます。Alpha では,浮動小数点の設定は,コンパイラが生成する命令ストリームの中に含まれています。Integrity 上では,命令の実行時に FPSR (Floating Point Status Register) の内容によって決まります。

Alpha では,各モジュールについて宣言したとおりものが得られ,途中で判断や仮定をする必要がありません。Integrity では,浮動小数点の設定は各オブジェクト・ファイルで指定され,LINKER はエントリ・ポイント MAIN のあるモジュールの浮動小数点設定をイメージ内に格納します。イメージがメモリに読み込まれた後,何らかの命令が実行される前に,FPSR には LINKER によって設定された値が設定されます。このように,OpenVMS には,このような混在モードの場合に正確な Alpha の動作を魔法のように再現する方法はありません。個々のモジュール宣言を区別するアプリケーションのために,プログラムの実行時の動的な変更に対応するシステム・サービス,すなわち SYS$IEEE_SET_* があります。

VAX F/D/G から IEEE への変換

アプリケーションが VAX の浮動小数点型を IEEE に変換できるように,ライブラリ・ルーチンをさらに追加する必要がありました。多くのルーチンはすでに存在していましたが,今度はアプリケーション開発者に対して,変換を積極的に勧め,足りない機能があることを発見しました。この予定外の作業をこのような遅い時期に誰ができるのでしょうか? 我々は Customer Support Center のエンジニア数名に協力を依頼し,彼らは期待通りの成果をあげてくれました。

メモリ内のワーキング・セットの固定

カーネル・モードに入って IPL を上げる特権プロセスは,自身のコードとデータをワーキング・セットにロックすることで,I/O の IPL が高くなりすぎても,ページ・フォルト・ハンドラが呼び出されるのを防いでいます。システム・サービス SYS$LKWSET は,特定範囲のアドレスを受け取り,メモリ内で該当するページをロックします。互換性のために,我々は,受け取ったアドレスの 1 つがコード・イメージ・セクションにあることが分かった場合に,SYS$LKWSET がメモリ内のイメージ全体をロックするように変更しました。

VAX ではコードとデータだけをロックする必要がありますが,Alpha では,コード,データ,およびリンケージ・データをロックします。少々複雑ですが実現可能です。Integrity 上では新しい ELF イメージ・フォーマットになったため,プログラマはコード,データ,short 型データ,リンケージ・データをロックする必要があります。これらはアプリケーション・レベルで知るのはほぼ不可能です。アプリケーションでは LIB$LOCK_IMAGE を使用して,イメージ全体をメモリ内でロックすることを強く推奨します。SYS$LKWSET を何度も呼び出すよりは簡単です。この新しい $LIB ルーチンは,Alpha と Integrity の両方で利用できるので,共通コードを維持できます。イメージ全体がロックされるため,プロセスのワーキング・セット・クォータを増やす必要がある場合があります。OpenVMS では,特権プロセスの多くを,LIB$LOCK_IMAGE を使用するように切り替え,SYSTEM アカウントのワーキング・セット・クォータを増やしました。

OpenVMS V8.2

Superdome デモ

ちょっと衆目を集めることほどわくわくするものはありません。2004 年 2 月 13 日,マサチューセッツ州ウエストボロの HP アナリスト・ミーティングで行われた,Superdome 4-OS (HP-UX,Linux,OpenVMS,Windows) のデモには,たくさんの注目が集まりました。4 つセルから成るシステムは,それぞれが別々のオペレーティング・システムが稼動する 4 nPar (ハード・パーティション) として構成されました。

V8.2 は,セル・ベースのシステムはサポートしておらず,このことがいくつか新しい問題を引き起こしました。今回は (多少のごまかしが許される) デモだったので,完全なソリューションを考え出すのではなく,いくつかの I/O 関連アドレスをドライバにハードコードしました。セル 0 で OpenVMS をブートしなければなりませんでしたが,この簡単な暫定的な対策で大きな効果が得られました。

50 ビットの物理アドレス指定

悪いタイミングで雷に遭いました。2004 年の真夏,最初の正式な Integrity フィールド・テストに向けてすべてが整っていましたが,rx4640 用の mx2 CPU でテストを開始したときに新たな事実が発覚しました。mx2 のキャッシュは,OpenVMS がサポートしている最大 43 ビットを超えるアドレスを使用する必要があったのです。1 つの選択肢は,rx4640 の 8 CPU バージョンをサポートせず,必要なメモリ管理作業は次のリリースまで延期することでしたが,それ以前に新しいプラットフォームが追加される可能性もあったため,V8.2 で対応することに決定しました。データ構造とソース・コードの変更は,DECnet や TCP/IP など,PFN と直接連携するあらゆる特権コードに影響するため,既知で必須の特権コードの変更を,すべて最初の Integrity リリースに盛り込みたいと考えていました。

急遽,OpenVMS に以下の変更を加えるために,設計書が作られ,プロジェクト計画が書かれ,5 人のエンジニアが選抜されました。

  1. PTE の PFN フィールドを 32 ビットから 40 ビットに拡張する。
  2. データ構造体,グローバル・セル,ルーチン・インタフェース内の他すべての PFN フィールドを,64 ビットに拡張する。

これらの変更は広範囲に及び,Integrity だけを対象としていましたが,プラットフォームの相違を埋めるマクロを使うことで,共通のソース・コードが維持されました。この作業でしばらくの間,週 1 回のビルドに混乱が生じ,影響を受けるレイヤード製品 (すでに完了したと思っていた) では,対応が難しい作業となりました。量は多くありませんが,微妙な領域にあったためです。基本オペレーティング・システムの作業が終わると,「50-Bit Physical Addressing Programming Cookbook」を参考に,開発者は間際になって割り当てられた追加作業を終わらせ,全員何とか生き残りました。

VAX キュー命令のエミュレーションの書き換え

Alpha PAL の呼び出しを OpenVMS のシステム・サービスに置き換える作業は,ほとんどのケースでうまく行きました。プロジェクトの早い段階で,我々は Integrity の EPC (Execute Privileged Code) 命令を使用する仕組みとして「プロモート・ページ」を作成しました。このメカニズムを利用して,SWIS に移行する前にカーネル・モードに入り,スタックの切り替え,レジスタの保存し,システム・サービス・ディスパッチャの呼び出しを行いました。

SWIS がない状態では,EPC は特権モードを切り替えるときにスタックの切り替え,レジスタの保存,IPL や AST などの処理を行いません。これはまさに,パフォーマンス重視のキュー命令のエミュレーションに必要なものです。ただし,スタックのセット・アップを行う SWIS がない状態では,多くの制約があります。コードはアセンブリ言語で慎重に書く必要がありましたが,不運な出来事が重なった後,必要なコードを正しく作成することができました。

スレッド化されたプロセス環境では,アラインメントに誤りのあるキュー要素へのアクセスをチェックするのは困難でした。我々は,呼び出し側の特権モードではアクセスできないキュー要素を検出する例外ハンドラをプログラミングしました。さらに,コードがアトミックにキュー命令の実行を続けられるかどうかを素早く判断するために,割り込みを不可にした TAK,PROBER,PROBEW 命令をうまく使う方法を設計しました。何度かつまずきましたが,最終的には良いソリューションができました。EPC は我々が必要としていたことを確実に実現しました。それ以外の PAL 呼び出しのいくつかをこの方法で変更しました。

最終的な V8.2 の変更点

2004 年のクリスマス直前,手に負えないような NaT の消費の問題が見つかりました。それが修正されてから,終わったと思いながら休暇に入りました。休みの間中テスト・クラスタを稼動させ,休暇明けには我々は勝利を宣言するはずでした。残念ながら,満足のいく結果にはなりませんでした。実際,休暇中に何人かのエンジニアが,2 つの問題に気づいていました。

浮動小数点...浮動小数点...浮動小数点!

Integrity システムには 128 個の浮動小数点レジスタがあります。コンテキストが切り替えられたときに,これらすべてのレジスタを無用に保存/復元しないことが望まれます。そのために,レジスタは構造上は,F0 〜 F31 (下位) と F32 〜 F127 (上位) の 2 つのセットとして扱われます。各セットでプロセッサによって維持されるステータス・ビットは,そのセット内のレジスタに変更が加えられたかどうかを示します。多くの場合,上位の浮動小数点レジスタ・セットは使用されず,OpenVMS は「変更」ビットを利用して不要な保存/復元をなくしています。しかし,AST 配信にかかわるところでそれが正しく行われておらず,それを見つけ出すまで非常に長い時間を要しました。

すると,また別の浮動小数点問題に直面しました。修正可能なメモリ・エラーが報告されたときに,浮動小数点レジスタが壊れたのです。この問題は発見が難しかっただけでなく,浮動小数点の使い方に関する社内の OpenVMS の決定に関係していました。OpenVMS および HP-UX とコンパイラ作成者との間には,コードが /INSTRUCTION_SET=NOFLOAT を使ってコンパイルされた場合,生成後のコードではレジスタ F6 〜 F11 のみを使用可能とするという協定があります。割り込み処理レベルでの保存と復元を制限するために,オペレーティング・システムはこの方法でコンパイルされています。レジスタの破損は,メモリ・エラーと同時に起こりました。ファームウェア・テスト・エンジニアリングで,修正可能なメモリ・エラーを挿入するテスト・プログラムを用意しました。我々はすぐにそれを OpenVMS にポーティングし,エラーのポーリング頻度を増やし,問題を診断して修正しました。OpenVMS のエラー・ログ機能がファームウェアを呼び出しており,浮動小数点レジスタを適切に保存していませんでした。

2005 年 1 月 10 日,V8.2 リリースの最後のコード変更が行われ,最終テストの実行が始まりました。テストは問題ありませんでした。ついに完成したのです。2005 年 1 月 13 日,OpenVMS Engineering Readiness Review が行われ,完成は正式なものとなりました。最終版の DVD が製造工程に送られました。


パフォーマンスの評価

実運用品質のシステムができましたが,どれだけの性能を発揮したでしょうか。いくつもの答えがある問いなので,同等レベルの Alpha と Integrity ハードウェア・プラットフォームが,特定の CPU,メモリ,I/O テストに対してどのような成績だったかに重点を置くことにしました。たとえば,Alpha DS25 と Integrity rx2600 や,Alpha ES45 と Integrity rx4640 を比較しました。

全般的に,Alpha システムと Integrity システムはほぼ同等の性能でした。いくつかのテストでは一方が少し優れており,別のテストでは反対の結果になりましたが,ほとんどの場合,差は少しでした。はるか昔の 2001 年の「発表」が行われたとき,パフォーマンスの優位が Alpha から Integrity に入れ替わるのは,2005 年頃になると述べられました。これはかなり正確な予想だったという結果となりました。

Integrity システムは,ソフトウェアからアクセス可能なパフォーマンス・カウンタを豊富に備えています。OpenVMS ツールには,データを収集し,適切な情報をルーチン内の命令ポインタに関連付ける機能が組み込まれています。これは,当初十分に性能を発揮していない領域を追跡し,改善するのに役立ちました。たとえば,RTL の特定の呼び出しシーケンスの中で,スタックのアンワインドが無用に行われていました (非常に高くつきます)。もう 1 つの例は,効率の悪い OTS データ移動ルーチンです。

1 つの普遍的な発見は,アラインメントが合っていないデータをなくさなければならないということです。アラインメントが合っていないデータ参照は Alpha 上でも高くつきますが,Integrity 上では 2 倍悪化することがあります。したがって,このようなデータ・セルは必ず自然な境界に合うようにアラインしてください。

これらの新しいプラットフォームでの経験を重ねるにつれて,当然ながらオペレーティング・システムとコンパイラも継続的に性能が向上し,CPU とプラットフォームの速度も向上するはずです。rx1600,rx2600,rx4640 (V8.2 でサポート) や,OpenVMS の将来のリリースでサポートされるもっと大型のシステムについても同じことが言えるでしょう。

まとめ

3 年半の取り組みの成果が,Integrity 上の OpenVMS I64 でした。我々は,アプリケーション・プロバイダが Alpha から Integrity へできる限り簡単に移行できるように努めました。ときどき例外が生じる可能性があることは認識していますが,ほとんどのアプリケーションに対して目標を達成しました。Integrity 向けには絶対に必要というものではなかったものもあり,少し迷惑をかけたかもしれませんが,OpenVMS を 2005 年には 2001 年よりも優れたシステムにすることが目標であり,我々はそれを実行したのです。

このような大規模なプロジェクトは,製品のライフサイクルの中では 2,3 回しか起こりません。今回は,OpenVMS にとって 2 度目であり,まだ前進を続けています。

謝辞

OpenVMS のポーティングには,ここでは紹介しきれないほど大勢の人々とグループにご協力いただきました。OpenVMS のコミュニティ全体が,この巨大な計画に参加しました。我々の顧客に自信をもって提供できる製品を作り上げるために,全員が最高の力を発揮してくれました。

今回の Integrity へのポーティングは非常に優秀な多くの人たちの努力の結果ですが,過去数年,もっと言うと数十年にわたり OpenVMS に貢献してきた人たちの仕事も大きく貢献しました。OpenVMS は,概念も実装も,一緒に仕事をするにはすばらしいシステムであり,我々よりも前に携わったすべての人たちに感謝します。

本稿をレビューしてくださった次の方々には特別にお礼申し上げます:Burns Fisher,Karen Noel,John Reagan,Ron Brender,Jeff Nelson,Josh Cope,Gaitan D'Antoni,Sue Lewis,Ken Moreau,Randy Barth。

詳細情報

この記事についてのご意見やご質問は,OpenVMS Business Management までお送りください。

付録 A - 完全な比較を行うために頭痛になる方法


付録 B - OpenVMS Alpha と Itanium のレジスタのマッピング


付録 C - HP i2000 での初ブート


付録 D - ブート・コンテストの公式発表:2003 年 1 月 31 日午後 3 時 31 分 (東部標準時間)


ブート・コンテスト・シャツを獲得した方々:

  • Luciana Silva
  • Gabriel Sterk
  • Randy Loch
  • Geoff Bryant
  • Kurt Huddleston
  • James Wilkinson
  • Lee Mah
  • Alan Frisbie
  • Hans Vlems

付録 E - ブート・コンテスト・コード

以下のファイルには,Integrity 上で OpenVMS の初ブートを成し遂げた 1361 のモジュールが含まれています。

vms_loader.efi
ipb.exe
sysboot.exe
sys$public_vectors.exe
sys$base_image.exe
sys$cpu_routines_4001.exe
sys$srbtdriver.exe
sys$opdriver.exe
  sys$dqbtdriver.exe
system_primitives_min.exe
system_synchronization_uni.exe
errorlog.exe
exec_init.exe
system_debug.exe
ia64vmssys.par
exception.exe
io_routines.exe
sysdevice.exe
process_management.exe
sys$vm.exe
shell8k.exe
  logical_names.exe
sys$ttdriver.exe
sys$srdriver.exe
sys$dqdriver.exe
vms$system_images.dat
sys$config.dat
sysinit.exe
libots.exe
librtl.exe
decc$shr.exe
cma$tis_shr.exe
image_management.exe
locking.exe
sysldr_dyn.exe
security.exe
vms_extension.exe
f11bxqp.exe
rms.exe
loginout.exe
dcl.exe
dcltables.exe
directory.exe
util$share.exe
directmsg
sysmsg
   

付録 F - クラスタ T シャツ


付録 G - 評価リリース V8.0


   Your feedback is important to us. Was this article useful/informative?
   
not at all(1) neutral(3) definitely(5)
 

 

** About PDF files: The PDF files on this Web site can be read online or printed using Adobe® Acrobat® Reader. If you do not have this software installed on your system, you may download it from the Adobe Web site.
プライバシー ご利用条件・免責事項