問題タブ [linux-x32-abi]

x32 と呼ばれる比較的新しい Linux ABIがあり、x86-64 プロセッサは 32 ビット モードで実行されるため、ポインタはまだ 32 ビットのみですが、64 ビット アーキテクチャ固有のレジスタは引き続き使用されます。そのため、通常の 32 ビットと同様に最大メモリ使用量は 4GB に制限されますが、ポインタが使用するキャッシュ スペースは 64 ビットよりも少なく、64 ビット演算を効率的に実行でき、より多くのレジスタにアクセスできます。 (16) バニラ 32 ビット (8) よりも。

ワークロードが 4 GB 以内にうまく収まると仮定すると、x32 のパフォーマンスが x86-64 よりも悪くなる可能性はありますか?

余分なメモリスペースが必要ない場合、何も失われないように思えます-常に同じパフォーマンス（すでにキャッシュに収まる場合）またはそれ以上（ポインタースペースの節約によりキャッシュにより多く収まる場合）を取得する必要があります。 . しかし、ページング/TLB などがあっても驚かないでしょう。私が知らない詳細。

32ビットのアプリケーションのパフォーマンスを向上させる必要があるため、パフォーマンスを向上させるために64ビットに移行することを考えました.しかし、x32abiについて知りました

以下に情報へのリンクがいくつかありますが、これがツールなのか、それとも何なのか知りたいだけです

それを使用する方法私はリンクと混同しています

https://sites.google.com/site/x32abi/ ここにリンクの説明を入力

http://en.wikipedia.org/wiki/X32_ABI

http://www.linuxplumbersconf.org/2011/ocw/sessions/531

新しい x32 ABI を使用してアプリケーションをコンパイルし、それを通常のカーネルで実行できますか? ランタイム C ライブラリはどうですか? コンパイル済みの x86/x86_64 ライブラリとの相互運用性はありますか?

X3232 ビット ポインターを使用するamd64/ CPU用の ABI です。x86_64これは、x86_64 のより大きなレジスタ セットと、32 ビット ポインタによるより小さなメモリおよびキャッシュ フットプリントを組み合わせることを目的としています。これにより、最大で約 40% の高速化が実現します。詳細と chroot 環境としての設定については、Stack Overflowの Difference between x86, x32, and x64 architecturesと Debian X32 Ports wiki ページを参照してください。

環境下の Debian メンテナからバグ レポートがあります。報告はadcq不正な指示です。インライン アセンブリはプリプロセッサ マクロに基づいてアクティブ化されるため、X32 を適切に検出していません (より正確には、現在までまったく検出していません)。

(私にとって) プリプロセッサ マクロの最も明白な選択肢は__X32__のようなものですが、それは提供されていません。Clang のパッチとDebian の提案に基づいて、__ILP32__使用できるようです。_ILP32しかし、それ以来、より標準的な答えが欲しいし、__code_model_small__面白そうにも見えます。(そして、コンパイラはサポートしていたが OS はサポートしていなかった SSE2 の問題を認識しています)。

Clang と GCC を使用するときに X32 ABI と環境を確実に検出するために使用できるプリプロセッサ マクロは何ですか?

明確にするために、この時点でコードを修正しようとしているわけではありません。完全な修復に使用できるマクロを知りたいだけです。

32 ビット組み込みプロセッサ用に記述された大規模なコードベースをコンパイルして、シミュレーション/単体テスト用に 64 ビット デスクトップ プロセッサで実行しようとしています。結果のオブジェクトを共有ライブラリにする必要があります。これは Windows の問題ではありません。このような dll (/DWIN32) をビルドでき、問題なく動作します。

Linux では、gcc とリンカーの両方に -m32 オプションを指定してコンパイルおよびリンクし、共有ライブラリを取得できます。問題は、このライブラリが (-m32 で指定したように) 32 ビット ライブラリであり、私の 64 ビット アーキテクチャでは動作しないことです。Python で、ライブラリをロードしようとします (ctypes.cdll.LoadLibrary() を使用)

-mx32 オプションを発見しました。ドキュメントによると、これはまさに私が望むものです:

-mx32 オプションは、int、long、およびポインター型を 32 ビットに設定し、x86-64 アーキテクチャー用のコードを生成します。

そのため、-mx32 をコンパイラとリンカーに渡し (-m32 オプションを置き換えます)、次の結果を取得します (出力を切り取りました)。

gcc 4.7 と gcc 4.8 で同じ結果が得られます。上記の出力は gcc 4.8 からのものです。

gcc-4.8-multilib と g++-4.8-multilib がインストールされています。

私のライブラリパスは次のとおりです。

.bashrc から、リンカーが機能するライブラリにのみバインドすることを読んだ後、絶望的に /4.8/ および /4.8/32/ を追加して、このように指定しました (以下)。

私が言及したように、これはWindows上でdllとしてすでに非常にうまく機能しています。何かが欠けているだけだと信じなければなりません。ポインターは 32 ビット、long は 32 ビットである必要があり、すべてが x86_64 で実行される必要があります。-mx32 は、まさにそれを行うと言っています (そうですか?)。

-m32 でコンパイルした後、オブジェクトの 1 つを確認します。

-mx32 でコンパイルした後、同じオブジェクトをチェックします。

私はこれについて間違った方法で進んでいますか？32 ビットの共有ライブラリを何らかの互換性レイヤーで引き続き使用できますか?

これらのリンク エラーに関する gcc 4.7 に対するバグ レポートを見ましたが、結論はあまり出ていませんでした。 このページには、gcc 4.8 が x32 の推奨される最小値であると記載されているため、インストールしました。それでも -- リンクできません。-m32 リンクは問題ありません。

OS X の Clang で X32 コードの一部についてバグ レポートを取得しました (エラーを以下に示します)。ユーザーは、Intel x86_64 システムで を使用してコードをコンパイルしようとしました-arch i386。X32 は 32 ビット整数、long、およびポインターです。

System V Application Binary Interface、AMD64 (LP64 および ILP32 プログラミング モデルを使用) (104 ページ) によると、有効な構成は、__ILP32__単独、または__ILP32__and (およびの代わりの__x86_64__ようなフレンド)のいずれかです。amd64__x86_64__

Intel386 の SYSTEM V APPLICATION BINARY INTERFACEも確認しましたが__ILP32__、友人については言及されていません。__ILP32__したがって、純粋な 32 ビット システムに存在するべきではないと思います。

質問に答えるには上記で十分だと思いますが、OS X システムで Clang を使用しています。OS X ABI Function Call Guideはそれについて議論しておらず、多くの場合 System V ガイドに従います。ただし、参照されている System V ガイドは X32 より前の 2003 年のものであるため、処理はありません。

__ILP32__私の質問は、__i386__有効な組み合わせまたは構成ですか?

完全を期すために、コードとコンパイラ エラーを次に示します。私はこの問題を解決しようとしていません。

ソースコード

BOOL_X32が環境で定義されている場合__ILP32__に定義されます。

コンパイラ エラー

X32 はほとんどが32 ビットです。ただし、アセンブリ言語を使用してスタックと対話する場合、64 ビットのレジスタと値をプッシュ/ポップする必要があります。

-arch i386最後に、x86_64 システムで使用する場合の Clang のプリプロセッサ マクロを次に示します。