問題タブ [yasm]

次のアセンブリ プログラムがあるとします。

Yasm の出力:

なぜここにコンマが必要なのですか? NASM は喜んでこれを組み立てます。

現在、独自のブートローダーを構築しようとしていますが、奇妙なことに気付きました。

以下のコードが、マークされた NOP コマンドを使用せずに NASM または Yasm でアセンブルされると、次の CALL がバイナリから欠落します。NOP が含まれていると、CALL は正しくアセンブルされますが、op コード 0x90 (NOP) はバイナリに存在しません (NOP の性質により、後で理解できます)。

「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 行をコメントアウトすると、正常に動作します。

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