シミュレーションタスクのアセンブラー。 パート2：シミュレーションの中核

<sup>HCF、n。 「Halt and Catch Fire」のニーモニック、破壊的な副作用を伴う、文書化されていない半神話的な機械命令のいずれか<...>

専門用語ファイル</sup>

以前の投稿で、コンピューティングシステムのソフトウェアモデル（シミュレーター）の開発におけるアセンブラーの応用分野についての講演を始めました。 ソフトウェアデコーダーの動作について説明し、単体テストを使用してシミュレーターをテストする方法についても説明しました。

この記事では、シミュレーターの等しく重要なコンポーネントであるカーネルを作成する際に、プログラマーがマシンコードの構造に関する知識を必要とする理由を説明します。カーネルは個々の命令のモデリングを担当します。

これまでのところ、議論は主にゲストアセンブラーに焦点を当ててきました。 アセンブラーマスターについてお話します。

アセンブラーを中心に-シミュレーターの中核

本格的なシミュレーション製品には、 マルチカメラの 「ハート」が必要です。ゲストコードを実行するいくつかの方法です。 常に、最も効果的なものが使用されます。

一般に、解釈、バイナリ変換、および直接実行の3つのテクノロジーが区別されます。 そして、それぞれにマシンコードとアセンブラの場所があります。

通訳と組み込み

最もシンプルなインタープリターベースのシミュレーターは、移植可能な高レベル言語で書かれています。 つまり、命令を記述するすべてのプロシージャは、そのロジックをCで実装するだけです。

機械語命令の大部分は、Cで簡単に表現できるかなり単純なセマンティクスを持っています。2つの数値を加算し、3番目の数値と比較し、左にシフトし、右にシフトします。

特権命令は、通常、さまざまなアクセスチェックを実行して例外をスローする必要があるため、より複雑です。 ただし、それらの数は比較的少ないです。

困難が生じます。 IEEE 754番号で機能する手順は次のとおりです。 浮動小数点、「浮動」。 これらの数値のいくつかの形式（float16からfloat32、float64、場合によっては準標準のfloat80、さらにはfloat82まで）を正しく処理する必要があります。 標準ではそれらを説明していますが、まだfloat128を直接サポートしているアーキテクチャはないようです。 非NaN数、非正規化数を維持し、丸めモードと例外シグナルを考慮します。 また、サイン、ルート、逆数値など、あらゆる種類の算術演算を実装します。

いくつかのヘルプは、非常に多くの標準を実装するオープンSoftfloatライブラリです。

シミュレートが困難な命令のクラスの別の例は、ベクトルSIMDです。 これらは、同じタイプの引数のベクトルに対してすぐに1つの操作を実行します。 第一に、整数オペランドもありますが、「浮力」でもよく機能します。 第二に、組み合わせ効果のため、このような命令が多数あります。各操作には、いくつかの長さのベクトルと要素形式、マスク形式、「ミキシング」ブロードキャストのオプションの使用、収集/分散などがあります。

必要なすべてのゲスト指示のエミュレート手順を正常に実装すると、モデルの作成者は非常に低いインタープリター速度に遭遇する可能性が高くなります。 これは驚くべきことではありません。1つの命令で実際のマシンで行われることは、すべてのエッジスクリプトを計算する内部ループと非自明なロジックを持つプロシージャとしてモデルに表示されます。 命令のセマンティクスを実装するための何かが、すぐに実行されたら！

少し待ってください。ただし、ホストプロセッサにはおそらくまったく同じまたは少なくとも非常によく似た命令があります。 皆のためではなく、少なくとも一部のためにしましょう。 さらに、一般的なコンパイラは、コードにマシン命令を含めるためのインターフェースを提供します- 組み込み （英語組み込み-内部）-マシン命令をラップする関数の説明。 Intel SDMの LZCNT命令の組み込み記述の例：

インテルC / C ++コンパイラ組み込み関数

LZCNT：

符号なし__int32 _lzcnt_u32（符号なし__int32 src）;

LZCNT：

符号なし__int64 _lzcnt_u64（符号なし__int64 src）;

GCCでも同じ組み込み関数が機能します。 以下では、少し実験を行いました。

$ cat lzcnt1.c #include <stdint.h> #include <immintrin.h> int main(int argc, char **argv) { int64_t src = argc; int64_t dst = _lzcnt_u64(src); return (int)dst; } $ gcc -O3 -mlzcnt lzcnt1.c #   , ..     LZCNT $ objdump -d a.out <......> Disassembly of section .text: 00000000004003c0 <main>: 4003c0: 48 63 c7 movslq %edi,%rax 4003c3: f3 48 0f bd c0 lzcnt %rax,%rax 4003c8: c3 retq 4003c9: 90 nop 4003ca: 90 nop 4003cb: 90 nop <......>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最適化フラグ-O3



コンパイラはすべてを_lzcnt_u64()



しました。「関数」 _lzcnt_u64()



から、プロローグまたはエピローグはなく、必要なマシン命令のみがありました。

機械命令のように、通常多くの組み込み関数があります（ただし、命令よりも少ないです）。 各コンパイラーは独自のセットを提供しますが、他のコンパイラーとは多少異なります。

• Microsoftコンパイラに存在する組み込み関数は、MSDNのx86およびx64で個別に説明されています。
• インテルC / C ++コンパイラーのドキュメントは、数年前からWebページで便利なインタラクティブ形式で入手できます 。 拡張クラス（SSE2、SSE3、AVXなど）および機能（ビット操作、論理、暗号化など）でフィルターし、セマンティクスと速度に関するヘルプを取得することは非常に便利です。対策）。
• IA-32用のGCCコンパイラーの組み込み関数は、ICCについて説明したものと基本的に同じです。
• Clangの場合、どのアーキテクチャでも利用可能な組み込み関数に関する明確なドキュメントは見つかりませんでした。 読者がこの問題に関する関連情報を持っている場合は、コメントで共有してください。

手書きのインラインアセンブラセクションと比較して、組み込み関数には次の利点があります。

1. 関数呼び出しははるかに馴染みがあり、理解しやすく、作成時にそれを損なう可能性が低くなります。 組み込み関数は、入力および出力レジスタの割り当て作業をコンパイラに転送し、構文チェック、型一致、およびその他の有用なことを実行し、必要に応じて問題を報告することもできます。 インラインコードの場合、アセンブラー診断ははるかに不可解です。 しばしばGNUのclobber仕様を記述しなければならない（そしてそれらに誤りを犯す）人は誰でも私に同意します。
2. コンパイラ向けの組み込み関数は、インラインアセンブラの「ブラックボックス」ではありません。インラインボックスでは、未知のレジスタとメモリの更新が発生します。 したがって、そのレジスタ割り当てアルゴリズムは、プロシージャコードを処理するときにこれを考慮することができます。 その結果、より高速なコードを簡単に取得できます。
3. 組み込み関数は弱いですが、コンパイラ間で移植可能です（ホストアーキテクチャは移植できません）。 極端な場合、ホストアーキテクチャが命令を直接サポートしていない場合、実装のプロトタイプを作成できます。 ケーススタディ：SSE2命令CVTSI2SD xmm, r/m64
   
   
   
   は、32ビットプロセッサモードで有効なエンコードがありません。 したがって、64ビットモードではツールが最初に開発されたが、組み込みであり、コードはそれを使用していましたが、組み込み関数はありません。 32ビットホストでコードをコンパイルすると、エラーがスローされました。 この組み込み関数に関連付けられたプロシージャは「ホット」ではなかったため（アプリケーションの速度はわずかに依存していました）、独自の_mm_cvtsi64_sd()
   
   
   
   実装はCで記述され、32ビットアセンブリに置き換えられました。

これらまたはその他の理由により、Microsoft は x64アーキテクチャのMS Visual Studio 2010以降でのインラインアセンブラーのサポートを停止しました。 この場合、マシンコードをC / C ++ファイルに挿入するには、組み込み関数のみを使用できます。

ただし、組み込み関数の使用は万能薬であると言って、真実に反するでしょう。 それでも、コンパイラーによって生成されたコードに注目する必要があります。特に、 最大限のパフォーマンスを引き出したい場合は注意が必要です。

バイナリトランスレータとコード生成

バイナリトランスレータ（以降DTと呼びます）は、ゲストマシンコードのブロック全体をホストマシンコードの同等のブロックに変換し、ホットコードの場合は繰り返し実行されるため、通常はインタープリターよりも高速に動作します。 インタプリタ（キャッシングが実装されていない場合）は、たとえ最近使用したとしても、最初から遭遇した各ゲスト命令を強制的に処理します。

また、ホストアーキテクチャの機能を使用せずに最初から最後まで記述できるインタープリターとは異なり、DTはアセンブラーと機械語命令のエンコードの両方の知識を必要とします。 シミュレータを新しいホストシステムに転送する場合、コード生成に正確に関与する重要な部分を書き換える必要があります。 これは速度の代価です。

