本文關(guān)鍵詞：高級語言，由筆耕文化傳播整理發(fā)布。

作者：徐宥

原文：

我主要想八卦一下高級語言的設(shè)計(jì)思想和各種范式的來龍去脈編程語言為什么會(huì)發(fā)生成現(xiàn)在這個(gè)樣子哩包括虛擬機(jī)的設(shè)計(jì)棧和寄存器兩大流派的來龍去脈等等, 也算是完成年初給大家許下的諾言.   僅電路與連線天地開,　始有FORTRAN,　LISP. ALGOL是基于遞歸函數(shù)的現(xiàn)在的都比較像不像可是很少有人知道, 最初, FORTRAN所有高級語言里面的遞歸調(diào)用那里學(xué)來的值得八卦一番.   之外不是階乘就是菲波拉契數(shù)列基本上都是因?yàn)楹瘮?shù)的遞歸調(diào)用才顯得簡單漂亮人民非常想念您第一版的就居然居然不支持遞歸不支持遞歸的語言能圖靈完全么但是沒遞歸調(diào)用的程序會(huì)很難寫那么, FORTRAN年.   至于計(jì)算能力嘛, 卻比你的手機(jī)還弱.　那時(shí)候計(jì)算機(jī)所做的最多的事情,　不是發(fā)郵件打游戲,　而是作計(jì)算.　作計(jì)算嘛,　自然需要一種和數(shù)學(xué)語言比較接近的編程語言.　于是,　1960年, IBM　就搗鼓出了用行話說　用現(xiàn)在的眼光看所以數(shù)學(xué)公式加上一個(gè)數(shù)組, 基本上就能完成所有的科學(xué)計(jì)算了. IBM　語言規(guī)范, 并且在自家的大型機(jī)上實(shí)現(xiàn)了這個(gè)語言.　   編譯器那時(shí)候的編譯器都是用機(jī)器語言或者很低級的匯編語言寫成的這些工程師覺得因?yàn)樵诳茖W(xué)計(jì)算中用到的變量等就是可以知道大小的也就相當(dāng)于沒有的或者沒有＋＋一個(gè)程序要多少內(nèi)存這個(gè)主意看上去很聰明的工程師比你想得更加聰明既然一個(gè)程序或者子程序要多少內(nèi)存在編譯的時(shí)候都知道了子程序中參數(shù)大小都定好是的在沒有操作系統(tǒng)管理的情況下如果內(nèi)存放的整整齊齊的這樣也是一件非常好的事情. (再次強(qiáng)調(diào)操作系統(tǒng)要等到才有人月神話>).   這樣靜態(tài)的搞內(nèi)存分配為啥呢我有個(gè)函數(shù)個(gè)菲波拉契數(shù)返回一個(gè)整數(shù), FORTRAN我運(yùn)行起來存在某個(gè)專門給輸入?yún)?shù)的位置里面遞歸的調(diào)用了Fib(4), FORTRAN不還是么我存新的參數(shù)給覆蓋掉了也把原來的返回值給覆蓋掉了這么一搞這下了怎么遞歸啊?   不是不知道這個(gè)問題你丫科學(xué)計(jì)算遞歸什么呀展不開是你數(shù)學(xué)沒學(xué)好你就不要用那時(shí)候乃是老大老大發(fā)話, 下面的消費(fèi)者只能聽他的.   所以就壓根沒有任何棧支持計(jì)算機(jī)發(fā)展史上我們現(xiàn)在也很難猜測的軟件工程師因?yàn)榈挠布こ處煕]有在硬件上設(shè)計(jì)出堆棧所以沒有能在里面設(shè)計(jì)出遞歸調(diào)用呢的硬件工程師覺得既然軟件沒要求不管怎么樣, 我們看到的是, 1960熟悉里面一個(gè)叫做用來標(biāo)記下一條要執(zhí)行的指令的位置如果沒有后者因?yàn)樾枰绦騿T手工維護(hù)一個(gè)棧而當(dāng)年壓根就不支持遞歸的硬件如果一個(gè)程序員想要遞歸調(diào)用就是讓程序員借用一個(gè)通用寄存器作為棧指針而且不能用 FORTRAN.   按照自然規(guī)律于是, 很快的, LISP這兩個(gè)新語言就出道了它的創(chuàng)始人是　是學(xué)院派人物演算所以, LISP因?yàn)檫f歸就是　但是有兩大問題擺在　一是他的二是他的　的指令而這個(gè)按照 Paul Graham里面的說法指令的一個(gè)叫 Steve Russell的工程師宣稱要實(shí)現(xiàn)的時(shí)候?qū)嶋H是實(shí)際可是, Russell叫　就是寫了一個(gè)解釋器在這個(gè)解釋器里面跑讓傳統(tǒng)上編譯－> 運(yùn)行 的高級語言流程解釋執(zhí)行的流程流程相當(dāng)于在用來解釋所有的　這個(gè)創(chuàng)舉從理論走到了實(shí)踐.   就可以怎么遞歸上面我也說了寫有了解釋器因?yàn)楝F(xiàn)在所有的空間分配都可以由解釋器管理了運(yùn)行時(shí)環(huán)境允許你動(dòng)態(tài)的分配空間隨之就帶來了一項(xiàng)新技術(shù)這個(gè)技術(shù)出現(xiàn)在　是解釋器的自然要求和歸宿上本來被繞過的問題里面用全新的方法被解決了. LISP比如抽象語法樹垃圾收集都很早的出現(xiàn)在了加上本身規(guī)則很少所以特別是和解釋器和運(yùn)行時(shí)相關(guān)的一項(xiàng)新技術(shù)出現(xiàn)“這玩意兒里早就有了”是有一定道理的.   這一派為日后所有虛擬機(jī)理論鋪開了一條新路. 這一派在70, 80年代迅速崛起的興起又迅速的隕落, 讓人唏噓不已.   高級語言編程領(lǐng)域也發(fā)生了一件大事的提出. ALGOL全是　注意到了　于是從一開始但是, 處理遞歸需要很小心的安排每個(gè)函數(shù)每次調(diào)用的地址和所謂的活動(dòng)窗口(Active Frame),難免會(huì)出點(diǎn)小問題和小這時(shí)候出場了叫做 “是男人就得負(fù)不能給各位讀者把這個(gè)男人測試的關(guān)竅講清楚我知道乃是看 ALGOL 60真的男人要能得到正確答案當(dāng)然所以自己猜了一個(gè)后來正確答案是可見也不是男人編譯器…

 虛擬機(jī)的前世今生

