Zynq? UltraScale+ ? MPSoC 的核心 ARM?v8 架構(gòu)使系統(tǒng)設(shè)計人員只需極少量修改就可以快速啟用并運(yùn)行現(xiàn)有的 ARMv7 代碼。這種架構(gòu)兼容性使設(shè)計人員可以提高生產(chǎn)力，加速產(chǎn)品上市進(jìn)程，同時減少開發(fā)成本和工程設(shè)計投資。

簡 介

軟件設(shè)計人員運(yùn)用基于新一代 ARMv8 架構(gòu)的賽靈思 Zynq UltraScale+ MPSoC，不僅可以充分利用其先進(jìn)性能，同時還能保持現(xiàn)有軟件投資。

在美國計算機(jī)學(xué)會雜志《美國計算機(jī)協(xié)會通訊全集》的一篇專欄中，Steve Furber 指出，32 位 ARMv7 SoC（例如 Zynq UltraScale+ MPSoC）是最豐富和最受歡迎的 SoC 產(chǎn)品。 另一層隱含的意義是：ARMv7 SoC 的用戶群很大，意味著軟件—— 從簡單的庫、工具一直到完整操作系統(tǒng)—— 的用戶群更為龐大。最近，隨著向 64 位平臺的移植持續(xù)加速，系統(tǒng)設(shè)計人員面臨的問題在于：是花大力氣將現(xiàn)有軟件移植到新架構(gòu)，還是簡單地在新平臺上重新開始開發(fā)軟件。

任何一個具有一定規(guī)模的軟件項(xiàng)目都需要投入大量的人力和軟件架構(gòu)。損失這些投資無論從短期還是長期看對項(xiàng)目都有毀滅性影響。因此，SoC 平臺之間的軟件移植會帶來很大不確定性。移植不當(dāng)很容易導(dǎo)致功能和性能不理想。在這個需要縮減設(shè)計預(yù)算和加速產(chǎn)品上市進(jìn)程的時代，不允許有太多的不確定性。

賽靈思 Zynq 產(chǎn)品組合的最新成員 Zynq UltraScale+ MPSoC 采用新一代 ARMv8 架構(gòu)，其精湛的設(shè)計可解決上述種種問題。ARMv8 采用設(shè)計人員熟悉的 CPU 架構(gòu)和軟件開發(fā)流程，使他們能夠立即著手進(jìn)行項(xiàng)目移植，且可將現(xiàn)有軟件基礎(chǔ)架構(gòu)投資損失降至最低。

ARMv8 通過設(shè)計簡化軟件移植

Zynq UltraScale+ MPSoC 中的 ARMv8 架構(gòu)與前代 ARMv7 架構(gòu)兼容，同時可擴(kuò)展支持最新特性與功能，因此能夠從根本上簡化軟件移植。這樣可創(chuàng)建熟悉的開發(fā)環(huán)境，讓軟件開發(fā)人員在移植過程伊始就能專注于代碼本身。ARMv8 架構(gòu)通過兩種基本方式實(shí)現(xiàn)這種深度兼容：

ARMv8 架構(gòu)支持兩種不同執(zhí)行狀態(tài)：

AArch32，本機(jī) 32 位狀態(tài)

AArch64，本機(jī) 64 位狀態(tài)

AArch64 狀態(tài)中的 64 位 ARMv8 指令集是 ARMv7 中指令集的自然延伸；AArch32 狀態(tài)中的 32 位指令集直接兼容于 ARMv7 中的指令集。

AArch64 執(zhí)行狀態(tài)是本機(jī) ARMv8 執(zhí)行環(huán)境。它支持 ARMv8 架構(gòu)的完整特性集與功能。相反，AArch32 執(zhí)行狀態(tài)提供與 ARMv7 環(huán)境的本機(jī)向后兼容。從軟件執(zhí)行角度來看，該狀態(tài)為本機(jī) ARMv7 環(huán)境。開發(fā)人員可選擇讓代碼在編譯時間內(nèi)在哪種執(zhí)行狀態(tài)下運(yùn)行。正常運(yùn)行時間內(nèi)，CPU 可在 AArch64 和 AArch32 這兩種執(zhí)行方式之間即時切換，以提供軟件所要求的執(zhí)行環(huán)境。這些上下文變化發(fā)生在異常邊界，無需用戶或軟件設(shè)計人員進(jìn)行輸入；32 位代碼和64 位代碼高效并行執(zhí)行。

當(dāng)在 AArch64 狀態(tài)下運(yùn)行時，提供完整的 64 位 ARMv8 指令集。很大程度上，64 位 ARMv8 指令集是ARMv7 中指令集的延伸。只需對指令集在語法和行為上稍加修改，就能支持 32 位指令以及 32 位與 64 位混合寄存器。當(dāng)在 AArch32 狀態(tài)下運(yùn)行時，處理器使用標(biāo)準(zhǔn) 32 位指令以及 32 位寄存器；軟件設(shè)計人員處理指令集的方式與使用其他 ARMv7 處理器時相同。

