Rust: `asm`（インラインアセンブリ）の追跡の問題

安定したコードでインラインアセンブリの下位互換性を確保するのに問題はありますか？

@ main-- https://github.com/rust-lang/rfcs/pull/1471#issuecomment -173982852に、後世のためにここで再現している素晴らしいコメントがあり

asmを取り巻くすべての未解決のバグと不安定性（） （たくさんあります）があるので、Rustで安定したインラインasmが欲しいのに、安定化の準備ができているとは本当に思いません。

また、今日のasm！（）が本当に最良の解決策であるかどうか、またはRFC ＃129またはDに沿ったものがより良いかどうかについても議論する必要があります。 ここで考慮すべき重要な点の1つは、asm（）がgccと同じ一連の制約をサポートしていないことです。 したがって、次のいずれかを実行できます。

• LLVMの動作に固執し、そのためのドキュメントを作成します（何も見つからなかったため）。 rustcの複雑さを回避できるので便利です。 C / C ++から来るプログラマーを混乱させ、いくつかの制約をRustコードでエミュレートするのが難しいかもしれないので悪いです。
• gccをエミュレートし、ドキュメントにリンクするだけです。多くのプログラマーはすでにこれを知っており、わずかな変更を加えてコピーアンドペーストできる例がたくさんあるので、すばらしいです。 コンパイラの重要な拡張機能であるため、問題があります。
• 他のことをする（Dのように）：報われるかもしれないし、報われないかもしれない多くの仕事。 正しく行われれば、これは人間工学の点でgccスタイルよりもはるかに優れている可能性がありますが、不透明なブロブよりも言語やコンパイラーとうまく統合できる可能性があります（これを評価するためのコンパイラーの内部に精通していないため、ここでは多くの手振りが行われます） 。

最後に、考慮すべきもう1つのことは＃1201です。これは、現在の設計では（私が思うに）インラインasmに大きく依存しています。つまり、インラインasmは正しく実行されています。

個人的には、MicrosoftがMSVC x64で行ったことを実行する方がよいと思います。つまり、asm命令ごとに（ほぼ）包括的な組み込み関数のセットを定義し、それらの組み込み関数のみを使用して「インラインasm」を実行します。 そうしないと、インラインasmを取り巻くコードを最適化することが非常に困難になります。これは、インラインasmの多くの用途がパフォーマンスの最適化を目的としているため、皮肉なことです。

インストリンシックベースのアプローチの利点の1つは、オールオアナッシングである必要がないことです。 最初に最も必要な組み込み関数を定義し、段階的に設定を構築できます。 たとえば、暗号の場合、 _addcarry_u64 、 _addcarry_u32ます。 インストリンシクスを実行するための作業は、すでにかなり徹底的に行われているように見えることに注意してください： //github.com/huonw/llvmint。

さらに、組み込み関数は（CおよびC ++での使用経験に基づいて）はるかに使いやすいため、最終的にインラインasmをサポートすることが決定された場合でも、組み込み関数を追加することをお勧めします。私たちがどこまで到達するかは、間違いのリスクがゼロのように思えます。

組み込み関数は優れていますが、 asm!は、命令を挿入するだけではありません。
たとえば、 probeクレートでELFノートを生成する方法を確認してください。
https://github.com/cuviper/rust-libprobe/blob/master/src/platform/systemtap.rs

この種のハッカーはめったにないと思いますが、それでもサポートするのは便利だと思います。

@briansmith

インラインasmは、独自のレジスタ/スタック割り当てを実行したいコード（裸の関数など）にも役立ちます。

@briansmithええ、これらは可能な限り組み込み関数を使用するいくつかの優れた理由です。 しかし、究極のエクサペハッチとしてインラインアセンブリがあるのは素晴らしいことです。

@briansmith asm!()は、前者を使用して後者を構築できるため、組み込み関数のスーパーセットであることに注意してください。 （この推論に対する一般的な議論は、コンパイラが理論的に_through_組み込み関数を最適化できるということです。たとえば、ループからそれらを引き上げたり、CSEを実行したりできます。ただし、_optimization_の目的でasmを作成する人は、より良い仕事をするというかなり強力な対位法です。とにかくコンパイラよりも。） https://github.com/rust-lang/rust/issues/29722#issuecomment -207628164およびhttps://github.com/rust-lang/rust/issues/29722#も参照してください。

一方、組み込み関数は、「十分にスマートなコンパイラ」に大きく依存して、手動でロールされたasm実装で得られるパフォーマンスを_少なくとも_達成します。 これに関する私の知識は時代遅れですが、大きな進歩がない限り、組み込み関数ベースの実装は、ほとんどではないにしても、多くの場合、まだかなり劣っています。 もちろん、それらははるかに使いやすいですが、プログラマーは、特定のCPU命令の世界に進んでいくときは、実際にはそれほど気にしません。

ここで、もう1つの興味深い考慮事項は、組み込み関数が、サポートされていないアーキテクチャーのフォールバックコードと結合される可能性があることです。 これにより、両方の長所が得られます。コードは引き続き移植可能です。ハードウェアがサポートする場合は、ハードウェアアクセラレーションによる操作を使用できます。 もちろん、これは非常に一般的な命令、またはアプリケーションに1つの明らかなターゲットアーキテクチャがある場合にのみ実際に効果があります。 さて、これについて言及する理由は、これは_compiler-provided_組み込み関数では_望ましくない_可能性があると主張することもできますが（実際に高速化されたバージョンとコンパイラの複雑さを実際に取得するかどうかは決して良くないので）私は組み込み関数が_library_によって提供される場合（そしてインラインasmを使用してのみ実装される場合）は別の話だと思います。 実際、インラインasmよりも組み込み関数を使用していることがわかりますが、これは私が好む全体像です。

（RFC ＃1199の組み込みは、主にSIMDを機能させるために存在するため、この説明とは多少直交していると思います。）

@briansmith

そうしないと、インラインasmを取り巻くコードを最適化することが非常に困難になります。これは、インラインasmの多くの用途がパフォーマンスの最適化を目的としているため、皮肉なことです。

ここで何を意味するのかわかりません。 コンパイラーがasmを個々の操作に分解して、強度の低下やのぞき穴の最適化を行うことはできないのは事実です。 ただし、GCCモデルでは、少なくとも、コンパイラは使用するレジスタを割り当てたり、コードパスを複製するときにコピーしたり、使用したことがない場合は削除したりすることができます。 asmが揮発性でない場合、GCCには、たとえばfsinような他の不透明な操作と同じように扱うのに十分な情報があります。 奇妙なデザインの全体的な動機は、インラインasmをオプティマイザーが混乱させる可能性のあるものにすることです。

しかし、特に最近では、あまり使用していません。 また、LLVMによる機能の表現については経験がありません。 だから私は何が変わったのか、それとも私がずっと誤解してきたのか疑問に思っています。

@japaricによるno_stdエコシステムのasm!マクロが含まれているため、この問題について最近の週に話し合いました。 残念ながら、この機能を安定させるための簡単な方法はわかりませんでしたが、これらすべてを忘れないようにするために必要なメモを書き留めておきたいと思いました。

• まず、現在、 asm!マクロで受け入れられる構文の優れた仕様がありません。 今のところ、通常は「LLVMを見て」と表示され、「clangを見て」と表示され、「gccを表示」と表示されますが、優れたドキュメントはありません。 結局、これは通常、「他の誰かの例を読んでそれを適応させる」または「LLVMのソースコードを読む」で終わります。 安定化のための最低限のことは、構文とドキュメントの仕様を用意する必要があるということです。

• 現在、私たちが知る限り、LLVMからの安定性の保証はありません。 asm!マクロは、LLVMが現在実行していることへの直接バインディングです。 これは、必要なときにLLVMを自由にアップグレードできることを意味しますか？ LLVMは、この構文が破られることは決してないことを保証しますか？ この懸念を軽減する方法は、LLVMの構文にコンパイルされる独自のレイヤーをasm!私たちは基本的に錆の安定を保証するいくつかのメカニズムを必要とする安定になることです。

• 現在、インラインアセンブリに関連するバグがかなりあります。 A-inline-assemblyタグは良い出発点であり、現在ICEやLLVMのsegfaultsなどが散らばっています。全体として、この機能は、今日実装されているように、他の人が安定したものに期待する品質保証を満たしていないようです。 Rustの機能。

• インラインアセンブリを安定させると、代替バックエンドの実装が非常に困難になる場合があります。 たとえば、miriやcraneliftなどのバックエンドは、実装によっては、LLVMバックエンドと同等の機能に到達するまでに非常に長い時間がかかる場合があります。 これは、ここで実行できることの一部が小さいことを意味する場合がありますが、インラインアセンブリの安定化を検討する際には、留意することが重要です。

上記の問題にもかかわらず、私たちは少なくともこの問題を前進させるための何らかの能力を確実に取り除こうと思っていました！ そのために、インラインアセンブリを安定化に向けて微調整する方法についていくつかの戦略をブレインストーミングしました。 前進するための主な方法は、clangが何をするかを調査することです。 おそらく、clangとCは効果的に安定したインラインアセンブリ構文を持っており、clangが行うこと（特にLLVM）をミラーリングできる可能性があります。 clangがインラインアセンブリを実装する方法をより深く理解することは素晴らしいことです。 clangには独自の翻訳レイヤーがありますか？ 入力パラメータを検証しますか？ （NS）

前進するためのもう1つの可能性は、すでに安定している他の場所から棚から外すことができるアセンブラーがあるかどうかを確認することです。 ここでのいくつかのアイデアは、nasmまたはplan9アセンブラーでした。 LLVMのアセンブラを使用すると、IRのインラインアセンブリ命令と同じ安定性の保証に関する問題が発生します。 （可能性はありますが、使用する前に安定性の保証が必要です）

LLVMのインラインasm構文は、clang / gccで使用される構文とは異なることを指摘しておきます。 違いは次のとおりです。

• LLVMは使用しています$0の代わりに%0 。
• LLVMは、名前付きasmオペランド%[name]サポートしていません。
• LLVMは、さまざまなレジスタ制約タイプをサポートしています。たとえば、x86では"a"ではなく"{eax}"です。
• LLVMは明示的なレジスタ制約（ "{r11}" ）をサポートします。 Cでは、代わりにレジスタasm変数を使用して、値をレジスタ（ register asm("r11") int x ）にバインドする必要があります。
• LLVM "m"と"=m"制約は基本的に壊れています。 Clangは、これらを間接メモリ制約"*m"と"=*m"に変換し、変数自体ではなく、変数のアドレスをLLVMに渡します。
• NS...

Clangは、インラインasmをgcc形式からLLVM形式に変換してから、LLVMに渡します。 また、制約の検証も実行します。たとえば、 "i"オペランドがコンパイル時定数であることを確認します。

これに照らして、clangと同じ変換と検証を実装し、奇妙なLLVM構文ではなく適切なgccインラインasm構文をサポートする必要があると思います。

オンラインのスライドを使用したD、MSVC、gcc、LLVM、およびRustの概要に関する優れたビデオがあります。

安定したRustでインラインASMを使用できるようにしたい人として、そしてRustからいくつかのLLVM MC APIにアクセスしようとするよりも多くの経験を持っている人として、いくつかの考えがあります。

• インラインASMは基本的に、コードのスニペットをコピーして出力.sファイルに貼り付け、文字列を置換した後、アセンブルします。 また、入力レジスタと出力レジスタ、およびクローバされたレジスタがアタッチされています。 この基本的なフレームワークがLLVMで実際に変更される可能性はほとんどありません（ただし、詳細の一部はわずかに異なる場合があります）。これは、フレームワークにかなり依存しない表現であると思われます。

• Rustに面した仕様からLLVMに面したIR形式への変換を構築することは難しくありません。 LLVMの$やGCCの%表記とは異なり、フォーマット用の錆びた{}構文はアセンブリ言語に干渉しません。

• LLVMは、特にLLVMによって生成されない命令で、どのレジスタが破壊されるかを実際に識別するという点で、驚くほど悪い仕事をします。 これは、ユーザーがどのレジスターが破壊されるかを手動で指定する必要があることを意味します。

• アセンブリを自分で解析しようとすると、悪夢になる可能性があります。 LLVM-C APIはMCAsmParserロジックを公開しておらず、これらのクラスはbindgenを使用するのが非常に面倒です（私はそれを実行しました）。

• 他のバックエンドへの移植性のために、インラインアセンブリを「この文字列を少しのレジスタ割り当てと文字列置換でコピーアンドペーストする」レベルに維持する限り、バックエンドをそれほど阻害するべきではありません。 整数定数とメモリの制約を削除し、レジスタバンクの制約だけを保持しても、問題は発生しません。

手続き型マクロで何ができるかを確認するために少し遊んでいます。 GCCスタイルのインラインアセンブリをrustスタイルに変換するものを作成しましたhttps://github.com/parched/gcc-asm-rs。 また、ユーザーが制約を理解する必要がなく、すべてが自動的に処理されるDSLを使用するものの開発も開始しました。

だから私は、さびが裸のビルディングブロックを安定させるだけでよいと思うという結論に達しました。そうすれば、コミュニティはマクロを使ってツリーから反復し、最良の解決策を考え出すことができます。 基本的には、「r」と「i」、そしておそらく「m」の制約のみを使用し、クローバーを使用せずに、現在のllvmスタイルを安定させるだけです。 他の制約とクローバーは、後で独自のミニrfcタイプのもので安定させることができます。

個人的には、この機能を安定させることは、誰かがフルタイムの専門業者を雇って1年間これを推進しない限り、決して成し遂げられないような大規模な作業であると感じ始めています。 asm!少しずつ安定させるという@parchedの提案が、これを扱いやすくすると信じたい。 誰かがそれを手に取って実行することを願っています。 しかし、そうでない場合は、決して到達しない満足のいく解決策に到達しようとするのをやめ、次のような不十分な解決策に到達する必要があります： asm!そのまま安定させる、いぼ、ICE、バグなど、ジャンクと非移植性を宣伝するドキュメントの明るい大胆な警告で、そして満足のいく実装が奇跡的に降りて、神から送られた場合、いつかその天国のホストに非難する意図があります。 IOW、私たちはmacro_rules!やったことを正確に行う必要があります（そしてもちろん、 macro_rules!場合と同じように、短期間の必死のバンド支援と漏れのある未来の証拠を得ることができます）。 代替バックエンドの影響については悲しいですが、システム言語がインラインアセンブリをそのような問題に任せるのは恥ずべきことであり、複数のバックエンドが実際に使用できる1つのバックエンドの存在を妨げ続けるという仮説を立てることはできません。 私はあなたにお願いします、私が間違っていることを証明してください！

システム言語がインラインアセンブリをそのような問題に任せるのは恥ずべきことです

データポイントとして、私はたまたま、安定したRustでいくつかのasmを放出することを唯一の目的として、 gccに依存するクレートに取り組んでいます： //github.com/main--/unwind- rs / blob / 266e0f26b6423f4a2b8a8c72442b319b5c33b658 / src / unwind_helper.c

それには確かに利点がありますが、私は「ビルディングブロックを安定させ、残りをproc-macrosに任せる」アプローチに少し警戒しています。 それは本質的に、設計、RFC、および実装プロセスを、仕事をしたい人、潜在的には誰にも外注します。 もちろん、安定性/品質の保証が弱いことが全体のポイントです（トレードオフは、何かが不完全である方が、まったくないよりもはるかに優れているということです）、私はそれを理解しています。

少なくともビルディングブロックは適切に設計されている必要があります。私の意見では、 "expr" : foo : bar : baz間違いなくそうではありません。 私は最初の試みで注文を正しくしたことを今まで覚えていません、私はいつもそれを調べなければなりません。 「コロンで区切られた魔法のカテゴリで、魔法の文字を含む定数文字列を指定すると、変数名に魔法のようなことをしてしまい、そこでマッシュアップするだけです」というのは悪いことです。

1つのアイデア、…

現在、dynasmという名前のプロジェクトがすでにあります。これは、1つのフレーバーのx64コードでアセンブリを前処理するために使用されるプラグインを使用してアセンブリコードを生成するのに役立ちます。

このプロジェクトはインラインアセンブリの問題に答えませんが、rustcが変数をレジスタにマップし、コードにバイトのセットを挿入することを受け入れる方法を提供する場合、そのようなプロジェクトを使用して埋めることもできます-これらのバイトのセットを増やします。

このように、rustcの観点から必要な唯一の標準化部分は、生成されたコードに任意のバイトシーケンスを挿入し、特定のレジスタ割り当てを適用する機能です。 これにより、特定の言語フレーバーのすべての選択肢が削除されます。

ダイナズムがなくても、これはcpuid / rtdsc命令のマクロを作成する方法としても使用できます。これは、バイトの生のシーケンスに変換されるだけです。

次の質問は、バイトシーケンスにプロパティ/制約を追加するかどうかだと思います。

[編集：このコメントで私が言ったことは正しいとは思わない。]

LLVMの統合アセンブラーを引き続き使用する場合（これは外部アセンブラーを生成するよりも高速であると思います）、安定化とは、LLVMのインラインアセンブリ式と統合アセンブラーのサポートを正確に安定させ、それらの変更が発生した場合にそれを補正することを意味します。

外部アセンブラーを生成する場合は、任意の構文を使用できますが、統合アセンブラーの利点を先取りし、呼び出している外部アセンブラーの変更にさらされます。

Clangでさえそうしないのに、LLVMのフォーマットで安定するのは奇妙だと思います。 おそらく内部でLLVMのサポートを使用しますが、GCCに似たインターフェイスを提供します。

特にAFAIKClangのスタンスは「ClangはGCCがサポートするものを正確にサポートする」であるため、「RustはClangがサポートするものを正確にサポートする」と言って1日と呼んでも100％問題ありません。 実際のRust仕様がある場合は、言語を「インラインアセンブリは実装定義」に緩和できます。 優先順位と事実上の標準化は強力なツールです。 GCC構文をLLVMに変換するためにClang独自のコードを再利用できれば、なおさらです。 代替のバックエンドの懸念はなくなることはありませんが、理論的には、GCCへのRustフロントエンドはそれほど厄介ではありません。 私たちが設計することも、無限に自転車に乗ることも、教えることも、維持することも少なくなります。

clangがサポートするものに関して定義されたものを安定させる場合、それをclang_asm!と呼ぶ必要があります。 asm!名前は、他の主要なRust機能のように、完全なRFCプロセスを通じて設計されたもののために予約する必要があります。 #bikeshed

Rustインラインアセンブリで見たいことがいくつかあります。

• template-with-substitutionsパターンは醜いです。 アセンブリテキストと制約リストの間を常に行き来しています。 簡潔さは、人々が位置パラメータを使用することを奨励します。これにより、読みやすさが低下します。 シンボリック名は、多くの場合、同じ名前が3回繰り返されることを意味します。テンプレート、オペランドの名前付け、およびオペランドにバインドされている式です。 Alexのコメントで言及されているスライドは、DとMSVCを使用すると、コード内の変数を簡単に参照できることを示しています。

• 制約は理解するのが難しく、（ほとんど）アセンブリコードと冗長です。 Rustに、命令の十分に詳細なモデルを備えた統合アセンブラがあれば、オペランドの制約を推測して、エラーや混乱の原因を取り除くことができます。 プログラマーが命令の特定のエンコーディングを必要とする場合、明示的な制約を提供する必要がありますが、これは通常は必要ありません。

Norman RamseyとMaryFernándezは、アセンブリと機械語のペアをコンパクトに記述するための優れたアイデアを持っていたときに、 New Jersey Machine CodeToolkitに関するいくつかの論文を書きました。 彼らは（Pentium Pro時代の）iA-32命令エンコーディングに取り組んでいます。 きちんとしたRISCISAに限定されるものではありません。

直近の週の労働からの結論をもう一度繰り返したいと思い

• 今日、私たちが知る限り、この機能のドキュメントは基本的にありません。 これには、LLVM内部およびすべてが含まれます。
• 私たちの知る限り、LLVMからの安定性は保証されていません。 LLVMでのインラインアセンブリの実装はいつでも変更される可能性があることを私たちは知っています。
• これは現在、rustcの非常にバグのある機能です。 それは（コンパイル時に）segfaults、ICEs、そして奇妙なLLVMエラーでいっぱいです。
• 仕様がなければ、このための代替バックエンドを想像することさえほぼ不可能です。

私にとってこれは「今これを安定させれば、将来後悔することを保証する」という定義であり、「後悔する」だけでなく、「新しいシステムの実装に深刻な問題を引き起こす」可能性が非常に高いようです。

最低限でも、弾丸（2）は妥協できないと確信しています（別名「安定チャネル」での安定の定義）。 他の箇条書きは、現在非常に高いRustコンパイラの期待される品質を損なうため、非常に悲しくなります。

@jcranmerは書いた：

LLVMは、特にLLVMによって生成されない命令で、どのレジスタが破壊されるかを実際に識別するという点で、驚くほど悪い仕事をします。 これは、ユーザーがどのレジスターが破壊されるかを手動で指定する必要があることを意味します。

実際には、クローバーリストを推測するのは非常に難しいと思います。 機械語フラグメントがレジスターを使用しているからといって、それがレジスターを破壊するわけではありません。 おそらくそれはそれを保存し、それを復元します。 保守的なアプローチは、コードジェネレーターが使用に適したレジスターを使用することを思いとどまらせる可能性があります。

@alexcrichtonは書いた：

私たちの知る限り、LLVMからの安定性は保証されていません。 LLVMでのインラインアセンブリの実装はいつでも変更される可能性があることを私たちは知っています。

LLVMドキュメントは、「新しいリリースは古いリリースの機能を無視できますが、それらを誤ってコンパイルすることはできません」と保証しています。 （IR互換性に関して）。 それはむしろインラインアセンブリを変更できる量を制限し、上で論じたように、現在の状況からセマンティクスを根本的に変更するLLVMレベルでの実行可能な置き換えは実際にはありません（たとえば、poisonやundefに関する進行中の問題とは異なります）。 したがって、その予想される不安定性により、Rust asm!ブロックのベースとして使用できないと言うのはやや不誠実です。 さて、それは他の問題があると言っているわけではありません（それは改善されましたが、不十分なドキュメント、制約の悪さ、貧弱な診断、そしてあまり一般的でないシナリオでのバグが頭に浮かぶものです）。

スレッドを読む際の私の最大の心配は、私たちが完璧を善の敵にすることです。 特に、いくつかの魔法のDSL仲介者を検索すると、インラインasmで使用可能な形式にまとめるのに数年かかるのではないかと心配しています。人々は、asmパーサーを統合し、それらをLLVMと連携させようとすると、エッジケース。

LLVMは、動作が指定されていない機能を誤ってコンパイルしないことを本当に保証していますか？ 変更が誤コンパイルであるかどうかをどのように判断するのでしょうか。 IRの他の部分でもそれを見ることができましたが、これは多くのことを期待しているようです。

Clangでさえそうしないのに、LLVMのフォーマットで安定するのは奇妙だと思います。

Clangは、GCC用に作成されたコードをコンパイルできるようにすることを目的としているため、これを行いません。 rustcにはその目的はありません。 GCC形式は人間工学的ではないので、最終的にはそれを望まないと思いますが、今のところそれを使用したほうがよいかどうかはわかりません。 現在のRust形式を使用する（毎晩の）コードはたくさんありますが、GCCスタイルに変更すると壊れてしまうため、特に優れたものを思い付くことができる場合にのみ変更する価値があります。

少なくともビルディングブロックは適切に設計されている必要があります。私の意見では、 "expr" : foo : bar : baz間違いなくそうではありません。

