アカウント名:
パスワード:
インラインアセンブラは、本当に重要なところだけをアセンブリ言語化できるという利点があるだけに、この変更も少し残念です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
無知な私におせーて！ (スコア:1, 興味深い)
Re:無知な私におせーて！ (スコア:1, 参考になる)
レジスタのやりくりロスが減るんじゃないかと。
(もちろんCPU内部にはより多くの物理レジスタがあってレジスタ
リネームされてるんでしょうけど)
インラインアセンブラも廃止 (スコア:2, 参考になる)
なので、ゲームなどでインラインアセンブラで最適化されたコードブロックが多数ある場合、64bit化にかなりの作業量が必要になるでしょうし、最適化を断念せざるを得ない場合もあるのではないでしょうか。
インラインアセンブラは、本当に重要なところだけをアセンブリ言語化できるという利点があるだけに、この変更も少し残念です。
Re:インラインアセンブラも廃止 (スコア:3, 参考になる)
Optimizing Inline Assembly [microsoft.com]
x86命令の所要クロック計測スレ [2ch.net]
インラインアセンブラで最適化されたコードブロックが多数ある場合、64bit化にかなりの作業量が必要になるというのは一理あるかもしれません。しかし SSE/SSE2 を多用するようなコードの場合、インラインアセンブラと組み込み関数のパフォーマンス面での比較はきちんと行う必要があるかと思います。
Re:インラインアセンブラも廃止 (スコア:2, 参考になる)
結局、インラインアセンブラのコードブロックが何をしているのかがコンパイラ側には判らない、というのが最適化の邪魔になる理由なのでしょう。その点で、gcc のインラインアセンブラは良くできてると思います。データの受け渡し方やコードブロックで使用するレジスタをコンパイラに通知できて、最適化への影響も少ない。難点は、あの構文だとどうしてもメンテナンス性の悪いソースコードになってしまうことか。
Re:インラインアセンブラも廃止 (スコア:1)
実際 インライン分も含めて最適化する C/C++ コンパイラもありますので、
Microsoft がやってやれないことはないです。
最適化に関してはインラインアセンブラがレジスタを決めうちで使ってしまうため、
レジスタ最適化への悪影響が大きいのが×なんだと私は考えます。
コンタミは発見の母
Re:インラインアセンブラも廃止 (スコア:1)
つか、スタートアップの部分やレジスタが動かない命令のインラインアセンブラは例外にするとして、スタックにレジスタをセーブしないインラインアセンブラの仕様というのはコンパイラがアセンブラコードを解釈して最適化で高級言語のコードと融合させる場合ならともかく、危険過ぎて信じられないのですが…
# gccに何故 __asm__ と __asm__ volatileがあるのか。とか…