Hvilket programmeringsspråk brukes til å skrive et BIOS-program?

BIOSer ble tidligere skrevet utelukkende på monteringsspråk, men overgangen ble gjort for lenge siden for å skrive flertallet av koden på noe høyere nivå språk, og la den være skrevet i forsamlingen så få deler av den som mulig, helst bare bootstrapper, (de aller første hundrevis av instruksjoner som CPU hopper over til etter en start / reset,) og hvilke rutiner som helst som omhandler spesifikke særegenheter i den underliggende arkitekturen.

BIOSer ble allerede skrevet primært i C så tidlig som på nittitallet. (Jeg skrev en BIOS i 90% C, 10% montering tidlig på nittitallet.)

Det som også har hjulpet sterkt i denne retningen er:

• C biblioteker som er målrettet mot en bestemt arkitektur og inkluderer funksjoner for å håndtere særegenheter ved den arkitekturen, for eksempel funksjoner for å lese / skrive byte til / fra I / O-porter i x86-arkitekturen. Microsoft C har alltid tilbudt biblioteksfunksjoner for den slags ting.

• C-kompilatorer som ikke bare målretter mot en bestemt CPU-arkitektur, men til og med tilbyr utvidelser til C-språket du kan bruke på for å skrive kode som bruker spesielle CPU-funksjoner. For eksempel støtter x86-arkitekturen ting som kalles interrupts, som påkaller rutiner kjent som interrupt handlers, og det krever at de har spesielle inn- / utgangsinstruksjonssekvenser. Helt fra de første dagene støttet Microsoft C spesielle nøkkelord som du kan bruke til å markere en funksjon som en avbruddshåndterer, slik at den kan påkalles direkte av en CPU-avbrudd, slik at du ikke trenger å skrive noen samling for den. >

I dag vil jeg anta at det meste av BIOS er skrevet i C ++, om ikke på noe høyere nivå språk.

De aller fleste koden som utgjør en BIOS er spesifikk for den underliggende maskinvaren, så den trenger egentlig ikke være bærbar: det er garantert at den alltid vil kjøre på samme type CPU. CPU-en kan utvikle seg, men så lenge den opprettholder bakoverkompatibilitet med tidligere versjoner, kan den fortsatt kjøre BIOS umodifisert. I tillegg kan du alltid kompilere delene av BIOS skrevet i C for å kjøre naturlig på en hvilken som helst ny CPU som kommer opp, hvis behovet oppstår.

Årsaken til at vi skriver BIOSer på språk på et høyere nivå enn montering er fordi det er lettere å skrive dem på denne måten, ikke fordi de virkelig trenger å være bærbare.

Kommentarer

