all
You must replace the baseURL in hugo.toml file when deploying, you can manage this announcement from the params.toml file.

微处理器寻址范围

内容列表

在此之前,让我们带着下面这个问题来看这篇文章:64 位处理器所支持的最大内存(寻址范围)为多少?

处理器

处理器(CPU)担负着整个计算机系统的核心任务执行责任,所以我们经常关心它的运算处理能力,也就是 CPU 的性能。

微处理器

我们经常所说的 Inter、AMD 两大常见品牌厂商出售的桌面端的处理器称为处理器(CPU),而把移动端嵌入式系统中 ARM 架构的处理器称为微处理器(MPU)。事实上,几乎电子设备上均有微型处理器,例如路由器、智能家电等等,只不过以上所提到的离我们最近而且我们也最熟悉。

CPU 的性能涉及到多个方面,我们常人最关心的一般就是主频,也就是 CPU 的时钟频率;L1、L2 缓存,这个可能部分人还不是很了解,事实上缓存非常关键,稍后会讲到;工艺,CPU 的工艺不仅可以降低功耗与成本,对性能的提高也是非常重要的;架构,这个对非专业的人来说很难理解,我们暂且可以理解为 CPU 内部各个协同工作器件的设计布局;还有很多,我们不一一列举,来具体探讨一下与今天的主题相关的方面:缓存。

缓存(Cache)

你可能无法想象,你经常关注的 CPU 主频对其性能的重要性小于缓存。缓存就如同它的名字,它的存在就是为了起缓冲作用。它缓冲的是 CPU 与内存之间的数据交互。由于目前 CPU 的时钟频率(主频)远超内存(memory)的工作频率,所以内存的数据传输速度根本跟不上 CPU 的请求速度,这对 CPU 来说是一种浪费。所以采用一种技术,即缓存技术,将缓存工作频率设计在 CPU 时钟与内存频率之间,极大地提高了数据传输速度。

数据交互有两种途径:
> [10%,慢] 处理器(CPU) <–> 内存(memory)
> [90%,快] 处理器(CPU) <–> 缓存(Cache) <–> 内存(memory)

微处理器内存寻址

既然 CPU 与内存之间有数据交互,那么就要确认每次数据读/写时的内存物理地址,如同游戏中在背包中存取东西时,首先要找到目标背包格子,才能进行正确的存取操作。

内存条的组成

一根 1G 的内存条是由许多内存颗粒(DRAM 芯片),例如 16K*8bit 的芯片,即存储单元构成的,这个过程需要字扩展、位扩展构成逻辑存储阵列。

按这样的想法,我们很容易拼成几十 G 的内存条,暂且不去说性能如何,CPU 能正确寻址吗?从而完成数据读写吗?

内存条构成:
(DRAM)16K8bit —字/位扩展—> (Memory)1G32bit

CPU 的地址线和数据线

每个 CPU 都有固定条数的数据线(Data)地址线(Address),顾名思义,很容易理解数据线就是用来传输数据的,地址线就是用来寻址的。这样的理解其实是相当正确的,只不过你稍加深入的学习,就很容易混淆概念甚至怀疑自己,从而建立错误的认知。

记住:地址位宽决定了 CPU 的寻址范围。

我们现在来讨论:64 处理器的寻址范围或者说支持的最大内存是多少?

这个问题的出现缘于 64 位处理器的诞生,宣传中不乏 32 位处理器最高可支持 4G 内存,64 位处理器可支持更大内存(这是官方话)。

百度上大多数答案都是 2^64 次方,像 CSDN、知乎等等的专业性较强的论坛上也会有少部分人这样回答。而他们有的会给出理由:64 根数据线,所以是 2^64 次方,换算下来应该有 16GT。

是的,如今所谓的 32 位或者 64 位处理器,32 和 64 指的就是 CPU 的字长,即数据(Data)位宽。

这是错误的概念!有很多人会觉得很正常,而且有自己的证明理由。例如:64 根数据线,可表示数据的范围就是 2^64,所以寻址范围理所当然就是如此。

