せっかちな人々(まったりも可)
どんなささいなことでも構いません.
面白い最適化のアイデアがありましたら書き込んで下さい.
無論雑談も大歓迎です.
新規書き込みスレッド表示|日付順表示|開設者ホームページへ戻るヘルプ
表示件数: 件/頁 
より新しい記事へ ← 86 件の投稿中 86件目〜37件目を表示 → より前の記事へ
103:Re: 貴方はどちら派?2000/02/25 (金) 18:53 コメント数:  0件
  なべちゃん@abk  |
全部小文字ですね。
シンボルには大文字を使ったりもしますが、小文字が多いです。
マクロは(まれにしか使いませんが)大文字ですね。

Z80だと、レジスタ名だけ大文字で書いてたような気もしなくはないですが、
よく覚えてないです。

関係無いけど、ローカルラベルの使い方を知らず、
みんな普通のラベルで書いてます。(例 XXX_st1, XXX_st2)
(基本的に擬似命令を知らないから使わない)

#よくも悪くもNA386育ち(汗

もっと関係ないけど、最近は DOS のファイラーでファイル名を小文字表示してます。
最初は違和感がありましたけども。
どうも UNIX かぶれの模様...
新規投稿この投稿にリプライ投稿者削除

102:TAB2000/02/25 (金) 18:39 コメント数:  0件
  なべちゃん@abk  |
へるみさん
> すんません。cgi(perl)は良く分からないので。
> #nifのcgiはCでもいいみたいだけど。

今ちょっと実験してみたところ、pre タグで囲めば、
tab code が有効になるみたいです。
ただ、書きこみ時にタブを使用したテキストを
ペーストする必要がありますが。
新規投稿この投稿にリプライ投稿者削除

101:Re: [esp]か[ebp]か2000/02/25 (金) 18:28 コメント数:  0件
  なべちゃん@abk  |
発言数のおおさいに参ってます(苦笑)
ところで、この掲示板ってログとか保存してるんですか?

> [ebp]を使う方が1byte命令数が少なかった
> ような気がしますが、準備に push ebp/mov ebp,esp
> が必要なのでどっこいどっこいという気がします。