因?yàn)榈脑?span lang="EN-US">, 發(fā)展出了運(yùn)行時(shí)環(huán)境這樣一個(gè)概念。基于這個(gè)概念，日后發(fā)展出了虛擬機(jī)技術(shù)。但這段歷史并不是平鋪直敘的，實(shí)際上，這里面還經(jīng)歷了一個(gè)非常漫長而曲折的過 程， 說起來也是非常有意思的。 這一節(jié)我們就著重解釋虛擬機(jī)的歷史。

我們世紀(jì)的程序員，凡要是懂一點(diǎn)編程技術(shù)的，基本上都知道虛擬機(jī)和字節(jié)碼這樣兩個(gè)重要的概念。 所謂的字節(jié)碼 (bytecode)， 是一種非常類似于機(jī)器碼的指令格式。這種指令格式是以二進(jìn)制字節(jié)為單位定義的（不會(huì)有一個(gè)指令只用到一個(gè)字節(jié)的前四位），所以叫做字節(jié)碼。所謂的虛擬機(jī)， 就是說不是一臺(tái)真的計(jì)算機(jī)，而是一個(gè)環(huán)境，其他程序能在這個(gè)環(huán)境中運(yùn)行，而不是在真的機(jī)器上運(yùn)行�，F(xiàn)在主流高級語言如 Java, Python, PHP, C#，編譯后的代碼都是以字節(jié)碼的形式存在的， 這些字節(jié)碼程序， 最后都是在虛擬機(jī)上運(yùn)行的。