首先,很多人这么理解是有原因的。学习微机原理时,我们都是以 Inter 的 8086/8088 为例来学习的,而恰好:**8086 数据位宽 16bit,8088 数据位宽 8bit,它们的地址位宽均为 20bit。**这样导致的结果就是,Data 位宽小于 Address 位宽的情况下,我们总以为由于数据线表示的范围不足以表示每一个地址,所以寻址范围由 Data 决定了。

**有趣的是,8086/8088 采用了段基地址和段偏移地址的方式,让 8086 只有 16 根数据线(2^16=64KB)的情况下,可以寻址到 1MB(也就是 20 根地址线)。**很多人觉得这仅仅是为了增大寻址范围(这是个错误的说法),却未曾想过这是务必要做的。

段基地址+段偏移地址:
16bit 的 Data 可表示 2^16=64KB 的地址范围
16 块 64KB 内存条 —(16bit 的 Data + 片选信号)—> 1MB 地址范围

假如不这样做,那么 16bit 的 Data 只能表示 64KB 地址范围,20bit 的 Address 其中就有 4 根闲置下来,既然多余了还要它干什么?但是,针脚的工艺那么难,无聊的加 4 根针脚闹着玩?所以说,用段基地址+段偏移地址来增加寻址范围(这么说是不对的,应该是弥补)是务必要做的,即就是:事实上,数据位宽并没有决定寻址范围。

那可以说,数据位宽与地址位宽同时决定了寻址范围吗?

我的答案是不可以这么说。你可以这么想,地址位宽大于数据位宽时,可以采用段基地址+段偏移地址方式来表示;那么当地址位宽=数据位宽时,刚好足够表示;至于数据位宽再增加时,虽然表示的数大了,但是地址位宽不足,无法表示超出部分的物理地址。所以说,无论数据位宽怎么变,最终寻址方式和范围都是相对于地址位宽来说的。

**数据(Data)位宽:**即字长,CPU 同一时刻所能传输最大数据位
> **地址(Address)位宽:**单独决定 CPU 的寻址范围

结语

由于工艺难度,CPU 上针脚数目的增加是非常难的,而且 CPU 针脚过多时,也需要主板能支持,就目前的工艺来看,最高可支持(2^37 次方)128G 内存条。

因此,64 位处理器指的是数据位宽 64bit,并不是地址位宽,那么最大可支持内存(寻址范围)也就不可能是 2^64 次方,并且远小于此。

comments powered by Disqus

相关

利用脚本执行 `tsc` 忽略类型检查错误

在发布 npm 包时添加对 TypeScript 类型定义文件的支持会让用户的使用体验增色不少,TypeScript 官方提供了 tsc --emitDeclarationOnly 命令用来生成类型定义文件(.d.ts)。但是,该命令会同时执行类型检查,遇到错误时会报错中断命令行进程,这就使其无法直接集成在 CI 环节在发布 npm 包时自动执行生成类型定义文件的操作。当然,一个解决办法就是解决掉代码中所有的类型检查错误即可,既然讨论到这个问题,必然不会花费额外精力去解决一些历史遗留问题。

了解更多

IDE:VS Code 配置同步

利用一款插件来同步 VS Code 的配置到 GitHub 的 gist 上,实现多个设备间共享一套配置。

了解更多

前端工程化:对于构建工具链的简单思考

前端工程化是在做与业务开发完全不同的事情,旨在解决软件工程领域与开发者密切相关的问题,通常会将其与基建开发、DevOps 放在一起讨论。前端开发是复杂的,其结合了 HTML/CSS/JavaScript 3 种语言,甚至还有很多其超集,没有开箱即用的工具链,不像 Java Web 开发、Android 开发等等有官方或者商业领域非常成熟的工具可以利用,一切都源于开源社区的从 0 开始构建。正因如此,前端工程化领域百花齐放,开放与创新展现的淋漓尽致,这也是前端开发者了解学习软件工程的机会。

了解更多