Tag: daj się poznać

Ogólne spojrzenie na architekturę x86

Złożoność

Architektura x86 dojrzewała przez lata. Inżynierowie przez cały czas starali się zachować zgodność wsteczną, wysoką przystosowalność do potrzeb programistów oraz oczywiście dodawać nowe i ulepszać stare funkcje. Z tych powodów IA-32 jest dosyć skomplikowana. Nim zanurzymy się w pełen dobrodziejstw tryb chroniony, warto poznać podstawowe elementy architektoniczne, które będziemy oprogramowywali :)

W tym celu posłużymy się schematem dostępnym w polecanych przeze mnie podręcznikach Intela:

GDT

Znajdująca się w centralnym punkcie obrazka struktura danych zwana Global Descriptor Table (GDT) jest „sercem” architektury x86. Zawiera ona deskryptory segmentów (struktury opisujące segmenty), na które podzielona jest pamięć. Tak jak wspominałem, segmentacja jest zawsze obecna w architekturze x86. Oprócz „zwykłych” segmentów w pamięci, zawierających dane czy kod, w GDT znajdują się również deskryptory TSS oraz LDT. Warto jednak wspomnieć, że bitowo patrząc, wszystkie deskryptory mają taką samą strukturę. Z każdym deskryptorem skojarzony jest odpowiedni selektor, czyli przesunięcie w tablicy GDT wskazujące na dany deskryptor, lokalność/globalność, czyli to, czy mamy do czynienia z wpisem GDT czy LDT oraz prawa dostępu. Adres (liniowy) tablicy GDT, wraz z limitem (długością) znajduje się w rejestrze GDTR.

Odwołując się w jakikolwiek sposób do pamięci, musimy więc podać selektor segmentu oraz przesunięcie wewnątrzsegmentowe. Z selektora pobierany jest numer deskryptora, a z deskryptora następnie adres bazowy, do którego następnie dodawane jest przesunięcie dając adres liniowy – w taki sposób następuje odwołanie do elementu w pamięci.

LDT

Local Descriptor Table (LDT) jest siostrzaną tablicą do GDT. Aktualnie jest już prawie nieużywana. Jej użycie jest istotne w systemach ze starymi procesorami np. 80826, w których nie było jednostki stronicowania – a więc nie było możliwości realizowania separacji, tym samym ochrony pamięci poszczególnych procesów. Aktualnie LDT używane jest wyłącznie do uruchomiania 16 bitowych programów. Niegdyś, każdy proces użytkownika, posiadał własną tablicę LDT, której pozycja znajdowała się w rejestrze LDTR. LDT oferowała ochronę pamięci polegającą na możliwości dostępu tylko przez deskryptory znajdujące się w tejże tablicy. Kernel oraz współdzielona pamięć opisana była w GDT.

TSS

Task State Segment (TSS) to segment opisujący zadanie (ang. task). Używany jest głównie przy sprzętowej wielozadaniowości, w której z każdym procesem skojarzony jest pojedynczy TSS. W strukturze TSS znajdują się wszystkie informacje potrzebne do „odtworzenia” zadania – rejestry ogólnego przeznaczenia i te bardziej szczególne, takie jak EIP. W przypadku programowej obsługi wielozadaniowości potrzebna tylko jednego lub dwóch segmentów TSS. Selektor segmentu TSS jest trzymany w rejestrze TR – Task Register.

IDT

Interrupt Descriptor Table (IDT), to trzecia, po GDT i LDT tablica systemowa. Wpisy w tej tablicy nazywamy bramkami (ang. gates) i mogą być to bramki: przerwań (interrupt), zadań (task) oraz pułapek (trap).  Powstrzymam się z omawianiem konkretnych bramek – zrobię to przy okazji implementowania IDT. Na tę chwilę powiem, że wpisy w IDT służą wywołaniu odpowiedniej procedury obsługi konkretnego zdarzenia, np. przerwania, pułapki. Adres liniowy IDT znajduje się w rejestrze IDTR.

Stronicowanie

Na obrazku, stronicowanie (ang. paging) przedstawione jest na dole (dla pamięci „płaskiej”, rozmiaru strony 4KiB). Jest to bardzo istotny element architektury x86, o którym napiszę więcej w przyszłości. Na chwilę obecną przedstawię ogólną ideę działania jednostki stronicowania. Po przejściu przez wszystkie zawiłości związane z GDT „na wyjściu” otrzymujemy adres liniowy zbudowany, tak jak wspomniałem, z adresu bazowego znajdującego się w deskryptorze segmentu i przesunięcia wewnątrzsegmentowego. Gdy jednostka stronicowania jest wyłączona, adres ten jest bezpośrednim adresem w pamięci liniowej. W przeciwnym wypadku, adres interpretowany jest jako wirtualny. W adresie tym można wydzielić 3 części: dir, table oraz offset. Dir wskazuje wpis w katalogu stron, który z kolei wskazuje na odpowiednią tablicę. Następnie table wskazuje wpis w tablicy stron, który wskazuje konkretną stronę. Offset to przesunięcie w tej konkretnej stronie, które jest już elementem, który chcemy pobrać/zapisać. Jak widać, pojedynczy dostęp do pamięci, np. mov [eax], 42 nie oznacza fizycznie jednego dostępu do pamięci, ale sporo więcej. Stronicowanie ma więc istotny wpływ na wydajność systemu operacyjnego, dając nam jednak elegancką ochronę pamięci.

Rejestry systemowe

Oprócz wspomnianych wyżej, architektura x86 posiada 5 rejestrów kontrolnych (CR0, CR1, CR2, CR3, CR4, XCR0), rejestr flag EFLAGS, rejestry debuggowania oraz rejestry specyficzne dla konkretnej platformy. Myślę, że nie ma co opisywać ich zawiłych funkcji – zrobię to przy okazji używania ich.

Podsumowanie

Jak widać, architektura x86 jest dosyć bizantyjska. Posiada wiele funkcjonalności, których aktualnie się nie używa, które jednak znalazły swoje zastosowanie w przeszłości. Jest z tego powodu bardzo ciekawa z punktu widzenia tworzenia systemów operacyjnych – można tworzyć bardzo skomplikowane twory, całkowicie zgodne z wizją programisty, łącząc old school z tym co trendy ;).

O wspomnianych wyżej elementach architektury x86 będę jeszcze dokładniej pisał przy okazji ich używania. Na pierwszy ogień pójdzie GDT.

Ogólna koncepcja ochrony w x86

Pierścienie

Tryb chroniony, jak sama nazwa wskazuje, ma oferować ochronę. W związku z tym, do architektury x86 wprowadzono pewien podział – na poziomy uprzywilejowania. Poziomów tych jest 4 i zwyczajowo nazywa się je ring 0, ring 1, ring 2 i ring 3, gdzie ring 0 to poziom najbardziej uprzywilejowany, a ring 3, to poziom najmniej uprzywilejowany.

Architektura nie narzuca w żaden sposób, który poziom za co ma odpowiadać – wiadomo tylko, że z danego poziomu mamy dostęp do elementów z poziomów o wyższych numerach (i oczywiście do elementów z danego poziomu). Przykładowo role można podzielić tak:

  • Ring 0 – jądro systemu
  • Ring 1 – wywołania systemowe
  • Ring 2 – biblioteki współdzielone
  • Ring 3 – aplikacje użytkownika

