Piszę w asemblerze, bo...

69ELEKTRONIKA PRAKTYCZNA 2/2009 C vs. Assembler Jestem pewnie jednym z nielicznych pro- gramistów (jeśli można tak dumnie nazwać twórców oprogramowania dla mikrokontrole- rów 8-bitowych), którzy nie używają języków wysokiego poziomu, w tym absolutnie obo- wiązującego każdego prawdziwego programi- stę języka C. Mimo drwiących uśmieszków kole- gów z sąsiednich biurek, ja z uporem maniaka pozostaję na poziomie zero-jedynkowym, ale czemuż miałbym to zmieniać, skoro jak dotąd nie natknąłem się na zagadnienie, którego bym nie rozwiązał używając asemblera. Programo- wanie na niskim poziomie, w tym przypadku oczywiście nie oznaczające programowania kiepskiego, pozwala mi wycisnąć ?siódme poty? z każdego mikrokontrolera, panować nad każ- dą mikrosekundą wykonywanego kodu. Moje czoło, wbrew podejrzeniom programistów wy- sokopoziomowych, pozostaje przy tym suche, co świadczy o umiarkowanym co najwyżej wy- siłku wkładanym w pisanie programów. Przeciwnicy asemblera wielokrotnie wyra- żali swoją wątpliwość, czy jako autor progra- mu, już w tydzień po jego napisaniu wiem, co dany jego fragment robi. Ja jednak jestem go- tów założyć się, że więcej będę wiedział o swo- im programie asemblerowym, niż oni o swoich programach napisanych w C. Wynika to przede wszystkim z konsekwentnie umieszczanych przeze mnie komentarzy, nawet we fragmen- tach o pozornie oczywistym przeznaczeniu. Piszący w języku C, wierząc w przejrzystość tego języka nie zawsze tak robią, działając na swoją zgubę. Próba ?rozgryzienia? programu bez komentarzy kończy się często konieczno- ścią długiej jego analizy. Nie chodzi tu nawet o zastosowany algorytm, już same deklaracje zmiennych wymagają niekiedy głębokiego za- stanowienia. Jak na ironię przyczyną jest jeden z najmocniejszych mechanizmów języka C, jakim są nawiasy i klamry. Dzięki nim można w jednej linii programu zapisać nawet bardzo skomplikowaną operację, ale można też nieźle się pogubić. Ciekawe ilu C-programistów pora- dzi sobie bez zaglądania do książek, co na przy- kład zadeklarowano w linii: int (*(*zmienna)[5][10])(unsigned char); Nie wspomnę już o tym, ilu z nich potra? podać, jakie wartości osiągną wszystkie zmien- ne po wykonaniu poniższego fragmentu pro- gramu (nie, nie, proszę nie uruchamiać debu- gera, najpierw analizujemy ?na piechotę?): int x=1,y=2,z; z=(x,x-=y,y=x+=1-y,x--); Powyższe przykłady nie należą do najbar- dziej wymyślnych, mogę nawet powiedzieć, że to najprostsze zadania, jakie przyszły mi na myśl. Oczywiście zdaję sobie sprawę z tego, że podobną piłeczkę mogą odbić programiści wysokopoziomowi, ale przepychanka nie ma tu większego sensu. Asembler to swojego rodzaju informa- tyczny swahili ? język (jeśli w ogóle zasługuje na taką nazwę) bardzo prymitywny, ale jak na ironię, to właśnie ta cecha decyduje o jego po- tędze. Istnieją zresztą elementy upodabniające asembler do języka wysokiego poziomu, takie na przykład jak makra. Dzisiaj asemblery w naj- prostszej postaci praktycznie nie występują, a każdy programista używa makroasemble- rów. Pewną niewygodą ? tu muszę się zgodzić z moimi adwersarzami ? jest różnorodność mnemoników dla poszczególnych mikrokon- trolerów/mikroprocesorów. Do dziś wspomi- nam łatwość pisania programów dla mikropro- cesora Z80, wyśmiewana już trochę w dobie AVR-ów i ARM-ów ?51-ka też jest miła w ob- słudze. Gdy zabieram się do programowania nowego mikrokontrolera, muszę najpierw do- kładnie przestudiować jego listę rozkazów, try- by adresowania itd., itd. Obowiązek ten ? nie zawsze najmilszy, bo lektura datasheet?ów nie jest specjalnie porywająca ? daje w efekcie wszechstronną znajomość układu, nad którym będę pracował. Programiści używający języków wysokiego poziomu często z tego etapu sami zwalniają się (czy dobrze robią?), wszak krecią robotę wykona za nich kompilator. Znam przy- padki, w których autorzy programów nie mają zielonego pojęcia o tym, jak działa użyty przez nich mikrokontroler, co to jest system przerwań, jak pracuje UART. Hmm, liczy się efekt końcowy. To fakt, ale osobiście miałbym moralnego kaca, gdyby przyszło mi tak pisać programy. A propos efektu końcowego: dyskusja na temat tego, czy dysponując współczesnymi mi- krokontrolerami warto pozostawać przy asem- blerze jest jednak trochę jałowa. Z grubsza ten sam rezultat można bowiem osiągnąć zarówno pisząc w asemblerze, jak i w języku C. Może to wymagać w jednym przypadku nieco dłuższe- go czasu opracowania projektu, w drugim zaś może się wiązać z koniecznością sięgnięcia po bardziej wydajny mikrokontroler. Skutki ?nan- sowe są trudne do przewidzenia przy podejmo- waniu tematu. Można je oszacować po zakoń- czeniu projektu i wdrożeniu go do produkcji. Broniąc swojej pozycji uważam, że być może mój kod wynikowy, mniejszy o kilka bajtów od kodu wytworzonego przez kompilator języka wysokiego poziomu, pozwoli na zastosowanie układu z mniejszą pamięcią. Zaoszczędzone w ten sposób centy przełożone na tysiące wy- produkowanych egzemplarzy urządzenia dadzą wymierną korzyść w postaci tysięcy dolarów. Chyba warto. Jestem jednak osobą ugodową, skłonną na kompromisy i dlatego uważam, że nie ma wcale wojny między asemblerowcami i C-programistami. Współczesne urządzenia są często tworzone nie przez jednego autora, ale przez całe zespoły. W takim zespole na pew- no znajdzie się miejsce dla kogoś, kto będzie odpowiedzialny za krytyczne czasowo funkcje programu, albo zajdzie konieczność optymali- zacji programu pod względem wielkości kodu wynikowego (tu człowiek jest nadal ponad naj- lepszymi kompilatorami). Myślę, że używając tylko asemblera o miejsce pracy nie muszę się martwić. assemblerowiec Piszę w asemblerze, bo... R E K L A M A Motor Control Bezpłatne szkolenie dla inżynierów odbędzie się w dniach 24 i 25.02.2009 w Krakowie. Szkolenie będzie poświęcone przede wszystkim nowoczesnej metodzie sterowania pracą silników elektrycznych Field Oriented Control (FOC), realizowanej na mikrokontrolerach z rodziny STM32 (rdzeń ARM Cortex M3). W programie przewidziano ćwiczenia praktyczne! Plan szkolenia jest dostępny na stronie internetowej www.ep.com.pl Zgłoszenia są przyjmowane: stm.warsaw@st.com, tel. 022 529 05 29 Motor Control