BIOSプログラムの記述に使用されているプログラミング言語はどれですか。
私が理解しているように、ROMに保持されているBIOSコード/ビットストリームは、一般的なものである必要があります（複数のCPUタイプまたはISAと一緒に動作します）。さらに、そのコードをダンプする（そしてそれを「逆アセンブルする」）ことが可能です。
それでは、どの言語、命令セット、またはマシンコードで記述されているのでしょうか？その操作を実行するために、どのような種類のプロセッサも必要ありませんか？もしそうなら、私はそれが外部CPUを使用すると思います、そしてそれはどうやってそれは採用されたものの特定の命令セットを知るのですか？
多分それは内部プロセッサを持っていますか？
BIOSは、以前はアセンブリ言語でのみ記述されていましたが、コードの大部分をより高いレベルの言語で記述し、アセンブリのできるだけ少ない部分（できればブートストラップのみ）で記述するように移行されました。 （開始/リセット後にCPUがジャンプする最初の数百の命令）そして、どのようなルーチンも、基礎となるアーキテクチャの特定の癖を扱います。
BIOSはすでに90年代初頭には主にCで書かれていました。 （私は90年代前半に90％C、10％アセンブリでBIOSを書きました。）
この方向に大きく貢献したのは次のとおりです。
特定のアーキテクチャーをターゲットとし、そのアーキテクチャーの特殊性に対処するための関数、たとえば、x86アーキテクチャーのI/Oポートとの間でバイトを読み書きするための関数を含むCライブラリ。 Microsoft Cは、常にその種のライブラリ関数を提供してきました。
特定のCPUアーキテクチャをターゲットにするだけでなく、特別なCPU機能を利用するコードを作成するために使用できるC言語の拡張機能さえ提供するCコンパイラ。たとえば、x86アーキテクチャは、割り込みハンドラと呼ばれるルーチンを呼び出す割り込みと呼ばれるものをサポートしており、特別な入口/出口命令シーケンスが必要です。非常に早い時期から、Microsoft Cは、関数を割り込みハンドラとしてマークするために使用できる特別なキーワードをサポートしていたため、CPU割り込みによって直接呼び出すことができ、そのためのアセンブリを記述する必要がありませんでした。
今日では、BIOSのほとんどがC++で記述されていると想定しています。
BIOSを構成するコードの大部分は基盤となるハードウェアに固有であるため、実際に移植可能である必要はありません。常に同じタイプのCPUで実行されることが保証されています。 CPUは進化する可能性がありますが、以前のバージョンとの下位互換性を維持している限り、BIOSを変更せずに実行できます。さらに、必要に応じて、Cで記述されたBIOSの一部をいつでも再コンパイルして、起動する新しいCPUでネイティブに実行できます。
BIOSをAssemblyよりも高いレベルの言語で記述する理由は、BIOSを実際に移植可能にする必要があるからではなく、このように記述する方が簡単だからです。
理論的には任意の言語でBIOSを記述できますが、現代の現実はほとんどのBIOSはアセンブリ、C、またはその2つの組み合わせを使用して記述されています。
BIOSは マシンコード にコンパイルできる言語で書かれている必要があります。これは、物理的なハードウェアマシンによって認識されます。これにより、直接または中間的に解釈される言語（Perl、Python、PHP、Ruby、Java、C＃、JavaScriptなど）がBIOSの記述に適切であるとして排除されます。 （理論的には、静的マシンコードに直接コンパイルするためにこれらの言語の1つを実装することも、なんらかの方法でインタプリタをBIOSに埋め込むこともできます。たとえば、 abandonware GCJプロジェクト Java。）
ほとんどのOEMは、 American Megatrends や Phoenix Techologies などの企業による独自の汎用BIOS実装を拡張してBIOSを実装しています。 （おそらく、これらの企業の1つがコンピューターの最初の起動画面に表示されるのを見たことがあるでしょう。）これらの実装のソースコードは公開されていませんが、一部はリークされています。私はこれをCおよびアセンブリのソースコードに直接リンクしたくありませんが、 このソースコードが議論されているインターネット上の場所 を覗き見したい人のためにあります。
一部のハードウェアメーカーは、高性能およびゲーム市場をターゲットとするメーカーのように、カスタマイズ機能、統計、および正確な実装用に設計された魅力的なユーザーインターフェイスでBIOS実装を飽和させています。これらの機能の多くは、American Megatrendsやその他の製品によって生成されるジェネリック製品で提供されるものを超えています。残念ながら、これらの企業はしばしば セキュリティリスクとしてのソースコードのリリースを参照 なので、これらのハイエンド実装についてはほとんど共有されていないため、ほとんど知られていません。もちろん、そのようなBIOS実装にアクセスして逆コンパイルする方法を見つけることはできますが、そうすることは難しく、おそらく違法である可能性があります。
元の質問に戻ると、ネイティブマシンコードを生成する必要があるため、BIOSは ネイティブマシンコードコンパイラでサポートされているプログラミング言語 で実装する必要があります。多くのそのような言語があり、過去数十年にわたって確信している一方で、いくつかの言語が実験で使用されてきましたが、私が見つけることができるすべてのオープンBIOS実装は、Cおよび/またはアセンブリの組み合わせに特に依存しています。この結論を形成するために私が調べたオープンソースのBIOS実装には、 OpenBIOS 、 tinyBIOS 、 coreboot 、 Intel BIOS が含まれます。 、および Libreboot 。また、今日は関係ないが、Cやアセンブリの規則に従っている非常に古いBIOS実装もいくつか見ました。
ハードウェアと直接対話するように構築された他のソフトウェアを検討することも重要だと思います。たとえば、 Linuxカーネル 、 OS Xカーネル 、および Windowsカーネル の大部分はCであり、一部のアセンブリとそれ以上特定のタスクのレベル言語。 Linuxのハードウェアドライバー および Windowsのハードウェアドライバー は主にCで記述されていることもわかっています。
BIOSに戻ると、選択したプログラミング言語の経済性を考慮することも重要だと思います。 BIOSは通常、ハードウェアの販売を補完するために必要なものとして作成されています。最近のBIOSシステムは、主にCやアセンブリで記述されていることが知られています。他のいくつかのツールへの移行は、販売に非常に悪影響を及ぼす可能性のある、一般に商品と見なされるものにかなりのコストを追加します。 Economics 101に入るまでもなく、何十年にもわたって実証されてきた実績のあるツールから逸脱することは、OEMにとっておそらく価値がないことは間違いありません。
もちろん、BIOSを作成する趣味のプロジェクトもあります。これらも、これまでのところ、Cやアセンブリを選択しているようです。おそらくいつか他の技術が使われるでしょう。しかし、今日の選択は明確です。
コンピュータの実際のBIOSは、アーキテクチャに依存するバイナリコードにコンパイルされる言語（おそらくCまたはアセンブリ）で記述されます。このコードは、他のどのアーキテクチャでも実行できません（そして、それは出荷されたマシンにすでに非常に固有であるため、間違いなく実際には必要ありません）。
しかし、あなたはおそらく オプションROM （GPUオプションROMの「ビデオBIOS」のように、BIOSと呼ばれることもあります）について考えていますか？
実際のレガシーBIOS互換オプションROMの場合、おそらくISA依存する実行可能コード（これも、目的のアーキテクチャをターゲットとするようにコンパイルできる任意の言語によって生成されます）です。PCIも複数のISAのコードを含み、ホストが起動プロセス中に適切なバイナリイメージを選択できるようにします。
UEFI互換のオプションROMの場合、異なるアーキテクチャで実行できる アーキテクチャに依存しないバイトコード形式 もありますが、ISAに依存するコードも引き続き使用できます。