64ビットアプリケーションとインラインアセンブリ
Visual C++ 2010を使用して32ビットWindowsアプリケーションを開発しています。インラインアセンブリを実際に使用したいものがあります。しかし、ビジュアルC++が64ビットアプリケーションでのインラインアセンブリをサポートしていないことに気づきました。したがって、将来64ビットに移植することは大きな問題です。
64ビットアプリケーションが32ビットアプリケーションとどのように異なるのか私にはわかりません。 32ビットアプリケーションをすべて将来64ビットにアップグレードしなければならない可能性はありますか？ 64bit CPUの方がレジスタが多いと聞きました。私のアプリケーションではパフォーマンスは問題ではないので、これらの追加のレジスタを使用することは私にとって問題ではありません。 32ビットアプリケーションを64ビットにアップグレードする必要がある他の理由はありますか？ 64ビットアプリケーションは、64ビットアプリケーションが64ビットCPUに固有のレジスタまたは命令を使用する可能性があることを除いて、32ビットアプリケーションと比較して処理が異なりますか？
私のアプリケーションは、他のOSコンポーネントと対話する必要があります。私が知っているドライバーは、64ビットWindowsでは64ビットでなければなりません。私の32ビットアプリケーションはそれらと互換性がありますか？
Visual C++ x64（またはARM）プロセッサのインラインアセンブリはサポートしていません 。一般にインラインアセンブリを使用することは悪い考えです。
- 通常、コンパイラは人間よりも優れたアセンブリを生成します。
- コンパイラよりも優れたアセンブリを生成できる場合でも、インラインアセンブリを使用すると、通常、あらゆるタイプのコードオプティマイザが無効になります。確かに、手で最適化されたコードは少し高速かもしれませんが、その周りのコードを最適化できないという事実は、一般的にプログラム全体の速度を低下させます。
- コンパイラ組み込み関数 は、CおよびC++言語と一貫した方法で高度なCPU機能（SSEなど）にアクセスでき、オプティマイザを無効にしないほとんどすべての主要コンパイラから利用できます。
32ビットアプリケーションが将来すべて64ビットにアップグレードされなければならない可能性があるのではないかと思います。
それはあなたのターゲットオーディエンスに依存します。サーバーを対象としている場合は、はい、それはサーバーであるため、ユーザーがWOW64サブシステムをインストールできないようにするのは妥当です。 Windows Server 2008 R2では、「サーバーコア」インスタンスとしてインストールする場合、これをオプションとしてすでに許可していると思います。
私のアプリケーションではパフォーマンスは問題ではないので、余分な64ビットレジスタを使用することは私にとって問題ではありません。 32ビットアプリを将来64ビットにアップグレードする必要がある他の理由はありますか？
64ビットはレジスターとは関係ありません。アドレス可能な仮想メモリのサイズに関係しています。
64ビットアプリケーションが64ビットCPUに固有のいくつかのレジスタ/命令を使用していることを除けば、64ビットアプリケーションプロセスは32ビットアプリケーションプロセスとは異なりますか？
最も可能性が高い。 32ビットアプリケーションは、2GBを超えるものを一度にメモリにマップできないという制約があります。 64ビットアプリケーションにはその問題はありません。 4 GBを超える物理メモリを使用していない場合でも、4 GBを超える仮想メモリをアドレス指定できると、ディスク上のファイルをメモリなどにマッピングするのに役立ちます。
私のアプリケーションは、他のOSコンポーネントと対話する必要があります。私が知っているドライバーは、64ビットWindowsでは64ビットでなければなりません。私の32ビットアプリケーションはそれらと互換性がありますか？
それは、それらのドライバーとの通信方法に完全に依存します。 「名前付きファイルインターフェース」のようなものである場合、アプリは32ビットのままです。共有メモリ（Yikes！の共有メモリはユーザーモードからドライバーでアクセスできますか？！？）のようなことをしようとすると、アプリを64ビットとしてビルドする必要があります。
@Billyの優れた記事とは別に、インライン64ビットアセンブリを使用する必要性を本当に感じている場合は、MASMなどの外部アセンブラを使用してそれを行うことができます これを参照 。 （事前構築スクリプトでこれをスピードアップすることも可能です）。
intel C Compiler 15は64ビットのインライン機能も備えています。そして、ICをVisual Studioにツールセットとして統合することができます。インラインアセンブリを備えたVC++ 64ビットがあります。 1つのキャッチしかし-その高価な歓声
その間、MinGWには64ビットのインラインアセンブリ言語もあります。そして、それはかなり速く、無料です。一部の数学では以前は遅くなりました。 MSVCとMinGWのパフォーマンスの比較から始めて、アプリケーションにとって適切な開始場所かどうかを確認します。
また、インラインアセンブリが周囲のコードの速度を低下させることになっている場合。それは多くの短いセグメントに当てはまるかもしれないが、私には思えます：
- 実際、人間はコンパイラよりも効率的に実行されるコードアセンブリを頻繁に実行します。少なくとも70年代と80年代にプログラミングを学び、2000年までずっとそうであった場合、少なくともそれは常に常識でした。
- ループに費やした時間とコードの量によって異なります。手書きのアセンブリルーチンを使用すると、ルーチンの速度が大幅に向上し、最適化によって失われるパフォーマンスが比較的小さくなる場合があります。またはなし-関数全体をアセンブリに変換する場合と同様に。
アセンブリは、M $が何を言っても、高度な最適化を必要とするコード内の場所を非常に多く持つことができます。実際に試してみるまで、Assemblyがコードを高速化するかどうかはわかりません。他のすべてはただ価値があります。
私はc ++コードをAssemblyにコンパイルし、それを手動で最適化するアプローチを支持しています。それはあなたにそれの多くを書く手間を省きます。少し実験するだけで、コンパイラーの最適な最適化を利用できます。それから改善を始めます。 FWIW、私は現代のプログラムを使う必要がありませんでした。多くの場合、他のものがそれと同じくらいまたはそれ以上にスピードアップできます-例えばマルチスレッドなど。ただし、パフォーマンスが重要なアプリケーションの場合は、試さない理由はないと思います。それが機能する場合は、それを使用してください。 M $はただ怠惰です。