クロスコンパイラ

クロスコンパイラとは、コンパイラが動作しているプラ​​ットフォームとは異なるプラットフォーム向けに実行可能なコードを作成できるコンパイラです。例えば、PCで動作し、 Androidデバイスで動作するコードを生成するコンパイラはクロスコンパイラです。

クロスコンパイラは、1つの開発ホストから複数のプラットフォーム向けのコードをコンパイルするのに便利です。例えば、コンピューティングリソースが限られている組み込みシステムなどでは、ターゲットプラットフォーム上で直接コンパイルすることが不可能な場合があります。

クロスコンパイラは、ソースツーソースコンパイラとは異なります。クロスコンパイラはクロスプラットフォームのソフトウェアで機械語を生成するためのもので、ソースツーソースコンパイラはテキストコードで1つのコーディング言語から別のコーディング言語に変換します。どちらもプログラミングツールです。

使用

クロスコンパイラの基本的な用途は、ビルド環境とターゲット環境を分離することです。これはいくつかの状況で役立ちます。

  • 組み込みコンピュータは、デバイスのリソースが非常に限られている場合に使用されます。例えば、電子レンジには、キーパッドとドアセンサーの読み取り、デジタルディスプレイとスピーカーへの出力、そして電子レンジによる調理制御を行うための極めて小型のコンピュータが搭載されています。このコンピュータは、通常、コンパイラ、ファイルシステム、開発環境を実行するには十分な性能を備えていません。
  • 複数のマシン向けにコンパイルする。例えば、企業では、あるオペレーティングシステムの複数の異なるバージョンや、複数の異なるオペレーティングシステムをサポートしたい場合があります。クロスコンパイラを使用することで、単一のビルド環境を構築し、それぞれのターゲット向けにコンパイルすることができます。
  • サーバーファームでのコンパイル。複数のマシン向けのコンパイルと同様に、多くのコンパイル操作を伴う複雑なビルドは、基盤となるハードウェアや実行中のオペレーティングシステムのバージョンに関係なく、空いているマシンであればどこでも実行できます。
  • 新しいプラットフォームへのブートストラップ。新しいプラットフォーム向け、あるいは将来のプラットフォームのエミュレータ向けのソフトウェアを開発する場合、クロスコンパイラを使用してオペレーティングシステムやネイティブコンパイラなどの必要なツールをコンパイルします。
  • 現在のプラットフォームで実行されるクロスコンパイラ( Windows XPで実行される Aztec C の MS-DOS 6502クロス コンパイラなど) を使用する愛好家が、Commodore 64 や Apple II などの現在は廃止された古いプラットフォームのエミュレータ用にネイティブ コードをコンパイルします。

仮想マシン（JavaのJVMなど）の使用は、クロスコンパイラが開発された理由のいくつかを解決します。仮想マシンパラダイムにより、同じコンパイラ出力を複数のターゲットシステムで使用できますが、仮想マシンは速度が遅い場合が多く、コンパイルされたプログラムはその仮想マシンを搭載したコンピュータでしか実行できないため、必ずしも理想的とは言えません。

通常、ハードウェア アーキテクチャは異なります (例: x86コンピューターでMIPS アーキテクチャ向けのプログラムをコーディングする場合)。ただし、LinuxでFreeBSDプログラムをコンパイルする場合のようにオペレーティング システム環境のみが異なる場合や、 glibcホストでuClibcを使用してプログラムをコンパイルする場合のようにシステム ライブラリのみが異なる場合でも、クロス コンパイルは使用できます。

カナダ十字

カナディアンクロスとは、元のマシンがターゲットマシンよりもはるかに低速であったり、不便であったりする場合に、他のマシン用のクロスコンパイラを構築するための手法です。3台のマシンA、B、Cがあり、マシンA（例：IA-32プロセッサでWindows XPを実行）を使って、マシンB（例： x86-64プロセッサでmacOSを実行）で動作するクロスコンパイラを構築し、マシンC（例： ARMプロセッサでAndroidを実行）用の実行ファイルを作成します。この例の実用的な利点は、マシンAは低速ですが独自のコンパイラを備えているのに対し、マシンBは高速ですがコンパイラが全く存在せず、マシンCはコンパイルに使用するには実用的ではないほど低速であることです。

