Yoshinori Sato
ysato****@users*****
2003年 10月 9日 (木) 23:44:27 JST
ForkAt Wed, 01 Oct 2003 13:13:33 -0400 (EDT),
Kazu Hirata wrote:
>
> 佐藤様、
>
> > かなり改善されますね。あちこちで使っているので、ものすごく有効だと
> > 思います。
> > これだけ効率が悪いということは、元の書き方がまずいのか。
>
> いえ、そんなことはないと思います。compiler にある程度の期待をしないと
> 高級言語での programming なんてやってられません。:-)
>
> > ここで計算しているのは、ビット列の指定されたビットが存在するオフセット
> > アドレスです。
> > そんな事ならもっと簡単になるだろうと思われそうですが、
> >
> > ・kernel内部でビット列をlongの値として扱うことがある。
> > ・ビット操作命令はbyte長しかない。
> > ・困ったことに変更処理はatomicでないといけない。
> > ・さらに困ったことにbigendian。
> >
> > という制限にまとめて襲われているので、こんな形になっています。
>
> すべての bit 操作が bitop.h の関数経由で行われるというのであればいっそ
> のこと bigendian の調整を外しても動くかもしれませんが、ちょっと恐いで
> すよね。
初期化のときにlongで読み書きしている所があるので、確実にはまります。
> > #atomicじゃなくてもいい方を論理演算にしたら軽くなるかな？
> > #32以下のときば計算減らすとか…
>
> 多少軽くなるかもしれません。というのは、現在、gcc 内部で asm ("...")
> は全て 200 bytes かかるものとして asm の近辺で jmp、bra:16、bra のうち
> どれを使うべきかが計算されています。asm を使わずに論理演算だけでやると
> gcc が全ての命令の長さを知っているので jmp や bra:16 が減り、bra が多
> くなります。実のところ、linker の -relax を使えば違いは起らないはずな
> のですが、h8300-elf-ld の relax 周りの不具合はまだちらほら聞くのでそう
> もいきません。
>
> あと、code の肥大化の原因として考えられるのは asm によくある固定の
> register の使用です。asm の中で %0 の代りに %w0 とかを使うと r1l 等の
> 非 32-bit register も表現することができますが、gcc 内部の仕様に依存し
> てしまいます。これについて何か方針等はございますでしょうか？
8/16bitレジスタを生成できれば余計なclobberが減るので、積極的に使いた
いと思います。
内部仕様への依存は、それを吸収するマクロを定義しておけば大きな問題に
はならないと思いますが。
--
Yoshinori Sato
<ysato****@users*****>