アカウント名:
パスワード:
どのCPUだったかなぁ。同じレジスタに値を代入するコードになってるのは。
下手になんかするとflagが変わる可能性がある。
似たような話では、8086が命令構成ではXCHG AX,AXだったはず(AXレジスタとAXレジスタの交換)
これのおかげでx64命令が酷いことになってんですよね。XCHG AX,AXを表す命令コードは32bit/64bitモードではXCHG EAX,EAXになって、32bitではこれで問題ないんですが、64bitモードだとEAXへ書き込みを行うとRAX(64bit拡張されたEAX)の上位32bitをクリアする仕様になっていて、NOPでこれが適用されるとRAXの値が破壊されてしまう。そのため、XCHG EAX,EAX「だけ」特別扱いしてレジスタ破壊が起きないようになってるのでした。
結果からするとその通りですが、説明としては、XCHG EAX,EAXだけ特別扱いしているというより、90hは「XCHG EAX,EAX」ではなく「NOP」に割り当てられている、という言うべきじゃないですかね。
無駄なレジスタへの書き戻しは行わないし、EAXレジスタ依存判定もしないようにしてるので、前後のEAXを使うコードに対してアウトオブオーダー入れ替え可能だし高速に実行できるようになってます。
それはCPUがアウトオブオーダー実行やレジスタリネーミングなどを行うようになってからの後付けの理屈で、8086の時代はXCHG AX,AXが何もしないからという理由でNOPに選ばれたのでしょ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
LD A,A (スコア:2)
どのCPUだったかなぁ。
同じレジスタに値を代入するコードになってるのは。
下手になんかするとflagが変わる可能性がある。
Re:LD A,A (スコア:0)
似たような話では、8086が命令構成ではXCHG AX,AXだったはず(AXレジスタとAXレジスタの交換)
Re: (スコア:0)
これのおかげでx64命令が酷いことになってんですよね。
XCHG AX,AXを表す命令コードは32bit/64bitモードではXCHG EAX,EAXになって、32bitではこれで問題ないんですが、64bitモードだとEAXへ書き込みを行うとRAX(64bit拡張されたEAX)の上位32bitをクリアする仕様になっていて、NOPでこれが適用されるとRAXの値が破壊されてしまう。そのため、XCHG EAX,EAX「だけ」特別扱いしてレジスタ破壊が起きないようになってるのでした。
Re: (スコア:0)
結果からするとその通りですが、説明としては、XCHG EAX,EAXだけ特別扱いしているというより、90hは「XCHG EAX,EAX」ではなく「NOP」に割り当てられている、という言うべきじゃないですかね。
無駄なレジスタへの書き戻しは行わないし、
EAXレジスタ依存判定もしないようにしてるので、
前後のEAXを使うコードに対してアウトオブオーダー入れ替え可能だし高速に実行できるようになってます。
Re: (スコア:0)
それはCPUがアウトオブオーダー実行やレジスタリネーミングなどを行うようになってからの後付けの理屈で、8086の時代はXCHG AX,AXが何もしないからという理由でNOPに選ばれたのでしょ。