   #Start Contents

   Jak pisac programy w jezyku asembler?

Wstep

   Pewnie wiele osob sposrod Was slyszalo juz o tym, "jaki ten asembler
   jest straszny". Ale te opinie mozecie juz smialo wyrzucic do Kosza
   (uzytkownicy Linuksa moga skorzystac z /dev/null), gdyz przyszla pora
   na przeczytanie tego oto dokumentu.
     _________________________________________________________________

   Na poczatek, przyjrzyjmy sie niewatpliwym zaletom jezyka asembler:
   (przeskocz zalety)
    1. Maly rozmiar kodu.
       Tego nie przebije zaden kompilator zadnego innego jezyka.
       Dlaczego? Oto kilka powodow:
          + Jako programista jezyka asembler ("asma") wiesz co i gdzie w
            danej chwili sie znajduje. Nie musisz ciagle przeladowywac
            zmiennych, co zabiera i miejsce, i czas. Mozesz eliminowac
            instrukcje, ktore sa po prostu zbedne.
          + Do Twojego pieknego kodu nie sa dolaczane zadne biblioteki z
            dziesiatkami procedur, podczas gdy Ty uzywasz tylko jednej z
            nich. Co za marnotrawstwo!
          + Jako znawca zestawu instrukcji wiesz, ktore z nich sa
            krotsze.
    2. Duza szybkosc dzialania.
       Znajac sztuczki optymalizacyjne, wiedzac, ktore instrukcje sa
       szybsze, eliminujac zbedne instrukcje z petli, otrzymujesz kod
       nierzadko dziesiatki razy szybszy od tych napisanych w jezykach
       wysokiego poziomu (high-level languages, HLLs). Nieprzebijalne.
    3. Wiedza.
       Nawet jesli nie piszesz duzo programow w asmie, zdobywasz wprost
       bezcenna wiedze o tym, jak naprawde dziala komputer i mozesz
       zobaczyc, jak marna czasem robote wykonuja kompilatory HLL-ow.
       Zrozumiesz, czym jest wskaznik i na czym polegaja czesto
       popelniane bledy z nim zwiazane.
    4. Mozliwosc tworzenia zmiennych o duzych rozmiarach, a nie
       ograniczonych do 4 czy 8 bajtow. W asemblerze zmienne moga miec
       dowolna liczbe bajtow.
    5. Wstawki asemblerowe.
       Jesli mimo to nie chcesz porzucic swojego ulubionego dotad HLLa,
       to w niektorych jezykach istnieje mozliwosc wstawiania kodu
       napisanego w asemblerze wprost do Twoich programow!

   Teraz przyszla kolej na     rzekome     argumenty przeciwko jezykowi
   asembler:
   (przeskocz wady)
    1. Nieprzenosnosc kodu miedzy roznymi maszynami.
       No coz, prawda. Ale i tak wiekszosc tego, co napisane dla
       procesorow Intela bedzie dzialalo na procesorach AMD i innych
       zgodnych z x86. I na odwrot.
       Nieprzenosnosc jest chyba najczesciej uzywanym argumentem
       przeciwko asemblerowi. Jest on zwykle stawiany przez programistow
       jezyka C, ktorzy po "udowodnieniu", jaki to jezyk C jest
       wspanialy, wracaja do pisania dokladnie w takim samym stopniu
       nie-przenosnych programow...
       Nie ukrywajmy: bez zmian kodu to tylko programy niewiele
       przewyzszajace "Witaj, swiecie" skompiluja sie i uruchomia pod
       roznymi systemami.
    2. "A nowoczesne kompilatory i tak produkuja najlepszy kod..."
       Nieprawda, i to z kilku powodow:
          + Kompilator uzywa zmiennych. No i co z tego, pytacie? A to, ze
            pamiec RAM (o dyskach itp. nie wspominajac) jest wiele, wiele
            razy wolniejsza niz pamiec procesora (czyli rejestry). Nawet
            pamiec podreczna (cache) jest sporo wolniejsza.
          + Kompilator nie wie, co sie znajduje na przyklad w danym
            rejestrze procesora, wiec pewnie wpisze tam te sama wartosc.
            Co innego z programista asma.
          + Kompilator nie jest w stanie przewidziec, co bedzie w danej
            chwili w innych rejestrach. Wiec do rejestru, ktory chce
            zmienic i tak wpisze jakas wartosc zamiast uzyc innego
            rejestru, co prawie zawsze byloby szybsze, a wiec i lepsze.
            Co innego zrobilby programista asma.
          + Kompilator moze uzywac dluzszych lub wolniejszych instrukcji.
          + Kompilator nie zawsze moze poprzestawiac instrukcje, aby
            uzyskac lepszy kod. Programista asma widzi, co sie w jego
            kodzie dzieje i moze wybrac inne, lepsze rozwiazanie (na
            przyklad zmniejszyc rozmiary petli czy pozbyc sie zaleznosci
            miedzy instrukcjami)
          + Kompilator moze nie byc swiadomy technologii zawartych w
            procesorze. Programista asma wie, jaki ma procesor i za darmo
            sciaga do niego pelna dokumentacje.
    3. Brak bibliotek standardowych.
       I znowu nieprawda. Istnieje co najmniej kilka takich. Zawieraja
       procedury wejscia, wyjscia, alokacji pamieci i wiele, wiele
       innych. Nawet sam taka jedna biblioteke napisalem...
    4. "Kod wyglada dziwniej. Jest bardziej abstrakcyjny."
       Dziwniej - tak, ale nie oszukujmy sie. To wlasnie jezyki wysokiego
       poziomu sa abstrakcyjne! Asembler przeciez operuje na tym, co
       fizycznie istnieje w procesorze - na jego wlasnych rejestrach przy
       uzyciu jego wlasnych instrukcji.
    5. Mniejsza czytelnosc kodu.
       Kod w jezyku C mozna tak napisac, ze nie zrozumie go nawet sam
       autor. Kod w asmie mozna tak napisac, ze kazdy go zrozumie.
       Wystarczy kilka slow wstepu i komentarze. W HLLach trzeba byloby
       wszystkie struktury objasniac.
       A wyglad i czytelnosc kodu zaleza tylko od tego, czy dany
       programista jest dobry, czy nie.
       Dobry programista asemblera nie bedzie mial wiekszych klopotow z
       odczytaniem kodu w asmie niz dobry programista C kodu napisanego w
       C.
    6. Brak latwych do zrozumienia instrukcji sterujacych (if, while,
       ...)
       Przeciez w procesorze nie ma nic takiego!
       Programista asma ma 2 wyjscia: albo uzywac prawdziwych instrukcji
       albo napisac wlasne makra, ktore takie instrukcje beda udawac (juz
       sa takie napisane). Ale nie ma nic uniwersalnego. Na jedna okazje
       mozna uzyc takich instrukcji, a na inna - innych. Jednak zawsze
       mozna wybrac najszybsza wersje wedlug wlasnego zdania, a nie
       wedlug zdania kompilatora.
       Asembler moze i nie jest z poczatku latwy do zrozumienia, ale
       wszystko przyjdzie wraz z doswiadczeniem.
    7. Trzeba pisac duzo kodu.
       No, tak. Jak sie komus mecza palce, to niech zostanie przy HLLach
       i zyje w swiecie abstrakcji. Prawdziwym programistom nie bedzie
       przeciez takie cos przeszkadzac!
       Mowi sie, ze ZLEJ baletnicy nawet rabek u sukni przeszkadza.
       Poza tym, programista nad samym pisaniem kodu spedza okolo 30%
       czasu przeznaczonego na program (reszta to plan wykonania,
       wdrazanie, utrzymanie, testowanie...). Nawet jesli programiscie
       asma zabiera to 2 razy wiecej czasu niz programiscie HLLa, to i
       tak zysk lub strata wynosi 15%.
       Duzo pisania sprawia, ze umysl sie uczy, zapamietuje skladnie
       instrukcji i nabiera doswiadczenia.
    8. Assmebler jest ciezki do nauki.
       Jak kazdy nowy jezyk. Nauka C lub innych podobnych przychodzi
       latwo, gdy juz sie zna na przyklad Pascala. Proba nauczenia sie
       innych "dziwnych" jezykow zajmie dluzej, niz nauka asma.
    9. Ciezko znajdowac i usuwac bledy.
       Na poczatku rownie ciezko, jak w innych jezykach. Pamietacie
       jeszcze usuwanie bledow ze swoich pierwszych programow w C czy
       Pascalu?
   10. Programy w asemblerze sa ciezkie w utrzymaniu.
       Znowu powiem to samo: podobnie jest w innych jezykach. Najlepiej
       dany program zna jego autor, co wcale nie oznacza, ze w
       przyszlosci bedzie dalej rozumial swoj kod (nawet napisany w
       jakims HLLu). Dlatego wazne sa komentarze. Zdolnosc do zajmowania
       sie programem w przyszlosci takze przychodzi wraz z
       doswiadczeniem.
   11. Nowoczesne komputery sa tak szybkie, ze i tak szybkosc nie robi to
       roznicy...
       Napiszmy program z czterema zagniezdzonymi petlami po 100
       powtorzen kazda. Razem 100 000 000 (sto milionow) powtorzen. Czas
       wykonania tego programu napisanego w jakims HLLu liczy sie w
       minutach, a czesto w dziesiatkach minut (czasem godzin - zalezy od
       tego, co jest w petlach). To samo zadanie napisane w asemblerze
       daje program, ktorego czas dzialania mozna liczyc w sekundach lub
       pojedynczych minutach!
       Po prostu najszybsze programy sa pisane w asemblerze. Czesto
       otrzymuje sie program 5-10 razy szybszy (lub jeszcze szybszy) niz
       ten w HLLu.
   12. Chcesz miec szybki program? Zmien algorytm, a nie jezyk
       A co jesli uzywasz juz najszybszego algorytmu a on i tak dziala za
       wolno?
       Kazdy algorytm zawsze mozna zapisac w asemblerze, co poprawi jego
       wydajnosc. Nie wszystko da sie zrobic w HLLu.
   13. Nowoczesne komputery i tak maja duzo pamieci. Po co wiec mniejsze
       programy?
       Wolisz miec 1 wolno dzialajacy program o rozmiarze 1 MB, napisany
       w HLLu i robic 1 czynnosc w danej chwili, czy moze wolisz
       wykonywac 10 czynnosci na raz dziesiecioma programami w asemblerze
       po 100kB kazdy (no, przesadzilem - rzadko ktory program w asmie
       siegnie az tak gigantycznych rozmiarow!)?

   To byl tylko wstep do bezkresnej wiedzy, jaka kazdy z Was zdobedzie.
   Ale nie myslcie, ze calkowicie odradzam Wam jezyki wysokiego poziomu.
   Ja po prostu polecam Wam asemblera.
   Najlepsze programy pisze sie w czystym asemblerze, co sprawia
   niesamowita radosc, ale mozna przeciez laczyc jezyki. Na przyklad,
   czesc programu odpowiedzialna za wczytywanie danych lub wyswietlanie
   wynikow mozna napisac w HLLu, a intensywne obliczeniowo petle pisac w
   asmie, albo robiac wstawki w kod, albo piszac w ogole oddzielne moduly
   i potem laczyc wszystko w calosc.
   Nauka tego wspanialego jezyka przyjdzie Wam latwiej, niz myslicie.
   Pomyslcie tez, co powiedza znajomi, gdy sie dowiedza, co umiecie!

   Spis tresci off-line (klawisz dostepu 1)
   Spis tresci on-line (klawisz dostepu 2)
   Ulatwienia dla niepelnosprawnych (klawisz dostepu 0)
