淺談彙編器、編譯器和解釋器
![](https://linuxstory.org/wp-content/uploads/2024/06/181309vdouxdfktr344rm4-800x400.jpg)
在計算機誕生不久的早期年代,硬體非常昂貴,而程序員比較廉價。這些廉價程序員甚至都沒有「程序員」這個頭銜,並且常常是由數學家或者電氣工程師來充當這個角色的。早期的計算機被用來快速解決複雜的數學問題,所以數學家天然就適合「編程」工作。
什麼是程序?
首先來看一點背景知識。計算機自己是做不了任何事情的,它們的任何行為都需要程序來引導。你可以把程序看成是非常精確的菜譜,這種菜譜讀取一個輸入,然後生成對應的輸出。菜譜里的各個步驟由操作數據的指令構成。聽上去有點兒複雜,不過你或許知道下面這個語句是什麼意思:
1 + 2 = 3
其中的加號是「指令」,而數字 1 和 2 是數據。數學上的等號意味著等式兩邊的部分是「等價」的,不過在大部分編程語言中對變數使用等號是「賦值」的意思。如果計算機執行上面這個語句,它會把這個加法的結果(也就是「3」)儲存在內存中的某個地方。
計算機知道如何使用數字進行數學運算,以及如何在內存結構中移動數據。在這裡就不對內存進行展開了,你只需要知道內存一般分為兩大類:「速度快/空間小」和「速度慢/空間大」。CPU 寄存器的讀寫速度非常快,但是空間非常小,相當於一個速記便簽。主存儲器通常有很大的空間,但是讀寫速度就比寄存器差遠了。在程序運行的時候,CPU 不斷將它所需要用到的數據從主存儲器挪動到寄存器,然後再把結果放回到主存儲器。
彙編器
當時的計算機很貴,而人力比較便宜。程序員需要耗費很多時間把手寫的數學表達式翻譯成計算機可以執行的指令。最初的計算機只有非常糟糕的用戶界面,有些甚至只有前面板上的撥動開關。這些開關就代表一個內存「單元」里的一個個 「0」 和 「1」。程序員需要配置一個內存單元,選擇好儲存位置,然後把這個單元提交到內存里。這是一個既耗時又容易出錯的過程。
![Programmers operate the ENIAC computer](/data/attachment/album/201906/26/181338d07mcgh77mgeh7c2.gif "Programmers operate the ENIAC computer")
程序員[Betty Jean Jennings](https://en.wikipedia.org/wiki/Jean_Bartik "Jean Bartik") (左) 和 [Fran Bilas](https://en.wikipedia.org/wiki/Frances_Spence "Frances Spence") (右) 在操作 ENIAC 的主控制面板
後來有一名 電氣工程師 認為自己的時間很寶貴,就寫了一個程序,能夠把人們可以讀懂的「菜譜」一樣的輸入轉換成計算機可以讀懂的版本。這就是最初的「彙編器」,在當時引起了不小的爭議。這些昂貴機器的主人不希望把計算資源浪費在人們已經能做的任務上(雖然又慢又容易出錯)。不過隨著時間的推移,人們逐漸發現使用彙編器在速度和準確性上都勝於人工編寫機器語言,並且計算機完成的「實際工作量」增加了。
儘管彙編器相比在機器面板上切換比特的狀態已經是很大的進步了,這種編程方式仍然非常專業。上面加法的例子在彙編語言中看起來差不多是這樣的:
01 MOV R0, 1
02 MOV R1, 2
03 ADD R0, R1, R2
04 MOV 64, R0
05 STO R2, R0
每一行都是一個計算機指令,前面是一個指令的簡寫,後面是指令所操作的數據。這個小小的程序首先會將數值 1 「移動」到寄存器 R0,然後把 2 移動到寄存器 R1。03 行把 R0 和 R1 兩個寄存器里的數值相加,然後將結果儲存在 R2 寄存器里。最後,04 行和 05 行決定結果應該被放在主存儲器里的什麼位置(在這裡是地址 64)。管理內存中存儲數據的位置是編程過程中最耗時也最容易出錯的部分之一。
編譯器
彙編器已經比手寫計算機指令要好太多了,不過早期的程序員還是渴望能夠按照他們所習慣的方式,像書寫數學公式一樣地去寫程序。這種需求推動了高級編譯語言的發展,其中有一些已經成為歷史,另一些如今還在使用。比如 ALGO 就已經成為歷史了,但是像 Fortran 和 C 這樣的語言仍然在不斷解決實際問題。
![Genealogy tree of ALGO and Fortran](/data/attachment/album/201906/26/181340u6zfjrmc6fjiiiif.png "Genealogy tree of ALGO and Fortran")
ALGO 和 Fortran 編程語言的譜系樹
這些「高級」語言使得程序員可以用更簡單的方式編寫程序。在 C 語言中,我們的加法程序就變成了這樣:
int x;
x = 1 + 2;
第一個語句描述了該程序將要使用的一塊內存。在這個例子中,這塊內存應該佔一個整數的大小,名字是 x
。第二個語句是加法,雖然是倒著寫的。一個 C 語言的程序員會說這是 「X 被賦值為 1 加 2 的結果」。需要注意的是,程序員並不需要決定在內存的什麼位置儲存 x
,這個任務交給編譯器了。
這種被稱為「編譯器」的新程序可以把用高級語言寫的程序轉換成彙編語言,再使用彙編器把彙編語言轉換成機器可讀的程序。這種程序組合常常被稱為「工具鏈」,因為一個程序的輸出就直接成為另一個程序的輸入。
編譯語言相比彙編語言的優勢體現在從一台計算機遷移到不同型號或者品牌的另一台計算機上的時候。在計算機的早期歲月里,包括 IBM、DEC、德州儀器、UNIVAC 以及惠普在內的很多公司都在製造除了大量不同類型的計算機硬體。這些計算機除了都需要連接電源之外就沒有太多共同點了。它們在內存和 CPU 架構上的差異相當大,當時經常需要人們花費數年來將一台計算機的程序翻譯成另一台計算機的程序。
有了高級語言,我們只需要把編譯器工具鏈遷移到新的平台就行了。只要有可用的編譯器,高級語言寫的程序最多只需要經過小幅修改就可以在新的計算機上被重新編譯。高級語言的編譯是一個真正的革命性成果。
![IBM PC XT](/data/attachment/album/201906/26/181342hqzpzn8bbprq8uzk.jpg "IBM PC XT")
1983 發布的 IBM PC XT 是硬體價格下降的早期例子。
程序員們的生活得到了很好的改善。相比之下,通過高級語言表達他們想要解決的問題讓事情變得輕鬆很多。由於半導體技術的進步以及集成晶元的發明,計算機硬體的價格急劇下降。計算機的速度越來越快,能力也越來越強,並且還便宜了很多。從某個時間點往後(也許是 80 年代末期吧),事情發生了反轉,程序員變得比他們所使用的硬體更值錢了。
解釋器
隨著時間的推移,一種新的編程方式興起了。一種被稱為「解釋器」的特殊程序可以直接讀取一個程序將其轉換成計算機指令以立即執行。和編譯器差不多,解釋器讀取程序並將它轉換成一個中間形態。但和編譯器不同的是,解釋器直接執行程序的這個中間形態。解釋型語言在每一次執行的時候都要經歷這個過程;而編譯程序只需要編譯一次,之後計算機每次只需要執行編譯好的機器指令就可以了。
順便說一句,這個特性就是導致人們感覺解釋型程序運行得比較慢的原因。不過現代計算機的性能出奇地強大,以至於大多數人無法區分編譯型程序和解釋型程序。
解釋型程序(有時也被成為「腳本」)甚至更容易被移植到不同的硬體平台上。因為腳本並不包含任何機器特有的指令,同一個版本的程序可以不經過任何修改就直接在很多不同的計算機上運行。不過當然了,解釋器必須得先移植到新的機器上才行。
一個很流行的解釋型語言是 perl。用 perl 完整地表達我們的加法問題會是這樣的:
$x = 1 + 2
雖然這個程序看起來和 C 語言的版本差不多,運行上也沒有太大區別,但卻缺少了初始化變數的語句。其實還有一些其它的區別(超出這篇文章的範圍了),但你應該已經注意到,我們寫計算機程序的方式已經和數學家用紙筆手寫數學表達式非常接近了。
虛擬機
最新潮的編程方式要數虛擬機(經常簡稱 VM)了。虛擬機分為兩大類:系統虛擬機和進程虛擬機。這兩種虛擬機都提供一種對「真實的」計算硬體的不同級別的抽象,不過它們的作用域不同。系統虛擬機是一個提供物理硬體的替代品的軟體,而進程虛擬機則被設計用來以一種「系統獨立」的方式執行程序。所以在這個例子里,進程虛擬機(往後我所說的虛擬機都是指這個類型)的作用域和解釋器的比較類似,因為也是先將程序編譯成一個中間形態,然後虛擬機再執行這個中間形態。
虛擬機和解釋器的主要區別在於,虛擬機創造了一個虛擬的 CPU,以及一套虛擬的指令集。有了這層抽象,我們就可以編寫前端工具來把不同語言的程序編譯成虛擬機可以接受的程序了。也許最流行也最知名的虛擬機就是 Java 虛擬機(JVM)了。JVM 最初在 1990 年代只支持 Java 語言,但是如今卻可以運行 許多 流行的編程語言,包括 Scala、Jython、JRuby、Clojure,以及 Kotlin 等等。還有其它一些不太常見的例子,在這裡就不說了。我也是最近才知道,我最喜歡的語言 Python 並不是一個解釋型語言,而是一個 運行在虛擬機上的語言!
虛擬機仍然在延續這樣一個歷史趨勢:讓程序員在使用特定領域的編程語言解決問題的時候,所需要的對特定計算平台的了解變得越來越少了。
就是這樣了
希望你喜歡這篇簡單介紹軟體背後運行原理的短文。有什麼其它話題是你想讓我接下來討論的嗎?在評論里告訴我吧。
via: https://opensource.com/article/19/5/primer-assemblers-compilers-interpreters
作者:Erik O'Shaughnessy 選題:lujun9972 譯者:chen-ni 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive