cpu位宽和其寻址范围并无关系,实际有关的是cpu地址位宽!

存储单元

1）8位二进制（1字节）作为一个存储单元(字节Byte是计算机中基本的数据单位,是存储数据的最小单位。但是计算机存储器是按照0,1来存储的,单个0或者1只固定占用一个bit,所以位bit是存储的最小单元)，这是由历史原因决定的，早期的ASCII是7位，后来又有IBM的8位EBCDIC得到广泛使用

2）每一个存储单元有一个地址编号，地址总线可以确定每个地址单元的编号，所以CPU的最小可寻址单位就是1字节（Byte）

3）内存也是数据存储器的一种，所以内存也是以1字节为单位的

也就是说,32位的cpu,地址总线位宽如果是32bit,或者换一种说法就是说存放cpu寻找内存地址的变量的大小是32bit,而32bit可以表示的最大数,也就是2^32-1,也就可以认为是2^32,也就是4*1024*1024*1024,也就是可以找到4*1024*1024*1024个存储单元,而每个存储单元的大小又是1byte,所以我们说这个cpu的最大寻址内存空间大小是4*1024*1024*1024 * 1byte=4GB.

CPU位数

　　32位CPU表示CPU一次最多能够处理数据的位数为32bit，即机器字长为32bit

CPU寻址

1）寻址空间一般指的是CPU对于内存寻址的能力。通俗地说，就是能最多用到多少内存的一个问题。

2）每个CPU的寻址能力是要看其地址线的数量，32位CPU一般有32根地址总线，那么就一共可以寻232个地址=也就是4x1024x1024x1024=4G个地址，1个地址对应1字节的存储单位，对应到内存上就是4GB（4GByte）

cpu的寻址能力,通俗的解释就是cpu可以访问到或者利用到的最大的内存地址. CPU的寻址能力与其地址总线位宽有关，而我们通常所说的CPU位宽是指其数据总线位宽,所以cpu位宽自然与寻址能力无关。

简单来说，CPU位宽指的是CPU在一个时钟周期内可以处理的二进制位数。比如8086 CPU是16位，一次可以处理2个字节(16位)，80386CPU是32位，一次可以处理4个字节。目前CPU基本上是64位，一次可以处理8个字节。

我们的Windows操作系统也分为32位和64位，主要针对CPU位宽。比如32位CPU不能用64位Windows(因为CPU一次只能处理32位，操作系统给你指令处理64位)，但是64位CPU可以运行32位Windows，也可以运行64位Windows。

那么CPU的地址总线位宽到底是什么？可以直接参考intel官方给出的解释: Intel® Xeon® Processor E5-2698 v3

微软给出的定义维基百科给出的定义

英特尔的解释是物理地址扩展(PAE)是允许32位处理器访问大于4gb的物理地址空间的功能。上图是英特尔至强处理器E5-2698 v3的截图，专门解释了物理地址的扩展，大意是让32位处理器能够使用4GB以上的内存。这个PAE是CPU的地址总线位宽。在8086中，一个16位的CPU，它的地址总线位宽是20位，正好可以寻址1MB。在80286中，它的PAE是24位。在PentiumII(32位CPU)中，这个PAE变成了36位，可以支持64GB寻址。64位CPU出现后，其地址总线位宽一般为36位或40位，它们寻址的物理地址空间为64GB或1T。

地址总线和数据总线是什么关系？可以理解为地址总线用于定位，数据总线用于传输，即当CPU需要从内存中读取数据或向内存中写入数据时，它使用地址总线指定需要访问的内存块的物理地址，然后通过数据总线发送数据。

因此，CPU的位宽与寻址能力无关。16位CPU的地址总线位宽可以是20位，32位CPU可以是36位，64位CPU可以是40位。所以下次，你一定不要说32位CPU只能处理2^32(4GB)，这是一个很大的错误。

操作系统的位宽和寻址能力有关系吗？其实是有的。当我们使用计算机时，我们实际上操作的是逻辑地址，32位操作系统的逻辑地址寻址范围只有2^32=4GB.所以不管你用什么样的CPU，最多只能支持4GB的内存容量，但这是操作系统的锅，不是说32位的CPU只能寻址4GB的空间，在这里可能容易造成错觉，所以一定要还CPU其清白。

by the way

针对不同操作系统编译得到的数据类型的大小也不同

参考1 参考2

但是java程序是编译为字节码,然后运行在jvm中的,所以不需要针对不同的平台重复编译,只需要保证不同的平台安装的是对应的jdk即可.

by the way

千年虫问题,因为计算机诞生初期,存储空间极其珍贵,所以当时的工程师就提出提出对于四位数的年份,在计算机存储时只表示后两位,比如1970/11/19就表示为70/11/19,所以到了2000年,就是00/01/01,这个时候计算机就识别为了1900年,并且2000年是闰年,有2月29号,但是1900年只有2月28号,所以导致时间计算出现错乱,所以很多严格依赖于系统时间的程序就出现故障.

和21世纪初的千年虫（the Millennium bug）问题类似，32位的Unix操作系统和Linux操作系统时间溢出问题又称为2038年问题（the Year 2038 problem）。如果你想知道什么是2038问题的话，你需要知道一些技术上的东西。这个bug是由用来写Unix/Linux的C语言引起的，C语言中用 time_t 来代表时间和日期，time_t 是整数（int）型的，它用来记载从1970年1月1日到2000年所经历的秒数。这个数据是以32位存储的，第一位是符号位，其余的31位用来存数字，而这31位数字可以存储的最大数字为2147483647。从1970年开始计算，这31位的数字可以表示的秒数最多可以用到2038年01月19日03时14分07秒，当时间到达这个数字的时候系统将会出现问题，到时候数字不会自动增加，而是会变为-2147483648，而这串数字代表的时间是1901年12月13日20时45分52秒，这会导致很多的程序出现问题，甚至崩溃。 2038年问题不仅比千年虫更隐蔽，而且比之前千年虫问题更具有破坏力，因为千年虫问题只会导致应用层的程序出现问题，比如信用卡支付系统，或者管理系统。而2038这个bug，将会影响系统最底层的时间控制的功能。要解决这个问题，最简单的方式是扩展Unix时间的长度，用64位数字来表示它。64位二进制数的实际可用位数是63位，最大表示到公历的UTC时间292,277,026,596年12月4日15时30分08秒. 如果那个时候人类文明还存在的话，公元纪年很可能已经因为太难用而被抛弃了. 理想的情况是到2038年，64位系统已经成为主流，从而避免特意去修正这个问题所需要的大量开销。否则，人们就必须把新的64位时间拆分成两部分并分别保存在两个变量里，这是一个麻烦而且效率低下的选择。

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名,转载请标明出处
最后编辑时间为: 2023/03/15 23:38