logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[AVR] C i ASM - Porównanie ilości i szybkości kodu - jak?

wilku_88 07 Lis 2008 17:02 8475 69
  • #1 5712061
    wilku_88
    Poziom 12  
    Wymyśliłem sobie temat na prezentację w której miałem pokazać że assember jest lepszy od C. Jednak po przemyśleniu i uwagach kolegów okazuje się że to bezsensowny temat ;). Postanowiłem zmienić go na:

    Porównanie języków ASM, C oraz Basom pod względem ilości oraz szybkości kodu na przykładzie mikrokontrolera ATmega16 i wyświetlacza LCD

    zalety ASM to jak wiadomo szybkość i mniejsza zajętość kodu w scalaku, co do objętości kodu to nie ma dużego kłopotu żeby pokazać że np.
    program wyświetlający coś na LCD zajmuje mniej niż w robiący to samo w C.
    Nie wiem natomiast jak przedstawić innym osobom że program wykonuje się szybciej...

    Macie jakieś pomysły? Może jeszcze jakieś zalety ASM? ;)

    pozdrawiam
  • #2 5712137
    Konto nie istnieje
    Konto nie istnieje  
  • #3 5712156
    Dr.Vee
    VIP Zasłużony dla elektroda
    Dobreee...

    No i co, pokażesz zaletę - napiszesz program w C i w ASM, porównasz szybkość i rozmiar kodu wynikowego. Przy okazji przekonasz się, że napisanie kodu w ASM zajęło Ci 5x więcej czasu (tylko nie umieszczaj tego broń Boże w prezentacji, w końcu masz udowodnić coś innego :) ) - poza tym szybkość działania obsługi wyświetlacza LCD to kluczowa sprawa dla sukcesu komercyjnego nowego urządzenia!!

    Podpowiedź - wygeneruj sobie listing assemblerowy z programu zoptymalizowanego w C, i optymalizuj dalej "na piechotę" - mniej się narobisz.

    W zwiazku z powyższym oczywiste są zalety ASM: więcej pracy dla programistów, wyższe zarobki (ASM to czarna magia) no i bezpieczeństwo zatrudnienia - jakże ważne w czasach kryzysu... ;)

    Patrząc na to z drugiej strony... (czyli wszystkich nie-programistów) - oprogramowanie i nowe produkty są droższe dla wszystkich, mają więcej bugów, są dużo mniej zaawansowane, a nowe generacje urządzeń wychodzą dużo rzadziej... :)

    Pozdrawiam,
    Dr.Vee
  • #4 5712422
    wilku_88
    Poziom 12  
    Piszę w ASM AVR już od dawna więc wiem o co biega ;)
    chodziło mi tutaj bardziej o temat na program, coś co pokaże że program działa szybciej a jednocześnie będzie to można zauważyć gołym okiem :)

    Może jakaś pętla obliczająca coś "pracochłonnego" i wyświetlająca wynik na wyświetlaczu?
  • #5 5712423
    bis
    Poziom 21  
    W tym konkretnym przypadku szybsze wykonywanie się programu nie zależy od użytego narzędzia programowania (assembler lub język C) ale od jakości algorytmu/kodu (czyli umiejętności programisty). Generalnie ten sam algorytm zapisany symbolicznie trzeba by było zapisać w C i zapisać w assemblerze (wykorzystując zmienne rejestrowe, bezpośrednie odwołania do portów itd..)
    a potem wywoływać ten algorytm (albo wiele jego wywołań) jako opóźnienie przy "mruganiu" jednym z LEDów. Wtedy, zakładając że uda się Tobie zakodować w assemblerze "lepiej" niż w C, będzie widać że dla algorytmu "lepszego" mruga częściej więc udowodnisz tezę o wyższości assemblera (oczywiście tylko dla tego aspektu).
    Dużo ciekawsze było by pokazania na wyświetlaczu "czasu" (w sekundach albo tickach timera) wykonania jednego i drugiego.


    Ogólnie to problem jest głupio postawiony. Tak samo można próbować pokazać że łopatka jest lepsza od koparki. Archeolog przyzna rację ale budowniczy autostrad będzie miał odwrotne zdanie.

    bis
  • #6 5712988
    remzibi
    Poziom 24  
    wilku_88 napisał:
    Mam zrobić prezentację w której pokażę że assember jest lepszy od C.


    Moim skromnym zdaniem ta teza jest lekko mowiac malo udana a ciezej "idiotyczna" , kto ci kazal zrobic te prezentacje - sam to wymysliles czy ktos na uczelni ?
    To taka robota , ze jeden zespol naukowcow dostaje nagrode za udowodnienie pozytywnego wplywu cocacoli na nauke - a drugi dostaje nagrode za udowodnienie czegos wrecz przeciwnego .
    Mam wrazenie , ze wlasnie wkreciles sie do jedego z takich zespolow :) .

    Zamiast tej prezentacji napisz jakis uzyteczny dla ludzkosci program albo spotkaj sie z dziewczyna zamiast tracic czas na glupoty :) .
  • #7 5713841
    BoskiDialer
    Poziom 34  
    Co do samego tematu: Szybkość kodu w asemblerze wynika z tego, że pisząc w nim kod wykorzystujemy wszystkie założenia dotyczące projektu - założenia są podstawą optymalizacji, a jeśli ktoś nie wykorzystuje wszystkich założeń, niech pisze w C, mniej się narobi, bo i tak nic nie zoptymalizuje - i tak:
    - można niektóre warunki uprościć (założenia dotyczące zakresu zmiennych oraz wartości jakiejś operacji logicznej)
    - można optymalizować główną ścieżkę wykonywania (najczęściej wykonywany kod dać w jednym ciągu, podczas gdy do przypadków szczególnych przechodzić skokami - w avr'ach jest to drobny zysk w cyklach: 1 cykl na niewykonaną instrukcję skoku, 2 na wykonaną)
    - można optymalizować rozłożenie zmiennych po rejestrach (zmienne najważniejsze/często wykorzystywane trzymać w rejestrach, mniej ważne ładować z pamięci - tutaj kompilator C może działać równie dobrze, czasem lepiej, jednak nie uwzględnia on przypadku najczęstszego w jakim kod jest wykonywany, kod jest zoptymalizowany tak samo lub podobnie pod wszystkie przypadki)
    - można implementować niskopoziomowe sztuczki, łącznie z wykorzystaniem instrukcji które nie są dostępne bezpośrednio z poziomu C.
    - można rozwijać kluczowe dla nas pętle do dowolnego poziomu wykorzytując dodatkowe założenia na czas (im szybciej, tym więcej rozwinięta pętla), warunki pętli (jeśli liczba przebiegów jest wielokrotnościa jakiejś liczby, mozna rozwinąć o liczbę będącą dzielnikiem tej liczby), liczbę przebiegów (przy dużej liczbie przebiegów jest sens rozwijać pętle bardziej, gdyż jest większy zysk spowodowany mniejszą liczbą sprawdzania warunków pętli)
    - można bezpośrednio zrealizować wszystkie usprawnienia, których kompilator nie potrafi. Wywołania końcowe - następujące po sobie [r|i]call oraz ret można zamienić na samo [r|i]jmp. Funkcje w obrębie jednego modułu można zoptymalizować znając listę wykorzystywanych rejestrów - w C wywołanie funkcji powoduje, że rejestry r0 oraz r18-r31 (bez r28 i r29) muszą - co jest związane z konwencją przekazywania parametrów i wywołań funkcji - być uznane za nie zawierające poprzedniej wartości. W kodzie asemblera lub w obrębie modułu napisanym w asemblerze można wywołać inną funkcję, o której wiadomo, że nie zmienia pewnych rejestrów. Nie trzeba wtedy ich odkładać na stos (lub przenosić do niższych rejestrów, które to muszą być odkładane na stos na początku funkcji).

    Ogólnie w C ciężko wprowadzić niektóre założenia dotyczące kodu, przez co kompilator nie może zoptymalizować kodu do konkretnego przypadku (ten sam kod może być raz wydajny, raz nie, zależy to od założeń na dane). W asemblerze wszystkie założenia da się wprowadzić, gdyż jest to najniższy poziom na jakim pisze się kod.

    Pomimo argumentów które przytoczyłem oraz dużego doświadczenia w pisaniu asm na avry jestem zwolennikiem łączenia C z asemblerem - aktualnie większość projektów jakie mam składa się z kodu głównego w C (często ponad 80% kodu), ale moduły odpowiedzialne za procesy krytyczne czasowo (minimalny czas reakcji) lub takie, które muszą być wykonywane skrajnie szybko (szybkość przetwarzania bloków danych) mam napisane w asemblerze. Jest to najlepszy kompromis, powiązanie szybkości pisania kodu (C) z możliwością silnego zoptymalizowania wybranych fragmentów (asm).
    Przenośność jest ograniczona, ale też nie do końca, kod w asemblerze nie da się przenieść na inną rodzinę procesorów, ale też nie ma sensu, gdyż na innej może istnieje możliwość jeszcze większej optymalizacji danego fragmentu kodu.
  • #8 5718780
    Seba319
    Poziom 24  
    Całkowicie zgadzam się z użytkownikiem BoskiDialer! Pisząc w C zyskujemy mnóstwo czas a jak to się mówi „czas to pieniądz”! Jeśli ktoś dajmy na to zleca wykonanie jakiegoś urządzenia to najczęściej zależy mu na czasie realizacji projektu i niezawodności urządzenia. Dobry świadomy programista zdający sobie sprawę z ograniczeń wynikających z fakty programowania w języku wysokiego poziomu może zastosować wstawki asm i procedury napisane w asm. Właśnie takie połączenie daje najlepsze efekty i pozwala szybko wygenerować bardo dobry kod.

    Wracając de meritum sprawy osobiście tak jak kilku przedmówców uważam że temat jest idiotyczny, bo równie dobrze można udowadniać że lepszy jest C ze względu na szybkość i łatwość w pisaniu programów. Jak to zwykle bywa racja jest gdzieś po środku czyli połączenie C z asm. Jeśli jednak już się w to wpakowałeś to musisz poszukać, właśnie owych wad języka C o których pisał BoskiDialer, a potem napisać dwie funkcje np. czasowe. Potem musisz to jakoś zobrazować wiec może mruganie diody LED lub jakiś pomiar czasy dajmy na to wykonania się x razy danej pętli realizującej określone zadanie, a potem wyświetlić ten czas na LCD.
  • #9 5728935
    arturt134
    Poziom 27  
    Moim zdaniem, asembler może być lepszy od C tylko w jednym zastosowaniu: przy cyfrowym przetwarzaniu sygnałów. Tam wydajność niektórych fragmentów kodu ma kluczowe znaczenie dla całości aplikacji.
    Poza tym, asembler DSP bardziej przypomina zapis arytmetyczny niż klasyczny asembler, np. AVR-a.
    W przypadków procesorów tradycyjnych C ma zdecydowaną przewagę nad asemblerem.
  • #10 5729772
    marek_Łódź
    Poziom 36  
    Fakt, temat dziwaczny. Przykład - zliczanie zbocz w przerwaniu. Kod obsługi przerwania wygenerowany w C vs najprostsza obsługa asemblerowa. Policzyć cykle zegarowe w jednymi drugim przypadku i przeliczyć na dopuszczalną częstotliwość zmian na linii wejściowej przerwania.
  • #11 5736397
    mieciomiecio
    Poziom 12  
    Kod C jest bezpośrednio tłumaczony do ASM. Sam pisałem kiedyś taki prosty kompilator na zaliczenie. Jeżeli założymy że optymalnie zostanie kod napisany w C i ASM to w kod w ASM będzie działał szybciej. Ale niekiedy bardziej istotne jest wykorzystanie pamięci RAM (programy w C są bardziej wymagające RAMU).
  • #13 5736691
    marek-c
    Poziom 19  
    BoskiDialer napisał:

    - można implementować niskopoziomowe sztuczki, łącznie z wykorzystaniem instrukcji które nie są dostępne bezpośrednio z poziomu C.
    .


    To chyba jedyne czego nie zrobi dobry programista w C...
    Sam się zdziwiłem co daje takie cóś:

    if(warunek)
    {}

    zmienić na

    if((dummy = warunek))
    {}

    Marek
  • #14 5736701
    Konto nie istnieje
    Konto nie istnieje  
  • #15 5737935
    wilku_88
    Poziom 12  
    witam, przyznaję Wam rację, i głupio mi bo temat był moim pomysłem jednak nieprzemyślanym... ;) Jedyne co można zaprezentować to Kody w poszczególnych programach robiące dokładnie to samo... i porównać objętość kodu (szybkość działania trudno tutaj pokazać).
    Nie można powiedzieć że C jest lepsze czy ASM jest lepszy w każdym przypadku... Który język będzie lepszy to zależy od celu i wielkości projektu ;) Pozdrawiam
  • #16 5738044
    marek_Łódź
    Poziom 36  
    wilku_88 napisał:
    witam, przyznaję Wam rację, i głupio mi bo temat był moim pomysłem jednak nieprzemyślanym... ;)
    Chyba nie masz się czym przejmować. Cała historia informatyki jest obudowana nieustającymi głupimi dyskusjami na temat wyższości Świąt Bożego Narodzenia nad Wielkanocnymi np. co lepsze Pascal, czy C,, Linux czy Windows, Atmel czy PIC, Spectrum czy C64 itd...itd..., czego przykłady mamy również na elektrodzie.
  • #17 5739122
    marek-c
    Poziom 19  
    albertb napisał:
    A co wg Ciebie daje?

    Albert


    Zmniejszenie kodu. Kompilator nie 'szasta' rejestrami podczas wyznaczania warunku.

    Marek
  • #18 5739346
    Dr.Vee
    VIP Zasłużony dla elektroda
    marek-c napisał:
    Sam się zdziwiłem co daje takie cóś:
    if(warunek)
    {}
    
    zmienić na
    
    if((dummy = warunek))
    {}


    marek-c napisał:
    [daje to] Zmniejszenie kodu. Kompilator nie 'szasta' rejestrami podczas wyznaczania warunku.


    Eee... Jasne. Chyba masz ten sam kompilator, który kilka postów powyżej napisał mieciomiecio na zaliczenie ;)

    Dla testu tego typu avr-gcc generuje:
    1) dla 8-bitowych zmiennych: and reg, reg + breq/brne
    2) dla 16-bitowych zmiennych: sbiw reg, 0 + breq/brne

    Instrukcja mov(w) nie zmienia żadnych flag, a nieużywane zmienne kompilator usuwa podczas optymalizacji, więc co miałoby zmienić tutaj przypisanie dummy=warunek?

    Może więc wyjaśnisz, w jaki sposób tutaj kompilator może "szastać rejestrami"?

    Pozdrawiam,
    Dr.Vee
  • #19 5739872
    marek-c
    Poziom 19  
    
            if((o = (a & 0b00001000)))
         17c:	13 fd       	sbrc	r17, 3
         17e:	02 c0       	rjmp	.+4      	; 0x184 <write_temp+0x1a>
         180:	ff 24       	eor	r15, r15
         182:	02 c0       	rjmp	.+4      	; 0x188 <write_temp+0x1e>
         184:	82 e3       	ldi	r24, 0x32	; 50
         186:	f8 2e       	mov	r15, r24
                c += 50;
    
    
            if(a & 0b00001000)
         17c:	81 2f       	mov	r24, r17
         17e:	13 fd       	sbrc	r17, 3
         180:	02 c0       	rjmp	.+4      	; 0x186 <write_temp+0x1c>
         182:	ff 24       	eor	r15, r15
         184:	02 c0       	rjmp	.+4      	; 0x18a <write_temp+0x20>
         186:	92 e3       	ldi	r25, 0x32	; 50
         188:	f9 2e       	mov	r15, r25
                c += 50;
    


    Andrzej Witkowski
    "Mikrokontrolery AVR programowanie w języku C"
    (początkowe rozdziały...)
  • #20 5740158
    BoskiDialer
    Poziom 34  
    Może to i nawet powodować jakieś przyśpieszenia, optymalizacje, ale jest to uzależnione od kompilatora, więc takich zabiegów ja nie uznaję. Dobry kompilator zoptymalizuje takie konstrukcje. Żeby sprawdzić rzeczywisty kod wynikowy obu sposobów (na kompilatorze, który posiadam - gcc 4.2.2 dla avr) napisałem taki kod:
    	unsigned char a;
    	unsigned char c;
    	asm volatile("; %0, %1":"=r"(a), "=r"(c):);
    
    	unsigned char o;
    	if((o = (a & 0b00001000))) 
    		c += 50; 
    
    	asm volatile("; %0, %1":"=r"(a), "=r"(c): "0"(a), "1"(c));
    
    	if(a & 0b00001000) 
    		c += 50;
    
    	asm volatile("; %0, %1":: "r"(a), "r"(c));

    Efekt jest jednoznaczny:
    	; r24, r25
    /* #NOAPP */
    	sbrc r24,3
    	subi r25,lo8(-(50))
    .L8:
    /* #APP */
    	; r24, r25
    /* #NOAPP */
    	sbrc r24,3
    	subi r25,lo8(-(50))
    .L10:
    /* #APP */
    	; r24, r25
    Nawet po wymuszeniu, aby obie zmienne znajdowały się w rejestrach r2 i r3:
    	register unsigned char a asm("r2");
    	register unsigned char c asm("r3");
    uzyskałem:
    	; r2, r3
    /* #NOAPP */
    	sbrs r2,3
    	rjmp .L8
    	ldi r24,lo8(50)
    	add r3,r24
    .L8:
    /* #APP */
    	; r2, r3
    /* #NOAPP */
    	sbrs r2,3
    	rjmp .L10
    	ldi r24,lo8(50)
    	add r3,r24
    .L10:
    /* #APP */
    	; r2, r3

    Czyli widać, że programista powinien zająć się pisaniem kodu, a kompilator optymalizacją (jeśli kod ma być super-optymalny, to można wyręczyć kompilator pisząc w asemblerze)
  • #21 5740179
    wilku_88
    Poziom 12  
    wracając do tej prezentacji, napisałem program na ATmega16 w Bascomie, C, Asemblerze który wyświetla na wyświetlaczu LCD "AKiSO" wyniki w ilości kodu jakie otrzymałem:

    ASM - 105B
    C - 550B
    Bascom - 491B ok 3% z całej pamięci

    Dziwi mnie fakt że w Bascomie program zajmuje mniej niż w C. Myślałem że będzie odwrotnie... Do kompilacji w C użyłem AVR Studio 4 czy jest jakaś możliwość większej optymalizacji? Biblioteka do LCD jest napisana zwięźle, więc nie wiem co jeszcze mogę zmienić.
  • #22 5740189
    BoskiDialer
    Poziom 34  
    wilku_88: Też nie wiem co możesz zmienić, nie widzę tej biblioteki przed sobą. Na pewno można załączyć optymalizację, można usunąć funkcje, które nie są wykorzystywane (w C ustalenie które funkcje są używane mogło by nastąpić dopiero na poziomie linkera, ale wtedy moduły już są zbudowane, więc nie da się ich wywalić - wyjątek: funkcje statyczne). Zawsze się coś tam jeszcze znajdzie.
  • #23 5740191
    Konto nie istnieje
    Konto nie istnieje  
  • #24 5740309
    Dr.Vee
    VIP Zasłużony dla elektroda
    wilku_88 napisał:
    wracając do tej prezentacji, napisałem program na ATmega16 w Bascomie, C, Asemblerze który wyświetla na wyświetlaczu LCD "AKiSO" wyniki w ilości kodu jakie otrzymałem:

    W takich sytuacjach raczej się eliminuje dodatkowe zmienne, a nie dodaje - a Ty użyłeś 3 różnych bibliotek do obsługi LCD w 3 różnych językach programowania. Przypomnij mi, co chciałeś porównać? :)

    Jak już się uwikłałeś, to np. napisz 3 procedury wykonujące jakieś intensywne obliczenia na kawałku pamięci, powiedzmy FFT. W takim zastosowaniu oczywiście ASM wygra, ale o to Ci chodzi, nie? :)

    Później uruchamiasz symulator, ładujesz kod i liczysz ile cykli zajęło wykonanie funkcji dla tych samych danych trzem różnym implementacjom. Bo rozmiar kodu to nie wszystko...

    Implementację FFT w ASM masz tutaj: http://elm-chan.org/docs/avrlib/avrfft.zip w C i Bascomie będziesz musiał sobie dorobić, ale to nie takie trudne...

    Pozdrawiam,
    Dr.Vee
  • #25 5740521
    marek-c
    Poziom 19  
    albertb napisał:
    marek-c:
    Jako dobry programista powinieneś wiedzieć, że efekt takiej zmiany zależy od:

    Albert


    A tego to nigdy nie twierdziłem! Wręcz odwrotnie.
    A dyskusja ciekawa, dzięki!

    Marek
  • #26 5741117
    orcan.bp
    Poziom 14  
    Drodzy koledzy uważam że nie należy dyskutować który język jest lepszy bo kryteria wyboru są różne. Czasami zależy nam na konstrukcji bardzo zaawansowanej z bardzo dużą ilością peryferii i czas nas goni więc piszemy w c szybko i przyjemnie a czasami zależy nam na minimalizacji kosztów w przypadku produkcji seryjnej i wtedy poświęcamy wiele czasu na program w asemblerze. Nasz kolega prosi o pomoc w wykazaniu wyższości asm nad c i na tym powinniśmy się skupić. Ja osobiście piszę najczęściej w asemblerze i nie mam problemu z długim czasem powstawania programu ponieważ przez długi czas zabawy w programowanie procesorów nazbierało się dużo bibliotek które jako gotowce wykorzystuję w swoich programach. Dla wszystkich którzy nie rozumieją w jaki sposób można udowodnić wyższość asemblera nad pozostałymi językami mam zadanie do wykonania po którym zrozumieją.
    zadanie:
    Termometr na 4 wyświetlaczach led z bardzo popularnym czujnikiem DS18B20 z rozdzielczością wyświetlania 0,1 st bez kwarcu na procku at90s1200.
    W asemblerze zajmuje 80 procent pamięci i jeszcze jest miejsce na rozwijanie programu.
    Dla osoby która napisze to samo w c lub bascomie daję 100 pkt.
    Proszę mi nie pisać że można procesor zmienić bo tu nie o to chodzi.
    Nadmieniam że nie chodzi mi o rozwijanie tematu o wyższości jednych świąt nad drugimi tylko chodzi o odpowiedź na temat postu
    Cytat:
    [AVR] C i ASM - Jak pokazać wyższość ASM nad C?
    .
    Pozdrawiam
  • #28 5741247
    orcan.bp
    Poziom 14  
    Ja nie napisałem że potrzebuje ten program bo puki co to nie muszę płacić za oprogramowanie a swoją drogą to jestem ciekaw jak poradzi sobie twój kompilator z prockiem taktowanym wewnętrznym oscylatorem i magistralą 1w oraz brakiem ramu a co za tym idzie bez stosu i z flashem 0.5k
    Moja ciekawość jest na tyle duża że chyba nawet jestem w stanie ci te 100 zł zapłacić aby ją zaspokoić.
  • #29 5741252
    Dr.Vee
    VIP Zasłużony dla elektroda
    orcan.bp napisał:
    Termometr na 4 wyświetlaczach led z bardzo popularnym czujnikiem DS18B20 z rozdzielczością wyświetlania 0,1 st bez kwarcu na procku at90s1200.
    W asemblerze zajmuje 80 procent pamięci i jeszcze jest miejsce na rozwijanie programu.
    Dla osoby która napisze to samo w c lub bascomie daję 100 pkt.
    Proszę mi nie pisać że można procesor zmienić bo tu nie o to chodzi.

    No tak, bez kompilatora C ani bascoma ciężko będzie coś napisać... nawet za taką zawrotną kwotę jak 100 pkt ;)

    Rozumiem, to jest ta zaleta - nawet na procesory sklecone z kostek TTL jest jakiś asembler, ale z kompilatorem to już gorzej... ;)

    PS. Żeby nie odbiegać zbytnio od tematu -> żeby pokazać wyższość ASM nad C należy np. zrobić swój własny procesor, na którego nikt nigdy nie napisze kompilatora C ;)

    Pozdrawiam,
    Dr.Vee
  • #30 5741256
    mirekk36
    Poziom 42  
    ja chociaż jestem początkujacy w C to też napiszę w 1KB taki program.

    generalnie uważam temat wątku z totalnie bzdurny. O ile rozumiem kłótnie czasem na forum wszelkich zaciekłych przeciwników bascoma przeciwko tym co korzystają z C lub asm, to próba udowadniania tego co w temacie mija się nieco ze zdrowym rozsądkiem,

    a podejrzewam , że kolega autor wymyślił sobie tę "prezentację", której nawiasem mówiąc nie zleciłby żaden nauczyciel. Tylko chyba sam autor po to aby w jakiś nieco pokrętny sposób uzyskać odpowiedzi na nurtujące go pytania:

    Cytat:
    wracając do tej prezentacji, napisałem program na ATmega16 w Bascomie, C, Asemblerze który wyświetla na wyświetlaczu LCD "AKiSO" wyniki w ilości kodu jakie otrzymałem:

    ASM - 105B
    C - 550B
    Bascom - 491B ok 3% z całej pamięci


    Jeśli kolega autor chce się zacząć uczyć poza Bascomem, którego też dobrze znać (ja tak uważam) także języka C (o asemblrze nie wspomnę bo go zawsze warto przynajmniej ogólnie znać) to niech kolega zacznie pisać sam swoje programy w C ale od podstaw (bo można) żeby odpowiedzieć sobie na te pytania powyżej. Wystarczy, że nie będziesz się opierał pisząc w C, o jakąś przepastną i rozbudowaną bibliotekę do LCD, tylko napiszesz swoją i z tymi funkcjami, które potrzebne są ci do porównania efektów a sam zobaczysz, że kod w C będzie znacznie mniejszy niż napisałeś i to bez aż tak różnych karkołomnych (przynajmniej jak dla mnie jeszcze) zaawansowanych sposobów optymalizacji o których pisali tu różni koledzy i fajnie bo można liznąć nieco wiedzy. (a tak przy okazji może jeszcze na dodatek kompilowałeś program w C z wyłączoną w ogóle optymalizacją - daj sobie przynajmniej parametr -Os i życzę powodzenia w C (a wstawek asemblera gdy się dobrze nauczysz C sam będziesz używał jak masła w bułce i nie przyjdą ci wtedy więcej do głowy pomysły o wyższości asm vs C i vice-versa ;)

    orcan.bp -> naukę C niedawno rozpoczynałem właśnie od wyświetlania multiplexowego LED i napisać to w C na jakimś przerwaniu timera to naprawdę mały pikuś i niewiele bajtów jak się dobrze wszystko napisze
REKLAMA