Windows64がx86-64上の他のすべてのOSとは異なる呼び出し規則を使用するのはなぜですか？
AMDには、x86-64で使用する呼び出し規約を記述したABI仕様があります。独自のx86-64呼び出し規約を持つWindowsを除き、すべてのOSがこれに従います。どうして？
誰もがこの違いの技術的、歴史的、または政治的な理由を知っていますか、それとも純粋にNIHsyndromeの問題ですか？
私は、OSごとに高レベルのものに対するニーズが異なる可能性があることを理解していますが、たとえば、Windowsでのレジスタパラメーターの受け渡し順序がrcx - rdx - r8 - r9 - rest on stack他の全員がrdi - rsi - rdx - rcx - r8 - r9 - rest on stack。
追伸私はこれらの呼び出し規約が一般的に異なるhowを知っており、必要に応じて詳細を見つける場所を知っています。私が知りたいのは、whyです。
編集：方法については、例えば wikipedia entry とそこからのリンク。
マイクロソフトは当初、IA64でIntelと強力なパートナーだったため、当初「初期のAMD64の取り組みに対して公式に非コミットメント」であったことを思い出してください（ 「現代64ビットコンピューティングの歴史」 建築。これは、UnixとWindowsの両方で使用するためにABIでGCCエンジニアと仕事をすることに開放されていたとしても、それがなかったときにAMD64の取り組みを公的にサポートすることを意味するので、そうしなかったことを意味すると思いますまだ正式に行われていません（おそらくIntelを混乱させていただろう）。
それに加えて、当時のマイクロソフトは、オープンソースプロジェクトに親しみを感じる傾向がまったくありませんでした。確かにLinuxやGCCではありません。
では、なぜ彼らはABIに協力したのでしょうか？私は、ABIが多かれ少なかれ同時に独立して設計されたという理由だけで異なると思います。
「最新の64ビットコンピューティングの歴史」からの引用：
マイクロソフトとのコラボレーションと並行して、AMDはオープンソースコミュニティとも協力して、チップの準備を進めました。 AMDは、ツールチェーン作業のためにCode SorceryとSuSEの両方と契約しました（Red HatはすでにIA64ツールチェーンポートでIntelに関与していました）。ラッセルは、SuSEがCおよびFORTRANコンパイラを作成し、Code SorceryがPascalコンパイラを作成したと説明しました。 Weberは、同社はLinuxコミュニティと協力してLinuxポートを準備していると説明しました。この取り組みは非常に重要でした。それは、MicrosoftがAMD64 Windowsの取り組みに投資し続けるインセンティブとして機能し、また、当時重要なOSになっていたLinuxがチップのリリース後に利用可能になることを保証しました。
ウェーバーは、必要に応じて他の企業の助けを借りずにAMDがエンドツーエンドのシステムを作成できるようにしたため、Linuxの仕事はAMD64の成功にとって絶対に重要であると言っています。この可能性により、AMDは、他のパートナーがバックアウトした場合でも最悪のサバイバル戦略を持つことが保証されました。
これは、MSとUnixの間で協力が必ずしも最も重要であるとAMDが感じていなかったが、Unix/Linuxをサポートすることが非常に重要であることを示しています。たぶん、一方または両方の側に妥協または協力するように説得しようとしても、どちらかを刺激する労力またはリスク（？）に値しませんか？おそらく、AMDは、一般的なABIを提案することでさえ、チップの準備が整ったときにソフトウェアサポートを用意するというより重要な目的を遅らせたり、遅らせたりするかもしれないと考えました。
憶測ですが、ABIが異なる主な理由は、MSとUnix/Linux側が協力していない政治的理由であり、AMDはそれを問題として認識していなかったと思います。
Win32には、ESIおよびEDIの独自の用途があり、それらを変更しないこと（または、少なくともAPIを呼び出す前に復元する必要があります）。64ビットコードには、 RSIとRDIでも同じです。これは、関数の引数を渡すために使用されない理由を説明します。
ただし、RCXとRDXが切り替えられる理由を説明できませんでした。