Vilket programmeringsspråk används för att skriva ett BIOS-program?

Som jag förstår ska BIOS-koden / bitströmmen som finns i ROM-enheten vara generisk (fungerar tillsammans med flera CPU-typer eller ISA). Dessutom såg jag nämnt på webben att det är möjligt att dumpa dess kod (och ”demontera” den).

Så, i vilket språk, instruktionsuppsättning eller maskinkod är det skrivet? Behöver den inte någon form av processor för att utföra sina operationer? Om så är fallet antar jag att den kommer att använda den externa processorn, hur känner den den specifika instruktionsuppsättningen för den anställda?

Kanske det har en intern processor?

Kommentarer

  • möjlig duplikat av Hur fungerar datorer?
  • Korspostering är dåligt nog, men när det hamnar på Hot Network Questions i båda versionerna , att ’ är strax bortom den bleka …
  • ” BIOS-kod / bitström som hölls i ROM bör vara generiskt (fungerar tillsammans med flera CPU-typer eller ISA). ” – Jag har aldrig hört talas om ett BIOS som fungerar med flera ISA. har du ett exempel?
  • As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs). Jag ’ d säger ” Nej, tvärtom ”
  • Detta är inte ens fjärrannons kopia av en fråga som är så allmän som ” Hur fungerar datorer? ”. Stäng inte som duper.

Svar

BIOS-filer skrivs enbart på monteringsspråk, men övergången gjordes för länge sedan för att skriva majoriteten av koden på något högre språk, och lämna skrivet i montering så få delar av den som möjligt, helst bara bootstrapper, (de allra första hundratals instruktionerna som CPU hoppar till efter en start / återställning,) och vilka rutiner som helst hanterar specifika särdrag i den underliggande arkitekturen.

BIOS skrevs redan främst i C redan tidigt på nittiotalet. (Jag skrev ett BIOS i 90% C, 10% montering i början av nittiotalet.)

Det som också har hjälpt mycket i denna riktning är:

  • C bibliotek som är inriktade på en specifik arkitektur och inkluderar funktioner för att hantera särdrag hos den arkitekturen, till exempel funktioner för att läsa / skriva byte till / från I / O-portar i x86-arkitekturen. Microsoft C har alltid erbjudit biblioteksfunktioner för den typen av saker.

  • C-kompilatorer som inte bara riktar sig mot en specifik CPU-arkitektur utan till och med erbjuder tillägg till C-språket som du kan använda på för att skriva kod som använder speciella CPU-funktioner. Till exempel stöder x86-arkitekturen saker som kallas interrupt, som åberopar rutiner som kallas interrupt-hanterare, och det kräver att de har speciella instruktions- / inmatningssekvenser. Från de allra första dagarna stödde Microsoft C speciella nyckelord som du kan använda för att markera en funktion som en avbrottshanterare, så att den kan åberopas direkt av ett CPU-avbrott, så att du inte behövde skriva någon enhet för den.

Nuförtiden skulle jag anta att det mesta av BIOS är skrivet i C ++, om inte på något högre nivå språk.

De allra flesta av koden som utgör ett BIOS är specifikt för den underliggande hårdvaran, så det behöver inte vara bärbart: det garanteras att det alltid kommer att köras på samma typ av CPU. CPU: n kan utvecklas, men så länge den bibehåller bakåtkompatibilitet med tidigare versioner kan den fortfarande köra BIOS omodifierad. Dessutom kan du alltid kompilera om de delar av BIOS som är skrivna i C för att kunna köras på alla nya processorer som kommer upp, om behovet uppstår.

Anledningen till att vi skriver BIOS på språk på en högre nivå än montering beror på att det är lättare att skriva dem på det här sättet, inte för att de verkligen behöver vara bärbara.

