Kazu Hirata
kazu****@cs*****
2003年 10月 2日 (木) 02:13:33 JST
Fork佐藤様、
> かなり改善されますね。あちこちで使っているので、ものすごく有効だと
> 思います。
> これだけ効率が悪いということは、元の書き方がまずいのか。
いえ、そんなことはないと思います。compiler にある程度の期待をしないと
高級言語での programming なんてやってられません。:-)
> ここで計算しているのは、ビット列の指定されたビットが存在するオフセット
> アドレスです。
> そんな事ならもっと簡単になるだろうと思われそうですが、
>
> ・kernel内部でビット列をlongの値として扱うことがある。
> ・ビット操作命令はbyte長しかない。
> ・困ったことに変更処理はatomicでないといけない。
> ・さらに困ったことにbigendian。
>
> という制限にまとめて襲われているので、こんな形になっています。
すべての bit 操作が bitop.h の関数経由で行われるというのであればいっそ
のこと bigendian の調整を外しても動くかもしれませんが、ちょっと恐いで
すよね。
> #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 内部の仕様に依存し
てしまいます。これについて何か方針等はございますでしょうか？
Kazu Hirata