编程珠玑番外篇-D. 高级语言怎么来的

最新推荐文章于 2022-04-16 14:44:23 发布

iteye_5282

最新推荐文章于 2022-04-16 14:44:23 发布

阅读量377

点赞数

文章标签：运维 php 嵌入式

编程珠玑番外篇-D.高级语言怎么来的-1

作者：徐宥

原文：http://blog.youxu.info/2009/05/13/hpl/

终于放暑假了,有心情来八卦了.我主要想八卦一下高级语言的设计思想和各种范式的来龙去脉,也就是回答这个问题:编程语言为什么会发生成现在这个样子哩?　这里面的奥妙又在哪里哩?我尝试着把这个系列的八卦写下去,包括虚拟机的设计,线程的设计,栈和寄存器两大流派的来龙去脉等等,也算是完成年初给大家许下的诺言.

高级编程语言的创始纪上写道:”初,世间无语言,仅电路与连线.及大牛出,天地开,　始有FORTRAN,　LISP. ALGOL随之,乃有万种语.” 我们都知道, LISP是基于递归函数的, FORTRAN是做科学计算的.现在的C等等,都比较像FORTRAN不像LISP.可是很少有人知道,最初, FORTRAN是不支持函数递归调用的,而LISP是一生下来就支持的,所有高级语言里面的递归调用,都是逐渐从LISP那里学来的.这段尘封的历史非常有趣,值得八卦一番.

一般人学编程,除了写Hello World之外,人生写的第二个程序,不是阶乘就是菲波拉契数列,　要不就是汉洛塔.而这几个程序,基本上都是因为函数的递归调用才显得简单漂亮.没有递归的日子里,人民非常想念您.可是,第一版的FORTRAN就居然居然不支持递归.细心的读者要问了,不支持递归的语言能图灵完全么?　当然可以,图灵机就是没递归的典型的例子.但是没递归调用的程序会很难写,尤其像汉诺塔这种.那么, FORTRAN他怎么就悍然不支持递归呢,让我们回到1960年.

话说当年,　IBM是计算机行业的领军者.　那时候的计算机,　都是比柜子还大的大家伙,至于计算能力嘛,却比你的手机还弱.　那时候计算机所做的最多的事情,　不是发邮件打游戏,　而是作计算.　作计算嘛,　自然需要一种和数学语言比较接近的编程语言.　于是,　1960年, IBM　就捣鼓出了FORTRAN,用行话说,　就是公式翻译系统.　这个公式翻译系统,　就成了世界上第一个编程语言.这个编程语言能做数学计算,　能作条件判断,　能GOTO.　用现在的眼光看,　这个语言能构模拟图灵机上的一切操作,　所以是图灵完全的.　学过数值计算的同学都知道,科学计算无非就是一大堆数学计算按照步骤进行而已.所以,一些控制判断语句,数学公式加上一个数组,基本上就能完成所有的科学计算了. IBM觉得这个语言够用了,就发布了FORTRAN　语言规范,并且在自家的大型机上实现了这个语言.　

在实现这个语言的时候, IBM　的工程师要写一个FORTRAN编译器(请注意那时候的大型机没有操作系统).那时候的编译器都是用机器语言或者很低级的汇编语言写成的,所以编译器要越简单越好.这些工程师觉得,　弄一个让用户运行时动态开辟内存的机制太麻烦了,　所以干脆,　强迫用户在写程序的时候,　就要定好数组的大小,　变量的类型和数目.这个要求并不过分,因为在科学计算中,数组的维度,用到的变量等,在计算之前,就是可以知道大小的.用现在的话说,　就是不能动态开辟内存空间,也就相当于没有malloc的C,或者没有new的C＋＋.这样的好处是,一个程序要多少内存,编译的时候就知道的一清二楚了.这个主意看上去很聪明,不过IBM的工程师比你想得更加聪明,他们想,既然一个程序或者子程序要多少内存在编译的时候都知道了,我们干脆就静态的把每个子程序在内存中的位置,子程序中参数,返回值和局部变量放的位置,大小都定好,不久更加整齐高效么.是的,我们都知道,在没有操作系统管理的情况下,程序的内存策略越简单越好,如果内存放的整整齐齐的,计算机的管理员就能够很好的管理机器的内存,这样也是一件非常好的事情. (再次强调,当年还没有操作系统呢,操作系统要等到1964年发布的IBM 360才有,具体开发一个操作系统之难度可参考<人月神话>).

