PICC 16 v9.70 pro发现BUG,郁闷

2020-02-09 11:25发布

有个习惯,新的C环境我都会测一下对于数据运算的支持,最怕的是类型隐式转换,这次第一个测试就出了问题,
PIC16F887, PICC16 v9.70(用的是坛里的破解)
void main(void)
{
        unsigned int a,b;
        a=258;
        a -=256;
        b=a>>1;
        while(b);
}

仿真结果如下:

(原文件名:test.JPG)

a -= 256, 结果应当是2,但窗口中出现了0xff02!
有几点都不妥当:
1. clrf 0x3. 这条指令应该不妥吧? 据说操作status得不到预期结果
2.a-=256汇编出来的结果 btfss 0x3,0 这是有什么根据呢? 就是前面clrf 0x3结果正确, 但我只减256,没要求减C啊?

另外, a-=257是不会有错的,因为它编译出来如下:
;a -= 257;
  07EF    3001     MOVLW 0x1
  07F0    02F2     SUBWF 0x72, F
  07F1    1C03     BTFSS 0x3, 0
  07F2    03F3     DECF 0x73, F
  07F3    02F3     SUBWF 0x73, F

好像这个问题是编译器太聪明了,但是也没优化成直接赋值
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
该问题目前已经被作者或者管理员关闭, 无法添加新回复
19条回答
jacky1982512
1楼-- · 2020-02-10 13:38
MPLAB IDE v8.53  最新版的是什么编译器;
是不是也是9.70
dahai168
2楼-- · 2020-02-10 13:56
 精彩回答 2  元偷偷看……
zhuyi
3楼-- · 2020-02-10 15:48
回复【11楼】micropower 流浪的飘云
-----------------------------------------------------------------------

呵呵,我预期的效果是认为 clrf 0x3 它应该清掉C(现在看来它的目的不是这样,可能只是切换BANK而已), 因为后面没做可以改变C标记的操作就直接进行 BTFSS 0X3,0 了这条指令,那你认为它是判断谁的借位呢?
所以我得出的结论是for PIC10/12/16 MCUs (PRO Mode)V9.70(和谐版)不妥(感觉有点太聪明了), 其实45天版得出的也是这个结果,如果不优化太高等级就不会出错
yf_888
4楼-- · 2020-02-10 17:47
我一直用picc9.50p12 和 IAR的EWPICv2.31, 几年下来一直都挺好,没有发现问题,这之前的PICC版本发现过一些问题包括picc8.05
camtime
5楼-- · 2020-02-10 23:22
不是吧,如果真是这样,这BUG真是太过分了。
flyunlimit
6楼-- · 2020-02-11 05:21
用汇编的飘过,当初学PIC没用C真是明知之举。

一周热门 更多>