W praktyce często używa się tylko dwóch poziomów – dla jądra i użytkownika.

Zakończenie

Z poziomami ochrony będziemy się stykać wielokrotnie podczas tworzenia systemu operacyjnego. Na razie wystarczy nam tyle informacji. Na różne sztuczki typu call gates przyjdzie jeszcze czas.

Segmentacja – nielubiana siostra stronicowania

Co to?

Segmentacja, to obok stronicowania, popularny sposób organizacji pamięci. W kwestii samej pamięci nic się nie zmieniło – nadal rozważamy liniową przestrzeń, której komórki posiadają adresy (dla przypomnienia – adres do konkretnej komórki pamięci nazywamy adresem fizycznym). Mechanizm segentacji dzieli liniową pamięć na segmenty – segmentem, mówiąc najprościej, jest pewien (najczęściej ciągły) obszar pamięci. W taki sposób do odwołania się do naszej „płaskiej”, jednowymiarowej pamięci potrzebujemy dwuwymiarowego adresu (adres logicznego – czyli pewnego, jednoznacznego odpowiednika adresu fizycznego) – jest to nazwa (najczęściej numer) segmentu, oraz pozycja wewnątrz tego segmentu. Przeanalizujmy poniższy rysunek:

Pamięć adresowana jest od 0x0000 do 0xFFFF. Zawiera ona 3 segmenty o numerach (nazwach) 0, 1 i 2. Jak widzimy w każdym segmencie adresowanie zaczyna się od 0x0000, a kończy się na pewnym adresie, nazywanym popularnie limitem, który jednocześnie wyznacza rozmiar segmentu. Teraz, aby odwołać się do elementu 1 o adresie 0x3000 należy podać adres segmentu czyli 1 oraz odpowiednie przesunięcie wewnątrz tego segmentu, czyli 0x3000 (takie samo jak adres fizyczny, gdyż segment zaczyna się na adresie 0x0000) – ostatecznie otrzymujemy adres (1, 0x3000) (notacja: (segment, przesunięcie wewnątrzsegmentowe)), dla elementu 2 o adresie fizycznym 0xA123 otrzymujemy w posegmentowanej pamięci adres (0, 0x2124), natomiast element 3 o adresie fizycznym 0xFFFF ma adres logiczny (2, 0x1FFF). Wszystko powinno być już teraz jasne. Trzeba przyznać, że dosyć to udziwnione – liniowa pamięć jest wygodna, po co więc używać dwuwymiarowego odpowiednika i w ogóle skąd się te segmenty biorą?

Zalety

Segmentację opracowano w celu umożliwienia podziału programu i danych na logicznie niezależne przestrzenie adresowe oraz aby wprowadzić łatwy mechanizm bezpieczeństwa i współdzielenia.

Segmentacja jest widoczna w modelu programowym – programista może swodobnie definiować nowe, własne segmenty – w ten sposób dostajemy logiczny, elegancki podział informacji. Przykładowe segmenty to: kod, dane, stałe, bss (statycznie alokowane dane), stos itd. To, co się w nich znajdzie zależy tak naprawdę od inwencji programisty.

Segmentacja wprowadza sprytne zabezpiecznie programów przed niebezpiecznymi błędami typu przepełnienie bufora, gdyż poszczególne segmenty mogą być oznaczone jako kod lub jako dane. Próba „wykonania” segmentu z danymi lub nadpisania załadowanego kodu zakończy się błędem. Ponadto segmenty mogą posiadać zabezpiecznia ze względu na poziom uprawnień – tj. czy to kod/dane systemu operacyjnego, sterowników, czy użytkownika.

Kolejną zaletą jest łatwość relokacji danych. Wyobraźmy sobie, że chcemy mieć tablicę o zmiennym rozmiarze – taką do której możemy „doalokować” pewną liczbę bajtów. W pewnym momencie, przy zmianie długości może się okazać, że bezpośrednio po naszej tablicy znajdują się inne, potrzebne dane. Musimy wtedy zaalokować naszą nową, większą tablicę w innym, odpowiednio dużym miejscu – a co się z tym wiąże – zmienić jej adres. Korzystając z segmentacji możemy umieścić taką dynamiczną tablicę w odpowiednim segmencie i w miarę potrzeb zwiększać jego limit. Gdy okaże się, że rozszerzający się segment zacznie zachodzić na inny, możemy go wtedy relokować w inne miejsce, ale tym razem adres się nie zmieni, gdyż segment nadal będzie miał ten sam numer, a elementy w jego wnętrzu to samo przesunięcie (choć oczywiście wiąże się to z kopiowaniem danych).

Ostatnią zaletą, o której warto wspomnieć to możliwość łatwego współdzielenia kodu oraz danych. Wystarczy w tym celu utworzyć odpowiednie, współdzielone segmenty i pozwolić na korzystanie z nich odpowiednim procesom. W taki sposób uruchomienie kilku instancji danego programu nie powoduje zapełnienia dostępnej pamięci wieloma identycznymi wersjami kodu.

Wady

Wady mechanizmu segmentacji są oczywiste. Segmentacja wymusza na programiście używania nieliniowej przestrzeni adresowej co może być kłopotliwe. Ponadto, tworzenie wielu segmentów, a nastepnie ich usuwanie może doprowadzić do powstawania „dziur” pomiędzy kolejnymi segmentami, które będą zbyt małe, aby pomieścić nowe segmenty. Takie zjawisko nazywamy szachownicowaniem lub (popularniej) zewnętrzną fragmentacją. Problem ten można rozwiązać za pomocą bardzo kosztownego kompaktowania – czyli upychania segmentów tak, aby następowały po sobie.

Realia

Architektura x86 posiada wsparcie dla segmentacji. Można powiedzieć nawet więcej – segmentacja działa zawsze i nie da się jej wyłączyć (w przeciwieństwie do stronicowania), czego większość informatyków jest nieświadoma. Sprytnym, programowym obejściem tego faktu jest utworzenie dwóch segmentów, rozciągających się na całą pamięć – kodu i danych. Będą one wtedy oczywiście na siebie zachodzić, ale niczemu to nie szkodzi. Tej techniki używają wszystkie nowoczesne systemy operacyjne w tym Linux, Windows oraz Mac OS X. Dlaczego segmentacja jest tak nielubiana? Cóż, widocznie wszyscy programiści kochają liniową przestrzeń adresową ;). Warto jednak zauważyć, że we wspomnianych systemach operacyjnych segmentacja realizowana jest niejako programowo – tj. istnieje możliwość tworzenia własnych segmentów (słówka kluczowe segment albo section w NASM) w assemblerze. Nie istnieje jednak szczególny powód aby to robić, dlatego z tej możliwości korzystają tylko kompilatory języków wyższego poziomu tak, aby ułożyć logicznie kod (w sekcje code, data, bss).

Jeśli interesują Was systemy korzystające z segmentacji, polecam poczytać o systemie MULTICS (z którego wywodzi się UNIX),  w którym mechanizmu tego użyto.

A20 – historia nieodpowiedzialności

A20?