この記事では、いわゆるテンプレートトランスレーターを作成する簡単な方法の1つについて説明します。 興味がある場合は、別の機会に、バイナリ翻訳のより高度な方法についてお話します。

デコーダーからゲストの命令に関する情報を受け取ったDTは、そのためのマシンコード、つまりカプセルを生成します。 順次実行される複数の命令について、順番に記録されたカプセルで構成される翻訳単位が作成されます。 その結果、ゲストシステム内の最初の翻訳された命令に制御が移るとき、このコマンドと後続のコマンドをシミュレートするには、翻訳ユニットからコードを実行するだけで十分です。

オペコードとオペランドの値を知って、ゲスト命令のコードを生成する方法は？ オペコードに従って、シミュレーターはテンプレートを選択します。これは、目的のセマンティクスを実装するホストマシンコードのプレフィックスです。 このようなテンプレートを単一の翻訳単位に直接「接着」するため、プロローグとエピローグが存在しないという点で、コンパイラによって通常作成される手順とは区別されます。 ただし、これでもまだ翻訳単位を準備完了としてマークするには十分ではありません。

別のタスクは未達成のままでした-オペランドの値を引数としてテンプレートに渡し、テンプレートを特殊化してカプセルに変換します。 さらに、ほとんどの場合、オペランドを変換の段階で正確に転送する必要があります。それらは既にわかっています。 つまり、カプセルのホストコードに直接「縫い付ける」必要があります。 暗黙のオペランド（たとえば、スタックにある値）では、これは機能せず、もちろん、時間を浪費しながら、シミュレーション段階で処理する必要があります。

明示的なオペランドのセットの次元（=組み合わせの数）が小さい場合、これらの組み合わせは、この命令のパターンのグループ（組み合わせごとに1つ）に「縫い付ける」ことができます。 その結果、ゲストオペコードごとに、オペランドが特定の各ケースで使用した値に応じて、N個のパターンから選択する必要があります。

残念ながら、すべてがそれほど単純ではありません。 実際には、オペランドの数の組み合わせが爆発的に増えるため、オペランドのすべての可能な値のパターンを生成することは不可能な場合がよくあります。 したがって、32個のレジスタを持つアーキテクチャでの3オペランドコマンドには、32×32×32 =2¹⁵ブロックのコードが必要です。 また、ゲストアーキテクチャに32ビット幅のリテラルオペランド（およびすべての重要なオペランド）がある場合、2³²のカプセルオプションを格納する必要があります。 あなたは何かを考え出す必要があります。

実際、ほとんど同一のテンプレートの束を保存する必要はありません-それらはすべて同じ所有者の指示を含んでいます。 ゲストオペランドを変更すると、ホストオペランドの一部のみが変更されます（ただし、命令の長さは以前の投稿を参照してください）。シミュレートされた状態の格納場所または送信されるリテラルが記述されます。 テンプレートからカプセルを作成するときは、対応するオフセットでビットまたはバイトを「パッチ」するだけです。



愛好家への質問：上記の例のどのアーキテクチャがゲストおよびホストとして使用されていますか？



したがって、DTを使用したシミュレーターの各ゲスト命令には、1つのマスターホストコードテンプレートと、正しいオペランドの元のオペランドを修正する1つのプロシージャで十分です。 当然、テンプレートに正しくパッチを適用するには、すべてのオペランドの先頭に対するオフセットを知る必要があります。つまり、ホストシステムのコマンドのエンコードを理解する必要があります。 実際、独自のエンコーダーを実装するか、何らかの方法でサードパーティツールの作業から必要な情報を分離する方法を学習する必要があります。

一般に、テンプレートの変換プロセスを次の図に示します。

直接実行と仮想化

私が検討している3番目のシミュレーションメカニズムは、直接実行です。 その動作の原理は名前に直接従っています-ゲストコードをシミュレートし、変更せずにホスト上で起動します。 明らかに、この方法は潜在的に最高のシミュレーション速度を提供します。 しかし、彼は最も「ムーディー」でもあります。 以下の要件を満たす必要があります。

1. ゲストとホストのアーキテクチャは一致する必要があります。 つまり、MIPSでARMのコードを直接シミュレートすることはできません。その逆も同様です。 いずれにしても、これは直接実行されません。
2. ホストアーキテクチャは効果的な仮想化の条件を満たさなければなりません。

