Hvilket programmeringssprog bruges til at skrive et BIOS-program?

BIOSer blev tidligere skrevet udelukkende på samlingssprog, men overgangen blev lavet for længe siden for at skrive størstedelen af koden på et sprog på et højere niveau og lade den være skrevet i samlingen så få dele af den som muligt, helst kun bootstrapper, (de allerførste par hundrede instruktioner, som CPUen hopper til efter en start / nulstilling,) og hvad som helst rutiner, der beskæftiger sig med specifikke særegenheder i den underliggende arkitektur.

BIOSer blev allerede skrevet primært i C så tidligt som i 1990erne. (Jeg skrev en BIOS i 90% C, 10% samling i begyndelsen af halvfemserne.)

Hvad der også har hjulpet meget i denne retning er:

• C biblioteker, der er målrettet mod en bestemt arkitektur og inkluderer funktioner til at håndtere de særlige forhold ved denne arkitektur, for eksempel funktioner til læsning / skrivning af bytes til / fra I / O-porte i x86-arkitekturen. Microsoft C har altid tilbudt biblioteksfunktioner til den slags ting.

• C-compilere, der ikke kun målretter mod en bestemt CPU-arkitektur, men endda tilbyder udvidelser til C-sproget, som du kan bruge på for at skrive kode, der bruger specielle CPU-funktioner. For eksempel understøtter x86-arkitekturen ting, der kaldes interrupts, som påberåber sig rutiner kendt som interrupt-handlers, og det kræver, at de har specielle ind- / udgangsinstruktions-sekvenser. Fra de meget tidlige dage understøttede Microsoft C specielle nøgleord, som du kunne bruge til at markere en funktion som en afbrydningshåndterer, så den kunne påberåbes direkte af en CPU-afbrydelse, så du ikke behøvede at skrive nogen samling til den.

I dag antager jeg, at det meste af BIOS er skrevet i C ++, hvis ikke på noget højere sprog.

Langt størstedelen af den kode, der udgør en BIOS er specifik for den underliggende hardware, så den behøver ikke rigtig at være bærbar: det garanteres, at den altid kører på den samme type CPU. CPUen kan udvikle sig, men så længe den opretholder bagudkompatibilitet med tidligere versioner, kan den stadig køre BIOS umodificeret. Plus, du kan altid kompilere de dele af BIOS, der er skrevet i C, for at køre indbygget på enhver ny CPU, der kommer op, hvis behovet opstår.

Årsagen til, at vi skriver BIOSer på sprog på et højere niveau end samling er fordi det er lettere at skrive dem på denne måde, ikke fordi de virkelig skal være bærbare.

Kommentarer

• Ja. Nogle gange kan du endda have et bundkort ikke kun bundet til en bestemt CPU-arkitektur, men endda til en bestemt CPU-leverandør. I dag kan du købe et x86-bundkort, der kun er kompatibelt med Intel x86-CPUer, eller et x86-bundkort, der kun er kompatibelt med AMD x86-CPUer. BIOS i disse bundkort vil i høj grad være identisk, fordi CPUen i begge tilfælde forstår x86-instruktionssættet, og de fleste perifere enheder er identiske, men nogle perifere enheder har forskelle, som BIOS skal tage højde for.
• @ Reflektion se nærmere på, hvordan et bundkort fysisk ser ud. CPU-stikket har et bestemt pin-arrangement, som er specifikt for familien af CPUer, det accepterer.Du kan fysisk ikke forbinde, sige en Intel P4 til et AMD Opteron-bundkort
• Udtrykket ” BIOS ” refererer til ” Basic Input / Output System ” på en pc, så at have en BIOS indebærer en x86 CPU. IA64-systemer har en EFI i stedet for en BIOS, PowerPC-systemer kan have et åbent firmwaresystem eller et proprietært system, Sparc-systemer har også OFW (eller rettere OpenBoot), OLPC X0 er et x86-baseret system, der bruger OFW. Selv pcer ‘ ikke bruger BIOS mere, de har skiftet til (U) EFI. OB / OFW er interessant, fordi det er designet til ikke kun at være bærbart, men på tværs af platforme. OFW-drivere fungerer på ethvert OFW-system, de er ” Skriv en gang kør hvor som helst “, uanset CPU ISA.
• ” I dag antager jeg, at det meste af BIOS er skrevet i C ++ ” Jeg ville ikke have ‘ antager ikke nødvendigvis, at det kan være sandt, men jeg arbejder i den branche, og bestemt er mange bootloadere skrevet i almindelig C. De mennesker, der skriver den slags ting, er ofte ” Old Guard ” og har tendens til ikke fuldt ud at stole på C ++ stadig.
• @TomDworzanski: Mens det teknisk set ikke er BIOS (som kun refererer til til den gamle pc-ting fra 1981), mange implementeringer af IEEE-1275 Open Firmware (som bruges til en lignende rolle som BIOS på Sparc, PowerPC Common Hardware Reference Platform (f.eks. PowerMac, PowerBook), den 100 $ bærbare OLPC X0 -1) er skrevet delvis på andre sprog end samling / C. OpenBoot , Åbn firmware , OpenBIOS alle indeholder …

