Wywołanie przerwania BIOS - BIOS interrupt call

Wywołania przerwań BIOS to funkcja, której systemy operacyjne i aplikacje używają do wywoływania funkcji oprogramowania Basic Input/Output System na komputerach zgodnych z IBM PC . Tradycyjnie wywołania systemu BIOS są używane głównie przez programy DOS i niektóre inne programy, takie jak programy ładujące (w tym, w większości historycznie, stosunkowo proste aplikacje, które uruchamiają się bezpośrednio i działają bez systemu operacyjnego — zwłaszcza oprogramowanie do gier). BIOS działa w trybie adresu rzeczywistego (tryb rzeczywisty) procesora x86, więc programy wywołujące BIOS muszą również działać w trybie rzeczywistym lub muszą przełączyć się z trybu chronionego do trybu rzeczywistego przed wywołaniem systemu BIOS i ponownym przełączeniem. Z tego powodu nowoczesne systemy operacyjne, które używają procesora w trybie chronionym lub w trybie Long, generalnie nie używają wywołań przerwań BIOS do obsługi funkcji systemowych, chociaż używają wywołań przerwań BIOS do sondowania i inicjowania sprzętu podczas rozruchu . Tryb rzeczywisty ma ograniczenie pamięci do 1 MB, nowoczesne programy ładujące (np. GRUB2 , Windows Boot Manager ) używają trybu nierzeczywistego lub chronionego (i wykonują wywołania przerwań BIOS w trybie Virtual 8086 , ale tylko do uruchamiania systemu operacyjnego), aby uzyskać dostęp do 4 GB pamięć.

We wszystkich komputerach instrukcje oprogramowania kontrolują fizyczny sprzęt (ekran, dysk, klawiatura itp.) od momentu włączenia zasilania. W komputerze system BIOS, wstępnie załadowany w pamięci ROM na płycie głównej, przejmuje kontrolę natychmiast po zresetowaniu procesora, w tym podczas włączania zasilania, po naciśnięciu przycisku resetowania sprzętu lub w przypadku krytycznej awarii oprogramowania ( potrójny błąd ) powoduje, że obwody płyty głównej automatycznie wyzwalają reset sprzętowy. BIOS testuje sprzęt i inicjuje jego stan; znajduje, ładuje i uruchamia program startowy (zwykle program ładujący system operacyjny i historyczny ROM BASIC ); i zapewnia podstawową kontrolę sprzętu dla oprogramowania uruchomionego na komputerze, które zwykle jest systemem operacyjnym (z aplikacjami), ale może być bezpośrednio uruchamianą pojedynczą aplikacją.

Ze strony IBM dostarczyli wszystkich informacji potrzebnych do pełnego wykorzystania BIOS-u lub bezpośredniego wykorzystania sprzętu i całkowitego uniknięcia BIOS-u podczas programowania wczesnych modeli IBM PC (przed PS/2). Od samego początku programiści mieli wybór, czy chcą używać BIOS-u, czy nie, na zasadzie peryferii sprzętowej. IBM zdecydowanie zachęcał do tworzenia „dobrze zachowujących się” programów, które uzyskiwały dostęp do sprzętu tylko przez wywołania BIOS INT (i wywołania usług DOS), aby wspierać zgodność oprogramowania z obecnymi i przyszłymi modelami komputerów PC z odmiennym sprzętem peryferyjnym, ale IBM zrozumiał to dla niektórych deweloperów oprogramowania i klientów sprzętu, wymagana była możliwość bezpośredniej kontroli sprzętu przez oprogramowanie użytkownika. Częściowo było tak dlatego, że znaczna część wszystkich cech sprzętowych i funkcji nie została ujawniona przez usługi BIOS-u. Dla dwóch przykładów (spośród wielu), adaptery MDA i CGA są zdolne do przewijania sprzętowego, a adapter szeregowy PC jest zdolny do przesyłania danych sterowanego przerwaniami, ale BIOS IBM nie obsługuje żadnej z tych przydatnych funkcji technicznych.

