編譯器的應用和最新進展

⑴ 編譯器的歷史

20世紀50年代，IBM的John Backus帶領一個研究小組對FORTRAN語言及其編譯器進行開發。但由於當時人們對編譯理論了解不多，開發工作變得既復雜又艱苦。與此同時，Noam Chomsky開始了他對自然語言結構的研究。他的發現最終使得編譯器的結構異常簡單，甚至還帶有了一些自動化。Chomsky的研究導致了根據語言文法的難易程度以及識別它們所需要的演算法來對語言分類。正如Chomsky架構（Chomsky Hierarchy），它包括了文法的四個層次：0型文法、1型文法、2型文法和3型文法，且其中的每一個都是其前者的特殊情況。2型文法（或上下文無關文法）被證明是程序設計語言中最有用的，而且今天它已代表著程序設計語言結構的標准方式。分析問題（parsing problem，用於上下文無關文法識別的有效演算法）的研究是在60年代和70年代，它相當完善的解決了這個問題。它已是編譯原理中的一個標准部分。
有限狀態自動機（Finite Automation）和正則表達式（Regular Expression）同上下文無關文法緊密相關，它們與Chomsky的3型文法相對應。對它們的研究與Chomsky的研究幾乎同時開始，並且引出了表示程序設計語言的單詞的符號方式。
人們接著又深化了生成有效目標代碼的方法，這就是最初的編譯器，它們被一直使用至今。人們通常將其稱為優化技術（Optimization Technique），但因其從未真正地得到過被優化了的目標代碼而僅僅改進了它的有效性，因此實際上應稱作代碼改進技術（Code Improvement Technique）。
當分析問題變得好懂起來時，人們就在開發程序上花費了很大的功夫來研究這一部分的編譯器自動構造。這些程序最初被稱為編譯器的編譯器（Compiler-compiler），但更確切地應稱為分析程序生成器（Parser Generator），這是因為它們僅僅能夠自動處理編譯的一部分。這些程序中最著名的是Yacc（Yet Another Compiler-compiler），它是由Steve Johnson在1975年為Unix系統編寫的。類似的，有限狀態自動機的研究也發展了一種稱為掃描程序生成器（Scanner Generator）的工具，Lex（與Yacc同時，由Mike Lesk為Unix系統開發）是這其中的佼佼者。
在20世紀70年代後期和80年代早期，大量的項目都貫注於編譯器其它部分的生成自動化，這其中就包括了代碼生成。這些嘗試並未取得多少成功，這大概是因為操作太復雜而人們又對其不甚了解。
編譯器設計最近的發展包括：首先，編譯器包括了更加復雜演算法的應用程序它用於推斷或簡化程序中的信息；這又與更為復雜的程序設計語言的發展結合在一起。其中典型的有用於函數語言編譯的Hindley-Milner類型檢查的統一演算法。其次，編譯器已越來越成為基於窗口的交互開發環境（Interactive Development Environment，IDE）的一部分，它包括了編輯器、連接程序、調試程序以及項目管理程序。這樣的IDE標准並沒有多少，但是對標準的窗口環境進行開發已成為方向。另一方面，盡管在編譯原理領域進行了大量的研究，但是基本的編譯器設計原理在近20年中都沒有多大的改變，它正迅速地成為計算機科學課程中的中心環節。
在20世紀90年代，作為GNU項目或其它開放源代碼項目標一部分，許多免費編譯器和編譯器開發工具被開發出來。這些工具可用來編譯所有的計算機程序語言。它們中的一些項目被認為是高質量的，而且對現代編譯理論感興趣的人可以很容易的得到它們的免費源代碼。
大約在1999年，SGI公布了他們的一個工業化的並行化優化編譯器Pro64的源代碼，後被全世界多個編譯器研究小組用來做研究平台，並命名為Open64。Open64的設計結構好，分析優化全面，是編譯器高級研究的理想平台。
編譯器相關專業術語: 1. compiler編譯器；編譯程序 2. on-line compiler 連線編譯器 3. precompiler 預編譯器 4. serial compiler 串列編譯器 5. system-specific compiler 特殊系統編譯器 6. Information Presentation Facility Compiler 信息展示設施編譯器 7. Compiler Monitor System 編譯器監視系統

⑵ 編譯器的編譯器優化

應用程序之所以復雜, 是由於它們具有處理多種問題以及相關數據集的能力。實際上, 一個復雜的應用程序就象許多不同功能的應用程序「 粘貼」 在一起。源文件中大部分復雜性來自於處理初始化和問題設置代碼。這些文件雖然通常占源文件的很大一部分, 具有很大難度, 但基本上不花費C PU 執行周期。
盡管存在上述情況, 大多數Makefile文件只有一套編譯器選項來編譯項目中所有的文件。因此, 標準的優化方法只是簡單地提升優化選項的強度, 一般從O 2 到O 3。這樣一來, 就需要投人大量 精力來調試, 以確定哪些文件不能被優化, 並為這些文件建立特殊的make規則。
一個更簡單但更有效的方法是通過一個性能分析器, 來運行最初的代碼, 為那些佔用了85 一95 % CPU 的源文件生成一個列表。通常情況下, 這些文件大約只佔所有文件的1%。如果開發人員立刻為每一個列表中的文件建立其各自的規則, 則會處於更靈活有效的位置。這樣一來改變優化只會引起一小部分文件被重新編譯。進而,由於時間不會浪費在優化不費時的函數上, 重編譯全部文件將會大大地加快。

⑶ 什麼是「編譯器」

了解的C/C++編譯器如下：
GCC家族有
Cygwin
Mingw32
DJGPP
Dev-C++(Mingw32)
還有正宗的GNU GCC 2.95.5~3.0.0.4版本
MS家族有
MSC 5.0、6.0、7.0
MSQC 1.0、2.5
MSVC 1.0、4.2、6.0、7.0
Borland家族有
TC 1.0、2.0
TC++ 1.01、3.0
BC 3.0、3.1、4.0、4.5、5.0、5.02
BCB 3.0、5.0、6.0
其它有
Intel C/C++ 5.0
Watcom C/C++ 11.0、11.0c
VectorC 1.3.3
IBM VisualAge for C++
DigitalMars C/C++
KAI C/C++ 4.03f for RedHat 7.2
Lcc4.1
LCC-WIN32 2001-09-25~2002-04-28日版
Small C
CC386
Pacific C
另外還有C的解釋器
Quincy
Eic
CINT

上面提到的編譯器/解釋器，大部分我都使用過。現在固定使用VC7.0 Cygwin Mingw32 VectorC和LCC-WIN32這五種編譯器。

在GCC家族中GNU GCC是根本，其它的編譯器版本都是從它導出的。其中，Cygwin和Mingw32都是WIN32平台下的編譯器，DJGPP是DOS下的32位編譯器。大家所熟知的DEV-C++充其量只是GCC的一個外殼，它所自帶的編譯器就是Mingw32的一個版本。這些GCC的版本中，Cygwin是最大的，它與其說是一個編譯器，倒不如說是一套編程工具。它不僅有編譯器，還有其它很多的工具。其實，它就是一個UNIX系統在WIN32平台上的實現。實現了大多常用的UNIX工具，最近的版本中連Apache這樣的「工具」都集成進來的。不過，Cygwin雖然功能強大，但它卻不是很易用（和UNIX相似，熟悉UNIX的人用它可以很快上手），因為太多其它的工具分散了人們的注意力。相比之下Mingw32就要好用得多，它只有最基本的幾個編程工具（只可惜它不自帶GDB）。GCC中並不只是C/C++編譯器，其中還有很多其它的編譯器如JAVA，Fortran，ADA等。它是一個編譯器集合，不過有些編譯器只能在UNIX系統上用。MS家族的編譯器就不用說了，大家對它們都很熟悉。VC 7.0(VC.NET)是它的最新產品。Borland家族也不用說，大家也是耳熟能詳。最近它才推出了BCB 6.0。

其它的編譯器如：Intel C/C++大家一看名稱就知道是Intel的東西，它和VC6完全兼容，不過要掛在VC6下才能用。Watcom C/C++是早先編譯器四國大戰中的一員，原本是很不錯的東西，可惜戰略不對，現在已不見聲息了。倒是以它為基礎的一個OpenWatcom現在還在奮戰。VectorC是我近日才發現的一個好東東，它是個純C的編譯器。IBM的VisualAge for C++原本是IBM想用來淌C++編譯器這片渾水的東西，不過IBM的戰略改了，它就被放棄了。DigitalMars C/C++的前身的Symantec C++（它也是編譯器四國大戰中的一員），不過現在Symantec不做了，於是它的作者就把它改成了DigitalMars C/C++開放給大家使用。以上這些都是WIN32平台上的東西。KAI C/C++是個很強大的C/C++編譯器，它是個多平台的編譯器。不過現在被INTEL收購了，已經停止開發了。Lcc4.1是個純C的編譯器它是開放源代碼的。不過不怎麼好用。LCC-WIN32是一個在LCC基礎上開發的C語言的集成開發環境，很好用，而且有很詳細的資料，FREE！Pacific C是一個純DOS的C的集成開發環境，就不多說了。Small C CC386都是開放源代碼的編譯器，它們都很簡單，應用來給大家學習編譯器的。Quincy Eic CINT都是C的解釋器，是用來讓大家學習C語言的其中CINT的功能很強大，還支持一些C++的特性。
當然還有很多其它的編譯器，這里我給出的編譯器都是可以在WIN32或DOS平台上用的（除KAI外）。UNIX平台上的編譯器還是以GNU的為主，其它的我就不是很清楚了。

在以上的編譯器中，最特別的就是VectorC這個東西只支持純C。但它卻號稱是最快的編譯器，不過經過我的試驗，它的確在有些情況下強過其它編譯器很多！而且它還有個互動式的優化器，可以讓你直接看到C代碼對映的匯編代碼。Cygwin和Mingw32為一母所生，其運行效果相差不大。它們生成的代碼效率都很不錯，編譯的速度也很快，最值得一提的是它們對C++的特性的支持算是所有編譯器中最完全的，而且它們還支持C99的大部分特性。這一點很是不錯！大家對MS的VC已經很熟悉了，本不用我多說。不過在它的最新的產品VC7.0中，有很大的改進。它對C++的特性的支持比6.0有了很大的提高，是我所用的編譯器中是僅次於GCC的。而且它編譯出的程序，運行速度很快！僅有少數時候次於VectorC與GCC，其它情況都是最快的！其平均運行速度是最快的。對Borland的產品我也無需多說。它的TC2.0與BC3.1都是我最喜歡的東西。可是現在的BCB卻大不如前了，編譯的速度和VC6一樣慢！IDE還有較多的BUG。最令人想不通的是它生成的代碼的運行速度很慢，比LCC-WIN32還慢！它唯一值得一提的就是它的RAD做的比MS的好。Intel的編譯器大家可能不熟，它太貴了！還要有VC的支持，很不劃算，而且編譯速度比VC6還慢。不過它的代碼質量很不錯。DigitalMars C/C++沒有什麼亮點，編譯速度較快，代碼執行速度適中，對C++特性支持還算不錯。LCC-WIN32是個很不錯的集成開發環境，它只支持純C。它的編譯速度極快！代碼執行速度較慢。不過它的最大亮點在於它的IDE，在所有的FREE編程工具中，它的IDE是最專業的，有很強大的代碼分析，管理功能。而且它提供了大量的編程資料。
我曾對一些編譯器的代碼執行效率做過一些測試，以下是概況：
1. VectorC、VC 7.0 （極快）
2. Intel C/C++、VC 6.0、GCC （很快）
3. DigitalMars C/C++ （一般）
4. LCC-WIN32、BCB、BC5.02 (較慢)
當然，我所做的測試比較片面。不過在很大程度上已能反映其大概狀況。

⑷ 編譯器、操作系統、應用軟體

我們先說下軟體體系的架構。一般以OSI七層模型為國際標准。

即：
應用層

表示層

會話層

傳輸層

網路層

數據鏈路層

物理層

編譯器：即是應用層高級語言代碼編譯成二進器(機器語言)代碼。它屬於應用層工具軟體

操作系統：它涵蓋了應用層、表示層、會話層和傳輸層、網路層、數據鏈接層的所有層級的語言程序。

應用軟體：即Application程序。所寫的代碼對象僅僅針對於表示層、會話層的訪問和交互。當然它是一個成型的行業軟體程序。

⑸ 編譯器的發展史

編譯器
編譯器，是將便於人編寫，閱讀，維護的高級計算機語言翻譯為計算機能識別，運行的低級機器語言的程序。編譯器將源程序（Source program）作為輸入，翻譯產生使用目標語言（Target language）的等價程序。源程序一般為高級語言（High-level language），如Pascal，C++等，而目標語言則是匯編語言或目標機器的目標代碼（Object code），有時也稱作機器代碼（Machine code）。

一個現代編譯器的主要工作流程如下：

源程序（source code）→預處理器（preprocessor）→編譯器（compiler）→匯編程序（assembler）→目標程序（object code）→連接器（鏈接器，Linker）→可執行程序（executables）
目錄 [隱藏]
1 工作原理
2 編譯器種類
3 預處理器（preprocessor）
4 編譯器前端（frontend）
5 編譯器後端（backend）
6 編譯語言與解釋語言對比
7 歷史
8 參見

工作原理
翻譯是從源代碼（通常為高級語言）到能直接被計算機或虛擬機執行的目標代碼（通常為低級語言或機器言）。然而，也存在從低級語言到高級語言的編譯器，這類編譯器中用來從由高級語言生成的低級語言代碼重新生成高級語言代碼的又被叫做反編譯器。也有從一種高級語言生成另一種高級語言的編譯器，或者生成一種需要進一步處理的的中間代碼的編譯器（又叫級聯）。

典型的編譯器輸出是由包含入口點的名字和地址以及外部調用（到不在這個目標文件中的函數調用）的機器代碼所組成的目標文件。一組目標文件，不必是同一編譯器產生，但使用的編譯器必需採用同樣的輸出格式，可以鏈接在一起並生成可以由用戶直接執行的可執行程序。

編譯器種類
編譯器可以生成用來在與編譯器本身所在的計算機和操作系統（平台）相同的環境下運行的目標代碼，這種編譯器又叫做「本地」編譯器。另外，編譯器也可以生成用來在其它平台上運行的目標代碼，這種編譯器又叫做交叉編譯器。交叉編譯器在生成新的硬體平台時非常有用。「源碼到源碼編譯器」是指用一種高級語言作為輸入，輸出也是高級語言的編譯器。例如: 自動並行化編譯器經常採用一種高級語言作為輸入，轉換其中的代碼，並用並行代碼注釋對它進行注釋（如OpenMP）或者用語言構造進行注釋（如FORTRAN的DOALL指令）。

預處理器（preprocessor）
作用是通過代入預定義等程序段將源程序補充完整。

編譯器前端（frontend）
前端主要負責解析（parse）輸入的源程序，由詞法分析器和語法分析器協同工作。詞法分析器負責把源程序中的『單詞』（Token）找出來,語法分析器把這些分散的單詞按預先定義好的語法組裝成有意義的表達式，語句 ，函數等等。 例如「a = b + c;」前端詞法分析器看到的是「a, =, b , +, c;」，語法分析器按定義的語法，先把他們組裝成表達式「b + c」，再組裝成「a = b + c」的語句。 前端還負責語義（semantic checking）的檢查，例如檢測參與運算的變數是否是同一類型的，簡單的錯誤處理。最終的結果常常是一個抽象的語法樹（abstract syntax tree，或 AST），這樣後端可以在此基礎上進一步優化，處理。

編譯器後端（backend）
編譯器後端主要負責分析，優化中間代碼（Intermediate representation）以及生成機器代碼（Code Generation）。

一般說來所有的編譯器分析，優化，變型都可以分成兩大類： 函數內（intraproceral）還是函數之間（interproceral）進行。很明顯，函數間的分析，優化更准確，但需要更長的時間來完成。

編譯器分析（compiler analysis）的對象是前端生成並傳遞過來的中間代碼，現代的優化型編譯器（optimizing compiler）常常用好幾種層次的中間代碼來表示程序，高層的中間代碼（high level IR）接近輸入的源程序的格式，與輸入語言相關（language dependent），包含更多的全局性的信息，和源程序的結構；中層的中間代碼（middle level IR）與輸入語言無關，低層的中間代碼(Low level IR)與機器語言類似。 不同的分析，優化發生在最適合的那一層中間代碼上。

常見的編譯分析有函數調用樹（call tree），控制流程圖（Control flow graph），以及在此基礎上的 變數定義－使用，使用－定義鏈（define-use/use-define or u-d/d-u chain），變數別名分析（alias analysis），指針分析（pointer analysis），數據依賴分析（data dependence analysis）等等。

上述的程序分析結果是編譯器優化（compiler optimization）和程序變形（compiler transformation）的前提條件。常見的優化和變新有：函數內嵌（inlining），無用代碼刪除（Dead code elimination），標准化循環結構（loop normalization），循環體展開（loop unrolling），循環體合並，分裂（loop fusion，loop fission），數組填充（array padding），等等。 優化和變形的目的是減少代碼的長度，提高內存（memory），緩存（cache）的使用率，減少讀寫磁碟，訪問網路數據的頻率。更高級的優化甚至可以把序列化的代碼（serial code）變成並行運算，多線程的代碼（parallelized，multi-threaded code）。

機器代碼的生成是優化變型後的中間代碼轉換成機器指令的過程。現代編譯器主要採用生成匯編代碼（assembly code）的策略，而不直接生成二進制的目標代碼（binary object code）。即使在代碼生成階段，高級編譯器仍然要做很多分析，優化，變形的工作。例如如何分配寄存器（register allocatioin），如何選擇合適的機器指令（instruction selection），如何合並幾句代碼成一句等等。

編譯語言與解釋語言對比
許多人將高級程序語言分為兩類: 編譯型語言 和 解釋型語言 。然而，實際上，這些語言中的大多數既可用編譯型實現也可用解釋型實現，分類實際上反映的是那種語言常見的實現方式。（但是，某些解釋型語言，很難用編譯型實現。比如那些允許 在線代碼更改 的解釋型語言。）

歷史
上世紀50年代，IBM的John Backus帶領一個研究小組對FORTRAN語言及其編譯器進行開發。但由於當時人們對編譯理論了解不多，開發工作變得既復雜又艱苦。與此同時，Noam Chomsky開始了他對自然語言結構的研究。他的發現最終使得編譯器的結構異常簡單，甚至還帶有了一些自動化。Chomsky的研究導致了根據語言文法的難易程度以及識別它們所需要的演算法來對語言分類。正如現在所稱的Chomsky架構（Chomsky Hierarchy），它包括了文法的四個層次：0型文法、1型文法、2型文法和3型文法，且其中的每一個都是其前者的特殊情況。2型文法（或上下文無關文法）被證明是程序設計語言中最有用的，而且今天它已代表著程序設計語言結構的標准方式。分析問題（parsing problem，用於上下文無關文法識別的有效演算法）的研究是在60年代和70年代，它相當完善的解決了這個問題。現在它已是編譯原理中的一個標准部分。

有限狀態自動機（Finite Automaton）和正則表達式（Regular Expression）同上下文無關文法緊密相關，它們與Chomsky的3型文法相對應。對它們的研究與Chomsky的研究幾乎同時開始，並且引出了表示程序設計語言的單詞的符號方式。

人們接著又深化了生成有效目標代碼的方法，這就是最初的編譯器，它們被一直使用至今。人們通常將其稱為優化技術（Optimization Technique），但因其從未真正地得到過被優化了的目標代碼而僅僅改進了它的有效性，因此實際上應稱作代碼改進技術（Code Improvement Technique）。

當分析問題變得好懂起來時，人們就在開發程序上花費了很大的功夫來研究這一部分的編譯器自動構造。這些程序最初被稱為編譯器的編譯器（Compiler-compiler），但更確切地應稱為分析程序生成器（Parser Generator），這是因為它們僅僅能夠自動處理編譯的一部分。這些程序中最著名的是Yacc（Yet Another Compiler-compiler），它是由Steve Johnson在1975年為Unix系統編寫的。類似的，有限狀態自動機的研究也發展了一種稱為掃描程序生成器（Scanner Generator）的工具，Lex（與Yacc同時，由Mike Lesk為Unix系統開發）是這其中的佼佼者。

在70年代後期和80年代早期，大量的項目都貫注於編譯器其它部分的生成自動化，這其中就包括了代碼生成。這些嘗試並未取得多少成功，這大概是因為操作太復雜而人們又對其不甚了解。

編譯器設計最近的發展包括：首先，編譯器包括了更加復雜演算法的應用程序它用於推斷或簡化程序中的信息；這又與更為復雜的程序設計語言的發展結合在一起。其中典型的有用於函數語言編譯的Hindley-Milner類型檢查的統一演算法。其次，編譯器已越來越成為基於窗口的交互開發環境（Interactive Development Environment，IDE）的一部分，它包括了編輯器、連接程序、調試程序以及項目管理程序。這樣的IDE標准並沒有多少，但是對標準的窗口環境進行開發已成為方向。另一方面，盡管近年來在編譯原理領域進行了大量的研究，但是基本的編譯器設計原理在近20年中都沒有多大的改變，它現在正迅速地成為計算機科學課程中的中心環節。

在九十年代，作為GNU項目或其它開放源代碼項目的一部分，許多免費編譯器和編譯器開發工具被開發出來。這些工具可用來編譯所有的計算機程序語言。它們中的一些項目被認為是高質量的，而且對現代編譯理論感性趣的人可以很容易的得到它們的免費源代碼。

大約在1999年，SGI公布了他們的一個工業化的並行化優化編譯器Pro64的源代碼，後被全世界多個編譯器研究小組用來做研究平台，並命名為Open64。Open64的設計結構好，分析優化全面，是編譯器高級研究的理想平台。

編譯器是一種特殊的程序，它可以把以特定編程語言寫成的程序變為機器可以運行的機器碼。我們把一個程序寫好，這時我們利用的環境是文本編輯器。這時我程序把程序稱為源程序。在此以後程序員可以運行相應的編譯器，通過指定需要編譯的文件的名稱就可以把相應的源文件（通過一個復雜的過程）轉化為機器碼了。

編譯器工作方法
首先編譯器進行語法分析，也就是要把那些字元串分離出來。然後進行語義分析，就是把各個由語法分析分析出的語法單元的意義搞清楚。最後生成的是目標文件，我們也稱為obj文件。再經過鏈接器的鏈接就可以生成最後的可執行代碼了。有些時候我們需要把多個文件產生的目標文件進行鏈接，產生最後的代碼。我們把一過程稱為交叉鏈接。

⑹ 編譯原理除了可以用來編寫編譯器，還在哪些領域可以用到編譯原理的知識

很多的，例如MASM編譯器。
編譯原理內容包括語言和文法、詞法分析、語法分析、語法制導翻譯、中間代碼生成、存儲管理、代碼優化和目標代碼生成等，這門課大部分人聽起來比較困難，介紹編譯程序構造的一般原理和基本方法，雖然只有少數人從事編譯方面的工作，但是這門課在理論、技術、方法上都對我們提供了系統而有效的訓練，有利於提高軟體人員的素質和能力。

⑺ 編譯器 優化

編譯是從源代碼（通常為高階語言）到能直接被計算機或虛擬機執行的目標代碼（通常為低階語言或機器語言）的翻譯過程。然而，也存在從低階語言到高階語言的編譯器，這類編譯器中用來從由高階語言生成的低階語言代碼重新生成高階語言代碼的又被叫做反編譯器。也有從一種高階語言生成另一種高階語言的編譯器，或者生成一種需要進一步處理的的中間代碼的編譯器（又叫級聯）。
典型的編譯器輸出是由包含入口點的名字和地址, 以及外部調用（到不在這個目標文件中的函數調用）的機器代碼所組成的目標文件。一組目標文件，不必是同一編譯器產生，但使用的編譯器必需採用同樣的輸出格式，可以鏈接在一起並生成可以由用戶直接執行的可執行程序。
從他的原理我們就好優化了，但是方法很多的

⑻ 編譯器具體實現中比較巧妙的思想有哪些

這種做法的好處是：
可以作為解釋器性能升級的一個簡單路徑，寫解釋器的代碼而得到初級編譯器的性能。事實上JamVM的解釋器可以配置為多種實現方式：switch-threading、indirect-threading、direct-threading、inline-threading，它們的差別僅在於對opcode的dispatch方式不同；所有實現方式都共享同一份handler代碼。
這種做法的缺點是：
這樣寫得到的「編譯器」無論從代碼組織還是程序思路都還是解釋器的那套，從編譯器的角度看很別扭。它最終實現出來效果跟從編譯器角度出發的template-based JIT一樣，但我覺得後者的思路更直觀，代碼也通常更清晰一些。
這種做法仍然無法跨越位元組碼邊界做任何優化，因為每個opcode對應一個單獨的handler，而這種做法的代碼生成僅僅是把handler拷貝到一起而已。
要在它的基礎之上進一步提高性能可以直接對位元組碼序列做些簡單模式匹配，以便跨越位元組碼邊界做優化。但這樣做通常是自討苦吃，工程上很難持續下去。