使用以下代码片段在EMU8086上进行测试:
MOV CX, 1527H
SUB CX, 44H
仿真程序显示AF为0。
1527
- 44
========
14E3
用手减法时,我们得到7-4= 3,这里没有问题。然后是2-4,然后我们不得不从下一个小食客那里借来。根据我的理解,AF应该是1。
发布于 2021-06-01 05:52:59
AF是根据第3位到第4位的进位(或借用)来设定的,即穿过最低/最不重要的咬边,一个位于AL/BL/CL/DL的中间,而不是AX的中间。(由于每一个十六进制数字代表一小部分,所以从最低的十六进制数字到第二低的十六进制数字。)
就像你说的,7h - 3h
不借钱,所以AF=0。
在字节操作数大小的上下文中,把AF描述为“半带”标志是有意义的,因为字节内只有一个咬边,而执行位置只有一半。
字操作数大小(在386和x86-64上较大)仍然从位3->4设置AF,而不是从操作数大小的中间设置,或者在任何其他位位置之间设置进位。
这是因为它分别用于打包和解压BCD操作,如DAA和AAA。请注意,AAA (用于在add ax, cx
之后使用或任何具有两个小数位的内容,解压缩成单独的字节)取决于AF检测低4位的执行情况。在这种情况下,永远不会有从位#7到位#8的进位(跨越字节边界),例如,0x0909
+ 0x0909
生成0x1212
,其AF设置进位来自9+9 = 12h
,但在字节边界没有从09h + 09h = 12h
进行进位。
AAA
并没有以不同的方式处理解压缩(检查AL的高比特),而是使用了与DAA (检查AF和低比特al
大于9)基本相同的逻辑-- https://www.felixcloutier.com/x86/aaa#operation。
有趣的事实:您可以使用use DAS
to save a couple bytes in int -> ASCII-hex conversion以及cmp和sbb,因为'9'
和'A'
的ASCII代码以及DAS的条件AL-=6
和其他行为之间的距离,所以完全的黑客/滥用才能正常工作。
https://stackoverflow.com/questions/67783284
复制相似问题