いてつくブログ

2ちゃんねるのスレッドをコピペしてまとめてみるブログ

レジスタ

PC等【C++】高速化手法【SSE】

1 :デフォルトの名無しさん:2005/10/27(木) 02:55:36
C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。

178 :デフォルトの名無しさん:2009/01/07(水) 23:00:55
メモリ(バキューン!)とかを考慮すると構造体より配列のほうが高速?

179 :デフォルトの名無しさん:2009/01/08(木) 00:02:43
>>178
同じ。

185 :デフォルトの名無しさん:2009/01/09(金) 14:29:17
>>179
うほ?
>>178の意味がいまいち分からんが、
char array[0x100];

struct{char value;} array[0x100];
だったらレジスタサイズにパディングされる分、構造体の方が早くね?
ちなみに、同じ事だが容量気にして構造体のなかでshortとか使うと
パデイング入るんでメモリに無駄が発生する。
まぁ、パディングを知っていれば無駄を防ぐこともできるけど。

189 :デフォルトの名無しさん:2009/01/11(日) 01:50:19
>>185
> struct{char value;} array[0x100];
> だったらレジスタサイズにパディングされる分、構造体の方が早くね?

pragmaやattributeでパックしない限りpaddingは入らないだろ。

191 :,,・´∀`・,,)っ-●◎○:2009/01/11(日) 06:05:36
>>189
構造体やその配列の場合、パディングが入る。
デフォルトが4バイト単位だったかな?

360 :デフォルトの名無しさん:2009/09/08(火) 20:07:19
だんごじゃないけどi5はi5だよ。それ以上でもそれ以下でもない。

361 :デフォルトの名無しさん:2009/09/08(火) 20:13:34
>>360
おめーみたいなカスには聞いとらん失せろゴミが
ダンゴさんマダー?

363 :デフォルトの名無しさん:2009/09/08(火) 21:25:40
>>361
ちょwだれww
ほれ、なんかcore2の時とかこれはいいぜーとかなんか詳しく言ってたような気がしたから
i7なりi5なりのアーキテクチャ面からの意見を聞いてみたかったんだ

382 :デフォルトの名無しさん:2009/09/10(木) 00:35:11
おい!テーブル使わん言ったじゃねえかよ。氏ねカス。

387 :デフォルトの名無しさん:2009/10/08(木) 03:33:43
unsigned int mod6(unsigned int m){
unsigned int a = 0;
static unsigned int x[] = {0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4};
__asm{
mov eax, m
test eax, 1
jz Mod3
inc a
Mod3:
shr eax, 1
lea ebx, x
mov edx, eax
and eax, 0000ffffh
shr edx, 16
add eax, edx
mov edx, eax
and eax, 0000003fh
mov ecx, edx
and edx, 00000fffh
shr ecx, 12
shr edx, 6
add eax, ecx
add eax, edx
mov edx, eax
and eax, 0000000fh
shr edx, 4
add eax, edx
mov edx, x[eax*4]
add a, edx
}
return a;
}

399 :デフォルトの名無しさん:2009/10/08(木) 15:58:42
逆数乗算で商を求めて元の値から引いたほうが速い
今のCore MAでは整数乗算は浮動小数除算機と兼用してて
非除数 - (除数×小数点以下切り捨てた商)

まあベンチ取ってみればわかるがコンパイラの吐くコードにも勝てんと思う

401 :デフォルトの名無しさん:2009/10/08(木) 17:45:39
static??const??int??rcp6??=??1.0??/??6.0??*??std::pow(2.0,16.0);
int??x??=??255??-??((255??*??rcp6)??>>??16)??*??6;

確かにこれで十分な気がするし、>>387より速そうだ。


414 :デフォルトの名無しさん:2009/10/09(金) 01:24:41
>>387
inline unsigned int mod6(unsigned int a){
 unsinged int b = (a >> 3) + (a >> 5); // /6
 unsinged int c = (b << 1) + (b << 2); // *6
 return a - c;
}

456 :デフォルトの名無しさん:2009/10/22(木) 03:07:47
C/C++でメモリプール(int, doubleなど様々な型が共存)を作り、
メモリプール内部でメモリの詰め直しを行って最適化しようと試みています。

入門書+α(boostがわかるぐらい)なので、
キャッシュやメモリに関する特殊なことは全然わかりません。
何か気をつけなければならないことや忠告があれば教えてください。

488 :,,・´∀`・,,)っ-○○○:2009/10/28(水) 04:46:10
for (i = 0; i < N; i+=4) {
  sum1 += A[i];
  sum2 += A[i+1];
  sum3 += A[i+2];
  sum4 += A[i+3];
}
sum = sum1 + sum2 + sum3 + sum4;

