交叉編譯器原理

⑴ 交叉編譯opencv 自動生成zlib嗎

第一步，安裝交叉編譯工具arm-linux-gcc-4.3.2
xgy@ubuntu:~/toolchain$mkdir arm
xgy@ubuntu:~/toolchain$cd arm
xgy@ubuntu:~/toolchain/arm$tar xvf arm-linux-gcc-4.3.2
解壓後，在當目錄下會多一個usr目錄，由於我不喜歡這目錄太深，然後就執行如下命令：
xgy@ubuntu:~/toolchain/arm$cp -rv usr/local/* .
xgy@ubuntu:~/toolchain/arm$rm -rf usr
接下來設置環境變數PATH，執行命令如下：
xgy@ubuntu:~/toolchain/arm$cd
xgy@ubuntu:~$vi .bashrc
在.bashrc文件的最後加入：exportPATH=$PATH:/home/xgy/toolchain/arm/4.3.2/bin 保存退出（：wq）
xgy@ubuntu:~$source .bashrc //使剛設置的值生效
到此本來交叉編譯工具就已經安裝成功了的，可經過檢查卻發現下圖中左列的arm-linux-g++,arm-linux-gcc是4.3.3版本的（用命令arm-linux-gcc -v 查看），而其它的確是版本的，4.3.2這是一個奇怪現象！

因為我曾試過用4.3.3版本的g++交叉編譯opencv2.0總是出錯如下：

在這里，我只好創建軟鏈接，使它指向右側的arm-none-linux-gnueabi-g++，arm-none-linux-gnueabi-gcc。在創建之前先對原來的兩個文件做備份。執行命令如下：

在這里再次檢查下arm-linux-gcc及arm-linux-g++的版本
命令arm-linux-gcc –v 輸出的最後一行是應該是：gcc version 4.3.2 (Sourcery G++ Lite 2008q3-72)在這里說明下，這個很重要：現在所用的arm-linux-gcc實際上使用的是~./toolchain/arm/4.3.2/bin/目錄下的arm-none-linux-gnueabi-gcc，而它的include為arm/4.3.2/arm-none-linux-gnueabi/include,對應的lib為arm/4.3.2/arm-none-linux-gnueabi/lib,也就是說，你如果用arm-linux-gcc編譯程譯的話，對頭文件它預設的就找arm/4.3.2/arm-none-linux-gnueabi/include,對庫它預設的就找 arm/4.3.2/arm-none-linux-gnueabi/lib，而不是/usr/include /usr/lib，所以如果你要加什麼.h .a .so文件的話，記著一定要把這些文件加到這兩個目錄下去，不然這個交叉編譯器會告你找不到所要的庫或頭文件。這里的原理對於其它交叉編譯器也適應（主要指目錄結構），只是可能目錄名不一樣。
OK，到此，交編譯器安裝成功！
2012-11-2 今天換了一個4.3.2版本的arm-linux-gcc沒有發現上面的問題，也許是我以前在復制的時候出錯了，用cp命令時最好使用-a選項。
由於opencv2.0依懶於zlib,png、jpeg圖形庫而我們的arm-linux-gcc 是不帶這些庫的，它只帶了一些基本的庫，所以這里我們首先就要交叉編譯這些文件，安裝到arm/4.3.2/arm-none-linux-gnueabi/include，arm/4.3.2/arm-none-linux-gnueabi/lib目錄中。庫不一定要最新的，庫的版本太新了，opencv有可能不認識。
首先安裝zlib庫，這個是後面兩個庫的編譯基礎。
xgy@ubuntu:~/tmp$ tar zxvf zlib-1.2.3.tar.gz
在當前目錄下會多一個zlib-1.2.3的目錄。
由於 zlib 庫的configure 腳本不支持交叉編譯選項，只好自己手動臨時把 gcc 修改成指向我們的交叉編譯器 arm-linux-gcc 。執行如下命令：
xgy@ubuntu:~/tmp$ cd /usr/bin
xgy@ubuntu:/usr/bin$ sudo –i //這里得切換到root用戶下才能有許可權做下面的操作。
[sudo] password for xgy: //在這里輸入xgy用戶的密碼
root@ubuntu:~# cd /usr/bin
root@ubuntu:/usr/bin# mv gcc gcc_back
root@ubuntu:/usr/bin# mv ld ld_back
root@ubuntu:/usr/bin# ln -sv/home/xgy/toolchain/arm/4.3.2/bin/arm-linux-gcc ./gcc
root@ubuntu:/usr/bin# ln -sv/home/xgy/toolchain/arm/4.3.2/bin/arm-linux-ld ./ld
下面檢查下是否換過來了
root@ubuntu:/usr/bin#gcc –v
gcc version4.3.2 (Sourcery G++ Lite 2008q3-72) //為輸出的最後一行

root@ubuntu:/usr/bin#ld -v
GNU ld (SourceryG++ Lite 2008q3-72) 2.18.50.20080215
接著切換到原來的目錄~/tmp/zlib-1.2.3執行如下命令
root@ubuntu:/usr/bin#su – xgy //注意這里和用命令 suxgy是有區別的，-表示用xgy的環境
xgy@ubuntu:~$ cdtmp/zlib-1.2.3/
xgy@ubuntu:~/tmp/zlib-1.2.3$./configure --prefix=/home/xgy/toolchain/arm/4.3.2/arm-none-linux-gnueabi/--shared
xgy@ubuntu:~/tmp/zlib-1.2.3$make （如果以前在這個目錄下執行過make ,那要先執行makeclean 然後執行make）
xgy@ubuntu:~/tmp/zlib-1.2.3$make install
然後可以去~/toolchain/arm/4.3.2/arm-none-linux-gnueabi/{include,lib}目錄下是否多了一些文件（可以另外再開一個終端查看，這樣方便點），如下圖：

在這里記著把剛才改過的gcc再改回去，不然後面會出錯！！！

接下來安裝png庫，這個是用來顯示png圖形的。
xgy@ubuntu:~/tmp$tar jxvf libpng-1.2.18.tar.bz2
xgy@ubuntu:~/tmp$cd libpng-1.2.18/
由於libpng不提供有效的configure腳本（可以查看INSTALL文件），所以只好自己動手改Makefile文件了。
xgy@ubuntu:~/tmp/libpng-1.2.18$cp scripts/makefile.linux Makefile
xgy@ubuntu:~/tmp/libpng-1.2.18$vi Makefile

CC=arm-linux-gcc //修改這里
MKDIR_P=mkdir -p

# where "make install" putslibpng12.a, libpng12.so*,
# libpng12/png.h and libpng12/pngconf.h
# Prefix must be a full pathname.
prefix=/home/xgy/toolchain/arm/4.3.2/arm-none-linux-gnueabi
exec_prefix=$(prefix)

# Where the zlib library and include filesare located.
#ZLIBLIB=/usr/local/lib
#ZLIBINC=/usr/local/include
ZLIBLIB=/home/xgy/toolchain/arm/4.3.2/arm/arm-none-linux-gnueabi/lib //修改這里
ZLIBINC=/home/xgy/toolchain/arm/4.3.2/arm/arm-none-linux-gnueabi/include//修改這里
保存退出後執行如下命令：
xgy@ubuntu:~/tmp/libpng-1.2.18$ make
xgy@ubuntu:~/tmp/libpng-1.2.18$ makeinstall
然後可以去~/toolchain/arm/4.3.2/arm-none-linux-gnueabi/{include,lib}目錄下是否多了一些文件（可以另外再開一個終端查看，這樣方便點），如下圖：

如果有錯，檢查下前面的步聚，特別是看zlib有安裝有沒有出錯。

接下來安裝jpeg庫
xgy@ubuntu:~/tmp/libpng-1.2.18$ cd ..
xgy@ubuntu:~/tmp$tar zxvf jpegsrc.v6b.tar.gz
xgy@ubuntu:~/tmp/jpeg-6b$
xgy@ubuntu:~/tmp/jpeg-6b$ ./configure --prefix=/home/xgy/toolchain/arm/4.3.2/arm-none-linux-gnueabi/--host=arm-linux --enable-shared
按此命令進行，然後修 改makefile文件將CC的值改為arm-linux-gcc，一定得改！！
xgy@ubuntu:~/tmp/jpeg-6b$make
安裝前需要在 arm-linux 下建個目錄，不然安裝會出錯
xgy@ubuntu:~/tmp/jpeg-6b$mkdir -pv /home/xgy/toolchain/arm/4.3.2/arm-none-linux-gnueabi/man/man1
mkdir: created directory `/home/xgy/toolchain/arm/4.3.2/arm-none-linux-gnueabi/man/man1
xgy@ubuntu:~/tmp/jpeg-6b$ make install

然後可以去~/toolchain/arm/4.3.2/arm-none-linux-gnueabi/{include, lib}目錄下是否多了一些文件（可以另外再開一個終端查看，這樣方便點），如下圖：

到此，三個庫安裝完畢！

⑵ 嵌入式系統原理與應用---簡答題

環境搭建
一、認識開發板
1，ARM開發板的硬體配置（以S3C2410為例）
CPU、SDRAM、FLASH、LCD(包括鍵盤LED驅動器，觸摸屏)、乙太網、USB、串口、調試介面（JTAG）、AD及擴展。

2，ARM體系結構與編程。
僅僅了解arm開發板的硬體構成顯然是不夠的，還需要由表及裡，了解ARM體系結構與編程。這部分內容有相應文檔，中文版有杜春雷編寫的《ARM體系結構與編程》。

註：SDRAM = Synchronous DRAM，同步動態隨機存取存儲器
這是一種與CPU實現外頻Clock同步的內存模式，一般都採用168Pin的內存模組，工作電壓為3.3V。所謂clock同步是將CPU與RAM通過一個相同的時鍾鎖在一起，使RAM和CPU能夠共享一個時鍾周期，以相同的速度同步工作，這樣可以取消等待周期，減少數據傳輸的延遲，因此可提升計算機的性能和效率。

二、開發板與宿主機直接通信
開發板與主機之間的通信有4種方式：
1.JTAG。
2.COM。傳輸協議通常是xmodem/ymodem/zmodem.
3.網口。TFTP協議。
4.SD卡口

三、宿主機之windows平台
開發環境：ADS1.2+超級終端
ADS1.2：學會使用ADS平台軟體，會用AXD進行調試。
超級終端：一般設置波特率115200，數據位8位，停止位1，無奇偶校驗，軟體硬體流控制設為無。
配置網路：主要是配置NFS，需關閉防火牆，簡化嵌入式網路調試環境設置過程。

四、宿主機之Linux平台
開發環境：Linux+minicom
Linux：定製或全部安裝。下載安裝交叉編譯器
minicom：初始化，配置，同windows下超級終端。
配置網路：主要是配置NFS，需關閉iptables。

五、文件燒寫
包括燒寫內核，根文件系統，應用程序等。
內核映像的燒寫有兩種方式：
1.vivi，xmodem協議下載，然後燒寫
2.linux系統啟動後，使用imagewrite工具燒寫imagewrite /dev/mtd/0 zImage:192k

⑶ 如何制定android交叉編譯工具鏈

經常搞嵌入式開發的朋友對於交叉編譯環境應該並不陌生，說白了，就是一組運行在x86 PC機的編譯工具，可以讓你在PC機上編譯出目標平台（例如ARM）可識別的二進制文件。Android平台也提供了這樣的交叉編譯工具鏈，就放在Android的NDK開發包的toolchains目錄下，因此，我們的Makefile文件中，只需給出相應的編譯工具即可。
廢話就先說到這，直接上例子，我們目標是把下面這個math.c文件編譯成一個靜態庫文件：
#include <stdio.h>
int add( int a , int b ) {
return a+b;
}
你需要編寫一個Makefile文件，這里假設你的Android ndk被安裝在 /opt/android/ndk 目錄下，當然，你可以根據自己的實際情況修改Makefile中相關路徑的定義，Makefile文件示例如下：
# Makefile Written by ticktick
# Show how to cross-compile c/c++ code for android platform
.PHONY: clean
NDKROOT=/opt/android/ndk
PLATFORM=$(NDKROOT)/platforms/android-14/arch-arm
CROSS_COMPILE=$(NDKROOT)/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-
CC=$(CROSS_COMPILE)gcc
AR=$(CROSS_COMPILE)ar
LD=$(CROSS_COMPILE)ld
CFLAGS = -I$(PWD) -I$(PLATFORM)/usr/include -Wall -O2 -fPIC -DANDROID -DHAVE_PTHREAD -mfpu=neon -mfloat-abi=softfp
LDFLAGS =
TARGET = libmath.a
SRCS = $(wildcard *.c)
OBJS = $(SRCS:.c=.o)
all: $(OBJS)
$(AR) -rc $(TARGET) $(OBJS)
clean:
rm -f *.o *.a *.so
這里不講Makefile文件的基本原理，只說明一下針對Android環境的Makefile文件編寫的注意事項。
（1） CROSS_COMPILE
必須正確給出Android NDK編譯工具鏈的路徑，當在目錄中執行make命令的時候，編譯系統會根據 CROSS_COMPILE 前綴尋找對應的編譯命令。
（2） -I$(PLATFORM)/usr/include
由於Android平台沒有使用傳統的c語言庫libc，而是自己編寫了一套更加高效更適合嵌入式平台的c語言庫，所以系統頭文件目錄不能再使用默認的路徑，必須直到Android平台的頭文件目錄
（3） -Wall -O2 -fPIC -DANDROID -DHAVE_PTHREAD -mfpu=neon -mfloat-abi=softfp
這些參數的意義網上基本上都有介紹，我就不一一解釋了，並不都是必須添加的，但比較常用。
編譯方法：
寫好makefile文件，並且保存之後，就可以直接在當前目錄下執行make命令，編譯完成後，當前目錄下會生成 libmath.a ，即可直接拿到Android的jni工程中和使用了。

⑷ 如何使用android的ndk編譯器 編譯c++的庫

1. 概述 首先回顧一下 Android NDK 開發中，Android.mk 和 Application.mk 各自的職責。 Android.mk，負責配置如下內容： （1） 模塊名（LOCAL_MODULE） （2） 需要編譯的源文件（LOCAL_SRC_FILES） （3） 依賴的第三方庫（LOCAL_STATIC_LIBRARIES，LOCAL_SHARED_LIBRARIES） （4） 編譯/鏈接選項（LOCAL_LDLIBS、LOCAL_CFLAGS） Application.mk，負責配置如下內容： （1） 目標平台的ABI類型（默認值：armeabi）（APP_ABI） （2） Toolchains（默認值：GCC 4.8） （3） C++標准庫類型（默認值：system）（APP_STL） （4） release/debug模式（默認值：release） 由此我們可以看到，本文所涉及的編譯選項在Android.mk和Application.mk中均有出現，下面我們將一個個詳細介紹。 2. APP_ABI ABI全稱是：Application binary interface，即：應用程序二進制介面，它定義了一套規則，允許編譯好的二進制目標代碼在所有兼容該ABI的操作系統和硬體平台中無需改動就能運行。（具體的定義請參考 網路 或者 維基網路 ） 由上述定義可以判斷，ABI定義了規則，而具體的實現則是由編譯器、CPU、操作系統共同來完成的。不同的CPU晶元（如：ARM、Intel x86、MIPS）支持不同的ABI架構，常見的ABI類型包括：armeabi，armeabi-v7a，x86，x86_64，mips，mips64，arm64-v8a等。 這就是為什麼我們編譯出來的可以運行於Windows的二進製程序不能運行於Mac OS/Linux/Android平台了，因為CPU晶元和操作系統均不相同，支持的ABI類型也不一樣，因此無法識別對方的二進製程序。 而我們所說的「交叉編譯」的核心原理也跟這些密切相關，交叉編譯，就是使用交叉編譯工具，在一個平台上編譯生成另一個平台上的二進制可執行程序，為什麼可以做到？因為交叉編譯工具實現了另一個平台所定義的ABI規則。我們在Windows/Linux平台使用Android NDK交叉編譯工具來編譯出Android平台的庫也是這個道理。 這里給出最新 Android NDK 所支持的ABI類型及區別： 那麼，如何指定ABI類型呢？在 Application.mk 文件中添加一行即可： APP_ABI := armeabi-v7a //只編譯armeabi-v7a版本 APP_ABI := armeabi armeabi-v7a //同時編譯armeabi，armeabi-v7a版本 APP_ABI := all //編譯所有版本 3. LOCAL_LDLIBS Android NDK 除了提供了Bionic libc庫，還提供了一些其他的庫，可以在 Android.mk 文件中通過如下方式添加依賴： LOCAL_LDLIBS := -lfoo 其中，如下幾個庫在 Android NDK 編譯時就默認鏈接了，不需要額外添加在 LOCAL_LDLIBS 中： （1） Bionic libc庫 （2） pthread庫（-lpthread） （3） math（-lmath） （4） C++ support library (-lstdc++) 下面我列了一個表，給出了可以添加到「LOCAL_LDLIBS」中的不同版本的Android NDK所支持的庫： 下面是我總結的一些常用的CFLAGS編譯選項： （1）通用的編譯選項 -O2 編譯優化選項，一般選擇O2，兼顧了優化程度與目標大小 -Wall 打開所有編譯過程中的Warning -fPIC 編譯位置無關的代碼，一般用於編譯動態庫 -shared 編譯動態庫 -fopenmp 打開多核並行計算， -Idir 配置頭文件搜索路徑，如果有多個-I選項，則路徑的搜索先後順序是從左到右的，即在前面的路徑會被選搜索 -nostdinc 該選項指示不要標准路徑下的搜索頭文件，而只搜索-I選項指定的路徑和當前路徑。 --sysroot=dir 用dir作為頭文件和庫文件的邏輯根目錄，例如，正常情況下，如果編譯器在/usr/include搜索頭文件，在/usr/lib下搜索庫文件，它將用dir/usr/include和dir/usr/lib替代原來的相應路徑。 -llibrary 查找名為library的庫進行鏈接 -Ldir 增加-l選項指定的庫文件的搜索路徑，即編譯器會到dir路徑下搜索-l指定的庫文件。 -nostdlib 該選項指示鏈接的時候不要使用標准路徑下的庫文件 （2） ARM平台相關的編譯選項 -marm -mthumb 二選一，指定編譯thumb指令集還是arm指令集 -march=name 指定特定的ARM架構，常用的包括：-march=armv6， -march=armv7-a -mfpu=name 給出目標平台的浮點運算處理器類型，常用的包括：-mfpu=neon，-mfpu=vfpv3-d16 -mfloat-abi=name 給出目標平台的浮點預算ABI，支持的參數包括：「soft」, 「softfp」 and 「hard」

⑸ linux嵌入式中的靜態交叉編譯是什麼意思

應該說是分為靜態和動態的

靜態就是把需要的庫文件也直接編譯進去

動態則是在需要的時候才去調用，本身不編譯進去

⑹ 編譯器的發展史

編譯器
編譯器，是將便於人編寫，閱讀，維護的高級計算機語言翻譯為計算機能識別，運行的低級機器語言的程序。編譯器將源程序（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文件。再經過鏈接器的鏈接就可以生成最後的可執行代碼了。有些時候我們需要把多個文件產生的目標文件進行鏈接，產生最後的代碼。我們把一過程稱為交叉鏈接。

⑺ 什麼是嵌入式linux交叉工具鏈

在編譯軟體的時候，會用到（鏈接）一些平台相關的類庫，如果是在本地運行的話，一般不用作特殊處理，但由於嵌入式軟體的運行平台不是本地，所以要做一些特殊處理，讓編譯環境信賴的類庫脫離本地信賴，使用嵌入式平台的類庫來進行鏈接，處理這一過程就叫作交叉編譯工具鏈。
不只是嵌入式要用到交叉編譯工具，跨平台編譯也要使用交叉編譯工具鏈，如linux編譯win32軟體，linu 32位系統編譯linux64位軟體等等。它們的部署原理都是一樣的。

⑻ 如何用gentoo交叉編譯一個基本系統

嵌入式系統的編譯環境
為某個平台開發軟體，首先需要一個編譯環境。一般來說，編譯環境包括三部分：工具 鏈/運行環境/編譯方法。對於嵌入式系統來說，常見的編譯環境有三種：

本地環境。如很流行的Ubuntu for ARM，利用官方製作好的目標機鏡像(通常包含了 編譯環境)，直接在目標機上編譯/安裝軟體，與PC機開發完全一樣。這種方法簡單省 事。缺點也顯而易見，編譯速度慢，耗時長，特別是較大的軟體包(如xbmc)的時候， 程序員不是停下來喝杯咖啡就可以收攤，恐怕得打場通宵dota後才能看到結果 了…(或許distcc能有所改善)

虛擬環境。在PC上建立目標機的虛擬環境，如QEMU-ARM，然後chroot到虛擬環境 中編譯/安裝軟體。這種方法利用了PC的處理能力，速度比本地環境要快得多，但 QEMU並不能完美的模擬目標機環境，如不支持某些系統調用等，這可能導致它不能 正確的編譯某些軟體。

交叉編譯。為目標機交叉編譯軟體，這是最常規的辦法，也是上面兩種方法實現的基 礎。說交叉編譯是「臟活」，是因為需要手工解決軟體包的所有依賴問題，手工編譯 每一個軟體包，並且解決軟體包對目標機兼容問題… 看網上鋪天蓋地關於求教/指導 某個軟體包如何正確交叉編譯就知道，有多少程序員在被它虐?

gentoo下的交叉編譯
gentoo是一個metadistribution，從源代碼構建整個系統，同時支持很多不同的體 系如alpha/arm/hppa/ppc/sh/sparc/s390等，也為交叉編譯提供了便利的工具，這是 其它二進制發行版沒有辦法比擬的(scratchbox也顯得弱爆了)。

gentoo下的交叉編譯通過crossdev和portage來實現。portage帶來的好處是自 動解決依賴和自動升級更新系統，跟本機環境一樣。

製作工具鏈
crossdev用來製作交叉工具鏈，並且還提供了交叉編譯環境下的emerge的輔助腳本。如 下編譯arm平台的工具鏈：

$ sudo crossdev -t arm-supertux-linux-gnueabi
這樣，crossdev最終製作了符合「gentoo規范」的arm交叉編譯器。

運行環境
crossdev生成/usr/arm-supertux-linux-gnueabi/目錄作為目標系統 $buildroot。編譯後生成的目標會被emerge到$buildroot，編譯時依賴的環境(如 鏈接庫/頭文件/pkgconfig等)也都在$buildroot。

交叉編譯
有了工具鏈/運行環境，使用的crossdev封裝過的emerge，就可以自由的emerge了。 如交叉編譯bash：

$ sudo emerge-arm-supertux-linux-gnueabi -avu bash
porage會自動把bash的依賴如ncurses/readline一起emerge到$buildroot。 交叉編譯就是變得如此簡單…

碰到的問題
站在巨人的肩膀上可以看的更遠，前提是我們先要爬上巨人的肩膀。portage是一個快 速更新迭代的系統，並不完美，維護者沒有辦法測試每個軟體包的所有兼容性。所以， 當你想安裝一個圖形環境如$emerge -avu enlightenment時，很可能會出現錯誤。但 portage提供了細粒度的控制幫助解決這樣的問題。下面是我碰到過一些情形和解決方 法：

由於軟體包的環境變數引起的問題，如鏈接庫指向了/usr/bin，而非 $buildroot。可以配置$buldroot/etc/portage/env/目錄下相應的文 件，portage會自動source該文件，從而改變編譯時的環境。

portage沒有包含該軟體或portage自身的bug引起，如默認使能了某個在目標機 平台不能使用的特性。建立一個針對目標機的overlay，自己編寫相應軟體包的 ebuild文件指導portage進行交叉編譯。

當某個軟體包分階段編譯時，如perl編譯時先生成miniperl，通過miniperl最 後生成perl目標映像。由於miniperl被交叉編譯器生成目標機的映像，正常情況 下不能主機環境中繼續運行生成最終的目標映像。這就要藉助qemu-arm+binfmt模 擬目標機環境，讓miniperl在主機環境中也能無縫的運行。

從形式上看，處理上面幾種情況，也是「臟活」。不僅需要了解該軟體包的編譯環境， 還需要了解portage的原理，還要知道ebuild的書寫語法。但是，與傳統的交叉編譯 方式比起來，這是一勞永逸的工作，別人使用我的運行環境和overlay，即不需再做什 么就能生成最終的目標機系統。

⑼ C++編程：什麼是CrossGCC

CrossGCC是一個比較通用的編譯器，支持幾乎所有主流MCU/CPU/DSP 。

它是免費的，藉助linux可以大幅提高便捷性。
想了解處理器的秘密執行原理，寫出高質量的代碼，用它很合適。

補充：C++這個詞在中國大陸的程序員圈子中通常被讀做「C加加」，而西方的程序員通常讀做「C plus plus」，「CPP」。 它是一種使用非常廣泛的計算機編程語言。C++是一種靜態數據類型檢查的、支持多重編程範式的通用程序設計語言。它支持過程化程序設計、數據抽象、面向對象程序設計、泛型程序設計等多種程序設計風格。