/usr/share/doc/HOWTO/pl-html/Assembly-HOWTO.pl.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<META HTTP-EQUIV="content-type" content="text/html; charset=iso-8859-2">
<TITLE>Assembly HOWTO</TITLE>


</HEAD>
<BODY>
<H1>Assembly HOWTO<BR></H1>

<H2>Autor: François-René Rideau 
<A HREF="fare@tunes.org">fare@tunes.org</A><BR>
v0.4n, 22 Sierpnia 1998<BR>
<B>Wersja polska: Zbigniew Micha³ Kempczyñski
<A HREF="mailto:wegorz@bydgoszcz.pkobp.pl">wegorz@bydgoszcz.pkobp.pl</A><BR> </B>
v1.0, 30 Stycznia 1999 r. </H2>
<P><HR>
<EM>Dokument ten zosta³ napisany w standardzie ISO-8859-2. Orygina³ tego dokumentu znajduje sie pod adresem 
<A HREF="http://www.tunes.org/~fare/Assembly-HOWTO">http://www.tunes.org/~fare/Assembly-HOWTO</A>.
<EM>To jest
Linux Assembly HOWTO.</EM>
Ten dokument opisuje metody programowania w assemblerze
z u¿yciem <EM>WOLNYCH</EM> narzêdzi programistycznych,
koncentruj±c siê na Systemie Operacyjnym Linux na platformach i386.
Za³±czony materia³ mo¿e, ale nie musi byæ zgodny,
z innym sprzêtem i/lub oprogramowaniem.
Przewodnictwo na tym bêdzie mile widziane.
<EM>S³owa kluczowe</EM>:
        assemblacja, assembler, wolny, makroprocesor, preprocesor,
        asm, inline asm, 32-bitowy, x86, i386, gas, as86, nasm</EM>
<HR>
<H2><A NAME="s1">1. WPROWADZENIE</A></H2>

<H2>1.1 Legal Blurp</H2>

<P>Copyright &copy; 1996,1997,1998 by François-René Rideau.
<P>Ten dokument jest wolnym oprogramowaniem, mo¿esz go redystrybuowaæ
i/lub modyfikowaæ zgodnie z za³o¿eniami GNU General Public License
opublikowanym przez Free Software Foundation;
wersja 2 Licencji, lub (w twoim przypadku) inna pó¼niejsza wersja.
<P>
<H2>1.2 Wa¿na Informacja</H2>

<P>To jest interaktywnie rozwijany dokument: jeste¶ specjalnie proszony do
zadawania pytañ, 
udzielania odpowiedzi na pytania,
poprawiania odpowiedzi,
dodawania nowych odpowiedzi na FAQ, 
wskazywania na inne oprogramowanie, 
wskazywania osobie prowadz±cej b³êdy lub braki na stronach.
Je¶li jeste¶ zmotywowany, móg³by¶
<EM>przej±æ prowadzenie tego HOWTO</EM>.
S³owem, dzia³aj !
<P>By przej±æ prowadzenie skontaktuj siê z kimkolwiek, kto wydaje siê prowadziæ
Assembly-HOWTO. W trakcie tego pisania to jestem ja, np.
<A HREF="mailto:fare@tunes.org">François-René Rideau</A>.
Jakkolwiek, minê³o trochê czasu od kiedy poszukiwa³em mocnego go¶cia
by podmieni³ mnie jako prowadz±cego ten dokument. Niekorzy¶ci± jest to,
i¿ musisz spêdziæ trochê czasu trzymaj±c dokument na czasie, poprawiaj±c go,
i ucz±c siê narzêdzi publikacyjnych LDP. Korzy¶ci± jest to, i¿ zdobêdziesz 
trochê s³awy <EM>i</EM> mo¿esz otrzymaæ wolne kopie kompendiów HOWTO.
<P>
<H2>1.3 Przed s³owem</H2>

<P>Ten dokument ma na celu udzielenie odpowiedzi na najczê¶ciej zadawane pytania przez ludzi,
którzy programuj± lub chc± programowaæ w 32-bitowym assemblerze x86
u¿ywaj±c <EM>wolnych</EM> assemblerów, 
zw³aszcza w systemie operacyjnym Linux.
Mo¿e on tak¿e wskazywaæ inne dokumenty o 
nie-wolnych, nie-x86, lub nie-32-bitowych assemblerach, 
chocia¿ nie jest to jego pierwszorzêdnym celem.
<P>Poniewa¿ g³ównym celem programowania w assemblerze jest budowa 
wnêtrzno¶ci systemów operacyjnych, interpretatorów, kompilatorów, i gier,
gdzie kompilator C zawodzi nie dostarczaj±c potrzebnych ¶rodków wyrazu,
(wykonanie jest coraz rzadszym tematem),
skoncentrujemy siê na rozwoju takiego oprogramowania.
<P>
<H3>Jak u¿ywaæ tego dokumentu</H3>

<P>Ten dokument zawiera odpowiedzi na pewne najczê¶ciej zadawane pytania.
W wielu miejscach, zosta³y umiejscowione adresy URL by wskazaæ na pewne 
oprogramowanie lub magazyny dokumentacji.
<P>Sprawd¼ gdzie s± skopiowane najbardziej u¿yteczne magazyny,
i spróbuj dobraæ siê do najbli¿szej z nich;
uchronisz w ten sposób Internet przed niepotrzebym ruchem w sieci,
i zaoszczêdzisz swój cenny czas.
<P>W szczególno¶ci pewne wielkie magazyny na ca³ym ¶wiecie,
sa kopiami innych popularnych magazynów.
Powiniene¶ siê nauczyæ i zapamiêtaæ miejsca umiejscowione blisko ciebie (roztropno¶æ-sieciowa).
Czasami, lista takich kopii jest wypisana w pliku, 
lub we wiadomo¶ci wej¶ciowej. Miej na uwadze te porady.
W przeciwnym wypadku zapytaj archie o oprogramowaniu którego szukasz...
<P>Naj¶wie¿sze wersje tego dokumentu znajduj± siê w
<A HREF="http://www.tunes.org/~fare/Assembly-HOWTO">http://www.tunes.org/~fare/Assembly-HOWTO</A>
lub
<A HREF="http://www.tunes.org/~fare/Assembly-HOWTO.sgml">http://www.tunes.org/~fare/Assembly-HOWTO.sgml</A><P>ale to co jest w magazynach Linux HOWTO <EM>powinno</EM> byæ tak¿e na czasie 
(ale tego nie wiem):
<P>
<A HREF="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/">ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/</A> (?)
<P>Francuska wersja tego HOWTO mo¿e byæ znaleziona w
<P>
<A HREF="ftp://ftp.lip6.fr/pub/linux/french/HOWTO/">ftp://ftp.lip6.fr/pub/linux/french/HOWTO/</A><P>
<H3>Inne zale¿ne dokumenty</H3>

<P>
<P>
<UL>
<LI>Je¶li nie wiesz czym jest <EM>wolne</EM> oprogramowanie,
proszê przeczytaj <EM>ostro¿nie</EM> GNU General Public License,
która jest u¿ywana w wielu wolnych programach,
i jest pierwowzorem dla wiêkszo¶ci takich licencji.
Ogólnie pojawia siê w pliku o nazwie <CODE>COPYING</CODE>, 
z wersj± biblioteczn± w pliku o nazwie <CODE>COPYING.LIB</CODE>.
Literatura z 
<A HREF="http://www.fsf.org">FSF</A>
(fundacja wolnego oprogramowania) mo¿e tak¿e ci pomóc.
</LI>
<LI>W szczególno¶ci, interesuj±cym rzecz± w takim typie wolnego oprogramowania
przychodz±cego ze ¼ród³ami jest to, i¿ mo¿esz je sprawdziæ, poprawiæ
a tak¿e czasami z nich zapo¿yczyæ. 
Przeczytaj ostro¿nie szczegó³y licencji i skorzystaj.
</LI>
<LI>Jest lista FAQ na comp.lang.asm.x86, która odpowie na wiele ogólnych pytañ
o programowaniu w assemblerze x86, i pytaniach o pewnych komercyjnych
assemblerach w 16-bitowym ¶rodowisku DOS-a.
Pewne z nich zahaczaj± o wolnym 32-bitowym programowaniu, wiêc mo¿esz chcieæ
przeczytaæ to FAQ... 

<A HREF="http://www2.dgsys.com/~raymoon/faq/asmfaq.zip">http://www2.dgsys.com/~raymoon/faq/asmfaq.zip</A>
</LI>
<LI>FAQ-i i dokumenty istniej± o programowaniu na twojej ulubionej platformie,
jakakolwiek ona jest, wiêc powiniene¶ skonsultowaæ tematy specyficzne dla niej 
nie bezpo¶rednio zwi±zane z programowaniem w assemblerze. </LI>
</UL>
<P>
<H2>1.4 Historia</H2>

