問題タブ [x86-64]

より高速な x86_64-linux 用の glibc の libm (およびヘッダー?) のドロップイン代替品はありますか?

これらは「ProgrammerVisible」 x86-64レジスタです。

_{（ソース：usenix.org）}

見えないレジスタはどうですか？ちょうど今、MMUレジスタ、割り込み記述子テーブル（IDT）がこれらの非表示レジスタを使用していることを知りました。私はこれらのことを難しい方法で学んでいます。全体像を一度に知ることができるリソース（本/ドキュメントなど）はありますか？

私はプログラマーの目に見えるレジスターを知っており、それらを使ったプログラミングに慣れています。見えないレジスタとその機能について知りたいだけです。全体像を把握したい。この情報はどこで入手できますか？

編集：

全体像を把握したい。この情報はどこで入手できますか？

これらは、これらすべての低レベルの詳細を理解するのに役立った2冊の本です。

1. コンピュータの組織と設計の基礎〜Sivarama P. Dandamudi-1版（2003）
2. コンピューターの構成と設計：ハードウェア/ソフトウェアインターフェイス、第4版、〜David A. Patterson、John L. Hennessy

動的言語 VM 実装に関する JIT 設計を研究しています。私は 8086/8088 の頃からあまり組み立てを行っていません。ほんの少しだけです。

私が理解しているように、x86 (IA-32) アーキテクチャには、今日でも以前と同じ基本的な制限付きレジスタ セットがありますが、内部レジスタの数は大幅に増加していますが、これらの内部レジスタは一般的には利用できず、レジスタの名前変更で使用されます。他の方法では並列化できないコードの並列パイプライン化を実現します。私はこの最適化をかなりよく理解していますが、これらの最適化は全体的なスループットと並列アルゴリズムに役立ちますが、制限されたレジスターセットがまだ残っているため、x86 でレジスターが 2 倍または 4 倍になると、レジスターの流出オーバーヘッドが増加します。通常の命令ストリームでは、プッシュ/ポップ オペコードが大幅に少ない可能性があります。または、私が気付いていないこれを最適化する他のプロセッサの最適化がありますか? 基本的に私なら

研究、またはさらに良いことに、個人的な経験への言及はありますか?

編集：x86_64には16個のレジスタがあり、これはx86-32の2倍です。修正と情報に感謝します。

画像処理を高速化するアセンブラ関数を作成しました (画像は CreateDIBSection で作成されます)。

Win32 の場合、アセンブラ コードは問題なく動作しますが、Win64 の場合、配列データにアクセスしようとするとすぐにクラッシュします。

関連情報を構造体に入れると、アセンブラー関数はこの構造体へのポインターを取得します。構造体ポインターは ebx/rbx に配置され、インデックスを使用して構造体からデータを読み取ります。

私が間違っていることは何ですか？私は Visual Studio 2008 と一緒に nasm を使用しており、Win64 では「デフォルト rel」を設定しています。

C++ コード:

アセンブラー コード:

Win32:

Win64:

JIT コンパイラでいくつかのオペコードを動的に生成しており、オペコードの配置に関するガイドラインを探しています。

1) 呼び出しの後に nops を追加することで、アライメントを簡単に「推奨」するコメントを読みました

2）並列処理のためにシーケンスを最適化するために nop を使用することについても読みました。

3) ops のアラインメントが「キャッシュ」のパフォーマンスに適していることを読みました

通常、これらのコメントは裏付けとなる参照を提供しません。ブログやコメントを読んで、「これを行うのは良い考えだ」と言うのと、特定の op シーケンスを実装するコンパイラを実際に書いて、オンラインのほとんどの資料、特にブログが役に立たないことに気付くのとは別のことです。実用化のために。だから私は自分で物事を見つけることを信じています（実際のアプリが何をするかを見るために逆アセンブルなど）。これは、外部情報が必要な 1 つのケースです。

コンパイラは通常、前の命令シーケンスの直後に奇数バイトの命令を開始することに気付きました。そのため、ほとんどの場合、コンパイラは特別な注意を払っていません。あちこちで「nop」を見かけますが、通常、nop は控えめに使用されているようです。オペコードのアライメントはどの程度重要ですか? 実際に実装に使える事例を参考にしていただけないでしょうか？ありがとう。

私は興味深い問題に直面しています.64ビットのマシンとOSを使用していることを忘れて、32ビットのアセンブリコードを書きました. 64ビットコードの書き方がわかりません。

これは、Linux 上の Gnu アセンブラー (AT&T 構文) 用の x86 32 ビット アセンブリ コードです。

さて、このコードは 32 ビット プロセッサと 32 ビット OS で問題なく動作するはずですよね? ご存知のように、64 ビット プロセッサは 32 ビット プロセッサと下位互換性があります。ですから、それも問題にはなりません。この問題は、64 ビット OS と 32 ビット OS でシステム コールと呼び出しメカニズムが異なるために発生します。理由はわかりませんが、32 ビット Linux と 64 ビット Linux の間でシステム コール番号が変更されました。

asm/unistd_32.h の定義:

asm/unistd_64.h の定義:

とにかく、直通番号の代わりにマクロを使用することは報われます。正しいシステムコール番号を保証します。

プログラムをアセンブルしてリンクして実行すると。

その印刷ではありませんhelloworld。

gdb では、次のように表示されます。

• プログラムはコード 01 で終了しました。

gdb でデバッグする方法がわかりません。チュートリアルを使用して、各ステップでレジスタをチェックする命令によってデバッグし、命令を実行しようとしました。常に「プログラムは01で終了しました」と表示されます。これをデバッグする方法を教えていただければ幸いです。

走ってみstraceました。これはその出力です：

1. write(0, NULL, 12)strace出力のシステムコールのパラメータを教えてください。
2. 正確には何が起こっているのですか？exitstatus=1 で正確に終了する理由を知りたいですか?
3. gdb を使用してこのプログラムをデバッグする方法を教えてください。
4. なぜ彼らはシステムコール番号を変更したのですか?
5. このマシンで正しく実行できるように、このプログラムを適切に変更してください。

編集：

Paul Rの答えを読んだ後。ファイルをチェックしました

私は、これらが ELF 32 ビットの再配置可能で実行可能であるべきだという彼の意見に同意します。しかし、それは私の質問に答えません。私の質問はすべてまだ質問です。この場合、正確には何が起こっているのでしょうか？誰かが私の質問に答えて、このコードの x86-64 バージョンを提供してもらえますか?

次のリンクでは、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 システム コールの規則は何ですか?

python2.6 の下に mysql-python をインストールする必要があります。mysql-python パッケージには、libpython2.6.so.1.0(64bit) に依存する python2.6-devel パッケージが必要です ネットでいくつかの python2.6-devel パッケージを見つけましたが、libpython2.6 が見つかりません サーバー アーキテクチャは x86_64 です.

誰かがこのライブラリを持っているか、どこで見つけられるか知っているかもしれません。

手伝ってくれてありがとう）

私は C++ でいくつかのパフォーマンスが重要な作業を行っています。現在、本質的に浮動小数点である問題に対して整数計算を使用しています。これにより、多くの厄介な問題が発生し、多くの厄介なコードが追加されます。

さて、浮動小数点の計算がおよそ 386 日ほど遅かったことについて読んだことを覚えています。私は (IIRC)、オプションのコプロセッサがあったと考えています。しかし、最近では指数関数的に複雑で強力な CPU が使用されているため、浮動小数点または整数の計算を行っても「速度」に違いはありませんか? 特に、実際の計算時間は、パイプラインのストールを引き起こしたり、メイン メモリから何かをフェッチしたりするようなものに比べて小さいので?

正しい答えはターゲット ハードウェアでベンチマークすることだと思いますが、これをテストするにはどのような方法がよいでしょうか? 私は 2 つの小さな C++ プログラムを作成し、それらの実行時間を Linux での「時間」と比較しましたが、実際の実行時間は変動しすぎています (仮想サーバーで実行している場合は役に立ちません)。何百ものベンチマークを実行したり、グラフを作成したりするのに 1 日を費やす以外に、相対速度を合理的にテストするためにできることはありますか? アイデアや考えはありますか？私は完全に間違っていますか？

私が次のように使用したプログラムは、決して同一ではありません。

プログラム 2:

前もって感謝します！

編集: 私が気にするプラットフォームは、デスクトップ Linux および Windows マシンで実行される通常の x86 または x86-64 です。

編集2（以下のコメントから貼り付け）：現在、広範なコードベースがあります。実際、私は「整数計算の方が速いため、float を使用してはならない」という一般化に反対しました。この一般化された仮定を反証する方法を (これが真実である場合でも) 探しています。すべての作業を行って後でプロファイリングしない限り、正確な結果を予測することは不可能であることは理解しています。

とにかく、すべての優れた回答と助けに感謝します。他に何でも自由に追加してください:)。

Linux amd64 の gdb 内から C/C++ ヒープの状態を調査しようとしていますが、これを行う良い方法はありますか?

私が試したアプローチの 1 つは「malinfo() を呼び出す」ことですが、残念ながら、gdb が戻り値を適切に処理しないため、必要な値を抽出することはできません。

接続しているプロセスのバイナリにコンパイルされる関数を簡単に作成できないため、この方法で自分のコードで mallinfo() を呼び出して値を抽出する独自の関数を簡単に実装できます。これをオンザフライで実行できる巧妙なトリックはありますか?

別のオプションは、ヒープを見つけて、malloc ヘッダー/空きリストをトラバースすることです。これらの場所とレイアウトを見つけるためにどこから始めればよいかについての指針をいただければ幸いです。

私は Google を試して、問題を約 2 時間読んでみました。いくつかの興味深いことを学びましたが、まだ必要なものが見つかりません。