

アプリケーションバイナリインターフェース(ABI)とは、ソフトウェアによって公開されるインターフェースであり、プロセス内マシンコードへのアクセス用に定義されています。多くの場合、公開するソフトウェアはライブラリであり、利用する側はプログラムです。
ABIは比較的低い抽象度レベルにあります。インターフェースの互換性は、ターゲットハードウェアとソフトウェアビルドツールチェーンに依存します。一方、アプリケーションプログラミングインターフェース(API)は、ソースコードへのアクセスを定義します。ソースコードは比較的高レベルで、ハードウェアに依存せず、人間が読みやすい形式です。APIはコンパイル前のソースコードレベルでインターフェースを定義するのに対し、ABIはコンパイル済みコードへのインターフェースを定義します。
APIの互換性は、一般的にシステム設計やツールチェーンにおいて重要な考慮事項です。しかし、プログラマーは、複数の言語でプログラムを作成する場合や、同じ言語に対して複数のコンパイラを使用する場合に、 ABIを直接扱う必要が生じる場合があります。
完全なABIがあれば、そのABIをサポートするプログラムは、そのABIを提供する複数のオペレーティングシステム上で、変更を加えることなく実行できます。ターゲットシステムは、必要なライブラリ(ABIを実装するもの)をすべて提供する必要があり、その他にも前提条件がある場合があります。
ABIが対象とするインターフェースの側面には以下が含まれます。
ABIには、Intelバイナリ互換性標準(iBCS)[ 3 ]や、さまざまな命令セット用のSystem Vリリース4 ABIが含まれます。
組み込みオペレーティングシステムで使用される組み込みABI(EABI)は、組み込みソフトウェアプログラムのファイル形式、データ型、レジスタの使用方法、スタックフレームの構成、関数パラメータの受け渡しなどの側面を規定します。
EABIをサポートする各コンパイラおよびアセンブラは、他の同様のコンパイラおよびアセンブラによって生成されたコードと互換性のあるオブジェクトコードを生成します。これにより、開発者はあるコンパイラによって生成されたライブラリと、別のコンパイラによって生成されたオブジェクトコードをリンクさせることができます。
通常、EABI は、ターゲット組み込みシステムの限られたリソースでのパフォーマンスを最適化するように設計されています。そのため、EABI では、デスクトップオペレーティングシステムでよく見られるカーネルとユーザー空間間の抽象化を省略する場合があります。たとえば、動的リンクを回避して実行可能ファイルを小さくし、ロードを高速化したり、固定レジスタの使用によりスタックとカーネル呼び出しをよりコンパクトにしたり、特権モードでアプリケーションを実行したりすることで、デバイス ドライバを呼び出すという間接的な操作なしにカスタム ハードウェア操作に直接アクセスしたりすることができます。[ 4 ] EABI の選択はパフォーマンスに影響を与える可能性があります。[ 5 ] [ 6 ]
広く使われている EABI にはPowerPC [ 4 ] 、Arm [ 7 ]、MIPS EABI [ 8 ]などがあります。Cライブラリなどの特定のソフトウェア実装では、より具体的な ABI を形成するために追加の制限が課される場合があります。1 つの例として GNU OABI と ARM 用 EABI があり、どちらも ARM EABI のサブセットです。[ 9 ]
厳密に言えば、旧ARM ABIと新ARM ABIはどちらもARM EABI仕様のサブセットですが、日常的な使用では、ここで説明する新しいものを「EABI」、古いものを「OABI」または「old-ABI」と呼びます。