私が理解しているように、ROMに保持されているBIOSコード/ビットストリームは汎用である必要があります（複数のCPUタイプまたはISAと連携して機能します）。さらに、そのコードをダンプする（そしてそれを「逆アセンブル」する）ことが可能であるとウェブ上で言及されているのを見ました。
では、どの言語、命令セット、または機械語で書かれていますか？ 「操作を実行するのに何らかのプロセッサは必要ありませんか？もしそうなら、外部CPUを使用すると思いますが、使用されているものの特定の命令セットをどのように知るのでしょうか？
多分それ内部プロセッサがありますか？
コメント
回答
BIOSは、以前はアセンブリ言語でのみ記述されていましたが、移行はずっと前に行われ、コードの大部分を高級言語で記述し、アセンブリで記述されたままにして、可能な限り少ない部分、できればブートストラップのみ（CPUがジャンプする最初の数百の命令）を残します。開始/リセット後まで）、および基盤となるアーキテクチャの特定の癖を処理するルーチンはすべて。
BIOSは、90年代初頭にはすでに主にCで記述されていました。 （私は90％CでBIOSを作成し、90年代初頭に10％アセンブリを作成しました。）
この方向でも大いに役立ったのは：
-
C特定のアーキテクチャを対象とし、そのアーキテクチャの特性を処理するための関数、たとえば、x86アーキテクチャのI / Oポートとの間でバイトを読み書きするための関数を含むライブラリ。 Microsoft Cは、常にそのようなもののためのライブラリ関数を提供してきました。
-
特定のCPUアーキテクチャを対象とするだけでなく、で使用できるC言語の拡張機能も提供するCコンパイラ特別なCPU機能を利用するコードを書くため。たとえば、x86アーキテクチャは、割り込みハンドラと呼ばれるルーチンを呼び出す割り込みと呼ばれるものをサポートしており、特別な開始/終了命令シーケンスが必要です。非常に初期の頃から、Microsoft Cは、関数を割り込みハンドラーとしてマークするために使用できる特別なキーワードをサポートしていたため、CPU割り込みによって直接呼び出すことができ、アセンブリを作成する必要はありませんでした。
現在、BIOSの大部分は、高級言語ではないにしても、C ++で記述されていると思います。
構成するコードの大部分BIOSは基盤となるハードウェアに固有であるため、実際に移植可能である必要はありません。常に同じタイプのCPUで実行されることが保証されています。 CPUは進化する可能性がありますが、以前のバージョンとの下位互換性を維持している限り、BIOSを変更せずに実行できます。さらに、必要に応じて、Cで記述されたBIOSの一部をいつでも再コンパイルして、新しいCPUでネイティブに実行できます。
BIOSをより高いレベルの言語で記述している理由アセンブリは、実際に移植可能である必要があるためではなく、この方法で記述しやすいためです。
コメント
- はい。マザーボードが特定のCPUアーキテクチャだけでなく、特定のCPUベンダーにバインドされている場合もあります。現在、Intel x86 CPUとのみ互換性のあるx86マザーボード、またはAMD x86CPUとのみ互換性のあるx86マザーボードを購入できます。これらのマザーボードのBIOSは、どちらの場合もCPUがx86命令セットを理解し、ほとんどの周辺機器が同一であるため、大部分は同一になりますが、一部の周辺機器には違いがあり、BIOSが考慮する必要があります。
- @Reflectionは、マザーボードが物理的にどのように見えるかを詳しく調べます。 CPUソケットには、受け入れるCPUのファミリに固有の特定のピン配置があります。たとえば、IntelP4をAMDOpteronマザーボードに物理的に接続することはできません
- ” BIOS “という用語はPCの”基本的な入力/出力システム”であるため、BIOSを使用することはx86CPUを意味します。 IA64システムにはBIOSの代わりにEFIがあり、PowerPCシステムにはOpen Firmwareシステムまたは独自のシステムがあり、SparcシステムにもOFW（またはOpenBoot）があり、OLPCX0はOFWを使用するx86ベースのシステムです。 PCでさえ’ BIOSを使用しなくなり、（U）EFIに切り替えました。 OB / OFWは、ポータブルであるだけでなくクロスプラットフォームであるように設計されているため、興味深いものです。 OFWドライバーは任意の OFWシステムで動作します。CPUに関係なく”どこでも一度実行できます” ISA。
- “最近では、BIOSのほとんどがC ++で記述されていると思います”私は’必ずしもそうだとは限りません。本当かもしれませんが、私はその業界で働いており、確かに多くのブートローダーはプレーンCで書かれています。そのようなものを書く人はしばしば”オールドガード”であり、C ++をまだ完全に信頼していない傾向があります。
- @TomDworzanski：技術的にはBIOSではありません（これは排他的に参照します）古い1981年のPCのものに）、IEEE-1275 Open Firmware（SparcのBIOS、PowerPC Common Hardware Reference Platform（PowerMac、PowerBookなど）、100ドルのラップトップOLPC X0と同様の役割に使用されます）の多くの実装-1）アセンブリ/ C以外の言語で部分的に書かれています。 OpenBoot 、 Open Firmware 、 OpenBIOS すべてに…
回答
理論的には任意の言語でBIOSを記述できますが、現代の現実はほとんどのBIOSは、アセンブリ、C、または2つのの組み合わせを使用して記述されています。
BIOSは、物理ハードウェアマシンによって理解されるマシンコードにコンパイルできる言語で記述されている必要があります。これにより、BIOSの作成に適しているとして、直接または中間的に解釈される言語（Perl、Python、PHP、Ruby、Java、C＃、JavaScriptなど）が排除されます。 （理論的には、これらの言語の1つを実装して、静的なマシンコードに直接コンパイルするか、何らかの方法でBIOSにインタープリターを埋め込むことができます。たとえば、 Java用の放棄されたGCJプロジェクト。）
ほとんどのOEMは、 American Megatrends
などの企業による独自の汎用BIOS実装を拡張することによってBIOSを実装します。 a>およびフェニックステクノロジ。 （おそらく、以前にコンピュータの最初の起動画面に表示された企業の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および/またはアセンブリで記述されています。他のツールに移行すると、一般に商品製品と見なされるものにかなりのコストがかかり、売上に非常に悪影響を与える可能性があります。Economics101に入らなければ、おそらくそうではないことを保証できます。何十年にもわたって実証されてきた実証済みのツールから逸脱することは、OEMにとって価値があります。
もちろん、BIOSを作成するための愛好家プロジェクトもあります。これらも、これまでのところ、Cおよび/またはアセンブリを選択しているようです。おそらくいつか他の技術が使われるでしょう。しかし、今日、選択は明確に定義されています。
コメント
- ちょっとした選択ですが、C＃とJavaは解釈されません。 。それらはバイトコードにコンパイルされます。インタプリタによって処理されるのはバイトコードです。 ‘最初の段落のロジックを変更しません。
- @Tonny That ‘は正しいです。 “直接または中間的に解釈される”をもう少し明確にするために追加しました。
- @Tonny通常はインタプリタではなくジッター。これは重要な違いです。’特定の動的手法がない限り、すべてをネイティブに事前にジッターすることができるためです’使用されていません。そのため、BIOSを.NET言語またはJavaで作成することは、理論的にはほぼ可能です。両方を実行し、必要なすべてのランタイムサポートが利用可能であることを確認した場合です。
- @Tonny実際にはC＃はネイティブコード msdn.microsoft.com/enにコンパイルされますが、それを行う努力は、便利さを損なう以上のものになると思います。 -us / vstudio / dotnetnative.aspx なので、弱い/動的言語のリストに表示されるのは’奇妙です。
- @Den C＃ 通常は ネイティブコードにコンパイルされていません。リンク先のこの.Netネイティブ製品はまだ正式にリリースされていません。 ‘が読んだものから、アプリケーションコードと必要なフレームワークコードを実行可能ファイルにコンパイルします。 FAQによると、これは最初はWindowsストアアプリを対象としているため、これがより広くサポートされるまでには時間がかかる場合があります。とはいえ、すべてがうまくいけば、Microsoftは将来的に仮想マシンモデルから離れる可能性があるようです。
回答
コンピューターの実際のBIOSは、アーキテクチャに依存するバイナリコードにコンパイルされた言語（おそらくCまたはアセンブリ）で記述されます。このコードは他のアーキテクチャでは実行できません（また、出荷元のマシンにすでに非常に固有であるため、実際に実行する必要はありません）。
しかし、おそらくオプションROM （GPUオプションROMの「ビデオBIOS」のようにBIOSと呼ばれることもあります）？
実際のレガシーBIOS互換の場合オプションROMの場合、それらはおそらくISAに依存する実行可能コードです（これも、目的のアーキテクチャをターゲットにするようにコンパイルできる任意の言語によって生成されます）。 PCIはまた、複数のISAのコードを含めることを許可し、ホストがブートプロセス中に適切なバイナリイメージを選択できるようにします。
UEFI互換オプションの場合ROMには、さまざまなアーキテクチャで実行できるアーキテクチャに依存しないバイトコード形式もありますが、ISAに依存するコードも引き続き使用できます。
As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs).I ‘ d say “いいえ、正反対です”