| 前へ | 次へ | 目次 | 索引 |
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 |
|---|---|
|
|
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』を参照してください。
1.3 移行プロセス
VAXプログラムをAlphaシステムで実行するために変換するプロセスは，次の段階に分類されます。
アプリケーションをOpenVMS Alphaに移行するのに役立つように，多くのツールと弊社によるサービスが提供されます。これらのツールについては，本書で実際のプロセスを説明するときに示します。
1.4 移行の手段
Alphaシステムで実行するためにプログラムを変換する方法としては，次の 2種類の方法があります。
この方法ではネイティブなAlphaイメージが作成されます。
この方法でもAlphaイメージが作成されますが，一部のルーチンはTIEのもとでエミュレートされます。
これらの2種類の方法は，図 1-1 に示すとおりです。第 2.2 節 では，移行方式を選択するときに考慮しなければならない事柄を説明しています。
図 1-1 VAXアプリケーションをAlphaシステムに移行する方法
プログラムをOpenVMS VAXからOpenVMS Alphaに変換するための，もっとも効果的な方法は，Alphaコンパイラ(DEC CやDEC Fortranなど)を使用してソース・コードを再コンパイルし，その後，OpenVMS リンカで適切なスイッチとオプション・ファイルを使用して，作成されたオブジェクト・ファイルと必要な他の共有可能なイメージを再リンクする方法です。この方法では，Alphaシステムのスピードを完全に活用できる，ネイティブなAlphaイメージが作成されます。
VAXシステムとAlphaシステムにはいくつかの相違点がありますが，VAX Environment 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 項 を参照してください。
| 前へ | 次へ | 目次 | 索引 |