VC++でインラインアセンブラを使ってて思うのですが、
コンパイラが吐き出すコードはeax,ecx,edxが
主に使われているようなのですが、
ebx,ediなどを使うことに何か問題があるのでしょうか？
自分デコードを書く場合は、edi,esiは関数の頭でpushして、
極力レジスタ数を確保して書いているのですが…。

> -9を足すというのが面白いですね。

やった…と思ったんですが、下部のsub eax,edxと相殺できて…

mov ebx, eax
sar eax, 31
add eax, 4
add eax, ebx
sar eax, 3

でいけそうです。
…と思ったら80000000h付近が違う結果になる…(^^;

＃ちなみにcdq（やCyを伴う命令）を使わないはSIMD化やx86以外の
＃CPUへの応用を考えてということであって、
＃決して私がK6系のオーナーだからではないです（笑）

-9を足すというのが面白いですね。
私はもとコードのまま素朴に
;eax = val;
cdq
xor eax, edx
sub eax, edx
inc eax
shr eax, 1
xor eax, edx
sub eax, edx
ってしてみました。

進入時にeax = val;でreturn eax;するとすると

mov ebx,eax
sar eax,31
mov edx,eax
and eax,-9
add eax,4
add eax,ebx
sar eax,3
sub eax,edx

という感じでしょうか？
＃固定小数点を四捨五入しつつ整数化してるのかな？

とあるDCTのルーチンでこんなコードがありました。
func(int val){
int sign;
sign = val & 0x80000000;
sign >>= 31;
val = ((-val)&sign)|(val&(~sign));
val += 4;
val >>= 3;
val = ((-val)&sign)|(val&(~sign));
return val;
}
分岐を消そうという努力は買うんですが、
もっとすっきりしたいですね。
#というか素直に分岐させたほうがはやかったりして。
asmでかくならどうすればよいでしょうか。

>知り合いでは首藤さんが出てたそうで
発表後に少しだけお会いしました。酒居さんは
メールを頂いたようです。
懇談会はこっち方面の知合いが居なかったので
おしゃべりする機会が無かったのが残念です。

お疲れ様でした。うちの研究室の人間はHPCに出てた
のが多いらしく話は聞きませんでした。(知り合いでは
首藤さんが出てたそうで)
反応はどんなもんでした?

>今ごろトラペを作り始めています
すっかりお任せして私は遊んでしまいました(^^)
代わりにFFTはがんばりますので勘弁して(^^;

解決しました。

C:\WINNT\System32\CONFIG.NTの中身を書き換えると良いようです。

長船です。

Windows2000のコンソールで割り当てられてるコンベンショナル
メモリを増やす方法をご存じの方いませんでしょうか？
デフォルトでは190kバイトぐらい何かに使われていて450kバイト
しか空いていないのですが、これを何とか480kバイトまで広げ
たいのです。
会社のWin2kマシンでは500kバイト近く空いているので、
どうにかすれば可能だと思うんですが‥‥。

学会会場には長袖の服を持って行くほうがいいでしょうねぇ(^^;;
夏の沖縄の建物内は冷房がきつすぎます。
屋外はそんなに気温が変わりません。大阪や東京のほうが暑いくらいでしょう。

P.S.
今ごろトラペを作り始めています(^^;;;

>24bitなら普通に
>...
でしょうねぇ。
PS2 Linuxってうちの会社にもやってきてました。
配属が違うんでいじられない。ちょっと残念。

>沖縄ええのう・・・
やっぱりすごく暑いんかなあ。

24bitなら普通に

*(BGR+2) = *RGB++;
*(BGR+1) = *RGB++;
*(BGR ) = *RGB++;
BGR += 3;

かなぁ？
PEN3みたいにプリフェッチとか使えればいいけど。

> あ、関係者はそろそろ沖縄か。
沖縄ええのう・・・

RGBのピクセルをBGRに変換するアルゴリズム募集中。
PS2はLSBだけど、フレームバッファがBGRみたい…。
(という訳でPS2 LinuxでEffecTVを動かしてます)

あ、関係者はそろそろ沖縄か。

げっ、自分で書いておいて何ですが、めっちゃわかりにくいやん！

>それで念のため前述の２つのコードで試してみたら
〜２つのコードをEnumWindowで、xor eax,eaxと合わせて試してみたら
>で、やっぱりこの違いしかないということを確認して、
で、へるみさんのレスで、やっぱり・・・・・・

重ねてすいませんです。 (。。)

レスどうもです。

> そんなことはないですよ(^^)。
それはよかったです。

> AAA'の場合はecx=B, edx=A, ebx=return addressになる点が
> AAAと違うと思います。
ですよね。AAA'は
mov ebx,[esp+0x4]
mov ecx,[esp+0x8]
mov edx,[esp+0xc]
mov [esp+0xc],ebx
ret 8
と同じですよね。
・・・・・・あれ？不正な処理？
す、すいません。 m(..)m

いや、実は WinAPIのコールバックができない（見えない引数を取る）
言語で無理矢理コールバックできるようにするラッパー（？）
を書いたんですが、これが不正な処理を・・・・・
単純にスタックに余裕を作って指定された数だけ引数を
スタックトップにコピー、本物の処理ルーチンを call、（以下略）
だったのでどこが悪いかさっぱりわからなかったんです。
それで念のため前述の２つのコードで試してみたら
popの方はダメで、retの方は問題無かったのでますます混乱、
わけわかんなくなっちゃった（^^;A ので・・・・・・

で、やっぱりこの違いしかないということを確認して、
詳しくテスト。原因は ebxの内容の破壊のようでした。
うう、Win95(^^;のばか〜。必要なレジスタぐらい保存しとけ〜。
って、アセンブラで組む方も悪いんだけど。ＳＤＫに載ってるかな。

というわけでホントにまぬけな質問で失礼しました。
＆ありがとうございました。
また悩めるとき（^^)があったらよろしくお願いします。

はじめましてよろしくお願いします。
>この掲示板があまりそういう用途でないのは承知しておりますが、
そんなことはないですよ(^^)。

>どう違うんでしょうか？
質問の意図がよくわかりませんが、明らかに違うような(^^;

push A
push B
call AAA or AAA'

AAA:
ret 8

AAA':
pop ebx ;ebx=return address, esp += 4
pop ecx ;ecx=B, esp += 4
pop edx ;edx=A, esp += 4
push ebx ;[es] = return addres, esp -= 4
ret
というコードを考えると
AAAの場合はreturnしたあとstackにあるA, Bを捨てますよね(esp+=8)。
AAA'の場合はecx=B, edx=A, ebx=return addressになる点が
AAAと違うと思います。

はじめまして、午後のこーだのおかげでNASMに巡り合えたShinといいます。
最近は、とっとと自動最適化ルーチン組んでしまおうと考えながらも
手動でスーパスカラのために最適化を繰り返している毎日（？）です。
ちょっと質問させていただきたいのですが、
ret 8
と
pop ebx
pop ecx
pop edx
push ebx
ret
はどう違うんでしょうか？
なにか勘違いでもしているのか、自分には違いが分かりません。

この掲示板があまりそういう用途でないのは承知しておりますが、
どうかよろしくお願いします。
とんでもなくマヌケな質問だったらごめんなさい。

> 人が通過するのを検知するとロックが外れ、前の人が切符を
> 取り忘れた場合は、次の１枚は内部で待機するようになってます。
> その場合はロックされたままになる模様。
そうですね。新幹線も同じようです。
するっと関西カードを２枚入れられる機械で長くないのも
ありますが、中はどうなっているんでしょうね。

> 前回の発言の前に一応確認したのだけど、抜き取る前でも
> ロックは外れるみたいです(JR, 南海)。
> #ロックは外れるけど入れるのは無理なのか?

人が通過するのを検知するとロックが外れ、前の人が切符を
取り忘れた場合は、次の１枚は内部で待機するようになってます。
その場合はロックされたままになる模様。

ちなみに新幹線の改札が長いのは特急券と乗車券を同時に処理
するためで、パイプラインというよりはスーパスカラといった
ところでしょうか (^^;

> 正確に言うと、その半分ささった乗車券を抜き取るまで
> 次の乗車券は入れられない、です。
前回の発言の前に一応確認したのだけど、抜き取る前でも
ロックは外れるみたいです(JR, 南海)。
#ロックは外れるけど入れるのは無理なのか?

> >入り口が蓋されて、次の券が入らない
> 乗車券は人間の速度よりも先に出るから次の人が入れますよね。
> #違ったっけ。
正確に言うと、その半分ささった乗車券を抜き取るまで
次の乗車券は入れられない、です。

へるみさんとPENさんはずっと遊んでてもいいのではないかと思います(^^; ＜ 自由な時間
前回の沖縄行き(それもSWoPPだったりする)から時間が経ったので「るるぶ沖縄」
を新たに買ってたりします。適当に観光しようかと思って...

>入り口が蓋されて、次の券が入らない
乗車券は人間の速度よりも先に出るから次の人が入れますよね。
#違ったっけ。
あと、通る人も歩く速度を落とさなくてもすむかもしれない。
つうか、まさに「どうでもいい話」ですが(^^;

ところで沖縄にいける許可が得られました。どこまで時間に余裕があるか分かりませんが初めてなので楽しんできます。

> (新幹線などの)駅の改札口で他より長めの自動改札があるのを見ると
> 「ああ、パイプラインが深い」って思うのは私だけ...
> に決まってますね(^^;
> #たくさん人を通すため?
いいえ。あれはパイプラインなんぞではありません。
なぜなら入れた乗車券（特急券）が出るまで、入り口が
蓋されて、次の券が入らない仕組みになっているからです。

(新幹線などの)駅の改札口で他より長めの自動改札があるのを見ると
「ああ、パイプラインが深い」って思うのは私だけ...
に決まってますね(^^;
#たくさん人を通すため?

とりあえずMMX2版を実装してみましたが速度に有意義な違いは見当たりませんでした(^^;。というわけでやはり今回は無視できるレベルのテーブル参照だったようです。
まあ、より小さくなった分他でキャッシュを(少し)有効利用できるようになるかもしれませんが。
ただ今回のpmovmskbってもっと面白い使い方を秘めてそうな気がしました。

小次郎さんのは良さげかも。アルゴリズム的に綺麗だし。
＃学生のころの実習でのALU自作を思い出す
依存関係が苦しいか？やっぱり32bytesのテーブルでループは
前半後半に分けるやり方が最速かな？

そうですね。私のも同じ方法です。
昨日はなぜか3命令と書きましたが2命令の間違いでした(^^;
>足し算の区切はb,w,dのどれでもOKだけど。

bでないと繰り上がりが発生してまずくない?
あ、かなり先だから問題無いのか。

あ、+= はsaturationなしね。足し算の区切はb,w,dのどれ
でもOKだけど。だから signed/unsigned は関係なし。
padd{b|w|d}を使ってね。

最初に
mm0 = 0x 00 00 00 00 00 00 00 00
mm1 = 0x 00 00 80 40 20 10 08 04
としておく。
ループの度に、
eax = pmovmskb( mm0 )
mm0 += mm1
とする。

> これを使うと3命令で出来ました(^^)/。

僕は同じ方法を、32bitにビットフィールドを
割り振ることでがんばってました(笑)
12命令程度です。
pmovmskbが2命令めってのがミソですか。

お久しぶりです。

3命令では大負けで、もう意味なさそうですが…

a |= ~0x3f;
b = a;
a >>= 1;
c = a;
a >>= 1;
a &= c;
c = a;
a >>= 2;
c &= a;
a >>= 2;
a &= c;
a ^= b;

という感じでリバースなINCが出来るかと。
＃並列性薄＆ぜんぜん最適化してないです

メモリを読まないことでメモリリードユニットが
ボトルネックになりにくくなって、スピードアップ！
…となるに違いないと信じて（笑）

MMX2命令(PIII, P4, Athlonでのみサポート)には
pmovmskb r32, mmxという命令がありまして。
これは何をする命令かというとmmx(64bitレジスタ)を
8個のcharと見なしたときのそれぞれのMSB(最上位bit)を
8個並べてr32の下位8bitに代入します。

例えば
mm0 = [0x12:0x34:0x56:0x78:0x80:0x00:0x54:0xFF]だと
それぞれMSBは0, 0, 0, 0, 1, 0, 0, 1なので
pmovmskb eax, mm0で
eax = 0x00000009
となります。これを使うと3命令で出来ました(^^)/。
#答えは明日。

dsk
>配列アクセスする換わりに、前回の値をレジスタに
>覚えておいて、簡単なビット演算で出来れば速度があがるかも？
そうです。私の説明が舌足らずで意図が伝わらなくて申し訳なかったです。>さ〜さん

>10年以上前だけど、IMOの問題で、
相変わらず、マニアックなこと知ってますね(^^;

長船さん
>パーシャルレジスタ使われるとRISC系のCPUに実装できないから (^^;;
x86系CPUが内部RISCになったときからこのペナルティが発生してますけど
私は何故そうなってしまうのか分かってません(^^;
簡単に説明できるもんなんでしょうか。

>日立発表で40%のコストを必要とするらしいんですが、そんなもんなんでしょうか？
SH3は分かりませんがPENさんたちが昔作ったのは486-100MHzでぎりぎりっぽかったです。
比較のしようがないかもしれませんが、まあ参考までに。

dsk
>64bytesならオールヒットだと思ったんだけど甘い？
詳しくは知らないけど32か64でしょうねぇ。
初回のロスが数十クロックあるならなんとか表を使わないバージョンもありかなと
思ったのですが、prefetch命令(必要なデータのアドレスを前もってCPUに教えて
おいて隙を見てキャッシュに移しといてもらう命令)を使ってもほとんど変化無かった
ので期待できそうにないです。
#私が(PIIIで)prefetch使って速くなったこと無いんであてにならないけど(^^;

>bsfは遅い？ ebx << cl が遅い？
どっちも遅いです(笑)。代用できる命令は無いので存在価値はあるんですけど。

a ^ a(n-1) で得られる数に対して欲しいのは
000001 100000
000011 110000
000111 111000
001111 111100
011111 111110
なので順番をかえてNOTで得られるはず、と思ったけど違った（汗
もうひとひねり必要らしい。

ちなみにbsfは最短でも7CLKらしいです。

ある程度縛られます。単に配列を高速につくるだけなら、
埋め込みが最も高速(時間0)なので...FFTでバタフライやる
ときにループ回してやりたい分だから...
ループ内で、配列アクセスする換わりに、前回の値をレジスタに
覚えておいて、簡単なビット演算で出来れば速度があがるかも？
ということです。
さ〜さんの方法だと、配列のアクセスしている訳で、レジスタ
内だけで計算すれば、配列のアクセスより速くなるかどうか？
が問題点だから、この問題の答えにはならないと思う。

※10年以上前だけど、IMO(国際数学オリンピック)の問題で、
さ〜さんのfor文の中身の2式が漸化式として出され、それが
bit reverseの関数になることを当てないと解けない問題が
出ました。

data{n+1} = f(data{n}) のとき
data{n}を abcdef、data{n+1}を ABCDEF と表したとき
A = a ^ 1;
B = b ^ (a & 1);
C = c ^ (b & a & 1);
D = d ^ (c & b & a & 1);
E = e ^ (d & c & b & a & 1);
F = f ^ (e & d & c & b & a & 1);
って感じにできますが、
わざわざ、data{n+1} = f(data{n})に
しばられなくてもいいわけで、

dt[0] = 0;
for(i = 0; i < 32; i ++)
{
　dt[i*2] = dt[i] >> 1;
　dt[i*2+1] = dt[i*2] | 0x20;
}

でいかがでしょう。

２行でかけるし(笑)
for(dt[(i=0)] = 0; i < 32; i ++)
　dt[i*2 +1] = (dt[i*2] = dt[i] >> 1) | 0x20;

＃シフトが不定なら、割り算で書いてもＯＫだし

64bytesならオールヒットだと思ったんだけど甘い？
FFT高速化なら、FFTのループをアンロールして、それぞれに
定数埋め込みが速いかも。

折衷案として、例えば、32bytesくらいでヒットなら、
完全にアンロールするのではなく、ループを2つに分けて、
前半はそのまま表引き、後半は引いてincする。
なんてのはどうかな？

ハードで実装というのは速度的には正しいと思う。実際
数値計算用スーパーコンにはそれ系の命令あるし。

ビット演算なら、 (1 << 7 - bsf(n^(n-1)+1) ) - 2 を
順にxorして行くのは遅いの？

eax = bitrev(n-1)
ebx = n
が入っているとして、
ecx = ebx - 1
ebx ^= ecx
ecx = bsf( ebx )
ecx ^= 7 ; 7からの引き算はxorで
ebx = 1
ebx <<= cl
ebx -= 2
eax ^= ebx

bsfは遅い？ ebx << cl が遅い？

やっぱり、n^(n-1) が 1,3,7,15,31のどれかにしかならないこと
を利用して、そこだけ表引きかな？5bytesなら完全ヒットでしょ。
離れてると駄目？

ソフトが専門じゃないので横槍になっちゃいますケド。

●へるみさん経由さ〜さん：

> >パーシャルレジスタは反則ですか(笑)
> 反則です(^^; 10clock程度はストールするんじゃないかしらん。

右に同じく。
パーシャルレジスタ使われるとRISC系のCPUに実装できないから (^^;;
＃ABCDEFGH→HGFEDCBAとか、ABCDEFGH→AEBFCGDHとかの変換は
＃ハードに実装してしまう私‥‥ (^^;;


そういえば、133MHzのSH3-DSPでMP3をソフトデコードすると、日立発表で
40%のコストを必要とするらしいんですが、そんなもんなんでしょうか？

メモリアクセスでキャッシュにヒットしなかった場合、
ここ
http://www.csl.sony.co.jp/person/fnami/pentopt.htm
によると100MHzシステムだと20〜5CLOK
平均を取って10CLOKと仮定する。

テーブルの場合、
lea eax,[edx,eax*4]
mov eax,[eax]

だから11CLOK？AGIとかどうなんだろう？？
まあ最近のＣＰＵは倍率も高いのでもっとかかるような気もする

ebx = eax; // --ABCDEF
eax &= 101010b; // --A-C-E-
ebx &= 010101b; // ---B-D-F
eax >>= 1; // ---A-C-E
eax = ebx * 2 + eax; // --BADCFE
ebx = eax; // --BADCFE
eax &= 110011b; // --BA--FE
ebx &= 001100b; // ----DC--
eax <<= 4; // BA:--FE----
eax |= ebx; // BA:--FEDC--
ebx = eax; // BA:--FEDC--
eax &= 1100000000b; // BA:--------
ebx &= 0000111100b; // --:--FEDC--
eax >>= 8; // ------BA
eax |= ebx; // --FEDCBA

ペアリングとかよくわからないけど、9CLOKぐらい？
ほんとにあってるのかな？これ？（＾＾；
メモリアクセスを10CLOKってのがかなり妖しいけど・・・。

>いつもＲＯＭしてるＥＺＩといいます。
どうも初めまして。
>^=じゃなくて&=じゃないですか？
そうですね。失礼しました。m(__)m

>やっぱテーブルの方が速いかも・・・
そうですねぇ。テーブルが小さいから1回目と32回目の
ときにキャッシュに入ってないときの処理時間がどのぐらいか
にかかりますね。根拠無いけど多くても4, 5命令ぐらいで実現
しないと無理かな。

さ〜さん
>パーシャルレジスタは反則ですか(笑)
反則です(^^; 10clock程度はストールするんじゃないかしらん。
今回の場合は任意のビットリバースでなくて、
0b100000から0b010000を作る、0b010000から0b110000を作る...
ということを考えないとまず無理なんじゃないかな。
例えば0b100000に0b11000000をxor, 次に0b100000, 次に0b11100000,...
って感じでxorすべき0b1..10..0の方をなんとかして生成するとか。
しかしいずれにせよ題材としては苦しすぎましたね(^^;

なんか面白そうなことになってますね(^^;

ebx = eax; // --ABCDEF
eax &= 010101b; // ---B-D-F
ebx &= 101010b; // --A-C-E-
ebx >>= 1; // ---A-C-E
eax = eax * 2 + ebx; // --BADCFE
ebx = eax; // --BADCFE
ebx &= 110011b; // --BA--FE
eax &= 001100b; // ----DC--
ebx <<= 4; // BA:--FE----
eax |= ebx; // BA:--FEDC--
al |= ah; // --FEDCBA

パーシャルレジスタは反則ですか(笑)
どちらかというと、Ｃ言語で美しく書くのが
いいんじゃないかと思います。

eaxが6bitなら

ebx = eax; //ABCDEFGH
eax &= 0x055;
ebx &= 0x0AA;
eax <<= 2;
eax = ebx + eax; //BADCFEHG0
ebx = eax;
eax &= 0x066; //001100110
ebx &= 0x198; //110011000
eax <<= 4;
eax = ebx + eax; //DCBAHGFE000
ebx = eax;
eax &= 0x078; //00001111000
ebx &= 0x780; //11110000000
eax <<= 8;
eax = ebx + eax; //HGFEDCBA0000000
eax >>= 7+2;

やっぱテーブルの方が速いかも・・・

> ビット操作より、Cで書くなら、
> static unsigned char b[64] = {
> 　0x20, 0x10, 0x30, 0x8, ...
> 　....
> };
> のような、結果埋め込みが速そう。
今使っていたFFTではそうしてるんですけど、もし
少しのビット操作でできるならそっちのほうが速いかなと
思って。

単純に

c = (a ^ b) | ((a & b)>>1);

として、b=1だから

c = (a ^ 1) | ((a & 1)>>1);

うーん、速くなりそうにない。

> 少し考えてみたけど64byteの配列の方が明らかに速そう(^^;
> というわけでお題は
> 「1つずつ増える6bitの数のビットリバースの
> 数列をいかに速く作るか?」
> つまり
> 100000b
> 010000b
> 110000b
> 001000b
> 101000b
> 011000b
> ...
> という数列を作るビット操作はどんなもの?
ビット操作より、Cで書くなら、
static unsigned char b[64] = {
　0x20, 0x10, 0x30, 0x8, ...
　....
};
のような、結果埋め込みが速そう。

いつもＲＯＭしてるＥＺＩといいます。
初書き込みです。

> 「1つずつ増える6bitの数のビットリバースの
> 数列をいかに速く作るか?」

さ〜さんのＨＰにあった単一レジスタで多重ループを応用して

add edx, 63
mov eax, 000001b
loop5:
or eax, 000010b
loop4:
or eax, 000100b
loop3:
or eax, 001000b
loop2:
or eax, 010000b
loop1:
or eax, 100000b
loop0:
and eax, 111111b
mov [edx],eax
dec edx
sub eax, 100000b
jns loop0
sub eax, 010000b
jns loop1
sub eax, 001000b
jns loop2
sub eax, 000100b
jns loop3
sub eax, 000010b
jns loop4
sub eax, 000001b
jns loop5

なんかかなり違う気もするけど（＾＾；
まだぺんちあむのアセンブラ勉強中だし。
どこかに勉強にいいＨＰとかツールとかあったら教えて下さい。

あと、前のビットリバースだけど

> eax ^= 0x55555555;
> ebx ^= 0xAAAAAAAA;

^=ってXORですよね？
^=じゃなくて&=じゃないですか？

やっぱテーブルはキャッシュとかあるから遅いのかな？？

少し考えてみたけど64byteの配列の方が明らかに速そう(^^;
というわけでお題は
「1つずつ増える6bitの数のビットリバースの
数列をいかに速く作るか?」
つまり
100000b
010000b
110000b
001000b
101000b
011000b
...
という数列を作るビット操作はどんなもの?

FFTはうるりさんでしょう(^^;
大学が田舎にあるので今日原稿を出そうと思うんだけど、時間がないっす(^^;;;