In welcher Programmiersprache wird ein BIOS-Programm geschrieben?

Soweit ich weiß, sollte der im ROM gespeicherte BIOS-Code / Bitstream generisch sein (mit mehreren CPU-Typen oder ISAs zusammenarbeiten). Außerdem habe ich im Web erwähnt gesehen, dass es möglich ist, seinen Code zu entleeren (und ihn "zu zerlegen").

Also, in welcher Sprache, in welchem ​​Befehlssatz oder in welchem ​​Maschinencode ist es geschrieben? Benötigt es keinen Prozessor, um seine Operationen auszuführen? Wenn ja, denke ich, dass es die externe CPU verwenden wird, woher kennt es dann den spezifischen Befehlssatz des verwendeten?

Vielleicht hat es einen internen Prozessor?

Früher wurden BIOSe ausschließlich in Assemblersprache geschrieben, doch der Übergang wurde vor langer Zeit vorgenommen, um den größten Teil des Codes in einer höheren Programmiersprache zu schreiben und so wenig Teile wie möglich in Assemblersprache zu belassen, vorzugsweise nur den Bootstrapper. (die ersten paar Hunderte von Anweisungen, zu denen die CPU nach einem Start / Reset springt) und welche Routinen sich auch immer mit bestimmten Macken der zugrunde liegenden Architektur befassen.

BIOSes wurden bereits in den frühen neunziger Jahren hauptsächlich in C geschrieben. (Ich habe in den frühen neunziger Jahren ein BIOS in 90% C, 10% Assembly geschrieben.)

Was auch in dieser Richtung sehr geholfen hat, ist:

• C-Bibliotheken, die auf eine bestimmte Architektur abzielen und Funktionen zum Behandeln von Besonderheiten dieser Architektur enthalten, z. B. Funktionen zum Lesen / Schreiben von Bytes zu / von E / A-Ports der x86-Architektur. Microsoft C hat immer Bibliotheksfunktionen für solche Dinge angeboten.

• C-Compiler, die nicht nur auf eine bestimmte CPU-Architektur abzielen, sondern sogar Erweiterungen der C-Sprache anbieten, die Sie verwenden können, um Code zu schreiben, der spezielle CPU-Funktionen nutzt. Beispielsweise unterstützt die x86-Architektur sogenannte Interrupts, die Routinen aufrufen, die als Interrupt-Handler bezeichnet werden, und für die spezielle Eingangs- / Ausgangsanweisungssequenzen erforderlich sind. Microsoft C unterstützte von Anfang an spezielle Schlüsselwörter, mit denen Sie eine Funktion als Interrupt-Handler markieren konnten, sodass sie direkt von einem CPU-Interrupt aufgerufen werden konnte und Sie keine Assembly dafür schreiben mussten.

Heutzutage würde ich annehmen, dass der größte Teil des BIOS in C ++ geschrieben ist, wenn nicht in einer höheren Sprache.

Der überwiegende Teil des Codes, der ein BIOS ausmacht, ist spezifisch für die zugrunde liegende Hardware, sodass es nicht unbedingt portabel sein muss: Es wird garantiert, dass es immer auf demselben CPU-Typ ausgeführt wird. Die CPU kann sich weiterentwickeln, aber solange die Abwärtskompatibilität mit früheren Versionen erhalten bleibt, kann das BIOS unverändert ausgeführt werden. Außerdem können Sie die in C geschriebenen Teile des BIOS jederzeit neu kompilieren, um sie bei Bedarf nativ auf jeder neuen CPU auszuführen.

Der Grund, warum wir BIOSes in höheren Sprachen als Assembly schreiben, ist, dass es einfacher ist, sie auf diese Weise zu schreiben, und nicht, weil sie wirklich portabel sein müssen.

Während man das BIOS theoretisch in jeder Sprache schreiben kann, ist die moderne Realität, dass das BIOS meist mit Assembly, C oder einer Kombination aus beiden geschrieben wird .

