不經一事不長一智...
在ARM上寫了幾年的程式, 今天第一次de到一個關於Portability的bug...
問題出在一個叫libmimic的library裡, 同樣的一段程式, 在x86/Linux上跑, 結果是正確的. 但是在ARM上跑, 畫面就會出現很多奇怪的黑白線條. 原本以為是在ARM上面, floating point變數運算時精確度不足, 所以某個table的值會算錯. 結果trace了半天, 發現裡面所有的table都是正確的, 是到最後產生圖片的的一個填顏色的地方才出錯... 搞了很久才知道原因. 下面這個網址有答案...
http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html
原來在ARM上gcc它似乎是不支援signed char這種type, 像下面這短短兩行code, 在ARM跟x86上結果就不同:
signed char c = 0xFB;
int i = c;
在x86裡, i = 0xFFFFFFFB, 而在ARM裡, i = 0x000000FB
就是這個原因, 造成libmimic做出來的結果, ARM跟x86上會不一樣...
問題出在一個叫libmimic的library裡, 同樣的一段程式, 在x86/Linux上跑, 結果是正確的. 但是在ARM上跑, 畫面就會出現很多奇怪的黑白線條. 原本以為是在ARM上面, floating point變數運算時精確度不足, 所以某個table的值會算錯. 結果trace了半天, 發現裡面所有的table都是正確的, 是到最後產生圖片的的一個填顏色的地方才出錯... 搞了很久才知道原因. 下面這個網址有答案...
http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html
原來在ARM上gcc它似乎是不支援signed char這種type, 像下面這短短兩行code, 在ARM跟x86上結果就不同:
signed char c = 0xFB;
int i = c;
在x86裡, i = 0xFFFFFFFB, 而在ARM裡, i = 0x000000FB
就是這個原因, 造成libmimic做出來的結果, ARM跟x86上會不一樣...
留言