っていうか組み込み関数使えよ

498 :デフォルトの名無しさん:2009/10/29(木) 08:44:26
>>488
これってNがわかっていないとコンパイラはやってくれないよね?
ICCだと出来るのかな?
GCCではベクトル化してくれなかった。

539 :デフォルトの名無しさん:2011/01/28(金) 11:43:56
x86は浮動小数点が弱くて仕方がないからなあ
8087のコプロセッサの頃からの負の遺産を引きずっている
でもL1/大容量L2キャッシュを媒介にする事によって相当克服して来てはいるんだけどな
PowerPCなどにどうしても勝てない

596 :デフォルトの名無しさん:2011/05/30(月) 10:20:14.97
結論から言うとメモリの転送がボトルネックです。
書き出しのアライメントを揃える事とstreamを使う事で何割かは改善出来ますが、基本的に速く出来ません。

最適化とは遅い部分を探し出す事に他なりません。
安直にSSEとかマルチプロセッサにしようと思わず、真にボトルネックを見つけられるようになりましょう。

真に遅い部分が分かったなら、平均化フィルタと何が違うのか、どうしてもう速く出来ないのかが理解出来るようになります。

598 :デフォルトの名無しさん:2011/06/13(月) 15:11:06.75
>>596
メモリの転送がボトルネックなのか、演算部分がボトルネックなのかは
どうやって判断すればいいのですか?つまりどこを見たらよいのか。
あるいはあなたはどうやってますか?
ツールとか使うのでしょうか?

618 :デフォルトの名無しさん:2011/07/02(土) 22:44:49.03
mapの方がアライメントされてないんじゃない?

619 :デフォルトの名無しさん:2011/07/02(土) 23:38:54.68
std::pair<int, hoge>からaligned_stl::pair<int, hoge>へのコードがバグってるんじゃないの

620 :618:2011/07/03(日) 00:21:26.44
適当な事書いたと思ったけど、std::mapにカスタムアロケータでいけるっぽい
http://ideone.com/sOWl6



621 :デフォルトの名無しさん:2011/07/03(日) 02:45:36.94
>>618
mapの方は、__declspec(align(16))みたいなことはしてませんが
カスタムアロケータを渡しており、カスタムのpair(aligned_stl::pair)を使うように指定してます。

>>619
わかりづらくてすみませんorz
std::pairは一切使っておらず、aligned_stl::pairのみです。
make_pairもaligned_stl::pairを返します。

>>620
ありがとうございます、Win7 64bitのVC2008Expressで動かしてみましたが
カスタムアロケータのc.insertで、Hoge()の引数なしのコンストラクタで落ちます(x_ = static_x)
Hoge hoge;
c.insert( ::std::make_pair<int,Hoge>(i, hoge) );
とやると、make_pairのところのコピーコンストラクタで落ちます( x_ = src.x_)。
なので、前回書いたのと同様に
Hoge hoge;
std::pair<int, Hoge> pairArg(i, hoge);
とやってからpairArgを渡すと落ちませんでした(c.insertのみ。d.insertは落ちる)。

