这肯定是开学前翻译的最后一篇文章了。
原文地址:
英文:http://www.glamenv-septzen.net/en/view/6
日文:http://www.glamenv-septzen.net/view/614
大概是以英文为主进行的翻译吧。。。咳咳。。。大概
【】里是吐槽,不要在意这些细节
x86架构中bios将启动加载在0x7c00附近之谜
你知道0x7c00么,在x86汇编编程里面一个神奇的数字【58同城!】
0x7c00是bis加载主引导记录(MBR,在hdd或者fdd中第一个扇区)
操作系统开发者或者启动加载器【bootloader我实在不知道该怎么翻译】开发者必须保证【这个是意译】
她们的汇编代码被加载并且从0x7c00开始
但是,首先,你也许想知道【我不想知道。。。那我来搜你的文章干嘛】
-我读过了全部的intel x86 32位编程指南,但根本没有找到这个神奇的数字0x7c00【泥垢】
没错,0x7c00不依赖于x86 CPU,自然你在intel cpu说明书里找不到它。
那么,问题来了【噗。。。原文是,然后,你就想问了】
“是谁和我订立下这个契约的呢?”【原文,谁决定了这个?】
其次,你也许想问
-0x7c00是32kib【1KiB=1024B,1KB=1000B,以后如果我去卖电脑了不要说我卖给你们的硬盘容量不符Orz】
减去1024b(10进制数)。这个数字到底代表着什么?
要是有人决定了这个数,为什么他/她选择了这么一个半吊子地址
【原文:半路的地址,意思是不是整数(计算机里面整数你懂的)的地址】?
嗯。。。那么围绕0x7c00两个问题来了(谜团)。
是谁!决定了0x7c00?
而他!32kib-1024b又代表着什么!
好吧,让我们深度挖掘ibm pc 5150(现代x86 32位计算机的祖先)的bios的秘密
0x7c00首次出现在ibm pc 5150的只读记忆器bios的0x19号中断的操作中
漫步在x86 ibm兼容的pc的历史中,
你会明白~【你会讶异,你是我内心深处的秘密】
ibm pc 5150是现代x86 32位ibm pc/at兼容机的始祖。
这个pc在1981年八月份发售,带有intel 8088(16位)处理器和16kib的内存【不要小看这台机子】
Bios和微软的basic程序储存在rom中【微软怒刷存在感,微软不是做windows起家的,科普一哈子】
当我们打开电源,bios进入post(启动自检)过程,然后,调用0x19号中断。
在0x19中断中,bios检查计算机是否有软盘,硬盘,复合盘【什么鬼?】中任何一个。
如果计算机有可用的磁盘,bios载入第一个512b的扇区进入0x7c00.
现在,你明白为什么你不能在x86的文档中找到这个神奇的数字了吧!
这个神奇的数字是属于bios规格的!
0x7c00的起源
围绕着IBM PC DOS(硬盘操作系统), 微软,和SCP的86-dos发生的故事是非常著名的【自古微软多基友】请看:【原文链接已失效,也许是历史太过久远,也可能。。。嗯,你懂的】
SCP的86-dos(1980年)是ibm pc dos 1.0的参考
86-dos(更早的时候我们叫它QDOS)是CP/M的8086/8088兼容系统
在1979年,Digital Research公司还没有为8086/8088 CPU开发出CP/M。
SCP卖出了两种S-100主板,一种是8086 CPU板,另一种是叫"CPU管理者(Monitor)"的只读板。
"CPU管理者"程序提供了启动加载器和调试器。
这个 "CPU管理者"启动加载器在0x200加载主引导分区,而不是"0x7C00"。
在1981年, IBM PC DOS成为了为intel 8086/8088设计的下一个类CP/M系统。
所以,我可以明确的告诉你0x7C00第一次出现在IBM PC 5150 ROM BIOS中。
在这之前,SCP的CPU管理者启动加载器加载到0x200,而不是0x7C00。
为什么启动加载器在0x200加载MBR ?
使用0x200有三个理由。
- 8086中断向量使用内存的0x0 - 0x3FF。
- 86-DOS从0x400开始被加载。
- 86-DOS不使用在0x200 - 0x3FF之间的中断向量。
这些理由意味着内存地址0x200 - 0x3FF需要被保留并且不能挡住任何进入操作系统的过程, 不管是86-DOS还是用户的应用程序都不能使用。
所以Tim Paterson (86-DOS开发者)选择0x200作为MBR的加载地址。
问:是谁决定了"0x7C00" ? - 答: 是IBM PC 5150 BIOS开发者团队
"0x7C00"是由IBM PC 5150 BIOS开发者团队(由David Bradley博士领导)。
就是上面提到的,这个神奇的数字诞生在1981年,而且为了保持BIOS和操作系统的向前兼容性"IBM PC/AT Compat" PC/BIOS的制造商【原文是“卖家”,翻译成制造商感觉好一点】并没有改变这个值。
不是Intel(8086/8088制造商)也不是Microsoft(操作系统制造商)决定了这个值。
问:"0x7C00 = 32KiB - 1024B"意味着什么? 答:是受到操作系统的需求以及内存布局的影响的结果。
IBM PC 5150内存最小的模型只有16KiB内存【现在知道你们的电脑有多强了吧】。这样,你也许有个问题:
"内存最小的模型(只有16KiB) 真的能从磁盘里读取出操作系统么? BIOS把MBR加载到32KiB - 1024B 地址,但是物理内存是不够的呀【的呀的呀】..."
不不不,这种情况是不在考虑范围内的。IBM PC 5150 ROM BIOS开发者团队的一位成员,David Bradley博士说:
"DOS 1.0要求最小内存是32K的,所以我们没必要在意在16KB内存的情况下启动【就算你启动了也开不了系统,何必浪费电~】。"
(注解: DOS 1.0要求最小内存是16KiB? 亦或是32KiB ?我不知道哪个是正确的.。但是,至少在1981以前的BIOS 开发中,他们认为32KiB是DOS要求的最小内存。)
BIOS开发者团队由于一下原因决定使用0x7c00:
- 他们想在32KiB中留出尽可能多的空间来让操作系统加载他们自己。
- 8086/8088使用0x0 - 0x3FF存放中断向量,并且BIOS数据就在这一段后面。
- 启动扇区大小是512字节,并且启动程序的栈/数据域需要多余512字节的空间。
- 所以,0x7C00,32KiB中最后的1024B就成了被选中的孩子【数码宝贝乱入。。。】
一旦操作系统被载入与启动,启动扇区就不再使用了,除非计算机断电复位。所以操作系统和应用程序可以自由的使用32KiB中的最后一个1024B。
操作系统被加载后,内存布局如下:
+--------------------- 0x400| BIOS数据区域
+--------------------- 0x5??| 操作系统加载区域
+--------------------- 0x7C00| 启动扇区
+--------------------- 0x7E00| 启动数据/栈
+--------------------- 0x7FFF| (未使用)
+--------------------- (...)
这些就是为什么选择"0x7C00"的原因了,这个魔性【神奇的而已】的数字已经在PC/AT Compat BIOS19号中断调用的系统中存在了三十年了。
参考
86-DOS相关:
- "8086 Monitor Instruction Manual"(MON 86 - V1.4)
- "86-DOS(TM) User's Manual Version 0.3"
- "86-DOS(TM) Programmer's Manual Version 0.3"
- "86-DOS(TM) Instruction Manual Version "
IBM PC 5150相关:
- "IBM Personal Computer Hardware Reference Library", "Technical Reference" (IBM Personal Computer Technical Reference manual)
- "IBM Personal Computer XT Hardware Reference Library", "Technical Reference" (IBM Personal Computer XT Technical Reference manual)
Intel 8086/8088数据表:
- "8086 16-BIT HMOS MICROPROCESSOR"
- "M80C86/M80C86-2 16-BIT CHMOS MICROPROCESSOR"
- "8088 8-BIT HMOS MICROPROCESSOR"
CP/M相关:
- The Unofficial CP/M Web Site
- CP/M Internals : Oscar Vermeulen Personal Web Site
- Digital Research - CP/M
- CP/M Main Page
86-DOS相关:
- Origins of DOS - Paterson Technology
- 86-DOS Resource Website
- DosMan Drivel
并且所有内容都和wikipedia密切相关。
特别鸣谢...
特别鸣谢:
- Tim Peterson
- David Bradley
日文文章,请看:
"Assembler/なぜx86ではMBRが"0x7C00"にロードされるのか?(完全版)"
翻译:Veyx Shaw
校对:Veyx Shaw
版权归原作者所有。