<P>Ka¿da wersja zawiera kilka napraw i mniejszych korekt,
których nie bêdzie trzeba ci±gle poprawiaæ.
<DL>
<DT><B>Version 0.1      23 Kwiecieñ 1996</B><DD><P>Francois-Rene "Faré" Rideau &lt;fare@tunes.org&gt;
tworzy i publikuje pierwsze mini-HOWTO,
poniewa¿ ``Jestem chory od ci±g³ego odpowiadania na te same pytania
na comp.lang.asm.x86''
<P>
<DT><B>Version 0.2      4 Maj 1996</B><DD><P>*
<P>
<DT><B>Version 0.3c     15 Czerwiec 1996</B><DD><P>*
<P>
<DT><B>Version 0.3f     17 Pa¼dziernik 1996</B><DD><P>*
<P>
<DT><B>Version 0.3g     2 Listopad 1996</B><DD><P>Utworzenie Historii. Dodanie wska¼ników w sekcji o cross-kompilacji.
Dodanie sekcji o programowaniu I/O pod Linux-em (w szczególno¶ci video).
<P>
<DT><B>Version 0.3h     6 Listopad 1996</B><DD><P>wiêcej o cross-kompilacji - Zobacz na sunsite: devel/msdos/ 
<P>
<DT><B>Version 0.3i     16 Listopad 1996</B><DD><P>NASM ³atwo przechodzi
<P>
<DT><B>Version 0.3j     24 Listopad 1996</B><DD><P>wskazanie na t³umaczenie francuskie
<P>
<DT><B>Version 0.3k     19 Grudzieñ 1996</B><DD><P>Co ? Zapomnia³em wskazac na terse???
<P>
<DT><B>Version 0.3l     11 Styczeñ 1997</B><DD><P>*
<P>
<DT><B>Version 0.4pre1  13 Styczeñ 1997</B><DD><P>tekst mini-HOWTO przekszta³ca siê w pe³ne linuxdoc-sgml-owe HOWTO,
by zobaczyæ jak wygl±daj± narzêdzia SGML.
<P>
<DT><B>Version 0.4      20 Styczeñ 1997</B><DD><P>pierwsze jako takie wypuszczenie tego HOWTO.
<P>
<DT><B>Version 0.4a     20 Styczeñ 1997</B><DD><P>do³o¿ono sekcjê Wyrazy Uznania  
<P>
<DT><B>Version 0.4b     3 Luty 1997</B><DD><P>przesuniêcie NASM: teraz jest przed AS86
<P>
<DT><B>Version 0.4c     9 Luty 1997</B><DD><P>Dodano sekcjê "CZY POTRZEBUJESZ ASSEMBLACJI ?"
<P>
<DT><B>Version 0.4d     28 Luty 1997</B><DD><P>Vapor oznajmia o nowym przewodnictwie Assembly-HOWTO.
<P>
<DT><B>Version 0.4e     13 Luty 1997</B><DD><P>Wypuszczenie o DrLinux
<P>
<DT><B>Version 0.4f     20 Marzec 1997</B><DD><P>*
<P>
<DT><B>Version 0.4g     30 Marzec 1997</B><DD><P>*
<P>
<DT><B>Version 0.4h     19 Czerwiec 1997</B><DD><P>wci±¿ wiêcej na temat "jak nie u¿ywaæ assemblacji";
unowocze¶nienie o NASM, GAS.
<P>
<DT><B>Version 0.4i     17 Lipiec 1997</B><DD><P>info o 16-bitowym trybie dostêpu z Linux-a.
<P>
<DT><B>Version 0.4j     7 Sierpieñ 1997</B><DD><P>*
<P>
<DT><B>Version 0.4k     19 Pa¼dziernik 1997</B><DD><P>*
<P>
<DT><B>Version 0.4l     16 Listopad 1997</B><DD><P>wypuszczenie o szóstej edycji LSL.
<P>
<DT><B>Version 0.4m     23 Marzec 1998</B><DD><P>poprawki o wywo³aniu gcc 
<P>To jest jeszcze inne ostatnie-wydanie-przez-Faré-przed-przejêciem-przez-nowego prowadz±cego (?)
<P>
</DL>
<P>
<H2>1.5 Wyrazy Uznania</H2>

<P>Chacia³bym podziêkowaæ nastêpuj±cym osobom, w kolejno¶ci wystêpowania:
<UL>
<LI>
<A HREF="mailto:buried.alive@in.mail">Linus Torvalds</A>
za Linux-a 
</LI>
<LI>
<A HREF="mailto:bde@zeta.org.au">Bruce Evans</A>
za bcc z którego jest wyci±gniêty as86
</LI>
<LI>
<A HREF="mailto:anakin@pobox.com">Simon Tatham</A> i
<A HREF="mailto:jules@earthcorp.com">Julian Hall</A>
za NASM
</LI>
<LI>
<A HREF="mailto:jim-neil@digital.net">Jim Neil</A>
za Zwiêz³o¶æ
</LI>
<LI>
<A HREF="mailto:gregh@sunsite.unc.edu">Greg Hankins</A>
za prowadzenie HOWTO
</LI>
<LI>
<A HREF="mailto:raymoon@moonware.dgsys.com">Raymond Moon</A>
za jego FAQ   
</LI>
<LI>
<A HREF="mailto:dumas@linux.eu.org">Eric Dumas</A>
za t³umaczenie mini-HOWTO na francuski
(smutna rzecz, ¿e autor jest francuzem i pisze po angielsku)
</LI>
<LI>
<A HREF="mailto:paul@geeky1.ebtech.net">Paul Anderson</A>
i
and 
<A HREF="mailto:rahim@megsinet.net">Rahim Azizarab</A>
za pomoc, je¶li nie przejêcie HOWTO.
</LI>
<LI>
<A HREF="mailto:pcg@goof.com">Marc Lehman</A>
za wgl±d w wywo³ania GCC.       
</LI>
<LI>Wszystkim ludziom którzy w³o¿one pomys³y, uwagi i wsparcie moralne.</LI>
</UL>
<P>
<P>
<H2><A NAME="doyouneedasm"></A> <A NAME="s2">2. CZY POTRZEBUJESZ ASEMBLACJI?</A></H2>

<P>No, nie chcia³bym przeszkadzaæ w tym co robisz,
ale tu jest kilka porad ciê¿ko zarobionego do¶wiadczenia.
<P>
<H2>2.1 Za i Przeciw</H2>

<P>
<P>
<H3>Korzy¶ci Assemblacji</H3>

<P>Assemblacja mo¿e wyraziæ mocno niskopoziomowe rzeczy:
<UL>
<LI>masz dostêp do zale¿nych-od-maszyny rejestrów i I/O.
</LI>
<LI>mo¿esz kontrolowaæ dok³adnie zachowanie kodu
w krytycznych sekcjach które mog± wywo³aæ martwe punkty
pomiêdzy wieloma w±tkami programowymi lub urz±dzeniami.  
</LI>
<LI>mo¿esz z³amaæ ustalenia zwyk³ego kompilatora,
który mo¿e pozwalaæ na pewne optymalizacje
(jak chwilowe ³amanie zasad o przydzielaniu pamiêci, 
w±tkach, konwencji wywo³añ, itd).      
</LI>
<LI>mo¿esz budowaæ interfejsy pomiêdzy fragmentami kodu
u¿ywaj±cego pewnych niekompatybilnych konwencji
(np. produkowanego przez ró¿ne kompilatory, 
lub oddzielonego nisko-poziomowym interfejsem).
</LI>
<LI>masz dostêp do nieu¿ywanych trybów twojego procesora 
(np. 16 bitowy tryb interfejsu startowego, instrukcji chip-owych 
(przyp.t³um.) lub dziedziczonego kodu na Intel PC)
</LI>
<LI>mo¿esz produkowaæ rozs±dnie szybki kod dla zwartych pêtli
by poradziæ sobie ze z³ym nie-zoptymalizowanym kompilatorem
(po co, s± przecie¿ dostêpne wolne zoptymalizowane kompilatory!)
</LI>
<LI>mo¿esz produkowaæ kod gdzie
ale tylko na procesorach ze znanym czasem instrukcji,
który ogólnie wy³±cza ca³y przep³yw .... 
</LI>
<LI>mo¿esz produkowaæ rêcznie-zoptymalizowany kod
który jest perfekcyjnie dostosowany do twojej szczególnej konfiguracji sprzêtowej,
a zatem do nikogo wiêcej.
</LI>
<LI>mo¿esz pisaæ pewien kod dla twojego kompilatora nowego jêzyka
(to jest co¶ którzy mog± zrobiæ nieliczni, i tak¿e oni, nie czêsto).</LI>
</UL>
<P>
<P>
<P>
<H3>Niekorzy¶ci Assemblacji</H3>

<P>Assemblacja jest bardzo nisko-poziomowym jêzykiem
(najni¿szym jest rêczne-kodowanie w kodach binarnych instrukcji).
<P>To znaczy
<UL>
<LI>jest d³ugo i monotonnie pisaæ wszystko od pocz±tku,
</LI>
<LI>jest mocno podatna na b³êdy,
</LI>
<LI>b³êdy bêd± bardzo trudne do wy¶ledzenia,
</LI>
<LI>jest to bardzo trudno zrozumieæ i modyfikowaæ,
np. utrzymywaæ
</LI>
<LI>rezultat jest bardzo nie-przeno¶ny na inne architektury,
aktualne i przysz³e,
</LI>
<LI>twój kod bêdzie zoptymalizowany tylko w pewnych implementacjach
na tej samej architekturze:  

dla przyk³adu, po¶ród platform Intelowskich,
ka¿dy wariant CPU i jego odmian
(wzglêdy ukryte, przepustowo¶æ, pojemno¶æ
jednostek obliczeniowych, cache'y, RAM-u, szyny, dysków,
obecno¶ci FPU, rozszerzeñ MMX, itd)   

daje potencjalnie ca³kowicie ró¿ne techniki optymalizacji.   

Warianty CPU ju¿ w³±czone 
Intel 386, 486, Pentium, PPro, Pentium II;
Cyrix 5x86, 6x86; AMD K5, K6.
        
Nowe warianty pojawiaj± siê wiêc nie spodziewaj siê, ¿e ka¿dy listing
twojego kodu bêdzie na czasie.
</LI>
<LI>twój kod mo¿e byæ tak¿e nieprzeno¶ny przez ró¿ne 
platformy systemowe na tej samej architekturze, przez brak w³a¶ciwych narzêdzi
(no, GAS wydaje siê pracowaæ na wszystkich platformach;
NASM wydaje siê pracowaæ lub byæ w stanie pracowaæ na platformach intelowskich).
</LI>
<LI>spêdzisz wiêcej czasu na kilku detalach, 
i nie bêdziesz móg³ skoncentrowaæ siê na ma³ych i du¿ych algorytmach,
które s± w stanie przynie¶æ najwiêksz± czê¶æ przyspieszenia.
[np. mo¿esz spêdziæ trochê czasu buduj±c bardzo szybkie
prymitywy manipulacji na listach/tablicach w assemblerze;
tylko hash-tablice (przyp.t³um.) mog± mocno przyspieszyæ twój program;
lub i innym przypadku, drzewka binarne;
lub pewne wysokopoziomowe struktury rozprowadzane przez klaster 
CPU] 
</LI>
<LI>ma³a zmiana w konstrukcji algorytmu mog³aby ca³kowicie
uniewa¿niæ twój ca³y istniej±cy assemblowany kod.
Tak wiêc tak¿e ty masz byæ gotowy (i w stanie) by przepisaæ to wszystko,
lub bêdziesz przywi±zany do poszczególnych rozwi±zañ algorytmicznych;
</LI>
<LI>W kodzie który nie wypada daleko od standardowych testów, 
komercyjne zoptymalizowane kompilatory wykonuj± prawe rêcznie-kodowany assembler
(no, to jest mniejsz± prawd± na architekturze x86
ni¿ na architekturach RISC-owych;
i byæ mo¿e mniejsz± prawd± ni¿ dla szeroko dostêpnych/wolnych kompilatorach;
jakkolwiek, dla typowego kodu w C, GCC jest ca³kiem dobry);   
</LI>
<LI>I w dowolnym przypadku, jak powiedzia³ wstrzemiê¼liwy John Levine na comp.compilers,
``kompilatory mocno u³atwiaj± u¿ywanie z³o¿onych struktur danych,
i kompilatory nie daj± znudzenia w po³owie drogi
i generuj± ca³kiem dobry kod.''   
One tak¿e bêd± <EM>prawid³owo</EM> przechodziæ transformacje kodu
poprzez ca³y (olbrzymi) program
podczas optymalizacji kodu pomiêdzy procedurami i granicami modu³ów.</LI>
</UL>
<P>
<P>
<H3>Ocenianie</H3>