この例のように、GCCでCanadian Crossを使用する場合、4つのコンパイラが関与する可能性がある。

  • マシンA（1）用の独自のネイティブコンパイラ（例えば、Microsoft Visual Studioのコンパイラ）を使用して、マシンA（2）用のgccネイティブコンパイラを構築します。
  • マシンAのgccネイティブコンパイラ（2）は、マシンAからマシンB（3）へのgccクロスコンパイラを構築するために使用されます。
  • マシンAからマシンBへのgccクロスコンパイラ（3）は、マシンBからマシンCへのgccクロスコンパイラ（4）を構築するために使用されます。

カナダ十字章の例、スキーム

最終結果のクロスコンパイラ（4）はビルドマシンAでは実行できませんが、代わりにマシンBで実行され、アプリケーションを実行可能コードにコンパイルし、その後マシンCにコピーされてマシンCで実行されます。

たとえば、NetBSD はというPOSIX Unix シェルスクリプトを提供しておりbuild.sh、これは最初にホストのコンパイラを使用して独自のツールチェーンを構築します。次に、これはシステム全体の構築に使用されるクロス コンパイラを構築するために使用されます。

カナディアン・クロスという用語が生まれたのは、これらの問題が議論されていた当時、カナダには3つの全国政党があったためである。[ 1 ]

初期のクロスコンパイラのタイムライン

GCCとクロスコンパイル

フリーソフトウェアのコンパイラコレクションであるGCCは、クロスコンパイル用にセットアップできます。多くのプラットフォームと言語をサポートしています。

GCCでは、対象プラットフォームごとにbinutilsのコンパイル済みコピーが利用可能である必要があります。特に重要なのはGNUアセンブラです。そのため、まずconfigureスクリプト--target=some-targetにスイッチを送信してbinutilsを正しくコンパイルする必要があります。GCCも同じオプションで設定する必要があります。binutilsが生成するツールがパスで利用可能であれば、 GCCを正常に実行できます。これは、以下のコマンドで実行できます（UNIX系オペレーティングシステムでbashを使用している場合）。 --target

PATH=/path/to/binutils/bin:${PATH} を作る

GCCをクロスコンパイルするには、ターゲットプラットフォームのC標準ライブラリの一部がホストプラットフォームで利用可能である必要があります。プログラマーはCライブラリ全体をコンパイルすることもできますが、この選択は信頼性に欠ける可能性があります。代替案としては、 Cソースコードのコンパイルに必要な最小限のコンポーネントのみを含む小さなCライブラリであるnewlibを使用する方法があります。

GNU Autotoolsパッケージ (つまりautoconf、automake、libtool ) は、ビルド プラットフォーム、ホスト プラットフォーム、ターゲット プラットフォームという概念を使用します。ビルド プラットフォームは、コンパイラが実際にコンパイルされる場所です。ほとんどの場合、 build は未定義のままにしておく必要があります (デフォルトで host になります)。ホスト プラットフォームは、出力が別のコンパイラであるかどうかに関係なく、コンパイラからの出力成果物が実行される場所です。ターゲット プラットフォームは、クロスコンパイラをクロスコンパイルするときに使用され、パッケージが生成するオブジェクト コードの種類を表します。それ以外の場合、ターゲット プラットフォームの設定は無関係です。[ 3 ] たとえば、Dreamcastで実行されるビデオ ゲームをクロスコンパイルする場合を考えてみましょう。ゲームがコンパイルされるマシンがビルド プラットフォームであり、Dreamcast がホスト プラットフォームです。 hostとtargetという名前は、使用されているコンパイラに関連し、sonとgrandsonのようにシフトされます。[ 4 ]

