この実装で定義された動作は、size(int)がプラットフォームに依存するか、コンパイラベンダーによって定義されるか、またはその両方を意味しますか?
原則として、コンパイラベンダーがその決定を下すことができます。実際には、コンパイラがシステムライブラリを直接呼び出すコードを出力する場合は、システムと同じ「ABI」(アプリケーションバイナリインターフェイス)に従う必要があります。特に、ABIはのサイズを指定しますint
。したがって、コンパイラベンダーは、ABIが言うサイズにすることを「決定」します。
複数のプラットフォームとアーキテクチャを対象とするコンパイラは、各プラットフォームの構成の一部として個別に決定を下します。各ターゲットは、「同じコンパイラ」と考えていても、異なるC実装を表します。
int
プログラムを実行するOSのサイズとは異なるサイズの準拠C実装を作成できます。人々がそうすることはめったになく、標準ライブラリはシステムコールを行うときに余分なフープを飛び越えなければならないでしょう。これはエミュレーターの一部として役立つ可能性がありますが、「プラットフォーム」はエミュレートされたプラットフォームであり、異なるサイズのintを持つホストプラットフォームではないと合理的に主張するかもしれません。
コードをコンパイルした後、異なるバージョンのプラットフォームで実行した場合でも、実装の依存関係は適用されますか?
sizeof(int)
はコンパイル時定数です。これは、コンパイラによって発行されたコードが特定の値をとる可能性があることを意味します。そのバイナリコードは、サイズの異なるプラットフォームの異なるバージョンで正しく実行できませんint
。
あるプラットフォームで実装定義のコードをコンパイルし、別のプラットフォームで実行すると、パフォーマンスが低下しますか?
それがまったく機能する場合、パフォーマンスが低下すると想定する特別な理由はありません。一般に、あるプラットフォーム向けのバイナリコードは別のプラットフォームでは機能しないため、通常はまったく機能しません(上記を参照)。プラットフォームが十分に類似していて機能する場合は、コンパイラーが1つのプラットフォームに対して行った最適化が、別のプラットフォームではそれほど適切な最適化ではない可能性があります。その場合、パフォーマンスが低下し、修正は、正しい(バージョンの)プラットフォームを対象とするコードを再コンパイルすることです。
これはARMで発生しますが、x86ではそれほど発生しません。過去のさまざまなチップは、本質的に同じ命令セットを提供していましたが、一部のチップの一部の命令は、他の命令と比較して大幅に異なるコストを持っています。命令Xが高速であると想定する最適化は、命令Xが低速である別のチップでの最適化としては不適切である可能性があります。ご想像のとおり、この種の違いは、チップメーカーをコンパイラベンダーにそれほど人気のあるものにするわけではなく、アセンブリプログラマーにもそれほど人気がありません。