2016.10.16
今天的代码被警告说:left shift count >= width of type
代码:
typedef enum
{
MSG_WARNING_DELAYED = (1 << 30),
MSG_WARNING_LOCKED = (1 << 31)
}MSG_EVENT_TASK_WARNING;平台:
AVR-GCC/Atmega16。
搜索了下、最终确定是移位的范围超过变量宽度(寄存器宽度)。
上面代码里面的1、在AVR-GCC/Atmega16下默认为8bit宽度,被放在8bit寄存器里面。
而(1 << 30)中左移了30位、已经超出了8bit宽度范围,8bit寄存器里面的所有bit都将被移出寄存器,结果将全是0。
所以这里需要指定(1 << 30)中1的宽度为32位、才能进行32位以内的移位操作,如下指定:
typedef enum
{
MSG_WARNING_DELAYED = ((uint32_t)1 << 30),
MSG_WARNING_LOCKED = ( 1UL << 31)
}MSG_EVENT_TASK_WARNING;
对函数的参数进行移位时、最容易被遗忘变量宽度。
如下面的代码就是在移位时、移位的范围超过了变量宽度、而又没有指定变量宽度:
unsigned long int GetCANIdentifier(unsigned char typ, unsigned char geraet, unsigned char cmd, unsigned char index)
{
return((unsigned long int) (typ<<16) | (geraet<<12) | (cmd<<4) | index);
}
应改为:
return(((uint32_t)typ << 16) | ((uint32_t)geraet << 12) | ((uint32_t)cmd << 4) | (uint32_t)index);代码来源:
《Compiler warning: left shift count >= width of type》。
就算最终是赋予32bit的变量,CPU在计算时、中间结果也不会自动地先进行类型转换,而是计算结束后才进行类型转换。
也就是如下代码中、也需要指定中间计算步骤里面的参数的宽度:
uint32_t temp = 1 << 31;仍然需要改为:
uint32_t temp = 1UL << 31;除非是在
32位环境下。
-------------------------------------------------------------------------------------------------------------------------------------
2016.10.17
今天调试了一下,发现默认的常数是16bit宽度。
昨天(1 << 8)都会被警告,今天只有(1 << 16)以及超过16位移位宽度的才被警告。
看了下反汇编,常数1的默认宽度确实变成了16bit宽度:
1UL得到的是一个32bit的立即数:
更为奇特的操作如下:
这里、(1 << 15)应该是按照16bit宽度、在预编译时就得到了0x8000,而将其存储到32bit的temp2016时、却要将高16位全设为FF。
好奇怪,将默认的优化级别从-Os改为-O0,反汇编结果依然不变。
(1UL << 15)才得到预期的结果。
--question-001

博客讨论了在AVR-GCC/Atmega16环境下,当进行移位操作时如果移位范围超过变量宽度(8位)会导致警告。示例代码显示了如何指定32位宽度来避免这个问题。此外,还提到了即使最终赋值给32位变量,CPU在计算过程中不会自动转换中间结果的类型。在调试过程中,发现默认常数宽度为16位,并且不同移位操作在反汇编层面有不同的表现。
4716

被折叠的 条评论
为什么被折叠?



