問題タブ [intel]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
assembly - 「pushl 2000」を AT&T asm から i386 の Intel 構文に変換する方法
以下を AT&T アセンブリから Intel アセンブリに変換しようとしています。
これは次のようにコンパイルされます。
しかし、私が何をしようとしても、Intel Synax で同じ結果を得ることができません。私は試しました:
だから私は手がかりがありません.「プッシュ2000」に相当するものは何ですか?
assembly - AT&T 構文を使用する完全な x86 アセンブリ言語リファレンスはありますか?
理想的には、AT&T 構文で書かれた Intel のSoftware Developer's Manualsのバージョンがあればよいのですが、十分に近いものを見つけることができれば幸いです。
compiler-construction - Intelコンパイラによって書かれたリマーク「LOOP WAS VECTORIZED」を無効にする方法は?
Intelコンパイラで書かれた「LOOP WAS VECTORIZED」というリマークを無効にしたい。しかし、最適化を無効にしたくありません。私は何をする必要がありますか?
syntax - gnu アセンブラ: ラベル/変数のアドレスを取得 [INTEL SYNTAX]
私はこのようなコードを持っています:
次に、woof のアドレスを eax に移動したいと思います。それを行うためのインテルの構文コードは何ですか? bleh のアドレスを ebx などに移動する場合も同様です。
あなたの助けは大歓迎です!
assembly - 「意図された目的」のために Intel レジスタを使用すると、効率が向上しますか?
この記事では、各レジスタには意図された目的があり、さらに重要なことに、
Intel のエンジニアがオリジナルの 8086 プロセッサを設計したとき、各レジスタには特別な目的がありました。彼らは命令セットを設計する際に、各レジスタが実行すると予想される機能に基づいて、多くの最適化と特別な命令を作成しました。インテルの当初の計画に従ってレジスターを使用すると、コードはこれらの最適化を最大限に活用できます。残念ながら、これは失われた芸術のようです。インテルの全体的な設計を認識しているコーダーはほとんどなく、ほとんどのコンパイラーは単純すぎたり、実行速度に重点を置いたりして、レジスターを適切に使用できません。ただし、レジスターと命令セットがどのように適合するかを理解することは、簡単なサイズコーディングへの道のりにおける重要なステップです。
この記事を裏付ける他の情報源はありますか? もしそうなら、私は本当にそれをチェックしたいです。
STOS
使用のような高速な操作edi
が使用eax
される状況について話しているのではないことに注意してesi
くださいecx
。
optimization - 最適化 , コンパイラとその効果
(i) プログラムが1 つの CPU クラス (例: マルチコア Core i7) でコードをコンパイルすることによって最適化されている場合、そのパフォーマンスは古い世代の他の CPU (例: Pentium 4) では最適以下のレベルになります。 .. 最適化すると、他の CPU のパフォーマンスに悪影響を与える可能性があります..?
(ii) 最適化のために、コンパイラは古い CPU では利用できない x86 拡張機能 (SSE 4 など) を使用する場合があります..それで、古い CPU の一部の非拡張ベースのルーチンへのフォールバックはありますか..?
(iii) インテル C++ コンパイラーは、Visual C++ コンパイラーまたは GCC よりも最適化されていますか..
(iv) 真にマルチコア スレッド化されたアプリケーションは、古い CPU (Pentium III または 4 など) 上で効率的に実行されますか?
assembly - Intelプロセッサのダミー操作処理
確かに、ちょっとばかげた質問があります。基本的に、一連のダミー、つまり NOP 命令を効率的に実行するために Intel プロセッサによって提供される特別なメカニズムがあるかどうか疑問に思っています。たとえば、NOPS を識別して破棄し、代わりに有用な命令をフェッチしようとする、ある種のプリフェッチ メカニズムがあると想像できます。または、これらの NOPS は通常の命令として実行ユニットにディスパッチされます。つまり、各サイクルで大まかに 5 つの nop を処理できます (5 つの実行ユニットがあると仮定して)
ありがとう、ラインハルト
linux - パフォーマンス評価中の外れ値
Intel の RDTSC を使用していくつかのパフォーマンス測定を試みていますが、さまざまなテスト実行中に得られる変動は非常に奇妙です。ほとんどの場合、C での私のベンチマークには 3000000 Mio サイクルが必要ですが、まったく同じ実行でも、場合によっては 5000000 とほぼ 2 倍かかることがあります。適切なパフォーマンスの見積もりが得られるように、負荷の高いワークロードを並行して実行しないようにしました。この巨大なタイミングの変動がどこから来るのか誰にも分かりませんか? 割り込みなどが発生する可能性があることは知っていますが、タイミングがこれほど大きく変動するとは思っていませんでした。
PS .: Linux を実行している Pentium プロセッサで実行しています。
フィードバックありがとう、ジョン
c# - C#を使用して、プログラムが実行されているコンピューターのチップセットを特定するにはどうすればよいですか。
コードを実行しているコンピューターのチップセットに応じて、コードの動作を変える必要があります。C#を使用してこれを判断するにはどうすればよいですか。
具体的には、Intel945と965です。
floating-point - powerpc を intel に移植する数値コードは、float を使用して異なる結果をもたらす
私の本質的な問題は、クラシック MacOS (CodeWarrior) から Windows (VS 2008) に移行して、x86 で浮動小数点演算を PowerPC のように動作させる方法です。
問題のコードには、非常に反復的で数値的に非常に敏感なアルゴリズムが山積みされています。
典型的な複雑な行は次のとおりです。
float
基本型としてtypedef を使用して記述されます。
に変更するdouble
と、両方のプラットフォームで非常に似た結果が得られますが、残念ながら数値が受け入れられないため、簡単に解決することはできません。
Mac コードは CodeWarrior を使用してコンパイルされており、FMADD および FMSUB 命令の生成をオフにするだけで、作成される数値に劇的な影響がありました。したがって、私の出発点は、最も類似していると思われる Visual Studio (2008) オプションを検索することでした - 融合追加が使用されていることを確認しました。その鍵は、計算で中間ストレージを割り当てる際のコンパイラの動作にあると思われます
現在、SSE2 と を有効にする組み合わせで最良の結果が得られてい/fp:fast
ます。組み込み関数を有効にすると、値が Mac の値からさらにずれます。
/fpスイッチのドキュメントには/fp:strict
、融合された追加動作のみがオフになると記載されています。
MSDNでは、FP10.OBJ を「LIBC.LIB、LIBCMT.LIB、または MSVCRT.LIB の前に」リンクすることについて説明しています。64 ビットの精度を保証します。リンカの入力フィールドに FP10.OBJ を指定することで、これを達成したようです (詳細なリンカの出力は、MSVCRTD.lib の前にそれを示しています)。
また、呼び出して64ビット精度を設定しました
DllMain で。
この問題は、プラットフォーム間の浮動小数点例外処理の違いによるものでも、PowerPC がゼロ整数による除算 (ゼロを返すだけ) を許可する (楽しい) 方法によるものでもないことに注意してください。 PCリント。プログラムが実行され、ある程度妥当な出力が生成されますが、十分ではありません。
アップデート:
友人からの興味深いコメント: 1 つの可能性として、PPC には 64 ビットの中間値を格納できる一時レジスタが多数あるのに対し、x86 コードでは FPU のアンロードと再ロードが必要になる場合があります (4 バイトに切り捨てられ、精度が失われます)。
これが、(IIRC)より多くのレジスタと中間値を保持するためのより多くの範囲があるため、SSE2がよりうまく機能する理由かもしれません。
1 つの可能性 - コードを 64 ビットとしてコンパイルできますか? x64 モードには、中間体用のレジスタが多く、FP 命令が優れているため、設計と実行において PPC に近い可能性があります。
彼が示唆したように、64 ビット ビルドでの最初のテストは、実際にはもっと近くなりました (最初はやり過ぎだと思っていましたが、それは不適切なモデリング設定が原因でした)。
最終決議
このトピックに興味を持っている人は、最終的にどのようにすべてがうまくいったかを知りたいと思うほど強迫観念を持っていると確信しています. ソフトウェアが完成し、一貫した数値結果が得られます。すべてのアルゴリズムで Mac に同じ結果を提供することはできませんでしたが、統計的に許容できるほど十分に近いものでした。専門家のユーザーが関心のある領域を選択することによって処理が導かれ、ユーザーの入力がモデルの進行状況に部分的に反応することを考えると、主任科学者はそれが受け入れられると判断しました (これは一晩で決定されたわけではありません!)。残りの数値の違いは、さまざまな臨床結果を決定するものの範囲内にあるため、テストではさまざまな診断が見られません.