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?
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”Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło