Odpowiedz 
 
Ocena wątku:
  • 0 Głosów - 0 Średnio
  • 1
  • 2
  • 3
  • 4
  • 5
Basic na pic-e, avr-y, arm-y
SP5FCS Offline
Adam
*****

Liczba postów: 1,071
Dołączył: 02-02-2009
Post: #4
RE: Basic na pic-e, avr-y, arm-y
(19-02-2012 23:26)SQ4AVS napisał(a):  I tutaj bardzo ważna uwaga ten basic daje np. bardziej optymalny kod wynikowy w większości zastosowań niż np. eclipse (język c), jakość kodu wynikowego nie zależy od zastosowanego języka a od jakości kompilatora.

Rafał, niestety problem jakości kodu jest bardziej złożony. Jakość kodu wynikowego zależy od:
- umiejętności i doświadczenia programisty;
- języka programowania;
- jakości użytego kompilatora oraz strategii kompilacji.

Przy złożonych projektach programista jest najważniejszy, jego doświadczenie oraz wiedza pozwala budować optymalne algorytmy i zwięzły kod programu. Brak wiedzy i doświadczenia skutkuje robieniem wszystkiego prostymi metodami "na piechotę". Przykład, procesory AVR mają sprzętowy I2C, SPI a część programistów stosuje obsługę programową (czas obsługi, wielkość kodu).

Istotnym czynnikiem decydującym o kodzie wynikowym jest język programowania. Dlaczego ?
Ponieważ możliwości poszczególnych języków są bardzo różne. Basic daje spore możliwości ale nie posiada wielu mechanizmów języka C (tablice wielowymiarowe, wskaźniki, struktury danych, unie, rekurencja, alokacja pamięci itd.) co przy rozbudowanych algorytmach decyduje o efektywności generowanego kodu. Powstawanie nowych języków programowania zawsze było związane z dodawaniem nowych możliwości poprawiających efektywność programowania.

Prawdą jest, że kompilator kompilatorowi nie jest równy co skutkuje jakością kodu wynikowego. Komercyjne kompilatory dedykowane na wybrany procesor zawsze będą bardziej optymalne od kompilatorów darmowych (prz. GCC vs. CodeVision na AVR). Porównywanie kodu wynikowego różnych języków jest już trudniejsze i nie zawsze jednoznaczne. Oczywiście może tak się zdarzyć, że marny kompilator C da przy prostych algorytmach kod gorszy niż Basic. Generalnie jednak przy tym samych umiejętnościach programisty najoptymalniejszy będzie kod w assemblerze potem w C a najsłabszy w Basicu. Proponuję napisać sobie prostą obsługę przerwania sprzętowego w poszczególnych językach i zobaczyć generowany kod wynikowy.

Ważnym czynnikiem jest strategia programisty: co jest ważniejsze szybkość pracy czy wielkość kodu wynikowego. Czasem programista świadomie rezygnuje z optymalizacji wielkości kodu w celu uzyskania maksymalnej szybkości realizacji algorytmu. Takie języki jak C oraz ich kompilatory mają zaimplementowane mechanizmy pozwalające na elastyczną zmianę strategii w poszczególnych modułach programu.

73 Adam
22-02-2012 1:50
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
Odpowiedz 


Wiadomości w tym wątku
Basic na pic-e, avr-y, arm-y - SQ4AVS - 19-02-2012, 23:26
RE: Basic na pic-e, avr-y, arm-y - SP5FCS - 22-02-2012 1:50

Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości