爲什麼編程語言嚴格依賴於原始類型，並且彙編更靈活？

Question

爲什麼我們沒有4位大小的數據類型？如果我們如此傾向，爲什麼我們不能製造它們呢？我已經看到了比特場，但是我聽說它們不能攜帶，也許還沒有被使用？我認爲這是機器如何解釋鑽頭位置的位置值的結果。 （big-endian，little-endian）

typedef struct 
{ 
    int b1 : 1; 
    int b2 : 1; 
    .. 
    .. 
    .. 
    int b32 : 1; 
} bitfield32; 

我們也不能創建比任何原始類型都大的比特字段。那麼爲什麼這些限制？它可以在組裝中完成嗎？

Answer 1

爲什麼我們沒有4位大小的數據類型？

誰說的？ Intel 4004 CPU有4位寄存器和4位存儲器操作數。由於直接支持4位數據類型，因此這種CPU很自然。

Intel 8051 CPU可以直接處理單個位的內存，所以你可以有1位變量。

這些只是CPU的兩個例子，其中數據類型可以非常小，比現在無處不在的8位字節小。

爲什麼我們不能讓他們如果我們這麼傾向？

我們可以。您可以創建一個直接支持4位數據類型的CPU，也可以將4位變量模擬爲較大變量的一部分。

您可以將2個4位變量打包爲8位字節。這種方法的問題是你需要使用更多的指令從8位寄存器或存儲單元中提取4位（你需要一個移位和掩碼（AND）指令），同樣你需要更多指令來正確保存4位位值轉換爲8位字節的一半（加載8位，清除4位二分之一的舊值（帶掩碼/ AND），轉換新值，將其與其餘值組合並保存）。顯然，這會對你的程序代碼大小和速度產生負面影響。此外，4位變量不是很有用，因爲它們可以保存的信息很少。由於這些原因，對較小類型的模擬不太流行。

我已經看過位字段，但我聽說他們不是可移植的，也許還沒用過？

它們被使用。它們的存在恰恰是因爲在一些（但不是全部）應用程序中它們非常有用。如果你有很多短變量，把它們中的幾個變成一個字節或一個機器字可能是有利的，從而減少了內存浪費。

它們不是完全不可移植的。它們在C和C++中的可移植性有限，因爲語言標準沒有精確定義更大數據類型中位域的位置和佈局。這是爲了讓編譯器編寫者在使用位域時最有效地利用CPU功能而完成的。

6.7.2.1 Structure and union specifiers從1999年C標準的clause 10這樣說：

實現可分配任何可尋址存儲單元，大到足以容納一個位域。如果剩餘足夠的空間，緊接在結構中的另一位字段之後的位字段應被打包到相同單元的相鄰位中。如果剩餘空間不足，則將不適合的位字段放入下一個單元或與相鄰單元重疊是實現定義的。位單元內的位字段的分配順序（從高位到低位或從低位到高位）是實施定義的。未指定可尋址存儲單元的對齊方式。

 

我覺得這是機器如何解釋的位位置的位值的結果。 （big-endian，little-endian）

是的，那是原因的一部分。但這絕對不是專門針對位域的。常規的非比特字段類型也有這個問題。

我們也不能像這樣做比任何原始類型都大的位域。那麼爲什麼這些限制？它可以在組裝中完成嗎？

如果您的C（或C++）編譯器（或解釋器）可以模擬比CPU直接支持的類型更大的類型，那麼您甚至可以擁有256位的位域。但是，如果CPU直接支持的最大類型是32位，這意味着使用更大的類型（不管是否是位域）類似於128位的類型將會產生更多的代碼和某些性能因爲單個CPU指令（或其中的幾個指令）將不能處理這些大數據值。您需要更多指令和更多時間來執行這些額外的指令。

是的，這可以在裝配中完成。只要你願意編寫代碼並使其工作，任何事情都可以在彙編中完成。 :)

Answer 2

爲什麼我們沒有4位大小的數據類型？

因爲像x86這樣的現代處理器可以工作的最小數量是8位。

爲什麼我們不能讓他們如果我們這麼傾向？

你可以，但他們會慢得多，因爲你不得不做更多的工作，因爲處理器不支持它。

它可以在裝配中完成嗎？

裝配只是一堆處理器的指令，所以如果你的處理器支持它，你只能有效地完成它。

如果你真的學習數字設計，這很有意義;在那之前，你必須將這些限制視爲理所當然。