W jakim języku programowania jest napisany program BIOS?


65

Jak rozumiem, kod BIOS / strumień bitów przechowywany w pamięci ROM powinien być ogólny (działać razem z wieloma typami procesorów lub ISA). Ponadto widziałem wspomniane w Internecie, że można zrzucić jego kod (i „go zdemontować”).

Więc w jakim języku, zestawie instrukcji lub kodzie maszynowym jest napisany? Czy nie potrzebuje żadnego procesora do wykonywania swoich operacji? Jeśli tak, myślę, że użyje zewnętrznego procesora, to skąd zna konkretny zestaw instrukcji zastosowanego?

Może ma wewnętrzny procesor?


9
możliwy duplikat Jak działają komputery?
komar

39
Cross posting jest wystarczająco zły, ale kiedy kończy się na Hot Network Questions w obu wersjach , jest to po prostu blady ...
Mason Wheeler

8
„Kod BIOS / strumień bitów przechowywany w pamięci ROM powinien być ogólny (współpracować z wieloma typami procesorów lub ISA).” - Nigdy nie słyszałem o systemie BIOS, który działa z wieloma programami ISA. Czy masz przykład?
chx

6
As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs). Powiedziałbym „Nie, wręcz przeciwnie”
edc65

11
Nie jest to nawet zduplikowana odpowiedź na tak ogólne pytanie jak „Jak działają komputery?”. Proszę nie zamykać jako dupe.
Andres F.,

Odpowiedzi:


103

BIOSy były pisane wyłącznie w języku asemblera, ale dawno temu dokonano przejścia, aby napisać większość kodu w jakimś języku wyższego poziomu i pozostawić napisane w asemblerze jak najmniej jego części, najlepiej tylko bootstrapper, (pierwsze kilkaset instrukcji, do których procesor przeskakuje po uruchomieniu / resecie) i wszelkie procedury dotyczące określonych dziwactw podstawowej architektury.

BIOSy pisano już głównie w C już na początku lat dziewięćdziesiątych. (Napisałem BIOS w 90% C, 10% montaż na początku lat dziewięćdziesiątych.)

W tym kierunku bardzo pomogło również:

  • Biblioteki C, które są ukierunkowane na określoną architekturę i zawierają funkcje do radzenia sobie ze specyfikami tej architektury, na przykład funkcje do odczytu / zapisu bajtów do / z portów we / wy architektury x86. Microsoft C zawsze oferował funkcje biblioteczne dla tego rodzaju rzeczy.

  • Kompilatory C, które nie tylko są ukierunkowane na określoną architekturę procesora, ale nawet oferują rozszerzenia języka C, których można używać do pisania kodu wykorzystującego specjalne funkcje procesora. Na przykład architektura x86 obsługuje rzeczy znane jako przerwania, które wywołują procedury znane jako procedury obsługi przerwań i wymaga od nich specjalnych sekwencji instrukcji wejścia / wyjścia. Od samego początku Microsoft C wspierał specjalne słowa kluczowe, których można użyć do oznaczenia funkcji jako procedury obsługi przerwań, aby można było ją wywoływać bezpośrednio przez przerwanie procesora, dzięki czemu nie trzeba było pisać dla niej żadnego zestawu.

Obecnie zakładam, że większość BIOSu jest napisana w C ++, jeśli nie w jakimkolwiek języku wyższego poziomu.

Zdecydowana większość kodu tworzącego system BIOS jest specyficzny dla podstawowego sprzętu, więc tak naprawdę nie musi być przenośny: gwarantuje się, że zawsze będzie działał na tym samym typie procesora. Procesor może ewoluować, ale dopóki zachowuje zgodność wsteczną z poprzednimi wersjami, może nadal działać w niezmodyfikowanym systemie BIOS. Ponadto zawsze można ponownie skompilować części systemu BIOS napisane w języku C, aby działały natywnie na każdym nowym procesorze, który pojawi się, jeśli zajdzie taka potrzeba.

Powodem, dla którego piszemy BIOS-y w językach wyższego poziomu niż asembler, jest to, że łatwiej jest je pisać w ten sposób, a nie dlatego, że naprawdę muszą być przenośne.


7
Tak. Czasami płyta główna może być powiązana nie tylko z konkretną architekturą procesora, ale nawet z konkretnym dostawcą procesora. Obecnie można kupić płytę główną x86, która jest kompatybilna tylko z procesorami Intel x86, lub płytę główną x86, która jest kompatybilna tylko z procesorami AMD x86. BIOS na tych płytach głównych będzie w dużej mierze identyczny, ponieważ w obu przypadkach procesor rozumie zestaw instrukcji x86, a większość urządzeń peryferyjnych jest identyczna, ale niektóre urządzenia peryferyjne mają różnice, które BIOS musi uwzględnić.
Mike Nakis,