可是,聪明的读者一下子就看出来了,这样静态的搞内存分配,就递不成归不了了.为啥呢.试想,我有个Fib函数,用来计算第N个菲波拉契数.这个函数输入一个整数,返回一个整数, FORTRAN编译器帮我把这个函数给静态分配了.好,我运行Fib(5)起来, FORTRAN帮我把5存在某个专门给输入参数的位置.我在Fib(5)里面递归的调用了Fib(4), FORTRAN一看,哈,不还是Fib么,参数是4,我存.这一存,新的参数4,就把原来的5给覆盖掉了,新的返回值,也把原来的返回值给覆盖掉了.大事不好了,这么一搞,新的调用的状态居然覆盖了老的调用,这下,就没法返回原来的Fib(5)了,这样一搞,怎么递归啊?

IBM这些写编译器的老前辈们,不是不知道这个问题,而是压根就鄙视提出这个问题的人:你丫科学计算递归什么呀,通通给我展开成循环,展不开是你数学没学好,想用递归,你就不要用FORTRAN了.那时候IBM乃是老大,只有他们家才生产大型机,老大发话,下面的消费者只能听他的.

既然软件不支持,硬件也就可以偷工减料嘛,所以,硬件上,就压根没有任何栈支持.我们都知道,计算机发展史上,软件和硬件是相互作用的.我们现在也很难猜测,是IBM的软件工程师因为IBM的硬件工程师没有在硬件上设计出堆栈所以没有能在FORTRAN里面设计出递归调用呢,还是IBM的硬件工程师觉得既然软件没要求,我就不设计了呢?不管怎么样,我们看到的是, 1960年前,所有的机器的硬件都没有直接支持栈的机制.熟悉CPU的都知道,现代CPU里面,都有两个至关重要的地址寄存器,一个叫做PC,用来标记下一条要执行的指令的位置,还有一个就是栈顶指针SP.如果没有后者,程序之间的调用就会非常麻烦,因为需要程序员手工维护一个栈,才能保证程序之间调用最后还能正确的返回.而当年,因为FORTRAN压根就不支持递归,所以支持FORTRAN的硬件,就省去了栈指针了.如果一个程序员想要递归调用,唯一的实现方法,就是让程序员借用一个通用寄存器作为栈指针,自己硬写一个栈,而且不能用FORTRAN.

因为　FORTRAN不支持递归调用,按照自然规律,自然会有支持递归的语言在同时代出现.于是,很快的, LISP和ALGOL这两个新语言就出道了.我们只说LISP.它的创始人John McCarchy是　MIT　教授,也是人工智能之父,是学院派人物.他喜欢丘齐的那一套Lambda演算,而非图灵的机械构造.所以, LISP从一开始,就支持递归的调用,因为递归就是　lambda演算的灵魂.但是有两大问题摆在　McCarchy面前.一是他的LISP理论模型找不到一个可以跑的机器,二是他的　LISP模型中有一个叫做　eval的指令,可以把一个字符串当成指令在运行时求值,而这个,当时还没有人解决过.按照Paul Graham大叔在他的Hackers and Painters里面的说法, McCarchy甚至压根就不想实现这个eval指令,因为当IBM的一个叫Steve Russell的工程师宣称要实现eval的时候, McCarthy还连连摇手说理论是理论,实际是实际,我不指望这个能被实现.可是, Russell居然就把这两个问题一并给解决了(这哥们也是电子游戏创始人,史上第一个电子游戏就是他写的,叫　Space War).　他的方法,说来也简单,就是写了一个解释器,让　LISP在这个解释器里面跑.这个创举,让传统上编译－>运行的高级语言流程,变成了　编写->解释执行的流程,也就是著名的REPL流程.他做的事情,相当于在IBM的机器上用机器码写了一个通用图灵机,用来解释所有的　LISP指令.这个创举,就让LISP从理论走到了实践.

因为有了运行时的概念, LISP想怎么递归,就可以怎么递归,只要运行时支持一个软件实现的栈就可以了.上面我也说了,也就是写解释器的人麻烦一点而已,写LISP程序的人完全就可以不管下层怎么管理栈的了.同时,有了解释器,也解放了原来动态分配空间的麻烦,因为现在所有的空间分配都可以由解释器管理了,所以,运行时环境允许你动态的分配空间.对空间分配的动态支持,随之就带来了一项新技术:垃圾收集器.这个技术出现在　LISP里面不是偶然的,是解释器的自然要求和归宿.在FORTRAN上本来被绕过的问题,就在LISP里面用全新的方法被解决了. LISP的划时代意义和解释器技术,使得伴随的很多技术,比如抽象语法树,动态数据结构,垃圾收集,字节码等等,都很早的出现在了LISP中,加上LISP本身规则很少,使用起来非常灵活,所以,每当有一项新技术出现,特别是和解释器和运行时相关的一项新技术出现,我们就会听到有人说,“这玩意儿LISP里早就有了”,这话,是有一定道理的.

