|
アプリケーションバイナリインタフェースアプリケーションバイナリインタフェース（ABI, 英: Application Binary Interface）とは、アプリケーション（ユーザ）プログラムとシステム（オペレーティングシステムやライブラリ）との間の、バイナリレベルのインタフェースである。また、アプリケーション相互間や、それらの部品（プラグイン等）とのバイナリインタフェースもある。 ABIはアプリケーションプログラミングインタフェース (API) とは異なる。APIはソースコードとライブラリ間のインタフェースを定義したものであり、同じAPIをサポートしたシステム間では同じソースコードをコンパイルして利用できる。一方、ABIはオブジェクトコードレベルのインタフェースであり、互換ABIをサポートするシステム間では同じ実行ファイルを変更無しで動作させることができる。 概要ABIには、以下のような定義が含まれる。
Intel Binary Compatibility Standard (iBCS) のような完全なABIでは[1]、オペレーティングシステム (OS) が何であれ必要な共有ライブラリが存在するなどの前提条件が満たされていれば、そのABIをサポートしたシステム間でプログラム（実行ファイル）を全く修正せずに動作させることができる。 他のABIとして例えばC++の名前修飾[2]や例外の伝播[3]や呼出規約があるが、あくまでも同じプラットフォーム上のコンパイラ間のABIであり、プラットフォーム間の互換性までは要求されない。 EABIEABI (Embedded Application Binary Interface) とは、組み込みシステムのソフトウェアについてのファイルフォーマット、データ型、レジスタ使用法、スタックフレームの構成、関数の引数渡し方法などについての規約を意味する。 あるEABIをサポートするコンパイラで生成したオブジェクトコードは、同じEABIをサポートする別のコンパイラで生成したコードと互換性があり、コンパイラが異なっていても同じEABIに対応していればライブラリやオブジェクトコード間でリンク可能である。アセンブリ言語でコードを書く場合でもEABIに準拠するように書けば、他のコードとのリンクが保証される。 EABIと汎用OS向けABIとの主な違いは、アプリケーションのコードでも特権命令の使用が許されている点、ダイナミックリンクが要求されない点（完全に不可能とされている場合もある）、メモリを節約するためスタックフレームをなるべくコンパクトに構成している点が挙げられる[4]。 EABIが広く使われているCPUアーキテクチャとしては、PowerPC[5]、ARM[6]、MIPS[7]がある。 ABI共通化の試みとその成果Unix系OSでは、同じハードウェアプラットフォーム上で非互換な複数のOSが動作する。 例えばRISCチップにおいては以下のような例がある。 最も互換Unix系OSが多いのは、IA-32系であろう。それらOS間でABIを定義して相互にアプリケーションが動作できるようにしようという試みがいくつかあった。しかし、そのような計画が成功したことはない。Linuxにおいては、Linux Standard Base（LSB）が同様の試みを行っている（LSBはABI以外にも多くの規定を試みている）。 一方、採用ベンダ数が多く、複数のUnix系OSが乱立していたMIPS系においては、何度もABIの共通化を目指した試みがなされている。 例えば、1990年代中盤〜後半にかけてUNIXワークステーション / サーバにおいて、MIPS系CPUを採用したNEC(UX/4800)、Sony(NEWS)、住友電工（EWS4800などのNECからのOEM品とSUMIStation）、日本タンデムコンピュータ（MIPS系だったNonStopServer）によるOCMP (Open Computing Environment for MIPS Platform) が定義され、シェアの維持など一定の成果を挙げた。OCMPはMIPS-ABIの日本語対応の側面とAPバスの標準化による周辺デバイスの共通化の側面がある。 脚注
関連項目外部リンク
|