移植

ソフトウェア工学において、移植とは、あるプログラムが本来設計された環境とは異なるコンピューティング環境（異なるCPU、オペレーティングシステム、サードパーティのライブラリなど）で何らかの実行を実現するためにソフトウェアを適応させるプロセスです。この用語は、ソフトウェア/ハードウェアを異なる環境で使用できるように変更する場合にも使用されます。^{[1] [2]}

ソフトウェアが移植可能であると判断されるのは、ソフトウェアを新しいプラットフォームに移植するコストが、ソフトウェアをゼロから作成するコストよりも大幅に低い場合です。ソフトウェアの実装コストに比べてソフトウェアの移植コストが低いほど、ソフトウェアの移植性が高いと言えます。

「ポート」という用語はラテン語の「運ぶ」を意味するportāreに由来しています。 ^{[3]コードが特定の}オペレーティングシステムまたはアーキテクチャと互換性がない場合は、コードを新しいシステムに「運ぶ」必要があります。

この用語は、通常、同じ CPU とオペレーティング システム上でより少ないメモリで実行できるようにソフトウェアを適応させるプロセスには適用されません。

ソフトウェア開発者は、自分が書いたソフトウェアは移植可能である、つまり新しい環境に適応させるのにほとんど労力はかからない、と主張することがよくあります。実際に必要な労力の量は、元の環境 (ソース プラットフォーム) と新しい環境 (ターゲット プラットフォーム) の相違の程度、どのプログラミング言語構成要素とサード パーティ ライブラリ呼び出しが移植可能ではないかを把握している元の作成者の経験、移植可能な構成要素のみを使用するために元の作成者が費やした労力の量 (プラットフォーム固有の構成要素の方が安価なソリューションになることが多い) など、いくつかの要因によって異なります。

今日のデスクトップで使用される、大きく異なる CPU とオペレーティング システムの数は、過去に比べてはるかに少なくなっています。x86 アーキテクチャが優位であるため 、ほとんどのデスクトップ ソフトウェアは別の CPU に移植されることはありません。同じ市場において、オペレーティング システムの選択肢は実質的にMicrosoft Windows、macOS、Linux の3 つに絞られています。ただし、組み込みシステムとモバイル市場では、移植性が依然として大きな問題であり、ARM が広く使用されている代替手段となっています。

ISOが公布したような国際標準は、コンピューティング環境の詳細を指定して、標準に準拠したさまざまなプラットフォーム間の違いを減らすことにより、移植を大幅に容易にします。これらの標準で指定された範囲内にとどまるソフトウェアを作成することは、現実的ではありますが、簡単ではありません。このようなプログラムを 2 つの標準に準拠したプラットフォーム ( POSIX.1など) 間で移植するには、ソース コードをロードして新しいプラットフォームで再コンパイルするだけで済みますが、プラットフォームの微妙な違いにより、さまざまな小さな修正が必要になることがよくあります。ほとんどの標準には、標準の解釈の違いによってプラットフォームごとに小さな違いが生じる「グレー エリア」があります。

また、さまざまなプラットフォームで一貫したプログラミング言語を提供するGNU コンパイラ コレクションや、環境内の小さな変化を自動的に検出し、コンパイル前にソフトウェアをそれに応じて適応させるAutotoolsなど、移植を容易にするツールも増え続けています。

一部の高水準プログラミング言語(例: Eiffel、Esterel )のコンパイラは、多くのプラットフォーム用のコンパイラが一般的に利用可能な別の高水準中間言語( Cなど) でソース コードを出力することで移植性を高めています。

移植に関連する（ただし移植とは異なる） 2 つのアクティビティは、エミュレーションとクロスコンパイルです。

最近のコンパイラは、コンパイラの移植性を高め、設計の労力を最小限に抑えるために、マシンコードに直接変換する代わりに、マシンに依存しない中間コードに変換します。中間言語は、中間言語で書かれたすべてのプログラムを実行できる仮想マシンを定義します（マシンはその言語によって定義され、その逆も同様です）。^[4]中間コード命令は、コードジェネレータによって同等のマシンコードシーケンスに変換され、実行可能コードが作成されます。仮想マシン用のインタープリタまたはJITを実際に実装することで、マシンコードの生成をスキップすることもできます。 ^[5]

中間コードを使用すると、コンパイラの移植性が向上します。これは、コンパイラ自体のマシン依存コード (インタープリタまたはコードジェネレータ) のみをターゲットマシンに移植すればよいためです。コンパイラの残りの部分は中間コードとしてインポートし、移植されたコードジェネレータまたはインタープリタでさらに処理して、コンパイラソフトウェアを生成するか、インタープリタで中間コードを直接実行することができます。マシンに依存しない部分は、別のマシン (ホストマシン)で開発およびテストできます。これにより、移植可能な中間コードを作成するためにマシンに依存しない部分を一度開発するだけで済むため、設計の労力が大幅に軽減されます。^[6]

インタプリタはコードジェネレータよりも複雑ではないため、移植も簡単です。これは、プログラムコードの見方が限られているためコードの最適化ができないためです (一度に 1 つの命令しか認識できず、ユーザーは最適化を行うためにシーケンスが必要です)。一部のインタプリタは、基盤となるハードウェアの命令セットについて最小限の仮定しか行わないため、移植が非常に簡単です。その結果、仮想マシンはターゲット CPU よりもさらに単純になります。^[7]

コンパイラのソースを、コンパイラが変換するプログラミング言語で完全に記述すると、コンパイラ ブートストラップと呼ばれる次のアプローチがターゲット マシン上で実行可能になります。

1. インタープリタを移植します。これは、ターゲットに既に存在するアセンブラを使用して、アセンブリ コードでコーディングする必要があります。
2. コード ジェネレーターのソースを新しいマシンに適合させます。
3. コード ジェネレーター ソースを入力として、インタープリターを使用して適応されたソースを実行します。これにより、コード ジェネレーターのマシン コードが生成されます。

最適化ルーチンのコーディングの難しい部分は、ターゲットのアセンブリ言語ではなく高級言語を使用して行われます。

BCPL言語の設計者によると、解釈されたコード（BCPLの場合）はマシンコードよりもコンパクトで、通常は2倍コンパクトです。ただし、解釈されたコードは、同じマシン上でコンパイルされたコードよりも約10倍遅く実行されます。^[8]

Java プログラミング言語の設計者は、インタープリタ コードのコンパクトさを活用しようとします。これは、Java プログラムをターゲットのJava 仮想マシン(JVM) で実行を開始する前に、インターネット経由で送信する必要がある場合があるためです。

移植とは、アーケード、ビデオゲームコンソール、またはパーソナルコンピュータのいずれかのプラットフォームで動作するように設計されたビデオゲームが、おそらく若干の違いはあるものの、別のプラットフォームで動作するように変換されるときにも使用される用語です。^[9]ビデオゲームの黎明期から1990年代まで、「移植」（当時は「変換」と呼ばれていたことも多い）は、多くの場合、真の移植ではなく、異なるシステムの制限のためにゲームを作り直したバージョンでした。たとえば、1982年のゲーム「ホビット」は、グラフィックイメージで拡張されたテキストアドベンチャーですが、その移植が開発されたパーソナルコンピュータの範囲によってグラフィックスタイルが大きく異なります。^[10]ただし、21世紀のビデオゲームの多くは、実際の移植を必要とせずに（代わりに個々のコンポーネントライブラリの共通移植に依存して）、1つ以上のコンソールとPC用のコードを出力できるソフトウェア（多くの場合C++）を使用して開発されています。^[10]

アーケードゲームをハードウェアの劣る家庭用システムに移植するのは困難だった。Atari 2600に移植されたパックマンのバージョンでは、 ROMスペースの不足を補うために元のゲームの視覚的特徴の多くが省略されており、画面に複数のゴーストが現れてちらつく効果が発生するとハードウェアが苦労した。Atari 2600パックマンの性能の悪さは、1983 年のビデオゲームの崩壊の原因として一部の学者によって挙げられている。^[11]

初期の移植版の多くは、コンピュータが大きく異なっていたため、ゲームプレイの品質に重大な問題を抱えていた。^[12] リチャード・ギャリオットは1984年のオリジンズ・ゲームフェアで、オリジン・システムズはまずApple II向けにビデオゲームを開発し、その後コモドール64とアタリの8ビットコンピュータに移植したと述べた。後者のマシンのスプライトやその他の高度な機能により、Appleへの移植が「はるかに困難で、おそらく不可能」だったためである。^[13]レビューでは、移植版が「Appleへの変換症候群」に悩まされ、^[14] Appleの「ひどいサウンドと黒・白・緑・紫のグラフィック」を維持しているとの苦情があった。^{[15] [16]}ギャリオットの発言の後、ダン・バンテンが「聴衆の中にいるアタリとコモドールの人たち、Appleの書き直しに満足していますか？」と尋ねると、聴衆は「いいえ！」と叫んだ。ギャリオットは「[そうでなければ]Apple版は完成しないでしょう。出版社の観点から言えば、それは金銭的に賢明ではありません」と答えた。^[13]

他社は違ったやり方で開発を進めた。例えば、Ozark Softscapeは、最先端のコンピュータ向けに開発することを優先し、移植中に必要に応じて機能を削除したり変更したりしたため、最初は Atari 向けに MULE を作成した。このような方針は必ずしも実行可能ではなかった。Bunten は「MULE は Apple 向けには作れない」と述べ、^{[12] 、} The Seven Cities of Goldの Atari 以外のバージョンは劣っていた。^[17] Compute! の Gazette は1986 年に、Atari から Commodore に移植する場合、通常は元のバージョンの方が優れていると書いた。同誌によると、1983 年後半に開発者が Commodore 向けの新しいソフトウェアを作成し始めてから、後者のゲームの品質が向上したという。^[18]

アーケードゲームの移植では、移植版のゲームプレイ、グラフィック、その他のアセットがアーケード版にどれだけ近いかを表すために、「アーケードパーフェクト」または「アーケードアキュレート」という用語がよく使用されました。1980年代初頭の多くのアーケード移植は、家庭用ゲーム機やコンピューターにはアーケードゲームのような高度なハードウェアがなかったため、アーケードパーフェクトからは程遠いものでしたが、ゲームプレイを近似することはできました。特に、Atari VCSのスペースインベーダーは、違いにもかかわらずコンソールのキラーアプリになりましたが、 ^[19]その後のパックマンの移植は、アーケードバージョンからの逸脱で悪名高いものでした。^[20]アーケードアキュレートゲームは、家庭用ゲーム機がアーケードシステムのパワーに追いつくにつれて、1990年代から普及しました。特に、マルチゲームアーケードシステムとして導入されたSNKのネオジオシステムは、同じ仕様の家庭用ゲーム機としても提供されました。これにより、アーケードパーフェクトなゲームを自宅でプレイできるようになりました。^[10]

「コンソール ポート」とは、元々コンソール用に作られたゲームで、その後パソコンでプレイできる同一バージョンが作られるものです。この用語はゲーム コミュニティで広く使用されています。コンソールから PC にゲームを移植するプロセスは、一般的にコンピューターが持つ高いパフォーマンスが十分に活用されていないため、否定的に捉えられることがよくあります。その理由の一部は、コンソールのハードウェアは稼働中ずっと固定されており (ゲームはコンソールの仕様に合わせて開発されている)、PC はハードウェアの進化に伴ってより強力になっているためですが、移植されたゲームが PC 向けに最適化されていない、または手抜きで移植されていることも原因です。大まかに似ていますが、コンソールでの 統合メモリの使用など、アーキテクチャの違いが存在する場合があります。

• コンソールエミュレータ
• クロスプラットフォーム
• 言語バインディング
• システム品質属性のリスト
• ポシュリブ
• プログラム変換
• ソフトウェアの移植性
• ソースツーソースコンパイラ
• 送信元ポート
• 一度書けばどこでもコンパイル可能
• 非移植の意味

• リチャーズ、マーティン、ウィットビー・ストレベンス、コリン（1984）。BCPL 、言語とそのコンパイラ。ケンブリッジ大学出版局。ISBN 0-521-28681-6。
• Tanenbaum, Andrew S. (1984)。構造化コンピュータ組織。Prentice -Hall。ISBN 0-13-854605-3。