[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]

1 移行プロセスの概要

多くのアプリケーションにとって,OpenVMS VAXからOpenVMS Alphaへの移行 (migration)は簡単です。アプリケーションがユーザ・モードでのみ実行され, 標準的な高級言語で作成されている場合には,ほとんどの場合, Alphaコンパイラを使用してそのアプリケーションを再コンパイルし, 再リンクすることにより,Alphaシステムで実行可能なバージョンを作成できます。 本書では,移行するアプリケーションを評価する方法, およびもっと複雑で特殊な場合の対処方法について説明します。


1.1 VAXシステムとAlphaシステムの互換性

OpenVMS Alphaオペレーティング・システムは,OpenVMS VAXのユーザ,システム管理, およびプログラミングの環境とできるだけ互換性( compatibility) を維持するように設計されています。一般的なユーザとシステム管理者にとって, OpenVMS AlphaはOpenVMS VAXと同じインタフェースを備えています。 プログラマにとっての目標は,「再コンパイル,再リンク,実行」 という移行のモデルにできるだけ近づけることです。

OpenVMS VAXシステムで動作しているアプリケーションの場合, ほとんどの部分はOpenVMS Alphaシステムでも変更されません。

ユーザ・インタフェース

システム管理インタフェース

システム管理ユーティリティはほとんど変更されません。ただし, おもな例外が1つあります。それはデバイス構成管理機能で, OpenVMS VAXシステムではSystem Generationユーティリティ(SYSGEN) で提供される機能ですが,OpenVMS Alphaでは System Managementユーティリティ(SYSMAN)で提供されます。

プログラミング・インタフェース

概して,システム・サービスおよびランタイム・ライブラリ (RTL)呼び出しインタフェースは変更されません。1 引数の定義を変更する必要はありません。 相違点がいくつかありますが,これらの相違点は,次の2種類に分類されます。

1  バージョン 7.0 では,OpenVMS Alpha は 64 ビット・アドレッシングをサポートするために, 多くのシステム・サービスと RTL ルーチンを提供します。これは VAX システムでは提供されません。したがって VAX から Alpha への移行の問題にはならないため,本書では説明しません。

これらのサービスとルーチンを呼び出すVAXイメージの大部分は,VEST (VAX Environment Software Translator)を使ってトランスレートし,OpenVMS AlphaのTIE (Translated Image Environment)のもとで実行すれば,正しく動作します。TIE についての詳しい説明は,第3.2.2.1項と 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。

データ

ODS-2データ・ファイルのディスク上でのフォーマットは,VAXシステムと Alphaシステムとで同じです。しかし,ODS-1ファイルはOpenVMS Alphaでサポートされません。

レコード管理サービス(RMS)とファイル管理インタフェースは変更されていません。

IEEEリトル・エンディアン・データ型であるS浮動小数点( S_floating )と T浮動小数点( T_floating )が追加されました。

大部分のVAXデータ型はAlpha Alphaアーキテクチャでもそのまま使用できます。 しかし,システム全体の性能を向上するために,H浮動小数点( H_floating ) と完全な精度のD浮動小数点 ( D_floating )のハードウェアによるサポートはなくなりました。

AlphaハードウェアはD浮動小数点データを処理のためにG浮動小数点に変換します。 VAXシステムでは,D浮動小数点は56ビット(D56)であり,16桁の精度です。 Alphaシステムでは,D浮動小数点は53ビット(D53)であり,15桁の精度です。

H浮動小数点データ型とD浮動小数点データ型は通常,G浮動小数点または IEEEフォーマットのいずれかに変換されます。しかし,H浮動小数点が必要な場合や, D56 (56ビットのD浮動小数点)の精度が必要な場合には, アプリケーションの一部をトランスレートしなければなりません。

データベース

標準的な弊社のデータベースは,VAXシステムと Alphaシステムで同様に機能します。

ネットワーク・インタフェース

VAXシステムとAlphaシステムはどちらも次のインタフェースをサポートします。


1.2  VAXアーキテクチャとAlphaアーキテクチャの相違点

VAXアーキテクチャは強力で柔軟な命令を備えた,複合命令セット・コンピュータ (CISC)・アーキテクチャであり,VAXシステム・ファミリ全体で使用されています。 統一アーキテクチャのVAXファミリを, OpenVMSオペレーティング・システムと組み合わせて使用すれば,アプリケーションを VAXstationで開発し,小型VAXシステムでプロトタイプを作成し,大型 VAXプロセッサのプロダクション環境で使用したり,フォールト・トレラントな VAXftプロセッサで実行することができます。VAXシステムのアプローチの利点は, 個別のソルーションを変更し, 大規模な問題全体のソルーションとして容易に統合できるということです。 VAXプロセッサのハードウェア設計は特に, 可用性の高いアプリケーションに適しています。たとえば, 重要な使命を担うビジネス業務を実行するための,信頼性の高いアプリケーションや, 様々な分散クライアント/ サーバ環境でのサーバ・アプリケーションを実行するのに適しています。