使用代碼庫

低層裸機(jī)和 RTOS 代碼開發(fā)人員是受低層處理器架構(gòu)差別影響最多的人。當(dāng)開始移植軟件時，最佳方式是啟用編譯器中所有警告和錯誤消息，使用 ARMv8 編譯器重新簡單編譯軟件，不做修改。對這種方式下生成的警告或錯誤信息進(jìn)行分析，這樣軟件開發(fā)團(tuán)隊可以確定哪些錯誤可以忽略，以及哪些需要在移植過程中加以注意。

ARMv8 編譯器本機(jī)支持標(biāo)準(zhǔn)高級代碼，例如 C 和 C++ ；當(dāng)有合適的 ARMv8 板支持包 （BSP） 時，可編譯和運(yùn)行這類代碼。相比之下，匯編代碼時則需要特別注意如何使用代碼。盡管 ARMv8 中依然存在諸多 ARMv7 匯編指令，但是它們的語法或行為存在微秒的變化。有些編碼結(jié)構(gòu)的編譯或行為與 ARMv7 不同，其中包括：硬編碼存儲器位置（ 適用任何軟件移植項(xiàng)目）、對 ARMv7 協(xié)處理器（ 例如 CP15） 和寄存器名稱的訪問，以及數(shù)據(jù)對齊。由ARM 發(fā)布的ARM? Cortex ? -A 程序員ARMv8-A 使用指南 （DEN0024A） 對移植問題進(jìn)行了詳細(xì)的分析。

我們不妨看看容易移植的代碼實(shí)例以及會產(chǎn)生問題的代碼，這樣有助于我們從概念上討論架構(gòu)之間的區(qū)別。

有的指令只需很少的操作就可從 ARMv7 轉(zhuǎn)換為 ARMv8 語法，ADD 指令就是個很好的例子。ARMv7 中的寄存器的命名方案為 Rn，其中 n 是寄存器的個數(shù)。這樣命名直接了當(dāng)，因?yàn)?ARMv7 中所有寄存器都是 32 位。在 ARMv8 中，寄存器既可以是 32 位也可以是 64 位。32 位寄存器的命名方案為 Wn，而 64 位寄存器的命名方案則為 Xn。這樣軟件設(shè)計人員必須根據(jù)正在考慮的操作對象的尺寸，對現(xiàn)有的代碼進(jìn)行評估并適當(dāng)?shù)匦薷摹Ｒ姳?1。

移植 ADD 這樣的指令不僅需要評估代碼的最終用途，還要相應(yīng)地改變寄存器名稱。根據(jù)整個代碼庫的復(fù)雜程度，甚至可以自動執(zhí)行移植。

其他情況下，例如訪問 ARMv7 協(xié)處理器，可能需要更全面的代碼分析。這種分析被認(rèn)為是最佳方法，因?yàn)閰f(xié)處理器控制很多針對整個處理器的系統(tǒng)級屬性和功能，而且控制協(xié)處理器是針對ARMv7 的常見操作。

當(dāng)在 AArch64 狀態(tài)下運(yùn)行時，無法直接訪問 CP15 寄存器，因?yàn)樗鼈儾辉?ARMv8 架構(gòu)中。當(dāng)在 AArch32 狀態(tài)下運(yùn)行時，則可通過概念協(xié)處理器訪問它們。這是由 AArch32 執(zhí)行狀態(tài)提供的結(jié)構(gòu)，用于為原有的 32 位代碼提供一致的執(zhí)行環(huán)境。

例如，假設(shè)一個程序需要 Main ID Register —— 協(xié)處理器 CP15 中 c0 寄存器的一部分—— 的內(nèi)容。使用 ARMv7 的專用 MRC 指令和 ARMv8 的 AArch32 執(zhí)行狀態(tài)訪問這個值：

MRC p15， 0， r1， c0， c0， 0

直接在 AArch32 狀態(tài)運(yùn)行的原有代碼無需修改；但移植到 AArch64 狀態(tài)的代碼需要根據(jù)新架構(gòu)的要求進(jìn)行調(diào)整。

在本機(jī) AArch64 執(zhí)行狀態(tài)下，Main ID Register 值位于名為 MIDR_Eln 的新專用寄存器中。該寄存器可方便地通過系統(tǒng)寄存器訪問指令來訪問。

MRS：

MRS x1， MIDR_EL1