どうもpairに関してはアラインメント指定しなくても、中のメンバが
アラインメント指定されていれば問題ないようですね(アロケータだけでよい?)。
もうちょっと試してまた報告します。
ただ、2008だとアラインメント指定が一時オブジェクトに対して効かないと考えたほうが
いいのかもしれませんね(´・ω:;.:...  (インライン展開された場合は除く)
ありがとうございました。

638 :デフォルトの名無しさん:2011/07/05(火) 22:56:13.54
余分なカッコが多すぎるコードってみにくくて嫌いだ。

if (a == 0 && b == 0 || c == 0 && d == 0)

if ((((a == 0) && (b == 0)) || ((c == 0) && (d == 0))))

この二つだと上の方がはるかに見やすいと個人的には思うが、
見やすさを優先してカッコをつけるとか言って下のように書く人がいる。


649 :デフォルトの名無しさん:2011/10/10(月) 19:26:30.72
指定桁数で四捨五入する以下の関数の実行速度を上げたいの。
(valueは0~9999、digitsは0~5が保証される)
SSE使って高速化頼む。

double NormalizeDouble(double value, int digits) {
  static double t0[] = { 1, 10, 100, 1000, 10000, 100000 };
  static double t1[] = { 1, 0.1, 0.01, 0.001, 0.0001, 0.00001 };
  return (int)(value * t0[digits] + 0.5) * t1[digits];
}

652 :デフォルトの名無しさん:2011/10/10(月) 19:49:57.12
>>649
最適化スレで終了宣言してからにしろよ

653 :デフォルトの名無しさん:2011/10/10(月) 19:50:50.26
でもベクトル化で少しは早くなるわよ

664 :デフォルトの名無しさん:2011/12/17(土) 22:41:12.80
signed shortの配列に
floatもしくはdouble型の乗算をして
クリップ処理をほどこし
signed shortの配列に戻すのを
SSEにしたいのでやってください


これ

signed short s[100];
float f
init a;

for (a=0;a<100;a++)
s = s[a] * f;

665 :デフォルトの名無しさん:2011/12/17(土) 23:06:34.33
それ、どう考えても実数型⇔整数型のコストがでかすぎる。
たった100件でいいなら実数で持てないの?

679 :デフォルトの名無しさん:2011/12/19(月) 02:15:44.43
初めてSSEに触れるので、まずは簡単なコードを作成してみたのですが、
SSEを使わないほうが40倍も速いという驚愕の結果が出ました。
何が間違っているんでしょうか??

コンパイラ:VC++2005(Releaseモード、浮動小数点モデル:FAST)

float* f4pakAdd( float* pfA, float* pfB )
{
  _declspec( align( 16 ) ) static float fC[ 4 ];
  
  _asm
  {
    mov ebx, pfA
    movaps xmm0, oword ptr [ebx]
    mov ebx, pfB
    movaps xmm1, oword ptr [ebx]
    addps xmm0, xmm1
    movaps fC, xmm0
  }
  
  return fC;
}

呼び出し側

for( int i = 0; i < 10000000; i++ )
{
  pfC = f4pakAdd( fA, fB );
}

682 :デフォルトの名無しさん:2011/12/19(月) 02:34:54.14
パイプライン化したコードでもないし、スタックチェックが行われている気がするが。
逆アセ確認したかい?

707 :デフォルトの名無しさん:2011/12/23(金) 11:26:47.88
どんな変数も問答無用でアライメント16にするようにコンパイルする設定があれば
面倒な記述を減らせると思うんですが、何かデメリットあるんでしょうか?
メモリの隙間ができて勿体無いとかあるかもしれませんが、メモリ量の多い昨今、
それほど問題にならないのでは?と思います。
むしろアライメントすることでメモリアクセスの冗長さを減らせて帯域を節約する効果も
あって一石二鳥ではと思うんです。

708 :デフォルトの名無しさん:2011/12/23(金) 11:59:03.43
gccだと-mpreferred-stack-boundary=4がデフォルトだから既に16バイトアライメントだよ
構造体の詰め物は互換性もあるし難しいじゃないか

710 :,, ・´ ∀ `・ ,,)っ-○○○:2011/12/23(金) 12:41:37.02
>>707
なにそれ君いまだにPS3向けのゲームとか組まされてるわけ?

711 :デフォルトの名無しさん:2011/12/23(金) 15:57:24.48
>>708
glibcのmallocは8バイトだよ

>>710
SandyBridgeでもアラインメント取れてないと遅いでしょ

713 :デフォルトの名無しさん:2011/12/23(金) 17:19:17.60
>>711
Nehalem以降はmovups/dquもペナルティ無く使えるでしょ
まあ結局Core2以前も考慮するとコード振り分けるから労力は変わらないのだけれど...

714 :707:2011/12/24(土) 02:12:26.59
すみません、自分は日曜プログラマレベルで、対象CPUはx86、環境はVC++です。
VC++の設定を見ていると、「構造体メンバのアライメント」というのがあって16バイトアライメントを選べるようになってました。
同様に通常の変数もアライメントできる設定があるかと思い探しましたが見付かりませんでした。

715 :デフォルトの名無しさん:2011/12/24(土) 02:18:17.32
どう考えてもこれ以上削れないってくらいの手書きインラインアセンブリコードに対し、
C記述版をVC++のReleaseモード(最適化O2)でコンパイルしたもののほうが1.3倍速かったです。
生成されたアセンブリを覗いてみたところ、

変数 * 3

というコードを

lea edx, DWORD PTR [eax+eax*2]

としていてびっくりしました。
これって、アドレス演算を行うローダ(専用の演算器?)を使うことで、
通常のALUと並行して演算(スーパースカラって言うんでしたっけ?)し
高速化しているということなんでしょうか??

716 :デフォルトの名無しさん:2011/12/24(土) 02:34:46.72
>>714
__declspec(align(N))

717 :707:2011/12/24(土) 02:44:05.59
>>716
ありがとうございます。
それは知っているんですが、>>707でも書いた通り、
そういった記述をわざわざせずとも、自動で全てアライメントしてくれるような設定があればイイのでは?
と思った次第です。

しかし、上でも仰られたように、互換性の問題があったりで難しいのでしょうね・・・
でも二重インクルード防止の「#pragma once」のように、互換性を考慮しない機能があったりするくらいですから、
自分のようにずっとVC++しか使わない人間を対象にそういうオプションが用意されていても良いのではと思いました。

733 :デフォルトの名無しさん:2012/03/09(金) 12:53:25.77
unsigned int maxpos(unsigned int src[256])
{
unsigned int i, m = 0;
for(i = 1; i < 256; i++)if(src[m] < src[i])m = i;
return m;
}
これをSSEで高速化する方法があれば教えて下さい

739 :デフォルトの名無しさん:2012/03/11(日) 00:41:15.69
>>733
画像とか統計の基礎だな。疑似コードで書くとこんな感じだ

maxpos(src[256]) {
pos = {0, 1, 2, 3};
for(i=0; i<256; i+=4) {
 s=load(&src[i]);
 isGT=maxVal<s;
 maxVal=isGT&s | ~isGT&maxVal;
 maxPos=isGT&pos | ~isGT&maxPos;
 pos += 4;
}
return max_position(
 maxVal[0], maxPos[0],
 maxVal[1], maxPos[1],
 maxVal[2], maxPos[2],
 maxVal[3], maxPos[3]);
}

762 :,, ・´ ∀ `・ ,,)っ-○○○:2012/03/14(水) 07:23:58.09
packed unsigned intの比較(マスク生成)だけど、両項のMSBを反転してからpcmpgtdするより
psubd + psradのほうが速いかもしれない

768 :デフォルトの名無しさん:2012/03/21(水) 23:53:20.16
P6,P2,P3,P4はforwardならnot taken backwardならtakenがデフォルト
P4はPrefixでヒントを出せる
PM,Core2はランダム
ソースはAgner

775 :デフォルトの名無しさん:2012/03/24(土) 21:41:50.71
そう思ってくれるのはいいが、間違いの指摘と
実際はどうなってんのか答えてくれ
批難だけの回答はいらん。

778 :デフォルトの名無しさん:2012/03/24(土) 21:52:06.49
>>775
じゃあ間違いを指摘してやる。

>大概returnやthrowが行われるからifをすっ飛ばせば速いのは解る。
前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if (xx) return
で「すっ飛ばせば云々」なんて、理解していないまま「わかったつもりになってるだけ」の証拠。

>今のCPUは分岐ヒントとか投棄とかあって単純じゃないんだろ
ヒントはともかく、投機はまさに「投機実行するために分岐予測をする」のであって
「投機実行もあるから分岐予測が複雑になる」はナンセンス。
もちろん、エンプラ系/VLIW系では「分岐の有無の両経路を実行する」なんてのもある(らしい)が
一般的とは言いがたい。

779 :デフォルトの名無しさん:2012/03/24(土) 21:59:34.64
>>778
内容じゃなく国語的に誤解されてるな。

>前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if( xx ) throw xxx;
throwなんて実行するケース殆ど無いんだから基本if実行しないってのは同じ話。
矛盾してないでしょ。

まず分岐予測が複雑になってるって話はしてないよ。
投棄実行については投棄実行を考慮した上での静的予測方法があるでしょという話。

780 :デフォルトの名無しさん:2012/03/24(土) 22:04:11.41
>>779
だから、ifの内部は「実行すると予測される」んだよ、バーカ

782 :デフォルトの名無しさん:2012/03/24(土) 22:06:41.25
せめて正しい漢字使えよ。

一度なら単なる変換ミスとして納得できるけど
繰り返しているってことは、別の意味に捉えているとしか思えない。

783 :デフォルトの名無しさん:2012/03/24(土) 22:09:32.88
>>780
お前バカだろ
みんなアセンブリ前提で言ってんだよ

jze label   if() {
・・・処理・・・
labeli     }


789 :デフォルトの名無しさん:2012/03/24(土) 22:48:33.55
投棄実行については誤解してたわ。
2つの分岐を両方実行して実際実行対象にならなかった方の結果を破棄するものだと思ってた。

792 :デフォルトの名無しさん:2012/03/24(土) 23:01:04.27
一応。

突然returnやthrowが出てくるのが
if (xx) return
という意味じゃないか、というのも勝手に俺が頭の中で補って想像しただけで
実際には何の説明も無く(ifの多くがreturnやthrowというのにも同意しにくい)
唐突な「rerturnやthrow」「すっ飛ばす」を必死に理解しようとしたのがそもそもの間違いかもね。

794 :デフォルトの名無しさん:2012/03/24(土) 23:04:39.09
>>792
>>779で補足だしてるだろしつこいわ

