这肯定是开学前翻译的最后一篇文章了。
原文地址：
英文：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
版权归原作者所有。
1797
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
