32/64bit总结及数据类型相关理解

就CPU、OS、编译器及应用程序32bit和64bit之间的一些关系和区别，通过拜读网络上各位大神的文章见解，个人通过实验总结以下几点：

1. 机器CPU的32bit或者64bit是由硬件本身决定的，和系统及软件没有关系；

2. 32bitCPU是无法运行64bit指令集的，所以64bit系统（可看成应用程序）是不能运行在32bitCPU上的；相反，64位CPU是从32bit发展过来的，所以出于兼容性考虑，64bitCPU是可以运行32bit指令集的；

3. 应用程序，也分为32bit和64bit，根据2说明，同样64bit的程序是不能运行在32bit的CPU上面的；

4. 最佳的方式就是64bit的CPU运行64bit的系统，然后跑64bit的应用程序，这样的话性能是最高的；但是在64bit的CPU下，运行32bit的系统，在安装64bit的拓展包的前提下，是可以运行64bit的应用程序的；但是用这种操作的性能会有所降低，具体表现在缓存命中率低、数据结构膨胀、内存对齐等问题；

5. 就编译器而言，个人认为同样可以看成是一个运行在PC端的应用程序，所以有32bit和64bit之分，得到的可执行文件分别是32bit和64bit的，交叉编译的话可运行在相关的嵌入式平台上；

6. 另外说明一下符号类型定义转换，如：typedef unsigned char uint8_t 在文件 stdint.h 中进行定义说明，其主要作用是考虑到平台之间移植的兼容问题，我们知道long int 类型在32bit系统下占用4个字节，但是在64bit系统下占用8个字节：

不同平台存在不同的编译器版本及bit位数，我对比过32bit编译器Eclipse及keil，其 stdint.h 文件对 unsigned char 类型的定义均为 uint8_t，说明这两个CPU架构是一样的，用户在这两个平台上使用 unsigned char 及 uint8_t 定义变量得到的结果是没有任何区别的，所以我们同一段程序在这两个平台上编译的程序数据类型所占数据位数是一致的；一般而言，在用户的应用代码中，不会直接的使用 unsigned char 定义数据类型，主要就是上面所说的移植兼容问题，通过分析，针对具体的平台，对应的数据类型的位数转换应该在对应的编译器中进行定义，或者人为定义，达到系统文件 stdint.h 的效果；

个人认为，重新定义 unsigned char 等类型的操作（类似于文件 stdint.h 的效果），如果单纯的是为了一个命名，而没有去系统的考虑编译器等原理上的问题，并达不到实际使用上的效果；

参考以下文章：

32位与64位 CPU、编译器、操作系统与应用程序的区别：

http://blog.csdn.net/trochiluses/article/details/24031749

8位无符号整数应该使用 unsigned char 还是 uint8_t：

http://www.easyfang.com/life/201509/728938.html

以及文章（总结的很详细）：

32位与64位编程注意事项总结：

http://blog.csdn.net/benpaobagzb/article/details/50719219