?編譯器、虛擬機(jī)、操作系統(tǒng)，到底哪個(gè)更難？

實(shí)際上，除了MATLAB這樣的數(shù)學(xué)軟件之外，肯定是編譯器更難！

虛擬機(jī)和操作系統(tǒng)更多的是麻煩，工作量大，而不是難。

1、虛擬機(jī)

什么是虛擬機(jī)？

能夠運(yùn)行字節(jié)碼的程序，就是虛擬機(jī)。

CPU的機(jī)器碼就是一種字節(jié)碼，它是直接在硬件上跑的，由硬件的數(shù)字電路來保證它的運(yùn)行。

但是虛擬機(jī)是由軟件程序來保證字節(jié)碼的運(yùn)行的。

軟件程序是高級(jí)語言寫的，可以寫非常上層的邏輯，實(shí)現(xiàn)起來比數(shù)字電路簡(jiǎn)單得多。

到了字節(jié)碼（機(jī)器碼）這個(gè)層面，邏輯已經(jīng)非常簡(jiǎn)單了，遠(yuǎn)不如高級(jí)語言的源代碼復(fù)雜。

讓字節(jié)碼運(yùn)行起來，實(shí)際上比編譯器生成字節(jié)碼更簡(jiǎn)單：

因?yàn)樯勺止?jié)碼是編碼，而讓字節(jié)碼運(yùn)行是解碼，任何時(shí)候都是編碼比解碼更復(fù)雜。

編碼，需要把雜亂的信息整理成有序的。

解碼，只需要把有序的信息順序讀出來就行。

所以，H264編碼的CPU消耗，遠(yuǎn)比H264解碼更大！

如果字節(jié)碼類似RISC架構(gòu)的機(jī)器碼（例如ARM），那么每4字節(jié)就是一條指令，指令里的每一位做什么都是固定的。

所以，虛擬機(jī)的代碼就是這樣的：

uint32_t codes[N]; // 程序的字節(jié)碼數(shù)組
for (i = 0; i < N; i++) {
uint8_t opcode = codes[i] >> 25; // 最高7位是操作碼，可以支持128個(gè)指令
uint8_t src = (codes[i] >> 19) & 0x3f; // 接著6位是源操作數(shù)的寄存器編號(hào)，
uint8_t dst = (codes[i] >> 13) & 0x3f; // 接著6位是目的操作數(shù)的寄存器編號(hào)，
// 寄存器的編號(hào)占6位，可以支持64個(gè)寄存器
uint8_t flag = (codes[i] >> 12) & 0x1; // 是否設(shè)置跳轉(zhuǎn)標(biāo)志，
uint16_t imm = codes[i] & 0xfff; // 可以攜帶12位的立即數(shù)，
run(ctx, opcode, src, dst, flag, imm); // 運(yùn)行字節(jié)碼，ctx為進(jìn)程的上下文
}

這種程序很難嗎？

不難。

機(jī)器碼的邏輯是特別簡(jiǎn)單的，比高級(jí)語言的代碼簡(jiǎn)單得多！

尤其是RISC架構(gòu)的，更是比x64的機(jī)器碼還簡(jiǎn)單。

x64的機(jī)器碼因?yàn)殚L(zhǎng)度不固定，解釋起來要一個(gè)字節(jié)一個(gè)字節(jié)的分析，稍微復(fù)雜一點(diǎn)，但復(fù)雜度也遠(yuǎn)不如高級(jí)語言的源代碼！

qemu復(fù)雜，是因?yàn)樗M多個(gè)型號(hào)的CPU。

如果只是給字節(jié)碼實(shí)現(xiàn)一個(gè)跨平臺(tái)的虛擬機(jī)，并不難。

把java源代碼變成字節(jié)碼的過程，遠(yuǎn)比讓java字節(jié)碼運(yùn)行起來，要難得多：

前者是編譯器，后者是虛擬機(jī)。

