Welke programmeertaal wordt gebruikt om een BIOS-programma te schrijven?

BIOS-en werden vroeger uitsluitend in assembleertaal geschreven, maar de de overgang is lang geleden gemaakt om het merendeel van de code in een taal van een hoger niveau te schrijven en zo min mogelijk delen ervan in assembly geschreven te laten, bij voorkeur alleen de bootstrapper (de allereerste paar honderden instructies die de CPU springt na een start / reset,) en welke routines dan ook omgaan met specifieke eigenaardigheden van de onderliggende architectuur.

BIOSen werden al in de eerste plaats in C geschreven in het begin van de jaren negentig. (Ik heb begin jaren negentig een BIOS geschreven in 90% C, 10% assembly.)

Wat ook enorm heeft bijgedragen in deze richting is:

• C bibliotheken die gericht zijn op een specifieke architectuur en functies bevatten voor het omgaan met eigenaardigheden van die architectuur, bijvoorbeeld functies voor het lezen / schrijven van bytes naar / van I / O-poorten van de x86-architectuur. Microsoft C heeft altijd bibliotheekfuncties voor dat soort dingen aangeboden.

• C-compilers die niet alleen gericht zijn op een specifieke CPU-architectuur, maar zelfs uitbreidingen bieden voor de C-taal die u kunt gebruiken in om code te schrijven die gebruik maakt van speciale CPU-functies. De x86-architectuur ondersteunt bijvoorbeeld dingen die bekend staan als interrupts, die routines aanroepen die bekend staan als interrupthandlers, en het vereist dat ze speciale entry / exit-instructiereeksen hebben. Vanaf het allereerste begin ondersteunde Microsoft C speciale trefwoorden die je kon gebruiken om een functie als een interrupt-handler te markeren, zodat deze direct door een CPU-interrupt kon worden aangeroepen, zodat je er geen assembly voor hoefde te schrijven.

Tegenwoordig zou ik aannemen dat het grootste deel van het BIOS is geschreven in C ++, zo niet in een taal op een hoger niveau.

De overgrote meerderheid van de code waaruit een BIOS is specifiek voor de onderliggende hardware, dus het hoeft niet echt draagbaar te zijn: het is gegarandeerd dat het altijd op hetzelfde type CPU zal draaien. De CPU kan evolueren, maar zolang deze achterwaartse compatibiliteit met eerdere versies handhaaft, kan het BIOS nog steeds ongewijzigd worden uitgevoerd. Bovendien kun je de delen van het BIOS die in C zijn geschreven altijd opnieuw compileren om native te draaien op elke nieuwe CPU die verschijnt, als dat nodig is.

De reden waarom we BIOS-en schrijven in talen van een hoger niveau dan assembly is omdat het gemakkelijker is om ze op deze manier te schrijven, niet omdat ze echt draagbaar moeten zijn.

Reacties

• Ja. Soms heb je zelfs een moederbord dat niet alleen aan een specifieke CPU-architectuur is gebonden, maar zelfs aan een specifieke CPU-leverancier. Tegenwoordig kun je een x86-moederbord kopen dat alleen compatibel is met Intel x86-CPUs, of een x86-moederbord dat alleen compatibel is met AMD x86-CPUs. Het BIOS in deze moederborden zal in hoge mate identiek zijn, omdat in beide gevallen de CPU de x86-instructieset begrijpt en de meeste randapparatuur identiek is, maar sommige randapparatuur heeft verschillen, waar het BIOS rekening mee moet houden.
• @Reflection bekijk hoe een moederbord er fysiek uitziet. De CPU-socket heeft een bepaalde pin-opstelling, die specifiek is voor de familie van CPUs die deze accepteert.Je kunt bijvoorbeeld een Intel P4 fysiek niet aansluiten op een AMD Opteron-moederbord.
• De term ” BIOS ” verwijst naar de ” Basisinvoer / uitvoersysteem ” van een pc, dus het hebben van een BIOS impliceert een x86 CPU. IA64-systemen hebben een EFI in plaats van een BIOS, PowerPC-systemen kunnen een Open Firmware-systeem of een eigen systeem hebben, Sparc-systemen hebben ook OFW (of liever OpenBoot), de OLPC X0 is een x86-gebaseerd systeem dat OFW gebruikt. Zelfs pcs ‘ gebruiken geen BIOS meer, ze zijn overgeschakeld naar (U) EFI. OB / OFW is interessant, omdat het is ontworpen om niet alleen draagbaar maar ook platformonafhankelijk te zijn. OFW-stuurprogrammas werken op elk OFW-systeem, ze zijn ” Write Once Run Anywhere “, ongeacht de CPU ISA.
• ” Tegenwoordig zou ik aannemen dat het grootste deel van het BIOS is geschreven in C ++ ” Ik zou niet ‘ Ik ga er niet per se van uit dat, het kan waar zijn, maar ik werk in die branche en zeker zijn veel opstartladers geschreven in gewone C. De mensen die dat soort dingen schrijven zijn vaak de ” Old Guard ” en hebben de neiging C ++ nog steeds niet volledig te vertrouwen.
• @TomDworzanski: hoewel technisch gezien geen BIOS (dat uitsluitend verwijst naar de oude pc-dingen uit 1981), veel implementaties van IEEE-1275 Open Firmware (die wordt gebruikt voor een vergelijkbare rol als het BIOS op Sparc, het PowerPC Common Hardware Reference Platform (bijv. PowerMac, PowerBook), de 100 $ laptop OLPC X0 -1) zijn gedeeltelijk geschreven in andere talen dan assembly / C. OpenBoot , Open Firmware , OpenBIOS bevatten allemaal …

