Autor: Łukasz

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.

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.

Skąd pomysł?

Po ponad 6 miesiącach od powstania idei serii postów, pierwsza część ujrzała właśnie światło dzienne. Pomysł na cykl notek zrodził mi się zaraz po ukończeniu kursu „Systemy operacyjne” na mojej ulubionej uczelni. Według (genialnego!) Prowadzącego, około 15% studentów po tym kursie przystępuje do napisania własnego systemu operacyjnego i wygląda na to, że ja jestem w grupie tych ~19 osób. Zapowiada się świetna zabawa :)

Co to będzie?

Seria będzie dokumentować i opowiadać o moich zmaganiach z próbą napisania (od zera) systemu operacyjnego o pewnej funkcjonalności. W postach postaram się zawrzeć wiedzę i kod, który krok po kroku będzie układał się w pełnowartościowy system operacyjny.

Po co to?

Cykl postów o tematyce programowania systemu operacyjnego będzie dokumentacją moich poczynań. Posty będą zdecydowanie miały charakter poznawczy, gdyż w żadnym przypadku nie jestem autorytetem w tej dziedzinie, a (na razie!) tylko początkującym amatorem. Proponuję więc nie polegać na zawartej tu wiedzy podczas kolokwiów z architektury komputerów ;) Proszę też o regularne komentarze z poprawkami do prezentowanych przeze mnie zagadnień – z pewnością będę je wtedy poprawiał. Przy okazji serii mam nadzieję zachęcić czytelników do zagłębienia się w fascynujący świat programowania systemowego, odkryć go nieco, a może nawet skłonić do napisania własnego systemu operacyjnego? Ponadto, nie znalazłem w internecie publikacji w języku polskim, które prowadziłyby krok po kroku (no dobrze, kilka by się znalazło, jednak kroki kończyły się zwykle na 3 odcinkach) po niezwykle zawiłej tematyce tworzenia systemu operacyjnego – będę więc pionierem ;> Przypominam również, że powstający system operacyjny nie ma za zadanie przewyższyć udziału rynkowego takich świetnych systemów jak Microsoft Windows, GNU/Linux czy Mac OS X, gdyż byłoby to niedorzeczne. To po prostu zwykły projekt eksperymentalny.

Co będzie potrzebne?

Najważniejszą rzeczą jest wytrwałość i chęć zdobywania wiedzy :) Posiadając te dwie cechy, nawet całkowity nowicjusz sporo może wynieść z tego cyklu. W swoich wypocinach postaram się zgrabnie balansować między nadmierną gęstością tekstu, a przesadną zwięzłością. Trudniejsze rzeczy postaram się dokładnie objaśniać, łatwiejsze będę traktował po macoszemu, dodając odnośniki, z których będzie można doczytać więcej. Zachęcam do komentowania rzeczy niejasnych i skomplikowanych tak, abym z czasem mógł dostosować poziom.

System operacyjny, przynajmniej z początku, będzie napisany w języku C z małym dodatkiem assemblera x86 (będę używał „dialektu” NASM-a), zatem znajomość C, jak również nieco assemblera zdecydowanie się przyda.

Z całą pewnością potrzebny będzie jakiś działający system operacyjny z dostępnymi narzędziami programistycznymi. W swoich postach będę opisywał tworzenie systemu operacyjnego w środowisku GNU/Linux w połączeniu z typowymi dla tej platformy narzędziami takimi jak gcc czy binutils. Przedstawione przykłady, da się jednak bez problemu skompilować pod Windowsem, czy Mac OS X, wymagałoby to jednak nieco więcej pracy (jeśli będzie taka potrzeba, mogę opisać techniki w oddzielnym poście). Zwolenników systemów innych niż Linux zachęcam do zainstalowania jakiejś łatwej i przyjemnej dystrybucji, choćby na maszynie wirtualnej i programowania w takim środowisku. Gwarantuję, że inicjalny trud się opłaci.

Kolejna rzeczą, która nie jest konieczna, ale znacząco ułatwi nam programowanie i testowanie naszego systemu będzie emulator platformy x86 (gdyż na tą platformę będzie powstawał nasz system). Mój wybór padł na qemu. Emulator przyda się, aby uruchamiać świeżo skompilowany system – choć oczywiście dla wytrwałych pozostaje opcja odpalania systemu na prawdziwej maszynie.

Formalizmy

