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

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

455:デフォルトの名無しさん
07/09/22 07:06:58
>>454
--------------------
int my_fputwc(wint_t c, FILE *fp)
{ wint_t r = fputwc(c, fp);
return (r == WEOF) ? EOF : r;
}

int wtbl[0x10000];
void dokkade_jikkou(void ) {
int i;
for (i = 0; i < 0x10000; i++)
wtbl[i] = i;
wtbl[0xffff] = EOF;
}
int my_fputwc(wint_t c, FILE *fp) return wtbl[fputwc(c, fp);]; }

みたいなこと(WEOF(wint_tの0xffff)をEOF(intの-1)に変換)
をもっとスマートに行う方法ないですかね。
---------これで何の不満があるんだ？-----------
wtbl[0xffff] = EOF;
for (i = 0; i < 0xffff; i++)
wtbl[i] = i;
}
--------------------

456:デフォルトの名無しさん
07/09/27 20:24:00
age

457:デフォルトの名無しさん
07/09/29 23:03:31
int rotate_0_9(int a){a++;return(a+(((a+6)>>4)+(((a+6)>>4)<<1))<<1)&15;}
or
int rotate_0_9(int a){a++;return(a+((a+6)>>4)*6)&15;}

引数が0～8の時1を加算し、引数が9の時0を返す。

458:デフォルトの名無しさん
07/09/29 23:17:24
return ++a%9;

459:デフォルトの名無しさん
07/09/29 23:39:43
% はビット演算じゃないだろう

460:デフォルトの名無しさん
07/09/29 23:58:36
int rotate_0_9(int a){return a<9?a+1:0;}

461:デフォルトの名無しさん
07/09/30 00:06:34
DAA

462:デフォルトの名無しさん
07/09/30 00:15:35
>>457
>>458
>>460
どれが速い？

463:デフォルトの名無しさん
07/09/30 00:20:18
実測あるのみ

464:デフォルトの名無しさん
07/09/30 00:34:05
試してみた！
cl /O2 rot9.c
rot9
rotate_0_9_457_1 1873 msec
rotate_0_9_457_2 1272 msec
rotate_0_9_458 4016 msec
rotate_0_9_460 641 msec
>>460が圧倒的だった(俺もそう思ってた)

ソースに続く

465:デフォルトの名無しさん
07/09/30 00:34:50
>>464のソース (VC6SP4)
----------------------------
#include <windows.h>
#include <stdio.h>
int rotate_0_9_457_1(int a){a++;return(a+(((a+6)>>4)+(((a+6)>>4)<<1))<<1)&15;}
int rotate_0_9_457_2(int a){a++;return(a+((a+6)>>4)*6)&15;}
int rotate_0_9_458(int a){return ++a%9;}
int rotate_0_9_460(int a){return a<9?a+1:0;}
//#define COUNT_TIMES 0x7fffffff
#define COUNT_TIMES 0x7ffffff
#define TEST(func) \
dwTime = GetTickCount(); \
for(i = 0, count = 0; count < COUNT_TIMES ; count++) { \
i=func(i); \
} \
printf( # func " %d msec\n", GetTickCount() - dwTime);
main() {
int i, count;
DWORD dwTime;
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS);
Sleep(100);
TEST(rotate_0_9_457_1)
Sleep(100);
TEST(rotate_0_9_457_2)
Sleep(100);
TEST(rotate_0_9_458)
Sleep(100);
TEST(rotate_0_9_460)
return 0;
}
----------------------------