弊社が実現したAlphaアーキテクチャは,高性能の縮小命令セット・コンピュータ (RISC)・アーキテクチャであり,1つのチップで64ビット処理を実現できます。 64ビットの仮想アドレスと物理アドレス,64ビットの整数, 64ビットの浮動小数点数値を処理します。64ビット処理は特に, 高い性能ときわめて大きいアドレッシング空間を必要とするアプリケーションにとって 役立ちます。たとえば,Alphaプロセッサは,グラフィック処理アプリケーションや, 膨大な数値を処理する経済予測や気象予報などのソフトウェア・アプリケーションに 適しています。これらは,イメージ処理,マルチメディア,ビジュアライゼーション, シミュレーション,モデリングなどの処理を必要とします。

Alphaアーキテクチャはスケーラブルでオープンなアーキテクチャとして設計されています。 シングル・チップによる手のひらサイズのパームトップ・システムから, 数千個のチップからなる超並列スーパーコンピュータまで, 様々なシステムでの実現が可能です。このアーキテクチャはまた, OpenVMS Alphaも含めて,複数のオペレーティング・システムをサポートします。

表 1-1は,Alphaアーキテクチャと VAXアーキテクチャの主な違いを示しています。

表 1-1  AlphaアーキテクチャとVAXアーキテクチャの比較

Alpha VAX

  • 64ビット・アドレス +

  • 64ビット処理

  • 命令

    • 単純

    • すべて同じ長さ(32ビット)

  • ロード/ストア・メモリ・アクセス

  • アラインされていないデータに対しては重大な性能低下

  • 多くのレジスタ

  • 命令は要求の順序と無関係に終了

  • 多段のパイプラインと分岐予測

  • 大きいページ・サイズ(ハードウェアに応じて8KB〜64KB)

  • 32ビット・アドレス

  • 32ビット処理

  • 命令

    • やや複雑

    • 可変長

  • 操作とメモリ・アクセスを1つの命令に組み合わせることが可能

  • アラインされていないデータに対して中程度の性能低下

  • 比較的数の少ないレジスタ

  • 命令は要求された順に終了

  • パイプラインは限定的に使用

  • 小さいページ・サイズ(512バイト)
+ 64ビット・アドレスについては, 『OpenVMS Alpha 64ビット・アドレッシングおよびVLM機能説明書』 を参照してください。

RISCの一般的な特性

Alphaアーキテクチャの特徴の一部は,新しいRISCアーキテクチャの典型的な 特徴です。次の特徴は特に重要です。

Alpha固有の特性

これまで説明したRISCの一般的な特性の他に,Alphaアーキテクチャは,移行した VAXアプリケーションをAlphaシステムで実行するのに使用される多くの機能を備えています。 Alphaアーキテクチャでは次の機能が提供されます。


1.2.1 ユーザ作成デバイス・ドライバ

ユーザ作成デバイス・ドライバとStep 2ドライバ・インタフェースと呼ぶ新しい インタフェースの正式なサポートは,OpenVMS AXPバージョン6.1から開始されました。 Step 2ドライバ・インタフェースはCプログラミング言語(およびMACROと BLISS)でユーザ作成デバイス・ドライバをサポートします。これは OpenVMS Alphaバージョン1.0とバージョン1.5で提供されていた一時的な Step 1ドライバ・インタフェースに代わるものです。既存の OpenVMS VAXデバイス・ドライバをAlphaシステム上で実行したい場合で, OpenVMS Alphaバージョン6.1に必要な変更を行っていない場合は, 『Creating an OpenVMS Alpha Device Driver from an OpenVMS VAX Device Driver』 を参照してください。

CでOpenVMS VAXデバイス・ドライバを作成する機能は,正式にはサポートされません。 たとえば,OpenVMS VAXでは内部のOpenVMS (lib)データ構造体に対して .hファイルを提供しません。 Step 2ドライバ・インタフェースの導入により,OpenVMS AlphaとOpenVMS VAXデバイス・ドライバの相違点が大きくなりました。VAX MACROまたはBLISS で作成されたデバイス・ドライバ・ソース・ファイルは,条件付きコンパイ ルとユーザ作成マクロを使用することにより,OpenVMS AlphaとOpenVMS VAX の間で共通に使用できます。

このアプローチが適切であるかどうかは,個々のドライバの性質に大きく左右されます。 (OpenVMSバージョン7.0では,64ビットのサポートにより, 相違点がさらに大きくなります。) OpenVMS Alphaの将来のバージョンでは,入出力 (I/O)サブシステムはデバイス・ドライバに影響を与えるような方向にさらに 進歩していく可能性があります。この結果,OpenVMS Alphaと OpenVMS VAXのデバイス・ドライバの相違点が大きくなり, 共通のドライバ・ソースを維持するのはますます複雑になります。 この理由から,長期的に見ると, 完全に共通なドライバ・ソース・ファイルを使用するアプローチは適切でないと考えられます。

