用 objdump 學到的一些東西...

Hacker News 首頁上看到「Hand-optimizing the TCC code generator (briancallahan.net)」這則,原始文章在「Hand-optimizing the TCC code generator」這邊。

主要是在文章內看到 objdump 這個東西,作者用這兩個指令看組語:

tcc -c true.c
objdump -d true.o

另外同樣道理也可以用 gcc -c true.cGCC 轉出來的版本。

倒出來的組語是 AT&T 語法,但我熟悉的是 Intel 語法,對我的直覺上需要習慣... 另外我看了一下 GCC 編出來的組語:

0000000000000000 <main>:
   0:   f3 0f 1e fa             endbr64 
   4:   55                      push   %rbp
   5:   48 89 e5                mov    %rsp,%rbp
   8:   b8 00 00 00 00          mov    $0x0,%eax
   d:   5d                      pop    %rbp
   e:   c3                      retq

第一行的那個 endbr64 指令沒看過,查一下發現原來是 Intel 在 CPU 層設計出來的安全機制,標示這個地方可以被 indirect call 進來:「What does the endbr64 instruction actually do?」。

至於文章裡面主要提到的 mov $0x0, %eax 可以用 xor %eax, %eax 代替 (或是 sub %eax, %eax) 算是很久前就會的東西了...

Google Chrome 對 CPU bug 的 patch

既然有方向了,後續應該會有人去找底層的問題...

先是在 Hacker News 上看到「Speculative fix to crashes from a CPU bug」這個猜測性的修正,這是因為他們發現在 IntelGemini Lake 低功耗晶片組上會發生很詭異的 crash:

For the last few months Chrome has been seeing many "impossible" crashes on Intel Gemini Lake, family 6 model 122 stepping 1 CPUs. These crashes only happen with 64-bit Chrome and only happen in the prologue of two functions. The crashes come and go across different Chrome versions.

然後依照 crash log 猜測跟 alignment 有關,所以決定用 gcc/clang 都有支援的 __attribute__ 強制設定 alignment 來避開,但看起來手上沒有可以重製的環境,所以只能先把實做丟上來...

Branchless UTF-8 解碼器

看到「A Branchless UTF-8 Decoder」這篇,先來回憶一下「非常經典的 UTF-8...」這篇,以及裡面提到的 encoding:

因為當初在設計 UTF-8 時就有考慮到,所以 decoding 很容易用 DFA 解決,也就是寫成一堆 if-then-else 的條件。但現代 CPU 因為 out-of-order execution 以及 pipeline 的設計,遇到 random branch 會有很高的效能損失,所以作者就想要試著寫看看 branchless 的版本。

成效其實還好,尤其是 Clang 上說不定在誤差內:

With GCC 6.3.0 on an i7-6700, my decoder is about 20% faster than the DFA decoder in the benchmark. With Clang 3.8.1 it’s just 1% faster.

而後來的更新則是大幅改善,在 Clang 上 DFA 版本比 branchless 的快:

Update: Björn pointed out that his site includes a faster variant of his DFA decoder. It is only 10% slower than the branchless decoder with GCC, and it’s 20% faster than the branchless decoder with Clang. So, in a sense, it’s still faster on average, even on a benchmark that favors a branchless decoder.

所以作者最後也有說這是個嘗試而已 XD:

It’s just a different approach. In practice I’d prefer Björn’s DFA decoder.

GCC 的警告參數

在「Useful GCC warning options not enabled by -Wall -Wextra」這邊提到 GCC 如果把這些參數放入 -Wall-Wextra 裡會產生出太多的誤判,但有些參數還是很有用。

不過這邊介紹的參數蠻多都需要 GCC 6+ 甚至 GCC 7+,翻了 Ubuntu 16.04 是 GCC 5.4。

這是文章介紹的參數的整理:

-Wduplicated-cond -Wduplicated-branches -Wlogical-op -Wrestrict -Wnull-dereference -Wold-style-cast -Wuseless-cast -Wjump-misses-init -Wdouble-promotion -Wshadow -Wformat=2

另外一個比較特別的問題是,其實愈來愈多專案搬到 clang 上,這幾年可以看出能量的消長蠻明顯的...

Android NDK 宣佈向 Clang 靠攏...

Hacker News Daily 上看到 Android NDK 宣佈向 Clang 靠過去的消息:「Changelog for NDK Build 2490520」。

