- 1 名前：デフォルトの名無しさん [2006/09/16(土) 09:46:26 ]
- 前スレ
ビット演算
pc8.2ch.net/test/read.cgi/tech/1123918075/
関連スレ
アセンブラ… (゜□゜) ↑アッー！↓
pc8.2ch.net/test/read.cgi/tech/1148402614/
関連情報
Hacker's Delight
ttp://www.hackersdelight.org/
ハッカーのたのしみ―本物のプログラマはいかにして問題を解くか
ttp://www.amazon.co.jp/exec/obidos/ASIN/4434046683
ビットを数える・探すアルゴリズム
ttp://www.nminoru.jp/~nminoru/programming/bitcount.html
Bitboard
ttp://en.wikipedia.org/wiki/Bitboard
- 231 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 08:18:56 ]
- >>230
memcpyより高速な手法が存在するとしたら、世の中のmemcpyはその高速
な手法を使うんじゃない？
- 232 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 08:24:56 ]
- >>230
ビット単位で転送するという話でもない限り、スレ違い。
- 233 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 08:26:58 ]
- >>231
いいえ。
- 234 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 08:31:37 ]
- 前スレのログってどこかにある？
- 235 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 08:35:42 ]
- あ、あったあった。
p2.chbox.jp/read.php?host=pc8.2ch.net&bbs=tech&key=1123918075&ls=all
ここの377に似たような質問があるね。
- 236 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 08:39:30 ]
- >>228
ビット位置を持って回ることを検討したか?
>>230
つ [ゼロコピー]
- 237 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 09:05:14 ]
- ビット位置を持って回るのは難しいと思いました。
ビットはこんな風に複数のビットが立ってる変数から取り出してます。
UInt32 bits;
...
while(bits)
{
UInt32 bit = bits&(-bits);
UInt32 bit_position = get_bit_position(bit);
...
}
で、このget_bit_position()の部分を作りたいのですが・・
- 238 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 09:12:52 ]
- ちょっと>>235を読んできます
- 239 名前：デフォルトの名無しさん mailto:sage [2007/05/22(火) 10:16:01 ]
- とりあえず>>235の430でやってみます。
みなさんありがとうございました。
- 240 名前：デフォルトの名無しさん [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/24(木) 05:19:07 ]
- 格好良いかどうかは主観だという良い例。
- 243 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 15:33:15 ]
- 汚いJavaコードコンテストの会場はこちらですか？
- 245 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 15:35:13 ]
- いいえ、ここはJavaを知らない244が居るスレです。
- 246 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 22:25:32 ]
- 面白くない 失せろ
- 247 名前：デフォルトの名無しさん [2007/05/27(日) 23:15:48 ]
- エンディアンの変換を共用体でやるのってどうやるんですか？
- 248 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：・∀・）っ-○◎● mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 00:21:29 ]
- ヤツはダンゴさんじゃない
- 251 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 00:52:56 ]
- 共用体って、本当はそういう風に使っちゃダメなんだよな。
規格違反。
まあ、そう使えないコンパイラはないと思うけど。
- 252 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 08:09:58 ]
- おいおい共用体をそういう風に使わずにほかにどんな用途があるって言うんだアホかw
- 253 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 10:29:21 ]
- 使ってはいけない理由があるからそう決められているんだろ。
その理由が皆目検討つかないが。
- 254 名前：240 mailto:sage [2007/05/28(月) 10:38:09 ]
- >>243
ありがとう。参考になった。
でも、そのままだと最後の書き込みサイズが正しくなかったよ。
- 255 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:18:41 ]
- >>255
> もっとも、C++では T 型と U 型の基本クラス V 型を定義して、V 型の参照として
> T 型にも U 型にも（もちろん V 型にも）正規にアクセスできるので、共用体は
> 不要になってしまった（のだろう、たぶん）。
不要になってないだろ。
基本クラス云々で各種のデータを扱う処理は正規にできるようになったけど、
複数の型を同一の領域に割り付けるのは union でないとできない。
まあ、そんな機会はめったとないが。
- 258 名前：デフォルトの名無しさん [2007/05/28(月) 22:22:43 ]
- 普通わざわざそんな面倒なことしないと思いますけどねw
それで何の御利益があると思って書いてるんだろうか？
不思議な発想だとしか言いようがない
っていうか、それ多態じゃなくて多重定義でしょ？w
- 259 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:29:27 ]
- ？
- 260 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:31:52 ]
- 258は>>255-256宛てね
- 261 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:35:30 ]
- 型がクラスだったりする可能性を考えると
共用体よりplacement newのほうが良いと思う。
- 262 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:36:54 ]
- バリアント型とか知らないのかな。
そして、それが内部的にどうなってるかとか、
そこでのコスト意識とかに至っては、全く考えた事ないんだろうね。
- 263 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:38:44 ]
- >>261
共用体に入れられるのはそもそも POD 型だけだが、
ポインタで保持しておくことなら可能だな。
- 264 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:54:29 ]
- >>262
> バリアント型とか知らないのかな。
Ｃ言語でそんなもん使う機会があまりないこととか知らないのかな。(w
- 265 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 22:59:44 ]
- いや、煽り抜きでそういう発想はちょっとないよね。
- 266 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 23:06:16 ]
- Cだとバリアント型はにっくきCOMの象徴のひとつだからトラウマが・・・ｗ
- 267 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 23:11:53 ]
- 皆がどのレスについてレスしてるのか分からなくなってきた。
つーかビット演算スレでなぜ共用体…。
「そういう発想」というのは共用体をvariantとして使う発想ということかしら。
- 268 名前：webmaster@気まぐれアナスイ mailto:192.168.0.1 [2007/05/28(月) 23:11:54 ]
- { >>>>>>>>985 }
ζ
!(+Φ＿Φ)つ√ζ
+⊂. + 〆∂ {Ж}
"〆∂∂
〆〆
.:"
- 269 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 23:15:15 ]
- コピペ君って馬鹿だな、まで読んだ。
- 270 名前：デフォルトの名無しさん [2007/05/28(月) 23:38:38 ]
- >>256
でも共用体って記述した順番にメモリに保存されるかについて
仕様では未定義ですよね
- 271 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 23:40:46 ]
- >>270
当たり前だろ。
つか struct の仕様と混同してないか?
- 272 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 23:43:42 ]
- >>270
これはひどい
- 273 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 23:45:43 ]
- コンパイラコンパイラ触ってるなら、
このくらい常識だろ？
- 274 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 23:49:33 ]
- それは二重に規格違反してて、
おかしくなるコンパイラもあるらしいよ。
俺はそういうの見た事無いけど。
- 276 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 00:13:33 ]
- おかしくなるコンパイラがあるのではなく、動作が保証されないということ。
そういうコンパイラが現実にあるのかと言われても、んなこと知らん。
だが、顧客に「正常に動作することが保証されている」プログラムを提供するためには
仕様上未定義とされる書き方をしてはいけないし、意識せずしてしまったらバグとして扱われて然り。
- 277 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 00:20:53 ]
- 参考までに>>274の規格違反している点を簡単に指摘してください
- 278 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 00:32:45 ]
- 規格違反していても、多分 >>249 がおかしくなる処理系はないんじゃね？
逆に、規格通り書いてもおかしくなることもある。
規格違反はそれはそれで重要だけど、
実際の処理系でどうなのかという方が時に重要な事もある。
ま、コメントとか残しておいて、
移植時にすぐ検索できるようにしておくべきではあるが。
- 279 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 00:44:32 ]
- >>277
共用体の pW メンバに代入した場合、
pW の値しか正当性が保証されない。
そのため、pW に代入したすぐ後に pB を参照したとき、
規格ではその動作を保証しない。
uint32_t * と uint8_t * のアドレス表現が等しいという保証は無い。
この間のキャストで何らかの変換作業が生じる場合には、
このコードは正しく動かない。
そもそもアドレス演算は、配列要素へのポインタでしか保証されない
（配列風の参照では p[4] と *(p + 4) は等価で、
ここには p + 4 というアドレス演算が生じる）。
ここが原因で >>274 のようなことをすると
おかしくなる処理系があるという風に聞いている。
（「ハッカーのたしなみ」 の 87 ページを参照）
- 280 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 01:08:03 ]
- ハッカーのたしなみ に一致する日本語のページ 約 104 件
ハッカーのたのしみ に一致する日本語のページ 約 26,800 件
- 281 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 01:15:26 ]
- すまんよ。まちがえた。
- 282 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 10:36:39 ]
- そもそもCの言語仕様で「未定義」な理由は、最初のバイトが最上位か最下位かはエンディアン依存だから。
逆にいうとハードに強く依存する標準仕様はあってはならない。
もちろん環境が特定できる場合なら、エンディアンの違いを理解して使うぶんにはまったく問題ない。
むしろ同一アーキテクチャでならコンパイラのABIレベルではこういう部分も互換性が保障されてないと駄目。
そもそもエンディアンなんて標準仕様外のものを扱うのに、標準仕様を持ち出すほうがおかしいと思うがね
構造体などのデータアラインメントやABIの互換性は言語の規格じゃなくて
各CPUやOSのメーカー、コンパイラメーカーなど同士の取り決めで決まる。
つーか、暗黙の共通仕様や独自仕様にたよらないとTCP/IPすら扱えないぜ。
- 283 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 10:52:02 ]
- 構造体のアラインメントはC仕様では未定義だが、アラインメント不整合だと例外を起こすアーキもある。
データレイアウトを実装者で取り決める独自仕様が認められないなら、Cは危険な言語だな逆にいえば。
「仕様では未定義」は逆にいえば実装では各環境のABIに従ってきめていいということ。
- 284 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 11:17:39 ]
- >>282-283
仕様上未定義を「未定義の動作」と混同していないか。
Cは移植性を高めるため、特定の環境に依存するような仕様はほとんど盛り込まれておらず
よって指摘の通り構造体のメモリ上でのレイアウトも定義されていない。
だが、メンバに正しくアクセスできることは保証されている。
- 285 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 11:25:40 ]
- 実は未定義ではなく実装依存という罠
- 286 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 11:38:48 ]
- エンディアンの変換はほぼ間違いなくできるがリトルからビッグかビッグからリトルかはエンディアン依存ってことだろ。
逆に>>349が意図しない動きをするコード吐くコンパイラって存在するなら教えてほしい。
変態のCellですら>>349が正しく動くことはABIレベルで保証されてる。
各型のレイアウトを厳密に定義してるからな。
- 287 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 11:43:14 ]
- 共用体で ビットフィールド を使えば、マシになるかい？
- 288 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 12:21:19 ]
- >>286
>>276
そして話題はループする。
ABIはCの言語仕様における実装依存の箇所を定めて厳密化するものなので
たとえABIの隙をかいくぐって自分の予期した挙動をさせることができたとしても
それは立派な規格違反。
あと、もし>>282さんと同一人物なら
＞そもそもCの言語仕様で「未定義」な理由は、最初のバイトが最上位か最下位かはエンディアン依存だから。
これのソースを頼む。探しているんだが、見つからない（汗
- 289 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 12:27:18 ]
- 規格にないものを扱うのに規格内のルールを持ち出す馬鹿。
windows.hを使うのも規格違反だとか言い出しそうだな
- 290 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 12:34:19 ]
- 厳密にはそうだな。ハンドルをポインタ型とかメチャクチャしたMSは糞。
ちなみに、規格にないものを付け加えるのではなく、規格に抜けているを補うのがABI。
本来は規格に矛盾しないABIを定めなければならない。
ところでここはビット演算についてかたるスレなのか？
- 291 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 12:56:10 ]
- ミドルエンディアンのこともたまには思い出してやってください
- 292 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 13:13:17 ]
- GUIがなくてstdioで画面入出力するようなアプリのほうが品質低いと見なすがなうちの顧客は。
「定義するな」なら違反になるが単に未定義のものに一定の動作保証をするだけなら違反じゃない。
何のために#pragmaが規格にあると思ってる。
処理系依存の拡張を、やっていいよと保証すらしてるのが規格だ。
ちなみにunion使った型変換はWindowsでは日常茶飯事だな。ULONG_INTEGERとか。
ここの住人がよく使うであろうMMXやSSEなんかはC用APIなんか、まさに共用体を使った型変換のオンパレード。
それでもパフォーマンスを求める客の「信頼」を得るためにすすんで使うものだ。
ANSI/ISO規格が絶対的に信頼されてて規格外のものは信頼されてないなんて独善的な言い分にすぎん。
getsみたいな危険な関数が野放しにされてるのはなんだね。
極論、信頼性の確保という面ではVC2005のセキュアCRT関数のほうが標準関数よりまとも。
ちなみにポインタをHANDLEという型にtypedefできるのは規定の動作。なんら問題ない。
- 293 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 13:37:27 ]
- きもちわるいなあ
- 294 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 14:40:40 ]
- エチケット袋持ってきましょうか？
- 295 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 15:10:33 ]
- いえ結構。そのまま吐きます
- 296 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 15:14:49 ]
- キッシュを食うのとエチケット袋を使うのはガキ。
- 297 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 17:55:34 ]
- 「規格違反のプログラム」 は、
特定の環境では動くことが保証されてるかもしれないけど、
全ての環境で動く保証が無い。
だから、そのプログラムが特定の環境でのみ使用される事が決まってるなら、
規格違反でもその環境でちゃんと動作する事が保証されていれば問題ない。
ただ、色んな環境で使われるプログラムであれば、規格通りに作らないといけない。
つまりは要件次第の問題であって、常にどちらかでないといけないみたいな事を言うのは愚。
>>292
gets の使用は規格で推奨されていない。
未だ存在しているのは単に互換性のため。
セキュアCRT関数は安全だが、
GCC でコンパイルしたいような場合には
#if 使って GCC でも大丈夫なようにする必要がある。
あと、ハンドルで問題とされているのは、
ハンドルの値は別にアドレスではないのに
ポインタに入れるようにしている点。
ただ、これは int にしてしまうと安全性が低くなるし、
環境依存という程ちゃんと動かなくなる環境もないしで、
いい hack だと思う。
- 298 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 18:53:41 ]
- 話は逸れるが、ハンドルも全てがアドレス値（ポインタ）でないとは限らない。
ドラッグ＆ドロップの処理などでGlobalAllocでメモリ確保したものを
HDROP型へキャストしてやるという事例がある。
ふうんと言われればそれまでのことだけど。
- 299 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 18:56:05 ]
- それをいうなら、そもそもポインタ（というより左辺値）だってアドレス値とは限らないでしょ？
- 300 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 19:02:00 ]
- プログラムごとに論理的なアドレス空間を持ってるんじゃないの？
昔、物理的なアドレスを使えば一意だろうと思って使ったら、見事に失敗した。
- 301 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 19:09:48 ]
- ＞ハンドルの値は別にアドレスではないのに
＃ハンドルの値は別にアドレスとは限らないのに
とするか。
- 302 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 19:13:49 ]
- まあ、メンバ関数ポインタなんかは
確かにメモリアドレス以上の情報を持ってることもあるけど、
C++ における「アドレス」ってのは、
そういう情報も含むんじゃないのかな。多分。
- 303 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 20:07:37 ]
- きょうび、１つのCPUでも「アドレス」が3種類くらいあって当たり前だしなぁ
- 304 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 20:27:53 ]
- Cはアドレスの概念を抽象化したから、Cにはアドレスという概念はないと。
どっかで見た。
- 305 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 20:36:02 ]
- ところがどっこい&演算子の読み方は・・・
- 306 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 21:00:16 ]
- アドレス演算子だな。
- 307 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 21:24:50 ]
- えっ？reference operatorじゃないの？
とか思ったけどそれはC++の話でしたねすいません
- 308 名前：デフォルトの名無しさん mailto:sage [2007/05/29(火) 21:53:21 ]
- ANSI C: address operator
別名: reference operator
- 309 名前：・∀・）っ-○◎● mailto:sage [2007/05/30(水) 01:32:06 ]
- よーしだんごやさんが燃料投下するぞー
「共用体を使った型変換は、保証されないとむしろ違反」
uint32とuint8[4]の完全なアドレス共用が保証できなければ
・各パートの先頭アドレスの一致
・char型(=1バイト)配列のデータ連続性
という規格で保証された動作に違反することになる。
断言する。
バイトオーダさえ一致すれば、共用体を使ったビット列の直接変換は保証できる。
つーか、規格にない動きまで保証されると規格【違反】なら、
Cコンパイラは現実のアーキテクチャ向けに実装された時点で違反を抱えることになり
空想の産物でなければならないことになるね。
規格外と規格違反を混同してるんじゃないの。
規格にない機能を実装したり独自の制約・動作保証をしたらいけないなんて規約は
規格に存在しない。
- 310 名前：・∀・）っ-○◎● mailto:sage [2007/05/30(水) 01:35:52 ]
- RubyはCで書かれてるけどオブジェクトは共用体を巧みに使うことでで実装されてるね。
それでもさまざまなプラットフォームに移植されてるけどｗｗｗｗ
- 311 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 01:47:03 ]
- 最適化でどうなるかとかちゃんと考えてるか？
- 312 名前：・∀・）っ-○◎● mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：・∀・）っ-○◎● mailto:sage [2007/05/30(水) 02:11:59 ]
- x86のeaxレジスタは下位半分はaxレジスタであり、ahとalでもある
レジスタそのものが共用体なんですよ。
- 315 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：・∀・）っ-○◎● mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 02:33:39 ]
- >>309
混同も何も、そもそも「規格外」とか「規格違反」とかいう用語は規格にあるのか？
- 318 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 02:35:52 ]
- %0X って意味ねー。
%08X っしょ。
- 319 名前：・∀・）っ-○◎● mailto:sage [2007/05/30(水) 03:08:16 ]
- 64bitから8ビットだけを取り出して操作するってAESとかCamelliaではありがちな処理なんだよな。
よく最適化されたコードは、MMレジスタからpextrwで16ビットをeaxに転送した後、al, ahを使ってテーブル参照する。
- 320 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 08:24:42 ]
- 気色の悪いHN付ける奴の行動パターンやそこから透けて見えるパーソナリティっていうのは、
どいつもこいつもどうしてこう画一的・類型的で凡庸なんだろうなw
恐らく本人の自己イメージはその正反対なんだろうけどさ。
- 321 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 08:41:04 ]
- 凡庸乙
- 322 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 08:48:32 ]
- >>320
あなたのその発言もまた 画一的・類型的で凡庸 な事に気付いてての発言だとすれば あなたは勇気がある。
気付いてないなら・・・・・
- 323 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 08:56:16 ]
- 人間なんてみんな一緒だろ。
ハッキリいってイルカよりもマグロの方が頭いいです。
人類の知能は一億年遅れてる。
- 324 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 14:10:27 ]
- 【高速化】ビット演算 0x02
- 325 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 20:38:32 ]
- 俺のアナルも高速化されそうです
- 326 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 01:08:47 ]
- 俺様の射精は低速化されましたが何か?
- 327 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 01:34:42 ]
- さらに角度までorz....
- 328 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 04:34:03 ]
- 自分の精液を味わって飲んでみましたクセになりそうです
- 329 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 09:31:52 ]
- 【下ネタ化】ビッチ猥談
- 330 名前：デフォルトの名無しさん [2007/06/01(金) 01:04:55 ]
- >>328
なんか体調によって味とか変わってくるらしいね。調子がいいときはどんな味がするん？
- 331 名前：デフォルトの名無しさん mailto:sage [2007/06/01(金) 01:06:15 ]
- ごめん、sage 忘れた。
|
 |
