为何在x86构架中 BIOS 会将 MBR 装载到 0x7c00地址处?
2015-12-22 16:33
393 查看
最近看了操作系统的实现的相关资料,对于这个问题一直想不明白,偶然找到国外博客中的一篇说明?遂简单翻译一下分享出来.
http://www.glamenv-septzen.net/en/view/6
操作系统亦或是引导程序的开发人员必须假设他们的汇编代码被加载到了这个地址,然后从这个地方开始执行。
是的,0x7C00 和 x86 CPU 毫无关系。你自然没法从intel手册上面找到他们。
你会问道,“那是谁决定了它?”
无论是谁决定的,他/她为什么要这样决定?
这里就有两个关于
谁决定的?
“0x7C00 = 32KiB - 1024B” ,也就是说是 32KB 的最后 1024B为起始地址,这一点有什么特殊含义?
这就要从
而 19号中断例程 就是 “POST”(Power On Self Test) ,上电自检(包括检查是否存在驱动器),之后将启动盘的第一分区的第一扇区的 512b 数据拷贝到 0x7c00处。
现在,你应该明白,为何在 intel手册上找不到了吧,因为它属于 BIOS 的规范。
“0x7c00”是由 IBM PC 5150 BIOS开发团队决定(David Bradley博士)。
如前所述,这[魔术数字]起源于在1981年,之后BIOS供应商和操作系统为了向后兼容,所以并没有改变这个值。
事实上,这个地址既不是由英特尔(8086/8088供应商)决定也不是由微软(OS厂商)决定。
8086/8088 0x0 - 0x3ff用于中断向量和BIOS数据区域。
引导扇区是512字节,boot 程序需要的数据/堆栈 大于 512 字节。
因此,0x7c00, 32KB 的最后 1024B 被选中了。
系统加电启动后,可以自由使用 0x7c00起始的, 32KB 的最后 1024B空间。
操作系统加载后,内存布局将是:
+——————— 0x0
| Interrupts vectors
+——————— 0x400
| BIOS data area
+——————— 0x5??
| OS load area
+——————— 0x7C00
| Boot sector
+——————— 0x7E00
| Boot data/stack
+——————— 0x7FFF
| (not used)
+——————— (…)
总之这个数字最后就变成了遗留问题,一直存在至今。 :)
http://www.glamenv-septzen.net/en/view/6
‘0x7C00’在x86体系中的秘密
你在x86汇编程序中听说过0x7C00这个[魔术数字]吗?
0x7C00是 BIOS 将 MBR 装载到的位置。
操作系统亦或是引导程序的开发人员必须假设他们的汇编代码被加载到了这个地址,然后从这个地方开始执行。
1:
> 我认真的读了 Intel x86(32bit) 的程序手册(简称 Intel手册),但是并没有在里面发现这个[魔术数字]
是的,0x7C00 和 x86 CPU 毫无关系。你自然没法从intel手册上面找到他们。
你会问道,“那是谁决定了它?”
2:
> "0x7C00 = 32KiB - 1024B",起始地址为这个数字到底有何意义?"
无论是谁决定的,他/她为什么要这样决定?
这里就有两个关于
0x7C00的问题了:
谁决定的?
“0x7C00 = 32KiB - 1024B” ,也就是说是 32KB 的最后 1024B为起始地址,这一点有什么特殊含义?
这就要从
IBM PC 5150这台远古时代的 x86 PC 说起了。
“0x7C00” 第一次出现是在 “IBM PC 5150” 的 BIOS 的 19号中断例程中。
IBM PC 5150是现代 x86 PC 的鼻祖,为了保证向下兼容的原则,”0x7C00”得以保留。
而 19号中断例程 就是 “POST”(Power On Self Test) ,上电自检(包括检查是否存在驱动器),之后将启动盘的第一分区的第一扇区的 512b 数据拷贝到 0x7c00处。
现在,你应该明白,为何在 intel手册上找不到了吧,因为它属于 BIOS 的规范。
“0x7C00” 的起源
这个地址的起源和当时的 DOS 系统不无关系,具体的可以看 DOS 的历史。“0x7c00”是由 IBM PC 5150 BIOS开发团队决定(David Bradley博士)。
如前所述,这[魔术数字]起源于在1981年,之后BIOS供应商和操作系统为了向后兼容,所以并没有改变这个值。
事实上,这个地址既不是由英特尔(8086/8088供应商)决定也不是由微软(OS厂商)决定。
“0x7C00 = 32KiB - 1024B” 有什么特殊含义? 是为了解决系统和 CPU 内存分布的需求
BIOS 决定这个地址的理由如下:
32kb是符合(DOS)系统加载的最小空间8086/8088 0x0 - 0x3ff用于中断向量和BIOS数据区域。
引导扇区是512字节,boot 程序需要的数据/堆栈 大于 512 字节。
因此,0x7c00, 32KB 的最后 1024B 被选中了。
系统加电启动后,可以自由使用 0x7c00起始的, 32KB 的最后 1024B空间。
操作系统加载后,内存布局将是:
+——————— 0x0
| Interrupts vectors
+——————— 0x400
| BIOS data area
+——————— 0x5??
| OS load area
+——————— 0x7C00
| Boot sector
+——————— 0x7E00
| Boot data/stack
+——————— 0x7FFF
| (not used)
+——————— (…)
总之这个数字最后就变成了遗留问题,一直存在至今。 :)
相关文章推荐
- IOS界面push跳转后navigationController不显示
- iOS 时间格式化
- iOS 8 WkWebView 网页的配置和前进,后退,js 交互和进度条的加载
- iOS开发系列--并行开发其实很容易
- 【iOS】判断viewcontroller 来源(展示出来)的4个方法
- iOS - layoutSubviews、drawRect、awakeFromNib和 loadNibNamed解释
- iOS NavigationController 右滑手势问题
- 海康威视 DVR IPC, IOS系统的SDK包。用于二次开发
- iOS 中KVC、KVO、NSNotification、delegate 总结及区别
- iOS中的2x,3x问题
- iOS中的汉字转换成拼音
- speex编译静态库for iOS
- ios7之后导航栏状态栏小记
- 仿ios日期选择器
- iOS获取一个控件的子控件的方法
- iOS9 企业级账号 无法安装的问题
- iOS证书及ipa包重签名探究
- iOS 计算器
- iOS之H5和Native混合开发
- iOS开发实用技术之第三方登陆