為什么 C “long”數據類型編譯為兩個 MSP430 “.word”？

Question

我明白那個：

char (1 byte)
short (2 bytes)
long (4 bytes)
long long (8 bytes)

但是在將 C 轉換為程序集時，為什么會有額外的.word 0或.word -1 ？

Answer 1

我不確定，但我認為您的問題是您了解其他 CPU（例如 x86）上的匯編程序，並且您假設.word是 32 位字。

但是，像.word和.long以及 C 數據類型 (.) 這樣的匯編語句都是處理器特定的，甚至是操作系統特定的。

示例： long表示 x86-64 Windows 上的 4 個字節和 x86-64 Linux 上的 8 個字節； char在 x86 上表示一個字節，在 MSP320F28x 上表示兩個字節。

在 MSP430 上，語句.word顯然表示 16 位，而語句.long似乎在您使用的匯編程序中不存在。

由於 MSP430 上的 C 數據類型long是 32 位，因此一個long類型的變量需要兩個.word語句（2x16 位）。

Answer 2

C 變量類型的大小特定於作者對該編譯器和目標的選擇。 根據定義，沒有固定的規則。 對於一個（版本）編譯器，一個 int 可以是一個目標的 16 位和另一個目標的 32 位。 對於兩個不同的編譯器，相同的目標一個可以選擇 16 位另一個 32 位。並且大小不必與通用寄存器大小一致 - 作者的選擇。

這就是 stdint.h 的全部意義所在，它最終是編譯器的一部分，並將 8、16、32、64 等大小之間的點與為該目標編譯器選擇的大小連接起來，特定版本的 gcc 用於 x86例如，stdint.h 預計不會與相同版本的 gccs msp430 stdint.h 兼容。

正如您所描述的那樣，這里似乎發生了什么。

char (1 byte)
short (2 bytes)
long (4 bytes)
long long (8 bytes)

匯編語言特定於匯編器，工具，而不是目標，匯編器的作者可以選擇他們選擇的任何語法和助記符等。 與芯片文檔有些相關是理智的道路，但肯定沒有匯編語言的規則。 特別是您如何定義數據項。 在這里，.word 表示 16 位值，.byte 表示 8 位值。

2048 = 0x0000....00800
-2048 = 0xFFFF....FF800

所以如果你剪掉2048的低8位你得到0x00，你砍掉低16你得到0x0800，低32你得到0x00000800，所以

.byte 0x00

.word 0x0800

假設小端：

.word 0x0800
.word 0x0000

8、16 和 32 位

十進制：

.byte 0

.word 2048

.word 2048
.word 0

或者

.word 2048,0

取決於匯編器的語法

對於負版-2048

.byte 0x00

.word 0xF800

.word 0xF800
.word 0xFFFF

對於該數字的 8、16 和 32 位版本

十進制

.byte 0

.word -2048

.word -2048
.word -1

和 long long -2048 將是

.word -2048
.word -1
.word -1
.word -1

或 long long -2048 也可以實現為：

.byte 0
.byte -8
.byte -1
.byte -1
.byte -1
.byte -1
.byte -1
.byte -1

兩者都在二進制文件中生成完全相同的數據。

Answer 3

MSP430 是 16 位 CPU，因此它不支持 32 位數字的硬件。 因此，與任何此類低端 MCU 一樣，它必須依賴軟件庫來處理更大的類型——一旦您使用 32 位算術，編譯器就會在您的代碼中內聯此功能。 這就是為什么 32 位算法在 16 個苦味上效率低下而在 8 個苦味上效率極低的原因。

術語“單詞”相當寬泛，但通常是指 CPU 可以存儲在數據寄存器中並在單個指令中處理的最大數據塊。 這個“字長”使您的 MSP430 成為“16 位”。 在 C 語言中，“單詞”對應於int類型，因此在該系統上將是 16 位。

在 C 中編程時，了解int的大小和范圍非常重要，因為這會影響 integer 常量123的類型，用於隱式提升小 Z157DB7DF530029575518ZD36 等類型的類型等等。

盡管在對嵌入式系統進行編程時，您永遠不應該明確使用這些類型中的任何一種，但您應該使用stdint.h中的類型。