用於不同存儲器尋址方案的C代碼的可移植性

Question

如果我理解正確， 0x10c的DCPU-16規范描述了一個16位地址空間，其中每個偏移地址都是一個16位字，而不是大多數其他存儲器架構中的字節。 這有一些奇怪的后果，例如我想sizeof(char)和sizeof(short)都會返回1 。

在這種不同的內存尋址方案之間保持C代碼可移植是否可行？ 要記住的問題是什么？

編輯 ：也許我應該給出一個更具體的例子。 假設您有一些處理字節流的網絡代碼。 你是通過在每個地址只放一個字節來丟棄你的一半內存，以便代碼可以保持不變，或者你是否通過位移來推廣所有內容以處理每個偏移的N個字節？

edit2 ：答案似乎集中在數據類型大小的問題上，這不是重點 - 我甚至不應該提到它。 問題是如何應對失去用指針解決內存中任何字節的能力。 期望代碼對此不可知是否合理？

Answer 1

這完全可行。 粗略地說，C的基本整數數據類型具有以下特征：

sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (long)

以上並不完全符合規范，但它很接近。

正如awoodland在評論中指出的那樣，你也期望DCPU-16的C編譯器具有CHAR_BIT == 16 。

不假設DCPU-16的sizeof (char) == 2 ，這是一個常見的謬誤。

Answer 2

當你說'失去解決一個字節的能力'時，我認為你的意思是'bit-octet'，而不是'char'。 可移植代碼應該只假設CHAR_BIT >= 8 。 實際上，沒有字節尋址的體系結構通常定義CHAR_BIT == 8 ，並讓編譯器生成訪問該字節的指令。

我實際上不同意建議的答案： CHAR_BIT == 16是一個不錯的選擇。 我更喜歡： CHAR_BIT == 8 ， sizeof(short) == 2 。 在這種情況下，編譯器可以處理移位/屏蔽，就像許多RISC架構一樣，用於字節訪問。

我想Notch將進一步修改和澄清DCPU-16規范; 已經有對中斷機制和進一步指令的請求。 這是游戲的美學背景，所以我懷疑很快會有官方的ABI規范。 也就是說， 有人會在努力！

編輯：

考慮C中的char數組。編譯器在DCPU存儲器的每個本機16位word中包含2個字節。 因此，如果我們訪問第10個元素（索引9 ），則獲取單詞＃[9/2] = 4，並提取字節＃[9％2] = 1。

設'X'為數組的起始地址，'I'為索引：

SET J, I
SHR J, 1    ; J = I / 2
ADD J, X    ; J holds word address
SET A, [J]  ; A holds word
AND I, 0x1  ; I = I % 2 {0 or 1}
MUL I, 8    ; I = {0 or 8} ; could use: SHL I, 3
SHR A, I    ; right shift by I bits for hi or lo byte.

寄存器A保存'字節' - 它是一個16位寄存器，因此可以忽略上半部分。 或者，上半部分可以歸零：

AND A, 0xff ; mask lo byte.

這不是優化的，但它傳達了這個想法。

Answer 3

平等就像這樣：

1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

short類型可以是1 ，事實上你甚至可能想要int類型實際上是1 （我沒有閱讀規范，但我認為正常的數據類型是16位）。 這個東西是由編譯器定義的。

實際上，編譯器可能希望將long設置為大於int即使它需要編譯器做一些額外的工作（比如在軟件中實現加法/乘法等）。

這不是內存尋址問題，而是粒度問題。

Answer 4

是的，它完全可以移植C代碼

在數據傳輸方面，建議打包（或使用壓縮）或發送16位字節

因為CPU幾乎完全只與（游戲）內部設備通信，這些內部設備可能也都是16位，這應該不是真正的問題

順便說一下，我同意CHAR_BIT應為16（IIRC），每個char必須是可尋址的，因此使CHAR_BIT ==8將需要sizeof(char*) ==2這將使其他所有內容過於復雜