コードサイズが大きい理由の分析

[hiroakitakada]

コードサイズが大きい理由は，積極的にインライン展開を行うことなので，インライン展開を抑止したバージョンを optimize_size ブランチに作成した。これにより，ReleaseFastの場合のコードサイズは，gccで-O2の時とほぼ同等になったが，ReleaseSmallの場合のsample1のコードサイズは，gccで-Osの場合と比べて約3KB（約10%）大きい。サンプル調査した関数のサイズは，gccよりもむしろ小さいので，コードサイズを大きくしている原因が他にも何かあると思われる。他の原因で分析済みのものは以下の通り。

• ext_tskが2回リンクされていた（c_api.ext_tsk と task_term.ext_tsk）。2回リンクしないようにコードを修正済み。
• エラーコードを，Zigのエラー型から，C言語APIでの値に変換するためのオーバヘッド（itronErrorCode自身およびそれを呼び出すためのオーバヘッド）がある。Zigのエラー型の数値を符号だけ変えてリターンするようにしたところ，280バイト小さくなった（用いたコードをコメントとして残してある）。

[hiroakitakada]

追加調査を実施した。

• Zig版のC言語部分（サンプルアプリ，システムサービス）のコンパイルオプションを-Osとするのを忘れていた。これにより，約2.8KB小さくなり，カーネルでgccでコンパイルした場合との差は430バイト程度に縮まった。

• sample1.cを，オーバランハンドラ拡張パッケージのものを使用していた。これにより，オーバランハンドラをサポートしない場合でも，未サポートのエラーを出力する（syslog）分のコードサイズが大きくなっていた。これを，ベースパッケージのsample1.cに差し替えると，約70バイト小さくなり，カーネルでgccでコンパイルした場合との差は360バイト程度となった。

• エラーコードの変換オーバヘッドを除外する際に，符号を反転するのをやめた ところ，さらに40バイト小さくなり，エラーコード変換のオーバヘッドは320バイト程度となった。いこれを見込むと，カーネルをgccでコンパイルした場合との差は，40バイト程度となる。

なお，同じ条件で，ZigのコンパイルオプションをReleaseFast，gccのコンパイルオプションを-O2とした場合には，Zig版の方が230バイト程度小さくなっている。

[hiroakitakada]

さらに，分析を進めて，様々な関数のサイズ比較を行ったところ，おおよそZig版の方がサイズが小さくなっている。ただし，いくつかの関数で，Zig版の方が多くなっており，それらについて，機械語レベルで比較した。

• wai_sem: wobj_make_waitがジェネリック関数になっており，インライン展開を抑止すると型の分だけ展開されるため，インライン展開していない。これがサイズが大きくなっている（1つの）理由と思われる。

• tslp_tsk: Zigは，ARMのpredicated命令の使い方が甘く，サイズが多くなっていると思われる。

• tmevt_down: Zigは少しずつ無駄なコードを出している。当初，ヒープの実装をポインタからインデックスに変えたことが影響しているのではないかと考えたが，分析の結果，その影響はほとんどない（ポインタによる実装をZigでやろうとすると，かなり汚いコードになる）。