Assembly HOWTO: KONWENCJE WYWOŁAŃ
Następna strona
Poprzednia strona
Spis treści
5. KONWENCJE WYWOŁAŃ
5.1 Linux
Połączenie z GCC
To jest preferowany sposób.
Sprawdź dokumentację i przykłady GCC z plików .S jądra Linux-a
które są przepuszczane przez gas (nie takie, które są przepuszczane przez as86).
32-bitowe argumenty są odkładane na stos w odwrotnej kolejności występowania
(stąd dostęp / pobieranie jest we właściwej kolejności),
zwracając bliski 32-bitowy adres.
%ebp, %esi,
%edi, %ebx są zapamiętywane,
inne rejestry też są zapamiętywane podczas wywołania;
%eax jest używany do przechowywania wyniku,
a %edx:%eax do przechowywania wyników 64-bitowych.
FP stack: Nie jestem pewien,
ale myślę że wynik jest w st(0), cały stos jest zapamiętany.
Pamiętaj, że GCC ma opcje modyfikujące konwencje wywołań
przez rezerwowanie rejestrów, przekazywanie argumentów w rejestrach,
nie używanie FPU, itd. Sprawdź strony .info i386.
Pamiętaj, że musisz zadeklarować atrybut cdecl
dla funkcji używających standardowej konwencji wywołań GCC
(nie wiem co daje użycie zmodyfikowanej konwencji wywołań).
Zobacz w stronach info GCC sekcję:
C Extensions::Extended Asm::
ELF kontra a.out - problemy
Pewne kompilatory poprzedają podkreśleniem każdy symbol,
podczas gdy inne nie.
W szczególności, Linux-owy GCC a.out ma takie poprzedniki,
podczas gdy Linux-owy ELF GCC nie.
Jeśli musisz poradzić sobie z wykorzystaniem obu formatów
zobacz jak robią to istniejące pakiety.
Dla przykładu, weź stare drzewo źródłowe Linux-a
z pakietami Elk, qthreads lub OCAML...
Możesz także nadpisać niejawnie C->asm zmieniając nazwę
przez wstawienie wyrażeń takich jak to
void foo asm("bar") (void);
by upewnić się, że wywołanie funkcji C foo będzie zabronione w assemblerze.
Zapamiętaj, że program objcopy, z pakietu binutils,
powinien pozwolić ci przekonwertować obiekty a.out w obiekty ELF,
i być może w przeciwną stronę także, w pewnych wypadkach.
Bardziej ogólnie, program ten realizuje konwersję formatów wielu plików.
Bezpośrednie wywołania systemowe Linux-a
To NIE jest rekomendowane,
ponieważ konwencje zmieniają się od czasu do czasu
od jądra do jądra (cf L4Linux),
dodatkowo to nie jest przenośne,
i niezyskowne w pisaniu biorąc pod uwagę libc,
I wyłącza poprawki i rozszerzenia które pojawiają się w libc,
takie, jak np. biblioteka zlibc,
która w locie przezroczyście dekompresuje spakowane gzip-em pliki.
Standardem i rekomendowaną drogą wywołań systemowych usług Linux-a jest
i tak zostanie, przejście przez libc.
Obiekty dzielone powinny trzymać twoje programy małymi.
I jeśli naprawdę chcesz mniejszych binariów, używaj #! ,
z interpretera mającego nad sobą wszystko czego nie chcesz w swoich
binariach.
Teraz, jeśli z pewnych powodów
nie chcesz linkować programów z libc
weź się za nią i zrozum jak działa!
Po tym wszystkim, nadal zamierzasz zamienić ją ?
Możesz zerknąć także jak mój
eforth 1.0c
robi to.
Źródła Linux-a są także użyteczne,
szczególnie plik nagłówkowy asm/unistd.h
który opisuje jak wywoływać funkcje systemowe...
Podstawowo, wywołujesz int $0x80
z __NR_numerem funkcji systemowej (z asm/unistd.h)
w %eax,
i parametrami (do pięciu) w
%ebx, %ecx, %edx,
%esi, %edi.
Rezultat jest zwracany w %eax
z wartością ujemną w przypadku błędu
której przeciwną wartość libc umieszcza w errno.
Stos użytkownika jest nietknięty
więc nie musisz mieć go właściwego podczas wywołania systemowego.
I/O pod Linux-em
Jeśli chcesz korzystać bezpośrednio z I/O pod Linux-em
jest coś prostego co nie uzależnia od OS,
i powinieneś obejrzeć IO-Port-Programming mini-HOWTO;
lub potrzebuje to sterownik urządzenia, powinieneś spróbować nauczyć się o
łamaniu jądra, rozwijaniu sterowników urządzeń, modułów jądra itd,
dla których są inne wspaniałe HOWTO i dokumenty z LDP.
W szczególności, jeśli chcesz zająć się programowaniem Grafiki
przyłącz się do projektu GGI:
http://www.ggi-projectorg/Jakkolwiek, we wszystkich przypadkach, zrobisz lepiej używając GCC inline assembly
z makrami z linux/asm/*.h, niż pisząc pliki źródłowe w samym assemblerze.
Dostęp do 16-bitowych sterowników z Linux-a/i386
Taka rzecz jest teoretycznie możliwa
(dowód: zobacz jak DOSEMU może selektywnie dawać dostęp portów do urządzeń programom), i słyszałem pogłoskę że ktoś gdzieś już to zrobił
(w sterowniku PCI? W dostępie do VESA ? ISA PnP ? nie wiem).
Jeśli masz więcej precyzyjnych informacji na ten temat
będa mile widziane.
Jakkolwiek, by uzyskać więcej informacji dobrymi miejscami są źródła jądra Linuxa,
źródła DOSEMU (i innych programów w
DOSEMU repository),
oraz źródła różnych niskopoziomowych programów działających pod Linux-em...
(być może GGI jeśli wspiera standard VESA).
Zasadniczo, musisz używać 16-bitowego trybu chronionego lub trybu vm86.
Na początku jest w miarę prosto to ustawić, ale będzie to działać tylko z dobrze-zrobionym kodem
The first is simpler to setup, but only works with well-behaved code
nie wykorzystującym jakiejkolwiek arytmetyki segmentowej
that won't do any kind of segment arithmetics
lub bezwzględnego adresowania segmentu (w szczególności adresowania segmentu 0),
or absolute segment addressing (particularly addressing segment 0),
do czasu zmian że wszystkie używane segmenty mogą być ustawione w zaawansowany
sposób w LDT.
Później pozwala się na większą zgodność z vanilla 16-bitowym otoczeniem (? przyp.tłum.),
ale wymaga to bardziej skomplikowanej manipulacji.
W obu przypadkach, przed wykonaniem skoku do 16-bitowego kodu
musisz
mmap każdy absolutny adres używany w 16-bitowym kodzie
(taki jak ROM, bufory video, docelowe DMA, i mapowane-do-pamięci I/O)
z /dev/mem to przestrzeni adresowej twojego procesu,
ustawić LDT i/lub monitor trybu vm86.
pobrać właściwe prawa dostępu do I/O z jądra (patrz powyższa sekcja)
I znowu, ostrożnie czytaj źródła do rzeczy zawartych
w powyższych informacjach o magazynie DOSEMU,
w szczególności te mini-emulatory
do uruchomiania ELKS i/lub prostych programów .COM pod Linux-em/i386.
5.2 DOS
Większość DOS-owych extenderów zawiera interfejs do usług DOS-a.
Poczytaj dokumentacje na ich temat,
ale często, symulują one tylko int $0x21 i inne,
więc robisz ``jakbyś'' był w trybie rzeczywistym
(mam wątpliwości czy nie są tylko łącznikami
i rozszerzają rzeczy by pracowały z 32-bitowymi operandami;
najczęściej są tylko przejściem w przerwanie
do trybu rzeczywistego lub przez uchwyt vm86).
Dokumentacja na temat DPMI i inne (oraz znacznie więcej) możesz znaleźć na
ftp://x2ftp.oulu.fi/pub/msdos/programming/DJGPP przychodzi z własną (ograniczoną) glibc pochodną/podzestawem/wymienioną, także.
Jest możliwa cross-kompilacja z Linux-a do DOS-a,
zobacz katalog devel/msdos/ najbliższej kopii FTP serwera sunsite.unc.edu
Zobacz także ekstender-dosa MOSS z projektu Flux w utah.
Inne dokumenty i FAQ są bardziej skoncentrowane na DOS-ie.
Nie zalecamy rozwoju pod DOS.
5.3 Winwybuchy i takie
(od tłum. Autor tego dokumentu nie przepada za Windows, słusznie zresztą,
i dlatego część tej podsekcji nie będzie mile widziana przez zwolenników
tego systemu :).
Hej, ten dokument zawiera tylko wolne oprogramowanie.
Zadzwoń kiedy Winwybuchy staną się wolne,
lub gdzie będą dostępne wolne narzędzia do tego!
No, po tym wszystkim, jest :
Cygnus Solutions
rozwijający bibliotekę cygwin32.dll,
dla programów GNU to uruchomienia pod platformami MakroGówna.
Jakkolwiek, możesz używać GCC, GAS, wszytkich narzędzi GNU,
i wielu innych Unix-owych aplikacji.
Zerknij na ich stronę domową.
Ja (Far) nie zamierzam rozszerzać Losedoze (od tłum. Windows -> Windoze ->
Losedoze (Lose) - przegrywać) programowania.
ale jestem pewny że wszędzie możesz znaleźć pełno dokumentów na tem temat...
5.4 Twój własny OS
Kontrola jest tym co przyciąga wielu programistów do assemblacji,
chcących najczęściej rozwijać OS co prowadzi lub pochodzi od łamania w assemblerze.
Zapamiętaj, że każdy system pozwalający na samorozwój może być określony jako "OS"
nawet mimo tego, że może chodzić "nad" pracującym systemem z wielozadaniowością lub I/O (takim jak Linux na Mach lub OpenGenera na Unix-ie), itd.
Stąd, dla łatwiejszego usuwania błędów,
możesz rozwijać twój ``OS'' najpierw jako proces chodzący
pod Linux-em (pomimo powolnego działania), a potem użyć
Flux OS kit
(co daje możliwość użycia sterowników Linux-a i BSD w twoim własnym OS)
by zrobić go niezależnym.
Gdy twój OS jest stabilny, jest jeszcze czas by napisać
sterowniki jeśli naprawdę to lubisz.
To HOWTO nie zawiera wewnątrz tematów takich jak
kod Boot loadera & wchodzenie w tryb 32-bitowy,
Zarządzanie Przerwaniami,
Podstawy o intelowskim ``trybie chronionym'' lub ``V86/R86'',
definiowania twoich formatów obiektów i konwencji wywołań.
Głównym miejscem gdzie możesz znaleźć pochodne informacje o tym wszystkim
to kody źródłowe istniejących OS i bootloaderów.
Masa wskaźników jest na poniższej stronie WWW:
http://www.tunes.org/~tunes/doc/Review/OSes.html
Następna strona
Poprzednia strona
Spis treści
Wyszukiwarka
Podobne podstrony:
Assembly HOWTO pl 4 (2)assembly howto plAssembly HOWTO pl 7 (2)Assembly HOWTO pl (2)Assembly HOWTO pl 6 (2)Assembly HOWTO pl 2 (2)assembly howto pl 3Assembly HOWTO pl 1 (2)bootdisk howto pl 8PPP HOWTO pl 6 (2)NIS HOWTO pl 1 (2)cdrom howto pl 1jtz howto pl 5Keystroke HOWTO pl (2)PostgreSQL HOWTO pl 14printing howto pl 5debian apt howto plKernel HOWTO pl 12 (2)XFree86 HOWTO pl (3)więcej podobnych podstron