观察Foxdisk3的makefile,可以看到使用的是bcc -ms的编译开关。这是要求编译器采用Samll内存模式进行编译,其特点是栈和数据都在64K以内,Code在另外一个64K内。为什么采用Small方式?主要是我当时设计的时候,没有考虑到后面的各种新的需求,以为代码可以控制在64K内完成;另外,这种模式比较便于汇编和C的混合编写,不用去考虑复杂的数据段、代码段的定位。
在整个代码编写过程中,除了引导部分(也即Loader.asm),其他的代码尽量用C编写。但是有两部分的代码仍旧无法避免使用汇编,一是时钟中断,为了让几个任务并行工作,使用了汇编;二是32位数的乘除计算。我们在平常使用C/C++及其他高级语言的时候,大数的计算很平常。那是因为编译器已经提供了库函数调用,方便 程序员 使用,操作系统已经提供了这样的机制进行支持。Foxdisk某种程度上相当于简单的操作系统,这些机制完全没有提供。因此,在进行大数计算时,只能自己来写这些函数了。
回到我们的启动话题。Loader.asm包含了所有启动的秘密,其承载了将Foxdisk的演出场景安排好的任务,相当于整个程序的导演,也是整个程序最难读的地方。我试着以自己的语言,将其原理解释清楚。
Loader.asm在编译后,将链接成一段512字节的二进制码。当然,它不是单独存在的,是与其他代码混杂着存在于Foxdisk.exe中。这段512字节码将由Setup.c中的main()函数拷贝到MBR区,起到引导的作用。
Bios在释放控制权的时候,将把MBR区的代码加载到0x7C00处,并跳转执行。也即从Loader.asm中的load_start处开始执行。
整个Loader.asm实现的功能可以概括为三个:1) 将存储在硬盘上的Foxdisk代码拷贝到指定的内存;2)将Foxdisk运行的数据拷贝到另外一段64K的内存中;3) 设定栈,并远程跳转(retf)至Foxdisk的BootEntry处,开始运行Foxdisk。Loader.asm中的几个变量,nCodeSect:Foxdisk代码段占用的硬盘扇区数;nDataSect:Foxdisk数据段占用的扇区数;iBegin: Foxdisk程序镜像所存储的硬盘起始位置;这些变量均由Setup.c中的函数进行初始化,也即安装的时候确定。另外一个变量iDisk,其值为0×80或者0×81,表示BIOS所认的第一个硬盘还是第二个硬盘,也是由Setup.c中函数对其进行初始化的。如果Foxdisk镜像存储在第二个硬盘上,则必须设置为0×81。现在想来,其作用不大,而且容易给调试带来麻烦。
load_start到load_chs,尝试使用扩展中断0×13(ah=0×40以上的int 0×13)访问磁盘中的数据,加载Foxdisk的代码段至0×7000:0起始的64K内存,数据段加载至0×8000:0开始的64K内存。
如果磁盘不支持磁盘的扩展中断(这种情况基本不可能),则回到原始的硬盘访问中断,尝试将Foxdisk的代码段和数据段加载到指定的内存中。从load_chs到load_ok间做的就是这件事,其功能与上一段其实是相同的,大部分情况下也不会执行。
从标志load_ok开始,进行设置栈以及跳转的工作。Retf是条远跳转指令,它将栈中的4个字节当成CS:IP,跳转过去执行。以上工作均在实模式下进行,不用考虑复杂的权限问题。注意,在retf执行前,bx中已经包含了BootEntry的地址,执行前的push bx就是将地址压栈,准备远程跳转。
至此,我们可以暂时抛去晦涩难懂的汇编,进入了C的世界。
下一篇博客是启动原理的最后一篇,介绍Foxdisk的整体逻辑框架,从逻辑层面介绍我是如何编排实现Foxdisk的功能。
5 total views, 5 views today
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Springboot启动原理之@SpringBootApplication
- 抖音品质建设:iOS 启动优化(原理篇)
- Spring Boot 解析(二):FatJar 启动原理
- Spring Boot 解析(二):FatJar 启动原理
- Tomcat 7 启动分析(五)Lifecycle 机制和实现原理
- JAVA线程池原理源码解析—为什么启动一个线程池,提交一个任务后,Main方法不会退出?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。