同意しました。 少なくとも、制約とクローバーがすべて1つのリストに含まれている生のLLVM形式を好みます。 現在、「=」プレフィックスを指定して出力リストに追加する必要がある冗長性があります。 また、LLVMがそれを、出力が式の結果である関数呼び出しのように扱う方法も考えます。現在のasm!実装は、「out」パラメーターを持つrustの唯一の部分です。

LLVMは、実際にどのレジスタが破壊されるかを特定するという点で、驚くほど悪い仕事をしています。

インラインアセンブリの主な理由は、LLVMが理解できないコードを含めることであるため、AFAIKLLVMはこれを実行しようとはしません。 実際のアセンブリを見ずに、レジスタ割り当てとテンプレート置換のみを行います。 （明らかに、ある段階で実際のアセンブリを解析してマシンコードを生成しますが、それは後で発生すると思います）

外部アセンブラを生成する場合

統合インラインアセンブラを使用する代わりの方法があるかどうかはわかりません。LLVMにレジスタを割り当てる方法があるからです。 ただし、グローバルアセンブリの場合は、外部アセンブラが機能します。

LLVMインラインアセンブラの重大な変更に関しては、Clangと同じボートに乗っています。 つまり、彼らがいくつかの変更を加えた場合、私たちはそれらが起こったときにそれらを回避する必要があります。

clangがサポートするものに関して定義されたものを安定させる場合、それをclang_asm！と呼ぶ必要があります。 asm！ 名前は、他の主要なRust機能のように、完全なRFCプロセスを通じて設計されたもののために予約する必要があります。 #bikeshed

私はそれですべてです。 +1

現在のRust形式を使用する（毎晩の）コードはたくさんありますが、GCCスタイルに変更すると壊れてしまうため、特に優れたものを思い付くことができる場合にのみ変更する価値があります。

@parched上で引用した@jimblandyの提案によると、 asm!を使用している人は誰でも、それを引き続き使用できます。

今日、私たちが知る限り、この機能のドキュメントは基本的にありません。 これには、LLVM内部およびすべてが含まれます。

GCCのアセンブリ構文が30年後に本当に指定または文書化されていない場合、文書化されたアセンブリサブ言語を作成することは、リソースが限られているためにRustの能力を超えるほど困難なタスクであるか、またはアセンブリを使用したい人は単に気にしません。

私たちの知る限り、LLVMからの安定性は保証されていません。 LLVMでのインラインアセンブリの実装はいつでも変更される可能性があることを私たちは知っています。

GCC / Clangのインラインアセンブリの実装が変更される可能性は低いと思われます。これは、90年代以降に記述されたすべてのCコードが破損するためです。

仕様がなければ、このための代替バックエンドを想像することさえほぼ不可能です。

言語としてのRustが、アセンブリにドロップするのが恥ずかしいために生き残れない場合、無慈悲になるリスクがありますが、代替バックエンドの可能性はありません。 NightlyはRustであるという考えを暗黙のうちに支持したい場合を除いて、Nightlyは十分ではありません。これは、LLVMの変更の見通しよりもRustの安定性の保証を損なうことになります。

他の箇条書きは、現在非常に高いRustコンパイラの期待される品質を損なうため、非常に悲しくなります。

Rust開発者の態度と、彼らが保持している膨大な品質基準に毎日感謝していると言っても、私は嘘をついていません（実際、あなたがその品質を維持できるように、すべてが遅くなることを願っていますブライアンのように燃え尽きることなく）。 しかし、luqmanaが4年前にRustは、2018年のいつか、安定したインラインアセンブリを必要です。 macro_rules!状況は、時には悪い方が良いことを認めています。 もう一度、私は誰かに私が間違っていることを証明するように頼んでいます。

FWIWとパーティーに遅れて来る私は@florobのケルントークが提案し

// Add 5 to variable:
let mut var = 0;
unsafe {
    asm!("add $5, {}", inout(reg) var);
}

// Get L1 cache size
let ebx: i32;
let ecx: i32;
unsafe {
    asm!(r"
        mov $$4, %eax;
        xor %ecx, %ecx;
        cpuid;
        mov %ebx, {};",
        out(reg) ebx, out(ecx) ecx, clobber(eax, ebx, edx)
    );
}
println!("L1 Cache: {}", ((ebx >> 22) + 1)
    * (((ebx >> 12) & 0x3ff) + 1)
    * ((ebx & 0xfff) + 1) * (ecx + 1));

次の戦略はどうですか：現在のasm名前をllvm_asm変更し（さらにいくつかの小さな変更もあります）、その動作はLLVMの実装の詳細であるため、Rustの安定性の保証は完全には拡張されません。 異なるバックエンドの問題は、使用するバックエンドに応じて、条件付きコンパイルの機能のようなtarget_feature多かれ少なかれ解決する必要があります。 はい、そのようなアプローチはRustの安定性を少しぼやけさせますが、このようにアセンブリを不安定な状態に保つことは、Rust自体に損害を与えます。

代替構文の提案を含むpre-RFCを内部フォーラムに投稿しました： https ：

私には、最高のものは間違いなくここでの種類の敵であるように見えます。 今のところ、互換性のある構文とセマンティクスを備えた安定版にgcc_asm!またはclang_asm!またはllvm_asm!マクロ（またはその適切なサブセット）を貼り付けることを完全にサポートしていますが、より良い解決策が検討されています。 上記で提案されたより洗練されたシステムは、古いスタイルのマクロを新しいマクロの構文サッカリンに変えるだけで簡単にサポートできるように見えます。

x86_64 popcntl命令のインラインアセンブリを必要とするバイナリプログラムhttp：//[email protected]/BartMassey/popcountがあります。 このインラインアセンブリは、このコードを毎晩保持する唯一のものです。 このコードは、12年前のCプログラムから派生したものです。

現在、私のアセンブリは条件付きです

    #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]

次に、 cpuid情報を取得して、 popcntが存在するかどうかを確認します。 Rustにある最近のGooglecpu_featuresライブラリhttps://opensource.googleblog.com/2018/02/cpu-features-library.htmlに似たものがRustにあると便利ですが、c'est lavieです。

これは何よりもデモプログラムなので、インラインアセンブリを維持したいと思います。 実際のプログラムの場合、 count_ones()組み込み関数で十分です。ただし、 popcntlを使用するにRUSTFLAGS介して「-Ctarget-cpu = native」をCargoに渡す必要があります。 （問題＃1137およびいくつかの関連する問題を参照してください） .cargo/configをソースと一緒に配布するのは良い考えではないようです。つまり、現在、Cargoを呼び出すMakefileがあります。

要するに、実際のアプリケーションでIntelや他の人の派手なポップカウント命令を使用できればいいのですが、それは必要以上に難しいようです。 組み込み関数は完全に答えではありません。 現在のasm!は、安定して利用できれば大丈夫です。 インラインアセンブリの構文とセマンティクスが優れていると便利ですが、実際には必要ありません。 target-cpu=nativeをCargo.tomlで直接指定できるのは素晴らしいことですが、それでは私の問題は実際には解決されません。

すみません、とりとめのないです。 なぜ私がこれを気にするのかを共有したいと思っただけです。

@BartMasseyわかりません、なぜどうしてそんなに必死にpopcntにコンパイルする必要があるのですか？ 私が見ることができる唯一の理由は、パフォーマンスとIMOであり、その場合は必ずcount_ones（）を使用する必要があります。 探しているのはインラインasmではなくtarget_feature（rust-lang / rfcs＃2045）なので、popcntの発行が許可されていることをコンパイラーに通知できます。

@BartMasseyこれにはインラインアセンブリを使用する必要はありません。 coresimd cfg_feature_enabled!("popcnt")を使用して、バイナリが実行されているCPUがpopcnt命令をサポートしているかどうかを照会します（可能であれば、コンパイル時にこれを解決します）。

coresimdは、 popcnt命令の使用が保証されているpopcnt組み込み関数も提供します。

@gnzlbg

coresimdは、popcnt命令の使用が保証されているpopcnt組み込み関数も提供します。

少し話題から外れていますが、この声明は厳密には真実ではありません。 _popcnt64は内部でleading_zerosを使用するため、 popcnt機能がクレートユーザーによって有効にならず、クレート作成者が#![cfg(target_feature = "popcnt")]使用を忘れた場合、この組み込み関数は次のようになります。効果のないアセンブリにコンパイルされ、それに対する保護手段はあり

したがって、popcnt機能がcrateユーザーによって有効にされない場合

インテリジェンスは#[target_feature(enable = "popcnt")]属性を使用して、クレートユーザーが有効または無効にするものに関係なく、インテリジェンスのpopcnt機能を無条件に有効にするため、これは正しくありません。 また、 assert_instr(popcnt)属性は、Rustがサポートするすべてのx86プラットフォームで、組み込み関数がpopcntに分解されることを保証します。

Rustが現在サポートしていないx86プラットフォームでRustを使用している場合は、 coreを移植する人が、これらの組み込み関数がそのターゲットでpopcntを生成するようにします。

編集： @newpavlov

したがって、popcnt機能がcrateユーザーによって有効にならず、crate作成者が＃！[cfg（target_feature = "popcnt"）]の使用を忘れた場合、この組み込み関数は無効なアセンブリにコンパイルされ、それに対する保護手段はありません。

少なくともこの問題で言及した例では、これを行うと未定義の動作がプログラムに導入され、この場合、コンパイラーは何でも実行できます。 動作する不良codegenは、取得できる複数の結果の1つです。

まず第一に、議論を狂わせたことをお詫びします。 私の要点を繰り返したいと思います。「gcc_asm！またはclang_asm！またはllvm_asm！マクロ（またはその適切なサブセット）を、互換性のある構文とセマンティクスを備えた安定版に貼り付けることを完全にサポートしますが、より良い解決策が検討されています。 「」

インラインアセンブリのポイントは、これがポップカウントベンチマーク/デモであるということです。 ベースラインとして、またインラインアセンブリの使用方法を説明するために、可能な場合は真に保証されたpopcntl命令が必要です。 また、RustcがGCCやClangと比較してひどく見えないように、可能な場合はcount_ones()がpopcount命令を使用することを保証したいと思います。

target_feature=popcntをご指摘いただきありがとうございます。 ここで使い方を考えます。 ユーザーがコンパイルしているCPUに関係なく、またpopcount命令があるかどうかに関係なく、 count_ones()をベンチに入れたいと思います。 ターゲットCPUにポップカウントがある場合はcount_ones()がそれを使用することを確認したいだけです。

stdsimd / coresimd木枠は見栄えがよく、おそらくこれらのベンチマークで有効にする必要があります。 ありがとう！ このアプリでは、標準言語の機能以外はできるだけ使用しないほうがいいと思います（ lazy_staticについてはすでに罪悪感を感じています）。 しかし、これらの施設は無視できないほど良さそうに見え、「公式」になるための道を順調に進んでいるようです。

@nbpによってcrateなど）に移行する実装があり、それらのバイトはコード内の特定の場所に直接含まれます。

関数内の任意の場所に任意のコードバイトをスプライスすることは、解決するのがはるかに簡単な問題のように思われます（ただし、入力、出力、およびそれらの制約をクローバーと同じくらいよく指定する機能は必要です）。

cc @eddyb

@nagisaそれは単なるマシンコードのチャックではありませんが、入力、出力、およびクローバーレジスタにも注意する必要があります。 ASMチャンクが％raxに特定の変数が必要であり、％esiを壊してしまうと言っている場合は、周囲のコードが適切に機能することを確認する必要があります。 また、開発者がコンパイラにレジスタを割り当てさせる場合は、値がこぼれたり移動したりしないように、割り当てを最適化することをお勧めします。

@simias 、確かに、変数を特定のレジスタに関連付ける方法と、どのレジスタを上書きするかを指定する必要がありますが、これらはすべて、アセンブリ言語やLLVMアセンブリ言語を標準化するよりも小さいものです。

バイトシーケンスでの標準化は、アセンブリフレーバーをドライバー/ proc-macroに移動することで、おそらく最も簡単な方法です。

適切なインラインアセンブリの代わりに逐語的なバイトを使用することの問題の1つは、コンパイラにレジスタのアルファ名前変更を行うオプションがないことです。これは、インラインアセンブリを作成する人々が期待していることでもありません。

しかし、コンパイラにそれを処理させたい場合、それはレジスタ割り当てでどのように機能しますか？ たとえば、GCCの（凶悪な）構文を使用すると、次のようになります。

asm ("leal (%1, %1, 4), %0"
     : "=r" (five_times_x)
     : "r" (x));

このようなものでは、コンパイラにレジスタを割り当てさせ、最も便利で効率的なものが何でも得られることを期待しています。 たとえば、x86 64では、 five_time_xが戻り値の場合、コンパイラはeaxを割り当てる可能性があり、 xが関数パラメータの場合、すでにいくつかのレジスタで使用可能である可能性があります。 もちろん、コンパイラは、コンパイルシーケンスのかなり遅い段階でレジスタを割り当てる方法を正確に知っているだけです（特に、関数パラメータや戻り値ほど簡単ではない場合）。

提案されたソリューションは、そのようなもので機能しますか？

@nbp私はこの提案に少し混乱していると言わません。
まず第一に、アセンブリ言語の標準化は、インラインアセンブリで実現したいと思ったことではありませんでした。 少なくとも私にとっては、システムアセンブラが使用するアセンブリ言語が受け入れられるという前提が常にありました。
問題は、アセンブリを解析/アセンブルすることではありません。それをLLVMに簡単に渡すことができます。
問題は、テンプレート化されたアセンブリを埋める（または、そうするために必要な情報をLLVMに与える）ことと、入力、出力、およびクローバーを指定することです。
後者の問題は、あなたの提案では実際には解決されません。 ただし、レジスタのクラス（ @simiasが尋ねる）をサポートしない/サポートできないため、これは軽減されますが、具体的なレジスタだけがサポートされます。
制約がその範囲まで単純化された時点で、実際には「実際の」インラインアセンブリをサポートするのと同じくらい簡単です。 最初の引数は（テンプレート化されていない）アセンブリを含む文字列であり、他の引数は制約です。 これは、LLVMのインラインアセンブラ式にいくらか簡単にマッピングできます。
一方、rawバイトの挿入は、LLVMでサポートされている（またはLLVM IRリファレンスマニュアルからわかる）私が知る限りではありません。 したがって、基本的にLLVM IRを拡張し、別のクレートを使用してLLVMにすでに存在する機能（システムアセンブリのアセンブリ）を再実装します。

@nbp

実際、変数を特定のレジスタに関連付ける方法と、どのレジスタを上書きするかを指定する必要がありますが、これらはすべて、アセンブリ言語やLLVMアセンブリ言語を標準化するよりも小さいものです。

では、それはどのように行われるのでしょうか？ 私はハードコードされたレジスタを備えたバイトのシーケンスを持っています。これは基本的に、入力/出力レジスタ、クローバーなどがすべてこのバイトのシーケンス内にハードコードされていることを意味します。

今、私はこのバイトを私の錆びたバイナリのどこかに注入します。 どのレジスタが入出力であるか、どのレジスタが破壊されたかなどをrustcに伝えるにはどうすればよいですか？ これは、インラインアセンブリを安定させるよりも、どのように解決すべき小さな問題ですか？ これはインラインアセンブリが行うこととまったく同じであるように見えますが、作成されたアセンブリで入力/出力クローバーを2回指定する必要があり、この情報をrustcに渡す必要があるためです。 また、rustcはこれを検証するのに簡単な時間はありません。そのためには、バイトのシーケンスを解析してアセンブリに入れ、それを検査できる必要があるためです。 私は何が欠けていますか？

@simias

asm ("leal (%1, %1, 4), %0"
     : "=r" (five_times_x)
     : "r" (x));

バイトのrawではレジスタのアルファ名の変更が許可されていないため、これは不可能であり、レジスタは先のコードシーケンスによって強制される必要があります。

@Florob

少なくとも私にとっては、システムアセンブラが使用するアセンブリ言語が受け入れられるという前提が常にありました。

私の理解では、システムアセンブラに依存することは、私たちが信頼したいことではなく、asmの一部として受け入れられている欠陥であるということです。 大きい。 また、asmに依存しています！ LLVM構文であることは、追加のバックエンドの開発にとって苦痛になります。

@gnzlbg

では、それはどのように行われるのでしょうか？ 私はハードコードされたレジスタを備えたバイトのシーケンスを持っています。これは基本的に、入力/出力レジスタ、クローバーなどがすべてこのバイトのシーケンス内にハードコードされていることを意味します。

アイデアは、入力、出力、およびクローバーされたレジスターのリストを持つことです。ここで、入力は（可変）参照またはコピーに関連付けられたレジスター名のタプルであり、クローバーされたレジスターはレジスター名のリストです。出力は出力レジスタのリストになり、タイプが関連付けられている名前付きレジスタのタプルを形成します。

fn swap(a: u32, b: u32) -> (u32, u32) {
  unsafe{
    asm_raw!{
       bytes: [0x91],
       inputs: [(std::asm::eax, a), (std::asm::ecx, b)],
       clobbered: [],
       outputs: (std::asm::eax, std::asm::ecx),
    }
  }
}

このコードシーケンスは、次のようなコンパイラプロシージャマクロの出力である可能性があります。

fn swap(a: u32, b: u32) -> (u32, u32) {
  unsafe{
    asm_x64!{
       ; <-- (eax, a), (ecx, b)
       xchg eax, ecx
       ; --> (eax, ecx)
    }
  }
}

これらのシーケンスは、シンボルやアドレスを直接埋め込むことができず、計算してレジスタとして指定する必要があります。 後でバイトシーケンス内にいくつかのシンボルアドレスを挿入する機能を追加する方法を理解できると確信しています。

このアプローチの利点は、レジスタと制約のリストのみを標準化する必要があることです。これは、将来のバックエンドで簡単にサポートできるものです。

@nbp

私の理解では、システムアセンブラに依存することは、私たちが信頼したいことではなく、asmの一部として受け入れられている欠陥であるということです。 大きい。 また、asmに依存しています！ LLVM構文であることは、追加のバックエンドの開発にとって苦痛になります。

それは正確な評価ではないと思いますか？ x86アセンブリの2つの異なる構文を除いて、アセンブリ構文は主に標準で移植可能です。 システムアセンブラの唯一の問題は、新しい命令がないことかもしれませんが、それは最適化する価値のないニッチな状況です。

実際の問題は、レジスタ割り当てへの接着剤です。 しかし、実際のアセンブリ文字列自体に関する限り、これは単に誰かが文字列の置換や解析を行う必要があることを意味します。この種の置換は、推定されるバックエンドで簡単に利用できるはずです。

このようなもののLLVM（またはgcc）の構文はくだらないことに同意しますが、プリコンパイルされたバイトに移動するということは、asm crateが完全なアセンブラーと場合によっては完全なレジスタアロケーターをインストールする（またはプログラマーにレジスタを手動で割り当てる）必要があることを意味します。システムアセンブラを使用します。 その時点では、実際にはそれほど多くの価値を追加しているようには見えません。

@jcranmer

...しかし、プリコンパイルされたバイトに移動するということは、asm crateが完全なアセンブラーと場合によっては完全なレジスタアロケーターをインストールする（またはプログラマーにレジスタを手動で割り当てる）か、システムアセンブラーを使用する必要があることを意味します

https://github.com/CensoredUsername/dynasm-rs

このクレートは、プラグインによって処理されるマクロを使用して、アセンブリコードをアセンブルし、実行時に連結される生のアセンブリコードのベクトルを生成します。

@nbpおそらく私の

アセンブリblobが周囲のコンパイラから出力されたアセンブリとうまく統合されない場合は、関数呼び出しに同じタイプのレジスタがあるため、スタンドアロンの.sアセンブリファイルの外部CスタイルメソッドでASMスタブを因数分解することもできます。 -割り当ての制約。 これは今日すでに機能していますが、rustcに組み込むと、スタンドアロンのアセンブリファイルを使用する場合に比べてビルドシステムが簡素化される可能性があります。 私が言っているのは、IMOの提案は、現在の状況と比べてそれほど遠くないということだと思います。

また、ASMコードがリンカーによって解決される外部シンボルを呼び出す場合はどうなりますか？ コンパイルプロセスの後半まで解決できない可能性があるため、その情報を渡す必要があります。 バイト配列と一緒に参照を渡し、リンカに後でそれらを解決させる必要があります。

@jcranmer

x86アセンブリの2つの異なる構文を除いて、アセンブリ構文は主に標準で移植可能です。

それが何を意味するのか理解できません。明らかに、ASM構文はアーキテクチャ間で移植できません。 また、同じアーキテクチャ内であっても、言語の組み立て方法を変更するバリエーションやオプションが存在することがよくあります。

例としてMIPSを挙げますが、アセンブラの動作を微調整する2つの重要な構成フラグがあります。 atとreorderです。 atは、特定の疑似命令をアセンブルするときに、アセンブラがAT （アセンブラ一時）レジスタを暗黙的に使用できるかどうかを示します。 ATを明示的に使用してデータを格納するコードは、 atでアセンブルする必要があります。そうしないと、壊れてしまいます。

reorderは、コーダーが分岐遅延スロットを手動で処理するか、アセンブラーがそれらを処理することを信頼するかを定義します。 間違ったreorder設定でコードをアセンブルすると、ほぼ確実に偽のマシンコードが生成されます。 MIPSアセンブリを作成するときは、分岐命令が含まれている場合は常に現在のモードに注意する必要があります。 たとえば、 reorderが有効になっているかどうかわからない場合、このMIPSリストの意味を知ることはできません。

    addui   $a0, 4
    jal     some_func
    addui   $a1, $s0, 3

32ビットARMアセンブリにはThumb / ARMのバリエーションがあり、ターゲットにしている命令セットを知ることが重要です（関数呼び出し間でオンザフライで変更できます）。 両方のセットの混合は非常に慎重に行う必要があります。 ARMコードは通常、暗黙的なPC相対ロードを使用して大きなイミディエート値をロードします。コードを事前にアセンブルする場合は、これらの値を近くに保持する必要がありますが、実際の命令ではないため、これらの値を渡す方法に注意する必要があります。明確に定義された場所。 私は次のような疑似命令について話している：

   ldr   r2, =0x89abcdef

一方、MIPSは、即値を2つの16ビット値に分割し、lui / oriまたはlui / andiコンボを使用する傾向があります。 これは通常、 li / la疑似命令の背後に隠されていますが、 noreorderを使用してコードを記述していて、遅延スロットを無駄にしたくない場合は、処理する必要があります。手作業で作成すると、見た目がおかしなコードになります。

.set noreorder

   /* Display a message using printf */
   lui $a0, %hi(hello)
   jal printf
   ori $a0, %lo(hello)

.data

hello:
.string "Hello, world!\n"

%hiおよび%lo構造は、それぞれhelloシンボルの上位16ビットおよび下位16ビットへの参照を生成するようにアセンブリに指示する方法です。

一部のコードには、非常に特殊な配置制約が必要です（たとえば、キャッシュ無効化コードを処理する場合は、座っているブランチにのこぎりを使わないようにする必要があります）。 また、前述したように、コンパイルプロセスのこの時点では解決できない外部シンボルを処理するという問題があります。

私は、あまり馴染みのない他の多くのアーキテクチャの特性を思い付くことができると確信しています。 これらの理由から、私はマクロ/ DSLアプローチについて非常に楽観的であるかどうかはわかりません。 コードの途中にランダムな不透明な文字列リテラルを含めることはあまりエレガントではないことを理解していますが、完全なASM構文を何らかの方法でrustに統合すると、サポートを追加するときの追加の頭痛の種を除いて、何が得られるかはわかりません。新しいアーキテクチャ。

