移植

ソフトウェア開発において、移植とは、ソフトウェアを異なるコンテキストで動作するように適応させるプロセスです。多くの場合、ソースコードを修正し、プログラムを異なるプラットフォーム（異なるCPUやオペレーティングシステムなど）や異なる環境（異なるライブラリやフレームワークなど）で動作させることが含まれます。また、あるコードベースから別のコードベースへ、あるいは同じソフトウェアの異なるバージョン間で変更や機能を適応させることも含まれます。 [ 1 ]

ソフトウェアは、ソースコードを変更することなく異なるコンテキストでホストできる場合、移植可能と分類されます。コンテキストへの適応にかかるコストが、ゼロから開発するコストよりも大幅に低い場合、移植可能とみなされる可能性があります。移植にかかるコストが書き換えにかかるコストに比べて低いほど、移植性が高いと言えます。移植にかかる労力は、元のコンテキストと新しいコンテキストの差異の程度、プログラマーのスキル、コードベースの移植性など、いくつかの要因に依存します。

語源

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

歴史

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

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

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

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

移植コンパイラ

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

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

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

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

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

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

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

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

ビデオゲームの移植

移植とは、アーケード、ビデオゲーム機、パソコンなど、あるプラットフォームで動作するように設計されたビデオゲームを、多少の違いはあるものの、異なるプラットフォームで動作するように変換することを指す用語でもあります。 [ 8 ]ビデオゲームの黎明期から1990年代にかけて、「移植」（当時は「コンバージョン」とも呼ばれていました）は、真の移植ではなく、異なるシステムの制限に合わせてゲームを作り直したバージョンであることがよくありました。例えば、1982年に発売されたゲーム『ホビット』は、グラフィックイメージが追加されたテキストアドベンチャーゲームですが、移植版が開発されたパソコンの種類によってグラフィックスタイルが大きく異なります。[ 9 ]しかし、21世紀のビデオゲームの多くは、実際の移植を必要とせずに（個々のコンポーネントライブラリの共通移植に頼って）、1台以上のコンソールとパソコン用のコードを出力できるソフトウェア（多くの場合C++ ）を使用して開発されています。[ 9 ]

アーケードゲームをハードウェアの劣る家庭用ゲーム機に移植するのは困難でした。Atari 2600向けの『パックマン』移植版では、 ROM容量の不足を補うためにオリジナルゲームの多くのビジュアル要素が省略され、画面に複数のゴーストが現れてちらつくという現象が発生すると、ハードウェアの性能が低下しました。Atari 2600版『パックマン』の低パフォーマンスは、1983年のビデオゲーム市場の崩壊の原因の一つであると一部の研究者は指摘しています。[ 10 ]

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

他社は異なる方法で開発を進めた。例えば、Ozark Softscapeは、最先端のコンピュータ向けに開発することを優先し、移植時に必要に応じて機能を削除または変更したため、MULEを最初にAtari向けに開発した。しかし、この方針は必ずしも実現可能ではなかった。Buntenは「MULEはAppleにはできない」 [ 11 ]と述べ、Atari版以外のThe Seven Cities of Goldは劣っていた[ 16 ] 。Compute !のGazette誌は1986年、AtariからCommodoreへの移植では、通常、オリジナルのほうが優れていると報じた。同誌によると、Commodoreのゲームの品質は、開発者が1983年後半に新しいソフトウェアの開発を開始したことで向上したという。[ 17 ]

アーケードゲームの移植において、「アーケードパーフェクト」や「アーケードアキュレート」という言葉は、移植版のゲームプレイ、グラフィック、その他の要素がアーケード版にどれだけ忠実であるかを表す際によく使われました。1980年代初頭のアーケード移植の多くは、家庭用ゲーム機やパソコンにはアーケードゲームのような高度なハードウェアがなかったため、アーケードパーフェクトには程遠いものでしたが、それでもゲームプレイをある程度再現することは可能でした。特に、Atari VCSの『スペースインベーダー』は、その違いにもかかわらず、同機のキラーアプリとなりました。 [ 18 ]一方、後に移植された『パックマン』は、アーケード版からの逸脱で悪名高いゲームでした。[ 19 ]アーケードアキュレートゲームは、家庭用ゲーム機がアーケード機の性能に追いつく1990年代以降、より普及しました。特に、マルチゲームアーケードシステムとして発売されたSNKのネオジオシステムは、同じ仕様の家庭用ゲーム機としても発売されました。これにより、アーケードパーフェクトなゲームが家庭でプレイできるようになりました。[ 9 ]

「コンソールポート」とは、元々、または主にコンソール向けに制作されたゲームを、パソコンでプレイできるバージョンに移植したものです。コンソールからPCへのゲーム移植は、他の種類の移植よりも冷笑的に見られることが多いです。これは、一部のPC移植版が、コンソールの発売当時でさえ、多くのPCで利用可能なより強力なハードウェアを十分に活用していないという事実に起因しています。コンソールのハードウェアは世代を通じて固定されているのに対し、PCのハードウェアは進化し続けるため、コンソールの制限に合わせて設計されたゲームは、PCでリリースされた際に最適化が不十分に見えることがあります。現在では両ゲームは概ね似ていますが、コンソールでは統合メモリや小型OSの使用など、アーキテクチャ上の違いが残っています。その他の反対意見は、ゲームパッド、視野が狭いTFUI、固定されたチェックポイント、公式サーバーまたはP2Pに制限されたオンライン、貧弱または全くない改造サポートなど、コンソールに慣例となっているユーザーインターフェイスの違いから生じており、また、コンソール開発者は一般に、外部APIや設定可能性ではなく内部のハードコーディングとデフォルトに依存しており、これらすべてが、PCへの「怠惰な」移植を避けるために、高価で徹底的な再設計を必要とする可能性がある。[ 20 ]