• Ja. Noen ganger kan du til og med ha et hovedkort bundet ikke bare til en bestemt CPU-arkitektur, men til og med til en bestemt CPU-leverandør. I dag kan du kjøpe et x86-hovedkort som bare er kompatibelt med Intel x86-prosessorer, eller et x86-hovedkort som bare er kompatibelt med AMD x86-prosessorer. BIOS i disse hovedkortene vil være identisk i stor grad, fordi i begge tilfeller forstår CPU-en instruksjonssettet x86, og de fleste eksterne enheter er identiske, men noen eksterne enheter har forskjeller som BIOS må ta hensyn til.
• @Reflection se nøye på hvordan et hovedkort fysisk ser ut. CPU-kontakten vil ha et visst pin-arrangement, som er spesifikt for familien av CPUer den aksepterer.Du kan fysisk ikke koble en Intel P4 til et AMD Opteron-hovedkort
• Begrepet » BIOS » refererer til » Grunnleggende inngangs- / utgangssystem » på en PC, så det å ha en BIOS innebærer en x86-CPU. IA64-systemer har en EFI i stedet for en BIOS, PowerPC-systemer kan ha et åpent firmware-system eller et proprietært system, Sparc-systemer har også OFW (eller rettere sagt OpenBoot), OLPC X0 er et x86-basert system som bruker OFW. Selv PC-er ‘ ikke bruker BIOS lenger, de har byttet til (U) EFI. OB / OFW er interessant, fordi det er designet for ikke bare å være bærbart, men plattform. OFW-drivere fungerer på ethvert OFW-system, de er » Skriv en gang kjør hvor som helst «, uavhengig av CPU ISA.
• » I dag vil jeg anta at det meste av BIOS er skrevet i C ++ » Jeg ville ikke ha ‘ antar ikke nødvendigvis at, Det kan være sant, men jeg jobber i den bransjen, og sikkert er mange bootloadere skrevet i vanlig C. Menneskene som skriver den slags ting er ofte » Old Guard » og har en tendens til ikke å stole fullt på C ++ fremdeles.
• @TomDworzanski: Mens det teknisk sett ikke er BIOS (som refererer eksklusivt til den gamle PC-saken fra 1981), mange implementeringer av IEEE-1275 Open Firmware (som brukes 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 språk enn montering / C. OpenBoot , Åpne firmware , OpenBIOS alle inneholder …

Mens man i teorien kan skrive BIOS på hvilket som helst språk, moderne virkelighet er mest BIOS er skrevet ved hjelp av Assembly, C, eller en kombinasjon av de to .

BIOS må skrives på et språk som kan kompileres til maskinkode , som forstås av den fysiske maskinvaremaskinen. Dette eliminerer direkte eller mellomliggende tolket språk (Perl, Python, PHP, Ruby, Java, C #, JavaScript, etc) som passende for å skrive BIOS. (Skjønt man i teorien kan implementere et av disse språkene for å kompilere direkte til statisk maskinkode, eller man kan på en eller annen måte legge inn tolken i BIOS. Det er for eksempel abandonware GCJ-prosjekt for Java.)

De fleste OEM-er implementerer BIOS ved å utvide proprietære, generiske BIOS-implementeringer fra selskaper som American Megatrends og Phoenix Techologies . (Du har sannsynligvis sett et av disse selskapene som ble vist på den første oppstartsskjermen på en datamaskin før.) Kildekoden for disse implementeringene er ikke offentlig tilgjengelig, men noe av det har blitt lekket. Jeg vil ikke koble til dette direkte. til C og monteringskildekoden, men det er steder på Internett der denne kildekoden blir diskutert for de som bryr seg om å kikke.

Noen maskinvareprodusenter, som de som målretter mot høyytelses- og spillmarkedene, metter BIOS-implementeringene med tilpasningsfunksjoner, statistikk og attraktive brukergrensesnitt som er designet for deres nøyaktige implementeringer. av amerikanske Megatrends og andre. Dessverre ser disse selskapene ofte utgivelsen av kildekoden sin som en sikkerhetsrisiko , så lite er kjent om disse avanserte implementeringene fordi det deles lite om dem Selvfølgelig ville jeg finne måter å få tilgang til og de-kompilere slike BIOS-implementeringer, men å gjøre det kan være vanskelig og muligens ulovlig.

Å gå tilbake til det opprinnelige spørsmålet på grunn av behovet for å produsere naturlig maskinkode, en BIOS må implementeres i et programmeringsspråk som støttes av en innfødt maskinkodekompilator . Selv om det er mange slike språk, og selv om jeg de siste tiårene er sikre på, har flere språk blitt brukt i eksperimentering, men hver åpen BIOS-implementering jeg har kunnet finne er avhengig av en kombinasjon av C og / eller montering. -kilde BIOS-implementeringer jeg så på for å danne denne konklusjonen inkluderer OpenBIOS , tinyBIOS , coreboot , Intel BIOS , og Libreboot . Jeg så også på noen veldig gamle BIOS-implementeringer som ikke er relevante i dag, men som også fulgte C- og / eller monteringsregelen.

Jeg tror det også er relevant å se på annen programvare bygget for å samhandle direkte med maskinvare.Vi vet for eksempel at Linux-kjernen , OS X-kjernen , og Windows-kjernen er i stor grad C med noe montering og noen språk på høyere nivå for bestemte oppgaver. Vi vet også at maskinvaredrivere på Linux og maskinvaredrivere på Windows er skrevet i stor grad i C .

Å komme tilbake til BIOS, jeg tror det også er viktig å vurdere økonomien til det valgte programmeringsspråket. BIOS er generelt skrevet som en nødvendighet for å utfylle maskinvaresalg. Moderne BIOS-systemer er kjent for å være i stor grad skrevet i C og / eller montering. En flytting til et annet verktøy vil legge til betydelige kostnader for det som generelt anses å være råvareprodukter som kan påvirke salget veldig negativt. Uten å komme inn i Economics 101, kan jeg forsikre deg om at det sannsynligvis ikke er verdt det til en OEM å avvike fra velprøvde verktøy som er bevist gjennom flere tiår.

Selvfølgelig er det og vil være hobbyprosjekter for å skrive BIOS også. Også disse ser ut til å velge C og / eller montering. Kanskje en dag vil andre teknologier bli brukt. Men i dag er valget av veldefinert.

Kommentarer

• Det er litt nit-picking men C # og Java tolkes ikke . De kompilerer for å byte-kode. Det er byte-koden som deretter blir håndtert av en tolk. Endrer ikke ‘ ikke logikken til første avsnitt.
• @Tonny Det ‘ er riktig. Jeg la til » direkte eller mellomliggende tolket » for å være litt tydeligere.
• @Tonny normalt en jitter snarere enn en tolk, som er et viktig skille fordi det ‘ er mulig å pre-jitte det hele til native så lenge visse dynamiske teknikker ikke er ‘ ikke brukt. Som sådan ville det omtrent være teoretisk mulig å skrive en BIOS på .NET-språk eller Java, hvis man gjorde begge deler og sørget for at all nødvendig kjøretidsstøtte var tilgjengelig. Jeg forestiller meg at anstrengelsene for å gjøre det, ville mer enn å dverge alle bekvemmeligheter som ble funnet.
• @Tonny Faktisk kompilerer C # til naturlig kode msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx så det ‘ er rart å se det i listen over svake / dynamiske språk.
• @Den C # er vanligvis ikke kompilert til opprinnelig kode. Dette .Net-opprinnelige produktet som du lenker til, er ennå ikke offisielt utgitt. Fra det jeg ‘ har lest, vil den kompilere applikasjonskoden og den nødvendige rammekoden til en kjørbar. I følge FAQ vil dette først og fremst være målrettet mot Windows Store-apper, så det kan ta litt tid før dette støttes bredere. Alt som blir sagt, virker det som om Microsoft kan bevege seg bort fra den virtuelle maskinemodellen en stund i fremtiden hvis alt går bra.

Den faktiske BIOS for en datamaskin vil bli skrevet på et eller annet språk (sannsynligvis C eller samling) som er kompilert til arkitekturavhengig binær kode; denne koden kan ikke kjøres på noen annen arkitektur (og uten tvil trenger den ikke, da den allerede er veldig spesifikk for maskinen den leveres med).

Men tenker du muligens på Option ROMs (som noen ganger kalles BIOSer, som i «Video BIOS» for en GPU-alternativ ROM)?

For faktisk, eldre BIOS-kompatibel valg-ROM-er, ville de sannsynligvis være ISA-avhengig kjørbar kode (igjen generert av hvilket som helst språk som kan kompileres for å målrette ønsket arkitektur); PCI tillater også inkludert kode for flere ISAer og lar verten velge riktig binært bilde under oppstartsprosessen.

For UEFI-kompatibelt alternativ ROM-er, det er også et arkitekturuavhengig bytekodeformat som kan kjøres på forskjellige arkitekturer, men ISA-avhengig kode kan også fortsatt brukes.