Kommentarer

  • Ja. Ibland kan du till och med ha ett moderkort inte bara bundet till en specifik CPU-arkitektur utan även till en specifik CPU-leverantör. Numera kan du köpa ett x86-moderkort som bara är kompatibelt med Intel x86-processorer, eller ett x86-moderkort som endast är kompatibelt med AMD x86-processorer. BIOS i dessa moderkort kommer i hög grad att vara identiskt, för i båda fallen förstår CPU: n instruktionsuppsättningen x86, och de flesta kringutrustning är identiska, men vissa kringutrustning har skillnader som BIOS måste ta hänsyn till.
  • @ Reflektion titta närmare på hur ett moderkort fysiskt ser ut. CPU-uttaget har ett visst stiftarrangemang, vilket är specifikt för familjen av processorer som det accepterar.Du kan fysiskt inte ansluta säg en Intel P4 till ett AMD Opteron-moderkort
  • Termen ” BIOS ” avser ” Basic Input / Output System ” på en dator, så att ha ett BIOS innebär en x86 CPU. IA64-system har en EFI istället för ett BIOS, PowerPC-system kan ha ett öppet firmware-system eller ett eget, Sparc-system har också OFW (eller snarare OpenBoot), OLPC X0 är ett x86-baserat system som använder OFW. Även datorer ’ inte använder BIOS längre, de har bytt till (U) EFI. OB / OFW är intressant, för det är utformat för att inte bara vara bärbart utan plattform. OFW-drivrutiner fungerar på vilket som helst OFW-system, de är ” Skriv en gång kör någonstans ”, oavsett CPU ISA.
  • ” Numera antar jag att det mesta av BIOS är skrivet i C ++ ” Jag skulle inte vilja ’ antar inte nödvändigtvis att, Det kan vara sant men jag arbetar i den branschen och säkert många bootloaders är skrivna i vanlig C. De som skriver den typen av saker är ofta ” Old Guard ” och tenderar inte att helt lita på C ++ fortfarande.
  • @TomDworzanski: Även om det tekniskt inte är BIOS (som endast refererar till till de gamla PC-grejerna från 1981), många implementeringar av IEEE-1275 Open Firmware (som används för en liknande roll som BIOS på Sparc, PowerPC Common Hardware Reference Platform (t.ex. PowerMac, PowerBook), den 100 $ bärbara datorn OLPC X0 -1) skrivs delvis på andra språk än montering / C. OpenBoot , Öppna firmware , OpenBIOS alla innehåller …

Svar

Även om man i teorin kan skriva BIOS på vilket språk som helst, modern verklighet är mest BIOS skrivs med hjälp av Assembly, C eller en kombination av de två .