不可能な移植とは、対象機種よりも大幅に性能の低いハードウェアにビデオゲームを移植することである。[ 21 ]例としては、プレイステーション4とXbox Oneのゲーム（ニーアオートマタやウィッチャー3 ワイルドハントなど）をNintendo Switchに移植することがあげられる。[ 22 ] [ 23 ]

参照

参考文献

  1. ^ Whitten, DE; Demaine, PAD (1975年3月). 「機種と構成に依存しないFortran：ポータブルFortran」. IEEE Transactions on Software Engineering . SE-1 (1): 111– 124. doi : 10.1109/TSE.1975.6312825 . S2CID  16485156 .
  2. ^ "port, v.2" .オックスフォード英語辞典（OEDオンライン） . オックスフォード大学出版局. 2017年12月21日閲覧。語源：複数の語源を持つ。フランス語からの借用語。ラテン語からの借用語。語源：フランス語porter、ラテン語portāre . ... 1.翻訳。運ぶ、担う、または運ぶ、持ってくる。
  3. ^ Tanenbaum 1984、p. 3、§ 1.1 言語、レベル、仮想マシンでは、用語とその関係について説明しています。
  4. ^ Tanenbaum 1984、p. 2。第1章「はじめに」では翻訳と解釈につ​​いて説明しています。
  5. ^ Richards & Whitby-Strevens 1984、p. 124、§ 7.1 Introductionでは、中間コードを使用したコンパイラの移植性について説明しています。
  6. ^ Richards & Whitby-Strevens 1984、p. 133、§ 7.4 ブートストラッププロセスとINTCODEでは、INTCODEインタープリタの役割について説明しています。
  7. ^ Richards & Whitby-Strevens 1984、p. 136、§ 7.4.3 例では、BCPL プログラムをインタープリタ用の INTCODE に変換する例を示しています。
  8. ^ Wolf, Mark JP (2008). 「用語集」 .ビデオゲームの爆発的発展：PONGからプレイステーション、そしてそれ以降の歴史. Bloomsbury Academic. p. 315. ISBN 978-0-313-33868-7。
  9. ^ a b c Grabarczyk, Pawel; Aarseth, Espen (2019),移植か変換か？ゲームのバージョンを分類するためのオントロジーフレームワーク | DiGRA Conference 2019
  10. ^ニコル、ベンジャミン (2015). 「ギャップを埋める：ネオジオ、メディアの想像力、そしてアーケードゲームの国内化」.ゲームズ・アンド・カルチャー. doi : 10.1177/1555412015590048 . S2CID 147981978 . 
  11. ^ a b Bunten, Dan (1984年12月). 「戦略ゲームデザイン最前線からの情報／洞察」Computer Gaming World . p. 40. 2013年10月31日閲覧。
  12. ^ a b「CGWコンピュータゲームカンファレンス」。コンピュータゲームワールド（パネルディスカッション）。1984年10月。30ページ。 2013年10月31日閲覧。
  13. ^ダニントン・ベン、ブラウン・マーク・R、マルコム・トム（1987年1月～2月）。「64/128ギャラリー」インフォメーション誌、pp.14  ～ 21。
  14. ^スタントン, ジェフリー; ウェルズ, ロバート P.; ロコワンスキー, サンドラ; メリッド, マイケル (編) (1984). 『アディソン・ウェズレー版 Atari ソフトウェア集』 . アディソン・ウェズレー. pp. 12, 21, 44, 126. ISBN 0-201-16454-X。
  15. ^バーンスタイン、ハーヴェイ（1985年5月）「Beyond Castle Wolfenstein」アンティック社、p.83 。 2015年1月8日閲覧。
  16. ^ Bunten, Dan. 「The Game Collection」 . Ozark Softscape MULE . 2017年10月4日閲覧。
  17. ^ Yakal, Kathy (1986年6月). 「コモドールグラフィックスの進化」 . Compute!'s Gazette . pp.  34– 42. 2019年6月18日閲覧。
  18. ^ケント、スティーブン（2001年）『ビデオゲームの究極史』スリーリバーズプレス、190頁。ISBN 0-7615-3643-4。
  19. ^ケント、スティーブン (2001). 「The Fall」.ビデオゲームの究極史.スリーリバーズプレス. pp.  237– 239. ISBN 978-0-7615-3643-7。
  20. ^ 「ひどいコンソール移植をやめよう - ガイド」 PC Gamer 2013年。
  21. ^ Yarwood, Jack (2024年12月17日). 「メイキング：『Dragon's Lair』の「不可能」なゲームボーイカラー移植」 . Time Extension . 2026年1月17日閲覧。
  22. ^マイナー、ジョーダン (2020年6月29日). 「Nintendo Switchへの不可能を可能にする移植版の美しさ」 . PCMAG . 2026年1月17日閲覧。
  23. ^ Cryer, Hirun (2022年10月6日). 「『ニーア オートマタ』のSwitch移植版は、実は2017年のゲームをプレイするのに最適な場所かもしれない」 . GamesRadar+ . 2026年1月17日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Porting&oldid=1336505238」から取得