1. 虛擬機(jī)的安全性和跨平臺(tái)性

虛擬機(jī)的好處大家都知道，最容易想到的是安全性和跨平臺(tái)性。安全性是因?yàn)楝F(xiàn)在可執(zhí)行程序被放在虛擬機(jī)環(huán)境中運(yùn)行，虛擬機(jī)可以隨時(shí)對程序的危險(xiǎn)行為， 比如緩沖區(qū)溢出，數(shù)組訪問過界等等進(jìn)行控制�？缙脚_(tái)性是因?yàn)橹灰煌脚_(tái)上都裝上了支持同一個(gè)字節(jié)碼標(biāo)準(zhǔn)的虛擬機(jī)，程序就可以在不同的平臺(tái)上不加修改而運(yùn) 行，因?yàn)樘摂M機(jī)架構(gòu)在各種不同的平臺(tái)之上，用虛擬機(jī)把下層平臺(tái)間的差異性給抹平了。我們最熟悉的例子就是了。Java 語言號稱 一次編寫，到處運(yùn)行(Write Once, Run Anywhere)，就是因?yàn)楦鱾�(gè)平臺(tái)上的虛擬機(jī)都統(tǒng)一支持字節(jié)碼，所以用戶感覺不到虛擬機(jī)下層平臺(tái)的差異。

虛擬機(jī)是個(gè)好東西，但是它的出現(xiàn)，不是完全由安全性和跨平臺(tái)性驅(qū)使的。

2. 跨平臺(tái)需求的出現(xiàn)

我們知道，在計(jì)算機(jī)還是鎖在機(jī)房里面的昂貴的龐然大物的時(shí)候，系統(tǒng)軟件都是硬件廠商附送的東西（是比爾蓋茨這一代人的出現(xiàn)，才有了和硬件產(chǎn)業(yè)分庭抗礼的軟件產(chǎn)業(yè)）， 一個(gè)系統(tǒng)程序員可能一輩子只和一個(gè)產(chǎn)品線的計(jì)算機(jī)打交道，壓根沒有跨平臺(tái)的需求。應(yīng)用程序員更加不要說了，因?yàn)橛?jì)算機(jī)很稀有，寫程序都是為某一臺(tái)計(jì)算機(jī)專 門寫的，所以一段時(shí)間可能只和一臺(tái)龐然大物打交道，更加不要說什么跨平臺(tái)了。 真的有跨平臺(tái)需求，是從微型計(jì)算機(jī)開始真的普及開始的。因?yàn)橹挥杏?jì)算機(jī)普及了，各種平臺(tái)都被廣泛采用了，相互又不互相兼容軟件，才會(huì)有軟件跨平臺(tái)的需求。 微機(jī)普及的歷史，比普及的歷史要早發(fā)展史是并行重疊的。

熟悉發(fā)展史的讀者都知道，真正普及開來，是因?yàn)槠淙慷加冒姹镜某錾鷽]多久，就迅速從原始的實(shí)現(xiàn)，移植到了等平臺(tái)上，產(chǎn)生了無數(shù)衍生版本。隨著跨平臺(tái)的的普及， 微型計(jì)算機(jī)也更多的普及開來，因?yàn)橹恍枰莆栈镜闹R，就可以順利操作微型計(jì)算機(jī)了。所以，微機(jī)和這兩樣?xùn)|西都在年在美國政府，大學(xué)，科研機(jī)構(gòu)，公司，金融機(jī)構(gòu)等各種信息化前沿部門間真正的普及開來了。這些歷史都是人所共知耳熟能詳?shù)摹?/p>

既然是跨平臺(tái)的，那么，本節(jié)所有的故事都和無關(guān)，因?yàn)楸旧砭筒皇且粋�(gè)跨平臺(tái)的操作系統(tǒng)）。的跨平臺(tái)性，一般是以各平臺(tái)廠商提供編譯器的方式實(shí)現(xiàn)的，而最終編譯生成的可執(zhí)行程序，其實(shí)不是跨平臺(tái)的。所以，跨平臺(tái)是源代碼級別的跨平臺(tái)，而不是可執(zhí)行程序?qū)用娴?/span>。 而除了標(biāo)準(zhǔn)了語言外，UNIX 上有一派生機(jī)勃勃的跨平臺(tái)語言，就是腳本語言。（注：腳本語言和普通的編程語言相比，在能完成的任務(wù)上并沒有什么的巨大差異。腳本語言往往是針對特定類型的問題提出的，，語法更加簡單，功能更加高層，常常幾百行C語言要做的事情，幾行簡單的腳本就能完成）

3. 解釋和執(zhí)行

腳本語言美妙的地方在于，它們的源代碼本身就是可執(zhí)行程序，所以在兩個(gè)層面上都是跨平臺(tái)的。不難看出，腳本語言既要能被直接執(zhí)行，又要跨平臺(tái)的話，就必然要有一個(gè)“東西”，橫亙在語言源代碼和平臺(tái)之間，往上，在源代碼層面，分析源代碼的語法，結(jié)構(gòu)和邏輯，也就是所謂的“解釋”；往下，要隱藏平臺(tái)差異，使得源代碼中的邏輯，能在具體的平臺(tái)上以正確的方式執(zhí)行，也就是所謂的“執(zhí)行”。

雖說我們知道一定要這么一個(gè)東西，能夠?qū)ι虾蛢蓚�(gè)模塊畢竟是相互獨(dú)立的，因此就很自然的會(huì)出現(xiàn)兩個(gè)流派：把解釋和執(zhí)行設(shè)計(jì)到一起 和 把解釋和執(zhí)行單獨(dú)分開來 這樣兩個(gè)設(shè)計(jì)思路，需要讀者注意的是，現(xiàn)在這兩個(gè)都是跨平臺(tái)的，安全的設(shè)計(jì)，而在后者中字節(jié)碼作為了解釋和執(zhí)行之間的溝通橋梁，前者并沒有字節(jié)碼作為橋梁。

4. 解釋和執(zhí)行在一起的方案

我們先說前者，前者的優(yōu)點(diǎn)是設(shè)計(jì)簡單，不需要搞什么字節(jié)碼規(guī)范，所以上早期的腳本語言，都是采用前者的設(shè)計(jì)方法。 我們以上大名鼎鼎的和兩個(gè)腳本語言的解釋器為例說明。和都是上極為常用的，圖靈完全的語言，其中在任何系統(tǒng)中都是作為標(biāo)準(zhǔn)配置的，甚至入選 IEEE POSIX盧浮宮的唯一同類語言品牌，其地位絕對不是下其他腳本語言能夠比的。這兩個(gè)語言是怎么實(shí)現(xiàn)解釋和運(yùn)行的呢？ 我從的標(biāo)準(zhǔn)實(shí)現(xiàn)中摘一段代碼您一看就清楚了:

argv[]) { ... syminit(); yyparse(); ... run(winner); } ... }

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

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

熟悉的讀者應(yīng)該能夠立即看出解析源代碼，生成了一棵語法樹。按照 winner 的定義, winner 是這棵語法樹的根節(jié)點(diǎn)。 在變成了 0)，將 run 作用到這棵語法樹的根節(jié)點(diǎn)上。 不難想像，這個(gè)的基本邏輯先用解釋器（這里解釋器），生成一棵語法樹，然后，從樹的根節(jié)點(diǎn)開始，往下用這個(gè)函數(shù)，遇山開山，遇水搭橋，一路遞歸下去，最后把整個(gè)語法樹遍歷完，程序就執(zhí)行完畢了。（這里附送一個(gè)小八卦，抽象語法樹這個(gè)概念是先提出的，因?yàn)槭亲钤缦襁@樣做的，的源代碼也是類似的邏輯解釋執(zhí)行的，我就不一一舉例了。

5. 三大缺點(diǎn)

現(xiàn)在我們看看這個(gè)方法的優(yōu)缺點(diǎn)。 優(yōu)點(diǎn)是顯而易見的，因?yàn)橥ㄟ^抽象語法樹在兩個(gè)模塊之間通信，避免了設(shè)計(jì)復(fù)雜的字節(jié)碼規(guī)范，設(shè)計(jì)簡單。但是缺點(diǎn)也非常明顯。最核心的缺點(diǎn)就是性能差，需要資源多，具體來說，就是如下三個(gè)缺點(diǎn)。

缺點(diǎn)1，因?yàn)榻忉尯瓦\(yùn)行放在了一起，每次運(yùn)行都需要經(jīng)過解釋這個(gè)過程。假如我們有一個(gè)腳本，寫好了就不修改了，只需要重復(fù)的運(yùn)行，那么在一般應(yīng)用下尚可以忍受每次零點(diǎn)幾秒的重復(fù)冗余的解釋過程，在高性能的場合就不能適用了。

缺點(diǎn)2，因?yàn)檫\(yùn)行是采用遞歸的方式的，效率會(huì)比較低。 我們都知道，因?yàn)檫f歸涉及到棧操作和狀態(tài)保存和恢復(fù)等，代價(jià)通常比較高，所以能不用遞歸就不用遞歸。在高性能的場合使用遞歸去執(zhí)行語法樹，不值得。

缺點(diǎn)3，因?yàn)橐磺谐绦虻钠瘘c(diǎn)都是源代碼，而抽象語法樹不能作為通用的結(jié)構(gòu)在機(jī)器之間互傳，所以不得不在所有的機(jī)器上都布置一個(gè)解釋+運(yùn)行的模塊。 在資源充裕的系統(tǒng)上布置一個(gè)這樣的系統(tǒng)沒什么，可在資源受限的系統(tǒng)上就要慎重了，比如嵌入式系統(tǒng)上。 鑒于有些語言本身語法結(jié)構(gòu)復(fù)雜，布置一個(gè)解釋模塊的代價(jià)是非常高昂的。本來一個(gè)遞歸執(zhí)行模塊就很吃資源了，再加一個(gè)解釋器，嵌入式系統(tǒng)就沒法做了。所以， 這種設(shè)計(jì)在嵌入式系統(tǒng)上是行不通的。

當(dāng)然，還有一些其他的小缺點(diǎn)，比如有程序員不喜歡開放源代碼，但這種設(shè)計(jì)中，一切都從源代碼開始，要發(fā)布可執(zhí)行程序，就等于發(fā)布源代碼，所以不愿意 公布源代碼的商業(yè)公司很不喜歡這些語言等等。但是上面的三個(gè)缺點(diǎn)，是最致命的，這三個(gè)缺點(diǎn)，決定了有些場合，就是不能用這種設(shè)計(jì)。

6. 分開解釋和執(zhí)行

前面的三個(gè)主要缺點(diǎn)，恰好全部被第二個(gè)設(shè)計(jì)所克服了。在第二種設(shè)計(jì)中， 我們可以只解釋一次語法結(jié)構(gòu)，生成一個(gè)結(jié)構(gòu)更加簡單緊湊的字節(jié)碼文件。這樣，以后每次要運(yùn)行腳本的時(shí)候， 只需要把字節(jié)碼文件送給一個(gè)簡單的解釋字節(jié)碼的模塊就行了。因?yàn)樽止?jié)碼比源程序要簡單多了，所以解釋字節(jié)碼的模塊比原來解釋源程序的模塊要小很多；同時(shí)， 脫離了語法樹，我們完全可以用更加高性能的方式設(shè)計(jì)運(yùn)行時(shí)，避免遞歸遍歷語法樹這種低效的執(zhí)行方式；同時(shí)，在嵌入式系統(tǒng)上，我們可以只部署運(yùn)行時(shí)，不部署 編譯器。 這三個(gè)解決方案，預(yù)示了在運(yùn)行次數(shù)遠(yuǎn)大于編譯次數(shù)的場合，或在性能要求高的場合，或在嵌入式系統(tǒng)里，想要跨平臺(tái)和安全性，就非得用第二種設(shè)計(jì)，也就是字節(jié) 碼+虛擬機(jī)的設(shè)計(jì)。