アセンブラを作成することは、一見些細なことのように思えるかもしれませんが、そこにあるすべてのアーキテクチャのすべてのベル、ホイッスル、および癖をサポートしたい場合は、非常に難しいことが判明する可能性があります。

一方、バインディングとクローバーを指定するための優れた方法を持つことは、非常に価値があります（gccの...完璧な構文と比較して）。

こんにちは、みんな、

ご迷惑をおかけして申し訳ありませんが、私は2セントを落としたかっただけです。なぜなら、私はただのユーザーであり、非常に恥ずかしがり屋で静かな人です。それに恋をしています。

しかし、この集会のことはただクレイジーです。つまり、3年間の会話であり、たくさんのアイデアと不満がありますが、最低限のコンセンサスのようには思えません。 RFCではなく3年で、それは少し死の終わりのように思えます。 私は謙虚な数学ライブラリを開発しています（2つまたは3つのクレートで実現することを願っています）、そして私にとって（そして、錆びたアセンブリを書くことに興味がある他の仲間にとって）最も重要なことは実際にできることですやれ！ 翌日すべてが変わらないという最低限の保証があります（それが不安定なチャンネル、特にこの会話が私に感じさせるものです）。

ここの誰もが最良の解決策を望んでいることを理解しています、そしておそらくいつか誰かがそれを思い付くでしょう、しかし今日に関しては私は現在のマクロはちょうど良いと信じています（まあ、いくつかの点で少し制限があるかもしれませんが、うまくいけばそれができないことは何もありません漸進的に対処する）。 アセンブリを書くことは、システム言語で最も重要なことのようであり、非常に必要な機能です。これが修正されるまではcpp_buildに頼っても大丈夫ですが、もっと時間がかかると、次のようになるのではないかと心配しています。永遠の依存関係。 理由はわかりませんが、それを不合理な考えと呼んでいますが、アセンブリを呼び出すためにcppを呼び出さなければならないのは少し悲しいことであり、純粋な錆の解決策が必要です。

FWIW錆はここで特別には、MSVCは、x86_64のいずれかのインラインアセンブラを持っていないということではありません。 変数をオペランドとして使用できるという非常に奇妙な実装がありますが、これはx86でのみ機能します。

@josevalaadインラインアセンブリを何に使用しているのかについて詳しく教えてください。

私たちは、それはOSのような、同様に他の理由のために、夜間に一般的に立ち往生している状況で使用される唯一の一般的に見て、その後も彼らはほとんど使用asm! 、とても安定asm! AされていませんLLVMの外部で適切に存続し、すべての人を喜ばせることができるものを設計および開発するための十分な優先順位。

さらに、ほとんどのことは、公開されたプラットフォーム組み込み関数を使用して実行できます。 x86とx86_64は安定化されており、他のプラットフォームが進行中です。 これらが目標の95〜99％を達成することは、ほとんどの人の期待です。 いくつかの固有のものを使用した例として、私自身のクレートjetsciiを見ることができます。

インラインアセンブリを使用してLLVMのコード生成バグを回避するjemallocPRをマージしました-https ：//github.com/jemalloc/jemalloc/pull/1303 。 誰かがこの問題（https://github.com/rust-lang/rust/issues/53232#issue-349262078）でインラインアセンブリを使用して、jetsciiクレートで発生したRust（LLVM）のコード生成バグを回避しました。 どちらも過去2週間に発生し、どちらの場合もユーザーは組み込み関数を試しましたが、コンパイラーは失敗しました。

Cコンパイラのコード生成が受け入れられない場合、最悪の場合、ユーザーはインラインアセンブリを使用して、Cで作業を続けることができます。

これが安定したRustで発生する場合、今のところ、別のプログラミング言語を使用するか、不確定な時間（多くの場合、数年のオーダー）待つように人々に指示する必要があります。 イケてないよ。

@eddybええと、私は小さな行列代数ライブラリを書いています。 そのライブラリ内で、ライブラリを純粋なrust実装にしたかったので、RustにBLAS、おそらくいくつかのLAPACK（まだ存在しない）ルーチンを実装しています。 まだ深刻なことではありませんが、とにかく、ユーザーが、特にGEMM操作を使用して、必要不可欠なasmの速度と楽しみを選択できるようにしたかったのです（とにかく、最もよく使用され、BLISの人々のアプローチに従う場合少なくともx86 / x86_64では、必要なものはすべて揃っています。 そして、それは完全な話です。 もちろん、夜間のチャンネルも使用できますが、機能の安定化という実用的な方向に少し押したかっただけです。

@shepmaster組み込み関数では不十分なユースケースが_

安定したインラインasmは重要であり、本質的なものだけでは不十分です。

私の当初のポイントは、誰かがより高速なコードを記述できるようにすることでした。 彼らは、組み込み関数が利用可能でさえあることを知っていることに言及していませんでした、そしてそれは私が共有しようとしたすべてです。 残りは背景情報でした。

私は特定の観点を主張することすらしていないので、私と議論しようとしないでください—私はこのレースに利害関係がありません。 私が理解しているように、私は単に現在の視点が何であるかを繰り返してインラインアセンブリを必要とするプロジェクトに参加して

はい、今のところ組み立てが必要な場合もあれば、永遠に必要になる場合もあります。私は最初に同じように言いました（明確にするために強調を追加しました）。

[組み込み関数]が目標の95〜99％を達成することは、ほとんどの人の期待です。

私の意見では、安定した集会を見たいのであれば、誰か（または人々のグループ）がRustチームから開始の方向性について一般的なコンセンサスを得て、それを実現するために多大な努力を払う必要があります。 。

まだ深刻なことではありませんが、とにかく、ユーザーが、特にGEMM操作を使用して、必要不可欠なasmの速度と楽しみを選択できるようにしたかったのです（とにかく、最もよく使用され、BLISの人々のアプローチに従う場合少なくともx86 / x86_64では、必要なものはすべて揃っています。

インラインアセンブリなしではアクセスできない、アクセスする必要のある命令をまだ理解していません。 それとも、算術命令の特定のシーケンスですか？
もしそうなら、インラインアセンブリに対して同等のRustソースをベンチマークしましたか？

インラインアセンブリなしではアクセスできない、アクセスする必要のある命令

さて、数学でのアセンブリについて話しているときは、基本的に、SIMDレジスタと_mm256_mul_pd、_mm256_permute2f128_pdなどの命令の使用とそれが進むベクトル化操作について話していることになります。 重要なのは、ベクトル化にさまざまなアプローチをとることができるということです。通常、ターゲットとするプロセッサと念頭に置いている使用法に対して最適化されたパフォーマンスが得られるまで、少し試行錯誤します。 したがって、通常、ライブラリレベルでは、最初にプロセッサにクエリを実行してasmコードを挿入し、サポートされている命令とレジスタのセットを確認してから、特定のバージョンの数学asmカーネルを条件付きコンパイルする必要があります。

もしそうなら、インラインアセンブリに対して同等のRustソースをベンチマークしましたか？

現在、具体的なテストはありません。休暇中なので、あまり関わりたくないのですが、2、3週間いただければ、パフォーマンスの比較を投稿できます。 いずれにせよ、コンパイラが手動で調整されたアセンブリを使用してできる限り高速にコードを生成することは不可能でした。 少なくともCでは、必要に応じて手動でループを展開するなどの従来のパフォーマンス手法を使用しても不可能であるため、Rustでは不可能であると思います。

Taylor Cramerは、ここに投稿することを提案しました。 議論の現状を理解するためにすべてのコメントを読んだわけではないので、許してください。 これは、私たちの状況を支持し、表明するための声にすぎません。

Googleのベアメタルプロジェクトでは、インラインおよびモジュールレベルのアセンブラの安定化に関する動きが見られることを望んでいます。 別の方法は、FFIを使用して、純粋なアセンブリで記述され、個別にアセンブルされ、バイナリにリンクされた関数を呼び出すことです。

アセンブラーで関数を定義し、FFIを介してそれらを呼び出し、別のステップでそれらをリンクすることもできますが、複雑さとパフォーマンスの両方の点で欠点があるため、それを排他的に行う深刻なベアメタルプロジェクトはありません。 レドックスは「asm！」を使用します。 Linux、BSD、macOS、Windowsなどの通常の容疑者はすべて、インラインアセンブラを多用しています。 ジルコンとseL4がそれを行います。 プラン9でさえ、数年前にハーベイフォークでこれに陥りました。

パフォーマンスが重要な場合、呼び出される関数の複雑さによっては、関数呼び出しのオーバーヘッドが支配的になる可能性があります。 複雑さの観点から、単一の命令を呼び出したり、レジスターを読み書きしたり、あるいはユーザースペースプログラマーから通常は隠されているマシン状態を操作したりするためだけに個別のアセンブラー関数を定義することは、間違いを犯すためのより退屈な定型文を意味します。 いずれにせよ、これを行うには、Cargoの使用（または外部ビルドシステムやシェルスクリプトなどの補足）をより創造的にする必要があります。 おそらくbuild.rsがここで役立つかもしれませんが、それをリンカーにフィードするのはもっと難しいようです。

シンボリック定数の値をアセンブラーテンプレートに組み込む方法があれば、それも非常に気に入っています。

インラインおよびモジュールレベルのアセンブラーの安定化に関する動きを見てみたいと思います。

最後のpre-RFC（https://internals.rust-lang.org/t/pre-rfc-inline-assembly/6443）は、6か月前にコンセンサスを達成したため（少なくとも基本的な問題のほとんどについて）、次のステップその上に構築されたRFCを提出することです。 これをもっと早く起こさせたいのなら、 @ Florobに連絡することをお勧めします。

その価値については、WindowsでTEB構造体へのポインタを取得するためにFSGSレジスタに直接アクセスする必要があります。また、任意のメモリ位置にbtを適用するための_bittest64ような組み込み関数も必要です。どちらも、インラインアセンブリまたは外部呼び出しなしで行う方法を見つけることができませんでした。

ただし、ここで説明する3番目のポイントは私に関係します。LLVMは、何か問題が発生した場合にJust Crashを優先し、エラーメッセージがまったく表示されないためです。

@MSxDOS

また、任意のメモリ位置にbtを適用するには、_bittest64のような組み込み関数が必要です。どちらも、インラインアセンブリまたは外部呼び出しなしで実行する方法を見つけることができませんでした。

これをstdsimdに追加するのは難しいことではありません。clangはインラインアセンブリを使用してこれらを実装します（https://github.com/llvm-mirror/clang/blob/c1c07cca8cae5f924cedaac7b202b0f3c167111d/test/CodeGen/bittest-intrin .c＃L45）ただし、これをstdライブラリで使用して、組み込み関数を安全なRustに公開できます。

欠落している組み込み関数に関する問題をstdsimdリポジトリで開くことをお勧めします。

@josevalaad

さて、数学でのアセンブリについて話しているときは、基本的に、SIMDレジスタと_mm256_mul_pd、_mm256_permute2f128_pdなどの命令の使用とそれが進むベクトル化操作について話していることになります。

ああ、そうかもしれないと思った。 試してみたい場合は、アセンブリをstd::arch組み込み呼び出しに変換して、同じパフォーマンスが得られるかどうかを確認できます。

そうでない場合は、問題を提出してください。 LLVMは魔法ではありませんが、少なくとも組み込み関数はasmと同じくらい優れている必要があります。

@dancrossnyc質問しても構わないのであれば、あなたの状況で、特にインラインアセンブリを必要とするユースケース/プラットフォーム機能は

@MSxDOSたぶん、「セグメント」レジスタを読み取るための組み込み関数を公開する必要がありますか？

たぶん、データ収集を行って、人々が本当にasm!を望んでいるものの内訳を取得し、他の方法でサポートできるものがいくつあるかを確認する必要があります。

たぶん、私たちはいくつかのデータ収集を行い、人々が本当にasmを望んでいるものの内訳を取得する必要があります！

asm!欲しい：

