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