新闻中心

EEPW首页>嵌入式系统>设计应用> keil大常量计算问题

keil大常量计算问题

作者: 时间:2016-11-26 来源:网络 收藏
Keil C51是与ANSI C兼容的编译器,ANSI C规范规定十进制整数常量的默认数据类型是int、long int和unsigned long int的其中一种,对给定的常量是其中的哪一种要看这个常量的实际大小,如果常数在-32768~32767之间则按int类型处理,如果按int类型处理会溢出就考虑long int或更大的数据类型unsigned long int。总之,编译器总是按尽可能的原则指定常量的类型。

但这一原则并不总能奏效,当两个常量做运算时就可能导致溢出。如:
#define SYSCLK22118400// SYSCLK in Hz (22.1184 MHz external crystal oscillator)
#define SLIDER_REST_TIME100// in ms,slider rest time
#define REST_DELAYSYSCLK * SLIDER_REST_TIME / (65536 * 1000)
unsigned char i;
i = REST_DELAY;
keilc51中运行i为0xE1,即225,并不是期望的结果22118400 * 100 / (65536 * 1000) = 33.75,取整为33。原因分析如下:
宏替换后为:i = 22118400 * 100 / (65536 * 1000);,编译器首先为22118400定义类型,因为22118400不在int的表示范围内,而在long int的范围-2147483648~2147483647内,所以22118400按long int类型处理,在做乘积运算时100被自动按long int处理,22118400 * 100将按两带符号长整型常量进行运算,运算结果仍为带符号长整型,结果写成十六进制是0x83D60000,其十进制是-2083127296,显然出现了溢出错误。keil编译器并没有给出任何错误或警告提示信息(VC++6.0还给出警告warning C4307: * : integral constant overflow),继续进行下一个运算65536 * 1000,结果为带符号长整型,十六进制为0x3E80000,十进制为65536000,最后按两长整型除法计算-2083127296 / 65536000,结果为0xFFFFFFE1,由于i为字符类型,取0xFFFFFFE1的最低有效字节为0xE1赋值给i,i的最终值为0xE1。
解决这种溢出错误的方法用C语言的一个术语就是“提升”(promotion),拿上例来说就是将22118400指定为无符号长整型,即:
#define SYSCLK22118400UL
注:虽然只要将22118400、100、65536和1000四个常数中的一个指定为无符号长整型即可得到正确的结果,但考虑到可读性及规范性,应选择大整数指定其类型。
小结:按C51编译器的默认类型整数常量运算可能出现溢出错误,对大整数应指定其数据类型以避免出现可能的运算错误。

本文引用地址://m.amcfsurvey.com/article/201611/321607.htm

转自:幽幽灵猫

http://www.cnblogs.com/civet/archive/2011/05/31/2064959.html
/////////////
近日做 射频系统,一个简单的MCU系统,程序全部用C语言设计,开发环境为盗版的Keil,用到定时器定义一个60秒的时间时,如此定义:
uint16 time; //16位变量

time = 60*1000/TMRCYC //TMRCYC=5, 定时器中断间隔为5ms
//time总时间60s
实际运行时,60s定时总是感觉不到,也就是说60s根本就没定义成功。
理论上讲,time =12000,比16位最大值65535小,应该没问题,但实际就是不行,以前没怎么用过Keil,所以也没注意这个问题,是否其他编译器也有这个问题不得而知,最后,定义改为:
time = 60*1000L/TMRCYC //常量1000后加L
问题解决。
但仍未完全明白其中道理,难道是编译器的问题,在此抛砖引玉,鄙人虽说也有几年程序经验,但哎,偏偏这么一个看似基础性的东西却不懂, 希望有大虾们解释下,可能对你们来说问题很简单,但不懂或没有遇见的小菜们却是有千千万万,你们就权当做好事了。
///http://bbs.21ic.com/icview-43268-1-1.html
///
上一篇 下一篇共25篇

编程中无穷大常量的设定技巧2012年11月22日 13:08:05

转自http://aikilis.tk/

如果问题中各数据的范围明确,那么无穷大的设定不是问题,在不明确的情况下,很多程序员都取0x7fffffff作为无穷大,因为这是32-bit int的最大值。如果这个无穷大只用于一般的比较(比如求最小值时min变量的初值),那么0x7fffffff确实是一个完美的选择,但是在更多的情况下,0x7fffffff并不是一个好的选择。

  1. 很多时候我们并不只是单纯拿无穷大来作比较,而是会运算后再做比较,例如在大部分最短路径算法中都会使用的松弛操作:
    if (d[u]+w[u][v] 我们知道如果u,v之间没有边,那么w[u][v]=INF,如果我们的INF取0x7fffffff,那么d[u]+w[u][v]会溢出而变成负数,我们的松弛操作便出错了,更一般的说,0x7fffffff不能满足“无穷大加一个有穷的数依然是无穷大”,它变成了一个很小的负数。
  2. 除了要满足加上一个常数依然是无穷大之外,我们的常量还应该满足“无穷大加无穷大依然是无穷大”,至少两个无穷大相加不应该出现灾难性的错误,这一点上0x7fffffff依然不能满足我们。

所以我们需要一个更好的家伙来顶替0x7fffffff,最严谨的办法当然是对无穷大进行特别处理而不是找一个很大很大的常量来代替它(或者说模拟它),但是这样会让我们的编程过程变得很麻烦。在我读过的代码中,最精巧的无穷大常量取值是0x3f3f3f3f,我不知道是谁最先开始使用这个精妙的常量来做无穷大,不过我的确是从一位不认识的ACMer(ID:Staginner)的博客上学到的,他/她的很多代码中都使用了这个常量,于是我自己也尝试了一下,发现非常好用,而当我对这个常量做更深入的分析时,就发现它真的是非常精巧了。

  1. 0x3f3f3f3f的十进制是1061109567,也就是10^9级别的(和0x7fffffff一个数量级),而一般场合下的数据都是小于10^9的,所以它可以作为无穷大使用而不致出现数据大于无穷大的情形。
  2. 另一方面,由于一般的数据都不会大于10^9,所以当我们把无穷大加上一个数据时,它并不会溢出(这就满足了“无穷大加一个有穷的数依然是无穷大”),事实上0x3f3f3f3f+0x3f3f3f3f=2122219134,这非常大但却没有超过32-bit int的表示范围,所以0x3f3f3f3f还满足了我们“无穷大加无穷大还是无穷大”的需求。
  3. 最后,0x3f3f3f3f还能给我们带来一个意想不到的额外好处:如果我们想要将某个数组清零,我们通常会使用memset(a,0,sizeof(a))这样的代码来实现(方便而高效),但是当我们想将某个数组全部赋值为无穷大时(例如解决图论问题时邻接矩阵的初始化),就不能使用memset函数而得自己写循环了(写这些不重要的代码真的很痛苦),我们知道这是因为memset是按字节操作的,它能够对数组清零是因为0的每个字节都是0,现在好了,如果我们将无穷大设为0x3f3f3f3f,那么奇迹就发生了,0x3f3f3f3f的每个字节都是0x3f!所以要把一段内存全部置为无穷大,我们只需要memset(a,0x3f,sizeof(a))。

所以在通常的场合下,0x3f3f3f3f真的是一个非常棒的选择。




关键词:keil大常量计

评论


技术专区

关闭