• コンパイラによって提供されない組み込み関数を回避する
• コンパイラのバグの回避/最適ではないコード生成
• 一連の単一の組み込み呼び出しでは実行できない操作を実行します。たとえば、読み取りEFLAGS-modify-write EFLAGSで、LLVMは読み取りと書き込みの間でeflagsを変更でき、LLVMはユーザーが変更しないと想定します。これは背後にあります（つまり、EFLAGSを安全に操作する唯一の方法は、読み取り-変更-書き込み操作を単一のアトミックasm!ブロックとして書き込むことです）。

そして、それらのうちのいくつが他の方法でサポートされる可能性があるかを確認してください。

何らかの形のインラインアセンブリを伴わないこれらのユースケースをサポートする他の方法は見当たりませんが、私の心は開いています。

以前のRFCスレッドの投稿からコピーしたものです。現在のプロジェクトで使用しているインラインアセンブリ（ARM64）を次に示します。

// Common code for interruptible syscalls
macro_rules! asm_interruptible_syscall {
    () => {
        r#"
            # If a signal interrupts us between 0 and 1, the signal handler
            # will rewind the PC back to 0 so that the interrupt flag check is
            # atomic.
            0:
                ldrb ${0:w}, $2
                cbnz ${0:w}, 2f
            1:
               svc #0
            2:

            # Record the range of instructions which should be atomic.
            .section interrupt_restart_list, "aw"
            .quad 0b
            .quad 1b
            .previous
        "#
    };
}

// There are other versions of this function with different numbers of
// arguments, however they all share the same asm code above.
#[inline]
pub unsafe fn interruptible_syscall3(
    interrupt_flag: &AtomicBool,
    nr: usize,
    arg0: usize,
    arg1: usize,
    arg2: usize,
) -> Interruptible<usize> {
    let result;
    let interrupted: u64;
    asm!(
        asm_interruptible_syscall!()
        : "=&r" (interrupted)
          "={x0}" (result)
        : "*m" (interrupt_flag)
          "{x8}" (nr as u64)
          "{x0}" (arg0 as u64)
          "{x1}" (arg1 as u64)
          "{x2}" (arg2 as u64)
        : "x8", "memory"
        : "volatile"
    );
    if interrupted == 0 {
        Ok(result)
    } else {
        Err(Interrupted)
    }
}

@Amanieuは、 @ japaricがARMの本質に向けて取り組んでいることに注意してください。 その提案があなたのニーズをカバーしているかどうかを確認する価値があります。

@shepmaster

@Amanieuは、 @ japaricがARMの本質に向けて取り組んでいることに注意してください。 その提案があなたのニーズをカバーしているかどうかを確認する価値があります。

注目に値するのは次のとおりです。

• この作業はインラインアセンブリに代わるものではなく、単にそれを補完するものです。 このアプローチは、ベンダーAPIをstd::archで実装します。これらのAPIは、すでに一部の人にとっては不十分です。

• このアプローチは、 foo(); bar(); baz();ような一連の組み込み呼び出しがその命令のシーケンスと区別できないコードを生成する場合にのみ使用できます-これは必ずしもそうではなく、そうでない場合、正しく見えるコードはせいぜい正しくないものを生成しますその結果、最悪で未定義の動作（我々はに起因するこれにバグがあったx86とx86_64でstd例えば、https://github.com/rust-、すでにlang-nursery / stdsimd / blob / master / coresimd / x86 / cpuid.rs＃L108-他のアーキテクチャにもこれらの問題があります）。

• 一部の組み込み関数には即時モード引数があり、関数呼び出しを介して渡すことができないため、 foo(3)は機能しません。 この問題のすべての解決策は現在、厄介な回避策であり、場合によっては、現在Rustで回避策が不可能であるため、これらの組み込み関数の一部を提供していません。

したがって、ベンダーAPIがRustで実装可能であり、 std::archで利用可能であり、問​​題を解決するために組み合わせることができる場合、インラインアセンブリよりも優れていることに同意します。 しかし、時々、APIが利用できないか、実装できない可能性があります。または、APIを正しく組み合わせることができません。 将来的には「実装可能性の問題」を修正する可能性がありますが、ベンダーAPIによって実行したいことが公開されていない場合、またはAPIを組み合わせることができない場合、このアプローチは役に立ちません。

LLVMの組み込み関数（特にSIMD）の実装について非常に驚くべきことは、組み込み関数の命令へのIntelの明示的なマッピングにまったく準拠していないことです。これらは、コンパイラーの幅広い最適化の対象となります。 たとえば、ある定数をメモリからロードするのではなく、他の定数から計算することでメモリの負荷を軽減しようとしたときのことを覚えています。 しかし、LLVMは単純に、回避しようとしていた正確なメモリ負荷に全体を定数畳み込みに戻しました。 別のケースでは、port5の圧力を下げるために、16ビットのシャッフルを8ビットのシャッフルに置き換えることを検討したいと思いました。 しかし、その果てしない知恵の中で、これまでに役立つLLVMオプティマイザーは、私の8ビットシャッフルが実際には16ビットシャッフルであることに気づき、それを置き換えました。

どちらの最適化も確かに（特にハイパースレッディングに直面して）より良いスループットをもたらしますが、私が達成したいと思っていたレイテンシーの削減はありません。 私はその実験のためにnasmまでずっとドロップダウンすることになりましたが、コードを組み込み関数からプレーンasmに書き直さなければならないのは不必要な摩擦でした。 もちろん、高レベルのベクトルAPIを使用する場合は、オプティマイザーで命令の選択や定数畳み込みなどを処理する必要があります。 しかし、どの命令を使用するかを明示的に決定したとき、コンパイラーがそれをいじりたくないのです。 唯一の選択肢はインラインasmです。

したがって、ベンダーAPIがRustで実装可能であり、 std::archで利用可能であり、問​​題を解決するために組み合わせることができる場合、インラインアセンブリよりも優れていることに同意します。

私が最初に言っていたのはそれだけです

目標の95〜99％を達成する

そしてまた

はい、今のところ組み立てが必要な場合もあれば、永遠に必要になる場合もあります。私は最初に同じように言いました（明確にするために強調を追加しました）。

[組み込み関数]が目標の95〜99％を達成することは、ほとんどの人の期待です。

これは、 @ eddybが並行して言っていることと同じです。 現在の状況の現実を指摘しようとしているときにわかりません。

私は

1. 組み込み関数が今日の安定した組み込み関数に向かって存在することを知らなかったあるポスターを指摘
2. 提案された組み込み関数に別のポスターを示し、提案に早期のフィードバックを提供できるようにしました。

これを非常に明確に述べさせてください。はい、インラインアセンブリが必要な場合があります。 私はそれを主張していません。 私は、現在利用可能なツールを使用して、人々が現実の問題を解決できるように支援しようとしているだけです。

私が言おうとしていたのは、これに対してより組織化されたアプローチ、適切な調査を行い、このスレッドの数人よりも多くのデータを収集し使用して最も一般的なニーズを指摘する必要がある

私は、各アーキテクチャは、インラインから、いくつかの使用を取得するトリッキー・ツー・モデルのサブセット、持っていると思われるasm! 、そして多分私達はそれらのサブセットに焦点を当て、その後、一般化しようとする必要があります。

cc @ rust-lang / lang

@eddyb _require_は強力な言葉であり、インラインアセンブラを使用する必要は厳密にはありません。 先に述べたように、純粋なアセンブリ言語でプロシージャを定義し、それらを個別にアセンブルし、FFIを介してRustプログラムにリンクすることができます。

ただし、前に述べたように、それを実行する深刻なOSレベルのプロジェクトはありません。 これは、多くのボイラープレート（読み：間違いを犯す可能性が高い）、より複雑なビルドプロセス（今のところ、単純なcargo呼び出しと、リンクされたほぼすぐに実行できるカーネルがもう一方の端から飛び出します。別のステップでアセンブラーとリンクを呼び出す必要があります）、インライン化する機能が大幅に低下します。 ほぼ確実にパフォーマンスが低下します。

コンパイラ組み込み関数のようなものは多くの場合に役立ちますが、ターゲットISAの監視命令セットのようなもの、特により難解なハードウェア機能（ハイパーバイザーやエンクレーブ機能など）の場合、組み込み関数がないことが多く、 no_std環境。 多くの場合、そこにある組み込み関数では不十分です。 たとえば、x86割り込み呼び出し規約はかっこいいように見えますが、トラップフレーム内の汎用レジスタへの可変アクセスを提供しません。エミュレーションを行う目的で未定義の命令例外を取得し、エミュレートされた命令が値を返すとします。 ％raxか何かで; 呼び出し規約では、それを呼び出しサイトに戻す良い方法が得られないため、自分でロールする必要がありました。 これは、アセンブラで独自の例外処理コードを作成することを意味しました。

したがって、正直に言うと、インラインアセンブラは必要ありませんが、それがないことはほとんど初心者ではないので十分に役立ちます。

@dancrossnyc私は一種のアセンブリのあなたのプロジェクト、あなたがそれをリンクどんなに内のすべてで必要なものであり、個別の組み立てを、避けることについて特に興味があります。

あなたの場合、それはスーパーバイザー/ハイパーバイザー/エンクレーブ特権ISAサブセットのようですが、それは正しいですか？

多くの場合、組み込み関数はありません

これは必然的ですか？つまり、LLVMなどの組み込み呼び出しとしてコンパイルした場合に、命令に不当に困難または不可能な要件がありますか？
それとも、ほとんどの開発者にとって有用とは言えない特殊なケースであると想定されているからですか？

そして私たちはno_std環境にいます

ちなみに、ベンダー組み込み関数はstd::archとcore::arch両方にあります（前者は再エクスポートです）。

x86割り込み呼び出し規約はクールに見えますが、トラップフレーム内の汎用レジスタへの変更可能なアクセスを提供しません

cc @rkruppeこれはLLVMで実装できますか？

@eddyb正解; ISAのスーパーバイザサブセットが必要です。 現時点では、特定のユースケースについてこれ以上お話しすることはできません。

これは必然的ですか？つまり、LLVMなどの組み込み呼び出しとしてコンパイルした場合に、命令に不当に困難または不可能な要件がありますか？
それとも、ほとんどの開発者にとって有用とは言えない特殊なケースであると想定されているからですか？

ある程度は両方とも真実ですが、バランスをとると、ここでは後者の方が適切だと思います。 いくつかのものはマイクロアーキテクチャ固有であり、特定のプロセッサパッケージ構成に依存します。 コンパイラが（たとえば）特定のプロセッサバージョンで条件付けられた特権命令サブセットの一部である組み込み関数として何かを公開することは合理的でしょうか？ 正直わかりません。

ちなみに、ベンダー組み込み関数はstd :: archとcore :: archの両方にあります（前者は再エクスポートです）。

それは実際に知っておくと本当に良いことです。 ありがとう！

コンパイラが（たとえば）特権命令サブセットの一部であり、特定のプロセッサバージョンを条件とする組み込み関数として何かを公開することは合理的でしょうか？ 正直わかりません。

すでに行っています。 たとえば、 xsave x86命令は、 core::archで実装および公開されており、すべてのプロセッサで使用できるわけではなく、ほとんどのプロセッサで特権モードが必要です。

@gnzlbg xsaveは特権がありません。 xsavesですか？

https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/arch/x86_64/index.htmlと、クイックスイープで見た唯一の特権命令を確認しました（徹底的な検索）は、 xsaves 、 xsaves64 、 xrstors 、およびxrstors64 。 これらは一般的なXSAVE*ファミリーに分類され、リアルモードで例外を生成しないため、組み込み関数であると思われます。一部の人々は、clang / llvmを使用してリアルモードコードをコンパイルしたいと考えています。

@dancrossnycはい、それらのいくつかは私が意図したものです（ xsave 、 xsaves 、 xsaveopt 、...をxsaveモジュールに実装します：https： //github.com/rust-lang-nursery/stdsimd/blob/master/coresimd/x86/xsave.rs）。

これらはcoreで入手できるため、x86用のOSカーネルを作成するために使用できます。 ユーザースペースでは、それらは役に立たないAFAICTです（常に例外が発生します）が、 coreこれを区別する方法がありません。 coreでしか公開できず、 stdでは公開できません