因此，開發(fā)人員應(yīng)該知道這種專用操作和調(diào)用，以便相應(yīng)地更改匯編指令。同樣，這是單行修改，不會影響周圍軟件代碼的整體結(jié)構(gòu)。此外，還要注意源寄存器和目標(biāo)寄存器都是本機(jī) 64 位寄存器，與 64 位架構(gòu)的其余部分一致。

對基于 Linux 操作系統(tǒng)的軟件而言，移植條件通常比 RTOS 或裸機(jī)代碼更直接。底層的 Linux 操作系統(tǒng)可通過抽象消除很多底層硬件中的差異。大多數(shù)情況下，只需使用 64 位 Linux 編譯器進(jìn)行重新編譯就可以讓代碼運(yùn)行在 64 位 Linux 上。賽靈思 PetaLinux 工具可針對64 位 Linux 環(huán)境在本機(jī)中整合和重新編譯代碼，從而自動執(zhí)行該過程。

其他情況下，開發(fā)人員可能需要使代碼保持為 32 位二進(jìn)制數(shù)。軟件可能需要與只有 32 位形式的外部庫鏈接；或者包含需要花時間轉(zhuǎn)換的 32 位匯編代碼。移植這類軟件時，可利用很多現(xiàn)代 Linux 版本中都有的 multiarch 或 multib 功能實(shí)現(xiàn)顯著加速。盡管不是完全一樣，但這些經(jīng)?？梢曰Q使用。

Multiarch 是一種系統(tǒng)和文件系統(tǒng)布局的配置方法，以便運(yùn)行 32 和 64 位動態(tài)鏈接程序。原來的32 位 ARMv7 Linux 程序無需修改，可直接導(dǎo)入，并與新的 64 位程序共存。該功能可用來快速建立并運(yùn)行系統(tǒng)，同時移植特定的 32 位應(yīng)用程序并針對底層 64 位架構(gòu)進(jìn)行微調(diào)。

支持Multiarch 的版本將 32 位和64 位庫納入相同 Linux 文件系統(tǒng)中，以實(shí)現(xiàn)這種兼容性。當(dāng)執(zhí)行 64 位應(yīng)用時，使用本機(jī) 64 位庫；32 位應(yīng)用則使用 32 位庫。

創(chuàng)建和維護(hù) multiarch 操作系統(tǒng)需要投入不少時間。幸好，開源項(xiàng)目，例如 Yocto Project、Canonical 和 Linaro，提供易于集成的內(nèi)容。Yocto Project 提供完整的端對端構(gòu)建系統(tǒng)；Canonical 和 Linaro 提供現(xiàn)成可用的參考文件系統(tǒng)，使開發(fā)人員快速取得進(jìn)展。賽靈思答復(fù)66636 詳細(xì)介紹了如何在 ZCU102 評估平臺上集成 Ubuntu Core 14.04 文件系統(tǒng)。

默認(rèn)情況下，這些 multiarch 文件系統(tǒng)只使用 64 位應(yīng)用程序。由于它們基于 dpkg 管理工具，因此只需簡單的命令行接口即可添加更多架構(gòu)：

# dpkg -add-architecture armhf

配置 dpkg 工具以支持 32 位架構(gòu)（ 例如 armhf），然后，使用更高級的封裝管理工具，例如 apt-get，就像在 Linux 的 Intel x86 兼容版本上一樣。

對于有些系統(tǒng)來說，通過 multiarch 在 64 位主機(jī)上運(yùn)行現(xiàn)有的 32 位應(yīng)用程序就足夠了，無需其他工作。對于其他系統(tǒng)，multiarch 可起到節(jié)省時間的作用，同時還要對軟件協(xié)議棧的其他部分進(jìn)行微調(diào)，并針對底層 64 位架構(gòu)和操作系統(tǒng)來優(yōu)化它們。

總 結(jié)

ARMv8 為軟件開發(fā)人員提供很多性能、安全和架構(gòu)方面的新功能，但是，如果軟件開發(fā)人員因擔(dān)心丟掉現(xiàn)有的軟件架構(gòu)而不愿意使用它，那么這些新功能也就無用武之地。ARMv8 可從硬件和軟件接口實(shí)現(xiàn)處理器架構(gòu)的自然演進(jìn)，從而消除這種顧慮。將開發(fā)人員熟悉的指令集實(shí)現(xiàn)自然演進(jìn)，以此簡化低級代碼的移植。此外，還可以回退到 AArch32 狀態(tài)，這樣開發(fā)人員就能夠快速運(yùn)行現(xiàn)有的32 位代碼，以最少的時間和精力在新硬件上評估代碼。最后，multiarch Linux 允許將一些代碼不經(jīng)任何修改直接運(yùn)行，這樣就可以顯著減少整體系統(tǒng)集成。ARMv8 處理器，例如 Zynq UltraScale+ MPSoC 允許開發(fā)人員利用新一代功能并保持原有軟件投資。