Hoewel men in theorie een BIOS in elke taal kan schrijven, de moderne realiteit is de meeste BIOS wordt geschreven met Assembly, C, of een combinatie van de twee .

BIOS moet worden geschreven in een taal die kan worden gecompileerd met machinecode , dat wil zeggen begrepen door de fysieke hardware-machine. Dit elimineert de direct of intermediair geïnterpreteerde talen (Perl, Python, PHP, Ruby, Java, C #, JavaScript, enz.) Als zijnde geschikt voor het schrijven van BIOS. (Hoewel men in theorie een van deze talen zou kunnen implementeren om ofwel rechtstreeks naar statische machinecode te compileren, of men zou op de een of andere manier de interpreter in BIOS kunnen insluiten. Er is bijvoorbeeld de verlaten GCJ-project voor Java.)

De meeste OEMs implementeren een BIOS door eigen, generieke BIOS-implementaties uit te breiden door bedrijven zoals American Megatrends en Phoenix Techologies . (Je hebt waarschijnlijk een van die bedrijven eerder op het eerste opstartscherm van een computer zien verschijnen.) De broncode voor deze implementaties is niet publiekelijk beschikbaar, maar een deel ervan is gelekt. Ik wil hier niet rechtstreeks naar verwijzen naar de C- en assembly-broncode, maar er zijn plaatsen op internet waar deze broncode wordt besproken voor degenen die willen gluren.

Sommige hardwarefabrikanten, zoals degenen die zich richten op de high-performance- en gamingmarkten, verzadigen hun BIOS-implementaties met aanpassingsfuncties, statistieken en aantrekkelijke gebruikersinterfaces die zijn ontworpen voor hun exacte implementaties. Veel van deze functies gaan verder dan wat wordt aangeboden in de geproduceerde generieke producten door American Megatrends en anderen. Helaas zien deze bedrijven het vrijgeven van hun broncode vaak als een beveiligingsrisico , dus er is weinig bekend over deze geavanceerde implementaties, omdat er wordt weinig over hen gedeeld Ik zou natuurlijk manieren vinden om toegang te krijgen tot dergelijke BIOS-implementaties en deze te decompileren, maar dit kan moeilijk en mogelijk illegaal zijn.

Terugkomend op de oorspronkelijke vraag, vanwege de noodzaak om native machinecode te produceren, een BIOS zou moeten worden geïmplementeerd in een programmeertaal die wordt ondersteund door een native machinecode-compiler . Hoewel er veel van dergelijke talen zijn en hoewel ik er zeker van ben dat er de afgelopen decennia verschillende talen zijn gebruikt bij experimenten, is elke open BIOS-implementatie die ik heb kunnen vinden specifiek afhankelijk van een combinatie van C en / of assembly. -sourced BIOS-implementaties die ik heb bekeken om deze conclusie te vormen, omvatten OpenBIOS , tinyBIOS , coreboot , Intel BIOS , en Libreboot . Ik heb ook gekeken naar enkele zeer oude BIOS-implementaties die vandaag niet relevant zijn, maar die ook de C- en / of assembly-regel volgden.

Ik denk dat het ook relevant is om te kijken naar andere software die is gebouwd om rechtstreeks communiceren met hardware.We weten bijvoorbeeld dat de Linux Kernel , de OS X-kernel , en de Windows-kernel bestaat grotendeels uit C met enige assembly en enkele talen van hoger niveau voor specifieke taken. We weten ook dat hardwarestuurprogrammas op Linux en hardwarestuurprogrammas op Windows grotendeels in C zijn geschreven .

Terugkomend op BIOS, ik denk dat het ook belangrijk is om de economie van de gekozen programmeertaal in overweging te nemen. BIOS is over het algemeen geschreven als een noodzaak om de verkoop van hardware aan te vullen. Van moderne BIOS-systemen is bekend dat ze grotendeels geschreven in C en / of assembly. Een verhuizing naar een andere tool zou aanzienlijke kosten met zich meebrengen voor wat algemeen wordt beschouwd als commodity-producten, wat een zeer nadelige invloed kan hebben op de verkoop. Zonder in Economics 101 te komen, kan ik u verzekeren dat dit waarschijnlijk niet de moeite waard voor een OEM om af te wijken van beproefde tools die in de afgelopen decennia zijn bewezen.

Natuurlijk zijn er en zullen ook hobbyistische projecten zijn om BIOS te schrijven. Ook deze lijken tot dusver C en / of montage te kiezen. Misschien zullen er ooit andere technologieën worden gebruikt. Maar tegenwoordig is de keuze voor goed gedefinieerd.

Opmerkingen

• Het is een beetje nit-picking maar C # en Java worden niet geïnterpreteerd . Ze compileren naar byte-code. Het is de byte-code die vervolgens wordt afgehandeld door een tolk. Verandert ‘ de logica van de eerste alinea niet.
• @Tonny Dat ‘ is correct. Ik heb ” direct of intermediair geïnterpreteerd ” toegevoegd om een beetje duidelijker te zijn.
• @Tonny normaal gesproken een jitter in plaats van een interpreter, wat een belangrijk onderscheid is omdat het ‘ mogelijk is om alles te pre-jiteren op native, zolang bepaalde dynamische technieken niet ‘ t gebruikt. Als zodanig zou het theoretisch mogelijk zijn om een BIOS in .NET-talen of Java te schrijven, als je dat allebei zou doen en ervoor zou zorgen dat alle benodigde runtime-ondersteuning beschikbaar was. Ik kan me voorstellen dat de inspanningen om dat te doen het gevonden gemak meer dan in de schaduw stellen.
• @Tonny C # compileert eigenlijk naar native code msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx dus het is ‘ raar om het te zien in de lijst met zwakke / dynamische talen.
• @Den C # is niet typisch gecompileerd naar native code. Dit .Net Native-product waarnaar u linkt, is nog niet officieel vrijgegeven. Van wat ik ‘ heb gelezen, zal het de applicatiecode en de vereiste frameworkcode compileren in een uitvoerbaar bestand. Volgens de veelgestelde vragen is dit in eerste instantie gericht op Windows Store-apps, dus het kan even duren voordat dit breder wordt ondersteund. Dat gezegd hebbende, lijkt het erop dat Microsoft in de toekomst misschien afstand neemt van het virtuele-machinemodel als alles goed gaat.

Het eigenlijke BIOS voor een computer zou in een taal worden geschreven (waarschijnlijk C of assembly) die is gecompileerd met architectuurafhankelijke binaire code; deze code kan “niet op een andere architectuur worden uitgevoerd (en waarschijnlijk ook niet echt nodig, aangezien het al erg specifiek is voor de machine waarmee het wordt verzonden).

Maar denkt u mogelijk aan Optie-ROMs (die soms BIOS-en worden genoemd, zoals in “Video BIOS” voor een GPU-optie-ROM)?

Voor daadwerkelijke, legacy BIOS-compatibele optie-ROMs, ze zouden waarschijnlijk ISA-afhankelijke uitvoerbare code zijn (opnieuw gegenereerd door elke taal die kan worden gecompileerd om zich te richten op de gewenste architectuur); PCI ook staat het opnemen van code voor meerdere ISAs toe en stelt de host in staat om de juiste binaire afbeelding te selecteren tijdens het opstartproces.

Voor UEFI-compatibele optie ROMs is er ook een architectuuronafhankelijke bytecode-indeling die kan worden uitgevoerd op verschillende architecturen, maar ISA-afhankelijke code kan ook nog steeds worden gebruikt.