W mojej serii postów zbliżam się coraz bardziej do momentu, w którym opuszczę tryb rzeczywisty i przejdę do trybu chronionego. Wspominałem, że w trybie rzeczywistym jesteśmy w stanie zaadresować do 1MiB pamięci RAM, a tryb chroniony daje nam dostęp do całej 4GiB przestrzeni. Jak się jednak okazuje, samo fizyczne przejście (o którym niebawem) nie wystarcza – trzeba wcześniej „odblokować” linię A20, czyli 21 linię adresową (A20 – od address line 20 – numeracja od 0 ;)) dostępu do pamięci. Przypomnijmy – 1 MiB = 2^20, a więc potrzebujemy 20 fizycznych linii, które wyznaczają adres. Odblokowanie 21 linii powoduje również aktywowanie pozostałych – ile ich jest, zależy tak naprawdę od konkretnego sprzętu. Dla sprzętu obsługującego 4GiB pamięci RAM będzie ich oczywiście 32.

Zgodność wsteczna…

Dociekliwi mogą zastanawiać się, dlaczego 21 linia adresowa jest domyślnie nieaktywna. Odpowiedź na to pytanie jest śmieszna i jednocześnie przykra – mówiąc najkrócej – zgodność wsteczna. W dawnych czasach procesora 8086 nie było potrzebnych więcej niż 20 linii – 1MiB było szczytem technologicznych marzeń. Powstało wtedy bardzo wiele programów współpracujących z tą architekturą, które tworzone były przez bardziej albo mniej rozgarniętych i odpowiedzialnych informatyków. Ci drudzy wykorzystywali fakt, iż przekroczenie granicy 1MiB (co było możliwe w związku z podziałem na segmenty – patrz tryb rzeczywisty) powodowało dostęp do początkowych bajtów pamięci. Mówiąc obrazowo – pamięć „zawijała się” – z końca do początku. Czujecie już jak bardzo bezmyślnym pomysłem było wykorzystanie tego „bugo-ficzera”? W końcu nastały piękne czasy IBM PC/AT wraz z Intelem 286, który umożliwiał zaadresowanie do 16 MiB pamięci. Rewolucja, prawda? Nie jest dziwnym, iż twórcy nowoczesnej technologii chcieli zachować 100% zgodności wstecznej z poprzednią architekturą, tak aby klienci wraz z wymianą sprzętu nie musieli wymieniać oprogramowania. Wszystko było pięknie do czasu, aż testrzy zaczęli zgłaszać bugi w pewnym oprogramowaniu – wykorzystujący zawijającą się pamięć! Prawa rynku są brutalne, więc zmartwieni, ważni ludzie pracujący nad 286 postanowili zaimplementować tego „buga” w swoim nowym procesorze blokując linię A20 i uzyskując pełną zgodność wsteczną :) Najwidoczniej poprawianie starych błędów mogło okazać się zbyt kosztowne i lepiej było je „obejść”. Z resztą, takie decyzje są w naszej branży bardzo powszechne. W taki sposób do dzisiejszego dnia, komputery architektury x86 mają (a raczej miewają) zablokowaną linię A20. Niestety, to nie koniec problemów.

Standardy, eee?

Okej, skoro już mamy tę linię zablokowaną, to warto by było ją aktywować, gdy już przekonamy się do nie-16bitowych aplikacji. Niestety w czasach 286 standardy nie były tak trendy jak teraz, więc nie opracowano ustandaryzowanego sposobu na dokonanie aktywacji. Koncepcji było wiele. Najpopularniejsą stała się koncepcja, aby do odblokowania A20 używać wolnego pina… w kontrolerze klawiatury! Czujecie zapach absurdu? Klawiatura, pamięć – gdzie tu związek? Wśród innych koncepcji warto wspomnieć o tzw. FAST A20 Gate pozwalającej na odblokowanie za pomocą portów, czy odpowiednich przerwaniach BIOS-u. Oczywiście różne sposoby działają lub nie na różnych płytach głównych różnych producentów, a jedyny sposób aby mieć jako taką pewność, iż udało się nam aktywować A20 to spróbować kilku sposobów. Jakby mało było złego, niektórzy producenci postanowili być na tyle dobroczynni, że dostarczają nam środowisko z już odblokowaną A20. Miło z ich strony, prawda? Dzięki temu, zanim przystąpimy do aktywowania A20, należy dodatkowo sprawdzić, czy ktoś nie zrobił tego za nas. Wspaniale!

Bolesna lekcja

Wnioski z powyższej historii są banalne. Nie bądźmy krótkowzroczni. Czasem nasze decyzje mogą mieć wpływ na rozwój spraw wiele lat później – w szczególności mogą go zahamować. Nie starajmy się również pomagać na siłę – czasem łatwo tym zaszkodzić. Przede wszystkim jednak, pamiętajmy o standardach – o tworzeniu ich i pielęgnowaniu.

W którymś z następnych postów zaimplementujemy sprawdzanie czy linia A20 jest aktywna oraz w razie potrzeby spróbujemy ją aktywować którymś z popularnych sposobów. Tymczasem zachęcam do poczytania na temat tu i tu.

Systemy operacyjne – książki

Wiedza, wiedza, wiedza…

Tworzenie systemów operacyjnych to niszowa dziedzina informatyki. Zajmują się nią nieliczni. Osobiście uważam jednak, że posiadanie wiadomości z zakresu systemów operacyjnych, to absolutny obowiązek każdego szanującego się informatyka. Nie myślę tu oczywiście o umiejętności obsługi Linuksa, czy też administracji Windowsem, tylko o zagadnieniach typu wieloprocesowość i wielowątkowość, synchronizacja procesów i wątków, szeregowanie, zarządzanie pamięcią, czy choćby znajomość zarysu historycznego początków informatyki. Wielu osobom może się wydawać, iż wiedza ta jest całkowicie zbędna „bo przecież ja programuję w .NET i nie robię żadnych wywołań systemowych i nie zarządzam pamięcią, tylko tworzę aplikacje webowe!”. Jasne, tak może być, tylko kompletna nieświadomość tego, co dzieje się „pod spodem”, może doprowadzić niejednokrotnie do katastrofy, a w innych sytuacjach wyjaśnienie takiego, a nie innego zachowania naszej aplikacji leży właśnie w systemie operacyjnym i jego „bebechach”. Jeśli to mimo wszystko nie przemawia, to po prostu powiem, że temat jest bardzo ciekawy i warto go zgłębić, choćby dla przyjemności :)

W dobie internetu, w którym wszystko można znaleźć, może się wydawać, że książki to przeżytek. Sam preferuję uczyć się nowych technologii z tutoriali i dokumentacji, gdyż zapewniają one absolutną aktualność zawartych informacji. Systemy operacyjne, jak już wspominałem wielokrotnie, to inna działka. Wiele wiadomości w tym zakresie to niezmienne od lat fundamenty, pozostałe natomiast zmieniają się bardzo powoli. Książki sprawdzają się tu bardzo dobrze, bo zapewniają całościowe i wyczerpujące podejście. Poza tym, kto nie lubi zapachu farby drukarskiej ponad świecący monitor?

Niekwestionowani liderzy

