前言：在写程序时候遇到了一些关于数据类型转换的问题，编译器也没有报错，运行时才发现数据不对，找bug花费了很多时间，但最终也发现是一些细节上的问题，特地在这里整理出一篇文章记录。

实验环境：

芯片架构：Cortex-M0+

开发IDE：Keil_v5

编译器：armcc

问题代码：

uint64_t TempData2;

uint8_t KeyeBuf1[8];

TempData2 = ( KeyeBuf1[0] + (KeyeBuf1[1] << 8) + (KeyeBuf1[2] << 16) + (KeyeBuf1[3] << 24)+

(KeyeBuf1[4] << 32) + (KeyeBuf1[5] << 40) + (KeyeBuf1[6] << 48));

在上述代码中，先前已经声明了TempData2的数据类型为无符号64位整型类型，在接下来的移位后累加数据总是出现差错，检查累加后数据范围也没有超过无符号64位整型数据范围。

问题分析：

经过一系列的排查，最终发现了问题所在，主要是以下三方面造成的影响：

1.机器平台与编译器的影响

stdint.h是C99中引进的一个标准C库的文件，目前大部分单片机的C编译器均支持。关于编译器支的更多数据类型完全可以在该文件中找到。以armcc编译器为例，文件中，对于8位，16位，32位，64位无符号整数类型的数据定义为如下：

#include

uint64_t TempData2;

typedef unsigned char uint8_t;

typedef unsigned short int uint16_t;

typedef unsigned int uint32_t;

typedef unsigned __INT64 uint64_t;

查找该文件可得uint64_t的类型是unsigned __INT64类型，__INT64类型的解释与机器平台和编译器相关。

机器平台的硬件架构以及编译器的编译最终都会影响执行代码的生成。Cortex-M0+是32位的处理器，内部的寄存器大多都是32位，这就导致了在默认情况下进行的运算，不管是8位，16位，32位都在32位寄存器中运算。

2.“=”符号运算顺序的影响

=符号的执行过程细分下来可以分成两步：

计算=右边部分得出最终结果

最后把结果赋给=左边变量

由于上述的运算顺序导致，=左边变量不管原先定位为多少位，对先执行的=右边计算过程没有影响，也就是说，在上述代码过程中，即使左边变量先定义为64位，在先进行右边部分计算时，还是按照右边部分数据最大的数据类型来数据对齐，而后进行计算。

3.移位程序移植性的影响

对于移位程序来说，右移数据基本不会出太大问题，但是左移就需要注意很多。在32位机器平台上，8位，16位，32位数据类型都会在32位寄存器中进行移位，只要我们确保移位后的数据不会超过32位数据类型，那么程序就会正常运行。而上述数据类型一旦移位后的数据类型超过32位，那么处理器会丢失左移向前进的数据，留下最低的32位。

问题解决：

对于上述代码进行分析，( KeyeBuf1[0] + (KeyeBuf1[1] << 8) + (KeyeBuf1[2] << 16) + (KeyeBuf1[3] << 24)+ (KeyeBuf1[4] << 32) + (KeyeBuf1[5] << 40) + (KeyeBuf1[6] << 48));中的Keye1数组数据类型都是8位，计算时都在32位寄存器中计算。前几个数据的移位没有超过32位数据类型不会出太大错误，从(KeyeBuf1[4] << 32)起，理论上移位后的数据超过了32位，只留下最低32位，导致数据出错。即使最后赋给了一个64位的变量，也是将一个32位数据赋给64位,而这些问题在编译时期编译器并不会指出，需要我们自己多加注意。

最后的解决方法是将KeyeBuf1数据在运算时强制转换为64位数据类型，这样进行运算时都是64位数据对齐，最后赋给一个64位数据类型，就不会出现数据丢失的情况了。代码如下：

TempData2 = ( KeyeBuf1[0] + (KeyeBuf1[1] << 8) + (KeyeBuf1[2] << 16) + ((uint64_t)KeyeBuf1[3] << 24)+

((uint64_t)KeyeBuf1[4] << 32) + ((uint64_t)KeyeBuf1[5] << 40) + ((uint64_t)KeyeBuf1[6] << 48));