99.99%可能性,KEIL BUG

只看该作者 · 2011-9-26 17:14

keil有bug很正常，以前经常遇到，

只看该作者 · 2011-9-26 17:19

Keil 4.x的版本确实有显示的bug，调试的时候变量窗口不对，但实际执行都是对的。楼主这点代码量太少，不足以判定bug在哪里。

只看该作者 · 2011-9-26 20:23

我感觉不是BUG，呵呵 X=4*Y+Z，如果是BUG，那么Z应该是多少呢？

只看该作者 · 2011-9-26 21:15

这不能算是一个 bug, 只是超出人们的预期而已。整数除法有着舍入方向的问题，向上舍入与向下舍入都不能说成是错误。
很多编译器，特别是没有高速硬件除法cpu上的编译器，会对 /2, /4, /8等等优化，用移位来代替真正的除法。如果Keil 对字节 /4 除法使用移位而不是内嵌硬件除法，这也不能算是一个 bug, 毕竟两个移位操作还是比一个硬件除法快。

只看该作者 · 2011-9-26 21:43

这个 BUG 足以让航天飞机在空中解体。

只看该作者 · 2011-9-27 00:25

这不能算是一个 bug, 只是超出人们的预期而已。整数除法有着舍入方向的问题，向上舍入与向下舍入都不能说成是错误。
很多编译器，特别是没有高速硬件除法cpu上的编译器，会对 /2, /4, /8等等优化，用移位来代替真正 ...
highgear 发表于 2011-9-26 21:15

没开优化也用移位，实在是不应该。。。。

只看该作者 · 2011-9-27 02:10

楼上，C的标准并没有规定负整数除法的方向，实际上，早期的标准声明负整数除法的舍入方向取决与cpu 以及编译器。
因此，-5/4的结果为-1还是-2都不能算是一个错误，都是正确的，只要遵循了同一个方向的舍入。很多的c/c++书中特地对负整数除法的舍入方向提出了告诫。

1万 · 2011-9-27 05:12

highgear老师解释的透彻，学习了

1万 · 2011-9-27 05:25

本帖最后由 Cortex-M0 于 2011-9-27 05:29 编辑

keil 这确实不能算是一个 bug, 只是超出人们的预期而已。
整数除法有着舍入方向的问题，向上舍入与向下舍入都不能说成是错误。

1万 · 2011-9-27 08:00

楼上，C的标准并没有规定负整数除法的方向，实际上，早期的标准声明负整数除法的舍入方向取决与cpu 以及编译器。
因此，-5/4的结果为-1还是-2都不能算是一个错误，都是正确的，只要遵循了同一个方向的舍入。很多的c/ ...
highgear 发表于 2011-9-27 02:10

还不能算BUG算什么？我看你都没仔细看大家的讨论！是不是BUG关键在于：
| -5/4 | > | -5/3 |

1万 · 2011-9-27 08:14

上面大家有很多人认为这不是个BUG,也许有些道理
但请大家再去测试以下的代码,
signed char x,y,z,a;
z = -5;
a = 4;
x = z/a;
y = z%a;
如果按以上有些理论,至少KEIL应该结果一样
但真正的结果呢

1万 · 2011-9-27 08:21

还有
试试
signed char x;
x = -5/4

1万 · 2011-9-27 08:21

上面大家有很多人认为这不是个BUG,也许有些道理
但请大家再去测试以下的代码,
signed char x,y,z,a;
z = -5;
a = 4;
x = z/a;
y = z%a;
如果按以上有些理论,至少KEIL应该结果一样
但真正的结果呢 ...
ayb_ice 发表于 2011-9-27 08:14

只因为 z/a用的是库函数，而不是移位运算！
如果库函数也遵循同样的舍入方向也没问题，看到这个问题我的第一想法就是:是不是舍入方向问题？
所以才做了这些测试，关键就是 z(-5)/4 != z(-5)/3!

只看该作者 · 2011-9-27 08:27

本帖最后由 ccmc 于 2011-9-27 08:35 编辑

楼上，C的标准并没有规定负整数除法的方向，实际上，早期的标准声明负整数除法的舍入方向取决与cpu 以及编译器。
因此，-5/4的结果为-1还是-2都不能算是一个错误，都是正确的，只要遵循了同一个方向的舍入。很多的c/ ...
highgear 发表于 2011-9-27 02:10

我知道的是，C和C++向0方向舍入。

没啥好争的了，大家都清楚，是优化导致C51编译器采用了移位方法进行运算，导致了“非预期的结果”。这本身就是不应该的事情。而同样的ARM编译器却没有类似情况。大家使用int型去试试就知道了。

同时这也告戒我们，编写程序要严谨，为避免出现可能的“非预期结果”，可以参照13楼的方法，杜绝摸棱两可的不同结果，这才是编程的思想。

1万 · 2011-9-27 08:29

还有
试试
signed char x;
x = -5/4
ayb_ice 发表于 2011-9-27 08:21

x = -5/4就不关keil事了，这个时候（-5/4）是PC机计算的。

只看该作者 · 2011-9-27 08:30

也许真的不是BUG，只是超出了人们的预期而已，设计的人没想到会有人直接把立即数写到程序里；
就好像设计火车的人们根本没预期天上会下雨打雷；是在是属于使用错误；

1万 · 2011-9-27 08:38

也许真的不是BUG，只是超出了人们的预期而已，设计的人没想到会有人直接把立即数写到程序里；
就好像设计火车的人们根本没预期天上会下雨打雷；是在是属于使用错误； ...
mcu5i51 发表于 2011-9-27 08:30

这个说法太牵强了，每个BUG都是超出设计者的预期的！
而且错不在移位运算，假如库函数用的也是同一个舍入方向那就不是BUG了!而偏偏它们用的是不同的舍入方向。

1万 · 2011-9-27 08:54

BUG就是BUG
至少你KEIL C51应该保持一致
这个不是BUG,那另外的不一致的那个就是BUG

1万 · 2011-9-27 08:56

也许真的不是BUG，只是超出了人们的预期而已，设计的人没想到会有人直接把立即数写到程序里；
就好像设计火车的人们根本没预期天上会下雨打雷；是在是属于使用错误； ...
mcu5i51 发表于 2011-9-27 08:30

开玩笑都是
下面的程序难道大家没有用过
x/10
x%10
x/16
x%16

只看该作者 · 2011-9-27 09:00

t.jm:
这是优化所产生的问题， y = x/4 与 y = x/a 的结果不同并不出乎意料。很多编译器对 /2, /4, /8 等常数分母都是直接使用移位而不是除法，这也不是超出预期，反而是在预期之内。
对于分子分母都是变量，keil 中 -5/4 = -5/3 的结果都是-1.

99.99%可能性,KEIL BUG

技术奇才奖章

以坛为家

湍急之河流

社区建设奖章

技术导师奖章

突出贡献奖章

沉静之湖泊

十世金身

甘甜之泉水

七世轮回

欢快之小溪

核心会员奖章

坚毅之洋流

技术高手奖章

荣誉元老奖章

技术领袖奖章

缘定三生