私は 1byte 少ないのと、push/pop するレジスタを増やしたとき調整が
あまりに面倒なので、ebp 使ってます。
2つ3つ引数があったら、ebpでいいやって感じてす(汗

ただルーチン内で ebp を破壊して、その後で引数参照するときは esp ですけど...
新規投稿この投稿にリプライ投稿者削除

100:Re: [esp]か[ebp]か2000/02/25 (金) 16:38 コメント数:  0件
  Mamiya  |
> 関数の引数を参照する時みなさんは
> どちらを使いますか?
私は
パラメーターが少ないときは[esp+disp]使い、
多いときは構造体のアドレス渡し(これも[esp+disp])
です。
新規投稿この投稿にリプライ投稿者削除

99:[esp]か[ebp]か2000/02/25 (金) 13:17 コメント数:  2件
  へるみ  |
関数の引数を参照する時みなさんは
どちらを使いますか?
私は殆んどespを使っています。
例外的なのはアライメントされたlocal変数を
使う時ぐらいです。

[ebp]を使う方が1byte命令数が少なかった
ような気がしますが、準備に push ebp/mov ebp,esp
が必要なのでどっこいどっこいという気がします。
新規投稿この投稿にリプライ投稿者削除

98:Re^11: Xプライト処理2000/02/22 (火) 18:50 コメント数:  0件
  さ〜  |   http://www1.webnik.ne.jp/%7Esanami/
小次郎さん:
a?b:cを((b^c)&m)^cとするの、使えますよ〜

.lp
mov eax,[edx]
mov edi,[ebx]
mov esi,eax
and eax,0x7f7f7f7f
add eax,0x7f7f7f7f
or eax,esi
and eax,0x80808080
shr eax,7
add eax,0x7f7f7f7f
xor eax,0x80808080
------------------------------ここから
xor edi,esi
and edi,eax
xor esi,edi
------------------------------ここまで新規
mov [ebx],esi
add ebx,4
add edx,4
dec ecx
jnz short .lp

ということで、1命令減17命令です。
でも、eaxへの書きこみが多いので完全なペアリングができるか不安です(^^;
試しにやってみてるんですが、できてません。
飽和加算にも応用できないか考えてます。

へるみさん:
> 私が前回書き込んだマスクを作る方法はちょっとやぼったい
> 気がしていましたがなるほどこんな方法がありましたか。
> これはいろんな部分で使えそうです。ありがとうございます。
僕は最初、
0-(a>>7)+(a<<1)と書いてました。
(a<<1)-(a>>7)を見てショックをうけたですよ(^^;
(7F + a)^80は↑の逆転で考えだしました。
他の部分に影響を与えないところがまたお徳ですね
新規投稿この投稿にリプライ投稿者削除

97:Re^10: Xプライト処理2000/02/22 (火) 12:59 コメント数:  1件
  へるみ  |
私が前回書き込んだマスクを作る方法はちょっとやぼったい
気がしていましたがなるほどこんな方法がありましたか。
これはいろんな部分で使えそうです。ありがとうございます。
新規投稿この投稿にリプライ投稿者削除

96:懺悔2000/02/22 (火) 04:44 コメント数:  0件
  小次郎  |
 ワタクシ、a?b:cをずっとm=a?~0:0として
((b-c)&m)+cみたいに書きこんでいましたが、
((b^c)&m)^cでなくては困りますよね…SIMDの時は。

 実際に使っているルーチンではXORを使っているのに、
何故かそういった書きこみを大量に…。

 読者の方にはご迷惑をおかけしました。ごめんなさい。

#(b&m)|(c&(!m))より演算数が少ないと喜んで
#間違いまくってしまった…
新規投稿この投稿にリプライ投稿者削除

95:Re^9: Xプライト処理2000/02/22 (火) 03:35 コメント数:  2件
  さ〜  |   http://www1.webnik.ne.jp/%7Esanami/
はじめまして。

最適化講座で僕の持ってるコードと同じことを書かれていて、
くっそ〜と思って、こちらの掲示板をながめていたら
マスク作成と15bit飽和加算のコードまで〜(^^;
仕組み的には僕のコードと同じだったので、書きこめませんでしたが、
ずっと考えつづけていいことを思いついたので書きこみにきました(^^;

参考にしたコードがスプライト処理なのに、
実際に書いたコードがなぜか8bit x4の飽和加算になってしまいました(笑)
ちょろっと書き換えてスプライト処理に戻しました(^^;
なにはともあれ、結果から。
まずはスプライト処理。

.lp
mov eax,[edx]
mov edi,[ebx]
mov esi,eax
and eax,0x7f7f7f7f
add eax,0x7f7f7f7f
or eax,esi
and eax,0x80808080
shr eax,7
add eax,0x7f7f7f7f
xor eax,0x80808080
and esi,eax
not eax
and edi,eax
or esi,edi
mov [ebx],esi
add ebx,4
add edx,4
dec ecx
jnz short .lp
ペアリングの並び替えはまだしてませんが18命令です。
説明。0かどうかのbitを立てるところまでは一緒です。
みそはマスク作成。
7f + 01 = 80 -> 80 ^ 80 = 00
7f + 00 = 7f -> 7f ^ 80 = ff
これで1命令かせいでる気がします。
我ながら自信作(^^;間違ってないことをいのりましょう。

で、8bit x4の飽和加算。ペアリングはしてませんし、
レジスタの割りつけも適当なので雰囲気だけ。

.lp:
mov eax,[edx]
mov edi,[ebx]
mov ebp,eax
and ebp,edi
mov esi,eax
xor esi,edi
shr esi,1
and esi,7f7f7f7f
add ebp,esi
and ebp,80808080
shr ebp,7
add esi,ebp
xor esi,80808080
and eax,esi
add eax,edi
or eax,esi
mov [ebx],eax
add ebx,4
add edx,4
dec ecx
jnz short .lp

t = ((a & b) + ((a xor b)>>1 & 7f7f7f7f) & 7f7f7f7f)
で飽和情報をゲットしてます。
コードが正しいかどうかのチェックはしてません(^^;
アイデアだけ、ということで。
ちょこちょこっといじれば15bit加算にもなると思います。

はじめましてで長文、すいません。
これからも来るつもりなので、よろしくお願いします。
新規投稿この投稿にリプライ投稿者削除

94:Re^5: 積算合成に応用できませんかね?2000/02/21 (月) 15:23 コメント数:  0件
  Mamiya  |
懲りずに考えています。

I1R5G5B5飽和加算(ただしIビットは0を仮定)

const unsigned maskA = 0x3def3def;
const unsigned maskB = 0x42104210;

/* 丸め(ラップラウンド)加算 */
tmp1 = ((col1 & maskA) + (col2 & maskA)) ^ ((col1 ^ col2) & maskB);
/* RGBの桁あふれ算出 */
tmp2 = col1 + col2 - tmp1;
output = tmp1 | (tmp2 - (tmp2>>5));
300万回、乱数でテストしました。
今度は大丈夫そうです。
新規投稿この投稿にリプライ投稿者削除

93:儚い暗号2000/02/21 (月) 15:15 コメント数:  0件
  へるみ  |
ちょっと変わったタイプの暗号を作れた!と
思ったけど0.1秒で解けてしまった。悲しい。
論文の夢が...

DJ☆Uchiさん
>殆ど分岐しないですね(^^;
>これをうまく利用した方が良いのかも知れません。
データが偏ってる場合はそうですね。
私もまた実験してみます。
新規投稿この投稿にリプライ投稿者削除

91:Re: 貴方はどちら派?2000/02/21 (月) 09:15 コメント数:  0件
  Mamiya  |
言われるまで、大文字から小文字に変わっていたことを自覚していませんでした。
#でもアセンブリ言語は大文字のほうが読みやすい気がします。慣れ?
.
新規投稿この投稿にリプライ投稿者削除

90:Re^4: 積算合成に応用できませんかね?2000/02/20 (日) 17:23 コメント数:  1件
  小次郎  |
 DirectDrawクラスの製作の合間に(笑)
(a+b)>>1=((a^b)&mask)>>1+(a&b)
を使って繰り上がりを検出しようという方針で
こんなのを考えてみました。

tmp1=(((col1^col2)&0x7bde7bde)>>1+(col1&col2))&0x42104210;
// =(((col1^col2)>>1)&0x3def3def+(col1&col2))&0x42104210;
tmp2=tmp1+tmp1;
tmp3=tmp2-(tmp1>>4);
output=(col1+col2-tmp2)|tmp3;

 検証してないし、どこかに勘違いがあるような気がするので、
信じないで下さい(をぃをぃ
新規投稿この投稿にリプライ投稿者削除

87:Re: 貴方はどちら派?2000/02/20 (日) 17:07 コメント数:  0件
  へるみ  |
>BASIC付属のエディタ(?)でソースを書いてた時は大文字でした。
小文字で書いても勝手に大文字になってましたし。
最近はテキストエディタで書くから小文字でやってます。
ただ16進数は大文字の方が見やすいのでそうしてます。
新規投稿この投稿にリプライ投稿者削除

86:Re: 貴方はどちら派?2000/02/20 (日) 00:39 コメント数:  0件
  HMD  |   http://www.geocities.co.jp/Playtown-Denei/3402/main.html
私は、「まったり」派 …というのはおいといて、

>  個人的な認識としては小文字で記述するのは
> Cなどの小文字が主の言語を習得してからアセンブラを
> 覚えた人が多いのではないかと思っているのですが。

私は、FORTRAN 77 から入ったので、大文字派かな?
#でも、その後 WATFOR に移って、小文字派に変わったようです。
新規投稿この投稿にリプライ投稿者削除

85:Re^3: 飽和演算2000/02/20 (日) 00:31 コメント数:  0件
  DJ☆Uchi@アセンブラ一年生  |   http://homepage1.nifty.com/uchi/
> > >一応こういう↓のを考えてみましたが、
> > >これだとジャンプした方がマシに思えてきます。
> > Ppro/P2/PIII系CPUだと分岐予測がはずれたときのペナルティは
> > 10clock以上あったと思うので大丈夫だと思いますが。
>
>  P5系は4クロック程度のペナルティでしたよね。
>  これでも4ペア=8命令分くらいに相当するので
> かなり痛いと思われます。
>
>  ただ、PCM合成であんまり飽和されても音が割れてしまって
> 困るということは、かなり分岐が偏っているはずですよね(笑)

えぇ、偏りまくっています。
しかも歪み防止のために合成後1ビット右シフトしてますので、
殆ど分岐しないですね(^^;
これをうまく利用した方が良いのかも知れません。

To:へるみさん
P6アーキテクチャのマシンでこのソフトを動かす人は皆無でしょうから、
無視です、無視!(^^;
新規投稿この投稿にリプライ投稿者削除

84:貴方はどちら派?2000/02/19 (土) 00:32 コメント数:  4件
  小次郎  |
 へるみさま曰く、内容がせっかち過ぎるようなので(違)
のんびりとした−むしろどうでもいいような−話題を。

 多くのアセンブラは記述に大文字のアルファベットでも
小文字のアルファベットでも区別しません。
 そのためか、大文字で記述する人も小文字で記述する人もいます。
#私の場合は両方が混じってしまっていますが(笑)

 手もとの書籍などを調べてみたところ、Z80関連は
ほぼ100%大文字で記述されているのに対して、
x86の場合は混在しているのが多いようです。
 さらに最近書かれた書籍の方が小文字比率が
高いように思われます。

 個人的な認識としては小文字で記述するのは
Cなどの小文字が主の言語を習得してからアセンブラを
覚えた人が多いのではないかと思っているのですが。

 まさか、パンチカード時代には大文字しかなかったこと
(厳密に言えば入力には区別がない。出力が大文字のみだった)
とかが関係していたりして(笑)<昔は大文字が多い
新規投稿この投稿にリプライ投稿者削除

83:Re^9: Xプライト処理2000/02/19 (土) 00:31 コメント数:  0件
  小次郎  |
> 昨日帰りの電車の中で作ってみたのですが、
> ペアリングのことを考えていないのはこれからとして
> 既に20命令なので小次郎さんには勝てないですね(^^;
> PS.
> ちなみにこのルーチンは一発完動でした(^^;

 なるほど、
tmp1=((Over&0x7f7f7f7f)+0x7f7f7f7f)|Over)&0x80808080
で作るわけですね…って、4演算で済んでるではないですか。
(私の場合は5演算)
 ということは…19命令でつくれますね。
#ソースは間違ったものを書きこんでばかりなので省略(汗)

 アンロールしてやれば、1クロック減…。
 ありがとうございました>へるみさま

> PPS.
> Athlonで測定すると小次郎さん、私のどちらでも
> 9clock/loop。既に最適化は死語なのか?

 ASMレベルの最適化好きの希望的意見(笑)としては
P5/P6/K6/MIIなどが、デコーダまたは実行器の制限に
よって基本的に1クロック当たり2演算だったのが
K7では3演算できるような構造になっているため、
別の方法での最適化が必要なのではないかなと思います。
(9クロックあれば27演算できるはずですから)

 ただ、3演算並列のためには個別にレジスタとして
最低3本が必要で、残りの4本を(カウンタやポインタを含めて)
使いまわさなくてはいけないのが辛そうですね。
 ということで、K7ではMMX命令を使うことは、SIMDで処理が
行われることよりも、並列記述のために求められるレジスタ数が
8本も増えるということの方が重要なのかも…。

 しかし、ほしいですね〜(笑)<Athlon
 できればムスタング×2で(それは贅沢過ぎ>自分)
 ついでに4ALU演算/CPU内部クロックのP7も(爆)
新規投稿この投稿にリプライ投稿者削除

82:Re^2: 飽和演算2000/02/19 (土) 00:30 コメント数:  1件
  小次郎  |
> >一応こういう↓のを考えてみましたが、
> >これだとジャンプした方がマシに思えてきます。
> Ppro/P2/PIII系CPUだと分岐予測がはずれたときのペナルティは
> 10clock以上あったと思うので大丈夫だと思いますが。

 P5系は4クロック程度のペナルティでしたよね。
 これでも4ペア=8命令分くらいに相当するので
かなり痛いと思われます。

 ただ、PCM合成であんまり飽和されても音が割れてしまって
困るということは、かなり分岐が偏っているはずですよね(笑)

> >どうにも不便ですね...。せめて TAB が使えれば...。
> すんません。cgi(perl)は良く分からないので。
> #nifのcgiはCでもいいみたいだけど。

 Formからの入力の中のスペースを&nbsp;に置換すれば、
解決できるんではないかと思います。
 たぶん、「<」などを「&lt;」などに置換しているところが
あるはずなので、そこに書き加えるだけでいいかと…思いますが…。
 識者のフォローを求みます(爆)
新規投稿この投稿にリプライ投稿者削除

81:Re: 飽和演算2000/02/18 (金) 21:49 コメント数:  0件
  へるみ  |
バイトしながら考えましたが
命令数はこっくりさんのと同じでした(^^)

mov edx,eax
sar eax,31
xor eax,edx
add eax,-32768
sbb esi,esi
and eax,esi
add eax,32768
xor eax,edx
新規投稿この投稿にリプライ投稿者削除

80:Re: 飽和演算2000/02/18 (金) 16:02 コメント数:  3件
  へるみ  |
ここの掲示版、ちょっとハイペースです(^^;
名前を「のんびりな人々」に変えましょうか。

確かに符合付き飽和演算は難しいですよね。

>一応こういう↓のを考えてみましたが、
>これだとジャンプした方がマシに思えてきます。

Ppro/P2/PIII系CPUだと分岐予測がはずれたときのペナルティは
10clock以上あったと思うので大丈夫だと思いますが。

>ペアリングって何?って感じですね(^^;
P5にはuパイプで実行出来るグループとvパイプで実行出来る
グループがあって、その2つの間に依存関係が無い時は同時
実行出来るという話です。
No.66でMamiyaさんが紹介されてるpageが凄く詳しいです。

なべちゃん
>どうにも不便ですね...。せめて TAB が使えれば...。
すんません。cgi(perl)は良く分からないので。
#nifのcgiはCでもいいみたいだけど。
新規投稿この投稿にリプライ投稿者削除

79:Re^6: Xプライト処理2000/02/18 (金) 15:49 コメント数:  0件
  Mamiya  |
> >アドレスの組み合わせ次第では倍以上遅くなる
> >ケースもありましたが。
> 確かalignミスのペナルティは3clockぐらいでしたっけ。
> これは逆にK6では1clockぐらいしかなかったと思います。
3clockでした。
他にキャッシュバンク競合ペナルティ(1clock)もあります。
新規投稿この投稿にリプライ投稿者削除

78:Re^3: 積算合成に応用できませんかね?2000/02/18 (金) 15:47 コメント数:  2件
  Mamiya  |
> > 飽和合成をとりあえず自分で考えてみました。
> コードテストを行ったところ結果が異常だったので訂正します。
> tmp1 = col1+col2;
> tmp2 = tmp1^col1^col2; /* 各ビットの繰り上がり検出 */
> tmp1 -= tmp2 & 0x84218421; /* 不要な繰り上がりの消去 */
> tmp2 &= 0x84208420; /* 各RGB値のあふれ */
> output = (tmp1 & 0x7fff) | (tmp2-(tmp2>>5));
このコードにも
Rが両方とも31の場合や
Gが両方とも31の場合に
異常な値を出力する問題がありました。
(下のキャリーを上まで伝えてしまうため)

d0 = (c0 & 0x7c1f7c1f) + (c1 & 0x7c1f7c1f); /* R0B */
d1 = c0 + c1 - d0; /* 0G0 */
d2 = (d0 & 0x80208020) | (d1 & 0x04000400);
d3 = (d0 & 0x7c1f7c1f) | (d1 & 0x03e003e0);
output = d3 | (d2-(d2>>5));
これだと美しくないのでもう少し考えてみます。
新規投稿この投稿にリプライ投稿者削除

77:Re^5: Xプライト処理2000/02/18 (金) 15:42 コメント数:  1件
  へるみ  |
>P55Cでは理論値通りの7clk/loopでした。
やっぱりそうですか。K6/K6-2はcarryを伴う演算が
遅いのが難です。

>アドレスの組み合わせ次第では倍以上遅くなる
>ケースもありましたが。
確かalignミスのペナルティは3clockぐらいでしたっけ。
これは逆にK6では1clockぐらいしかなかったと思います。
新規投稿この投稿にリプライ投稿者削除

76:Re^8: Xプライト処理2000/02/18 (金) 15:39 コメント数:  4件
  へるみ  |
昨日帰りの電車の中で作ってみたのですが、
ペアリングのことを考えていないのはこれからとして
既に20命令なので小次郎さんには勝てないですね(^^;
PS.
ちなみにこのルーチンは一発完動でした(^^;

PPS.
Athlonで測定すると小次郎さん、私のどちらでも
9clock/loop。既に最適化は死語なのか?

.lp:
mov eax,[edx]
mov edi,[ebx]
mov esi,eax
and eax,0x7F7F7F7F
add edx,4
add eax,0x7F7F7F7F
or eax,esi
and eax,0x80808080
mov ebp,eax
add eax,eax
shr ebp,7
sub eax,ebp
and esi,eax
not eax
and edi,eax
or esi,edi
mov [ebx],esi
add ebx,4
dec ecx
jnz short .lp
新規投稿この投稿にリプライ投稿者削除

75:Re^4: Xプライト処理2000/02/18 (金) 15:24 コメント数:  2件
  Mamiya  |
> K6-2/Athlonで実行してみました。
> 詳しいソースはこちら
> >http://homepage1.nifty.com/herumi/adv/test/test0217.lzh
> Mamiyaさんのコードでは 11clk/loopでした。
> [esi]アドレッシングを別のレジスタに置き換えると
> 8clk/loopに激減。やはりK6/K6-2では[esi]は鬼門の模様。
> #何故こんな仕様にしたんかいな。どうみてもAMDのミス。
>
> それから、32bit colorではなく24bit colorで最上位bitが常に0を
> 仮定するならsbbを回避でき、その場合は7clk/loopまでいきました。
> まだ煮つめた訳ではありませんが、とりあえず。
>
> 出来たらP5などでも測定して頂けるとありがたいです。
P55Cでは理論値通りの7clk/loopでした。
もっともアドレスの組み合わせ次第では倍以上遅くなるケースもありましたが。

新規投稿この投稿にリプライ投稿者削除

74:Re^7: Xプライト処理2000/02/18 (金) 06:10 コメント数:  5件
  小次郎  |
>  これで、かの8bit*4のスプライトルーチンがすべてペアリングできそうです。

MOV EAX,[EDX] ;u ?ABCDEFGH Over
MOV EDI,[EDX] ;v Over
SHR EAX,1 ;U ??ABCDEFG
SUB EBX,4 ;v
OR EAX,80808080H ;u ?1ABCDEFG
LOOP1:
OR EAX,EDI ;u01 ?1IJKLMNO
ADD EBX,4 ;v01
SUB EAX,01010101H ;u02 ?P???????
ADD EDX,4 ;v02
AND EAX,80808080H ;u03 0P0000000 (Over==0)?0:128
MOV ESI,[EBX] ;v03 Base
MOV EBP,EAX ;u04 0P0000000 Copy
SUB EDI,ESI ;v04 Over-Base
SHR EBP,7 ;U05 00000000P (Over==0)?0:1
ADD EAX,EAX ;v05 P0000000? (Over==0)?0:256
SUB EBP,EAX ;u06 ?PPPPPPPP (Over==0)?0:255
MOV EAX,[EDX] ;v06
SHR EAX,1 ;U07 ??ABCDEFG
AND EBP,EDI ;v07 (Over==0)?0:Over-Base
OR EAX,80808080H ;u08 ?1ABCDEFG
ADD EBP,ESI ;v08 (Over==0)?Base:Over
MOV [EBX],EBP ;u09 Write
DEC ECX ;n09
MOV EDI,[EDX] ;u10 Over
JNZ LOOP1 ;v10

 こうなりました。ついに20命令10ペア化。
 ありがとうございました>Mamiyaさま

 ちなみに、
tmp=((Over|(Over>>1)|0x80808080)-0x01010101)&0x80808080;
Over=(((tmp<<1)-(tmp>>7))&(Over-Base))+Base;
というアルゴリズムを使っているのですが、
もう少し速くなるような方法があったら、よろしくお願いします。
新規投稿この投稿にリプライ投稿者削除

73:飽和演算2000/02/17 (木) 22:30 コメント数:  5件
  DJ☆Uchi@アセンブラ一年生  |   http://homepage1.nifty.com/uchi/
皆さんに影響されて、私もここ数日ほど飽和演算の方法を考えているのですが
なかなか巧い方法が思いつきません。
(16bit-Wave128音合成後の飽和演算処理)

「レジスタに入っている値が+32767以上だったら+32768に、-32768以下だったら-32768にする」
という命題なのですが、今までは素直にジャンプして逃げてました。
一応こういう↓のを考えてみましたが、これだとジャンプした方がマシに思えてきます。
(eaxには[+32767*128〜-32768*128]の範囲に収まる任意の数値が入っています)

sub eax,01000000h
add eax,01008000h
sbb esi,esi
and eax,esi
sub eax,0000FFFFh
sbb esi,esi
and eax,esi
add eax,00007FFFh

う〜ん、ペアリングって何?って感じですね(^^;
実際にはステレオなので、もう一チャンネル分の処理を混ぜ合わせればペアリング率
も高まると思いますが、もう少し賢い方法は無いでしょうか?
新規投稿この投稿にリプライ投稿者削除

72:Re^6: Xプライト処理2000/02/17 (木) 16:49 コメント数:  6件
  小次郎  |
> > > > mov edx,ecx ;u
> > > > add ecx,0ffffffffh ;v !=0ならキャリー
> >
> >  個人的にはレジスタリネーミングなしのP5で
> > このコードがペアリングできるかどうか知りたいのですが、
> > ご存知の方、いらっしゃいませんか?
> パイプラインのステージの都合で大丈夫です。

 やはり、WBステージの時点で書きこむから大丈夫ってことなんですね。
 パイプライン上はそうできるとはわかっていたんですが、
Intelのやることだから変な制限でできないこともあるかな〜なんて、
勝手に心配していたんです(をぃ)

 これで、かの8bit*4のスプライトルーチンがすべてペアリングできそうです。

#電話代がかかっているので、そのソースは23時以降に書きこませていただきます
新規投稿この投稿にリプライ投稿者削除

71:Re^2: sprite2000/02/17 (木) 15:45 コメント数:  0件
  Mamiya  |
> Mamiyaさん
> > mov ecx,[esi] ;v esi = over
> >* mov edx,ecx ;u
> > add ecx,0ffffffffh ;v !=0ならキャリー
>
> あっ。じゃ、"*"の所が唯一ペアリングされない命令ってことなんですね。

(MMX)Pentiumではuパイプで直前のvパイプの結果も使用可能なはずです。
したがって最後の命令以外は全てペアリングされる はず です。
しかしK6では上手くいっていないようです。

とりあえず家のMMX Pentiumで実際に計測してみます。
#しかし私は32bppを使わないのですこし不毛
新規投稿この投稿にリプライ投稿者削除

70:Re: sprite2000/02/17 (木) 15:14 コメント数:  1件
  なべちゃん@abk  |
Mamiyaさん
> mov ecx,[esi] ;v esi = over
>* mov edx,ecx ;u
> add ecx,0ffffffffh ;v !=0ならキャリー

あっ。じゃ、"*"の所が唯一ペアリングされない命令ってことなんですね。

小次郎さん
>HTMLではASCIIコード20hスペースが1つにまとめられるので見づらいかも…

どうにも不便ですね...。せめて TAB が使えれば...。
#ここは使えない模様
新規投稿この投稿にリプライ投稿者削除

68:Re^3: Xプライト処理2000/02/17 (木) 10:37 コメント数:  3件
  へるみ  |
K6-2/Athlonで実行してみました。
詳しいソースはこちら
>http://homepage1.nifty.com/herumi/adv/test/test0217.lzh
Mamiyaさんのコードでは 11clk/loopでした。
[esi]アドレッシングを別のレジスタに置き換えると
8clk/loopに激減。やはりK6/K6-2では[esi]は鬼門の模様。
#何故こんな仕様にしたんかいな。どうみてもAMDのミス。

それから、32bit colorではなく24bit colorで最上位bitが常に0を
仮定するならsbbを回避でき、その場合は7clk/loopまでいきました。
まだ煮つめた訳ではありませんが、とりあえず。

出来たらP5などでも測定して頂けるとありがたいです。
#winなら nasm オプションは -DWIN32 -f win32
#Linuxなら -D__unix__ -f elf
#DOSなら -D__tos__ -f obj
#というところ。

ついでにAthlonでは5clk/loopでした(笑)やはり速いんですね。驚き。
新規投稿この投稿にリプライ投稿者削除

67:Re^3: 積算合成に応用できませんかね?2000/02/17 (木) 10:21 コメント数:  0件
  Mamiya  |
CGIが不調。
こちらの方が読みやすいかも。
http://www.proc.org.tohoku.ac.jp/befis/halloffame/mmx/mmx.txt
新規投稿この投稿にリプライ投稿者削除

66:Re^5: Xプライト処理2000/02/17 (木) 09:57 コメント数:  7件
  Mamiya  |
> > > add ecx,0ffffffffh ;v !=0ならキャリー
> > > sbb ecx,ecx ;u
> > ところで、この二つはペアリングされないような気がするんですが(汗
>
>  私の知る限りではペアリング不許可だったとも思いましたが。

ペアリングはこっちです。
> sbb ecx,ecx ;u
> sub edx,eax ;v


>
> > > mov edx,ecx ;u
> > > add ecx,0ffffffffh ;v !=0ならキャリー
>
>  個人的にはレジスタリネーミングなしのP5で
> このコードがペアリングできるかどうか知りたいのですが、
> ご存知の方、いらっしゃいませんか?
パイプラインのステージの都合で大丈夫です。
レジスタリネーミングという技術では、
次のコードのグループの順番すら入れ替わります。

A=B+C
D=A+E

;Bが結果待ちならこちらを先に実行
A=F+C
G=A+E






必読
http://www.csl.sony.co.jp/person/fnami/pentopt.htm
新規投稿この投稿にリプライ投稿者削除

65:Re^2: 積算合成に応用できませんかね?2000/02/17 (木) 09:44 コメント数:  4件
  Mamiya  |
> 飽和合成をとりあえず自分で考えてみました。
> tmp1=(col1&col2)<<1;
> tmp2=tmp1&0x84208420;
> tmp1=tmp1&0x7bde7bde;
> output=(tmp1+(col1^col2))|(tmp2-(tmp2>>5));
>
> なにか意見があればよろしくお願いします。
コードテストを行ったところ結果が異常だったので訂正します。
tmp1 = col1+col2;
tmp2 = tmp1^col1^col2; /* 各ビットの繰り上がり検出 */
tmp1 -= tmp2 & 0x84218421; /* 不要な繰り上がりの消去 */
tmp2 &= 0x84208420; /* 各RGB値のあふれ */
output = (tmp1 & 0x7fff) | (tmp2-(tmp2>>5));


MMXを使って各ルーチンを最適化した例。
http://www.proc.org.tohoku.ac.jp/befis/halloffame/mmx/txtview.pl?mmx.txt
新規投稿この投稿にリプライ投稿者削除

64:Re^2: スプライト処理2000/02/17 (木) 02:07 コメント数:  0件
  小次郎  |
> ではそのうちNo. 008辺りのことを使って実際にやってみますね。

 よろしくおねがいしますです。
 で、8bit*4pixelのSIMD方式でやってます。
 16bit*2pixelも同様の形式です。

> ここにアップしてくだされば、みなさんが最適化してくれるかも。

 では、ご好意に甘えて(笑)

MOV EAX,[EDX] ;U ?ABCDEFGH
SHR EAX,1 ;U ??ABCDEFG
MOV ESI,[EDX] ;V Over
OR EAX,080808080H ;U ?1ABCDEFG
OR EAX,ESI ;U ?1IJKLMNO
SUB EAX,001010101H ;U ?P???????
LABEL1:
AND EAX,080808080H ;U 0P0000000
ADD EDX,4 ;V
MOV EBP,EAX ;U Copy
MOV EDI,[EBX] ;V Base
SHR EAX,7 ;U ?0000000P
ADD EBP,EBP ;V P0000000?
SUB EBP,EAX ;U ?PPPPPPPP 256*P-P=255*P
SUB ESI,EDI ;V Over-Base
AND EBP,ESI ;U (Over==0)?0:Over-Base
MOV EAX,[EDX] ;V ?ABCDEFGH
ADD EBP,EDI ;U (Over==0)?Base:Over
SHR EAX,1 ;V ??ABCDEFG
MOV [EBX],EBP ;U Write
MOV ESI,[EDX] ;V Over
OR EAX,080808080H ;U ?1ABCDEFG
ADD EBX,4 ;V
OR EAX,ESI ;U ?1IJKLMNO
SUB EAX,001010101H ;U ?P???????
DEC ECX ;V
JNZ LABEL1 ;V

#HTMLではASCIIコード20hスペースが1つにまとめられるので見づらいかも…
 もう1つレジスタがあればアンロールして18クロック/16Byteになるんですが。
 やっぱり、レジスタ少ないですよね、x86って。
 SPを潰そうかと何度思ったことか(笑)

 先ほどは間違いのあるコードを書きこんでしまいました。
 その間にご覧になった方がいらっしゃいましたら、すみませんでした。
#まだ、間違っていたらどうしよう(汗)
新規投稿この投稿にリプライ投稿者削除

63:派手に恥じ書いた(汗2000/02/17 (木) 01:30 コメント数:  0件
  なべちゃん  |
これ以上恥が拡大するまえに(激汗

>cmpxchgですか?
>これって、比較した後、無条件に交換する命令だと思い込んでいたんですが

そのとおりです。忘れてください(汗

#部屋から紙切れ発掘したら"CMOVcc"と勘違いしてた模様。
 使えるCPUは不明(^^;;

>最近のCPUはメモリがボトルネックになりやすいから避けていたんですよ。
>MMXルーチンを通らないCPUは200MHz程度だから関係無いですかね?

誰か詳しい人ヘルプ。
(個人的には実測しかないような気もしますが(^^;;)

>あ、毎回パターン生成するスプライトがあるので、andパターン生成ルーチンを
>作るっていうのが面倒で避けていたって言うのもあるんですが(笑)

私の場合は元データが(マップごとに)決まって、
たかだか1パターン1KBでしたので...(^^;
新規投稿この投稿にリプライ投稿者削除

59:Re^4: Xプライト処理2000/02/17 (木) 00:40 コメント数:  8件
  小次郎  |
> > add ecx,0ffffffffh ;v !=0ならキャリー
> > sbb ecx,ecx ;u
> ところで、この二つはペアリングされないような気がするんですが(汗

 私の知る限りではペアリング不許可だったとも思いましたが。

> > mov edx,ecx ;u
> > add ecx,0ffffffffh ;v !=0ならキャリー

 個人的にはレジスタリネーミングなしのP5で
このコードがペアリングできるかどうか知りたいのですが、
ご存知の方、いらっしゃいませんか?
新規投稿この投稿にリプライ投稿者削除

58:Re: スプライト2000/02/17 (木) 00:36 コメント数:  1件
  小次郎  |
> xchgcmp(バキ
>
> #よく覚えてないけど、条件付レジスタ交換。ただし486以降。
> ...だと思った。誰かふぉろーを(ずぎゃ

 cmpxchgですか?
 これって、比較した後、無条件に交換する命令だと思い込んでいたんですが、
条件付で交換なんですか?
 だれか、教えてください(をぃ

> あとメモリを無駄に使って、あらかじめ and パターンと dot パターンを作るとか。
> (最近やった方法)

 最近のCPUはメモリがボトルネックになりやすいから避けていたんですよ。
 MMXルーチンを通らないCPUは200MHz程度だから関係無いですかね?
 あ、毎回パターン生成するスプライトがあるので、andパターン生成ルーチンを
作るっていうのが面倒で避けていたって言うのもあるんですが(笑)
新規投稿この投稿にリプライ投稿者削除

57:Re^3: Xプライト処理2000/02/16 (水) 16:54 コメント数:  9件
  なべちゃん@abk  |
> add ecx,0ffffffffh ;v !=0ならキャリー
> sbb ecx,ecx ;u

ああ、こうすればいいのか(^^;;

ところで、この二つはペアリングされないような気がするんですが(汗

とは言ったものの自身は持てない訳でして、
(厳密なペアリングのルールはしらないから)
こんな私はむやみに発言しないで、読んでお勉強の方がよさそう(激汗
新規投稿この投稿にリプライ投稿者削除

55:Re^2: 積算合成に応用できませんかね?2000/02/16 (水) 14:48 コメント数:  0件
  へるみ  |
くぅ〜先を越された(^^;
しかし、これは「出来たらいいな」と思いつつ
無理だろうと最初からあきらめていたコードです。
まだまだ修行が足りん。
PCM波形合成にも適用できそうですね > こっくりさん

MMXで飽和演算するにしても15bit colorだと8bit pack
への変更だけで時間を食うのでもしかしたら最速?
新規投稿この投稿にリプライ投稿者削除

54:Re^2: Xプライト処理2000/02/16 (水) 12:54 コメント数:  14件
  Mamiya  |
>
> 32bit colorでですか?
> ではそのうちNo. 008辺りのことを使って実際にやってみますね。
> 15bit colorでなら以前、こっくりさんをうならせた(^^;
> コードがありますが、もっとうまい方法があるかも。
> >http://homepage1.nifty.com/herumi/adv/sample/layer.asm
>
> >私が使っているのはソフトパイプラインを使ったP5向け最適化
>
> ここにアップしてくだされば、みなさんが最適化してくれるかも。
32bitならこんなところでしょうか。

mov eax,[edi] ;u edi = base
mov ecx,[esi] ;v esi = over
mov edx,ecx ;u
add ecx,0ffffffffh ;v !=0ならキャリー
sbb ecx,ecx ;u
sub edx,eax ;v
and edx,ecx ;u
add edi,4 ;v AGIとペアリング対策
add eax,edx ;u
add esi,4 ;v
mov [edi-4],eax ;u
新規投稿この投稿にリプライ投稿者削除

53:Re: 積算合成に応用できませんかね?2000/02/16 (水) 12:41 コメント数:  6件
  Mamiya  |
飽和合成をとりあえず自分で考えてみました。
tmp1=(col1&col2)<<1;
tmp2=tmp1&0x84208420;
tmp1=tmp1&0x7bde7bde;
output=(tmp1+(col1^col2))|(tmp2-(tmp2>>5));

なにか意見があればよろしくお願いします。
新規投稿この投稿にリプライ投稿者削除

52:Re:スプライト処理2000/02/16 (水) 11:29 コメント数:  16件
  へるみ  |
>あと、HuffmanCodeLの最適化の話のCソースはidx=0が
>前提ですよね。

そうでした。ご指摘ありがとうございます。
実はver. 2.24で出したバグはそんな感じ(^^;

>スプライト処理
>(Base[i]=(Over[i]==0)?Base[i]:Over[i])も
>取り上げていただきたいです

32bit colorでですか?
ではそのうちNo. 008辺りのことを使って実際にやってみますね。
15bit colorでなら以前、こっくりさんをうならせた(^^;
コードがありますが、もっとうまい方法があるかも。
>http://homepage1.nifty.com/herumi/adv/sample/layer.asm

>私が使っているのはソフトパイプラインを使ったP5向け最適化

ここにアップしてくだされば、みなさんが最適化してくれるかも。
新規投稿この投稿にリプライ投稿者削除

51:スプライト2000/02/16 (水) 10:50 コメント数:  2件
  なべちゃん@abk  |
>  できたら、スプライト処理(Base[i]=(Over[i]==0)?Base[i]:Over[i])も
> 取り上げていただきたいです<最適化講座

xchgcmp(バキ

#よく覚えてないけど、条件付レジスタ交換。ただし486以降。
...だと思った。誰かふぉろーを(ずぎゃ

あとメモリを無駄に使って、あらかじめ and パターンと dot パターンを作るとか。
(最近やった方法)

SETcc reg
ror reg
sar reg,31

とかじゃダメ?(^^;

#命令表ないから確認できない(自爆
新規投稿この投稿にリプライ投稿者削除

50:積算合成に応用できませんかね?2000/02/16 (水) 10:19 コメント数:  7件
  Mamiya  |
正確にはこうですね。
>output = (col0 & col1) + (((col0 ^ col1) & 0x7dbe7bde) >> 1);/*(誤)*/
output = (col0 & col1) + (((col0 ^ col1) & 0x7bde7bde) >> 1);

コピーしたので被害が拡大していますね(我ながら間抜け過ぎる)。
新規投稿この投稿にリプライ投稿者削除

49:Re: unsigned int(32bit)なら2000/02/16 (水) 03:05 コメント数:  20件
  小次郎  |
> output = (col0 & col1) + (((col0 ^ col1) & 0x7dbe7bde) >> 1);

 素晴らし過ぎですね…。感動しました。
 教え下さったMamiyaさまに感謝です。
 もちろん、考えてくださった方にも大感謝ものです。

 a+b=(a&b)<<1+(a^b)だから(a+b)>>1=(a&b)+(a^b)>>1で
下位バイトに影響を与えないようにシフト前にマスク。
 いわれれば、簡単なことなんですが、なかなか思いつきませんよね…。

 そうそう。7dbeh=0111110110111110bですね…。
 ちょっとはまりました(笑)

 あと、HuffmanCodeLの最適化の話のCソースはidx=0が前提ですよね。
 (x==0&&y!=0)の時にidx+=yしてidx==yにならないとASM版が食い違いますので。
 いや、午後のこーだの元のcソースをみればいいだけですが。

 揚げ足とりみたいになってしまいましたが、ここを訪れた初心者の方などが迷うと
困るかなと思いまして、書かせていただきました。

 できたら、スプライト処理(Base[i]=(Over[i]==0)?Base[i]:Over[i])も
取り上げていただきたいです<最適化講座
 私が使っているのはソフトパイプラインを使ったP5向け最適化で
1ループ(4Byte毎)が20命令、11clockくらいなんですが、できれば
もう少し速いとうれしいので…

 でわでわ
新規投稿この投稿にリプライ投稿者削除

48:re:逆アセンブラ2000/02/15 (火) 17:36 コメント数:  0件
  FAM  |
教えてもらった所からGETしました。
x86は初めてですが、これから勉強する予定です。
新規投稿この投稿にリプライ投稿者削除

47:nasm の逆汗2000/02/15 (火) 16:21 コメント数:  0件
  なべちゃん  |
> 名前が違ったかな。

DOS binary をずっと探してたんですが、
Win binary の中に入ってました(汗)。お手数おかけしました m(__)m

#ただ窓用な気が...
新規投稿この投稿にリプライ投稿者削除

43:逆アセンブラ2000/02/15 (火) 14:04 コメント数:  1件
  へるみ  |
下のFAMさんへの返事のpageの事を差してたんですけど
名前が違ったかな。
expを作れないのでしたら持ってきますが。
新規投稿この投稿にリプライ投稿者削除

より新しい記事へ ← 86 件の投稿中 86件目〜37件目を表示 → より前の記事へ
表示件数: 件/頁 

パスワード:


Copyright(C) 2000 NIFTY Corporation All Rights Reserved.