Elektroda.pl
Elektroda.pl
X
CControls
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Assembler a C++ czyli wybór szybciej czy taniej...

pomozcie19 15 Maj 2009 22:40 18907 144
  • #61 15 Maj 2009 22:40
    michalko12
    Specjalista - Mikrokontrolery

    kedzi1 napisał:
    Warto się dowiedzieć w czym pisane są poważne aplikacje biznesowe na mainframe, aplikacje urzywane przez banki. Są to języki wysokiego poziomu. Tylko szaleniec dał by to pisać całe w asm. W urządzeniach lotniczych też stosuje się specjalne języki wysokiego poziomu. Nikt nie napisze awioniki w asm. Tam jeszcze więcej do gadania mają komputery niż w C.


    Ja napisałem że podobno podkreślam podobno w samolotach w krytycznych systemach programy pisane są w asemblerze. Napisałem to na podstawie tego co usłyszałem od człowieka który projektuje urządzenia dla wojska do samolotów.

    A co do aplikacji dla banków itp. hmmmm... zdaje się że ostatnio Visa trochę przejechała się na takim sofcie.
    Po drugi nie o takich aplikacjach jest mowa w tym wątku, twój przykład to jest jak porównanie Visty do FreeRTOSa.

  • CControls
  • #62 15 Maj 2009 23:00
    AnnaWesolaLat23
    Poziom 15  

    michalko12 napisał:

    Ciekawostka...
    Podobno w samolotach w krytycznych systemach wszystko co ma jakiś program ma program napisany w asemblerze.


    To tak sie konczy pisanie w C tych niektrytycznych rzeczy: jak np wlaz do samolotu ktory sie zacial (F22).

    Code:
    The incident at Langley has many Pentagon watchers shaking their heads. Tom Christie, the former director of testing and evaluation for the DOD, calls the F-22 incident at Langley "incredible." "God knows what'll happen next," said Christie, who points out that the F-22 has about two million lines of code in its software system. "This thing is so software intensive. You can't check out every line of code." 
    

    Now, just for the sake of comparison, Windows XP, one of the most common computer operating systems, contains about 45 million lines of code. But if any of that code fails, then the computer that's running it simply stops working. It won't cause that computer to fall out of the sky. If any of the F-22's two million lines of computer code go bad, then the pilot can die, or, perhaps, just get trapped in the cockpit.

    One analyst inside the Pentagon who has followed the F-22 for years said that "Everyone's incredulous. They're asking can this really have happened?" As for Lockheed Martin, the source said, "Whatever the problem was, the people who built it should know how to open the canopy."


    Link

    A tu link do fotek

    Ofiara programistow C:
    Assembler a C++ czyli wybór szybciej czy taniej...
    i jeszcze jedna:
    Assembler a C++ czyli wybór szybciej czy taniej...

    Udanego weekendu chlopaki, nie pijcie za duzo!

  • CControls
  • #63 15 Maj 2009 23:05
    kedzi1
    Poziom 18  

    Ktoś tu porównał to co pisze na AVRy do VISTY. Może moje porównanie nie jest dobre, chodziło o to że nie można mówić o tym, że języki wysokiego poziomu są złe i powodują tylko błędy. W krytycznych aplikacjach też pisze się w tych językach.

    Dlaczego człowiek, który całe życie pisze w asm twierdzi, że programy w C są gorsze. Może kompilatory powodują czasami błędy, ludzie piszący w asm też. Nie ma ludzi nieomylnych. Tak jak błędy kompilatora są przewidywalne to juz człowieka ani troche. Nie ma cudów, nawet super specjalista może w końcu zrobić babola. Tylko że w asm jest to już niewybaczalne.

    Sam jeszcze nie miałem kłopotów z programem pisanym zarówno w asm i w C. Urządzenia z firmware napisanym w C, które projektowałem pracuja non stop przez kilka lat i nie podejrzewam żeby miało się coś wysypać. Po prostu przekonałem się że w C można programować nawet lepiej niż w asm, dlatego ograniczyłem ten język do wstawek. Jakie to daje korzyści nie wspomnę.

    Niech zgłosi się ten który pisał obliczenia zmienno przecinkowe albo np stos TCP/IP w asm. Niech który sie pochwali co robi w takich przypadkach. Co? Nie da się? Pewnie się da, tylko jakim kosztem i czy już ktoś próbował. :)

  • #64 15 Maj 2009 23:10
    AnnaWesolaLat23
    Poziom 15  

    @michalko12 - dla bankow nie dosc ze pisze sie w C++ to jeszcze w kompilatorze M$

  • #65 15 Maj 2009 23:26
    kedzi1
    Poziom 18  

    Nie sądzicie, że ludzie, którzy popełnili te błędy pisząc w asm popełnili by ich jeszcze więcej.

  • #66 15 Maj 2009 23:31
    michalko12
    Specjalista - Mikrokontrolery

    kedzi1 napisał:
    Ktoś tu porównał to co pisze na AVRy do VISTY. Może moje porównanie nie jest dobre, chodziło o to że nie można mówić o tym, że języki wysokiego poziomu są złe i powodują tylko błędy. W krytycznych aplikacjach też pisze się w tych językach.

    Dlaczego człowiek, który całe życie pisze w asm twierdzi, że programy w C są gorsze. Może kompilatory powodują czasami błędy, ludzie piszący w asm też. Nie ma ludzi nieomylnych. Tak jak błędy kompilatora są przewidywalne to juz człowieka ani troche. Nie ma cudów, nawet super specjalista może w końcu zrobić babola. Tylko że w asm jest to już niewybaczalne.

    Sam jeszcze nie miałem kłopotów z programem pisanym zarówno w asm i w C. Urządzenia z firmware napisanym w C, które projektowałem pracuja non stop przez kilka lat i nie podejrzewam żeby miało się coś wysypać. Po prostu przekonałem się że w C można programować nawet lepiej niż w asm, dlatego ograniczyłem ten język do wstawek. Jakie to daje korzyści nie wspomnę.

    Niech zgłosi się ten który pisał obliczenia zmienno przecinkowe albo np stos TCP/IP w asm. Niech który sie pochwali co robi w takich przypadkach. Co? Nie da się? Pewnie się da, tylko jakim kosztem i czy już ktoś próbował. :)


    Każdy język ma swoje zalety i wady, a języki wysokiego poziomu są dobre, takie jest moje zdanie.
    Niestety kompilatory to tez programy z błędami, nie można im do końca ufać, w aplikacjach biznesowych, finansowych itp błąd w programie spowodowany przez człowieka czy tez przez błędy w kompilatorze raczej nie zagrożą życiu no chyba że ktoś po stracie kilu zer wyskoczy przez okno. W samolotach czy innych tego typu wynalazkach gdzie życie człowieka zależy od sprzętu na błędy w kompilatorze nie można sobie pozwolić a jedynym sposobem na unikniecie tego typu błędów jest nie stosowanie kompilatorów, więc wcale bym sie nie zdziwił jeśli jest prawdą że te programy dla takich wynalazków są pisane w asemblerze.
    Pisanie i testowanie programów w asemblerze nie musi być trudne jeśli robi to się według zasad i norm które są stworzone do tego typu celów.

    Dodano po 4 [minuty]:

    AnnaWesolaLat23 napisał:
    @michalko12 - dla bankow nie dosc ze pisze sie w C++ to jeszcze w kompilatorze M$


    Przecież ja nic nie mówię, że tam pisze się w asemblerze, nawet sobie tego nie wyobrażam. Nie wyobrażam sobie żeby ktoś nawet bawił się w wstawki asemblerowe, tam po prostu nie ma takiej potrzeby

  • #67 15 Maj 2009 23:35
    kedzi1
    Poziom 18  

    Tak, kompilatory do których mamy dostęp maja błędy, choć coraz mniej. Do specjalnych zastosowań stosuje się inne języki i inne kompilatory. Zresztą co tu mówić procesory też miewają błędy wrodzone. Poprostu klasa narzędzi których używamy sprawiają takie problemy.

    Tu powstaje powiem paradoks, skoro niektórzy twierdzą, że dzięki pisaniu w asm unikną błędów, to dlaczego kompilatory pisane w asm są takie niedoskonałe :).

    Chyba każdy się zgodzi że niektórych programów nie napiszemy wyłącznie w asm. Dobry programista upora się z błędami wynikłymi z wad kompilatora. Zresztą będzie on na bieżąco w znanych błędach. Jak mowiłem są one baaaaardzo rzadkie. Czy ktoś przytoczy przykład takiego błędu, nie pisze tego żeby kogoś ośmieszyć. Pytam z ciekawości ponieważ nie spotkałem się z takowym.

  • #68 15 Maj 2009 23:36
    michalko12
    Specjalista - Mikrokontrolery

    kedzi1 napisał:
    Nie sądzicie, że ludzie, którzy popełnili te błędy pisząc w asm popełnili by ich jeszcze więcej.


    Ja nie sądzę, tak jak napisałem, do tego są stworzone specjalne normy i zasady. Tego nie pisze jedna osoba, a jeszcze więcej osób to testuje. Takie programy nie powstają w kilka dni i nie kosztują kilka k€/k$

  • #69 15 Maj 2009 23:43
    kedzi1
    Poziom 18  

    Zeszliśmy zasadniczo z tematu. Piszemy o mikrokontrolerach i to najczęściej takich jak AVR.

    Pytanie: Czy ograniczanie się w takich aplikacjach do asm jest dobre? W skomplikowanych programach asm odpada, więc jak taką napisze ktoś kto pisze tylko w asm? W prostych tym bardzie nie warto się męczyć.

    Nie pisze już o 16/32 bitowcach do tam już nikt tego nie programuje w asm. Urzeka mnie traktowanie się piszących "zegarki" w asm za wybitnie uzdolniony gatunek na wymarciu. Piszą jak by pisanie w asm było równoważne z osiągnięciem ostatniego poziomu wtajemniczenia. Powiem tak: ja w ramach rozwoju przesiadłem sie z asm na C + asm i bardzo dobrze na tym wyszedłem.

  • #70 15 Maj 2009 23:44
    michalko12
    Specjalista - Mikrokontrolery

    kedzi1 napisał:
    Tak, kompilatory do których mamy dostęp maja błędy, choć coraz mniej.


    Żeby kompilatory nie miały błędów, musiałby nie być rozwijane i wtedy może by osiągnęły taki poziom że prawdopodobieństwo wystąpienia błędu byłoby znikome. Powstają nowe procesory, nowe architektury, w starych architekturach usuwane są błędy wiec kompilatory muszą za tym nadążać,
    użytkownicy żądają nowych opcji i udogodnień których stwórcy kompilatorów nie byli w stanie przewidzieć podczas ich tworzenia. Więc kompilatory muszą być rozwijane i tym samym nie ma szans na to żeby były tworzone w asm i bez błędów.

  • #71 15 Maj 2009 23:49
    kedzi1
    Poziom 18  

    Nie zauważyłeś że profesjonalni koderzy nie rzucają się bezmyślnie na najnowsze wersje kompilatorów. Jeżeli mówimy o nowych procesorach i nowych architekturach to są to procesory coraz bardziej skomplikowane i tam już piszący w asm jakoś się nie chcą pchać, bo nie da się sensownie takich wykorzystać pisząc w asm.

  • #72 15 Maj 2009 23:49
    VanThor
    Poziom 19  

    AnnaWesolaLat23 napisał:
    michalko12 napisał:

    Ciekawostka...
    Podobno w samolotach w krytycznych systemach wszystko co ma jakiś program ma program napisany w asemblerze.


    To tak sie konczy pisanie w C tych niektrytycznych rzeczy: jak np wlaz do samolotu ktory sie zacial (F22).



    A gdzie tam jest napisane, że oprogramowanie było napisane w C?

    Ale przyjmijmy, że tak faktycznie jest - 2 miliony linii kodu w C.
    Szacując bardzo zgrubnie niech zamienny program napisany w asemblerze ma około 20 milionów linii kodu w asemblerze. I teraz niech mi ktoś usiłuje wmówić, że napisze program w asemblerze na 20 milionów linii kodu i nie popełni żadnego, ani jednego błędu! Im większy jest program (liczony w instrukcjach czy liniach danego języka) tym większe prawdopodobieństwo, że pojawią się błędy. Większy kod napisany przez człowieka = więcej błędów. To nie język programowania wprowadza do oprogramowania błędy - robi to człowiek, który go używa. Im więcej człowiek musi stworzyć, tym więcej tych błędów popełni. Poza tym - ktoś stworzył program całkowicie w asemblerze i od kompletnego zera na więcej niż milion linii kodu? Ktoś w ogóle słyszał o takim wyczynie?

    Padł argument, że przy bardzo produkcji w milionach sztuk opłaca się stosować asemblera. A ktoś się zastanowił, w jakim języku stworzono oprogramowanie do telefonu komórkowego, pralki itp? Otóż przeważająca większość to C, C++, Java. Asembler w śladowych ilościach. Nawet w kartach SIM do naszych komórek jest bardzo okrojona, ale jednak Java. Więc jednak nie opłaca się tak bardzo pisać w asemblerze, nawet jeśli trzeba będzie wyprodukować miliony sztuk. Często też ważniejszym aspektem przy tworzeniu oprogramowania jest nie koszt wytworzenia, ale czas - jak się spóźnisz z produktem, albo pozwolisz wyprzedzić konkurencji to zarobisz mniej.

    Ktoś pisał, że jakby systemy operacyjne i oprogramowanie na komputery osobiste było bardziej zoptymalizowane (czyt. pisane w asemblerze) to by się dużo energii zaoszczędziło. A co z energią straconą podczas pisania tego kodu w asemblerze, optymalizacji?

  • #73 15 Maj 2009 23:53
    michalko12
    Specjalista - Mikrokontrolery

    kedzi1 napisał:
    Zeszliśmy zasadniczo z tematu. Piszemy o mikrokontrolerach i to najczęściej takich jak AVR.

    Pytanie: Czy ograniczanie się w takich aplikacjach do asm jest dobre?


    Jedne aplikacje mozna napisac w assemblerze inne nie.

    kedzi1 napisał:

    W skomplikowanych programach asm odpada, więc jak taką napisze ktoś kto pisze tylko w asm?


    Pewnie nie napisze, napisze ja ktoś kto zna język wyższego poziomu.

    kedzi1 napisał:

    W prostych tym bardzie nie warto się męczyć.


    Czasami jest taka potrzeba

    kedzi1 napisał:

    Nie pisze już o 16/32 bitowcach do tam już nikt tego nie programuje w asm. Urzeka mnie traktowanie się piszących "zegarki" w asm za wybitnie uzdolniony gatunek na wymarciu. Piszą jak by pisanie w asm było równoważne z osiągnięciem ostatniego poziomu wtajemniczenia. Powiem tak: ja w ramach rozwoju przesiadłem sie z asm na C + asm i bardzo dobrze na tym wyszedłem.


    I taka powinna być droga poznawania programowania uC. Znajomość asemblera pomaga zrozumieć architekturę procesora i tym samy tworzyć bardziej optymalne wersje kodu w języku wyższego poziomu.

  • #74 15 Maj 2009 23:53
    VanThor
    Poziom 19  

    michalko12 napisał:
    kedzi1 napisał:
    Nie sądzicie, że ludzie, którzy popełnili te błędy pisząc w asm popełnili by ich jeszcze więcej.


    Ja nie sądzę, tak jak napisałem, do tego są stworzone specjalne normy i zasady. Tego nie pisze jedna osoba, a jeszcze więcej osób to testuje. Takie programy nie powstają w kilka dni i nie kosztują kilka k€/k$


    Takie specjalne "normy i zasady" mogą istnieć nie tylko dla asemblera :)

  • #75 15 Maj 2009 23:56
    kedzi1
    Poziom 18  

    Nie chodzi o to żeby udowadniać co jest lepsze. Pytanie zadał młody człowiek, który być może będzie chciał zrobić karierę w tym kierunku. Jeżeli od początku będzie urzywał tylko asm i głupio się przy tym upierał, to bądzmy szczerzy tej kariery nie zrobi. Pewnie będzi robił fajne projekty na DIY ale na ty zakończy. W pewnym momencie stwierdzi że asm nie pozwana na większe projekty i na tym się skończy. ;(

    Cytat:
    Jedne aplikacje mozna napisac w assemblerze inne nie.


    jakich aplikacji nie mogę napisać w C?

    Cytat:
    Pewnie nie napisze, napisze ja ktoś kto zna język wyższego poziomu.


    A ty nie dostaniesz pracy tylko on bo będzie robił wstawki asm i już ciebie nie będzie potrzebował (mówimy o programistach piszących całe programy w asm).

    Cytat:
    Czasami jest taka potrzeba


    Napisz kiedy.

    Cytat:
    Znajomość asemblera pomaga zrozumieć architekturę procesora i tym samy tworzyć bardziej optymalne wersje kodu w języku wyższego poziomu.


    Zgadza się też zaczynałem od asm. Tylko dlaczego mam się do niego ograniczać?

  • #76 16 Maj 2009 00:06
    michalko12
    Specjalista - Mikrokontrolery

    VanThor napisał:

    A gdzie tam jest napisane, że oprogramowanie było napisane w C?

    Ale przyjmijmy, że tak faktycznie jest - 2 miliony linii kodu w C.
    Szacując bardzo zgrubnie niech zamienny program napisany w asemblerze ma około 20 milionów linii kodu w asemblerze. I teraz niech mi ktoś usiłuje wmówić, że napisze program w asemblerze na 20 milionów linii kodu i nie popełni żadnego, ani jednego błędu!


    2mln kodu ???? Jeśli nawet to nie pisane ciurkiem tylko w postaci procedur/ bibliotek które można łatwo testować. Kiedyś programy były pisane na taśmach perforowanych lub kartach, dało się to testować i poprawiać?
    Kwestia tylko ile zasobów trzeba na to poświęcić.
    Jeśli ktoś ma jakiś cel żeby pisać w takim czy innym języku to będzie to robił nie patrząc na koszta i zasoby tego typu. Czasami inne czynniki mają decydujące znaczenie.

  • #77 16 Maj 2009 00:13
    kedzi1
    Poziom 18  

    Cytat:
    Jeśli ktoś ma jakiś cel żeby pisać w takim czy innym języku to będzie to robił nie patrząc na koszta i zasoby tego typu. Czasami inne czynniki mają decydujące znaczenie.


    Zgadza się, ma to swoje uzasadnienia. Tylko dlaczego wciskacie ten asm młodemu człowiekowi, który jak mu się poszczęści to zostanie prawdziwym przyziemnym programistą, któremu raczej nie zdarzy się pisać programów za miliony. Jeżeli nawet to najpierw i tak będzie pisał w C, żeby zrobić najpierw karierę i wykazać się w poważnych projektach.

    No i ma się to nijak do osób, które piszą całe programy w asm na AVR'ki.

  • #78 16 Maj 2009 00:27
    VanThor
    Poziom 19  

    michalko12 napisał:
    VanThor napisał:

    A gdzie tam jest napisane, że oprogramowanie było napisane w C?

    Ale przyjmijmy, że tak faktycznie jest - 2 miliony linii kodu w C.
    Szacując bardzo zgrubnie niech zamienny program napisany w asemblerze ma około 20 milionów linii kodu w asemblerze. I teraz niech mi ktoś usiłuje wmówić, że napisze program w asemblerze na 20 milionów linii kodu i nie popełni żadnego, ani jednego błędu!


    2mln kodu ???? Jeśli nawet to nie pisane ciurkiem tylko w postaci procedur/ bibliotek które można łatwo testować. Kiedyś programy były pisane na taśmach perforowanych lub kartach, dało się to testować i poprawiać?


    Nie wierzysz, że można mieć dwa miliony linii kodu w C :) Można i to dużo łatwiej i szybciej niż w asemblerze 20 milionów. A testować można i kod napisany w asemblerze i w C i w czym tylko się uda napisać. Sama idea testowania ma niewiele wspólnego z jakimkolwiek językiem, więc nie jest żadnym argumentem. Zresztą testowanie też wymaga zaangażowania ze strony człowieka / zespołu ludzi, a gdzie jest człowiek tam są błędy.

    A ta magiczna liczba 2 milionów pochodzi z artykułu na temat domniemanej winy języka C w zablokowaniu klapy samolotu.

  • #79 16 Maj 2009 01:00
    michalko12
    Specjalista - Mikrokontrolery

    kedzi1 napisał:




    jakich aplikacji nie mogę napisać w C?


    Wszystkie możesz tylko nie zawsze pozwalają Ci na to zasoby.
    A tłumaczenie że wtedy trzeba brać mocniejszy procesor nie zawsze jest uzasadnione, weźmy np energooszczędność.


    Cytat:
    Cytat:
    Pewnie nie napisze, napisze ja ktoś kto zna język wyższego poziomu.


    A ty nie dostaniesz pracy tylko on bo będzie robił wstawki asm i już ciebie nie będzie potrzebował (mówimy o programistach piszących całe programy w asm).


    Albo ja nie rozumiem, albo ty się pogubiłeś.
    Niech sobie będą specjaliści od asm, niech sobie będą specjaliści od C
    i niech będą specjaliści od C+ASM, każdy gdzieś jakąś prace znajdzie , jak któryś stwierdzi że ma braki to się doszkoli. To jest tak samo jak ze znajomością różnych architektur procesorów, pracę dostanie ten który akurat zna tą na która ma byc napisany program, raz jest potrzeby programista na taka architekturę innym razem na inną, zdarzy sie może że ten sam programista będzie znał kilka architektur. Życie....



    Cytat:
    Cytat:
    Czasami jest taka potrzeba


    Napisz kiedy.


    Weź napisz coś w C na PIC10Fxxx, pewnie w niektórych przypadkach da się ale w zasadzie będzie to przerost formy na treścią.
    Druga sprawa są procesory dla których nie ma darmowych kompilatorów C, jednych stać innych nie a muszą akurat zastosować taki procesor np ST62xx



    Cytat:
    Cytat:
    Znajomość asemblera pomaga zrozumieć architekturę procesora i tym samy tworzyć bardziej optymalne wersje kodu w języku wyższego poziomu.


    Zgadza się też zaczynałem od asm. Tylko dlaczego mam się do niego ograniczać?


    A kto każe Ci się ograniczać, robisz według własnego uznania i własnych potrzeb. Dobrze wiesz ze jak przyjdzie moment że trzeba bawić się z floatami to z asm nie przebrniesz tego tematu.

    Dodano po 8 [minuty]:

    kedzi1 napisał:

    Tylko dlaczego wciskacie ten asm młodemu człowiekowi, który jak mu się poszczęści to zostanie prawdziwym przyziemnym programistą, któremu raczej nie zdarzy się pisać programów za miliony. Jeżeli nawet to najpierw i tak będzie pisał w C, żeby zrobić najpierw karierę i wykazać się w poważnych projektach.


    Nie wszyscy są karierowiczami...
    Myślę że ten wątek uzmysłowił już nie jednemu ewentualne korzyści stosowanie tego czy innego poziomu języka i że nie warto zatrzymywać się tylko przy C czy też ASM, a jeśli nie to i tak nie ma sensu dalej go przekonywać.

    Dodano po 16 [minuty]:

    kedzi1 napisał:
    Nie zauważyłeś że profesjonalni koderzy nie rzucają się bezmyślnie na najnowsze wersje kompilatorów. Jeżeli mówimy o nowych procesorach i nowych architekturach to są to procesory coraz bardziej skomplikowane i tam już piszący w asm jakoś się nie chcą pchać, bo nie da się sensownie takich wykorzystać pisząc w asm.


    Pisać da się tylko że trzeba opanować wszystko na nowo asembler, architekturę, myślenie i styl pisania, bo porównując AVR i i ARM to uważam że to już jest przepaść.

  • #80 16 Maj 2009 02:24
    BoskiDialer
    Poziom 34  

    Sam temat dochodzi do niesmacznego (dla mnie) poziomu, w którym jedni starają się za wszelką cenę wykazać, że asm jest jedynym słusznym językiem, że w nim można napisać wszystko i jest to lepsze od wszystkiego innego, a drudzy starają się przez całkowite zaprzeczenie pokazać wyższość drugiego. Radzę się powstrzymać, gdyż temat podchodzi pod Podstawowe zasady pisania postów w tym dziale i FAQ" (prowadzenie sporów dotyczących wyższości jednego języka nad innym). Może lepiej podawać jakie dokładnie konstrukcje są niewskazane oraz jak z nimi walczyć (chodzi o C i C++)?

    Owszem są rzeczy, które można napisać tylko w asm (najczęściej są to niskopoziomowe funkcje jak np. przełączanie wątków kiedy brak wsparcia od strony sprzętowej - mam udane implementacje na AVR oraz ARM - cała reszta w C), ale teraz bardziej zwraca się uwagę na elastyczność kodu, możliwość powtórnego wykorzystania kodu. Kompilatory są dzisiaj na tyle dopracowane, że pisanie programu w 100% w asmie jest często sztuką dla sztuki (chociaż są projekty, gdzie są tylko zależności czasowe i jest to wymagane) - optymalizacja jest dobra, kod napisany w C jest wystarczająco dobry (czasem wystarczy rozwiązanie dobre, nie optymalne). Znajomość asemblera wychodzi tylko na dobre programistom C - wiadomo jak zapisać kod, aby mógł zostać lepiej zoptymalizowany dalej będąc przenośnym, jakich konstrukcji unikać, gdyż są trudno realizowalne w kodzie wynikowym (np liczby zmiennoprzecinkowe na avr'ach), oraz co lepiej zapisać w kodzie asemblera, gdyż kompilator sobie nie radzi ze zoptymalizowaniem danego fragmentu lub jest fragment krytyczny czasowo (podczas gdy cała reszta już nie). Zysk czasu przy pisaniu jest ogromny.

    Może napiszę coś o niewskazanych konstrukcjach oraz o tym co można robić, aby kod w C i C++ był porównywalnie optymalny do kodu asemblera:
    - najważniejsze: funkcje statyczne. Kompilatory przeważnie budują moduły osobno, po czym są one łączone przez linker. Jeśli nikt nie ma nawyku oznaczania funkcji wewnętrznych modułów jako statycznych, to będzie dużo funkcji w pliku wynikowym, które nigdy nie zostaną wywołane. Używanie static pozwala usunąć te funkcje, które bez wątpienia są zbędne. Jeśli ktoś uważa, że posiadanie kompilatora oznacza, że można pisać kod byle jak, kompilator ma go doprowadzić do super-perfekcji - jest w błędzie. Umiejętność optymalizacji jest ważna we wszystkich językach, gdyż nie wszystkie założenia dotyczące danych da się przekazać kompilatorowi. Jak by to powiedzieć: kompilator nie zawsze ma to samo "na myśli" co my, przez co nie może zoptymalizować jakiegoś fragmentu.
    - klasy w C++: klasy wprowadzają dość spory narzut - do każdej funkcji przekazywany jest dodatkowy parametr this (chyba, że funkcja jest statyczna a więc nie odnosi się do konkretnej instancji). Różne mechanizmy typu operatory, o ile pamiętam wymagają zwracania referencji na obiekt, co niestety wymaga cykli w każdym wywołaniu funkcji, mimo że nie zawsze wynik jest potrzebny. Mechanizmy typu dziedziczenie są wygodne, jednak pojawiają się dodatkowe tablice funkcji wirtualnych (które zajmują miejsce w pamięci), wywołania wymagają dodatkowych cykli (pobranie wskaźnika na tablicę funkcji, pobranie wskaźnika z tablicy). Nie zawsze te mechanizmy są niezbędne. Dawno nie pisałem w C++, więc ten podpunkt może zawierać błędy.

    Również zaczynałem od pisania w czystym asemblerze. Za największe moje osiągnięcie związane z programowaniem mikrokontrolerów uważam umiejętność łączenia modułów napisanych w całości w asemblerze z modułami napisanymi w całości w C, jak i umiejętność pisania wstawek - dzięki temu mam możliwość wyboru pomiędzy optymalnym a przenośnym.

  • #81 16 Maj 2009 07:44
    mirekk36
    Poziom 42  

    Krisgorn napisał:
    janbernat napisał:
    mirekk36:
    "o kompilowaniu ASM i może co? jeszcze jego optymalizacji?"
    Jak jesteś na 100% pewny że "Chłopów" napisał Słowacki- to sprawdź.
    "Program stosowany do przetwarzania z zapisu źródłowego na postać binarną jest kompilatorem..."
    Jeśli używasz mnemoników w ASM-to potem ten plik tekstowy kompilujesz do postaci 0-1.
    Nie twierdzę że taki program musi coś optymalizować-chyba że jest to makroasembler jak np.
    AVRASM lub C.
    Zanim kogoś op... to sprawdź czy masz rację.


    ... a ty dalej się pogrążasz. W przypadku zamiany mnemoników asemblera na kod binarny nie ma mowy o żadnej kompilacji. Ten proces nazywa się asemblacją.

    człowieku - janbernacie nie idź tą drogą - opanuj się - bo coraz większy wstyd sam sobie przynosisz ;) - panie Słowacki od Chłopów

    a wracając do tematu, to też już wcześniej zwracałem uwagę, że za pomocą co niektórych, szczególnie płci pięknej ;) ... temat zmienia kategorię jak warzywa półki w warzywniaku

    po co to pier-nikowanie o Vistach, $MS ... a nawet już samolotach, kosmosie i młotach pneumatycznych itp ...

    to zaczyna przypominać dyskusję z filmu "Seksmisja" - gdzie któraś wyskoczyła z tekstem "...A KOPERNIK TEŻ BYŁA KOBIETĄ!" .... tutaj też zaczynają już powoli padać podobne argumenty

    poczytajcie to co pisze np kolega BoskiDialer albo inni ale w temacie - bo to można z przyjemnością poczytać i się jeszcze czegoś dowiedzieć - a nie! - gdy sama sieczka leci

  • #82 16 Maj 2009 10:12
    UDMA
    Poziom 16  

    michalko12 napisał:

    Weź napisz coś w C na PIC10Fxxx, pewnie w niektórych przypadkach da się ale w zasadzie będzie to przerost formy na treścią.


    Kiedyś pisałem firmware w C na PIC10F i nie widzę problemu. Trzeba tylko unikać typów wielobajtowych i wywoływania funkcji z parametrami (oszczędność RAM).

  • #83 16 Maj 2009 10:32
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Podejmę wątek kolegi BoskiDialer i również poprę funkcje statyczne. Zapewne nie jest to powszechna wiedza, ale jeśli funkcja nie jest statyczna, dla kompilatora jest globalna - musi więc on założyć, że może ona zostać wywołana przez dowolne źródło w dowolnym momencie. Jeśli zaś funkcja jest statyczna dla danego modułu, to kompilator wie, że jedynie funkcje z danego modułu mogą ją wywołać, a więc może dokonać takich oto optymalizacji:
    1. (o czym wspomniał BoskiDialer) jeśli funkcja nie jest nigdzie używana, zostanie usunięta
    2. Jeśli funkcja używana jest w małej ilości miejsc (ekstremalny przypadek - jedno miejsce), to kompilator może sprawdzić, czy bardziej opłaca się stworzyć osobną funkcję (która musi mieć prolog i epilog - zachowanie stanu i rejestrów oraz odtworzenie owych), czy może włączyć funkcję bezpośrednio do funkcji wywołujących (inline function), co może zajmować mniej miejsca w efekcie (dla jednego wywołania zawsze zajmie mniej miejsca).
    3. Analizować warunki wywołania, które są znane, bo kompilator może dostrzec, że funkcja zawsze wywoływana jest w taki sposób, że połowa jej kodu jest zbędna lub można ją znacząco uprościć.
    4. ...

    ŻADNA z tych optymalizacji nie jest możliwa gdy funkcja jest nie-statyczna. Kompilator przyjmuje wtedy, że możliwa jest KAŻDA możliwa kombinacja parametrów, ze funkcja może zostać wywołana kiedykolwiek i nie może jej w żaden sposób uprościć. Static is your friend!

    Dużym ułatwieniem dla programisty jest stosowanie wewnątrz danego modułu zmiennych statycznych, które mają taką zaletę, że nie są eksportowane jako dostępne z zewnątrz. Co za tym idzie w jednym module możemy mieć zmienną globalną static int index, i nie będzie ona przeszkadzała innym statycznym zmiennym z innych modułów o tej samej nazwie. Gdy projekt się rozrasta, dobrze mięc choć z głowy martwienie się o wymyślanie nowych i zrozumiałych nazw dla zmiennych. Ta sama zaleta odnosi się też do funkcji statycznych.

    Takie kompendium dobrych praktyk byłoby bardzo wskazane! Anyone?

    4\/3!!

  • #84 16 Maj 2009 11:38
    kamyczek
    Poziom 34  

    W tej bitwie nie będzie wygranych będą tylko przegrani bo masę energii idzie na pisanie czegoś co i tak nie doprowadzi do niczego sensownego jedni będą pisać w C i mówić że to najlepsze inni w asemblerze i twierdzić że nie ma nić lepszego. Proponuję zakończyć temat , bo to jeden z tych podobnych do pytania : Co było pierwsze kura czy jajko?. Zaoszczędzony czas wykorzystajmy na przyjemności , zabawę i doskonalenie swoich umiejętności . Miłego weekendu życzę koledzy i koleżanki...

  • #85 16 Maj 2009 11:39
    BoskiDialer
    Poziom 34  

    Często widuję konstrukcje typu:

    Code:
    for(i=0; i<8; i++)
    
      jakasfunkcja(1 << i);

    Taka konstrukcja ma sens przy kompilowaniu na różne platformy, jednak w przypadku avr'ów warto zauważyć, że brak jest instrukcji przesuwania w lewo o dowolną ilość bitów, przez co przesuwanie o zmienną zostaje przekształcone w pętlę co wydłuża wykonywanie. Wystarczy dodać jedną tymczasową przesuwaną o w lewo po każdym przebiegu przez co kod jest szybszy. Często kompilator sam dokona takiego zabiegu, jednak jeśli istnieje dużo zmiennych lokalnych, może tego nie dokonać, gdyż trzeba by zacząć przenosić na stos. Optymalizować można w kierunku minimalizacji rozmiaru kodu, minimalizacji zużycia pamięci oraz minimalizacji czasu wykonywania. Minimalizacja zużycia pamięci może zostać zrealizowana przez liczenie wyrażenia za każdym razem gdy jest potrzebne, jednak rośnie kod. Kod można zmniejszać upraszczając algorytm (np zmiana złożoności), jednak wtedy zmienia się czas wykonywania. Minimalizując czas wykonywania można rozwinąć pętlę, jednak tu rośnie rozmiar kodu. Można też niektóre wyrażenia liczyć raz co zwiększa zużycie pamięci. Kompilator musi balansować pomiędzy tymi trzema wymiarami. Oczywiście są zabiegi, które zmniejszają wszystkie 3 elementy, to bym nazwał zasadniczą optymalizacją.

    Ważnym jest też posiadanie w miarę możliwości najmniejszej liczby zmiennych lokalnych. Przy wywoływaniu funkcji wszystkie zmienne lokalne, które muszą zachować wartość, muszą trafić do innych rejestrów lub na stos, co zwiększa kod (odwołania do stosu lub przenoszenie), zwiększa zużycie pamięci (jeśli zmienne lecą na stos, to zwiększa się rozmiar stosu, jeśli zmienne lecą do innych rejestrów, to tamte rejestry muszą być z początku funkcji przeniesione na stos i na jedno wychodzi). Sam dostęp do stosu (co prawda 2 cykle dla push/pop) jest szybki, jednak pomnożyć liczbę rejestrów odkładanych razy liczba wywołań funkcji i od razu widać, że niektóre wywołania lepiej przesunąć w miejsce (o ile dozwolone), gdzie liczba obowiązujących zmiennych lokalnych (tzn których wartość będzie używana) jest stosunkowo mała.

    Liczba argumentów funkcji - dla mnie za maksimum uznaję 4 argumenty. Przeważnie przy większej ilości muszą one być przekazywane przez stos.

    Warto zauważyć, że znajomość asemblera umożliwia takie zapisywanie programu, aby dawał się on dobrze optymalizować. Hipotetyczny kod:
    Code:
       if(d == -(a << b))
    
          a = b & ~( (d >> c) | (d << (32-c)) );

    Optymalizuje się dwóch instrukcji kompilując na ARM'a (winarm-060606, -Os):
    Code:
       cmn   r3, r0, asl r1
    
       biceq   r0, r1, r3, ror r2

    Co prawda kompilator zastosował tutaj pewien zabieg, który spowoduje że dla c=33 kod będzie działał inaczej niż wynika to z zapisu (d przesunięte w prawo o 33 powinno być równe 0, d przesunięte w lewo o 255 [znaczący jest tylko dolny bajt r2] tez powinno być równe 0, chociaż rotacja nie da zawsze zera), to jednak taki zabieg jest bardzo często poprawny.

    Warto dodać, że pisząc w C a myśląc w asemblerze uzyskuje się równie dobry kod, ale można myśleć o tym co się pisze, a nie jak się pisze (nie trzeba pamiętać o rejestrach, ramkach stosu, o czynnościach które służą temu, aby kod w ogóle działał).

    Jak sobie jeszcze coś przypomnę, to napiszę. Może będzie później warto wydzielić wątek z tematu.

  • #86 16 Maj 2009 12:15
    Freddie Chopin
    Specjalista - Mikrokontrolery

    BoskiDialer napisał:
    Ważnym jest też posiadanie w miarę możliwości najmniejszej liczby zmiennych lokalnych. Przy wywoływaniu funkcji wszystkie zmienne lokalne, które muszą zachować wartość, muszą trafić do innych rejestrów lub na stos, co zwiększa kod (odwołania do stosu lub przenoszenie), zwiększa zużycie pamięci (jeśli zmienne lecą na stos, to zwiększa się rozmiar stosu, jeśli zmienne lecą do innych rejestrów, to tamte rejestry muszą być z początku funkcji przeniesione na stos i na jedno wychodzi). Sam dostęp do stosu (co prawda 2 cykle dla push/pop) jest szybki, jednak pomnożyć liczbę rejestrów odkładanych razy liczba wywołań funkcji i od razu widać, że niektóre wywołania lepiej przesunąć w miejsce (o ile dozwolone), gdzie liczba obowiązujących zmiennych lokalnych (tzn których wartość będzie używana) jest stosunkowo mała.

    Nie mogę się zgodzić, albo zgodzę się częściowo. Kompilator gcc przy włączonej optymalizacji optymalizuje też użycie pamięci dla zmiennych lokalnych.

    Przykładowy kod:

    Code:

    int f(int param)
    {
       int a,b,c,d,e,f,g,h;

       a=2*param;
       b=a/14;
       c=b*b*b;
       d=c+12345;
       e=300-d;
       f=e*888;
       g=f/12;
       h=g+2;

       return h;
    }


    Kod ten po skompilowaniu zajmuje 40 bajtów.

    Kod ten można napisać w jednej linijce przy użyciu jednej zmiennej lokalnej (a nawet zero, bo można liczyć od razu na parametrze funkcji param). Wyglądać to będzie wtedy tak:

    Code:

    int f(int param)
    {
       param=(((300-((((2*param)/14)*((2*param)/14)*((2*param)/14))+12345))*888)/12)+2;

       return param;
    }


    Nie muszę chyba mówić o tym, która wersja jest całkowicie niezrozumiała. GCC optymalizuje takie użycie zmiennych. Zmienna a przestaje istnieć gdy tylko przestaje być potrzebna - przechodzi w zmienną b, któa następnie zmienia się w zmienną c, itd... Czytelność kodu nieskończenie razy lepsza, zysk w aplikacji praktycznie żaden - kod wynikowy funkcji jednolinijkowej zajmuje 32bajty, zapewne kompilator po prostu zoptymalizował obliczenia, które może wykonywać w dowolnej kolejności, skoro są w jednej linijce) Z tego względu należy IMHO ignorować takie optymalizacje jak "mniej zmiennych lokalnych = mniejsza ilość kodu i używanej pamięci", gdyż przy jakiejkolwiek optymalizacji kompilatora (czyli innej niż -O0) jest to całkowicie bezsensowne. W podanych dwóch przykładach obydwie funkcje odkładają na stos TYLE SAMO rejestrów (akurat dla ARMv7 żadnego, bo wszystko liczone jest na 4 standardowo dostępnych dla funkcji wywołanej), choć pierwsza ma 8 zmiennych lokalnych, a druga zero.

    Przykład ten nie demonstruje optymalności kodu, tylko fakt, że oszczędzanie zmiennych lokalnych kosztem czytelności nie ma sensu - optymalne obliczenia są po stronie programisty! Dlatego też ten naprędce sklecony przykład nie powinien być brany jako dowód tego, że jednolinijkowe obliczenia są lepsze (bo zajmują o 8bajtów kodu mniej).

    4\/3!!

  • #87 16 Maj 2009 12:25
    BoskiDialer
    Poziom 34  

    Swoim przykładem tylko potwierdziłeś to, co ja napisałem: "wszystkie zmienne lokalne, które muszą zachować wartość" - po wyliczeniu wartości dla b, wartość zmiennej "a" nie będzie już dalej potrzebna, nie musi zachować wartości, więc można zmienną w tym miejscu porzucić. Może nie wyraziłem się jasno, ale chodziło mi właśnie o posiadanie jak najmniejszej ilości zmiennych których wartość będzie jeszcze wykorzystywana - wszystkie inne można w danym momencie uznać za nieobowiązujące.

    Przy okazji przypomniało mi się, że nie warto wywoływać funkcji w przerwaniach (chodzi głównie o avr'y) - wywołana funkcja (według konwencji) może zmienić wartość rejestrów r0, r18-r27, r30, r31 oraz sreg [a r1 musi być równe 0 podczas wywoływania]. Nawet jeśli funkcja robi proste przypisanie, to funkcja obsługi przerwania musi odłożyć 15 rejestrów na stos, po czym pod koniec je zdjąć (60 cykli zegara), należy też dodać do tego obsługę SREG oraz r1 (dodatkowe 3 cykle).

  • #88 16 Maj 2009 12:58
    Dr.Vee
    VIP Zasłużony dla elektroda

    BoskiDialer napisał:
    Przy okazji przypomniało mi się, że nie warto wywoływać funkcji w przerwaniach (chodzi głównie o avr'y) - wywołana funkcja (według konwencji) może zmienić wartość rejestrów r0, r18-r27, r30, r31 oraz sreg [a r1 musi być równe 0 podczas wywoływania].

    Oczywiście dotyczy to jedynie funkcji łączonych zewnętrznie, tj. z biblioteki lub innej jednostki kompilacji.

    Funkcje statyczne w obrębie danego modułu oraz funkcje inline można wywoływać (o ile zapewni się, że rzeczywiście zostaną rozwinięte w miejscu wywołania). W gcc takie funkcje można porównać do "bezpiecznego makra."

    Pozdrawiam,
    Dr.Vee

  • #89 16 Maj 2009 14:03
    kamyczek
    Poziom 34  

    BoskiDialer napisał:
    ... jednak w przypadku avr'ów warto zauważyć, że brak jest instrukcji przesuwania w lewo o dowolną ilość bitów, przez co przesuwanie o zmienną zostaje przekształcone w pętlę co wydłuża wykonywanie

    A mnożyć przez 2,4,8,16,32,64,128... potrafisz ? mówi coś instrukcja mul ...Problem właśnie w tym że algebra liczb binarnych w przypadku wielu programistów jest powodem braku zrozumienia wielu zagadnień i wybór C ,które uzupełnia braki w wielu zagadnieniach.

  • #90 16 Maj 2009 14:45
    BoskiDialer
    Poziom 34  

    kamyczek: Owszem, istnieje instrukcja mul, tylko zauważ, że ja mówię o "przesuwaniu o zmienną" - w takim przypadku czy mnożenie będzie przez 2, 4, 8 czy 16 jest ustalane w trakcie wykonywania, a więc na potrzeby mnożenia trzeba najpierw wygenerować wartość przez którą się mnoży (coś w rodzaju: a * (1<<i)). Radził bym Ci trochę ostrożniej podchodzić do tego co mówisz oraz zastanowić się, czy potrafisz to poprzeć przykładem.