关于冯诺依曼架构和哈佛架构的一点思考
目录
- 1 冯诺依曼架构
- 2 哈佛架构
- 2.1 从软件的角度看哈佛架构
- 2.2 从硬件的角度看哈佛架构
- 3 混合架构(改进的哈佛架构)
- 3.1 MCU使用的混合架构
- 3.2 MPU使用的混合架构
- 3.3 总结
1 冯诺依曼架构
冯诺依曼架构讲计算机分为五个部分:
- 运算器
- 控制器
- 存储器
- 输入设备
- 输出设备
从wiki找了一张图说明上述5个部分的关系:
冯诺依曼架构有个特点:程序和数据放在一起,位于存储器。这也就意味着,只需要一条数据总线和地址总线,就可以实现指令的读取和数据的读写。这样做硬件上当然更加简单,成本也低。但也有一个缺点,不能同时取指和读写数据,这限制了性能。
2 哈佛架构
半导体技术发展的很快,随着技术的发展,同样的价钱可以买到更多数量的晶体管。这也就意味着,为了追求更好的性能,硬件可以做的更复杂,复杂度不再(明显)是计算机架构的制约。针对冯诺依曼架构的缺点,哈佛架构被提出:将指令存储和数据存储严格分开,也即指令和数据有着完全独立的存储空间,更严格的说,指令和数据具有独立的地址空间(不仅仅是独立的存储介质)。可见,哈佛架构是一种并行体系结构,可以同时取指和读写数据。
用一张图来简单表示:
这种指令和数据分别存储在独立的存储介质,且各自拥有独立的地址空间的设计并没有成为主流。这就是值得思考的地方,这种设计的问题在哪里?就本人极为有限的知识储备,这里简单说以下自己的看法,权当怕抛砖引玉了。
2.1 从软件的角度看哈佛架构
当前我们使用的操作系统和编译器,数据和程序都是共用一套地址空间的。独立地址空间意味着很多软件基础设施要重写。当时没有采用独立地址空间,可能也有出于软件实现方面的考虑。
2.2 从硬件的角度看哈佛架构
从硬件上看,SRAM访问速度快,但成本和功耗高,因此容量做不大。DRAM正好相反,适合做大容量存储器。因此,假如使用I/D SRAM实现独立的存储介质,那么容量就做不大;假如使用I/D DRAM实现独立的存储介质,那么就需要两套DDR控制器,这无疑成本更高,更何况还要考虑DDR控制器所挂的高速总线的带宽,想要做到真正的并行就不能有瓶颈存在。
此外,不管是使用SRAM还是DRAM,这种完全分离的设计都缺乏灵活性,指令和数据各分配多大的?除非专用计算机,可以预设使用场景。通用的话,应用是非常灵活的,不能预判用户是对数据存储空间更大,还是程序需求空间更大,怎么分配两者的大小都不合适。
3 混合架构(改进的哈佛架构)
哈佛架构的初衷是实现并行,但其最初的架构设计有不合理的地方。因此出现了改进的哈佛架构,实际上是一种混合架构,既有哈佛架构的东西,也有冯诺依曼架构的东西。下面分别简单介绍一下当前MCU和MPU实际使用的这种混合架构。
3.1 MCU使用的混合架构
MCU一般存储器的容量比较小,很少会使用DRAM,大多使用的存储器都是SRAM、ROM以及支持XIP的Flash(一般是Nor Flash)。当然,也有例外,比如esp32系列,使用cache和SPI Flash实现了类似Nor Flash的片上执行的效果。大多数的MCU的存储架构如下:
复杂一些的,使用总线矩阵连接CPU和多种存储器;简单一些的也可以直接使用数据总线和指令总线连接存储器。
对比最初的哈佛架构,这种混合架构的特点是:
- 统一地址空间
- 不再保持独立的存储介质
这些改进是很合理的,首先,当前似乎也没有主流的支持独立地址空间的编译器(不确定);再者,MCU本身存储器就小,经不起严格区分指令和数据存储介质带来的浪费,因此更切实的做法是不再限制存储介质的用途,SRAM可以存放数据也可以存放指令,ROM/Flash可以存放指令也可以存放只读数据,从而为R/W变量节约更昂贵(也更耗电的)SRAM。
必须得承认的是,这种不保持独立存储介质的设计在并行访问时会带来一定的冲突。但大体上,数据是放在SRAM,指令放在ROM/Flash,混放并不严重。此外,也可以对存储介质做物理上的划分来减少冲突。因此,冲突总体是可以接受的,大体还是发挥了哈佛架构并行的优势(工程嘛,总是要有所取舍的)。
值得一提的是,统一地址空间的具体实现又可以进一步细分:
- I/D地址范围不重合
- 实际映射的物理存储介质完全重合
- 实际映射的物理存储介质部分重合
- 实际映射的物理存储介质完全不重合
- I/D地址范围重合
当我们需要自己写链接脚本的时候,上述这些细分情况还是有必要弄清楚的。当前,主流应该是I/D地址范围重合
,个人觉得这也是对软件来说最清晰的设计。
3.2 MPU使用的混合架构
MPU一般需要大容量的内存,需要大容量的DRAM,而DRAM的速度和CPU的速度差距太大,因此需要Cache(不妨理解为SRAM)作为缓冲。用一幅图来描述这种混合架构(简单起见,MMU就不画了):
对比最初的哈佛架构,这种混合架构的特点是:
- 统一地址空间
- 内部保持指令和数据的存储介质独立,外部则是统一的DRAM
这样设计的合理性在于,CPU所有的数据和指令都是从Cache获取(不要抬杠少部分uncache的情况),因此保持对Cache访问的严格并行可以带来很大的性能收益。所以Cache一般划分ICache
和DCache
。并且Cache的容量也不大,这种划分带来的灵活性的损失也是可以接受的。大容量的DRAM则没有限制数据和指令的存储,配合MMU
,可以实现非常灵活的内存管理。
3.3 总结
工程通常就是这个样子,设计,应用,改进,再应用,再改进…
关于冯诺依曼架构和哈佛架构的一点思考相关推荐
- 【嵌入式】计算机体系结构:冯诺依曼架构和哈佛架构
计算机体系结构:冯诺依曼架构和哈佛架构 计算机体系结构有冯 · 诺依曼(普林斯顿)架构.哈佛架构两种 两者的区别: 指令和数据的保存方式不同 冯诺依曼架构: 指令和数据存放在一起,共用一个存储器,自然 ...
- 普林斯顿体系架构和哈佛架构
目前接触到的单片机架构就这两种:普林斯顿体系和哈佛结构: 两者的主要区别是:code memory和date memory是不是分开存放. 普林斯顿体系是程序存储器和数据存储器集合一体的架构:MEMO ...
- 微型计算机之哈佛架构是什么?
"哈佛体系结构"指的是什么? 微型计算机处理命令和数据,但是在很久以前的微型计算机中,用命令和数据共享了一条总线.在这种情况下,CPU在读取指令时使用总线,因此无法访问数据,并且在 ...
- 冯·诺依曼架构哈佛架构(嵌入式学习)
冯·诺依曼架构&哈佛架构 0. 前言 1. 冯·诺依曼架构(von Neumann architecture) 关键组件 限制&挑战 2. 哈佛架构 关键组件 限制&挑战 3. ...
- x86架构和arm架构处理器分析
x86架构和arm架构处理器分析 目录: 1.两种cpu架构:冯洛伊曼和哈佛 2.x86架构和arm架构分析 3.x86架构和arm架构功耗探究 一.两种cpu架构: 目前主流的cpu处理 器都采用了 ...
- 从CPU架构--x86架构和arm架构处理器--功耗
目录: 1.两种cpu架构:冯洛伊曼和哈佛 2.x86架构和arm架构分析 3.x86架构和arm架构功耗探究 一.两种cpu架构: 目前主流的cpu 处理器都采用了冯洛伊曼架构或者哈佛架构,那么这和 ...
- 哈佛架构、冯诺依曼架构、指令集
1.CISC与RISC的区别: CISC(复杂指令集):复杂指令集就是CPU在工作的时候需要有很多的汇编指令来完成,它可以用一个汇编指令来完成一件复杂的工作.例如:乘法,加法,乘加,乘减等处理的时候, ...
- 哈佛架构 VS 冯·诺依曼架构
1. 引言 冯·诺依曼架构为: 哈佛架构为: 二者最大的区别体现在: 哈佛架构 与 冯·诺依曼架构 主要不同之处有: Parameters Von Neumann Architecture Harva ...
- 一套用了 70 年的计算机架构 —— 冯·诺依曼架构
本文已收录到 GitHub · AndroidFamily,有 Android 进阶知识体系,欢迎 Star.技术和职场问题,请关注公众号 [彭旭锐] 进 Android 面试交流群. 前言 大家好, ...
最新文章
- cas协议,以及tomcat搭建cas服务器
- 某业务付费统计脚本问题排查
- ROS-Kinetic 中使用XSENS MTI 1 姿态传感器
- SELinux的开启和关闭
- mybatis报错,找不到对应mapper文件
- Maven基础:Maven环境搭建及基本使用(1)
- 1090 Highest Price in Supply Chain (25)(25 分)
- 前端学习(1654):前端系列实战课程之js运行代码
- oracle用户相关操作
- 基于android预约功能,基于Android的银行业务预约系统的设计与实现
- CSDN下载码怎么使用
- Keli 编译遇到 *** FATAL ERROR L250: CODE SIZE LIMIT IN RESTRICTED VERSION EXCEEDED
- 520表白网页代码html 爱心网页制作
- w10桌面不显示计算机了,win10系统电脑开机后不显示桌面的详细方案
- 三维von Mises-Fisher分布的均值方差
- LOJ#6198. 谢特 SAM+启发式合并+01trie
- for linux pdf转mobi_pdftotext —— Linux/Unix中将PDF文件转化为Text文本格式的利器
- unity3d 挂载脚本_Unity3D 全局脚本
- Cloudera Manager拓展SPARK2-2.3.0.cloudera3-1.cdh5.6.0.p0.1-el6.parcel
- python 运行 daemon 程序