<P>Podsumowuj±c, chocia¿ mo¿esz uznaæ 
¿e u¿ycie assemblacji jest czasami konieczne,
a nawet po¿yteczne w kilku przypadkach gdzie nie jest konieczne,
bêdziesz chcia³:
<P>
<UL>
<LI>minimalizowaæ u¿ycie kodu assemblera,
</LI>
<LI>hermetyzowaæ ten kod w dobrze zdefiniowanych interfejsach
</LI>
<LI>mieæ kod assemblera generowany automatycznie 
ze wzorców wyra¿onych w wysokopoziomowym jêzyku
ni¿ w assemblerze (np. assemblerowe makra GCC inline)
</LI>
<LI>mieæ narzêdzia automatyzuj±ce t³umaczenie tych programów 
w kod assemblera
</LI>
<LI>mieæ ten kod zoptymalizowany je¶li jest to mo¿liwe
</LI>
<LI>Nade wszystko,
np. pisaæ (rozszerzaæ do) zoptymalizowanych wnêtrzno¶ci kompilatora.</LI>
</UL>
<P>Nawet w przypadkach kiedy Assemblacja jest konieczna (np. rozwój OS)
mo¿esz uznaæ, ¿e nie a¿ do tego stopnia
i trzymaæ siê w/w zasad.
<P>Obejrzyj ¼rod³a j±dra Linux-a zwracaj±c uwagê:
jak ma³o assemblacji jest konieczne,
by uzyskaæ szybki, niezawodny, przeno¶ny, utrzymywalny OS.
Tak¿e udana gra taka jak DOOM zosta³a prawie ca³kowicie napisana w C,
z ma³a czê¶ci± napisan± w assemblerze tylko do przy¶pieszenia jej dzia³ania.
<P>
<H2>2.2 Jak NIE u¿ywaæ Assemblera</H2>

<P>
<P>
<H3>Ogólne zasady uzyskania efektywnego kodu</H3>

<P>Jak rzek³ Charles Fiterman na comp.compilers
o 'cz³owieku kontra kod assemblera wygenerowany przez komputer', 
<P>``Cz³owiek powinien zawsze wygraæ i oto przyczyna.
<UL>
<LI>Po pierwsze cz³owiek pisze ca³o¶æ w jêzyku wysokiego poziomu.
</LI>
<LI>Po drugie zarysowuje gdzie mog± wyst±piæ gor±ce punkty gdzie program spêdza swój czas.
</LI>
<LI>Po trzecie ma kompilator produkuj±cy kod assemblera dla tych ma³ych
sekcji kodu.
</LI>
<LI>Po czwarte rêcznie dostosowuje je by znale¼æ ma³e korzy¶ci 
nad wygenerowanym przez maszynê kodem.</LI>
</UL>

Cz³owiek wygrywa poniewaz umie u¿ywaæ maszyny.''
<P>
<H3>Jêzyki ze zoptymalizowanymi kompilatorami</H3>

<P>Jêzyki takie jak 
ObjectiveCAML, SML, CommonLISP, Scheme, ADA, Pascal, C, C++,
wsród innych,
wszystkie maj± wolne zoptymalizowane kompilatory,
które zoptymalizuj± masê twoich programów,
i czêsto bêd± lepsze ni¿ rêczny kod assemblera nawet dla szczelnych pêtli,
umo¿liwiaj±c ci skoncentrowanie siê na wysokopoziomowych szczegó³ach,
i bez zakazywania ci z³apania
kilku procent wykonania w wy¿ej wymieniony sposób
w momencie gdy osi±gniesz stabilny rozwój.
Oczywi¶cie, s± tak¿e komercyjne zoptymalizowane kompilatory
dla wiêkszo¶ci z tych jêzyków.
<P>Pewne jêzyki maj± kompilatory produkuj±ce kod w C,
który mo¿e byæ dalej zoptymalizowany przez dany kompilator C.
Takimi s± LIST, Scheme, Perl i wiele innych.
Prêdko¶æ jest ca³kiem dobra.
<P>
<H3>Ogólne zasady przy¶pieszania twojego kodu</H3>

<P>W celu przyspieszenia kodu
powiniene¶ robiæ zrobiæ to tylko dla fragmentów programu
które narzêdzie profiluj±ce konsekwentnie okre¶la
jako w±skie gard³o wykonania. 
<P>St±d, je¶li okre¶lisz fragmenty kodu jako zbyt wolne, powiniene¶
<UL>
<LI>najpierw spróbowaæ lepszego algorytmu;
</LI>
<LI>nastêpnie spróbowaæ skompilowaæ go zamiast interpretowaæ;
</LI>
<LI>nastêpnie spróbowaæ w³±czyæ optymalizacje twojego kompilatora;
</LI>
<LI>nastêpnie daæ kompilatorowi wskazówki jak optymalizowaæ
(wypisywanie informacji w LISP-ie; u¿ywanie rejestrów w GCC;
i pe³no innych opcji w wiêkszo¶ci kompilatorów, itd).
</LI>
<LI>nastêpnie mo¿na cofn±æ siê do programowania w assemblerze</LI>
</UL>
<P>Na koñcu, przed zej¶ciem do pisania w assemblerze,
powiniene¶ prze¶ledziæ wygenerowany kod,
sprawdzaj±c czy problem nie le¿y faktycznie w z³ej generacji kodu,
co jest mo¿liwe ale nie w wypadkach:
kod wygenerowany przez kompilator mo¿e byæ lepszy ni¿ móg³byæ napisaæ,
w szczególno¶ci na nowoczesnych architekturach!
Wolne czê¶ci programu mog± byæ równie zagmatwane.
Najwiêkszym problemem nowoczesnych architektur z szybkimi procesorami
s± pewne opó¼nienia dostêpu do pamiêci, nietrafiony dostêp do cache,
i TLB oraz b³êdy stronnicowania;
optymalizacja z u¿yciem rejestrów staje siê wtedy mniej u¿yteczna,
i zyska³byæ wiêcej po przemy¶leniu struktury danych oraz wykorzystuj±c
w±tkowanie gdy¿ uzyska³by¶ lepsze umiejscowienie w dostêpie do pamiêci.
Byæ mo¿e po¼niej dopiero ca³kowicie odmienne spojrzenie na problem, pomo¿e go rozwi±zaæ.
<P>
<H3>Sprawdzanie kodu generowanego przez kompilator</H3>

<P>Jest wiele powodów do sprawdzenia kodu generowanego przez kompilator.
Tu jest zawarte co robiæ z takim kodem:
<UL>
<LI>sprawdziæ czy generowany kod
mo¿e byæ wzmocniony rêcznym kodem assemblera
(lub prze³±czaniem prze³±czników kompilatora)
</LI>
<LI>gdy zachodzi taka mo¿liwo¶æ
rozpocz±æ z tak wygenerowanego kodu i zmodyfikowaæ go;
zamiast rozpoczynaæ wszystko od pocz±tku
</LI>
<LI>bardziej ogólnie, u¿ywaæ generowanego kodu jako kawa³ków do modyfikacji,
który co najmniej daje w³a¶ciw± drogê
twoim funkcjom w assemblerze interfejs do ¶wiata zewnêtrznego 
</LI>
<LI>wy³apaæ b³êdy w kompilatorze (oby jak najrzadziej)</LI>
</UL>
<P>Standardow± metod± uzyskania kodu assemblera 
jest wywo³anie twojego kompilatora z flag± <CODE>-S</CODE>.
Dzia³a to dla wiêkszo¶ci Unix-owych kompilatorów,
w³±czaj±c w to GNU C Compiler (GCC), ale YMMV.
Dla GCC, bardziej zrozumia³y kod assemblera bêdzie wyprodukowany
po u¿yciu opcji <CODE>-fverbose-asm</CODE>.
Oczywi¶cie, je¶li chcesz dostaæ dobry kod assemblera,
nie zapomnij u¿yæ opcji optymalizacji i wskazówek!
<P>
<H2><A NAME="s3">3. ASSEMBLERY</A></H2>

<P>
<P>
<H2>3.1 Inline Assemblera GCC</H2>

<P>Dobrze znany kompilator GNU C/C++ (GCC),
zoptymalizowany 32-bitowy kompilator bêd±cy sercem projektu GNU,
wspiera ca³kiem dobrze architekturê x86,
w³±czaj±c w to zdolno¶æ wstawiania kodu assemblera w programach w C,
w sposób gdzie zarz±dzanie rejestrami mo¿e byæ wyspecyfikowane lub pozostawione GCC.
GCC dzia³a na wiêkszo¶ci dostêpnych platform,
dla godnych uwagi Linux-a, *BSD, VST, OS/2, *DOS-a, WIN*, itd.
<P>
<H3>Gdzie znale¼æ GCC</H3>

<P>Orginalny adres GCC jest adresem FTP GNU
<A HREF="ftp://prep.ai.mit.edu/pub/gnu/">ftp://prep.ai.mit.edu/pub/gnu/</A>
razem ze wszystkimi wersjami aplikacji z projektu GNU.
Przekompilowane i skonfigurowane dla Linux-a wersje s± w 
<A HREF="ftp://sunsite.unc.edu/pub/Linux/GCC/">ftp://sunsite.unc.edu/pub/Linux/GCC/</A>
Istnieje wiele kopii FTP obu adresów,
na ca³ym ¶wiecie a tak¿e na no¶nikach CD.
<P>Rozwój GCC zosta³ podzielony niedawno na dwie czê¶ci.
Wiêcej na temat eksperymentalnej wersji egcs mozna znale¼æ na
<A HREF="http://www.cygnus.com/egcs/">http://www.cygnus.com/egcs/</A><P>¬ród³a przystosowane do twojej ulubionego OS, oraz przekompilowane binaria
mo¿na znale¼æ na zwyk³ych adresach FTP.
<P>Najbardziej popularny port GCC dla DOS-a nosi nazwê DJGPP
i mo¿e byæ znaleziony w katalogach o takiej nazwie na adresach FTP. Zobacz:
<P>
<A HREF="http://www.delorie.com/djgpp/">http://www.delorie.com/djgpp/</A><P>Jest tak¿e port GCC na OS/2 nazwany EMX,
dzia³aj±cy tak¿e pod DOS-em, 
zawieraj±cy wiele bibliotek emuluj±cych wywo³ania funkcji unix-a.
Zobacz:
<P>
<A HREF="http://www.leo.org/pub/comp/os/os2/gnu/emx+gcc/">http://www.leo.org/pub/comp/os/os2/gnu/emx+gcc/</A><P>
<A HREF="http://warp.eecs.berkeley.edu/os2/software/shareware/emx.html">http://warp.eecs.berkeley.edu/os2/software/shareware/emx.html</A><P>
<A HREF="ftp://ftp-os2.cdrom.com/pub/os2/emx09c/">ftp://ftp-os2.cdrom.com/pub/os2/emx09c/</A><P>
<H3>Gdzie znale¼æ dokumentacje GCC Inline Asm</H3>

