MulderPatch 1.2 release
星期天花了一點時間改了一下 MulderPatch 的程式，釋出 1.2 更新版。同樣地，在 ppc 上正常運作的功能移植到 intel 機器上就爛了。每次要編成 universal binary 總是要費很多功夫，花了我整個晚上，因為我並沒有 intel 的機器可以測試。
寫 MulderPatch 的過程中，我更加體驗到 ppc 架構比起 intel x86 實在是合理許多。先不提 register 的數量優勢，在 ppc 上的 BOOL 是 4 bytes ，intel 上只有 1 byte。看起來 intel 比較節省記憶體，但是當 未知回傳型態的 objective-C method 回傳 BOOL 時，intel 版就必須做很累贅的指標轉型或者 & 0x000000FF （硬降轉 BOOL 會編不過）。應該說，big endian 逼得 ppc 不得不使 BOOL 是 4 bytes，但是這樣設計真的很方便啊～ 可惜 ppc 不爭氣。為什麼不是 ppc 超快超涼超便宜，
“這就有點怪了，通常是語言實作底層 native type。而且在相同語言底下，不同平台有那麼大的差異倒是蠻好奇的。以前用 virtual c++ 的經驗，bool 實際上弄出來的 byte size 就是 4。
---jclin. 3/19, 2007另外雖然是 x86 CISC 架構，以先前反組譯 windows 程式的經驗，絕大部份的程式都會直接使用 EAX, EBX, ECX… 等等這些 32 bit register 反而不太會像一般寫組語那樣還用 AX, AH, AL 等等；或是類似 RISC load/store 那樣，也很少看到如 ADD DWORD PTR [0x12345678], 0xff 這種包含 load, add, store 一次做很多的指令。個人是覺得 compiler 也是朝 RISC 和簡單化這種方向在走，而且 x86 CPU 內部的微指令集就像是 RISC 那樣；太複雜化的指令 compiler 最做最佳化會很難，CPU decode/execute 效率可能也不高。所以用 32bit 的指令雖然佔空間，但是效率上卻可能比 16bit 好，例如 MOV EAX,1; INC EAX 語 MOV AX,1; INC AX 這樣都是同樣目的。
另外 intel 畢竟是全球半導體跟微處理機的龍頭，靠他的製程技術和微處理器架構演變出來的 CPU，也不能說是 PPC 不爭氣。另外我是覺得 x86 並非不好的架構，只是 x86 指令寫得好也是有他的優點，例如寫成 32bit 模式的指令。我覺得 x86 指令雖然複雜，但是可以想成是一種壓縮後的資料，經過 fetch/decode 後可以變成微指令，然後透過 superscaler、out-of-order… 等等可以得到更好的執行效率。此外另外一個觀點是，因為是複雜指令，所以相同 instruction cache size 下，x86 的指令是否應該比 RISC 在 cache 內所儲存的實際運算量還多？相同的 size 下，x86 decode 出來的 micro code 做得比 RISC 還多事情，是否也能減少 cache miss 來得比 RISC 好？
此外 x86 的 MMX, SSE, SSE2 而寫出來的最佳化程式，像是在 multimedia 就很常用，至少 LAME 裡面就有；但卻沒有看過 LAME 有 AltiVec 的 FFT/iFFT 版本（很久之前看的，不確定有沒有加了）。大概也是因為 x86 CPU 市佔率高，很多 open source 軟體會有人幫忙寫 MMX/SSE/SSE2 指令集來最佳化。所以魚幫水、水幫魚，有些軟體在 x86 上就是效率比較高。像是 LAME 在 PPC 上可能壓縮 MP3 就會比 iTunes 來得慢，iTunes 也是因為有 Apple 自己的 AltiVec library 優化，但並非大多數軟體都會用 Apple AltiVec lib。另外因為 virtualization 的關係，總是要相同的指令集，x86 有 windows/linux/blah blah。所以我個人覺得 x86 transition 比留在 ppc 上來得好。:P”