プログラムの64ビットバージョンを作成するのが難しいのはなぜですか？

私の短時間のプログラミングでは、プログラムの完全なソースがある限り、32ビットまたは64ビットのマシンでC ++、Javaなどをコンパイルするのは簡単でした。

しかし、多くのソフトウェアは64ビットでリリースされていません。最も厄介なことに、Unityエンジンの64ビットリリースはまだありません。

64ビットマシン用に一部のプログラムをコンパイルするのが難しいのはなぜですか？

compiler 64-bit 32-bit

— カルベン
ソース

愚かなプログラマーが想定し続けるためsizeof(int)==sizeof(void*)

— ラチェットフリーク

私たちの環境で一番の理由は、64ビットとして利用できないサードパーティのコンポーネントに依存していることです。それがUnityにも当てはまるかどうかはわかりませんが、そうだとしてもそれほど驚かないでしょう。

— ドックブラウン

サイズを想定する代わりに、int、float、pointerにint32、int64のようなtypedefを使用できます。これは多くの問題を解決するかもしれません。問題の多くは、想定し始めた時点から始まります。

— -Kshitij

実際、これはフラットアーキテクチャでは完全に合理的な仮定です。Windowsは、独自のねじ込みを壊さないように意図的に間違っています。

— ジョシュア

なぜそれが合理的な仮定でしょうか？私はまともな持つことを期待したいoperator*ためにint、しかし、ポインタはそれを必要としません。また、ほとんどのLinuxおよびUnix環境にintは32ビットもあります。

— –MSalters

回答:

一般的な問題は、文書化されていない仮定をプログラムにエンコードすることは非常に簡単であり、それらの仮定が行われた場所を見つけることは非常に難しいことです。高レベルの言語はこれらの懸念からやや隔離する傾向がありますが、プラットフォームやサービスの実装に使用される低レベルの言語では、アーキテクチャ間で必ずしも移植可能でないことを簡単に行うことができます。

intポインタを格納するのに十分な大きさであると仮定します
ポインターのタグ付けなど、ポインターの表現のプロパティを想定
データポインターとコードポインターが同じサイズであると仮定します

リリース管理の実際的な懸念もあります。x86ビルドのみを作成する場合、x86-64上で実行されますが、レジスタの可用性が制限されているため、おそらくより遅くなります。一方、x86とx86-64の両方でビルドする場合、両方のアーキテクチャでテストし、1つのアーキテクチャでのみ発生する可能性のあるバグに対処する必要があるため、新しいリリースの出荷コストが増加します。

— ジョン・パーディ
ソース

64ビットバージョンのOSでx86バイナリが実行された場合にのみ現れるバグを記述することができることに注意してください。それはただ難しい;

— スティーブジェソップ

+1。「リリース管理」のポイントに次を追加します。特定のコンポーネントの32ビットおよび64ビットバージョンが利用できる場合でも、ソフトウェアがサードパーティのコンポーネントに依存している場合、新しいリリースをテストするための追加作業過小評価しないでください。ですから、私見リリース管理は、単なるリストではなく、そのリストの最初のポイントであるべきです。

— Doc Brown

intポインターサイズの問題について詳しく説明していただけますか？64ビット環境では、メモリスペースがintで許可される範囲よりも大きいためでしょうか？

— TankorSmash

@TankorSmash：x86では通常sizeof(int) == sizeof(void *)（両方とも32ビット）; x86_64では、int32ビットを維持するのが普通です（x86との互換性を維持し、メモリ内のスペースを浪費しないようにします）が、ポインターは64ビットでなければなりません（仮想アドレススペースが2 ^ 64になるため）intまたはに押し込まれましたunsigned int。

— マッテオイタリア

ほとんどのソフトウェアは、32ビットと64ビットの両方のIntel / AMDアーキテクチャ用にコンパイルされた場合、同じように動作します。ただし、一部のソフトウェアはサポートしません。怠lazや、より多くの聴衆にリーチすることは別として、64ビットとして再コンパイルできない理由はいくつかあります。

ソフトウェアは安全でないポインタ操作を使用する場合があります。おそらく、プログラムはintにポインターを置きます。intは通常、ほとんどのCおよびC ++コンパイラーでは32ビットです。ポインターは、64ビットプログラムの64ビットです。それは機能しません。
使用されている整数型が異なるサイズである場合、ビットシフト演算は異なる結果を生成する場合があります。これは、次のような標準のtypedefの代わりに通常のデータ型を使用する場合に問題になる可能性がありますint32_t
ユニオンで使用されるデータ型はサイズを変更し、ユニオンの動作を変更する場合があります。
ソフトウェアは、32ビットのみのライブラリに依存する場合があります。一般に、64ビットプログラムは、スタック、ポインターなどに関する仮定のために、64ビットライブラリでのみ動作します。

あなたの質問であなたが尋ねる難しさは、いくつかのコードベースでは、安全でない操作を実行し、安全でない仮定を行い、開発者によって入れられたショートカットと巧妙な「最適化」を持つコードの数百万行があるかもしれないということです。コードは64ビット環境でコンパイルされないか、コンパイルされますが、表示されるバグがあります。すべての問題を修正するのに時間がかかる場合があります。64ビットバージョンをリリースできるようになるまで、会社が時間をかけて修正するかもしれません。全面的な書き換えが必要なため、企業は現在のメンテナンスリリースと一緒に「バージョン2」を開発するかもしれません。

ストーリーの教訓は、きれいなコードを記述し、コンパイラーを推測したり、不要な賢明な最適化を追加したり、ソフトウェアを破壊したり、おそらく助けにはならないことです。

この記事では、この答えに含めることを望んでいたよりもはるかに詳細に説明します。64ビットプラットフォームでのC ++コードの移植に関する20の問題

— トゥレインズコルドヴァ
ソース

問題は、単なるコンパイルよりもはるかに大きくなります。32ビットのみの多くのVSTiを必要とするため、利用可能な64ビットFL Studioを使用できないムスク人の友人がいます。他のダイナミックリンクベースのプラグインアーキテクチャも同様に影響を受けます。

— StarWeaver

編集してくれてありがとう：私は通常文法について非常にうるさいですが、いくつかの間違いを犯しました。そして@StarWeaverは、コードはコンパイルされるかもしれないがバグがあると言ったときに触れたと思います。これは、ターゲットとする言語とプラットフォームに関係なく、きれいなコードを書くという私のポイントにまだ戻っています。

「ショーストッパーバグがある」ショーストッパーは明らかであり、「あなたの顔に」あり、対処することができます。おそらくもっと悪いと思うのは、微妙に不正確な結果を生み出すすべての問題であり、それらは長い間気付かれないでしょう。

— ブルハンアリ