@gnzlbg xsaveoptまたはxsaveがユーザースペースで例外を発生させる理由がわかりません： xsavesは、例外を生成するように定義されているファミリの1つだけです（#GP CPL> 0の場合）、保護モードのみ（SDMvol.1ch。13;vol.2Cch。5XSAVES）。 xsaveとxsaveoptは、プリエンプティブユーザースペーススレッドなどの実装に役立ちます。したがって、組み込み関数としての存在は実際には理にかなっています。 xsavesの本質は、誰かがxsaveファミリーからすべてを追加しただけで、特権の問題に気付かなかったため（つまり、ユーザースペースから呼び出し可能であると想定した場合）、または誰かがそれを呼び出したいと思ったためだと思います。リアルモードから。 後者はとてつもないように見えるかもしれませんが、たとえばClangとLLVMを使用してリアルモードファームウェアを構築している人がいることは知っています。

誤解しないでください。 coreにLLVM組み込み関数が存在することは素晴らしいことです。 rdtscpの結果を再び有用な形式に変換するために、そのばかげた一連の命令を書く必要がなければ、私は幸せになります。 ただし、カーネルやその他のベアメタル監視のようなものを作成する場合、現在の組み込み関数のセットはインラインアセンブラの代わりにはなりません。

@dancrossnyc xsaveについて言及したとき、CPUIDビットXSAVE、XSAVEOPT、XSAVECなどの背後で使用可能な組み込み関数のいくつかを参照していました。これらの組み込み関数のいくつかは特権モードを必要とします。

コンパイラが（たとえば）特権命令サブセットの一部であり、特定のプロセッサバージョンを条件とする組み込み関数として何かを公開することは合理的でしょうか？

すでに行っており、安定したRustで利用できます。

xsavesの本質は、特権の問題に気付かずに誰かがxsaveファミリーからすべてを追加したためだと思います。

これらの組み込み関数を追加しました。 coreに依存するプログラムがこれらを使用したいOSカーネルであることが完全に問題なく、ユーザースペースで無害であるため、特権の問題を認識し、とにかく追加することにしました。それらを使用しようとすると、プロセスが終了します）。

ただし、カーネルやその他のベアメタル監視のようなものを作成する場合、現在の組み込み関数のセットはインラインアセンブラの代わりにはなりません。

同意しました、それがこの問題がまだ開いている理由です;）

@gnzlbg申し訳ありませんが、 xsaveうさぎの穴を開けてこれを脱線させるつもりはありません。

ただし、私が知る限り、特権実行を必要とする組み込み関数はxsaves関連するものだけであり、それでも常に特権があるとはん（ここでも、リアルモードは関係ありません）。 それらが安定したRustで（真剣に）利用できるのは素晴らしいことです。 他のものはユーザースペースで役立つかもしれません、そして同様に私はそれらがそこにあることは素晴らしいと思います。 ただし、 xsavesとxrstorsは、特権命令セットのごく一部であり、2つの命令に組み込み関数を追加することは、一般的に行うこととは質的に異なります。それは_一般的に_適切です。 たとえば、VMX拡張機能からのVMWRITE命令について考えてみます。 組み込み関数が実行命令のようなことをしてからrflags 「返す」と想像します。 それは、本質的なものとして持つべき奇妙に特殊化されたものの一種です。

そうでなければ、私たちはここで同意していると思います。

std::arch RFCによるFWIWは、現在、ベンダーがAPIで公開しているstd::archのみ組み込み関数を追加できます。 xsave場合、 IntelはそれらをC APIではありません。 現在公開されていないベンダー組み込み関数が必要な場合は、特権モードが必要かどうかに関係なく、問題を開きます。

ベンダーがその組み込み関数を公開していない場合、 std::archはその場所ではない可能性がありますが、それに代わる方法はたくさんあります（インラインアセンブリ、グローバルアセンブリ、Cの呼び出しなど）。

申し訳ありませんが、インテルの組み込み関数を意味するためにxsave組み込み関数を作成したとのことですが。 私の以前のコメントは、なぜxsavesが本質的であると思うのかについても当てはまります（Intelのコンパイラライターによる事故か、誰かがリアルモードでそれを望んでいたためです。前者はすぐに気付くと思いますがファームウェアは奇妙なことをするので、後者は私をまったく驚かせません）。

とにかく、はい、私たちは基本的に同意すると思います。組み込み関数はすべての場所ではないので、asm！（）が安定した状態に移行することを望んでいます。 昨日おっしゃったように、この分野で進歩が見られていることをとてもうれしく思います。 @ Florobをそっと

asm!のいくつかの追加の詳細とユースケース：

オペレーティングシステム、ファームウェア、特定の種類のライブラリ、または特定の他の種類のシステムコードを作成する場合は、プラットフォームレベルのアセンブリへのフルアクセスが必要です。 Rustがサポートするすべてのアーキテクチャのすべての命令を公開する組み込み関数があったとしても（これは、私たちが持っていることに近づくことはできません）、人々がインラインアセンブリで定期的に引っ張るスタントのいくつかにはまだ十分ではありません。

インラインアセンブリで実行できることのうち、他の方法では簡単に実行できないことのごく一部を次に示します。 これらのすべては、私が見た（または場合によっては書かれた）実際の例であり、仮説ではありません。

• 特定のパターンの命令のすべての実装を別のELFセクションに収集し、コードをロードする際に、実行しているシステムの特性に基づいて実行時にそのセクションにパッチを適用します。
• 実行時にターゲットにパッチが適用されるジャンプ命令を記述します。
• 命令の正確なシーケンスを発行して（個々の命令の組み込み関数を当てにすることができないように）、途中で発生する可能性のある中断を注意深く処理するパターンを実装できるようにします。
• 命令を発行し、その後にasmブロックの最後にジャンプし、その後に、命令が障害を生成した場合にジャンプするハードウェア障害ハンドラーの障害回復コードが続きます。
• アセンブラがまだ知らない命令に対応するバイトのシーケンスを発行します。
• 別のスタックに注意深く切り替えてから別の関数を呼び出すコードを記述します。
• 特定のレジスタに引数を必要とするアセンブリルーチンまたはシステムコールを呼び出します。

+ 1e6

@eddyb

さて、私は本質的なアプローチを試して、それがどこに行くのかを見ていきます。 あなたはおそらく正しいでしょう、そしてそれは私の場合の最良のアプローチです。 ありがとうございました！

@joshtriplettはそれを釘付けにしました！ これらは私が念頭に置いていた正確なユースケースです。

loop {
   :thumbs_up:
}

他のいくつかのユースケースを追加します。

• BIOS / EFI呼び出しや16ビットリアルモードなどの奇妙なアーキテクチャモードでコードを記述します。
• 奇妙な/異常なアドレッシングモードでコードを書く（16ビットリアルモード、ブートローダーなどで頻繁に発生します）

@ mark-im絶対に！ そして、両方のリストにサブケースがあるポイントを一般化する：呼び出し規約間の変換。

私はこの問題に賛成して＃53118を締めくくり、記録のためにここにPRをコピーします。 これは8月のものですが、簡単に見てみると、状況は変わっていないようです。

インラインアセンブリのrustcと一般的なrust言語に関連付けられていることを意味します。 ドキュメント全体のほとんどは、llvmツールチェーンを使用したx86 / x86_64アセンブリに固有のものです。 明確にするために、私は明らかにプラットフォーム固有のアセンブリコード自体を参照しているのではなく、インラインアセンブリの一般的なアーキテクチャと使用法全体を参照しています。

ARMターゲットに関しては、インラインアセンブリの動作に関する信頼できる情報源は見つかりませんでしたが、実験とARM GCCインラインアセンブリのドキュメントを参照すると、次の点が完全にずれているようです。

• ARM / MIPS（および他のほとんどのCISC？）としてのASM構文は、最初に宛先レジスタでIntel風の構文を使用します。 ドキュメントは、インラインasmが実際のプラットフォーム/コンパイラ固有の構文にトランスパイルされたat＆t構文を取り、x86レジスタの名前をARMレジスタのみの名前に置き換える必要があることを意味/暗示していることを理解しました。
• 関連して、 intelオプションは無効であり、コンパイル時に「不明なディレクティブ」エラーが発生
• ARM GCCインラインアセンブリドキュメントからの適応（ arm-none-eabi-*ツールチェーンを使用してthumbv7em-none-eabiに対して構築する場合、インラインアセンブリの形式に関するいくつかの基本的な仮定でさえ、プラットフォーム固有であるように見えます。特に、 ARMの場合、出力レジスタ（2番目のマクロ引数）はレジスタ参照としてカウントされるようです。つまり、x86 llvm命令の場合のように、 $0は最初の入力レジスタではなく、最初の出力レジスタを参照します。
• 同時に、他のコンパイラ固有の機能は存在しません。 レジスタへの名前付き参照は使用できません。インデックスのみを使用できます（たとえば、 asm("mov %[result],%[value],ror #1":[result] "=r" (y):[value] "r" (x));は無効です）。
• （x86 / x86_64ターゲットの場合でも、インラインアセンブリの例で$0と$2を使用すると、これらの番号が選択された理由が説明されていないため、非常に混乱します。）

私を最も驚かせたのは、締めくくりの言葉だと思います。

asmの現在の実装！ マクロはLLVMのインラインアセンブラ式に直接バインドされているため、クローバーや制約などの詳細については、ドキュメントも確認してください。

これは普遍的に真実ではないようです。

ドキュメントは、インラインasmが実際のプラットフォーム/コンパイラ固有の構文にトランスパイルされたat＆t構文を取り、x86レジスタの名前をARMレジスタのみの名前に置き換える必要があることを意味/暗示していることを理解しました。

intelとat＆tの構文の概念は、x86にのみ存在します（ただし、私が気付いていない他のケースもあるかもしれません）。 これは、同じバイナリコードのセットを表すために、同じニーモニックのセットを共有する2つの異なる言語であるという点で独特です。 GNUエコシステムは、x86の世界の主要なデフォルトとしてat＆t構文を確立しました。これが、インラインasmのデフォルトである理由です。 LLVMのインラインアセンブラ式に直接バインドされているという点で誤解されています。LLVMのインラインアセンブラ式は、ほとんどの場合、（置換を処理した後の）プレーンテキストをテキストアセンブリプログラムにダンプするだけです。 これは、完全にプラットフォーム固有であり、x86の世界を超えて完全に無意味であるため、今日のasm!()固有（または関連性さえ）ではありません。

関連して、 intelオプションは無効であり、コンパイル時に「不明なディレクティブ」エラーが発生します。

これは、上記で説明した「ダム」/単純な平文の挿入の直接的な結果です。 エラーメッセージが示すように、 .intel_syntaxディレクティブはサポートされていません。 これは、GCC（attスタイルを出力）でIntelスタイルのインラインasmを使用するための古くてよく知られた回避策です。インラインasmブロックの先頭に.intel_syntaxと記述してから、いくつかのIntel-を記述します。 asmのスタイルを設定し、最後に.att_syntax終了して、アセンブラをattモードに戻し、（後続の）コンパイラで生成されたコードをもう一度正しく処理できるようにします。 これは汚いハックであり、少なくともLLVM実装には長い間奇妙な癖があったことを覚えているので、最終的に削除されたため、このエラーが表示されているようです。 残念ながら、ここでの唯一の正しい行動は、rustcから"intel"オプションを削除することです。

インラインアセンブリの形式に関するいくつかの基本的な仮定でさえ、プラットフォーム固有であるように見えます

あなたの観察は完全に正しいです、各プラットフォームはそれ自身のバイナリフォーマットとそれ自身のアセンブリ言語の両方を構成します。 これらは完全に独立しており、（ほとんど）コンパイラによって処理されません。これがrawアセンブラでのプログラミングの要点です。

レジスタへの名前付き参照は使用できず、インデックスのみを使用できます

