1. ホーム
  2. 質問と答え
  3. 異なるCPUで異なる動作をするX64命令

異なるCPUで異なる動作をするX64命令

2016-11-15 13 views
3

インタビュー中に、使用されているCPUに応じて異なる動作をするx64命令があるかどうか尋ねられました。なぜこれが当てはまるのですか？異なるCPUで異なる動作をするX64命令

出典

2016-11-15 awpsoleet

+1

@PeterCordesこの質問への答えは、 "命令" と "CPU" の正確な定義に多くを依存しています。例えば、 'cpuid'は死んでいますが、P4では議論の余地があります。 –

+2

x86とx64プロセッサー・チップを焼く企業はあまりなく、AMDとIntelは唯一の生存者です。 x64はIntelによって後に採用されたAMDによって発明されました。 3DNowとMMXはアーキテクチャを拡張する方法に必ずしも同意しませんでした。彼らの間違いから学んだことで、彼らはユーザーランドコードで一緒に行動しました。しかし、プロテクトモードと仮想化は、OSが気にするもので、まだまだ異なっています。はい、あなたは簡単にcpuidに答えることができました:) –

+0

MMXは、x86-64がSSEとSSE2を必要とし、MMEレジスタで動作するいくつかのSSE命令が必要なので、x86-64の必須ベースライン部分だと思います。だから我々はCPUが基本的にそれを永遠にサポートし続けると期待できますが、Skylake上でさえMMXバージョンの命令の中にはXMM相当のものよりスループットが低いものもあります。将来のCPUでのMMXサポートは、さらに刻々と変化し、マイクロコード化されたものになる可能性があります。 （3DNowは、すでに死んでおり、AMDの新しいCPUを含むほとんどのCPUで完全にサポートされていません） –

答えて

5

leave a register or some flags with undefined valuesがあります。 IntelとAMDは異なる場合があります。

これらの未定義のケースでの実際のハードウェアの実際の動作によっては、それに依存する古いソフトウェアの下位互換性が保持されることがあります。たとえば、入力= 0のBSFは、ZFを設定し、インテルのマニュアルに従って宛先レジスタに未定義の内容を残します。しかし、AMDのマニュアル（および実際のIntel + AMDハードウェア）は、その場合に宛先を変更しないままにしています。 （bsf/bsrに出力依存関係があるのはなぜですか？

パフォーマンスの差がある場合は、多数あります（タグwikiのリンクを参照してください）！

あなたはサポートされていない手順について話しているだけではありませんか？ LAHF/SAHFのように、いくつかの非常に初期のx86-64 CPUではロングモードでサポートされていませんか？また、CMPXCHG16Bも初期のK8ではサポートされていません。

サポートされていない命令の最も興味深いケースは、LZCNTが、それをサポートしていないCPUでREP BSRとしてデコードすることです。非ゼロ入力の場合でも、逆の結果を返します。 （_tzcnt_u32(x) == 31-bsr(x)）。 TZCNTはそれをサポートしていないCPU上でREP BSFと同様にデコードしますが、入力= 0以外は同じことをします。は同じマシンコードを別々に実行しているため、同じ命令を別の方法で実行している場合は、となりますが、これはあなたが求めているようなものです。

特権のない命令についてのみ話していますか？おそらく、特権命令の動作にはさらに多くの違いがあります。たとえば、インテルとAMDの両方で、SYSRETのバグがLinux has to work aroundであると、悪意のあるユーザー空間がカーネルをハングアップさせないようにすることができます。

私はわからないんだけどカウント別のケース：PREFETCHW NOPとしてハスウェル少なくともCore2のからインテルのCPU上で実行されますが、AMDのCPU（とBroadwellマイクロアーキテクチャ以来インテル）にas an actual prefetchに。

CPUによってはNOPとして実行されるものもあれば、不正なinsnとして故障する古代のCPUを除いて、プリフェッチとして実行するものもあります（構造的に見える効果はありません）。 64ビットWindows8.1 apparently requires that PREFETCHW can run without faulting（64ビットPentium4 CPUで実行されないようにする）

出典

2016-11-16 00:12:57

+2

明白な 'cpuid'以外に' tzcnt'を 'rep bsf'と' lzcnt'として実行することができます'f3 0f bc/r'の' f3'がそれらのCPU上で 'rep'と解釈され、アーキテクチャ的に異なるように動作するため、' rep bsr'をCPUで実行します。それらはx64の_architecturally-different_ behaviorについて私が知っている3つのインスタンスです。 'xacquire/xrelease'HLEプレフィックスのための' f2/f3'のco-optingは、間違いなくカウントされます。 –

+0

私はこれが彼が指している指示の一種だと思っています。私たちはDRMについて議論していました。特定のCPUモデルでしか実行できないコードを、アンパックされたバイナリの共有を防ぐ1つの方法です。 – awpsoleet

+1

'bsf' /' bsr'について、AMDは、入力がゼロの場合、すなわち実際のIntelの動作に合わせてレジスタが変更されていないことを実際に記録しているようです。少なくとも[このソース]（https://chessprogramming.wikispaces.com/BitScan#Processor%20Instructions%20for%20Bitscans-x86-Bsf/Bsr%20behavior%20with%20zero%20source）によると、 – BeeOnRope

3

は、IntelとAMD

  • ソースがゼロで、オペランドサイズが32ビットである場合には、Intelの64のBSFとBSR命令はAMD64のとは異なる行動との違いがたくさんあります。プロセッサはゼロフラグをセットし、デスティネーションの上位32ビットを未定義のままにします。
  • Intel 64には、AMD64でアーキテクチャーと見なされるものがあるMSRが欠けています。これらは、SYSCFG,TOP_MEMおよびTOP_MEM2を含む。
  • Intel 64では、互換モードではない64ビットモードでのみSYSCALL/SYSRETを許可し、両方のモードでSYSENTER/SYSEXITを許可します。[34] AMD64は、ロングモードの両方のサブモードでSYSENTER/SYSEXITが欠けています。[35]
  • 64ビットモードでは、66H（オペランドサイズオーバーライド）プレフィックスを持つブランチの近くで動作が異なります。インテル64では、この接頭辞は無視されます。命令には32ビット符号拡張オフセットがあり、命令ポインタは切り捨てられません。 AMD64は命令の16ビットオフセットフィールドを使用し、命令ポインタの上位48ビットをクリアします。
  • AMDプロセッサは浮動小数点数を発生させます。Intelプロセッサではない間に、80ビットシグナリングNaNのFLDまたはFSTPを実行すると、無効な例外が発生します。
  • SYSRETを使用して非正規アドレスに戻るとき、AMD64プロセッサは特権レベル3で一般保護違反ハンドラを実行し、Intel 64プロセッサでは特権レベル0で実行されます。[38] [39]

https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

出典

2016-11-16 02:59:29

関連する問題

 関連する問題