問題タブ [yasm]

「Linux 用の 64 ビット Intel アセンブリ言語プログラミングの概要」を読み、学習のために Yasm と MS Visual Studio 2013 を使用してコードを Windows に移植しています。第 7 章に、switch の例があります。

そして、リンカーから取得しました：

ただし、何が起こっているのかを理解しようとしましたが、x64 アーキテクチャのアドレス指定の問題であることを理解しています。だから私は自分のコードを次のように変更しました：

そして、コードは機能しました。しかし、質問があります。このコードは、リンカーとして gcc または ld を使用して Linux で動作するはずです。なぜコードを変更する必要があったのですか?

4GB の RAM を搭載した VM で GAS を使用して 200MB を超える x86 asm ファイルをアセンブルしようとしています。残念ながら、GAS はすぐにすべてのシステム メモリを消費し、殺されます。--reduce-memory-overheadsフラグも試してみましたが、同じ結果が発生します。

yasm も使用してみましたが、メモリも不足しています。

アセンブラが実際にはこのサイズのファイルを処理するように設計されていないことは知っていますが、そうしようとして大量のメモリを使用していることにも驚きました (なぜそうなったのでしょうか?)。

実際のコードは 1 つの大きな関数であり、いくつかの部分に分割されているため、理論的には別の関数に分割することは可能です (または別のファイルにする必要がありますか?) が、関数を分割せずにこれを組み立てる方法はありますか? より多くの RAM を割り当てることもできますが、使用可能な RAM の量に対してはあまり役に立たないと思います (4GB で十分だと思います)。

次のメインループがあるとしましょう

これを計る方法は、このような別の長いループに入れることです

私が見つけたのは、選択したアライメントがタイミングに大きな影響を与える可能性があるということです (最大 +-10%)。コードの配置を選択する方法が明確ではありません。コードを揃える場所として考えられる場所が 3 つあります。

1. 関数へのエントリで (たとえばtriad_fma_asm_repeat、以下のコードを参照)
2. .L1メインループを繰り返す外側のループ（上記）の開始時
3. 私のメインループの開始時（.L2上記）。

私が見つけたもう 1 つのことは、ソース ファイルに別のルーチンを配置した場合、1 つの命令を変更する (たとえば、命令を削除する) と、それらが独立した関数であっても、次の関数のタイミングに大きな影響を与える可能性があることです。過去に、これが別のオブジェクト ファイルのルーチンに影響を与えるのを見たことがあります。

Agner Fog の最適化アセンブリ マニュアルのセクション 11.5「コードのアライメント」を読みましたが、パフォーマンスをテストするためにコードをアライメントする最良の方法はまだ明確ではありません。彼は、私が実際には従わない内側のループのタイミングの例、11.5 を示しています。

現在、コードから最高のパフォーマンスを得ているのは、さまざまな値とアライメントの位置を推測するゲームです。

アライメントを選択するためのインテリジェントな方法があるかどうか知りたいですか? 内側と外側のループを揃える必要がありますか? 内側のループだけ？関数へのエントリも？短い NOP または長い NOP の使用は重要ですか?

主に Haswell に興味があり、次に SNB/IVB、そして Core2 に興味があります。

NASM と YASM の両方を試してみたところ、これが 1 つの大きな違いであることがわかりました。NASM は、YASM がマルチバイト NOP を挿入する 1 バイトの NOP 命令のみを挿入します。たとえば、上記の内側ループと外側ループの両方を 32 バイトに合わせることで、NASM は 20 の NOP (0x90) 命令を挿入しましたが、YASM は次の命令を挿入しました (objdump から)。

これまでのところ、これによるパフォーマンスの大きな違いは観察されていません。命令の長さではなく、アライメントが重要であるようです。しかし、Agner は整列コードのセクションに次のように書いています。

シングルバイト NOP を多く使用するよりも、何もしない長い命令を使用する方が効率的です。

アラインメントを試して効果を確認したい場合は、アセンブリと私が使用する C コードの両方を見つけることができます。double frequency = 3.6CPU の実効周波数に置き換えます。ターボを無効にすることもできます。

アセンブリ ルーチンを呼び出して時間を計測するために使用する C コードを次に示します。

NASM マニュアルの次の記述が気になります。

最後の警告: ALIGN と ALIGNB は、最終的な実行可能ファイルのアドレス空間の先頭ではなく、セクションの先頭に対して相対的に機能します。たとえば、現在のセクションが 4 バイト境界にのみ整列されることが保証されている場合に 16 バイト境界に整列するのは、労力の無駄です。繰り返しますが、NASM は、セクションのアラインメント特性が ALIGN または ALIGNB の使用に適しているかどうかをチェックしません。

コード セグメントが 32 バイトにアラインされた絶対アドレスを取得しているか、相対アドレスのみを取得しているかはわかりません。

はじめに、私は地元の大学でシステム プログラミングを学んでいます。vBox で Ubuntu を使用して、yasm でアセンブルし、プログラムを実行しています。機能しているコードがありますが、vm のオーバーヘッドが実行のタイミングに問題を引き起こしていると思います。私たちはスレッド化されたプログラムに取り組んでいます。

ネイティブの win7 インストールでプログラムをアセンブルして実行したいのですが、リンク エラーが発生します。Windowsで使用しているコマンドは次のとおりです。

組み立てますが、リンクするとhw12.obj: file not recognized: File format not recognized

バージョン情報は次のとおりです。

関連する質問です。問題が解決するかどうかはわかりません（解決しないと思います）：

私は現在、定数と syscall コードをハードコーディングしていますsection .data。参照用のコードは次のとおりです。

私の教授は、これらすべてを既に含むファイルがあると述べていましたが、それを含めることができましたが、その方法については言及していませんでした. 私はそのようなことを行う方法を見つけることができませんでした。また、syscode を検索する必要がないように、win と同等のものも知りたいです。別名、Windowsでアセンブルするためにインクルードを変​​更するだけです。

私はアセンブリプログラミングで新しいことを始めています。下に表示されているコードを書きました。これは、アセンブリでバブルソートすることを目的としています。しかし、ヤムでコンパイルすると、「セグメンテーション違反 (コアダンプ)」というエラーが発生しました。ところで、私は自分のプログラムを実行しています

Ubuntuシステムで。まず第一に、あなたが助けてくれてありがとう、私は自分のプログラムを書き直しました。しかし、私はまだ同じエラーが発生しました。gdb のおかげで、配列からのスタック オーバーフローであることがわかりました。しかし、私はそれを修正する方法がわかりません。以下の 2 行をコメントアウトすると、正常に動作します。

これで残りはすべて揃った。

Just-In-Time コンパイラを作成しようとしていますが、動作させたくないコードがあります。私のプラットフォームは x86-64 ubuntu です。

yasm で次のコードを記述しました。

したがって、正しく理解できれば、これはAstdout に書き込まれるはずです。今、私はこのコードをコンパイルします

これにより、次のマシンコードが生成されました。

次に、結果のコードを C++ で読み取り、次のように呼び出します。

C++ の部分は、単純な算術演算で既に試しており、うまく機能したので問題ないと思います。

とにかく、セグメンテーション違反はありません。コードは実行されているようですが、何も起こりません。stdout には何もありません。

何かアドバイス？

//編集:完全な C++ コード:

CMake 3.4.1 を使用して、Visual Studio 2013 64 ビット C++ ソリューションを生成およびビルドしています。プロジェクトの 1 つには、VisualStudio で yasm アセンブラーを lib としてコンパイルする .asm ファイルも含まれています。これらのファイルに yasm を使用するように CMake を構成するにはどうすればよいですか?設定方法の例を含むドキュメントは見つかりませんでした。

64 ビット レジスタを使用し、(私が思うに) 適切なコマンドをアセンブルしてリンクしているにもかかわらず/usr/include/asm/unistd_32.h、ではなくからのシステムコール番号を使用する必要があるのはなぜだろうと思っています。 unistd_64.h

ファイルhellow.asmは（64.hのものを使用すると機能しないため、32.hのように書き込みに4、終了に1を使用していることを認識しています。書き込みは1であり、 exit 60 を試してみましたが、結果はありませんでした。)

file実行可能ファイルとオブジェクトファイルで次のように返されます。

オブジェクトファイル:ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

実行可能：ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

私/usr/include/unistd.hは：

この投稿をここまで読んだなら、私の "hello world" プログラムが代わりに "hey you beauty" と言っている理由がわかるはずです: 私のコンピューターが、バーにいる汚れた老人のように私に話しかけてくるのが好きです。 .

アセンブラーを学習しようとしていますが、このチュートリアルで問題が発生しています http://www.tutorialspoint.com/assembly_programming/assembly_file_management.htm

ファイルを書き出すときを除いて、うまく機能します。ではなく、myfile.txtという名前になっていmyfile.txtWelcome to Tutorials PointWritten to file?ます。

理由が分からないようです。チュートリアルからソースを削除しましたが、同じことを行います。

誰かが理由を教えてもらえますか?

nasm 2.12.02 を使用しています。yasm 1.2.0 でも試してみたので、アセンブラー コードが原因であると確信しています。

私は構築して実行していますOpenSUSE Linux 3.16.7-35-default #1 SMP Sun Feb 7 17:32:21 UTC 2016 (832c776) x86_64 x86_64 x86_64 GNU/Linux

アセンブリ ( でコンパイル) を/でyasmコンパイルされたオブジェクトと結合しようとしています。これは、最終的な実行可能ファイルにリンクされている に ( で)リンクしようとしています。msvccl.exelink.exe.dll

ソースからオブジェクト ファイルを作成することも、これらのオブジェクトから dll を作成することも、まったく問題なく動作します。

最後のステップで、 を.dll実行可能ファイルにリンクすると、次のエラーが発生します。

私はCを使用しています.Win64には名前マングリングがありませんが、複数のスキーム（_xxx_xxxxまたはなど__imp_xxx_xxxx）を試しました。

オブジェクト ファイルを調べると、dumpbin.exeすべてのシンボルが明らかになります。

しかし、からエクスポートされたシンボルにはありません.dll:

.dllを使用して、宣言を 内でエクスポートされたものとしてマークしましたが__declspec(dllexport)。

リンカーを満足させ、シンボルが実際にそこにあることを彼に伝える方法はありますか?