悲しいことに、rustcが公開するLLVMのインラインasm実装とGCC（clangがエミュレートする）の実装の間にはかなり大きな不一致があります。 asm!()をどのように進めるかについての決定がなければ、これを改善する動機はほとんどありません。さらに、私はずっと前に主要なオプションの概要を説明しましたが、それらにはすべて明らかな欠点があります。 これは優先事項ではないように思われるので、少なくとも数年間は今日のasm!()で立ち往生するでしょう。 適切な回避策があります：

• オプティマイザーを使用して最適なコードを生成します（少し微調整するだけで、通常、生のアセンブリを自分で作成しなくても、必要なものを正確に取得できます）
• 組み込み関数を使用します。これは、ほとんどすべての点でインラインasmよりも優れたもう1つの非常に洗練されたソリューションです（命令の選択とスケジューリングを正確に制御する必要がある場合を除く）。
• build.rsからccクレートを呼び出して、Cオブジェクトをインラインasmにリンクします
  
  
  
  • 基本的には、 build.rsから好きなアセンブラを呼び出すだけです。Cコンパイラを使用するのはやり過ぎに思えるかもしれませんが、 build.rsシステムと統合する手間を省くことができます。
  
  

これらの回避策は、非常に特殊なエッジケースのごく一部を除くすべてに適用されます。 あなたがそれらの1つに当たった場合（幸いなことに私はまだです）、あなたは運が悪いです。

ドキュメントは非常に光沢がないことに同意しますが、インラインasmに精通している人には十分です。 そうでない場合は、おそらくそれを使用するべきではありません。 誤解しないでください-あなたは間違いなく自由に実験して学ぶべきですが、 asm!()は不安定で無視されており、本当に良い回避策があるので、可能な限り深刻なプロジェクトで使用しないことを強くお勧めします。

build.rsからcccrateを呼び出して、Cオブジェクトをインラインasmにリンクします

build.rsからccクレートを呼び出して、プレーンなアセンブリファイルを作成することもできます。これにより、最大限の制御が可能になります。 上記の2つの「回避策」がユースケースで機能しない場合に備えて、これを正確に実行することを強くお勧めします。

@ main--書き込み：

これらの回避策は、非常に特殊なエッジケースのごく一部を除くすべてに適用されます。 あなたがそれらの1つに当たった場合（幸いなことに私はまだです）、あなたは運が悪いです。

つまり、完全に運が悪いわけではありません。 Rustのinline asmを使用する必要があります。 リストされている回避策のいずれもここでカバーしていないというエッジケースがあります。 あなたが言うように、あなたが他のコンパイラからのプロセスに精通しているなら、それはほとんど問題ありません。

（別のユースケースがあります。いつかCの代わりにRustを使用してコンピューターアーキテクチャなどをプログラミングするシステムを教えたいと思います。インラインアセンブリがないと、これははるかに厄介になります。）

Rustでインラインアセンブリを優先し、後でではなく早く安定させたいと思います。 多分これはRust2019の目標になるはずです。 私はあなたが以前にあなたの素敵なコメントでリストした解決策のどれでも大丈夫です：私はそれらのどれの問題でも生きることができました。 アセンブリコードをインライン化できることは、私にとって、Cの代わりにRustをどこにでも書くための前提条件です。私はそれが安定している必要があります。

Rustでインラインアセンブリを優先し、後でではなく早く安定させたいと思います。 多分これはRust2019の目標になるはずです。

Rust 2019のブログ投稿を書いて、この懸念を表明してください。 私たちの十分な数がそれを行うならば、私たちはロードマップに影響を与えることができると思います。

上記の私のコメントを明確にするために-問題は、ドキュメントがasm!(..)マクロの内容がどのように「深く」解析/相互作用されるかを説明していないことです。 私はx86とMIPS / ARMアセンブリに精通していますが、llvmには独自のアセンブリ言語形式があると思います。 私は以前にx86のインラインアセンブリを使用しましたが、asmからbrigeCおよびASMへのろくでなしがどの程度進んだかは明確ではありませんでした。 rustインラインアセンブリセクションの文言に基づく私の推定（現在は無効）は、LLVMにはat＆tモードまたはIntelモードのいずれかでx86アセンブリを模倣するように構築された独自のASM形式があり、必然的に示されているx86の例のように見えるというものでした。

（私を助けたのは、展開されたマクロ出力を研究することでした。これにより、何が起こっているのかが明らかになりました）

そのページの抽象化を減らす必要があると思います。 LLVMによって解析されるものと、ASMとして直接解釈されるものを明確にします。 どの部品が錆に固有であり、どの部品が実行しているハードウェアに固有であり、どの部品がそれらを一緒に保持する接着剤に属しているか。

build.rsからccクレートを呼び出して、Cオブジェクトをインラインasmにリンクします

クロスランゲージLTOの最近の進歩により、この「外部アセンブリブロブ」を効果的にインライン化して、このアベニューの欠点のいくつかを減らすことができるかどうか疑問に思います。 （おそらくそうではありません）

build.rsからccクレートを呼び出して、Cオブジェクトをインラインasmにリンクします

クロスランゲージLTOの最近の進歩により、この「外部アセンブリブロブ」を効果的にインライン化して、このアベニューの欠点のいくつかを減らすことができるかどうか疑問に思います。

これが機能しても、インラインアセンブリをCで記述したくありません。Rustで記述したいと思います。 :-)

インラインアセンブリをCで記述したくありません。

.sファイルと.Sファイルを直接コンパイルしてリンクすることができます（たとえば、このクレートを参照）。これは、私の本ではCから十分に離れています。:)

この道の欠点のいくつかを減らすことができれば

クロスランゲージLTOはLLVMIRに依存しており、アセンブリではこれが生成されないため、これは現在実現可能ではないと思います。

クロスランゲージLTOはLLVMIRに依存しており、アセンブリではこれが生成されないため、これは現在実現可能ではないと思います。

アセンブリをLLVMIRモジュールのモジュールレベルのアセンブリに詰め込むことができます。

最新の提案/現在の状況を知っている人はいますか？ 今年のテーマは「始めたものの成熟と仕上げ」 asm 、ようやく

新しい（安定化される）構文の漠然とした計画が昨年2月に議論されました： https ：

それらのメモによると、 @ joshtriplettと@AmanieuはRFCを書くためにサインアップしました。

新しい構文のステータスはどうなっていますか？

それはRFCされ、毎晩実装される必要があります

ping @joshtriplett @Amanieuここで物事を進めるのを手伝ってくれるかどうか教えてください！ 間もなくご連絡いたします。

@cramertj AFAICT誰でもこれを前進させることができます。これはブロックされて介入して作業を開始するのを待っています。 全体的な設計をスケッチするpre-RFCがあり、次のステップはそれを実装し、それがprocマクロ、フォーク、または別の不安定な機能として実際に機能するかどうかを確認することです。

おそらく、そのpre-RFCを適切なRFCに変換して送信しようとすることもできますが、実装がなければ、そのようなRFCが説得力があるとは思えません。

編集：明確にするために、私は具体的にこのようなpre-RFCの一部を意味することを納得させることによって：

さらに、レジスタクラスのマッピングが必要に応じて追加されます（llvm-constraint 6を参照）。

lang-refには数十のarch固有のレジスタクラスがあります。 RFCはこれらすべてを単純に排除することはできず、それらがすべて想定どおりに機能するか、意味があるか、またはここから公開できるようにLLVMで十分に「安定」していることなどを確認することで、実装のメリットが得られます。これらを試してみてください。

RISC-Vインラインアセンブリはここで#![feature(asm)]サポートされていますか？

私の知る限り、サポートされているプラ​​ットフォームでのすべてのアセンブリがサポートされています。 これは、llvmコンパイラのasmサポートへのほぼ生のアクセスです。

はい、RISC-Vがサポートされています。 アーキテクチャ固有の入力/出力/クローバー制約クラスは、LLVMlangrefに文書化され

ただし、注意点があります。入力/出力/クローバー制約で個々のレジスタに制約する必要がある場合は、ABI名ではなく、アーキテクチャレジスタ名（x0-x31、f0-f31）を使用する必要があります。 アセンブリフラグメント自体では、どちらの種類のレジスタ名も使用できます。

これらの概念に不慣れな人として、私はただ言うことができます...この全体の議論は_ばかげている_ようです。 マシンコードとの1対1のマッピングであるはずの言語（アセンブリ）がこれほどの頭痛の種になるのはどうしてですか？

私はかなり混乱しています：

• asmを作成している場合、サポートしようとしているすべてのアーキテクチャとバックエンドに対して（ #[cfg(...)]人間が）書き直す必要はありませんか？
• これは、「構文」の質問が議論の余地があることを意味します...そのアーキテクチャの構文を使用するだけで、コンパイラがたまたま使用しているバックエンドです。
• Rustは、バイトを正しいレジスタに入れて、コンパイル対象のアーキテクチャのスタックにプッシュ/ポップできるようにするために、stdの安全でない関数が必要です。これも、すべてのアーキテクチャ、場合によってはすべてのバックエンドで書き直す必要があります。

下位互換性が問題になると思いますが、バグの数が非常に多く、これが安定しなかったという事実があるため、バックエンドに渡す方がよいかもしれません。 Rustは、LLVMやgcc、または他の誰かの奇妙な構文の間違いを修正しようとするビジネスに従事するべきではありません。 Rustは、対象となるアーキテクチャとコンパイラのマシンコードを発行するビジネスを行っています...そしてasmはすでに基本的にそのコードです！

ここで進展がない理由は、誰もこの問題の修正に時間を費やしていないためです。 これは、機能を安定させるための適切な理由ではありません。

このスレッドを読んでいる間、私はアイデアを思いつき、それを投稿しなければなりませんでした。 古い投稿に回答している場合は申し訳ありませんが、それだけの価値があると思いました。

@ main--言った：

どちらの最適化も確かに（特にハイパースレッディングに直面して）より良いスループットをもたらしますが、私が達成したいと思っていたレイテンシーの削減はありません。 私はその実験のためにnasmまでずっとドロップダウンすることになりましたが、コードを組み込み関数からプレーンasmに書き直さなければならないのは不必要な摩擦でした。 もちろん、高レベルのベクトルAPIを使用する場合は、オプティマイザーで命令の選択や定数畳み込みなどを処理する必要があります。 しかし、どの命令を使用するかを明示的に決定したとき、コンパイラーがそれをいじりたくないのです。 唯一の選択肢はインラインasmです。

インラインasmの代わりに、ここで本当に必要なのは、オプティマイザーに「スループット用にこれを最適化する」、「レイテンシー用にこれを最適化する」、「バイナリサイズ用にこれを最適化する」というLLVMの関数属性です。 このソリューションがアップストリームであることはわかっていますが、特定の問題を自動的に解決するだけでなく（レイテンシーを低くするだけでなく、アルゴリズムの同形実装を提供することで）、Rustプログラマーがパフォーマンス特性をよりきめ細かく制御できるようになります。それは彼らにとって重要です。

@ felix91grこれは、割り込みハンドラなど、命令の正確なシーケンスを発行する必要があるユースケースを解決しません。

@ mark-imはもちろん違います。 だから私は文字通りの引用をしました！ 🙂

私のポイントは、インラインasm機能を使用して、「コンパイラーが必要なものとは逆の方法で最適化する」（この場合は古典的です：レイテンシーとスループット）を解決できるとしても、おそらく（そして間違いなく）そのユースケースは最適化をよりきめ細かく制御することで、より適切に機能します:)

cc https://github.com/CraneStation/cranelift/issues/444#issuecomment -531574394

インラインアセンブリの今後の変更に照らして、この問題のほとんどの議論はもはや関連性がありません。 そのため、この問題を閉じて、インラインアセンブリのフレーバーごとに2つの個別の追跡問題を作成します。

• LLVMスタイルのインラインアセンブリの追跡の問題（ llvm_asm ）＃70173
• インラインアセンブリの問題の追跡（ asm! ）＃72016