Koniec gadania, przystępujmy do rzeczy. Chcemy napisać system operacyjny, no dobrze… tylko co to tak właściwie jest? W literaturze dałoby się znaleźć setki mniej lub bardziej zmyślnych/złożonych/obszernych definicji, wymyślić nowych można by było kilka kolejnych, a więc… która jest dobra? Odpowiedzi na to pytanie nie ma, gdyż brakuje obiektywnych kryteriów oceny, czy dana definicja jest poprawna, zła, ładna, zgrabna itd. Mi najbardziej do gustu przypadła następująca:

System operacyjny jest to zbiór programów i procedur spełniających dwie podstawowe funkcje:

– zarządzanie zasobami systemu komputerowego,

– tworzenie maszyny wirtualnej.

Natomiast najtrafniejsza definicja zasobu systemu to wg mnie:

Zasobem systemu jest każdy jego element sprzętowy lub programowy, który może być przydzielony danemu procesowi.

Definicją procesu zajmiemy się przy innej okazji.

Teraz kilka słów wyjaśnień. Jak widać z definicji systemu operacyjnego – nie jest on sam w sobie programem, a zbiorem programów i procedur. System, który będziemy implementować za jakiś czas będzie wyglądał z punktu widzenia czysto technicznego jakby był jednym programem, jednak to tylko decyzja implementacyjna – w ogólności tak być nie musi. Pierwsza funkcja, którą pełni system operacyjny wydaje się być jasna – zarządza on zasobami, które oferuje. Zarządza, czyli udziela dostępu użytkownikowi, czy też raczej programowi użytkowemu. Zasoby sprzętowe to na przykład dysk twardy, pamięć, czy też komputery podłączone w sieci, do stacji na której działa system operacyjny. Zasoby programowe to natomiast wszelkiego rodzaju tablice, czy też semafory. Druga funkcja, czyli tworzenie maszyny wirtualnej może brzmieć nieco tajemniczo. Sama maszyna wirtualna jest raczej kojarzona z procesem wirtualizacji, stawianiem odseparowanych serwerów itp., tym razem chodzi jednak po prostu o tworzenie warstwy abstrakcji łatwej do oprogramowania, użytkowania i tę właśnie warstwę nazywamy maszyną wirtualną. Nieformalnie reasumując: system operacyjny ma za zadanie oferować to, co posiada, w przystępnej formie ;)

Rozważmy teraz takie pytanie: Czy program działający na mikrokontrolerze np. mikrofalówki, lodówki, czy pralki jest systemem operacyjnym? Odpowiedź na to pytanie (według podanej wyżej definicji) to: nie. Program ten jest zadany odgórnie, nie ma możliwości oprogramowywania go – nie posiada żadnej warstwy abstrakcji i o zasobach tutaj też trudno mówić. Z kolei, zastanówmy się nad takim telewizorem, który działa w oparciu o jądro Linux. Tu sprawa nie jest już taka prosta. W końcu wiadomo, że Linux to system operacyjny (puryści mogliby się doczepić do tego stwierdzenia.. ;)), tylko że ten system dla użytkownika końcowego jest całkowicie przezroczysty – nie ma on bezpośredniego dostępu do zasobów, szczególnej maszyny wirtualnej też tu nie widać. Zatem, czy patrząc na telewizor w kontekście pudełka,  w którego środku coś się dzieje i otrzymujemy obraz, należy mówić o systemie operacyjnym? Tak jak już mówiłem, z definicjami nie jest łatwo.

Na koniec

To tyle na pierwszy odcinek serii. W kolejnym odcinku zajmiemy się już konkretami, czyli własnościami architektury x86. Poniżej załączam listę stron z materiałami, które zdecydowanie będą się przydawać.

OSDev.org – bardzo aktywny serwis typu wiki, traktujący o tematyce programowania systemów operacyjnych. Polecam od niego zaczynać szukanie odpowiedzi na pojawiające się wątpliwości.

Bona Fide OS Developer – strona zawiera pokaźną ilość przydatnych tutoriali, niestety nie jest zbyt często uaktualniana

Operating System Resource Center – skarbnica wiedzy o wszelakich zasobach systemów operacyjnych. Panuje tam trochę bałaganu, nie mniej jednak, można tam znaleźć masę przydatnych informacji.

Intel® 64 and IA-32 Architectures Software Developer’s Manuals – darmowe (!) podręczniki Intela do architektury x86 (i x86-64), zawierające 2 grube tomy na temat programowania systemowego. Przystępnie napisane, zwięźle objaśniają subtelności architektoniczne. Da się tam chyba znaleźć odpowiedź na każde pytanie, choć tego nikt nie jest pewien, bo nikt nie dał rady ich przeczytać ;)

Into the Void – skrócony (jakby ten intelowski okazał się za długi, ciężko dostępny) opis instrukcji architektury x86

W porządku, to tyle. Do usłyszenia w następnej części!