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

x86 CPU特権リングに関するいくつかの質問： リング1と2がほとんどのオペレーティングシステムで使用されないのはなぜですか？それは他のアーキテクチャとのコードの互換性を維持するためだけですか、それとももっと良い理由がありますか？ これらのリングを実際に使用するオペレーティングシステムはありますか？それとも完全に未使用ですか？

102 x86  cpu  privileges 

だから私は次のレジスタとその使用法が何であることになっているのか知っています： CS =コードセグメント（IPに使用） DS =データセグメント（MOVに使用） ES =宛先セグメント（MOVSなどに使用） SS =スタックセグメント（SPに使用） しかし、以下のレジスタが何のために使用されることを意図していますか？ FS = "ファイルセグメント"？ GS = ??? 注：私は特定のオペレーティングシステムについて尋ねるのではなく、CPUが何のために使用することを意図していたかについて尋ねます。

102 assembly  x86  cpu-architecture  cpu-registers  memory-segmentation 

アセンブラについて読んでいると、プロセッサの特定のレジスタをプッシュし、後でもう一度ポップして以前の状態に戻すと書いている人によく出くわします。 どうすればレジスターをプッシュできますか？どこにプッシュされますか？なぜこれが必要なのですか？ これは、単一のプロセッサ命令に要約されますか、それとももっと複雑ですか？

101 assembly  x86  stack  terminology 

私は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 

私はアセンブリ言語の初心者ですが、コンパイラーによって生成されたx86コードは、EBP他の何かのためにレジスターを使用できるリリース/最適化モードでも、通常フレームポインターを保持していることに気づきました。 フレームポインターがコードのデバッグを容易にする理由、およびalloca()関数内で呼び出された場合に必要になる理由を理解しています。ただし、x86には非常に少数のレジスターがあり、そのうちの2つを使用してスタックフレームの場所を保持する場合、私には意味がありません。最適化されたリリースやリリースビルドでも、フレームポインターを省略することが悪い考えと見なされるのはなぜですか？

94 performance  assembly  x86 

持っている起動可能なx86ディスクのMBR（最初の512バイト）を分解したいのですが。MBRを使用してファイルにコピーしました dd if=/dev/my-device of=mbr bs=512 count=1 ファイルを逆アセンブルできるLinuxユーティリティの提案はありますmbrか？

91 linux  assembly  x86  x86-16  mbr 

この質問は、主題に関する優れた無料情報の空白を埋めることを目的としています。 私は良い答えが1つの大きなSOの答え、または少なくともいくつかの答えに収まると信じています。 主な目標は、完全な初心者に十分な情報を提供して、自分でマニュアルを読み、ページングに関連するOSの基本的な概念を理解できるようにすることです。 推奨ガイドライン： 答えは初心者に優しいはずです： 具体的ですが、おそらく単純化された例が非常に重要です 示された概念の適用は大歓迎です 有用なリソースを引用することは良いことです OSがページング機能をどのように使用するかについての小さな余談は大歓迎です PAEおよびPSEの説明は大歓迎です x86_64への小さな余談は大歓迎です 関連する質問と、なぜ私はそれらが偽物ではないと思うのか x86ページテーブルはどのように機能しますか？：タイトルはこの質問とほとんど同じですが、本文はcr3およびTLBに関連する特定の質問をします。その質問はこれのサブセットです。 x86仮想化はどのように機能しますか：本体はソースのみを要求します。

90 x86  paging  virtual-memory 

Windowsでのアセンブリの基本的なものを書きたかったのですが、NASMを使用していますが、何も動作しません。 WindowsでC関数を使用せずにHello Worldを作成してコンパイルする方法は？

89 winapi  assembly  x86  nasm 

Pentium Pro（P6マイクロアーキテクチャ）から、Intelはマイクロプロセッサを再設計し、古いCISC命令の下で内部RISCコアを使用しました。Pentium Pro以降、すべてのCISC命令は小さな部分（uops）に分割され、RISCコアによって実行されます。 当初、Intelが新しい内部アーキテクチャを非表示にし、プログラマに「CISCシェル」の使用を強制することを決定したことは明らかでした。この決定のおかげで、Intelは互換性を損なうことなくマイクロプロセッサアーキテクチャを完全に再設計することができました。それは合理的です。 しかし、私は1つのことを理解していません。なぜ、Intelは内部RISC命令セットを何年も隠しているのですか？古いx86CISC命令セットを使用するように、プログラマーにRISC命令を使用させないのはなぜですか？ Intelが下位互換性を長期間維持している場合（64ビットモードの隣に仮想8086モードがまだあります）、CISC命令をバイパスして、RISCコアを直接使用するようにプログラムをコンパイルできないのはなぜですか？これにより、x86命令セットをゆっくりと放棄する自然な方法が開かれますが、これは最近非推奨になっています（これが、Intelが内部でRISCコアを使用することを決定した主な理由ですよね？）。 新しいIntelの「Corei」シリーズを見ると、AVX、SSE4などを追加したCISC命令セットのみが拡張されていることがわかります。

89 x86  intel  cpu-architecture 

誰かが次のアセンブリコードが何をするのか説明できますか？ int 0x80

89 assembly  x86 

x86のアセンブリコードでは、あるJEとJNEまったく同じJZとJNZ？

88 assembly  x86 

私はgdbのターゲット実行可能ファイルの外にいて、そのターゲットに対応するスタックさえ持っていません。私はx86アセンブリの専門家ではないので、とにかくシングルステップでアセンブリコードで何が起こっているのかを確認したいと思います。残念ながら、gdbはこの単純なアセンブリレベルのデバッグを行うことを拒否します。適切なブレークポイントで設定および停止できますが、シングルステップ以降を実行しようとすると、gdbは「現在の関数の境界が見つかりません」というエラーを報告し、EIPは変更されません。 追加の詳細： マシンコードはgccasmステートメントによって生成され、objdump -dの出力から、それが実行されているカーネルメモリの場所にコピーしました。ローダーを使用してオブジェクトコードを再配置されたアドレスにロードする簡単な方法は気になりませんが、ロードはカーネルモジュールで実行する必要があることに注意してください。 別の代替策は、gdbに提供する偽のカーネルモジュールまたはデバッグ情報ファイルを作成して、この領域がプログラムコード内にあると信じ込ませることだと思います。gdbは、カーネル実行可能ファイル自体で正常に機能します。 （本当に知りたい人のために、実行時にVMware VM内のLinuxカーネルデータスペースにコードを挿入し、VMwareWorkstationの組み込みgdbスタブを介してカーネルをリモートデバッグするgdbからデバッグしています。カーネルを記述していないことに注意してください。悪用;私はプロトタイプを書いているセキュリティ大学院生です。） （アセンブリ内の各命令にブレークポイントを設定できます。これは機能しますが、x86アセンブリ命令のサイズが異なり、再起動するたびにアセンブリの場所が変わるため、しばらくするとかなり面倒になります。）

88 linux  assembly  gdb  x86  linux-kernel 

どういうrep; nop意味ですか？ pause指導と同じですか？ rep nop（セミコロンなし）と同じですか？ 簡単なnop指示との違いは何ですか？ AMDプロセッサとIntelプロセッサでは動作が異なりますか？ （ボーナス）これらの指示の公式文書はどこにありますか？ この質問の動機 別の質問のコメントでいくつか議論した後rep; nop;、x86（またはx86-64）アセンブリで何を意味するのかわからないことに気付きました。また、ウェブ上で適切な説明を見つけることができませんでした。 これrepは、「次の命令cx回数を繰り返す」ことを意味するプレフィックスであることを私は知っています（または、少なくとも、古い16ビットx86アセンブリではそうでした）。これによると、ウィキペディアでの集計表、それが思わrepだけで使用することができmovs、stos、cmps、lods、scas（多分、この制限は、新しいプロセッサ上で削除されました）。したがって、rep nop（セミコロンなしで）nop操作cx時間を繰り返すと思います。 しかし、さらに調べてみると、さらに混乱しました。これは、と思われるrep; nopとpause まったく同じオペコードにマップし、pauseちょうどより少し異なる振る舞いを持ってnop。2005年からのいくつかの古いメールは異なることを言っていました： 「力を入れすぎないように」 「2バイトのエンコーディングだけで「nop」と同等です。」 「それはIntelの魔法です。それは「いや、でも他のHT兄弟を走らせて」のようなものです。」 「Intelでは一時停止し、Athlonでは高速パディングです」 これらの異なる意見で、私は正しい意味を理解することができませんでした。 これは、Linuxカーネル（i386とx86_64の両方）でこのコメントとともに使用されています。同じコメントで、BeRTOS/* REP NOP (PAUSE) is a good thing to insert into busy-wait loops. */でも使用されています。

86 assembly  x86  x86-64  cpu  machine-code 

次のコードをコンパイルします。 double getDouble() { double value = 2147483649.0; return value; } int main() { printf("INT_MAX: %u\n", INT_MAX); printf("UINT_MAX: %u\n", UINT_MAX); printf("Double value: %f\n", getDouble()); printf("Direct cast value: %u\n", (unsigned int) getDouble()); double d = getDouble(); printf("Indirect cast value: %u\n", (unsigned int) d); return 0; } 出力（MSVC x86）： INT_MAX: 2147483647 UINT_MAX: …

85 c  visual-c++  casting  x86  floating-point 

私は、RAMが単一の物理ページによってのみ裏付けられているLinux VMを実行できるかどうかを把握しようとしています。 これをシミュレートするために、KVMのネストされたページフォールトハンドラーを変更して、現在処理されているページフォールトに対応するものを除くすべてのネストされたページテーブル（NPT）エントリから現在のビットを削除しました。 Linuxゲストを起動しようとしたときに、次のようなメモリオペランドを使用するアセンブリ命令に気づきました。 add [rbp+0x820DDA], ebp 命令を含むページとオペランドで参照されるページ（この例では[rbp+0x820DDA]）の現在のビットを復元するまで、ページフォールトループが発生します。 なぜそうなのかと思います。CPUはメモリページに順次アクセスするべきではありませんか。つまり、最初に命令を読み取ってから、メモリオペランドにアクセスしますか？または、x86では、命令ページとすべてのオペランドページに同時にアクセスできる必要がありますか？ AMD Zen 1でテストしています。

64 assembly  x86  paging  virtualization  kvm