803 :デフォルトの名無しさん:2012/03/25(日) 16:12:43.94
インテルの最適化マニュアルだと
>インテルPentiumM??プロセッサー、インテルCoreSolo??プロセッサー、インテルCoreDuoプロセッサーは、
>ジャンプの向きに従った条件分岐を静的には予測しない。これらのプロセッサーでは、
>すべての条件分岐は、最初に発生したときでも動的に予測される。
と書いてあって、wikiで調べたらPenM以降は広域分岐予測を取り入れた関係で静的予測はしなくなったみたいだね
http://ja.wikipedia.org/wiki/%E5%88%86%E5%B2%90%E4%BA%88%E6%B8%AC

>>768
>PM,Core2はランダム
というよりも、「前に実行した別の分岐命令の結果も影響する」とした方が適切みたいだ

分岐予測に関して
http://news.mynavi.jp/column/architecture/index.html
の第167回からの解説が参考になるよ



http://toro.2ch.net/test/read.cgi/tech/1130349336/l50/../人気ブログランキングへ

PC等Cで書くかアセンブラで書くか・・・

1 :デフォルトの名無しさん:04/09/30 02:24:11

下手なアセンブラコードよりも、Cで書いてコンパイラに任せた方が速い場合もあります。
こういう場合はアセンブラで、こういう場合はCで書いた方がいいよという情報をみんなで交換していきましょう。


このスレはCあるいはC++の中で使用するアセンブラに特化したスレです。アセンブラの全般の話題はこちらへ

アセンブラ… (°Д°)ハァ?
http://pc5.2ch.net/test/read.cgi/tech/1093519463/l50


23 :デフォルトの名無しさん:04/11/04 11:23:41
アセンブラを基礎から学べるサイトを教えてください

95 :デフォルトの名無しさん:2005/12/05(月) 15:15:01
超音波をAD変換させてポート1に出力したいのですが
#include<3048.h>

void ioinit(void)
{
P1.DDR=0xff;
}

void adinit(void)
{
AD.ADCSR.BIT.ADF=0;
AD.ADCSR.BIT.SCAN=0;
AD.ADCSR.BIT.CKS=1;
AD.ADCSR.BIT.CH=0;
}
}

どこがいけないのでしょうか?




97 :デフォルトの名無しさん:2005/12/05(月) 16:07:26
>>95-96

ここで聞いた方がいい
http://science4.2ch.net/test/read.cgi/denki/1133272478/


98 :デフォルトの名無しさん:2005/12/05(月) 18:47:45
>>95
3048.hの中身が分からない事には、何も言えません。
本の中身を、タイトルだけ見て当てろと言ってるのと同じだよ。

102 :デフォルトの名無しさん:2005/12/06(火) 15:25:26
>>95
3048.hってもしかしてルネサスのCPUじゃない?
ADってA→Dコンバートだから入力なんだが・・・

103 :デフォルトの名無しさん:2005/12/06(火) 16:03:59
全然、知らないけど、

超音波装置:電圧出力 → AD変換でデジタル値に変換
そのデジタル値を出力ってこと?
デジタルの出力ってどんなの?

105 :デフォルトの名無しさん:2005/12/06(火) 16:35:09
>>103
普通は
DA変換でデジタル値をアナログ電圧に変換 → 超音波装置:電圧入力


106 :デフォルトの名無しさん:2005/12/06(火) 21:22:23
>>105
そうすると>>95は実は、>>105の意味?

107 :デフォルトの名無しさん:2005/12/06(火) 21:30:04
>>106
>>95はADコンバートのスキャン開始を設定しているだけ
H8/3048のAD端子にかかっている電圧を一定時間毎に
デジタル値に変換してCPUの内部レジスタに転送してくれる機能が
あるんだけど、それを作動させたにすぎない
無論、超音波なんて出ない

108 :デフォルトの名無しさん:2005/12/06(火) 21:38:42
>>107
つーことは、>>102が正解ってことか。

127 :デフォルトの名無しさん:2006/06/13(火) 03:46:32
趣味の話しだけどCが苦痛の人もいます
アセンブラの方がやりやすくてイライラする
そういう場合に使う

149 :デフォルトの名無しさん:2006/10/20(金) 01:21:25
いまさらアセンブラを勉強して何になるの?
組み込み系のしごとでなけりゃ、使うことねーよ。


152 :デフォルトの名無しさん:2006/10/20(金) 10:53:49
>>149
32bit同士の掛け算は結果が64bitになる。
Cでも書けるが時間が4倍かかってしまう。
これは遅すぎて耐えられない。