Android NDK 做為效能的加速手段而使用到 C 或是 C++,所以會使用對應的 compiler suite:

The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++. Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation.

而粗體的兩段則說明了遷移:

PSA: Everyone should be switching to Clang.

以及:

GCC in the NDK is now deprecated.

C 語言的 extern 與 static...

把十年多的 BBS source code porting 到 Ubuntu 上,被迫要用 GCC 4.6 而一路找出來的...

在 BBS 內有這樣的資料結構要處理:

typedef struct p {
    struct p *pointer;
} P;

static P p1 = { &p2 };
static P p2 = { &p1 };

兩個要互指,但在指定 p1 時 p2 還沒有被定義,所以要用 extern 先宣告:

typedef struct p {
    struct p *pointer;
} P;

extern P p2;

static P p1 = { &p2 };
static P p2 = { &p1 };

這個語法在舊版的 GCC 沒問題 (3.4),但在新版的 GCC 4.6 上不接受這個寫法,會抱怨後面的 p2 實際在宣告是 static,與前面的 extern non-static 不符。

後來在 Stack Overflow 上找到「static extern vs extern static」這篇說明,要先定義 static 再定義 extern:

static P p2;
extern P p2;

這樣寫的原因在原文的下方有說明,所以是 C99 定義的關係?

FreeBSD 10 的改變...

Zite 上看到 FreeBSD 10 的改變:「FreeBSD 10's New Technologies and Features」。

最耀眼的當然是對 GCC 的宣戰達到高潮,第一個將預設編譯器換掉的 major release。同樣的,也把 GNU 的 libstdc++ 換成 MIT license 實作的 libc++。

再來是 ISCBIND 被換掉,改用 Unbound 以及 LDNS

然後 UFS 檔案系統可以透過 growfs(8) 線上長大... XDDD

其他的改善包括了 iSCSI stack 重寫,PF 防火牆可以善用 SMP 資源,以及 ZFS 的更新。等正式出版後應該還是會等到 10.1 再上 production 吧?感覺 compiler 一換不知道會有多少雷啊 XD

FreeBSD 預設的 compiler 從 GCC 換成 clang

FreeBSD 預設的 compiler (/usr/bin/cc/usr/bin/c++/usr/bin/cpp) 從 GCC 4.2.1 換成 clang 了:「Revision 242624」。

目前只有 CURRENT 裡的 amd64 與 i386 版本換過去,如此一來,FreeBSD 10.0 會是第一個使用 clang 作為預設編輯器的正式版本 (看起來不像會 back port 回 FreeBSD 9)。接下來是 Ports 大混戰了,應該會有一卡車的 ports 用 USE_GCC=yes 來解?

從 2009 年的努力到現在三年多了 (參考「[ANNOUNCE]: clang/llvm can compile booting FreeBSD kernel on i386/amd64」這封公告信),離拔掉 GCC 4.2.1 又進了一大步...

FreeBSD 將在 10.0 時將預設編譯器從 GCC 換成 clang

FreeBSD 預定在今年十一月將 amd64 與 i386 版本的 C 與 C++ 預設編譯器從 GCC 4.2.1 換成 clang,也就是下一個 major release (10.0) 就會是預設編譯器:「Clang as default compiler November 4th」。

自從 GCC 決定要換成 GPLv3 後整個計畫才活起來,到現在走了三年,看起來明年應該有機會看到預設是使用 clang 的 FreeBSD?

接下來的工作是解決 Ports 裡面一堆用 clang 編不過的軟體,以目前「Ports and Clang」這邊列出來的數量,看起來把幾個大的傢伙解決掉就差不多了?(不過應該是不怎麼好解,不然這種大目標物應該早就解決了...)

在 Mac OSX 上安裝 GCC

參考「Xcode, GCC, and Homebrew」這篇文章整理的...

先前是裝上面那篇文章作者所整理的 OSX GCC Installer,但在新的 MBA 上面發現 homebrew 會抱怨 Xcode 版本太舊?

後來還是改裝 Apple 提供的 Command Line Tools for Xcode (需要 Apple ID) 就沒問題了。

Update:在 Twitterbcse 提醒標題不對,因為實際上 gcc 指令被 alias 到 llvm-gcc-4.2,這並不是 GCC (只是相容介面,骨子裡還是 llvm),這篇只是講 Mac OSX 上面要怎麼裝 compiler 讓 homebrew 可以用...