除了上面的软件模拟之外, MIT还有一派在作硬件模拟,这一派,以后发展成了灿烂一时的　LISP machine,为日后所有虚拟机理论铺开了一条新路.这一派在70, 80年代迅速崛起,然后随着　PC的兴起又迅速的陨落,让人唏嘘不已.

最后附送一个八卦: 1960年的时候,高级语言编程领域也发生了一件大事,即　ALGOL 60的提出. ALGOL是划时代的标准,我们今天用的　C/Java全是　ALGOL家族的. ALGOL注意到了　FORTRAN的不支持递归的问题,于是从一开始,就订立标准支持递归.但是,处理递归需要很小心的安排每个函数每次调用的地址和所谓的活动窗口(Active Frame),而并不是每个编译器都是牛人写的,所以在处理递归这样一个新事物上,难免会出点小问题和小BUG.这时候,搞笑的高爷爷(Knuth)出场了,他提出了一个测试,叫做 “是男人就得负67″. (The man or boy test).恕我功底不深,不能给各位读者把这个男人测试的关窍讲清楚,但是,我知道,这个测试,乃是看ALGOL 60编译器有没有正确的实现递归和外部引用的.照高爷爷的说法,真的男人要能得到正确答案,不是男人的就得不到正确答案.当然,高爷爷当时自己也没有男人编译器,所以自己猜了一个-121,后来,真的男人编译器出来了,正确答案是-67.可见,高爷爷的人脑编译器,也不是男人编译器…

编程珠玑番外篇-E.高级语言怎么来的-2

虚拟机的前世今生

上节我们提到了LISP中,因为eval的原因,发展出了运行时环境这样一个概念。基于这个概念，日后发展出了虚拟机技术。但这段历史并不是平铺直叙的，实际上，这里面还经历了一个非常漫长而曲折的过程，说起来也是非常有意思的。这一节我们就着重解释虚拟机的历史。

我们21世纪的程序员，凡要是懂一点编程技术的，基本上都知道虚拟机和字节码这样两个重要的概念。所谓的字节码(bytecode)，是一种非常类似于机器码的指令格式。这种指令格式是以二进制字节为单位定义的（不会有一个指令只用到一个字节的前四位），所以叫做字节码。所谓的虚拟机，就是说不是一台真的计算机，而是一个环境，其他程序能在这个环境中运行，而不是在真的机器上运行。现在主流高级语言如Java, Python, PHP, C#，编译后的代码都是以字节码的形式存在的，这些字节码程序，最后都是在虚拟机上运行的。

1.虚拟机的安全性和跨平台性

虚拟机的好处大家都知道，最容易想到的是安全性和跨平台性。安全性是因为现在可执行程序被放在虚拟机环境中运行，虚拟机可以随时对程序的危险行为，比如缓冲区溢出，数组访问过界等等进行控制。跨平台性是因为只要不同平台上都装上了支持同一个字节码标准的虚拟机，程序就可以在不同的平台上不加修改而运行，因为虚拟机架构在各种不同的平台之上，用虚拟机把下层平台间的差异性给抹平了。我们最熟悉的例子就是Java了。Java语言号称一次编写，到处运行(Write Once, Run Anywhere)，就是因为各个平台上的Java虚拟机都统一支持Java字节码，所以用户感觉不到虚拟机下层平台的差异。

虚拟机是个好东西，但是它的出现，不是完全由安全性和跨平台性驱使的。

2.跨平台需求的出现

我们知道，在计算机还是锁在机房里面的昂贵的庞然大物的时候，系统软件都是硬件厂商附送的东西（是比尔盖茨这一代人的出现，才有了和硬件产业分庭抗礼的软件产业），一个系统程序员可能一辈子只和一个产品线的计算机打交道，压根没有跨平台的需求。应用程序员更加不要说了，因为计算机很稀有，写程序都是为某一台计算机专门写的，所以一段时间可能只和一台庞然大物打交道，更加不要说什么跨平台了。真的有跨平台需求，是从微型计算机开始真的普及开始的。因为只有计算机普及了，各种平台都被广泛采用了，相互又不互相兼容软件，才会有软件跨平台的需求。微机普及的历史，比PC普及的历史要早10年，而这段历史，正好和UNIX发展史是并行重叠的。

熟悉UNIX发展史的读者都知道，UNIX真正普及开来，是因为其全部都用C，一个当时绝对能够称为跨平台的语言重写了一次。又因为美国大学和科研机构之间的开源共享文化，C版本的UNIX出生没多久，就迅速从原始的PDP-11实现，移植到了DEC，Intel等平台上，产生了无数衍生版本。随着跨平台的UNIX的普及，微型计算机也更多的普及开来，因为只需要掌握基本的UNIX知识，就可以顺利操作微型计算机了。所以，微机和UNIX这两样东西都在1970年到1980年在美国政府，大学，科研机构，公司，金融机构等各种信息化前沿部门间真正的普及开来了。这些历史都是人所共知耳熟能详的。

既然UNIX是跨平台的，那么，UNIX上的语言也应当是跨平台的（注:本节所有的故事都和Windows无关，因为Windows本身就不是一个跨平台的操作系统）。UNIX上的主打语言C的跨平台性，一般是以各平台厂商提供编译器的方式实现的，而最终编译生成的可执行程序，其实不是跨平台的。所以，跨平台是源代码级别的跨平台，而不是可执行程序层面的。而除了标准了C语言外，UNIX上有一派生机勃勃的跨平台语言，就是脚本语言。（注：脚本语言和普通的编程语言相比，在能完成的任务上并没有什么的巨大差异。脚本语言往往是针对特定类型的问题提出的，语法更加简单，功能更加高层，常常几百行C语言要做的事情，几行简单的脚本就能完成）

3.解释和执行

脚本语言美妙的地方在于，它们的源代码本身就是可执行程序，所以在两个层面上都是跨平台的。不难看出，脚本语言既要能被直接执行，又要跨平台的话，就必然要有一个“东西”，横亘在语言源代码和平台之间，往上，在源代码层面，分析源代码的语法，结构和逻辑，也就是所谓的“解释”；往下，要隐藏平台差异，使得源代码中的逻辑，能在具体的平台上以正确的方式执行，也就是所谓的“执行”。

虽说我们知道一定要这么一个东西，能够对上“解释”，对下“执行”，但是“解释”和“执行”两个模块毕竟是相互独立的，因此就很自然的会出现两个流派：把解释和执行设计到一起和把解释和执行单独分开来这样两个设计思路，需要读者注意的是，现在这两个都是跨平台的，安全的设计，而在后者中字节码作为了解释和执行之间的沟通桥梁，前者并没有字节码作为桥梁。

4.解释和执行在一起的方案

我们先说前者，前者的优点是设计简单，不需要搞什么字节码规范，所以UNIX上早期的脚本语言，都是采用前者的设计方法。我们以UNIX上大名鼎鼎的AWK和Perl两个脚本语言的解释器为例说明。AWK和Perl都是UNIX上极为常用的，图灵完全的语言，其中AWK,在任何UNIX系统中都是作为标准配置的，甚至入选IEEE POSIX标准，是入选IEEE POSIX卢浮宫的唯一同类语言品牌，其地位绝对不是UNIX下其他脚本语言能够比的。这两个语言是怎么实现解释和运行的呢？我从AWK的标准实现中摘一段代码您一看就清楚了:

int main(int argc, char *argv[]) {

...

  syminit();

  compile_time = 1;

  yyparse();

...

    if (errorflag == 0) {

      compile_time = 0;

      run(winner);

...

其中,run的原型是
run(Node *a) /* execution of parse tree starts here */

而winner的定义是:
Node *winner ; /* root of parse tree */

熟悉Yacc的读者应该能够立即看出, AWK调用了Yacc解析源代码，生成了一棵语法树。按照winner的定义,winner是这棵语法树的根节点。在“解释”没有任何错误之后，AWK就转入了“执行” (compile_time变成了0)，将run作用到这棵语法树的根节点上。不难想像，这个run函数的逻辑是递归的（事实上也是），在语法树上，从根依次往下，执行每个节点的子节点，然后收集结果。是的，这就是整个AWK的基本逻辑:对于一段源代码,先用解释器（这里awk用了Yacc解释器），生成一棵语法树，然后，从树的根节点开始，往下用run这个函数，遇山开山，遇水搭桥，一路递归下去，最后把整个语法树遍历完，程序就执行完毕了。（这里附送一个小八卦，抽象语法树这个概念是LISP先提出的，因为LISP是最早像AWK这样做的，LISP实在是属于开天辟地的作品！）Perl的源代码也是类似的逻辑解释执行的，我就不一一举例了。

5.三大缺点

现在我们看看这个方法的优缺点。优点是显而易见的，因为通过抽象语法树在两个模块之间通信，避免了设计复杂的字节码规范，设计简单。但是缺点也非常明显。最核心的缺点就是性能差，需要资源多，具体来说，就是如下三个缺点。

缺点1，因为解释和运行放在了一起，每次运行都需要经过解释这个过程。假如我们有一个脚本，写好了就不修改了，只需要重复的运行，那么在一般应用下尚可以忍受每次零点几秒的重复冗余的解释过程，在高性能的场合就不能适用了。

缺点2，因为运行是采用递归的方式的，效率会比较低。我们都知道，因为递归涉及到栈操作和状态保存和恢复等，代价通常比较高，所以能不用递归就不用递归。在高性能的场合使用递归去执行语法树，不值得。

缺点3，因为一切程序的起点都是源代码，而抽象语法树不能作为通用的结构在机器之间互传，所以不得不在所有的机器上都布置一个解释+运行的模块。在资源充裕的系统上布置一个这样的系统没什么，可在资源受限的系统上就要慎重了，比如嵌入式系统上。鉴于有些语言本身语法结构复杂，布置一个解释模块的代价是非常高昂的。本来一个递归执行模块就很吃资源了，再加一个解释器，嵌入式系统就没法做了。所以，这种设计在嵌入式系统上是行不通的。

当然，还有一些其他的小缺点，比如有程序员不喜欢开放源代码，但这种设计中，一切都从源代码开始，要发布可执行程序，就等于发布源代码，所以不愿意公布源代码的商业公司很不喜欢这些语言等等。但是上面的三个缺点，是最致命的，这三个缺点，决定了有些场合，就是不能用这种设计。

6.分开解释和执行

前面的三个主要缺点，恰好全部被第二个设计所克服了。在第二种设计中，我们可以只解释一次语法结构，生成一个结构更加简单紧凑的字节码文件。这样，以后每次要运行脚本的时候，只需要把字节码文件送给一个简单的解释字节码的模块就行了。因为字节码比源程序要简单多了，所以解释字节码的模块比原来解释源程序的模块要小很多；同时，脱离了语法树，我们完全可以用更加高性能的方式设计运行时，避免递归遍历语法树这种低效的执行方式；同时，在嵌入式系统上，我们可以只部署运行时，不部署编译器。这三个解决方案，预示了在运行次数远大于编译次数的场合，或在性能要求高的场合，或在嵌入式系统里，想要跨平台和安全性，就非得用第二种设计，也就是字节码+虚拟机的设计。

讲到了这里，相信对Java,对PHP或者对Tcl历史稍微了解的读者都会一拍脑袋顿悟了:原来这些牛逼的虚拟机都不是天才拍脑袋想出来的，而是被需求和现实给召唤出来的啊！

我们先以Java为例，说说在嵌入式场合的应用。Java语言原本叫Oak语言，最初不是为桌面和服务器应用开发的，而是为机顶盒开发的。SUN最初开发Java的唯一目的，就是为了参加机顶盒项目的竞标。嵌入式系统的资源受限程度不必细说了，自然不会允许上面放一个解释器和一个运行时。所以，不管Java语言如何，Java虚拟机设计得直白无比，简单无比，手机上，智能卡上都能放上一个Java运行时（当然是精简版本的）。这就是字节码和虚拟机的威力了。

SUN无心插柳，等到互联网兴起的时候, Java正好对绘图支持非常好，在Flash一统江湖之前，凭借跨平台性能，以Applet的名义一举走红。然后，又因为这种设计先天性的能克服性能问题，在性能上大作文章，凭借JIT技术，充分发挥上面说到的优点2，再加上安全性，一举拿下了企业服务器市场的半壁江山，这都是后话了。

再说PHP。PHP的历史就包含了从第一种设计转化到第二种设计以用来优化运行时性能的历史。PHP是一般用来生成服务器网页的脚本语言。一个大站点上的PHP脚本,一旦写好了，每天能访问千百万次，所以，如果全靠每次都解释，每次都递归执行，性能上是必然要打折扣的。所以，从1999年的PHP4开始，Zend引擎就横空出世，专门管加速解释后的PHP脚本,而对应的PHP解释引擎，就开始将PHP解释成字节码，以支持这种一次解释，多次运行的框架。在此之前，PHP和Perl,还有cgi,还算平分秋色的样子，基本上服务器上三类网页的数量都差不多，三者语法也很类似，但是到了PHP4出现之后，其他两个基于第一种设计方案的页面就慢慢消逝了，全部让位给PHP。你读的我的这个Wordpress博客，也是基于PHP技术的，底层也是Zend引擎的。著名的LAMP里面的那个P，原始上也是PHP，而这个词真的火起来，也是99年PHP4出现之后的事情。