stm32 无符号char,如果不初始化，右移8位后，值不一定是0

gmajvfhpa · 发表于 2020-6-3 20:56:23

keil MDK 编译，
unsigned char k , b ;
................
b = k>>8;
这时b 可能不是0。什么原因？

Jacky.Qiu · 发表于 2020-6-3 21:03:55

k没有初始化，试试赋个0xFF

cumt_123456 · 发表于 2020-6-3 21:15:01

你降低下编译器优化等级试试

gmajvfhpa · 发表于 2020-6-3 21:40:15

cumt_123456 发表于 2020-6-3 21:15
你降低下编译器优化等级试试

降到 0 级也是一样。
只要先赋个值，就不出错了

Himem · 发表于 2020-6-3 21:47:01

调试模式汇编跟一下看看编译成什么指令了

gmajvfhpa · 发表于 2020-6-3 21:58:18

gmajvfhpa 发表于 2020-6-3 21:40
降到 0 级也是一样。
只要先赋个值，就不出错了

611: k=0;
0x080188CE 2700 MOVS r7,#0x00
612: for(j=0;j<x;j++)
613: {
0x080188D0 2400 MOVS r4,#0x00
0x080188D2 E01C B 0x0801890E
614: k= k>>1;
0x080188D4 107F ASRS r7,r7,#1

复制代码

查看到的汇编代码，K不初始化时，R7的值就不确定。8位的K 右移。并不是只移动R7的低8位，而是把R7高位的数据移入低8位中，所以出现不想要的结果。
但这样的话，又不符合 ”8位无符号右移，左边补0“ 这种说法

2nd · 发表于 2020-6-3 22:07:09

GCC试了下没这个问题，字节左移赋值后是零。

gmajvfhpa · 发表于 2020-6-3 22:14:04

2nd 发表于 2020-6-3 22:07
GCC试了下没这个问题，字节左移赋值后是零。

跟踪结果是没补始化时 R7=0x07070707,右移一位后是0x03838383

wye11083 · 发表于 2020-6-3 22:22:01

gmajvfhpa 发表于 2020-6-3 22:14
跟踪结果是没补始化时 R7=0x07070707,右移一位后是0x03838383

那这是mdk的bug了，数据类型被自动扩展了但是没有后续的掩码工作。gcc如果用byte类型会导致汇编里大量的shl 24，shr 24操作来移除高位全部0。所以arm之类的一般都强烈建议完全基于32位整型来计算，避免数据的额外处理步骤。

lb0857 · 发表于 2020-6-4 08:08:56

32位mcu 处理32位数据最为拿手省时省力处理8位数据反而耗时吃力还容易出错

117433525 · 发表于 2020-6-4 08:24:15

32位宽,向右移,会不会把bit8-15的随机数移过来了,你向左移8位试试.

zhugean · 发表于 2020-6-4 09:29:30

为什么老是纠结这些不规范的写法是什么表现呢？
怎么表现都是正常的，换个编译器可能就是不同的结果。
如果想满足好奇心，建议关闭编译器的自动整型提升看看，可能会得到你想要看到的结果。

myxiaonia · 发表于 2020-6-4 10:32:12

这里b不是0又如何呢，真正用的时候，会帮你变成0的，编译器都很聪明，会延迟生效

goodjob2 · 发表于 2020-6-4 10:36:39

本帖最后由 goodjob2 于 2020-6-4 10:40 编辑

右移8位是个什么操作？不会溢出吗？你这个UCHAR本身才8位啊

Scarlette · 发表于 2020-6-4 12:08:45

wye11083 发表于 2020-6-3 22:22
那这是mdk的bug了，数据类型被自动扩展了但是没有后续的掩码工作。gcc如果用byte类型会导致汇编里大量的s ...

关于这点，UXTB它不香吗……

mcu5i51 · 发表于 2020-6-4 15:25:52

为什么就没有人想下这个没有初始化的变量是个什么值呢

supercoo · 发表于 2020-6-4 16:01:37

楼主试试定义为全局变量不初始化

leebilly007 · 发表于 2020-6-4 17:37:52

那你就初始化一下会死啊

armstrong · 发表于 2020-6-4 19:34:09

你这个问题条件不足，要看k，b是局部变量还是全局静态变量。
如果是局部变量，k，b就是不确定的；全局静态变量的话会被放在bss段，c启动代码把它们初始化成0。

gmajvfhpa · 发表于 2020-6-5 08:07:31

armstrong 发表于 2020-6-4 19:34
你这个问题条件不足，要看k，b是局部变量还是全局静态变量。
如果是局部变量，k，b就是不确定的；全局静态 ...

K是局部变量。在8位机上 unsigned char 右移左边是补0，但现在32位机上，在K不初始化的情况下右移，左边不一定是补0.

goodjob2 · 发表于 2020-6-5 08:41:11

gmajvfhpa 发表于 2020-6-5 08:07
K是局部变量。在8位机上 unsigned char 右移左边是补0，但现在32位机上，在K不初始化的情况下右移，左 ...

你一个8位数据，最多移7位，你移8位是做什么？1000 0000 >>7 = 0000 0001

jia_xuan · 发表于 2020-6-5 11:25:57

中途没有赋值的，定义的时候就要初始化。

hzpyl · 发表于 2020-6-5 14:08:20

32位CPU，用32位数据最好。

KevinHua768 · 发表于 2020-6-16 16:13:20

纠结这个问题没有什么意义

abutter · 发表于 2020-6-16 20:46:07

C 语音里面未定义行为，一个 8 位的数据右移 8 位之后应该是啥？

Gorgon_Meducer · 发表于 2020-6-16 22:41:43

局部变量未初始化的时候，编译器是没有义务保证他的值为某一个确定的数值的。这个可不是编译器BUG。不要与自己
预期不符合就说是编译器bug。

EMC菜鸟 · 发表于 2020-6-16 23:11:38

wye11083 发表于 2020-6-3 22:22
那这是mdk的bug了，数据类型被自动扩展了但是没有后续的掩码工作。gcc如果用byte类型会导致汇编里大量的s ...

我也觉得是BUG，不符合C的标准用法。

EMC菜鸟 · 发表于 2020-6-16 23:13:57

Gorgon_Meducer 发表于 2020-6-16 22:41
局部变量未初始化的时候，编译器是没有义务保证他的值为某一个确定的数值的。这个可不是编译器BUG。不要与 ...

不管是否初始化，右移首位补零好像是标准C的做法吧？当然我并不确定C里是否有明确的说明。

gmajvfhpa · 发表于 2020-6-17 11:32:10

Gorgon_Meducer 发表于 2020-6-16 22:41
局部变量未初始化的时候，编译器是没有义务保证他的值为某一个确定的数值的。这个可不是编译器BUG。不要与 ...

可能我说的不够清楚。其实问题是：一个不确定值的 unsigned char 数，右移一位后，首位不一定是补0

Gorgon_Meducer · 发表于 2020-6-17 20:52:40

gmajvfhpa 发表于 2020-6-17 11:32
可能我说的不够清楚。其实问题是：一个不确定值的 unsigned char 数，右移一位后，首位不一定是补0 ...

给你这么一说，的确是编译器在这里欠考虑。
因为arm compiler 5一般是先进行ALU操作，在赋值给别的变量前才会用一条专门指令去把寄存器长度截取为uint8_t。
你这个例子高概率的，a直接就是在通用寄存器页里分配的，按照先ALU运算，后截取的步骤，Rx bit7以上的值已经影响bit0~bit7了，然后才进行长度截取，已经于事无补了——考虑到你保存的结果还是在a里，编译器估计都不会进行长度截取……

你arm compiler 5版本是多少？优化等级是多少？
尝试过arm compiler 6么？arm compiler 5已经停止维护了，即便有问题也不会修复了。

Gorgon_Meducer · 发表于 2020-6-17 20:54:43

EMC菜鸟发表于 2020-6-16 23:13
不管是否初始化，右移首位补零好像是标准C的做法吧？当然我并不确定C里是否有明确的说明。 ...

我以为你们说的是未初始化的变量初始值的问题。真没注意到这里移位非0的问题。
不过我知道编译器会怎么做，所以判断下来，我知道为什么会有这个问题。

stm32 无符号char,如果不初始化，右移8位后，值不一定是0

阿莫论坛20周年了！感谢大家的支持与爱护！！

本帖子中包含更多资源