Piszę w języku C, bo...

Piszę w języku C, bo...
Pobierz PDF Download icon
68 ELEKTRONIKA PRAKTYCZNA 2/2009 NOTATNIK KONSTRUKTORA Języki programowania pisane dla ?dużych? komputerów posiadają naleciałości środowiska, dla którego są przeznaczone w związku z tym, że pracują pod kontrolą konkretnego systemu operacyjnego, z wykorzystaniem konkretnych bibliotek. W ?małych? mikrokontrolerach jest inaczej. Brak systemu operacyjnego (w więk- szości prostych aplikacji programiści tworzą namiastkę własnego OS) jest powodem, dla którego wszystkie kompilatory, bez względu na język programowania, są w stanie wyproduko- wać prawie taki sam kod wynikowy. Może ina- czej ? gdyby pisała je ta sama ?rma, lub osoba, to kod wynikowy powstający po kompilacji przy pomocy języków Pascal, Basic i C będzie bardzo podobny. Wynika z tego bardzo dobra infor- macja: nie ma znaczenia, czy program powstaje w Basicu, C, czy Pascalu ? liczą się umiejętności! Owszem, przy pomocy asemblera można wyko- nać najmniejszy i działający najbardziej spraw- nie kod wynikowy, ale czy każdy jest w stanie to zrobić? Czy nie jest nadmiernym brakiem skrom- ności twierdzenie, że jest się lepszym od całego zespołu programistów pracujących nad kom- pilatorem języka C? Albo z innej strony. Oso- biście dla większości aplikacji wybieram język C, ale nie stronię od różnych Basic?ów i Visual Composer?ów, jeśli aplikacja jest prosta i chcę ją zrobić szybko. Moim zdaniem C ma najwięcej zalet i daje największą swobodę programiście. Nie zawsze jest to cecha dobra, ponieważ czę- stokroć nadmiar swobody, idący w parze z bra- kiem doświadczenia lub po prostu niewiedzą, jest niebezpieczeństwem dla aplikacji. Niestety, jeszcze większą swobodę programowania daje każdemu asembler. Zaczynałem swoją praktykę programowa- nia od asemblera. We wczesnych latach porów- nywałem kod napisany w asemblerze z tym tworzonym przez kompilator. Często uśmiecha- łem się przy tym sam do siebie, utwierdzając się w przekonaniu, że jestem lepszy. Tak, to praw- da ? kod wynikowy tworzony przeze mnie był mniejszy, ale czas potrzebny na jego napisanie i uruchomienie był znacznie dłuższy, niż dla programów napisanych w języku wysokiego poziomu. Wówczas jednak nie miałem jeszcze tej świadomości. To fakt, że większość kompi- latorów była wtedy typu ?command line?, że kosztowały koszmarnie wielkie kwoty pienię- dzy, a do tego były niezbyt wygodne w użyciu, że nie mieliśmy do dyspozycji pamięci więk- szych, niż 2 kB, ale czasy się zmieniły, a wraz z nimi odszedł tamten sposób myślenia. Teraz tak naprawdę liczy się to, ile jest się w stanie wyprodukować i w jakim czasie. Decydującym kryterium jest tzw. time to market. I obojętnie co będą twierdzić zwolennicy programowania w asemblerze, to właśnie kompilatory języków wysokiego poziomu pozwalają na maksymalne skrócenie czasu od pomysłu do realizacji. Dziś większość programów piszę w języ- ku C, czasami robię wstawki w asemblerze, i to tylko dla krytycznych czasowo procedur ob- sługi, i tylko wówczas, gdy naprawdę muszę. Z reguły unikam jednak nawet tego, ponieważ niepotrzebne używanie asemblera robi program nieczytelnym. Jednym zdaniem: staram się tak pisać program, aby w całości był w C. Krótki czas potrzebny na napisanie aplikacji jest moim zdaniem znacznie ważniejszym czynnikiem, ani- żeli niewielki kod wynikowy. Przy dzisiejszych cenach mikrokontrolerów i układów pamię- ci kto dba o to, czy program zajmuje 4, czy 16 kB? Dopóki mieści się w pamięci procesora i dobrze wykonuje swoje zadanie, to wielkość zajmowanej przezeń pamięci nie ma absolutnie żadnego znaczenia. Ponadto uważam, że po- czątkujący programista nie mający zbyt dużego doświadczenia w programowaniu, np. o pół- rocznym stażu, niekoniecznie napisze program w asemblerze, którego kod wynikowy będzie mniejszy niż ten utworzony przez kompilator języka wysokiego poziomu. Moim zdaniem, o czym już wspomniałem wcześniej, używanie jako jedynego kryterium ilości zajmowanej pa- mięci, jest w dzisiejszych czasach trywializmem i zupełnie nie ma sensu. Kod programu nie powinien być jak najmniejszy, a efektywnie realizować powierzone mu zadania i powi- nien powstać w jak najkrótszym czasie. Niektóre osoby twierdzą, że pisząc w asem- blerze czują się jak ?Neo chwytający kule?, co też moim zdaniem nie jest tak do końca praw- dą. Łatwo jest mówić w ten sposób, gdy pisze się dla jednego typu procesora (np. z rdzeniem 8051), ale co zrobić, gdy ten sam algorytm trze- ba przenieść na inny typ mikrokontrolera, z in- nym rdzeniem? Wówczas pisząc w asemblerze trzeba usiąść i na nowo napisać praktycznie cały program, bo nowy procesor, to nowe tryby adresowania, inne rozkazy, często inne nazwy rejestrów i struktura logiczna CPU. Tak napraw- dę liczy się efektywny algorytm, a nie ?chwy- tanie kul?! Asembler to tylko narzędzie i to do tego narzędzie bardzo trudne w użyciu, mało elastyczne i przez to wymagające mnóstwa czasu. Kiepski programista będzie miał tak pro- blemy w asemblerze, jak i w każdym innym języku programowania. Owszem, wielu programistów w świecie mikrokontrolerów może czuć się jak Neo, jednak liczba osób, które pisząc programy może konku- rować z producentami kompilatorów zmniejsza się wraz z kolejną generacją mikrokontrolerów pojawiających się na rynku. A kto wie, co wy- darzy się za 10 lat? Prawdopodobnie w syste- mach embedded pojawią się rdzenie mikrokon- trolerów o zmiennej liczbie cykli maszynowych potrzebnych na realizację instrukcji, zależnie od tego, w jakiej lokalizacji pamięci umieszczone są dane oraz jaka jest historia ich użycia (np. dla danych umieszczonych w pamięci cache). Wówczas bardzo trudno będzie wyznaczyć np. liczbę cykli w obsłudze przerwania, przewidzieć czas realizacji procedury i panować nad tym, co robi CPU procesora. Jednocześnie wzrośnie szybkość pracy procesorów i to, czy obsługa przerwania będzie napisana w asemblerze, czy w języku wysokiego poziomu, przestanie mieć znaczenie. Już dziś można kupić popularną 51- -kę taktowaną zegarem 100 MHz (sic!) o cyklu maszynowym równym cyklowi zegarowemu. A przecież nie można założyć, że na tym postęp w dziedzinie mikrokontrolerów się zakończy. A co z procesorami o zmiennych listach in- strukcji? W takim procesorze można wgrywać zestawy instrukcji najlepiej dopasowane do realizacji konkretnego zadania. Jak wówczas poradzi sobie programista piszący w asemble- rze? Kompilator języka wysokiego poziomu sam może wgrać odpowiednie zestawy instrukcji, wybrać je optymalnie. Oczywiście może to też zrobić programista, ale znowuż pojawia się za- gadnienie jego umiejętności. Jeśli program będzie spełniał stawiane przed nim wymagania, to czy ma to znaczenie w jakim języku jest napisany? A skoro na na- pisanie i uruchomienie programu w języku C potrzeba znacznie mniej czasu, niż na równo- ważny w asemblerze, to czy wysiłek ma sens? Moim zdaniem asembler trzeba poznać, ponieważ jest to język programowania sprzętu, na którym będzie się pracować. Nic lepiej nie uczy zasad działania, niż asembler, ale pisanie w nim całych programów nie ma sensu. Dla mnie na dziś dzień jest to język ?wstawek?, konieczny do użycia tylko w skrajnych przypad- kach. Jest też językiem dobrym (być może) do pisania niewielkich, amatorskich programów. To, że program napisany w języku C będzie po- trzebował np. o 300% więcej pamięci, nie jest już w dzisiejszych czasach problemem. Za to czas od pomysłu do uruchomienia i co najważ- niejsze ? sprzedaży, będzie o wiele krótszy. Na dodatek łatwo jest przekazać program komuś innemu, wytłumaczyć jak działa. Struktura jest czytelna i zrozumiała. Osobiście bardzo cenię też programistów, którzy mają wystarczającą wiedzę i wybierają najlepsze narzędzie do roz- wiązania konkretnego problemu, nie kierując się uprzedzeniami typu ?Basic jest zły, a asembler to najlepszy język programowania?, a nie piszą programy o najmniejszym kodzie wynikowym. Wysokopoziomowiec Piszę w języku C, bo...
Artykuł ukazał się w
Luty 2009
DO POBRANIA
Pobierz PDF Download icon

Elektronika Praktyczna Plus lipiec - grudzień 2012

Elektronika Praktyczna Plus

Monograficzne wydania specjalne

Elektronik marzec 2021

Elektronik

Magazyn elektroniki profesjonalnej

Raspberry Pi 2015

Raspberry Pi

Wykorzystaj wszystkie możliwości wyjątkowego minikomputera

Świat Radio marzec 2021

Świat Radio

Magazyn krótkofalowców i amatorów CB

Automatyka Podzespoły Aplikacje marzec 2021

Automatyka Podzespoły Aplikacje

Technika i rynek systemów automatyki

Elektronika Praktyczna marzec 2021

Elektronika Praktyczna

Międzynarodowy magazyn elektroników konstruktorów

Praktyczny Kurs Elektroniki 2018

Praktyczny Kurs Elektroniki

24 pasjonujące projekty elektroniczne

Elektronika dla Wszystkich kwiecień 2021

Elektronika dla Wszystkich

Interesująca elektronika dla pasjonatów