内存管理与“三地址”的千丝万缕(2)
来源:互联网 发布:算法 epub 编辑:程序博客网 时间:2024/05/23 12:07
好,开始正题!
线性地址转换成物理地址(保护模式下):现在有了线性地址,32位的线性地址中高十位用来索引页目录表,中间十位用来索引页表,最后十二位是页面内的偏移值,页目录每一个页目录项是四字节,共有4KB,即1024项。目录项里有页表的基地址(页表也是4KB,但有4个页表),而后加上线性地址的中间十位即页表的偏移地址得到索引的页表项,页表项里又含有页的基址,加上线性地址的最后十二位值得到物理存储器的物理地址,因为是十二位偏移,所以每页是4KB。这只是简单的过程,具体的大家还是要参考别的书籍了!
现在讲一下arm(以S3C2410为例)的内存管理机制,这和cpu很相似,要是你懂了cpu的,这就不在话下了,其中有些许的细节差别我略微的讲一下。
你发现有一点很明显的区别了吗?Pentium的所有外设是独立编址的,但是arm9却不是这样,它利用存储控制器将外设的访问地址统一起来,这其中就包括了NandFlash与SDRAM,这也正是嵌入式的魅力,利用4G的空间分配给所有外设,或者可以按pentium的观点来说便是“存储器与外设统一编址”(记住,两者不是一样的啊,这里只是形象称呼而已),这在嵌入式系统中可以节省很多元件,使体积大大减少,符合嵌入式系统的定义。
Arm9的页机制与intel的很类似,,用表格存储虚拟地址对应的物理地址。有一个细微的差别是页的大小分为三种:大页(64KB)、小页(4KB)、极小页(1KB)。(尽管pentium的页大小也是可调的,但是只有4KB与4MB供选择,这通过CR4控制寄存器的PSE位),另外arm9的页表还分为粗页表与细页表。其他的包括段寻址是一样的。顺便提一下,给定的虚拟地址转换成线性地址中,虚拟地址的各位代表的意义也是与pentium不一样的,这同样体现在线性地址转换成物理地址。这里就不再赘述了,可以参考arm9的书籍。
还有就是arm9的TLB与cache的问题,这里就不提了,这个很容易理解的,它与pentium一样。两者都是为了让cpu执行得更快而做出的设计。
现在讲一下使用arm9时一个很重要的细节。在通常的bootloader中,未开启MMU前,我们程序用的地址都是物理地址,开启之后就变成了虚拟地址,这就涉及到bootloader中有一些程序的物理地址必须与虚拟地址一样,这样才不致于开启MMU后程序执行错了。具体实现是在页表设置中实现。当数据和代码还在NandFlash中时,内存中没有数据,读取数据时便需要地址转换,这在bootloader的lowlevel_init.s程序中体现了,代码如下:
Ldr r0,=SMRDATA
Ldr r1,_TEXT_BASE
Sub r0,r0,r1
Ldr r1,BWSCON
Add r2,r0,#13*4
这时内存中(SDRAM)没有数据,不能使用连接脚本程序里面的确定地址读取数据。
以上就是我最近学习linux的总结,这并不是最终版本,一旦有新的想法,我会及时更新这篇文章!这里估计有很多错误的,欢迎大家指正批评!
- 内存管理与“三地址”的千丝万缕(2)
- 内存管理与“三地址”的千丝万缕(1)
- 指针和数组的千丝万缕(三)
- 寄存器 cache 内存 硬盘之间的千丝万缕
- JSTL与EL之间的千丝万缕
- 浅谈#define与typedef千丝万缕的关系
- JSTL与EL之间的千丝万缕
- 【Cell报表】与JS的千丝万缕
- JSTL与EL之间的千丝万缕
- JSTL与EL之间的千丝万缕
- 千丝万缕的FGC与Buffer Pool
- 千丝万缕的FGC与Buffer Pool
- 千丝万缕的FGC与Buffer Pool
- JSTL与EL之间的千丝万缕
- 计算机与艺术千丝万缕的联系
- 霍夫曼编码与priority_queue的千丝万缕
- 内存管理(2)linux的地址映射机制
- 指针和数组的千丝万缕(一)
- Ant编译Enum类型的错误
- oracle 聚合函数
- httpclient超时总结
- 长沙现代阳光体检中心
- ASIHTTPRequest系列(一):同步和异步请求
- 内存管理与“三地址”的千丝万缕(2)
- 第十六周 任务四(升级版)
- 求1+2+3+....n
- MAC下搭建discuz论坛
- 在ClassView中双击某个函数名,打不开,解决方法
- CL_SALV_TABLE
- 利用IWebBrowser2接口的Navigate2方法实现Http POST传输
- 浅析iOS移动设备用户界面设计11大精粹
- Android Socket 中文乱码