| 152:Re^2: 雑談2000/03/11 (土) 13:49 |
コメント数： 0件 |
|
へるみ |
|
#Athlon500->600への改造に失敗して結局Athlon600を買い直しました(T_T)
#2カ月の命であった。なむさん。
小次郎さん、鹿原さん
AGIストールやパーシャルレジスタストールの説明ありがとうございます。
なんだか分けが分からなくなりました(^^;
いくら離れてても出るのではチェックしにくいですね。
さ〜さん
>>見ていないです(^^;
>うゎぁ、すいません、流してしてさい
いえいえ、お気になさらずに。相当昔のことですから。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 151:Re: 雑談2000/03/11 (土) 02:58 |
コメント数： 1件 |
|
さ〜 |
http://www1.webnik.ne.jp/%7Esanami/
|
> さ〜さんとこのpageとネタがかぶらないようにしないということで(^^;
僕んとこのページの今後はDirectX関連とのからみに
なりそうな感じです。多分，ゲームを作るのに使うことに
限定されそうなので。
ネタのことはあんまり気にしないでください。
かぶったらかぶったで，あぁ，かぶったね，と。(^^;
どちらかというと僕の方が気にする立場ですけど(笑)
> >MASM関係のページを探していたら見つけました。
> ああ、大昔少し見てました。ただ嫌な思い出があってそれ以来
> 見ていないです(^^;
うゎぁ，すいません，流してください
> >http://member.nifty.ne.jp/kaz1-iwata/
> ではFPU向けの最適化の話題が多いです。最適化コンテストが面白いです。
ゲームにしか使わないのでFPU関連は敷居が高くて・・・。
ちなみに僕は，インラインアセンブラの人で，
つい最近，ようやくループを書くようになった程度のレベルです。
というわけで読み物として楽しんでみます(^^;
そんなわけで今後ともご指導よろしくお願いします＞ALL |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 149:Re^15: Xプライト処理2000/03/11 (土) 02:39 |
コメント数： 0件 |
|
さ〜 |
http://www1.webnik.ne.jp/%7Esanami/
|
> (誤)add edx,8
> (正)add ebx,8
あゎゎゎ、すいません〜。さらに修正したコードを
書きこむの忘れてました(^^;
それはそうと、
> >02の手前でAGIストールは発生しないのでしょうか。
ですが、当然ストールしますね。
これには深い訳があるわけではなく(^^;
単に僕がAGIストールの発生条件を間違えていたためです。
ということで、修正しなきゃと思ってコードを見なおしたら・・・
あれ？回避されてる・・・。う〜ん、偶然とは恐ろしい(笑)
ということで、長くなって申し訳ないのですが、
（おそらく）AGIストールの発生しないバージョンとして
書きこませていただきます(^^;
------------------------------------------------------
00:-u shr ecx, 1
00:-v sub ebx, 8
LP:
01:1u mov eax, [edx]
01:-v add ebx, 8
02:2u mov edi, [edx + 4]
02:1v and eax, 0x7f7f7f7f
03:2u and edi, 0x7f7f7f7f
03:1v add eax, 0x7f7f7f7f
04:2u add edi, 0x7f7f7f7f
04:1v mov esi, [edx]
05:1u or eax, esi
05:2v mov esi, [edx + 4]
06:2u or edi, esi
06:1v and eax, 0x80808080
07:1u shr eax, 7
07:2v and edi, 0x80808080
08:2u shr edi, 7
08:1v add eax, 0x7f7f7f7f
09:1u xor eax, 0x80808080
09:1v mov esi, [ebx]
10:1u and eax, esi
10:2v mov esi, [edx]
11:1u or eax, esi
11:2v add edi, 0x7f7f7f7f
12:2u xor edi, 0x80808080
12:2v mov esi, [ebx+4]
13:2u and edi, esi
13:2v mov esi, [edx+4]
14:2u or edi, esi
14:1v mov [ebx], eax
15:2u mov [ebx+4], edi
15:-v add edx, 8
16:-u dec ecx
16:-v jnz short LP
------------------------------------------------------
そう言えば少し気にしているのですが、
以前に書きこんだ
>透過部分はもとから00です(笑)
の「笑」の部分は自嘲の笑いです(^^;。気にさわられた方が
おりましたらごめんなさい。あぁすっきりした(^^; |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 148:Re^2: まとめてレス2000/03/11 (土) 01:32 |
コメント数： 0件 |
|
鹿原 淳 |
http://www.proc.org.tohoku.ac.jp/~kabbalah/
|
> あと、パーシャルレジスタアクセスはP5系では発生しないので
> 「P6系では」と書いてしまいましたが、i486でも発生するようです。
> ただ、どのくらい離すと発生しなくなるのかを調べきれません
> でしたので、どなたかご存知の方、教えてください。
486では、AGIは1命令間に挟めば出なくなりますが、パーシャルレジスタストー
ルはいくら離せば出なくなるという資料を見たことがありません。
多分、いくら離れてても出るのではないでしょうか(^^;。
ただし、486のパーシャルレジスタストールは組み合わせによって出たり出な
かったりするので、組み合わせを考えれば回避できそうです。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 147:AGI2000/03/11 (土) 00:39 |
コメント数： 0件 |
|
小次郎 |
|
> ところでPPro系CPUではAGIストールってないのですか。
「Intel Architecture Optimization Manual」(24281603.pdf)の3-29に
「Pentium Pro and Pentium II processors incur no penalty for the
AGI condition.」とあるので大丈夫そうです。
> K6系ではなさそう、Athlonではあるようだけど1命令前でなければよい?
> 詳しい方お願いします m(__)m
詳しくはないのですが（笑）
K7のAGIはP5などのAGIと発生原因が違うような気がします。
P5などのAGIはアドレス修飾に使用しているレジスタへのWBを
待つために発生するようですが、K7のAGIは前のアドレス計算が
終了する前に次のアドレス計算を行ったときに発生するようです。
P5タイプのAGIはアドレス計算がOoOで実行されるCPUの
K5/K6系/K7/P6系では発行自体を遅らせることで回避するので
発生しないと思われます。
逆にOoO機構のあるM2系はアドレス計算部がIn-Orderのようなので
AGIが発生しそうな気がするのですが、手持ちの資料などからは
よくわかりませんでした。(^^;
やはり、詳しい方によろしくお願いします。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 146:Re: まとめてレス2000/03/11 (土) 00:24 |
コメント数： 1件 |
|
小次郎 |
|
> アドバイスありがとうございます、皆様。とても勉強になってます。
> i486を中心に最適化したのを書き忘れててごめんなさい(^^;;
> (for TOWNSなものでして.....)
asmソースの先頭に「for MSV PS」と書いてあるのを
見逃してました。(^^;
> >・プリフィックス付き命令のペナルティ（+4）
> ここまで大きいものですか...
「(+4)」というのは、プリフィックス付き命令が4つあったからで、
1つにつき1つのペナルティだとおもいます。
あと、パーシャルレジスタアクセスはP5系では発生しないので
「P6系では」と書いてしまいましたが、i486でも発生するようです。
ただ、どのくらい離すと発生しなくなるのかを調べきれません
でしたので、どなたかご存知の方、教えてください。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 145:Re^14: Xプライト処理2000/03/10 (金) 13:33 |
コメント数： 1件 |
|
へるみ |
|
>02の手前でAGIストールは発生しないのでしょうか。
(誤)add edx,8
(正)add ebx,8
でしたね。
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 144:Re^13: Xプライト処理2000/03/10 (金) 10:59 |
コメント数： 3件 |
|
へるみ |
|
#121への亀レスです
よく見ていないのですが
>lp.
> 01:1u - mov eax, [edx+4]
> 01:-v - add edx, 8
> 02:2u - mov edi, [edx]
02の手前でAGIストールは発生しないのでしょうか。
ところでPPro系CPUではAGIストールってないのですか。
K6系ではなさそう、Athlonではあるようだけど1命令前でなければよい?
詳しい方お願いします m(__)m |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 143:雑談2000/03/10 (金) 10:53 |
コメント数： 2件 |
|
へるみ |
|
>面白く読ませてもらいました。
>ビデオカメラ欲しくなりますね(^^;
さ〜さんとこのpageとネタがかぶらないようにしないと
いうことで(^^;
実はカメラを知人に借りて遊んでいたのですが何故か
壊れていまい(おいおい)、今は持ってないんです。残念。
でもその時は結構リアルタイムエフェクトに凝ってました。
小さいけど多量に演算が必要なのでアセンブリ言語で書く意味が
あって面白いです。
>MASM関係のページを探していたら見つけました。
ああ、大昔少し見てました。ただ嫌な思い出があってそれ以来
見ていないです(^^;
>http://member.nifty.ne.jp/kaz1-iwata/
ではFPU向けの最適化の話題が多いです。最適化コンテストが面白いです。
#忙しくて御無沙汰してるんですが。
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 140:Re: 並列絶対値は可能か?2000/03/09 (木) 22:30 |
コメント数： 3件 |
|
さ〜 |
http://www1.webnik.ne.jp/%7Esanami/
|
> 飽和加算が出来るぐらいだから当然出来ると思いますが、さてどのぐらいの
> ステップで出来るものでしょうか。
> 動機づけはhttp://homepage1.nifty.com/herumi/adv/adv40.html#016です。
面白く読ませてもらいました。
ビデオカメラ欲しくなりますね(^^;
本題。ちょっと余裕がなくてあんまり考えていないのですが、
アイデアの一つとして。
平均値を取ると言うのはどうでしょうか。
0-255の平均値であれば最大127.5ですから
切り捨てて、差を使えば8bitを符号付7bitとして
使えます。
c = (a + b)/2
c = c - a
です。この計算だとcは必ず 127〜-128 になります。
あとは符号ビットからマスクを作って
負の値のbyteだけ反転→+1してやれば
絶対値を得ることは可能です。+1はオーバーフローが
ありえないので素でＯＫですね。
得られた値と閾値の判定は、別の問題としてもいいでしょうか？(笑)
この方法の問題点は切り捨ての値で、
その辺りは考察が必要ですね。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 139:まとめてレス2000/03/09 (木) 19:03 |
コメント数： 3件 |
|
なべちゃん@abk |
|
アドバイスありがとうございます、皆様。とても勉強になってます。
i486を中心に最適化したのを書き忘れててごめんなさい(^^;;
(for TOWNSなものでして.....)
★へるみさん
>取り敢えずloopとrepなしlodsbは止めた方がいいのではないかと。
やはりそうですか(^^;;
★小次郎さん
解析ありがとうございます。
shl/shr がペアリングできないのは知りませんでした（汗
RSBも知りませんでした...(^^;;
>・プリフィックス付き命令のペナルティ（+4）
ここまで大きいものですか...
★かばらさん
>lodsがmov+addの組み合わせより速いのは386だけです。
486だと思ってました（汗）
rep がついたときと勘違いしてた模様です(--;;
---
さっそく家に帰って書き直してみたいと思います。
ちなみに bp を使ったのは、境界をまたぐメモリアクセスがどうかな...って
思ったのですが、chace されてれば関係ないんですかね？
#現在 palette を 32bit table にするか、依頼者に質問中...
#16bit table -> 32bit table の変換するぐらいなら、やめた方がいいですよね？
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 138:Re^3: 256 palette color to 16bit color2000/03/09 (木) 18:31 |
コメント数： 0件 |
|
なべちゃん@abk |
|
> 256色スプライトの32k色画面への埋め込みではなく
> 全画面変換な感じなのでx,y別々にループする必要が
> ないような気が(^^; いかが?>なべちゃん
あ....全然気がつかなかった...その通りです(^^;;
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 137:Re^2: 256 palette color to 16bit color2000/03/09 (木) 15:47 |
コメント数： 1件 |
|
へるみ |
|
>必要なのは小手先の最適化ではなく命令数や
>メモリアクセスを減らしたりといった
>アルゴリズムの再検討です。
256色スプライトの32k色画面への埋め込みではなく
全画面変換な感じなのでx,y別々にループする必要が
ないような気が(^^; いかが?>なべちゃん
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 136:Re^2: 256 palette color to 16bit color2000/03/09 (木) 02:16 |
コメント数： 0件 |
|
鹿原 淳 |
http://www.proc.org.tohoku.ac.jp/~kabbalah/
|
自己レス。
> ・ebpの下位16ビットにアクセスするのにbpを使っていますが、ここは素直に
> or すべきでしょう。486以降ではプレフィクスがつくと遅くなります。プレ
> フィクスによってコードが(1バイトですが)長くなるのも何かアレですし。
う、386だと
mov reg,mem ... 4クロック
or reg,mem ... 6クロック
だから、orにすると遅くなるのか…しかもプレフィクスのペナルティがないし。
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 135:Re: 256 palette color to 16bit color2000/03/09 (木) 01:41 |
コメント数： 3件 |
|
鹿原 淳 |
http://www.proc.org.tohoku.ac.jp/~kabbalah/
|
新山だす。
まだきちんとコードを追ってはいませんが、一見して386専用の雰囲気を受け
ます。とりあえず基本的なあたりだと、
・lodsがmov+addの組み合わせより速いのは386だけです。
・ebpの下位16ビットにアクセスするのにbpを使っていますが、ここは素直に
or すべきでしょう。486以降ではプレフィクスがつくと遅くなります。プレ
フィクスによってコードが(1バイトですが)長くなるのも何かアレですし。
・CALL/RETが対応していないと、RSBを積んだCPUではretの戻り先の予測がで
きなくなります。スタックにループポイントのラベルを積むというのは面白
い手法だとは思いますが…
P5*のペアリングやP6系やK6、Athlon等の細かいことは先達に任せます。
逆に、「386で速く動いてほしい、それ以上のCPUは元が速いからいいじゃん」
というポリシーでいくなら、必要なのは小手先の最適化ではなく命令数やメモ
リアクセスを減らしたりといったアルゴリズムの再検討です。特に、386はメ
モリを読むのが4クロックととっても遅いので…書くのは2クロックなのに
(^^;;
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 134:Re^2: 256 palette color to 16bit color（続き）2000/03/09 (木) 00:41 |
コメント数： 0件 |
|
小次郎 |
|
ためしにP5対象として見積もってみました。
・シフト系やプリフィックス付き命令がUパイプでのみ実行可能で
あることやレジスタの依存関係で13ペア分のデコード
・lodsd命令が2クロック命令であること（+1）
・プリフィックス付き命令のペナルティ（+4）
・アドレス生成インターロックの発生（+2）
より、ループ内部が最短20クロック程度。
対して、変換のテーブルも32ビットで用意するようにして、
すべてを32ビット演算でこなす場合では24命令12ペアで構成でき、
P5上で1ループ最短12クロックというのがとりあえず作れそうです。
P5以降が対象なら32ビット演算のみで作った方が速いかもしれません。
テーブルサイズの増加でキャッシュヒット率が下がりますが。
長文失礼しました。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 133:Re: 256 palette color to 16bit color2000/03/09 (木) 00:41 |
コメント数： 1件 |
|
小次郎 |
|
lodsd ;N01 *1
mov cl,al ;u02 *2
mov dl,ah ;v02 *2
mov bp,[ebx+edx*2] ;U03 *3 *4 *5
shr eax,16 ;U04
shl ebp,16 ;U05
mov bp,[ebx+ecx*2] ;U06 *3
mov [edi],ebp ;u07 *4
mov dl,ah ;v07 *2
mov bp,[ebx+edx*2] ;U08 *3 *4 *5
mov cl,al ;v08 *2
shl ebp,16 ;U09
mov bp,[ebx+ecx*2] ;U10 *3
mov [edi+4],ebp ;u11 *4
add edi,8 ;v12
ret ;v13 *6
*1
へるみさまも仰っておられますが、lodsd命令は
P5系:ペアリング不可の2クロック
P6系:2μOP命令
K6系:longデコード load・alu使用
K7系:VectorPath命令
となっているので、movとaddに分けた方が無難ではないかと
思われます。
ちなみにmov eax,[esi]にするとK6系では遅くなるようなので、
レジスタの割り当てから変更した方がよいかと。
*2
8ビット演算はK6系ではALUXでしか実行できません。
これは大した問題ではないと思いますが、参考までに。
*3
プリフィックス付き命令は
P5系:デコードで1クロックの追加 Uパイプでのみの実行
P6系:デコード時にペナルティが発生
となっているようなので、できれば使わない方がいい命令の
1つだと思います。
*4
パーシャルレジスタアクセスが発生するとP6系では
パーシャルレジスタの書きこみリタイアまで待たされるので
大きなロスになりそうです。
*5
アドレス生成インターロックが発生しそうなので
P5などではペナルティで遅くなりそうです。
*6
CALL以外でスタックに積んだアドレスへのRETは
「Return Stack Buffer」を持つようなCPU（P55C/P6系/K6系/WinChip系）で
問題になりそうです。
詳しいことまでは調べきれませんでしたが、
予想では最初のRETの分岐予測に失敗するというのと
その失敗でRSBを空にしてしまうために一時的にRSB機構が働かなくなる
というペナルティがあるような気がします。
（続く） |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 132:Re: 256 palette color to 16bit color2000/03/08 (水) 21:17 |
コメント数： 0件 |
|
へるみ |
|
まだ良く見てませんがなんか逆アセンブルを阻止するための様なコードですね(^^;
取り敢えずloopとrepなしlodsbは止めた方がいいのではないかと。
loopが速いのはK6..K6-IIIだけですし、repなしstring命令は大抵のCPUでもの凄く遅いです。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 127:Re^6: [esp]か[ebp]か2000/03/04 (土) 21:53 |
コメント数： 0件 |
|
なべちゃん@abk |
|
へるみさん
> 汎用レジスタとしてebpをがんがん使ってると言う意味です。
なるほど、そういうことでしたか。
たしかに貴重な汎用レジスタのひとつですからね...
＃最適化してる途中で、
＃割りこみ禁止して esp 使ったろうか...とか考えた人って居ませんか？
＃さすがにやったことはないんですが...（窓だと無理か） |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 126:Re^5: [esp]か[ebp]か2000/03/04 (土) 18:37 |
コメント数： 1件 |
|
へるみ |
|
>espの書き間違え???
言葉足らずでしたかな。
汎用レジスタとしてebpをがんがん使ってると言う意味です。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 124:Re^3: [esp]か[ebp]か2000/03/04 (土) 11:59 |
コメント数： 3件 |
|
へるみ |
|
> たまに逆汗しますが、espなコンパイラは見たことないですね。
VC++やgccはebpをがんがん使ってますよ(^^;
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 123:Re^2: [esp]か[ebp]か2000/03/03 (金) 19:37 |
コメント数： 4件 |
|
なへちゃん@abk |
|
> ＃esp派のコンパイラってあるのかな？
たまに逆汗しますが、espなコンパイラは見たことないですね。
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 122:Re^13: Xプライト処理2000/03/03 (金) 14:12 |
コメント数： 0件 |
|
さ〜 |
http://www1.webnik.ne.jp/%7Esanami/
|
バグ入りでした。
---------------------------
00:-u - shr ecx, 1
00:-v - sub edx, 4
lp.
01:1u - mov eax, [edx+4]
01:-v - add edx, 8
02:2u - mov edi, [edx]
---------------------------
15:-v - add ebx, 8
---------------------------
と入れ替えてください。
要するに、DWORD２つを同時に操作していることを
忘れてたわけです。かえって最初の00でのペアリングが
できてよかったかも(^^; |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 121:Re^12: Xプライト処理2000/03/02 (木) 16:04 |
コメント数： 5件 |
|
さ〜 |
http://www1.webnik.ne.jp/%7Esanami/
|
まだまだしつこく考えてます。
ふと気がついたのですが、
((a | b) & MASK) | a
っちゅーのもアリですねぇ。なにかに使えないか，考えてます(^^;
あと、気がついたときショックだったんですが、
a = a & MASK
MASK = ~MASK
b = b & MASK
a = a | b
というのは無駄ですね。どこが無駄かと言うと，
a & MASK しなくても透過byteはもともと00です(笑)
ということで
(b & notMASK) | a
でオッケーです。
このおかげでレジスタの占有率が下がりましたので
アンロールして完全ペアリングができました(^^;
見方：最初の数字がカウント，1vというのはDWORDで1セット目に
関する演算でvパイプによる実行，です。
したがって2の系列をすべて削除すれば普通の合成ルーチンが得られます。
--------------------------------------------
00:-u - sub edx, 4
00:-v - nop(dummy)
lp.
01:1u - mov eax, [edx+4]
01:-v - add edx, 4
02:2u - mov edi, [edx+4]
02:1v - and eax, 0x7f7f7f7f
03:2u - and edi, 0x7f7f7f7f
03:1v - add eax, 0x7f7f7f7f
04:2u - add edi, 0x7f7f7f7f
04:1v - mov esi, [edx]
05:1u - or eax, esi
05:2v - mov esi, [edx+4]
06:2u - or edi, esi
06:1v - and eax, 0x80808080
07:1u - shr eax, 7
07:2v - and edi, 0x80808080
08:2u - shr edi, 7
08:1v - add eax, 0x7f7f7f7f
09:1u - xor eax, 0x80808080
09:1v - mov esi, [ebx]
10:1u - and eax, esi
10:1v - mov esi, [edx]
11:1u - or eax, esi
11:2v - add edi, 0x7f7f7f7f
12:2u - xor edi, 0x80808080
12:2v - mov esi, [ebx+4]
13:2u - and edi, esi
13:2v - mov esi, [edx+4]
14:2u - or edi, esi
14:1v - mov [edx], eax
15:2u - mov [edx+4], edi
15:-v - add ebx, 4
16:-u - dec ecx
16:-v - jnz short .lp
--------------------------------------------
最初のsubが泣かせます(笑)。
こんな命令ねぇ〜とか、ここはペアにならないとかあったら教えてください(^^; |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 120:Re: [esp]か[ebp]か2000/03/02 (木) 03:03 |
コメント数： 5件 |
|
小次郎 |
|
> 関数の引数を参照する時みなさんは
> どちらを使いますか?
> 私は殆んどespを使っています。
> 例外的なのはアライメントされたlocal変数を
> 使う時ぐらいです。
使っているコンパイラがebpなので、まるっきり影響を
受けてのebp派です。
＃Bolandコンパイラは大体ebp派だと思うんですが、
＃esp派のコンパイラってあるのかな？
さて、ルーチン関連の話題が出たので便乗して
質問させていただきます。
P6ではPUSHが4μop命令、POPがCOMPLEX命令なので
苦手なような気がします。（重要な命令なのに…）
ということで、レジスタの退避にMOVを使っておいた方が
有利なのかなぁ…と思っているんですが、P6コアのCPUを
持っていないことと、PUSH・POPの方がなれていて楽なので
そのままにしてしまっているのですが、皆様方はどうなさってます？
＃PC Watchの読者アンケートでのP6コアユーザの圧倒的な多さが
＃P6向け最適化は重要だよと圧力をかけるので（笑） |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 119:Re^4: 反転マスクおよび飽和加算のアルゴリズム2000/03/02 (木) 02:33 |
コメント数： 0件 |
|
小次郎 |
|
> >最大2or4の書きこみが遅延で行えるようなので、
> >読みこみをalignしたほうが良いと考えてます。
>
> なるほど。
> ただ私が現在使ってるふる〜いマシンでは
> VRAMアクセス時のalignミスのペナルティがすさまじく
> 大きいため書き込み側をalignしてます。special caseですが(^^;
>
> メモリ…メモリ間では私も測定してないです。
> どうなんでしょうね。やはりCPU/マザーごとに違うのでしょうか。
ワタシはなにも考えずにsrcは読み込みが1回、
dstは読み込みと書き込みが1回ずつなので
単純にアクセス回数の多いdstに合わせてしまっていました。
あと、画面外へはみ出したスプライトの処理に関しても
dstにあわせた方がラクという理由もありますが。
やっぱり、要測定ですよね。こういうときは（笑） |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 118:Re: 反転マスクおよび飽和加算のアルゴリズム2000/03/02 (木) 02:27 |
コメント数： 0件 |
|
小次郎 |
|
> 一つ目。
> 以前にマスクを作るとき、
> (0x7F + a) xor 0x80 で作れます、と報告しました。
> このときは、(a == 0) ? 0xFF : 0x00 です。
> この反転マスクが
> (0x80 - a) xor 0x80 で作れます。
> つまり、(a == 0) ? 0x00 : 0xFF です。
> ときおり役に立ってます(^^;
ワタシは(a+0x7f)^0x80を教わってからは(a+0x7f)^0x7fを使ってました。
（(a+0x7f)^0x80^0xffより）
引き算では痛めにあったので加算だけにしておこうと思って（笑）
> 二つ目。
> 飽和加算で使えます。
> ((a + b) - MASK) or MASK
> で飽和した結果が得られます。
> MASKを引くところがミソです。
> 1byteならa+b < 0x1FE なので、0xFFを
> 引くと必ず ((a + b) - 0xFF) < 0x100 になるので、
> オーバーフローを打ち消せます。
また、勉強になりました。
やっぱり、引き算から逃げていてはダメですね（爆） |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 117:Re^3: 反転マスクおよび飽和加算のアルゴリズム2000/03/01 (水) 16:39 |
コメント数： 1件 |
|
へるみ |
|
>最大2or4の書きこみが遅延で行えるようなので、
>読みこみをalignしたほうが良いと考えてます。
なるほど。
ただ私が現在使ってるふる〜いマシンでは
VRAMアクセス時のalignミスのペナルティがすさまじく
大きいため書き込み側をalignしてます。special caseですが(^^;
メモリ…メモリ間では私も測定してないです。
どうなんでしょうね。やはりCPU/マザーごとに違うのでしょうか。
#昔単なる転送ルーチンでシフトしながら、というのをかいたこと
#あったけど実際は面倒で使わなかったです。
#>http://homepage1.nifty.com/herumi/adv/sample/prog02.html
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 115:Re^2: 分岐予測2000/03/01 (水) 13:53 |
コメント数： 0件 |
|
なべちゃん@abk |
|
DJ☆Uchiさん
>＃ｅｓｐの小文字派です。＜というかＮＡ３８６しか使えない（笑）
おお頑張りますねぇ〜。私は卑怯な手段で逃げました。
けど、ソースは NA386式 で書いて、
コンパイル時にバッチファイルでヘッダとフッダを付加するってことしてます。
あのお手軽さは病み付き（笑）
たしかにマクロもマクロで使いこなせば便利なのでしょうけども... |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 114:Re^2: 反転マスクおよび飽和加算のアルゴリズム2000/03/01 (水) 13:48 |
コメント数： 2件 |
|
さ〜 |
http://www1.webnik.ne.jp/%7Esanami/
|
> ところで見事な8bit colorスプライトルーチンですが、実際に
> 使う時はsrcかdestのどちらかが4byte alignされなくなりますよね。
> その場合はどちらを優先します?
> あるいはsrcを4パターン用意しておくとか(メモリの無駄)
実際に計測してないのでわからないのですが、
最大2or4の書きこみが遅延で行えるようなので、
読みこみをalignしたほうが良いと考えてます。
つまり、L1キャッシュにヒットしない場合、
読み込みではデータが準備できるまで待たされるわけですが、
書き込みでは書きこみ完了を待たずに次の命令にすすめる、
という前提です。ただ、問題は書きこみでキャッシュミスの
ときにキャッシュラインをロードしてくれない場合（P54C/MMX）、
スプライトの端の部分では読みこみを行って合成するため
結局意味ないじゃ〜ん、というところかと。
これらの仮定はすべて↓のサイトの記述に基づいています。
http://www.csl.sony.co.jp/person/fnami/pentopt.htm
#ということはP54C/MMX/Pro/P2でキャッシュを考えてコードを
#分岐させたほうがいい、のですかね？
4パターンのコードをすべて書いておいたり（いけるかも(^^;） |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 113:Re: 反転マスクおよび飽和加算のアルゴリズム2000/03/01 (水) 10:36 |
コメント数： 3件 |
|
へるみ |
|
>何かの役に立つかもしれないので、2つほど。
最近ちょっと雑用(主用?)が多くて更新できませんが、
そのうち遊ばせて頂きます。
ところで見事な8bit colorスプライトルーチンですが、実際に
使う時はsrcかdestのどちらかが4byte alignされなくなりますよね。
その場合はどちらを優先します?
あるいはsrcを4パターン用意しておくとか(メモリの無駄)
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 112:Re^2: 分岐予測2000/03/01 (水) 10:33 |
コメント数： 0件 |
|
へるみ |
|
>Ｋ７の完全ランダム時以外は完敗ですか・・・。(^^;
>Ｋ６に至っては完全ランダムでも分岐した方がいい結果
>が出てますね。
まあ、今回は意図した結果にはなりませんでしたが、
「分岐を減らす」のがよい効果を生むことは多々ありますので
ケースバイケースで対応すべしということですね。
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 111:st0で返す2000/03/01 (水) 10:30 |
コメント数： 0件 |
|
へるみ |
|
かたやまさん
>> あと浮動小数もポインタ渡しですね。
>> #High-Cでst0に返すオプションがあれば...
> Use_x87_for_resultというオプションがあります。
うろ覚えですが、以前「おおあるやん」と思って試したら
全然変わらなかった記憶が(^^;
#もう一度試してみます。
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 110:反転マスクおよび飽和加算のアルゴリズム2000/03/01 (水) 04:47 |
コメント数： 5件 |
|
さ〜 |
http://www1.webnik.ne.jp/%7Esanami/
|
どうも〜、さ〜 です。
何かの役に立つかもしれないので、
2つほど。
一つ目。
以前にマスクを作るとき、
(0x7F + a) xor 0x80 で作れます、と報告しました。
このときは、(a == 0) ? 0xFF : 0x00 です。
この反転マスクが
(0x80 - a) xor 0x80 で作れます。
つまり、(a == 0) ? 0x00 : 0xFF です。
ときおり役に立ってます(^^;
二つ目。
飽和加算で使えます。
((a + b) - MASK) or MASK
で飽和した結果が得られます。
MASKを引くところがミソです。
1byteならa+b < 0x1FE なので、0xFFを
引くと必ず ((a + b) - 0xFF) < 0x100 になるので、
オーバーフローを打ち消せます。
考えたコードはどれもこれも一つのレジスタに連続アクセスする
ようなものばかりで、なんだかなぁと思ってましたが、よくよく
考えてみると、アンロールして並列動作をペアリングしやすく
なるのでした。ということで開き直ってます(^^;
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 109:Re^3: [esp]か[ebp]か2000/03/01 (水) 00:02 |
コメント数： 1件 |
|
かたやま |
|
へるみさん
> Mamiyaさん
> >多いときは構造体のアドレス渡し
> 構造体はコンパイラによって方式が違う時があるので
> 私もポインタ渡しにしてます。
> あと浮動小数もポインタ渡しですね。
> #High-Cでst0に返すオプションがあれば...
Use_x87_for_resultというオプションがあります。
HC17UM.DOCの中に説明が記述してありますが、
これで浮動小数点関数の返り値がst0に返らないでしょうか？
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 108:Re: 分岐予測2000/02/29 (火) 22:36 |
コメント数： 2件 |
|
DJ☆Uchi |
http://homepage1.nifty.com/uchi/
|
わざわざ測定までしていただいて、ありがとうございます。
> これから分かることは、
> 範囲が完全なランダムでないときは下手に分岐しない様な
> コードを書くよりは素直に分岐するコードを書いたほうがいい、
> ということでしょうか。
そのようですね。
Ｋ７の完全ランダム時以外は完敗ですか・・・。(^^;
Ｋ６に至っては完全ランダムでも分岐した方がいい結果が出てますね。
６ステージというパイプラインの短さと予測精度がＫ７より上なのが効いてるのかな？
早速、元に戻すことにします。
＃ｅｓｐの小文字派です。＜というかＮＡ３８６しか使えない（笑）
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 107:分岐予測2000/02/29 (火) 11:34 |
コメント数： 3件 |
|
へるみ |
|
以前のこっくりさんのサウンドクリッピングの簡単な実験をしてみました。
もとのコードはこれ。
>*src = ( *src > 32767 ) ? 32767 : ( *src < -32768 ) ? -32768 : *src;
test1: 普通の分岐(ただし殆んどは分岐しないことを想定)
<pre>
proc test1
mov edx,[esp+4]
mov ecx,[esp+8]
jmp short .lp
align 16
.lp:
mov eax,[edx]
add edx,4
cmp eax,32767
jg short .large
cmp eax,-32768
jl short .small
.next:
dec ecx
jnz short .lp
ret
align 16
.large:
mov dword [edx-4],32767
jmp short .next
.small:
mov dword [edx-4],-32768
jmp short .next
</pre>
test2: 分岐しないコード
<pre>
proc test2
push ebx
push esi
%assign _P 4*2
mov edx,[esp+_P+4]
mov ecx,[esp+_P+8]
jmp short .lp
align 16
.lp:
mov eax,[edx]
add edx,4
mov ebx,eax
sar ebx,31
xor eax,ebx
sub eax,32767
sbb esi,esi
and eax,esi
add eax,32767
xor eax,ebx
mov [edx-4],eax
dec ecx
jnz short .lp
pop esi
pop ebx
ret
</pre>
8192個の配列に対して
<pre>
for K6-2
test1 test2
48k 96k if ( rand() % 7 ) - 5; -(1)
46k 102k if ( rand() % 65537 ) - 30000; -(2)
80k 97k if rand(); -(3)
for K7
28k 57k if ( rand() % 7 ) - 5;
33k 57k if ( rand() % 65537 ) - 30000;
111k 57k if rand();
</pre>
でした。
これから分かることは、
範囲が完全なランダムでないときは下手に分岐しない様な
コードを書くよりは素直に分岐するコードを書いたほうがいい、
ということでしょうか。 |
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 106:Re^3: [esp]か[ebp]か2000/02/28 (月) 17:10 |
コメント数： 0件 |
|
なべちゃん@abk |
|
へるみさん
>>ところで、この掲示板ってログとか保存してるんですか？
>全然考えてませんでした。
>そうですね。100件を超えたようですし、残しておきます。
資料価値の高い発言も多いので、ログあると便利かなぁ...とか
＃ありがたいです
> 私はあまり文明の力(?)に頼ると別のアセンブラにしたとき困る
> かもしれないので使ってません(^^;
私は NA386 でアセンブルできるように書いてます（アホ
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
| 104:Re^2: [esp]か[ebp]か2000/02/25 (金) 20:31 |
コメント数： 4件 |
|
へるみ |
|
Mamiyaさん
>多いときは構造体のアドレス渡し
構造体はコンパイラによって方式が違う時があるので
私もポインタ渡しにしてます。
あと浮動小数もポインタ渡しですね。
#High-Cでst0に返すオプションがあれば...
なべちゃん
>ところで、この掲示板ってログとか保存してるんですか？
全然考えてませんでした。
そうですね。100件を超えたようですし、残しておきます。
#まだフォローしてない記事もあるし。
>レジスタを増やしたとき調整があまりに面倒なので、
>ebp 使ってます
NASMの疑似命令+マクロの自動処理に任せてる人もいるようです。
#午後のnasm.h参照
私はあまり文明の力(?)に頼ると別のアセンブラにしたとき困る
かもしれないので使ってません(^^;
|
|
新規投稿｜この投稿にリプライ｜投稿者削除
|
|