個々のドライバに応じて,ドライバを共通モジュールとアーキテクチャ固有の モジュールに分割する方法が適している可能性があります。たとえば, ディスク圧縮を行うデバイス・ドライバを作成する場合, 圧縮アルゴリズムはアーキテクチャから独立したモジュールに簡単に分離できます。 異なる種類のオペレーティング・システム間でいくつかの共通モジュールを作成し, オペレーティング・システム固有のデータ構造体をこのような共通のモジュールから 分離することができます。たとえば,OpenVMS,Windows NT,Digital UNIXの間でこのようなアプローチを採用できます。

新しいOpenVMS Alphaのデバイス・ドライバを作成する方法の詳細については, 『Writing OpenVMS Alpha Device Drivers in C』を参照してください。


1.3 移行プロセス

VAXプログラムをAlphaシステムで実行するために変換するプロセスは, 次の段階に分類されます。

  1. 移行するコードを評価します。

  2. 移行計画を作成します。

  3. 移行環境を設定します。

  4. アプリケーションを移行します。

  5. 移行したアプリケーションをデバッグし,テストします。

  6. 移行したソフトウェアをソフトウェア・システムに統合します。
アプリケーションをOpenVMS Alphaに移行するのに役立つように,多くのツールと 弊社によるサービスが提供されます。これらのツールについては, 本書で実際のプロセスを説明するときに示します。


1.4 移行の手段

Alphaシステムで実行するためにプログラムを変換する方法としては,次の 2種類の方法があります。

これらの2種類の方法は,図 1-1に示すとおりです。 第2.2節では, 移行方式を選択するときに考慮しなければならない事柄を説明しています。

図 1-1 VAXアプリケーションをAlphaシステムに移行する方法 :(クリックで表示)

再コンパイルと再リンク

プログラムをOpenVMS VAXからOpenVMS Alphaに変換するための,もっとも効果的な方法は, Alphaコンパイラ(DEC CやDEC Fortranなど)を使用してソース・コードを再コンパイルし, その後,OpenVMSリンカで適切なスイッチとオプション・ファイルを使用して, 作成されたオブジェクト・ファイルと必要な他の共有可能なイメージを再リンクする方法です。 この方法では,Alphaシステムのスピードを完全に活用できる, ネイティブなAlphaイメージが作成されます。

トランスレーション

VAXシステムとAlphaシステムにはいくつかの相違点がありますが,VAXEnvironment Software Translator (VEST)を使用すれば,大部分のユーザ・モードの VAXイメージを,Alphaシステムでエラーなしに実行することができます。VESTは DECmigrate for OpenVMS Alphaの一部です。例外については, 第2.3節を参照してください。

この方法では,ソースを再コンパイルする場合より高いレベルで VAXとの互換性を維持できますが,トランスレートされたイメージは再コンパイルされた イメージほど高い性能を実現できないため,トランスレーションは, 再コンパイルが不可能な場合や実用的でない場合に, 代わりとなる安全な手段として使用してください。たとえば, 次の状況ではトランスレーションが適しています。

VESTはVAXバイナリ・イメージ・ファイルをネイティブな Alphaイメージにトランスレートします。このイメージは,Alphaシステム上の Translated Image Environment (TIE)のもとで実行されます(TIEは, OpenVMS Alphaでバンドル・ソフトウェアとして提供される共有可能イメージです)。 トランスレートされたVAXイメージは, エミュレータやインタプリタのもとで実行されるわけではなく(ただし, 一部の例外があります),元のVAXイメージで命令が実行する操作と同じ操作を実行する Alpha命令が,新しいAlphaイメージに盛り込まれるのです。

トランスレートされたイメージをAlphaシステムで実行する速度は,元のイメージを VAXシステムで実行する速度と同じくらいになります。しかし, トランスレートされたイメージは, Alphaアーキテクチャを完全に活用するための最適化コンパイラの恩恵を受けないため, 通常,ネイティブなAlphaイメージの速度と比較すると,約 25〜40%の速度でしか動作しません。このように性能が低下する主な理由は, データがアラインされていないためと,複雑な VAX命令が広範囲にわたって使用されているためです。

イメージのトランスレーションとVESTについての詳しい説明は, 第3.2.2.1項と 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。

ネイティブなAlphaイメージとトランスレートされたイメージの混在

1つのアプリケーションを構成するイメージで, 2種類の移行方式を混在させて使用できます。また,1つのアプリケーションを, 移行の1段階として部分的にトランスレートすることもできます。このようにすれば, 完全に再コンパイルする前に,アプリケーションをAlphaハードウェアで実行し, テストできます。1つのアプリケーション内のネイティブなAlphaイメージと, トランスレートされたVAXイメージの相互操作性についての詳しい説明は, 第2.7.2項を参照してください。


[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]