Go Wiki: AssemblyPolicy

このドキュメントでは、Goの暗号化パッケージにアセンブリコードを追加するタイミングと方法について説明します。

一般的に、ルールは以下のとおりです。

• 私たちは、アセンブリではなく、移植可能なGoを好みます。アセンブリでコードを作成すると、N個のパッケージではなく、（N個のパッケージ * M個のアーキテクチャ）を保守する必要があります。
• アセンブリの使用を最小限に抑えます。55%の高速化のために2倍のアセンブリを使用するよりも、50%の高速化のために少量のアセンブリを使用することを好みます。コミットメッセージにアセンブリ/Goの境界をどこに置くかについての決定を説明し、ベンチマークでそれをサポートしてください。
• スタンドアロンのGoプログラムや、avoのようなgo get可能なプログラムなど、高レベルのプログラムを使用して、非自明な量のアセンブリを生成します。他の再現可能なプロセス（正式に検証されたコードジェネレータなど）の出力も考慮されます。実装戦略については、事前にイシュートラッカーで話し合ってください。
• Goで記述された高レベルのロジックから呼び出される、小さくテスト可能なユニット（25〜75行）を使用します。Goで記述されたロジックから呼び出される小さくテスト可能な関数を使用するのが遅すぎる場合は、Go互換のラッパーを持つ小さくテスト可能なアセンブリユニットを使用することで、Goテストで個々のユニットをテストできます。
• すべてのアセンブリ関数には、アセンブリと並行してテストされる、参照用のGo実装が必要です。構造とテスト方法については、TargetSpecificに従ってください。
• プラットフォームが根本的に異なる機能（高レベルの暗号化命令など）を持っている場合を除き、アセンブリユニットと参照Go実装のインターフェースは、アーキテクチャ全体で同じである必要があります。
• Goセキュリティチームが特定の実装の所有を明示的にコミットしない限り、外部の貢献者はそれを維持することをコミットする必要があります。変更が必要な場合（たとえば、より広範なリファクタリングの一部として）で、メンテナが利用できない場合、アセンブリは削除されます。
• コードはCIでテストする必要があります。これは、命令をサポートするビルダが必要であり、複数の（またはフォールバック）パスがある場合は、それらを個別にテストする必要があることを意味します。（ヒント：GODEBUG=cpu.X=offを使用してCPU機能の検出を無効にします。）
• コンパイラの改善に伴い再評価できるように、実装にアセンブリが必要な理由（特定のパフォーマンス上の利点、命令へのアクセスなど）をGoコードに文書化してください。

標準ライブラリにあるすべてのアセンブリがこのポリシーに準拠しているわけではありません。実装が準拠するように更新されるまで、既存のアセンブリの変更は推奨されません。新しいアセンブリは準拠している必要があります。

このコンテンツはGo Wikiの一部です。