Rynek książek na temat systemów operacyjnych jest bardzo mały – tak jak mówiłem – nisza. Jak to się jednak mówi – nie ilość, ale jakość! Na polskim rynku niepodzielnie królują dwa tytuły i są to „Systemy operacyjne”, której autorem jest Andrew Stuart Tanenbaum, twórca kultowego systemu MINIX, od którego wiele się zaczeło oraz „Podstawy systemów operacyjnych” autorstwa Abrahama Silberschatza, Petera Baera Galvina oraz Grega Gagne’a. Najnowsze wydanie (trzecie) pierwszej z nich ukazało się w tym roku za sprawą wydawnictwa helion i pokrywa się z najnowszą, angielską wersją, natomiast druga z wymienionych książek wydawana jest przez WNT – najnowsze wydanie z 2005 roku, to wydanie szóste, podczas gdy na świecie mamy już wydanie ósme. Dodatkowo niepokojącym jest fakt, że już od długiego czasu na stronie wydawnictwa widnieje napis „Książka czasowo niedostępna”. Może to oznaczać, że nowe wydanie jest w drodze, albo niestety – jakieś problemy. Dość już jednak suchych faktów, przejdźmy do tego, co książki te oferują i która z nich jest lepsza.

Obie książki oferują całościowe ujęcie tematu. Znajdziemy w nich dużo wyczerpujących informacji na tematy takie jak historia systemów operacyjnych; podstawowe pojęcia; procesy i wątki – IPC, szeregowanie, synchronizacja; zarządzanie pamięcią – stronicowanie i segmentacja, algorytmy alokacji pamięci; system plików; wejście-wyjście; bezpieczeństwo. Dodatkowo „Podstawy systemów operacyjnych” zawierają obszerny rozdział poświęcony rozproszonym systemom operacyjnym, natomiast w ramach rekompensaty „Systemy operacyjne” posiadają duży rozdział o implementacji systemu operacyjnego. Na uwagę zasługują też rozdziały opisujące konkretne systemy operacyjne – co i jak zostało w nich zrealizowane. Oczywiście w książce Tanenbauma informacje dotyczą nowszych wydań konkretnych systemów.

Język obu książek nie jest szczególnie lekki, ale nie powiedziałbym, że czyta się je ciężko – tematyka wymaga (niestety, bądź stety) używania języka formalnego, jednak wszystko daje się zrozumieć. Ciężko też znaleźć fragmenty, w których autorzy „laliby wodę”. Moim zdaniem, udało się im zachować równowagę pomiędzy niejasną zwięzłością, a przesadną obszernością.

Żadna z książek nie wyczerpuje tematu, bo jest to raczej niemożliwe. Obie natomiast prezentują bardzo obszerny kawałek tematu na swoich ponad 1000 stronach. Która z nich jest zatem trafniejszym zakupem? Na dzień dzisiejszy odpowiedź jest prosta – jest to książka „Systemy operacyjne”, ze względu na łatwą dostępność (księgarnia helion 99 zł (!) na dzień dzisiejszy) i większą aktualność (mimo wszystko). „Podstawy systemów operacyjnych” daje się czasem trafić w antykwariatach, na kiermaszach, bądź na allegro, jednak jej cena sięga nierzadko… 300 zł ze względu na swoistą unikalność. Cena zabójcza. Aha, muszę jeszcze wspomnieć, iż obie książki posiadają niebanalne okładki :) Powiedziałbym nawet, że okładka „Systemów operacyjnych” to najciekawiej zaprojektowana okładka, jaką w życiu widziałem. Polecam zobaczyć ;>

Na zakończenie

Naprawdę gorąco zachęcam do przeczytania jednego z tych tytułów – i nieważne czy jesteś programistą, administratorem, architektem, serwisantem, czy reinstalatorem Windowsów – zawsze znajdziesz tam wiele ciekawych informacji, które – nóż, widelec – mogą się kiedyś przydać. A nawet jeśli nie – wiedza jest zawsze sexy i w modzie :)

EDIT 11.10.2010:

Na rynku brak książek rodzimych autorów o tematyce tworzenia czy budowy systemów operacyjnych, jednak właśnie dostałem informację, o pozycji, która niebawem się ukaże – Programowanie systemowe mikroprocesorów rodziny x86 autorstwa Włodzimierza Stanisławskiego i Damiana Raczyńskiego. Myślę, że warto spróbować!

Dostęp do sprzętu peryferyjnego – podstawy

Zarys

W życiu każdego projektanta systemów operacyjnych nadchodzi moment, w którym chciałby się on skontaktować z urządzeniami zewnętrznymi, gdyż samotny procesor przestaje spełniać jego wygórowane oczekiwania :) Jak to bywa prawie ze wszystkim, istnieje kilka sposobów dostępu do sprzętu peryferyjnego, co wynika oczywiście z naturalnej ewolucji hardware’u – w tym poście zajmę się jednak tylko dwoma, najprostszymi metodami – port I/O oraz memory-mapped I/O, co dałoby się przetłumaczyć jako odpowiednio – wejście/wyjście za pomocą portów oraz wejście wyjście odwzorowane w pamięci. Wśród bardziej zaawansowanych metod, na które jeszcze przyjdzie czas, warto wspomnieć o DMA oraz dostępie przez przerwania.

Memory-mapped I/O

Memory-mapped I/O to bardzo prosty sposób na dostęp do urządzeń zewnętrznych polegających na tym, iż w dostępnej pamięci operacyjnej – a dokładniej w dostępnej przestrzeni adresowej – posiadamy zarezerwowany zakres adresów pozwalających na odwoływanie się do urządzeń. Rezerwacja może być zarówno stała, jak i tymczasowa. Technicznie, w uproszczeniu rzecz ujmując, realizacja wygląda tak, iż każde z urządzeń monitoruje szynę adresową procesora i reaguje na każdy jego dostęp do odpowiedniego zakresu. Zaletami takiego podejścia są oczywiście – prostota i jasność w korzystaniu (łatwo programuje się to w C), gdyż dostęp do pamięci jest prosty; procesor oparty o memory-mapped I/O jest tańszy, mniejszy, prostszy i mniej energochłonny; dostęp do pamięci jest szybki, a więc dostęp do urządzeń poprzez szynę adresową też – również dzięki możliwości wykorzystania różnych trybów adresowania. Wady? Takie podejście „przerywa” ciągłość pamięci w konwencjonalnym ujęciu, a więc zmniejsza też ilość dostępnej pamięci. Dla formalności, przykładowy kod:

unsigned char *videoram = (unsigned char *) 0xB8000;
videoram[0] = 65; /* character 'A' */
videoram[1] = 0x07; /* forground, background color */

W ten sposób wypiszemy literkę ‚A’ na ekranie, odwołując się do karty graficznej. Wygląda prosto, prawda? I o to właśnie chodzi :) Pozostaje jeszcze pytanie, na które nie ma odpowiedzi – skąd wiedzieć która cześć pamięci za co odpowiada? Rozwiązania należy szukać w mapie pamięci, która dla każdej architektury może być inna. Warto też pamiętać, że istnieje możliwość dynamicznego przydzielania adresów dla urządzeń.

Port I/O

Port I/O to kolejna, starsza i generalnie gorsza metoda dostępu do urządzeń, która ciągle jest obecna w architekturze x86 z powodu.. tak tak, zgodności wstecznej. Sposób ten polega na istnieniu dodatkowej, obok RAM-u, przestrzeni adresowej, w której każde urządzenie ma swój adres. Dostęp do portów odbywa się za pomocą specjalnych instrukcji, charakterystycznych dla architektury, które nie mają swojego odpowiednika w języku C. W assemblerze x86 są to: IN, INS/INSB/INSW/INSD, OUT, OUTS/OUTSB/OUTSW/OUTSD pozwalające wczytać/pisać odpowiednią porcję danych z/do wskazanego portu. Technicznie, transfer danych odbywa się za pomocą specjalnego I/O pina w CPU lub za pomocą przeznaczonej do tego szyny adresowej, która nieco przyspiesza ten proces. Zaletami tego rozwiązania jest oszczędność przestrzeni adresowej,  a więc i samej pamięci oraz fakt, iż dostęp przez odpowiednie instrukcje, w jasny sposób wskazuje czytającemu kod programiście, kiedy odbywa się komunikacja ze sprzętem. Wadą, jak już wspomniałem, jest powolność oraz brak wsparcia dla operacji 64 bitowych. Przykładowy kod:

a20wait:
        in      al, 0x64
        test    al, 2
        jnz     a20wait
        ret

Kod ten, jak widać, wczytuje do rejestru al (ax) bajt z urządzenia o adresie 0x64, o którym będzie jeszcze mowa ;) Warto zwrócić uwagę, że używany jest tu rejestr (e)ax, gdyż… jest to jedyny rejestr dostępny do użycia z portami w architekturze x86 – niestety. Podobnie – adres może być stałą natychmiastową lub wartością wyłącznie z rejstru DX. Pozostaje nam jeszcze odpowiedź na pytanie zadane dla dostępu przez memory-mapped I/O – czyli skąd wiedzieć, który port połączony jest z którym urządzeniem. Odpowiedź i tym razem jest niełatwa. Niektóre urządzenia takie jak timery, kontrolery przerwań, porty PS/2, serial, parallel, dyskietka, dysk twardy, karta graficzna mają przypisane konkretne adresy z powodów kompatybilności. Pozostałe urządzenia typu plug-and-play mają adresy przypisane przez BIOS i aby je otrzymać, należy poprosić o to szynę PCI :) Inne urządzenia (np. karty ISA) posiadają zworki, którymi da się ustawić konkretny port. Pamiętacie ustawianie portów Soundblastera w grach za czasów DOS-a? Tak – to właśnie dlatego :)

Podsumowanie

Nowoczesne architektury – 32 i 64 bitowe odchodzą od modelu z portami na rzecz zunifikowanej przestrzeni adresowej – ze względu na wysoką wydajność i elegancję takiego rozwiązania. W obecnych czasach, mała ilość pamięci nie jest już przeszkodą. Są jednak chwile, w których dostęp za pomocą portów jest słuszną (lub jedyną ;>) metodą dostępu do urządzeń – należy więc o niej pamiętać. Konkretne przykłady użycia – już wkrótce.

Po co branchuję?

Ludzie branche tworzą…

Motywów do tworzenia gałęzi w projektach jest co nie miara. W nie tak prehistorycznych czasach (które chyba z resztą trwają do dziś) królowania CVS, a później SVN większość rzeczy trafiała bezpośrednio do trunka – głównej gałęzi. Rozgałęzienia były tworzone w momentach, gdy projekt rzeczywiście obierał dwa, dosyć odmienne biegi rozwoju (np. v1 i v2 – obie rozwijane). Inną strategią (nie wykluczającą pierwszej!) było tworzenie gałęzi – stabilnej, rozwojowej, a czasem eksperymentalnej i odpowiednie „code promotion”, czyli „przenoszenie” kodu między gałęziami: stabilna <- rozwojowa <- eksperymentalna. Jeszcze inny sposób wykorzystywania gałęzi, to oddzielny branch dla każdego podzespołu. Tak stworzone gałęzie były stopniowo (zwykle po zakończeniu pracy nad modułem) włączane do wspomnianego trunka. Powodem stosunkowo niedużej liczby rozgałęzień była największa bolączka wspomnianych scentralizowanych systemów kontroli wersji – nieprzyjemny merge.

W nowoczesnych-trendy-lux-czasach rozproszonych systemów kontroli wersji takich jak git, hg, bzr promuje się podejście „branch-per-feature” – czyli tworzenie nowej gałęzi dla każdego, nowego „ficzera”, każdego naprawianego buga itd. Nic co jest „work-in-progress” nie powinno trafić do gałęzi głównej. Wszystko to jest możliwe dzięki mniej bolesnemu merge’owaniu gałęzi, a takie podejście jest samo w sobie niezwykle wygodne i efektywne.

Nieco kreatywności

Przy okazji serii postów którą tworzę, potrzebowałem prostego i efektywnego sposobu udostępniania kodów dla poszczególnych odcinków serii. W grę wchodziło uploadowanie paczek z aktualnym kodem, dla danego odcinka, na serwer i linkowanie ich w notce. Szczerze powiedziawszy – nie znoszę takiego podejścia. Wydaje mi się, że łatwo doprowadza to do bałaganu, nieaktualnych wersji i niedziałających linków. Potrzebowałem lepszego sposobu i do głowy przyszedł mi pomysł.. aby każdy odcinek serii był oddzielnym branchem. Takie rozwiązanie ma szereg zalet: Czytelnicy mogą z łatwością pobrać aktualny, dla danego odcinka, kod; mogę bezproblemowo wnosić zmiany do kodu dla konkretnej części; struktura tego podejścia jest bardzo przejrzysta, a ponadto wyjątkowo łatwo się tym wszystkim zarządza. Z dodatkowych zalet warto wspomnieć o przeglądarce kodu na githubie, która umożliwia Czytelnikom natychmiastowy podgląd kodu dla danej części, bez potrzeby ściągania go. Jak dla mnie – rewelacja :) Przedstawione przeze mnie podejście ma oczywiście sens tylko w serii postów ze stopniowo przyrastającym kodem. Puryści mogliby jednak powiedzieć, że takie rzeczy powinno załatwiać się labelami, ale jak już wspomniałem – mam zamiar w miarę potrzeb aktualizować kod dla konkretnych odcinków, a zarządzanie etykietami, to nic przyjemnego.

Nowa, lepsza przyszłość? ;)

Cieszy mnie, że era linkowania paczek z kodem dobiega końca, a repozytoria wchodzą w coraz to nowe obszary działalności – ludzie za pomocą systemów kontroli wersji rozpowszechniają najróżniejsze rzeczy – począwszy od configów, aż do dokumentów. Niewątpliwa w tym zasługa ogólnodostępnych, darmowych, świetnie przygotowanych serwisów takich jak github, gitorious, czy bitbucket. Wydaje mi się, że używanie systemów kontroli wersji jest po prostu efektywne, łatwe, szybkie i pewne, zatem ich (nadchodząca) wszechobecność jest rzeczą naturalną. Koniec broken linków! :)

Tworzenie systemu operacyjnego – część 0×02: Dobrodziejstwa BIOS-u

512 bajtów (tak samo jak 640K) nie wystarczy każdemu

W poprzednim odcinku załadowaliśmy 512 bajtów zawartości dysku do pamięci. W taki sposób uruchomiliśmy nasz bootloader, który niestety nic nie robił. Teraz wypadałoby, aby zmienił on tryb operacyjny, wyświetlił kilka diagnostycznych komunikatów no i załadował jądro za pomocą sterownika ATA… tylko to wszystko nie zmieści się w 512 bajtach! Jeśli postawimy na minimum, tj. załadowanie jądra z dysku – również może być ciężko, sterownik jednak swoje waży. Z pomocą przychodzi nam jednak BIOS!

Funkcje BIOS-a – przerwania

BIOS udostępnia nam bardzo wiele funkcji poprzez przerwania. Wśród oferowanego asortymentu są np.: pisanie na ekran, wczytywanie z dysku, sprawdzanie stanu sprzętu, uzyskiwanie mapy pamięci, aktywowanie dodatkowej pamięci i wiele, wiele innych. My zajmiemy się dla przykładu tylko dwoma. Pełna ich lista znajduje się tutaj i tutaj. Widzicie funkcje opisane jako „???”? Uważajcie na nie! Skoro nikt, nawet twórcy BIOS-ów nie wiedzą do czego służą, to możecie nimi przez przypadek przejąć władzę nad światem lub wyłączyć prąd u sąsiada w domu.. :)

Dla niezaznajomionych z programowaniem systemowym: przerwanie wywołuje się poleceniem int numer_przerwania, natomiast argumenty przekazuje się za pomocą odpowiednich rejestrów.

int 0x10

Na początek postaramy się wypisać coś na ekran. W tym celu skorzystamy z przerwania 0x10, którego dokładny opis jest tutaj. Oto kod:

	mov	ax, 0x0000
	mov	ds, ax		; round way to do that...
	mov	si, msg

	mov	ah, 0x0E	; mode - teletype (advance and scroll)
	mov	bh, 0x00	; page number
	mov	bl, 0x07	; colors

.next_char:
	lodsb
	or	al, al		; letter here
	jz	.continue
	int	0x10		; BIOS video interrupt
	jmp	.next_char

msg:
	db	'Hello from bootloader!', 13, 10, 0

Idąc od początku, warto zwrócić uwagę na linie 5 i 6 i na dziwną, okrężną drogę ładowania rejestru DS (data segment). Niestety – takie są ograniczenia architektury – nie można bezpośrednio ładować rejestrów segmentowych. Do rejestru SI ładujemy adres pamięci pierwszej litery (czyli mówiąc najprościej – napisu) i tak uzyskana para (DS:SI) wskazuje nam jednoznacznie, gdzie jest napis. Pora na kolejne ustawienia. W rejestrze AH, zgodnie z opisem musi znaleźć się wartość 0xE, która definiuje tryb wyświetlania liter – jest to przewijanie i przeskakiwanie na następną pozycję (w dokumentacji nazwany teletype). W rejestrze BH przechowujemy numer strony – u nas jest to strona zerowa. Rejestr BL zawiera natomiast kolory (tła i liter) – białe litery na czarnym tle.

Możemy teraz przejść do pętli wypisującej literę po literze. Instrukcja lodsb ładuje literę wskazywaną przez DS:SI do rejestru AL, a następnie przesuwa wskaźnik do następnej litery. Polecenie o tyle przydatne,  gdyż oszczędzamy w ten sposób cenne miejsce w naszych 512 bajtach. Kolejnym krokiem jest sprawdzenie, czy przypadkiem nie dotarliśmy do końca napisu i jeśli tak, to opuszczenie pętli (linie 15 i 16), następnie wywołanie samego przerwania (linia 17) oraz skok zamykający pętle. Bajecznie proste prawda? Po wykonaniu tego kawałka kodu powinniśmy ujrzeć na ekranie napis „Hello from bootloader!”. Czas na trochę bardziej przydatne i skomplikowane przerwanie.

int 0x13

Szczęśliwa „trzynastka” ;) pozwala nam na wczytywanie danych z dysku za pomocą adresowania typu LBA (jeśli nie wiesz co to, przeczytaj koniecznie podlinkowaną stronę Wikipedii). Rzut oka na kod:

	mov	si, read_pocket
	mov	ah, 0x42	; extension
	mov	dl, 0x80	; drive number (0x80 should be drive #0)
	int	0x13

read_pocket:
	db	0x10		; size of pocket
	db	0		; const 0
	dw	1		; number of sectors to transfer
	dw	0x7E00, 0x0000	; address to write
	dd	1		; LBA
	dd	0		; upper LBA

Tym razem w rejestrze SI znajduje się adres „kieszeni” (o której szerzej – zaraz) zawierającej informacje o tym co i gdzie wczytać. Rejestr AH zawiera numer identyfikujący tę właśnie funkcję (wśród dostępnych funkcji znajdują się również takie, które pozwalają na dostęp CHS). Natomiast rejestr DL zawiera numer dysku z którego chcemy czytać… zupełnie spodziewanie, dysk numer 0 znajduje się pod numerem 0x80 ;> Przerwanie wywołujemy w linii 24 i o ile wszystko poszło gładko, powinniśmy mieć dane załadowane pod wskazany adres. Co do samej kieszeni, to komentarze chyba mówią wszystko. Pierwszy bajt zawiera rozmiar kieszeni, drugim powinno być zawsze 0, kolejne dwa to liczba sektorów do wczytania, następne dwa słowa to człony adresu (u nas to 0x0000:0x7E00), potem następuje adres sektora startowego na dysku (zaczynamy od sektora numer 1, czyli efektywnie od drugiego) i jego „górna” część. Prosto, łatwo i przyjemnie! :) W prawdziwym, profesjonalnym systemie powinniśmy jakoś obsłużyć błędy wczytywania, których kody zwracane są w odpowiednich rejestrach (opis tu).

Wszystko do kupy

Finalnie nasz kod wygląda tak:

[ORG 0x7C00]			; here is where our code will be loaded by BIOS
[BITS 16]

bootloader:
	mov	ax, 0x0000
	mov	ds, ax		; round way to do that...
	mov	si, msg

	mov	ah, 0x0E	; mode -> teletype (advance and scroll)
	mov	bh, 0x00	; page number
	mov	bl, 0x07	; colors

.next_char:
	lodsb
	or	al, al		; letter here
	jz	.continue
	int	0x10		; BIOS video interrupt
	jmp	.next_char

.continue:
	mov	si, read_pocket
	mov	ah, 0x42	; extension
	mov	dl, 0x80	; drive number (0x80 should be drive #0)
	int	0x13
	cli			; turn off maskable interrupts, we don't need them now
	hlt
.halt:	jmp	.halt

msg:
	db	'Hello from bootloader!', 13, 10, 0
read_pocket:
	db	0x10		; size of pocket
	db	0		; const 0
	dw	1		; number of sectors to transfer
	dw	0x7E00, 0x0000	; address to write
	dd	1		; LBA
	dd	0		; upper LBA 

times 510-($-$$) db 0		; fill rest with zeros
dw 0xAA55			; bootloader indicator, used by BIOS

Do celów testowych musimy stworzyć dalszą część naszego wirtualnego dysku, jako że ma on tylko 512 bajtów i wczytanie kolejnego sektora zaowocuje błędem. Proponuję zrobić to tak:

echo 'Ala ma kota' > ./bin/text
dd if=/dev/zero of=./bin/zeros bs=1  count=500
cat ./bin/boot.bin ./bin/text ./bin/zeros > ./bin/hda.img

Kolejno: tworzę plik z zawartością „Ala ma kota” (plus nowa linia!), tworzę plik 500 bajtowy z samymi zerami, a następnie wszystko łącze w kolejności: kod + tekst + zera, co nam daje 1024 bajty.

Po uruchomieniu naszego bootloadera w QEMU zobaczymy na ekranie „Hello from bootloader!”, natomiast w pamięci pod adresem 0x7E00 powinien być napis „Ala ma kota”. Dla pewności, w trybie monitora sprawdźmy to komendą xp /12bc 0x7E00. Wspaniale!

Single stage

Nasz bootloader aktualnie posiada tylko jeden etap (ang. stage) działania. Bardziej złożone bootloadery, jak np. GNU GRUB posiadają kilka etapów działania (najczęściej 2) ze względu na wspomniane ograniczenie 512 bajtów. W kolejnej części cyklu spróbujemy napisać stage 2 dla naszego bootloadera, który odpowiednio skonfiguruje środowisko pracy dla naszego jądra. Tymczasem zachęcam do zapoznania się z pełnymi źródłami części 0x02:

git clone git://github.com/luksow/OS.git --branch 0x02

Jeśli chcesz go tylko przejrzeć, wejdź tutaj.

Edytor tekstu zamiast wypasionego IDE?

Filozoficzne pytanie

Mam silny background .NET-owy, zdarzyło mi się dłużej programować w Javie. Właściwie od kiedy zacząłem programować bardziej „na serio”, towarzyszyło mi Visual Studio, Eclipse, czy NetBeans. Od zawszę więc myślałem, że dobre środowisko pracy, to podstawa. Bynajmniej, nie twierdzę teraz inaczej – ale czy dobre środowisko oznacza ciężkie, w pełni wyposażone, dopasowane do danego języka IDE? A może „zwykły” edytor tekstu wystarczy?

Rys historyczny

Pierwszą styczność z edytorem tekstu, konkretniej z vim-em zawdzięczam mojemu Wspaniełemu Koledze. Wtedy, szczerze powiedziawszy, nie spodziewałem się, że ktokolwiek tego używa – nie działa backspace, trzeba wcisnąć „i”, żeby pisać i nie da się z niego wyjść? Żartów z niego było co niemiara ;> ale Michał poruszał się w nim całkiem sprawnie. Niedługo i ja musiałem się nieco do niego przekonać, gdyż jest on podstawowym (jedynym) wyposażeniem w części pracowni na mojej zacnej uczelni. Hmm.. przekonać to za dużo powiedziane – wypadałoby to raczej nazwać – powstrzymywaniem nienawiści :)

Sytuacja uległa nieco zmianie, gdy przeczytałem (bardzo dobry moim zdaniem) artykuł Roba Conery’ego właśnie o edytorach tekstu, głównie o vim-ie. Pomyślałem wtedy, że coś w tym musi być! Poszperałem więc w internecie, obejrzałem screencast podlinkowany przez Roba.. i dałem vim-owi drugą szansę. Realizowałem akurat całkiem duży (jak na realia szkolne) uczelniany projekt, więc szansa była. Tym razem miałem w sobie więcej entuzjazmu i po niełatwej przeprawie udało się – dostrzegłem urodę edytorów tekstu!

Bolesna przesiadka

Nie ma co ukrywać, że zmiana IDE na edytor jest bolesna, bardzo bolesna. Zaryzykowałbym stwierdzenie, że większość osób, która nawet próbuje, odpada bardzo szybko. Tak było i w moim przypadku, ale za którymś podejściem się przełamałem. Edytory takie jak vim lub Emacs wprost „z pudełka”, z przydatnych rzeczy, oferują podświetlanie składni dla kilku języków.. i to by było na tyle. Dodajmy do tego, że nawet podstawowa obsługa i nawigacją są skomplikowane i katastrofa gotowa ;)

Obrazek ten jest humorystyczną ilustracją tego o czym mówię :) Co zatem przyciąga licznych wyznawców tekstowych edytorów?

Nieskończone dobro

Oba wspomniane edytory posiadają nieograniczone możliwości konfiguracyjne – skonfigurować można dosłownie wszystko za sprawą specjalnych, charakterystycznych dla danego edytora języków. Jasnym chyba jest, że dzięki temu zaprogramować można w nich wszystko, nawet przejmowanie kontroli nad światem :>

Użytkownicy nie muszą jednak programować wszystkiego sami – istnieją setki, tysiące (miliony?) pluginów zarówno do Emacsa jak i vima. Pomyśl nad najbardziej absurdalną rzeczą, jaka przychodzi Ci do głowy i jaką może mieć edytor (i nie, przeglądarka WWW, gry, organizator czasu to nie są absurdalne rzeczy) – tak Emacs ma ją już napisaną :)

Właśnie za sprawą owych dodatków (własnych, ściągniętych, czy też dostosowanych) dostajemy do edytorów wsparcie do rozmaitych języków programowania (podświetlanie składni, snippety, uzupełnianie, połączenie z debuggerami, integracja z narzędziami do testowania itd. itp.). W ten sposób ujawnia się jedna z największych zalet edytorów – uczymy się narzędzia RAZ i używamy go do wszystkich języków programowania, robiąc tylko odpowiednie dostosowania. W ten sposób zwraca nam się zainwestowany na początku czas – z nawiązką.

Last but not least pamiętajmy, że edytory nastawione są na.. edycję. W związku z tym mają niezwykle bogate możliwości edycji tekstu (a tym przecież jest kod!) i to w sposób łatwy i szybki. Pomyślcie teraz – czy więcej czasu podczas kodzenia spędzacie na pisaniu, czy edycji tego co już powstało? No właśnie :)

Co edytor zrobił dla mnie?

O tym postaram się napisać w przyszłości, prezentując przy okazji używane przeze mnie dodatki. Niestety, nie będą to tutoriale step-by-step, gdyż sam jeszcze jestem lamką :)

Poniżej jeszcze kilka linków do poczytania:

Wpis na blogu Roba Conery’ego podlinkowany wyżej

O programowaniu C# w Emacsie

Bardzo dobry wpis o edycji tesktu w vimie, przedstawiający „filozofię” tego edytora

Tworzenie systemu operacyjnego – część 0×01: Włączam komputer i…, bootloader

Power on!

W życiu każdego młodego informatyka nastaje moment, gdy zaczyna się zastanawiać, co tak właściwie się dzieje, gdy włącza komputer. Na ten temat można by mówić długo i na różnym poziomie szczegółowości. Ja nie będę zajmował się jednak skaczącymi elektronami i zmieniającymi się poziomami energetycznymi w krzemie, a tym co interesuje programistę systemów operacyjnych – poziomem oprogramowania.

Włączenie komputera rozpoczyna się od naciśnięcia przycisku (genialne spostrzeżenie, prawda?), który włącza zasilanie komputera, a konkretniej – zasila płytę główną. Ta z kolei, w pierwszej chwili uruchamia swój własny firmware. Ciężko określić jak dokładnie proces ten przebiega, gdyż dla każdej płyty głównej może być to trochę inne. Tak naprawdę chodzi o to, że płyta główna potrzebuje programu, który uruchomi procesor. Jeśli w tym momencie coś pójdzie nie tak, będziemy oglądać ciemny ekran, słyszeć kręcące się wiatraczki i piski z głośniczka na płycie głównej. Załóżmy jednak, że udało się uruchomić procesor. Co ciekawsi zastanawiają się pewnie – „a co jeśli komputer posiada dwa lub więcej procesorów?”. Otóż w systemach wieloprocesorowych jeden z procesorów jest tzw. bootstrap processor (BSP), który odpowiedzialny jest za uruchomienie BIOS-u oraz zainicjowanie jądra. Drugi z procesorów pozostaje w stanie zatrzymania (halt), aż do momentu kiedy explicite zostanie obudzony przez jądro systemu operacyjnego. Wracając jednak do naszej sekwencji – nasz świeżo uruchomiony procesor znajduje się w dobrze zdefiniowanym stanie – tj. znane są zawartości części jego rejestrów, w szczególności rejestru wskaźnika instrukcji CS:IP. Rejestr ten przechowuje magiczny adres nazwany reset vector. W tym momencie płyta główna musi się upewnić, że instrukcja znajdująca się pod tym adresem, to skok do miejsca w pamięci, w którym znajduje się zmapowany BIOS – jest to obszar adresów nieco poniżej magicznej granicy 1MB (np. 0x9FC00 – 0xFFFFF). Warto zwrócić uwagę na słowo zmapowany – tzn. dokładnie w tym miejscu w pamięci RAM znajdują się śmiecie, a płyta główna tworzy iluzję, jakoby znajdował się tam BIOS (wie jak to zrobić dzięki przechowywanej przez nią mapy pamięci). Od momentu gdy zacznie wykonywać się BIOS, ciężko powiedzieć co dzieje się dalej, gdyż to zależy od konkretnego BIOS-u – a więc od producenta płyty głównej. Standardowo jest to wykonanie „Power-on self-test”, czyli tzw. POST-u, który testuje – integralność samego BIOS-u, niektóre podzespoły, pamięć itp. Kolejnym krokiem po POST jest przejście do sekwencji bootowania. Pierwszym krokiem bootowania jest przejrzenie (predefiniowanej przez użytkownika w ustawieniach BIOS-u) listy urządzeń do wystartowania i odszukaniu urządzenia (np. dysku), którego pierwszy (a w zasadzie zerowy) sektor, czyli 512 bajtów, kończy się bajtami 0x55 oraz 0xAA. Bajty te oznaczają, iż urządzenie jest bootowalne – zawiera bootloader. Następnie, wspomniane 512 bajtów jest kopiowane pod adres 0x7C00, a procesor zaczyna wykonywać instrukcje spod tegoż adresu. Warto wspomnieć, że istnieje pewien standard, jak owe 512 bajtów powinno wyglądać – tzn. powinien być tam MBR. Nie jest to jednak istotne, gdyż w tym momencie pełną władzę przejmujemy my – programiści! :)

Przed dalszą lekturą upewnij się, że zapoznałeś się informacjami zawartymi w:

QEMU – podstawy

Tryby operacyjne – tryb rzeczywisty

Bootloader

Pierwsza wersja naszego bootloadera będzie robiła.. nic :) a dokładniej nasz bootloader „zatrzyma” procesor. W kolejnej części nieco go rozbudujemy. W tym miejscu trzeba zaznaczyć, że komputer pracuje w trybie rzeczywistym. Spójrzmy na kod naszego bootloadera:

[ORG 0x7C00]			; here is where our code will be loaded by BIOS
[BITS 16]

bootloader:
	cli			; turn off maskable interrupts, we don't need them now
	hlt			; halt CPU
	jmp	bootloader	; this should not happen, but.. ;)

times 510-($-$$) db 0		; fill rest with zeros
dw 0xAA55			; bootloader indicator, used by BIOS

Teraz będą objaśnienia. Pierwsza linia to wskazówka dla naszego kompilatora, żeby przyjął odpowiednie przesunięcie w adresach. Gdyby tej linii nie było (co możecie sprawdzić) kompilator „myślałby”,  że kod wskazywany przez etykietę bootloader znajduje się pod adresem 0x0000, a co za tym idzie skok z linii 7 by się nie powiódł.

Druga linia, to kolejna wskazówka, mówiąca tym razem, że chcemy kod wynikowy 16 bitowy – pamiętacie o trybie rzeczywistym?

Linie 5, 6 i 7 należy rozpatrywać razem. Instrukcja cli wyłącza maskowalne przerwania. O tym co to dokładniej znaczy będzie innym razem, ważne żeby zapamiętać iż przerwania wybudzają procesor, ze stanu halt, aktywowanego poleceniem hlt. W stanie halt procesor zatrzymuje się i nie wykonuje następującej instrukcji, aż do wznowienia. Tak więc brak instrukcji cli spowodowałby chwilowe wstrzymanie procesora, a następnie (gdyż przerwań w tle dzieje się dużo!) wykonanie instrukcji z linii 7, która jest swoistą „ostatnią deską ratunku” :) Polecam poeksperymentować usuwając linie 5 i 7 i zobaczyć dokąd zabrnie nasz IP i czy nie skończy się to restartem.

Linia 9 to makro NASM-a mówiące, aby wypełnić następujące bajty, aż do 510, zerami.

Linia 10 to wspomniany indykator świadczący o tym, iż jest to kod bootloadera.

W ten sposób otrzymujemy 512 bajtów bootloadera.

Nasz kod kompilujemy poleceniem:

nasm boot.asm -f bin -o ./bin/boot.bin

Przełącznik -f bin mówi, iż chcemy, aby wynikowy kod był tzw. płaską binarką (ang. flat binary), czyli ma nie zawierać żadnych nagłówków, ani informacji pomocniczych, a całość kodu źródłowego jest bezpośrednio zamieniana na kod. Możemy to sprawdzić używając narzędzia hexdump – zobaczymy, iż pierwszym bajtem wynikowego pliku boot.bin jest 0xFA, które jest kodem operacji cli :)

Pozostaje nam teraz uruchomienie naszego bootloadera za pomocą polecenia:

qemu -hda ./bin/boot.bin

I voila! Nasz bootloader działa i nic nie robi :) Będąc w QEMU polecam pobawić się trybem monitora, w szczególności wyświetlić fragmenty pamięci.

Końcowe słowa

To tyle w dzisiejszym odcinku. W następnym postaramy się rozbudować nasz bootloader w sposób, który pozwoli załadować nam nasz przyszły kernel. W repozytorium znajduje się pełen kod wraz z plikiem Makefile (niezbyt pięknym, swoją drogą), który pozwala na automatyzację kompilacji i uruchamiania kodu.

Aby ściągnąć kod części 0x01 wykonaj:

git clone git://github.com/luksow/OS.git --branch 0x01

Jeśli chcesz go tylko przejrzeć, wejdź tutaj.