移位操作

unsigned char date[4];
unsigned long int value;
如果移位操作是:
value=date[0]<<24  | date[1]<<16  | date[2]<< 8 | date[3];
输出的结果value值是不对的，高16位输出为0，低6位是对的。

如果移位操作：
value=date[0]<<8  | date[1]；
value=value<<16  | date[2]<< 8 | date[3];
输出的结果value值是正确的。

这是为什么啊

这个问题，你看一上反汇编就知道了。
value=date[0]<<24  | date[1]<<16  | date[2]<< 8 | date[3];
等式都是8位数据进行操作，所以系统保存的结果是8位的。
所以经常在不是同类型的变量操作时要小心，数据运算的时候会将数据都转换成默认类型再进行运算。

第一个等式不会转换，因些错了，第二个运算前会去转换。

还有一点建议，你这个程序移位打上括号，不然可读性不好。

将其强制类型转换
（unsigned long）data

delin17 发表于 2013-3-13 12:49
这个问题，你看一上反汇编就知道了。
value=date[0]

反汇编只有用R6和R7 来保存date[2]和date[3]，根本就没有date[0]和date[1]的事，这是咋回事，为什么系统保存的结果是8位的。

date[0],data[1]
直接优化掉了，无效操作

数据溢出了

delin17 发表于 2013-3-13 12:49
这个问题，你看一上反汇编就知道了。
value=date[0]

第一个等式不会转换，因些错了，第二个运算前会去转换。
这句话不太明白什么意思

ccxlslr 发表于 2013-3-13 15:04
对于位数小于int类型的，默认按int型操作，因此不做类型转换，移位大于15就没意义了。你的操作数是一个8位 ...

对于位数小于int类型的，默认按int型操作，这是仅对于移位操作来说的吗？

2楼正解

ccxlslr 发表于 2013-3-13 15:16
你也要注意，标准C都有整数提升。8位并不一定按8位运算

不是标准C有扩展，在嵌入式的世界，很多操作会根据实际情况去优化。8bit+8bit一定是两个8bit相加的。
实际这些操作都是根编译器有关系的。

醉心369 发表于 2013-3-13 14:42
第一个等式不会转换，因些错了，第二个运算前会去转换。
这句话不太明白什么意思 ...

第一个等式的右值全是8bit的，所以他操作用的全是8bit的
而第二个等式的右值存在非8bit的，所以运算的时候会去转换。

unsigned char date[4];
改成
unsigned int date[4];
应该就都可以了吧

9楼正解

我以VC,Keil MDK上试了，确实如你所说。
看来是我的理解有问题。

delin17 发表于 2013-3-14 10:04
我以VC,Keil MDK上试了，确实如你所说。
看来是我的理解有问题。

看到这里有点晕，到底怎样理解呢

标准的C是按ccxlslr所说的，Keil钩上那个选项之后也是。如果没有选中那个选项，基本上按我所说的执行的。

delin17 发表于 2013-3-15 17:38
标准的C是按ccxlslr所说的，Keil钩上那个选项之后也是。如果没有选中那个选项，基本上按我所说的执行的。 ...

你哪里理解的有问题，正确的理解是什么

顶

"对于位数小于int类型的，默认按int型操作，因此不做类型转换，移位大于15就没意义了"

学习了，原来是这样。
难怪此前用一个uint变量位移16以上不能得到正确结果。还以为是单片机不支持。
话说ccxlslr楼去哪了。