<P>Dokumentacja GCC zawiera pliki w formacie texinfo.
Mo¿esz przekompilowaæ je TeX-em i wydrukowaæ rezultat,
lub przekonwertowaæ je do .info i ogl±daæ emacs-em,
lub przekonwertowaæ je do .html.
Mo¿esz przekonwertowaæ je (w³a¶ciwymi narzêdziami) do tego co lubisz najbardziej, lub czytaæ takie jakie s±.
Pliki .info s± ogólnie dostarczane z ka¿d± dobr± instalacj± GCC.
<P>W³a¶ciw± sekcj± do sprawdzenia jest:
<CODE>C Extensions::Extended Asm::</CODE>
<P>Sekcja
<CODE>Invoking GCC::Submodel Options::i386 Options::</CODE>
mo¿e byæ ci tak¿e pomocna.
W szczególno¶ci, podaje ci specyficzne ograniczenia nazw rejestrów:
abcdSDB koresponduj± do
<CODE>%eax</CODE>, <CODE>%ebx</CODE>, <CODE>%ecx</CODE>, <CODE>%edx</CODE>,
<CODE>%esi</CODE>, <CODE>%edi</CODE>, <CODE>%ebp</CODE>
wy³±czaj±c (nie ma litery dla <CODE>%esp</CODE>).
<P>Zasoby gier dla DJGPP (nie tylko dla hackerów gier) maj± swoj± stronê
specjalnie o assemblerze:
<P>
<A HREF="http://www.rt66.com/~brennan/djgpp/djgpp_asm.html">http://www.rt66.com/~brennan/djgpp/djgpp_asm.html</A><P>Jest jeszcze strona www nazwana ``DJGPP Quick ASM Programming Guide'',
zawieraj±ca od URL-i do FAQ,
AT&amp;T Sk³adnia ASM x86 ,
Pewne informacje o inline ASM,
i konwertowanie plików .obj/.lib:
<P>
<A HREF="http://remus.rutgers.edu/~avly/djasm.html">http://remus.rutgers.edu/~avly/djasm.html</A><P>GCC zale¿y od GAS podczas assemblacji, i ¶ledzi jego sk³adniê (patrz poni¿ej);
pamiêtaj±c ¿e inline asm wymaga znaków procent podczas cytowania
by mog³y przej¶æ do GAS.
Zobacz poni¿sz± sekcjê o GAS.
<P>Znajdziesz <EM>pe³no</EM> u¿ytecznych przyk³adów w podkatalogu <CODE>linux/include/asm-i386/</CODE>
¼róde³ j±dra Linux-a.
<P>
<H3>Jak w³a¶ciwie wywo³ywaæ GCC z kodem inline assemblera.</H3>

<P>Poniewa¿ funkcje assemblera w ¼ród³ach j±dra
(i bardzo prawdopodobnie twoje w³asne nag³ówki,
je¶li spróbujesz stworzyæ twoje oprogramowanie w assemblerze tak czyste
jak to jest w j±drze linuxa)
s± osadzone w funkcjach <CODE>extern inline</CODE>,
GCC musi zostaæ wywo³±ny z <CODE>-O</CODE> flag (or <CODE>-O2</CODE>, <CODE>-O3</CODE>, itd),
by te funkcje by³y dostêpne.
Je¶li nie, twój kod mo¿e siê skompiluje, ale nie zostanie w³a¶ciwie zlinkowany,
gdy¿ bêdzie szuka³ funkcji <CODE>extern</CODE> które nie s± inline
w bibliotekach z którymi twój program bêdzie linkowany !!!.
Innym sposobem jest zlinkowanie z bibliotekimi zawieraj±cymi wycofane
wersje tych funkcji.
<P>Assemblacja inline mo¿e zostaæ wy³±czona opcj± <CODE>-fno-asm</CODE>,
która ka¿e zaprzestaæ kompilatorowi dzia³ania gdy zostanie u¿yte rozszerzenie sk³adni o inline asm,
w przeciwnym wypadku wygeneruje wywo³anie funkcji zewnêtrznej o nazwie <CODE>asm()</CODE>,
która nie zostanie w³a¶ciwie rozwi±zana przez linker.
Opcja <CODE>-fasm</CODE> przywraca dzia³anie s³owa kluczowego <CODE>asm</CODE>.
<P>Bardziej ogólnie, dobrymi opcjami dla GCC na platformie x86 s±
<HR>
<PRE>
        gcc -O2 -fomit-frame-pointer -W -Wallpp
</PRE>
<HR>
<P><CODE>-O2</CODE> jest dobrym poziomem optymalizacji w wiêkszo¶ci przypadków.
<P>Optymalizacja ponadto zajmuje wiêcej czasu, otrzymuj±c kod który jest mocno d³u¿szy, ale tylko trochê szybszy;
taka optymalizacja mo¿e byæ u¿yteczna tylko dla ciasnych pêtli (je¶li takie s±),
któr± mo¿esz jakkolwiek zrealizowaæ w assemblerze.
W przypadkach gdy koniecznie potrzebujesz silnej optymalizacji ze strony kompilatora dla kilku plików, rozwa¿ u¿ycie <CODE>-O6</CODE>.
<P><CODE>-fomit-frame-pointer</CODE> pozwala generowaæ kod omijaj±cy g³upie
zarz±dzanie ramk± wska¼ników, co daje mniejszy i szybszy kod,
i zwalnia rejestry do dalszych optymalizacji.
Wyklucza to ³atwe u¿ycie narzêdzi odpluskwiaj±cych (<CODE>gdb</CODE>),
ale kiedy chcesz ich u¿yæ, nie martw siê o rozmiar i prêdko¶æ kodu.
<P><CODE>-W -Wall</CODE> w³±cza generowanie wszytkich ostrze¿eñ i pomaga wychwyciæ
g³upie b³êdy.
<P>Mo¿esz dodaæ specyficzne dla danego procecora <CODE>-m486</CODE> lub inne flagi tak, ¿e
GCC wyprodukuje kod bardziej zaadaptowany dla danego komputera.
Zauwa¿, ¿e EGCS (i chyba GCC 2.8) maj± <CODE>-mpentium</CODE> i tego typu flagi,
podczas gdy GCC 2.7.x i starsze wersje nie.
Niez³y wybór flag specyfikuj±cych procesor powinien byæ w j±drze Linux-a.
Sprawd¼ dokumentacjê texinfo o zainstalowanej u ciebie wersji GCC.
<P><CODE>-m386</CODE> pomo¿e zoptymalizowaæ wielko¶æ,
a tak¿e prêdko¶æ na komputerach gdzie pamiêæ jest w pe³ni wykorzystana,
odk±d wielkie programy s± przyczyn± wymiany pamiêci,
jakakolwiek "optymalizacja" jest sensowna dla wiêkszego kodu.
Przy takich ustawieniach, mo¿e byæ pomocne przestanie korzystania z C, 
i w zamian skorzystanie z jêzyka u³atwiaj±cego kod faktoryzuj±cy (przyp.t³um.)
taki jak funkcjonalny jêzyk i/lub FORTH;
i u¿ywaæ implementacji bazuj±cej na wykorzystaniu bajtów i s³ów.
<P>Zapamiêtaj, ¿e mo¿esz u¿ywaæ ro¿nych flag dla ró¿nych plików,
wiêc u¿ywaj maksymalnej optymalizacji tam, gdzie program wykonuje siê najd³u¿ej,
podczas gdy pozosta³e pliki optymalizuj pod wzglêdem rozmiaru.
<P>Do optymalizacji mo¿e byæ pomocna opcja <CODE>-mregparm=2</CODE>
i/lub koresponduj±ce atrybuty funkcji,
ale mog± stwarzaæ wiele problemów podczas linkowania obcego kodu, 
<EM>w³±czaj±æ w to libc</EM>.
S± sposoby by w³a¶ciwie zadeklarowaæ u¿ycie obcych funkcji,
tak, ¿e zostan± wygenerowane w³a¶ciwe wywo³ania,
lecz mo¿esz byæ zmuszony rekompilowaæ obce biblioteki tak,
by u¿ywa³y takich samych konwencji wywo³añ opartych na rejestrach...
<P>Zapamiêtaj, ¿e mo¿esz ustawiæ te flagi jako domy¶lne edytuj±c plik
<CODE>/usr/lib/gcc-lib/i486-linux/2.7.2.3/specs</CODE>
lub gdziekolwiek on jest w twoim systemie (lepiej nie dodawaj tam -Wall).
Dok³adn± lokalizacjê plików specyfikatorów GCC w <EM>twoim</EM> systemie
mo¿esz uzyskaæ wo³aj±æ <CODE>gcc -v</CODE>.
<P>
<H2>3.2 GAS</H2>

<P>GAS jest GNU Assemblerem, na którym opiera siê GCC.
<P>
<H3>Gdzie go znale¼æ</H3>

<P>Znajdziesz go w tym samym miejscu gdzie GCC,
w paczce o nazwie binutils.
<P>
<H3>Jaka jest sk³adnia AT&amp;T </H3>

<P>W zwi±zku z tym, ¿e GAS zosta³ pomy¶lany by wspieraæ 32-bitowe kompilatory unixowe
u¿ywa on standardowej sk³adni ``AT&amp;T'',
która sk³adni± mocno przypomina standardowe assemblery m68k,
i jest standardem w ¶wiecie UNIX-a.
Sk³adnia nie jest ani gorsza, ani lepsza ni¿ sk³adnia ``Intel-owska''.
Jest po prostu inna.
Kiedy bêdziesz zamierza³ u¿ywaæ jej,
zauwa¿ysz bardziej regularna sk³adniê ni¿ w Intel-u,
chocia¿ trochê nudniejsz±. 
<P>Oto najwa¿niejsze ostrze¿enia odno¶nie sk³adni GAS:
<UL>
<LI>Nazwy rejestrów s± poprzedzone <CODE>%</CODE>, wiêc
wygl±d rejestrów <CODE>%eax</CODE>, <CODE>%dl</CODE> itd
zamiast tylko <CODE>eax</CODE>, <CODE>dl</CODE>, itd.
Dziêki temu mo¿liwe jest w³±czanie zewnêtrznych symboli w C bezpo¶rednio
w kodzie assemblera, bez zamieszania i konieczno¶ci 
stosowania okropnych podkre¶leñ jako przedrostków.
</LI>
<LI>Kolejno¶æ operandów jest nastêpuj±ca: pierwsze ¼ród³o, ostatnie przeznaczenie,
w przeciwieñstwie do konwencji intel-a, gdzie pierwsze jest przeznaczenie,
a ostatnie ¼ród³o.
Odt±d, to co w sk³adni intel-a jest <CODE>mov ax,dx</CODE> (wstaw rejestr
<CODE>dx</CODE> w rejestr <CODE>ax</CODE> w sk³adni att bêdzie wygl±da³o nastêpuj±co:
<CODE>mov %dx, %ax</CODE>.</LI>
<LI>D³ugo¶æ operandu jest wyspecyfikowana przez przyrostek w nazwie instrukcji.
Przyrostkiem jest <CODE>b</CODE> dla (8-bitów) bajtu,
<CODE>w</CODE> dla (16-bitów) s³owa, 
i <CODE>l</CODE> dla (32-bitów) podwójnego s³owa.

Na przyk³ad, w³a¶ciw± sk³adni± powy¿szej instrukcji 
bêdzie <CODE>movw %dx,%ax</CODE>.
Jakkolwiek, gas nie wymaga ¶cis³ej sk³adni att,
wiêc przyrostek jest opcjonalny, kiedy d³ugo¶æ operandu mo¿e byæ wywnioskowana z 
rejestrów, w przeciwnym przypadku, domy¶lnie zostanie wstawiony 32-bitowy operand (z ostrze¿eniem).
</LI>
<LI>Wymuszaj±ce operandy zaznaczone s± przyrostkami <CODE>$</CODE>,
tak jak w <CODE>addl $5,%eax</CODE>
(dodaj wymuszaj±ce long dla warto¶æ 5 do rejestru <CODE>%eax</CODE>).
</LI>
<LI>Brak przedrostka w operandzie wskazuje, ¿e jest to adres w pamiêci;
st±d <CODE>movl $foo,%eax</CODE>
wstawia zawarto¶æ <EM>adresu</EM> zmiennej <CODE>foo</CODE> w rejestr <CODE>%eax</CODE>,
ale <CODE>movl foo,%eax</CODE>
wstawia <EM>zawarto¶æ</EM> zmiennej <CODE>foo</CODE> w rejestr <CODE>%eax</CODE>.
</LI>
<LI>Indeksacja lub wskazanie po¶rednie jest realizowane przez umieszczenie 
rejestru indeksowego lub wskazania po¶redniego (komórki wskazania
po¶redniego) w nawiasach,
np <CODE>testb $0x80,17(%ebp)</CODE>
(sprawdza najstarszy bit bajtu o offsecie 17
z komórki wskazanej przez <CODE>%ebp</CODE>). </LI>
</UL>
<P>Istnieje program pomagaj±cy w konwersji programów
ze sk³adni TASM do sk³adni AT&amp;T. Zobacz
<P>
<A HREF="ftp://x2ftp.oulu.fi/pub/msdos/programming/convert/ta2asv08.zip">ftp://x2ftp.oulu.fi/pub/msdos/programming/convert/ta2asv08.zip</A><P>GAS ma obszern± dokumentacjê w formacie TeXinfo,
któr± mo¿na znale¼æ co najmniej w dystrybucji ¼ród³owej.
Przegl±d wyci±gniêtych stron .info z Emacs-a lub innych programów.
Zdarza³y siê pliki o nazwach gas.doc lub as.doc
gdzie¶ w pakietach ¼ród³owych GAS, ale zosta³y w³±czone w dokumentacje TeXinfo.
Oczywi¶cie, w razie w±tpliwo¶ci, alternatywn± dokumentacj±
s± same ¼ród³a!
Sekcj±, która szczególnie ciê zainteresuje to
<CODE>Machine Dependencies::i386-Dependent::</CODE>
<P>Znowu, ¼ród³a Linux-a (j±dra systemu), s± dobrymi przyk³adami;
zobacz w linux/arch/i386, nastêpuj±ce pliki:
<CODE>kernel/*.S, boot/compressed/*.S, mathemu/*.S</CODE>
<P>Je¶li piszesz jaki¶ jêzyk, pakiet obs³ugi w±tków, itd.
mo¿esz obejrzeæ jak inne jêzyki (OCaml, gforth, itd.),
lub pakiety obs³ugi w±tków (QuickThreads, MIT pthreads, LinuxThreads, itd),
lub cokolwiek, zrób to.
<P>Na koñcu, po prostu skompiluj program w C do assemblera
dziêki czemu zobaczysz interesuj±c± ciê sk³adniê.
Zobacz sekcjê 
<A HREF="#doyouneedasm">Czy potrzebujê Assemblacji?</A>.
<P>
<H3>Ograniczony tryb 16-bitowy</H3>

<P>GAS jest 32-bitowym assemblerem, zadaniem którego jest wspomóc 32-bitowy kompilator.
Aktualnie ma on jedno ograniczenie 16-bitowego trybu,
który zawiera niedokoñczone u¿ycie 32-bitowych przedrostków do instrukcji,
tak wiêc piszesz 32-bitowy kod, który chodzi w 16-bitowym trybie na 32 bitowym procesorze.
W obu trybach, wspiera on 16-bitowe u¿ywanie rejestrów,
ale nie wspiera 16-bitowego adresowania.
U¿ycie dyrektywy <CODE>.code16</CODE> and <CODE>.code32</CODE> prze³±cza pomiêdzy trybami.
Zapamiêtaj, ¿e dyrektywa inline assembly
<CODE>asm(&quot;.code16\n&quot;)</CODE>
pozwoli GCC wygenerowaæ 32-bitowy kod, który uruchomi siê w trybie rzeczywistym!
<P>Stwierdzi³em ju¿, ¿e wiêksza czê¶æ kodu potrzebnego do pe³nego wspomagania
16-bitowego trybu programowania zosta³a dodana do GAS przez Bryan'a Ford'a (proszê o potwierdzenie?),
ale ostatecznie, nie pojawi³a siê w ¿adnej dystrybucji któr± sprawdzi³em,
a¿ do binutils-2.8.1.x ... wiêcej informacji na ten temat bêdzie mile widziane.
<P>Cienkim rozwi±zaniem jest definiowanie makr (patrz poni¿ej), które produkuja
kod binarny (z <CODE>.byte</CODE>) który potrzebujesz tylko dla 16-bitowych instrukcji
(prawie ¿adnych je¶li u¿yjesz code16 jak powy¿ej,
i mo¿esz spokojnie za³o¿yæ, ¿e kod bêdzie dzia³a³ na zgodnych 32-bitowych procesorach x86).
By znale¼æ w³a¶ciwe kodowanie, mo¿esz zainspirowaæ siê
¼ród³ami 16-bitowych assemblerami.
<P>
<H2>3.3 GASP</H2>

<P>GASP jest Preprocesorem GAS.
Dodaje makra i trochê milsz± sk³adniê do GAS.
<P>
<H3>Gdzie znale¼æ GASP</H3>

<P>GASP jest zawarty razem z GAS w archiwum GNU binutils. 
<P>
<H3>Jak to dzia³a</H3>

<P>Dzia³a jako filtr, w stylu cpp i jemu podobnym.
Nie pamiêtam szczegó³ów, ale przychodzi on z w³asn± dokumentacj± w texinfo,
wiêc przejrzyj j± (w .info), wydrukuj, prze¶led¼ (?).
GAS z GASP-em wed³ug mnie jest typowym makro-assemblerem.
<P>
<P>
<H2>3.4 NASM</H2>

<P>Projekt Netwide Assembler wypuszcza jeszcze jeden assembler,
napisany w C, który powinien byæ do¶æ modelowy
do ewentualnego wsparcia znanych sk³adni i formatów obiektów.
<P>
<H3>Gdzie znale¼æ NASM</H3>

<P>
<A HREF="http://www.cryogen.com/Nasm">http://www.cryogen.com/Nasm</A><P>Wersja binarna jest na kopii sunsite w 
<CODE>devel/lang/asm/</CODE>
Powinna byæ tak¿e dostêpna jako .rpm lub .deb w dystrybucjach RedHat/Debian
w dystrybucyjnym contrib.
<P>
<H3>Co to robi</H3>

<P>W momencie pisania tego HOWTO, wersja NASM to 0.97.
<P>Sk³adnia jest w stylu Intel-a.
Czê¶æ makroprocesora jest zintegrowana.
<P>Wspierane formaty plików obiektowych to 
<CODE>bin</CODE>, <CODE>aout</CODE>, <CODE>coff</CODE>, <CODE>elf</CODE>, <CODE>as86</CODE>,
(DOS) <CODE>obj</CODE>, <CODE>win32</CODE>, (ich w³asny format) <CODE>rdf</CODE>.
<P>NASM mo¿e byæ u¿ywany jako wspomaganie dla wolnego kompilatora LCC
(pliki wspieraj±ce s± zawarte).
<P>NASM rozwija siê zbyt szybko by to HOWTO by³o aktualne.
Je¿eli nie u¿ywasz BCC jako 16-bitowego kompilatora
(który wykracza poza to 32-bitowe HOWTO),
powiniene¶ u¿ywaæ NASM zamiast powiedzmy AS86 lub MASM,
poniewa¿ jest mocno wspierany online
i chodzi na wszystkich platformach.
<P>Uwaga: NASM przychodzi tak¿e z disassemblerem, NDISASM.
<P>Jego rêcznie napisany parser powoduje, ¿e pracuje szybciej ni¿ GAS,
chocia¿ oczywi¶cie nie wspiera trzech bilionów ró¿nych architektur.
Do x86, on powienien byæ assemblerem wyboru...
<P>
<H2>3.5 AS86</H2>

<P>AS86 jest 80x86 16- i 32-bitowym assemblerem i jest czê¶ci±
kompilatora jêzyka C (BCC) Bruce'a Evans'a. 
Ma on g³ównie sk³adniê Intel-owsk±,
chocia¿ ró¿ni siê nieznacznie np w trybach adresowania.
<P>
<H3>Gdzie dostaæ AS86</H3>

<P>Ca³kowicie przestarza³a wersja AS86 jest dystrybuowana przez HJLu
tylko do kompilacji j±dra Linux-a,
w pakiecie o nazwie bin86 (aktualna wersja 0.4),
dostêpnej w dowolnym magazynie oprogramowania GCC dla Linux-a.
<P>Ale nie radzê nikomu u¿ywania go do czegokolwiek innego ni¿ przekompilowania Linux-a.
Ta wersja wspiera tylko plik obiektowy hacked minix, 
który nie jest wspierany przez GNU binutils ani nic innego,
i ma parê b³êdów w trybie 32-bitowym,
wiêc powieniene¶ lepiej trzymaæ go tylko do kompilacji Linux-a. 
<P>Ostatnie wersje Bruce'a Evans'a (bde@zeta.org.au)
s± publikowane wraz z dystrybucj± FreeBSD.
No, by³y: Nie mogê znale¼æ ¼róde³ z dystrybucji 2.1 na :(
Odt±d, wk³adam ¼ród³a w moim miejscu:
<P>
<A HREF="http:///www.tunes.org/~fare/files/bcc-95.3.12.src.tgz">http:///www.tunes.org/~fare/files/bcc-95.3.12.src.tgz</A><P>Projekt Linux/8086 (aka ELKS) jest w pewnym stopniu pozosta³o¶ci± bcc
(chocia¿ nie s±dze by zawiera³ 32-bitowe ³aty).
Obejrzyj
<A HREF="http://www.linux.org.uk/Linux8086.html">http://www.linux.org.uk/Linux8086.html</A>
<A HREF="ftp://linux.mit.edu/">ftp://linux.mit.edu/</A>.
<P>Miêdzy innymi, ostatnie wersje, w przeciwieñstwie do HJLu's,
wspieraj± Linux-owy format GNU a.out,
wiêc mo¿esz linkowaæ twój kod z programami Linux-owymi, i/lub u¿ywaæ zwyk³ych
narzêdzi z pakietu GNU binutil do manipulacji danymi.
Ta wersja mo¿e ko-egzystowaæ bez szkody z poprzedni± wersj± 
(zobacz poni¿sze pytanie).
<P>BCC z 12 marca 1995 roku i wcze¶niejsze jego wersje maj± brak sk³adnika jakim
jest odk³adanie/pobieranie ze stosu rejestrów segmentowych jako 16-bitowych,
co jest uci±¿liwe gdy programujesz w trybie 32-bitowym.
£ata jest opublikowana w projekcie Tunes
<A HREF="http://www.tunes.org/">http://www.tunes.org/</A>
podstrona
<CODE>files/tgz/tunes.0.0.0.25.src.tgz</CODE>
w rozpakowanym katalogu
<CODE>LLL/i386/</CODE>
£ata powinna byæ tak¿e dostêpna bezpo¶rednio z 
<A HREF="http://www.tunes.org/~fare/files/as86.bcc.patch.gz">http://www.tunes.org/~fare/files/as86.bcc.patch.gz</A>
Bruce Evans zaakceptowa³ tê ³atê, wiêc je¶li którego¶ dnia pojawi siê
nowa wersja bcc, powinna zawieraæ tê ³atê...
<P>
<H3>Jak wywo³aæ assembler?</H3>

<P>
<P>Oto wpis GNU Makefile do u¿ywania bcc
do transformacji <CODE>.s</CODE> asm
w oba GNU a.out <CODE>.o</CODE> obiekt
i <CODE>.l</CODE> listing:
<P>
<HR>
<PRE>
%.o %.l:        %.s
        bcc -3 -G -c -A-d -A-l -A$*.l -o $*.o $&lt;
</PRE>
<HR>
<P>Usuñ <CODE>%.l</CODE>, <CODE>-A-l</CODE>, and <CODE>-A$*.l</CODE>,
je¶li nie chcesz listingu.
Je¶li chcesz czego¶ wiêcej ni¿ GNU a.out, 
mo¿esz przejrzeæ dokumentacjê bcc o wspieranych formatach, 
i/lub u¿yæ objcopy z pakietu GNU binutils.
<P>
<P>
<H3>Gdzie znale¼æ dokumentacje</H3>

<P>Dokumentacje które s±, zawieraj± siê w pakiecie bcc.
Podrêczniki s± tak¿e dostêpne gdzie¶ pod adresem FreeBSD.
Kiedy masz w±tpliwo¶ci, ¼ród³a same w sobie s± czêsto dobr± dokumentacj±:
to nie jest zbyt dobrze komentowane, ale styl programowania jest zrozumia³y. 
Mo¿esz spróbowaæ obejrzeæ jak as86 jest u¿ywany w Tunes 0.0.0.25...
<P>
<P>
<H3>Co je¶li nie mogê ju¿ skompilowaæ Linux-a z now± wersj± ?</H3>

<P>Linus jest zasypywany listami i moja ³ata kompiluj±ca Linux-a
z Linuxowym a.out as86 chyba do niego nie dotar³a (!) (od t³um. trudno to przet³umaczyæ - proszê o poprawki).
Teraz, nie powinno to mieæ znaczenia: trzymaj tylko as86 z pakietu bin86 
w /usr/bin i daj zainstalowaæ bcc dobry as86 w
/usr/local/libexec/i386/bcc/as
gdzie powinien byæ. Nie bêdziesz nigdy wo³a³ wprost tego ``dobrego'' as86,
poniewa¿ bcc robi wszystko w³a¶ciwie, w³±czaj±c konwersjê to Linux-owego a.out,
gdy jest wywo³any z w³a¶ciwymi opcjami;
wiêc assembluj pliki wy³±cznie z bcc jako g³ownym assemblerem, nie bezpo¶rednio z as86.
<P>
<P>
<H2>3.6 INNE ASSEMBLERY</H2>

<P>To s± inne, nieregularne, opcje,
w przypadku, gdy powy¿sze ciê niesatysfakcjonowa³y (dlaczego?),
których nie zalecam w przypadku u¿ytkowania (?),
ale mogê udowodniæ u¿yteczno¶æ je¶li assembler musi byæ zintegrowany
w oprogramowaniu które rozwijasz (np. OS lub aplikacje rozwojowe).
<P>
<P>
<H3>Win32Forth assembler</H3>

<P>Win32Forth jest <EM>wolnym</EM> 32-bitowym systemem ANS FORTH
który dzia³a pod Win32s, Win95, Win/NT.
Zawiera wolny 32-bitowy assembler (zawiera przed/przyrostkow± sk³adniê)
zintegrowany w jêzyku FORTH.
Przetwarzanie makr jest przez
pe³n± moc jêzyka FORTH;
jakkolwiek, jedynym wspieranym wej¶cia i wyj¶cia jest Win32For
(¿adnego zrzutu do plików .obj -- mo¿esz oczywi¶cie dodaæ to samemu).
Znajdziesz to na 
<A HREF="ftp://ftp.forth.org/pub/Forth/win32for/">ftp://ftp.forth.org/pub/Forth/win32for/</A><P>
<P>
<H3>Terse</H3>

<P>Terse jest narzêdziem programowania dostarczaj±cym
<EM>NAJBARDZIEJ</EM> zwart± sk³adnie assemblera
dla rodziny x86!
Zobacz 
<A HREF="http://www.terse.com">http://www.terse.com</A>.
Mówiono, ¿e jest gdzie¶ jaki¶ wolny klon 
który zosta³ porzucony po pustych pretensjach, ¿e sk³adnia
powinna byæ w³asno¶ci± autora;
i zapraszam ciê do przejêcia tego,
je¶li taka sk³adnia ciê interesuje.
<P>
<P>
<H3>Nie-wolne i/lub Nie-32bitowe x86 assemblery.</H3>

<P>Mo¿esz znale¼æ wiêcej o nich,
wraz z podstawami programowania w assemblerze x86
w FAQ Raymond'a Moon'a dla comp.lang.asm.x86
<A HREF="http://www2.dgsys.com/~raymoon/faq/asmfaq.zip">http://www2.dgsys.com/~raymoon/faq/asmfaq.zip</A><P>Zapamiêtaj, ¿e wszystkie bazujace na DOS-ie assemblery powinny pracowaæ w Linuxowym emulatorze DOS-u
tak dobrze jak inne podobne emulatory, wiêc je¶li ju¿ masz jaki¶
mo¿esz go nadal u¿ywaæ w prawdziwym OS.
Ostatnie assemblery bazuj±ce na DOS-ie tak¿e wspieraj± COFF i/lub inne formaty 
plików obiektowych, które s± wspierane przez bibliotekê GNU BFD,
wiêc mo¿esz u¿ywaæ ich razem z wolnymi 32-bitowymi wolnymi narzêdziami,
byæ mo¿e u¿ywaj±æ GNU objcopy (czê¶æ binutils) jako filtr konwertuj±cy.
<P>
<P>
<H2><A NAME="s4">4. METAPROGRAMOWANIE/MAKROPRZETWARZANIE</A></H2>

<P>Assemblacja programów jest nudna,
ale do krytycznych czê¶ci programów.
<P>Powiniene¶ u¿ywaæ w³a¶ciwego narzêdzia do w³a¶ciwego zadania,
wiêc nie wybieraj assemblacji kiedy nie jest stosowna;
C, OCAML, perl, Scheme, mog± byæ lepszym wyborem dla wiêkszo¶ci
twojego programowania.
<P>Jakkolwiek, s± wypadki gdy te narzêdzia nie daj± ci 
wystarczaj±cej kontroli nad maszyn±, i assemblacja jest wtedy u¿yteczna i konieczna.
W takich wypadkach, docenisz system makroprzetwarzania i metaprogramowania
które pozwol± ci wracaæ do raz przygotowanych wzorców z których
ka¿dy z nich jest przygotowany jako wielokrotna definicja,
co pozwala bezpiecznie programowaæ i automatycznie przechodziæ modyfikacjê takich wzorców itd.
"Go³y" assembler jest czêsto niewystarczaj±cy,
nawet je¶li chcesz robiæ tylko ma³e operacje w po³±czeniu z C.
<P>
<H2>4.1 Co jest zintegrowane w powy¿szym</H2>

<P>Tak, wiem ¿e ta sekcja nie zawiera u¿ytecznych informacji.
Masz swobodê do prowadzenia jej, je¶li odkryjesz co¶ ciekawego...
<P>
<P>
<H3>GCC</H3>

<P>GCC pozwala (i wymaga) wyspecyfikowaæ ograniczenia rejestrów
w twoim kodzie ``inline assembly'', wiêc optymalizer zawsze wie o tym.
W ten sposób, assemblacja kodu inline jest tak naprawdê realizowana przez wzorce,
a nie wymuszana. 
<P>Pó¼niej mo¿esz umie¶ciæ twój kod assemblera w makrach CPP,
i funkcjach inline w C,
wiêc ka¿dy mo¿e u¿yæ go jako funkcje w C lub makro.
<P>Funcje inline s± bardzo podobne do makr, ale s± czasami czystsze w u¿yciu.
Strze¿ siê tych wypadków, kod bêdzie zduplikowany,
tak wiêc tylko lokalne etykiety (w stylu <CODE>1:</CODE>) powinny byæ definiowane w kodzie assemblera.
Jakkolwiek, makro powinno pozwoliæ nazwie dla nie lokalnej etykiety
byæ przekazan± jako parametr (lub inaczej, powinienes u¿ywaæ dodatkowych
meta-programowych metod).
Zapamiêtaj tak¿e, ¿e rozej¶cie siê kodu jako inline assemblera bêdzie potencjalnie rozprowadza³ nim b³êdy, 
wiêc uwa¿aj dok³adnie w kwestii ograniczeñ rejestu w kodzie inline asm.
<P>Ostatecznie, jêzyk C w sobie mo¿e byæ rozwa¿any jako dobra abstrakcja 
programowania w assemblerze,
co przyniesie ci ulgê z wiêkszo¶ci± k³opotów z assemblacj±.
<P>Strze¿ siê pewnych optymalizacji które zawile przekazuj± argumenty do funkcji;
przez rejestry mog± powodowaæ niedopasowanie tych funkcji do wywo³añ 
z zewnêtrznych (w szczególno¶ci rêcznie napisanego kodu assemblera) funkcji
w standardowy sposób; atrybut "asmlinkage" mo¿e chroniæ 
funkcjê przed k³opotami z tak± flag± optymalizacyjn±;
obejrzyj ¼ród³a j±dra linux-a dla przyk³adów.
<P>
<H3>GAS</H3>

<P>GAS ma mo¿liwo¶æ w³±czania pewnych makr, jak opisano w dokumentacji texinfo.
Oprócz tego, podczas gdy GCC rozpoznaje pliki .s jako surowy assembler do wys³ania do GAS,
tak¿e rozpoznaje pliki .S jako pliki do przepuszczenia przez CPP przed
wpuszczeniem ich do GAS.
Znowu, znowu, zobacz ¼ród³a Linux-a dla przyk³adów.
<P>
<P>
<H3>GASP</H3>

<P>Dodaje wszelkie u¿yteczne dodatki makroassemblacji do GAS.
Obejrzyj jego dokumentacjê texinfo.
<P>
<P>
<H3>NASM</H3>

<P>NASM tak¿e zawiera pewne wsparcie makr.
Zobacz dokumentacjê.
Je¶li masz jakie¶ dobre pomys³y,
mo¿esz chcieæ skontaktowaæ siê z autorami,
jako, ¿e oni aktywnie go rozwijaj±.
W miêdzyczasie, zobacz poni¿ej zewnêtrzne filtry.
<P>
<P>
<H3>AS86</H3>

<P>On tak¿e ma trochê prostego wsparcia makrami, ale nie mog³em nigdzie znale¼æ dokumentacji.
Teraz ¼ród³a s± bardzo przejrzyste,
wiêc je¶li jeste¶ zainteresowany, ³atwo powieniene¶ je zrozumieæ.
Je¶li potrzebujesz wiêcej ni¿ tylko bazê, powiniene¶ u¿yæ zewnêtrznego filtra
(zobacz poni¿ej).
<P>
<P>
<H3>INNE ASSEMBLERY</H3>

<P>
<UL>
<LI>Win32FORTH:
CODE i END-CODE s± normalne wiêc nie prze³±czaj ich z trybu interpretacji
to trybu kompilacji, bêdziesz mia³ wtedy dostêp do ca³ej mocy FORTH
podczas assemblacji.</LI>
<LI>TUNES:
nie dzia³a jeszcze, ale jêzyk Scheme jest prawdziwym wysokopoziomowym jêzykiem
który pozwala na meta-programowanie.</LI>
</UL>
<P>
<P>
<H2>4.2 Zewnêtrzne Filtry</H2>

<P>Jakiekolwiek jest wsparcie makr twojego assemblera,
lub jakikolwiek jêzyk u¿ywasz (nawet C !),
je¶li jêzyk nie jest dla ciebie wystarczaj±co wyrazisty,
mo¿esz chcieæ przepu¶ciæ pliki przez zewnêtrzny filtr
z regu³ami w Makefile takimi jak te:
<P>
<HR>
<PRE>
%.s:    %.S other_dependencies
        $(FILTER) $(FILTER_OPTIONS) &lt; $&lt; > $@
</PRE>
<HR>
<P>
<P>
<H3>CPP</H3>

<P>CPP nie jest bardzo wyrazisty, ale wystarczaj±cy do wielu ³atwych rzeczy,
jest standardem, i jest przezroczy¶cie wywo³ywany przez GCC.
<P>Dla przyk³adu jego ograniczeñ, nie mo¿esz deklarowaæ obiektów, takich ¿e
destruktory wywo³ywane automatycznie na koñcu deklarowanego bloku;
nie mo¿esz wiêc zmieniaæ kierunki widoczno¶ci, itd. 
<P>CPP przychodzi wraz z kompilatorem C. Je¶li móg³by¶ robiæ to bez niego,
nie zawracaj sobie g³owy przynoszeniem CPP (chocia¿ my¶lê jakby¶ móg³).
<P>
<P>
<H3>M4</H3>

<P>M4 daje ci pe³n± moc makroprzetwarzania, 
z jêzykiem równym Turingowi, rekursj±, wyra¿eniami regularnymi, itd.
Mo¿esz robiæ wszystko czego CPP nie.
<P>Zobacz macro4th/This4th z
<A HREF="ftp://ftp.forth.org/pub/Forth/">ftp://ftp.forth.org/pub/Forth/</A> in Reviewed/ ANS/ (?),
lub ¼ród³a Tunes 0.0.0.25 jako przyk³ady 
zaawansowanego makroprogramowania z u¿yciem m4.
<P>Jakkolwiek, jego niefunkcjonalna semantyka cytowania i odcytowywania zmusza ciê do u¿ywania
jawnego ogonkowo-kontynuacyjno-przej¶ciowego (przyp. t³um.) stylu makr je¶li
chcesz robiæ <EM>zaawansowane</EM> makro programowanie
(czego przypomnieniem jest TeX -- BTW, czy kto¶ próbowa³ u¿ywaæ TeX-a jako
makroprocesora do czego¶ innego ni¿ typesetting ?)
To NIE jest gorsze ni¿ CPP, który nie pozwala na cytowanie i rekursjê.
<P>W³a¶ciw± wersj± m4 jest GNU m4 1.4 (lub pó¼niejsza je¶li istnieje)
która zawiera wiêkszo¶æ sk³adników i mniej b³êdów lub ograniczeñ.
m4 zosta³ pomy¶lany jakko wolny do czegokolwiek ale prosty w u¿yciu,
mo¿e byæ wiêc nadal dobry dla wiêkszo¶ci programów w assemblerze
(chyba nie piszesz programów z milionami linii w assemblerze?).
<P>
<P>
<H3>Makroprzetwarzanie z twoim w³asnym filtrem</H3>

<P>Mo¿esz pisaæ twój w³asny prosty filtr rozszerzaj±cy makra
z u¿yciem zwyk³ych narzêdzi: perl, awk, sed, itd.
To jest szybki sposób i mo¿esz wszystko kontrolowaæ.
Ale oczywi¶cie, moc makroprzetwarzania musi co¶ kosztowaæ.
<P>
<P>
<H3>Metaprogramowanie</H3>

<P>Zamiast u¿ywania zewnêtrznych filtrów które rozszerzaj± makra, 
jedn± z dróg jest pisanie programów, które pisz± czê¶æ
lub ca³o¶æ innych programów.
<P>Dla przyk³adu, móg³by¶ u¿yæ programu produkuj±cego kod ¼ród³owy
<UL>
<LI>do generowania tablic sinus/cosinus/cokolwiek,</LI>
<LI>do wyci±gania reprezentacji ¼ród³owej pliku binarnego,</LI>
<LI>do kompilacji bitmap w szybkie funkcje wy¶wietlaj±ce,</LI>
<LI>do wyci±gania dokumentacji, kodu pocz±tkowego/koñcowego,
tablic opisowych, tak dobrze jak normalnego kodu z samych plików ¼ród³owych,</LI>
<LI>do zwyk³ego kodu assemblera, generowanego ze skryptów perl/shell/scheme
które robi przetwarzanie,</LI>
<LI>do rozchodzenia danych zdefiniowanych w jednym punkcie
w ró¿ne krzy¿owe wg odwo³añ tablice i nag³ówki.</LI>
<LI>itd.</LI>
</UL>

Pomy¶l o tym!
<P>
<P>
<H3>Czê¶æ wspomagaj±ca z dostêpnych kompilatorów</H3>

<P>Kompilatory takie jak SML/NJ, Objective CAML, MIT-Scheme, itd,
maj± w³asn± czê¶æ wspomagaj±c± assembler,
któr± mo¿esz ale nie musisz wykorzystywaæ,
je¶li zamierzasz generowaæ kod pó³automatycznie
z wymienionych jêzyków.
<P>
<P>
<H3>Zestaw narzêdzi Machine-Code z New-Jersey</H3>

<P>Jest projekt, u¿ywaj±cy jêzyka programowania Icon,
do budowy podstawowych rzeczy do produkcji manipulacji na kodzie assemblera.
Zobacz
<A HREF="http://www.cs.virginia.edu/~nr/toolkit/">http://www.cs.virginia.edu/~nr/toolkit/</A><P>
<P>
<H3>Tunes</H3>

<P>Projekt Tunes OS rozwija swój w³asny assembler
jako rozszerzenie jêzyka Scheme i 
jako czê¶æ procesu rozwojowego.
Nie dzia³a to jeszcze, ale pomoc jest widziana.
<P>Assembler manipuluje symbolicznymi drzewami sk³adni,
wiêc mo¿esz prawie mieæ podstawê do translacji sk³adni assemblera, 
disassembler, wspóln± czê¶æ wspomagaj±c± assembler/kompilator, itd.
Tak¿e, pe³na moc jêzyka Scheme
czyni go nie do pokonania z makroprzetwarzaniem/metaprogramowaniem.
<P>
<A HREF="http://www.tunes.org/">http://www.tunes.org/</A><P>
<P>
<H2><A NAME="s5">5. KONWENCJE WYWO£AÑ</A></H2>

<P>
<P>
<P>
<H2>5.1 Linux</H2>

<P>
<P>
<H3>Po³±czenie z GCC</H3>

<P>To jest preferowany sposób.
Sprawd¼ dokumentacjê i przyk³ady GCC z plików <CODE>.S</CODE> j±dra Linux-a
które s± przepuszczane przez gas (nie takie, które s± przepuszczane przez as86).
<P>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. 
<CODE>%ebp</CODE>, <CODE>%esi</CODE>,
<CODE>%edi</CODE>, <CODE>%ebx</CODE> s± zapamiêtywane, 
inne rejestry te¿ s± zapamiêtywane podczas wywo³ania;
<CODE>%eax</CODE> jest u¿ywany do przechowywania wyniku,
a <CODE>%edx:%eax</CODE> do przechowywania wyników 64-bitowych.
<P>FP stack: Nie jestem pewien,
ale my¶lê ¿e wynik jest w <CODE>st(0)</CODE>, ca³y stos jest zapamiêtany.
<P>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.
<P>Pamiêtaj, ¿e musisz zadeklarowaæ atrybut <CODE>cdecl</CODE>
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ê:
<CODE>C Extensions::Extended Asm::</CODE>
<P>
<P>
<P>
<H3>ELF kontra a.out - problemy</H3>

<P>Pewne kompilatory poprzedaj± podkre¶leniem ka¿dy symbol,
podczas gdy inne nie.
<P>W szczególno¶ci, Linux-owy GCC a.out ma takie poprzedniki,
podczas gdy Linux-owy ELF GCC nie.
<P>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...
<P>Mo¿esz tak¿e nadpisaæ niejawnie C<CODE>-&gt;</CODE>asm zmieniaj±c nazwê
przez wstawienie wyra¿eñ takich jak to
<HR>
<PRE>
        void foo asm(&quot;bar&quot;) (void);
</PRE>
<HR>

by upewniæ siê, ¿e wywo³anie funkcji C foo bêdzie zabronione w assemblerze.
<P>Zapamiêtaj, ¿e program <CODE>objcopy</CODE>, z pakietu <CODE>binutils</CODE>,
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.
<P>
<P>
<H3>Bezpo¶rednie wywo³ania systemowe Linux-a</H3>

<P>To <EM>NIE</EM> 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 <CODE>zlibc</CODE>,
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.
<P>Obiekty dzielone powinny trzymaæ twoje programy ma³ymi.
I je¶li naprawdê chcesz mniejszych binariów, u¿ywaj <CODE>#!</CODE> ,
z interpretera maj±cego nad sob± wszystko czego nie chcesz w swoich
binariach.
<P>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± ?
<P>Mo¿esz zerkn±æ tak¿e jak mój
<A HREF="ftp://ftp.forth.org/pub/Forth/Compilers/native/unix/Linux/linux-eforth-1.0c.tgz">eforth 1.0c</A>
robi to.
<P>¬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  <CODE>int $0x80</CODE>
z <CODE>__NR_</CODE>numerem funkcji systemowej (z <CODE>asm/unistd.h</CODE>)
w <CODE>%eax</CODE>,
i parametrami (do piêciu) w 
<CODE>%ebx</CODE>, <CODE>%ecx</CODE>, <CODE>%edx</CODE>,
<CODE>%esi</CODE>, <CODE>%edi</CODE>.
Rezultat jest zwracany w <CODE>%eax</CODE> 
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.
<P>
<P>
<H3>I/O pod Linux-em</H3>

<P>Je¶li chcesz korzystaæ bezpo¶rednio z I/O pod Linux-em
jest co¶ prostego co nie uzale¿nia od OS,
i powiniene¶ obejrzeæ  <CODE>IO-Port-Programming</CODE> 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.
<P>W szczególno¶ci, je¶li chcesz zaj±æ siê programowaniem Grafiki
przy³±cz siê do projektu GGI:
<A HREF="http://www.ggi-projectorg/">http://www.ggi-projectorg/</A><P>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.
<P>
<P>
<H3>Dostêp do 16-bitowych sterowników z Linux-a/i386</H3>

<P>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 
<A HREF="ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/">DOSEMU repository</A>),
oraz ¼ród³a ró¿nych niskopoziomowych programów dzia³aj±cych pod Linux-em...
(byæ mo¿e GGI je¶li wspiera standard VESA).
<P>Zasadniczo, musisz u¿ywaæ 16-bitowego trybu chronionego lub trybu vm86.
<P>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>Pó¼niej pozwala siê na wiêksz± zgodno¶æ z vanilla 16-bitowym otoczeniem (? przyp.t³um.),
ale wymaga to bardziej skomplikowanej manipulacji.
<P>W obu przypadkach, przed wykonaniem skoku do 16-bitowego kodu 
musisz
<UL>
<LI>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,</LI>
<LI>ustawiæ LDT i/lub monitor trybu vm86.</LI>
<LI>pobraæ w³a¶ciwe prawa dostêpu do I/O z j±dra (patrz powy¿sza sekcja)</LI>
</UL>

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.
<P>
<P>
<H2>5.2 DOS</H2>

<P>Wiêkszo¶æ DOS-owych extenderów zawiera interfejs do us³ug DOS-a.
Poczytaj dokumentacje na ich temat,
ale czêsto, symuluj± one tylko <CODE>int $0x21</CODE> 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).
<P>Dokumentacja na temat DPMI i inne (oraz znacznie wiêcej) mo¿esz znale¼æ na 
<A HREF="ftp://x2ftp.oulu.fi/pub/msdos/programming/">ftp://x2ftp.oulu.fi/pub/msdos/programming/</A><P>DJGPP przychodzi z w³asn± (ograniczon±) glibc pochodn±/podzestawem/wymienion±, tak¿e.
<P>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.
<P>Inne dokumenty i FAQ s± bardziej skoncentrowane na DOS-ie.
Nie zalecamy rozwoju pod DOS.
<P>
<P>
<H2>5.3 Winwybuchy i takie</H2>

<P>(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!
<P>No, po tym wszystkim, jest :
<A HREF="http://www.cygnus.com">Cygnus Solutions</A>
rozwijaj±cy bibliotekê cygwin32.dll,
dla programów GNU to uruchomienia pod platformami MakroGówna.
<P>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...
<P>
<P>
<H2>5.4 Twój w³asny OS</H2>

<P>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æ
<A HREF="http://ww.cs.utah.edu/projects/flux/">Flux OS kit</A>
(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.
<P>To HOWTO nie zawiera wewn±trz tematów takich jak
kod Boot loadera &amp; 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:
<A HREF="http://www.tunes.org/~tunes/doc/Review/OSes.html">http://www.tunes.org/~tunes/doc/Review/OSes.html</A><P>
<P>
<H2><A NAME="s6">6. DO ZROBIENIA &amp; WSKAZANIA</A></H2>

<P>
<P>
<UL>
<LI>wype³niæ niekompletne sekcje</LI>
<LI>dodaæ wiêcej wska¼ników na oprogramowanie i dokumentacjê</LI>
<LI>dodaæ proste przyk³ady z ¿ycia do zilustrowania sk³adni, mocy,
i ograniczeñ proponowanych rozwi±zañ.</LI>
<LI>poprosiæ ludzi o pomoc w tym HOWTO</LI>
<LI>znale¼æ kogo¶ kto ma czas by przej±æ zarz±dzanie tym HOWTO</LI>
<LI>byæ mo¿e napisaæ parê s³ów o assemblacji na innych platformach?
</LI>
<LI>Trochê wskazañ (dodatkowo oprócz tych ju¿ wymienionych w tym HOWTO)
<UL>
<LI>
<A HREF="http://www.intel.com/design/pentium/manuals/">podrêczniki pentium</A></LI>
<LI>
<A HREF="http://www.xs4all.nl/~feldmann">b³êdy cpu w rodzinie x86</A></LI>
<LI>
<A HREF="http://www.eng.ufl.edu/ftp">hornet.eng.ufl.edu dla koderów w assemblerze</A></LI>
<LI>
<A HREF="ftp://ftp.luth.se/pub/msdos/demos/code/">ftp.luth.se</A></LI>
<LI>
<A HREF="ftp://zfja-gate.fuw.edu.pl/cpu/protect.mod">PM FAQ</A></LI>
<LI>
<A HREF="http://www.fys.ruu.nl/~faber/Amain.html">Strona Assemblera 80x86</A></LI>
<LI>
<A HREF="http://www.cit.ac.nz/smac/csware.htm">Courseware</A></LI>
<LI>
<A HREF="http://www.ee.ucl.ac.uk/~phart/gameprog.html">programowanie gier</A></LI>
<LI>
<A HREF="http://bewoner.dma.be/JanW">eksperymenty z programowaniem w linux-ie w tylko-asm</A></LI>
</UL>
</LI>
<LI>I oczywi¶cie, u¿ywaæ twoich zwyk³ych Internetowych Narzêdzi Przeszukiwañ
by znale¼æ wiêcej informacji,
i daæ mi znaæ je¶li znajdziesz co¶ interesuj±cego!</LI>
</UL>
<P>
<P>Author's .sig:
<PRE>
## Faré | VN: Ð£ng-Vû Bân   | Join the TUNES project!  http://www.tunes.org/ ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&amp;Cybernethics  | Project for a Free Reflective Computing System ##
</PRE>
<P>
<H2><A NAME="s7">7. Od t³umacza</A></H2>

<P> To jest pierwsze t³umaczenie tego HOWTO. Z pewno¶ci± zawiera ono masê b³êdów
i niektóre sentencje mog± mieæ inne znaczenie ni¿ ja im nada³em. Dlatego proszê o email je¶li znajdziesz jakie¶ b³êdy (merytoryczne, gramatyczne i inne). 
Postaram siê poprawiæ dokument w jak najkrótszym czasie i opublikowaæ. 
Uwagi i komentarze ¶lij na 
<A HREF="mailto:wegorz@bydgoszcz.pkobp.pl">Zbigniew Micha³ Kempczyñski</A>. Szczególne podziêkowania sk³adam mojej kole¿ance <EM>Annie Dzieniszewskiej</EM> za pomoc w trudnych gramatycznych kawa³kach tego tekstu.
Je¶li kto¶ wie jak przet³umaczyæ <EM>Legal Blurp</EM> to proszê o email.
<P>
</BODY>
</HTML>
doc-linux-pl-html 2002.06.14-3 / usr / share / doc / HOWTO / pl-html / Assembly-HOWTO.pl.html
