我不会给你提供教科书上对操作系统的定义，因为解释得太抽象了，看了之后似乎只是获得一些感性认识，好奇心强的读者反而会产生更多迷惑。为了说清楚问题，让我给您举个例子。
让我们扯点远的……在盘古开天之际，除动物以外，世界上只有土地、荒草、树木、石头等资源。人们为了躲避天灾、野兽攻击等危险，开始住进了山洞，为了获取食物，用石头和树木等材料打造一些武器。当时所有人都在做这些相同的事。这就是没有组织的人类社会，所有人都在重复“造轮子”。
后来各个地区有了自己权威性的部落，部落都专门找人打造武器，谁需要武器就直接申请领取便可，大部分人不需要自己打造武器了。后来嫌打猎太麻烦了，干脆养一些家畜好了，直接供给人们，谁需要可以过来交换。这就是把大家的重复性劳动集中到了一起，让人们可以专注于自己的事情。
再后来，部落之间为了通信，开始有信使了，这是最原始的通信方式。到后来发展到有社会组织，通信越来越频繁了，干脆搞个驿站吧，谁需要通信，直接写信，由驿站代为送达。
随着人口越来越多，社会组织需要了解到底有多少人，为了方便人口管理，于是就在各地建了“户籍办事”处，人们的生老病死都要到那里登记申报。
说到这我估计您已经猜出我所说的了，上面提到的部落其实就是最原始的操作系统雏形，它将大家都需要的工作找专人负责，大家不用重复劳动。而以上的社会组织其实就是代表现代操作系统，除了把重复性工作集中化，还有了自己的管理策略。
把上面的例子再具体一下，人们想狩猎时，可不可以自己先打造武器，然后拿着自己的武器去狩猎？当然可以，自己制造武器完全没有问题，但部落既然有现成的武器可用，何必自己再费事呢。另外，部落担不担心你随意制造武器会对他人造成伤害？当然会，所以部落不允许你自己制造武器了，人们只有申请的资格，给不给还是要看人家部落的意愿。这就是操作系统提供给用户进程一些系统调用，当用户进程需要某个资源时，直接调用便可，不用自己再费尽心思考虑硬件的事情了，由操作系统把资源获取到后交给用户进程，用户进程可以专注于自己的工作。但操作系统为了保护计算机系统不被损害，不允许用户进程直接访问硬件资源，比如用户进程将操作系统所占据的内存恶意覆盖了，操作系统也就不复存在了，没有操作系统的话，计算机将会瘫痪无法运作。
当人们想和远方的朋友说话时，虽然可以徒步走到亲朋好友身边再对其表达想说的话，但社会组织已经给提供了邮局和电话，何必自己再大老远跑一趟呢。这就是操作系统（社会组织）提供的资源。两个人想在一起生活，要不要一定先结婚呢？完全不用，领不领证都不会阻碍人们在一起生活，但是社会组织为了方便人口管理做了额外约束。不领证的话，至少社会组织无法预测未来人口数量趋势，无法做出宏观调控，甚至这是找到你家人的一种方法。这就如Linux系统中的内存管理，分别要记录哪些页是Active，哪些是“脏页”。不记录会不会影响程序执行，当然不会，记录这些状态还不是为了更好地管理内存吗。
以上说的社会组织和人们之间的关系，正是操作系统和用户进程的关系，希望大家能对操作系统有个初步印象，后面的实践中我们将实例化各个部分。
学无止境，学习没有说到头的那天。学习到任何程度都是存有疑惑的，就像中学和大学都讲物理，但学的深度不一样，各个阶段都会产生疑问。我们只是基于一些公认的知识，使其作为学习的起点，并以此展开上层的研究。
比如我对太空很感兴趣，大伙儿都知道地球围绕太阳做周期性公转，后来又知道电子围绕原子核来做周期性公转运动，这和地球绕太阳公转的行为如出一辙，甚至我在想太阳是不是相当于原子核，地球相当于一个电子，我们只是生活在一个电子上……而我们身体里有那么多的原子和电子，对那些我们身体中更为细微的生物来说，我们的身体是不是一个宇宙，无尽的猜想，无尽的疑惑。想法虽然有些荒诞，但基于现有科技目前谁也无法证明这是错的，而且近期已有科学文献证明人的大脑就像个宇宙。如果无止境地刨根问底下去，虽然会对底层科学更加清晰，但这对上层知识的学习非常不利，从而我们需要一个公设，我们认为原子是不可再分的，没有更微小的对象了，一切理论研究以此为基础展开。比如乘法是基于加法的，我们研究3×4等于多少，必须要承认1+1等于2，并认为其为真理，不用再去质疑1+1为什么等于2了，这就是我们的公设，至于为什么1+1等于2，还是由专门研究基础科学的学者们去探究吧。
学习操作系统也一样，不必纠结于硬件内部是如何工作的，我们只要认为给硬件一个输入，硬件就会给我一个输出就行了，因为即使你学到了硬件内部电子电路，随着你不断进步，钻研不断深入，也许有一天你的求知欲到了物理领域，并产生了物理科学方面的质疑……这让我想到一个笑话，某人准备去买自行车，结果被销售人员不断劝说，加点钱就能买摩托啦，等决定买摩托时，销售人员又说既然都决定买摩托车了，不如再加点买汽车吧，给出了各种汽车方面的优势，欲望需求不断升级，不断被销售劝说，最后居然花了几百万元买车，最后才想起自己是来买自行车的，甚至他还没有驾照……于是，咱们赶紧就此打住，我们是来学操作系统的。
你想学到哪个程度呢，你的公设是什么，要不咱们还是走一步说一步吧。
首先应该明确，在计算机中有分层的概念，也就是说，计算机是一个大的组合物，由各个部分组合成一个系统。每个部分就是一层功能模块，各司其职，它只完成一定的工作，并将自己的工作结果（也就是输出）交给下一层的模块，这里的模块指的是各种外设、硬件。
这样，各种工作成果不断累加，通过这种流水线式的上下游协作，便实现了所谓的系统。可见，系统就是各种功能组合到一起后，产生最终输出的组合物。就像人的身体，胃负责搅拌食物，将这些食物变食糜后交给小肠，因为小肠只能处理流食，所以上游的输出一定要适合作为下游的输入，是不是有点类似管道操作了，哈哈，分工协作是大自然的安排，并不是只有计算机世界才有。我们人类的思想是大自然安排好的，所以人类创造的事物也是符合大自然规律的。
好，赶紧回到正题，操作系统是管理资源的软件，操作系统能做什么，取决于主机上硬件的功能。就像用Maya造一个人体模型出来，首先我得知道Maya这个软件提供曲线曲面各种建模方法才行，换句话说，对于人体建模，你不可能会想到用QQ，因为它不是干这个的。我想说的是硬件不支持的话，操作系统也没招……操作系统一直是所谓的底层，拥有至高无上的控制权，一副牛气轰轰的样子，原来也要依仗他人啊。是啊，操作系统毕竟是软件，而软件的逻辑是需要作用在硬件上才能体现出来的。
所以说，写操作系统需要了解硬件，这些硬件提供了软件方面的接口，这样我们的操作系统通过软件（计算机指令）就能够控制硬件。我们需要做的就是知道如何通过计算机指令来控制硬件，参考硬件手册这下少不了啦。
硬件是各种各样的，发展速度还是非常快的。各个硬件都有自己的个性，操作系统不可能及时更新各种硬件的驱动方法吧。比如，刚出来某个新硬件，OS开发者们便开始为其写驱动，这不太现实，会把人累死的。于是乎，便出现了各种硬件适配设备，这就是IO接口。接口其实就是标准，大家生产出来的硬件按照这个标准工作就实现了通用。
硬件在输入输出上大体分为串行和并行，相应的接口也就是串行接口和并行接口。串行硬件通过串行接口与CPU通信，反过来也是，CPU通过串行接口与串行设备数据传输。并行设备的访问类似，只不过是通过并行接口进行的。
访问外部硬件有两个方式。
（1）将某个外设的内存映射到一定范围的地址空间中，CPU通过地址总线访问该内存区域时会落到外设的内存中，这种映射让CPU访问外设的内存就如同访问主板上的物理内存一样。有的设备是这样做的，比如显卡，显卡是显示器的适配器，CPU不直接和显示器交互，它只和显卡通信。显卡上有片内存叫显存，它被映射到主机物理内存上的低端1MB的0xB8000～0xBFFFF。CPU访问这片内存就是访问显存，往这片内存上写字节便是往屏幕上打印内容。看上去这么高大上的做法是怎么实现的，这个我们就不关心了，前面说过，计算机中处处是分层，我们要充分相信上一层的工作。
（2）外设是通过IO接口与CPU通信的，CPU访问外设，就是访问IO接口，由IO接口将信息传递给另一端的外设，也就是说，CPU从来不知道有这些设备的存在，它只知道自己操作的IO接口，你看，处处体现着分层。
于是问题来了，如何访问到IO接口呢，答案就是IO接口上面有一些寄存器，访问IO接口本质上就是访问这些寄存器，这些寄存器就是人们常说的端口。这些端口是人家IO接口给咱们提供的接口。人家接口电路也有自己的思维（系统），看到寄存器中写了什么就做出相应的反应。接口提供接口，哈哈，有意思。不过这是人家的约定，没有约定就乱了，各干各的，大家都累，咱们只要遵循人家的规定就能访问成功。
应用程序是软件（似乎是废话，别急，往后看），操作系统也是软件。CPU会将它们一视同仁，甚至，CPU不知道自己在执行的程序是操作系统，还是一般应用软件，CPU只知道去cs：ip寄存器中指向的内存取指令并执行，它不知道什么是操作系统，也无需知道。
操作系统是人想出来的，为了让自己管理计算机方便而创造出来的一套管理办法。
应用程序要用某种语言编写，而语言又是编译器来提供的。其实根本就没有什么语言，有的只是编译器。是编译器决定怎样解释某种关键字及某种语法。语言只是编译器和大家的约定，只要写入这样的代码，编译器便将其翻译成某种机器指令，翻译成什么样取决于编译器的行为，和语言无关，比如说C语言的printf函数，它的功能不是说一定要把字符打印到屏幕上，这要看编译器对这种关键字的处理。
编译器提供了一套库函数，库函数中又有封装的系统调用，这样的代码集合称之为运行库。C语言的运行库称为C运行库，就是所谓的CRT（C Runtime Library）。
应用程序加上操作系统提供功能才算是完整的程序。由于有了操作系统的支持，一些现成的东西已经摆在那了，但这些是属于操作系统的，不是应用程序的，所以咱们平时所写的应用程序只是半成品，需要调用操作系统提供好的函数才能完整地做成一件事，而这个函数便是系统调用。
用户态与内核态是对CPU来讲的，是指CPU运行在用户态（特权3级）还是内核态（特权0级），很多人误以为是对用户进程来讲的。
用户进程陷入内核态是指：由于内部或外部中断发生，当前进程被暂时终止执行，其上下文被内核的中断程序保存起来后，开始执行一段内核的代码。是内核的代码，不是用户程序在内核的代码，用户代码怎么可能在内核中存在，所以“用户态与内核态”是对CPU来说的。
当应用程序陷入内核后，它自己已经下CPU了，以后发生的事，应用程序完全不知道，它的上下文环境已经被保存到自己的0特权级栈中了，那时在CPU上运行的程序已经是内核程序了。所以要清楚，内核代码并不是成了应用程序的内核化身，操作系统是独立的部分，用户进程永远不会因为进入内核态而变身为操作系统了。
应用程序是通过系统调用来和操作系统配合完成某项功能的，有人可能会问：我写应用程序时从来没写什么系统调用的代码啊。这是因为你用到的标准库帮你完成了这些事，库中提供的函数其实都已经封装好了系统调用，你需要跟下代码才会看到。其实也可以跨过标准库直接执行系统调用，对于Linux系统来说，直接嵌入汇编代码“int 0x80”便可以直接执行系统调用，当然要提前设置好系统调用子功能号，该子功能号用寄存器eax存储。
会不会有人又问，编译器怎么知道系统调用接口是什么，哈哈，您想啊，下载编译器时，是不是要选择系统版本，编译器在设计时也要知道自己将来运行在哪个系统平台上，所以这都是和系统绑定好的，各个操作系统都有自己的系统调用号，编译器厂商在代码中已经把宿主系统的系统调用号写死了，没什么神奇的。
前面提到了用户进程陷入内核，这个好解释，如果把软件分层的话，最外圈是应用程序，里面是操作系统，如图1所示。
▲图1 陷入内核
应用程序处于特权级3，操作系统内核处于特权级0。当用户程序欲访问系统资源时（无论是硬件，还是内核数据结构），它需要进行系统调用。这样CPU便进入了内核态，也称管态。看图中凹下去的部分，是不是有陷进去的感觉，这就是“陷入内核”。
按理说咱们应该先看看段是什么，不过了解段是什么之前，先看看内存是什么样子，如图2所示。
▲图2 内存示例
内存按访问方式来看，其结构就如同上面的长方形带子，地址依次升高。为了解释问题更明白，我们假设还在实模式下，如果读者不清楚什么是实模式也不要紧，这并不影响理解段是什么，故暂且先忽略。
内存是随机读写设备，即访问其内部任何一处，不需要从头开始找，只要直接给出其地址便可。如访问内存0xC00，只要将此地址写入地址总线便可。问题来了，分段是内存访问机制，是给CPU用的访问内存的方式，只有CPU才关注段，那为什么CPU要用段呢，也就是为什么CPU非得将内存分成一段一段的才能访问呢？
说来话长，现实行业中有很多问题都是历史遗留问题，计算机行业也不能例外。分段是从CPU 8086开始的，限于技术和经济，那时候电脑还是非常昂贵的东西，所以CPU和寄存器等宽度都是16位的，并不是像今天这样寄存器已经扩展到64位，当然编译器用的最多的还是32位。16位寄存器意味着其可存储的数字范围是2的16次方，即65536字节，64KB。那时的计算机没有虚拟地址之说，只有物理地址，访问任何存储单元都直接给出物理地址。
编译器在编译程序时，肯定要根据CPU访问内存的规则将代码编译成机器指令，这样编译出来的程序才能在该CPU上运行无误，所以说，在直接以绝对物理地址访问内存的CPU上运行程序，该程序中指令的地址也必须得是绝对物理地址。总之，要想在该硬件上运行，就要遵从该硬件的规则，操作系统和编译器也无一例外。
若加载程序运行，不管其是内核程序，还是用户程序，程序中的地址若都是绝对物理地址，那该程序必须放在内存中固定的地方，于是，两个编译出来地址相同的用户程序还真没法同时运行，只能运行一个。于是伟大的计算机前辈们用分段的方式解决了这一问题，让CPU采用“段基址+段内偏移地址”的方式来访问任意内存。这样的好处是程序可以重定位了，尽管程序指令中给的是绝对物理地址，但终究可以同时运行多个程序了。
什么是重定位呢，简单来说就是将程序中指令的地址改写成另外一个地址，但该地址处的内容还是原地址处的内容。
CPU采用“段基址+段内偏移地址”的形式访问内存，就需要专门提供段基址寄存器，这些是cs、ds、es等。程序中需要用到哪块内存，只要先加载合适的段到段基址寄存器中，再给出相对于该段基址的偏移地址便可，CPU中的地址单元会将这两个地址相加后的结果用于内存访问，送上地址总线。
注意，很多读者都觉得段基址一定得是65536的倍数（16位段基址寄存器的容量），这个真的不用，段基址可以是任意的。这就是段可以重叠的原因。
举个例子，看图2，假设段基址为0xC00，要想访问物理内存0xC01，就要将用0xC00：0x01的方式来访问才行。若将段基址改为0xc01，还是访问0xC01，就要用0xC01：0x00的方式来访问。同样，若想访问物理内存0xC04，段基址和段内偏移的组合可以是：0xC01：0x03、0xC02：0x02、0xC00：0xC04等，总之要想访问某个物理地址，只要凑出合适的段基地址和段内偏移地址，其和为该物理地址就行了。这时估计有人会问这样行不行，0xC05：-1，能这样提问的同学都是求知欲极强的，可以自己试一下。
说了这么多，我想告诉你的是只要程序分了段，把整个段平移到任何位置后，段内的地址相对于段基址是不变的，无论段基址是多少，只要给出段内偏移地址，CPU就能访问到正确的指令。于是加载用户程序时，只要将整个段的内容复制到新的位置，再将段基址寄存器中的地址改成该地址，程序便可准确无误地运行，因为程序中用的是段内偏移地址，相对于新的段基址，该偏移地址处的内存内容还是一样的，如图3所示。
▲图3 段的重定位
所以说，程序分段首先是为了重定位，我说的是首先，下面还有其他理由呢。
偏移地址也要存入寄存器，而那时的寄存器是16位的，也就是一个段最多可以访问到64KB。而那时的内存再小也有1MB，改变段基址，由一个段变为另一个段，就像一个段在内存中飘移，采用这种在内存中来回挪位置的方式可以访问到任意内存位置。
所以说，程序分段又是为了将大内存分成可以访问的小段，通过这样变通的方法便能够访问到所有内存了。
但想一想，1M是2的20次方，1MB内存需要20位的地址才能访问到，如何做到用16位寄存器访问20位地址空间呢？
在8086的寻址方式中，有基址寻址，这是用基址寄存器bx或bp来提供偏移地址的，如“mov [bx]，0x5；”指令便是将立即数0x5存入ds：bx指向的内存。
大家看，bx寄存器是16位的，它最大只能表示0～0xFFFF的地址空间，即64KB，也就是单一的一个寄存器无法表示20位的地址空间——1MB。也许有人会说，段基址和段内偏移地址都搞到最大，都为0xFFFF，对不起，即使不溢出的话，其结果也只是由16位变成了17位，即两个n位的数字无论多大，其相加的结果也超不过n+1位，因为即使是两个相同的数相加，其结果相当于乘以2，也就是左移一位而已，依然无法访问20位的地址空间。也许读者又有好建议了：CPU的寻址方式又不是仅仅这一种，上面的限制是因为寄存器是16位，只要不全部通过寄存器不就行了吗。既然段寄存器必须得用，那就在偏移地址上下功夫，不要把偏移地址写在寄存器里了，把它直接写成20位立即数不就行啦。例如mov ax，[0x12345]，这样最终的地址是ds+0x12345，肯定是20位，解决啦。不错，这种是直接寻址方式，至少道理上讲得通，这是通过编程技巧来突破这一瓶颈的，能想到这一点我觉得非常nice。但是作为一个严谨的CPU，既然宣称支持了通过寄存器来寻址，那就要能够自圆其说才行，不能靠程序员的软实力来克服CPU自身的缺陷。于是，一个大胆的想法出现了。
16位的寄存器最多访问到64KB大小的内存。虽然1MB内存中可容纳1MB/64KB=16个最大段，但这只是可以容纳而已，并不是说可以访问到。16位的寄存器超过0xffff后将会回卷到0，又从0重新开始。20位宽度的内存地址空间必然只能由20位宽度的地址来访问。问题又来了，在当时只有16位寄存器的情况下是如何做到访问20位地址空间的呢？
这是因为CPU设计者在地址处理单元中动了手脚，该地址部件接到“段基址+段内偏移地址”的地址后，自动将段基址乘以16，即左移了4位，然后再和16位的段内偏移地址相加，这下地址变成了20位了吧，行啦，有了20位的地址便可以访问20位的空间，可以在1MB空间内自由翱翔了。
首先，程序不是一定要分段才能运行的，分段只是为了使程序更加优美。就像用饭盒装饭菜一样，完全可以将很多菜和米饭混合在一起，或者搅拌成一体，哈哈，但这样可能就没什么胃口啦。如果饭盒中有好多小格子，方便将不同的菜和饭区分存放，这样会让我们胃口大开增加食欲。
x86平台的处理器是必须要用分段机制访问内存的，正因为如此，处理器才提供了段寄存器，用来指定待访问的内存段起始地址。我们这里讨论的程序代码中的段（用section或segment来定义的段，不同汇编编译器提供的关键字有所区别，功能是一样的）和内存访问机制中的段本质上是一回事。在硬件的内存访问机制中，处理器要用硬件——段寄存器，指向软件——程序代码中用section或segment以软件形式所定义的内存段。
分段是必然的，只是在平坦模型下，硬件段寄存器中指向的内存段为最大的4GB，而在多段模式下编程，硬件段寄存器中指向的内存段大小不一。
对于在代码中的分段，有的是操作系统做的，有的是程序员自己划分的。如果是在多段模型下编程，我们必然会在源码中定义多个段，然后需要不断地切换段寄存器所指向的段，这样才能访问到不同段中的数据，所以说，在多段模型下的程序分段是程序员人为划分的。如果是在平坦模型下编程，操作系统将整个4GB内存都放在同一个段中，我们就不需要来回切换段寄存器所指向的段。对于代码中是否要分段，这取决于操作系统是否在平坦模型下。
一般的高级语言不允许程序员自己将代码分成各种各样的段，这是因为其所用的编译器是针对某个操作系统编写的，该操作系统采用的是平坦模型，所以该编译器要编译出适合此操作系统加载运行的程序。由于处理器支持了具有分页机制的虚拟内存，操作系统也采用了分页模型，因此编译器会将程序按内容划分成代码段和数据段，如编译器gcc会把C语言写出的程序划分成代码段、数据段、栈段、.bss段、堆等部分。这会由操作系统将编译器编译出来的用户程序中的各个段分配到不同的物理内存上。对于目前咱们用高级语言编码来说，我们之所以不用关心如何将程序分段，正是由于编译器按平坦模型编译，而程序所依赖的操作系统又采用了虚拟内存管理，即处理器的分页机制。像汇编这种低级语言允许程序员为自己的程序分段，能够灵活地编排布局，这就属于人为将程序分成段了，也就是采用多段模型编程。
这么说似乎不是很清楚，一会再用例子和大伙儿解释就明白了。在这之前，先和大家明确一件事。
CPU是个自动化程度极高的芯片，就像心脏一样，给它一个初始的收缩，它将永远地跳下去。突然想到Intel的广告词：给你一颗奔腾的心。
只要给出CPU第一个指令的起始地址，CPU在它执行本指令的同时，它会自动获取下一条的地址，然后重复上述过程，继续执行，继续取址。假如执行的每条指令都正确，没有异常发生的话，我想它可以运行到世界的尽头，能让它停下来的唯一条件就是断电。
它为什么能够取得下一条指令地址？也就是说为什么知道下一条指令在哪里。这是因为程序中的指令都是挨着的，彼此之间无空隙。有同学可能会问，程序中不是有对齐这回事吗？为了对齐，编译器在程序中塞了好多0。是的，对齐确实是让程序中出现了好多空隙，但这些空隙是数据间的空隙，指令间不存在空隙，下一条指令的地址是按照前面指令的尺寸大小排下来的，这就是Intel处理器的程序计数器cs：eip能够自动获得下一条指令的原理，即将当前eip中的地址加上当前指令机器码的大小便是内存中下一条指令的起始地址。即使指令间有空隙或其他非指令的数据，这也仅仅是在物理上将其断开了，依然可以用jmp指令将非指令部分跳过以保持指令在逻辑上连续，我们在后面会通过实例验证这一原理。
为了让程序内指令接连不断地执行，要把指令全部排在一起，形成一片连续的指令区域，这就是代码段。这样CPU肯定能接连不断地执行下去。指令是由操作码和操作数组成的，这对于数据也一样，程序运行不仅要有操作码，也得有操作数，操作数就是指程序中的数据。把数据连续地并排在一起存储形成的段落，就称为数据段。
指令大小是由实际指令的操作码决定的，也就是说CPU在译码阶段拿到了操作码后，就知道实际指令所占的大小。其实说来说去，本质上就是在解释地址是怎么来的。这部分在第3章中的“什么是地址”节中有详解。
给大家演示个小例子，代码没有实际意义，是我随便写的，只是为方便大家理解指令的地址，代码如下。
code_seg.S
1 mov ds,ax
2 mov ax,[var]
3 label：
4 jmp label
5 var dw 0x99
本示例一共就5行，简单纯粹为演示。将其编译为二进制文件，程序内容是：
8E D8 A1 07 00 EB FE 99 00
就这9个字节的内容，有没有觉得一阵晕炫。如果没有，目测读者兄弟的技术水平远在我之上，请略过本书。
其实这9个字节的内容就是机器码。为了让大家理解得更清晰，给大家列个机器码和源码对照表，见表1。
表1 机器码和源码对照表
地 址 |
机 器 码 |
源 码 |
|---|---|---|
00000000 |
8ED8 |
mov ds，ax |
00000002 |
A10700 |
mov ax，[0x7] |
00000005 |
EBFE |
jmp short 0x5 |
00000007 |
|
var dw 0x99 |
00000008 |
|
var dw 0x99 |
表1第1行，地址0处的指令是“mov ds，ax”，其机器码是8ED8，这是十六进制表示，可见其大小是2字节。前面说过，下一条指令的地址是按照前面指令的尺寸排下来的，那第2行指令的起始地址是0+2=2。在第2行的地址列中，地址确实是2。这不是我故意写上去的，编译器真的就是这样编排的。第2列的指令是“mov ax，[0x7]”（0x7是变量var经过编译后的地址），其机器码是A10700，这是3字节大小。所以第3条指令的地址是2+3=5。后面的指令地址也是这样推算的。程序虽然很短，但麻雀虽小，五脏俱全，完美展示了程序中代码紧凑无隙的布局。
现在大伙儿明白为什么CPU能源源不断获取到指令了吧，如前所述，原因首先是指令是连续紧凑的，其次是通过指令机器码能够判断当前指令长度，当前指令地址+当前指令长度=下一条指令地址。
上面给出的例子，其指令在物理上是连续的，其实在CPU眼里，只要指令逻辑上是连续的就可以，没必要一定得是物理上连续。所以，明确一点，即使数据和代码在物理上混在一起，程序也是可以运行的，这并不意味着指令被数据“断开”了。只要程序中有指令能够跨过这些数据就行啦，最典型的就是用jmp跳过数据区。
比如这样的汇编代码：
1 jmp start ;跳转到第三行的start，这是CPU直接执行的指令
2 var dd 1 ;定义变量var并赋值为1。分配变量不是CPU的工作
;汇编器负责分配空间并为变量编址
3 start： ;标号名为start，会被汇编器翻译为某个地址
4 mov ax,0 ；将ax赋值为0
这几行代码没有实际意义，只是为了解释清楚问题，咱们只要关注在第2行的定义变量var之前为什么要jmp start。如果将上面的汇编代码按纯二进制编译，如果不加第1行的jmp，CPU也许会发出异常，显示无效指令，也许不知道执行到哪里去了。因为CPU只会执行cs：ip中的指令，这两个寄存器记录的是下一条待执行指令的地址，下一个地址var处的值为1，显然我们从定义中看出这只是数据，但指令和数据都是二进制数字，CPU可分不出这是指令，还是数据。保不准某些“数据”误打误撞恰恰是某种指令也说不定。既然var是我们定义的数据，那么必须加上jmp start跳过这个var所占的空间才可以。
加个jmp指令，这样做一点都不影响运行，只不过这样写出来的程序，其中引用的地址大部分是不连续的，也就是程序在取地址时会显得跳来跳去。就美观层面上看，这样的结构显得很凌乱，不利于程序员阅读与维护。如果把第2行的var换到第1行，数据和代码就分开了，没有混在一起，标号都不用了，代码简洁多了，如下。
var dd 1
mov ax,0
做过开发的同学都清楚，尽量把同一属性的数据放在一起，这样易于维护。这一点类似于MVC，在程序逻辑中把模型、视图、控制这三部分分开，这样更新各部分时，不会影响到其他模块。
将数据和代码分开的好处有三点。
第一，可以为它们赋予不同的属性。
例如数据本身是需要修改的，所以数据就需要有可写的属性，不让数据段可写，那程序根本就无法执行啦。程序中的代码是不能被更改的，这样就要求代码段具备只读的属性。真要是在运行过程中程序的下一条指令被修改了，谁知道会产生什么样的灾难。
第二，为了提高CPU内部缓存的命中率。
大伙儿知道，缓存起作用的原因是程序的局部性原理。在CPU内部也有缓存机制，将程序中的指令和数据分离，这有利于增强程序的局部性。CPU内部有针对数据和针对指令的两种缓存机制，因此，将数据和代码分开存储将使程序运行得更快。
第三，节省内存。
程序中存在一些只读的部分，比如代码，当一个程序的多个副本同时运行时（比如同时执行多个ls命令时），没必要在内存中同时存在多个相同的代码段，这将浪费有限的物理内存资源，只要把这一个代码段共享就可以了。
后两点较容易理解，咱们深入讨论下第一点，不知您有没有想过，数据段或代码段的属性是谁给添加上的呢，是谁又去根据属性保护程序的呢，是程序员吗？是编译器吗？是操作系统吗？还是CPU一级的硬件支持？
首先肯定不是程序员，人家操作系统设计人员为了让程序员编写程序更加容易，肯定不会让他们分心去处理这些与业务逻辑无关的事。看看编译器为我们做了什么，它将程序中那些只读的代码编译出来后，放在一片连续的区域，这个区域叫代码段。将那些已经初始化的数据也放在一片连续的区域，这个区域叫数据段，那些具有全局属性的但又未初始化的数据放在bss段。总之，程序中段的类型可多了，用“readelf –e elf”命令便可以看到很多段的类型，感兴趣的读者请自行查阅。好了，编译器的工作到此就完事了，显然，数据段和代码段的属性到现在还没有体现出来。
先看CPU为我们提供了哪些原生的支持。在保护模式下，有这样一个数据结构，它叫全局描述符表（Global Descriptor Table，GDT），这个表中的每一项称为段描述符。先递归学习一下，什么是描述符？描述符就是描述某种数据的数据结构，是元信息，属于数据的数据。就像人们的身份证，上面有写性别、出生日期、地址等描述个人情况的信息。在段描述符中有段的属性位，在以后的章节中可以看到，其实是有2个，一个是S字段，占1bit大小，另外一个是占4bit大小的TYPE字段，这两个字段配合在一起使用就能组合出各种属性，如只读、向下扩展、只执行等。提供归提供，可得有人去填写这张表啊，谁来做这事呢，有请操作系统登场。
接着看操作系统为我们做了什么。
操作系统在让CPU进入保护模式之前，首先要准备好GDT，也就是要设置好GDT的相关项，填写好段描述符。段描述符填写成什么样，段具备什么样的属性，这完全取决于操作系统了，在这里大家只要知道，段描述符中的S字段和TYPE字段负责该段的属性，也就是该属性与安全相关。
说到这里，答案似乎浮出水面了。
（1）编译器负责挑选出数据具备的属性，从而根据属性将程序片段分类，比如，划分出了只读属性的代码段和可写属性的数据段。再补充一下，编译器并没有让段具备某种属性，对于代码段，编译器所做的只是将代码归类到一起而已，也就是将程序中的有关代码的多个section合并成一个大的segment（这就是我们所说的代码段），它并没有为代码段添加额外的信息。
（2）操作系统通过设置GDT全局描述符表来构建段描述符，在段描述符中指定段的位置、大小及属性（包括S字段和TYPE字段）。也就是说，操作系统认为代码应该是只读的，所以给用来指向代码段的那个段描述符设置了只读的属性，这才是真正给段添加属性的地方。
（3）CPU中的段寄存器提前被操作系统赋予相应的选择子（后面章节会讲什么是选择子，暂时将其理解为相当于段基址），从而确定了指向的段。在执行指令时，会根据该段的属性来判断指令的行为，若有返回则发出异常。
总之，编译器、操作系统、CPU三个配合在一起才能对程序保护，检测出指令中的违规行为。如果GDT中的代码段描述符具备可写的属性，那编译器再怎么划分代码段都没有用，有判断权利的只有CPU。
好，现在大家对GDT有个感性认识，随着以后章节中讲GDT的时候，大家就会有深刻的理解了。
以上说明了程序按内容分段的原因，那么编译器编译出来的段和内存访问中的段是一回事吗？
其实算一回事，也不算一回事。怎么说呢，我觉得当初Intel公司在设计CPU时，其采用分段机制访问内存的原因，肯定不是为了上层软件的优美，毕竟那只是逻辑上的东西。那为什么也算一回事呢？
分析一下，编译出来的代码段是指一片连续的内存区域。这个段有自己的起始地址，也有自己的大小范围。用户进程中的段，只是为了便于管理，而编译器或程序员在“美学方面”做出的规划，本质上它并不是CPU用于内存访问的段，但它们都是描述了一段内存，而且程序中的段，其起始地址和大小可以理解为CPU访问内存分段策略中的“段基址：段内偏移地址”，这么说来，至少它们很接近了，让我们更近一步：程序是可以被人为划分成段的，并且可以将划分出来的段地址加载到段寄存器中，见下面的代码0-1。
代码1 程序分段
1 section my_code vstart=0
2 ;通过远跳转的方式给代码段寄存器CS赋值0x90
3 jmp 0x90:start
4 start: ;标号start只是为了jmp跳到下一条指令
5
6 ;初始化数据段寄存器DS
7 mov ax,section.my_data.start
8 add ax,0x900 ;加0x900是因为本程序会被mbr加载到内存0x900处
9 shr ax,4 ;提前右移4位,因为段基址会被CPU段部件左移4位
10 mov ds,ax
11
12 ;初始化栈段寄存器SS
13 mov ax,section.my_stack.start
14 add ax,0x900 ;加0x900是因为本程序会被mbr加载到内存0x900处
15 shr ax,4 ;提前右移4位,因为段基址会被CPU段部件左移4位
16 mov ss,ax
17 mov sp,stack_top ;初始化栈指针
18
19 ;此时CS､DS､SS段寄存器已经初始化完成,下面开始正式工作
20 push word [var2] ;变量名var2编译后变成0x4
21 jmp $
22
23 ;自定义的数据段
24 section my_data align=16 vstart=0
25 var1 dd 0x1
26 var2 dd 0x6
27
28 ;自定义的栈段
29 section my_stack align=16 vstart=0
30 times 128 db 0
31 stack_top: ;此处用于栈顶,标号作用域是当前section,
;以当前section的vstart为基数
32
代码1是实模式下运行的程序，其中自定义了三个段，为了和标准的段名（.code、.data等）有所区别，这里代码段取名为my_code，数据段取名为my_data，栈段取名为my_stack。这段代码是由MBR加载到物理内存地址0x900后，mbr通过“jmp 0x900”跳过来的，我们的想法是让各段寄存器左移4位后的段基址与程序中各分段实际内存位置相同，所以对于代码段，希望其基址是0x900，故代码段CS的值为0x90（在实模式下，由CPU的段部件将其左移4位后变成0x900，所以要初始化成左移4位前的值）。但没有办法直接为CS寄存器赋值，所以在代码0-1开头，用“jmp 0x90：0”初始化了程序计数器CS和IP。这样段寄存器CS就是程序中咱们自己划分的代码段了。
在此提醒一下，各section中的定义都有align=16和vstart=0，这是用来指定各section按16位对齐的，各section的起始地址是16的整数倍，即用十六进制表示的话，最后一位是0。所以右移操作如第9行的shr ax，4，结果才是正确的，只是把0移出去了。否则不加align=16的话，section的地址不能保证是16的整数倍，右移4位可能会丢数据。vstart=0是指定各section内数据或指令的地址以0为起始编号，这样做为段内偏移地址时更方便。具体vstart内容请参阅本书相应章节。
第6～10行是初始化数据段寄存器DS，是用程序中自已划分的段my_data的地址来初始化的。由于代码1本身是脱离操作系统的程序，是MBR将其加载到0x900后通过跳转指令“jmp 0x900”跳入执行的，所以要将my_data在文件内的地址section.my_data.start加上0x900才是最终在内存中的真实地址。右移4位的原因同代码段相同，都是CPU的段部件会自动将段基址左移4位，故提前右移4位。此地址作为段基址赋值给DS，这样段寄存器DS中的值是程序中咱们自己划分的数据段了。
第12～17行是初始化栈段寄存器，原理和数据段差不多，唯一区别是栈段初始化多了个针指针SP，为它初始化的值stack_top是最后一行，因为栈指针在使用过程中指向的地址越来越低，所以初始化时一定得是栈段的最高地址。
经过代码段、数据段、栈段的初始化，CPU中的段寄存器CS、DS、SS都是指向程序中咱们自己划分的段地址，之后CPU的内存分段机制“段基址：段内偏移地址”，段基址就是程序中咱们自己划分的段，段内偏移地址都是各自定义段内的指令和数据地址，由于在section中有vstart=0限制，地址都是从0开始编号的。所以，程序中的分段和CPU内存访问的分段又是一回事。
让我们对此感到疑惑的原因，可能是我们一般都是用高级语言开发程序，在高级语言中，程序分段这种工作不由我们控制，是由编译器在编译阶段完成的。而且现代操作系统都是在平坦模型（整个4GB空间为1个段）下工作，编译器也是按照平坦模型为程序布局，程序中的代码和数据都在同一个段中整齐排列。大家可以用readelf –e /bin/ls查看一下ls命令，结果太长，就不截图啦。咱们主要关注三段内容。
Section Headers：列出了程序中所有的section，这些section是gcc编译器帮忙划分的。
Program Headers：列出了程序中的段，即segment，这是程序中section合并后的结果。
Section to Segment mapping：列出了一个segment中包含了哪些section。
在Section Headers和Program Headers中您会发现，这些分段都是按照地址由低到高在4GB空间中连续整洁地分布的，在平坦模型下和谐融洽。
显然，不用程序员手工分段，并且采用平坦模型，这种操作上的“隔离”固然让我们更加方便，但也让我们更加感到进程空间布局的神秘。如果程序分段像代码0-1那样地直白、亲民，大家肯定不会感到迷惑了。其实我想说的是无论是否为平坦模型，程序中的分段和CPU中的内存分段机制，它们属于物品与容器的关系。
举个例子，程序中划分的段相当于各种水果，比如代码段相当于香蕉，数据段相当于葡萄，栈段相当于西瓜。CPU内存分段策略中的段寄存器相当于盛水果的盘子。可以用一个大盘子将各种水果都放进来，但依然是分门别类地摆放，不能失去美感混成一锅粥，这就是段大小为4GB的平坦模型。也可以把每种水果分别放在一个小盘子里一块儿端上来，这就是普通的分段模型，如图4所示。
▲图4 程序中分段在平坦模型和 分段模型中的区别
总结一下，程序中的段只是逻辑上的划分，用于不同数据的归类，但是可以用CPU中的段寄存器直接指向它们，然后用内存分段机制去访问程序中的段，在这一点上看，它们很像相片和相框的关系：程序中的段是内存中的内容，相当于相片，属于被展示的内容，而内存分段机制则是访问内存的手段，相当于相框，有了相框，照片才能有地摆放。
我想大家应该已经搞清楚了内存分段和程序分段的关系，其实就是一回事，内存分段指的是处理器为访问内存而采用的机制，称之为内存分段机制，程序分段是软件中人为逻辑划分的内存区域，它本身也是内存，所以处理器在访问该区域时，也会采用内存分段机制，用段寄存器指向该区域的起始地址。
物理地址就是物理内存真正的地址，相当于内存中每个存储单元的门牌号，具有唯一性。不管在什么模式下，不管什么虚拟地址、线性地址，CPU最终都要以物理地址去访问内存，只有物理地址才是内存访问的终点站。
在实模式下，“段基址+段内偏移地址”经过段部件的处理，直接输出的就是物理地址，CPU可以直接用此地址访问内存。
而在保护模式下，“段基址+段内偏移地址”称为线性地址，不过，此时的段基址已经不再是真正的地址了，而是一个称为选择子的东西。它本质是个索引，类似于数组下标，通过这个索引便能在GDT中找到相应的段描述符，在该描述符中记录了该段的起始、大小等信息，这样便得到了段基址。若没有开启地址分页功能，此线性地址就被当作物理地址来用，可直接访问内存。若开启了分页功能，此线性地址又多了一个名字，就是虚拟地址（虚拟地址、线性地址在分页机制下都是一回事）。虚拟地址要经过CPU页部件转换成具体的物理地址，这样CPU才能将其送上地址总线去访问内存。
无论在实模式或是保护模式下，段内偏移地址又称为有效地址，也称为逻辑地址，这是程序员可见的地址。这是因为，最终的地址是由段基址和段内偏移地址组合而成的。由于段基址已经有默认的啦，要么是在实模式下的默认段寄存器中，要么是在保护模式下的默认段选择子寄存器指向的段描述符中，所以只要给出段内偏移地址就行了，这个地址虽然只是段内偏移，但加上默认的段基址，依然足够有效。
线性地址或称为虚拟地址，这都不是真实的内存地址。它们都用来描述程序或任务的地址空间。由于分页功能是需要在保护模式下开启的，32位系统保护模式下的寻址空间是4GB，所以虚拟地址或线性地址就是0～4GB的范围。转换过程如图5所示。
▲图5 虚拟地址、物理地址等
其实上面已经提到了段重叠，也许有的读者已经明白了，但还是在此特意解释一下吧。
依然假设在实模式下（并不是说在保护模式下就不存在段重叠，只是这样就会少解释了相关数据结构，如段描述符，不过这不重要，原理是一样的），一个段最大为64KB，其大小由段内偏移地址寻址范围决定，也就是2的16次方。其起始位置由段基地址决定。CPU的内存寻址方式是：给我一个段基址，再给我一个相对于该段起始位置的偏移地址，我就能访问到相应内存。它并不要求一个内存地址只隶属于某一个段，所以在上面的图0-2中，欲访问内存0xC03，段基址可以选择0xC00，0xC01，0xC02，0xC03，只不过是段内偏移量要根据段基地址来调整罢了。用这种“段基地址：段内偏移”的组合，0xC00：3和0xC02：1是等价的，它们都访问到同一个物理内存块。但段的大小决定于段内偏移地址寻址范围，假设段A的段基址是从0xC00开始，段B的段基址是从0xC02开始，在16位宽度的寻址范围内，这两个段都能访问到0xC05这块内存。用段A去访问，其偏移为5，用段B去访问，其偏移量为3。这样一来，用段B和段A在地址0xC02之后，一直到段B偏移地址为0xfffe的部分，像是重叠在一起了，这就是段重叠了，如图6所示。
▲图6 段重叠
平坦模型是相对于多段模型来说的，所以说平坦模型指的就是一个段。比如在实模式下，访问超过64KB的内存，需要重新指定不同的段基址，通过这种迂回变通的方式才能达到目的。在保护模式下，由于其是32位的，寻址范围便能够达到4GB，段内偏移地址也是地址，所以也是32位。可见，在32位环境下用一个段就能够访问到硬件所支持的所有内存。也就是说，段的大小可以是地址总线能够到达的范围。既然平坦模型是相对于多段模型来说的，为什么不称为单段模型，而称为平坦呢，我估计很多读者已经明白了，用多个小段再加上不断换段基址的方式访问内存确实够麻烦的，可能换着换着就晕了，别忘记了，这种多段模型为了访问到1MB地址空间，还需要额外打开A20地址线呢，这种访存方式本身就是种补救措施，相当于给硬件打了个补丁，既然是补丁，访问内存的过程必然是不顺畅的。相对于那么麻烦的多段模型，平坦模型不需要额外打开A20地址线，不需要来回切换段基址就可以在地址空间内任意翱翔。如果把内存段比喻成小格子的话，平坦模型下的内存访问，没有众多小格子成为羁绊，可谓一路“平坦”。
所以“平坦”这两个字，突显了当时的程序员受多段模型折磨之苦，迫不及待地想表达其优势的喜悦之情。
CPU中存在段寄存器是因为其内存是分段访问的，这是设计之初决定的，属于基因里的东西。前面已经介绍过了内存分段访问的方法，这里不再赘述。
CPU内部的段寄存器（Segment reg）如下。
（1）CS——代码段寄存器（Code Segment Register），其值为代码段的段基值。
（2）DS——数据段寄存器（Data Segment Register），其值为数据段的段基值。
（3）ES——附加段寄存器（Extra Segment Register），其值为附加数据段的段基值，称为“附加”是因为此段寄存器用途不像其他sreg那样固定，可以额外做他用。
（4）FS——附加段寄存器（Extra Segment Register），其值为附加数据段的段基值，同上，用途不固定，使用上灵活机动。
（5）GS——附加段寄存器（Extra Segment Register），其值为附加数据段的段基值。
（6）SS——堆栈段寄存器（Stack Segment Register），其值为堆栈段的段值。
32位CPU有两种不同的工作模式：实模式和保护模式。
每种模式下，段寄存器中值的意义是不同的，但不管其为何值，在段寄存器中所表达的都是指向的段在哪里。在实模式下，CS、DS、ES、SS中的值为段基址，是具体的物理地址，内存单元的逻辑地址仍为“段基值：段内偏移量”的形式。在保护模式下，装入段寄存器的不再是段地址，而是“段选择子”（Selector），当然，选择子也是数值，其依然为16位宽度。
可见，在32位CPU中，sreg无论是工作在16位的实模式，还是32位的保护模式，用的段寄存器都是同一组，并且在32位下的段选择子是16位宽度，排除了段寄存器在32位环境下是32位宽的可能，综上所述，sreg都是16位宽。
这两个小问题，一些非开发型技术人员经常会问到，做过开发的同学肯定了解。想想还是简单说一下吧（因为这名词似乎也没法说复杂）。
软件中的工程是指开发一套软件所需要的全部文件，包括配置环境。
在一般的集成开发环境中如eclipse或vc++，在程序的开始都是先建立一个project，这就是所谓的工程，它相当于一个大目录，以后写的代码都在这里面。
全部文件包含实际代码和环境配置两部分。实际代码部分，除了自己写的代码文件之外，一般都要包含其他同事写的头文件，若是与他方合作，还要包含第三方头文件。环境配置部分，一般是配置一些模板、库文件目录，具体还要根据所用的实际框架来配置，包含一些服务器的地址，端口之类也都在配置文件中。还是那句话，工程就是为了完成软件编写所涉及的全部相关文件。
协议是一种大家共同遵守的规约，主要用来实现通信、共享、协作；起初是为避免大家各干各的，无法彼此调用对方成果的情况，从而给大家统一一种接口、一组数据调用或者分析的约定。
大家达成一致后，都遵守这个约定开发自己的产品，别人只要也按照这个约定就能够享用自己的成果，从而实现了彼此兼容。只要是技术人员都对TCP/IP有所了解，这就是我们目前赖以生存的网络协议。根据OSI七层模型，它规定数据的第一层，也就是最外层物理层，这一层包含的是电路相关的数据。发送方和接收方都彼此认同最外层的就是电路传输用的数据。每一层中的前几个固定的字节必须是描述当前层的属性，根据此属性就能找到需要的数据。各层中的数据部分都是更上一层的数据，如第一层（物理层）中的数据部分是第二层（数据链路层）的属性+数据，第三层（网络层）的数据部分是第四层（传输层）TCP或UDP的属性+数据。各层都是如此，直到第七层（应用层）的数据部分才是真正应用软件所需要的数据。由此可见，对方一大串数据发过来后，经过层层剥离处理，到了最终的接收方（应用软件），只是一小点啦。
如图7所示，两边的应用程序互发数据时，其实发的就是最顶层的那一小点“数据”，每下一层，便加了各层的报文头，上层整个（包括自己的报文头和报文体）全部成了下一层的数据部分。
这样说似乎还是很抽象，具体地说，就是需要的数据是在偏移文件固定大小的字节处，这个固定字节是多少，就是协议中所规定的。不了解TCP/IP的同学可以参看各层报文格式，自行查阅吧。
▲图7 OSI七层模型
其实，Windows下的程序也无法直接在Linux下运行。
对于这个问题，很多同学都会马上给出答案：格式不同。其实……答对啦，确实是格式不同，不过这只是一方面，还有另一方面，系统API不同，API即Application Programming Interface，应用程序编程接口。
先说说格式。其实格式也算是协议，就是在某个固定的位置有固定意义的数据。Linux下的可执行程序格式是elf，也就是 “Executable and Linking Format”平时咱们用readelf命令可以查看elf文件头，里面有节（section）信息、段（segment）信息、程序入口（entry_point）、哪个段由哪些节组成等信息。
而Windows下的可执行程序是PE格式（portable executable，可移植的可执行文件），因为我没了解过，所以具体文件头咱们就不关注了，有兴趣的同学自行查看。
那如果Linux支持了PE格式就可以运行Wndows程序了吗？也不行，因为在上面说过了，还有系统API不同。Linux中的API称为系统调用，是通过int 0x80这个软中断实现的。而Windows中的API是存放在动态链接库文件中的，也就是Windows开发人员常说的DLL，即Dynamic Link Library 的缩写。LL是一个库，里面包含代码 和数据，可供用户程序调用，DLL不是可执行文件 ，不能够单独运行。也就是说，Linux中的可执行程序获得系统资源的方法和Windows不一样，所以显然是不能在Windows中运行的。
除以上原因外，这还和编译器、标准库有关，不再列举。
局部变量，顾名思义其作用域属于局部，并不是像static那样属于全局性的。全局的变量，意味着谁都可以随时随地访问，所以其放在数据段中。而局部变量只是自己在用，放在数据段中纯属浪费空间，没有必要，故将其放在自己的栈中，随时可以清理，真正体现了局部的意义。这个就是堆栈框架，提到了就说一点吧，栈由于是向下生长的，堆栈框架就是把esp指针提前加一个数，原esp指针到新esp指针之间的栈空间用来存储局部变量。解释一个概念，堆是程序运行过程中用于动态内存分配的内存空间，是操作系统为每个用户进程规划的，属于软件范畴。栈是处理器运行必备的内存空间，是硬件必需的，但又是由软件（操作系统）提供的。堆是堆，而堆栈就是栈，和堆没关系，只是都这么叫。栈和堆栈都是指的栈，在C程序的内存布局中，由于堆和栈的地址空间是接壤的，栈从高地址往低地址发展，堆是从低地址往高地址发展，堆和栈早晚会碰头，它们各自的大小取决于实际的使用情况，界限并不明朗，所以这可能是堆栈常放在一直称呼的原因吧。
函数参数为什么会放到栈区呢？第一也是其局部性导致的，只有这个函数用这个参数，何必将其放在数据段呢。第二，这是因为函数是在程序执行过程中调用的，属于动态的调用，编译时无法预测会何时调用及被调用的次数，函数的参数及返回值都需要内存来存储，如果是递归调用的话，参数及返回值需要的内存空间也就不确定了，这取决于递归的次数。也许这么说您也依然觉得费解，如果完全明白，需要了解一下编译原理，很多知识都是通过实践后才搞明白的。当然我不是说让您为了搞明白这个问题而去尝试写个编译器。
总之，在函数的编译阶段根本无法确定它会被调用几次，其参数和函数的返回地址也要内存来存储，所以也不知道其会需要多少内存。我想，即使神通广大的编译器设计者可以预测这些了，那提前准备好内存也是一种浪费，而且您想啊，在系统中可用内存紧缺的情况下，提前把内存分配给目前并不使用内存的进程（只因为要存储其函数参数），而眼前需要内存的程序若无内存可用，引用罗永浩老师的一句话：“我想不到比这个更伤感的事情了”所以编译器为了让世界更美好一些，选择将为函数参数动态分配内存，也就是在每次调用函数时才为它在栈中分配内存。
首先说这是谬论（有没有想喷我的冲动？大人且慢，请听我慢慢道来）。
不管用什么语言，程序最终都是给CPU运行的，只有CPU才能让程序跑起来。CPU不知道什么是汇编语言、C语言，甚至Java、PHP、Python等，它根本不知道交给它的指令曾经经历过那么多的解释、编译工序。不管什么语言，编译器最终翻译出来的都是机器指令。所以在这一点来说，汇编语言编译器编译出来的机器指令和C编译器编译出来的机器指令无异。
那为什么还说汇编语言更快呢？
我觉得应该说汇编语言生成的指令数更少，从而“显得”执行得快，并不是汇编语言本身有多少威武霸气，而是因为汇编语言本身就是机器指令的符号化，意思是说，一个汇编语言中的符号对应一个机器指令，它们是一一对应的。用汇编语言写程序就相当于直接在写机器指令，汇编语言编译器并不会添加额外的语句，因此汇编语言写的程序会更直接，CPU不会因多执行一些无关的指令而浪费时间，当然会快。
再看看C编译器为咱们做了什么。为了让C程序员更加方便地编程，C编译器在背后做了大量的工作，不仅如此，出于通用性、易用性或者其他方面的考虑，C编译器往往会在背后加入额外的C语言代码来支撑，因此实际的C代码量就变得很大。另外在编译阶段，C代码会率先被编译成汇编代码，然后再由汇编器将汇编代码翻译成机器指令，由于C代码已经变得冗余了，编译出的汇编代码自然也会冗余，其机器指令也会多很多。
大多数人愿意用C语言写程序是因为C语言强大且更容易掌握。但这份优势是有代价的。C程序员不用考虑切换栈，不用考虑用哪个段。这些必须要考虑的事情，程序员不考虑，只好由编译器帮着考虑了。而且为了通用性、功能，甚至安全方面的考虑，自然在背后要多写一些代码。就拿打印字符串来说，C语言的printf()，这里面的工作可多了去了，不仅要检查打印的数据类型，还要负责格式，小数点保留位数……而在汇编语言中只要往显存地址处mov一个字符就行了，字符串也就是多几个mov操作而已。您说，C语言为了让开发者用得爽，自己在背后做了多少贡献。
总结：高级语言如C语言为了通用性等，需要兼顾的东西比较多，往往还加入了一些额外的代码，因此编译出来的汇编代码比较多，很多部分都是一些周边功能，并不是直接起作用的，不如用汇编语言直接写功能相关的部分效果来得更直接，C语言被编译成机器指令后，生成的机器指令当然也包括这些额外的部分，相当于多执行了一些“看似没用”的指令，因此会比直接用汇编语言慢。
首先肯定的是先有的编程语言，哪怕这个语言简单到只有一个符号。先是设计好语言的规则，然后编写能够识别这套规则的编译器，否则若没有语言规则作为指导方向，编译器编写将无从下笔。
第1个编译器是怎么产生的？这个问题我并没有求证，不过可以谈下自己的理解，请大伙儿辩证地看。
这个问题属于哲学中鸡生蛋、蛋生鸡的问题，这种思维回旋性质的本源问题经常让人产生迷惑。可是现实生活中这样的例子太多了。
（1）英语老师教学生英语，学生成了英语老师后又可以教其他学生英语。
（2）写新的书需要参考其他旧书，新的书将来又会被更新的书参考，就像本书编写过程一样，要参考许多前辈的著作。
（3）用工具可以制造工具，被制造出来的工具将来又可以制造新的工具。
（4）编译器可以编译出新的编译器。
这种自己创造自己的现象，称为自举。
自举？是不是自己把自己举起来？是的，人是不能把自己举起来的，这个词很形象地描述了这类“后果必须有前因”的现象。
以上前三个列举的都是生活例子，似乎比第4个更容易接受。即使这样，对于前三个例子大家依然会有疑问。
（1）第一个会英语的人是谁教的？
（2）第一本书是怎样产生的？
（3）第一个工具是如何制造出来的？
其实看到第2个例子大家就可能明白了，世界上的第一本书，它的知识来源肯定是人的记忆，通过向个人或群众打听，把大家都认同的知识记录到某个介质上，这样第一本书就出生了。此后再记录新的知识时，由于有了这本书的参考，不需要重新再向众人打听原有知识了，从此以后便形成了书生书的因果循环。
从书的例子可以证明，本源问题中的第一个，都是由其他事物创建出来的，不是自己创造的自己。
就像先有鸡还是先有蛋一样，一定是先有其他生命体，这个生命体不是今天所说的鸡。伴随这个生命体漫长的进化中，突然有一天它具备了生蛋的能力（也许这个蛋在最初并不能孵化成鸡，这个生命体又经过漫长的进化，最终可以生出能够孵化成鸡的蛋），于是这个蛋可以生出鸡了。过了很久之后，才有的人类。人一开始接触的便是现在的鸡而不知道那个生命体的存在，所以人只知道鸡是由蛋生出来的。
很容易让人混淆的是编译C语言时，它先是被编译成汇编代码，再由汇编代码编译为机器码，这样很容易让人误以为一种语言是基于一种更底层的语言。
似乎没有汇编语言，C语言就没有办法编译一样。拿gcc来说，其内部确实要调用汇编器来完成汇编语言到机器码的翻译工作。因为已经有了汇编语言编译器，那何必浪费这个资源不用，自己非要把C语言直接翻译成机器码呢，毕竟汇编器已经无比健壮了，将C直接变成机器码这个难度比将C语言翻译为汇编语言大多了，这属于重新造轮子的行为。
曾经我就这样问过自己，PHP解释器是C语言写的，C编译器是汇编写的（这句话不正确），汇编是谁写的呢？后来才知道，编译器GCC其实是用C语言写的。乍一听，什么？用C语言写C编译器？自己创造自己，就像电影超验骇客一样。当时的思维似乎陷入了死循环一样，现在看来这不奇怪。其实编译器用什么语言写是无所谓的，关键是能编译出指令就行了。编译出的可执行文件是要写到磁盘上的，理论上，只要某个进程，无论其是不是编译器，只要其关于读写文件的功能足够强大，可以往磁盘上写任意内容，都可以生成可执行文件，直接让操作系统加载运行。想象一下，用Python写一个脚本，功能是复制一个二进制可执行文件，新复制出来的文件肯定是可以执行的。那Python脚本直接输出这样的一个二进制可执行文件，它自然就是可以直接执行的，完全脱离Python解释器了。
编译器其实就是语言，因为编译器在设计之初就是先要规划好某种语言，根据这个语言规则来写合适的编译器。所以说，要发明一种语言，关键是得写出与之配套的编译器，这两者是同时出来的。最初的编译器肯定是简单粗糙的，因为当时的编程语言肯定不完善，顶多是几个符号而已，所以难以称之为语言。只有功能完善且符合规范，有自己一套体系后才能称之为语言。不用说，这个最初的编译器肯定无法编译今天的C语言代码。编程语言只是文本，文本只是用来看的，没有执行能力。最初的编译器肯定是用机器码写出来的。这个编译器能识别文本，可以处理一些符号关键字。随着符号越来越多，不断地改进这个编译器就是了。
以上的符号就是编程语言。后来这个编译器支持的关键字越来越多了，也就是这个编译器支持的编程语言越发强大了，可以写出一些复杂的功能的时候，干脆直接用这个语言写个新的编译器，这个新的编译器出生时，还是需要用老的编译器编译出来的。只要有了新的编译器，之后就可以和老的编译器说拜拜了。发明新的编译器实际上就是为了能够处理更多的符号关键字，也就是又有新的开发语言了，这个语言可以是全新的，也可以是最初的语言，这取决于编译器的实现。这个过程不断持续，不断进化，逐渐才有了今天的各种语言解释器，这是个迭代的过程。
图8所示这张图片在网络上非常火，它常常与励志类的文字相关。起初看到这个雕像在雕刻自己时，我着实被感动了，感受到的是一种成长之痛。今天把它贴过来的目的是想告诉大家，起初的编译器也是功能简单，不成规范，然而经过不断自我“雕刻”，它才有了今天功能的完善。
▲图8 雕刻（来源网络）
本文节选自《操作系统真象还原》
内容简介
本书共分16章，讲解了开发一个操作系统需要的技术和知识，主要内容有：操作系统基础、部署工作环境、编写MBR主引导记录、完善MBR错误、保护模式入门、保护模式进阶和向内核迈进、中断、内存管理系统、线程、输入输出系统、用户进程、完善内核、编写硬盘驱动程序、文件系统、系统交互等核心技术。
本书适合程序员、系统底层开发人员、操作系统爱好者阅读，也可作为大专院校相关专业师生用书和培训学校的教材。