【高速化】ビット演算　0x02

【高速化】ビット演算 ..

116:デフォルトの名無しさん
07/01/18 16:58:05
>>109
! がオーバーロードされてたら、二回も呼ばれることになるぜ。

117:デフォルトの名無しさん
07/01/19 01:20:26
オーバーロードまで考慮したら ! 二回より != の方が遅いことも
十分ありえるけどな。

118:デフォルトの名無しさん
07/01/19 14:36:23
64bitのビットを数えるのは外出？

119:デフォルトの名無しさん
07/01/19 18:41:42
>>118
ビットを数えるってのがよくあるpop関数のことなら死ぬほど既出。

120:デフォルトの名無しさん
07/01/23 07:38:25
あげ

121:デフォルトの名無しさん
07/01/23 10:19:53
レス４は絶対ここの住民だろ笑
ｽﾚﾘﾝｸ(tech板)l50

122:デフォルトの名無しさん
07/01/26 23:52:21
>>121
こいつのせいでビット操作のスレになってるじゃないか

123:デフォルトの名無しさん
07/01/29 12:22:02
ビット演算でbranch freeなmagic incrementは可能かね？

124:デフォルトの名無しさん
07/02/12 18:20:58
Bit Twiddling Hacks
URLﾘﾝｸ(graphics.stanford.edu)
こんなサイトが（英語だけど）
テンプレに入れる？

125:デフォルトの名無しさん
07/02/12 21:33:10
入れるのはいいけど、それまで続くんか?

126:デフォルトの名無しさん
07/02/12 22:46:32
コンパイル時には>>124をテンプレとしてオーバーライドします。

127:デフォルトの名無しさん
07/02/13 07:43:07
もうこのスレも息切れみたいだね。

128:デフォルトの名無しさん
07/02/13 23:14:23
だいたいビット演算ごときでときめいちゃうのは厨房までだろw
煽りぬきで

129:デフォルトの名無しさん
07/02/13 23:51:38
ていうか、パズルみたいなもんだろ。

さすがに、ネタ切れにて閉店でいいと思うよ。

130:デフォルトの名無しさん
07/02/15 15:02:08
よほど要求速度や省メモリがシビアな環境でない限りは妙な小細工はたいして必要ないもんね

131:デフォルトの名無しさん
07/02/15 15:47:08
int i = 20070215;

で、この i からそれぞれ 2007, 2, 15 って数字が欲しいんだけど
誰かカッコ良くビット演算使ってやってください。

132:デフォルトの名無しさん
07/02/15 15:50:34
>>131
実質的には除数固定で割り算を行うのと同じだから
割り算の話になるな。

133:デフォルトの名無しさん
07/02/15 16:48:06
0x20070215

134:デフォルトの名無しさん
07/02/15 16:53:01
>>131-133
それすごくもったいなくないか

たしか
日：1-31 (5bit)
月：1-12 (4bit)
年：00-99 (7bit)

で 16bit っつー表記があったな
FDとかHDのタイムスタンプとか

今なら年だけ
0000-9999 (14bit)
でも 23bit で余裕な訳だが

135:デフォルトの名無しさん
07/02/15 17:03:23
>>134
そんなところでビットをケチったってしょうがねぇべさ。
そのフォーマット(MS-DOSのFATだな)はタイムスタンプが2秒単位でしか記録できないしね。
#hour:5, minute:6, second:5

136:デフォルトの名無しさん
07/02/16 03:33:47
ねえ偉い人
１０進数を３進数に変換するコードはJAVAでどう書きますか？

137:デフォルトの名無しさん
07/02/16 03:46:47
↑バカ

138:デフォルトの名無しさん
07/02/16 14:24:00
イマイチビット演算はよくわからん

139:デフォルトの名無しさん
07/02/16 15:18:45
ビット演算してると脳汁が出る

大抵は無意味だけど
オナニーとしてはﾅｶﾅｶそそる

140:デフォルトの名無しさん
07/02/16 15:28:21
ビット演算って1や0にするだけじゃん。

141:デフォルトの名無しさん
07/02/16 15:35:59
だが、それがいい。

142:デフォルトの名無しさん
07/02/16 15:55:53
3|17 2
3| 5 2
　 1

10進数:17 -> 3進数:122

10進数から3進数への変換て、これであってる？

143:デフォルトの名無しさん
07/02/16 15:59:57
なんかboost::randomの使い方が良く分からないので
extern boost::mt19937 brand;
inline const float&n_rand(){
static float x;
*((unsigned int*)&x)=(brand()&0x7FFFFF)|0x3F000000;
return x;
}
とかやってる俺はkusobaka

144:デフォルトの名無しさん
07/02/16 20:57:54
うわっバカだ

staticいらないだろ。

145:デフォルトの名無しさん
07/02/16 23:56:47
bitマスクとかメンドクサイから言語レベルでbitの配列みたいに扱える
演算子があれば良いんだけどな。
STLやboostを使っても型変換が必要だし。

146:デフォルトの名無しさん
07/02/16 23:58:08
ビットフィールド？

147:デフォルトの名無しさん
07/02/17 00:00:30
static を除去するなら、戻り値は const float & ではなく float にすべきでもある。
ところで、乱数の範囲はそれでいいのか？
２進表現で0x3f800000 から 0x3fffffff にして、そこから 1.0f を引くと [0..1) になって使いやすいと思うが。

148:デフォルトの名無しさん
07/02/17 01:31:32
floatの表現がIEEEに合致するってのは保証されてるんだっけ？

149:デフォルトの名無しさん
07/02/17 01:54:26
うんにゃ、されてない

150:デフォルトの名無しさん
07/02/17 08:36:23
だが、それがいい

151:デフォルトの名無しさん
07/02/18 21:02:06
32bitのエンディアンの変換てどうすればいい？

152:150
07/02/18 21:13:28
ごめん、よく考えたら大したことなかった。
これでOKだ。
x = ( ( x >> 8 ) & 0x00ff00ff ) | ( ( x << 8 ) & 0xff00ff00 );
x = ( ( x >> 16 ) & 0x0000ffff ) | ( ( x << 16 ) & 0xffff0000 );

153:デフォルトの名無しさん
07/02/19 09:11:59
単に
x = (x & 0x000000ff) << 24 | (x & 0x0000ff00) << 8
| (x & 0x00ff0000) >> 8 | (x & 0xff000000) >> 24;
と書いては何かまずいの？

152の方法だと1行目で算出したxを2行目で使っているので
1行目の処理と2行目の処理の並列性が無いし、マスク用の
定数が4バイトの2つ、3バイトの1つ、2バイトの1つで、
どのCPUを想定しているのかは知らないけど、普通は
上の方法のマスク定数より長いコードになるのでは。

24回のshiftが16回のshiftより時間がかかる状況なら
上の方法は好ましくないし、エンディアン変換のビット長が
64bitなら152の方法のほうが良いように思うが。

154:デフォルトの名無しさん
07/02/19 18:34:24
普通に共用体でやった方がエレガントで早いと思いますが。。

155:デフォルトの名無しさん
07/02/19 21:49:23
正直これでいいや。
URLﾘﾝｸ(msdn2.microsoft.com)(VS.80).aspx

156:デフォルトの名無しさん
07/02/20 21:52:40
>>155
?

157:デフォルトの名無しさん
07/03/01 22:52:20
あげ

158:デフォルトの名無しさん
07/03/21 06:17:18
任意のビット数のシフトやローテートてなんで１クロックで実行できねーの？
連続した場合ね。

159:デフォルトの名無しさん
07/03/22 00:34:10
1024bitとか？

160:デフォルトの名無しさん
07/03/22 08:22:35
そもそも1クロックで実行っていつの時代のどのCPUの話だよ
30年前の8bit時代から頭の中進歩してないオジサマ丸出しだねw

しかも昔の8bitマイコンだって命令サイクルと実クロックは別物だしね

161:デフォルトの名無しさん
07/03/22 21:47:22
なんか言いたいんだろうけど、何を言いたいのかさっぱりわからん。

知ったか厨の典型だな。(w

162:デフォルトの名無しさん
07/04/07 02:22:12
あげ

163:デフォルトの名無しさん
07/04/29 08:20:14
a

164:デフォルトの名無しさん
07/04/29 10:38:15
1Bit CPUの可能性について語れないのは素人。

165:デフォルトの名無しさん
07/04/29 10:44:47
cmos 4000 シリーズの事か？

166:デフォルトの名無しさん
07/04/29 10:52:16
MC14500　か

167:デフォルトの名無しさん
07/04/29 12:29:58
コネクションマシンか？

168:デフォルトの名無しさん
07/04/29 18:46:24
バイトの縛りがうざいんだよ

169:デフォルトの名無しさん
07/04/30 02:15:38
22時以降はダメとか?

170:デフォルトの名無しさん
07/04/30 07:39:02
ざぶんとん

171:デフォルトの名無しさん
07/05/03 20:17:24
>どっちかのbitが立ってることを確認するために
>if(hoge & 0x000000C0)
>みたいな書き方出来ると思うのですが
>両方のbitが立ってることを確認したければ
>if(hoge & 0x000000C0 == 0x000000C0)
>って書くしか方法ないですか？

以下から正しいものを選べ

1) if(hoge & 0x000000C0 & 0x000000C0)
2) if((hoge & 0x000000C0) & 0x000000C0)
3) if(!((hoge & 0x000000C0) ^ 0x000000C0))
4) if((hoge & 0x00000080) && (hoge & 0x00000040))
5) if(~(hoge | ~0x000000C0))
6) if(~(~hoge | ~0x000000C0))

172:デフォルトの名無しさん
07/05/03 20:20:41
(hoge & 0x000000C0) == 0x000000C0 が一番速いだろう。

173:デフォルトの名無しさん
07/05/03 20:30:47
#include <stdio.h>

#define MASK 0x0000C0C0

int bittesta(int hoge)
{
if((hoge & MASK) == MASK){
return 1;
}else{
return 0;
}
}

int bittestb(int hoge)
{
if(!((hoge & MASK) ^ MASK)){
return 1;
}else{
return 0;
}
}

int main(int ac, char **av)
{
int hoge = 1234;
bittesta(hoge);
bittestb(hoge);
return 0;
}

174:デフォルトの名無しさん
07/05/03 20:31:55
_bittesta:
pushl %ebp
movl %esp, %ebp
subl $4, %esp
movl 8(%ebp), %eax
andl $49344, %eax
cmpl $49344, %eax
jne L10
movl $1, -4(%ebp)
jmp L9
L10:
movl $0, -4(%ebp)
L9:
movl -4(%ebp), %eax
leave
ret
_bittestb:
pushl %ebp
movl %esp, %ebp
subl $4, %esp
movl 8(%ebp), %eax
andl $49344, %eax
cmpl $49344, %eax
jne L13
movl $1, -4(%ebp)
jmp L12
L13:
movl $0, -4(%ebp)
L12:
movl -4(%ebp), %eax
leave
ret

175:デフォルトの名無しさん
07/05/03 20:34:17
>>172 が正解なんだけど
いまどきのコンパイラは
>>171 (3) で書いても
最適化されて >>172 になってるんだね

176:デフォルトの名無しさん
07/05/03 22:06:56
ど素人です。質問があります。

例えば1か0が格納される変数(Aと仮定)のスイッチ切り替えの場合

【例①】
if(A == 1)
{
A = 0;
}
else
{
A = 1;
}

【例②】
A = A ^ (0 + 1);

この場合早いのはやはり例②なのでしょうか？

177:デフォルトの名無しさん
07/05/03 22:13:48
A ^= 1;

が速い。まあ、例２と同じだあな。

178:デフォルトの名無しさん
07/05/03 22:18:35
>>177
有難うございました。

179:デフォルトの名無しさん
07/05/03 22:24:42
SUBR #n 　　　Acc = n-Acc を持ってるCPUだと
A　=　1-A　

のが速かったりするぞ

180:デフォルトの名無しさん
07/05/04 00:48:43
>>177,179
いや、今回は1と0で設定されてるけどほんとは3と5かもしれないだろ
そういう場合ってやっぱA ^= 1;とかA = 1-Aより

A ^= (3 + 5);のほうが正解なんじゃないか？

1と0ならA = 1-Aとかでもいいんだけどな

181:・∀・）っ-○◎●
07/05/04 00:52:14

A ^= 8;
？？？？？？？？？？？？？？？？？？？？？？？？？？？？

Aには1か0が格納されるって最初の条件で確定してるんだが

182:180
07/05/04 00:53:56
>>181
汎用性を高めるって意味だよ

183:・∀・）っ-○◎●
07/05/04 00:55:14
いや8はおかしいだろ常識的に考えて

184:180
07/05/04 00:55:36
A変数に1か0だけの設定なら

A ^= 1;でいいと思うが

A変数に3か5が入ってる設定だと

A ^= 5;じゃダメだろ？

だったらどちらにでも応用できる

A ^= (1 + 0);
A ^= (5 + 3);

がいいんじゃないかって話をしたかっただけだ。

185:・∀・）っ-○◎●
07/05/04 00:56:41
8じゃ最下位ビットはトグルできません＞＜

186:180
07/05/04 00:59:14
じゃあ7だこの野郎

187:・∀・）っ-○◎●
07/05/04 00:59:43
ちなみに俺の回答は
A = ~A;

188:デフォルトの名無しさん
07/05/04 01:01:02
工ｴｴｪｪ(´д`)ｪｪｴｴ工

189:180
07/05/04 01:01:45
俺は今赤面しながら画面に張り付いてるｗｗｗｗｗｗｗｗｗｗ
確かに8じゃ無理だったｗｗｗｗｗｗｗｗｗ

190:・∀・）っ-○◎●
07/05/04 01:24:45
>>187だと「1」にならないね。
仮に全ビット使う場合の話。
信号制御用の1ビットレジスタをこれで操作してたような。

0か1かならこっちのほうが素直か
A = !A;

191:デフォルトの名無しさん
07/05/04 01:59:07
3 と 5 のトグルなら A ^= 6; だな。
要するに A ^= (3 ^ 5);

192:デフォルトの名無しさん
07/05/04 08:32:25
拡張して　0,1,2 のトグル a=(a+1) % 3 とか 0～9 での循環a=(a+1) % 10とかになると途端に難しくなるな

193:デフォルトの名無しさん
07/05/04 08:50:20
WORD wに0x0001が含まれていて0x0010が含まれてない、の結果をBOOL bに納める式は
どう書くと一番短いですか？

194:デフォルトの名無しさん
07/05/04 08:52:03
b = (w & 0x0011) == 0x0001;

195:デフォルトの名無しさん
07/05/04 08:59:54
if ((w && 0x0001) == 0x0001)
{
if ((w && 0x0010) != 0x0010)
{
b = TRUE;
}
else
{
b = FALSE;
}
}

196:デフォルトの名無しさん
07/05/04 09:05:23
>>194
ありがとん

197:デフォルトの名無しさん
07/05/04 09:17:53
a:= a +1;
a:= (a+ (a shr 2) ) and 3;

これだと 1,2,3の循環になるな

198:デフォルトの名無しさん
07/05/04 12:09:44
A ^= (3 ^ 5);

199:デフォルトの名無しさん
07/05/04 12:19:48
1001
1000
0000
0001
0011
0010
0110
0100
0101
0111

200:デフォルトの名無しさん
07/05/04 12:21:58
　　　　　　　ヾ　 /　　　　＜仮面ﾗｲﾀﾞｰ555が＞
　　　　　　,. -ﾔ'''ｶｰ､　　　/Y⌒Y⌒Y⌒Y⌒Yヾ
ー―ｧ　　/r⌒|:::|⌒ヾ
　 _ノ　オ{（　　|0|　　）} オｵｵォォｫｫ！！！！！
　　　　__,ヽ,ヾ,_|V|,_ノ､/ ,r-,,=
　　　,゛＝=ゝ_ＶiＶ_ノ~i/　〃 `ー―-､
　　 / 　/⌒`//´⌒c/＾＾＾ )））)))))））
,,―ｲ　 {ｰ''"~{ {~゛`ー`/'`'~/ー--―'
））　　,./ゝ＿/∧ゝ＿ノ　　ﾉ
ー''"　　｜ﾛ　　ﾛ　　　　｜
人,_,人,_,人,_,人,_,人,_,
＜適当な番号をゲット!!＞

201:デフォルトの名無しさん
07/05/04 15:08:21
あまり適当な番号には見えない件について

202:デフォルトの名無しさん
07/05/04 16:12:03
0xC8

203:デフォルトの名無しさん
07/05/04 16:43:42
丁度256円になります。

204:デフォルトの名無しさん
07/05/04 16:47:10
ポイントはお付きしますか？

205:デフォルトの名無しさん
07/05/04 16:50:33
いいえ、彼はペンです。

206:デフォルトの名無しさん
07/05/05 02:12:41
char v;
if(v){ ..... }

vのビット列が [10000000] と [00000001]
ではやっぱり前者の方が早いんだろうか

207:デフォルトの名無しさん
07/05/05 02:21:08
最適化や前後のループや分岐予測によるだろ…常識的に考えて…

208:デフォルトの名無しさん
07/05/05 02:37:55
嫌な答え方だな

209:デフォルトの名無しさん
07/05/05 03:18:03
感じないわ。

210:デフォルトの名無しさん
07/05/05 03:39:36
痛くないわ。

211:デフォルトの名無しさん
07/05/05 11:01:09
五寸釘はイヤだろ・・・・常考

212:デフォルトの名無しさん
07/05/05 11:21:15
ごっすんごっすん五寸釘ー

213:デフォルトの名無しさん
07/05/05 12:16:52
そっちかよクソ

214:デフォルトの名無しさん
07/05/06 17:55:55
あいーん

215:デフォルトの名無しさん
07/05/14 21:23:54
効率的では無いけど少々トリッキーなJavaのコード。数列の解説は面倒なので略。

float[] p = {
0.000f, 0.000f, 1.000f, 5.373f, 0.000f, 0.998f, 4.989f, 0.000f, 1.075f, 5.000f, 0.000f, 0.000f,
0.000f, 5.373f, 0.998f, 4.865f, 4.865f, 0.951f, 4.970f, 2.370f, 1.160f, 5.000f, 1.326f, 0.000f,
0.000f, 4.989f, 1.075f, 2.370f, 4.970f, 1.160f, 3.700f, 3.700f, 0.179f, 4.473f, 2.598f, 0.000f,
0.000f, 5.000f, 0.000f, 1.326f, 5.000f, 0.000f, 2.598f, 4.473f, 0.000f, 3.536f, 3.536f, 0.000f,
};
float[] q = new float[384];
int i,j,k;
for(i=0;i<8;i++) {
k = (((i>>>2)^(i>>>1)^i)&1)*12;
for(j=0;j<16;j++) {
q[i*48+j*3+0] = ((i&1)==0)?p[(j^k)*3+0]:-p[(j^k)*3+0];
q[i*48+j*3+1] = ((i&2)==0)?p[(j^k)*3+1]:-p[(j^k)*3+1];
q[i*48+j*3+2] = ((i&4)==0)?p[(j^k)*3+2]:-p[(j^k)*3+2];
}}
for(i=0;i<32;i++) {
for(j=0;j<12;j++) { System.out.printf("%+6.3ff,",q[i*12+j]); }
System.out.print("\n");
}

216:215の出力結果(1/2)
07/05/14 21:26:12
+0.000f,+0.000f,+1.000f,+5.373f,+0.000f,+0.998f,+4.989f,+0.000f,+1.075f,+5.000f,+0.000f,+0.000f,
+0.000f,+5.373f,+0.998f,+4.865f,+4.865f,+0.951f,+4.970f,+2.370f,+1.160f,+5.000f,+1.326f,+0.000f,
+0.000f,+4.989f,+1.075f,+2.370f,+4.970f,+1.160f,+3.700f,+3.700f,+0.179f,+4.473f,+2.598f,+0.000f,
+0.000f,+5.000f,+0.000f,+1.326f,+5.000f,+0.000f,+2.598f,+4.473f,+0.000f,+3.536f,+3.536f,+0.000f,
-0.000f,+5.000f,+0.000f,-1.326f,+5.000f,+0.000f,-2.598f,+4.473f,+0.000f,-3.536f,+3.536f,+0.000f,
-0.000f,+4.989f,+1.075f,-2.370f,+4.970f,+1.160f,-3.700f,+3.700f,+0.179f,-4.473f,+2.598f,+0.000f,
-0.000f,+5.373f,+0.998f,-4.865f,+4.865f,+0.951f,-4.970f,+2.370f,+1.160f,-5.000f,+1.326f,+0.000f,
-0.000f,+0.000f,+1.000f,-5.373f,+0.000f,+0.998f,-4.989f,+0.000f,+1.075f,-5.000f,+0.000f,+0.000f,
+0.000f,-5.000f,+0.000f,+1.326f,-5.000f,+0.000f,+2.598f,-4.473f,+0.000f,+3.536f,-3.536f,+0.000f,
+0.000f,-4.989f,+1.075f,+2.370f,-4.970f,+1.160f,+3.700f,-3.700f,+0.179f,+4.473f,-2.598f,+0.000f,
+0.000f,-5.373f,+0.998f,+4.865f,-4.865f,+0.951f,+4.970f,-2.370f,+1.160f,+5.000f,-1.326f,+0.000f,
+0.000f,-0.000f,+1.000f,+5.373f,-0.000f,+0.998f,+4.989f,-0.000f,+1.075f,+5.000f,-0.000f,+0.000f,
-0.000f,-0.000f,+1.000f,-5.373f,-0.000f,+0.998f,-4.989f,-0.000f,+1.075f,-5.000f,-0.000f,+0.000f,
-0.000f,-5.373f,+0.998f,-4.865f,-4.865f,+0.951f,-4.970f,-2.370f,+1.160f,-5.000f,-1.326f,+0.000f,
-0.000f,-4.989f,+1.075f,-2.370f,-4.970f,+1.160f,-3.700f,-3.700f,+0.179f,-4.473f,-2.598f,+0.000f,
-0.000f,-5.000f,+0.000f,-1.326f,-5.000f,+0.000f,-2.598f,-4.473f,+0.000f,-3.536f,-3.536f,+0.000f,

217:215の出力結果(2/2)
07/05/14 21:27:16
+0.000f,+5.000f,-0.000f,+1.326f,+5.000f,-0.000f,+2.598f,+4.473f,-0.000f,+3.536f,+3.536f,-0.000f,
+0.000f,+4.989f,-1.075f,+2.370f,+4.970f,-1.160f,+3.700f,+3.700f,-0.179f,+4.473f,+2.598f,-0.000f,
+0.000f,+5.373f,-0.998f,+4.865f,+4.865f,-0.951f,+4.970f,+2.370f,-1.160f,+5.000f,+1.326f,-0.000f,
+0.000f,+0.000f,-1.000f,+5.373f,+0.000f,-0.998f,+4.989f,+0.000f,-1.075f,+5.000f,+0.000f,-0.000f,
-0.000f,+0.000f,-1.000f,-5.373f,+0.000f,-0.998f,-4.989f,+0.000f,-1.075f,-5.000f,+0.000f,-0.000f,
-0.000f,+5.373f,-0.998f,-4.865f,+4.865f,-0.951f,-4.970f,+2.370f,-1.160f,-5.000f,+1.326f,-0.000f,
-0.000f,+4.989f,-1.075f,-2.370f,+4.970f,-1.160f,-3.700f,+3.700f,-0.179f,-4.473f,+2.598f,-0.000f,
-0.000f,+5.000f,-0.000f,-1.326f,+5.000f,-0.000f,-2.598f,+4.473f,-0.000f,-3.536f,+3.536f,-0.000f,
+0.000f,-0.000f,-1.000f,+5.373f,-0.000f,-0.998f,+4.989f,-0.000f,-1.075f,+5.000f,-0.000f,-0.000f,
+0.000f,-5.373f,-0.998f,+4.865f,-4.865f,-0.951f,+4.970f,-2.370f,-1.160f,+5.000f,-1.326f,-0.000f,
+0.000f,-4.989f,-1.075f,+2.370f,-4.970f,-1.160f,+3.700f,-3.700f,-0.179f,+4.473f,-2.598f,-0.000f,
+0.000f,-5.000f,-0.000f,+1.326f,-5.000f,-0.000f,+2.598f,-4.473f,-0.000f,+3.536f,-3.536f,-0.000f,
-0.000f,-5.000f,-0.000f,-1.326f,-5.000f,-0.000f,-2.598f,-4.473f,-0.000f,-3.536f,-3.536f,-0.000f,
-0.000f,-4.989f,-1.075f,-2.370f,-4.970f,-1.160f,-3.700f,-3.700f,-0.179f,-4.473f,-2.598f,-0.000f,
-0.000f,-5.373f,-0.998f,-4.865f,-4.865f,-0.951f,-4.970f,-2.370f,-1.160f,-5.000f,-1.326f,-0.000f,
-0.000f,-0.000f,-1.000f,-5.373f,-0.000f,-0.998f,-4.989f,-0.000f,-1.075f,-5.000f,-0.000f,-0.000f,

218:デフォルトの名無しさん
07/05/14 21:53:43
誰かエスパーしてくれ

219:デフォルトの名無しさん
07/05/14 23:11:47
新手の荒らしだろ、スルーよろ。

220:デフォルトの名無しさん
07/05/15 00:22:46
k = (((i>>>2)^(i>>>1)^i)&1)*12;
は
k = ((i>>>2)&4)*12;
と等価じゃない？

221:デフォルトの名無しさん
07/05/15 00:24:00
k = (((i>>>2)^(i>>>1)^i)&1)*12;
は
k = ((i>>>2)&1)*12;
と等価

222:デフォルトの名無しさん
07/05/15 00:25:45
おいおい、不等号3つって……

223:デフォルトの名無しさん
07/05/15 00:56:43
System.out.printfって何だよ
オブジェクト指向すげえよ

224:デフォルトの名無しさん
07/05/15 02:01:14
>>>220-221
^は排他的論理和、>>>は符号無し右シフト、&は論理積なので、
k=(((i>>>2)^(i>>>1)^i)&1)*12はi=1,2,4,7の時にk=12、i=0,3,5,6の時にk=0となる。
全然等価じゃねーぞ。

225:215
07/05/15 03:58:02
エスパー困難なコードですが、一番意図の分かりにくい部分だけ解説。

k = (((i>>>2)^(i>>>1)^i)&1)*12;
上の文は、iのパリティがevenであればk=0、oddであればk=12とする処理を行う部分ですが
iの値域が0～7に限られるため、パリティの計算は下3bitに対してのみ行っています。
k = (Integer.bitCount(i)&1)*12; とする手もありますが、今回は先のように書きました。

p[0]～p[15]を4x4の行列と見た場合に、q[]にその値をコピーする
for(j=0;j<16;j++) { q[j] = p[j^k]; }
の処理はkの値によって以下のような振る舞いの変化をします。
k=0：そのまま、k=3：列を逆順に入れ替え、k=12：行を逆順、k=15：行・列ともに逆順

226:デフォルトの名無しさん
07/05/15 04:07:12
そこまで式が込み入ってたら、テーブルの方が速くないかな。
まあ、環境によるとは思うが。

227:デフォルトの名無しさん
07/05/20 08:13:37
あげ

228:デフォルトの名無しさん
07/05/22 07:41:36
ある変数の中でビットが必ず一つだけ立っているとき
そのビットの位置（左右どちらからでもよい）を求めたいのですが
↓のNTZやNLZを求めるアルゴリズムを使うのよりも高速にできませんか？
URLﾘﾝｸ(www.nminoru.jp)
立っているビットの数が一つという条件があるので
何か工夫できないか考えたんですけど思いつきません。

229:デフォルトの名無しさん
07/05/22 08:06:11
どっかで聞いたような質問だな・・・

230:デフォルトの名無しさん
07/05/22 08:07:19
memcpyよりも高速にコピーできる高速memcpyを作りたいのですが
何か参考になる方法ってありますか？

231:デフォルトの名無しさん
07/05/22 08:18:56
>>230
memcpyより高速な手法が存在するとしたら、世の中のmemcpyはその高速
な手法を使うんじゃない？

232:デフォルトの名無しさん
07/05/22 08:24:56
>>230
ビット単位で転送するという話でもない限り、スレ違い。

233:デフォルトの名無しさん
07/05/22 08:26:58
>>231
いいえ。

234:デフォルトの名無しさん
07/05/22 08:31:37
前スレのログってどこかにある？

235:デフォルトの名無しさん
07/05/22 08:35:42
あ、あったあった。
URLﾘﾝｸ(p2.chbox.jp)
ここの377に似たような質問があるね。

236:デフォルトの名無しさん
07/05/22 08:39:30
>>228
ビット位置を持って回ることを検討したか?

>>230
つ [ゼロコピー]

237:デフォルトの名無しさん
07/05/22 09:05:14
ビット位置を持って回るのは難しいと思いました。
ビットはこんな風に複数のビットが立ってる変数から取り出してます。
UInt32 bits;
...
while(bits)
{
UInt32 bit = bits&(-bits);
UInt32 bit_position = get_bit_position(bit);
...
}
で、このget_bit_position()の部分を作りたいのですが・・

238:デフォルトの名無しさん
07/05/22 09:12:52
ちょっと>>235を読んできます

239:デフォルトの名無しさん
07/05/22 10:16:01
とりあえず>>235の430でやってみます。
みなさんありがとうございました。

240:デフォルトの名無しさん
07/05/23 15:19:02
24xx32～24xx512 までのシリアルEE-PROMというのは
pageというのを持っていてページサイズ内なら一度に書き込みが出来ます
ページサイズは8～256まで２のべき乗で、ROMタイプによって異なります。
今、EE_write(adr , size, dt[] ) という関数があって、この関数はページサイズを認識しません。
そこでこのラッパを作りたいのです
pagesize, ADR, SIZE , *p

if( (ADR ^ (ADR + SIZE -1)) & (0xFFFFu-(pagesize-1) ) ){　一度に書ける }

分割しなければいけない場合
ADR ～ (ADR | (pagesize-1) ) が最初に書く領域　

というふうに考えたのだけど、ループが格好良く書けないの。

241:デフォルトの名無しさん
07/05/23 16:43:01
自己レス
結局こうやった

while(( (ADR ^ (ADR+SIZE-1)) & (0xFFFFU-(pagesize-1)) ) ){
　ct = (ADR | (pagesize-1))+1 -ADR;
　EE_write(ADR, ct , p);
　p　　+= ct;
　ADR　+= ct;
　SIZE -= ct;
}
EE_write(ADR, SIZE , p );

242:デフォルトの名無しさん
07/05/24 05:19:07
格好良いかどうかは主観だという良い例。

243:デフォルトの名無しさん
07/05/25 17:20:07
>>241
普通に書くとこんな感じ？

　　　　unsigned　tail　=　adr　+　size;
　　　　unsigned　ct　=　pagesize　-　adr　%　pagesize;

　　　　while　(adr　+　ct　<　tail)　{
　　　　　　　　EE_write(adr,　ct,　dt);
　　　　　　　　dt　+=　ct;
　　　　　　　　adr　+=　ct;
　　　　　　　　ct　=　pagesize
　　　　}
　　　　if　((ct　=　tail　-　adr)　!=　0)
　　　　　　　　EE_write(adr,　ct,　dt);

>>241って、SIZEに　0　を指定されると大変なことになりそうだな。

244:デフォルトの名無しさん
07/05/27 15:33:15
汚いJavaコードコンテストの会場はこちらですか？

245:デフォルトの名無しさん
07/05/27 15:35:13
いいえ、ここはJavaを知らない244が居るスレです。

246:デフォルトの名無しさん
07/05/27 22:25:32
面白くない　失せろ

247:デフォルトの名無しさん
07/05/27 23:15:48
エンディアンの変換を共用体でやるのってどうやるんですか？

248:デフォルトの名無しさん
07/05/27 23:26:39
バイトオーダーは詳しくないが
int, int って並びなら、
1, 2, 3, 4, 5, 6, 7, 8 が
4, 3, 2, 1, 8, 7, 6, 5 ってなるだけで
8, 7, 6, 5, 4, 3, 2, 1 にはならないのでは？

249:・∀・）っ-○◎●
07/05/27 23:31:17
こうですかわかりません＞＜

typedef union {
　　uint32_t wd;
　　uint8_t bt[4];
} HogeType;

HogeType a, b;
a.wd = src;
b.bt[0] = a.bt[3];
b.bt[1] = a.bt[2];
b.bt[2] = a.bt[1];
b.bt[3] = a.bt[0];
dest = b.wd;

250:デフォルトの名無しさん
07/05/28 00:21:29
ヤツはダンゴさんじゃない

251:デフォルトの名無しさん
07/05/28 00:52:56
共用体って、本当はそういう風に使っちゃダメなんだよな。
規格違反。
まあ、そう使えないコンパイラはないと思うけど。

252:デフォルトの名無しさん
07/05/28 08:09:58
おいおい共用体をそういう風に使わずにほかにどんな用途があるって言うんだアホかw

253:デフォルトの名無しさん
07/05/28 10:29:21
使ってはいけない理由があるからそう決められているんだろ。
その理由が皆目検討つかないが。

254:240
07/05/28 10:38:09
>>243
ありがとう。参考になった。
でも、そのままだと最後の書き込みサイズが正しくなかったよ。

255:デフォルトの名無しさん
07/05/28 15:48:22
>>252,>>253
共用体のメンバのうち T 型の a というメンバに値が格納されているときは
U(!= T) 型の b というメンバの値は T 型の a に依存し、U 型の値としては
不正と見なされるため b を通してのアクセスは未定義の動作となる。

ではなぜ共用体が存在するのかというと、おそらく原始的なポリモーフィズムの
実現の為。

ある変数が複数通りの型（ここでは T と U とする）の値を受け入れる可能性が
あるとき、構造体のような、型の異なる複数の変数を用意するのは非効率のため
単一の変数で複数の型を扱える共用体を使う。

もっとも、C++では T 型と U 型の基本クラス V 型を定義して、V 型の参照として
T 型にも U 型にも（もちろん V 型にも）正規にアクセスできるので、共用体は
不要になってしまった（のだろう、たぶん）。

256:デフォルトの名無しさん
07/05/28 17:15:17
共用体はこういうことのためにある。

enum Variant_Type {
　 VARIANT_INT,
　 VARIANT_DOUBLE,
　 VARIANT_CHAR,
　 VARIANT_STRING
};
struct Variant {
　 union {
　　 int i;
　　 double d;
　　 char c;
　　 char *s;
　 } value;
　 enum Variant_Type type;
};

/* var->type で分岐して、その内容を表示する関数 */
void Variant_show(const struct Variant *var) { ... }

int main(void) {
　 Variant var;

　 var.type = VARIANT_INT;
　 var.value.i = 4;
　 Variant_show(&var);

　 var.type = VARIANT_STRING;
　 var.value.s = "hoge";
　 Variant_show(&var);
}

257:デフォルトの名無しさん
07/05/28 22:18:41
>>255
> もっとも、C++では T 型と U 型の基本クラス V 型を定義して、V 型の参照として
> T 型にも U 型にも（もちろん V 型にも）正規にアクセスできるので、共用体は
> 不要になってしまった（のだろう、たぶん）。

不要になってないだろ。

基本クラス云々で各種のデータを扱う処理は正規にできるようになったけど、
複数の型を同一の領域に割り付けるのは union でないとできない。

まあ、そんな機会はめったとないが。

258:デフォルトの名無しさん
07/05/28 22:22:43
普通わざわざそんな面倒なことしないと思いますけどねw
それで何の御利益があると思って書いてるんだろうか？
不思議な発想だとしか言いようがない

っていうか、それ多態じゃなくて多重定義でしょ？w

259:デフォルトの名無しさん
07/05/28 22:29:27
？

260:デフォルトの名無しさん
07/05/28 22:31:52
258は>>255-256宛てね

261:デフォルトの名無しさん
07/05/28 22:35:30
型がクラスだったりする可能性を考えると
共用体よりplacement newのほうが良いと思う。

262:デフォルトの名無しさん
07/05/28 22:36:54
バリアント型とか知らないのかな。
そして、それが内部的にどうなってるかとか、
そこでのコスト意識とかに至っては、全く考えた事ないんだろうね。

263:デフォルトの名無しさん
07/05/28 22:38:44
>>261
共用体に入れられるのはそもそも POD 型だけだが、
ポインタで保持しておくことなら可能だな。

264:デフォルトの名無しさん
07/05/28 22:54:29
>>262
> バリアント型とか知らないのかな。

Ｃ言語でそんなもん使う機会があまりないこととか知らないのかな。(w

265:デフォルトの名無しさん
07/05/28 22:59:44
いや、煽り抜きでそういう発想はちょっとないよね。

266:デフォルトの名無しさん
07/05/28 23:06:16
Cだとバリアント型はにっくきCOMの象徴のひとつだからトラウマが・・・ｗ

267:デフォルトの名無しさん
07/05/28 23:11:53
皆がどのレスについてレスしてるのか分からなくなってきた。
つーかビット演算スレでなぜ共用体…。

「そういう発想」というのは共用体をvariantとして使う発想ということかしら。

268:webmaster@気まぐれアナスイ
07/05/28 23:11:54
　　 { >>>>>>>>985 }
　　　 ζ
　　　　!(+Φ＿Φ)つ√ζ
　　 +⊂.　+ 〆∂ 　 {Ж}
　　 "〆∂∂
　　〆〆
　 .:"

269:デフォルトの名無しさん
07/05/28 23:15:15
コピペ君って馬鹿だな、まで読んだ。

270:デフォルトの名無しさん
07/05/28 23:38:38
>>256
でも共用体って記述した順番にメモリに保存されるかについて
仕様では未定義ですよね

271:デフォルトの名無しさん
07/05/28 23:40:46
>>270
当たり前だろ。

つか struct の仕様と混同してないか?

272:デフォルトの名無しさん
07/05/28 23:43:42
>>270
これはひどい

273:デフォルトの名無しさん
07/05/28 23:45:43
コンパイラコンパイラ触ってるなら、
このくらい常識だろ？

274:デフォルトの名無しさん
07/05/28 23:46:54
という批判と、このスレでの質問だという事を考えると、>>249　は

typedef union {
　　uint32_t *pW;
　　uint8_t *pB;
} HogeType;

HogeType a;
uint8_t w;
a.pW = &src;
a.pB[0] ^= a.pB[3];
a.pB[1] ^= a.pB[2];
a.pB[2] ^= a.pB[1];
a.pB[3] ^= a.pB[0];
a.pB[0] ^= a.pB[3];
a.pB[1] ^= a.pB[2];

みたいなのが希望って事か？

275:デフォルトの名無しさん
07/05/28 23:49:33
それは二重に規格違反してて、
おかしくなるコンパイラもあるらしいよ。
俺はそういうの見た事無いけど。

276:デフォルトの名無しさん
07/05/29 00:13:33
おかしくなるコンパイラがあるのではなく、動作が保証されないということ。
そういうコンパイラが現実にあるのかと言われても、んなこと知らん。
だが、顧客に「正常に動作することが保証されている」プログラムを提供するためには
仕様上未定義とされる書き方をしてはいけないし、意識せずしてしまったらバグとして扱われて然り。

277:デフォルトの名無しさん
07/05/29 00:20:53
参考までに>>274の規格違反している点を簡単に指摘してください

278:デフォルトの名無しさん
07/05/29 00:32:45
規格違反していても、多分 >>249 がおかしくなる処理系はないんじゃね？
逆に、規格通り書いてもおかしくなることもある。
規格違反はそれはそれで重要だけど、
実際の処理系でどうなのかという方が時に重要な事もある。
ま、コメントとか残しておいて、
移植時にすぐ検索できるようにしておくべきではあるが。

279:デフォルトの名無しさん
07/05/29 00:44:32
>>277
共用体の pW メンバに代入した場合、
pW の値しか正当性が保証されない。
そのため、pW に代入したすぐ後に pB を参照したとき、
規格ではその動作を保証しない。

uint32_t * と uint8_t * のアドレス表現が等しいという保証は無い。
この間のキャストで何らかの変換作業が生じる場合には、
このコードは正しく動かない。

そもそもアドレス演算は、配列要素へのポインタでしか保証されない
（配列風の参照では p[4] と *(p + 4) は等価で、
　ここには p + 4 というアドレス演算が生じる）。
ここが原因で >>274 のようなことをすると
おかしくなる処理系があるという風に聞いている。
（「ハッカーのたしなみ」の 87 ページを参照）

280:デフォルトの名無しさん
07/05/29 01:08:03
ハッカーのたしなみに一致する日本語のページ約 104 件
ハッカーのたのしみに一致する日本語のページ約 26,800 件

281:デフォルトの名無しさん
07/05/29 01:15:26
すまんよ。まちがえた。

282:デフォルトの名無しさん
07/05/29 10:36:39
そもそもCの言語仕様で「未定義」な理由は、最初のバイトが最上位か最下位かはエンディアン依存だから。
逆にいうとハードに強く依存する標準仕様はあってはならない。

もちろん環境が特定できる場合なら、エンディアンの違いを理解して使うぶんにはまったく問題ない。
むしろ同一アーキテクチャでならコンパイラのABIレベルではこういう部分も互換性が保障されてないと駄目。
そもそもエンディアンなんて標準仕様外のものを扱うのに、標準仕様を持ち出すほうがおかしいと思うがね
構造体などのデータアラインメントやABIの互換性は言語の規格じゃなくて
各CPUやOSのメーカー、コンパイラメーカーなど同士の取り決めで決まる。
つーか、暗黙の共通仕様や独自仕様にたよらないとTCP/IPすら扱えないぜ。

283:デフォルトの名無しさん
07/05/29 10:52:02
構造体のアラインメントはC仕様では未定義だが、アラインメント不整合だと例外を起こすアーキもある。
データレイアウトを実装者で取り決める独自仕様が認められないなら、Cは危険な言語だな逆にいえば。

「仕様では未定義」は逆にいえば実装では各環境のABIに従ってきめていいということ。

284:デフォルトの名無しさん
07/05/29 11:17:39
>>282-283
仕様上未定義を「未定義の動作」と混同していないか。
Cは移植性を高めるため、特定の環境に依存するような仕様はほとんど盛り込まれておらず
よって指摘の通り構造体のメモリ上でのレイアウトも定義されていない。

だが、メンバに正しくアクセスできることは保証されている。

285:デフォルトの名無しさん
07/05/29 11:25:40
実は未定義ではなく実装依存という罠

286:デフォルトの名無しさん
07/05/29 11:38:48
エンディアンの変換はほぼ間違いなくできるがリトルからビッグかビッグからリトルかはエンディアン依存ってことだろ。

逆に>>349が意図しない動きをするコード吐くコンパイラって存在するなら教えてほしい。
変態のCellですら>>349が正しく動くことはABIレベルで保証されてる。
各型のレイアウトを厳密に定義してるからな。

287:デフォルトの名無しさん
07/05/29 11:43:14
共用体で　ビットフィールド　を使えば、マシになるかい？

288:デフォルトの名無しさん
07/05/29 12:21:19
>>286
>>276
そして話題はループする。

ABIはCの言語仕様における実装依存の箇所を定めて厳密化するものなので
たとえABIの隙をかいくぐって自分の予期した挙動をさせることができたとしても
それは立派な規格違反。

あと、もし>>282さんと同一人物なら
＞そもそもCの言語仕様で「未定義」な理由は、最初のバイトが最上位か最下位かはエンディアン依存だから。
これのソースを頼む。探しているんだが、見つからない（汗

289:デフォルトの名無しさん
07/05/29 12:27:18
規格にないものを扱うのに規格内のルールを持ち出す馬鹿。
windows.hを使うのも規格違反だとか言い出しそうだな

290:デフォルトの名無しさん
07/05/29 12:34:19
厳密にはそうだな。ハンドルをポインタ型とかメチャクチャしたMSは糞。
ちなみに、規格にないものを付け加えるのではなく、規格に抜けているを補うのがABI。
本来は規格に矛盾しないABIを定めなければならない。

ところでここはビット演算についてかたるスレなのか？

291:デフォルトの名無しさん
07/05/29 12:56:10
ミドルエンディアンのこともたまには思い出してやってください

292:デフォルトの名無しさん
07/05/29 13:13:17
GUIがなくてstdioで画面入出力するようなアプリのほうが品質低いと見なすがなうちの顧客は。

「定義するな」なら違反になるが単に未定義のものに一定の動作保証をするだけなら違反じゃない。
何のために#pragmaが規格にあると思ってる。
処理系依存の拡張を、やっていいよと保証すらしてるのが規格だ。

ちなみにunion使った型変換はWindowsでは日常茶飯事だな。ULONG_INTEGERとか。
ここの住人がよく使うであろうMMXやSSEなんかはC用APIなんか、まさに共用体を使った型変換のオンパレード。
それでもパフォーマンスを求める客の「信頼」を得るためにすすんで使うものだ。

ANSI/ISO規格が絶対的に信頼されてて規格外のものは信頼されてないなんて独善的な言い分にすぎん。
getsみたいな危険な関数が野放しにされてるのはなんだね。
極論、信頼性の確保という面ではVC2005のセキュアCRT関数のほうが標準関数よりまとも。

ちなみにポインタをHANDLEという型にtypedefできるのは規定の動作。なんら問題ない。

293:デフォルトの名無しさん
07/05/29 13:37:27
きもちわるいなあ

294:デフォルトの名無しさん
07/05/29 14:40:40
エチケット袋持ってきましょうか？

295:デフォルトの名無しさん
07/05/29 15:10:33
いえ結構。そのまま吐きます

296:デフォルトの名無しさん
07/05/29 15:14:49
キッシュを食うのとエチケット袋を使うのはガキ。

297:デフォルトの名無しさん
07/05/29 17:55:34
「規格違反のプログラム」は、
特定の環境では動くことが保証されてるかもしれないけど、
全ての環境で動く保証が無い。
だから、そのプログラムが特定の環境でのみ使用される事が決まってるなら、
規格違反でもその環境でちゃんと動作する事が保証されていれば問題ない。
ただ、色んな環境で使われるプログラムであれば、規格通りに作らないといけない。

つまりは要件次第の問題であって、常にどちらかでないといけないみたいな事を言うのは愚。

>>292
gets の使用は規格で推奨されていない。
未だ存在しているのは単に互換性のため。
セキュアCRT関数は安全だが、
GCC でコンパイルしたいような場合には
#if 使って GCC でも大丈夫なようにする必要がある。

あと、ハンドルで問題とされているのは、
ハンドルの値は別にアドレスではないのに
ポインタに入れるようにしている点。
ただ、これは int にしてしまうと安全性が低くなるし、
環境依存という程ちゃんと動かなくなる環境もないしで、
いい hack だと思う。

298:デフォルトの名無しさん
07/05/29 18:53:41
話は逸れるが、ハンドルも全てがアドレス値（ポインタ）でないとは限らない。
ドラッグ＆ドロップの処理などでGlobalAllocでメモリ確保したものを
HDROP型へキャストしてやるという事例がある。

ふうんと言われればそれまでのことだけど。

299:デフォルトの名無しさん
07/05/29 18:56:05
それをいうなら、そもそもポインタ（というより左辺値）だってアドレス値とは限らないでしょ？

300:デフォルトの名無しさん
07/05/29 19:02:00
プログラムごとに論理的なアドレス空間を持ってるんじゃないの？
昔、物理的なアドレスを使えば一意だろうと思って使ったら、見事に失敗した。

301:デフォルトの名無しさん
07/05/29 19:09:48
＞ハンドルの値は別にアドレスではないのに
＃ハンドルの値は別にアドレスとは限らないのに

とするか。

302:デフォルトの名無しさん
07/05/29 19:13:49
まあ、メンバ関数ポインタなんかは
確かにメモリアドレス以上の情報を持ってることもあるけど、
C++ における「アドレス」ってのは、
そういう情報も含むんじゃないのかな。多分。

303:デフォルトの名無しさん
07/05/29 20:07:37
きょうび、１つのCPUでも「アドレス」が3種類くらいあって当たり前だしなぁ

304:デフォルトの名無しさん
07/05/29 20:27:53
Cはアドレスの概念を抽象化したから、Cにはアドレスという概念はないと。
どっかで見た。

305:デフォルトの名無しさん
07/05/29 20:36:02
ところがどっこい&演算子の読み方は・・・

306:デフォルトの名無しさん
07/05/29 21:00:16
アドレス演算子だな。

307:デフォルトの名無しさん
07/05/29 21:24:50
えっ？reference operatorじゃないの？
とか思ったけどそれはC++の話でしたねすいません

308:デフォルトの名無しさん
07/05/29 21:53:21
ANSI C: address operator
別名: reference operator

309:・∀・）っ-○◎●
07/05/30 01:32:06
よーしだんごやさんが燃料投下するぞー
「共用体を使った型変換は、保証されないとむしろ違反」

uint32とuint8[4]の完全なアドレス共用が保証できなければ

・各パートの先頭アドレスの一致
・char型(=1バイト)配列のデータ連続性
という規格で保証された動作に違反することになる。

断言する。
バイトオーダさえ一致すれば、共用体を使ったビット列の直接変換は保証できる。

つーか、規格にない動きまで保証されると規格【違反】なら、
Cコンパイラは現実のアーキテクチャ向けに実装された時点で違反を抱えることになり
空想の産物でなければならないことになるね。

規格外と規格違反を混同してるんじゃないの。
規格にない機能を実装したり独自の制約・動作保証をしたらいけないなんて規約は
規格に存在しない。

310:・∀・）っ-○◎●
07/05/30 01:35:52
RubyはCで書かれてるけどオブジェクトは共用体を巧みに使うことでで実装されてるね。
それでもさまざまなプラットフォームに移植されてるけどｗｗｗｗ

311:デフォルトの名無しさん
07/05/30 01:47:03
最適化でどうなるかとかちゃんと考えてるか？

312:・∀・）っ-○◎●
07/05/30 01:59:18
まあ、パーシャルリード・ライトはモダンアーキテクチャでは遅いから速度面でのメリットないし
バイトオーダーの変換に共用体を持ち出すこと自体は俺としても感心しない。
HDの洗礼受けた人間ならこんな厨コードになるだろう

uint32 bswap(uint32 n) {
n = (n >> 16 | n << 16);
return ((n >> 8) & 0x00FF00FF) | ((n << 8) & ~0x00FF00FF);
}

こんなコードを書く間にもx86なら即値が使えるとか、
PowerPCならAND-NOT命令があるから定数ロードは1個だけでいいとか
アーキの特性を考えながら組む。
速くなるか遅くなるかも実装依存。それがビット演算厨の愉しみ。

書いた後で、「PPCとx86なら組み込みのBSWAPで十分な気もしてきた」とか思うのもまた一興。

313:デフォルトの名無しさん
07/05/30 02:07:16
んじゃ、燃料投下。
--
template<typename Type> static inline void endian(Type & val) {
union foo {Type t; char c[sizeof(Type)];} bar = {val};
std::reverse(bar.c, bar.c + sizeof(bar));
val = bar.t;
}

314:・∀・）っ-○◎●
07/05/30 02:11:59
x86のeaxレジスタは下位半分はaxレジスタであり、ahとalでもある
レジスタそのものが共用体なんですよ。

315:デフォルトの名無しさん
07/05/30 02:18:15
>>313
template<> static inline void endian<int>(int & val) {
union foo {int t; char c[sizeof(int)];} bar = {val};
char tmp = bar.c[0]; bar.c[0] = bar.c[3]; bar.c[3] = tmp;
tmp = bar.c[1]; bar.c[1] = bar.c[2]; bar.c[2] = tmp;
val = bar.t;
}
--
これくらいの特殊化しておかないとw
ついでに言うと、これをどう最適化するかがコンパイラの腕の見せ所。

316:・∀・）っ-○◎●
07/05/30 02:21:07
若本・・・じゃなかった、CellのSPEで実行

#include <algorithm>
#include <stdio.h>
template<typename Type> static inline void endian(Type & val) {
union foo {Type t; char c[sizeof(Type)];} bar = {val};
std::reverse(bar.c, bar.c + sizeof(bar));
val = bar.t;
}
int main()
{
unsigned int i = 0x12345678;
endian(i);
printf("0x%0X\n", i);
return 0;
}

[root@ps3 age]# spu-gcc test.cpp
[root@ps3 age]# ./a.out
0x78563412

317:デフォルトの名無しさん
07/05/30 02:33:39
>>309
混同も何も、そもそも「規格外」とか「規格違反」とかいう用語は規格にあるのか？

318:デフォルトの名無しさん
07/05/30 02:35:52
%0X って意味ねー。
%08X っしょ。

319:・∀・）っ-○◎●
07/05/30 03:08:16
64bitから8ビットだけを取り出して操作するってAESとかCamelliaではありがちな処理なんだよな。
よく最適化されたコードは、MMレジスタからpextrwで16ビットをeaxに転送した後、al, ahを使ってテーブル参照する。

320:デフォルトの名無しさん
07/05/30 08:24:42
気色の悪いHN付ける奴の行動パターンやそこから透けて見えるパーソナリティっていうのは、
どいつもこいつもどうしてこう画一的・類型的で凡庸なんだろうなw

恐らく本人の自己イメージはその正反対なんだろうけどさ。

321:デフォルトの名無しさん
07/05/30 08:41:04
凡庸乙

322:デフォルトの名無しさん
07/05/30 08:48:32
>>320
あなたのその発言もまた　画一的・類型的で凡庸　な事に気付いてての発言だとすれば　あなたは勇気がある。
気付いてないなら・・・・・

323:デフォルトの名無しさん
07/05/30 08:56:16
人間なんてみんな一緒だろ。
ハッキリいってイルカよりもマグロの方が頭いいです。
人類の知能は一億年遅れてる。

324:デフォルトの名無しさん
07/05/30 14:10:27
【高速化】ビット演算　0x02

325:デフォルトの名無しさん
07/05/30 20:38:32
俺のアナルも高速化されそうです

326:デフォルトの名無しさん
07/05/31 01:08:47
俺様の射精は低速化されましたが何か?

327:デフォルトの名無しさん
07/05/31 01:34:42
さらに角度までorz....

328:デフォルトの名無しさん
07/05/31 04:34:03
自分の精液を味わって飲んでみましたクセになりそうです

329:デフォルトの名無しさん
07/05/31 09:31:52
【下ネタ化】ビッチ猥談

次ページ