トップページ > プログラム > 2015年07月20日 > AMStoo45

書き込み順位&時間帯一覧

8 位/225 ID中時間01234567891011121314151617181920212223Total
書き込み数35100000000010000000000010



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
アセンブラ初心者スレッド

書き込みレス一覧

アセンブラ初心者スレッド
773 :デフォルトの名無しさん[sage]:2015/07/20(月) 00:20:33.85 ID:AMStoo45
自分に都合の悪い所はスルーか
それは置いといて、理解してないっていうなら聞くけど、この関数のどこに「EIPを取るためにCALLは事実上必須の技術要素」
のcallがあんの?
アセンブラ初心者スレッド
776 :デフォルトの名無しさん[sage]:2015/07/20(月) 00:38:26.64 ID:AMStoo45
>>771で指摘した点には反論しないのねw
>>739ではやらかしたと思ったんでしょw
アセンブラ初心者スレッド
781 :デフォルトの名無しさん[sage]:2015/07/20(月) 00:54:38.35 ID:AMStoo45
>JITコンパイラ済みコードからCライブラリを呼び出す場合、Cライブラリ内で発生する例外に備えて、
>Cライブラリ呼び出しの前にsetjumpを行わなければならない。
これはRubyからCのライブラリの関数を呼び出せるようにしたための制限だろ
Cとリンクして動かさなければ関係ないはずだし、そう書いてあると思うのだが
これが「事実上」なの?
アセンブラ初心者スレッド
784 :デフォルトの名無しさん[sage]:2015/07/20(月) 01:00:27.57 ID:AMStoo45
>>780
ネイティブでないforkを持ち出しても意味ないの
Cygwin使ったことある?
forkのエミュレーションが遅くて昔から問題視されてるよ
レベルが低すぎるってんなら>>771のプロセス/スレッドのとこ個別に反論してみてよ
アセンブラ初心者スレッド
785 :デフォルトの名無しさん[sage]:2015/07/20(月) 01:01:29.77 ID:AMStoo45
あんた、いつも後出しで特定環境のこと持ち出したりするね
アセンブラ初心者スレッド
786 :デフォルトの名無しさん[sage]:2015/07/20(月) 01:05:50.67 ID:AMStoo45
>>782
JIT開発経験が無いとか噛みついてきたからさ
そして、団子は「それじゃ例外処理を実装できない」と言ったんだよ
アセンブラ初心者スレッド
787 :デフォルトの名無しさん[sage]:2015/07/20(月) 01:05:56.20 ID:AMStoo45
>>782
JIT開発経験が無いとか噛みついてきたからさ
そして、団子は「それじゃ例外処理を実装できない」と言ったんだよ
アセンブラ初心者スレッド
789 :デフォルトの名無しさん[sage]:2015/07/20(月) 01:11:00.75 ID:AMStoo45
>>771を否定できないと団子の立場が無いって言ってんのに
アセンブラ初心者スレッド
795 :デフォルトの名無しさん[sage]:2015/07/20(月) 02:12:40.06 ID:AMStoo45
>>722で誰かがアセンブラが戻りアドレスを把握してるって指摘したら
団子がつまらない自尊心の為に関係ないプロセス/スレッドの話まで持ち出してきて
それが相手を罵倒できるようなレベルの内容じゃなかったでしょ
その後も誰かが何か書くたびに「化石には理解できんでしょうよ」とか絡みついて見苦しいことしてるくせにな

JITはアセンブラも含むんだから、そこで例外を実現するにはOSの例外処理機構に
マッチしてればいいだけなのに「それじゃ例外処理を実装できない」と絡んできたんだろうが
こっちもrubyのような環境を想定してなかったのは確かだが、例外処理はハンドラによって変わるの理解してる?
C++でCライブラリを呼び出したらsetjumpなんてしてると思ってんの?
アセンブラ初心者スレッド
799 :デフォルトの名無しさん[sage]:2015/07/20(月) 12:17:45.00 ID:AMStoo45
>しかしながら、CRubyインタプリタにおける例外処理の実装は、コンパイル済みコードで発生した
>例外の受け渡しを前提に設計されたものではなく、CRubyインタプリタに合わせた単純な実装では、
>効率的な処理を行う実装することが難しい。
CRubyのライブラリがsignal使って例外処理を実装してるのがいけないってことだろ
こいつのせいでJITの例外処理では完結できなくなったのが原因じゃないか
JITのランタイム環境はフローの基本ブロックのアドレス程度は管理してるはずなので
Rubyのような問題のある特定環境じゃなきゃsetjump(のコール)を使用しなくても動作させるのは可能なはずだよな

>どのみちEIPとESPの保存はJITでの例外処理の実装に最低限必要なんだけどね
「例外が発生したアドレス」やレジスタの内容はOSがお膳立てして保存してあるだろ
callは「呼び出した命令の次の命令のアドレス」を保存するんだぞ
例外ハンドラに処理が移った時点でJIT環境の管理するアドレス情報で処理するのは可能だろ
回復に必要な経路の情報は既にスタックフレームに入ってんの
だから「CPUが例外を実装するのにCALLは事実上必須の技術要素」というのなら理解できると書いたんだけど
団子は例外処理に関する知識も微妙だな
本当に本人?

知識自慢ってよりね、>>718のcall/retは内部で別の命令で処理されてるの?って疑問に対して
限定的に似た動作をさせることは不可能じゃないってことだったのに
団子が火病ってリロケータブルはまあいいとしても、JITだのDLLやスレッド/プロセスのことを持ち出して
スレタイとは異なる話を展開をさせたんだよ
その知識が変じゃないかってこと
そして自分が言い負かされそうになるとスレタイのことを言い出したw


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。