466:デフォルトの名無しさん
07/09/30 00:38:34
printf( # func " %d msec (i:%d)\n", GetTickCount() - dwTime, i);
と変更して計算結果も表示してみたら>>457の最初の式の結果がおかしい事に
気付いたんだけど。

rotate_0_9_457_1 1862 msec (i:0)
rotate_0_9_457_2 1272 msec (i:7)
rotate_0_9_458 3986 msec (i:7)
rotate_0_9_460 671 msec (i:7)

467:デフォルトの名無しさん
07/09/30 00:40:00
int rotate_0_9_467(int a){
static int t[10]={1,2,3,4,5,6,7,8,9,0};
return t[a];
}
表引き。
これもやってみてくれ。

468:デフォルトの名無しさん
07/09/30 00:49:01
>>457
やってみるよ。

457_1のiの推移
0 2 6 14 4 10 12 0 2 6 14 4 10 12 0 2 6 14 4 10 12 0 2 6 14
無茶苦茶だった。

469:デフォルトの名無しさん
07/09/30 00:55:09
rotate_0_9_457_1 1893 msec (i:0)
rotate_0_9_457_2 1272 msec (i:7)
rotate_0_9_458 3996 msec (i:7)
rotate_0_9_460 661 msec (i:7)
rotate_0_9_467 621 msec (i:7)

テーブル引きのがわずかに速いね。
>>460と>>467が微差だったんでカウンタ倍にしてみた。
#define COUNT_TIMES 0xfffffffに変更。

rotate_0_9_457_1 3535 msec (i:2)
rotate_0_9_457_2 2553 msec (i:5)
rotate_0_9_458 7991 msec (i:5)
rotate_0_9_460 1332 msec (i:5)
rotate_0_9_467 1202 msec (i:5)

計ったPCはThinkPad X31 (PenM1.6G Banias) XPSP2

470:デフォルトの名無しさん
07/09/30 00:57:00
あと>>458は0～8の繰り返しで条件が違うんで
int rotate_0_9_458(int a){return ++a%10;}
に修正してる

471:デフォルトの名無しさん
07/09/30 01:13:29
_rotate_0_9_457_2 PROC NEAR
; 13 : int rotate_0_9_457_2(int a){a++;return(a+((a+6)>>4)*6)&15;}

mov ecx, DWORD PTR _a$[esp-4]
inc ecx
lea eax, DWORD PTR [ecx+6]
sar eax, 4
lea eax, DWORD PTR [eax+eax*2]
lea eax, DWORD PTR [ecx+eax*2]
and eax, 15
ret 0
_rotate_0_9_457_2 ENDP
掛け算消えるんだね

_rotate_0_9_458 PROC NEAR
; 14 : int rotate_0_9_458(int a){return ++a%10;}
mov eax, DWORD PTR _a$[esp-4]
mov ecx, 10
inc eax
cdq
idiv ecx
mov eax, edx
ret 0
_rotate_0_9_458 ENDP
見るからに遅そうな

472:デフォルトの名無しさん
07/09/30 01:16:44
_rotate_0_9_460 PROC NEAR
; 15 : int rotate_0_9_460(int a){return a<9?a+1:0;}
mov eax, DWORD PTR _a$[esp-4]
cmp eax, 9
jge SHORT $L53312
inc eax
ret 0
$L53312:
xor eax, eax
ret 0
_rotate_0_9_460 ENDP
普通だね

_rotate_0_9_467 PROC NEAR ; COMDAT
mov eax, DWORD PTR _a$[esp-4]
mov eax, DWORD PTR _?t@?1??rotate_0_9_467@@9@9[eax*4]
ret 0
_rotate_0_9_467 ENDP
短いね
この短さがテーブル参照のオーバーヘッドを相殺してる？
けどaが10以上だったら脂肪

473:デフォルトの名無しさん
07/09/30 01:27:47
まあ表引きはキャッシュから外れた時にペナルティがあるから
平均的には>460がいいんだろうな。

474:デフォルトの名無しさん
07/09/30 02:05:05
>>473
確かに、別の環境だと逆転してたり。

#Celeron 430@2.4G XPSP2
rotate_0_9_457_1 1750 msec (i:2)
rotate_0_9_457_2 1359 msec (i:5)
rotate_0_9_458 2969 msec (i:5)
rotate_0_9_460 719 msec (i:5)
rotate_0_9_467 860 msec (i:5)

#Core2Duo 4300@3.2G XPSP2
rotate_0_9_457_1 1281 msec (i:2)
rotate_0_9_457_2 1000 msec (i:5)
rotate_0_9_458 2172 msec (i:5)
rotate_0_9_460 516 msec (i:5)
rotate_0_9_467 656 msec (i:5)

475:デフォルトの名無しさん
07/09/30 04:40:29
％は割り算があるから遅いってことか。0～9ではなく0～2^n-1の場合にかぎり使えばいいかな。
でも実際の仕事では0～99のローテートでも％で書いたりするなあ。

476:デフォルトの名無しさん
07/09/30 08:29:40
剰余は定数除算よりも更に遅い。

477:デフォルトの名無しさん
07/09/30 09:14:40
その剰余をビット演算でなんとか．．．

478:デフォルトの名無しさん
07/09/30 10:11:46
このスレの355から、剰余をビット演算でする方法が書かれているよ。

入力が必ず0～9なら
a=((a+7)&15)-6; 　// 0～8 が 1～9 9が-6

(aの符号拡張か　4bitの算術右シフト結果)のビット反転と and

479:457
07/09/30 23:43:50
ふぬぅ、やっぱ分岐しない上にテーブルも使わない奴は遅いな。

480:デフォルトの名無しさん
07/09/30 23:45:02
逆に考えて、分岐する上にテーブルも使う奴は・・・

すまん、逆に遅くなりそうだ。

481:デフォルトの名無しさん
07/10/01 16:44:48
modも内部的には分岐してるだろ。RISCならよくわかる。

482:デフォルトの名無しさん
07/10/01 17:41:59
え～(*o*) それは２のｎ乗の場合とそうでないので分けてるとか？

483:ヽ・´∀｀・,,）っ━━━━━━┓
07/10/04 02:56:19
剰余　＝　披除数－ (除数＊商)

一般的には商と剰余は同時に求めることが可能

484:デフォルトの名無しさん
07/10/21 17:07:33
age

485:デフォルトの名無しさん
07/10/21 18:36:55
剰余のビット演算への変換ならこのページにあるよ。
URLﾘﾝｸ(www.tensyo.com)

縛りを入れるともっと高速化出来そう…

486:デフォルトの名無しさん
07/10/23 00:23:05
ある変数の値が

2018か2019
4049か4050
であるか判別する方法は4回比較するしか
ないかな？

487:デフォルトの名無しさん
07/10/23 00:49:07
愚直な方法だけど比較２回には減らしてみた。
bool check(int value) {
const int mask = ~1;
if( (value & mask) == 2018 || ((value + 1) & mask) == 4050 ) return true;
return false;
}

488:デフォルトの名無しさん
07/10/23 01:56:04
テストしてないけど。
bool check(int value) {
const int mask = ~1;
if (((abs(value - 3034) + 1) & mask) == 1016) return true;
return false;
}

489:デフォルトの名無しさん
07/10/23 09:11:06
AND も加算も比較＝減算も、演算量は同じ、ってこと考えたら、どっちも減ってない。
比較４回に比べてリーダビリティは下がってる。

490:デフォルトの名無しさん
07/10/23 09:53:31
switch (value) {
case 2018: case 2019: case 4049: case 4050:
　　doit();
}

491:デフォルトの名無しさん
07/10/23 11:06:26
if (v == 2018 || v == 2019 || v == 4049 || v == 4050) return 1;
return 0;
0m48.123s
0m2.250s

const int mask = ~1;
if ((v & mask) == 2018 || ((v + 1) & mask) == 4050) return 1;
return 0;
0m53.281s
0m2.278s

const int mask = ~1;
if (((abs (v - 3034) + 1) & mask) == 1016) return 1;
return 0;
0m52.661s
0m2.167s

switch (v) {
case 2018: case 2019: case 4049: case 4050:
return 1;
}
return 0;
0m46.065s
0m2.087s

if (v < 2018 || (v > 2019 && (unsigned int) (v - 4049) > 1)) return 0;
return 1;
0m45.938s
0m2.086s

いろいろ測ってみた
コンパイラやマシンによって違うと思うけど

492:デフォルトの名無しさん
07/10/23 11:25:06
４回比較より下の２つのが短いのが不思議ですね。
入力が多数回で、４つの値が均等にバラつくという条件にしたら、最後まで演算しない４回比較
がイイかと思えますが。

493:デフォルトの名無しさん
07/10/23 11:26:33
>>489
可読性も考慮するの？このスレで？

494:デフォルトの名無しさん
07/10/23 11:29:15
ちなみに最後の一個はswitchバージョンのアセンブル出力をCに直したもの

495:デフォルトの名無しさん
07/10/23 12:45:37
iccで試してみた。
# icc -xP -O3 -ip
# icc 10.0
上から、0.3, 0.23, 0.33, 0.3, 0.22[sec/(10000 * 10000call)]だった。
どうやらswitchで書いても一番上と同じような出力になるようだ。
gccでも試してみた。
# gcc -O3 -funroll-loops
# gcc 3.4.6
こちらは、0.16, 0.22, 0.27, 0.17, 0.22[sec/(10000 * 10000call)]だった。
なんでこんなに速いんだ?w

496:デフォルトの名無しさん
07/10/23 21:35:27
>>495
アセンブリコードで比較してみると分かるんじゃね？

497:デフォルトの名無しさん
07/10/23 23:12:05
俺には>>486が
if(v==2018||v==2019){
}else　if(v==4049||v==4050){
}else{
}
って条件に読めるんだが

498:デフォルトの名無しさん
07/10/23 23:17:57
俺も俺も

499:デフォルトの名無しさん
07/10/24 00:23:34
>>486
日本語でおｋ

やっと言う側に回れたか

500:デフォルトの名無しさん
07/10/24 01:05:28
>>497
いや、今日きちんとみかか村に出撃して
糞仕様について問い詰めてきたけど

case 2018: case 2019: case 4049: case 4050:

で正しい

どうもみんなありがとう

501:デフォルトの名無しさん
07/11/02 19:56:43
>491
>if (((abs (v - 3034) + 1) & mask) == 1016) return 1;
ここら辺の数値の導き方教えてください
どいった関係で3034とか出すの？ど素人ですんません

502:デフォルトの名無しさん
07/11/02 20:15:08
>>501
2018+4050=2019+4049=3034+3034

v = [2018 or 2019 or 4049 or 4050] の時
abs(v - 3034) = [1015 or 1016]
abs (v - 3034) + 1 = [1016 or 1017]
mask=0xfffffffeより奇数はそれを超えない偶数に変換される。
(abs (v - 3034) + 1) & mask = 1016

503:デフォルトの名無しさん
07/11/02 21:44:43
>502
ものっそい感動しました
久しぶりに成長した気がする
この括り方すげー

504:デフォルトの名無しさん
07/11/03 20:48:03
もはや逆方向にソースから動作仕様を求めることはほぼ不可能だな

505:デフォルトの名無しさん
07/11/04 06:35:34
かっこいい BIN→BCD は？

506:デフォルトの名無しさん
07/11/04 08:47:47
速さなら、00h,01h,02h・・・を表に持ち、binで表引き。 <99のチェックは必要。
サイズなら、((bin/16)<<4) | (bin%16) ・・・バイト版。　<99のチェックは必要。
ワードは、／100の商と余りに分けて、上のを呼び、合成。
自分で書いたのはこんな当たり前の奴だなあ・・・

507:デフォルトの名無しさん
07/11/10 16:03:38
しばらく前はメモリアクセスがからむテーブル参照の方が重いって話だったけど、
また状況変った？

508:デフォルトの名無しさん
07/11/10 16:47:46
キャッシュの容量
メモリアクセス速度とキャッシュアクセス速度の比率
によって変わるからなあ
細かくいいだすとキャッシュ方式も絡むし
結局「場合による」んじゃねえの

509:デフォルトの名無しさん
07/11/10 17:28:19
一般論としては、キャッシュに載っている(=頻繁に呼ばれる)ならテーブルの方が速いんじゃないかね。
ただ、この場合の「一般」というのは、分岐が含まれる(=分岐ミスの可能性がある)という前提。

例えば上の((bin/16)<<4) | (bin%16) の場合だと
依存関係が2箇所あって、その部分は同時実行は出来ないけど
キャッシュアクセスに要する数クロック程度の時間と比べてどちらが速いかはわからんね。

テーブルジャンプ(ほぼ同じ値が続く場合以外)は糞だけど。

510:デフォルトの名無しさん
07/11/10 17:37:19
掛けたり割ったりすることにものすごい抵抗感がある

511:デフォルトの名無しさん
07/11/10 18:06:01
いや、この場合に限れば、まず間違いなく最適化でシフトやアンドになるよ。

512:506
07/11/11 02:32:03
今のチップで乗除算持ってないほうが珍しいよね。俺が書いたのは3MHzの8085だったから、
キャッシュ云々の話はなし。／100だけは除算ルーチン使わないとだめだった。

513:デフォルトの名無しさん
07/11/11 13:44:02
ARMは現役のチップだけど除算命令なかったような

514:デフォルトの名無しさん
07/11/14 11:40:49
x/100　は　掛け算があるなら
655*( x + x/2048 + x/16384)/ 65536

515:デフォルトの名無しさん
07/11/14 14:14:26
その掛け算とｼﾌﾄの計算量なら、100=64hだから、分母の<<2と<<5と<<6を引いたほうが・・・

516:デフォルトの名無しさん
07/11/14 15:57:51
y = (655*x)>>16 で概算して

while ( x-y*100>=100 ) y++;

ならせいぜいループ１回だろ

517:デフォルトの名無しさん
07/11/14 18:05:59
最低でもx<6557202(≒(1<<32)/655)が言えなければ。

518:デフォルトの名無しさん
07/11/14 18:34:29
>>512

(42949672*x+65536)>>32

519:デフォルトの名無しさん
07/11/15 07:36:11
シフト演算子がアンカーになってしまう（ｗ
>>514-516 は、たぶん数学的には同等なような気がする。

>>518 それ、どういう原理なの？ 32シフトしたら全部なくなっちゃうような気が・・・

520:デフォルトの名無しさん
07/11/15 08:53:19
32bitレジスタ持ってるような16bit以上のCPUを想定してるんだろ

x386なら32x32bit掛け算の結果が２つのレジスタに判られるから 32bitシフトは上位のレジスタを採用するだけになる。

521:デフォルトの名無しさん
07/11/15 11:57:03
>>32
>>32

522:デフォルトの名無しさん
07/11/15 12:18:01
>>512
>>‍32

523:デフォルトの名無しさん
07/11/15 12:22:04
>>521
>>522
何が言いたいのか意味不明だ。

524:デフォルトの名無しさん
07/11/15 12:29:42
>>523

525:デフォルトの名無しさん
07/11/15 12:42:20
これでどうだ

x >> 32

526:デフォルトの名無しさん
07/11/15 12:44:23
俺他人だけど　>>‍523 色が違うだろって言いたいんじゃないのかな？

527:デフォルトの名無しさん
07/11/15 13:11:18
>>523
こうすればいいのよ（たぶん）

528:527
07/11/15 13:12:44
>>‍527
吊ってくるorz

529:518
07/11/15 16:36:17
>>520
あたり。
あと、>>518のxは0～65535の範囲である必要がある。

530:デフォルトの名無しさん
07/11/15 16:54:12
多少ステップ数がかかるように見えても、まだハードウエア除算は普通の命令２０個分以上に重いからな
1/100 は1/10のルーチンを２度呼んでたな。

1/10は1/2/5 だから１ビットシフトしてから５で割る
65536/5=13107.2 だから13107を係数に使うと誤差は16bitの範囲で１
だけど１ビットシフトしてるから、15bitの範囲になってるから最大誤差は0.5なんでOK
という事で、最大誤差の0.5を足して

x = x / 2
x = (13107*x+ 6553) / 2^16

を２度繰り返す

531:デフォルトの名無しさん
07/11/16 01:35:07
>>518 や、>>530 は余りも一緒に求まるの？

532:デフォルトの名無しさん
07/11/16 08:46:49
この話は掛け算が高速ならという話だから
余りは後から　y=x/N を求めた後 x-N*y で求めればいい

余りだけが必要なら355付近から話題が出てる

533:デフォルトの名無しさん
07/11/16 09:53:08
実測で、ハードウェアまたはCの除算を上回るルーチン作れるの？うｐして
動かしてみる辛さ

534:デフォルトの名無しさん
07/11/16 10:26:25
どっかのスレでやってたでしょ。
パソコンの除算命令はレイテンシが大きいから連続して実行させるととても重くなる。
ただ整数ユニットでは実行されないから、その間に他の命令を入れられるならＯＫ

あ、このスレか、>>367-379

535:デフォルトの名無しさん
07/11/16 10:59:28
int型の除算で標準のものより速いものは作れるのか作れないのか？

536:デフォルトの名無しさん
07/11/16 11:03:08
分母が固定なら可能。　変数なら無理。　

537:デフォルトの名無しさん
07/11/16 11:04:47
まてよ。分子が固定な場合、ニュートン法である程度いけるかな・・・・まあ無理か

538:デフォルトの名無しさん
07/11/16 11:23:21
分母が固定ならif文などで分岐すれば、総合的には速度が上げられるのか?
作ってくれ

539:デフォルトの名無しさん
07/11/16 11:26:26
経験上、演算や比較文より代入に時間がかかる気がする
たぶんレジスタ動作　+　演算より、メモリ動作は遅いんだろう

540:518
07/11/16 11:39:24
>>535
ループの中で定数(変数でも変わらなければＯＫ)で除算するのは、
置き換えた方が高速化できるし、それを実際に使っている。

ピクセル操作のような回数の多いループでは劇的な効果がある。

>>539
それは毎回キャッシュから外れた場合の話。
オンキャッシュなら少しでもＣＰＵを止めない方がいい。

541:デフォルトの名無しさん
07/11/16 11:45:08
>>538
で、分母はいくらなの？　100の場合はいろいろ出てるよね。

542:デフォルトの名無しさん
07/11/16 11:46:27
汎用の除算は出来ないか?
例えば2～500まで定数だけ作って分岐させて使う
そのとき高速になるのか?

543:デフォルトの名無しさん
07/11/16 11:48:53
その分岐の為に時間を使ってしまうから無理だろうね
たとえば関数テーブルで分岐したとしても、キャッシュミスを起こすだろう。

544:518
07/11/16 11:50:14
>>542
できる。
それぐらいなら除数の逆数のテーブルを使って可能。分岐はさせないほうがいい。
ただ、16bit全域とかになると、テーブルの方が不利になるCPUが多い。

545:デフォルトの名無しさん
07/11/16 11:54:52
逆数で気づいたけど、浮動小数点の掛け算で計算すると鈍いの？

546:デフォルトの名無しさん
07/11/16 11:57:24
逆数の2進展開を持っていたらビット演算できそうだけど・・・どうだろ　速いのか？

547:デフォルトの名無しさん
07/11/16 12:00:46
たびたび連投すまんが、計算でループを使うなら、はじめに分岐させてもコストは同じようなものだな
2～1024までなら10回の分岐で決定する　10回程度のループを使うなら分岐させた方が良い

548:デフォルトの名無しさん
07/11/16 12:01:09
>>544
(A*x+B)のＡ，Ｂをテーブルにするの？

でも、たとえば　65535÷３はどうするの？A=21845にしたら、これでは無理だよね

549:デフォルトの名無しさん
07/11/16 12:10:41
x / n = (Ax + B ) >> C ってどうやって求めるの？

550:518
07/11/16 12:12:05
>>548
そうそう。Bは固定でいい。

16ビット範囲の X / Dなら、R = 4294967295 / D として、

X / D の値は (R * X + 65536) >> 32となる。

Dが複数あるなら、D→Rのテーブルを作ればＯＫ

551:デフォルトの名無しさん
07/11/16 12:14:16
>>550
BCC5.5だけど、上のやつ計算できなかったよ

552:518
07/11/16 12:19:40
>>551

__asm{
mov eax, R
mul X
add eax, 010000h
adc edx, 0
mov eax, edx
}

553:デフォルトの名無しさん
07/11/16 13:04:33
>>550

Rが切り捨てなら汎用になるように
(R * X + R - 1 ) >> 32
でいいんじゃないの？

554:518
07/11/16 13:09:18
>>553
65536より、R - 1のがいい理由は何？

555:デフォルトの名無しさん
07/11/16 13:24:06
理由は、Xが16bitの範囲を超えて入力された時の誤差が多少でも減る事だな

556:518
07/11/16 13:36:17
>>555
誤差が許される場合はいいかもね。
そうでない場合は、素直に３２ビットに拡張した方が良くないか？

557:デフォルトの名無しさん
07/11/16 14:03:01
ようするに
(A * x + A-1 ) >> B
として AのMSBが1になるように B を調整するって事だよね？

Ｂは常に32以上だから、実際には上位ワードだけを>>(B-32) するのだろうけど

558:518
07/11/16 17:10:53
>>557
いや、そうじゃなくて、余計なA - 1 という演算を使うのではなく、
550の式を32ビットに拡張すればいいってこと。

32ビット範囲の X / Dなら、R = ((1 << 64) - 1) / D として、
X / D の値は (R * X + (1 << 32)) >> 64となる。

559:デフォルトの名無しさん
07/11/17 04:25:26
>>530
ルネサスのマニュアルによるとシフト演算と割り算に迷ったら割り算の方が大抵速いみたいなことが書いてあったけど

560:デフォルトの名無しさん
07/11/17 07:26:50
>>558 さすがに64bit掛算はまだ普及してないだろ

561:デフォルトの名無しさん
07/11/17 07:28:20
>>559 SHが特殊で固定シフト命令が1,2,4,8みたいな飛び飛びのシフトしか１命令で出来なかったりするからじゃないの？

562:デフォルトの名無しさん
07/11/17 12:16:14
でも、仕事で使用するとしたら、普通に割り算したほうがソースとして見やすいよね。
2で割るのを1ビットシフトするぐらいはいいけど、あえて複雑な演算にするほど処理能力を求められないでしょ？普通の開発は。

でも、このような議論って技術者としては面白いし、ある意味大切だよね。

563:デフォルトの名無しさん
07/11/17 12:40:03
>>560
アルゴリズム上の話で、実際に64bit乗算をするわけではないと思う。

元ネタはこれじゃね？
URLﾘﾝｸ(www.emit.jp)

564:デフォルトの名無しさん
07/11/17 13:51:33
>>560
コンパイラがやってくれることもしばしば。
まぁ尤も、コンパイラのアセンブリ出力を見たときに「割り算がない」って悩まないためにも
知識はあったほうがいいのだけれどね。

565:デフォルトの名無しさん
07/11/17 13:57:31
Y = (R * X ) >> 64 って事は、R = 2^64 / D って事だろ？
Dが16bitの範囲なら Rは　48bitって事になるぞ。　64bitモードに以降しないと効率悪いぞ

566:デフォルトの名無しさん
07/11/17 14:00:28
もともと
D=100の場合

1　: ( x * 4294967200 + 65536) >> 32
2　: ( x * 4294967200 + 4294967199 >> 32
のどっちが大きな x までまともに計算出来るかって問題でしょ？

567:デフォルトの名無しさん
07/11/17 14:01:49
違うか
1　: ( x * 42949672 + 65536 ) >> 32
2　: ( x * 42949672 + 42949671 ) >> 32

568:デフォルトの名無しさん
07/11/17 15:24:56
BCCで出来ないんだけど・・・CPUのせいかもしれない
内部で32+24ビット程度しか保持していない気がする

569:デフォルトの名無しさん
07/11/17 15:33:51
>>518がちゃんとうごくぱそこんってあるの?
テストプログラム作ったけど上位1ビットの値は壊れているようだ

#include <iostream>
using namespace std;

main(){
int n;
for(n=50;n<=64;n++)
cout<<n<<" "<<(unsigned int)((1<<n)>>(n-1))<<endl;
}

570:デフォルトの名無しさん
07/11/17 15:43:45
これっていくつになりますか?
1になるはずですよね?

cout << (unsigned int) ( ((1<<64)-2) >> 63 );

571:デフォルトの名無しさん
07/11/17 17:43:47
>>570
-1を unsigned にキャストしてるんだからUINT_MAXになると思う。

572:デフォルトの名無しさん
07/11/17 18:06:10
符号付整数の右シフトが論理シフトになるか算術シフトになるかは処理系定義

573:ヽ・´∀｀・,,）っ━━━━━━┓
07/11/17 19:18:14
>>569
unsigned __int64かunsigned long longでおｋ

574:ヽ・´∀｀・,,）っ━━━━━━┓
07/11/17 19:20:40
>>570
なんで普通のコンピュータで使えるビット数越えたシフト使うんだ。
1 << 64なんてオーバーフローで0になること確定じゃないか。

575:デフォルトの名無しさん
07/11/17 20:42:48
~0ULLでおｋ

576:デフォルトの名無しさん
07/11/17 23:58:43
>>569

>>563のコードと同じだからそっちでやってみればいいんじゃないか。

577:デフォルトの名無しさん
07/11/18 07:54:51
#include <iostream>
using namespace std;

main(){
unsigned int n;
for(n=60;n<64;n++)
cout<<n<<" "<<(unsigned int)(((1<<n)-2)>>(n-1))<<endl;
cout<<63<<" "<<(unsigned int) ( ((1<<63)-2) >> 62 );
}

63の値が変わるのはなぜ?

578:デフォルトの名無しさん
07/11/18 08:34:36
>>577
サイズを超えるシフトは未定義。

579:デフォルトの名無しさん
07/11/18 22:48:23
ARMは割り算使うと糞遅いから困るな。

580:デフォルトの名無しさん
07/12/03 22:55:09
age

581:デフォルトの名無しさん
07/12/03 23:13:14
32bitパソコンだと、16*16しか値は保証されないよね
a + b * 65536　などと表示して、32bit以上を表現したら
ハードウェア搭載の除算よりビット演算のほうが速い?
除算が現れたらintを16bit数に変換して計算する

582:デフォルトの名無しさん
07/12/04 05:02:29
X = 65536 、R = 1/Xとすると

(a+bX) / (c+dX) = (b+aR) / (d+cR)であり、

1/(1+R)　のテイラー展開は、　1　-　R + R^2 - ・・・+(-R)^n+ ・・・
Rの巾は非常に小さいため2乗までを採用すると、

(a+bX) / (c+dX)　=　( (b+aR)/d ) * 1/(1 + cR/d)
=( (b+aR)/d ) * (1 - cR/d + (cR/d)^2 )
=1/(X^3 * d^3) * (a + bX ) * (c^2 -cdX + d^2X^2 )　となる

これで32bit除法を高速化出来るか?

583:582
07/12/04 05:12:33
32bit内で処理しようとすると大変だ　普通にCPUに任せた方が楽そう

584:デフォルトの名無しさん
07/12/16 20:25:38
BOOL bResultの値が 0 か -1
if (bResult == 0 || bResult == -1)

じゃなくて、一発で調べる方法はないですか？

585:デフォルトの名無しさん
07/12/16 20:42:35
BOOLなのに何故数値と比較してるんだ？

586:デフォルトの名無しさん
07/12/16 21:10:40
GetMessageじゃね？

587:デフォルトの名無しさん
07/12/16 21:30:22
BOOLは偽==0、真==0以外じゃなかったか？
定義を調べた方が良さそう。

588:デフォルトの名無しさん
07/12/16 22:05:41
世の中には変な使い方する椰子がいるのよ。MSとかw

URLﾘﾝｸ(msdn.microsoft.com)

589:デフォルトの名無しさん
07/12/16 22:08:46
if(bResult^0==-1)

590:デフォルトの名無しさん
07/12/16 22:37:38
x^0=x

591:デフォルトの名無しさん
07/12/16 22:42:19
if (((((uint32_t)bResult) + 1) >> 1) == 0)

同じ3演算だけど-1をロードしないだけ早いかも？
uint32_tがいいかどうかはよくわからない。

592:デフォルトの名無しさん
07/12/17 00:16:01
-1か0、限定なんだからそのまま書いたほうが分かりやすいような。

593:デフォルトの名無しさん
07/12/17 00:26:58
>>588
( ･д⊂ヽ゛

594:デフォルトの名無しさん
07/12/17 00:29:32
>>588
>警告 GetMessage 関数は、0 以外の値、0、-1 のいずれかを返します。したがって、次のようなコードは避けてください。

そもそも…

595:デフォルトの名無しさん
07/12/17 00:30:54
まー継ぎ接ぎだからな

596:デフォルトの名無しさん
07/12/17 00:39:34
>>591
右シフト・条件分岐より、比較・条件分岐の方が速くない？

if (((uint32_t)bResult + 1) <= 1)

597:デフォルトの名無しさん
07/12/17 00:50:04
>>596
マシン語レベルでは結局0比較に変換されるから同じ程度じゃないかな。
でもCレベルではそっちの方が短くていいと思う。

598:デフォルトの名無しさん
07/12/17 01:17:11
>>597
ちょっと前まで主流だった某CPUではシフトは加減算の
8倍遅かったし、それ以外のCPUでも演算器の関係で
シフトの方が並列化されにくいかも、とかそういう話。

599:デフォルトの名無しさん
07/12/17 01:19:21
で、何億回呼ぶのよ

600:デフォルトの名無しさん
07/12/17 02:05:25
シフトのほうが速いと思ってたのに・・・

601:デフォルトの名無しさん
07/12/17 03:12:30
>>599
そんなこと言うならこのスレの意義って一体なんなのさ。

確かにWindows APIをそんなアホみたいに呼ぶ事はないだろうが、
こんな風に一般化してみれば、それなりに使い道はあるだろ。

_Bool bounds_check(int n, int lower, int upper)
{
　return (unsigned)(n - lower) < (unsigned)(upper - lower);
}

>>600
加減算よりシフトの方が速いCPUなんてあるのかな？
演算の頻度からいっても普通は加減算を最速に設計すると思うけど。
x86系を数種類しか触った事ないから、他にはあるのかも知れないが。

602:デフォルトの名無しさん
07/12/17 04:47:19
ハードウェアの構造上加減算よりシフトの方が圧倒的に単純なんだよ
小さい加算器を作ったことがあればわかるはず
クロック数が一緒ってことはあるかもしれんが、
シフトの方が遅いってことはまずないだろう

603:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/17 05:39:05
ARMだと全命令にプレディケーション使えるからCレベルの単純な分岐は直列化できるよ
分岐は極端に遅いなんていうのはCellプログラマだけにしてください。

604:デフォルトの名無しさん
07/12/17 07:41:05
>>602
このケースは1bitだからその通りだけど
x86の8086-286までは、2bit以上のシフトは遅かったんだよ。
最初は直接bit数指定のインストラクションすらなかったし。

605:デフォルトの名無しさん
07/12/17 13:11:19
URLﾘﾝｸ(answers.google.com)

606:デフォルトの名無しさん
07/12/17 13:13:10
>>603
単純な分岐なら、if文使ってコンパイラに任せた方が速いね。
絶対値求める時とか、NULLならreturnするとか、分岐コストかからなくていい。

607:デフォルトの名無しさん
07/12/17 14:37:02
むしろif文にbool型しかとらないJava/C#が異端なんじゃねーの？
俺もbool型オンリーの方が好きだが、スクリプト言語してるとそうじゃない方が多い気がする。

608:デフォルトの名無しさん
07/12/17 18:27:51
ifの選択肢にTrueとFalse以外なんてあり得るの？

609:デフォルトの名無しさん
07/12/17 18:33:36
if(666){//実行されます。}

610:デフォルトの名無しさん
07/12/17 19:02:56
コメントに括弧閉じ書いて意味あんの

611:デフォルトの名無しさん
07/12/17 21:34:17
if (GetMessage(...) <= 0)

で充分でね?

612:デフォルトの名無しさん
07/12/17 21:49:47
>>602
シフタってのはデータセレクタの塊だから多ビットのシフトは
シリコンの面積を喰うのよ

613:デフォルトの名無しさん
07/12/17 23:54:21
>>611
-1以外の負の値が未定義

614:デフォルトの名無しさん
07/12/17 23:54:34
シフタのないプロセッサには出会ったことが無いけどね。

615:デフォルトの名無しさん
07/12/17 23:58:16
if (bResult == 0 || bResult == -1)

は

if (((uint32_t)bResult + 1) <= 1)

と同じコードになったぞ。
gcc賢いな。
ちなにみRISCでどうなるか見たかったので団子の嫌いなCELLのgccでコンパイルしたw
ちなみにCELL(SPE)もヒントブランチあるから。
むしろARMのプリディケーションいまいちだと思うけど。

616:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/18 00:11:17
知ってるが

Cellのスカラ性能が
気に食わない

617:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/18 00:45:11
分岐ヒントもBranchの15クロックくらい前くらいに入れないと駄目じゃなかったっけ
しかも二重に使うとハングする致命的なバグ持ちだから始末に困る

618:デフォルトの名無しさん
07/12/18 00:47:47
if (bResult == 0 || bResult == -1) こんなん対して食わないだろ゜

619:ヽ・´∀｀・,,）っ━━━━━━┓
07/12/18 00:52:15
SSE4.1のXMMに対する比較命令が加わったから4条件同時判定とかも便利そうだね

620:デフォルトの名無しさん
07/12/18 08:10:08
ダンゴさんが連投するとスレが引き締まるな

621:デフォルトの名無しさん
07/12/18 11:30:40
ダンゴage

622:デフォルトの名無しさん
07/12/18 20:46:31
test

623:デフォルトの名無しさん
07/12/21 07:08:36
test

624:デフォルトの名無しさん
07/12/21 07:18:07
URLﾘﾝｸ(www.nicovideo.jp)

625:デフォルトの名無しさん
07/12/30 10:37:00
年末あげ

626:デフォルトの名無しさん
08/01/03 18:36:52
URLﾘﾝｸ(itl.jisakuita.net)

ダンゴさんすげえな

627:デフォルトの名無しさん
08/01/09 19:20:08
sge

628:デフォルトの名無しさん
08/01/14 22:47:23
V(･∀･)V

629:デフォルトの名無しさん
08/01/21 23:54:19
あげ

630:デフォルトの名無しさん
08/01/22 00:09:06
以下の2つの値があったとします。
x1 = 0xFF842144
x2 = 0x5400FF33

ユーザからの入力u1、u2が入力された場合
考えられるケースは以下の4つになると思います。
・u1=x1、u2=x2一致
・u1=x1一致
・u2=x2一致
・どちらとも一致しない

最低3回比較しないとどのケースか判断できないって
思い込んでるのですが
何かいいアイディアくれる人いませんか？

631:デフォルトの名無しさん
08/01/22 00:46:32
愚問だと思いますが。。

しかし、そんあ80年代前半のBASICの論理式みたいなアナクロな発想をするって
今日日奇特な人だね。

632:デフォルトの名無しさん
08/01/22 00:50:58
u1がx1と一致するケースに
・u1=x1一致、u2=x2一致
・u1=x1一致、u2=x2不一致
がある
u1がx1と一致しないケースに
・u1=x1不一致、u2=x2一致
・u1=x1不一致、u2=x2不一致
がある

つまり４通り
比較は最大２回

633:デフォルトの名無しさん
08/01/22 01:21:29
その比較を10^12回通りくらい計算するつもりなら最適化もあり

634:デフォルトの名無しさん
08/01/22 01:30:35
あらかじめ
p = x1 XOR x2
の値を取得しておく
q1 = p XOR u1
q2 = p XOR u2
を得る

635:ヽ・´∀｀・,,）っ━━━━━━┓
08/01/22 01:30:56
SSE4のptest使えば一回で済む

636:デフォルトの名無しさん
08/01/22 01:54:14
>>634
得た後はどうすればいいのw？
q1とq2をどうやって使うの？

637:デフォルトの名無しさん
08/01/22 02:56:20
>>632
＞・u1=x1一致、u2=x2一致
あんた馬鹿?

638:デフォルトの名無しさん
08/01/22 11:10:15
>>635
無理だろ，あれは and と andnot だから．pcmpeqd の方が良さげ

639:デフォルトの名無しさん
08/01/22 11:49:49
632ってこういうことだろ？

if( u1 == x1 ) {
if( u2 == x2 ) {
//ryouhou
} else {
//u1 nomi
}
} else {// not
if( u2 == x2 ) {
//u2 nomi
} else {
//ryouhou itti sinai
}
}

どこも間違ってるように思えないんだが。

640:デフォルトの名無しさん
08/01/22 12:34:57
しかし、BY（文脈読めない）な奴が多いな。

ここがどういうスレかを考えれば、>>630が何を聞きたいか
多少説明不足でもだいたい分かるだろ普通w

641:デフォルトの名無しさん
08/01/22 13:13:10
ほうほう。それでそれで?

642:デフォルトの名無しさん
08/01/22 18:32:50
int a[] = {両方一致, 片方一致, 片方一致, 一致しない};
b1 = (u1 == x1)
b2 = (u2 == x2)
return a[(b1 << 1) | b2];

643:642
08/01/22 18:33:45
× int a[] = {両方一致, 片方一致, 片方一致, 一致しない};
○ int a[] = {一致しない, 片方一致, 片方一致, 両方一致};

644:デフォルトの名無しさん
08/01/23 10:32:39
ゼロフラグでレジスタに0,1をセットする命令があるならソレが効率的だね。

それがないと、減算して、さらに１引いてキャリーを出してローテートしなくちゃいけない
アキュムレータが2個しかないCPUなら
AccA := u1-x1-1;
RotWithC(AccB);
AccA := AccA+x1+1-x2-1;
RotWithC(AccB);
AccB := AccB and 3;

結局、そのあたり何が効率的かはアセンブラで見ないといけないけど
アセンブラで出来る高速化は、リニアにしか効かないから、そんなに意味ないんだよね

645:デフォルトの名無しさん
08/01/23 20:55:34
全面的に同意．ただ２倍位速くなることもあるから最後の手としては有効．まぁ今は可能 intrinsic 使うけど．

646:デフォルトの名無しさん
08/01/23 21:06:35
割り算を掛け算とビットシフトに置き換える計算式求めるプログラムできた

#include <iostream>
using namespace std;
main(){
unsigned int N,n,k;
for(N=2; N<65000 ; N++){
for(n=0; (1<<n)<N ; n++); n+=15;
double X=(pow(2,n)/N);
unsigned int Y=(unsigned int)X;
unsigned int d=0;
if(X-Y<=Y+1-X)d=(unsigned int)(pow(2,n)- (N-1)*Y)-1; else Y++;
printf("x /%5d = ( x * %5d + %5d ) >> %2d",N,Y,d,n);
for(k=1; k<(1<<16) ; k++) if(k/N != ((k*Y+d)>>n))break;
if(k==(1<<16))printf(" OK\n"); else printf(" ERR\n");
}}

647:646
08/01/24 15:42:18
64bit機か、内部で64bitまで計算結果を保持しているなら
32bitの割り算も出来るけど646は16bit同士です

648:デフォルトの名無しさん
08/01/24 15:52:26
GCC の中見りゃあるんじゃね？

649:デフォルトの名無しさん
08/01/24 17:46:02
>>648
gcc のカオス・スパゲッティ状態を知らぬようだな。

勧めるならせめて Small-C くらいにしとけ。
このルーチンなら工学社から出ていた
Small-C ハンドブックにもちゃんと説明されていたんだし。

650:デフォルトの名無しさん
08/02/04 20:42:37
ハッカーの楽しみ買ってきました～
これから読みますﾉｼ

651:デフォルトの名無しさん
08/02/05 23:53:51
Hacker's Delight やっと届いた

652:ヽ・´∀｀・,,）っ━━━━━━┓
08/02/06 01:12:31
俺もアレ訳本出る前ネットショップで買ったわ

653:デフォルトの名無しさん
08/02/22 06:50:56
a

654:デフォルトの名無しさん
08/02/28 07:49:51
a

655:デフォルトの名無しさん
08/03/01 13:50:55
a　<<　1

656:デフォルトの名無しさん
08/03/05 07:05:43
a

657:デフォルトの名無しさん
08/03/11 07:43:25
あげ

658:デフォルトの名無しさん
08/03/24 22:44:22
あげ

659:デフォルトの名無しさん
08/03/30 21:00:53
あげ

660:デフォルトの名無しさん
08/03/30 21:42:47
なにこのスレきもい。
でも懐かしい。

661:デフォルトの名無しさん
08/04/06 18:17:38
　　　　|
　　　　|
　　　／￣￣￣￣￣￣
　＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／

662:デフォルトの名無しさん
08/04/06 18:41:01
ダンゴさんを称えるスレというわけではありませんが、まあ、KY。

663:デフォルトの名無しさん
08/04/06 19:46:30
GCAの作者のページにビット演算が載ってたけど今いちわからん

664:デフォルトの名無しさん
08/04/07 17:04:46
ViViの作者のページにもビット演算が載ってたけどだいたい理解した
URLﾘﾝｸ(vivi.dyndns.org)

665:デフォルトの名無しさん
08/04/07 19:44:18
>配列による状態表現よりも処理が高速になる場合が多い
この表現は凶悪だな。何故なら、高速にならなかった場合にはかなり遅くなる可能性があるからだ。

666:デフォルトの名無しさん
08/04/17 06:42:52
age

667:デフォルトの名無しさん
08/05/01 06:01:45
age

668:デフォルトの名無しさん
08/05/01 08:02:29
燃料がないな

669:デフォルトの名無しさん
08/05/01 08:50:52
16bitカラーで　5：5：5 とか 5：6：5 とか　の時代なら色々やったけどな

670:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/01 18:55:25
AltiVecにも16bitカラー用の演算があったな

671:デフォルトの名無しさん
08/05/09 19:08:22
こちらのスレから誘導されて参りました。よろしくお願いします。

スレ立てるまでもない質問はここで第91刷
ｽﾚﾘﾝｸ(tech板:171番)

以下の条件で、32bit値のハミングウェイトが素数か否かを判定する
出来るだけ高速な方法を探しています

・入力はランダム
・（最悪ではなく）平均速度が速いことが望ましい
・0、1は素数ではない（偽になって欲しい）
・ハミングウェイトそのものの値は必要ない
・64bit拡張などは必要ない。32bit決め打ちで良い
・外部メモリはあまり使いたくない

皆様のお知恵を貸していただけませんでしょうか

672:デフォルトの名無しさん
08/05/09 19:25:44
一応、今はこんな感じです
ベタな実装で恥ずかしいですが…

int hw_is_prime(unsigned long x)
{
　　x = ( (x & 0xAAAAAAAA) >> 1 ) + (x & 0x55555555) ;
　　x = ( (x & 0xCCCCCCCC) >> 2 ) + (x & 0x33333333) ;
　　x = ( (x & 0xF0F0F0F0) >> 4 ) + (x & 0x0F0F0F0F) ;
　　x = ( (x & 0xFF00FF00) >> 8 ) + (x & 0x00FF00FF) ;
　　x = ( (x & 0xFFFF0000) >> 16) + (x & 0x0000FFFF) ;

　　return (1 << x) & 0xA08A28AC;
}

673:デフォルトの名無しさん
08/05/09 21:56:14
1 << 32 の結果って決まってたっけ

674:デフォルトの名無しさん
08/05/12 10:32:41
処理系定義かな。0ビットシフトになる場合と32ビットシフトになる場合が一般的だと思う。

675:デフォルトの名無しさん
08/05/12 18:51:02
まぁ 8bit, 16bit, 32bit が int の場合と、
64bit が int の場合では結果は明らかに異なるよな

676:デフォルトの名無しさん
08/05/12 20:19:59
8bitがintになることってありえるっけ

677:デフォルトの名無しさん
08/05/12 20:51:31
規格は一応-32767～32767だからないんじゃね？

678:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/12 21:34:45
1ビットマシンとか4ビットマシンとかってCでプログラミング可能なの？

679:デフォルトの名無しさん
08/05/12 21:44:21
CHAR_BIT >= 8 だけど、
別に変数１つをレジスタ１つで扱えないといけないわけじゃないし
問題ないんじゃね？

680:デフォルトの名無しさん
08/05/12 21:47:55
ダンゴさんのカキコでスレが加熱したな

681:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/12 21:59:19
レス番飛んでるな

682:デフォルトの名無しさん
08/05/13 11:50:54
ダとかンとかゴとか入ると飛ぶんだよな。

683:デフォルトの名無しさん
08/05/13 11:56:23
実は見えてる

684:デフォルトの名無しさん
08/05/13 12:39:16
ダンゴって名前を嫌がるのは、
体型が肉団子だからだよな。

685:ヽ・´∀｀・,,）っ-○◎●
08/05/13 12:47:46
だんごはこれだろ

━━━┓がどうみたらだんごに見えるねん

あたまわるいんとちゃうか

686:ヽ・´∀｀・,,）っ鹵～＜巛巛巛
08/05/13 12:50:40
虫除けのようなものだよ

687:デフォルトの名無しさん
08/05/13 14:33:31
ダンゴさんってどんな仕事してるの?

688:デフォルトの名無しさん
08/05/13 16:51:03
名無しさんの書き込みでスレがヒートアップしたな。

689:デフォルトの名無しさん
08/05/13 18:15:31
他愛もない雑談だけどな。
と、だけ書くのもなんだから、ちょこっとマジレス。

ANSI C での int の定義は処理系依存で、CPUのレジスタ幅によるらしい。
なので、Z80 なら 8bit の筈だけど、
大体のZ80 C処理系では char=8bit, int=16bit と扱う。
なんで int は 16bit より大きいという誤解があるんだろうなぁ。
その昔は char=7bit なんで処理系もあったというので、
油断は出来ないように思うんだよ。

690:デフォルトの名無しさん
08/05/13 18:38:03
INT_MINは-32767以下、INT_MAXは+32767以上じゃないといけないと決まってる
昔の話は知らん

691:ヽ・´∀｀・,,）っ━━━━━━┓
08/05/13 19:01:17
1ビットCPUは実際にあった
URLﾘﾝｸ(www.d1.dion.ne.jp)

692:デフォルトの名無しさん
08/05/13 21:12:11
昔はやりたい放題だったかも知れないが、
今は規格に準拠した処理系であれば int >= 16 bits なのは真理。
あと、int のサイズの定義は CPU のレジスタ幅にして欲しそうな定義ではあるけど、
そう断言している訳じゃない。
実際最近でも 64-bit マシンで int = 32-bit のことがある。

693: ◆0uxK91AxII
08/05/14 01:14:15
>>689
＞その昔は char=7bit なんで処理系もあったというので、
無い。

694: ◆0uxK91AxII
08/05/14 01:21:20
ごめん、間違い。

695:デフォルトの名無しさん
08/05/14 03:04:09
uartと間違えたんだな

696:デフォルトの名無しさん
08/05/14 23:42:41
ハネウェルの昔のマシンとかは 6bit 単位のマシンとかがあったから、
それとの勘違いだろ。(7bit があったかどうかは知らん。)

まあ単位が 6bit なのは uart と同じ理由だが。

697:デフォルトの名無しさん
08/05/15 02:07:52
>>691
それはCPUと言うよりリレーの置き換えみたいなもの
Connection Machineのはまともな1bit CPUだけどbit sliceだから何bitにでも
化ける

698:デフォルトの名無しさん
08/05/28 00:29:01
あげ

699:デフォルトの名無しさん
08/05/30 00:17:23
11100111

こんなビットがあったとき、0が4と5ビット目に
存在するってどうやって調べるのが効率いいのかな？

個数はわかるけど位置はどうすりゃいいんだろう

次ページ