Das BIOS muss in einer Sprache geschrieben sein, die sich zu Maschinencode kompilieren lässt, der von der physischen Hardwaremaschine verstanden wird. Dadurch werden die direkt oder zwischenzeitlich interpretierten Sprachen (Perl, Python, PHP, Ruby, Java, C #, JavaScript usw.) als für das Schreiben des BIOS geeignet ausgeschlossen. (Theoretisch könnte man jedoch eine dieser Sprachen implementieren, um entweder direkt in statischen Maschinencode zu kompilieren, oder den Interpreter in das BIOS einbetten. Es gibt beispielsweise das Abbruch-GCJ-Projekt für Java.)

Die meisten OEMs implementieren ein BIOS, indem sie proprietäre, generische BIOS-Implementierungen von Unternehmen wie American Megatrends und Phoenix Techologies erweitern . (Sie haben wahrscheinlich schon einmal gesehen, dass eines dieser Unternehmen auf dem ersten Startbildschirm eines Computers angezeigt wurde.) Der Quellcode für diese Implementierungen ist nicht öffentlich verfügbar, aber ein Teil davon ist durchgesickert. Ich mag nicht auf das C und Assembler - Quellcode diesen direkt verbinden, aber es gibt Orte im Internet , wo diese Quellcode wird diskutiert für diejenigen , die spähen kümmern.

Einige Hardwarehersteller, wie diejenigen, die auf den Hochleistungs- und Spielemarkt abzielen, sättigen ihre BIOS-Implementierungen mit Anpassungsfunktionen, Statistiken und attraktiven Benutzeroberflächen, die für ihre genauen Implementierungen entwickelt wurden. Viele dieser Funktionen gehen über das hinaus, was die von American Megatrends und anderen produzierten Generika bieten. Leider sehen diese Unternehmen die Veröffentlichung ihres Quellcodes oft als Sicherheitsrisiko an. Daher ist über diese High-End-Implementierungen nur wenig bekannt, da nur wenig über sie geteilt wird. Man könnte natürlich Wege finden, um auf solche BIOS-Implementierungen zuzugreifen und diese zu dekompilieren, aber dies könnte schwierig und möglicherweise illegal sein.

Zurück zur ursprünglichen Frage: Da nativer Maschinencode erstellt werden muss, muss ein BIOS in einer Programmiersprache implementiert werden, die von einem nativen Maschinencode-Compiler unterstützt wird . Obwohl es viele solcher Sprachen gibt und ich mir sicher bin, dass in den letzten Jahrzehnten mehrere Sprachen zum Experimentieren verwendet wurden, stützt sich jede offene BIOS-Implementierung, die ich finden konnte, speziell auf eine Kombination aus C und / oder Assembly. Zu den Open-Source-BIOS-Implementierungen, die ich mir angesehen habe, um diese Schlussfolgerung zu ziehen, gehören OpenBIOS , tinyBIOS , Coreboot , Intel BIOS und Libreboot. Ich habe mir auch einige sehr alte BIOS-Implementierungen angesehen, die heute nicht relevant sind, aber auch die C- und / oder Assembly-Regel befolgt haben.

Ich denke, es ist auch wichtig, sich andere Software anzusehen, die für die direkte Interaktion mit der Hardware entwickelt wurde. Wir wissen zum Beispiel, dass der Linux-Kernel , der OS X-Kernel und der Windows-Kernel größtenteils C sind, mit einigen Assembler- und einigen höheren Sprachen für bestimmte Aufgaben. Wir wissen auch, dass Hardwaretreiber unter Linux und Hardwaretreiber unter Windows größtenteils in C geschrieben sind.

Zurück zum BIOS, denke ich, ist es auch wichtig, die Wirtschaftlichkeit der gewählten Programmiersprache zu berücksichtigen. BIOS wird im Allgemeinen als eine Notwendigkeit geschrieben, den Hardware-Verkauf zu ergänzen. Es ist bekannt, dass moderne BIOS-Systeme weitgehend in C und / oder Assembly geschrieben sind. Ein Umstieg auf ein anderes Tool würde die Kosten für Warenprodukte erheblich erhöhen, was sich sehr negativ auf den Umsatz auswirken könnte. Ohne auf Economics 101 einzugehen, kann ich Ihnen versichern, dass es sich für einen OEM wahrscheinlich nicht lohnt, von jahrzehntelang bewährten Werkzeugen abzuweichen.

Natürlich gibt es und wird es auch Hobby-Projekte geben, um BIOS zu schreiben. Auch diese scheinen sich bisher für C und / oder Assembly zu entscheiden. Vielleicht werden eines Tages andere Technologien eingesetzt. Aber heute ist die Wahl gut definiert.

Das eigentliche BIOS für einen Computer wird in einer Sprache (wahrscheinlich C oder Assembly) geschrieben, die zu architekturabhängigem Binärcode kompiliert ist. Dieser Code kann auf keiner anderen Architektur ausgeführt werden (und muss es wohl auch nicht, da er bereits sehr spezifisch für die Maschine ist, mit der er ausgeliefert wird).

Aber denken Sie möglicherweise über Options-ROMs nach (die manchmal als BIOS bezeichnet werden, wie im "Video-BIOS" für ein GPU-Options-ROM)?

Bei tatsächlichen, mit älteren BIOS-kompatiblen Options-ROMs handelt es sich wahrscheinlich um ISA-abhängigen ausführbaren Code (der wiederum von einer beliebigen Sprache generiert wird, die für die gewünschte Architektur kompiliert werden kann). PCI ermöglicht auch das Einschließen von Code für mehrere ISAs und ermöglicht es dem Host, das entsprechende Binär-Image während des Startvorgangs auszuwählen.

Für UEFI-kompatible Options-ROMs gibt es auch ein architekturunabhängiges Bytecode-Format , das auf verschiedenen Architekturen ausgeführt werden kann. ISA-abhängiger Code kann jedoch weiterhin verwendet werden.