インラインアセンブリ

返信する


答えを正確に入力してください。答えられるかどうかでスパムボットか否かを判定します。
BBCode: ON
[img]: ON
[flash]: OFF
[url]: ON
スマイリー: OFF
トピックのレビュー
   

展開ビュー トピックのレビュー: インラインアセンブリ

by 夕 » 2007年3月04日(日) 13:54

konisiさん、takさん、ありがとうございます。
関数ポインタを使って機械語の呼び出しを行うとジャンプと復帰の手間がかかるということですか。
確かに高速化を目指すのには不向きですね。アセンブリや機械語を直接記述しないとできない処理をするときには使えそうです。
一番よいのは直接プログラム中に埋め込めることなんですが・・・。

by konisi » 2007年3月04日(日) 12:36

やっぱりオペラントを書いた方が良かったんですね、すみませんでした。

ところで僕は、割と適当にオペコードを覚えています。

40番台前半がinc、後半がdec
50番台前半がpush、後半がpop
70番台はjxx(条件付ジャンプ)
C2とC3、CAとCBがret

by tak » 2007年3月04日(日) 01:46

少し補足します。

この方法では、何らかの方法でメモリ領域を確保し、そこに機械語列を格納します。
したがってインラインアセンブラのようにプログラムの任意の位置に機械語列を埋め込めるわけではありません。
自分で書いた機械語を実行するためには、そのメモリ領域へ明示的にジャンプする必要があります。
オリジナル機械語列が任務を完遂したら、今度は処理を本流（ジャンプ元）に戻すこともしなければなりません。

これって結局、単なるプロシージャ呼び出しのことですよね。

アセンブラや生の機械語列を使ってまで強力に高速化したいということは、オリジナル機械語列に突入するジャンプと復帰の手間すら惜しいような場面なのでしょう。
それを考えると、ジャンプ必須となってしまうこの方法を使う気はしません。


ちなみに、Pentiumで言う C3 と C2 は ret(near), CB は ret(far) のことですね…
オペコードを覚えているわけではないので、調べるのが少々面倒でした。

by konisi » 2007年3月03日(土) 14:43

Pentiumで言う、最後の方にC3やCB、C2 xx xxのあるコードの事だと思うんですが。

関数形式、とでも言い換えましょうか？

by 夕 » 2007年3月02日(金) 23:22

返信がずいぶんと遅れてしまってすみません。
質問ですが、提示していただいたトピックに書かれていた
プロシージャ形式のマシン語とは何のことでしょうか。

by tak » 2007年1月22日(月) 00:14

> 私は、インラインアセンブリに対応するよりは、寧ろ機械語を埋め込めるようにしてほしいです。

それは可能です。下記のトピックで検討されています。
マシン語を走らせる

要約すると、機械語の命令列を Byte 型の配列として用意しておき、関数ポインタ呼び出しを通じて配列のアドレスへジャンプすることによってこれを実現します。

by 夕 » 2007年1月21日(日) 23:28

私は、インラインアセンブリに対応するよりは、寧ろ機械語を埋め込めるようにしてほしいです。
ABが動くCPU全てのアセンブリ言語の命令に対応するのは難しいため、インラインアセンブリを実装しても、
対応できなかった命令を使いたいと思ったときには、ユーザーは対応を待つしかないので、
それなら機械語を埋め込めれば、と思ったわけです。

by Lbey » 2007年1月20日(土) 21:44

プログラム中にどうしてもアセンブリで書く必要がある部分があり、
それ以外にもアセンブリで書きたい部分があります。
是非、インライン アセンブラの実装をお願いします。

by イグトランス » 2006年11月27日(月) 23:53

殆ど全ての場合では，そのようにプリプロセッサで分けることになると思っています。

> 32bitのexeファイルって、確か64bit環境でも動かせましたよね？
たしかに動かせますけど，
64ビットの恩恵を享受できないのはもったいないとは思いませんかということです。

by konisi » 2006年11月27日(月) 21:39

おっと、自動ログインが切れてること忘れてた。
上のゲスト=konisiです。

追記

どっち道低水準言語を使うということは機種に依存するコードを書くということに相当するので、64bit⇔32bit間の不具合は、後回しにできることかと思います。

32bitのexeファイルって、確か64bit環境でも動かせましたよね？

by ゲスト » 2006年11月27日(月) 21:33

32bitのアセンブリコードは64bitでも殆どが動くと思いますが・・・

考えてみれば、rax(64bitアキュム)とかは32bitではコンパイルできないですよね・・・。

#ifdef _WIN32

とかで振り分けても別にいいのだけれども、はたして64bitアセンブリで最適化されたコードを32bitアセンブリに移植できる人がどれだけ居るか・・・？

32bitアセンブリでまず最適化しておいて、64bitでもっと速く出来るならそっちを追加で書く　というスタイルが必要になりそうです。

あと2～3年は時間がありそうなのでゆっくり勉強しますが。

by イグトランス » 2006年11月27日(月) 00:32

ふと思ったのですが，ABには64ビット版も存在する以上，インラインアセンブラを導入したら，
それを使うときには当たり前のことですが，32ビット・64ビット両方でアセンブリのコードを書くことになります。

ライブラリの中なら別に構いませんが，気軽にインラインアセンブラを使い，しかも32ビットのコードしか書かなかったので，
64ビットコンパイルはできませんというプログラムを書かれたら，もったいないことになるなあと思いました。

by イグトランス » 2006年10月29日(日) 13:06

インラインアセンブラは定期的に出てくる話題です。
http://www.activebasic.com/forum/viewtopic.php?t=98
私は今もそこに述べたとおり否定的に思っていますが，（投票も要らないに投じました）
これだけ要望が出てくるならいっそ導入すべきなのかもしれません。

（以下アセンブリ言語を使わない人間の戯言です）
ところでアセンブリ言語を使うならMMXやSSEなどといったSIMD命令を使うのも醍醐味の1つなのではないでしょうか？
特権命令を使用できてもかまわないというのは現実的ですが。

by OverTaker » 2006年10月29日(日) 12:56

ABの長所はフリーで、実行ファイルが小さめで、尚且つ動作が速いところ　ということになっていますが、シェアウェアのPureBasicに、実行ファイルの小ささ及び動作速度において負けています。
今のActiveBasicは生産性がよくないので、速度や実行ファイルの大きさよりも、そちらを先にどうにかしたいと思っています。搭載されることに超したことはないのですが、現段階では、他のことに手を尽くしてほしいです。
ということから、「要らない」に一票投じました。

ぜひほしい

by たかせ » 2006年10月29日(日) 12:46

高瀬です。
ぜひほしいの一言です。

これでＣに劣らない言語に近づいていくでしょう

ページトップ