- 1 名前：デフォルトの名無しさん [2007/03/25(日) 21:19:33 ]
- アセンブラ全般に関するスレッドです。
【前スレ】
アセンブラ… (゜□゜) ↑アッー！↓
pc11.2ch.net/test/read.cgi/tech/1148402614/
- 24 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 18:00:59 ]
- >>16
まじで？
そこの式に出てくるような8ビット精度でやられるんだったらむしろ迷惑この上ないんだけど。
- 25 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 19:46:17 ]
- それはイメージ図みたいな物で、実際のコードではない。肝心なところを手元で再現したもの。
ニュアンスだけならこれで十分かと思ったのだが、誤解があったようで、すまんかった。
VCの最適化はたしかedx:eaxの幅64ビットを目一杯使うはずなんで、信頼してやってくれ。
- 26 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 19:48:31 ]
- あと一つ断っておくが、さすがのVCと云えども浮動小数点計算の整数化まではしないぞ。
俺が感心したのは整数除算の右シフト化の部分だ。レスの趣旨から読み取ってもらえるとは思うが。
- 27 名前：デフォルトの名無しさん [2007/04/04(水) 11:49:33 ]
- しかし最近のアセンブリンガーは何やってるかわからなくなってきた。
最適化と称して俺のコードを台無しにする
- 28 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 13:00:16 ]
- アセンブラが難しいとされたのってさ、アドレッシングが貧弱で、
レジスタも少なく、使いづらいセグメントがあったりする石を使って、
限られたメモリ資源内でやらなきゃならなかったりしたからじゃないかな。
- 29 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 13:41:40 ]
- >>28
まあ確かに32個あると楽だけどな
- 30 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 13:53:45 ]
- つまり、アセンブルはパズルなんだよ。
コップ一杯の水を、容量の異なるコップを移し変えて400mlと600mlに分けるには
みたいな発想力がある程度もとめられる。
それができない人間が嫌うだけで
神という文字を入れたいのに記憶容量が足りない
おおっとネと申に分けられるじゃないか、これで後から合わせれば神になるぞ、
ということに気づく人間と、気づかない人間
ここに、アセンブラできる奴とできない奴が別れるのだ
- 31 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 14:05:41 ]
- アセンブラには、以前の日本が持っていた、
頭を働かせて出来る限り小さくまとめ、出来る限り高速に、出来る限り遠くへ、出来る限り豊かに
という、だいわ魂が宿っている、気がしてならない。
つまり、アセンブラを極めることは、かつての日本人が持っていた、
知恵というものを、取り戻すことであるといえるのではないか。
- 32 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 14:12:21 ]
- 31の意見も同意できないことはないが
俺はアセンブラは小さいものが好きな日本人をあらわしてる
と思う
アメリカ人は大きいものが好きだからオブジェクト指向なんだろうと思う
- 33 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 15:18:23 ]
- 折角の>31の高説も、「だいわ魂」で台無しだな。
- 34 名前：デフォルトの名無しさん [2007/04/04(水) 18:23:11 ]
- gdbを使うと、なぜか実行開始時に必ず SIGTRAP で止まるんだけど、解決方法分かる人いる？
- 35 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 22:39:02 ]
- 友人に、メモリにほとんどアクセスせずにハチャメチャな方法でやってる香具師が居るんだが。
使用レジスタ
eax,ebx,ecx,edx,edi,esi,ebp,es,fs,gs,mmx
- 36 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 22:43:57 ]
- > メモリにほとんどアクセスせずに
可能であれば、わざわざ糞遅いメモリなんぞにアクセスする必要はないだろ。
- 37 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 23:20:28 ]
- 限度があるぞｗ
それにキャッシュを意識して慎重に組めばそんなに気にならないもんだど
- 38 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 23:21:49 ]
- 書いた本人以外にメンテナンス困難なソースとか
見ると吐き気がしてくる。
- 39 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 23:39:15 ]
- ＞使用レジスタ
＞eax,ebx,ecx,edx,edi,esi,ebp,es,fs,gs,mmx
それなんてicc?
- 40 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 23:50:11 ]
- なんつったってねicc
- 41 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 02:05:08 ]
- 今、MMXを使って半透明合成を行う関数を書いています。
元画像1と元画像2を半透明合成して描画先に転送するという単純な仕様なのですが、
メモリアクセスがネックとなり、目標とする速度に達しませんでした。
そこで色々と実験してみたところ、うちのK6-2で、
元画像1 ＋ 元画像2 → 描画先
と処理するより、
元画像2 → 描画先
元画像1 ＋ 描画先 → 描画先
としたほうが速くなることが分かりました。
単純に考えると、後者のほうがメモリアクセスも命令数も多く、遅くなるはずなので、
キャッシュが実行速度に大きく影響しているのだと思われます。
とは言うものの、私はアセンブリにはあまり詳しくなく、
どうすればキャッシュを効率よく利用できるのか分かりません。
特に、持っていないが動作環境に載っている底辺CPUでは実験もできず、
どんな方法でうまくキャッシュされるのか見当もつきません。
そこで質問なのですが、下記のソース
sakuratan.ddo.jp/uploader/source/date36979.txt
のAB_START1におけるメモリアクセスを改善して、高速化することは可能でしょうか。
うまくキャッシュに乗れば、当然前者のほうが速いと思うのですが……。
- 42 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 00:09:50 ]
- まだソース見てないが、一度の計算ブロックで扱うメモリの量は64KBに抑えると
キャッシュに乗りやすかった気がする。
- 43 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 09:48:03 ]
- >>41
元画像1、元画像2、描画先の各先頭アドレスの下位14bitが
同じということはないよね？(800x600だからまずないだろうけど)
もし同じだと、K6-2 L1データキャッシュの2way set associativeの
制限に引っかかるかもしれないので。
それからK6-2といえば、Write AllocateのON/OFFを設定で変えられると思うけど、
ON/OFFどっちの設定での結果？ 設定を変えると速度に変化はある？
それとここは間違いだよね
mov ebx, [src1] ;
mov ebx, [src2] ;
- 44 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 10:30:46 ]
- >>42
64kbですか……。
画像一枚あたり1.4MBもあるので、 収めるには分割すべきなんでしょうかね……。
>>43
下位14bitはまず一致しないはずです。
Write AllocateはONになっていたので、OFFに変えてみたところ、
素直なブレンド ： 85ms→35ms
二段階のブレンド ： 65ms→55ms
と、大幅に高速化しました。
これはキャッシュミスが頻発しているということなのでしょうか……？
あと、すみません、ご指摘のとおりsrc1のところはeaxのミスです。
- 45 名前：デフォルトの名無しさん [2007/04/06(金) 10:37:40 ]
- Write Allocate は、ランダムライトでワリを喰う。
- 46 名前：42 mailto:sage [2007/04/06(金) 14:06:45 ]
- 他のプログラムで使ってる分とか、スタックとか機械語の命令とか全部含めて64kbな。
だからデータ読み込み系で32kb占有できればいい方かと。
書き込みはほぼ間違いなくヒットするから気にしなくてよかったはず。
デュアルコアCPUだと1次キャッシュが二つ乗ってる上に2次キャッシュがあるからもう少しキャッシュヒットすると思うけど。
- 47 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 14:22:11 ]
- >>46
ちゃんと理詰めで算出しろよ
キャッシュ機構によってサイズが違うぞ
- 48 名前：43 mailto:sage [2007/04/06(金) 14:45:50 ]
- >>44
WA OFFによりメモリ読み込みが減って10msくらい速くなるというのはまだわかるけど、
素直なブレンドの方で50msも速くなるのは何でだろう？
何で素直なブレンドはWA ONで50msも遅くなるのか…。
WA ONの場合、元画像2(src2)または描画先(dest)のアドレスを8バイト〜数百バイトぐらい
ずらしてみても速度に変化はないですよね？
- 49 名前：42 mailto:sage [2007/04/06(金) 16:26:48 ]
- >>47
算出が面倒になった。
>>48
ﾜｶﾗﾈ。50msの溝についてだれか分かる人解説ｷﾎﾞﾝ
- 50 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 17:59:31 ]
- 素直なブレンドで描写先に転送するとき。
WA OFFだと単にデータをメモリへ転送するだけで済むところを、
WA ONの場合は、まずメモリからキャッシュにロードを行い
そのキャッシュに書き込んでからメモリに転送する。
つまり、無駄なロードが大量に生じて、キャッシュも無駄に使うから遅い。
これは最近のCPUでも同様に遅い。movntqを使うと何倍も速くなったりする。
参考：
pc11.2ch.net/test/read.cgi/tech/1085749218/138
WA ONの二段階のブレンドで、65msと若干速いのは
無駄なロードを先に済ませちまうからかな？
- 51 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 00:33:56 ]
- VISTAの64ビットでは__asmが使えないのは、本当なの？
- 52 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 01:18:18 ]
- Vistaは関係ないが、64bitでインライン使えないのは本当。
- 53 名前：デフォルトの名無しさん [2007/04/07(土) 02:19:34 ]
- >>52
64ビット環境のAPIフックするには1万ドル払ってDetours Professional 2.1っていうのを購入する必要があるみたいだね。
Microsoftって将来的には個人開発者を低レベルプログラミングから追い出すつもりなのかな？
- 54 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 02:24:57 ]
- mov cr0,0
mov cr1,0
mov cr2,0
mov cr3,0
- 55 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 06:16:44 ]
- >>54
(ﾟДﾟ)
- 56 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 07:46:55 ]
- ml64で我慢しとけ。
- 57 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 13:46:11 ]
- >>54
最もやってみたいことだが、決してやってはいけないことだな。
cr系に即値って入れれたっけ？
- 58 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 14:19:20 ]
- おまらに聞きたいんだが今からアセンブラを勉強するとしたら
どんな本が一番いいと思う？
- 59 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 14:28:09 ]
- いまどきのアセンブラの教科書
- 60 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 16:21:52 ]
- どんな本がとか言われてもな。
メーカが供給してるその石の仕様書があれば他には何にも要らないと思うが。
- 61 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 16:53:06 ]
- >>58
アセンブラは、たとえばC言語のANSI Cみたいな業界標準がないから
「これ１冊でアセンブラを網羅」なんて教科書はない。
メジャーなアセンブラ（MASMなど）なら例外的に参考書が発行されている
こともあるが、原則的には>>60の言うCPUの仕様書とアセンブラのマニュアル見るしかない。
- 62 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 18:19:04 ]
- >>59
どっちだよｗｗ
- 63 名前：デフォルトの名無しさん mailto:sage [2007/04/07(土) 18:26:35 ]
- >>59
d.hatena.ne.jp/yaneurao/20050602
- 64 名前：41 mailto:sage [2007/04/08(日) 00:06:43 ]
- みなさん、どうもありがとうございます。
やはり書き込み時のキャッシュ問題ですか……。
K6-2や初代CeleronにはmovntqなどのSSE命令は実装されていないので、
その辺りでは今の二段階処理が現実的なのかもしれませんね……。
CPU別の切り替えも視野に入れて検討してみます。
- 65 名前：43 mailto:sage [2007/04/08(日) 08:59:02 ]
- >>64
家にPentiumII266MHzがあるので計測してみました。
count=800*600*3/8
src1,src2,destは各800*600*3バイト
mov ebx, [src1] ; はeaxに修正しています。
PentiumII266MHz EDO-DRAM
素直なブレンド ： 36msくらい
二段階のブレンド ： 56〜57msくらい
P6はWrite AllocateをOFFにできないので、
Write Allocateが機能している状態での計測です。
- 66 名前：43 mailto:sage [2007/04/08(日) 09:24:41 ]
- >>64
movntqが利用できないのであれば
destをNOCACHE領域にしてしまうとか。
VirtualAlloc(,MEM_COMMIT,PAGE_READWRITE|PAGE_NOCACHE)
で領域確保して、書き込み処理が終わったら
VirtualProtect(,PAGE_READWRITE,)
でCACHE可に属性変更する等。
- 67 名前：41 mailto:sage [2007/04/09(月) 21:58:55 ]
- VirtualAllocでキャッシュの有無まで指定できるなんて、今まで知りませんでした。
K6-2で試してみたところ、WA ONでも、VirtualProtectを入れて40ms弱で素直なブレンドが実行できました。
これなら十分に使えそうです。
キャッシュをオフにしたことでPen4等では遅くなりましたが、
これは初回起動時にでも計測して保存しておけば切り分けられそうです。
どうもありがとうございます。
それにしても、Pen2ってそんなに速いんですね……。
Intel系のCPUは心配せずとも良いのかもしれません。
- 68 名前：デフォルトの名無しさん [2007/04/14(土) 18:50:56 ]
- 64bitOSではアセンブラ使えないのですか？
それともインラインが使えないだけ？
インラインどうしても使いたい場合の代替ってありますか。
- 69 名前：デフォルトの名無しさん mailto:エイトワンのファン [2007/04/14(土) 18:54:00 ]
- 島根県のみなさん、パチンコをするなら、
優良パチンコ店 エイトワン
に行こう！ 遠隔（※１）を絶対やってないのは「エイトワン」だけ！
違法ロム（※２）を絶対使ってないのも「エイトワン」だけ！
エイトワンでは、遠隔等が可能な設備は入れていません。 ロムも、警察がチェックしやすいようにしています。
詳しい方はご存知の通り、どんなにパチンコの遊戯人口が変動しても、その市場規模は変わりません（※３）。
要するに、客が減っても、残った客から絞り盗る量を増やして調整しているのです。
しかし、何故それが可能なのか？…ご理解頂けると思いますが、９割以上の店が確実に遠隔等を行ってます。
１万店以上の中でも、遠隔も違法ロムも確実にやってないのは「エイトワン」１店だけです！
※１…遠隔とは
「お、あの客は新顔だな。勝たせて味を占めさせるか。遠隔操作で設定変更しよ」
「客が減ってきたな。ま、設定を絞めて（１人あたりから）搾る量を増やせばいいか」
「あのオヤジ負け続けてるからそろそろ辞めるかもな。今日は勝たせてやるか」
※２…違法ロムとは
「うちのアタリ確率は、もちろん他と同じ『○○○分の１』ですよ！（ロムいじってるからウソだけど）」
※３ 市場規模 遊戯人口
平成06年 30兆4,780億円 2,930万人
平成08年 30兆0,630億円 2,760万人
平成10年 28兆0,570億円 1,980万人
平成12年 28兆6,970億円 2,020万人
平成14年 29兆2,250億円 2,170万人
平成16年 29兆4,860億円 1,790万人
- 70 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 18:54:40 ]
- モジュールとして、リンクするくらいしかない場合
それって速度の面でどうなの。
- 71 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 19:06:07 ]
- >>68
よほど特殊なCPUで無い限り使える。
インライン？というのはCのことか何を言いたいのか不明。
>>70
中身というかその処理内容次第。
- 72 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 19:32:53 ]
- >68
インライン？
このスレは、インラインアセンブラの「中のコード」については話せると思うが
「インラインアセンブラを使うには」という内容ならその処理系のスレで訊きな
- 73 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 19:44:26 ]
- インラインアセンブラ使うとコンバイラがバグるよ
- 74 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 20:13:34 ]
- CPUとかOSとかコンバイラ（笑）の具体的情報もないのに
＞64bitOSではアセンブラ使えないのですか？それともインラインが使えないだけ？
＞インラインアセンブラ使うとコンバイラがバグるよ
って会話が成立する摩訶不思議なスレはここですか^^
- 75 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 20:42:08 ]
- アセンブリ言語で書く必要があるならインライン・アセンブラなんて中途半端なことせずにアセンブラ使え。
インライン・アセンブラを使わないと性能が出ないような処理系なら窓から投げ捨てろ。
- 76 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 20:53:36 ]
- ｴｰ(´д`)
- 77 名前：デフォルトの名無しさん [2007/04/14(土) 21:07:14 ]
- 押す！
- 78 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 21:39:11 ]
- >>75
それ、激しくﾏﾝﾄﾞｸｾ
- 79 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 22:13:22 ]
- だがソース中にインラインアセンブラが散在していると
環境が変わったとき、もっとマンドクサイことに…
- 80 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 22:20:32 ]
- その辺は設計次第でどうにかなる
大体速度要求されるような部分って限られてるし
- 81 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 23:30:39 ]
- 少し前に、64bitだとCであれJAVAであれ、「インラインアセンブラは絶対通らない」と言われていた。
- 82 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 23:53:16 ]
- どこの世界の話ですか?
Windows 方面かな?
- 83 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 02:22:23 ]
- ヌコモフモフシタイオ
- 84 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 02:42:32 ]
- M$が64bit版VC++でインラインアセンブラを止めたことに尾ヒレがついてそういう話になったんだろうが・・・
しかしまあ、64bitなCPUでもインラインアセンブラ使わにゃならんと言うのも、それはそれで哀しいものがあるな。
- 85 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 02:50:57 ]
- 64bitインラインアセンブラについて
ttp://www.codeproject.com/vista/vista_x64.asp#Inline_Assembly
代わりの構文が用意されているみたい
- 86 名前：デフォルトの名無しさん [2007/04/15(日) 10:48:47 ]
- シェーダもそうだ
Direct3D version10 では、アセンブリシェーダが一切許容されなくなった。
HLSLやGLSLよりも簡単かつ速いのに。
固定機能の廃止でシェーダで代用しろとか、
64bit用VCでアセンブラ使えないとか、マイクロソフトはどうなっているんだ。
そういうことをするから、「絶対必要なのに誰も知らないアセンブラ」になっていくんだ。
ウィルススキャンは、言ってみればリバースエンジニアリングだが、
リバースエンジニアリングにはアセンブラの知識が必要だ。
それでなくてもハード屋と密接に絡むソフト屋はアセンブラの知識が必要だ。
それなのにこれ以上マイナー言語にしてどうしたいと言うのか
- 87 名前：デフォルトの名無しさん mailto:sage [2007/04/15(日) 11:58:49 ]
- >>86
>>56
- 88 名前：デフォルトの名無しさん [2007/04/15(日) 12:37:52 ]
- 64bitだとAPIフックもできないの？
- 89 名前：デフォルトの名無しさん [2007/04/15(日) 22:46:32 ]
- >>88
できない ×
やらせない ○
- 90 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 10:28:26 ]
- >>85
紛らわしい事を言うな
代わりの構文でインラインアセンブラが利用可能なのかと思ったじゃないか
- 91 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 12:02:23 ]
- ＞代わりの構文でインラインアセンブラが利用可能なのかと思ったじゃないか
可能でしょ。
- 92 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 20:54:55 ]
- >>90の思考、__asm と 組み込み関数は違う
>>91の思考、__asm と 組み込み関数は同じ
- 93 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 22:00:57 ]
- > >>91の思考、__asm と 組み込み関数は同じ
このスレ的にはありえない思考回路だな...。
- 94 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 01:00:05 ]
- すみませんが、.NETのアプリをnasmとかで作れます？？
- 95 名前：デフォルトの名無しさん [2007/04/21(土) 01:08:21 ]
- 無理にきまってんだろ
- 96 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 01:10:52 ]
- >>94
つ ilasm
- 97 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 01:42:04 ]
- >>94
dbで直接書けばOK
- 98 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 01:49:51 ]
- >>94
＞nasmとか
といわれても。
アセンブリ言語で書けるか、ということならできる。
- 99 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 01:58:57 ]
- >>97
バイナリエディタのほうが絶対いいｗ
- 100 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 02:34:42 ]
- 相対アドレスを計算して入力するのが面倒だったのでmasm+exe2binでz80のプログラムを作ったことがあるな
- 101 名前：デフォルトの名無しさん [2007/04/22(日) 12:55:12 ]
- 質問でございます
いまいちよくつかめないんですが、メモリを確保する場合（文字列でも何でもいいです）、通常ヒープに確保され、
ローカル変数だけスタック、という認識であっていますか？
ちょっとスレ違いかもしれないんですが、このスレのエロい方々が一番詳しそうなので。
- 102 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 12:58:06 ]
- ものによる。
- 103 名前：デフォルトの名無しさん [2007/04/22(日) 13:01:10 ]
- おーっそこをなんとかお手数ですがｋｗｓｋお願いします＞＜
- 104 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 13:01:22 ]
- ものによるけど、普通の PC で普通の言語使ってるならそうな事が多いんでない？
- 105 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 13:22:10 ]
- >>101
*まず言語と質問の意図を教えれ*
このスレどおりアセンブラなら、何をどこにとろうが自由だ。
Cのグローバル変数に相当するものならヒープにとるだろうし
一時的な文字列領域ならスタックにとることもある。
まさに>>102の言うとおりだ。
- 106 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 14:08:29 ]
- アッー！！そうか、アセンブラだとpushすればスタックだし、heapallocをcallすればヒープか・・・
処理系はC++なんですが、コンパイラに依存ってことですね。
- 107 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 14:14:22 ]
- アセンブラから見れば、ヒープもスタックも、グローバル変数も、みんなメモリ
メモリの確保は静的にする場合と動的にする場合とがあるけど
動的に確保する場合の概念としてスタックだのﾋｰプだの発明したわけだ。
その２つしかないわけじゃなく、オーディオのフィルタ処理なんかはリング遅延器とか色々あるわけ
- 108 名前：デフォルトの名無しさん [2007/04/22(日) 15:05:10 ]
- なるほどねー。ちょっと微妙に納得いかないのは、
スタックはなぜEXEイメージのヘッダに最大サイズが定義されて、それ以上は制限されるのに
ヒープはメモリあるだけ確保できる。
これはデータ構造の用途を分けるためですか？
- 109 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 15:16:00 ]
- それはwindowsの話をしてるんだよね？
多くの環境で、データ・ﾋｰプは上（小さい方）から、スタックは下（大きい方から）取られる。
これなら、どっちかが制限されるのはおかしいという事だろ？
で、x86は仮想記憶をサポートしてるから、SSの領域も
上にどんどん確保してゆく事も理屈の上では可能。
でも、 windowsはスレッドを実装してるから、スタック領域が複数必要になる。
だから、スタックは最大サイズを決めておかないと、困った事になるわけだ
- 110 名前：・∀・）っ-○◎● mailto:sage [2007/04/22(日) 15:16:38 ]
- ヒープにも限界はあるよ。
スタックは連続したメモリを必要とする。
不連続なデータでいいなら、確保できる容量は多くなる罠。
最近のOSは仮想メモリ機構があるから、実メモリ容量以上、
スワップファイル分だけ確保できたりするんだが。。。
- 111 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 15:39:47 ]
- >>108
Windowsの話な。
アレは仮想メモリを使ってるから、プロセス毎（大雑把にいえばEXE毎）に
２GBのメモリ領域を割り当てられるわけだ。32bit Windowsのユーザー領域ね。
実際にメモリを２GB積んでるかどうかは関係ないぞ。
とにかく、EXE毎に２GBのメモリを積んでると思いねえ。
で、スタックというのは（再帰呼び出しでもしない限り）何MBも食うことはあまりない。
一方、ヒープは画像や映像などメモリバカ食いすることがあるので、２GBのうち
相当部分をヒープで管理しなくてはならない。
原始的なOSはスタックを制御してないので、
スタックを超えてもぐんぐんヒープ領域を侵していく。
その結果、理由の分からないバグに遭遇してしまう。
Windowsは、スタックを使い切ったらエラーを出す仕組みになってるので
EXEにその領域を書き込んでる。
で、なぜヒープじゃなくてスタックの方を制御するのかというと、
スタックは一回の取得−開放が直前のスタックと連続してるので管理しやすい。
ヒープは、気まぐれに領域をとり、気まぐれに開放されるので穴ぼこだらけになる。
と、スタックの方が管理しやすいからだと思いますよ。
- 112 名前：デフォルトの名無しさん [2007/04/22(日) 17:09:09 ]
- >>109-111
うおーありがとう＞＜
そうです、Windowsしか知らないので＞＜
スタックはＯＳ管理⇒プロセスを超えるスタックオーバーフロー検出のため
ヒープは制限がない(仮想メモリサイズ:x86なら2GB)⇒メモリに対し断片的にアロケートするため
（逆にスタックはその性質上連続したメモリ領域が必要なので、最初に固定サイズの連続領域を
確保するため、そのアロケートサイズをEXEヘッダに持っていなければいけないので制限される）
これが全ての理由ではないかもしれませんが、
上述の理由等でスタックとヒープのそれぞれの役割が決まっているわけですね。
そしてその決まりは処理系によって異なり、アセンブラの場合はむしろ人によって使い方が
異なる場合がある、という感じでしょうか。
かなり勉強になります！！
- 113 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 17:32:21 ]
- 試したことないからわからんが、もしかしたら64bitのVCでもインラインマクロアセンブラ(非MASM)使えるんじゃね？
ちなみに↓はx86用。
// インラインマクロアセンブラ？
// WINAPI*は環境に合わせて書き換えてね
typedef void (WINAPI* FUNCTION)();
#define ASM_CALL(function) {FUNCTION f=(FUNCTION)(void*)function;f();}
// 必要なのあれば追加
#define RET 0xc3
#define MOV_EAX(a) (char)0xb8,(char)(a&0xff),(char)((a>>8)&0xff),(char)((a>>16)&0xff),(char)((a>>24)&0xff)
// eaxに16入れるだけ
unsigned char function[] = {
MOV_EAX(16),
RET
};
// 呼び出してみる
ASM_CALL(function);
まぁ、ネタだけどな・・・
だれかx64用の命令セット定義してちょ ヽ(；´ー｀)ノ
- 114 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 17:34:11 ]
- まあC++Builderが出来るようになるだろ
ダメならDelphi for win64で書いて リンクするさ
- 115 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 17:49:52 ]
- >>112
制限しなければいけないもっとも重要な理由はスレッドのサポートにあると思うよ。
スレッド間でスタック領域も共用しなければいけないからね
- 116 名前：デフォルトの名無しさん mailto:sage [2007/04/22(日) 17:57:39 ]
- >>113
（ ﾟдﾟ）ノ ﾄﾞｿﾞｰ
ttp://homepage1.nifty.com/herumi/soft/xbyak.html
- 117 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 00:58:01 ]
- emit でただバイナリねじこんでるのと同じでは・・・
tc1の時代に逆戻り？
- 118 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 09:56:42 ]
- >>113>>116
データ実行で吹っ飛ばないのですか？
- 119 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 10:26:10 ]
- DSやSSにあるコード実行が禁止出来てるなら バッファオーバーランの脆弱性などだいぶ緩和できてたろう
- 120 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 10:54:44 ]
- 最近のCPUだとEXビットとか聞いたもので、どうなんでしょか
- 121 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 11:12:32 ]
- linuxの場合、mprotectで実行属性を与えるようになってる。
Windowsの場合も、VirtualAllocやVirtualProtectで実行権限与えればＯＫよ。
- 122 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 11:12:34 ]
- windowsは16bitの昔からダブルポインタを解決するためにthunkとよばれる
動的に小さいコードを作る技術を使ってきたからな。
当時はDLLでDSを渡す為に使われた。
32bitになっても、DelphiのVCLなんかでは WinProcからObjectとメソッドアドレスの２つを
作りだすために使われている。
- 123 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 11:16:57 ]
- 実行時にコード変更（生成）するのってマルチスレッドとかとの相性どうなんだろう
- 124 名前：デフォルトの名無しさん mailto:sage [2007/04/23(月) 11:22:30 ]
- >>123
そのコード空間がスレッドごとに独立していれば大して問題にならない。
|
 |