153 :デフォルトの名無しさん:2006/10/20(金) 11:02:16
>>152
たった4倍
10秒が40秒になるんだったら遅すぎて耐えられないだろうけど
1/100msecが4/100msecになったところでたいした変わらないだろ

192 :デフォルトの名無しさん:2007/04/10(火) 15:22:04
生産性は大して変わらないが移植性が明らかに落ちるのが問題

193 :・∀・)っ-○◎●:2007/04/15(日) 15:21:28
>生産性は大して変わらない

構造化されてないスパゲッティコードばっかし書く人ならそうだな

194 :デフォルトの名無しさん:2007/04/15(日) 19:16:13
>>193
馬鹿が背伸びして話題に参加することないのにw
192の言っていることは疑念の余地無く正しいし、それが分からないとしたら
アセンブラでコーディングしたことがないんだろうな。

199 :デフォルトの名無しさん:2007/04/17(火) 23:28:28
>>194
こいつアセンブラでしかコーディングしたことないのか

16bit時代のWindows3.0だってアセンブラで書かれているのはほんの一部でしかない。
明らかに移植性より生産性を重視しての選択だろ
アセンブリ言語はコードを書くための生産性もそうだが
バグつぶしにかかる時間が高級言語に比べ明らかに落ちる

202 :デフォルトの名無しさん:2007/04/18(水) 00:10:38
>>199
>明らかに移植性より生産性を重視しての選択だろ
ここは「移植性と生産性」って書かないと何の反論にもならないんじゃないの?
アセンブラのコードの移植性が高い、と言ってる人間が誰かいるか?

まあいいや。
さすがにアセンブラと、例えばCを比べたときに、
生産性や可読性がまったく変わらないとまではいえないけど、分野によっては
それほど大差がなかったりするのは経験上事実だと思う。
(逆にいうと、複雑なデータ構造をこねくりまわすようなプログラムは
確かにアセンブラでは辛い場合が多いとは思う。)

もちろんCみたいに文法の足枷がないぶん、ループや分岐といった「構造」が
浮き彫りになるようなコーディングスタイルをきっちり決めないとそういうわけには
いかないと思うけど。

203 :199:2007/04/18(水) 00:24:31
>>202に反論するけど別に>>194に反論してる訳じゃないし
第三者的な位置から言ってみただけ
ちょっと>>194が狭い世界しか知らない風なのに
「馬鹿」呼ばわりしたのもムカついたし
それに>>192から逆上って読めば理解できるかと思ったから
あえてクドくかかなかっただけ。




208 :デフォルトの名無しさん:2007/04/19(木) 00:41:34
うちじゃ白黒二台とも現役なのに……

209 :デフォルトの名無しさん:2007/04/20(金) 12:58:46
>>208
黒って何だ?
#白はDreamCastなんだろうけど。

297 :デフォルトの名無しさん:2009/06/20(土) 15:20:08
それをゆうなら、Vista 32bit OSだろ?
アセンブラをダウンロードしてインストールすればいい。

299 :デフォルトの名無しさん:2009/06/21(日) 13:09:16
>>297
それを「いう」なら,だろ?

300 :デフォルトの名無しさん:2009/06/21(日) 13:45:09
「言う」は終止形・連体形が「ゆー」となる不規則変化動詞なので、「ゆう」と表記するのは全く問題ない。
古くは「いふ」「ゆふ」の両方の表記が見られた。

何で日本人が「いう」と書かないといけないと思い込んでるかというと、
「現代仮名遣い」によって「『言う』は常に『いう』と書け」と例外規定されているからだが、
日本語は日本国だけで使用される言語でもないので、
日本語を使用するにあたって、日本政府の決めた表記法に必ずしも従う必要はない。

303 :デフォルトの名無しさん:2009/06/21(日) 15:25:00
>>300
日本語が公用語の国って日本以外にあるの?
なにゆってんの?w

304 :デフォルトの名無しさん:2009/06/22(月) 09:37:11
「公用語として使う国」という電波をどこから受信したか知らんが、
日本国内であっても従う義務がないのは確かだな。

305 :デフォルトの名無しさん:2009/06/22(月) 10:53:33
>>304
義務って何?w

307 :デフォルトの名無しさん:2009/06/22(月) 12:07:03
>>305
義務も知らんのか。伊達に草生やしてないな。

308 :デフォルトの名無しさん:2009/06/22(月) 12:56:58
>>307
何で「義務」なんて言葉を使ってるのかきいてるんだよ。

俺は「いう」で習ったしそれが一般的だと思ったから指摘したまで。
従う必要があるとかないとかそんな話始めから誰もしてないっつーの。
「ゆう」がいいなら勝手に使ってなw

