こんばんは、川合です。
KOYANAGI, Masaaki さんは 2003/11/20 00:46:57 の「[OSASK 6675] Re
: go_0020b.」で書きました：
>> ・改変前：全部で40219行。このうちの2493行（6.2％）を改変。
>> ・改変後：2493行は1525行にまとまった。これにより圧縮前のサイズで
>> cc1、cc1plus、osaskgoのいずれにおいても、14KB弱のサイズ縮小が
>> みられた。アルゴリズムは前よりもいいので、多分コンパイル速度も
>> 0.1％くらいは改善しているかもしれない。
>実際に go をビルドして時間を測って比較してみれば、分かるのでは
>ありませんか?
うーん、どうでしょう。HDDアクセスのほうのアクセス誤差のほうが
支配的で、0.1％くらいの時間差は検出できない気がします。まあ僕と
しては、小さくなったし、速くなった（はずだ）ということが言いたい
のであって、どれだけ速くなったかということにはとりあえず関心があ
りません。サイズが小さくなっても遅くなったら、効率が上がったとは
言えない場合もありますが、今回はその心配はない、ということです。
もし詳しく知りたい人がいましたら、リリース後にチェックしてみて
ください。
>改良の余地はあると思いますが、時間は非常にかかるように思います。
>もし川合さんが今回のペースで、一人で、
（引用中略）
>ここまでやると、数年かかることになってしまいます。
そのとおりです。
>サイズを小さくするという目的なら、
>
>・どの関数のサイズが大きいかどうかを事前に調べる(Linux なら nm コマンド)
>・ソースコードにはコメントや空行が含まれているので、それを除いた行数を
>調べておく(フリーソフトで実質の行数を数えるものはいくつかあるでしょう。)
>
>というように調査したデータから手を入れる場所を考えて効率的にやるべきだと
>思います。
これも全くそのとおりです。
ええと、僕は「改良の余地がある」と主張したいだけで、改良したい
とまでは思っていないのです。まあなんというか、GCCってだめじゃん
といいたかっただけなので、どうやって改良するか、という点はあまり
心配しないでください。
本気で改良を始めたら、OSASKの開発が止まってしまいます。
I.Tak. さんは 2003/11/20 12:58:03 の「[OSASK 6676] Re: go_0020b.
」で書きました：
> 主にGOのサイズの話でしたが, 速さについても少し触れられていた
>のでユーザとして意見を述べたいと思います。
>
> コンパイル時間で比較すると, bim2binはcc1と肩を並べる長時間を
>食い潰しています。手抜き仕様でディスクを食い潰されるより, 時間
>を食い潰される方が困ります。何度も実行するものですから。コンパ
>イラ本体よりもこちらを先に直すべきだとおもいます。
そうかなあ。＞ディスクよりも時間 osaskgoに限って言えば、1MBを
超えるサイズは時間以上に問題だろうと思うのですが・・・。
もし時間がかかって困るということなら、最後のリリース時以外には
いつも、bim2binのオプションに「maxdis:1k」とでも書いておいてくだ
さい（orgを作るときも、binを作るときも）。見違えるほど速くなりま
す。
もちろん、速度についてやきもきするならこれを直すべきだというの
は、正論だと思います。
> あとobj2bimは「bss領域の0クリアを前提にしたコンパイラもあるか
>らbss領域を0クリアする」ということでしたけど, GOを前提にすれば
>そんなに気を効かせなくてもいいわけですし, こちらも直せばOSASK界
>のほぼすべてのバイナリに益があります。アプリの起動速度や, もし
>かしたらページの利用効率も上がるかも。
GOを前提にすれば、そんなことは気にしないでいいというのは、ごも
っともです。・・・でも、OSASK界のほぼすべてのバイナリに益があり
ます、は違うかもしれません。
そもそも、CやC++のstatic変数は初期値を指定しなければ初期値は全
て0とするのが仕様で、その意味ではCでbss領域が生成されることは普
通ありません（GCCとかは、参照される前に書かれるかどうかを慎重に
チェックして、大丈夫と分かったものだけにbss属性をあたえていた、
はず・・・ということで、多くのケースではうまく判定できず、dataセ
クションになります）。
結局bssを生かせるのはアセンブラ派の僕やI.Tak.さんくらいでしょ
う。しかも僕はASKAでstructすればいいやと思っているので、bssは結
局使いません。ということで、「ほぼすべてのバイナリに益」というの
は違う気がします。
アプリの起動時間が上がるのは多分間違いありませんが、同じバイト
の繰り返しなら、tek0もl2d3もかなりの速度で展開できます。だからあ
まり問題にはならないかもしれません。でも、ページの利用効率upはあ
るかもしれないですね。nasmやASKAで書けば、ですが（Cの場合、初期
化されると分かっているからこそbssに割り振るわけで、結局アクセス
が最初のほうにあることに違いはなく、だから利用効率に差は出ないと
思われます）。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! imasy.org
Homepage http://www.imasy.org/~kawai/