多くのアプリケーションにとって,OpenVMS VAXからOpenVMS Alphaへの移行 (migration)は簡単です。アプリケーションがユーザ・モードでのみ実行され, 標準的な高級言語で作成されている場合には,ほとんどの場合, Alphaコンパイラを使用してそのアプリケーションを再コンパイルし, 再リンクすることにより,Alphaシステムで実行可能なバージョンを作成できます。 本書では,移行するアプリケーションを評価する方法, およびもっと複雑で特殊な場合の対処方法について説明します。
OpenVMS Alphaオペレーティング・システムは,OpenVMS VAXのユーザ,システム管理, およびプログラミングの環境とできるだけ互換性( compatibility) を維持するように設計されています。一般的なユーザとシステム管理者にとって, OpenVMS AlphaはOpenVMS VAXと同じインタフェースを備えています。 プログラマにとっての目標は,「再コンパイル,再リンク,実行」 という移行のモデルにできるだけ近づけることです。
OpenVMS VAXシステムで動作しているアプリケーションの場合, ほとんどの部分はOpenVMS Alphaシステムでも変更されません。
DIGITALコマンド言語(DCL)はOpenVMSに対する標準的なユーザ・インターフェイスであり, OpenVMS Alphaでも変更されません。OpenVMS VAXで使用できるすべてのコマンド, 修飾子,およびレキシカル関数はOpenVMS Alphaでも使用できます。
OpenVMS VAXの以前のバージョンを対象に作成されたコマンド・プロシージャは, OpenVMS Alphaシステムでもまったく変更せずに動作します。しかし, ビルド・プロシージャなどのある特定のコマンド・プロシージャは, 新しいコンパイラ修飾子やリンカ・スイッチに対応できるように 変更しなければならないことがあります。 リンカ・オプション・ファイルも変更が必要な場合があり, 特に共用可能イメージ( shareable image )の場合は変更が必要となります。
ウィンドウ・インタフェースであるDECwindows Motifは変更されません。
DECformsインターフェイスは変更されません。
2つの標準的なOpenVMSエディタであるEVEとEDTは変更されません。
1 | バージョン 7.0 では,OpenVMS Alpha は 64 ビット・アドレッシングをサポートするために, 多くのシステム・サービスと RTL ルーチンを提供します。これは VAX システムでは提供されません。したがって VAX から Alpha への移行の問題にはならないため,本書では説明しません。 |
ルーチン名 | 制約事項 |
---|---|
LIB$DECODE_FAULT | VAX命令をデコードする |
LIB$DEC_OVER | VAXプロセッサ・ステータス・ロングワード(PSL)のみに適用される |
LIB$ESTABLISH | Alphaシステムでは, 類似する機能をコンパイラがサポートする |
LIB$FIXUP_FLT | VAX PSLのみに適用される |
LIB$FLT_ UNDER | VAX PSLのみに適用される |
LIB$INT_OVER | VAX PSLのみに適用される |
LIB$REVERT | Alphaシステムではコンパイラがサポートする |
LIB$SIM_TRAP | VAXコードに適用される |
LIB$TPARSE | 動作ルーチンのインタフェースの変更が必要である。 LIB$TABLE_PARSEに置換されている |
これらのサービスとルーチンを呼び出すVAXイメージの大部分は,VEST (VAX Environment Software Translator)を使ってトランスレートし,OpenVMS AlphaのTIE (Translated Image Environment)のもとで実行すれば,正しく動作します。TIE についての詳しい説明は,第3.2.2.1項と 『DECmigrate for OpenVMS AXP Systems Translating Images』を参照してください。
レコード管理サービス(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アーキテクチャは強力で柔軟な命令を備えた,複合命令セット・コンピュータ (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アーキテクチャの主な違いを示しています。
Alpha | VAX |
---|---|
|
|
+ 64ビット・アドレスについては, 『OpenVMS Alpha 64ビット・アドレッシングおよびVLM機能説明書』 を参照してください。 |
Alphaアーキテクチャの特徴の一部は,新しいRISCアーキテクチャの典型的な 特徴です。次の特徴は特に重要です。
Alphaアーキテクチャではかなり単純な命令を使用しており,これらはすべて 32ビットの長さです。これらの共通の命令は1クロック・サイクルだけを必要とします。 このようにサイズが統一された単純な命令の採用により, 複数命令発行(mullti-instruction issue) や最適化された命令スケジューリングなどの方式を採用でき,その結果, きわめて高い性能を実現できます。
初期のAlphaプラットフォームは,1クロック・サイクルで2つの命令を出しました。 現在のシステム(EV5以上)では,1クロック・サイクルに4つの命令を出します。
Alphaアーキテクチャでは,32個の64ビット整数レジスタと,32個の 64ビット浮動小数点レジスタを定義しています。大部分のデータ操作は,レジスタ間で実行されます。 操作の前に,オペランドがメモリからレジスタにロードされます。操作が終了した後, 結果はレジスタからメモリにストア(格納)されます。
このように操作をレジスタ・オペランドに制限すれば, 単純で統一された命令セットを使用できます。さらに, メモリ・アクセスを算術演算から分離することにより,完全なパイプライン, 命令スケジューリング,および並列操作ユニットを実現できるシステムとして, 大幅に性能を向上できます。
Alphaアーキテクチャではマイクロコードを使用しないため, Alphaプロセッサはマシン命令を実行するために,ランダム・アクセス・メモリ (RAM)からマイクロコード命令をフェッチするのに必要な時間を削減できます。
Alphaアーキテクチャでは,命令が発行された順番に完了することは保証されません。 その結果として,算術演算例外や浮動小数点例外は, 最適化された命令列を乱さないように,少し時間をおいて報告されます。
これまで説明したRISCの一般的な特性の他に,Alphaアーキテクチャは,移行した VAXアプリケーションをAlphaシステムで実行するのに使用される多くの機能を備えています。 Alphaアーキテクチャでは次の機能が提供されます。
Alphaアーキテクチャは特定のオペレーティング・システムにだけ対応するわけではありません。 異なるオペレーティング・システムに対応できるように, 特権アーキテクチャ・ライブラリ・コード(PALcode)を作成できます。
さらに,CやMACRO-32コンパイラなどのように,特定のOpenVMS Alphaコンパイラは PALcode組み込み関数を提供しており,Alpha命令セットで提供される命令を補足します。 たとえば,MACRO-32コンパイラは,Alphaに対応する命令のない VAX命令をエミュレートする組み込み関数を提供します。
PALcodeを使用すると,内部ハードウェア・レジスタと物理メモリにアクセスします。 PALcodeは物理メモリと仮想メモリの直接的な対応関係を提供できます。 PALcodeの詳細については,『Alpha Architecture Reference Manual』を参照してください。
ユーザ作成デバイス・ドライバと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』を参照してください。
VAXプログラムをAlphaシステムで実行するために変換するプロセスは, 次の段階に分類されます。
Alphaシステムで実行するためにプログラムを変換する方法としては,次の 2種類の方法があります。
この方法ではネイティブなAlphaイメージが作成されます。
この方法でもAlphaイメージが作成されますが,一部のルーチンは TIEのもとでエミュレートされます。
プログラムを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との互換性を維持できますが,トランスレートされたイメージは再コンパイルされた イメージほど高い性能を実現できないため,トランスレーションは, 再コンパイルが不可能な場合や実用的でない場合に, 代わりとなる安全な手段として使用してください。たとえば, 次の状況ではトランスレーションが適しています。
トランスレートされたイメージを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項を参照してください。