タグ付けされた質問 「x86-64」

私にとっては、ファンキーなMOVのようです。その目的は何ですか、いつ使用する必要がありますか？

676 assembly  x86  x86-64  x86-16 

私が2009年に最初に気付いたのは、GCC（少なくとも私のプロジェクトと私のマシン上で）が、 -Os速度（-O2または-O3）ではなくサイズ（）です。 私はなんとかこの驚くべき動作を示し、ここに投稿するのに十分なほど小さいコードを作成することに成功しました。 const int LOOP_BOUND = 200000000; __attribute__((noinline)) static int add(const int& x, const int& y) { return x + y; } __attribute__((noinline)) static int work(int xval, int yval) { int sum(0); for (int i=0; i<LOOP_BOUND; ++i) { int x(xval+sum); int y(yval+sum); int z = add(x, y); sum += …

445 c++  performance  gcc  x86-64  compiler-optimization 

.NETアセンブリの任意のリストを持っています。 各DLLが（x64またはAny CPUではなく）x86用にビルドされたかどうかをプログラムで確認する必要があります。これは可能ですか？

327 .net  assemblies  x86  64-bit  x86-64 

私は約読んでいるdivとmul組立オペレーション、と私はC言語で簡単なプログラムを作成することにより、アクションでそれらを見ることにしました。 ファイルDivision.c #include <stdlib.h> #include <stdio.h> int main() { size_t i = 9; size_t j = i / 5; printf("%zu\n",j); return 0; } そして、次のコードでアセンブリ言語コードを生成します。 gcc -S division.c -O0 -masm=intel しかし、生成されたdivision.sファイルを見ると、div操作は含まれていません。代わりに、ビットシフトとマジックナンバーを使用して、ある種のブラックマジックを実行します。計算するコードスニペットはi/5次のとおりです。 mov rax, QWORD PTR [rbp-16] ; Move i (=9) to RAX movabs rdx, -3689348814741910323 ; Move some magic number to …

228 c  gcc  assembly  x86-64  integer-division 

バックグラウンド： 組み込みアセンブリ言語を使用して一部のPascalコードを最適化しているときに、不要なMOV命令に気づき、それを削除しました。 驚いたことに、不要な命令を削除すると、プログラムの速度が低下しました。 任意の、役に立たないMOV命令を追加すると、パフォーマンスがさらに向上することがわかりました。 効果は不安定で、実行順序に基づいて変化します。同じジャンク命令が1行で上または下に転置されると、速度が低下します。 CPUがあらゆる種類の最適化と合理化を行うことを理解していますが、これはより黒魔術のように見えます。 データ： 私のコードのバージョンは、時間を実行するループの途中で3つのジャンク操作を条件付きでコンパイルします2**20==1048576。（周囲のプログラムはSHA-256ハッシュを計算するだけです）。 私のかなり古いマシン（Intel（R）Core（TM）2 CPU 6400 @ 2.13 GHz）での結果： avg time (ms) with -dJUNKOPS: 1822.84 ms avg time (ms) without: 1836.44 ms プログラムはループで25回実行され、実行順序は毎回ランダムに変化しました。 抜粋： {$asmmode intel} procedure example_junkop_in_sha256; var s1, t2 : uint32; begin // Here are parts of the SHA-256 algorithm, in Pascal: // …

222 performance  optimization  assembly  x86-64  freepascal 

以下のリンクは、UNIX（BSDフレーバー）とLinuxの両方のx86-32システムコール規則を説明しています。 http://www.int80h.org/bsdasm/#system-calls http://www.freebsd.org/doc/en/books/developers-handbook/x86-system-calls.html しかし、UNIXとLinuxの両方でのx86-64システムコール規則は何ですか？

147 linux  unix  assembly  x86-64  abi 

O'NeillのPCG PRNGの実装中にGCCのバグを見つけたと思います。（Godboltのコンパイラエクスプローラの初期コード） 、（rdiに格納された結果）を乗算oldstateした後MULTIPLIER、GCCはその結果をINCREMENTに追加せず、INCREMENT代わりにrdxに移動し、rand32_ret.state の戻り値として使用されます。 最小限の再現可能な例（コンパイラエクスプローラ）： #include <stdint.h> struct retstruct { uint32_t a; uint64_t b; }; struct retstruct fn(uint64_t input) { struct retstruct ret; ret.a = 0; ret.b = input * 11111111111 + 111111111111; return ret; } 生成されたアセンブリ（GCC 9.2、x86_64、-O3）： fn: movabs rdx, 11111111111 # multiplier constant (doesn't fit in imm32) xor …

133 c  gcc  assembly  x86-64  compiler-bug 

ネイティブアセンブリがマネージコードアプリケーション（C＃）からx64またはx86としてコンパイルされているかどうかを確認したいと思います。 OSローダーがこの情報を知る必要があるため、PEヘッダーのどこかにあるはずだと思いますが、見つかりませんでした。もちろん、マネージコードで実行することを好みますが、必要に応じて、ネイティブC ++を使用できます。

133 c#  .net  winapi  64-bit  x86-64 

Rustには128ビットの整数があり、これらはデータ型i128（およびu128unsigned int）で示されます。 let a: i128 = 170141183460469231731687303715884105727; Rustはこれらのi128値を64ビットシステムでどのように機能させますか。たとえば、これらをどのように計算しますか？ 私の知る限りでは、値はx86-64 CPUの1つのレジスターに収まらないため、コンパイラーは何らかの方法で1つのi128値に2つのレジスターを使用しますか？あるいは、それらを表すために何らかの大きな整数構造体を代わりに使用していますか？

128 rust  x86-64  bigint  int128  llvm-codegen 

ではインテルのマニュアルのx86-64のツアー、私が読んで おそらく最も驚くべき事実はMOV EAX, EBX、RAXレジスタなどの上位32ビットを自動的にゼロにするなどの命令です。 同じ出典で引用されているIntelのドキュメント（手動の基本アーキテクチャで64ビットモードの3.4.1.1汎用レジスター）は、次のように述べています。 64ビットのオペランドは、宛先の汎用レジスターで64ビットの結果を生成します。 32ビットのオペランドは32ビットの結果を生成し、デスティネーションの汎用レジスターで64ビットの結果にゼロ拡張します。 8ビットおよび16ビットのオペランドは、8ビットまたは16ビットの結果を生成します。デスティネーション汎用レジスタの上位56ビットまたは48ビットは、それぞれ操作によって変更されません。8ビットまたは16ビット演算の結果が64ビットのアドレス計算を目的としている場合は、明示的にレジスタを完全な64ビットに符号拡張します。 x86-32およびx86-64アセンブリでは、次のような16ビット命令 mov ax, bx eaxの上位ワードがゼロになるこの種の「奇妙な」動作を表示しないでください。 したがって、この動作が導入された理由は何ですか？一見すると論理的に見えないようです（ただし、x86-32アセンブリの癖に慣れているためかもしれません）。

118 assembly  x86  x86-64  cpu-registers  zero-extension 

マルチターゲティング用にVisual Studioビルドを設定する方法について少しジレンマがあります。 背景：c＃.NET v2.0とサードパーティの32ビットDLLへのp / invoking、SQLコンパクトv3.5 SP1、セットアッププロジェクト。現在、プラットフォームターゲットはx86に設定されているため、Windows x64で実行できます。 サードパーティ企業がDLLの64ビットバージョンをリリースしたばかりで、専用の64ビットプログラムを構築したいと考えています。 これは私がまだ答えを持っていないいくつかの質問を提起します。まったく同じコードベースが必要です。DLLの32ビットセットまたは64ビットDLLへの参照を使用してビルドする必要があります。（サードパーティとSQL Server Compactの両方） これは、2つの新しい構成セット（Debug64とRelease64）で解決できますか？ 2つの個別のセットアッププロジェクト（標準ビジュアルスタジオプロジェクト、Wixまたはその他のユーティリティなし）を作成する必要がありますか、それとも同じ.msi内で解決できますか？ 任意のアイデアや推奨事項を歓迎します。

111 .net  visual-studio  64-bit  x86-64 

AMDには、x86-64で使用する呼び出し規約を記述したABI仕様があります。独自のx86-64呼び出し規約があるWindowsを除いて、すべてのOSがこれに従います。どうして？ 誰かがこの違いの技術的、歴史的、または政治的な理由を知っていますか、それとも純粋にNIH症候群の問題ですか？ OSによっては、より高いレベルのものに対するニーズが異なる可能性があることは理解していますが、たとえば、Windowsでのレジスタパラメータの受け渡し順序rcx - rdx - r8 - r9 - rest on stackが他の誰もが使用してrdi - rsi - rdx - rcx - r8 - r9 - rest on stackいる理由を説明していません。 PS私はこれらの呼び出し規約が一般的にどのように異なるかを知っており、必要に応じて詳細の場所を知っています。私が知りたいのはその理由です。 編集：方法については、たとえばwikipediaのエントリとそこからのリンクを参照してください。

110 windows  x86-64  calling-convention 

現在のところ、この質問はQ＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 最近、私はいくつかのSOアーカイブを読んでいて、x86アーキテクチャに対するステートメントに遭遇しました。 サーバーとミニ/メインフレーム、ミックスコアに異なるCPUアーキテクチャが必要なのはなぜですか？言う 「PCアーキテクチャは混乱である、任意のOSの開発者はあなたにそれを言うだろう。」 アセンブリ言語を学ぶことは、努力する価値がありますか？（アーカイブ）は、 「 x86アーキテクチャはせいぜい恐ろしいものであることを理解している」と述べています。 x86アセンブラを学ぶ簡単な方法はありますか？ 「ほとんどの大学はMIPSのようなものでアセンブリを教えています。理解するのがはるかに簡単だからです。x86アセンブリは本当に醜いです。」 のような多くのコメント 「ほとんどのアーキテクチャーと比較して、X86はかなりひどい。」 「X86がMIPS、SPARC、PowerPCよりも劣っているのは間違いなく従来の知識です」 「x86は醜い」 検索してみましたが、理由はわかりませんでした。これが私がよく知っている唯一のアーキテクチャであるため、x86が悪いとは思わない。 他の人と比較してx86を醜い/悪い/劣っていると考える理由を誰かが親切に教えてくれますか？

105 assembly  x86  mips  x86-64  cpu-architecture 

InstallUtil.exeを使用してWindowsサービスをインストールしようとすると、エラーメッセージが表示されます System.BadImageFormatException：ファイルまたはアセンブリ ' {xxx.exe}'またはその依存関係の1つを読み込めませんでした。不正な形式のプログラムを読み込もうとしました。 何ができますか？ 編集：（OPによるものではありません）dupから抽出された完全なメッセージは、はるかに多くのヒットを得ています[グーグル性のために]： C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319> InstallUtil.exe C：\ xxx.exe Microsoft（R）.NET Frameworkインストールユーティリティバージョン4.0.30319.1 Copyright（c）Microsoft Corporation。全著作権所有。 インストールの初期化中に例外が発生しました：System.BadImageFormatException：ファイルまたはアセンブリ 'file：/// C：\ xxx.exe'またはその依存関係の1つを読み込めませんでした。不正な形式のプログラムを読み込もうとしました。

104 .net  windows-services  x86  64-bit  x86-64 

私はC ++でパフォーマンスが重要な作業を行っており、現在「本質的に浮動小数点」である問題のために「より速い」ため、整数計算を使用しています。これは多くの迷惑な問題を引き起こし、多くの迷惑なコードを追加します。 浮動小数点の計算が386日ほどで非常に遅くなったことを読んだことを覚えています（IIRC）が、オプションのコプロセッサーがあったと思います。しかし、今日では指数関数的に複雑で強力なCPUを使用しているため、浮動小数点や整数の計算を行っても、「速度」に違いはありませんか？特に、実際の計算時間は、パイプラインのストールを引き起こしたり、メインメモリから何かをフェッチしたりするのに比べて短いのですか？ 正しい答えはターゲットハードウェアでベンチマークすることですが、これをテストするための良い方法は何でしょうか？2つの小さなC ++プログラムを作成して、その実行時間とLinuxの「時間」を比較しましたが、実際の実行時間は変動しすぎます（仮想サーバーで実行しているのに役立ちません）。終日何百ものベンチマークの実行、グラフの作成などに費やすのではなく、相対速度の妥当なテストを行うために何かできることはありますか？アイデアや考えはありますか？私は完全に間違っていますか？ 私が使用したプログラムは次のとおりですが、まったく同じではありません。 #include <iostream> #include <cmath> #include <cstdlib> #include <time.h> int main( int argc, char** argv ) { int accum = 0; srand( time( NULL ) ); for( unsigned int i = 0; i < 100000000; ++i ) { accum += rand( ) % 365; } …

100 c++  x86  floating-point  x86-64