組み込み Linux 開発者によく使われるもう 1 つの方法は、GCC コンパイラとScratchboxやScratchbox 2、あるいはPRootなどの特殊なサンドボックスを組み合わせることです。これらのツールは「chroot された」サンドボックスを作成し、プログラマーは追加のパスを設定することなく、必要なツール、libc、ライブラリを構築できます。ランタイムを「欺く」機能も提供されており、意図したターゲット CPU (ARM アーキテクチャなど) で実際に実行されていると「信じさせる」ことで、設定スクリプトなどをエラーなく実行できます。Scratchbox は「非 chroot された」方法に比べて動作が遅く、ホスト上にあるほとんどのツールは Scratchbox に移動して初めて機能します。

Manx Aztec C クロスコンパイラ

ニュージャージー州シュルーズベリーのManx Software Systems は、1980 年代初頭から、 IBM PC 互換機やMac を含むさまざまなプラットフォーム向けのプロの開発者を対象としたC コンパイラを製造してきました。

マン島のAztec Cプログラミング言語は、 MS-DOS、Apple II、DOS 3.3、ProDOS、コモドール64、Mac 68k [ 5 ]、Amigaなど、さまざまなプラットフォームで利用できました。

1980年代から1990年代にかけてManx Software Systemsが消滅するまで、Aztec C [ 6 ]のMS-DOS版は、ネイティブモードコンパイラとして、またコモドール64 [ 7 ]やApple II [ 8 ]など、異なるプロセッサを搭載した他のプラットフォーム向けのクロスコンパイラとして提供されていました。Aztec Cのインターネットディストリビューションは現在も存在し、MS-DOSベースのクロスコンパイラも含まれています。これらは現在も使用されています。

Manx社のネイティブモード8086 MS-DOSコンパイラであるAztec C86もクロスコンパイラでした。Commodore 64やApple II用のAztec C65 6502クロスコンパイラのように異なるプロセッサ向けのコードをコンパイルすることはできませんでしたが、16ビット8086ファミリプロセッサ向けの当時のレガシーオペレーティングシステム用のバイナリ実行ファイルを生成することができました。

IBM PCが初めて発売された当時は、CP/M-86とPC DOSの2つのオペレーティングシステムが選択可能でした。Aztec C86には、両方のIBM PCオペレーティングシステム用のコードを生成するためのリンクライブラリが付属していました。1980年代を通して、Aztec C86の後継バージョン（3.xx、4.xx、5.xx）では、 MS-DOSの「暫定」バージョン1と2のサポートが追加されました[ 9 ]。これらのバージョンは、Aztec C86が終焉までターゲットとしていた「ベースライン」のMS-DOSバージョン3以降よりも堅牢性に欠けていました。

最後に、Aztec C86はC言語開発者にROM書き込み可能な「HEX」コードの作成機能を提供しました。このコードはROMバーナーを使って8086ベースのプロセッサに直接転送できました。今日では準仮想化はより一般的かもしれませんが、デバイスドライバの開発が個々のアプリケーションごとにアプリケーションプログラマによって行われることが多く、新しいデバイスが家内工業のようなものだった当時は、低レベルのROMコードを作成するという慣行が一人当たりの負担としてより一般的でした。アプリケーションプログラマがメーカーのサポートなしにハードウェアと直接インターフェースすることは珍しくありませんでした。この慣行は、今日の組み込みシステム開発に似ています。

Aztec-Cの主要な開発者は、トーマス・フェンウィックとジェームズ・グッドナウ2世の2人でした。フェンウィックは後に、Microsoft Windows CEカーネル、当時はNK（「New Kernel」の意）と呼ばれていたカーネルの作者として有名になりました。[ 10 ]

Microsoft C クロスコンパイラ

初期の歴史 – 1980年代