ゲストアーキテクチャが指定された条件（たとえば、Intel®VT-x拡張を備えたIntel IA-32 / Intel 64）を満たしていると仮定します。 シミュレータに直接実行のサポートを追加するときに発生する次のタスクは、オペレーティングシステムのカーネルモジュール（ドライバー）の作成です。 これなしでは実行できません。シミュレータは特権命令を実行し、ページテーブル、物理メモリ、割り込みなどのシステムリソースを操作する必要があります。 ユーザーのスペースからはアクセスできません。 一方、カーネルを完全に「掘り下げる」ことは有害です。ドライバーのプログラミングとデバッグは、アプリケーションプログラムを書くよりもはるかに時間と労力がかかります。 したがって、通常は、システムコールインターフェイスを介してアクセスされる最小限のシミュレーター機能のみがカーネルに持ち出されます。 私が知っているすべての仮想マシンとシミュレーターは、直接実行を使用することで、カーネルモジュールとそれを使用するユーザーアプリケーションのように設計されています。

カーネルモジュールは特定のOSに書き込まれるため、アプリケーションを別のOSに転送するときは、おそらく非常に強力に書き換える必要があることを理解する必要があります。 これは、サイズを最小化するもう1つの理由です。

原則として、カーネルでのアセンブラーの使用は、ユーザーランドとほぼ同じ条件下で正当化されます。つまり、それなしではできない場合です。 仮想マシンは、VMCS（仮想マシン制御構造）、制御、デバッグ、モデル固有のレジスタなどのシステム構造と連携します。これらのレジスタは、特殊な命令でのみ利用できます。 それらに組み込み関数を使用するのが最も合理的ですが、...

すべての機械語命令に既製の組み込み関数があるわけではありません。 主にユーザーコードをビルドするように設計されたコンパイラーでは、ドライバーライターのニーズをどうにかして忘れてしまいます。 それらにアクセスするには、インラインアセンブラを使用する必要があります。 たとえば、KVM仮想マシンのソースコードには、VMCSフィールドを読み取るための関数の定義があります。

 #define ASM_VMX_VMREAD_RDX_RAX ".byte 0x0f, 0x78, 0xd0" static __always_inline unsigned long vmcs_readl(unsigned long field) { unsigned long value; asm volatile (__ex_clear(ASM_VMX_VMREAD_RDX_RAX, "%0") : "=a"(value) : "d"(field) : "cc"); return value; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

正直なところ、 vmread



ではvmreadニーモニックのVMREAD呼び出しを期待していますが、何らかの理由でバイト形式の生の表現が使用されています。 たぶんこの方法で、著者はそのような命令を知らないコンパイラでアセンブリをサポートしたかったでしょう。

ところで、上記の例のLZCNTの固有の例は、次のようにインラインアセンブラ形式を使用して書き換えることができます。 この単純なケースでは、マシンコードは同じように生成されます。

 #include <stdint.h> int main(int argc, char **argv) { int64_t src = argc; int64_t dst; __asm__ volatile( "lzcnt %1, %0\n" :"=r"(dst) :"r"(src) :"cc" ); return (int)dst; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この記事では、GNUインラインアセンブラ形式の機能について詳細に説明するつもりでしたが、これを行わないことにしました。 このトピックに関する多くの情報がインターネット上にあります。 それでも必要な場合は、次の記事でこれを行うことができます。

アセンブラ全体を1つのファイルにアセンブルする方が、Cコードにアセンブルするよりも有益です。 KVMの例は見つかりませんでしたが、 Xenの例がありました。 このファイルでは、アセンブラ自体の量は4分の1以下であり、残りはこのコードの機能とそのインターフェースを文書化したプリプロセッサディレクティブとコメントです。

まとめ

アセンブリ言語は、シミュレーションソリューションの開発において重要な役割を果たします。 これは、モデルのさまざまなコンポーネントで使用されるほか、モデルをテストするプロセスでも使用されます。

高レベル言語も使用する複雑なプロジェクトのアセンブラーコード自体は、3つの方法で表すことができます。

1. 組み込み関数は、通常のC / C ++関数のインターフェースを備えた個々のマシン命令のラッパーです。
2. アセンブラー挿入-選択したコンパイラー/アセンブラーに固有のアセンブラーコードのフラグメントで、それらを取り巻く高レベルのコードと一致します。
3. 完全にアセンブラーで記述されたファイル-アクションの特定のシーケンスを完全にアセンブラーで表現する方が便利な（まれな）場合に使用されます。 これらは、関数インターフェイス（目的のプラットフォームのABIを独立して実装する）を介して、または何らかの方法で相互作用しない（独立した単体テストの場合）のいずれかを通じて、外部の世界と対話します。