309 :デフォルトの名無しさん:2009/06/22(月) 14:13:50
>>308
俺は??>>303??のオナニー解釈を揶揄しただけなんだが。

>俺は「いう」で習ったしそれが一般的だと思ったから指摘したまで。
>>303??がその「指摘」なの?

317 :>>299,303,305,308:2009/06/22(月) 20:11:46
>>309
すまんが>>303は失言だった。すまん。取り消させてくれ。

> >>303 がその「指摘」なの?
いや,>>299のことだ。

「ゆう」もありってのは勉強になったよ。ありがとな。
ここまでにする。

319 :デフォルトの名無しさん:2009/06/23(火) 14:28:56
TASMとNASMで同一の命令が展開されたバイナリコードが
両者違う場合があるのですが、何故ですか?

332 :デフォルトの名無しさん:2009/06/24(水) 05:19:10
VSがはくアセンブリなんて、基礎から遠いところにあると思うがな・・・。

アセンブリレベルの最適化を学ぶということは、CPUアーキテクチャを学ぶこととほぼ同義。
インテルのサイトからマニュアル落としてこいよ。

>>319のような質問をするってことは、「80386/80486プログラミングガイド」辺りを読んで
より造詣を深めたほうがほうがいいかもしれない。最適化の話は全く出てこないが。
その後はせいぜいSIMD命令くらいだし。

347 :デフォルトの名無しさん:2009/07/15(水) 00:55:48
>プリフィックスが変だったりムダにLOCKとかの指定がついてたり、jmp先が命令の狭間になってないかで見る。
自分で自分を書き換えるタイプのプログラムだと
命令の狭間にjmpしててもおかしくはないような気もする
いまどきのCPUでも出来るのかどうかはしらないけど

348 :デフォルトの名無しさん:2009/07/15(水) 03:56:14
>>347
そゆのは例外でしょ。同じコードに複数の意味を持たせる場合も有るし、そういうガチガチに手を加えてある箇所は手で位置を指定しなおさないと。

広範囲の自己書き換えはパッカー(UPX等)とか耐タンパ手法とかで今でも使われてるから出来なくは無いかと思うけど、命令のキャッシュ機能はあるはず。
Win32APIにFlushInstructionCacheってのがあるけど、これはマルチプロセッサで命令キャッシュをクリアするモノらしい。
IFだけで実装無しってオチ・・・だったりしないよな?

352 :デフォルトの名無しさん:2009/07/15(水) 21:12:49
>>348
そのまさかだったらしい。
ttp://blogs.msdn.com/oldnewthing/archive/2003/12/08/55954.aspx
call/retでのキャッシュクリアが目的だそうで。

353 :デフォルトの名無しさん:2009/07/15(水) 22:49:15
ret と jmpってどう違うんですか?

354 :デフォルトの名無しさん:2009/07/16(木) 00:05:04
>>352
そのページの記事のコピー元の投稿日が分らないし、英語苦手なんで単語拾っただけだが、親投稿自体は98年以前の記事の様に見えるが・・・
VC++6.0付属のMSDN Libraryを参照すると
>This function is valid only on multiprocessor computers.
>この機能はマルチプロセッサコンピュータのみで有効です。

>Windows 95 and Windows 98: The FlushInstructionCache function always returns TRUE.
>Windows 95 and Windows 98 support only single-processor computers.
>Windows 95 and Windows 98:このFlushInstructionCache機能は常に非0を返します
>Windows 95 and Windows 98はシングルプロセッサコンピュータのみをサポートします。
とのことだから、"Win9xでダミー関数なのは"公式らしい。

コメントの方だと広域ジャンプでパイプラインハザードが起きてパイプラインが破棄されるとかその辺の話をしている・・・のか?
MSDNだとマルチプロセッサで有効(もしくは有効にする予定)の機能らしいが、コメントでマルチ??に触れてる奴がいないしちょっとアテにならん気がする。

95年代のCPU事情だとマルチコアはPC用途では考慮もされずワークステーションのごく一部実装されたマルチプロセッサで走るNT系のみをターゲットにしたAPI設計なのだろうけれど、現代のHT/マルチコアではどう作用するのだろう?

>>353
retはアトミックにスタックのポップを実行すると思われる。
pop ecx
jmp ecx
とかだとアトミックに実行されることは保障されないし、レジスタも一個浪費する。
あと、解析系のプログラムはretを期待するはずなのでその辺の違い。

375 :デフォルトの名無しさん:2009/09/28(月) 12:35:40
double f(double a)
{
return a + 1.0;
}

をアセンブラで書くとどうなる?

