嘘でもハッタリでもいいからinline対応しとけ

以前もちょろっと書いたけど、最近、ちょっとずつだけどGCCのバックエンド部分のコードを読んでたりする。ちなみに、nsawa氏のC33用のものが量が少なくて読みやすいと思う。アーキテクチャ的にも簡単だし。
で、フラグレジスタの動作の記述方法がわからなくて悩んでるところ。もうちょい悩みそう。
内部が理解できれば、すんなり理解できるんだけど、この場合中身というのは、すなわち、RTL最適化の部分であって、それはそれは量が多い。
で、まあ、そんな感じで、また、「GCCのソースわかんないよー」状態になってんだけど、しかし、これは、量が多いだけでなくて、やっぱりGCCのコードは読みにくいんじゃなかろうか、と思う。と、書くといいわけっぽいけど、それでも、やっぱりカーネルのソース読んでるときに比べるとGCCのコード読んでるときっていうのは常にもやがかかった感じになってしまう。
そこらへんの原因は、関数の長さがちょっと長かったり、いっこのif文がちょっと画面からはみでるくらいの大きさになったりしてたりするような、「息継ぎする間もないコード」にあるように感じる。

でも、そういうのって、結局のところCにインライン関数が無いのが原因だよなぁ…と、思う。
GCCもプログラムの構造に問題があるわけではないのだ、むしろ、構造はきれいだと思う。ただ、ちょっと、ifの条件がマクロが&& ||で連続してたりするとか、そういう細かいところがわかりにくくなっているだけなのだ。もし、そういう部分が、関数として切り出されていたら、非常に読みやすいコードになっているだろうと思う。
実際、Linuxカーネルのコードが読みやすい理由のひとつに「inlineを有効利用している」と、いうのがあげられるだろう。

で、よーするに、何がいいたいかというと、「プログラミング言語は、なにがなんでもinline関数は書けるようにしとかないといけない」、ということだ。
もし、インライン関数が書けないようであれば、効率という面で、プログラマに一種のプレッシャーを与えることになってしまうだろう。で、その結果として、効率重視と称して、GCCのように見にくいコードが生まれてしまったとしたら、それは、やっぱり、プログラマの責任だけでなく、言語設計者の責任でもあると思う。
Python使いにいわせれば、「見にくいコードを書くように向かわせる言語は悪だ」と、いった感じで。
んで、ここで重要なのは、プログラマにプレッシャーを与えないようにインライン対応するのであって、効率のためではない、と、いうこと。だから、バリバリの動的言語で、インライン展開なんか不可能そうな場合であったとしても、言語仕様としてとりあえず、実際に展開するかどうかにかかわらず、プログラマに安心感を与えるためだけに関数にインライン属性を付けれるようにしとくのだ。
で、その部分は「これは今は正しく動作しませんが、将来実装される予定です」とかにしておく、と。そうすれば、プログラマも「あー、将来実装されんだったらいいかなー」とか、そういう気分になって、効率悪くなったとしても分かりにくい部分は適当に関数分けしてくれるんじゃないかなー、とか、思う。

と、いうはなし。
あと、こういう観点でいうと、OCamlとか、DMDなんかのようにインラインを明示できないっていうのは効果薄いんじゃないか、と思う。ほら、どうせ、CPU効率なんて何の意味もないくらいしか変わらないし。それだったら、いっそ、「俺はこれをインライン展開してる！！」て、気分になれたほうがいいんじゃないだろうか。