gcc 読み会中

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

昨日の夜から学生と一緒にgcc compilerを読んでます。というか、
自分でがんがん追っているだけなんだが。version 4.x は 3.x と、
全然違う。まったく違うじゃん。

確かに Recursive Decent に変わってましたが、その分、読みにく
くなっている。けど、フローは読みやすい。

パーサは、だいたい終ったので、これから、コード生成部分に突入
するらしい。もちろん、全部読んでいるわけではないけどね。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

ko...@ie.u-ryukyu.ac.jpさん:

> 昨日の夜から学生と一緒にgcc compilerを読んでます。というか、
> 自分でがんがん追っているだけなんだが。version 4.x は 3.x と、
> 全然違う。まったく違うじゃん。
>
> 確かに Recursive Decent に変わってましたが、その分、読みにく
> くなっている。けど、フローは読みやすい。

へー。なんでRecursive Descentに変えたの? 久野

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

In article <0612160815...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes

> > 確かに Recursive Decent に変わってましたが、その分、読みにく
> > くなっている。けど、フローは読みやすい。
> へー。なんでRecursive Descentに変えたの? 久野

速度的に全然違うそうです。まぁ、テーブル読み込みのインタプリタ
と比べても仕方ないだろうとは思うんだけど。

後は、想像ですが、
non-terminal: sub { i=1; } sub1 { i=2; } ;
| sub { i=2; } sub2 { i=4; } ;
みたいな記述だと、何がどう実行されるのかわかりづらく、
メンテナンス性が悪いんでしょう。

結局、yacc って何だったんだとは、今になって思う。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

ko...@ie.u-ryukyu.ac.jpさん:
> 速度的に全然違うそうです。まぁ、テーブル読み込みのインタプリタ
> と比べても仕方ないだろうとは思うんだけど。

速度が問題になるのかなあ。CPUがこんなに速くなってるのに。

> 後は、想像ですが、
> non-terminal: sub { i=1; } sub1 { i=2; } ;
> | sub { i=2; } sub2 { i=4; } ;
> みたいな記述だと、何がどう実行されるのかわかりづらく、
> メンテナンス性が悪いんでしょう。
> 結局、yacc って何だったんだとは、今になって思う。

いや、初心者がささっと作れるようにするのにはLALRパーサジェネレー
タがいいと私は思ってますよ。でもプロ(級)がメンテするGCCならツー
ル入ってるより全部コードの方が楽なのかなと想像します。もう構文解
析なんてどうでもいいからツール捨てるために書き直したとか。

Cの再帰下降解析…あんまり書きたくないな… 久野

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

In article <0612161601...@utogw.gssm.otsuka.tsukuba.ac.jp>, ku...@gssm.otsuka.tsukuba.ac.jp writes

> > 速度的に全然違うそうです。まぁ、テーブル読み込みのインタプリタ
> > と比べても仕方ないだろうとは思うんだけど。
> 速度が問題になるのかなあ。CPUがこんなに速くなってるのに。

lookup table だと分岐予測を不可能にするので、その意味でも
思ったより、影響します。

ただ、時間がかかるのは最適化の方なので、パーサが速くなっても
ねぇ。と普通は思うんだけど... 実は、そうではないです。

最近は、ソースが結構巨大。特に、

include ファイルがでかい

つまり、ソース自体が小さくて、最適化もさしてかからないんだが、
無駄な include をがんがん読む。この部分の速さは重要です。
特に、

C++

で顕著です。C++ でなくても、オブジェクト指向に書くと構造体と
クセサが増えるし。あと、inline ですね。使うか使わないかに
変わらず、include するしかないので。

gcc 4.0 は、preprocessor builtin でもあるので、その効果もあり
構文解析が速くなっているようです。

C++ のコンパイルの地獄の遅さに閉口している人は結構いると思う。

> いや、初心者がささっと作れるようにするのにはLALRパーサジェネレー
> タがいいと私は思ってますよ。でもプロ(級)がメンテするGCCならツー
> ル入ってるより全部コードの方が楽なのかなと想像します。もう構文解
> 析なんてどうでもいいからツール捨てるために書き直したとか。

LALRかどうかは、BNFからはわかりませんよね。あと曖昧性を自明
に解決しないので、エラーが出たと言って騒ぐ初心者が後をたたな
いという致命的な欠点があります。無理して取ると、汚くなるし。

さらに、構造体の構文解析とかをyaccでやらせてみるとわかるんですが、
文法の自由度が高すぎて、つい、top down に書いて、わけがわからなく
なってしまう。再帰下降法の方が、bottom upに書くしかないので、
文法構築のとっかかりが良いようです。

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

今日は、RTLの生成部分をgdbでtraceしながら。Emacs が gdb mode
に入らない。gud モードとかになるが、ソースを表示してくれない。

screen -L でlogを取りながら読むんだが uxterm のカーソルでも
戻っても上が見れない。script の方が良かったか。そもそも、p *
tree とかやると、100行以上でるので役にたたないし。bit filed
で色んなものが定義されているのが裏目にでてるな。

bitfield に関しては、やっぱり苦労するらしく、そここに「ここ
はbitfieldがあるからうんぬん」のコメントがたくさんある。なく
しちゃえば良かったのにね。

　 execute_pass_list (all_passes);

で、all_passes に入っているroutineが順々に、構文木に適用され
ていく。構文木はいじらずに、それにくっついているRTLを変更し
ながら最適化していく感じです。SSA (単一代入表現)は、構文木の
一部として実現されているわけね。

expr.c の expand_expr_real_1() で、ほとんど生成されてしまう。
*.md から、insn_*. c が4つ生成されるのか。

最適化は読みませんでしたが、まぁ、parse から fprintfで命令が
印刷されるところまで読みました。あぁ、tokenizer はすっとばし
たな。

読んだファイルと、テストプログラム

http://www.ie.u-ryukyu.ac.jp/%7Ekono/lecture/compiler/gcc/gcc.log

gdb のlog

http://www.ie.u-ryukyu.ac.jp/%7Ekono/lecture/compiler/gcc/gdb.log

emacs 操作のlogがあれば、完璧な再現になりますが、そんなもの
はありません... text base で emacs を操作してlog取ればよか
ったな。今度は、そうしよう。

あと、「GCC解読室Wiki」なるものがあるのね。

http://wikiwiki.jp/aloha/?FrontPage