377 :デフォルトの名無しさん:2009/09/28(月) 12:54:25
>>375
cc -S してみれば?

387 :デフォルトの名無しさん:2009/10/14(水) 21:08:57
ストリング命令は何故、DS:SI及びES:DIで処理されるのですか?

529 :デフォルトの名無しさん:2009/10/26(月) 21:47:00
セグメントベースとは、セグメントアドレスに対して*16を行ったアドレスの事ですか?

553 :デフォルトの名無しさん:2009/12/14(月) 04:13:25
void ch1puts(_UBYTE* srcp) {      /* 送信バッファ書き込みルーチン*/
  register _UWORD Rx=c0s_wpt;     // loop中はRegに持つ
  do {                /* サイズ回 loop    */
    s0ring[Rx] = *srcp++;      /* 1 キャラ put, srcp++  */
    Rx = (_UWORD)((Rx+1)&(sizeof s0ring-1));// カウンタ更新
  } while( *srcp );
  c0s_wpt = Rx;            // ringポインタ更新
  SCI0.SCR.BYTE = 0xF0;        /* TIE,TE ON    */
}  石はH8S。まあ、ふつうに素直なringバッファに書き込むルーチンなんだが

554 :デフォルトの名無しさん:2009/12/14(月) 04:24:22
引数はER0に乗ってきて、関数中ではそれをER2に持つ。*srcpをER0のまま使えるのに。
RxにE0を使い、loop中でE0→ER1に毎回ゼロ拡張が起きる。RxにR1を使えばloop前に
E1を1回だけゼロにしとけば済むのに。&演算も R1=R1&07FF とワードになる。
R1H=R1H&7 でイイのに。これだからへうのコンパイラ嫌いなんだ。

562 :デフォルトの名無しさん:2009/12/17(木) 12:06:20
書き方が悪いような

563 :デフォルトの名無しさん:2009/12/21(月) 05:06:18
>>562 553のcコードに対して提案を書いてみて。コンパイルしたlst貼るから。

564 :デフォルトの名無しさん:2009/12/21(月) 11:00:08
union
{
unsigned int WORD;
struct
{
uncigned char high;
unsigned char low;
} BYTE;
} c0s_wpt;

cos_wpt.WORD++;
c0s_wpt.BYTE.high&=7;


567 :563:2009/12/21(月) 15:14:18
あと、>>554では>>553のコードの展開形のうちダメな点を3点挙げています。
>>564は1,2番目に対しては何も言っていませんね。3番目に対して的外れな提案しただけ。

580 :デフォルトの名無しさん:2009/12/22(火) 17:04:18
gdlで検索してみて

591 :567:2009/12/23(水) 16:26:22
>>580 gdl 使ってみました。複数ファイルリンク機能とか無いみたいなので、全部ひとつの
ファイルにして読み込ませればいいですか? 割禁とかマシン依存な機能はどう書けば
いいのでしょう? 割り込み処理関数の書き始めも文法違うみたい。
展開したフォルダの中にマニュアルみたいのが見つからないんです。

602 :591:2009/12/28(月) 01:32:15
BCLR/BSETは、LD mask ST 型で出るんですね。ここが残念

606 :602:2009/12/29(火) 04:43:33
ライフボートのcでは、初期値ゼロが不要な領域(ringバッファ)に別のセクション名を与えて、
デフォのセクション名の領域だけをクリヤする、ってことをできたんです。
GCCで似たようなことをするにはどういう手法がありますか?

608 :602:2009/12/30(水) 04:18:18
coffとかelfとかのファイル型式が理解できてないですが、-O srec a.out xxx.MOTで
MOTに変換できました。BIT操作は素直に割禁使うことにしました。
RAMクリヤが必要な空間だけ隔離できないのがちょっと残念ですが性能上は問題無い。
でもRAM16Kのうち2Kもlibが使うし、ROMもアプリ6Kでlibが28K。どちらも余っているから
いいけど、なんかグヤジー・・・

609 :デフォルトの名無しさん:2010/01/04(月) 13:07:28
asm volatile ("bclr %1,@%a0:8": :"i" (&SCI0.SSR),"i"(6))
かな?

611 :デフォルトの名無しさん:2010/01/06(水) 05:58:30
わを・・・>>609は605へのレスですよね。 ありがとうございます。試してみます。

786 :デフォルトの名無しさん:2011/09/24(土) 20:08:45.15
何なのよ?


http://hibari.2ch.net/test/read.cgi/tech/1096478651/l50人気ブログランキングへ

学ばないブログ
忍者AdMax
記事検索
最新コメント
QRコード
QRコード
  • ライブドアブログ