講到了這里，相信對對或者對歷史稍微了解的讀者都會(huì)一拍腦袋頓悟了: 原來這些牛逼的虛擬機(jī)都不是天才拍腦袋想出來的，而是被需求和現(xiàn)實(shí)給召喚出來的��！

我們先以為例，說說在嵌入式場合的應(yīng)用。語言，最初不是為桌面和服務(wù)器應(yīng)用開發(fā)的，而是為機(jī)頂盒開發(fā)的。的唯一目的，就是為了參加機(jī)頂盒項(xiàng)目的競標(biāo)。嵌入式系統(tǒng)的資源受限程度不必細(xì)說了，自然不會(huì)允許上面放一個(gè)解釋器和一個(gè)運(yùn)行時(shí)。所以，不管虛擬機(jī)設(shè)計(jì)得直白無比，簡單無比，手機(jī)上，智能卡上都能放上一個(gè)運(yùn)行時(shí)（當(dāng)然是精簡版本的）。 這就是字節(jié)碼和虛擬機(jī)的威力了。

正好對繪圖支持非常好，在一統(tǒng)江湖之前，憑借跨平臺(tái)性能，以的名義一舉走紅。然后，又因?yàn)檫@種設(shè)計(jì)先天性的能克服性能問題，在性能上大作文章，憑借技術(shù)，充分發(fā)揮上面說到的優(yōu)點(diǎn)2，再加上安全性，一舉拿下了企業(yè)服務(wù)器市場的半壁江山，這都是后話了。

再說的歷史就包含了從第一種設(shè)計(jì)轉(zhuǎn)化到第二種設(shè)計(jì)以用來優(yōu)化運(yùn)行時(shí)性能的歷史。是一般用來生成服務(wù)器網(wǎng)頁的腳本語言。一個(gè)大站點(diǎn)上的PHP腳本, 一旦寫好了，每天能訪問千百萬次，所以，如果全靠每次都解釋，每次都遞歸執(zhí)行，性能上是必然要打折扣的。 所以，從開始，腳本解釋引擎，就開始將解釋成字節(jié)碼，以支持這種一次解釋，多次運(yùn)行的框架。 在此之前，和還有還算平分秋色的樣子，基本上服務(wù)器上三類網(wǎng)頁的數(shù)量都差不多，三者語法也很類似，但是到了出現(xiàn)之后，其他兩個(gè)基于第一種設(shè)計(jì)方案的頁面就慢慢消逝了， 全部讓位給博客，也是基于技術(shù)的，底層也是引擎的。 著名的里面的那個(gè) P， 原始上也是年出現(xiàn)之后的事情。

第二種設(shè)計(jì)的優(yōu)點(diǎn)正好滿足了實(shí)際需求的事情，其實(shí)不勝枚舉。比如說 在和等宿主語言上也都表現(xiàn)的淋漓盡致。像這樣的小型語言，本來就是讓運(yùn)行時(shí)為了嵌入其他語言的，所以運(yùn)行時(shí)越小越好，自然的，就走了和嵌入式系統(tǒng)一樣的設(shè)計(jì)道路。

7. 結(jié)語

其實(shí)第二種設(shè)計(jì)也不是鐵板一塊，里面也有很多流派，各派有很多優(yōu)缺點(diǎn)，也有很多細(xì)致的考量，下一節(jié)，如果不出意外，我將介紹我最喜歡的一個(gè)內(nèi)容： 下一代虛擬機(jī)：寄存器還是棧。

說了這么多，最后就是一句話，有時(shí)候我們看上去覺得一種設(shè)計(jì)好像是天外飛仙，橫空出世，其實(shí)其后都有現(xiàn)實(shí)，需求等等的諸多考量。虛擬機(jī)技術(shù)就是這樣，在各種需求的引導(dǎo)下，逐漸的演化成了現(xiàn)在的樣子。

 

  本文關(guān)鍵詞：高級語言，由筆耕文化傳播整理發(fā)布。

本文編號：375497