BIOS måste skrivas på ett språk som kan kompileras till maskinkod , vilket förstås av den fysiska maskinvarumaskinen. Detta eliminerar de direkt eller mellanliggande tolkade språken (Perl, Python, PHP, Ruby, Java, C #, JavaScript, etc.) som lämpliga för att skriva BIOS. (Men i teorin kan man implementera ett av dessa språk för att antingen kompilera direkt till statisk maskinkod eller så kan man på något sätt bädda in tolk i BIOS. Det finns till exempel abandonware GCJ-projekt för Java.)

De flesta OEM-företag implementerar ett BIOS genom att utöka egna, generiska BIOS-implementeringar av företag som American Megatrends och Phoenix Techologies . (Du har antagligen sett ett av dessa företag visas på datorns första startskärm tidigare.) Källkoden för dessa implementeringar är inte tillgänglig för allmänheten, men en del av den har läckt ut. Jag vill inte länka till detta direkt till C- och monteringskällkoden, men det finns platser på Internet där denna källkod diskuteras för dem som bryr sig om att kika.

Vissa hårdvarutillverkare, som de som riktar sig till marknaderna med hög prestanda och spel, mättar sina BIOS-implementeringar med anpassningsfunktioner, statistik och attraktiva användargränssnitt som är utformade för deras exakta implementeringar. Många av dessa funktioner går utöver vad som erbjuds i generiska produkter som produceras av amerikanska Megatrends och andra. Tyvärr ser dessa företag ofta frisättningen av källkoden som en säkerhetsrisk , så lite är känt om dessa avancerade implementeringar eftersom lite delas om dem Naturligtvis skulle jag hitta sätt att komma åt och de-kompilera sådana BIOS-implementeringar men det kan vara svårt och möjligen olagligt.

Återgå till den ursprungliga frågan på grund av behovet av att producera inbyggd maskinkod, ett BIOS måste implementeras i ett programmeringsspråk som stöds av en inbyggd maskinkodkompilator . Även om det finns många sådana språk och även om jag är säker på de senaste decennierna har flera språk använts i experiment, men varje öppen BIOS-implementering jag har kunnat hitta är beroende av en kombination av C och / eller montering. BIOS-implementeringar som jag tittade på för att skapa denna slutsats inkluderar OpenBIOS , tinyBIOS , coreboot , Intel BIOS och Libreboot . Jag tittade också på några mycket gamla BIOS-implementeringar som inte är relevanta idag men också följde C- och / eller monteringsregeln.

Jag tycker att det också är relevant att titta på annan programvara byggd för interagera direkt med hårdvara.Vi vet till exempel att Linux-kärnan , OS X-kärnan och Windows-kärnan är till stor del C med en del montering och några språk på högre nivå för specifika uppgifter. Vi vet också att hårdvarudrivrutiner på Linux och hårdvarudrivrutiner på Windows är skrivna till stor del i C .

Att komma tillbaka till BIOS, jag tycker att det också är viktigt att ta hänsyn till ekonomin för det valda programmeringsspråket. BIOS skrivs vanligtvis som en nödvändighet för att komplettera hårdvaruförsäljning. Moderna BIOS-system är kända för att vara till stor del skrivet i C och / eller montering. En övergång till något annat verktyg skulle tillföra betydande kostnader för vad som i allmänhet anses vara råvaruprodukter som kan påverka försäljningen mycket negativt. Utan att komma in i Economics 101 kan jag försäkra er om att det förmodligen inte det är värt det för en OEM att avvika från beprövade verktyg som har bevisats under årtionden.

Naturligtvis finns det och kommer att finnas hobbyprojekt för att skriva BIOS också. Hittills verkar även dessa välja C och / eller montering. Kanske en dag kommer andra tekniker att användas. Men idag är valet av väldefinierat.

Kommentarer

  • Det är lite nit-picking men C # och Java tolkas inte . De kompilerar för byte-kod. Det är byte-koden som sedan hanteras av en tolk. Ändrar ’ inte logiken i första stycket.
  • @Tonny Det ’ är korrekt. Jag lade till ” direkt eller mellanliggande tolkat ” för att vara lite tydligare.
  • @Tonny normalt en jitter snarare än en tolk, vilket är en viktig skillnad eftersom det ’ är möjligt att förjita allt till native så länge som vissa dynamiska tekniker inte är ’ används inte. Som sådan skulle det nästan vara teoretiskt möjligt att skriva ett BIOS på .NET-språk eller Java, om man gjorde både det och såg till att allt runtime-stöd som behövdes var tillgängligt. Jag föreställer mig att ansträngningarna att göra det skulle mer än dvärga alla bekvämligheter som hittades.
  • @Tonny Egentligen kompilerar C # till inbyggd kod msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx så det ’ är konstigt att se det i listan över svaga / dynamiska språk.
  • @Den C # är vanligtvis inte kompilerad till inbyggd kod. Denna .Net-inbyggda produkt som du länkar till har ännu inte officiellt släppts. Från vad jag ’ har läst kommer det att sammanställa applikationskoden och den nödvändiga ramkoden till en körbar. Enligt FAQ kommer detta inledningsvis att riktas till Windows Store-appar, så det kan ta lite tid innan detta stöds bredare. Allt som sägs verkar det som om Microsoft kan komma bort från den virtuella maskinmodellen någon gång i framtiden om allt går bra.

Svar

Den faktiska BIOS för en dator skulle skrivas på något språk (förmodligen C eller sammansättning) som kompileras till arkitekturberoende binär kod; den här koden kan inte köras på någon annan arkitektur (och utan tvekan behöver det inte, eftersom den redan är väldigt specifik för den maskin som den levereras med.

Men tänker du kanske på Option ROMs (som ibland kallas BIOS, som i ”Video BIOS” för en GPU-option ROM)?

För faktisk, äldre BIOS-kompatibel alternativ-ROM-skivor, de skulle troligen vara ISA-beroende körbar kod (återigen genererad av vilket språk som helst som kan kompileras för att rikta sig till önskad arkitektur); PCI tillåter även inklusive kod för flera ISA och låter värden välja lämplig binär bild under startprocessen.

För UEFI-kompatibelt alternativ ROM-skivor, det finns också ett arkitekturoberoende bytekodformat som kan köras på olika arkitekturer, men ISA-beroende kod kan också fortfarande användas.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *