對於Android NDK編譯器ARM和Thumb模式的理解

標籤：

編譯NDK項目時，編譯器無法識別arm彙編，設定LOCAL_ARM_MODE := arm後問題解決，

 

NDK文檔上對LOCAL_ARM_MODE的說明如下：

LOCAL_ARM_MODE

By default, ARM target binaries are generated in ‘thumb‘ mode, where each instruction are 16-bit wide, and linked with /thumb STL libraries. You can define this variable to ‘arm‘ if you want to force the generation of the module‘s object files in ‘arm‘ (32-bit instructions) mode. E.g.:

 LOCAL_ARM_MODE := arm 

Note that you can also instruct the build system to only build specific sources in ARM mode by appending an ‘.arm‘ suffix to its source file name. For example, with:

 LOCAL_SRC_FILES := foo.c bar.c.arm 

Tells the build system to always compile ‘bar.c‘ in ARM mode, and to build foo.c according to the value of LOCAL_ARM_MODE.

NOTE: Setting APP_OPTIM to ‘debug‘ in your Application.mk will also force the generation of ARM binaries as well. This is due to bugs in the toolchain debugger that don‘t deal too well with thumb code.

 

文檔上的說明比較簡略，我在網上找了篇不錯的文章，如下： 

原文連結：http://blog.k-res.net/archives/1291.html 

以前在做Symbian的時候，曾經研究過ARM CPU的指令集問題，ARM處理器支援兩套指令集，即ARM和Thumb。ARM為32位指令集而Thumb為16位指令集，理論上32位可以提供更快的執行速度但會產生更大的二進位執行檔案，而16位的Thumb則恰恰相反，省地但慢，這也正是體現出了ARM對於嵌入式裝置的專業性。對於我這種犧牲一切換速度的理念來說，當時就留下了ARM就比Thumb快的印象，以致於現在在做Android NDK原生開發時，也是優先用ARM指令集。（這個可以通過在Android.mk中加入LOCAL_ARM_MODE := arm控制，預設情況下NDK使用Thumb指令集）

但是最近在Xcode編譯iOS項目時，注意到同為ARM處理器的蘋果裝置，使用的是Thumb指令集，而且好像還是某種新版本的Thumb指令集，小搜尋了一下看到有人說這種armv7引入的叫做Thumb-2的指令集要比arm指令集更好！於是又重新搜尋更新了一下大腦知識庫…

armv7對於蘋果裝置來說，意味著iPhone 3GS以上層級的裝置的CPU，而目前主流的Android裝置幾乎全是armv7處理器的了。也許對於早起的armv6處理器來說，ARM指令集還有優勢，但是對於新的v7處理器，各種資料都表明Thumb-2要更好一些。

總的來說，ARM指令集會在某些方面有優勢，比如手寫彙編（額…），而Thumb則能產生更精簡的代碼，而且還有一點我之前沒有太意識到的問題就是：省電！所以仔細斟酌後，我還是決定把NDK編譯選項由原來的ARM改回預設的Thumb，遵循預設原則吧還是。

而對於v7和非v7的問題，Android上可以這樣處理，以略增大apk為代價，加入單獨針對v7和非v7版的so檔案，這樣apk在安裝時會自動根據目標裝置的CPU安裝合適的so庫，從而達到更好的效果，具體做法是在Application.mk中加入”APP_ABI := armeabi armeabi-v7a"

另外，隨著項目規模的增大，代碼編譯產生時間會大大增加，這時候可以考慮更換r8c版NDK新加入的Clang編譯器（蘋果家的編譯器，新版Xcode預設就用它），實測發現Clang比GCC明顯快很多，而且對於warning, error的顯示也比GCC要人性的多（有人說GCC的提示就像是天書，呵呵），不過據說Clang也有一些不足，比如對於標準的支援不如GCC（這話怎麼聽著像是說MS的…），不如GCC支援的語言廣等，但感覺對於Android原生開發來說都是些無關緊要的事，我只要編譯快，運行快就好了！

改用Clang編譯器的方法如下：

對於ndk-build方式，可以使用“export NDK_TOOLCHAIN_VERSION=clang3.1”匯出環境變數，或者將這個環境變數設定加入到Application.mk中。

對於獨立編譯方式，在make-standalone-toolchain.sh指令碼中加入–llvm-version=3.1 並在makefile中用<tool-path>/bin/clang and <tool-path>/bin/clang++替換 CC 和CXX 參數。

PS:實際編譯時間發現Clang好像對中文注釋支援不是特別好，比如有端代碼在if(…)後謝了//中文注釋，導致編譯器處理至此處時直接報了異常，刪除注釋後就沒事了…

參考文章：

 

• Producing optimised NDK code for multiple architectures? http://stackoverflow.com/questions/5089783/producing-optimised-ndk-code-for-multiple-architectures
• Is there a way to compile for ARM rather than Thumb in Xcode 4? http://stackoverflow.com/questions/8390606/is-there-a-way-to-compile-for-arm-rather-than-thumb-in-xcode-4

 

對於Android NDK編譯器ARM和Thumb模式的理解