Melyik programozási nyelven írják le a BIOS programot?

A BIOS-okat korábban kizárólag az assembly nyelvben írták, de a már régen megtörtént az átállás, hogy a kód nagy részét valamilyen magasabb szintű nyelvre írják, és a lehető legkevesebb részt, lehetőleg csak a bootstrappert hagyják összeírásban (a CPU ugrik az első néhány száz utasítás a start / reset után,) és bármilyen rutin foglalkozik az alapul szolgáló architektúra sajátos furcsaival.

A BIOS-okat már a kilencvenes évek elején elsősorban C-ben írták. (A kilencvenes évek elején írtam egy BIOS-t 90% C-ban, 10% -os összeállításban.)

Ami ebben az irányban is nagyban segített:

• C egy adott architektúrát megcélzó könyvtárak, amelyek tartalmazzák az adott architektúra sajátosságainak kezelésére szolgáló funkciókat, például az x86-os architektúra I / O portjaira érkező bájtok olvasására / írására szolgáló funkciókat. A Microsoft C mindig kínált könyvtári funkciókat az ilyen jellegű dolgokhoz.

• A C fordítók nemcsak egy adott CPU-architektúrát céloznak meg, de még olyan C-nyelv kiterjesztéseket is kínálnak, amelyekben használható speciális CPU-funkciókat használó kód írása. Például az x86 architektúra olyan megszakításként ismert dolgokat támogat, amelyek megszakításkezelőként ismert rutinokat hívnak elő, és speciális belépési / kilépési utasítássorozatokra van szükségük. A Microsoft C a kezdetektől fogva támogatta azokat a speciális kulcsszavakat, amelyekkel meg lehet jelölni egy függvényt megszakításkezelőként, így közvetlenül meghívhatja a CPU megszakítása, így nem kellett ehhez összeállítást írni.

Manapság azt feltételezném, hogy a BIOS nagy része C ++ nyelven íródott, ha nem akármilyen magasabb szintű nyelven.

A felépítő kód túlnyomó többsége egy BIOS az alapul szolgáló hardverre jellemző, ezért nem igazán kell hordozhatónak lennie: garantált, hogy mindig ugyanazon a típusú CPU-n fog futtatni. A CPU fejlődhet, de mindaddig, amíg visszafelé kompatibilis marad a korábbi verziókkal, változatlanul futtathatja a BIOS-t. Ezenkívül bármikor újrafordíthatja a BIOS C-ben írt részeit, hogy natív módon fusson minden felmerülő új CPU-n, ha erre szükség van.

Az ok, amiért a BIOS-okat magasabb szintű nyelveken írjuk, mint Az összeállítás azért van, mert így könnyebb ezeket megírni, nem azért, mert valóban hordozhatóaknak kell lenniük.

Megjegyzések

• Igen. Néha előfordulhat, hogy az alaplap nemcsak egy adott CPU-architektúrához, hanem még egy adott CPU-gyártóhoz is kapcsolódik. Manapság megvásárolható egy x86 alaplap, amely csak az Intel x86 CPU-kkal kompatibilis, vagy egy x86 alaplap, amely csak az AMD x86 CPU-kkal kompatibilis. Ezekben az alaplapokban a BIOS nagymértékben azonos lesz, mert a CPU mindkét esetben megérti az x86 utasításkészletet, és a perifériák többsége azonos, de néhány perifériának vannak olyan különbségei, amelyeket a BIOS-nak figyelembe kell vennie.
• @ Reflection alaposan vizsgálja meg, hogyan néz ki fizikailag az alaplap. A CPU foglalat egy bizonyos pin-elrendezéssel rendelkezik, amely az általa elfogadott CPU-családra jellemző.Fizikailag nem lehet csatlakozni, mondjuk az Intel P4-hez, az AMD Opteron alaplaphoz.
• A ” BIOS ” kifejezés a ” Alapvető bemeneti / kimeneti rendszer ” a PC-n, tehát a BIOS megléte x86-os CPU-t jelent. Az IA64 rendszerekben BIOS helyett EFI van, a PowerPC rendszerekben lehet Open Firmware rendszer vagy saját, a Sparc rendszerekben is van OFW (vagy inkább OpenBoot), az OLPC X0 egy x86 alapú rendszer, amely OFW-t használ. Még a PC-k sem ‘ nem használják tovább a BIOS-t, (U) EFI-re váltottak. Az OB / OFW érdekes, mert nemcsak hordozhatóvá, hanem több platformra is tervezték. Az OFW illesztőprogramok bármely OFW rendszeren működni fognak, ” Írják az egyszer futtatott bárhová “, CPU-tól függetlenül ISA.
• ” Manapság azt feltételezem, hogy a BIOS nagy része C ++ nyelven van írva ” Nem szeretnék ‘ nem feltétlenül feltételezi ezt: Lehet, hogy igaz, de én ebben az iparban dolgozom, és minden bizonnyal sok boot betöltő egyszerű C betűvel van írva. Azok, akik ilyeneket írnak, gyakran a ” Old Guard “, és hajlamosak még mindig nem bízni teljesen a C ++ – ban.
• @TomDworzanski: Bár technikailag nem a BIOS (ami kizárólag a BIOS-ra utal) a régi, 1981-es PC-cuccokhoz), az IEEE-1275 Open Firmware számos implementációja (amelyet hasonló szerephez használnak, mint a Sparc BIOS-ját, a PowerPC Common Hardware Reference Platform (pl. PowerMac, PowerBook), a 100 dolláros laptop OLPC X0 -1) részben az assembly / C nyelveken kívül vannak megírva. OpenBoot , Firmware megnyitása , OpenBIOS mind tartalmaz …

Míg elméletileg bármi nyelven írhatunk BIOS-t, a a modern valóság a legtöbb BIOS az Assembly, C vagy a két kombinációjával íródott.

A BIOS-t olyan nyelven kell írni, amely kompilálható gépi kódra , amelyet a fizikai hardver-gép ért. Ez kiküszöböli a közvetlenül vagy közepesen értelmezett nyelveket (Perl, Python, PHP, Ruby, Java, C #, JavaScript stb.), Amelyek megfelelőek a BIOS írásához. (Bár elméletileg megvalósíthatná az egyik ilyen nyelvet, hogy közvetlenül fordítson statikus gépi kódra, vagy valahogy beágyazhatja a tolmácsot a BIOS-ba. Létezik például a elhagyja a GCJ projektet Java-ra.)

A legtöbb OEM gyártja a BIOS-t úgy, hogy kiterjeszti a saját, általános BIOS-implementációkat olyan vállalatokkal, mint az American Megatrends és Phoenix Techologies . (Valószínűleg korábban látta már az egyik ilyen céget a számítógép első indítóképernyőjén.) Ezeknek a megvalósításoknak a forráskódja nem nyilvános, de némelyikük kiszivárgott. Nem akarok közvetlenül erre hivatkozni. a C és a assembly forráskódhoz, de az interneten vannak helyek, ahol erről a forráskódról beszélünk azok számára, akiket érdekel a bekukucskálás.

Egyes hardvergyártók, például a nagy teljesítményű és játékpiacokat célzó gyártók, telítették BIOS-implementációikat testreszabási funkciókkal, statisztikákkal és a pontos megvalósításukhoz tervezett vonzó felhasználói felületekkel. Ezen funkciók közül sok túlmutat az előállított generikus termékekben az American Megatrends és mások. Sajnos ezek a vállalatok gyakran a forráskódjuk kiadását biztonsági kockázatnak tekintik , ezért ezekről a csúcskategóriás implementációkról keveset tudni, mert keveset osztanak róluk Természetesen megtalálja az ilyen BIOS-megvalósítások elérésének és fordításának visszavonásának módját, de ez nehéz és esetleg illegális lehet.

Visszatérve az eredeti kérdésre, mivel szükség van natív gépi kód, egy BIOS előállítására. programozási nyelvben kellene megvalósítani, amelyet natív gépkód-fordító támogat . Bár sok ilyen nyelv létezik, és bár biztos vagyok benne, hogy az elmúlt évtizedekben több nyelvet is használtak a kísérletekben, minden olyan nyitott BIOS-implementáció, amelyet megtalálhattam, kifejezetten a C és / vagy az összeállítás kombinációjára támaszkodik. forrásból származó BIOS-implementációk, amelyeket ennek a következtetésnek az elkészítéséhez néztem, többek között az OpenBIOS , tinyBIOS , coreboot , Intel BIOS és Libreboot . Megnéztem néhány nagyon régi, ma még nem releváns BIOS-implementációt is, de betartottam a C és / vagy összeállítási szabályt is.

Úgy gondolom, hogy más, a közvetlenül kommunikálnak a hardverrel.Tudjuk például, hogy a Linux kernel , az OS X kernel és a A Windows kernel nagyrészt C, néhány összeszereléssel és néhány magasabb szintű nyelvvel meghatározott feladatokhoz. Azt is tudjuk, hogy a hardver illesztőprogramok Linux rendszeren és a hardver illesztőprogramok Windows rendszeren nagyrészt C .

Visszatérve a BIOS-hoz, azt gondolom, hogy a választott programozási nyelv gazdaságosságát is figyelembe kell venni. A BIOS-t általában a hardverértékesítés kiegészítésének szükségességeként írják. A modern BIOS-rendszerekről ismert, hogy nagyrészt C-ben és / vagy összeállításban írva. Ha valamilyen más eszközre lép, jelentős költségekkel járhat az általában árucikkeknek tekintett termék, ami nagyon hátrányosan befolyásolhatja az értékesítést. Anélkül, hogy belekezdenék a Economics 101-be, biztosíthatom Önöket, hogy valószínűleg nem megéri az OEM-nek, hogy eltérjen az évtizedek óta bevált és bevált eszközöktől.

Természetesen vannak és lesznek hobbi projektek a BIOS megírásához is. Úgy tűnik, hogy ezek is eddig a C-t és / vagy az összeszerelést választották. Talán egy napon más technológiákat is alkalmaznak. De manapság a választása jól körülhatárolható.

Megjegyzések

• Ez egy kicsit nit-picking, de a C # és a Java nincs értelmezve . Bájtkódra fordítanak. Ez a bájtkód, amelyet aztán egy tolmács kezel. Nem változtatja meg az első bekezdés logikáját ‘.
• @Tonny Ez a ‘ helyes. Azért adtam hozzá a ” -t, hogy egyenesen vagy közvetve értelmezzem a ” -t, hogy egy kicsit világosabb legyen.
• @Tonny általában a nem jet, hanem tolmács, ami azért fontos megkülönböztetés, mert ‘ lehetséges mindezt előrementetni a natív nyelvig, amíg bizonyos dinamikus technikák nem jelennek meg ‘ nem használt. Mint ilyen, elméletileg szinte lehetséges lenne BIOS-t írni .NET nyelveken vagy Java-ban, ha mindezt megteszi, és biztosítja, hogy minden szükséges futásidejű támogatás rendelkezésre álljon. Elképzelem, hogy ennek erőfeszítései nem csupán eltörpítenék a talált kényelmet.
• @Tonny Valójában a C # natív kódra fordít msdn.microsoft.com/hu -us / vstudio / dotnetnative.aspx , ezért ‘ furcsa látni a gyenge / dinamikus nyelvek listáján.
• @Den C # általában nem natív kódra van lefordítva. Ez a .Net Native termék, amelyhez linkel, még nem jelent meg hivatalosan. Abból, amit ‘ olvastam, az alkalmazáskódot és a szükséges keretrendszer-kódot futtatható fájlba állítja össze. A GYIK szerint ez eredetileg a Windows Store alkalmazásokat célozza meg, ezért eltarthat egy ideig, amíg ezt szélesebb körben támogatják. Mindezek alapján úgy tűnik, hogy a Microsoft egy ideig a jövőben eltávolodhat a virtuális gép modelljétől, ha minden jól megy.

A számítógép tényleges BIOS-át valamilyen nyelven (valószínűleg C vagy assembly) írják, amelyet architektúrától függő bináris kódra fordítanak; ez a kód nem futtatható más architektúrán (és vitathatatlanul nincs is rá szükség, mivel már nagyon jellemző arra a gépre, amellyel szállítják).

De gondolkodik-e Opciós ROM-ok (amelyeket néha BIOS-nak neveznek, mint például a GPU opcionális ROM-ok „Video BIOS” -ában)?

A tényleges, régi BIOS-kompatibilis opcionális ROM-ok, valószínűleg ISA-függő futtatható kódok lennének (amelyet ismét bármely olyan nyelv generál, amelyet össze lehet állítani a kívánt architektúra megcélozására); A PCI emellett lehetővé teszi, hogy több ISA kódot is tartalmazzon, és lehetővé teszi a gazdagép számára, hogy a rendszerindítás során kiválassza a megfelelő bináris képet.

UEFI-kompatibilis beállításhoz ROM-ok, létezik egy architektúrától független bájtkód-formátum is, amely különböző architektúrákon futtatható, de továbbra is használható ISA-függő kód.