Obecnie BIOS w nowym komputerze nadal obsługuje większość, jeśli nie wszystkie, wywołania funkcji przerwań BIOS zdefiniowane przez IBM dla IBM AT (wprowadzone w 1984 r.), wraz z wieloma nowszymi, plus rozszerzenia niektórych oryginalnych ( np. rozszerzone zakresy parametrów) ogłoszone przez różne inne organizacje i współpracujące grupy branżowe. To, w połączeniu z podobnym stopniem kompatybilności sprzętowej, oznacza, że ​​większość programów napisanych dla IBM AT może nadal działać poprawnie na nowym komputerze, zakładając, że większa szybkość wykonywania jest akceptowalna (co zwykle dotyczy wszystkich gier oprócz gier, w których taktowanie oparte na procesorze). Pomimo znacznych ograniczeń usług dostępnych przez przerwania BIOS-u, okazały się one niezwykle użyteczne i odporne na zmiany technologiczne.

Cel wywołań BIOS

Wywołania przerwań systemu BIOS wykonują sterowanie sprzętowe lub funkcje we/wy żądane przez program, zwracają informacje systemowe do programu lub wykonują obie te czynności. Kluczowym elementem celu wywołań BIOS-u jest abstrakcja — wywołania BIOS-u wykonują ogólnie zdefiniowane funkcje, a szczegółowe informacje o tym, jak te funkcje są wykonywane na konkretnym sprzęcie systemu, są zawarte w BIOS-ie i ukryte przed programem. Na przykład program, który chce czytać z dysku twardego, nie musi wiedzieć, czy dysk twardy jest dyskiem ATA , SCSI , czy SATA (lub dawniej dyskiem ESDI , MFM lub RLL z być może kontroler Seagate ST-506 , być może jeden z kilku typów kontrolerów Western Digital lub z innym zastrzeżonym kontrolerem innej marki). Program musi jedynie zidentyfikować zdefiniowany w systemie BIOS numer dysku, do którego chce uzyskać dostęp, oraz adres sektora, do którego ma być odczytywany lub zapisywany, a system BIOS zajmie się przetłumaczeniem tego ogólnego żądania na określoną sekwencję wymaganych podstawowych operacji aby wykonać zadanie za pomocą określonego sprzętu kontrolera dysku, który jest podłączony do tego dysku. Program nie musi wiedzieć, jak kontrolować na niskim poziomie każdy rodzaj dysku twardego (lub karty graficznej, interfejsu portu lub urządzenia peryferyjnego zegara czasu rzeczywistego), do którego może potrzebować dostępu. To zarówno ułatwia programowanie systemów operacyjnych i aplikacji, jak i zmniejsza rozmiar programów, zmniejszając duplikację kodu programu, ponieważ funkcja zawarta w systemie BIOS nie musi być zawarta w każdym programie, który tego potrzebuje; zamiast tego programy zawierają stosunkowo krótkie wywołania systemu BIOS. (W systemach operacyjnych, w których nie jest używany system BIOS, wywołania usług dostarczane przez sam system operacyjny zazwyczaj spełniają tę samą funkcję i cel).

BIOS uwalnia również projektantów sprzętu komputerowego (w zakresie, w jakim programy są pisane wyłącznie do korzystania z BIOS-u) od przymusu zachowania dokładnej zgodności sprzętu ze starymi systemami podczas projektowania nowych systemów, aby zachować zgodność z istniejącym oprogramowaniem. Na przykład klawiatura w IBM PCjr działa zupełnie inaczej niż klawiatura we wcześniejszych modelach IBM PC, ale dla programów, które używają klawiatury tylko przez BIOS, ta różnica jest prawie niewidoczna. (Dobrym przykładem drugiej strony tego problemu jest fakt, że znaczna część programów komputerowych używanych w czasie wprowadzenia PCjr nie korzystała z klawiatury wyłącznie przez BIOS, więc IBM uwzględnił również funkcje sprzętowe w PCjr, aby emulować sposób działania oryginalnego sprzętu klawiatury IBM PC i IBM PC XT . Emulacja sprzętu nie jest dokładna, więc nie wszystkie programy, które próbują bezpośrednio korzystać ze sprzętu klawiatury, będą działać poprawnie na PCjr, ale wszystkie programy, które używają tylko usług klawiatury BIOS, będą .)

Oprócz zapewniania dostępu do urządzeń sprzętowych, BIOS zapewnia dodatkowe funkcje, które są zaimplementowane w oprogramowaniu BIOS. Na przykład BIOS utrzymuje oddzielne pozycje kursora dla maksymalnie ośmiu stron wyświetlania tekstu i zapewnia wyjście podobne do TTY z automatycznym zawijaniem wierszy i interpretacją podstawowych znaków sterujących, takich jak powrót karetki i wysuw wiersza, podczas gdy sprzęt do wyświetlania tekstu zgodny z CGA ma tylko jeden globalny kursor wyświetlacza i nie może automatycznie przesuwać kursora, używać pozycji kursora do adresowania pamięci wyświetlacza (aby określić, która komórka znaku zostanie zmieniona lub zbadana) lub zinterpretować znaki kontrolne. Na przykład interfejs klawiatury BIOS interpretuje wiele naciśnięć klawiszy i kombinacji klawiszy, aby śledzić różne stany zmiany biegów (lewy i prawy Shift , Ctrl i Alt ), aby wywołać usługę drukowania ekranu po naciśnięciu Shift + PrtScrn , aby ponownie uruchomić system po naciśnięciu klawiszy Ctrl + Alt + Del , aby śledzić stany blokady (Caps Lock, Num Lock i Scroll Lock) oraz, w maszynach klasy AT, kontrolować odpowiednie wskaźniki stanu blokady na klawiaturze, oraz do wykonywania innych podobnych funkcji interpretacyjnych i zarządzania klawiaturą. W przeciwieństwie do tego, zwykłe możliwości standardowego sprzętu klawiatury PC i PC-AT ograniczają się do zgłaszania do systemu każdego pierwotnego zdarzenia naciśnięcia lub zwolnienia pojedynczego klawisza (tj. przejścia ze stanu „zwolniony” do „wciśniętego” stanu lub odwrotnie), wykonanie polecenia resetowania i autotestu klawiatury oraz, w przypadku klawiatur klasy AT, wykonanie polecenia z systemu hosta w celu ustawienia stanów bezwzględnych wskaźników stanu blokady (diod LED).

Wywoływanie BIOS: przerwania oprogramowania BIOS

Systemy operacyjne i inne oprogramowanie komunikują się z oprogramowaniem BIOS w celu kontrolowania zainstalowanego sprzętu poprzez przerwania programowe. Przerwanie programowe to specyficzna odmiana ogólnej koncepcji przerwania. Przerwanie jest mechanizmem, za pomocą którego CPU może zostać nakłoniony do zatrzymania wykonywania programu linii głównej i natychmiastowego wykonania specjalnego programu, zwanego procedurą przerwania (ISR). Po zakończeniu ISR CPU kontynuuje pracę z programem głównym. Na procesorach x86, gdy wystąpi przerwanie, ISR do wywołania znajduje się w tablicy adresów punktów początkowych ISR (zwanych "wektorami przerwań") w pamięci: Tablica Wektorów Przerwań (IVT). Przerwanie jest wywoływane przez jego numer typu, od 0 do 255, a numer typu jest używany jako indeks w tablicy wektorów przerwań, a pod tym indeksem w tablicy znajduje się adres ISR, który zostanie uruchomiony w odpowiedzi na przerwać. Przerwanie programowe to po prostu przerwanie wyzwalane poleceniem programowym; dlatego przerwania programowe działają jak podprogramy, z tą główną różnicą, że program, który wykonuje wywołanie przerwania programowego, nie musi znać adresu ISR, tylko jego numer przerwania. Ma to zalety w zakresie modułowości, kompatybilności i elastyczności w konfiguracji systemu.

Wywołania przerwań systemu BIOS można traktować jako mechanizm przekazywania komunikatów między systemem BIOS a oprogramowaniem klienckim systemu BIOS, takim jak system operacyjny. Komunikaty żądają danych lub akcji z systemu BIOS i zwracają żądane dane, informacje o stanie i/lub produkt żądanej akcji do wywołującego. Komunikaty są podzielone na kategorie, każda z własnym numerem przerwania, a większość kategorii zawiera podkategorie, zwane "funkcjami" i identyfikowane przez "numery funkcji". Klient systemu BIOS przekazuje większość informacji do systemu BIOS w rejestrach procesora i odbiera większość informacji z powrotem w ten sam sposób, ale dane zbyt duże, aby zmieścić się w rejestrach, takie jak tabele parametrów kontrolnych lub dane sektora dysku do przesyłania dysków, są przekazywane przez przydzielenie bufora (czyli trochę miejsca) w pamięci i przekazywanie adresu bufora w rejestrach. (Czasami wiele adresów elementów danych w pamięci może być przekazywanych w strukturze danych w pamięci, z adresem tej struktury przekazywanym do BIOS w rejestrach.) Numer przerwania jest określony jako parametr instrukcji przerwania oprogramowania (w języku asemblera Intela , instrukcja „INT”), a numer funkcji jest określony w rejestrze AH; to znaczy, wywołujący ustawia w rejestrze AH numer żądanej funkcji. Ogólnie usługi BIOS odpowiadające każdemu numerowi przerwań działają niezależnie od siebie, ale funkcje w ramach jednej usługi przerwań są obsługiwane przez ten sam program BIOS i nie są niezależne. (Ten ostatni punkt dotyczy ponownego wejścia .)

Oprogramowanie BIOS zwykle powraca do wywołującego z kodem błędu, jeśli się nie powiedzie, lub z kodem stanu i/lub żądanymi danymi, jeśli się powiedzie. Same dane mogą być tak małe, jak jeden bit lub tak duże, jak 65 536 bajtów całych sektorów dysku surowego (maksymalnie, które zmieszczą się w jednym segmencie pamięci trybu rzeczywistego). BIOS był przez lata wielokrotnie rozszerzany i ulepszany przez wiele różnych podmiotów korporacyjnych, a niestety wynikiem tej ewolucji jest to, że nie wszystkie funkcje BIOS-u, które można nazwać, wykorzystują spójne konwencje formatowania i przekazywania danych lub raportowania wyników. Niektóre funkcje BIOS-u zgłaszają szczegółowe informacje o stanie, podczas gdy inne mogą nawet nie zgłaszać sukcesu lub niepowodzenia, ale po prostu wracają po cichu, pozostawiając dzwoniącemu założenie sukcesu (lub przetestowanie wyniku w inny sposób). Czasami może być również trudne ustalenie, czy określone wywołanie funkcji systemu BIOS jest obsługiwane przez system BIOS na określonym komputerze lub jakie są ograniczenia parametrów wywołania na tym komputerze. (W przypadku niektórych nieprawidłowych numerów funkcji lub poprawnych numerów funkcji z nieprawidłowymi wartościami kluczowych parametrów — szczególnie w przypadku wczesnej wersji systemu BIOS IBM — system BIOS może nic nie zrobić i powrócić bez kodu błędu; jest to [niewygodna, ale nieunikniona] odpowiedzialność wołającego, aby uniknąć tego przypadku, nie wykonując takich wywołań, lub pozytywnie przetestować oczekiwany efekt wywołania, zamiast zakładać, że wywołanie było skuteczne.Ponieważ BIOS ewoluował w wielu krokach w swojej historii, funkcja, która jest prawidłowa w jedna wersja systemu BIOS od pewnego dostawcy może nie być ważna we wcześniejszej lub odmiennej wersji systemu BIOS od tego samego dostawcy lub w wersji systemu BIOS — w dowolnym wieku — od innego dostawcy).

Ponieważ wywołania przerwań BIOS używają przekazywania parametrów w oparciu o rejestr procesora, wywołania są zorientowane tak, aby były wykonane z języka asemblera i nie mogą być bezpośrednio wykonane z większości języków wysokiego poziomu (HLL). Jednak język wysokiego poziomu może zapewnić bibliotekę procedur opakowujących, które tłumaczą parametry z formularza (zwykle opartego na stosie) używanego przez język wysokiego poziomu na formularz oparty na rejestrach wymagany przez BIOS, a następnie z powrotem do konwencji wywoływania HLL po BIOS powraca. W niektórych wariantach C, wywołania BIOS mogą być wykonane przy użyciu wbudowanego języka asemblera w module C. (Obsługa wbudowanego języka asemblerowego nie jest częścią standardu ANSI C, ale jest rozszerzeniem języka; dlatego moduły C, które używają wbudowanego języka asemblerowego są mniej przenośne niż czyste moduły C w standardzie ANSI.)

Wywołanie przerwania

Wywołanie przerwania może być wykonane przy użyciu instrukcji asemblera INT x86 . Na przykład, aby wydrukować znak na ekranie przy użyciu przerwania BIOS 0x10, można wykonać następujące instrukcje języka asemblera x86:

 mov ah, 0x0e    ; function number = 0Eh : Display Character
 mov al, '!'     ; AL = code of character to display
 int 0x10        ; call INT 10h, BIOS video service

Tabela przerwań

Listę typowych klas przerwań BIOS można znaleźć poniżej. Zauważ, że niektóre BIOS-y (szczególnie stare) nie implementują wszystkich tych klas przerwań.

BIOS używa również niektórych przerwań do przekazywania przerwań zdarzeń sprzętowych do programów, które zdecydują się je odbierać lub kierować komunikaty do własnego użytku. Poniższa tabela zawiera tylko te przerwania BIOS, które mają być wywoływane przez programy (używając instrukcji przerwania programowego języka asemblera "INT") w celu żądania usług lub informacji.

INT 18h: wykonaj BASIC

INT 18htradycyjnie przeskoczyłem do implementacji Cassette BASIC (dostarczonej przez Microsoft) przechowywanej w Option ROM-ach . To wywołanie jest zwykle wywoływane, jeśli system BIOS nie może zidentyfikować żadnych woluminów dysku startowego podczas uruchamiania.

W czasie, gdy oryginalny IBM PC (maszyna IBM typ 5150) został wydany w 1981 roku, BASIC w pamięci ROM był kluczową cechą. Współczesne popularne komputery osobiste, takie jak Commodore 64 i linia Apple II, również miały w pamięci ROM Microsoft Cassette BASIC (chociaż Commodore zmienił nazwę ich licencjonowanej wersji na Commodore BASIC), więc w znacznej części zamierzonego rynku komputery IBM PC potrzebowały BASIC do konkurowania. Podobnie jak w przypadku innych systemów, ROM BASIC IBM PC służył jako prymitywny bezdyskowy system operacyjny, pozwalający użytkownikowi ładować, zapisywać i uruchamiać programy, a także pisać i udoskonalać je. (Oryginalny IBM PC był również jedynym modelem PC od IBM, który, podobnie jak jego dwaj konkurenci, zawierał interfejs kasetowy. Podstawowy model IBM PC miał tylko 16 KiB pamięci RAM i nie miał żadnych napędów dyskowych [ żadnego rodzaju ], więc kaseta interfejs i BASIC w pamięci ROM były niezbędne, aby model podstawowy był użyteczny. IBM PC z mniej niż 32 KiB pamięci RAM nie jest w stanie uruchomić się z dysku. Spośród pięciu układów 8 KiB ROM w oryginalnym IBM PC, łącznie 40 KiB, cztery zawierają BASIC i tylko jeden zawiera BIOS; gdy zainstalowane jest tylko 16 KiB RAM, ROM BASIC stanowi ponad połowę całkowitej pamięci systemowej [dokładnie 4/7].)

W miarę upływu czasu BASIC nie był już dostarczany na wszystkich komputerach, przerwanie to po prostu wyświetlało komunikat o błędzie wskazujący, że nie znaleziono woluminu startowego (słynne „No ROM BASIC” lub bardziej objaśniające komunikaty w późniejszych wersjach BIOS-u); w innych wersjach BIOS-u poprosi użytkownika o włożenie woluminu startowego i naciśnięcie klawisza, a następnie po naciśnięciu klawisza pętla z powrotem do programu ładującego (INT 19h) w celu ponownego uruchomienia systemu.

Rainbow 100 B firmy Digital INT 18hnazywał swój BIOS, który był niekompatybilny z BIOSem IBM. Turbo Pascal , Turbo C i Turbo C++ zmieniły przeznaczenie INT 18 na alokację pamięci i stronicowanie. Inne programy również ponownie wykorzystały ten wektor do własnych celów.

Haki BIOS

DOS

W systemach DOS, IO.SYS lub IBMBIO.COM przechwytuje przerwanie INT 13 w celu wykrywania zmiany dyskietki, śledzenia wywołań formatowania, korygowania błędów granic DMA i obchodzenia problemów w BIOS-ie ROM IBM „01/10/84” z kodem modelu 0xFC przed pierwsze połączenie.

Omijanie BIOS-u

Wiele nowoczesnych systemów operacyjnych (takich jak Linux i Windows NT ) omija wywołania przerwań BIOS po uruchomieniu, jądro systemu operacyjnego przełącza procesor w tryb chroniony lub tryb długi podczas uruchamiania, preferując używanie własnych programów (takich jak sterowniki jądra ) do kontroli dołączony sprzęt bezpośrednio. Powodem tego było przede wszystkim to, że te systemy operacyjne uruchamiają procesor w trybie chronionym lub trybie długim, podczas gdy wywoływanie wywołania przerwania BIOS wymaga przełączenia na tryb rzeczywisty lub tryb nierzeczywisty lub użycie trybu wirtualnego 8086 . Tryb rzeczywisty, tryb nierzeczywisty i tryb wirtualny 8086 są wolne. Istnieją jednak również poważne powody bezpieczeństwa, aby nie przełączać się w tryb rzeczywisty, a kod BIOS trybu rzeczywistego ma ograniczenia zarówno pod względem funkcjonalności, jak i szybkości, które motywują projektantów systemów operacyjnych do znalezienia dla niego zamiennika. W rzeczywistości ograniczenia szybkości BIOS-u sprawiły, że nawet w erze DOSu programy obeszły go w celu uniknięcia ograniczeń wydajności, zwłaszcza w przypadku wyświetlania grafiki wideo i szybkiej komunikacji szeregowej. Problemy z funkcjonalnością BIOS-u obejmują ograniczenia w zakresie zdefiniowanych funkcji, niespójność w podzbiorach tych funkcji obsługiwanych na różnych komputerach oraz różnice w jakości BIOS-ów (tj. niektóre BIOS-y są kompletne i niezawodne, inne są skrócone i zawierają błędy). Biorąc sprawy w swoje ręce i unikając polegania na BIOS-ie, twórcy systemów operacyjnych mogą wyeliminować niektóre zagrożenia i komplikacje, jakie napotykają przy pisaniu i wspieraniu oprogramowania systemowego. Z drugiej strony, robiąc to, ci programiści stają się odpowiedzialni za dostarczanie oprogramowania sterowników „bare-metal” dla każdego innego systemu lub urządzenia peryferyjnego, z którym zamierzają współpracować z ich systemem operacyjnym (lub za nakłonienie producentów sprzętu do dostarczenia tych sterowników). Powinno więc być oczywiste, że kompaktowe systemy operacyjne opracowane przy niewielkich budżetach mają tendencję do intensywnego używania BIOS-u, podczas gdy duże systemy operacyjne budowane przez ogromne grupy inżynierów oprogramowania z dużymi budżetami częściej wybierałyby pisanie własnych sterowników zamiast korzystania z BIOS-u — to znaczy , nawet bez uwzględnienia problemów ze zgodnością systemu BIOS i trybu chronionego.

Zobacz też

• Wywołanie przerwania DOS
• Tablica deskryptorów przerwań
• Adres bazowy wejścia/wyjścia
• Lista przerwań Ralfa Browna

Bibliografia

• Lista przerwań x86 (znana również jako RBIL, Lista przerwań Ralfa Browna)
• Instrukcja obsługi wbudowanego systemu BIOS
• Podręcznik użytkownika PhoenixBIOS 4.0
• IBM Personal System/2 i Personal Computer BIOS Interface Technical Reference , IBM, 1988, OCLC  20737442
• System BIOS dla komputerów IBM PC, kompatybilnych i komputerów EISA , Phoenix Technologies , 1991, ISBN  0201577607
• Programmer's Guide to the AMIBIOS , American Megatrends , 1993, ISBN  0070015619
• The Programmer's PC Sourcebook autorstwa Thoma Hogana, Microsoft Press, 1991 ISBN  155615321X