經(jīng)歷過2個項目的業(yè)務代碼從X86服務器遷移到aarch64泰山服務器上，以前沒有相關(guān)經(jīng)驗摸索了好久，踩了很多坑，現(xiàn)在遷移工作也差不多收尾了，Taishan服務器上跑比X86的溜多了。寫了一篇代碼遷移經(jīng)驗總結(jié)，歡迎大家參考。

編程語言簡介

按照翻譯方式的不同，高級語言通常可以分為兩類：一類是編譯翻譯，一類是解釋翻譯，分別對應著編譯型語言和解釋型語言。

1.編譯型語言

典型的如C、C++語言，都屬于編譯型語言，源代碼到執(zhí)行的過程概括如圖1-1所示。C/C++編譯好的程序是機器指令，由操作系統(tǒng)加載到存儲器（一般為內(nèi)存）后由CPU直接執(zhí)行。

圖 編譯型語言執(zhí)行過程

基于編譯型語言開發(fā)的應用程序，例如C/C++語言應用程序，其編譯后得到可執(zhí)行程序，可執(zhí)行程序執(zhí)行時依賴的指令是CPU架構(gòu)相關(guān)的。因此，基于x86架構(gòu)編譯的C/C++語言應用程序，無法直接在TaiShan服務器運行，需要進行移植編譯，移植編譯過程中遇到的問題可以參考第2、3章提供的方法解決。

2.解釋型語言

典型的如Java、Python語言，都屬于解釋型語言，源代碼到執(zhí)行的過程概括如圖1-2所示。Java/Python編譯好的程序是平臺無關(guān)的字節(jié)碼，由虛擬機解釋執(zhí)行，虛擬機完成平臺差異的屏蔽。

圖 解釋型語言執(zhí)行過程

基于解釋型語言開發(fā)的應用程序，是CPU架構(gòu)不相關(guān)的，例如Java、Python，將這類應用程序移植到TaiShan服務器，無需修改和重新編譯，按照與x86一致的方式部署和運行應用程序即可。

Java應用程序jar包內(nèi)，可能包含基于C/C++語言開發(fā)的so庫文件，這類so庫需要移植編譯，移植編譯so庫遇到的問題可以參考第2、3章提供的方法解決，使用編譯得到的so庫重新打包jar包。

準備工作

C/C++程序移植需要安裝編譯器，推薦使用gcc7.3及以上版本（最低不低于4.8.5），下載安裝參考鏈接:

• gcc7.3版本下載地址：

  http://ftp.gnu.org/gnu/gcc/gcc-7.3.0/

• 安裝步驟參考：https://gcc.gnu.org/install/

移植相關(guān)問題處理-編譯腳本移植類問題

1.1 -m64編譯選項

現(xiàn)象描述

告警信息：gcc:error: unrecognized command line option ‘-m64’

可能原因

-m64是x86 64位應用編譯選項，m64選項設(shè)置int為32bits及l(fā)ong、指針為64 bits，為AMD的x86 64架構(gòu)生成代碼。在ARM64平臺無法支持。

處理步驟

將ARM64平臺對應的編譯選項設(shè)置為-mabi=lp64。

1.2 char數(shù)據(jù)類型的符號

現(xiàn)象描述

告警信息：warning:comparison is always false due to limitedrange of data type

可能原因

char變量在不同CPU架構(gòu)下默認符號不一致，在x86架構(gòu)下為signed char，在ARM64平臺為unsigned char，移植時需要指定char變量為signed char。

處理步驟

在編譯選項中加入“-fsigned-char”選項，指定ARM64平臺下的char為有符號數(shù)。

源碼修改類問題

2.1 代碼中匯編指令需要重寫

現(xiàn)象描述

ARM的匯編語言與x86完全不同，需要重寫，涉及使用嵌入?yún)R編的代碼，都需要針對ARM進行配套修改。

處理步驟

需要重新實現(xiàn)匯編代碼段。

示例：

在x86架構(gòu)下：

在ARM64平臺下，使用gcc內(nèi)置函數(shù)實現(xiàn)：

2.2 替換x86 CRC32匯編指令

現(xiàn)象描述

編譯錯誤：unknownmnemonic `crc32q\' -- `crc32q (x3),x2\'或operand 1 should be an integer register -- `crc32b (x1),x0\'

或unrecognizedcommand line option ‘-msse4.2’。

可能原因

x86使用的是crc32b和crc32q匯編指令完成CRC32C校驗值計算功能，而ARM64平臺使用crc32cb、crc32ch、crc32cw、crc32cx 4個匯編指令完成CRC32C校驗值計算功能。

處理步驟

請使用crc32cb、crc32ch、crc32cw、crc32cx取代x86的CRC32系列匯編指令，替換方法如表所示，并在編譯時添加編譯參數(shù)-mcpu=generic+crc。

示例：

在x86下的實現(xiàn)：

在ARM64平臺下的實現(xiàn)：

2.3? 替換x86 bswap匯編指令

現(xiàn)象描述

編譯報錯：Error:unknown mnemonic `bswap\' -- `bswap x3\'。

可能原因

bswap是x86的字節(jié)序反序指令，需替換為ARM64的rev指令。

處理步驟

x86指令實現(xiàn)的bswap如下：

替換為ARM64指令后如下：

2.4? 替換x86 rep匯編指令

現(xiàn)象描述

編譯報錯：unknownmnemonic `rep` -- `rep`。

可能原因

rep為x86的重復執(zhí)行指令，需替換為ARM64的rept指令。

處理步驟

替換方法如下：

替換前：

替換后：

2.5 快速移植內(nèi)聯(lián)SSE/SSE2應用

現(xiàn)象描述

部分應用采用了gcc封裝的用SSE/SSE2實現(xiàn)的函數(shù)，但是gcc目前沒有提供對應的ARM64平臺版本，需要實現(xiàn)對應函數(shù)。

處理步驟

目前已有開源代碼實現(xiàn)了部分ARM64平臺的函數(shù)，代碼下載地址：https://github.com/open-estuary/sse2neon.git

使用方法如下：

步驟 1 ??將下載項目中的SSE2NEON.h文件拷貝到待移植項目中。

步驟 2 ??在源文件中刪除如下代碼。

步驟 3? ?在源代碼中包含頭文件SSE2NEON.h

----結(jié)束

2.6 弱內(nèi)存序?qū)е鲁绦驁?zhí)行結(jié)果和預期不一致

現(xiàn)象描述

弱內(nèi)存序?qū)е鲁绦驁?zhí)行結(jié)果和預期不一致。

可能原因

ARM64平臺是弱內(nèi)存序，原理如下：

1. 同一份數(shù)據(jù)，在cache里面存在多份，需要CPU之間進行同步。

2. 代碼編寫順序和執(zhí)行順序可能不一樣。

CPU內(nèi)部是流水線執(zhí)行，在執(zhí)行到x=1時，如果x在內(nèi)存，那么CPU就會等待x導入到cache，在等待的過程中如果y已經(jīng)在cache中了，那么CPU會執(zhí)行y=1，這樣就導致后面的語句先執(zhí)行。

對系統(tǒng)的影響

· 影響無鎖編程的代碼。

·?對于使用信號量機制寫的互斥代碼，因為信號量函數(shù)已經(jīng)帶了內(nèi)存屏障的指令，所以無影響。

處理步驟

找到使用無鎖編程的代碼，檢查是否用內(nèi)存屏障指令保證了數(shù)據(jù)的一致性。

使用內(nèi)存屏障指令保證對共享數(shù)據(jù)的訪問和預期一致。

示例：

2.7 對結(jié)構(gòu)體中的變量進行原子操作時程序異常coredump

現(xiàn)象描述

程序調(diào)用原子操作函數(shù)對結(jié)構(gòu)體中的變量進行原子操作，程序coredump，堆棧如下：

可能原因

ARM64平臺對變量的原子操作、鎖操作等用到了ldaxr、stlxr等指令，這些指令要求變量地址必須按變量長度對齊，否則執(zhí)行指令會觸發(fā)異常，導致程序coredump。

一般是因為代碼中對結(jié)構(gòu)體進行強制字節(jié)對齊，導致變量地址不在對齊位置上，對這些變量進行原子操作、鎖操作等會觸發(fā)問題。

處理步驟

代碼中搜索“#pragmapack”關(guān)鍵字（該宏改變了編譯器默認的對齊方式），找到使用了字節(jié)對齊的結(jié)構(gòu)體，如果結(jié)構(gòu)體中變量會被作為原子操作、自旋鎖、互斥鎖、信號量、讀寫鎖的輸入?yún)?shù)，則需要修改代碼保證這些變量按變量長度對齊。

2.8?核數(shù)目硬編碼

TaiShan服務器相對于x86服務器，CPU核數(shù)會有變化，如果模塊代碼針對處理器core數(shù)目硬編碼，則會造成無法充分利用系統(tǒng)能力的情況，例如CPU核的利用率差異大或者綁核出現(xiàn)跨numa的情況。

處理步驟

您可以通過搜索代碼中的綁核接口（sched_setaffinity）來排查綁核的實現(xiàn)是否存在CPU核數(shù)硬編碼的情況。

