64 ビット環境のほとんどの新機能は、一般の 32 ビットインタフェースを拡張したものですが、一部の新機能は 64 ビット環境に固有の機能です。
64 ビットアプリケーションは、ELF64 実行可能およびリンク形式 (Executable and Linking Format) によって作成されます。この形式によって、大規模なアプリケーションおよびアドレス空間を完全に記述することができます。
『SPARC Compliance Definition, Version 2.4』には、SPARC V9 ABI の詳細が含まれます。このマニュアルでは 32 ビットの SPARC V8 ABI と 64 ビット SPARC V9 ABI について説明しています。この文書は、SPARC International の www.sparc.com から入手できます。
次に SPARC V9 ABI の機能を示します。
すべての 64 ビット SPARC 命令と 64 ビット幅のレジスタを最大限有効に活用できます。関連した新しい命令の多くは、既存の V8 命令セットの拡張版です。『SPARC Architecture Manual, Version 9』を参照してください。
基本的な呼び出し規約は同じです。呼び出し側の最初の 6 つの引数は、出力レジスタの %o0-%o5 に格納されます。SPARC V9 ABI では、関数呼び出しの動作を「軽く」するために、従来より大きいレジスタファイル上で、従来どおりレジスタウィンドウを使用しています。結果は %o0 に格納されます。すべてのレジスタは 64 ビット量として扱われるので、64 ビットの値は、一組のレジスタにではなく 1 つのレジスタに渡されます。
スタックの配置が変わりました。基本セルサイズが 32 ビットから 64 ビットに拡大されました。さまざまな「隠れた」パラメータ語が削除されました。戻りアドレスは %o7 + 8 のままです。
%o6 は従来どおりスタックポインタレジスタ %sp として参照され、%i6 は フレームポインタレジスタ %fp として参照されます。ただし、%sp レジスタと %fp レジスタは、スタックバイアスと呼ばれる定数だけ、スタックの実際のメモリー位置からオフセットされます。スタックバイアスのサイズは 2047 ビットです。
命令長は従来どおり 32 ビットです。したがって、アドレス定数を生成するには通常以上の命令が必要となります。CALL 命令は、アドレス空間内への分岐には使用できなくなりました。CALL 命令は、%pc から + 2G バイトまたは - 2G バイト以内までしか到達できないからです。
整数乗算機能および除算機能は、現在完全にハードウェアで実装されています。
データ構造体を渡す方法と戻す方法は異なります。小さいデータ構造体と浮動小数点引数のいくつかは、現在はレジスタに直接渡されます。
ユーザートラップ機能により、ユーザートラップハンドラが (シグナルを発信する代わりに) 非特権コードからのトラップのいくつかを取り扱うことができるようになりました。
すべてのデータ型はそれぞれのサイズに境界整列されるようになりました。
基本派生型の多くは、従来よりサイズが大きくなりました。したがって、多くのシステムコールインタフェースのデータ構造体のサイズも変わっています。
2 つの異なるライブラリセット (32 ビット SPARC アプリケーション用のライブラリと 64 ビット SPARC アプリケーション用のライブラリ) が、システムに存在します。
開発者にとって重要な SPARC V9 ABI の特徴の 1 つに、スタックバイアスがあります。64 ビットの SPARC プログラムでは、2047 バイトのスタックバイアスを、フレームポインタとスタックポインタの両方に追加して、スタックフレームの実際のデータを取得する必要があります。 次の図を参照してください。
スタックバイアスについては、SPARC V9 ABI を参照してください。
64 ビットアプリケーションのアドレス空間の配置は、32 ビットアプリケーションのアドレス空間の配置に密接に関係しています。ただし、開始アドレスとアドレス指定の制限値は大きく変更されています。SPARC V8 と同様に、SPARC V9 のスタックはアドレス空間の上端から下方に広がり、ヒープは下端から上方にデータセグメントを拡張します。
以下の図は、64 ビットアプリケーションに与えられたデフォルトのアドレス空間を示します。「予約済み」となっているアドレス空間の領域は、アプリケーションからマップすることはできません。これらの制約は、将来のシステムで緩和される可能性があります。
上図の実際のアドレスは、ある特定のマシンの特定の実装を示しており、説明のためにだけ掲載してあります。
デフォルトでは、64 ビットプログラムは開始アドレス 0x10000000 にリンクされます。プログラム全体は、テキスト、データ、ヒープ、スタック、および共用ライブラリを含めて、4G バイトを超えるアドレスに存在します。これは、64 ビットプログラムが正しいことを検証するのに役立ちます。たとえばプログラムが関連するポインタの上位 32 ビットを切り落としてしまうと、そのプログラムはアドレス空間の下方の 4G バイトの部分へアクセスしようとして失敗します。
64 ビットプログラムは 4G バイトを超える位置でリンクされますが、リンカーのマップファイルを使用し、コンパイラまたはリンカーに -M オプションを指定して、4G バイト未満の位置でリンクすることも可能です。4G バイト未満で 64 ビット SPARC プログラムをリンクするためのリンカーマップファイルは、/usr/lib/ld/sparcv9/map.below4G にあります。
詳細は、ld(1) のリンカーのマニュアルページを参照してください。
コンパイラには、性能の向上や、64 ビット SPARC プログラムでのコードサイズを小さくするなど、さまざまな目的に合わせた各種のコードモデルがあります。コードモデルは以下の要素で決定します。
位置決め方法 (絶対コード、あるいは位置に依存しないコード)
コードサイズ (2G バイト未満)
位置 (下部、中央、アドレス空間内の任意位置)
外部オブジェクト参照モデル (スモールまたはラージ)
次の表は、64 ビット SPARC プログラムで使用できる各種コードモデルを示したものです。
表 6–1 コードモデルの説明
コードモデル |
位置決め方法 |
コードサイズ |
位置 |
外部オブジェクト参照モデル |
---|---|---|---|---|
abs32 |
絶対 |
2G バイト未満 |
下部 (アドレス空間の下位 32 ビット) |
なし |
abs44 |
絶対 |
2G バイト未満 |
中央 (アドレス空間の下位 44 ビット) |
なし |
abs64 |
絶対 |
2G バイト未満 |
任意 |
なし |
pic |
位置に依存しないコード |
2G バイト未満 |
任意 |
スモール (1024 以下の外部オブジェクト) |
pic |
位置に依存しないコード |
2G バイト未満 |
任意 |
ラージ (2**29 以下の外部オブジェクト) |
スモールコードモデルを使用すると、命令シーケンスを短くできる場合があります。絶対コード内で静的データ参照を行うのに必要な命令の数は、abs32 コードモデルの場合が最も少なく、abs64 が最も多く、abs44 がその中間になります。同様に、pic コードモデルは、PIC コードモデルよりも少ない命令で静的データ参照を行います。その結果、コードモデルが小さいほどコードサイズも小さくなり、ラージコードモデルのような、より完全な機能性を必要としないプログラムの性能が向上します。
使用するコードモデルを指定するには、-xcode=<model> コンパイラオプションを使用する必要があります。現在、コンパイラは 64 ビットオブジェクトに対し、デフォルトで abs64 モデルを使用します。コードは、abs44 コードモデルの使用により最適化できます。より少ない命令を使用して、現在の UltraSPARC プラットフォームがサポートする 44 ビットのアドレス空間を利用できます。
コードモデルについては、SPARC V9 ABI およびコンパイラのマニュアルを参照してください。
abs32 コードモデルでコンパイルしたプログラムは、-M /usr/lib/ld/sparcv9/map.below4G オプションを使用して、4G バイトよりも下方にリンクする必要があります。