ちょっとしたテクニークスレッド
108 ：名無しさん＠お腹いっぱい。：
0xff * 0xffサイズのテーブルを作る……
って、今のPCだと逆効果かも。
って、今のPCだと逆効果かも。
|
|
|
109 ：108：2000/11/12(日) 06:57
あう、0x100 * 0x100サイズの間違い
ああ鬱だし脳
ああ鬱だし脳
110 ：名無しさん＠お腹いっぱい。：2000/11/12(日) 07:14
int なんちゃら(unsigned char a＠｀ unsigned char b)
{
unsigned char retval;
_asm {
mov al＠｀ a
mov dl＠｀ b
add al＠｀ dl
sbb cl＠｀ cl
or al＠｀ cl
mov retval＠｀ al
}
return retval;
}
うまく使わんと、パーシャルレジスタストールの餌食になるよ。
{
unsigned char retval;
_asm {
mov al＠｀ a
mov dl＠｀ b
add al＠｀ dl
sbb cl＠｀ cl
or al＠｀ cl
mov retval＠｀ al
}
return retval;
}
うまく使わんと、パーシャルレジスタストールの餌食になるよ。
clはdlでもよかった…
どこがテクニークなの？
Cでやるならテーブルが一番手軽だろ。
BYTE Table[2]={0＠｀0xFF};
BYTE a＠｀ b;
int c;
c = a + b;
c=c | Table[c >> 8];
255+255は512以下だからな。
BYTE Table[2]={0＠｀0xFF};
BYTE a＠｀ b;
int c;
c = a + b;
c=c | Table[c >> 8];
255+255は512以下だからな。
８６系のアセンブラなら、alに３つ足して ahに127を足して、符号拡張
して、alとandかな。
４つ足した数を使って飽和させるほうが早い気がする。
どっちにしろ、cでifを使うのにくらべて、測定可能な速度差が出るかど
うかは、わからんけど。
して、alとandかな。
４つ足した数を使って飽和させるほうが早い気がする。
どっちにしろ、cでifを使うのにくらべて、測定可能な速度差が出るかど
うかは、わからんけど。
115 ：名無しさん＠お腹いっぱい。：2000/11/13(月) 00:32
あまり気にしすぎるのも時間の無駄のような気がするなぁ。
前いた会社に最適化マニアがいて、きちんと動いてるのに
まだ速くする！とか言ってゴネてくれたが・・・。
前いた会社に最適化マニアがいて、きちんと動いてるのに
まだ速くする！とか言ってゴネてくれたが・・・。