私はどのような状況でも OS をプログラムするのに適していませんが、これは仮説です。
アセンブリ言語でほぼゼロから簡単なオペレーティング システムを作成したいと考えています。大きな野心を念頭に置いて、実行のために可能な限り最適化したいと考えています。また、コードが複数のアーキテクチャ (特に x86 と x64 は交換可能) に対してかなり移植可能であることも望んでいます。私は少しミニマリストな気がするので、ソフトウェアの「肥大化」を放り出しましょう。
私が探しているのは、この基準を満たすことができるアセンブラです。明らかに、私は公式または非公式に適切に文書化されたものを望んでおり、それが適切に知られている必要があります（つまり、インターネットサハラの真ん中で「ΣASM」を見つけたくありません. ）
あなたが指定した状況では、おそらく NASM が最良の選択でしょう。十分に文書化されており、かなり広く使用されており、十分にテストされています。また、生のバイナリ出力ファイルを直接生成できる数少ないファイルの 1 つでもあります。ほとんどの場合、それを取得するにはリンカーを使用してジャンプする必要があります。これは、ブートローダの問題ほど OS 自体の問題ではありませんが、(何らかの理由で) OS で作業しているほとんどの人は、少なくともいくつかのおもちゃのブートローダも作成しています。
あなたは自分自身と大きく矛盾しています。x86 での実行を最適化することはできません。特に 32 ビットと 64 ビットの間でジャンプする場合、各ファミリは劇的に異なる速度で同じバイナリを実行できます。x86 での速度が目標の場合は、asm で記述せず、C を使用してから、たまたま使用しているプラットフォームに合わせてコンパイラを最適化します。大規模なプロジェクトの場合、コンパイラと競合することはできません。コンパイラで生成された短いコード シーケンスの場合は、そうです。x86 の場合、コンパイラは x86 上で平均的な速度で、あなたよりも優れた仕事をする可能性があります。肥大化は必ずしもコンパイラや言語に起因するとは限りませんが、選択した言語の設計と実装に起因します。肥大化した C またはその他のように肥大化した asm を持つのは非常に簡単です。
2 つ目は、アセンブリ言語で記述している場合です。このコードのどの程度が命令であり、どの程度がアセンブラ固有のディレクティブやその他のニュアンスであると予想されますか? 少なくとも、それらのアセンブラーで共有される最小限の数のディレクティブを使用して、異なるアセンブラーで動作するある程度移植可能な asm を作成することを試みることができます。残りは命令です。x86 には残念ながらここにも問題があります。まず intel と at&t の構文の問題があり、バイト ptr と Near/Far アイテムを使用して、Intel 構文に限定されている特定の命令のフレーバーをアセンブラーに伝えます。 x86 アセンブラから別のアセンブラへ。ラズベリー パイは 25 ドル、ビーグルボーンは 90 ドルで購入できます。
x86 アセンブリはせいぜい恐ろしいものであり、バンドエイドの上に何十年ものバンドエイドがあります (前身 + バンドエイドであったオリジナルから始まります)。適切なサイズのアセンブリ プロジェクトを実行する必要があると感じた場合 (C などのより便利なものに対して)、特に速度が目標の場合は、より優れたプロセッサと命令セットを選択してください。プロジェクトの規模がわかりません。十分に小さい場合は、thumb、thumb2、arm、avr、または msp430 になり、大きい場合は、arm または mips になります。悲しいことに、ほとんどの場合、おそらく gnu binutils を使用するでしょう。x86の場合、その命令セットとそのハードウェアを使用する必要があると本当に思うなら、私はジェリーに同意します.nasmを使用してください.