4
@ Refleksja przyjrzyj się, jak fizycznie wygląda płyta główna. Gniazdo procesora będzie miało określony układ styków, który jest specyficzny dla rodziny procesorów, które akceptuje. Nie można fizycznie połączyć, powiedzmy, Intel P4 z płytą główną AMD Opteron
Caleth

14
Termin „BIOS” odnosi się do „podstawowego systemu wejścia / wyjścia” komputera, więc posiadanie systemu BIOS oznacza procesor x86. Systemy IA64 mają EFI zamiast BIOS, systemy PowerPC mogą mieć system Open Firmware lub zastrzeżony, systemy Sparc mają również OFW (a raczej OpenBoot), OLPC X0 jest systemem opartym na x86, który wykorzystuje OFW. Nawet komputery nie używają BIOS-u, przełączyły się na (U) EFI. OB / OFW jest interesujący, ponieważ ma być nie tylko przenośny, ale także wieloplatformowy. Sterowniki OFW będą działać na każdym systemie OFW, są one „Write Once Run Anywhere”, niezależnie od CPU ISA.
Jörg W Mittag

14
„W dzisiejszych czasach zakładałbym, że większość BIOS-u jest napisana w C ++” Nie musiałbym zakładać, że to prawda, ale pracuję w tej branży i na pewno wiele programów ładujących jest napisanych zwykłym C. Ludzie, którzy piszą tego rodzaju rzeczy to często „Old Guard” i zwykle nie ufają w pełni C ++.
Sam

6
@TomDworzański: Choć technicznie nie jest to BIOS (który odnosi się wyłącznie do starych komputerów PC z 1981 r.), Wiele implementacji otwartego oprogramowania układowego IEEE-1275 (używanego do podobnej roli jak BIOS w Sparc, wspólnej platformie sprzętowej PowerPC (np. PowerMac, PowerBook), laptop 100 $ OLPC X0-1) są napisane częściowo w językach innych niż asembler / C. OpenBoot , Open Firmware , OpenBIOS zawierają…
Jörg W Mittag

11

Podczas gdy teoretycznie można pisać BIOS w dowolnym języku, współczesna rzeczywistość jest taka, że większość BIOS-u jest pisana przy użyciu Asemblera, C lub ich kombinacji .

BIOS musi być napisany w języku, który można skompilować z kodem maszynowym , zrozumiałym dla fizycznego komputera sprzętowego. Eliminuje to języki interpretowane bezpośrednio lub pośrednio (Perl, Python, PHP, Ruby, Java, C #, JavaScript itp.) Jako odpowiednie do pisania BIOS-u. (Chociaż teoretycznie można zaimplementować jeden z tych języków w celu kompilacji bezpośrednio do statycznego kodu maszynowego lub w jakiś sposób osadzić interpreter w systemie BIOS. Istnieje na przykład projekt GCJ w Javie dla porzuconego oprogramowania ).

Większość producentów OEM wdraża system BIOS, rozszerzając zastrzeżone, ogólne implementacje systemu BIOS przez firmy takie jak American Megatrends i Phoenix Techologies . (Prawdopodobnie wcześniej widziałeś jedną z tych firm na pierwszym ekranie rozruchowym komputera.) Kod źródłowy dla tych implementacji nie jest publicznie dostępny, ale niektóre z nich wyciekły. Nie chcę linkować tego bezpośrednio do kodu źródłowego C i asemblera, ale są miejsca w Internecie, w których ten kod źródłowy jest omawiany dla tych, którzy chcą zajrzeć.

Niektórzy producenci sprzętu, na przykład ci ukierunkowani na rynki o wysokiej wydajności i rynku gier, nasycają swoje wdrożenia BIOS funkcjami dostosowywania, statystykami i atrakcyjnymi interfejsami użytkownika zaprojektowanymi z myślą o ich dokładnych implementacjach. Wiele z tych funkcji wykracza poza to, co jest oferowane w ogólnych produktach wytwarzanych przez amerykańskie Megatrends i inne. Niestety, firmy te często postrzegają wydanie swojego kodu źródłowego jako zagrożenie dla bezpieczeństwa , więc niewiele wiadomo o tych zaawansowanych implementacjach, ponieważ niewiele się o nich mówi. Można oczywiście znaleźć sposoby na uzyskanie dostępu i dekompilację takich implementacji systemu BIOS, ale może to być trudne i być może nielegalne.

Wracając do pierwotnego pytania, z powodu potrzeby tworzenia natywnego kodu maszynowego, BIOS musiałby zostać zaimplementowany w języku programowania obsługiwanym przez natywny kompilator kodu maszynowego . Chociaż istnieje wiele takich języków i jestem pewien, że w ciągu ostatnich kilku dziesięcioleci, eksperymentowano z kilkoma językami, każda otwarta implementacja BIOS-u, którą udało mi się znaleźć, polega konkretnie na kombinacji C i / lub asemblera. Open-pozyskiwane implementacje BIOS Spojrzałem na tworząc ten wniosek obejmuje OpenBIOS , tinyBIOS , coreboot , Intel BIOS i Libreboot. Przyjrzałem się także niektórym bardzo starym implementacjom BIOS-u, które dziś nie są istotne, ale także przestrzegałem zasady C i / lub asemblera.

Wydaje mi się, że warto także spojrzeć na inne oprogramowanie stworzone do bezpośredniej interakcji ze sprzętem. Wiemy na przykład, że Linux Kernel The kernel OS X , a jądro systemu Windows są w dużej mierze C z jakimś zespołem i niektórych językach wyższego poziomu dla poszczególnych zadań. Wiemy również, że sterowniki sprzętowe w systemie Linux i sterowniki sprzętowe w systemie Windows są napisane głównie w C.

Wracając do BIOS-u, myślę, że ważne jest również rozważenie ekonomiki wybranego języka programowania. BIOS jest ogólnie pisany jako konieczność uzupełniania sprzedaży sprzętu. Wiadomo, że współczesne systemy BIOS są w dużej mierze napisane w C i / lub asemblerze. Przejście na inne narzędzie spowodowałoby znaczne koszty w odniesieniu do produktów powszechnie uważanych za towary, które mogłyby bardzo negatywnie wpłynąć na sprzedaż. Nie wchodząc w Economics 101, zapewniam cię, że producent OEM nie powinien odejść od wypróbowanych i sprawdzonych narzędzi, które zostały sprawdzone przez dziesięciolecia.

Oczywiście istnieją i będą hobbystyczne projekty pisania BIOS-u. Te też wydają się wybierać C i / lub montaż. Być może któregoś dnia zostaną wykorzystane inne technologie. Ale dzisiaj wybór jest dobrze określony.


4
To trochę wybieranie nitów, ale C # i Java nie są interpretowane. Kompilują się do kodu bajtowego. Jest to kod bajtowy, który jest następnie obsługiwany przez interpretera. Nie zmienia logiki pierwszego akapitu.
Tonny

1
@Tonny To prawda. Dodałem „bezpośrednio lub pośrednio zinterpretowany”, aby było trochę jaśniej.

@Tonny zwykle jest jittera, a nie tłumacza, co jest ważnym rozróżnieniem, ponieważ możliwe jest wstępne wszystko to natywne, pod warunkiem, że nie są używane pewne techniki dynamiczne. W związku z tym teoretycznie możliwe byłoby napisanie BIOS-u w językach .NET lub Javie, gdyby zrobić to jedno i upewnić się, że cała wymagana obsługa środowiska wykonawczego jest dostępna. Wyobrażam sobie jednak, że wysiłki w tym zakresie przyniosłyby więcej niż jakiekolwiek wygody.
Jon Hanna

1
@Tonny Właściwie C # kompiluje się do natywnego kodu msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx, więc dziwnie jest widzieć go na liście słabych / dynamicznych języków.
Den

@ Den C # zwykle nie jest kompilowany do kodu natywnego. Ten produkt .Net Native, do którego prowadzi łącze, nie został jeszcze oficjalnie wydany. Z tego, co przeczytałem, skompiluje kod aplikacji i wymagany kod frameworka w plik wykonywalny. Zgodnie z często zadawanymi pytaniami będzie to początkowo ukierunkowane na aplikacje ze Sklepu Windows, więc może zająć trochę czasu, zanim będzie ono obsługiwane w szerszym zakresie. Mimo wszystko wydaje się, że Microsoft może odejść od modelu maszyny wirtualnej w przyszłości, jeśli wszystko pójdzie dobrze.

4

Rzeczywisty BIOS dla komputera zostałby napisany w jakimś języku (prawdopodobnie C lub asemblerze) skompilowanym do kodu binarnego zależnego od architektury; ten kod nie może działać na żadnej innej architekturze (i prawdopodobnie nie musi tak naprawdę, ponieważ jest już bardzo specyficzny dla maszyny, z którą jest dostarczany).

Ale czy myślisz o opcjach ROM (które są czasami nazywane BIOSami, jak w „BIOSie wideo” dla ROM opcji GPU)?

W przypadku rzeczywistych, opcjonalnych ROM-ów kompatybilnych z BIOS-em, prawdopodobnie byłyby to pliki wykonywalne zależne od ISA (ponownie generowane przez dowolny język, który można skompilować w celu uzyskania pożądanej architektury); PCI pozwala także na dołączenie kodu dla wielu ISA i pozwala gospodarzowi wybrać odpowiedni obraz binarny podczas procesu rozruchu.

W przypadku opcjonalnych ROM-ów kompatybilnych z UEFI istnieje również niezależny od architektury format bajtów, który można uruchomić na różnych architekturach, ale nadal można stosować kod zależny od ISA.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.