Który język programowania jest używany do pisania programu BIOS?

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

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

Może tak ma wewnętrzny procesor?

Komentarze

  • możliwy duplikat Jak działają komputery?
  • Cross-posting jest wystarczająco zły, ale kiedy trafia na pytania Hot Network w obu wersjach , że ' jest tuż za bladą …
  • ” Kod BIOS / strumień bitów przechowywany w ROM powinien być ogólny (współpracować z wieloma typami procesorów lub ISA). ” – nigdy nie słyszałem o BIOS-ie, który współpracuje z wieloma ISA. masz przykład?
  • As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs). I ' d powiedz ” Nie, wręcz przeciwnie ”
  • To nie jest nawet reklama zdalna powielenie pytania tak ogólnego, jak ” Jak działają komputery? „. Proszę nie zamykać jako dupe.

Odpowiedź

BIOSy były pisane wyłącznie w języku asemblera, ale przejście zostało zrobione dawno temu, aby napisać większość kodu w jakimś języku wyższego poziomu i pozostawić napisane w asemblerze jak najmniejszą jego część, najlepiej tylko bootstrapper (pierwsze kilkaset instrukcji, które procesor przeskakuje po starcie / zresetowaniu) i wszelkie procedury zajmujące się określonymi dziwactwami podstawowej architektury.

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

To, co również bardzo pomogło w tym kierunku, to:

  • C biblioteki, które są przeznaczone dla określonej architektury i zawierają funkcje do radzenia sobie ze specyfiką tej architektury, na przykład funkcje do odczytu / zapisu bajtów do / z portów I / O architektury x86. Microsoft C zawsze oferował funkcje biblioteczne dla tego rodzaju rzeczy.

  • Kompilatory C, które nie tylko są przeznaczone dla określonej architektury procesora, ale nawet oferują rozszerzenia języka C, których można używać w rozkaz 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 programy obsługi przerwań i wymaga, aby miały specjalne sekwencje instrukcji wejścia / wyjścia. Od samego początku Microsoft C obsługiwał specjalne słowa kluczowe, których można było użyć do oznaczenia funkcji jako modułu obsługi przerwań, aby można było ją wywołać bezpośrednio przez przerwanie procesora, więc nie trzeba było pisać dla niej żadnego asemblera.

W dzisiejszych czasach zakładałbym, że większość BIOS-u jest napisana w C ++, jeśli nie w jakimkolwiek języku wyższego poziomu.

Ogromna większość kodu tworzącego BIOS jest specyficzny dla podstawowego sprzętu, więc tak naprawdę nie musi być przenośny: gwarantuje się, że będzie zawsze działał na tym samym typie procesora. Procesor może ewoluować, ale tak długo, jak zachowuje wsteczną zgodność z poprzednimi wersjami, może nadal uruchamiać niezmodyfikowany BIOS. Ponadto, jeśli zajdzie taka potrzeba, zawsze możesz przekompilować części BIOS-u napisane w C, aby działały natywnie na każdym nowym procesorze, który się pojawi.

Powód, dla którego piszemy BIOS w językach wyższego poziomu niż asemblerowanie wynika z tego, że łatwiej jest je napisać w ten sposób, a nie dlatego, że naprawdę muszą być przenośne.

Komentarze

  • Tak. Czasami możesz nawet mieć płytę główną powiązaną nie tylko z określoną 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żym stopniu 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ć.
  • @Reflection przyjrzyj się dokładnie, jak fizycznie wygląda płyta główna. Gniazdo procesora będzie miało określony układ pinów, który jest specyficzny dla rodziny procesorów, które akceptuje.Fizycznie nie można połączyć, powiedzmy Intel P4 z płytą główną AMD Opteron
  • Termin ” BIOS ” odnosi się do ” Podstawowy system wejścia / wyjścia ” komputera PC, więc posiadanie BIOS-u wymaga procesora x86. Systemy IA64 mają EFI zamiast BIOS, systemy PowerPC mogą mieć system Open Firmware lub system zastrzeżony, systemy Sparc mają również OFW (lub raczej OpenBoot), OLPC X0 to system oparty na architekturze x86, który wykorzystuje OFW. Nawet komputery PC nie ' nie używają już BIOS-u, przeszły na (U) EFI. OB / OFW jest interesujący, ponieważ został zaprojektowany nie tylko jako przenośny, ale także wieloplatformowy. Sterowniki OFW będą działać w każdym systemie OFW, są ” zapisywane po uruchomieniu w dowolnym miejscu „, niezależnie od procesora ISA.
  • ” Obecnie zakładam, że większość BIOS-u jest napisana w C ++ ” Nie ' t koniecznie zakładam, że to może być prawda, ale pracuję w tej branży i na pewno wiele programów ładujących jest napisanych w prostym C. Ludzie, którzy piszą tego typu rzeczy, to często ” Stara Gwardia ” i zwykle nie ufają w pełni C ++.
  • @TomDworzanski: Chociaż technicznie nie BIOS (który odnosi się wyłącznie do starego sprzętu PC z 1981 roku), wiele implementacji IEEE-1275 Open Firmware (które jest używane do podobnej roli jak BIOS w Sparc, PowerPC Common Hardware Reference Platform (np. PowerMac, PowerBook), laptop OLPC X0 za 100 $ -1) są częściowo napisane w językach innych niż assembler / C. OpenBoot , Otwórz oprogramowanie sprzętowe , OpenBIOS wszystkie zawierają…

Odpowiedź

Chociaż teoretycznie można napisać BIOS w dowolnym języku, współczesna rzeczywistość to większość BIOS-u jest napisana przy użyciu Assembly, C lub kombinacji tych dwóch .

BIOS musi być napisany w języku, który można skompilować do kodu maszynowego , który jest zrozumiały dla fizycznej maszyny sprzętowej. Eliminuje to języki interpretowane bezpośrednio lub pośrednio (Perl, Python, PHP, Ruby, Java, C #, JavaScript itp.) Jako odpowiednie do pisania systemu BIOS. (Chociaż teoretycznie można by zaimplementować jeden z tych języków do bezpośredniej kompilacji do statycznego kodu maszynowego lub w jakiś sposób osadzić interpreter w systemie BIOS. Jest na przykład Porzucić projekt GCJ dla Javy.)

Większość producentów OEM wdraża BIOS, rozszerzając własne, ogólne implementacje BIOS przez firmy takie jak American Megatrends i Phoenix Techologies . (Prawdopodobnie widzieliście już wcześniej jedną z tych firm wyświetlaną na pierwszym ekranie startowym komputera). Kod źródłowy tych implementacji nie jest publicznie dostępny, ale część z niego wyciekła. Nie chcę łączyć się z tym bezpośrednio do kodu źródłowego C i asemblera, ale są miejsca w Internecie, w których omawiany jest ten kod źródłowy dla tych, którzy chcą zajrzeć.

Niektórzy producenci sprzętu, na przykład ci, którzy koncentrują się na rynkach wysokiej wydajności i gier, nasycają swoje implementacje BIOS funkcjami dostosowywania, statystykami i atrakcyjnymi interfejsami użytkownika zaprojektowanymi pod kątem ich dokładnych implementacji. Wiele z tych funkcji wykracza poza to, co jest oferowane w produkowanych produktach generycznych firmy American Megatrends i innych. Niestety firmy te często postrzegają publikację kodu źródłowego jako zagrożenie bezpieczeństwa , więc niewiele wiadomo o tych zaawansowanych wdrożeniach, ponieważ niewiele się o nich mówi ld oczywiście znajdzie sposoby na dostęp i dekompilację takich implementacji BIOS-u, ale może to być trudne i prawdopodobnie nielegalne.

Wracając do pierwotnego pytania, z powodu potrzeby stworzenia natywnego kodu maszynowego, BIOSu musiałby być zaimplementowany w języku programowania obsługiwanym przez natywny kompilator kodu maszynowego . Chociaż istnieje wiele takich języków i chociaż jestem pewien, że w ciągu ostatnich kilku dekad w eksperymentach używano kilku języków, każda otwarta implementacja BIOS-u, jaką udało mi się znaleźć, opiera się w szczególności na połączeniu języka C i / lub assemblera. Pochodzące ze źródeł implementacje BIOS-u, które przyjrzałem się, aby sformułować taki wniosek, obejmują OpenBIOS , tinyBIOS , coreboot , Intel BIOS i Libreboot . Przyjrzałem się także kilku bardzo starym implementacjom BIOS-u, które nie są obecnie istotne, ale także stosowałem się do C i / lub reguły asemblera.

Myślę, że warto również przyjrzeć się innym programom współdziałają bezpośrednio ze sprzętem.Wiemy na przykład, że jądro Linuksa , jądro OS X i Jądro Windows jest w większości C z pewnymi asemblerami i kilkoma językami wyższego poziomu do określonych zadań. Wiemy również, że sterowniki sprzętu w systemie Linux i sterowniki sprzętu w systemie Windows są napisane głównie w języku C .

Wracając do BIOS-u, myślę, że ważne jest również, aby wziąć pod uwagę ekonomię wybranego języka programowania. BIOS jest ogólnie napisany jako konieczność uzupełnienia sprzedaży sprzętu. Wiadomo, że nowoczesne systemy BIOS są w dużej mierze napisane w C i / lub montażu. Przejście na inne narzędzie zwiększyłoby znaczne koszty produktów powszechnie uważanych za towarowe, co mogłoby bardzo niekorzystnie wpłynąć na sprzedaż. Bez wchodzenia w Ekonomię 101, mogę zapewnić, że prawdopodobnie nie jest to warto, aby producent OEM odszedł od wypróbowanych i prawdziwych narzędzi, które sprawdzały się przez dziesięciolecia.

Oczywiście istnieją i będą projekty hobbystyczne, które mają również na celu napisanie BIOS-u. Jak dotąd wydaje się, że oni również wybierają C i / lub montaż. Być może kiedyś zostaną użyte inne technologie. Ale dzisiaj wybór jest dobrze zdefiniowany.

Komentarze

  • Trochę trzeba wybierać nitki, ale C # i Java nie są interpretowane . Kompilują się do kodu bajtowego. Jest to kod bajtowy, który jest następnie obsługiwany przez interpreter. Nie ' nie zmienia logiki pierwszego akapitu.
  • @Tonny That ' jest poprawne. Dodałem ” bezpośrednio lub pośrednio zinterpretowane „, aby było trochę bardziej przejrzyste.
  • @Tonny zwykle a jitter zamiast interpretera, co jest ważną różnicą, ponieważ ' można wstępnie jitować wszystko na natywny, o ile pewne techniki dynamiczne nie są ' t używane. W związku z tym teoretycznie byłoby możliwe napisanie BIOS-u w językach .NET lub Javie, gdyby się to robiło i upewnił się, że dostępne jest całe potrzebne wsparcie w czasie wykonywania. Wyobrażam sobie, że wysiłki w tym celu przyniosłyby więcej niż wszelkie znalezione wygody.
  • @Tonny Właściwie C # kompiluje się do kodu natywnego msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx , więc ' dziwnie jest widzieć go na liście słabych / dynamicznych języków.
  • @Den C # jest zwykle skompilowany do kodu natywnego. Ten produkt .Net Native, z którym łączysz się, nie został jeszcze oficjalnie wydany. Z tego, co ' przeczytałem, skompiluję kod aplikacji i wymagany kod struktury do pliku wykonywalnego. Zgodnie z często zadawanymi pytaniami, będzie to początkowo skierowane do aplikacji ze Sklepu Windows, więc szersze wsparcie może zająć trochę czasu. Biorąc to wszystko pod uwagę, wydaje się, że Microsoft może w przyszłości odejść od modelu maszyny wirtualnej, jeśli wszystko pójdzie dobrze.

Odpowiedź

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

Ale czy prawdopodobnie myślisz o Opcjonalne ROMy (które są czasami nazywane BIOSami, jak w „Video BIOS” dla opcjonalnej pamięci ROM GPU)?

W przypadku rzeczywistej, starszej wersji BIOS opcjonalnych ROM-ów, prawdopodobnie byłyby one wykonywalnym kodem zależnym od ISA (ponownie generowanym przez dowolny język, który można skompilować w celu dostosowania do żądanej architektury); PCI również umożliwia dołączenie kodu dla wielu ISA i pozwala hostowi wybrać odpowiedni obraz binarny podczas procesu rozruchu.

Dla opcji zgodnej z UEFI ROM, istnieje również format kodu bajtowego niezależny od architektury , który można uruchomić na różnych architekturach, ale nadal można używać kodu zależnego od ISA.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *