す疯Ⅱ恒す 发表于 2017-5-24 10:41
看汇编代码吧，移位的数据并没有保存在原来的数组，保存在RO R1寄存器上，所以并没有任何问题。 ...
恩恩，是的
hjl2832 发表于 2017-5-24 09:08
这样写有什么问题？BUFF左移8位后等于16位，右边8位会自动补0，这时再与buff相或，得到一个完整的16 ...
如果在51单片机里，BUFF左移8位后还等于16位吗？
潇潇雨歇pku 发表于 2017-5-24 09:06
这种还是以事实为准，写代码跑一遍是最简单的获取答案的途径
事实是对32单片机来说，数据不会丢失
NNXia 发表于 2017-5-23 22:33
看到4楼那位大哥的调试图了吗？请问为什么会出现那种情况？
没问题的，buf只是内存上的变量，要进行其它操作，比如移位，相加，相减等都是先要放到内核寄存器才能操作，内核寄存器都是32位的，不会有问题。这种方法不太好，用指针的方法会好很多
签到签到
蓝凌风 发表于 2017-5-24 16:48
没问题的，buf只是内存上的变量，要进行其它操作，比如移位，相加，相减等都是先要放到内核寄存器才能 ...
恩恩，是的
涨姿势了:lol
有问题
看了楼上大哥的汇编，知道这个结果的原因了。原因是r0 r1 寄存器是32位的，但是如果移植到16位机或8位机上，就不会是这个结果了。结论是写程序要规范，要先类型转换好了，再移位，否则的话，程序的移植性会很差。
应该是可以的吧，32位的计算能力，把8位数据装进去，然后还有24位其实是未知的，左移后，占用了未知的8位，赋值的时候只要是能装下都应该是可以的，你可以这样，拿两个不同大小的，uint16 和uint32来分别装结果，看看是否是有区别