ARM平台的數據轉換（從x86 / x64開始）

Question

我們已經為x86和x64平台開發了win32應用程序。 我們希望在ARM平台上使用相同的應用程序。 對於ARM平台，字節序會有所不同，即ARM平台通常使用Big endian格式。 因此，我們想在設備的應用程序中處理此問題。

例如//在x86 / x64中， int nIntVal = 0x12345678
在ARM中， int nIntVal = 0x78563412

如何在ARM中為以下數據類型存儲值？

1. 雙
2. char數組，即char chBuffer [256]
3. int64

請澄清這一點。

問候，拉普爾

Answer 1

字節序僅對寄存器<->存儲器操作重要。

在寄存器中沒有任何耐力。 如果你把

int nIntVal = 0x12345678

在您的代碼中，它將對任何Endianess Machine產生相同的效果。

所有架構中的所有IEEE格式（ float ， double ）都是相同的，因此這無關緊要。

在兩種情況下，您只需要關心字節序：

a）將整數寫入必須在兩種體系結構之間傳輸的文件。 解決方案：使用hton*, ntoh*系列轉換器，使用非二進制文件格式（例如XML）或標准化文件格式（例如SQLite）。

b）您強制轉換整數指針。

int a = 0x1875824715;
char b = a;
char c = *(char *)&a;
if (b == c) {
    // You are working on Little endian
}

順便提一下，后面的代碼是一種方便的方式，可以在運行時測試您的耐久性。

數組之類的東西，如果您使用write, fwrite調用方式來轉移它們，除非它們包含整數，否則不會有任何問題：然后看一下上面。

int64_t ：看上面。 僅在需要將二進制文件存儲在文件或強制轉換指針中時才關心。

Answer 2

（謝爾蓋L.，上面說，你taht大多不必關心字節順序，他是對的，至少有1例外：我以為你要的二進制數據從一個平台轉換到另... ）

http://en.wikipedia.org/wiki/Endianness有一個很好的概述。

簡而言之：

• 小字節序表示，最低有效字節先存儲（最低地址）
• 大尾數表示最高有效字節先存儲

數組元素的存儲順序不受影響（但是數組元素中的字節順序當然會受到影響）

所以

• 字符數組不變
• int64-與x86相比，字節順序相反

關於浮點格式，請考慮http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness 。 通常，它似乎遵循與整數格式相同的字節順序規則，但是較舊的ARM平台也有例外。 （我沒有親身經歷）。

一般來說，我會建議，首先對照實驗測試原始類型的轉換。

還請考慮，編譯器可能在結構中使用不同的填充（您尚未解決的主題）。

希望這可以幫助。

Answer 3

在98％的情況下，您無需關心字節序。 除非您需要在不同字節序的系統之間傳輸某些數據，或者讀/寫某些字節序敏感的文件格式，否則您不必理會它。 即使在這種情況下，您也可以編寫代碼，以任何字節序編譯時都能正確執行。

從Rob Pike的“字節順序謬誤”帖子中：

假設您的數據流具有一個低位字節序編碼的32位整數。 提取方法如下（假設無符號字節）：

 i = (data[0]<<0) | (data[1]<<8) | (data[2]<<16) | (data[3]<<24); 

如果是big-endian，請按以下步驟提取它：

 i = (data[3]<<0) | (data[2]<<8) | (data[1]<<16) | (data[0]<<24); 

這兩個片段在任何機器上運行， 獨立於機器的字節順序的，獨立的對齊問題，獨立公正的東西的。 給定無符號字節和32位整數，它們是完全可移植的。

Answer 4

arm是little endian，根據架構有兩個大endian變體，但最好只運行本機little endian，那里的工具和代碼量已在little endian模式下進行了更全面的測試。

如果您進行系統工程，字節序只是系統工程中的一個因素，那么一切都可以解決，不用擔心，不用擔心。 定義您的接口和該設計的代碼。 例如，假設一個處理器的字節序自動導致必須進行字節交換，這是一個錯誤的假設，並且最終會咬你。 您最終將不得不交換偶數次，以撤消導致交換的其他錯誤假設（理想情況下，當然交換0次，而不是2或4或6次，等等）。 如果在編寫代碼時根本不關心字節序，則應獨立於字節序編寫。

由於某些ARM具有BE32（字不變）和較新的ARM BE8（字節不變），因此您必須做更多的工作才能嘗試制造出一些通用的東西，這些東西也試圖補償小的intel，少臂，BE32臂和BE8臂。 Xscale傾向於本機運行大字節序，但也可以以小字節序運行，以減少麻煩。 您可能以為，因為ARM克隆是big endian，那么所有都是big endian，這是另一個錯誤的假設。