BIOSプログラムの作成に使用されるプログラミング言語はどれですか？

私が理解しているように、ROMに保持されているBIOSコード/ビットストリームは汎用である必要があります（複数のCPUタイプまたはISAと一緒に動作します）。さらに、Webで、コードをダンプ（および「逆アセンブル」）できることが言及されています。

それで、どの言語、命令セットまたはマシンコードで書かれていますか？操作を実行するのに、どんな種類のプロセッサーも必要ではありませんか？もしそうなら、私はそれが外部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を作成する理由は、実際に移植性が必要なためではなく、この方法で作成する方が簡単だからです。

理論上はどの言語でもBIOSを記述できますが、現代の現実では、ほとんどのBIOSはAssembly、C、または2つの組み合わせを使用して記述されています。

BIOSは、マシンコードにコンパイルできる言語で記述されている必要があります。これは、物理的なハードウェアマシンによって理解されます。これにより、直接または中間的に解釈される言語（Perl、Python、PHP、Ruby、Java、C＃、JavaScriptなど）をBIOSの記述に適したものとして排除します。（理論的には、これらの言語の1つを実装して静的マシンコードに直接コンパイルするか、何らかの方法でインタプリタをBIOSに埋め込むことができます。たとえば、Java用の放棄ソフトウェアGCJプロジェクトがあります。）

ほとんどのOEMは、American MegatrendsやPhoenix Techologiesなどの企業による独自の汎用BIOS実装を拡張してBIOSを実装しています。（おそらく、これらの会社の1つがコンピューターの最初のブート画面に表示されるのを見たことがあるでしょう。）これらの実装のソースコードは公開されていませんが、その一部は漏えいしています。これをCおよびアセンブリのソースコードに直接リンクさせたくはありませんが、インターネット上には、このソースコードが覗きたい人のために議論されている場所があります。

高性能およびゲーム市場をターゲットとするハードウェアメーカーの一部は、カスタマイズ機能、統計、および正確な実装用に設計された魅力的なユーザーインターフェイスでBIOS実装を飽和させています。これらの機能の多くは、American Megatrendsなどが生産するジェネリック製品で提供されるものを超えています。残念ながら、これらの企業はソースコードのリリースをセキュリティリスクと見なすことが多いため、これらのハイエンドの実装についてはほとんど知られていないため、これらのハイエンドの実装についてはほとんど知られていません。もちろん、そのようなBIOS実装にアクセスして逆コンパイルする方法を見つけることはできますが、そうすることは難しく、おそらく違法かもしれません。

元の質問に戻ると、ネイティブマシンコードを生成する必要があるため、ネイティブマシンコードコンパイラがサポートするプログラミング言語でBIOSを実装する必要があります。このような言語は多数ありますが、過去数十年にわたって確かにいくつかの言語が実験に使用されてきましたが、私が見つけたすべてのオープンBIOS実装は、Cおよび/またはアセンブリの組み合わせに特に依存しています。この結論を形成するために私が調べたオープンソースのBIOS実装には、OpenBIOS、tinyBIOS、coreboot、Intel BIOS、およびLibrebootが含まれます。。また、今日関係のない非常に古いBIOS実装もいくつか見てきましたが、Cおよび/またはアセンブリルールにも従いました。

ハードウェアと直接やり取りするために構築された他のソフトウェアを見るのも重要だと思います。たとえば、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に依存するコードも使用できます。