編譯器parser
time_t.TOxxx();//改變時間格式，然後應用新的時間格式列印就可以了，如printf("%s",time().ToString);
❷ 編譯器內部使用了哪些技術
編譯器是一種將高級語言代碼轉換為機器語言代碼的工具。在編譯器內部，使用了許多技術來實現代碼的轉換和優化。
其中一些常見的技術包括：
詞法分析器（Lexer）：將源代碼轉換為一個個標記（Token），並去除無用的空格和注釋。
語法分析器（Parser）：將標記轉換為抽象語法樹（AST），並舉隱檢查語正虛廳法是否正確。
語義分析器（Semantic Analyzer）：對AST進行分析，檢查變數、函數、類型等是否符合規范，並進行類型檢查等操作。
優譽早化器（Optimizer）：對生成的機器語言代碼進行優化，以提高代碼的執行效率和空間利用率。
代碼生成器（Code Generator）：將優化後的代碼生成可執行的機器語言代碼。
調試器（Debugger）：用於調試生成的代碼，可以在代碼執行過程中進行斷點調試、變數監視等操作。
編譯器內部使用這些技術，可以提高代碼的執行效率、減少代碼出錯的概率，並方便程序員進行調試和維護。
碼字不易，希望能幫到您！ 求採納...
❸ 編譯原理的發展歷程
在20世紀40年代，由於馮·諾伊曼在存儲-程序計算機方面的先鋒作用，編寫一串代碼或程序已成必要，這樣計算機就可以執行所需的計算。開始時，這些程序都是用機器語言 （machine language ）編寫的。機器語言就是表示機器實際操作的數字代碼，例如：
C7 06 0000 0002 表示在IBM PC 上使用的Intel 8x86處理器將數字2移至地址0 0 0 0 （16進制）的指令。
但編寫這樣的代碼是十分費時和乏味的，這種代碼形式很快就被匯編語言（assembly language ）代替了。在匯編語言中，都是以符號形式給出指令和存儲地址的。例如，匯編語言指令 MOV X,2 就與前面的機器指令等價（假設符號存儲地址X是0 0 0 0 ）。匯編程序（assembler ）將匯編語言的符號代碼和存儲地址翻譯成與機器語言相對應的數字代碼。
匯編語言大大提高了編程的速度和准確度，人們至今仍在使用著它，在編碼需要極快的速度和極高的簡潔程度時尤為如此。但是，匯編語言也有許多缺點：編寫起來也不容易，閱讀和理解很難；而且匯編語言的編寫嚴格依賴於特定的機器，所以為一台計算機編寫的代碼在應用於另一台計算機時必須完全重寫。
發展編程技術的下一個重要步驟就是以一個更類似於數學定義或自然語言的簡潔形式來編寫程序的操作，它應與任何機器都無關，而且也可由一個程序翻譯為可執行的代碼。例如，前面的匯編語言代碼可以寫成一個簡潔的與機器無關的形式 x = 2。
在1954年至1957年期間，IBM的John Backus帶領的一個研究小組對FORTRAN語言及其編譯器的開發，使得上面的擔憂不必要了。但是，由於當時處理中所涉及到的大多數程序設計語言的翻譯並不為人所掌握，所以這個項目的成功也伴隨著巨大的辛勞。幾乎與此同時，人們也在開發著第一個編譯器， Noam Chomsky開始了他的自然語言結構的研究。他的發現最終使得編譯器結構異常簡單，甚至還帶有了一些自動化。Chomsky的研究導致了根據語言文法（grammar ，指定其結構的規則）的難易程度以及識別它們所需的演算法來為語言分類。正如現在所稱的-與喬姆斯基分類結構（Chomsky hierarchy ）一樣-包括了文法的4個層次：0型、1型、2型和3型文法，且其中的每一個都是其前者的專門化。2型（或上下文無關文法（context-free grammar ））被證明是程序設計語言中最有用的，而且今天它已代表著程序設計語言結構的標准方式。
分析問題（ parsing problem ，用於限定上下文無關語言的識別的有效演算法）的研究是在20世紀60年代和70年代，它相當完善地解決了這一問題， 現在它已是編譯理論的一個標准部分。它們與喬姆斯基的3型文法相對應。對它們的研究與喬姆斯基的研究幾乎同時開始，並且引出了表示程序設計語言的單詞（或稱為記號）的符號方式。
人們接著又深化了生成有效的目標代碼的方法，這就是最初的編譯器，它們被一直使用至今。人們通常將其誤稱為優化技術（optimization technique ），但因其從未真正地得到過被優化了的目標代碼而僅僅改進了它的有效性，因此實際上應稱作代碼改進技術（code improvement technique ）。
這些程序最初被稱為編譯程序-編譯器，但更確切地應稱為分析程序生成器 （parser generator ），這是因為它們僅僅能夠自動處理編譯的一部分。這些程序中最著名的是 Yacc （yet another compiler- compiler），它是由Steve Johnson在1975年為Unix系統編寫的。
類似地，有窮自動機的研究也發展了另一種稱為掃描程序生成器 （scanner generator ）的工具，Lex （與Yacc同時，由Mike Lesk為Unix系統開發的）是這其中的佼佼者。在20世紀70年代後期和80年代早期，大量的項目都關注於編譯器其他部分的生成自動化，這其中就包括代碼生成。這些嘗試並未取得多少成功，這大概是因為操作太復雜而人們又對其不甚了解。
編譯器設計最近的發展包括：首先，編譯器包括了更為復雜的演算法的應用程序，它用於推斷或簡化程序中的信息；這又與更為復雜的程序設計語言（可允許此類分析）的發展結合在一起。其中典型的有用於函數語言編譯的Hindle y - Milner類型檢查的統一演算法。
其次，編譯器已越來越成為基於窗口的交互開發環境（interactive development environment，IDE ）的一部 分，它包括了編輯器、鏈接程序、調試程序以及項目管理程序。這樣的IDE的標准並沒有多少， 但是已沿著這一方向對標準的窗口環境進行開發了。
❹ 編譯原理試題·
Lex和Yacc應用方法(一).初識Lex
草木瓜 20070301
Lex(Lexical Analyzar 詞法分析生成器)，Yacc(Yet Another Compiler Compiler
編譯器代碼生成器)是Unix下十分重要的詞法分析，語法分析的工具。經常用於語言分
析，公式編譯等廣泛領域。遺憾的是網上中文資料介紹不是過於簡單，就是跳躍太大，
入門參考意義並不大。本文通過循序漸進的例子，從0開始了解掌握Lex和Yacc的用法。
一.Lex(Lexical Analyzar) 初步示例
先看簡單的例子(註：本文所有實例皆在RetHat linux下完成):
一個簡單的Lex文件 exfirst.l 內容：
%{
#include "stdio.h"
%}
%%
[\n] ;
[0-9]+ printf("Int : %s\n",yytext);
[0-9]*\.[0-9]+ printf("Float : %s\n",yytext);
[a-zA-Z][a-zA-Z0-9]* printf("Var : %s\n",yytext);
[\+\-\*\/\%] printf("Op : %s\n",yytext);
. printf("Unknown : %c\n",yytext[0]);
%%
在命令行下執行命令flex解析，會自動生成lex.yy.c文件：
[root@localhost liweitest]flex exfirst.l
進行編譯生成parser可執行程序：
[root@localhost liweitest]cc -o parser lex.yy.c -ll
[注意：如果不加-ll鏈結選項，cc編譯時會出現以下錯誤，後面會進一步說明。]
/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../crt1.o(.text+0x18): In function `_start':
../sysdeps/i386/elf/start.S:77: undefined reference to `main'
/tmp/cciACkbX.o(.text+0x37b): In function `yylex':
: undefined reference to `yywrap'
/tmp/cciACkbX.o(.text+0xabd): In function `input':
: undefined reference to `yywrap'
collect2: ld returned 1 exit status
創建待解析的文件 file.txt：
title
i=1+3.9;
a3=909/6
bcd=4%9-333
通過已生成的可執行程序，進行文件解析。
[root@localhost liweitest]# ./parser < file.txt
Var : title
Var : i
Unknown : =
Int : 1
Op : +
Float : 3.9
Unknown : ;
Var : a3
Unknown : =
Int : 909
Op : /
Int : 6
Var : bcd
Unknown : =
Int : 4
Op : %
Int : 9
Op : -
Int : 333
到此Lex用法會有個直觀的了解：
1.定義Lex描述文件
2.通過lex，flex工具解析成lex.yy.c文件
3.使用cc編譯lex.yy.c生成可執行程序
再來看一個比較完整的Lex描述文件 exsec.l ：
%{
#include "stdio.h"
int linenum;
%}
%%
title showtitle();
[\n] linenum++;
[0-9]+ printf("Int : %s\n",yytext);
[0-9]*\.[0-9]+ printf("Float : %s\n",yytext);
[a-zA-Z][a-zA-Z0-9]* printf("Var : %s\n",yytext);
[\+\-\*\/\%] printf("Op : %s\n",yytext);
. printf("Unknown : %c\n",yytext[0]);
%%
showtitle()
{
printf("----- Lex Example -----\n");
}
int main()
{
linenum=0;
yylex(); /* 進行分析 */
printf("\nLine Count: %d\n",linenum);
return 0;
}
int yywrap()
{
return 1;
}
進行解析編譯：
[root@localhost liweitest]flex exsec.l
[root@localhost liweitest]cc -o parser lex.yy.c
[root@localhost liweitest]./parser < file.txt
----- Lex Example -----
Var : i
Unknown : =
Int : 1
Op : +
Float : 3.9
Unknown : ;
Var : a3
Unknown : =
Int : 909
Op : /
Int : 6
Var : bcd
Unknown : =
Int : 4
Op : %
Int : 9
Op : -
Int : 333
Line Count: 4
這里就沒有加-ll選項，但是可以編譯通過。下面開始著重整理下Lex描述文件.l。
二.Lex(Lexical Analyzar) 描述文件的結構介紹
Lex工具是一種詞法分析程序生成器，它可以根據詞法規則說明書的要求來生成單詞識
別程序，由該程序識別出輸入文本中的各個單詞。一般可以分為<定義部分><規則部
分><用戶子程序部分>。其中規則部分是必須的，定義和用戶子程序部分是任選的。
(1)定義部分
定義部分起始於 %{ 符號，終止於 %} 符號，其間可以是包括include語句、聲明語句
在內的C語句。這部分跟普通C程序開頭沒什麼區別。
%{
#include "stdio.h"
int linenum;
%}
(2) 規則部分
規則部分起始於"%%"符號，終止於"%%"符號，其間則是詞法規則。詞法規則由模式和
動作兩部分組成。模式部分可以由任意的正則表達式組成，動作部分是由C語言語句組
成，這些語句用來對所匹配的模式進行相應處理。需要注意的是，lex將識別出來的單
詞存放在yytext[]字元數據中，因此該數組的內容就代表了所識別出來的單詞的內容。
類似yytext這些預定義的變數函數會隨著後面內容展開一一介紹。動作部分如果有多
行執行語句，也可以用{}括起來。
%%
title showtitle();
[\n] linenum++;
[0-9]+ printf("Int : %s\n",yytext);
[0-9]*\.[0-9]+ printf("Float : %s\n",yytext);
[a-zA-Z][a-zA-Z0-9]* printf("Var : %s\n",yytext);
[\+\-\*\/\%] printf("Op : %s\n",yytext);
. printf("Unknown : %c\n",yytext[0]);
%%
A.規則部分的正則表達式
規則部分是Lex描述文件中最為復雜的一部分，下面列出一些模式部分的正則表達式字
符含義：
A-Z, 0-9, a-z 構成模式部分的字元和數字。
- 指定范圍。例如：a-z 指從 a 到 z 之間的所有字元。
\ 轉義元字元。用來覆蓋字元在此表達式中定義的特殊意義，
只取字元的本身。
[] 表示一個字元集合。匹配括弧內的任意字元。如果第一個字
符是^那麼它表示否定模式。例如: [abC] 匹配 a, b, 和C
的任何一個。
^ 表示否定。
* 匹配0個或者多個上述模式。
+ 匹配1個或者多個上述模式。
? 匹配0個或1個上述模式。
$ 作為模式的最後一個字元時匹配一行的結尾。
{ } 表示一個模式可能出現的次數。 例如: A{1,3} 表示 A 可
能出現1次或3次。[a-z]{5} 表示長度為5的，由a-z組成的
字元。此外，還可以表示預定義的變數。
. 匹配任意字元，除了 \n。
( ) 將一系列常規表達式分組。如：{Letter}({Letter}|{Digit})*
| 表達式間的邏輯或。
"一些符號" 字元的字面含義。元字元具有。如："*" 相當於 [\*]。
/ 向前匹配。如果在匹配的模式中的"/"後跟有後續表達式，
只匹配模版中"/"前面的部分。如：模式為 ABC/D 輸入 ABCD，
時ABC會匹配ABC/D，而D會匹配相應的模式。輸入ABCE的話，
ABCE就不會去匹配ABC/D。
B.規則部分的優先順序
規則部分具有優先順序的概念，先舉個簡單的例子：
%{
#include "stdio.h"
%}
%%
[\n] ;
A {printf("ONE\n");};
AA {printf("TWO\n");};
AAAA {printf("THREE\n");};
%%
此時，如果輸入內容：
[root@localhost liweitest]# cat file1.txt
AAAAAAA
[root@localhost liweitest]# ./parser < file1.txt
THREE
TWO
ONE
Lex分析詞法時，是逐個字元進行讀取，自上而下進行規則匹配的，讀取到第一個A字元
時，遍歷後發現三個規則皆匹配成功，Lex會繼續分析下去，讀至第五個字元時，發現
"AAAA"只有一個規則可用，即按行為進行處理，以此類推。可見Lex會選擇最長的字元
匹配規則。
如果將規則
AAAA {printf("THREE\n");};
改為
AAAAA {printf("THREE\n");};
./parser < file1.txt 輸出結果為：
THREE
TWO
再來一個特殊的例子：
%%
title showtitle();
[a-zA-Z][a-zA-Z0-9]* printf("Var : %s\n",yytext);
%%
並輸入title，Lex解析完後發現，仍然存在兩個規則，這時Lex只會選擇第一個規則，下面
的則被忽略的。這里就體現了Lex的順序優先順序。把這個例子稍微改一下：
%%
[a-zA-Z][a-zA-Z0-9]* printf("Var : %s\n",yytext);
title showtitle();
%%
Lex編譯時會提示：warning, rule cannot be matched.這時處理title字元時，匹配
到第一個規則後，第二個規則就無效了。
再把剛才第一個例子修改下，加深下印象！
%{
#include "stdio.h"
%}
%%
[\n] ;
A {printf("ONE\n");};
AA {printf("TWO\n");};
AAAA {printf("THREE\n");};
AAAA {printf("Cannot be executed!");};
./parser < file1.txt 顯示效果是一樣的，最後一項規則肯定是會忽略掉的。
C.規則部分的使用變數
且看下面示例：
%{
#include "stdio.h"
int linenum;
%}
int [0-9]+
float [0-9]*\.[0-9]+
%%
{int} printf("Int : %s\n",yytext);
{float} printf("Float : %s\n",yytext);
. printf("Unknown : %c\n",yytext[0]);
%%
在%}和%%之間，加入了一些類似變數的東西，注意是沒有;的，這表示int，float分
別代指特定的含義，在兩個%%之間，可以通過{int}{float}進行直接引用，簡化模
式定義。
(3) 用戶子程序部分
最後一個%%後面的內容是用戶子程序部分，可以包含用C語言編寫的子程序，而這些子
程序可以用在前面的動作中，這樣就可以達到簡化編程的目的。這里需要注意的是，
當編譯時不帶-ll選項時，是必須加入main函數和yywrap(yywrap將下後面說明)。如：
...
%%
showtitle()
{
printf("----- Lex Example -----\n");
}
int main()
{
linenum=0;
yylex(); /* 進行Lex分析 */
printf("\nLine Count: %d\n",linenum);
return 0;
}
int yywrap()
{
return 1;
}
三.Lex(Lexical Analyzar) 一些的內部變數和函數
內部預定義變數：
yytext char * 當前匹配的字元串
yyleng int 當前匹配的字元串長度
yyin FILE * lex當前的解析文件，默認為標准輸出
yyout FILE * lex解析後的輸出文件，默認為標准輸入
yylineno int 當前的行數信息
內部預定義宏：
ECHO #define ECHO fwrite(yytext, yyleng, 1, yyout) 也是未匹配字元的
默認動作
內部預定義的函數：
int yylex(void) 調用Lex進行詞法分析
int yywrap(void) 在文件(或輸入)的末尾調用。如果函數的返回值是1，就停止解
析。 因此它可以用來解析多個文件。代碼可以寫在第三段，這
樣可以解析多個文件。 方法是使用 yyin 文件指針指向不同的
文件，直到所有的文件都被解析。最後，yywrap() 可以返回1
來表示解析的結束。
lex和flex都是解析Lex文件的工具，用法相近，flex意為fast lexical analyzer generator。
可以看成lex的升級版本。
相關更多內容就需要參考flex的man手冊了，十分詳盡。
四.關於Lex的一些綜述
Lex其實就是詞法分析器，通過配置文件*.l，依據正則表達式逐字元去順序解析文件，
並動態更新內存的數據解析狀態。不過Lex只有狀態和狀態轉換能力。因為它沒有堆棧，
它不適合用於剖析外殼結構。而yacc增加了一個堆棧，並且能夠輕易處理像括弧這樣的
結構。Lex善長於模式匹配，如果有更多的運算要求就需要yacc了。
❺ 編譯器的發展史
編譯器
編譯器，是將便於人編寫，閱讀，維護的高級計算機語言翻譯為計算機能識別，運行的低級機器語言的程序。編譯器將源程序（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文件。再經過鏈接器的鏈接就可以生成最後的可執行代碼了。有些時候我們需要把多個文件產生的目標文件進行鏈接，產生最後的代碼。我們把一過程稱為交叉鏈接。
❻ 我看BNF，請問parser是什麼意思
parser 就是語言或語句的分析器,它是一段程序和一組子程橋衡序,執行:
"循環: 讀一字元,判斷:如果,則,否則;讀一字元,如果,則,否則...".
它把橡消扒讀入的一個一個字元,分解成一個一個的詞,分析出詞意,句意.
例如讀入: y = (2.0 * cos(0.1) - x * sin(0.1));
分解成x,y,2.0,0.1,cos,sin 等詞
分析出: 數 2.0,0.1;變數x,y;函數名cos,sin
運算符-,*,(,)
行結束符分號
然後分析句意,先算函數,再做乘梁昌法,再減法,再賦值.
parser 類似編譯器.
❼ Parser Combinator 在語法解析的當中處於怎樣的位置
結論先行：parser combinator 在正經的編譯相關研究沒有提及，是因為它沒有解決任何新的演算法問題，只是換了一種方式來編寫非左遞歸文法。換言之，它在語法解析演算法研究領域里沒有價值。
如果要看詳細的解釋，就必須從語法分析的兩個基本演算法看起。
從演算法上說，語法分析的思路分為自頂向下和自底向上兩類。兩者對輸入文本的分類是類似的：它們都將輸入劃分為終結符和產生式（或者說，表達式），而區別在於遍歷的方法：自頂向下方法通過獲取向前數第 k 個終結符猜測整句表達式究竟屬於哪個產生式並將後續展開進行後續計算；而自底向上方法通過不停地遍歷終結符（所謂移進，shift），直到發現已經獲取的終結符序列滿足某一個已知的產生式，從而將已知的終結符序列合並成產生式（即所謂規約，rece）。所以自頂向下文法的一個特徵就是，它不能很好地支持左遞歸文法，因為自頂向下方法要求所有能夠被它解析的文法，總是必須在前若干個終結符上看出區別，這也是所謂 ANTLR 的 LL(k) 文法中的 k 的含義。自底向上方法不受這個限制，相反地，為了能夠處理二義文法，自底向上演算法需要決定可以規約時應該繼續看下一個終結符，還是選擇直接合並產生式，這也就是 Yacc/Bison 里用的 LALR 演算法著名的移進/規約沖突和規約/規約沖突。順便說一句，前面 @vczh 梓翰說的 Generalized LR 其實也沒有解決沖突，它只是將所有的選擇列出來，而 LALR 選擇自動丟棄部分選擇。但從語法的解析能力上看，兩者沒有區別。
那麼，parser combinator 是不是跳出兩者之外的第三種方法？我們可以拿一個典型的 parser combinator 來做例子，即 Haskell 的 parsec。我不知道這里的朋友有多少熟悉這個庫，只說一點。Parsec 的 <|> 操作符——它的右端要求必須是在左端出錯並且沒有接收任何輸入的前提下，才會轉入右端。這實際上就是說，它的左端和右端不能有公共左因子，而這一點，正是它支持遞歸下降文法的典型特徵。對其行為有疑問的，可以查閱 Real World Haskell 對 backtracing 和 Try 操作符的說明和在線評論：<a href="http://book.realworldhaskell.org/read/using-parsec.html" target="_blank">http://book.realworldhaskell.org/read/using-parsec.html</a>。
我猜看到這里，熟悉 parsec 的朋友可能要拿 Try 算符來反駁我。然而 Try 算符的存在，恰恰說明 parsec 並不是以一致的方式處置語法規則的。一般從工程角度上說，即便是寫不出上下文無關文法的語言，也一樣可以用上下文無關分析器分析。一個很常見的例子是 Perl 和它的怪異變體，Powershell，程序員實際上可以在語法分析過程中引入一些分析的小技巧以及合理地參考語義信息，來讓它被正確解析。同樣的技巧也可以被用在遞歸下降文法上。Parsec 的 Try 和 Optional，它們都是通過在遞歸過程中增加一些回溯的操作來允許一定程度的回溯，從而獲得更強的表達能力，代價則是時間復雜度上升，這一點 Real World Haskell 也有說明。其實這沒有什麼特別，很多編譯器開發者也都是這么做的。事實上，由於 Haskell 運行時大量使用惰性求值和圖規約技術，遞歸操作是相對低代價的，所以 Haskell 更段燃鬧能容忍握罩深度的遞歸調用。但這是實現細節，而非演算法差異。與之對比，Yacc/Bison 允許程序員自由書寫左遞歸文法而不需要任何顯式標注，這是它在演算法層面處理能力更強的明證。
所以，parser combinator 其實就是自頂向下分析演算法的一種。所謂 parser combinator 和 parser generator 的區別，實際上就是將演算法的狀態表示為一個整數（Yacc/Bison 的做法）和一個類（ANTLR 的做法）的分別，看上去寫法完全不段基同，然而寫法並不決定表達能力。雖然我必須承認，從工程角度上，combinator 不需要單獨寫語法定義文件，調試起來確實比 Yacc/Bison 舒服很多。