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

int const __round_down = 0x173a;

asm volatile("fldcw __round_down");

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

↓の数値は切り捨てを仮定してやってました。
正しくは32767.0Fと65535.0Fにしてください。
そうすれば銀行家丸めの影響、(元の２．の問題）のみが
残ります。でも銀行家丸めのほうが良い、という考え方も
ありかもしれないのでこれでもいいかも。

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

floatレベルで先にクリッピングですか。
それだと確かに大きさの制限がないですね。

65535.99609375F
でした。
簡単な実験では floatの 0.0F は全てのビットが0でした。

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

・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;
}

巧くいく条件は
ビッグエンディアンまたはsizeof(int) == sizeof(float)
となりますね。
最新のチップ上の処理系だと
sizeof(int) == 8, sizeof(float) ==4
でリトルエンディアンはありそうだけど。

> intが2bytesの処理系でリトルエンディアンだと巧くいかない
> のかな？
sizeof(float)=sizeof(int)=4は仮定したいです...

intが2bytesの処理系でリトルエンディアンだと巧くいかない
のかな？

intとfloatのサイズが合っていれば（☆）エンディアン違っても
大丈夫だね。alphaとかだと巧くいかないんじゃないかな？と思
ったんだけどどうなのかな？。

（☆）sizeof(int) == sizeof(float)

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

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

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

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のうまい解決法ってあるのかしらん。

色々あるのね＞cygwin　sshdまであってびっくり。
どうも cmd.exe と command.exe(Dos窓)の合わせ技一本
みたいですね。

> > これとは違いますが 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 が介在すればとにかく落ちるのかな? と思って試してみました。

どういう実験をしたのでしょうか？

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


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

> dos窓@win2kからLinuxにtelnetしてdanger.cをコンパイル実行
> してみたが特に何も起こらず。telnetプロトコルは\bや\tを
> 吸収しないはずだが......

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

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

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

> それって、どのように落ちたのでしょう？
やはりリブートをエミュレーションするんですかね。

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

件のバグはSP3で直るそうです。
M$のNT系サービスパック係からの直接情報です (^^;

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

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

> 私はやっていないのですが、Net News の方で、Windows2000 on
> VMware で落ちたという報告がありました。
それって、どのように落ちたのでしょう？
VMwareだけが落ちたのか全体が落ちたのか？
＃VMwareをよく分かってないので無意味な質問かも知れません

> ところで小柳さんって確かVMwareをもっていらっしゃいましたよね。
> エミュレータ上だとどうなるんでしょうか。

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

hung は hang の過去形あるいは、is hung upとして現在完了
なので、「お前はもう死んでいる」と言ったのですが。
綴り間違いがセキュリティホール memo メーリングリスト
でも伝播してるよ....

　CScript上でVBSとJScriptでやって見ましたが、
残念ながらクラッシュしませんでした。
＃残念なのか？（笑）
　やりかたがわるかったかなぁ。
　でも、ループにしても1回しか回らないところを見ると
CScript.exeはしっかり死んでるのかな。

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

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

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

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

互いに怪しい文字列を送りつけて相手のマシンを撃墜する
ものになるのかしらん(^^; >Xbox

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

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

> 以下のスレッドで現在議論されています。
ありがとうございます。
echoでも落ちるようですね。私も試していたんだけどなあ...
ところで小柳さんって確かVMwareをもっていらっしゃいましたよね。
エミュレータ上だとどうなるんでしょうか。

> 見たいで面白いな。＞ 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 がハングアップする」
以下のスレッドで現在議論されています。

見たいで面白いな。＞ hung up
というのは置いといてBCCとVC++で同じバグだったりして。
cygwinもDOS窓にラッピングしているだけでしょ。
だからコンソールとしての質は同じで、コンソールのバグと
ライブラリのバグが重なって......でも何故リブート？

>hung up -> hang up
どっちか分からなかったのだけどはずれたか(^^;

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

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

DLしたdanger.exeを起動するとcygwinのコンソールにWarning
が沢山表示され、そのままリブートしたよ。

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

hung up -> hang up

> 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では落ちませんでした。:)

一発でリブートしました。

cygwin/gcc on Win2k では大丈夫。
普通に表示し続けるだけでC-Cで終わる。

ここまで追い詰めました。
#include <stdio.h>

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

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

> どんな状況でmovqntqより速いんでしょうか。
あくまでもmovntqで速度の出ない場合です。
連続したメモリへの書き込みは圧倒的にmovntqの方が速いです。

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

> movq [edi],mm0
> prefetcht0 [edi+nn]
> とかやるとちょっと速くなります。
どんな状況でmovqntqより速いんでしょうか。
よくあることならmovntqの存在意義が(^^;
というか私はprefetch関連は使って速くなったことが無いので
あんまり信用していないです。

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

最近気づいたのですが書き込みにもプリフェッチは有効なんですね。
movntqでの書き込みで速度が出ないルーチンの場合、
movq [edi],mm0
prefetcht0 [edi+nn]
とかやるとちょっと速くなります。
movntq [edi],mm0
prefetchnta [edi+nn]
の方が速かったかな？
一部のAthlonでは逆に遅くなったりしたけど・・・。

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

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

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

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

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

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

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

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

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

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

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


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

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

> ｘ86系のCPUでページ境界をまたぐとき、
> 物理アドレスが連続してたほうが早かったりするんでしょうか。
>
> 386だとページング無効にするとちょっと早いらしいけど、
> 最近のはパイプライン深いから関係ないんですかね(^^;;

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

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

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

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

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

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

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

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

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

レジスタは、現在の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な２次元配列)を転置するコードを
MMXで書いてみましたが、予想通り遅いです。
これは書き込みの際の手間（命令数の増加）なのか、そもそも
縦に書き込むことが遅いのかどちらなんでしょうか？

>ｘ86系のCPUでページ境界をまたぐとき、物理アドレスが
>連続してたほうが早かったりするんでしょうか。

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

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

ｘ86系のCPUでページ境界をまたぐとき、
物理アドレスが連続してたほうが早かったりするんでしょうか。

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

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

基本的に差は無いです。
大昔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などを変更してはいけないというルールが
あるからでしょう。