これはシステムに関する低レベルの質問です。
プロテクト モードからリアル モードに戻ろうとしているので、32 ビット コードと 16 ビット コードを混在させる必要があります。ちょっとした背景情報として、私のコードは GRUB の起動直後にこれを行っているので、できることとできないことを教えてくれる厄介なオペレーティング システムはありません。
とにかく、アセンブリで [BITS 32] と [BITS 16] を使用して、どのタイプの操作を使用する必要があるかを nasm に伝えますが、コードをテストすると、bochs を使用して、いくつかの操作で bochs が実行されていないコードのように見えます私が書いた。0x66アセンブラがエクストラと's に固執しているように見え、0x67bochs を混乱させます。
では、同じファイルに 32 ビットと 16 ビットのコードが混在している場合に、nasm でコードを正常にアセンブルするにはどうすればよいでしょうか? 何か裏技あるの？
問題は、記述子テーブルを正しく設定していないことにありました。私は 1 ビット間違って反転していたので、16 ビット モードに移行する代わりに 32 ビット モードに移行しました (たまたま 1 メガの制限があるセグメントを使用)。
提案をありがとう！
テリー
0x66 と 0x67 は、次のオペコードをデフォルト以外のビット数として解釈する必要があることを示すために使用されるオペコードです。より具体的には、（このリンクによると）、
「NASM が BITS 16 モードの場合、32 ビット データを使用する命令には 0x66 バイトがプレフィックスとして付けられ、32 ビット アドレスを参照する命令には 0x67 プレフィックスが付けられます。BITS 32 モードでは、その逆が当てはまります: 32 ビット命令プレフィックスは必要ありませんが、16 ビット データを使用する命令には 0x66 が必要であり、16 ビット アドレスで動作する命令には 0x67 が必要です。」
これは、障害があるのは bochs であることを示唆しています。
これが低レベルだなんて冗談じゃない！
生成されたオペコード/オペランドをチェックして、nasm が BITS ディレクティブを正しく尊重していることを確認しましたか? また、ジャンプ ターゲットが正しいことを確認してください。nasm が間違ったオフセットを使用している可能性があります。
nasm のバグでない場合は、bochs にバグがある可能性があります。人々が 32 ビット モードから 16 ビット モードに頻繁に切り替えるとは思えません。
リアル モードの場合、既定のサイズは暗黙的に 16 ビットなので、BITS 16 モードを使用する必要があります。このように、32 ビットのオペランド サイズが必要な場合は 0x66 プレフィックスを追加し、32 ビット アドレス サイズの場合は 0x67 プレフィックスを追加します。
Intel IA-32 Software Developer's Guide、Volume 3、Chapter 16 (MIXING 16-BIT AND 32-BIT CODE; 章番号は本の版によって異なる場合があります) を参照してください。
実アドレス モード、仮想 8086 モード、および SMM はネイティブ 16 ビット モードです。
BITS 32 ディレクティブは、プロテクト モードまたはロング モード以外で使用する場合にのみ、アセンブラーを混乱させます。