Mens man i teorien kan skrive BIOS på ethvert sprog, moderne virkelighed er mest BIOS er skrevet ved hjælp af Assembly, C eller en kombination af de to .

BIOS skal skrives på et sprog, der kan kompileres til maskinkode , som forstås af den fysiske hardware-maskine. Dette eliminerer de direkte eller mellemliggende fortolkede sprog (Perl, Python, PHP, Ruby, Java, C #, JavaScript osv.) Som passende til skrivning af BIOS. (Skønt man i teorien kunne implementere et af disse sprog for enten at kompilere direkte til statisk maskinkode, eller man kunne på en eller anden måde integrere tolken i BIOS. Der er for eksempel abandonware GCJ-projekt til Java.)

De fleste OEMer implementerer en BIOS ved at udvide proprietære, generiske BIOS-implementeringer fra virksomheder som American Megatrends og Phoenix-teknologier . (Du har sandsynligvis set et af disse virksomheder vist på den første opstartsskærm på en computer før.) Kildekoden til disse implementeringer er ikke offentligt tilgængelig, men noget af det er lækket. Jeg ønsker ikke at linke direkte til dette til C- og samlingskildekoden, men der er steder på Internettet, hvor denne kildekode diskuteres for dem, der holder af at kigge.

Nogle hardwareproducenter, som dem, der er målrettet mod markederne med høj ydeevne og spil, mætter deres BIOS-implementeringer med tilpasningsfunktioner, statistikker og attraktive brugergrænseflader designet til deres nøjagtige implementeringer. Mange af disse funktioner går ud over, hvad der tilbydes i de generiske produkter, der produceres af amerikanske Megatrends og andre. Desværre ser disse virksomheder ofte frigivelsen af deres kildekode som en sikkerhedsrisiko , så man ved ikke så meget om disse avancerede implementeringer, fordi der deles lidt om dem Selvfølgelig ville jeg finde måder at få adgang til og de-kompilere sådanne BIOS-implementeringer, men det kan være svært og muligvis ulovligt at gøre det.

Gå tilbage til det originale spørgsmål på grund af behovet for at producere native maskinkode, en BIOS skulle implementeres i et programmeringssprog understøttet af en indbygget maskinkodekompilator . Selvom der er mange sådanne sprog, og selvom jeg er sikker på, at der i løbet af de sidste par årtier er brugt flere sprog i eksperimenter, er hver åben BIOS-implementering, jeg har været i stand til at finde specifikt, afhængig af en kombination af C og / eller samling. -kilde BIOS-implementeringer, jeg så på for at danne denne konklusion, inkluderer OpenBIOS , tinyBIOS , coreboot , Intel BIOS og Libreboot . Jeg kiggede også på nogle meget gamle BIOS-implementeringer, der ikke er relevante i dag, men som også fulgte C- og / eller monteringsreglen.

Jeg synes, det er også relevant at se på anden software, der er bygget til interagere direkte med hardware.Vi ved for eksempel, at Linux-kernen , OS X-kernen og Windows-kerne er stort set C med nogle samlinger og nogle sprog på højere niveau til specifikke opgaver. Vi ved også, at hardwaredrivere på Linux og hardwaredrivere på Windows er stort set skrevet i C .

At komme tilbage til BIOS synes jeg, det er også vigtigt at overveje økonomien i det valgte programmeringssprog. BIOS er generelt skrevet som en nødvendighed for at supplere salg af hardware. Moderne BIOS-systemer vides at være stort set skrevet i C og / eller montering. Et skridt til et andet værktøj vil tilføje betydelige omkostninger til det, der generelt betragtes som råvareprodukter, der kan påvirke salget meget negativt. Uden at komme ind i økonomi 101 kan jeg forsikre dig om, at det sandsynligvis ikke det værd for en OEM at afvige fra velprøvede værktøjer, der er bevist gennem årtier.

Selvfølgelig er der og vil være hobbyprojekter til også at skrive BIOS. Hidtil synes disse også at vælge C og / eller samling. Måske en dag vil andre teknologier blive brugt. Men i dag er valget af veldefineret.

Kommentarer

• Det er en lille smule nit-picking men C # og Java fortolkes ikke . De kompilerer til byte-kode. Det er byte-koden, der derefter håndteres af en tolk. Ændrer ‘ ikke logikken i første afsnit.
• @Tonny Det ‘ er korrekt. Jeg tilføjede ” direkte eller mellemliggende fortolket ” for at være lidt mere tydelig.
• @Tonny normalt en jitter snarere end en tolk, hvilket er en vigtig skelnen, fordi det ‘ er muligt at pre-jit det hele til native, så længe visse dynamiske teknikker ikke er ‘ t brugt. Som sådan ville det næsten være teoretisk muligt at skrive en BIOS på .NET-sprog eller Java, hvis man gjorde begge det og sørgede for, at al nødvendig runtime-support var tilgængelig. Jeg forestiller mig, at bestræbelserne på at gøre det mere end ville dværge enhver bekvemmelighed, der blev fundet.
• @Tonny Faktisk kompilerer C # til native-kode msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx så det ‘ er underligt at se det på listen over svage / dynamiske sprog.
• @Den C # er ikke typisk kompileret til native-kode. Dette .Net-oprindelige produkt, som du linker til, er endnu ikke officielt frigivet. Fra det jeg ‘ har læst, vil det kompilere applikationskoden og den krævede rammekode til en eksekverbar. Ifølge FAQ bliver dette oprindeligt målrettet mod Windows Store-apps, så det kan tage lidt tid, før dette understøttes bredere. Når det er sagt, ser det ud til, at Microsoft måske bevæger sig væk fra den virtuelle maskinemodel et stykke tid i fremtiden, hvis alt går godt.

Den egentlige BIOS til en computer ville blive skrevet på et eller andet sprog (sandsynligvis C eller samling), der er kompileret til arkitekturafhængig binær kode; denne kode kan ikke køre på enhver anden arkitektur (og uden tvivl behøver det ikke virkelig, da den allerede er meget specifik for den maskine, den leveres med).

Men tænker du muligvis på Option ROMer (som undertiden kaldes BIOSer som i “Video BIOS” for en GPU option ROM)?

For faktisk, ældre BIOS-kompatibel option ROMer, de ville sandsynligvis være ISA-afhængig eksekverbar kode (igen genereret af ethvert sprog, der kan kompileres for at målrette mod den ønskede arkitektur); PCI tillader også inklusive kode til flere ISAer og giver værten mulighed for at vælge det relevante binære billede under opstartsprocessen.

For UEFI-kompatibel mulighed ROMer er der også et arkitekturuafhængigt bytekodeformat , der kan køres på forskellige arkitekturer, men ISA-afhængig kode kan også stadig bruges.