以下圖例取自 CS:APP 第 2 章重點提示和練習
不是所有的位元組合都能表示合理的數字,存取某些位元組合在特定機器上可能會造成嚴重錯誤,此種組合稱作陷阱表示法 (trap representation)。除非使用位元運算或是違反標準其他規定 (如溢位),一般的運算不可能產生陷阱表示法。
C 語言標準明確允許實作自行決定在以下兩種狀況下是否是陷阱表示法:
位元運算會忽略填充位元,因此(等級不低於 unsigned int 的)無號整數可安心使用。為求最大可攜性,位元運算不應該用在有號整數上。
在 C11 規格 6.2.6.2 Integer types 指出
For unsigned integer types other than unsigned char, the bits of the object representation shall be divided into two groups: value bits and padding bits (there need not be any of the latter). If there are N value bits, each bit shall represent a different power of 2 between 1 and , so that objects of that type shall be capable of representing values from 0 to using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified.
uintN_t
和 intN_t
保證沒有填充位元,intN_t
一定是二補數,而且 intN_t
不可能有陷阱表示法,堪稱是最安全的整數型態。實作可能不提供這些型態,不過一旦提供,即保證符合性質。 N1256 7.18.1.1 p1~p3
位移運算子(Shift operator):
x << y
: x 左移 y 位元,左移出的位元會被丟棄,右側會補上 0x >> y
: x 右移 y 位元,右移出的位元會被丟棄。兩種位移:
例:
X = 10100010;
Logical shift: x >> 2
= 00101000
Arithmetic shift: x >> 2
= 11101000
注意位移運算的兩種未定義狀況
The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has a signed type and a negative value, the resulting value is implementation-defined.
算術位移的應用,若要判斷一個 int 型態的變數 n
是否為正數,可用 n >> 31
其等價於 n >=0 ? 0: -1
.
有號數 x 到無號數 (U 結尾) 映射機制:非負數不變為 x,負數轉換為大的正數 (x + 2w,最靠近 0 的負數映射最大,最小的負數被映射為剛好在二補數表達之外的無符號數)。
1000
] ~ 7 [0111
]當無號數與有號數在 C 語言混合在單一表示式時,有號數會被轉換為無號數。在運算子操作時會有些意外的結果。有號數負值會因為轉換成 2 補數後,反而負值會大於正值。因此要注意混用時的運算狀況。
案例:
變數 1 | 變數 2 | 比較結果 | 轉換後 |
---|---|---|---|
0 | 0U | == | unsigned |
-1 | 0 | < | signed |
-1 | 0U | > | unsigned |
2147483647 | -2147483647-1 | > | signed |
2147483647U | -2147483647-1 | < | unsigned |
-1 | -2 | > | signed |
(unsigned)-1 | -2 | > | unsigned |
2147483647 | 2147483648U | < | unsigned |
2147483647 | (int) 2147483648U | > | signed |
一個導致意外結果的案例:
這個例子會造成無窮迴圈,因為 sizeof
會回傳值是 unsigned int 型態,i 變數也會被轉換為 unsigned 的形式,無號數 0 再減 1 就會變為 0xFFFFFFFF
而產生無窮迴圈。
在有號整數上都可能產生陷阱表示法
補充資訊: Writing TMin in C
延伸閱讀: Signed and Unsigned Numbers
在 Whirlwind Tour of ARM Assembly 指出,若 n 是有號 32-bit 整數,那麼 n >> 31
相當於 n >= 0 ? 0 : -1
若 n 是 32-bit 整數,那麼 abs(n)
等同於 ((n >> 31) ^ n) - (n >> 31)
n >> 31
是 0;n ^ 0
仍是 n;n - 0
仍是 n
n >> 31
是 -1;-1
以 2 補數表示為0xFFFFFFFF
;n ^ (-1)
等同於 1 補數運算; 最後再減-1
,得到 2 補數運算的值
例如: unsigned int to unsigned short
Linux 核心原始程式碼存在大量 bit(-wise) operations (簡稱 bitops
),頗多乍看像是魔法的 C 程式碼就是 bitops 的組合。這裡舉個案例,觀察下方 ASCII 字元編號的二進位數值,可知道大寫 'A' 字元的編號是十進位 65,對應於二進位的 100_0001 (請略去底線,只是為了視覺方便),即 2 的 6 次方加 1,那麼小寫 'a' 字母是緊接在大寫 'Z' 字母之後嘛?不是!小寫 'a' 字母的編號是十進位 97,恰好跟大寫 'A' 字母相隔 32,即 2 的 5 次方。
為什麼 ASCII 採用不直覺的設計呢?我們繼續觀察:
從二進位表示法清楚得知,G
和 g
其實相差 1 個位元,換言之,透過 XOR 0010_0000 (或 C 語言的 ^ 32
),就可實作出「大寫字母轉小寫」和「小寫字母轉大寫」的效果。
小提示:在 GNU/Linux, FreeBSD, macOS 上輸入 "man ascii" 即可得到精美的 ASCII 表格,有八進位和十進位表示 (至於為何 UNIX 系統和 C 語言存在八進位表示法,這是另外的故事)。
許多人使用的 vim 啟發自 Bill Joy 在加州大學柏克萊分校就讀時所發展的 vi
編輯器,後者若干特性被 vim 保留,包含使用 hjkl 等按鍵分別表示游標的向左、向下、向上,及向右。採用 hjkl 作為方向鍵的因素是,Bill Joy 當時採用的 ADM-3A 鍵盤沒有獨立方向鍵,不過後續的問題是:既然方向鍵和字母按鍵共用,那為何挑 hjkl,而非 asdf 一類在 QWERTY 鍵盤 橫向連續的按鍵呢?
當我們回顧 1967 年 ASCII 的編碼規範 ISO/IEC 646,可發現前 32 個字元都是控制碼,讓人們得以透過這些特別字元來控制畫面和相關 I/O,早期鍵盤的 "control" 按鍵就搭配這些特別字元使用。"control" 組合按鍵會將原本字元的第 1 個 bit 進行 XOR,於是 H
字元對應 ASCII 編碼為 100_1000 (過去僅用 7 bit 編碼),組合 "control" 後 (即 Ctrl+H) 會得到 000_1000,也就是 backspace 的編碼,這也是為何在某些程式中按下 backspace 按鍵會得到 ^H
輸出的原因。相似地,當按下 Ctrl+J 時會得到 000_1010,即 linefeed
不只是上述 ADM-3A 鍵盤如此,當時大部分的電傳打字機 (teletyper) 也採用相同的慣例。既然相鄰的 H 和 J 都有其對應游標移動的控制碼,也很自然地延伸到 K 和 L 按鍵。
where n is the bit number, and 0 is the least significant bit
Example:
Example:
assuming 16 bit, 2-byte short integer:
assuming 16 bit, 2-byte short integer, two's complement:
The code below shows how to set or clear a bit of an integer.
Output is:
x ^ y
(~x & y) | (x & ~y)
可從 rasterization, equalizer, 和算術去思考。
pipeline-1
pipeline-2
像素處理的程式碼片段:
其中 "Alpha blend components" 可透過改寫為以下:
參考資料:
what (r+1 + (r >> 8)) >> 8 does? - stackoverflow
給定每個 pixel 為 32-bit 的 RGBA 的 bitmap,其轉換為黑白影像的函式為:
人眼吸收綠色比其他顏色敏感,所以當影像變成灰階時,僅僅將紅色、綠色、藍色加總取平均,這是不夠的,常見的方法是將 red * 77, green * 151 + blue * 28,這三個除數的總和為 256,可使除法變簡單
提出效能改善的方案:
16 MB; 表格太大
降到 32 KB 以內; cache friendly
原始程式碼: RGBAtoBW
BMP (BitMaP) 檔是很早以前微軟所開發並使用在 Windows 系統上的圖型格式,通常不壓縮,不像 JPG, GIF, PNG 會有破壞性或非破壞性的壓縮。雖然 BMP 缺點是檔案非常大,不過因為沒有壓縮,即使不借助 OpenCV、ImageMagick 或 .NET Framework 等等,也可以很容易地直接用 Standard C Library 作影像處理。
BMP 主要有四個部份組成:
以下是使用一張 的 BMP 圖片,所得知的檔案資訊:
執行時間:0.034494 sec
RGB 分別都是 8 bit,可以建立三個大小為 256 bytes 的 table,這樣就不用在每次轉 bw 過程中進行浮點數運算。
bw = (uint32_t) (r * 0.299 + g * 0.587 + b * 0.114);
bw = (uint32_t) (table_R[r] + table_G[g] + table_B[b]);
執行時間: 0.028148 sec
使用 pointer 的 offset 取代原本的繁雜的 bitwise operation。
執行時間: 0.020379 sec
將上述 Version 1 和 Version 2合併在一起
執行時間: 0.018061 sec
用 Raspberry Pi 2 測試: