せっかちな人々(まったりも可)

どんなささいなことでも構いません.
面白い最適化のアイデアがありましたら書き込んで下さい.
無論雑談も大歓迎です.


 
名前
 
タイトル
 
e-mail
 
URL
 
パスワード
 
cookie
有効期限:10 日
メッセージ



  次へ  ← 608-554 / 604 件表示 →  前へ
件/頁   
 



608. FPUコントロール へるみ  2001/11/08 (木) 17:13
>asm volatile("fldcw __round_down");
話は少しずれますがVC++だとデフォルトが0で割ったときに
例外を発生させないので時限爆弾的にバグが発覚することが
ありました。そういうのは全部発生させるようにしておいたほうが
安全かも。




607. gcc on x86だと dsk  2001/11/07 (水) 17:01
int const __round_down = 0x173a;

asm volatile("fldcw __round_down");

としておいてから、それぞれの数字を
32767.4960375F
65535.9960375F
とすると2.も解決します。





606. floatは銀行家丸めするんですね dsk  2001/11/07 (水) 16:38
↓の数値は切り捨てを仮定してやってました。
正しくは32767.0Fと65535.0Fにしてください。
そうすれば銀行家丸めの影響、(元の2.の問題)のみが
残ります。でも銀行家丸めのほうが良い、という考え方も
ありかもしれないのでこれでもいいかも。

IEEE754は丸め方を指定することが出来たような気がする。
これを用いれば2.の問題に関しても適切な答えが作れると
思う。





605. なるほど へるみ  2001/11/07 (水) 13:00
floatレベルで先にクリッピングですか。
それだと確かに大きさの制限がないですね。




604. 65536より1つ小さい数は dsk  2001/11/06 (火) 13:06
65535.99609375F
でした。
簡単な実験では floatの 0.0F は全てのビットが0でした。

#include <stdio.h>
main() {
 float f = 0.0F;
 int i = *(int*)&f;
 printf("%d\n", i);
 return 0;
}





603. 高速版 dsk  2001/11/06 (火) 12:33
・intが4バイト2の補数表現
・shortが2バイト2の補数表現
・floatがIEEE754単精度
・floatの足し算が高速
・IEEE754単精度で全てのビットが0のとき0.0Fを表す
 ↑自分で調べろ、と言われそうですが
が成り立ってたら1. 3. が解決されるのですが....

short fast( float f ){
 int sign;
 short ret;
 
 /* clipping */
 f -= 32767.5F;
 sign = *(int*)&f >> 31
 *(int*)&f &= sign;
 f += 65535.99F; /* 65536より1つ小さい数のつもり*/
 sign = *(int*)&f >> 31
 *(int*)&f &= ~sign;
 
 /* convert */
 f += 8388608.0F;
 ret = *(int*)&f & 65535;
 ret -= 32768;
 
 return ret;
}




602. 某友人のマシンがαなんだよな dsk  2001/11/05 (月) 10:09
巧くいく条件は
ビッグエンディアンまたはsizeof(int) == sizeof(float)
となりますね。
最新のチップ上の処理系だと
sizeof(int) == 8, sizeof(float) ==4
でリトルエンディアンはありそうだけど。




601. SPARCではOKでした。 へるみ  2001/11/02 (金) 16:24
> intが2bytesの処理系でリトルエンディアンだと巧くいかない
> のかな?
sizeof(float)=sizeof(int)=4は仮定したいです...




600. ん?アルファは逆に巧くいくのか? dsk  2001/11/02 (金) 11:30
intが2bytesの処理系でリトルエンディアンだと巧くいかない
のかな?




599. そ、そうだね dsk  2001/11/02 (金) 11:24
intとfloatのサイズが合っていれば(☆)エンディアン違っても
大丈夫だね。alphaとかだと巧くいかないんじゃないかな?と思
ったんだけどどうなのかな?。

(☆)sizeof(int) == sizeof(float)




598. え、? へるみ  2001/10/31 (水) 21:22
>endian依存だし.... > sign = *(int*)&f;
floatがIEEE-754になってる限りendianには関係無いと思うけど違う?
少なくともPPCとx86では動いてるけど。
int x=[B3:B2:B1:B0]がB0:B2:B1:B3
みたいにmemoryに格納されてれば知らんが(^^;




597. うー dsk  2001/10/31 (水) 17:26
endian依存だし.... > sign = *(int*)&f;
それはいいとして
ANSI( or ISO9899 )だと INT_MIN, SHRT_MIN は
-32767 以下であることしか保証されていない訳だから
3.はあきらめてもいいんじゃないかな?
2.は銀行家丸めするの?
1.はそういうデータは捨てたほうが身のため?




596. FFTのbitreverse へるみ  2001/10/31 (水) 15:48
しばらく前bitreverseをテーブル引きしない方法の話題がありました(No.519〜)。
そんときの方法を実際に使ってみましたが速度は変わらなかったです>gogo3.07
あまりにせこい技だったか。




595. clippingしてPCMに出力 へるみ  2001/10/31 (水) 15:38
iDCTによるfloatの出力結果をshortに変換するコード
short normal( float f ){
int ret;
if( f > 0 ){
ret = (int)(f + 0.5F);
return (ret > 32767) ? 32767 : ret;
}else{
ret = (int)(f - 0.5F);
return (ret <-32768) ?-32768 : ret;
}
}
高速版
short fast( float f ){
int mask, sign, x;
sign = *(int *)&f;
f = (float)fabs(f) + (1<<23);
x = *(int *)&f & ((1<<23)-1);// x = (int)abs(f);
sign >>= 31;// sign = (f<0) ? -1 : 0;
x -= 32767;
mask = x >> 31;// mask = (x < 32767) ? -1 : 0;
x = (x & mask) + 32767;// x = (x < 32767) ? x : 32767;
return (x ^ sign) - sign;
}
差異
1. |f|>2^23のとき変
2. f=2n+0.5の時の丸め処理ちょっと違う
3. -32768以下が-32767になる
誤差を考えるとどれも許容範囲なんですが3のうまい解決法ってあるのかしらん。




594. なるほど dsk  2001/10/30 (火) 15:18
色々あるのね>cygwin sshdまであってびっくり。
どうも cmd.exe と command.exe(Dos窓)の合わせ技一本
みたいですね。




593. Re^4: MSの人は必死でデバグしたのか? こばやし  2001/10/30 (火) 14:36
> > これとは違いますが rxvt 上で cmd.exe を起動して(cmd.exe 自身
> > の window は作られない)その中で実行してみたけど、落ちませんで
> > した。
> rxvt上で cmd.exe を起動? rxvt for win?

そうです。cygwin に含まれているものをそのまま使いました。

> > 同じことを teraterm で localhost に telnet して実行してみた
> > けどやっぱり落ちない。
> Server入れてるの?Workstaion版だとConnection refused
> になると思うけど....

ごめんなさい説明不足でした。Workstation 版ですけど cygwin の inetd から telnetd を動かしてそこに teraterm で localhost から login してさらにその中で cmd.exe を起動しました。

http://memo.st.ryukoku.ac.jp/archive/200110.month/1765.html

という話があったので、window を開かなくても cmd.exe が介在すればとにかく落ちるのかな? と思って試してみました。




592. Re^3: MSの人は必死でデバグしたのか? dsk  2001/10/30 (火) 13:25
どういう実験をしたのでしょうか?

> これとは違いますが rxvt 上で cmd.exe を起動して(cmd.exe 自身
> の window は作られない)その中で実行してみたけど、落ちませんで
> した。
rxvt上で cmd.exe を起動? rxvt for win?


> 同じことを teraterm で localhost に telnet して実行してみた
> けどやっぱり落ちない。
Server入れてるの?Workstaion版だとConnection refused
になると思うけど....




590. Re^2: MSの人は必死でデバグしたのか? こばやし  2001/10/29 (月) 20:00
> dos窓@win2kからLinuxにtelnetしてdanger.cをコンパイル実行
> してみたが特に何も起こらず。telnetプロトコルは\bや\tを
> 吸収しないはずだが......

これとは違いますが rxvt 上で cmd.exe を起動して(cmd.exe 自身
の window は作られない)その中で実行してみたけど、落ちませんで
した。

同じことを teraterm で localhost に telnet して実行してみた
けどやっぱり落ちない。




589. Re: MSの人は必死でデバグしたのか? dsk  2001/10/29 (月) 18:48
> 私は昨日TOWNS上に(別にTOWNSである必然性はないんだけど(^^;)
> telnetdもどきをつくってWinからloginしたときに例の文字列を
> 表示させて落とすことを試してみたんですがうまく行きませんでした。
> タイミングの問題なのかな。
dos窓@win2kからLinuxにtelnetしてdanger.cをコンパイル実行
してみたが特に何も起こらず。telnetプロトコルは\bや\tを
吸収しないはずだが......





587. MSの人は必死でデバグしたのか? へるみ  2001/10/29 (月) 18:13
> それって、どのように落ちたのでしょう?
やはりリブートをエミュレーションするんですかね。

私は昨日TOWNS上に(別にTOWNSである必然性はないんだけど(^^;)
telnetdもどきをつくってWinからloginしたときに例の文字列を
表示させて落とすことを試してみたんですがうまく行きませんでした。
タイミングの問題なのかな。




586. Re^2: 2000くらっしゃー 長船  2001/10/29 (月) 17:42
件のバグはSP3で直るそうです。
M$のNT系サービスパック係からの直接情報です (^^;

>  Pocket Post PetのCE化みたいに
> MSX箱もXP化とかできるとおもしろいんですがね〜

XboxはDCみたいなCD(DVD?)側にOSが焼きこまれる形になると
思われるので、XP化は無理なんじゃないですかね?
逆にWindows上でXboxソフトを動かすソフトは早々に現れると
思いますが‥‥。




585. Re^4: お前はもう、死んでいる dsk  2001/10/29 (月) 14:04
> 私はやっていないのですが、Net News の方で、Windows2000 on
> VMware で落ちたという報告がありました。
それって、どのように落ちたのでしょう?
VMwareだけが落ちたのか全体が落ちたのか?
#VMwareをよく分かってないので無意味な質問かも知れません




584. Re^3: お前はもう、死んでいる 小柳 雅明  2001/10/27 (土) 09:24
> ところで小柳さんって確かVMwareをもっていらっしゃいましたよね。
> エミュレータ上だとどうなるんでしょうか。

私はやっていないのですが、Net News の方で、Windows2000 on
VMware で落ちたという報告がありました。




582. えーと、くだなないことですが dsk  2001/10/26 (金) 10:00
hung は hang の過去形あるいは、is hung upとして現在完了
なので、「お前はもう死んでいる」と言ったのですが。
綴り間違いがセキュリティホール memo メーリングリスト
でも伝播してるよ....





581. Re: 2000くらっしゃー 小次郎  2001/10/26 (金) 00:54
 CScript上でVBSとJScriptでやって見ましたが、
残念ながらクラッシュしませんでした。
#残念なのか?(笑)
 やりかたがわるかったかなぁ。
 でも、ループにしても1回しか回らないところを見ると
CScript.exeはしっかり死んでるのかな。

> 同僚の協力のもと、幾つか実験してみました。
> PascalとDelphi6も落ちました。2000とXPだけでなくNT4でも
> 同様に落ちました。
> どうやら「"\t\b\b"」の無限ループがガンなようです。

 NT系限定なことをみるとCMD.EXEのバグですかねぇ。

> ひょっとしてXboxでも落ちる??

 Pocket Post PetのCE化みたいに
MSX箱もXP化とかできるとおもしろいんですがね〜




580. 将来のネットワークゲームは へるみ  2001/10/25 (木) 23:29
互いに怪しい文字列を送りつけて相手のマシンを撃墜する
ものになるのかしらん(^^; >Xbox




579. 2000くらっしゃー 長船  2001/10/25 (木) 16:04
同僚の協力のもと、幾つか実験してみました。
PascalとDelphi6も落ちました。2000とXPだけでなくNT4でも
同様に落ちました。
どうやら「"\t\b\b"」の無限ループがガンなようです。

ひょっとしてXboxでも落ちる??




578. Re^2: お前はもう、死んでいる へるみ  2001/10/25 (木) 15:48
> 以下のスレッドで現在議論されています。
ありがとうございます。
echoでも落ちるようですね。私も試していたんだけどなあ...
ところで小柳さんって確かVMwareをもっていらっしゃいましたよね。
エミュレータ上だとどうなるんでしょうか。




577. Re: お前はもう、死んでいる 小柳 雅明 [URL]  2001/10/25 (木) 14:06
> 見たいで面白いな。> hung up
> というのは置いといてBCCとVC++で同じバグだったりして。
> cygwinもDOS窓にラッピングしているだけでしょ。
> だからコンソールとしての質は同じで、コンソールのバグと
> ライブラリのバグが重なって......でも何故リブート?

fj.os.ms-windows.programming
でこの現象を知って
セキュリティホール memo メーリングリスト
へ投稿しました。
http://memo.st.ryukoku.ac.jp/archive/200110.month/thread.html
の「コンソールプログラムで Windows 2000 がハングアップする」
以下のスレッドで現在議論されています。





576. お前はもう、死んでいる dsk  2001/10/25 (木) 13:45
見たいで面白いな。> hung up
というのは置いといてBCCとVC++で同じバグだったりして。
cygwinもDOS窓にラッピングしているだけでしょ。
だからコンソールとしての質は同じで、コンソールのバグと
ライブラリのバグが重なって......でも何故リブート?





575. Re: cygwinのコンソールから へるみ  2001/10/24 (水) 12:17
>hung up -> hang up
どっちか分からなかったのだけどはずれたか(^^;

>コンソールの問題よりライブラリの問題か?
BCCとVC++は違うライブラリを使ってると思うのだけど
同じDLLを呼んでるのかな。

あとMS-DOS用コンパイラで作ったものだと大丈夫みたい。




574. cygwinのコンソールから dsk [URL]  2001/10/24 (水) 10:56
DLしたdanger.exeを起動するとcygwinのコンソールにWarning
が沢山表示され、そのままリブートしたよ。

コンソールの問題よりライブラリの問題か?




573. ところで dsk [URL]  2001/10/24 (水) 10:34
hung up -> hang up




572. Re: ???? へるみ  2001/10/23 (火) 21:42
> cygwin/gcc on Win2k では大丈夫。
consoleが独自だからかなあ。

rubyでは落ちました。

>for i in (1..100)
> printf "hung up\t\t\b\b\b\b\b\b"
>end

PS.
残念ながら(?)echoでは落ちませんでした。:)




571. DLしたdanger.exeだと dsk [URL]  2001/10/23 (火) 19:32
一発でリブートしました。




570. ???? dsk [URL]  2001/10/23 (火) 19:25
cygwin/gcc on Win2k では大丈夫。
普通に表示し続けるだけでC-Cで終わる。




568. Re: 6時間が消えた... へるみ  2001/10/23 (火) 13:24
ここまで追い詰めました。
#include <stdio.h>

int main(void){
for(;;) printf("hung up\t\t\b\b\b\b\b\b");
return 0;
}
Win2k/WinXpどちらでも落ちます。VC++/BCCどちらでも落ちます。




567. 6時間が消えた... へるみ  2001/10/23 (火) 01:41
最近更新してないので誰も見てないかもしれませんが(汗)
>http://homepage1.nifty.com/herumi/soft/himitsu/danger.zip
をコマンドプロンプト or 直接実行するとWin2kがハング
したりリブートしたりします。
もとは1万行ほどのプログラムからここまで絞る間に
リセットすること数知れず。みなさんのところでも起こります?
#win98では大丈夫な模様。




565. Re^2: メモリアクセス EZI  2001/08/24 (金) 20:25
> どんな状況でmovqntqより速いんでしょうか。
あくまでもmovntqで速度の出ない場合です。
連続したメモリへの書き込みは圧倒的にmovntqの方が速いです。

prefetch系の命令はPentiumの場合、速くなってもチョットなので
殆ど解らないかも。
逆に命令を入れた分だけ遅くなることも。
Athlonだとバージョン?によって速い時と遅い時があります。
今度新しく出る奴は勝手にprefetchしてくれるらしいので
ますますprefetch命令は使えなくなるかも・・・。




564. Re: メモリアクセス へるみ  2001/08/24 (金) 13:08
> movq [edi],mm0
> prefetcht0 [edi+nn]
> とかやるとちょっと速くなります。
どんな状況でmovqntqより速いんでしょうか。
よくあることならmovntqの存在意義が(^^;
というか私はprefetch関連は使って速くなったことが無いので
あんまり信用していないです。

2次元配列の転置は例えば8x8の小ブロックずつ行うとキャッシュの
ヒット率が高くなるのでは?





563. メモリアクセス EZI  2001/08/23 (木) 19:51
最近気づいたのですが書き込みにもプリフェッチは有効なんですね。
movntqでの書き込みで速度が出ないルーチンの場合、
movq [edi],mm0
prefetcht0 [edi+nn]
とかやるとちょっと速くなります。
movntq [edi],mm0
prefetchnta [edi+nn]
の方が速かったかな?
一部のAthlonでは逆に遅くなったりしたけど・・・。




562. Re^2: 縦方向への書き込み Shin  2001/08/20 (月) 20:59
> mmレジスタぎりぎり全部使っちゃいますけど、
> 待避スペースを作れば、punpck?dqとmovqも使えますし。

ぉぉう。よく考えれば待避スペースなんていらないや。
よく考えなくてもいらないや。
本当に一度にやらずとも
ループ内で四行ずつ二回に分ければ良かったんだ・・・・
失礼しましたm(_ _)m。

#あっ、ハードディスクが嘘ついてる〜(T_T)




561. Re^2: 縦方向への書き込み 剣聖炎羅 [URL]  2001/08/20 (月) 07:15
> IA-32のキャッシュは一度に32バイトずつメインメモリに
> アクセスするので、これをできる限り有効に使うために、
> $tmmmx_xloopで一度にpSrcから二行ずつコピーしているのをやめ、
> 一気に八行ずつコピーするように変えてみてはどうでしょうか。

例によってウェーブレット変換ルーチンで使ってるので、マトリクスの大きさが最低でも4の倍数になってしまいます。
って、あ!そうか。1つ上のレベルだと8の倍数になってるから関数を別にすれば良いんだ^^;;




560. Re: 縦方向への書き込み Shin  2001/08/20 (月) 00:32
> 行列(2bytePack-shortな2次元配列)を転置するコードを
> MMXで書いてみましたが、予想通り遅いです。
> これは書き込みの際の手間(命令数の増加)なのか、そもそも
> 縦に書き込むことが遅いのかどちらなんでしょうか?

キャッシュでかなり損していそうです。
pDestの方でキャッシュがほとんど効いていないのではないかと。

IA-32のキャッシュは一度に32バイトずつメインメモリに
アクセスするので、これをできる限り有効に使うために、
$tmmmx_xloopで一度にpSrcから二行ずつコピーしているのをやめ、
一気に八行ずつコピーするように変えてみてはどうでしょうか。

mmレジスタぎりぎり全部使っちゃいますけど、
待避スペースを作れば、punpck?dqとmovqも使えますし。

これで、少しは速くなると思います。
16バイトへのアラインメント合わせも忘れないでくださいね。

(注)MMX命令マシンが壊れちゃって実験できていません。(T_T)


#最近のボトルネックはメモリの遅さのようで、
#IA-64もスタック on レジスタ(?)みたいなの積んでますねぇ。
#IA-32にも欲しい(^^。
#おっと、そのまえにレジスタ増やせ〜!こればっかり(^^;;。

駄文失礼しました。では。




559. Re: ハードより?の話が出てるのでついでに^^; Shin  2001/08/19 (日) 22:48
> x86系のCPUでページ境界をまたぐとき、
> 物理アドレスが連続してたほうが早かったりするんでしょうか。
>
> 386だとページング無効にするとちょっと早いらしいけど、
> 最近のはパイプライン深いから関係ないんですかね(^^;;

それは物理アドレスが連続しているためではなく、
ページング管理用のメモリを参照しないためだと思います。
今のx86でもページング無効にするとごく僅かに速くなりそうな気がします。
キャッシュが効くのでほんとにほんとにごく僅かでしょうけど(^^。

でもそうだとすると386でも「ちょっと」というぐらいも速くならないような気が・・・・・・
もっと何かあるのかな?

#レジスタは切望します(^^。
#IA-64がうらやましい・・・・
#x86-64もちょっとは増えてたなぁ・・・うふふ(^^;;




558. Re: メモリ Hash  2001/08/14 (火) 01:00
> えらいマニアックな話題ですね(^^;。
> そのへんに触れたものって見たこと無いです。

まともなロジックは思いつかないので、簡単お気楽に早くなる方法はないかなと(^^;;

> >最近のはパイプライン深いから関係ないんですかね(^^;;
> レジスタが少ないくせにどんどん深くなるから困ります(^^;

ほしいですねぇレジスタ。

レジスタ使いまわしすぎて「今、EBXに入ってるのなに?(;_;)」
とかいいつつソースを遡り、「お、なるほど。」と納得して戻ってくると
今度は「EDXは何?」と無限ループにはまってしまいますし(笑)

キャッシュを信じて潔くメモリにおいときゃいいんですけどね。





557. 縦方向への書き込み 剣聖炎羅 [URL]  2001/08/14 (火) 00:57
レジスタは、現在のCPUではあまり関係がなかったんですね^^;

 const DWORD xloopnum = ((WORD)((xSize>>2)-1))<<16;
 const DWORD yloopnum = (WORD)((ySize>>1)-1);
 const DWORD xSizeX2 = xSize*2;
 const DWORD ySizeX2 = ySize*2;

  mov esi, dword ptr [yloopnum]
  mov eax, [pSrc]
  mov ecx, [ySizeX2]
  mov edi, eax
  add edi, [xSizeX2]
  mov ebx, [pDest]
 $tmmmx_yloop:
  push ebx
  or esi, dword ptr [xloopnum]
  lea edx, [ebx+ecx]
 $tmmmx_xloop:
  movq mm0, qword ptr [eax]
  movq mm2, mm0
  movq mm1, qword ptr [edi]
  punpcklwd mm0, mm1

  punpckhwd mm2, mm1
  movd [ebx], mm0
  psrlq mm0, 32
  movd [edx], mm0

  movd [ebx+ecx*2], mm2
  psrlq mm2, 32
  movd [edx+ecx*2], mm2

  add eax, 8
  lea ebx, [ebx+ecx*4]
  add edi, 8
  lea edx, [edx+ecx*4]
 //$tmmmx_xloop_end:
  sub esi, 0x10000
  jns $tmmmx_xloop

 //$tmmmx_yloop_end:
  pop ebx
  add eax, [xSizeX2]
  add ebx, 4
  add edi, [xSizeX2]
  sub esi, 0xffff0001
  jns $tmmmx_yloop

行列(2bytePack-shortな2次元配列)を転置するコードを
MMXで書いてみましたが、予想通り遅いです。
これは書き込みの際の手間(命令数の増加)なのか、そもそも
縦に書き込むことが遅いのかどちらなんでしょうか?




556. メモリ へるみ  2001/08/11 (土) 16:09
>x86系のCPUでページ境界をまたぐとき、物理アドレスが
>連続してたほうが早かったりするんでしょうか。

えらいマニアックな話題ですね(^^;。
そのへんに触れたものって見たこと無いです。

>最近のはパイプライン深いから関係ないんですかね(^^;;
レジスタが少ないくせにどんどん深くなるから困ります(^^;




555. ハードより?の話が出てるのでついでに^^; Hash  2001/08/10 (金) 18:29
x86系のCPUでページ境界をまたぐとき、
物理アドレスが連続してたほうが早かったりするんでしょうか。

386だとページング無効にするとちょっと早いらしいけど、
最近のはパイプライン深いから関係ないんですかね(^^;;

まぁ、DOSとかでないと連続した領域を確保するのは難しいんでしょうけどね(^^;




554. Re: レジスタによって、速度は違いますか? へるみ  2001/08/09 (木) 10:20
基本的に差は無いです。
大昔MS-DOS全盛のころのx86 real modeでは
bx, di, si, bpが汎用レジスタではなかったことの
名残だと思います。

細かいことを言うと
(A) test ecx, 1
(B) mov eax,[esp+4]
(C) mov esi,[ebp+ecx*2]
よりは
(A') test eax, 1
(B') mov eax,[ebp+4]
(C') mov esi,[edi+ecx*2]
の方が1byte小さくなります。
コードが小さいと(少しだけ)コードの密度が上がりますから
デコーダが(少しだけ)速く処理できるかもしれません。
(A)については全般にeaxを使ったbit演算命令は他のレジスタを
使うよりは1byte小さくなることがあります。
(B)については関数の引数のアクセスのためにebpが用意された
からかなあ。
(C)についてはIntelの複雑怪奇なアドレス生成規則のせいです(^^;
あとは、今のx86 Cコンパイラに関数の呼び出し前後で
esi,edi,ebxなどを変更してはいけないというルールが
あるからでしょう。



 

  次へ  ← 608-554 / 604 件表示 →  前へ
件/頁   

 
password:
http://homepage.nifty.com/mboard/
Copyright(C) 2001 NIFTY Corporation All Rights Reserved.