główna strona  Asembler
wielka
ściema
 
Jeśli spotkasz na swej drodze kogoś, kto na pytanie "jaki znasz język programowania" odpowie "asembler", nie wierz mu. Po prostu nie ma takiego języka.
jak to nie ma?
A tak to. Słowo asembler oznacza program tłumaczący teksty zapisane w języku asemblera na kod maszynowy. Zazwyczaj mówiąc "asembler" delikwent ma na myśli "język asemblera", który to zwrot i tak nie oznacza żadnego konkretnego języka, lecz raczej klasę formalizmów służących do zapisu kodu maszynowego procesorów w postaci symbolicznej, czytelnej dla człowieka. A ponieważ istnieje wiele różnych procesorów, istnieje też wiele różnych asemblerów i aby być precyzyjnym, powinno się raczej mówić "znam asembler komputera IBM 360" albo "znam asembler maszyny CDC 6000" itd. Nawiasem mówiąc ten ostatni nazywa się oficjalnie COMPASS i w ten sposób unika wszelkich niejednoznaczności związanych z nadużywanym słowem asembler. Porównaj: Asembler.
Dziś wielu mówi "asembler", a myśli o języku procesorów 8086, co wydaje się żenującym przykładem zawężania horyzontów. Nastąpiło interesujące socjologicznie przejście od wyobrażenia "nasze jest najlepsze" do "nasze jest jedyne". Na dodatek pomimo ciągłego wzbogacania możliwości w kolejnych wersjach procesorów, zmiany te opornie się przenoszą na oprogramowanie, bo dopóki wciąż istnieją starsze komputery, staramy się zapewnić działanie na nich także nowego oprogramowania. Nowe możliwości procesorów są więc wykorzystywane z dużą nieśmiałością. To stanowi istotny hamulec w rozwoju programowania asemblerowego.
W znacznie mniejszym stopniu ten problem dotyka kompilatorów języków wysokiego poziomu, które zgrabnie dostosowują tworzony kod do możliwości docelowego procesora bez potrzeby zmieniania czegokolwiek w źródłowym tekście programu.
moje asemblerowe fascynacje
Zaczęło się z początkiem lat 80 od asemblera maszyny IBM 360. W rzeczywistości był to radziecko-rodzimej produkcji komputer RIAD, nie tylko programowo zgodny z pierwowzorem, lecz nawet przewyższający go pod względem nowoczesności konstrukcji oraz mocy obliczeniowej. Wszyscy używali wtedy asemblera aby uzyskać przyzwoitą prędkość działania programów. Przy szybkościach liczonych w setkach tysięcy elementarnych operacji na sekundę było to naprawdę ambitne wyzwanie. Napisałem wówczas szereg zaawansowanych aplikacji działających w czasie rzeczywistym na zdalnym terminalu, między innymi symulator mikrokomputera z procesorem 6502. Prosty, napisany dla zabawy, interpreter rozkazów maszynowych został wkrótce wzbogacony o asembler, disasembler i debuger, pozwalając na łatwe wprowadzanie programów i śledzenie rejestrów i pamięci na żywo podczas działania programu. Później straciłem kontakt z maszynami RIAD i dziś nie wiem czy gdzieś jeszcze takowe działają. Przez wiele lat taszczyłem ze sobą wszędzie wielkie kręgi taśm zawierających cały ówczesny dorobek, lecz w końcu gdzieś przepadły podczas jednej z mych licznych przeprowadzek.
Z początkiem lat 90 oddałem się bez reszty programowaniu Atari 800XL oraz działalności popularyzatorskiej związanej z tym komputerem. Ta niewielka maszynka zauroczyła mnie niespodziewanie dużymi możliwościami, ma zresztą po dziś dzień spory krąg zagorzałych fanów. W tym czasie posługiwałem się równolegle komputerami PC z kultowym Turbo Pascalem i Turbo C Borlanda i bardzo brakowało mi podobnie wygodnych narzędzi dla Atari. Stworzyłem więc od podstaw szybki, wydajny asembler wraz z pełnoekranowym systemem edycyjno-uruchomieniowym typu IDE, wzorowanym na ww. narzędziach Borlanda (wcześniejsze prace nad symulatorem mikrokomputera okazały się w tym bardzo pomocne). Produkt ten spotkał się z bardzo życzliwym przyjęciem wśród użytkowników i stał się wkrótce niezwykle popularny za sprawą wsparcia ze strony miesięcznika Tajemnice Atari, gdzie publikowano liczne przykłady, porady i wskazówki. Porównaj: QA.
W początkach mojego zainteresowania komputerami PC dużo pisałem w języku asemblera, wierząc że wyciskam optymalną wydajność z niezbyt szybkich wtedy maszyn. Powstały kunsztowne biblioteki do wyświetlania "okienek" w DOS-owym trybie znakowym i tym podobnych głupot. Zaistniały jak fajerwerki, zabłysły i zgasły. DOS odszedł do lamusa, procesory zmieniły się tyle razy, że trudno to zliczyć, przynosząc coraz większe prędkości i coraz bogatsze zestawy rozkazów. Niełatwo nadążyć za tymi zmianami, a zostając w tyle, stajemy się hamulcem zamiast motorem postępu. Optymalizacja traci na znaczeniu wobec drastycznego wzrostu szybkości działania komputerów. Asembler stał się przeżytkiem.
za, a nawet przeciw
Pokutuje jeszcze gdzieniegdzie przekonanie, że język asemblera jest najefektywniejszy. W rzeczywistości przeważnie tak nie jest. Kiepski programista ma dużo więcej okazji do spartolenia programu asemblerowego, niż gdy posługuje się np. Pascalem czy C. Biblioteki funkcji w językach wysokiego poziomu były optymalizowane przez pokolenia wybitnych fachowców, stosujących nierzadko metody i sztuczki, na które trudno wpaść z marszu przeciętnie zdolnemu programiście. Przykładowo, nawet tak proste zadanie jak skopiowanie ciągu bajtów z jednego miejsca w drugie, prawie zawsze będzie szybsze w funkcji bibliotecznej w C niż zrealizowane na piechotę w języku asemblera. Dlaczego? Bo najprostszą myślą jest przesyłanie w pętli, bajt po bajcie. Bardziej doświadczeni przypomną sobie, że jest rozkaz blokowego kopiowania bajtów. Niektórzy z nich przyspieszą rzecz przez kopiowanie blokowe całych słów, co jednak wymaga poradzenia sobie z dopasowaniem do granicy słowa i może być mniej efektywne w szczególnych przypadkach. Zapewne tylko nieliczni pomyślą, że można rozdzielić zadanie pomiędzy większą liczbę procesorów/rdzeni. Współczesne kompilatory optymalizujące główkują za nas w takich przypadkach i przeważnie wybierają lepiej niż niezły nawet asemblerowiec. Żeby było jasne: nie podważam Twoich umiejętności, kolego. Ale w dzisiejszych czasach, gdy często najważniejszym kryterium oceny programu jest termin oddania go do użytku, zwykle lepsze efekty daje skupienie się na elegancji interfejsu użytkownika niż na optymalizacji kodu, a możliwość zrzucenia tego ostatniego na kompilator wydaje się najlepszym rozwiązaniem.
Czy warto więc się uczyć języka asemblera? Adeptom powiem: zdecydowanie nie. Takim dinozaurom, jak ja, czasem się ta wiedza przydaje do oceny skuteczności optymalizacji dokonywanych przez kompilatory, przy poszukiwaniu usterek w wadliwie działających programach, przy analizie kodu wirusów... Przyznam jednak, że coraz rzadziej korzystam z tych umiejętności. Można powiedzieć, że odwróciłem się plecami do asemblera. Dlatego w tej części wspomnień nie będzie błyskotliwych przykładów ;-)
 
opiekun: Janusz Wiśniewski :: rejestracja odwiedzin 2115 gości
mobi