如果存在，則根據(jù)TaiShan服務器實際核數(shù)進行修改，消除硬編碼，可通過接口（sysconf(_SC_NPROCESSORS_CONF)）來獲取實際核數(shù)再進行綁核。

?

2.9?雙精度浮點型轉(zhuǎn)整型時數(shù)據(jù)溢出，與X86平臺表現(xiàn)不一致

現(xiàn)象描述

C/C++雙精度浮點型數(shù)轉(zhuǎn)整型數(shù)據(jù)時，如果超出了整型的取值范圍，TaiShan平臺的表現(xiàn)與x86平臺的表現(xiàn)不同。

可能原因

在兩個平臺下，是兩套CPU架構(gòu)，其中的算數(shù)邏輯單元的實現(xiàn)可能會有差異，操作系統(tǒng)、編譯器的實現(xiàn)都會有所不同。x86（指令集）中的浮點到整型的轉(zhuǎn)換指令，定義了一個indefinite integer value——“不確定數(shù)值”（64bit：0x8000000000000000），大多數(shù)情況下x86平臺確實都在遵循這個原則，但是在從double向無符號整型轉(zhuǎn)換時，又出現(xiàn)了不同的結(jié)果。鯤鵬的處理則非常清晰和簡單，在上溢出或下溢出時，保留整型能表示的最大值或最小值，開發(fā)者并不會面對不確定或無法預期的結(jié)果。

處理步驟

參考如下數(shù)據(jù)轉(zhuǎn)換的表格，調(diào)整代碼中的實現(xiàn)：

double數(shù)據(jù)向long轉(zhuǎn)換：

double數(shù)據(jù)向unsigned long轉(zhuǎn)換：

double數(shù)據(jù)向int轉(zhuǎn)換：

double數(shù)據(jù)向unsigned int轉(zhuǎn)換：

編譯優(yōu)化項

4.1 gcc編譯器優(yōu)化浮點運算精度

現(xiàn)象描述

編譯優(yōu)化選項設(shè)置-O2級別及以上時，相同的浮點數(shù)乘加運算在x86平臺和ARM64平臺的運算結(jié)果，在小數(shù)點后16位存在差異。

可能原因

ARM64平臺編譯優(yōu)化選項設(shè)置為-O2級別及以上，進行浮點數(shù)的乘加運算(a+=b*c)，運算結(jié)果的精度只能精確到小數(shù)點后16位。在配置-O2選項時，gcc使用融合指令fmadd完成乘加運算，而不是fadd和fmul。

fmadd將浮點數(shù)的乘法和加法看成不可分的一個操作，不對中間結(jié)果進行舍入，從而導致計算結(jié)果有所差別。

對系統(tǒng)的影響

編譯優(yōu)化選項設(shè)置-O2級別及以上時，浮點乘加運算的性能有提升，但是運算的精度受到影響。

處理步驟

添加編譯選項-ffp-contract=off可以關(guān)閉該優(yōu)化。

4.2 增加編譯選項匹配Kunpeng處理器架構(gòu)，提升性能

在編譯時增加編譯選項指定處理器架構(gòu)為armv8，使編譯器按照Kunpeng處理器的架構(gòu)和微架構(gòu)生成可執(zhí)行程序，提升性能。

處理步驟

編譯選項中添加-march=armv8-a。

4.3 增加編譯選項匹配Kunpeng處理器流水線，提升性能

如果使用了gcc 9.1以上的版本，在編譯時增加編譯選項指定使用tsv110流水線，使編譯器按照Kunpeng處理器的流水線編排指令執(zhí)行順序，充分利用流水線的指令集并行，提升性能。

處理步驟

編譯選項中添加 -mtune=tsv110。

轉(zhuǎn)載申明：轉(zhuǎn)載本號文章請注明作者和來源，本號發(fā)布文章若存在版權(quán)等問題，請留言聯(lián)系處理，謝謝。

推薦閱讀

更多架構(gòu)相關(guān)技術(shù)知識總結(jié)請參考“架構(gòu)師技術(shù)全聯(lián)盟書店”相關(guān)電子書(35本技術(shù)資料打包匯總詳情可通過“閱讀原文”獲取)。

全店內(nèi)容持續(xù)更新，現(xiàn)下單“架構(gòu)師技術(shù)全店打包匯總(全)”，后續(xù)可享全店內(nèi)容更新“免費”贈閱，價格僅收188元(原總價290元)。

溫馨提示：

掃描二維碼關(guān)注公眾號，點擊閱讀原文鏈接獲取“架構(gòu)師技術(shù)全店資料打包匯總(全)”電子書資料詳情。