Ale uwierz mi, że nie dopatrywałem się drugiego dna .... Twoje zdanie, że warto zwracać uwagę również i na takie rzeczy jak wielkość bufora w tym konkretnym przypadku uważam wręcz za BARDZO POZYTYWNĄ ... jedyne co to chciałem podpowiedzieć, że ja nie postrzegam tego jako trend ... ale fakt też jest taki - że wiele osób ot po prostu to wprost przepisuje bez zastanowienia ... Ba! ja sam często nie przykładam w tym konkretnym przypadku pewnie uwagi żeby to gdzieś poprawić ....
I teraz - nie chodzi o to abym to próbował tłumaczyć, że jak ja to robię nawet bezwiednie to oznacza, że tak jest dobrze, itp ...
Tyle, że nie do końca też w tym konkretnym przypadku upatruję jakiejś tragedii - dlaczego ? .... dlatego, że jest to bufor przejściowy i tworzony tylko na czas działania funkcji, a po jej zakończeniu niszczony. Owszem - zgodzę się, że w skrajnych przypadkach - szczególnie gdy działamy tak, że pamięci RAM zostaje nam już tylko kilka procent i istnieje ryzyko, że nawet tych kilka bajtów może gdzieś zaorać rąbek stosu - to ma to swoje uzasadnienie, albo gdyby nie przemyśleć sytuacji i użyć tworzenia zawsze za dużego bufora w dużej ilości jakichś swoich funkcji ... i jeszcze do tego w procku ATtiny2313 (128 b RAM) albo ATtiny13 (64 b RAM) to pewnie, że tu trzeba już dbać o KAŻDY bajt co jest mega oczywiste ale też dość szybko wychodzi w praniu ...
Kolejna rzecz to co teraz napiszę - nie ma być jakąś obroną maniakalną książki - ale .... w takiej książce jak Bluebook ja to zostawię jak jest ... dlatego, że zwracam w niej szczególną uwagę na funkcję itoa() i czytanie dokumentacji ... co więcej, gdybym tutaj dał bufor 7 bajtów zamiast 17 ... to też (założę się pojawiłyby się pytania) ... a dlaczego coś mi się dzieje złego gdy dam radix 2 ? ... Czego by nie użyć pojawiłyby się pytania - chyba że ...
i tu dopiero wydaje mi się, że dochodzimy do sedna sprawy - chyba żeby opisać dokładnie KAŻDĄ funkcję wbudowaną, w tym także zasady tworzenia bufora .... Ale na tym polu jest wolna droga i każdy może podejść do sprawy jak uważa za stosowne. Ja kompletnie nie twierdzę, że zrobiłem to najlepiej - ale jak mówię zostanę przy swoim .... Ktoś inny może się za to zabrać i opisać inaczej ... Dlaczego o tym mówię ?
Ano dlatego, że na potrzeby całej książki poczyniłem pewne założenia tego typu, że
- gdy opisuję zagadnienie B to czytelnik gdzieś tam już musi znać podstawy czyli zagadnienie A (przykład - że czytelnik wie co to jest reprezentacja liczb binarnych i hexadecymalnych - o podstawach przeliczania nie ma ani słowa w książce i wiem że część osób ma z tym kłopot a nawet nieraz w mailach pisze do mnie - dlaczego tego nie opisałem? Ja na to odpowiadam, że dlatego, że gdybym miał opisywać pewne podstawy to książka musiałaby liczyć nie 460 stron ale może 1500 stron ? Poza tym dla jednego to są podstawy np te sposoby przeliczania a dla innego musiałbym się cofnąć może jeszcze wcześniej ? Po trzecie zaś - po kilku latach od ukazania się książki stworzyłem poradnik wideo na ten temat i tam mogę śmiało odesłać.
- gdy opisuję np komunikację RS232 to z pełną świadomością i piszę wręcz wprost w książce - że pominę opis podstaw działania RS232, budowy ramki danych itp itd - ale za to pokażę nie tylko jak to działa ... opiszę to tak - że KAŻDY nie wiedząc na tym etapie jak zbudowana jest ramka danych RS232 i tak dokona transmisji i jeszcze ją zrozumie. Oczywiście że znajomość RS232 od podstaw się przyda, ba! jest wręcz wg mnie konieczna - ale to można poza książką doczytać - dowiedzieć się - bo znowu musiałbym napisać dzieło które miałoby 1500 stron
Podsumowując - zakładam, że do pewnych spraw czytelnik sam dojdzie - że jak już się nauczy podstaw - to ....
i teraz uważaj - nauczy się także optymalizować kod - i również PISZĘ O TYM WPROST w książce, dlatego też np mój bodajże najważniejszy rozdział o multipleksowaniu LED jest napisany w sposób bardzo nieoptymalny ! Co więcej kilka osób z elektrody próbowało mi zarzucać właśnie - że NIGDY tak nie powinno się uczyć kogoś tylko od razu pokazać MEGA OPTYMALNY sposób a zawartość procedury obsługi przerwania zapisać wręcz w jednej linii kodu w C ! Przy okazji oczerniając i mnie i książkę a nawet w pewnym okresie czasu łamiąc moje prawa autorskie na pewnym blogu - ale z tego to już ich wyleczyłem za pomocą prawnika. Ja rozumiem, że oni czy ktokolwiek może uznać, że moje metody że moja metodologia w książce jest zła, niedobra itp itd ... to normalne - nie jestem geniuszem i zawsze to powtarzam, ale jak ktoś ma coś przeciw aż tak mocno to niech że się weźmie za napisanie książki lepszej - która uzupełni pewne sprawy, wypełni lukę albo będzie dużo lepsza - a ja przysięgam wtedy że będę sam ją także polecał i pewnie się z niej też sam dużo nauczę ...
Tymczasem nie chwaląc się bo nie o to chodzi, dodatkowo przyznam, że sam jestem nawet już po 5 latach mocno zaskoczony, ale jednak ta książka trafia do szkół, na uczelnie ! ... wykorzystywana jest w dydaktyce i nawet zaliczana do listy obowiązkowych na niektórych uczelniach. Ale piszę to tylko dlatego - żeby pokazać, że jednak chyba to moje podejście które prezentuję w książce w całości jednak trafia i to nie tylko do hobbystów ...
Jak widzisz wg mnie poruszyłeś akurat taki istotny temat i stąd moja dyskusja - ale nie kłótnia i nie zarzuty żadne pod twoim adresem broń Boże - tak nie myśl ....
Na koniec odniosę się do ostatniej części twojej wypowiedzi wyżej ....
rskup napisał(a):
Dodatkowo nie do końca ufam w pełną micro(procesorowość) C w każdych dostępnych funkcjach i jego optymalne zachowanie (to chyba taka trauma z dzieciństwa). Często jak zaglądam do pliku lss, to się mi włos na głowie jeży co tam kompilator zrobił z tak prostym zapisem. Szczególnie że sam się wychowałem na asemblerze a nawet tworzyłem poważny komercyjny kod, akurat to były czasy AT89C2051,
Ale to widać po tobie
... - to komplement oczywiście do ciebie ....
Nie mniej jednak - ja nie zgodzę się, że każdy kod skompilowany w C do asemblera trzeba poprawiać nawet gdy wydaje ci się okiem asemblerowca czasem nieoptymalny .... Prezentujesz tu właśnie podejście (nie jako pierwszy bo jest kilku takich asemblerowców na forum, którzy często to samo piszą co ty że "ja nie dowierzam kompilatorowi i wciąż sprawdzam *.lss i poprawiam" ... a ja zawsze na to mówię i powtarzam to samo:
- daj pan spokój - programowanie w C mocno różni się od programowania w ASM. To jest język wyższego poziomu i on nie ma służyć do tego, żeby po kompilacji było WSZYSTKO TAK ZOPTYMALIZOWANE że głowa boli bo ? .... no właśnie dlaczego tak nie ?
Ano dlatego - że głównym założeniem jest to - że programowanie w C ma być wygodne i zapewnić szybką realizację celu a częściej celem głównym jest SZYBKOŚĆ REALIZACJI projektu i tu pod tym względem (wątpię abyś się z tym nie zgodził) język C bije na głowę asembler !
Czy to znaczy, że ja twierdzę, że asembler jest zły i nie należy go używać? uczyć się ? .... ależ NIE!
wręcz odwrotnie - ucząc się C warto chociażby liznąć asemblera, ba jak ktoś lubi to warto się go nauczyć po to aby np niektóre proste projekty stworzyć w samym ASM !
Ja też wywodzę się z asemblera - i ZAWSZE gdy poznaję nowego procka to nie ma (jak to się mówi) bata, zawsze muszę zacząć od poznania przynajmniej na sucho jego asemblera i koniec! Dopiero później zabieram się za język wyższego rzędu na potrzeby jego programowania ...
Sam również przeglądam plik *.lss
ale tu jest pewnie między nami OGROMNA różnica .... Ja z racji wskoczenia w C coraz mniej albo prawie wcale nie używam asemblera więc ? ... jak się czegoś nie używa to często się sporo zapomina a zatem uważam, że jestem dużo gorszym asemblerowcem niż ty. Ok ... to kiedy i po co sięgam do tego asemblera ? - przede wszystkim wtedy kiedy warto:
1. gdy dochodzę do ściany i czasowo C mi się nie wyrabia a bez tego nie wykonam obsługi pewnych zależności czasowych, nie oprogramuję jakiegoś ważnego zagadnienia bo tam już optymalizacja C nie sięga ... przykład? np wstawki ASM dla obsługi Magic LED
2. gdy muszę z jakichś ważnych względów zrealizować jakiś projekt na mega małym procku np ATtiny10 ale nawet 13. Wtedy jak trzeba to zrobię go nawet TYLKO w ASM ... a jeśli w C - to wręcz siedzenie i patrzenie w *.lss jest wręcz wymagane żeby coś większego stworzyć
Tyle, że na co dzień w 99,99% przypadków:
1. wybieram większy procek gdy brakuje mi zasobów
2. tworzę projekty gdzie optymalizacja na poziomie kompilatora C NICZEMU nie przeszkadza
dzięki temu projekt tworzę SZYBKO !
Na koniec już - zapytam - po co np optymalizować pętlę którą zorganizował kompilator (a w wielu przypadkach można) gdy nie ma to ŻADNEGO uzasadnienia bo w projekcie i tak w pętli głównej tego nie potrzebuję, a jeśli nawet takich pętli mam dużo i nagle się okazuje, że procek ATmega8 ma za mało FLASH ? .... to ja wolę wziąć procka ATmega168 niż dłubać się w asm rozumiesz ?
kolejna sprawa - co to znaczy że program jest zoptymalizowany? Ty jako asemblerowiec powinieneś to wiedzieć ....
więc wiesz, że nie ma CUDOWNEJ optymalizacji pod każdym kątem
za to jest wiele rodzajów optymalizacji, np:
- optymalizacja pod kątem zajętości pamięci FLASH
- optymalizacja pod kątem czasu
i często - hmmm prawie zawsze obie kłócą się ze sobą - a poszukiwanie IDEALNEJ optymalizacji - jako asemblerowiec wiesz, że jest jak poszukiwanie świętego grala....
Tylko nie pisz mi proszę - że program napisany w czystym ASM będzie zawsze bardziej optymalny niż ten skompilowany w C - tzn, że to jest argument. Bo owszem ja się z tym zgodzę nawet - tylko na szali postawię coś innego
Masz do realizacji projekt napisania stosu TCP, obsługi FAT32 na kartach SD plus kilka innych tego typu rzeczy .... masz na tym zarobić i zarobek będzie tym większy im szybciej zrobisz pracę .... Chyba już sam czujesz przez skórę kto wygra - taki pojedynek - ten kto pisze w C czy ten kto w ASM ?
Inna sprawa jest taka - że są też dwa marginesy - jest część programów, które bez chociażby wstawek ASM nigdy nie powstaną w samym C albo bez pomocy asemblera w nim. I ten margines jest mały - bo jest dużo więcej programów, które powstaną w czystym C i będą działać idealnie pomimo to, że będą troszkę spuchnięte nawet jeśli chodzi o zajętość FLASH niż gdyby były napisane w ASM ale tu należy dodać przez naprawdę dobrego programistę w ASM.
Mi się wydaje - że mi udało się pojąć te zależności ... pomimo że też wywodzę się od asemblera i kiedyś TYLKO w tym pisałem i tylko to uważałem. Warto tu umieć balansować swoje podejście a nie wciąż podchodzić tak:
rskup napisał(a):
Dodatkowo nie do końca ufam w pełną micro(procesorowość) C
Bo tak na początku korzystania z C mówi KAŻDY asemblerowiec, czasem nawet nie na początku tylko zawsze ? ... moim zdaniem traci troszkę na tym ... ale może się mylę
ło matko - ale się rozpisałem - uważam jednak że czasem warto i można o tym podyskutować
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
