DOSBox上の8086アセンブリ：idiv命令のバグ？

Question

は、私は私の友人は彼のプログラムをデバッグを支援し、私たちもここで発生する問題にそれを絞り込む：TASM 4.1でそれを組み立てた後

.MODEL small 
.STACK 16 
.CODE 
start: 
    mov ax, 044c0h 
    mov bl, 85 
    idiv bl 
exit: 
    mov ax, 4c00h 
    int 21h 

end start 

、およびDOSBoxを0.74上でそれを実行している、それがに入ります無限ループターボデバッガでそれを調べると、何らかの理由でcsとipレジスタが変更され、2つの一見無作為な命令がそれらを復帰してidiv行を指すように復帰させた後、再び無限に実行することがわかります。

誰でもこれについて説明しますか？

Answer 1

この質問は、他の部門関連の障害のバリエーションです。

• idiv/div問題：Zero edx first, or sign-extend eax into it.x86 tag wikiは、いくつかの追加のリンクがあります。 32b divは、64b/32b => 32b商が32bに実際には収まらない場合には障害が発生します。

---

あなたのデバッガがにジャンプするようだどうやらランダムコードは、算術演算例外ハンドラ（ゼロ除算なども同じもの）です。あなたのコードにDivision Overflowが発生しています。あなたは16ビット/ 8ビットIDIVをやっています。ドキュメントから：

AXはr/m8で符号分割し、結果はAL：←Quotient、AH←Remainに格納されます。

ます（あなたのケースBLに）8ビットの除数と分割するための商の範囲は-128~ + 127であることがわかります。 044c0h IDIV 85は207（10進数）です。 207は符号付き8ビットレジスタに収まらないため、除算のオーバーフローと予期しない問題の原因が発生します。

これを解決するには、最大16ビットの除数に移動できます。だから、除算をBX（16ビットレジスタ）に置くことができます。それはmov bx, 85です。残念ながら、それほど単純ではありません。 16ビットの除数を使用する場合、プロセッサは被除数がDXの上位16ビットで32ビットであり、下位16ビットがAXであるとみなします。

符号付き除算DX：AXはr/m16で、結果はAX←Quotient、DX←残りに格納されます。

この問題を解決するには、AXの16ビット値を符号拡張する必要があります。これは、命令をAXに配置した後に使用する必要があるため、単純です。命令セットリファレンスから

DX：AX←AXの符号拡張。効果的

AXの最上位ビット（MSB）が0 DXある場合、MSBは、次に1 DXが0FFFFH（いずれかに設定されたすべてのビット）になる場合は0となるであろう。数字の符号ビットはMSBです。そう

mov ax, 044c0h 
cwd    ; Sign extend AX into DX (DX:AX = 32-bit dividend) 
mov bx, 85   ; Divisor is 85 
idiv bx   ; Signed divide of DX:AX by BX