2、操作系統(tǒng)

如果只是讓OS內(nèi)核在CPU上跑起來，大概只需要5000-8000行的C代碼！

Linux 0.01版（即第一個(gè)Linux版本）的代碼量也就在8000行左右。

Linux 0.11版，大約不到2萬行。

與編譯器比起來，操作系統(tǒng)只是更麻煩！

因?yàn)橐С值尿?qū)動(dòng)模塊很多、要支持的文件系統(tǒng)很多、要支持的網(wǎng)絡(luò)協(xié)議很多，這些模塊的代碼都是工作量?

但是，麻煩不等于難！

8000行代碼的OS內(nèi)核（例如Linux 0.01），只需要實(shí)現(xiàn)進(jìn)程管理、內(nèi)存管理、控制臺(tái)管理、鍵盤驅(qū)動(dòng)、硬盤驅(qū)動(dòng)，另外支持一種簡(jiǎn)單的文件系統(tǒng)，就可以跑得起來。

這樣的OS內(nèi)核實(shí)際上已經(jīng)很完善了?

剩下的都是在文件系統(tǒng)的底下添加驅(qū)動(dòng)模塊、網(wǎng)絡(luò)協(xié)議模塊。

按照unix一切皆是文件的設(shè)計(jì)哲學(xué)，外設(shè)的驅(qū)動(dòng)模塊和TCP/IP協(xié)議，都是隸屬于文件系統(tǒng)的子模塊。

shell（命令解釋器）不屬于OS內(nèi)核，而是一個(gè)用來解釋命令的用戶態(tài)程序。

當(dāng)然，shell對(duì)系統(tǒng)的使用來說是必需的。

在文件系統(tǒng)的API基礎(chǔ)上，實(shí)現(xiàn)列目錄、創(chuàng)建目錄、創(chuàng)建文件之類的功能并不難。

當(dāng)然，這些命令實(shí)現(xiàn)起來的工作量，比讓一個(gè)8000行的OS內(nèi)核運(yùn)行起來還大。

3、編譯器

光一個(gè)語法分析就可能超過1萬行！

如果語法像C++那么復(fù)雜，那語法分析的代碼量更大。

（如果用第三方的正則表達(dá)式庫的話，第三方庫的代碼也沒有低于1萬行的）

而且編譯器的實(shí)現(xiàn)中有一些非常別扭的地方，例如C++的如下代碼：

vector<vector<A> > vecA;
vector<vector<A>> vecA;

兩個(gè)> >之間必須有一個(gè)空格，否則g++是會(huì)報(bào)錯(cuò)的。

之所以會(huì)這樣是鍵盤上的符號(hào)太少了，而C++的語法太復(fù)雜，在編碼上實(shí)在應(yīng)付不過來了。

另外，編譯器的后端也有一些非常復(fù)雜的模塊，例如：指針分析、自動(dòng)內(nèi)存管理、循環(huán)分析、寄存器分配、goto的處理，等等。

還有一種是并行分析：

for (i = 0; i < N; i++)
a[2*i+1] = a[2*i];

顯然，N個(gè)源位置與N個(gè)目的位置是不可能相同的，所以它可以并行復(fù)制數(shù)據(jù)。

人一眼就可以看出來源位置與目的位置的數(shù)組讀寫是不相關(guān)的，但用代碼怎么判斷？

要用整數(shù)線性規(guī)劃。

運(yùn)籌學(xué)上有這一章，龍書（編譯原理）里也有提到，我也曾經(jīng)學(xué)過但都忘了?

虛擬機(jī)和操作系統(tǒng)真只是工作量大，論難度還是編譯器和MATLAB！

我的gitee上也有一個(gè)bochs上的內(nèi)核demo，有興趣的可以看看，實(shí)現(xiàn)起來比scf簡(jiǎn)單多了。

scf編譯器的后端只加了必需的模塊，都寫了4萬行代碼。