Microsoft C (MSC) は他のコンパイラよりも歴史が浅く[ 11 ]、1980年代に遡ります。最初のMicrosoft CコンパイラはLattice Cを開発した会社によって開発され、Microsoftによって自社ブランドとしてリブランドされましたが、MSC 4がリリースされ、これがMicrosoftが独自に開発した最初のバージョンとなりました[ 12 ] 。

1987年、多くの開発者がMicrosoft Cへの移行を開始し、Microsoft Windowsの開発を通して現在に至るまで、さらに多くの開発者がそれに続きました。Clipper、そして後にClarionといった製品が登場し、クロスランゲージ技術を用いてデータベースアプリケーション開発を容易にし、プログラムの一部をMicrosoft Cでコンパイルできるようにしました。

Borland C (カリフォルニアの会社) は、Microsoft が最初の C 製品をリリースする何年も前から購入可能でした。

1987

Cプログラムは長らく、アセンブリ言語で書かれたモジュールとリンクされてきました。ほとんどのCコンパイラ（現在のコンパイラも含む）は、アセンブリ言語パス（効率性を高めるために調整し、アセンブル後にプログラムの残りの部分とリンクできるもの）を提供しています。

Aztec-Cのようなコンパイラは、すべてのコードを別個のパスでアセンブリ言語に変換し、さらに別個のパスでコードをアセンブルすることで、非常に効率的でコードサイズが小さいことで知られていましたが、1987年までにMicrosoft Cに組み込まれたオプティマイザは非常に優れたものとなり、書き換えの対象となるのはプログラムの「ミッションクリティカル」な部分のみとなりました。実際、C言語プログラミングは「最低レベル」言語としての地位を奪い、プログラミングは多分野にわたる成長産業となり、プロジェクトは大規模化しました。プログラマーはユーザーインターフェイスやデータベースインターフェイスを高水準言語で記述するようになり、今日まで続くクロスランゲージ開発の必要性が生まれました。

1987年、マイクロソフトはMSC 5.1をリリースし、MS-DOS用のクロスランゲージ開発環境を提供した。アセンブリ言語（MASM）で書かれた16ビットバイナリオブジェクトコードと、マイクロソフトの他の言語（QuickBASIC、Pascal、Fortranなど）を1つのプログラムにリンクすることができ、このプロセスは「混合言語プログラミング」、現在では「言語間呼び出し」と呼ばれている。[ 13 ]この混合言語でBASICを使用する場合、ガベージコレクションに必要なBASICをコンパイルする内部ランタイムシステムや、MS-DOSのQBasicのようなBASICインタープリターをシミュレートするその他の管理操作をサポートするために、メインプログラムはBASICで記述する必要があった。

特にCコードの呼び出し規約では、パラメータをスタックに「逆順」で渡し、値をプロセッサレジスタではなくスタックに返すというものでした。すべての言語を連携させるためのプログラミング規則は他にもありましたが、この規則はWindows 16ビット版および32ビット版を通して継続された言語間開発やOS/2向けプログラムの開発を通じて受け継がれ、今日まで続いています。これはPascal呼び出し規約として知られています。

当時、Microsoft C が利用されていたもう一つのクロスコンパイルは、Symbol Technologies PDT3100（在庫管理に使用）のようなハンドヘルドデバイスを必要とする小売アプリケーションでした。このデバイスは、 8088ベースのバーコードリーダーを対象としたリンクライブラリを提供していました。アプリケーションはホストコンピュータで構築され、その後、シリアルケーブル経由でハンドヘルドデバイスに転送され、そこで実行されました。これは、Symbolを買収したMotorolaなどの企業が、 Windows Mobileを使用して現在同じ市場で行っていることと似ています。

1990年代初頭

1990 年代を通して、MSC 6 (最初のANSI C準拠コンパイラ) 以降、Microsoft は C コンパイラを新興の Windows 市場に再び焦点を当てるようになり、OS/2とGUIプログラムの開発にも焦点を当てるようになりました。MS-DOS 側では MSC 6 を通じて言語の混合互換性が維持されましたが、 Microsoft Windows 3.0 と 3.1 のAPI はMSC 6 で書かれていました。MSC 6 は 32 ビット アセンブリのサポートと、Windows XPの基礎となる新興のWindows for WorkgroupsとWindows NTのサポートも提供するように拡張されました。サンクと呼ばれるプログラミング手法が導入され、モノリシックな16 ビット MS-DOS アプリケーションで好まれていた静的バインディングではなく、ランタイム バインディング (動的リンク)を活用する 16 ビット プログラムと 32 ビット プログラム間の受け渡しが可能になりました。静的バインディングは、一部のネイティブ コード開発者によって依然として好まれていますが、一般的には、機能成熟度モデル(CMM)などの新しいベスト プラクティスに必要なレベルのコード再利用は提供されません。

MS-DOS のサポートは、Microsoft の最初の C++ コンパイラである MSC 7 のリリースでも引き続き提供されました。MSC 7 は、C プログラミング言語および MS-DOS との下位互換性があり、16 ビットと 32 ビットの両方のコード生成をサポートしていました。

Aztec C86が残した役割をMSCが引き継ぎました。Cコンパイラの市場シェアは、最新かつ最高のWindows機能を活用し、CとC++を単一のバンドルで提供し、既に10年前のMS-DOSシステムもサポートするクロスコンパイラへと移行し、Aztec Cのようなコンパイラを開発していた小規模企業はもはや競争に打ち勝つことができず、組み込みシステムなどのニッチ市場に進出するか、姿を消すかのどちらかでした。

MS-DOS および 16 ビット コード生成のサポートは、Microsoft C++ および Microsoft Application Studio 1.5 (現在 Microsoft が提供するクロス開発環境であるMicrosoft Visual Studioの前身) にバンドルされた MSC 8.00c まで継続されました。

1990年代後半

MSC 12 は Microsoft Visual Studio 6 とともにリリースされ、MS-DOS 16 ビットバイナリのサポートは廃止され、代わりに 32 ビットコンソールアプリケーションのサポートが提供されるようになりました。ただし、Windows 95およびWindows 98 のコード生成とWindows NTのサポートは提供されました。Microsoft Windows を実行する他のプロセッサ用のリンクライブラリも提供されており、この慣行は Microsoft によって今日まで続けられています。

MSC 13 はVisual Studio 2003とともにリリースされ、 MSC 14 はVisual Studio 2005とともにリリースされました。どちらも Windows 95 などの古いシステム用のコードを生成しますが、モバイル マーケットやARM アーキテクチャを含むいくつかのターゲット プラットフォーム用のコードも生成します。

.NET 以降

2001年、Microsoftは共通言語ランタイム（CLR）を開発しました。これはVisual Studio IDEの.NET Frameworkコンパイラの中核を成すものです。オペレーティングシステム上のこのレイヤーはAPIに組み込まれており、Windowsオペレーティングシステムを実行するプラットフォーム間でコンパイルされた開発言語の混在を可能にします。

.NET Framework ランタイムと CLR は、ターゲットコンピュータ上のプロセッサとデバイス向けのコアルーチンへのマッピングレイヤーを提供します。Visual Studio のコマンドライン C コンパイラは、さまざまなプロセッサ向けのネイティブコードをコンパイルし、コアルーチン自体のビルドにも使用できます。

ARM アーキテクチャ上のWindows Mobileなどのターゲット プラットフォーム向けの Microsoft .NET アプリケーションは、さまざまなプロセッサを搭載した Windows マシンでクロスコンパイルされます。また、Microsoft では、昔のクロス コンパイラや他のプラットフォームのクロス コンパイラとは異なり、構成をほとんど必要としないエミュレーターやリモート展開環境も提供しています。

Monoなどのランタイム ライブラリは、クロスコンパイルされた .NET プログラムにLinuxなどの他のオペレーティング システムとの互換性を提供します。

Qtやその前身であるXVTなどのライブラリは、Windows版のビルドにはMicrosoft C言語を使用しながら、他のプラットフォームとのソースコードレベルのクロス開発機能を提供します。MinGWなどのコンパイラも、ソフトウェア開発における非Windows側のUnixとの互換性がより高く、開発者が使い慣れたビルド環境を用いてあらゆるプラットフォームをターゲットとできるため、この分野で人気が高まっています。

フリーパスカル

Free Pascal は最初からクロスコンパイラとして開発されました。コンパイラの実行ファイル (ppcXXX、XXX はターゲットアーキテクチャ) は、同じアーキテクチャのすべての OS の実行ファイル (内部リンカーが存在しない場合はオブジェクトファイルのみ、内部アセンブラが存在しない場合はアセンブリファイルのみ) を作成できます。たとえば、ppc386 は i386-linux、i386-win32、i386-go32v2 (DOS) およびその他すべての OS の実行ファイルを作成できます ( [ 14 ]を参照)。ただし、別のアーキテクチャにコンパイルするには、まずコンパイラのクロスアーキテクチャバージョンをビルドする必要があります。結果として得られるコンパイラ実行ファイルの名前には、ターゲットアーキテクチャの前に「ross」が追加されます。つまり、コンパイラが x64 をターゲットとしてビルドされている場合、実行ファイルは ppcrossx64 になります。

選択したアーキテクチャOS向けにコンパイルするには、コンパイラスイッチ（コンパイラドライバfpc用）の-Pと-Tを使用します。これはコンパイラ自体をクロスコンパイルする際にも使用されますが、makeオプションのCPU_TARGETとOS_TARGETで設定します。Free Pascalにターゲットプラットフォーム用のツールがまだ内蔵されていない場合は、ターゲットプラットフォーム用のGNUアセンブラとリンカーが必要です。

カラン

Clang はネイティブでクロス コンパイラーであり、ビルド時に Clang がターゲットとするアーキテクチャを選択できます。

プラン9

異種混合システムであるPlan 9とそのツールチェーンは、クロスコンパイルとネイティブコンパイルを区別しません。Makefileはアーキテクチャに依存しません。

参照

参考文献

  1. ^ 「4.9 カナダの十字架」。CrossGCC 。 2004年10月9日時点のオリジナルよりアーカイブ。 2012年8月8日閲覧。当時、カナダには3つの全国政党があり、名称が必要だったため、この十字は「カナダの十字架」と呼ばれています。
  2. ^ Ritchie, DM (1984年10月). 「UNIXシステム：UNIXタイムシェアリングシステムの進化」 . AT&Tベル研究所技術ジャーナル. 63 (8): 1577– 1593. doi : 10.1002/j.1538-7305.1984.tb00054.x .
  3. ^ 「クロスコンパイル（Automake）」。
  4. ^ 「クロスコンパイル」。
  5. ^ 「Obsolete Macintosh Computers」 2008年2月26日時点のオリジナルよりアーカイブ。2008年3月10日閲覧。
  6. ^アステカC
  7. ^コモドール64
  8. ^アップルII
  9. ^ MS-DOSタイムライン2008年5月1日アーカイブat the Wayback Machine
  10. ^ Inside Windows CE (Fenwick を検索)
  11. ^ Microsoft 言語ユーティリティのバージョン履歴
  12. ^ PCベースのCコンパイラの歴史 2007年12月15日アーカイブ、 Wayback Machine
  13. ^どのBasicバージョンがC、FORTRAN、Pascal、MASMを呼び出すことができるか
  14. ^ 「Free Pascal 対応プラットフォーム一覧」 .プラットフォーム一覧. 2010年6月17日閲覧. i386
「 https://en.wikipedia.org/w/index.php?title=Cross_compiler&oldid=1336040887」から取得