8085-进位旗的奇怪行为

Question

I正在使用GNUSim8085 (在训练器上的结果也一样)

我已经熟悉了ADC指令，下面的说明似乎不像我想的那样工作。

stc  ;to make sure carry is set

mvi a,00h  
mvi b,0ffh          

adc b

hlt

我预期会设置进位标志，因为我们正在添加11111111+00000000+00000001，这样显然会产生一个进位标志，但没有设置进位标志。为什么这是这样的。你能解释一下吗。

为什么在下面的代码中生成进位，而不是在上面的代码中生成：

stc  ;to make sure carry is set

mvi a,7dh  ; 7dh  ==    01111101
mvi b,c8h  ; c8h  ==    11001000        

adc b

hlt

Answer 1

继续我之前的评论:它是_eef_inst_func_add_with_carry_i函数中的一个bug，它位于src/8085-instructions.c的GNUSim8085源代码中。下面是来自master分支离开GitHub的当前源代码(Re.88a6040a2b7f153ff97e2c3026145814f7fc39)：

eef_data_t data_1;

/* I'm not sure abt the new code
 * Old code:
 if (op == '+')
 data_1 = data + sys.flag.c;
 else
 data_1 = data - sys.flag.c;
*/
data_1 = data + sys.flag.c;

/* check for flags */
sys.flag.c = 0; 
sys.flag.c = (_eef_is_carry (sys.reg.a, data, op)
              || _eef_is_carry (sys.reg.a, data_1, op));

…

见第326行。这里。

让我们暂时忽略：

• 冗余分配sys.flag.c = 0;
• 指向与SBB指令相关的早期错误的注释。

eef_data_t是guint8的别名，代码检查data或data_1 (即data + sys.flag.c )的添加是否转换为eef_data_t、累加器溢出，以及相应地设置进位标志。

如果是data == 0xff，那么data_1 == 0是因为data + sys.flag.c == 0x100，但是结果在赋值中被转换回8位无符号整数，失去了最重要的位。然后，eef_is_carry用于检查0 + 0xff或0 + 0是否溢出，两者都不是。因此，清除进位。但是，实际添加的当然是0 + 0x100，它肯定会溢出。

我坚持我以前的说法，这是一个错误。不设置进位标志是不合逻辑的，尽管根据公认的加法规则，在数学上应该有进位。8085规范没有描述这种特殊情况。而且，即使例外是有效的，你不同意它应该有详细的记录吗？

最重要的是，在普通用例中，行为类似的ADC不能可靠地工作。硬件一级的ADC指令甚至存在的原因是相对于使用比较和分支这种丑陋的选择，增加了多字加法的速度(并减小了代码大小)。如果ADC没有正确地检测到所有的进位条件，那么该命令在实现通用多字加法方面是不够的，甚至是无用的。在我看来，有一个坏的ADC是没有意义的，而一点也没有。(正如我前面提到的，由于这个错误，ADC也违反了交换性a + b == b + a定律。)

尽管如此，你指出你的教练董事会表现出了同样的行为。我没有8085教练板，而你没有说你有哪一个，所以我不能复制这种行为。我认为你的教练板有可能和GNUSim8085有同样的错误。取决于板上是否有8085的克隆，这甚至可能是"bug兼容性错误“与GNUSim8085的不幸情况。不过，这都是目前的猜测。