Yoshinori Sato
ysato****@users*****
2003年 10月 9日 (木) 23:44:27 JST
At 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*****>