我正在為 ARM 和 DSP 代碼重新設計一個 C 專案（我對 ARM、DSP 和 C 比較陌生……談論一場災難……哈哈）并找到了一段代碼，開發人員在其中實作了按位運算。我不確定，但在我看來，他們可能沒有達到他們設定的目標。
他們創建了一個uint32for statuses，我假設其意圖是僅將 32 位用于 32 個bool值，但是他們隨后創建了 32 個變數，每個變數都有他們嘗試創建的變數的位值。這是一個簡短的示例
// The status variable
uint32 STATUSES;
// The hard-coded values
const uint32 ACTIVE = 0x00000001;
const uint32 OPEN = 0x00000002;
const uint32 RUNNING = 0x00000003;
// etc.
然后他們通過執行以下操作繼續檢查STATUSES變數的狀態
if (STATUSES & ACTIVE)
{
// do something
}
我理解按位部分。如果該位處于活動狀態，STATUSES則該值將評估為真，因為僅當兩個位都為真時，按位與才為真。
我的假設是使用按位運算的目的是減少程式的記憶體占用，但是他們創建常量變數來存盤比較值的事實是否首先否定了按位操作的全部意義？
通過創建狀態變數，然后創建常量，它們使用的記憶體不是比僅使用 32 個布林值更多嗎？（bool= 1 位元組，int= 2 到 4 位元組，不確定在這個系統中是什么）
另外，如果他們想使用按位運算并真正節省空間，那么執行以下操作會不會更好
// The status variable
uint32 STATUSES;
// Constants to compare against
uint32 ACTIVE() { return 0x00000001; }
uint32 OPEN() { return 0x00000002; }
uint32 RUNNING() { return 0x00000003; }
etc.
我知道在基于 OOP 的編程中，記憶體分配如下：
- 區域變數（基元）-> 堆疊
- 新關鍵字（物件）-> 堆
- 硬編碼 -> ??? 沒有把握
該代碼用于科學儀器，因此我們需要盡可能快地使用盡可能少的記憶體。他們的方法比我提出的方法呼叫選項快嗎？我寫的硬編碼比較方法是用哪個記憶體存盤的？
任何關于他們為什么會以他們的方式完成實施的見解將不勝感激。
ps 參與創建該軟體的人都不在了。
uj5u.com熱心網友回復：
我認為其意圖是僅將 32 位用于 32 個布林值
不，看起來其目的是創建各種位掩碼。RUNNING = 0x00000003不能被視為布林值，而是由 . 組成的位掩碼ACTIVE | OPEN。
值得注意的是，uint32當 C 標準已經uint32_t在stdint.h. 發明你自己的本地（非）標準只不過是不好的做法——你所獲得的只是降低了可讀性和可移植性。（如果您的代碼庫早于 1999 年，那么這也可以解釋為什么沒有使用標準型別。）
但是，他們創建常量變數來存盤比較值這一事實是否首先否定了按位執行的全部意義？
在嵌入式系統中，數字常量要么與程式代碼一起存盤，要么存盤在一個特殊的.rodata段中——在任何一種情況下，它都會消耗閃存而不是 RAM。如果意圖是從 RAM 執行，那么確實可能沒有保存記憶體。此外，根據硬體的不同，從閃存中獲取值可能比從 RAM 中獲取值更昂貴。
您可能會發現這篇關于 C 變數最終在微控制器中的位置有用的帖子：什么存在于微控制器的不同記憶體型別中？我對 DSP 的經驗也有限，但它們與微控制器的共同點通常比與 PC 的共同點要多得多。您可能希望找到由聯結器生成的“映射檔案”，以詳細查看分配的所有內容的最終位置。
此外，如果您的 DSP 最適合 32 位型別，那么將所有內容分配到 32 位塊中是一種記憶體優化速度。
uint32 ACTIVE() { return 0x00000001; }等是胡說八道，它只會得到優化，0x00000001因為編譯器將行內函式。
請注意，鍵入0x00000001沒有u后綴的十六進制文字是危險的做法。這并不意味著它們是 32 位寬，而是它們的 type (signed) intup to value0x80000000突然變成 type unsigned int。
uj5u.com熱心網友回復：
當您使用全域const值（在宣告中初始化，具有內部鏈接）時，編譯器會將值直接放入代碼中，而不是參考其存盤位置。
只要您不獲取這些變數的地址，就根本不會為它們分配存盤空間。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/485110.html