696 :
デフォルトの名無しさん:
これがベクトル化されれば夢のような話だ!
for(j=0;j<16;j++){
for(i=0;i<16;i++){
d1[i]^=GF[((FG[a[j]]-1)+(FG[h1[i][FG[b[j]]]]-1)%255)+1];
d2[i]^=GF[mlt(FG[a[j]],FG[h2[i][FG[b[j]]]])];
}
}
697 :
デフォルトの名無しさん:2010/09/19(日) 19:30:36
int a[]={130, 160, 130, 193, 130, 211, 130, 241, 130, 160, 130, 169, 130, 241, 130, 196};
int b[]={131, 94, 131, 129, 131, 84, 131, 140, 131, 139, 131, 95, 131, 67, 131, 96};
int c[]={123,111,222,231,132,125,124,133,122,147,158,210,1,2,3,4};
int main(void){
int i;
for(i=0;i<16;i++)
a[i]^=(b[i]+c[i])%16;
}
$ gcc -O3 -ftree-vectorize -ftree-vectorizer-varbose=5 -mmmx -msse2 -S v.c[1P[1@e
v.c:8: note: dependence distance = 0.
v.c:8: note: accesses have the same alignment.
v.c:8: note: dependence distance modulo vf == 0 between a[i_21] and a[i_21]
v.c:8: note: vect_model_load_cost: aligned.
v.c:8: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 .
v.c:8: note: vect_model_load_cost: aligned.
v.c:8: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 .
v.c:8: note: vect_model_load_cost: aligned.
v.c:8: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 .
v.c:8: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 0 .
v.c:8: note: not vectorized: relevant stmt not supported: D.1523_11 = D.1522_10 % 16
v.c:5: note: vectorized 0 loops in function.
ベクトル化できない。なぜ?
698 :
デフォルトの名無しさん:2010/09/19(日) 20:49:25
こう書いたらアセンブラソースリストが2倍近く小さくなった。
for(i=0;i<16;i++)
a[i]^=(b[i]+c[i])&0xff;
a[i]^=(b[i]+c[i])%16;
a[i]^=(b[i]+c[i])&0xff;
って同じことをするんですか
700 :
デフォルトの名無しさん:2010/09/19(日) 21:13:06
違うみたい
701 :
デフォルトの名無しさん:2010/09/19(日) 21:53:31
a[i]^=(b[i]+c[i])&0xf;
の間違い。
>>696 そもそも、アドレスの遷移が複雑すぎて
ベクトル処理向きじゃないんじゃねえか?
テーブルがキャッシュに載りきるぐらいなら
別の方法で速くはなりそうだが。
>>698 0xFF は 255 だぞ。
703 :
デフォルトの名無しさん:2010/09/19(日) 22:01:23
255以下の数に変換したいだけです。
256は要らない。
行列の大きさは4kbyte位なのでキャッシュに入りそうです。
別の高速化でもいいので教えてください。
配列のメモリアクセスがボトルネックになっている可能性があります。
704 :
デフォルトの名無しさん:2010/09/19(日) 22:04:34
部分的にベクトル変換に成功しているのですが実行速度が-O3のみの
時より10倍くらい遅くなってしまいます。
なぜでしょう?
配列の中身は、256以上の時はあるのかい?
706 :
デフォルトの名無しさん:2010/09/19(日) 23:43:22
h[32][256]
GF[256]
FG[256]
配列はこれだけです。
配列をintで宣言してるけど、unsigned charで宣言は出来ないのかなと思って
708 :
デフォルトの名無しさん:2010/09/19(日) 23:50:45
unsigned charにすると自動ベクトル生成に失敗します。
-O3 -ftree-vectorize -ftree-vectorizer-verbose=5 -mmmx -msse2
sse使わないと早くならないのかいな?
710 :
デフォルトの名無しさん:2010/09/20(月) 00:03:46
行列演算なのでループをなくしたいです。
128ビット演算なのでSSE2で最適化できるかと思ったのです。
データの中身は8ビットみたいだけど(intでも32ビット)
見間違いかな
712 :
デフォルトの名無しさん:2010/09/20(月) 01:45:36
データは8ビットで統一されてます。出力は8×32ビット
2個コードがあるから、どっちのことかわかんねえじゃねえか。
714 :
デフォルトの名無しさん:2010/09/20(月) 02:11:44
for(i=0;i<16;i++)
a[i]^=(d1[i]+c[i])&0xff;
こっちはintにすれば自動的にベクトル処理してくれます。ただ32ビット
なので16個いっぺんに計算してくれているかどうかはわかりません。
本体部分が
for(j=0;j<16;j++){
for(i=0;i<16;i++){
d1[i]^=GF[((FG[a[j]]-1)+(FG[h1[i][FG[b[j]]]]-1)&0xff)+1];
d2[i]^=GF[mlt(FG[a[j]],FG[h2[i][FG[b[j]]]])];
}
}
です。SIMD以外でもキャッシュを工夫して高速化できればいいかと思います。
何かいい方法があったら教えてください。
スレタイに従うなら、アセンブラで書いた方がいいんじゃないの
716 :
デフォルトの名無しさん:2010/09/20(月) 09:13:39
次のようにして本体部分の自動ベクトル化も成功しました。
2秒ほど高速になりました。
for(k=0;k<500000;k++){
for(j=0;j<16;j++){
o=FG[a[j]];
p=FG[b[j]];
for(i=0;i<16;i++){
e1[j][i]=((o-1)+(h1[p][i]-1))&0xff+1;
e2[j][i]=((o-1)+(h2[p][i]-1))&0xff+1;
// d1[i]^=FG[mlt(o,h1[p][i])];
// d2[i]^=FG[mlt(o,h2[p][i])];
}
}
for(j=0;j<16;j++){
for(i=0;i<16;i++){
d1[j]^=GF[e1[j][i]];
d2[j]^=GF[e2[j][i]];
}
}
for(i=0;i<16;i++)
a[i]^=(d1[i]+c[i])&0xff;
for(i=0;i<16;i++)
b[i]^=(d2[i]+c[i])&0xff;
}
717 :
デフォルトの名無しさん:2010/09/20(月) 12:11:15
嘘です。18秒かかります。
GPGのAESは7秒 orz
718 :
デフォルトの名無しさん:2010/09/22(水) 09:23:22
#include <stdio.h>
#include <stdlib.h>
int main(void){
unsigned long long int a,b;
a=strtoull("0x1111111111111111",(char **)NULL,16);
b=strtoull("0x2222222222222222",(char **)NULL,16);
a=a^b;
printf("%llu\n",a);
return 0;
}
このプログラムをMMXを使って最適化したいのですがわかりません。
アセンブラで書くしかないのでしょうか。
ここの掲示板って知ったかぶりでメーカーの商品の批判ばっかりしてる奴ばっかりだね。
どうせ文句言いながらも使ってるくせに。メーカーさんの苦労もかんがえろ。そんなに
そんなに嫌ならOSもパーツも自分で作れ。どうせお前らには出来ないが。今大学院で
OSの研究をしているが、純粋にみんな凄いって感心している。オタクの集まりっていうのは
ほんまウザいねん。お前らに電子工学の知識があるのか?情報科学を学んだことがあるのか?
お前らまともに勉強してから文句言え。
XCode 3.2.3 で Release | i386 構成でアセンブルすると
どうも 64-bit でアセンブルされてるように見えるんだけど
Debug | i386 構成だとちゃんと 32-bit でアセンブルされてるようだ
Release 構成でも 32-bit でアセンブルされる方法はないのかな?
OS: Mac OS X 10.6.6
CPU: Intel Core 2 Duo
XCode: 3.2.3 (64-bit)
723 :
デフォルトの名無しさん:2011/02/11(金) 20:17:58
age忘れた
724 :
デフォルトの名無しさん:2011/02/16(水) 11:21:48
え?
725 :
デフォルトの名無しさん:2011/03/10(木) 07:16:19.45
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
http://sky.geocities.jp/ttl_ttl_ttl_pic/ NASMでC言語を作る NASMで高度な設計書類とNASMの簡単な利用方法のサイトです
C言語のHEADの作り方 DLLファイルの作り方が書いてあります
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
726 :
デフォルトの名無しさん:2011/03/10(木) 07:25:36.87
Rubyで書こう
×C言語を作る
○Cの下請け処理を汗で書く?
アホは逝け
は〜い、逝きますwww。
x86とAMD64(?)64bitのやつの逆アセンブルとアセンブルをプログラムから利用出来るようなライブラリってありませんかね?
アセンブラインタプリタみたいなので利用したい
732 :
福盛俊明:2011/03/27(日) 03:00:55.53
アハ〜♪”
>>731 ?
クロスアセンブラって知ってる?
インタプリタは無理だけど(てか、インタプリタ自体に32bit/64bitが有っても、ソースにbitは関係無いし)、バイナリ作るだけなら、理論上、16bitOS上でも64bitのバイナリ作れるよ
ちょっと調べればアセンブラは32bitでも64bitのバイナリ作れるのは有るんじゃ無い?
ちなみに、x86のgasにちょっと細工するだけで、GBA(ARM)向けのバイナリが作れます
クロスアセンブラは簡単にアーキテクチャの壁を超えられる良い例ですね
(アセンブラの場合、アーキテクチャの壁とハード仕様の壁、両方超える必要が有りますが)
ぐぬぬ
>>734 そうそうだから文字列をバイナリに変換するライブラリが欲しい
作れるだけでいいんです
例えばプログラムでアセンブラを変換してバイナリを生成して
メモリに投入して関数ポインタで呼び出して実行するみたいなことがしたい
もちろん逆もしたいので逆アセンブル機能も欲しい
要するにメモリ上で現在動いてるプログラムの関数をリアルタイムでデバッグしたい
そういうレベルのデバッガを作ろうとしてて、アセンブラライブラリが欲しいんです
自分で作るしかないでしょ
俺はVSの逆アセで済ましてるな。作るの面倒。
理論上は、数値入りの命令は工夫が居るけど、全種類のデータあれば単純に検索だけで実装できるよね。
オペランドに計算式書けるようにするとかしなけりゃ
大した手間かからんべ
命令コード汚いと泣きたくなることもあるが
それもある
自分で実装すると変数やラベルまでやるのは大変だから
ライブラリであると助かるんだよな
汗にライブラリってのがわからん
アセンブリ言語で書かれたライブラリ、にしろ
アセンブリ言語から利用するライブラリ、にしろ
普通にあるものだと思うが
今時、そんな発想するんか?
JITコンパイルか動的バイナリ変換でもしたいのかと思った
Windowsの通常あり得ない方法でプログラムを動かしたりするのに
バイナリをあらかじめ用意するとか出来ないし
オフセットが変わるとごろっと変わってくるからね
というかリアルタイムでメモリをいじって挙動を調べたりすることをやってるもんで
まさにアセンブラのインタプリタが欲しいのですよ
ハッカーになりたいんだったら、こっそりやったほうがいいよ
そういうことをやりたいなら、一行アセンブラくらいサクッと
作れないとダメだろう
アセンブラは力技だから誰がやってもサクッとはいかないよ
何千行のソースは約束されてるし
アセンブラで一度実用的なプログラムを書いた経験があれば、Cの有り難さが身に染みて分かる
C言語で多くの実用的なプログラムを書いた経験が有れば、アセンブラのここぞというありがたさが身に染みてわかる
>>752 あほか
思いっきり機種依存の話をしてどうする
>>751には同意出来るが、
>>752には同意しかねるな
実用的なアプリ = 速度が要求されるアプリとは限らないし、移植性や保守性を考えたら、アセンブラは使わないに越した事はない
Cじゃ速度的に間に合わなくてCPUごとにアセンブラ使ってる俺涙目
ちなみに今度8種類目
C で書いてても、大事なところは objdump 等で
アセンブラを確認してる。
cは 「抽象化されたアセンブラ」 である、ってのは至言だよな
節電が一番大事な世の中になってきた
C、アセンブリ語、マシン語を紙に書く時代に戻るの?
休肝日をまねて休電日を作るとか。
コーディングなんて仕事全体の2割以下だろ。
そして唯一の楽しいフェーズなんだ。
昔のファミコンプログラマーはなんでもかんでもアセンブラーで書いて、すごいと思います。
当時の開発環境で C 使うのも、それなりに苦行な気も。
intが2バイトだったりとかいろいろ気をつかうからねぇ
アマチュア時代、MSXでC言語でゲーム作ったりしていました。
hello,worldをコンパイルするだけで4分ぐらいかかってました。その間フロッピードライブが
ものすごい勢いで動き続けるのでいつか壊れるだろうと思ってました。
ゲームが完成する頃には総コンパイル時間が1時間ぐらいだったと思います。
完成したゲームをMSX-FANに投稿しましたが、採用されませんでした。
私の苦労は・・・。
ちなみに当時のソースをひっぱりだしててきて、Phenom II 3GHzという環境上で、CP/Mエミュ
レータ+コンパイラでコンパイルしたら物の数秒でコンパイル完了しました。
数秒も掛かったのか。
CPUがざっと1000から1万倍、ディスクがざっと1000倍速くなっていることを考えると遅過ぎる。
>>766 あの時代だとBDS-Cあたりか
俺は耐えられなかったのでTurbo Pascalで遊んでた
>>767 Z80エミュレーターで走ってるんだから十分速いだろう
マルチコア使うアセンブラ、どう書いたらいいのか全然わからん。。。
誰かマルチコア cortex-a9 の使い方、
どこでどう勉強したらいいか教えてください。
マルチコアで書き方が変わることはありません。
atomicな処理が出来れば、ハマることはないと思うけど
シングルとして書いた処理をマルチスレッドにすりゃいいだけでは?
例えば0から100の処理をループする時に
偶数用スレッドと奇数用スレッドを用意してインデックスを渡して
後の処理内容はまったく同じ
>>769 メモリバリア・キャッシュ、
グローバルなリソースの排他、
プライオリティ インバージョン
の3つが解っていればあとは応用編。
単にスレッド3本走らせるだけなら
>>770-771 のとおり何も変わらん。
待ち合わは wfe とかか。
x86でリング3で実行出来るキャッシュフラッシュ命令はありませんか?
INVDやWBINVDは特権命令なので実行しようとすると例外が出て止まります
リング3を解除すること考えたら
その状態でキャッシュフラッシュせにゃいかん状況が想像できない
ハード絡みならそっちからフラッシュ要求だしてもらうべきだろう
>>774 そうですねデバイスドライバモドキを作ってそこで実行するかな
>>775 2つのアルゴリズムを比較したい時に前のデータがキャッシュに残っていたら
アレなので両方ともキャッシュをフラッシュしてから実行開始する簡単な方法が
あればと思いました
全く関係ない巨大配列を読み書きすれば、テストデータがキャッシュから追い出されるんじゃない?
その後キャッシュされるのに
>>779 それでいいんだよ
それぞれのアルゴリズムのテスト前にキャッシュから追い出せばいいわけ
今時のOSで、キャッシュフラッシュして何やりたいんだか
実行時間計測?
>>781 キャッシュフラッシュの用途で、それ以外何があると
なんだかなあ〜
何だよ
ハッキリ言えよ
今時のOSでキャッシュフラッシュとか逝ってるところが
何なのよ?
787 :
デフォルトの名無しさん:2011/10/01(土) 21:24:40.70
Linux のアセンブラ割り込みじゃなくsysenter使ってx86 32bitタイプCPUで出来るんでしょうか?
色々ネットをgoogleで調べたのですが、良くわかりません。
Darwinと64bitタイプ向けのサンプルは発見できたのですが。
788 :
デフォルトの名無しさん:2011/10/01(土) 21:32:41.39
>>787つづき
コンパイルして動作させようとしたのは、"hello world"を表示するものでした。
ソフト割り込み(かな int 0x80でシステムコールしてました)は上手く動作しました。
>>785 コンテキストスイッチの時にキャッシュ汚染されるから同じようなもんだろうが
>>787 cpuidのsep立ってればできる
今時のCPUなら全部対応していると思うが
791 :
uy:2011/10/03(月) 14:00:28.26
もうどんなときでもアセンブラでかくのは極力やめたほうがいいんだろうな
たとえそいつがかけても、そいつがいなくなったら誰もメンテできないという自体になる
アセンブラでやるっていうのは最終手段になりつつある
>>1のいうように下手にかけば遅いし、
速いアセンブラコードかくには、アセンブラである程度何か書いた事がないと
コンパイラの最適化の下をいく
アセンブラで速いコードをかけるとか、
そんな技術者はもうほとんどいないし、これから若手がそういう人材になる見込みも
792 :
uy:2011/10/03(月) 14:03:04.75
きわめて薄い ただB言語やPascal言語と違って、上位互換が出てきたわけじゃなく
所詮、いまだアセンブラは奥の奥で使われているから、誰も使えない、誰もかけないなんて状況には
ならないんだけどな、 本当の意味で正しくアセンブラ言語を発音できるやつは、いずれ絶滅危惧種になる
才能のないやつがプログラマとして生きるなら「ここ」だよ
「ここ」だけは才能がいらず、知識量だけでやっていける
アセンブラはそういうもの
ゴミみたいなやつでもできる あ、だけどバカにしているわけじゃないよ
がんばれ
そのゴミみたいな奴の一人です(w
実際、古代の石でASM開発された奴の保守は私ぐらいしか出す先がありません。
狭い狭いニッチですが、フジツボみたいにしがみついてます。 趣味+実益(w
箱モノならアセンブラなんぞいっぱいあるだろ
Photoshopのフィルタってアセンブラで書かれてるって聞いたんですが本当ですか?
インラインアセンブラが使えないコンパイラしか持ってないとか
そういう理由でもない限り、C/C++で書かない理由が見当たらない。
インラインアセンブラで書く、という意味を含めて、アセンブリ言語で書く可能性としては、
画像のピクセル毎の処理とかで、かつSSE命令を使うとか、飽和加算が必要とか、
いくつか可能性は考えられるけどね。けどまぁほんとにごく一部のコードに限られるはず。
ハッカーもやっぱりアセンブラでプログラム書いてるんじゃないかい?
マシン語でプログラム書くの大変でしょ
修正するたびにjmpのアドレス値を全部書き換えなきゃいけないとか
汗でんでんはどうでもよくてマイクロアーキテクチャをどれだけ理解してるってところじゃないかな?
シムとかプロフなしに速いループを書くのはやっぱり難しいよ。
16bitあたりならコンパイラよりも人の方がいいコードをかける
それ以上はそんなことする気にもなれん
>>801 禁止しない限り人が書いたコードを最適化する RISC チップ用アセンブラもあることだしねぇ
ここでいってるビット数はOPコード長でいいんだよね?
>>803 バイトマシンであるところのx86は8bitかよと
内部バスのパラレル幅 でいいんだよね?
どうでもいい
ALUのbit長にきまっとろうが
今時、何Bit CPUと言う定義は意味がない。
>>804 可変長OPコードだぞ。
>>804 そうそう、x86は8ビットマシンに見えてしまって。
>>807 IBMの S/360,370は、ALUは32bitだったがアーキテクチャーは16bitだった。
たしかに、今では
>>808 が正解のようだ。
リセット直後にコード解釈のためフェッチするサイズだな
H8なんか同じ石でどっちでも動くようになってる。
ワロタ それイイな。 人がコンパイラを越えられなくなったら32bitね
22 名前:デフォルトの名無しさん[sage] 投稿日:04/10/11(月) 20:19:26
>>21 ARMは、そろそろ使用に耐えなくなる頃合だよん
DATとCLKでシリアル出力する関数を、速くするためにforを使わずのべたんで書いた。
ROTL R6 ; MSBから出力 石とASMはH8S
BST #1,@P4DR
BSET #0,@P4DR
BCLR #0,@P4DR
これをbit数分、並べた。forのカウントもしないし、cだとportを読んでmaskで変更して
書き戻すコードしか出ないから、cでは書けない関数の好例。
if (hoge & (1 << bit))
*P4DR | = 1;
else
*P4DR & = ~1;
て書いたら
bld #bit,RnL
bst #0,@P4DR
て最適化してくれるようになればいいんでないかと思う
今のところH8系のcではできないの。P4DR.1 = R6=rotlw(1,R6); とは書けるけど、
ROTL R6 BST #1,@P4DR ではなくR6→R5 R5からBLDでCYに取り出してBSTする。
c中にASMコードも書けないのでASMの関数コールを用意するしかなかった。
AduCという所のcはCYまで使えるので817の書き方ができるお利口さんだが、
すごくローカルな方言。
820 :
817:2012/02/14(火) 04:38:59.09
当時のソフトボート社提供の<INH8.h>の中身は
#pragma function = intrinsic(0)
int rotlw (int count, int data);
・・・
void bset (unsigned char bit_no, unsigned long address);
void bclr (unsigned char bit_no, unsigned long address);
#pragma function = default
これを真似してbset/bclrの辺りに
void bst (unsigned char bit_no, unsigned long address);
を書いてみたけど、BST命令は出ずに関数コールになった。
bset/bclrを書いたらコンパイラが狂い死にした(w
ルネサスのcなら書けるんだけど。
動作周波数が遅いのか
速度を必要としてるのか
データシートに書いてある最高速度で動かしたいのか
速さが必要ないのに汗で書くことも無いような
ほんとに速さが必要になった時に汗でも書けるぐらいでいいんじゃねえの
Cであがいて最後は全部汗とか、はまりパターンにならんように
最初にどっちで書くのがいいか見極めが必要なのかも
822 :
817:2012/02/15(水) 04:09:34.73
前の世代の製品のときに、パルスがトロいって文句いわれたんですよ。
同じ部署の次世代製品だったから、企画の時からこれ以上出せない文句無しの
出してやろうと決めていました。動き出してから、書き込み速いねって誉められました。
動作周波数は、分周してuartの適切なレートが出る奴を選ぶので、CPUの最高より
若干低め:16.588とかの半端なクロックが使われます。
別の部署の製品では、seup/holdが4μのPLLでCPUが20MHzだったため、1パルス
毎にディレイかまさなくちゃいけなくて、なんかくやしかったり(w
ハード屋さんに聞いたら、(回路をケチるためらしいんだけど)横浜コンチみたいな
波形なので、トロくさせることで確実にしてるみたい。
823 :
817:2012/02/18(土) 05:03:46.97
>seup/holdが4μ 40μの間違いでした。
824 :
デフォルトの名無しさん:2012/04/30(月) 05:22:50.09
領海
今のCPUって単一スレッドでも多重パイプラインで複数命令実行してたりして
訳分からないnopとかいっぱい入ってるし、命令ブロックの配置とか
元のロジックの順番変わったりするしそんなの手作業でハンドアッセンブルなんて
不可能じゃないの?初期のペンティアムのUパイプだのVパイプだのの時点でもう
訳わからん
「今のCPU」って一口に言っても、Ivy Bridgeも、PICもあるから一概に言えん。
この文脈でそう言っちゃうのは馬鹿だろう。
「単一スレッドでも多重パイプラインで複数命令実行してたりして訳分からないnopとか
いっぱい入ったりする、命令ブロックの配置とか元のロジックの順番変わったりする
今のCPUって、手作業でハンドアッセンブルなんて不可能じゃないの?初期のペンティ
アムのUパイプだのVパイプだのの時点でもう訳わからん」
せめてこう書くべき